UNIDAD 2 SISTEMAS DE BASE DE DATOS ORIENTADAS A OBJETOS

2.1 Modelo de datos orientados a objetosLa 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 SGBDOOLas 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 PRODUCTOSSGBD 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 ODMGEste 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 ObjetosIdentidadLa 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 BDOOEncapsulamientoEl 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).

Polimorfismose 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.