Unidad 2. Sistemas de Bases de Datos Orientadas a Objetos

2.1 Modelo de Datos Orientados 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 procedimiento, 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 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 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. La 

orientación a objetos es un paradigma que no se aplica sólo al desarrollo de SGBD sino, en general, al 

desarrollo de sistemas de información.

2.1.3 Productos

SGBD libres

MySQL Licencia Dual

PostgreSQL

SQLite

DB2 Express-C

Apache 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

Oracle Express Edition 10

2.2 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 ultima versión, ODMG 3.0, apareció en enero de 2000.

2.3 Identidad y Estructura de Objetos

Un objeto es una cosa tangible, algo a que se puede aprehender intelectualmente o algo hacia lo que se puede dirigir una acción o pensamiento.

Un objeto representa un item individual e identificable, o una entidad real o abstracta, con un papel definido en el dominio del problema

Un objeto tiene:

Estado

Comportamiento

Identidad

La estructura y el comportamiento de objetos similares se definen en sus clases comunes. El término objeto y ejemplo (instance) de una clase son intercambiables.

Identidad de un objeto

Identidad es la propiedad de un objeto que lo lleva a distinguirse de otros.

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. Así dibuja tendrá un único nombre y podrá emplearse indiferentemente sobre cualquier figura.
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 dentrode 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 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.