UNIDA 7 BASE DE DATOS ORIENTADO A OBJETOS.

7.1 VISIN GENERAL

Las aplicaciones tradicionales de las bases de datos consisten en tareas de procesamiento de
datos, como la gestin bancaria o de nminas, con tipos de datos relativamente sencillos que se
adaptan bien al modelo relacional.
El enfoque orientado a objetos para la programacin fue introducida por primera vez con el
lenguaje simula 67, que se diseo para la programacin de simulaciones. Smalltalk fue uno de los
primeros lenguajes de programacin orientada a objetos para aplicaciones generales. Actualmente,
los lenguajes c++ y java solo los lenguajes de programacin orientada a objetos ms usados.

7.2 TIPOS DE DATOS COMPLEJOS

Todos los valores de tipos de datos pueden agruparse en dos categoras principales: simples o
complejos.

Un valor simple o tipo de dato simple es un valor que ActionScript almacena en el nivel
ms bajo de abstraccin, lo que significa que las operaciones con tipos de datos simples
son generalmente ms rpidas y eficientes que las operaciones realizadas con tipos de
datos complejos.
Un valor complejo o tipo de datos complejo es un valor que no es simple y que hace
referencia a los valores simples. Estos se denominan con frecuencia tipos de datos de
referencia. Los valores complejos pertenecen al tipo de datos Object (objeto) o a un tipo de
datos basado en el tipo de datos Object.

Las variables que contienen datos de tipo simple se comportan en ciertas situaciones de modo
diferente a las que contienen tipos complejos.
7.3 TIPOS ESTRUTURADOS 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 direccin:
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 especificacin not final de direccin

indica que se pueden crear subtipos de direccin. Ahora se pueden usar estos tipos para crear
atributos compuestos en las relaciones, con slo 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 ms 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 notacin punto;
por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El
acceso al atributo nombre devolvera 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
Herencia.
La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se
considerar la herencia de los tipos y despus en el nivel de las tablas:
Herencia de tipos: Los tipos derivados heredan los atributos de superclase; los mtodos tambin
se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el
efecto de un mtodo declarndolo de nuevo, y esto ser lo que se conoce como sobre escritura
(overriding) del mtodo.
Supngase que se tiene la siguiente definicin de tipo para las personas:
create type Persona
(Nombre varchar(20),
direccion varchar(20))
Puede que se desee almacenar en la base de datos informacin adicional sobre las personas que
son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores tambin
son personas, se puede usar la herencia para definir en SQL los tipos estudiante y profesor:
create type Estudiante
under Persona
(Grado varchar(20),
Departamento varchar(20))
create type Profesor
under Persona
(Sueldo Integer,
Departamento varchar(20)
7.4 HERENCIA DE TABLAS

Las subtablas en SQL se corresponden con la nocin del modelo E-R de la especializacin y la
generalizacin. Por ejemplo, supngase que se define la tabla personas de la manera siguiente:
Crate table persona of Persona
Se pueden definir entonces las tablas estudiantes y profesores como subtablas de persona:
Crate table estudiantes of Estudiante
Under persona
Crate table profesores of Profesor
Under persona
Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre. Por tanto, cada atributo
presente en persona debe estar tambin presente en las subtablas. Si una consulta usa la tabla
persona, encontrar no slo las tuplas insertadas directamente en la tabla, sino tambin las tuplas
insertadas en sus subtablas estudiantes y profesores. Sin embargo, slo se puede acceder a los
atributos que estn presentes en persona.
7.5 TIPOS DE ARREGLO MULTICONJUNTO EN SQL.
SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se aadieron 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.
Supngase que se desea registrar informacin sobre libros, incluido un conjunto de palabras clave
para cada libro. Supngase tambin 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 estn ordenados, de modo que se puede distinguir el primer autor del
segundo autor, etc.
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 restriccin 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
aadiendo una clusula ref is a la instruccin 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 instruccin system
generated especifica que la base de datos genera de manera automtica 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 = Martn)
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
definicin de tipos de la tabla a la que se hace referencia, y la definicin de la tabla debe
especificar que la referencia est generada por el usuario (user generated):
create type Persona
(Nombre varchar(20),
Direccin 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, Martn, Av del Segura, 23)
7.7 IMPLEMENTACIN DE LAS CARACTERSTICAS OR.

Los sistemas de bases de datos relacionales orientadas a objetos son bsicamente 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 aplicacin como ODBC y JDBC se han extendido para recuperar y
almacenar tipos estructurados; por ejemplo, JDBC ofrece el mtodo getObject() que devuelve un
objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado.
Tambin es posible asociar clases de Java con tipos estructurados de SQL, y JDCB puede realizar
conversiones entre los tipos.
Lenguajes de programacin persistentes
Los lenguajes de las bases de datos se diferencan de los lenguajes de programacin tradicionales
en que trabajan directamente con datos que son persistentes; es decir, los datos siguen existiendo
una vez que el programa que los cre haya concluido. Las relaciones de las bases de datos y las
tuplas de las relaciones son ejemplos de datos persistentes.
El acceso a las bases de datos es slo un componente de las aplicaciones del mundo real.
Mientras que los lenguajes para el tratamiento de datos como SQL son bastante efectivos en el
acceso a los datos, se necesita un lenguaje de programacin para implementar otros componentes
de las aplicaciones como las interfaces de usuario o la comunicacin con otras computadoras. La
manera tradicional de realizar las interfaces de las bases de datos con los lenguajes de
programacin es incorporar SQL dentro del lenguaje de programacin.
Los lenguajes de programacin persistentes son lenguajes de programacin extendidos con
estructuras para el tratamiento de los datos persistentes. Los lenguajes de programacin
persistentes pueden distinguirse de los lenguajes con SQL incorporado, al menos, de dos maneras:
1.- En los lenguajes incorporados el sistema de tipos del lenguaje anfitrin suele ser diferente del
sistema de tipos del lenguaje para el tratamiento de los datos. Los programadores son
responsables de las conversiones de tipo entre el lenguaje anfitrin y SQL. Hacer que los

programadores lleven a cabo esta tarea presenta varios inconvenientes:

El cdigo para la conversin entre objetos y tuplas opera fuera del sistema de tipos
orientado a objetos y, por lo tanto, tiene ms posibilidades de presentar errores no detectados.
La conversin en la base de datos entre el formato orientado a objetos y el formato
relacional de las tuplas necesita gran cantidad de cdigo. El cdigo para la conversin de formatos,
junto con el cdigo para cargar y descargar datos de la base de datos, puede suponer un
porcentaje significativo del cdigo total necesario para la aplicacin.
Por el contrario, en los lenguajes de programacin persistentes, el lenguaje de consultas se halla
totalmente integrado con el lenguaje anfitrin y ambos comparten el mismo sistema de tipos. Los
objetos se pueden crear y guardar en la base de datos sin ninguna modificacin explcita del tipo o
del formato; los cambios de formato necesarios se realizan de manera transparente.

2.- Los programadores que usan lenguajes de consultas incorporados son responsables de la
escritura de cdigo explcito para la bsqueda en la memoria de los datos de la base de datos. Si
se realizan actualizaciones, los programadores deben escribir explcitamente cdigo para volver a
guardar los datos actualizados en la base de datos.
Por el contrario, en los lenguajes de programacin persistentes, los programadores pueden trabajar
con datos persistentes sin tener que escribir explcitamente cdigo para buscarlos en la memoria o
volver a guardarlos en el disco.
Sin embargo, los lenguajes de programacin persistentes presentan ciertos inconvenientes que
hay que tener presentes al decidir su conviene usarlos. Dado que los lenguajes de programacin
suelen ser potentes, resulta relativamente sencillo cometer errores de programacin que daen las
bases de datos. La complejidad de los lenguajes hace que la optimizacin automtica de alto nivel,
como la reduccin de E/S de disco, resulte ms difcil. En muchas aplicaciones el soporte de las
consultas declarativas resulta de gran importancia, pero los lenguajes de programacin
persistentes no soportan bien actualmente las consultas declarativas (SQL es un ejemplo).