martes, 20 de septiembre de 2011

Bases de datos orientadas a Objetos


    Las aplicaciones de las bases de datos en áreas como el diseño asistido por computadora, la ingeniería de software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones.

    El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensión del concepto ISA del modelo Entidad - Relación. Puesto que el valor de un dato en un objeto también es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.

    El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales.

    1. Estructuras de objetos

    El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.

    Un objeto tiene asociado:
    • Un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.
    • Un conjunto de mensajes a los que el objeto responde.
    • Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje.

    El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación.

    La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos.

    Constructores de tipo

    Todos los tipos de objetos tienen asociado por defecto un método que se encarga de construir nuevos objetos de ese. El nombre del método es el mismo que el nombre del tipo, y sus parámetros que tenemos en dicho método son los atributos del tipo de objetos.

    Pueden ser:

    • Constructores de átomos
    • Constructores de tuplas
    • Constructores de conjuntos

    Encapsulamiento de operaciones, métodos

    Cada objeto contiene y define procedimientos (métodos) y la interfaz mediante la cual se puede acceder a él y otros objetos pueden manipularlo. La mayoría de los SGBDOO permite el acceso directo a los atributos incluyendo operaciones definidas por el propio SGBDOO las cuales leen y modifican los atributos para evitar que el usuario tenga que implementar una cantidad considerable de métodos cuyo único propósito sea el de leer y escribir los atributos de un objeto. Generalmente, los SGBDOO permiten al usuario especificar qué atributos y métodos son visibles en la interfaz del objeto y pueden invocarse desde afuera.

    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.

    Persistencia

    La persistencia es una de las características que los SGBDOO heredan tanto de los SGBD como del modelo de objetos. La diferencia está en que la persistencia proporcionada por el SGBD tradicional, se refiere únicamente a la conservación de los datos, mientras que la persistencia heredada del modelo de objetos hace referencia no sólo a la conservación del estado de un objeto, si no también a la conservación de la clase, que debe trascender a cualquier programa individual, de forma que todos los programas interpreten de la misma manera el estado almacenado. 

    Se puede distinguir entre:
    • ŒPersistencia en el espacio, que hace referencia al hecho de que los objetos creados en una máquina puedan llevarse a otra, y que incluso puedan tener representaciones diferentes en diferentes máquinas. 
    • Persistencia en el tiempo, hace referencia a la cualidad de los objetos de sobrevivir a la ejecución del proceso que los creó

    2. Jerarquía de tipos y clases

    Existe las jerarquías de tipo, en las cuales más tipos especializados (subtipos) tienen todos sus atributos y todos los métodos de los tipos generalizados (supertipos), pero pueden agregar nuevos atributos y métodos particulares.

    En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo. Sería inútil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definición común, aunque difieran en los valores asignados a las variables.

    Así que básicamente las bases de datos orientados a objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase.

    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 SGDB:

    • Herencia de sustitución: en cualquier lugar donde podamos tener un objeto de tipo t’ podemos sustituirlo por un objeto de tipo t si t hereda de t’ (este tipo de herencia se basa en la similitud del comportamiento). 
    • Herencia de inclusión: corresponde a la noción de clasificación y se basa en la estructura del objeto, no en las operaciones. Afirma que t es subtipo de t’ si cada objeto de tipo t es también un objeto de tipo t’. 
    • Herencia de restricción: es un subcaso de la herencia de inclusión. Un tipo t es un subtipo de t’ si está formado por todos los objetos de t que satisfacen una restricción dada. 
    • Herencia de especialización: un tipo t es un subtipo de un tipo t’ si los objetos del tipo t son objetos del tipo t’ que contienen información más específica.

    Las clases en un sistema orientado a objetos se representan en forma jerárquica como en el diagrama anterior, así que las propiedades o características del elemento persona las contendrán (heredarán) los elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar al utilizado en la de especialización (la relación ISA) del modelo E-R.

    Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan.

    3. SGBDOO (Sistema Gestor de Base de Datos Orientada a Objetos) 

    Los sistemas de gestión de bases de datos orientadas a objetos surgen debido a la falta de capacidad semántica del Modelo Relacional para atender nuevos tipos de
    aplicaciones:

    • Diseño y fabricación en ingeniería(CASE, CAD/ CAM) 
    • Bases de datos gráficas y de imágenes. 
    • Bases de datos científicas. 
    • Sistemas de información geográfica. 
    • Bases de datos multimedia. 
    • Acceso uniforme a sistemas de múltiples bases de datos. 

    Este tipo de aplicaciones necesita trabajar con datos de forma diferente a lo que conocemos porque necesitan:

    • Estructuras más complejas para los objetos. 
    • Transacciones de mayor duración. 
    • Nuevos tipos de datos para almacenar imágenes o grandes bloques de texto 
    • Necesidad de definir operaciones no estándar, especificas para cada aplicación. 
    • Controlar versiones y configuraciones. 

    Las bases de datos de objetos están diseñadas para simplificar la programación orientada a objetos. Almacenan los objetos directamente en la base de datos, y emplean las mismas estructuras y relaciones que los lenguajes de programación orientados a objetos. 

    Un SGBDOO es un sistema de objetos y un sistema de bases de datos. Se puede entonces decir que un SGBDOO es un SGBD que almacena objetos, permitiendo concurrencia, recuperación...  

    Para los usuarios tradicionales de bases de datos, esto quiere decir que pueden tratar directamente con objetos, no teniendo que hacer la traducción a tablas o registros. Para los programadores de aplicaciones, esto quiere decir que sus objetos se conservan, pueden ser gestionados aunque su tamaño sea muy grande, pueden ser compartidos entre múltiples usuarios, y se mantienen tanto su integridad como sus relaciones. 

    Las bases de datos tradicionales almacenan sólo datos, mientras que las bases de datos orientadas a objetos almacenan objetos, con una estructura arbitraria y un comportamiento. Una simple metáfora (Esther Dyson) ayuda a ilustrar la diferencia entre ambos modelos. 

    Una posible solución sería traducir cada objeto a tablas, pero esto es una tarea tediosa, y en el caso de utilizar datos complejos puede llegar a ser excesivamente complicado. El problema de la traducción a tablas implica:

    • Tiempo de desarrollo. El tiempo empleado en generar el código para la traducción de objetos a tablas y viceversa. 
    • Errores. Debidos precisamente a esa traducción. 
    • Inconsistencia. Debida a que el ensamblaje/ desensamblaje puede realizarse de forma diferente en las distintas aplicaciones. 
    • Tiempo de ejecución. Empleado en el ensamblaje/ desensamblaje. 

    Muchos vendedores de bases de datos relacionales están incorporando capas de objetos sobre sus motores relacionales (basados en tablas), que son bastante útiles para la integración con aplicaciones y bases de datos de objetos, y que pueden ayudar en la generación de algunos códigos de ensamblaje/ desensamblaje, pero no mejora en absoluto el tiempo de ejecución del problema.

    Manifiestos de de SGBDOO
    • Manifiesto de los Sistemas de Bases de Datos al Objeto puras, ATKINSON, 1989: Enfoque purista que sostiene que los SGBO deben soportar una modelo de objetos puros y no basarse en extensiones semánticas de modelos clásicos como el relacional. 
    • Manifiesto de los SBD de Tercera Generación, STONEBRAKER, 1990: SGBD Relacionales extendidos que sean capaces de soportar los conceptos de orientación al objeto.  Postura que propugnan los principales vendedores de productos relacionales. 
    • Tercer manifiesto, DARWEN y DATE 1995: Reinterpretan el modelo relacional bajo la visión orientada al objeto. 

    4. Diseño de Base de Datos OO por transformación EER-OO

    Para la transformación de EER-OO se usan los lenguajes:

    Lenguaje ODL

    El DDL o lenguaje de definición de datos, se utiliza para expresar la estructura y condiciones de integridad sobre el esquema de la base de datos. En una base de datos  relacional define las tablas, los atributos en la tabla, el dominio de los atributos y las  restricciones sobre un atributo o una tabla.

    En un SGBDOO el DDL debe ser empleado para definir no sólo lo anteriormente mencionado, si no también para definir métodos, datos compuestos, relaciones ISA, herencia, etc.

    El DDL propuesto por ODMG-93 – Estandarización de los sistemas de bases de datos orientados a objetos – denominado ODL pretende principalmente facilitar la portabilidad de los esquemas de las bases de datos. Este ODL no es un lenguaje de programación completo, define las propiedades y los prototipos de las operaciones de los tipos, pero no los métodos que implementan esas operaciones.

    El ODL intenta definir tipos que puedan implementarse en diversos lenguajes de programación; no está por tanto ligado a la sintaxis concreta de un lenguaje de programación particular. De esta forma un esquema especificado en ODL puede ser soportado por cualquier SGBDOO que sea compatible con ODMG-93.

    La sintaxis de ODL es una extensión de la del IDL ( Interface Definition Language) desarrollado por OMG como parte de CORBA (Common Object Request Broker Architecture). 



    Lenguaje OML

    El lenguaje de manipulación es empleado para la elaboración de programas que permitan crear, modificar y borrar datos que constituyen la base de datos. 

    ODMG-93 no propone un OML estándar, simplemente sugiere que este lenguaje sea la extensión de un lenguaje de programación, de forma que se puedan realizar entre 
    otras las siguientes operaciones sobre la base de datos: 

    • Œ Creación de un objeto 
    • Œ Borrado de un objeto 
    • Œ Modificación de un objeto 
    • Œ Identificación de un objeto 

    LENGUAJE OQL

    El lenguaje de consulta propuesto por ODMG-93, presenta las siguientes características: 

    • No es computacionalmente completo. Sin embargo, las consultas pueden invocar métodos, e inversamente los métodos escritos en cualquier lenguaje de programación soportado pueden incluir consultas. 
    • Tiene una sintaxis abstracta. 
    • Su semántica formal puede definirse fácilmente. 
    • Proporciona un acceso declarativo a los objetos. 
    • Tiene una sintaxis concreta al estilo SQL, pero puede cambiarse con facilidad. 
    • Puede optimizarse fácilmente. 
    • No proporciona operadores explícitos para la modificación, se basa en las operaciones definidas sobre los objetos para ese fin. 
    • Proporciona primitivas de alto nivel para tratar con conjuntos de objetos, pero no se restringe sólo a ellas. 

    5. Objetos complejos estructurados, no estructurados


    Un sistema de BBDDOO debe poder dar cabida a diferentes tipos de datos, desde los más sencillos a objetos más complejos, todos ellos de pueden resumir en estos ocho: 

    Tipo abstracto para construir otros tipos. Permite construir nuevos tipos a partir de caracteres, float, enteros. Por ejemplo: punteros, números complejos, cadenas de bits... 

    • Array. Son matrices de elementos de datos, como los que podemos encontrar en innumerables aplicaciones científicas. 
    • Secuencia de tipo: Insertar elementos en una matriz en cualquier posición. 
    • Tuplas: Forma natural de representar las propiedades de una entidad.
    • Conjunto: Forma natural de representar los grupos del mundo real. 
    • Funciones: Para crear, modificar y borrar otros objetos 
    • Uniones: Elementos de datos que pueden tomar diferentes valores de los diferentes tipos, es decir, matrices heterogéneas. 
    • Composición recursiva del resto de tipos, se utiliza para representar objetos complejos, tales como documentos, espacios geométricos... 

    Extensibilidad de tipos


    El conjunto de tipos predefinidos que aporta el sistema de base de datos debe ser extensible mediante algún mecanismo que permita definir tipos nuevos. No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos.

    No hay comentarios:

    Publicar un comentario