Conceptos Avanzados de Base de Datos y BD orientado a Objetos

Diferencias entre el modelo ER y el modelo ER extendido

Modelo Entidad-Relación (ER):

En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades.

Entidad: Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección...).

Relación: Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:

-Relaciones 1-1

-Relaciones 1-n

-Relaciones n-n

Modelo Entidad-Relación Extendido(EER):

Varios modelos ER extendidos (EER) han aparecido en la literatura reciente. En general, su contribución es añadir la abstracción de generalización al modelo original.

Detrás de las diferencias sintácticas de varias extensiones está el enriquecimiento semántico acerca de las relaciones entre las entidades. Por ejemplo, muchos de los cambios sintácticos propuestos giran alrededor de la generalización/especialización, una clara indicación de las mejoras semánticas. En el EER se añaden los conceptos de generalización, agregación, clase y subclase.

Clases, superclases, especialización y retícula

Clases:

Una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".

Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variables miembro o variables de instancia), encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.

Superclase:

Entidad en la que se encuentran las subclases (Clase mayor o padre).

Especialización:

Es el proceso por el que se definen las diferentes subclases de una superclase. El conjunto de subclases se define basándonos en características diferenciadoras de las ocurrencias de entidad de la superclase. Por ejemplo, el conjunto se subclases {SECRETARIA, INGENIERO, TECNICO} es una especialización de la superclase EMPLEADO mediante la distinción del tipo de trabajo en cada ocurrencia de entidad. Podemos tener varias especializaciones de una misma entidad basándonos en distintos criterios. Por ejemplo, otra especialización de EMPLEADO podría dar lugar a las subclases ASALARIADO y SUBCONTRATADO, dependiendo del tipo de contrato.

Retícula:

Conocida también como herencia en malla o múltipe. Una malla o retícula consta de clases, cada una de las cuales puede tener una o más superclases inmediatas. Una herencia múltiple es aquella en la que cada clase puede heredar métodos y variables de cualquier número de superclases.

La clase C tiene dos superclases, A y D. Por consiguiente, la clase C hereda las propiedades de las clases A y D. Evidentemente, esta acción puede producir un conflicto de nombres, donde la clase C hereda las mismas propiedades de A y D

Generalización, agregación y asociación

Generalización:

El proceso de especialización expuesto en el punto anterior nos permite lo siguiente:

-Definir un conjunto se subclases a partir de una entidad.

-Asociar atributos específicos a cada subclase.

-Establecer relaciones específicas entre cada subclase con otras entidades o subclases.

Podemos pensar en un proceso inverso de abstracción en el cual suprimimos las diferencias entre las distintas entidades, identificando sus características comunes, y generalizando dichas entidades en una sola superclase de la cual las entidades iniciales serían subclases especiales. Por ejemplo, supongamos las entidades COCHE y CAMION de la figura 2(a); podremos generalizarlas en la entidad VEHICULO, como se muestra en la figura 2(b). Tanto COCHE como CAMION serán ahora subclases de la superclase generalizada VEHICULO. Usamos el término generalización para referirnos al proceso de definición de una entidad generalizada a partir de unas entidades dadas.

Hay que tener en cuenta que el proceso de generalización puede ser visto funcionalmente como el proceso inverso de especialización. Por tanto, en la figura 2 podemos ver {COCHE, CAMION} como una especialización de VEHICULO, así como VEHICULO puede verse como la generalización de COCHE y CAMION. De la misma forma podemos ver en la figura 1 a EMPLEADO como la generalización de SECRETARIA, TÉCNICO e INGENIERO. En algunas ocasiones se utilizan flechas para representar en los diagramas cual a sido la técnica de identificación de superclases/clases.

Agregación:

La agregación es un tipo especial de relación en el que se modela una semántica del tipo “tiene” o “es parte de”, en la que una entidad represente una entidad de mayor tamaño (el “todo”), compuesta de entidades más pequeñas (las “partes”).

Asociación:

Un modelo de datos debe especificar las asociaciones existentes entre las entidades. Estas asociaciones son las relaciones entre entidades. Por ejemplo, la frase "los clientes compran productos" nos dice que hay dos entidades, "Clientes" y "Productos", que están relacionadas por "comprar".

La gran mayoría de las asociaciones son binarias, como "los clientes compran productos" o "los empleados venden productos". Entre las dos hay una asociación ternaria implícita: "los empleados venden productos a los clientes". Con las dos asociaciones binarias independientemente no podríamos saber a qué clientes se han vendido los productos que ha vendido un cierto empleado: en este caso necesitamos de la asociación ternaria.

Las asociaciones entre dos entidades cualesquiera pueden ser de tres tipos: uno-a-uno, uno-a-muchos y muchos-a-muchos.

Asociaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad X se puede asociar con tan sólo un ejemplar de la entidad Y, entonces decimos que la asociación es uno-a-uno. Cuando elegimos una asociación uno-a-uno debemos asegurarnos de que o bien se mantiene la asociación en todo momento, o en caso de que cambie no nos interesan los valores pasados.

Por ejemplo: si asumimos que en los despachos de un edificio hay uno por persona, entonces la asociación será uno-a-uno. Pero esta asociación sólo es cierta en un momento dado. A lo largo del tiempo, se irán asignando diferentes empleados en el edificio. Habrá que valorar si el mantenimiento de esta información es útil en nuestro modelo o no.

Asociaciones uno-a-muchos: Es el tipo de asociación más común, donde un solo ejemplar de una entidad se puede asociar con cero, uno o muchos ejemplares de otra entidad. Por ejemplo, una persona puede tener varios números de teléfono.

Asociaciones muchos-a-muchos: Los clientes compran en muchas tiendas, una tienda tiene muchos clientes. Como este tipo de relaciones no se puede modelar directamente en una base de datos relacional, se modela usando una tabla intermedia que tenga una asociación uno-a-muchos con cada uno de los participantes originales. Por ejemplo, un pedido puede tener muchos tipos de confección, y un tipo de confección puede aparecer en varios pedidos.

Modelado de datos con especialización y generalización

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.

Si todas las subclases en una especialización tienen la condición de pertenencia en el mismo atributo de la superclase, la especialización será una especializació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, como puede verse en la figura 1.

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

FIGURA 1

Se pueden aplicar dos restricciones mas 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. La figura 1 muestra este caso, donde la d del círculo denota la desunión.

FIGURA 2

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, como se muestra en el ejemplo de la figura 2.

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. Por ejemplo, si cada EMPLEADO debe se ASALARIADO o SUBCONTRATADO, entonces la especialización {ASALARIADO, SUBCONTRATADO} de la figura 1 es una especialización total de EMPLEADO; esto se representa en el diagrama ERE usando una línea doble entre el círculo y la superclase. 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. Por ejemplo, si alguna ocurrencia de entidad EMPLEADO no pertenece a ninguna de las subclases {SECRETARIA, INGENIERO, TÉCNICO} de las figuras 1 y 2, entonces la especialización es parcial.

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, si 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.

Categorías y la categorización

En algunos casos, se necesita representar una relación superclase/ clase simple con mas 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 1. 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.

Una categoría tiene dos o más superclases que pueden representar distintas entidades, mientras que las otras relaciones superclase /subclase tienen una sola superclase. Podemos comparar una categoría, como PROPIETARIO en la figura 1, con la subclase compartida JEFE DE INGENIERIA . La segunda es una subclase de cada una de las tres superclases INGENIERO, JEFE y ASALARIADO, de manera que una ocurrencia de JEFE DE INGENIERIA debe existir en las tres. Esto representa la restricción de que un jefe de ingeniería debe se un INGENIERO, un JEFE, y un ASALARIADO; esto es, JEFE DE INGENIERIA es un subconjunto de la intersección de las tres subclases. Por otro lado, una categoría es un subconjunto de la unión de sus superclases. Por tanto, una ocurrencia de entidad que es miembro de PROPIETARIO, debe existir al menos en una de las superclases, pero no tiene que ser miembro de todas. Esto representa la restricción de que un PROPIETARIO puede ser una EMPRESA, un BANCO, o una PERSONA. en la figura 1. En este ejemplo, como en la mayoría de los casos en los que se usan categorías, una ocurrencia de la categoría es miembro de exactamente una de las superclases.

FIGURA 1

Las superclases de una categoría pueden tener diferentes claves, como se ve en la categoría PROPIETARIO de la figura; o pueden tener las mismas claves como se ve en la categoría VEHICULO MATRICULADO. Hay que tener en cuenta que, en el caso de que la categoría sea total, puede ser representada como una especialización o una generalización. En tal caso la elección de cual utilizar es subjetiva. Si dos clases representan las mismas entidades y comparten muchos atributos, incluyendo la misma clave, es preferible la utilización de especialización/generalización; en otro caso la categorización es más apropiada.

Base de datos orientada a objetos

Las bases de datos orientadas a objetos (BDOO) son aquellas cuyo modelo de datos está orientado a objetos y almacenan y recuperan objetos en los que se almacena estado y comportamiento. Su origen se debe a que en los modelos clásicos de datos existen problemas para representar cierta información, puesto que aunque permiten representar gran cantidad de datos, las operaciones que se pueden realizar con ellos son bastante simples.

Las clases utilizadas en un determinado lenguaje de programación orientado a objetos son las mismas clases que serán utilizadas en una BDOO; de tal manera, que no es necesaria una transformación del modelo de objetos para ser utilizado por un SGBDOO. De forma contraria, el modelo relacional requiere abstraerse lo suficiente como para adaptar los objetos del mundo real a tablas.

Las bases de datos orientadas a objetos surgen para evitar los problemas que surgen al tratar de representar cierta información, aprovechar las ventajas del paradigma orientado a objetos en el campo de las bases de datos y para evitar transformaciones entre modelos de datos (usar el mismo modelo de objetos).

Características:

-Objetos: cada entidad del mundo real se modela como un objeto.

La forma de identificar objetos es mediante un identificador de objetos (OID, Object Identifier), único para cada objeto. Generalmente este identificador no es accesible ni modificable para el usuario (modo de aumentar la integridad de entidades y la integridad referencial). Los OID son independientes del contenido. Es decir, si un objeto cambia los valores de atributos, sigue siendo el mismo objeto con el mismo OID. Si dos objetos tienen el mismo estado pero diferentes OID, son equivalentes pero tienen identidades diferentes.

-Encapsulamiento: 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 (Sistema Gestor de Base de Datos Orientada a Objetos) 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.

Otros conceptos utilizados de la misma manera que en la POO son:

o Clases

o Herencia simple, múltiple y repetida.

o Polimorfismo de operación, de inclusión y paramétrico; ligadura tardía (late binding); sobrecarga (overloading) y suplantación o anulación (overriding).

o Objetos complejos

Métodos:

A la vez que creamos un tipo de objeto, realizamos la especificación de los métodos. Los métodos se pueden ejecutar sobre los objetos de su mismo tipo. A continuación mostramos un ejemplo: si x es una variable PL/SQL que almacena objetos del tipo Alumnos_T, entonces x.FechaNacimiento() calcula la fecha de nacimiento del alumno almacenado en x.

-Métodos 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.

-Métodos de comparación:

Estos métodos son utilizados para que se pueda comparar los objetos de un cierto tipo. Esta acción se lleva a cabo indicando cuál es el criterio de comparación. Para poder hacer posible la realización de una comparación es necesario escoger entre un método MAP o un método ORDER:

Un método de MAP es utilizado para indicar cuál de los atributos del tipo se va a utilizar para ordenar los objetos del tipo.

Un método ORDER utiliza los atributos del objeto sobre el que se ejecuta para realizar un cálculo y compararlo con otro objeto del mismo tipo que toma como argumento de entrada. Este método debe devolver un valor negativo si el primero es mayor que el segundo, un valor positivo si ocurre lo contrario y un cero si ambos son iguales.

Persistencia:

Se entiende por persistencia como la acción de preservar la información de un objeto de forma permanente (guardar), pero a su vez también se refiere a poder recuperar la información del mismo (leer) para que pueda ser nuevamente utilizada.

En el caso de persistencia de objetos la información que persiste en la mayoría de los casos son los valores que contienen los atributos en ese momento, no necesariamente la funcionalidad que proveen sus métodos.

La persistencia no es ni una capacidad ni una propiedad de la POO, no tiene nada que ver con el paradigma en sí, solo es el mecanismo que se usa para persistir información de un determinado tipo (como puede ser serializar, guardar los datos en una tabla, en un archivo plano, etc).

Jerarquía de clases y Herencia

Jerarquía de clases:

En la POO, la jerarquía de clases significa un conjunto de clases relacionadas por la jerarquía de generalización/especialización.

A continuación se muestra un ejemplo en el que se describen tres figuras las cuales poseen diferentes niveles de jerarquía:

Consideremos las figuras planas cerradas como el rectángulo, y el círculo. Tales figuras comparten características comunes como es la posición de la figura, de su centro, y el área de la figura, aunque el procedimiento para calcular dicha área sea completamente distinto dependiendo del nivel de las clases.

Podemos por tanto, diseñar una jerarquía de clases, tal que la clase base denominadaFi gura, tenga las características comunes y cada clase derivada las específicas.

Como se muestra en el ejemplo cada figura tiene su nivel de jerarquía a continuación se explicará más detalladamente cada nivel. La claseFigura es la que contiene las características comunes a dichas figuras concretas por tanto, no tiene forma ni tiene área. Esto lo expresamos declarandoFigura como una clase abstracta, declarando la función miembro area abstract.

Jerarquía de herencia:

Conocido también como herencia simple. En esta jerarquía cada clase tiene como máximo una sola superclase. La herencia simple permite que una clase herede las propiedades de su superclase en una cadena jerárquica.

Sistema Gestor de Base de Datos Orientada a Objetos - SGBDOO

Un Sistema de Gestión de Bases de Datos (SGBD) es un conjunto de datos relacionados entre sí y un grupo de programas para tener acceso a esos datos.

Un Sistema de Gestión de Bases de Datos Orientadas a Objetos (SGBDOO) se puede decir que 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 registros o tablas.

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. Consideremos el problema de almacenar un coche en un garaje al final del día. En un sistema de objetos el coche es un objeto, el garaje es un objeto, y hay una operación simple que es almacenar-coche-en-garaje. En un sistema relacional, todos los datos deben ser traducidos a tablas, de esta forma el coche debe ser desarmado, y todos los pistones almacenados en una tabla, todas las ruedas en otra, etc. Por la mañana, antes de irse a trabajar hay que componer de nuevo el coche para poder conducir (problema: al componer piezas puede salir una moto en vez de un coche).

EER-OO en Base de Datos Orientada a Objetos

Los objetos se corresponden con las entidades del modelo E-R (entidad-relación). El paradigma orientado a objetos está basado en el encapsulamiento de los datos y del código relacionado con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos.

Los atributos derivados de las entidades del modelo E-R pueden expresarse en el modelo orientado a objetos como mensajes sólo de lectura. Por ejemplo, el atributo derivado antigüedad de una entidad empleado puede expresarse como el mensaje antigüedad de un objeto empleado. El método que implemente los mensajes, puede determinar la antigüedad restando la fecha-alta del empleado de la fecha actual.

En el modelo orientado a objetos hay que expresar cada atributo de las entidades como una variable y un par de mensajes del objeto correspondiente. La variable se utiliza para guardar el valor del atributo, uno de los mensajes se utiliza para leer el valor del atributo y el otro mensaje se utiliza para actualizar ese valor. Por ejemplo, el atributo dirección de la entidad empleado puede representarse mediante: hay que expresar cada atributo de las entidades como una variable y un par de mensajes del objeto correspondiente. La variable se utiliza para guardar el valor del atributo, uno de los mensajes se utiliza para leer el valor del atributo y el otro mensaje se utiliza para actualizar ese valor.

Objetos complejos estructurados, no estructurados y extensibilidad de tipos

Objetos complejos estructurados:

Están construidos mediante algunos más simples ó mediante la aplicación de constructores a ellos. Los Objetos más simples son objetos como: Integer, Carácter, String de Bytes de cualquier longitud, booleanos ó punto flotante y algunos pueden ser de tipo atómico.

Hay varios constructores de objetos complejos como son: Listas y arreglos. Por ejemplo: El juego mínimo de constructores que el sistema debe tener son una lista y un Arreglo.

Las listas y arreglos son importantes porque pueden capturar ordenes las cuales ocurren en el mundo real y también se pueden levantar en muchas especificaciones científicas donde las necesidades de la gente son matrices, series de tiempo de información ó datos. El objeto de constructores debe ser ortogonal cualquier constructor debe ser aplicado a cualquier objeto.

Objetos complejos no estructrados:

Permiten el almacenamiento y manipulación de objetos de gran tamaño, tales como imágenes, cadenas de texto largas (Objetos Binarios Extensos BLOB).

Extensibilidad de tipos:

Como en un SGBDOO se le permite a los usuarios crear nuevos tipos, y como un tipo incluye a la estructura y a las operaciones, se puede decir que un SGBDOO tiene un sistema de tipos extensibles. Se pueden crear bibliotecas de nuevos tipos definiendo sus estructura y operaciones, incluso con los tipos complejos. Las aplicaciones entonces pueden usar o modificar estos tipos, esto último creando subtipos de los tipos provistos en las bibliotecas.