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.

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.

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

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.

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

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.

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.