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

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.