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 informacin y modelar
ciertos aspectos del "mundo real", puesto que los modelos clsicos 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 bsicamente 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 representacin de las entidades del "mundo real".

Sobrecarga y poca riqueza semnticas.

Soporte inadecuado para las restricciones de integridad y empresariales

Estructura de datos homognea

Operaciones limitadas

Dificultades para gestionar las consultas re cursivas

Des adaptacin 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 (slo 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

Manipulacin navegacional y de conjunto de registros

Jerarquas de objetos o tipos y herencia

Integracin de los datos con sus procedimientos asociados

Modelos extensibles mediante tipos de datos definidos por el usuario

Gestin de versiones

Facilidades de evolucin

Transacciones de larga duracin

Interconexin e interoperabilidad
Debido a las limitaciones anteriormente expuestas, su uso es ms ventajoso si
se presenta en alguno de los siguientes escenarios:
Un gran nmero de tipos de datos diferentes
Un gran nmero 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 ingeniera, manufacturacin, simulaciones, automatizacin de
oficina y en numerosos sistemas de informacin. No obstante, las BDOO no
estn restringidas a estas reas. Ya que al ofrecer la misma funcionalidad que
su precursoras relacionales, el resto de campos de aplicacin 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 caractersticas de un SGBDOO son:
1.-Debe soportar objetos complejos. Debe ser posible construir objetos
complejos aplicando constructores a objetos bsicos.
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
mtodos, y los datos e implementacin de estos mtodos estn 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 mtodos.
6.-La sobrecarga debe ser soportada, los mtodos 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 programacin de propsito
general.
8.-El conjunto de tipos de datos debe ser extensible. No habr distincin entre
los tipos definidos por el usuario y los tipos definidos por el sistema,
9.-Persistencia de datos. Los datos deben mantenerse despus de que la
aplicacin que los cre haya finalizado, el usuario no tiene que hacer copia
explcitamente.
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.-Recuperacin. El sistema gestor debe de proveer mecanismos de
recuperacin de la informacin en caso de fallo de sistema.
13.-El SGDB debe proveer de manera fcil 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 jerrquicos.
Los SGBD relacionales se basan en el modelo de datos jerrquico. El modelo
jerrquico 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 jerrquica.
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 terminologa
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 ms prometedoras y ms 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 sera
equivalente a la edicion express SQL server de Windows y otra ms completa

de pago, ese pago se hara en la licencia de ella ya que permitira usarse en

otras distribuciones sin usar la licencia GNU.

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

BSDFirebird basada en la versin 6 de InterBase, Initial Developers

PUBLIC LICENSE Version 1.0.

SQLite (http://www.sqlite.org SQLite) Licencia Dominio PblicoDB2

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 Jerrquica

CA-IDMS

SGBD no libres y gratuitos

Microsoft SQL Server Compact Edition Basica

Sybase ASE Express Edition para Linux (edicin gratuita para Linux)

Oracle Express Edition 10

2.2 Estandar ODMG

Este Modelo estndar ODMG, especifica los elementos que se definirn, y en
qu manera se har, para la consecucin de persistencia en las Bases de
datos orientadas a objetos que soporten el estndar. Consta de un lenguaje de
definicin 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 propsito de definir
estndares para los SGBD orientados a objetos. Este grupo propuso un modelo
estndar para la semntica de los objetos de una base de datos. Su ultima
versin, ODMG 3.0, apareci en enero de 2000.
El estndar ODMG es un producto de consorcio internacional OMG, el cual
principalmente proporciona tcnicas orientadas a objetos para la ingeniera
de software. Sus estndares pueden ser aceptados por empresas certificadas
como ISO. El estndar OSMG es el modelo para la semntica de los objetos de
una base de datos. Permite portar tanto los diseos como las
implementaciones en diversos sistemas compatibles.
ODMG est compuesto por:

Modelo de Objeto

El modelo de objetos ODMG permite que tanto los diseos, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone
de las siguientes primitivas de modelado:
Los componentes bsicos de una base de datos orientada a objetos son los
objetos y los literales. Un objeto es una instancia autocontenida de una entidad
de inters del mundo real. Los objetos tienen algn tipo de identificador unico.
Un literal es un valor especfico, 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 especfico compartido por todos los objetos y literales de ese
tipo. Los tipos tambin pueden tener comportamientos. Cuando un tipo tiene
comportamientos, todos los objetos de ese tipo comparten los mismos
comportamientos. En el sentido prctico, 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 operacin puede requerir datos
de entrada (parmetros de entrada) y puede devolver algn 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 mltiples usuarios y aplicaciones. La definicin de una base de
datos est contenida en un esquema que se ha creado mediante el lenguaje de
definicin de objetos ODL (Object Definition Language) que es el lenguaje de
manejo de datos que se ha definido como parte del estndar propuesto para
las bases de datos orientadas a objetos.

Lenguaje de definicin de objeto ODL

ODL es un lenguaje de especificacin para definir tipos de objetos para

sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de
definicin 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 definicin 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 sperconjunto 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 mtodos que stos
poseen.La

sintaxis

bsica

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 programacin la identidad de los objetos sirve para comparar si dos objetos
son iguales o no. No es raro encontrar que en muchos lenguajes de
programacin la identidad de un objeto est determinada por la direccin
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 disposicin, distribucin y orden de las partes del cuerpo de una cosa
determinada inanimada, que puede ser perceptible por algn sentido, y se
puede accionar sobre ella.

Desglosando la definicin, es de considerar que objeto es una cosa, que puede

ser material real (materia con una forma definida, que se puede percibir con
algn sentido (vista, tacto, etc.), ejemplo una mesa, o una manzana), o
abstracta (por ejemplo una idea, o un proyecto que todava no se concreta o se
hace real), y que esa cosa u objeto, est conformado por partes (an lo ms
pequeo, como el tomo, se forma por un conjunto de elementos), y las
mismas estn 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 caractersticas y
comportamientos, esto es, las variables y mtodos. 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 abstraccin 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 slo 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
cmo lo hace.
Herencia
A travs de ella los diseadores pueden crear nuevas clases partiendo de una
clase o de una jerarqua de clases preexistente (ya comprobadas y verificadas)
evitando con ello el rediseo, la modificacin y verificacin de la parte ya
implementada. La herencia facilita la creacin de objetos a partir de otros ya

existentes e implica que una subclase obtiene todo el comportamiento

(mtodos) y eventualmente los atributos (variables) de su superclase.
Es la relacin entre una clase general y otra clase ms especfica. Por ejemplo:
Si declaramos una clase prrafo derivada de una clase texto, todos los
mtodos y variables asociadas con la clase texto, son automticamente
heredados por la subclase prrafo.
La herencia es uno de los mecanismos de los lenguajes de programacin
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
programacin).
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 ejecucin qu mtodo debe
invocarse en respuesta a la recepcin de un mensaje, conocido como enlace
tardo (late binding) o enlace dinmico (dynamic binding).
Polimorfismo
se refiere a la propiedad por la que es posible enviar mensajes sintcticamente
iguales a objetos de tipos distintos. El nico requisito que deben cumplir los
objetos que se utilizan de manera polimrfica es saber responder al mensaje
que se les enva.
La apariencia del cdigo puede ser muy diferente dependiendo del lenguaje
que se utilice, ms all de las obvias diferencias sintcticas.
En lenguajes basados en clases y con un sistema de tipos de datos fuerte
(independientemente de si la verificacin se realiza en tiempo de compilacin o
de ejecucin), es posible que el nico modo de poder utilizar objetos de manera
polimrfica sea que compartan una raz comn, es decir, una jerarqua 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 jerarqua) para enviar el

mismo mensaje (o un grupo de mensajes) al grupo de objetos que se tratan de

manera polimrfica.
No obstante, algunos lenguajes de programacin (Java, C++) permiten que dos
objetos de distintas jerarquas de clases respondan a los mismos mensajes, a
travs

de

las

denominadasinterfaces (esta

tcnica

se

conoce

como composicin de objetos). Dos objetos que implementen la misma interfaz

podrn ser tratados de forma idntica, como un mismo tipo de objeto, el tipo
definido por la interfaz. As, distintos objetos podrn intercambiarse en tiempo
de ejecucin siempre que sean del mismo tipo, y adems con dependencias
mnimas entre ellos. Por estos motivos se considera un buen principio de
diseo en programacin orientada a objetos el favorecer la composicin 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, tambin como un contrato que debe cumplir cualquier clase que
implemente una cierta interfaz, y como una forma de documentacin para los
desarrolladores. A veces, en la literatura especfica sobre Java se habla de
"herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos
de la programacin orientada a objetos porque una clase que implementa una
interfaz slo obtiene su tipo de datos y la obligacin de implementar sus
mtodos, no copia comportamiento ni atributos. Esta terminologa puede llevar
a confusin, 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 composicin, evite la necesidad de la herencia mltiple y favorezca
una utilizacin ms amplia del polimorfismo.

2.5 Persistencia, Concurrencia y Recuperacin en BDOO

Persistencia
Esta se refiere a la capacidad de manipular directamente los datos
almacenados en una base de datos usando un lenguaje de programacin

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
cdigo.Con la persistencia la manipulacin de objetos se realiza directamente
por el lenguaje de programacin 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 mltiples usuarios. Cuando una
aplicacin est accesando a una seccin 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 aplicacin.
Los mecanismos de control de concurrencia son necesarios para reforzar las
propiedades delas transacciones (ACID). Los modos bsicos de control de
concurrencia son: Modo Pesimista Modo optimista Modo mixto Modo semioptimista. El modo pesimista obliga a una transaccin 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 transaccin como si no ocurriera ningn

conflicto y resuelve este al final del commit, generalmente se emplea usando
estampas de tiempo y copias de los elementos de la transaccin. El modo
mixto combina diferentes controles de concurrencia a diferentes objetos y tipos
de datas en una misma transaccin. El modo semi-optimista es una variante
del modo mixto que no detiene a la transaccin hasta que esta termina. Los
principales mecanismos de control de concurrencia son tres: Candados que
prohben accesos que puedan provocar conflictos de acceso Estampas de
tiempo.- estas permiten impedir violaciones a los datos. Guardar mltiples
versiones

Recuperacin

de

los

objetos

de

datos.

Con recuperacin nos referimos al proceso de aplicacin de consistencia

despus de que una transaccin a abortado como resultado de fallas de
hardware o problemas de comunicacin. Las fallas del sistemas, tanto de
hardware como de software no deben repercutir en estados de inconsistencia
de la base datos. La recuperacin es la tcnica que asegura que eso no ocurra.
La recuperacin puede ser total o parcial dependiendo de las circunstancias, de
la recuperabilidad.