UNIDAD 2 SISTEMAS DE BASE DE DATOS ORIENTADAS A OBJETOS

2.1 Modelo de datos orientados a objetos

La existencia de problemas para representar cierta información y modelar ciertos aspectos del
"mundo real", puesto que los modelos clásicos permiten representar gran cantidad de datos, pero
las operaciones y representaciones que se pueden realizar sobre ellos son bastante simples.

El paso del modelo de objetos al modelo relacional genera dificultades que en el caso no surgen ya
que el modelo es el mismo.Por lo tanto, las bases de datos orientadas a objetos surgen
básicamente para tratar de paliar las deficiencias de los modelos anteriores y para proporcionar
eficiencia y sencillez a las aplicaciones.

Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos Orientadas a Objetos son:

 Pobre representación de las entidades del "mundo real".

 Sobrecarga y poca riqueza semánticas.

 Soporte inadecuado para las restricciones de integridad y empresariales

 Estructura de datos homogénea

 Operaciones limitadas

 Dificultades para gestionar las consultas re cursivas

 Des adaptación de impedancias

Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado acceso

navegacional

No ofrecen soporte para tipos definidos por el usuario (sólo dominios)Mientras que las
necesidades de las aplicaciones actuales con respecto a las bases de datos son:

 Soporte para objetos complejos y datos multimedia

 Identificadores únicos

 Soporte a referencias e interrelaciones

 Manipulación navegacional y de conjunto de registros

 Jerarquías de objetos o tipos y herencia

 Integración de los datos con sus procedimientos asociados

 Modelos extensibles mediante tipos de datos definidos por el usuario

 Gestión de versiones

 Facilidades de evolución
  Transacciones de larga duración

 Interconexión e interoperabilidad

Debido a las limitaciones anteriormente expuestas, su uso es más ventajoso si se presenta en

alguno de los siguientes escenarios:

Un gran número de tipos de datos diferentes

Un gran número de relaciones entre los objetos

Objetos con comportamientos complejos

Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones entre objetos y
comportamiento de los objetos principalmente en aplicaciones de ingeniería, manufacturación,
simulaciones, automatización de oficina y en numerosos sistemas de información. No obstante, las
BDOO no están restringidas a estas áreas. Ya que al ofrecer la misma funcionalidad que su
precursoras relacionales, el resto de campos de aplicación tiene la posibilidad de aprovechar
completamente la potencia que las BDOO ofrecen para modelar situaciones del mundo real.

2.1.1 Caracteristicas de SGBDOO

Las características de un SGBDOO son:

1.-Debe soportar objetos complejos. Debe ser posible construir objetos complejos aplicando
constructores a objetos básicos.

2.-Identidad del objeto. Todos los objetos deben tener un identificador, el cual es independiente
de los valores de sus atributos.

3.-Encapsulamiento. Los programadores solo tienen acceso a la interfaz de los métodos, y los
datos e implementación de estos métodos están en los objetos.

4.-Tipos o clases. El esquema de una base orientada a objetos contiene un conjunto de clases o
tipos.

5.-Tipos o clases deben ser capaces de heredar de sus super-tipos o superclases los atributos y los
métodos.

6.-La sobrecarga debe ser soportada, los métodos deben poder aplicarse a diferentes tipos.

7.-El DML debe ser completo. El DML en los sistemas gestores de bases de datos orientados a
objetos debe ser un lenguaje de programación de propósito general.

8.-El conjunto de tipos de datos debe ser extensible. No habrá distinción entre los tipos definidos
por el usuario y los tipos definidos por el sistema,
9.-Persistencia de datos. Los datos deben mantenerse después de que la aplicación que los creó
haya finalizado, el usuario no tiene que hacer copia explícitamente.

10.-El SGBD debe ser capaz de manejar bases de datos grandes.

11.-El SGDB debe soportar la concurrencia. Debe disponer del mecanismo para el control de la
concurrencia.

12.-Recuperaci¢n. El sistema gestor debe de proveer mecanismos de recuperación de la

información en caso de fallo de sistema.

13.-El SGDB debe proveer de manera fácil de hacer consultas.

2.1.2 Tipos de SGBDOO

SGBD de red.

Los SGBD relacionales se basan en el modelo de datos de red. Los datos en el modelo de red se

representan mediante colecciones de registros y las relaciones entre los datos se representan
mediante

enlaces, que se pueden ver como punteros. Los registros en la base de datos se organizan como

colecciones de grafos dirigidos. En la figura se presenta un ejemplo de base de datos en red.

SGBD jerárquicos.

Los SGBD relacionales se basan en el modelo de datos jerárquico. El modelo jerárquico es similar
al

modelo de redes, en el sentido en que los datos y las relaciones entre los datos se representan
mediante

registros y enlaces, respectivamente. Éste se diferencia del modelo de redes en que los registros
se

organizan como colecciones de árboles en lugar de grafos dirigidos. En la siguiente figura se

presenta un ejemplo de base de datos jerárquica.

Modelo de datos relacionales.

Basados en el modelo relacional, los datos se describen como relaciones que se suelen
representar

como tablas bidimensionales consistentes en filas y columnas. Cada fila (tupla, en terminología
relacional) representa una ocurrencia. Las columnas (atributos) representan propiedades de las
filas.

Cada tupla se identifica por una clave primaria o identificadora.

Modelo orientados a objetos.

Una de las novedades más prometedoras y más desarrolladas comercialmente de los nuevos
SGBD,

son los basados en un nuevo modelo de datos conocido como modelo orientado a objetos.

2.1.3 PRODUCTOS

SGBD libres

 MySQL Licencia Dual, depende el uso (no se sabe hasta cuando, ya que la compro Oracle).
Sin embargo, existen 2 versiones: una gratuita que sería equivalente a la edicion “express”
SQL server de Windows y otra más completa de pago, ese pago se haría en la licencia de
ella ya que permitiría usarse en otras distribuciones sin usar la licencia GNU.

 PostgreSQL (http://www.postgresql.org Postgresql) Licencia

 BSDFirebird basada en la versión 6 de InterBase, Initial Developer’s PUBLIC LICENSE

Version 1.0.

 SQLite (http://www.sqlite.org SQLite) Licencia Dominio PúblicoDB2 Express-C

(http://www.ibm.com/software/data/db2/express/)

 Apache Derby (http://db.apache.org/derby/)

SGBD no libres

 Advantage Database

 dBase

 FileMaker

 Fox Pro

 IBM DB2 Universal Database (DB2 UDB)

 IBM Informix
  Interbase de CodeGear, filial de Borland

 MAGIC

 Microsoft Access

 Microsoft SQL Server

 NexusDB

 Open Access

 Oracle

 Paradox

 PervasiveSQL

 Progress (DBMS)

 Sybase ASE

 Sybase ASA

 Sybase IQ

 WindowBase

 IBM IMS Base de Datos Jerárquica

 CA-IDMS

SGBD no libres y gratuitos

 Microsoft SQL Server Compact Edition Basica

 Sybase ASE Express Edition para Linux (edición gratuita para Linux)

 Oracle Express Edition 10

2.2 Estandar ODMG

Este Modelo estándar ODMG, especifica los elementos que se definirán, y en qué manera se hará,
para la consecución de persistencia en las Bases de datos orientadas a objetos que soporten el
estándar. Consta de un lenguaje de definición de objetos, ODL, que especifica los elementos de
este modelo. Un grupo de representantes de la industria de las bases de datos formaron el ODMG
(Object Database Management Group) con el propósito de definir estándares para los SGBD
orientados a objetos. Este grupo propuso un modelo estándar para la semántica de los objetos de
una base de datos. Su ultima versión, ODMG 3.0, apareció en enero de 2000.
El estándar ODMG es un producto de consorcio internacional OMG, el cual principalmente
proporciona técnicas orientadas a objetos para la ingeniería de software. Sus estándares pueden
ser aceptados por empresas certificadas como ISO. El estándar OSMG es el modelo para la
semántica de los objetos de una base de datos. Permite portar tanto los diseños como las
implementaciones en diversos sistemas compatibles.

ODMG está compuesto por:

 Modelo de Objeto

El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean
portables entre los sistemas que lo soportan. Dispone de las siguientes primitivas de modelado:

Los componentes básicos de una base de datos orientada a objetos son los objetos y los literales.
Un objeto es una instancia autocontenida de una entidad de interés del mundo real. Los objetos
tienen algún tipo de identificador unico. Un literal es un valor específico, como “Amparo” o 36. Los
literales no tienen identificadores. Un literal no tiene que ser necesariamente un solo valor, puede
ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre. Los
objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio específico compartido
por todos los objetos y literales de ese tipo. Los tipos también pueden tener comportamientos.
Cuando un tipo tiene comportamientos, todos los objetos de ese tipo comparten los mismos
comportamientos. En el sentido práctico, un tipo puede ser una clase de la que se crea un objeto,
una interface o un tipo de datos para un literal (por ejemplo, integer ). Un objeto se puede pensar
como una instancia de un tipo. Lo que un objeto sabe hacer son sus operaciones. Cada operación
puede requerir datos de entrada (parámetros de entrada) y puede devolver algún valor de un tipo
conocido. Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen
con otros objetos. El estado actual de un objeto viene dado por los valores actuales de sus
propiedades.Una base de datos es un conjunto de objetos almacenados que se gestionan de modo
que puedan ser accedidos por múltiples usuarios y aplicaciones. La definición de una base de datos
está contenida en un esquema que se ha creado mediante el lenguaje de definición de objetos
ODL (Object Definition Language) que es el lenguaje de manejo de datos que se ha definido como
parte del estándar propuesto para las bases de datos orientadas a objetos.

 Lenguaje de definición de objeto ODL

ODL es un lenguaje de especificación para definir tipos de objetos para sistemas compatibles con
ODMG. ODL es el equivalente del DDL (lenguaje de definición de datos) de los SGBD tradicionales.
Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. La
sintaxis de ODL extiende el lenguaje de definición de interfaces (IDL)de la arquitectura CORBA
(Common Object Request Broker Architecture).

 Lenguaje de Consulta de objetos OQL

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente
sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de
objetos y estructuras. Está basado en SQL-92, proporcionando un súperconjunto de la sintaxis de
la sentencia SELECT.OQL no posee primitivas para modificar el estado de los objetos ya que las
modificaciones se pueden realizar mediante los métodos que é́ stos poseen.La sintaxis básica de
OQL es una estructura SELECT...FROM...WHERE..., como en SQL.

2.3 Identidad y Estructura de Objetos

Identidad

La identidad es la propiedad que permite diferenciar a un objeto y distinguirse de otros.

Generalmente esta propiedad es tal, que da nombre al objeto. Tomemos por ejemplo el "verde"
como unobjeto concreto de una clase color; la propiedad que da identidad única a este objeto es
precisamente su "color" verde. Tanto es así que para nosotros no tiene sentido usar otro nombre
para el objeto que no sea el valor de la propiedad que lo identifica.

En programación la identidad de los objetos sirve para comparar si dos objetos son iguales o no.
No es raro encontrar que en muchos lenguajes de programación la identidad de un objeto esté
determinada por la dirección de memoria de la computadora en la que se encuentra el objeto,
pero este comportamiento puede ser variado redefiniendo la identidad del objeto a otra
propiedad.

Estructura

Es la disposición, distribución y orden de las partes del cuerpo de una cosa determinada
inanimada, que puede ser perceptible por algún sentido, y se puede accionar sobre ella.

Desglosando la definición, es de considerar que objeto es una cosa, que puede ser material real
(materia con una forma definida, que se puede percibir con algún sentido (vista, tacto, etc.),
ejemplo una mesa, o una manzana), o abstracta (por ejemplo una idea, o un proyecto que todavía
no se concreta o se hace real), y que esa cosa u objeto, está conformado por partes (aún lo más
pequeño, como el átomo, se forma por un conjunto de elementos), y las mismas están dispuestas,
ordenadas, o acomodadas de tal forma que conforman un cuerpo, ya sea que forme parte de la
naturaleza, o haya sido creado por el ser humano (en este caso entonces es una obra de ingenio).

2.4 Encapsulamiento, Herencia y Polimorfismo en BDOO

Encapsulamiento
El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las
variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto
era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el
ocultamiento

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos
a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles
internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será
necesario saber cómo lo hace.

Herencia

A través de ella los diseñadores pueden crear nuevas clases partiendo de una clase o de una
jerarquía de clases preexistente (ya comprobadas y verificadas) evitando con ello el rediseño, la
modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos
a partir de otros ya existentes e implica que una subclase obtiene todo el comportamiento
(métodos) y eventualmente los atributos (variables) de su superclase.

Es la relación entre una clase general y otra clase más específica. Por ejemplo: Si declaramos una
clase párrafo derivada de una clase texto, todos los métodos y variables asociadas con la clase
texto, son automáticamente heredados por la subclase párrafo.

La herencia es uno de los mecanismos de los lenguajes de programación orientada a

objetos basados en clases, por medio del cual una clase se deriva de otra de manera que extiende
su funcionalidad. La clase de la que se hereda se suele denominar clase base, clase
padre, superclase, clase ancestro (el vocabulario que se utiliza suele depender en gran medida del
lenguaje de programación).

En los lenguajes que cuentan con un sistema de tipos fuerte y estrictamente restrictivo con el tipo
de datos de las variables, la herencia suele ser un requisito fundamental para poder emplear
el Polimorfismo, al igual que un mecanismo que permita decidir en tiempo de ejecución qué
método debe invocarse en respuesta a la recepción de un mensaje, conocido como enlace
tardío (late binding) o enlace dinámico (dynamic binding).

Polimorfismo

se refiere a la propiedad por la que es posible enviar mensajes sintácticamente iguales

a objetos de tipos distintos. El único requisito que deben cumplir los objetos que se utilizan de
manera polimórfica es saber responder al mensaje que se les envía.

La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá
de las obvias diferencias sintácticas.
En lenguajes basados en clases y con un sistema de tipos de datos fuerte (independientemente de
si la verificación se realiza en tiempo de compilación o de ejecución), es posible que el único modo
de poder utilizar objetos de manera polimórfica sea que compartan una raíz común, es decir, una
jerarquía de clases, ya que esto proporciona la compatibilidad de tipos de datos necesaria para
que sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos de diversas
subclases de dicha jerarquía) para enviar el mismo mensaje (o un grupo de mensajes) al grupo de
objetos que se tratan de manera polimórfica.

No obstante, algunos lenguajes de programación (Java, C++) permiten que dos objetos de distintas
jerarquías de clases respondan a los mismos mensajes, a través de las
denominadasinterfaces (esta técnica se conoce como composición de objetos). Dos objetos que
implementen la misma interfaz podrán ser tratados de forma idéntica, como un mismo tipo de
objeto, el tipo definido por la interfaz. Así, distintos objetos podrán intercambiarse en tiempo de
ejecución –siempre que sean del mismo tipo–, y además con dependencias mínimas entre ellos.
Por estos motivos se considera un buen principio de diseño en programación orientada a objetos
el favorecer la composición de objetos frente a la herencia de clases.1

En Java las interfaces se declaran mediante la palabra clave "interfaces"Estas se utilizan para lograr
la necesaria concordancia de tipos que hace posible el polimorfismo, también como un contrato
que debe cumplir cualquier clase que implemente una cierta interfaz, y como una forma de
documentación para los desarrolladores. A veces, en la literatura específica sobre Java se habla de
"herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de la
programación orientada a objetos porque una clase que implementa una interfaz sólo obtiene su
tipo de datos y la obligación de implementar sus métodos, no copia comportamiento ni atributos.
Esta terminología puede llevar a confusión, puesto que en Java a menudo se utiliza la mal llamada
"herencia de interfaces" para dotar a una clase de uno o varios tipos adicionales, lo que unido a la
composición, evite la necesidad de la herencia múltiple y favorezca una utilización más amplia del
polimorfismo.

2.5 Persistencia, Concurrencia y Recuperación en BDOO

Persistencia

Esta se refiere a la capacidad de manipular directamente los datos almacenados en una base de
datos usando un lenguaje de programación orientado a objetos. Esto contrasta con una base de
datos utilizada por SQL o una interfaz utilizada por ODBC o JDBC. Utilizando unobjeto de base de
datos significa que se puede tener un mayor rendimiento y se aminora laescritura de código.Con la
persistencia la manipulación de objetos se realiza directamente por el lenguaje de programación
de la misma manera que en la memoria, sin persistencia de objetos. Esto selogra mediante el uso
inteligente de almacenamiento en caché.

Concurrencia
Los SMBDOO deben poder ser accesibles por múltiples usuarios. Cuando una aplicación está
accesando a una sección de la base de datos, otras aplicaciones deben poder acceder a otras
secciones de la base de datos. La concurrencia permite a los usuarios cooperar y colaborar en una
aplicación. Los mecanismos de control de concurrencia son necesarios para reforzar las
propiedades delas transacciones (ACID). Los modos básicos de control de concurrencia son: Modo
Pesimista Modo optimista Modo mixto Modo semi-optimista. El modo pesimista obliga a una
transacción a esperar a que se resuelva el conflicto que pueda o ponga en riesgo la concurrencia
para dejarle continuar cuando el conflicto halla sido resuelto.

El modo optimista deje correr la transacción como si no ocurriera ningún conflicto y resuelve este
al final del commit, generalmente se emplea usando estampas de tiempo y copias de los
elementos de la transacción. El modo mixto combina diferentes controles de concurrencia a
diferentes objetos y tipos de datas en una misma transacción. El modo semi-optimista es una
variante del modo mixto que no detiene a la transacción hasta que esta termina. Los principales
mecanismos de control de concurrencia son tres: Candados que prohíben accesos que puedan
provocar conflictos de acceso Estampas de tiempo.- estas permiten impedir violaciones a los
datos. Guardar múltiples versiones de los objetos de datos.

Recuperación

Con recuperación nos referimos al proceso de aplicación de consistencia después de que una
transacción a abortado como resultado de fallas de hardware o problemas de comunicación. Las
fallas del sistemas, tanto de hardware como de software no deben repercutir en estados de
inconsistencia de la base datos. La recuperación es la técnica que asegura que eso no ocurra. La
recuperación puede ser total o parcial dependiendo de las circunstancias, de la recuperabilidad.