UNIDAD 7

Unidad        #7

BASE DE DATOS ORIENTADA A OBJETOS

7.1    VISIÓN GENERAL

El modelo de datos relacional orientado a objetos extiende el modelo de datos relacional ofreciendo un sistema de tipos más rico que incluye tipos de datos complejos y orientación a objetos. Hay que extender de manera acorde los lenguajes de consulta relacionales,  en especial SQL, para que puedan trabajar con este sistema de tipos más rico. Los sistemas de Bases de Datos Relacionales basadas en objetos, es decir, los sistemas de Bases de Datos basados en el modelo Objeto-Relación, ofreces un medio de migración cómodo para los usuarios de las Bases de Datos Relacionales que deseen usar características Orientadas a Objetos.

 Un obstáculo es la dificultad de acceso a los datos de la Base de Datos desde los programas escritos en lenguajes de programación como C++ o JAVA. La mera extensión de sistema de tipos soportado por las bases de datos no resulta suficiente para resolver completamente este problema. Tener que expresar el acceso a la Base de Datos mediante un lenguaje (SQL) que es diferente del lenguaje de programación también hace más difícil el trabajo del programador.

El termino sistemas de Base de Datos Orientadas a Objetos se usa para hacer referencia a los sistemas de Bases de Datos que soportan sistemas de tipos Orientados a objetos y permiten el acceso directo a los datos desde los lenguajes de programación orientados a objetos usando el sistema de tipos nativo del lenguaje.

7.2    TIPOS DE DATOS COMPLEJOS

Las aplicaciones de Bases de Datos tradicionales consisten en tareas de procedimientos de datos, tales como la banca y la gestión de nominas. Dichas aplicaciones presentan conceptualmente tipos de datos simples. Los elementos de datos básicos son registros bastante pequeños y cuyos campos son atómicos, es decir, no contienen estructuras adicionales y en los que se cumple la Primera Forma Normal.  Como ejemplo, considérense los atributos multivalorados del Modelo E-R. Esos atributos resultan naturales, por ejemplo, para la representación de números de teléfono, ya que las personas pueden tener más de un teléfono. La alternativa de la normalización mediante la creación de una nueva relación resulta costosa y artificial para este ejemplo.

Con sistemas de tipos complejos se pueden representar directamente conceptos del Modelo E-R, como los atributos compuestos, los atributos multivalorados, la generalización y la especialización, sin necesidad de una compleja traducción al Modelo Relacional.

7.3    TIPOS ESTRUCTURADOS Y HERENCIA EN SQL

Antes de SQL: 1999 el sistema de tipos de SQL consistía en un conjunto bastante sencillo de tipos predefinidos. SQL: 1999 añadió un sistema de tipos extenso a SQL, lo que permite los tipos estructurados y la herencia de tipos.

Titulo	Array_autores	Editor	Conjunto_palabras_clave
		(nombre, sucursal)
Compiladores Redes	[Gómez, Santos] [Santos, Escudero]	(McGraw, Nueva York) (Oxford, Londres)	{Análisis sintáctico, análisis} {internet, web}

Relación de libros que no están en la 1FN, libros.

Titulo	Autor	Posición
Compiladores Compiladores Redes Redes	Gomes Santos Santos Escudero	1 2 1 2

Autores

Titulo	Palabra_Clave
Compiladores Compiladores Redes Redes	Análisis sintáctico Análisis Internet Web

Palabras_Clave

Titulo	Nombre_Editor	Sucursal_Editor
Compiladores Redes	McGraw-Hill Oxford	Nueva York Londres

Libros4

Versión en la 4FN de la relación libros

7.4 HERENCIA DE TABLAS.

Las tablas de SQL se corresponden con el concepto de especialización general de E-R. Por ejemplo, supóngase que se define la tabla personas de la manera siguiente:

create table personas of persona

A continuación no se puede definir las tablas estudiantes y profesores como subtablas de personas de la manera siguiente:

create table estudiantes of estudiante

under personas

create table profesores of profesor

under personas

Los tipos de las personas deben ser subtipos del tipo de la tabla madre. Por tanto, todos los atributos presentes en personas también están presentes en las subtablas.

Además, cuando se declaran estudiantes y profesores como subtablas de personas, todas las tuplas presentes en estudiantes o en profesores pasan a estar también presentes de manera implícita en personas. Por tanto, si una consulta usa la tabla personas, no solo encuentra tuplas directamente insertadas en esa tabla, si no también tuplas insertadas en sus subtablas, es decir, estudiante y profesores.

La palabra clave only también puede usarse en las sentencias delete y update. Sin la palabra clave only, la instrucción delete aplicada a una súper tabla, como personas, también borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes); por ejemplo, la instrucción:

delete from personas where P

borrara todas las tuplas de las tablas personas, así como de sus subtablas estudiantes y profesores, que satisfagan P.

Teóricamente, la herencia múltiple es posible con las tablas, igual que con los tipos. Por ejemplo, se puede crear una tabla del tipo Profesor Ayudante:

create table profesores_ayudantes

of Profesor ayudante

under estudiantes, profesores

Como secuencia de la declaración, todas las duplas presentes en la tabla profesores_Ayudantes también se hallan presentes de manera implícita en las tablas profesores y estudiantes y, a su vez, en la tabla personas. Hay que tener en cuenta, no obstante, que SQL no soporta la herencia múltiple de tablas.

Los requisitos de consistencia de la subtablas son:

1.- Cada tupla de la súper tabla puede corresponderse, como máximo, con una tupla de cada una de sus subtabla inmediatas.

2.- SQL posee una restricción adicional que hace que todas las tuplas que se corresponden entre sí deben proceder de una tupla (acertada en una tabla).

Por ejemplo, si la primera condición, se podrían tener 2 tuplas de estudiantes (o de profesores) que correspondieran a la misma persona.

Dado que SQL no soporta la herencia múltiple, las 2da condición impiden realmente que ninguna persona sea a la vez profesor y estudiante. Aunque se soportara la herencia múltiple, surgiría el mismo problema si estuviera ausente la subtabla profesores_Ayudante.

No obstante hay que tener en cuenta, que por degradación, SQL prohíbe las situaciones de este tipo debido a segundo requisito de consistencia. Ya que SQL tampoco soporta la herencia múltiple, no se puede usar la herencia para modelar una situación en la que alguien pueda ser a la vez estudiante y profesor.

7.5    TIPOS DE ARREGLOS Y MULTICONJUNTOS EN SQL

Creación y acceso a los valores de los conjuntos

 En SQL: 1999 se puede crear un array de valores de esta manera: 

Array [‘Silberschartz’, ‘Korth’, ‘Sudarshan’]

 De manera parecida, se puede crear un multiconjunto de palabras clave de la manera siguiente:

Multiset [‘Silberschartz’, ‘Korth’, ‘Sudarshan’]

 Por lo tanto, se puede crear una tupla definido por la relación libros como: 

insert intolibros

values

(‘Compiladores’, array [‘Gómez’, ‘Santos’’],

New Editor (‘McGraw-Hill’, ‘Nueva York’),

Multiset [‘análisis sintáctico’, ‘análisis’])

 Se puede tener acceso a los elementos del array o actualizarlos especificando el índice del array, por ejemplo, array_autores.

7.6   IDENTIDAD DE LOS OBJETOS Y TIPOS DE REFERENCIA EN SQL

 Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo 

Departamento, de la manera siguiente: 

Create  type Departamento (nombre varchar (20), director ref (Persona) scope  personas) 

create table departamentos of  Departamento

 En este caso, la referencia está restringida a las tuplas de la tabla personas. La restricción del ámbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas. 

La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autor-referenciable (self-referential attribute), se declara añadiendo una cláusula

ref is a la instruction create table : 

create table personas of  Persona

 ref is id_persona system generated

 En este caso, id_persona es el nombre del atributo, no una palabra clave, y la instrucción system generated especifica que la base de datos genera de manera automática el identificador. Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente: 

insert into departamentos values(‘CS’, null)

update departamentos set director = (select p.id_persona from persona as p where

nombre = ‘Martín’) where nombre = ‘CS’

 Una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores. El tipo del atributo auto-referencial debe especificarse como parte de la definición de tipos de la tabla a la que se hace referencia, y la definición de la tabla debe especificar que la referencia está

generada por el usuario(user generated): create type Persona (nombre varchar(20), dirección varchar(20)) ref using varchar(20) create table personas of Persona ref is id_persona user generated

 Al insertar tuplas en personas hay que proporcionar el valor del identificador: 

insert into personas(id_persona, nombre, dirección) values

(‘01284567’, ‘Martín’, ‘Av. del Segura, 23’)

 7.7  IMPLEMENTACIÓN DE LAS CARACTERÍSTICAS O-R

Los sistemas de bases de datos relacionales orientadas a objetos son básicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesarias en muchos niveles del sistema de base de datos. Las interfaces de programas de aplicación como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el método getObject () que devuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado. También es posible asociar clases de Java con tipos estructurados de SQL, y JDCB puede realizar conversiones entre los tipos.