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.

    Conceptos avanzados de modelo de datos


    1. Diferencias entre el modelo ER y el modelo ER extendido (EER)

    El Modelo Entidad-Relación Extendido incluye todos los conceptos del Entidad-Relación e incorpora los conceptos de Subclase y Superclase con los conceptos asociados de Especialización y Generalización. Otro nuevo concepto incluido por el ERE es el de Categoría. Asociado a estos conceptos está el importante mecanismo de Herencia de atributos.
    • SUBCLASE: Grupo de elementos con algo en común, que pertenecen a una ENTIDAD. 
    • SUPERCLASE: Entidad de la que procede una SUBCLASE. 
    • RELACIÓN Clase/Subclase (o Superclase/Subclase): Es una relación 1:1 en la que ambos elementos son el mismo. Se suele representar por ES_UN. 

    Características del Modelo EER:
    • Una Entidad no puede ser sólo miembro de una SUBCLASE. Debe ser también miembro de la SUPERCLASE. 
    • Una Entidad puede ser miembro de varias SUBCLASES. 
    • Una Entidad se define por sus atributos y sus relaciones, los cuales son HEREDADOS por sus SUBCLASES. 
    • Atributos y Relaciones LOCALES o ESPECÍFICAS: Son aquellas que son propias de una SUBCLASE (no de la SUPERCLASE a la que pertenece).


    2. Modelado de las Subclases y Superclases

    En el modelo entidad-relación extendido, una entidad agrupa un conjunto de ocurrencias de entidad del mismo tipo, en muchos casos esas ocurrencias tienen un significado propio para la base de datos y se deberán de representar de otra manera.

    Las subclases deberán de pertenecer a una superclase y podremos tener las relaciones clase/subclase. Debido a que una subclase es a su vez parte de una superclase, la superclase tendrá sus atributos específicos así como los atributos correspondientes a la superclase a la cual pertenece. Si esto existe en un diagrama se dice entonces que existe una herencia. De la misma manera en que se heredan los atributos, las subclases heredarán las relaciones que contenga la superclase.

    Especialización

    El proceso por el que se definen las diferentes subclases de una superclase se conoce como especialización. El conjunto de subclases se define basándonos en características diferenciadoras de las ocurrencias de entidad de la superclase.





    Espec./Generalización en RETÍCULA (malla o red)
    Una subclase puede serlo de varias superclases. En ese caso, la subclase HEREDA los atributos de TODAS sus superclases (por todos los caminos).

    3. Generalización

    Se da cuando se tienen varias entidades con características comunes y pueden crearse una entidad superior que tenga la información general de la aplicación. En otras palabras la generalización es el proceso inverso de la especialización.

    Agregación

    Es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relación abstraída y las entidades que participan en ella en un rectángulo.



    Asociación/Relaciones

    Dos (o más) tipos de relación son exclusivos, respecto de un tipo de entidad que participa en ambos, si cada instancia del tipo de entidad sólo puede participar en uno de los tipos de relación.


    4. Modelos de Datos con Especialización y Generalización

    Las subclases y superclases se corresponden con entidades y por tanto se representarán con rectángulos en el diagrama ERE. Ahora veremos con más detalle las propiedades de especialización y generalización.

    4.1. Restricciones de especialización y generalización

    En general podremos tener varias especializaciones o generalizaciones definidas sobre la misma entidad o superclase. En tal caso las ocurrencias de entidad pueden pertenecer a cada una de las especializaciones. Sin embargo, una especialización o generalización puede consistir en solo una subclase.

    En algunas especializaciones y generalizaciones podremos determinar exactamente que ocurrencias de entidad se convertirán en ocurrencias de cada subclase, mediante la utilización de una condición en algún atributo de la superclase. Tales subclases se llaman subclases definidas por predicado (o definidas por condición). 

    Si todas las subclases en una especialización o generalización tienen la condición de pertenencia en el mismo atributo de la superclase, la especialización será unaespecialización definida por atributo y el atributo será llamado atributo de definición de la especialización. Definiremos una especialización definida por atributo en el diagrama colocando el atributo de definición cerca del arco que va desde el círculo a la superclase.

    Cuando no exista tal condición para determinar la pertenencia a una superclase, la subclase se llamará subclase definida por el usuario. En tales subclases, la pertenencia vendrá determinada por los usuarios de la Base de Datos cuando realicen una operación de inserción de una ocurrencia en la subclase; por tanto, el usuario especifica la pertenencia de cada ocurrencia individualmente y no mediante una condición que pueda ser evaluada automáticamente.



    Se pueden aplicar dos restricciones más a la especialización. La primera es la restricción de desunión, la cual especifica que las subclases de la especialización deben estar separadas. Esto significa que una ocurrencia de la entidad puede ser miembro de como máximo una de las subclases de la especialización. Una especialización definida por atributo implica la restricción dedesunión, si el atributo para definir el predicado de pertenencia es simple. También usaremos la notación d para especificar que una especialización definida por el usuario debe tener la restricción de desunión asociada.



    Si las subclases no son desunidas, sus conjuntos de ocurrencias pueden solaparse, esto es, la misma ocurrencia de entidad puede ser miembro de más de una subclase de la especialización. Este caso, que es el caso por defecto, se representa mediante una O en el circulo.

    La segunda restricción a la especialización se llama la restricción de totalidad, la cual puede ser parcial o total. Una restricción de especialización total especifica que cada ocurrencia de entidad de la superclase debe ser miembro de alguna subclase de la especialización. Una línea sencilla se utiliza para representar una especialización parcial, la cual permite que una ocurrencia de entidad no pertenezca a ninguna de las subclases. 

    Hay que tener en cuenta que las restricciones de desunión y totalidad son independientes, por tanto habrá cuatro tipos de especialización:
    • Desunión, total
    • Desunión, parcial
    • Solapamiento, total
    • Solapamiento, parcial
    Como es lógico, las restricciones correctas vienen dadas por la naturaleza del problema real aplicado a cada especialización, sin embargo, la generalización en una superclase suele ser total, ya que la superclase se deriva de las subclases y, por tanto, contiene sólo ocurrencias de entidad que están en las subclases.

    4.2. Reglas de inserción y borrado para Especialización y Generalización

    Como consecuencia de las restricciones definidas anteriormente, aparecen reglas para la inserción y borrado de Especialización (y Generalización). Algunas de esas reglas son las siguientes:
    • Borrar una tupla de una superclase implica el borrado automático en todas las subclases a las que pertenezca.
    • Insertar una tupla en una superclase implica que tiene que ser obligatoriamente insertada en todas las subclases definidas por predicado en las que satisfaga el predicado de definición.
    • Insertar una tupla en una superclase de una especialización total implica una inserción obligatoria en al menos una de las subclases de la especialización.

    4.3. Jerarquías de Especialización, Red de Especialización y Herencia Múltiple.


    Una subclase puede, a su vez, tener más subclases especificadas a partir de ella, formando una jerarquía o red de especializaciones. Una jerarquía de especialización tiene la restricción cada subclase participa (como subclase) en una relación clase/subclase. Como contraste, para una red de especialización una subclase puede ser subclase en mas de una relación clase/subclase. 




    En tal red o jerarquía de especialización, una subclase hereda no solamente los atributos de su superclase directa, sino también todos los de sus predecesores hasta la raíz. 

    Una subclase con más de una superclase se llama subclase compartida. Hay que tener en cuenta que una subclase compartida implica una red; si no existen subclases compartidas estaremos en presencia de una jerarquía en vez de una red.

    Aunque se ha utilizado la especialización para definir estos conceptos, la generalización es igualmente aplicable a estos. Por tanto podremos hablar de la misma forma de jerarquía de generalización y red de generalización.

    4.4. Diseño Top-down frente a Bottom-up

    En el proceso de especialización, solemos empezar con una entidad y a continuación definimos las subclases de la entidad mediante especializaciones sucesivas; esto es, definimos repetitivamente más agrupamientos específicos a partir de la entidad. Esta especialización sucesiva corresponde a un proceso de refinamiento conceptual top-down durante el diseño del esquema conceptual.

    Es posible llegar a la misma jerarquía o red desde otra dirección. En tal caso el proceso conlleva generalización en vez de especialización y corresponde a una síntesis conceptual bottom-up. En términos estructurales, las jerarquías o redes resultantes de ambos procesos puede se idénticas; la única diferencia radica en la manera o el orden en que se especifican las clases y subclases del esquema.

    En la práctica, es frecuente que no se utilice solamente especialización o solamente generalización, sino una combinación de ambos procesos. En este caso, se incorporan continuamente nuevas clases a la jerarquía o la red según se van haciendo visibles para usuarios y diseñadores.

    5. Categorías y Categorización

    Una categoría es una subclase de la unión de dos o más superclases que pueden tener diferentes claves ya que pueden representar diferentes entidades. En este caso es necesario sintetizar una clave subrogada, que identifique cada una de las ocurrencias de la categoría y que será heredada como clave foránea por cada una de las superclases. Por cuestiones de eficiencia a la hora de realizar los joins entre la categoría y sus correspondientes clases, se añadirá un atributo a la tabla de la categoría que exprese a que subclase pertenece cada túpla en particular.