martes, 20 de septiembre de 2011

Sistema de Gestión de Base de Datos Orientado a Objetos

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.


Jerarquías de tipos, de clases y herencia.

Jerarquía de clases.

  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.
 Por ejemplo: Retomemos la relación alumno-cursa-materia agregándole la entidad maestro; donde los atributos considerados para cada uno son alumno: Nombre, Dirección, Teléfono, Especialidad, Semestre, Grupo; Maestro: Nombre, Dirección, Teléfono, Número económico, Plaza, RFC; Materia: Nombre, Créditos, Clave.


Estructuras de objetos, constructores de tipos, Encapsulamiento de operaciones, métodos y persistencia

  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 está 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.

Estructura 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
Constructores de conjunto
Son cruciales porque son una forma natural de representar las colecciones del mundo real y se utilizan para definir atributos multi-elevados, solo se puede aplicar a tuplas.

Constructores de tuplas
Son importantes porque proporcionan un medio natural para representar los componentes o propiedades de entidad, solo puede ser aplicado a valores atómicos.

Constructores de átomos
Los átomos son como las constantes y los identificadores de un lenguaje imperativo: incluye los números, las cadenas, los nombre, las funciones y unos cuantos constructores.


Uso de las categorías y la categorización

Todas las relaciones superclase/subclase vistas hasta ahora tienen superclase única. Incluso la subclase compartida JEFE DE INGENIERIA en la red de la figura 5 es una subclase de tres relaciones superclase/subclase distintas, donde cada una de las relaciones tiene una superclase única. En algunos casos, sin embargo, se necesita representar una relación superclase/ clase simple con más de una superclase, donde las superclases son diferentes entidades. En este caso llamamos a la subclase categoría.

Por ejemplo, supongamos que tenemos tres entidades: PERSONA, BANCO y EMPRESA. En la Base de Datos de vehiculo, un dueño de un vehiculo puede ser una persona, un banco o una empresa. Necesitaremos crear una clase que contenga ocurrencias de las tres entidades para desempeñar el papel de propietario. Se creará con este fin una categoría propietario que sea una subclase de la unión de la clases EMPRESA, BANCO y PERSONA. Representaremos las Categorías en el diagrama ERE como se muestra en la figura 7. Las superclase EMPRESA, BANCO y PERSONA se conectan al círculo con el símbolo U (unión). Un arco con el símbolo de pertenencia conecta el circulo con la categoría (subclase) PROPIETARIO. Si es necesario un predicado de definición, éste se coloca cerca de la línea de la superclase a la cual se aplica el predicado. En la figura 8 tenemos dos categorías: PROPIETARIO, la cual es una subclase de la unión de PERSONA, BANCO y EMPRESA; y VEHICULO MATRICULADO, la cual es una subclase de la unión de COCHE y CAMION.


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

Restricciones de especialización y generalización.

En los siguientes párrafos veremos las restricciones aplicables a una especialización o a una generalización; sin embargo, por abreviar, nuestra visión se referirá solamente a la especialización en vez de a ambas técnicas.
En general podremos tener varias especializaciones 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 puede consistir en solo una subclase, tal como JEFE ; en tal caso no utilizaremos la notación círculo.
En algunas especializaciones 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). Por ejemplo, si la entidad EMPLEADO tiene el atributo tipotrabajo, como se ve en la figura 3, podremos especificar una condición de pertenencia a la subclase SECRETARIA mediante el predicado tipotrabajo = "Secretaria"), al cual llamaremos predicado de definición de la subclase. Esta condición es una restricción especificando que los miembros de la subclase SECRETARIA deben satisfacer el predicado y que todas las ocurrencias de la entidad EMPLEADO en las que el valor del atributo tipotrabajo sea "Secretaria" deben pertenecer a la esta subclase.


Modelado de la generalización, agregación y asociación

Agregación
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:
    • Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamadaComposición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").
    • Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:

En donde se destaca que:
    • Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
    • Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
    • La composición (por Valor) se destaca por un rombo relleno.
    • La agregación (por Referencia) se destaca por un rombo transparente.

Modelado de las clases, superclases, especialización y retícula

Subclases, Superclases y Especialización.

En el modelo Entidad-Relación, una entidad agrupa un conjunto de ocurrencias de entidad del mismo tipo. En muchos casos, estas ocurrencias se pueden agrupar a su vez en otros subconjuntos que tienen un significado propio para los propósitos de la Base de Datos y, por tanto, deberían representarse de forma explícita. Por ejemplo, la entidad EMPLEADO puede a su vez subdividirse en SECRETARIA, INGENIERO, JEFE, TÉCNICO, ASALARIADO, SUBCONTRATADO, etc. El conjunto de ocurrencias de entidad en cada una de estas entidades será un subconjunto de las ocurrencias de entidad de EMPLEADO, ya que por ejemplo, un ingeniero también es un empleado. Llamaremos a cada uno de estos subconjuntos Subclases de la entidad EMPLEADO y a EMPLEADO una Supercalse de cada uno de estos subconjuntos.

Llamaremos a la relación existente entre las Superclases y las Subclases como relación Clase/Subclase. En el ejemplo anterior, EMPLEADO/SECRETARIA y EMPLEADO/TÉCNICO son dos relaciones Clase/Subclase. Hay que tener en cuenta que una ocurrencia de una Subclase representa el mismo objeto real que alguna correspondiente a su Superclase, por ejemplo la SECRETARIA "Concha Leco" será también la EMPLEADO "Concha Leco".


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

El Modelo Entidad-Relación.
Es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades.
  • Se elabora el diagrama (o diagramas) entidad-relación.
  • Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:
  • Transformación de relaciones múltiples en binarias.
  • Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
  • Conversión en tablas (en caso de utilizar una base de datos relacional).

El modelo de datos entidad-relación está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objetos.