Unidad 7

Bases de Datos Orientadas a Objetos

Los modelos de bases de datos tradicionales (relacional, red y jerárquico) han sido capaces de satisfacer con éxito las necesidades, en cuanto a bases de datos, de las aplicaciones de gestión tradicionales. Sin embargo, presentan algunas deficiencias cuando se trata de aplicaciones más complejas o sofisticadas como, por ejemplo, el diseño y fabricación en ingeniería (CAD/CAM, CIM), los experimentos cientificos, los sistemas de información geografica o los sistemas multimedia. Los requerimientos y las características de estas nuevas aplicaciones difieren en gran medida de las típicas aplicaciones de gestión: la estructura de los objetos es más compleja, las transacciones son de larga duración, se necesitan nuevos tipos de datos para almacenar imágenes y textos, y hace falta definir operaciones no estándar, especıficas para cada aplicación. 

Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientación a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no está limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. Una característica clave de las bases de datos orientadas a objetos es la potencia que proporcionan al diseñador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos.

Tipos de datos complejos

Colecciones

Los conjuntos son ejemplares de los tipos colección. Otros ejemplares son los arrays y los multiconjuntos (es decir, colecciones sin orden donde un elemento puede aparecer varias veces). Las siguientes definiciones de atributos ilustran la declaración de un array:

array-autores varchar(20) array [10]

array-autores es un array de hasta 10 nombres de autor

Se puede acceder a los elementos del array especificando el índice del array, por ejemplo:

array-autores[1]

Objetos de gran tamaño (LOB)

Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios Kbytes), tales como la fotografía de una persona, o muy grandes (del orden de varios Mbytes o incluso Gbytes), tales como imágenes médicas de alta resolución o clips de video. SQL proporciona por tanto nuevos tipos de datos para objetos de gran tamaño para datos de caracteres (clob) y binarios (blob). Las letras “lob” en estos tipos de datos son acrónimos de “LargeObject” (objeto grande). Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicación conseguiría un “localizador” de un objeto grande y lo usaría para manipularlo desde el lenguaje anfitrión.

Tipos estructurados

Los tipos estructurados permiten la representación directa de atributos compuestos de los diagramas E-R. Un tipo estructurado puede tener métodos definidos sobre él. Los métodos se declaran como parte de la dentición de tipos de un tipo estructurado.

Constructores

Hay que definir funciones constructoras para crear valores de tipos estructurados. En SQL y en muchos otros lenguajes se utiliza una función con el mismo nombre que un tipo estructurado como función constructora. De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predefinidos. Cualquier otra función constructora tiene que crearse explícitamente. Puede haber más de una constructora para el mismo tipo estructurado; aunque tengan el mismo nombre, solo tienen que ser distinguibles por el número de argumentos y sus tipos.

Herencia

La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerara la herencia de los tipos y después en el nivel de las tablas.

Herencia de tipos

Los tipos derivados heredan los atributos de superclase. Los métodos también se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarandolo de nuevo. Esto se conoce como sobre-escritura (overriding) del método.

Herencia de tablas

Las subtablas en SQL se corresponden con la noción del modelo E-R de la especialización y la generalización. Por tanto, cada atributo presente en una supertabla debe estar también presente en las subtablas. Además, cuando se declaran subtablas derivadas de una supertabla, cada tupla presente en una subtablas también esta presentes en la supertabla. En principio, serıa posible la herencia múltiple tanto en tipos como en tablas, pero ANSI SQL no lo soporta. Las subtablas pueden guardarse de manera eficiente sin replica de todos los campos heredados  de una de las dos siguientes formas:

Cada tabla almacena la clave primaria (que se puede heredar de una tabla padre) y los atributos definidos localmente.

Los atributos heredados (aparte de la clave primaria) no hace falta guardarlos y pueden obtenerse mediante una reunión con la supertabla basada en la clave primaria.

Cada tabla almacena todos los atributos heredados y definidos localmente, cuando se inserta una tupla se almacena solo en la subtabla en la que se inserta y su presencia se infiere en cada supertabla. El acceso a todos los atributos de una tupla es más rápido, dado que no se requiere una reunión.

Tipos de arreglo multiconjunto en sql

SQL soporta dos tipos de conjuntos arrays y multiconjuntos. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. Los multiconjuntos son como los conjuntos, salvo que os conjuntos permiten que cada elemento aparezca, como mucho una vez. Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro, además se desea almacenar el nombre de los autores de un libro en forma de array, a diferencia de los elementos de los multiconjuntos, los elementos de los arrays están ordenados, de modo que se puede distinguir el primer autor del segundo, etc. Estos se pueden definir como arrays y como multiconjuntos:

Créate type Editor as(nombre varchar(20),

sucursal varchar(20))

créate type Libro as (titulo varchar(20),

array_autores varchar (20) array [10],

fecha_publicacion date,

editor Editor,

conjunto_palabras_clave varchar(20)[multiset]

create table libro of Libro

La primera instrucción define el tipo denominado Editor, que tiene dos componentes: nombre y sucursal.

La segunda instrucción define el tipo estructurado Libro, que contiene título, un array_autores, que es un array de hasta de diez nombres de autor, una fecha de publicación, un editor y un multiconjunto de palabras clave. Finamente se crea la tablalibros, que contiene las tuplas del tipo libro.

Identidad de los objetos

El concepto de la identidad de los objetos tiene una relación interesante con los punteros de los lenguajes de programación. Una manera sencilla de conseguir una identidad intrínseca es utilizar los punteros a las ubicaciones físicas de almacenamiento. En concreto, en muchos lenguajes orientados a objetos como C++, los identificadores de los objetos son en realidad punteros internos de la memoria. Sin embargo, la asociación de los objetos con ubicaciones físicas de almacenamiento puede variar con el tiempo. Hay varios grados de permanencia de las identidades:

Dentro de los procedimientos: La identidad solo persiste durante la ejecución de un único procedimiento. Un ejemplo de la identidad dentro de los procedimientos son las variables locales del interior de los procedimientos.

Dentro de los programas: La identidad solo persiste durante la ejecución de un único programa o una única consulta. Un ejemplo de la identidad dentro de los programas son las variables globales de los lenguajes de programación. Los punteros de la memoria principal o de la memoria virtual solo ofrecen identidad dentro de los programas.

Entre programas: La identidad persiste de una ejecución del programa a otra. Los punteros a los datos del sistema de archivos del disco ofrecen identidad entre los programas, pero pueden cambiar si se modifica la manera en que los datos se guardan en el sistema de archivos.

Persistente: La identidad no solo persiste entre las ejecuciones del programa sino también entre las reorganizaciones estructurales de los datos. Es la forma persistente de la identidad necesaria para los sistemas orientados a objetos.

Implementación de las características O-R

La orientación a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que se han organizado tomando como base conceptos del mundo real. Los modelos orientados a objetos son útiles para comprender problemas, comunicarse con expertos en esa aplicación, modelar empresas, preparar documentación y diseñar programas y bases de datos.

El beneficio principal no es un tiempo de desarrollo más reducido, el desarrollo orientado a objetos puede requerir más tiempo que el desarrollo convencional porque se pretende que promueva la reutilización futura y la reducción de los posteriores errores y el futuro mantenimiento. Las bases de datos orientadas a objetos unen dos tecnologías:

La de las bases de datos y la de los lenguajes orientados a objetos. Los LPOO aportan gran capacidad en la manipulación de datos, pero no implementan el almacenamiento y consulta de grandes volúmenes de datos.

Por el contrario, las bases de datos convencionales aportan un dominio de las técnicas de almacenamiento y consulta de grandes volúmenes de datos, aunque su capacidad de manipulación es limitada. Las bases de datos orientadas a objetos pretenden unir la capacidad de manipulación de datos de los LPOO con la capacidad de almacenamiento y consulta de los SGBD.