UNIDAD 7 - Bases de Datos Orientadas a objetos

7.1 Visión general

Los modelos de bases de datos tradicionales presentan deficiencias en cuento a aplicaciones más complejas o sofisticadas. Además son difíciles de utilizar cuando las aplicaciones que acceden a ellas están escritas en un lenguaje de programación orientado a objetos.

 La orientación a objetos ofrece flexibilidad, no está limitada por los tipos de datos y los lenguajes de consulta  de los sistemas de bases de datos tradicionales. La característica clave 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.

 Las BDOO se han diseñado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos. También están diseñadas para simplificar la POO. Almacenan los objetos en la BD con las mismas estructuras y relaciones que los lenguajes de POO. 

 Una SGBDOO es una SGBD que almacena objetos incorporando así todas las ventajas de la OO. Pueden  tratar directamente con objetos, no teniendo que hacer la traducción a tablas o registros. Sus objetos se conservan, pueden ser gestionados aunque su tamaño sea grande, pueden ser compartidos entre múltiples usuarios  y mantienen su integridad como sus relaciones.

 ODMG (Object Database Mangement Group) es el grupo de fabricantes de SGBDOO que propuso el estándar ODM-93 en 1993; en 1997 evolucionó a ODMG-2.0 y en enero de 2000 se publicó la última versión ODMG 3.0. El uso del estándar proporciona portabilidad (que se pueda ejecutar sobre sistemas distintos), interoperabilidad (que la aplicación pueda acceder a varios sistemas diferentes) y además permite que los usuarios puedan comparar entre distintos sistemas comerciales.

7.2 Tipos de datos complejos

Los elementos de datos básicos son registros bastante pequeños cuyos campos son atómicos. En los últimos años, ha crecido la demanda de formas de abordar tipos de datos más complejos. Considérense por ejemplo, las direcciones. Mientras que una dirección completa se puede considerar como un elemento de datos atómico del tipo cadena de caracteres, esa forma de verlo esconde detalles como la calle, la población y el código postal que pueden ser interesantes para las consultas. Por otra parte, si una dirección se representa dividiéndola en sus componentes, la escritura de las consultas sería más complicada.

Como ejemplo adicional, 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.

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

Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el atributo compuesto nombre con los atributos componentes nombre_pila y apellidos:

create type Nombre as

(nombre_pila varchar(20),

apellidos varchar(20))

final

De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto dirección:

create type Direccion as

(calle varchar(20),

ciudad varchar(20),

codigo_postal varchar(9))

not final

En SQL estos tipos se denominan tipos definidos por el usuario. Las especificaciones final indica que no se puede crear subtipos de nombre, mientras que la especificación not final de dirección indica que se pueden crear subtipos de dirección. Ahora se pueden usar estos tipos para crear atributos compuestos en las relaciones, con sólo declarar que un atributo es de uno de estos tipos. Por ejemplo, se puede crear una tabla cliente de la siguiente manera.

create table cliente (

nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

O bien, realizando una estructura más del tipo Cliente y generar la tabla a partir de ella:

create type TipoCliente as

(nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

not final

create table cliente of TipoCliente

Se puede tener acceso a los componentes de los atributos compuestos usando la notación “punto”; por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El acceso al atributo nombre devolvería un valor del tipo estructurado Nombre.

La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre.apellido, direccion.ciudad

from cliente

En SQL:1999 se usan funciones constructoras para crear valores de los tipos estructurados. Las funciones con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado. Por ejemplo, se puede declarar una función constructora para el tipo Nombre de esta manera:

create function Nombre(nombre_pila varchar(20), apellidos varchar(20))

returns Nombre

begin

set self.nombre_pila = nombre_pila;

set self.apellidos = apellidos;

end

De manera predeterminada, cada tipo estructurado tiene una función sin argumentos que configura los atributos con sus valores predeterminados. Cualquier otra función constructora hay que crearla de manera específica.

La instrucción siguiente ilustra la manera de crear una nueva tupla de la relación Cliente. Se da por supuesto que se ha definido una función constructora para Direccion, igual que la función constructora que se definió para Nombre.

insert into Cliente

values

(new Nombre(‘Martín’, ‘Gómez’),

new Direccion(‘Calle Mayor 20’, ‘Madrid’, ‘28045’),

date ‘22-8-1960’)

7.4 Herencia de tablas

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

create table personas of Persona

A continuación 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 subtablas 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 y profesores pasan a estar también presentes de manera implícita en personas. Por tanto, si una consulta usa la tabla personas, no sólo encuentra tuplas directamente insertadas en esa tabla, sino también tuplas insertadas en sus subtablas, es decir, estudiantes y profesores. No obstante, esa consulta sólo puede tener acceso a los atributos que están presentes en personas.

SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas “only personas” en lugar de personas. 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 supertabla, 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

borrará todas las tuplas de la tabla personas, así como de sus subtablas estudiantes y profesores, que satisfagan P. Si se añade la palabra clave only a la instrucción anterior, las tuplas que se insertaron en las subtablas no se ven afectadas, aunque satisfagan las condiciones de la cláusula where.

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se añadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces.

Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro. Supóngase también que se deseara almacenar 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 autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),

sucursal varchar(20))

create 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 libros of Libro

7.5 Tipos de arreglo multiconjunto en SQL

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se añadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces.

Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro. Supóngase también que se deseara almacenar 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 autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),

sucursal varchar(20))

create 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 libros of Libro

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 autorreferenciable (self-referential attribute), se declara añadiendo una cláusula ref is a la instrucción 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 autoreferencial 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),

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

PASTOR GODINEZ OMAR

JUAREZ SANTIAGO HECTOR