Unidad II. Sistemas de bases de datos orientadas a objetos

2.1. El modelo de datos orientado a objetos.

Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos adaptadas a estos lenguajes.

La programación orientada a objetos permite cohesionar datos y procedimientos, haciendo que se diseñen estructuras que poseen datos y procedimientos; haciendo que se diseñen estructuras que poseen datos (atributos) en las que se definen los procedimientos (operaciones) que pueden realizar con los datos. En las bases orientadas a objetos se utiliza esta misma idea.

A través de este concepto se intenta que estas bases de datos consigan arreglar las limitaciones de las relacionales. Por ejemplo, el problema de la herencia (el hecho de que no se puedan realizar relaciones de herencia entre las tablas), tipos definidos por el usuario, disparadores (triggers) almacenables en la base de datos, soporte multimedia...

Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales, aunque son el tipo de base de datos que más está creciendo en los últimos años.

Su modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG (Object Data Management Group), grupo de administración de objetos de datos, organismo que intenta crear estándares para este modelo.

2.1.1. Características de los SGBDOO.

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 súper-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 genera
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.

Las Bases de datos orientados a objetos se propusieron con la idea de satisfacer las necesidades de las aplicaciones más complejas. El enfoque orientado a objetos ofrece la flexibilidad para cumplir con algunos de estos requerimientos sin estar limitado por los tipos de datos y los lenguajes de consulta disponibles en los sistemas de bases de datos tradicionales.

Como cualquier Bases de Datos programables, una Base de Datos Orientada a Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un depósito persistente listo para su explotación.

Una BDOO almacena y manipula información que puede ser digitalizada (presentada) como objetos, además proporciona un acceso ágil y permite una gran capacidad de manipulación.

Los principales conceptos que se utilizan en las Bases de Datos Orientada a Objetos (BDOO) son las siguientes:

1. Identidad de objetos.

2. Constructores de tipos.

3. Encapsulamiento.

4. Compatibilidad con los lenguajes de programación.

5. Jerarquías de tipos y herencia.

6. Manejo de objetos complejos.

7. Polimorfismo y sobrecarga de operadores.

8. Creación de versiones.

BDOO

Está diseñada para simplificar la POO almacena objetos directamente en la base de datos empleando las mismas estructuras que leguajes de programación.

SGBOO

Es un sistema de objetos y un sistema de base de datos que almacena objetos permitiendo la concurrencia y recuperación. Pueden tratar directamente con los objetos sin hacer la traducción a tablas registros, para los programadores de aplicación (general o específica) los objetos se conservan en su forma y tamaño pueden compartirse con múltiples usuarios.

Niveles de abstracción

1. Interno. - Como se van a guardar los objetos (disco duro).

2. Conceptual. - Como guardar la estructura.

3. Externo. - Lo que vamos a mostrar al usuario (interfaz).

Consideraremos el problema de almacenar un coche en el garaje en un sistema de objetos, el coche es un objeto, el garaje es un objeto y hay una operación simple que es almacena el coche en el garaje. En el sistema relacional todos los datos se traducen en tablas, entonces el coche debe de ser desarmado, las llantas se colocan en un lugar, los birlos en otro lugar, por la mañana antes de salir hay que componer el coche antes de conducir.

Aplicaciones de la BDOO

1. Diseño asistido por computadora CAD.

2. Fabricación asistida por computadora CAM.

3. Ingeniería de software asistido por computadora CASE.

4. Sistemas de gestión de red.

5. Sistemas de información de oficina y sistemas multimedia OIS.

6. Sistema autoedición digital.

7. Sistemas de información geográfica GIS.

8. Sistemas Web interactivos dinámicos.

2.1.3. Productos.

El número de productos para utilizar XML con Bases de Datos está creciendo a una gran velocidad. Nuevos productos entran al mercado de forma constante. Aquí se realiza una clasificación de estos productos, mencionando cuales son las características genéricas de los mismos, que funcionalidades brindan y se analizan algunos de estos productos existentes en el mercado.

Antes de continuar, hay que realizar la aclaración de que los documentos XML pertenecen a dos categorías: "basados en datos" y "basados en documentos". Los documentos XML "basados en datos" son en los que XML es usado como un transporte de datos. Estos son por ejemplo órdenes de compra, registros de pacientes y datos científicos. Los "basados en documentos" son en los que XML es usado para representar documentos, como un manual de usuario, páginas estáticas, folletos de marketing. Este último tipo de documento se caracteriza por su estructura irregular.

Para grabar y recuperar datos en un documento "basados en datos", se necesitará una Base de datos, como puede ser una Base de Datos relacional o una orientada a objetos.

Para grabar y recuperar datos en un documento "basados en documentos", se necesita una Base de Datos de XML o un Sistema de Administración de Contenidos. Ambos están diseñados para almacenar fragmentos del contenido, como procedimientos, capítulos, y glosarios, y pueden incluir metadatos, como nombre del autor, fecha de revisión, etc. Un Sistema de Administración de Contenidos generalmente tiene funcionalidades adicionales, como editores, controladores de versiones, etc. [Bourret R., XML].

En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas:

Prototipos Experimentales

• ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer.

Y entre los sistemas disponibles en el mercado están:
Sistemas de Bases de Datos Comerciales Orientados a Objetos

• GEMSTONE/OPAL de ServicLogic,
• ONTOS de Ontologic,
• Objectivity de Objectivity Inc.,
• Versant de Versant Technologies,
• ObjecStore de Object Design y
• O2 de O2 Technology.

Esta es solo una lista parcial de los prototipos experimentales y de los sistemas de bases de datos comerciales orientados a objetos. Desafortunadamente, es aún demasiado pronto para saber cuáles sistemas se instalarán como líderes en este campo.

2.2. El estándar 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 última 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 único. 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 un objeto 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).

Fuente: http://acrediteme.blogspot.mx/2013/12/unidad-2-sistemas-de-base-de-datos.html

2.4. Encapsulamiento, herencia y polimorfismo en BDOO.

Encapsulamiento

El encapsulamiento se centra en la implementación que da lugar al comportamiento observable de un objeto. El encapsulamiento se consigue a menudo mediante la ocultación de información, es decir, se basa en ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.

El encapsulamiento proporciona, por tanto, barreras explícitas entre abstracciones diferentes. Existen dos visiones diferentes del encapsulamiento [ATK89], la primera y original que es la del lenguaje de programación; y la segunda que es la adaptación de esa visión para la base de datos.

Desde el punto de vista de las bases de datos, esto se traduce en el hecho de que un objeto abarca operaciones y datos, pero con una diferencia. En las bases de datos no está claro si la parte estructural es parte de la interfaz (depende del sistema), mientras que en los lenguajes de programación la estructura de datos es claramente parte de la implementación y no de la interfaz. Como se puede observar, el encapsulamiento proporciona una forma lógica de independencia de los datos, ya que se puede cambiar la implementación de un tipo sin cambiar ninguno de los programas que usan ese tipo.

Herencia

Las clases o tipos heredan de sus ancestros.

Ventajas de la herencia

• Ayuda al modelado porque proporciona una descripción concisa y precisa del mundo.
• Ayuda a compartir especificaciones e implementaciones en las aplicaciones.
• Tipos de herencia a destacar en los sistemas de gestión de bases de datos
• Herencia de sustitución: en cualquier lugar donde podamos tener un objeto de tipo podemos sustituirlo por un objeto de tipo t si t hereda de t’.
• Herencia de restricción: es un subcaso de la herencia de inclusión. Un tipo t es un subtipo de si está formado por todos los objetos de t que satisfacen una restricción dada.
• Herencia d especialización: un tipo t es un subtipo de t’, si los objetos de tipo t son objetos de tipo t’ que contienen información más específica.

Polimorfismo

Existen casos en los que se desea tener el mismo nombre para diferentes operaciones. Supongamos la operación dibuja que toma un objeto como entrada y lo dibuja en pantalla. Dependiendo del tipo de objeto (cuadrado, estrella, flecha, …) debemos emplear diferentes mecanismos de visualización. Es decir, necesitamos visualizar un conjunto cuyos miembros no se conocen en tiempo de compilación.

En una aplicación que emplee el sistema convencional, habrá tantas operaciones como figuras a representar: dibuja cuadrado, dibuja estrella, dibuja flecha etc. En un sistema orientado a objetos se definirá la operación en una clase más general.

Para proporcionar esta nueva funcionalidad, el sistema no puede asociar los nombres de las operaciones con los métodos correspondientes en tiempo de compilación; se hará en tiempo de ejecución. Esto es lo que se conoce como ligadura tardía y dificulta o imposibilita el chequeo de tipo.

Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos:

Encapsulación – Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos.

Herencia – Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases.

Polimorfismo – Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones.

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 un objeto de base de datos significa que se puede tener un mayor rendimiento y se aminora la escritura 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 se logra 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 haya 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 accesoEstampas 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 sistema, 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.