You are on page 1of 45

Base de Datos

Orientada a Objetos

Prof. Eduardo Márquez Lozada

Visión general

Visión general
En una base de datos orientada a objetos
(BDOO), la información se representa mediante objetos
como los presentes en la programación orientada a
objetos. Cuando se integra las características de una
base de datos con las de un lenguaje de programación
orientado a objetos, el resultado es un sistema gestor de
base de datos orientada a objetos (ODBMS, object
database management system).
Un ODBMS hace que los objetos de la base de
datos aparezcan como objetos de un lenguaje de
programación en uno o más lenguajes de
programación a los que dé soporte.

Visión general
Las bases de datos orientadas a objetos se
diseñan para trabajar bien en conjunción con lenguajes
de programación orientados a objetos como Java, C#,
Visual Basic.NET y C++. Los ODBMS usan exactamente el
mismo modelo que estos lenguajes de programación.
Los ODBMS son una buena elección para
aquellos sistemas que necesitan un buen rendimiento en
la manipulación de tipos de dato complejos.
Los ODBMS proporcionan los costes de desarrollo
más bajos y el mejor rendimiento cuando se usan
objetos gracias a que almacenan objetos en disco y
tienen una integración transparente con el programa
escrito en un lenguaje de programación orientado a
objetos, al almacenar exactamente el modelo de
objeto usado a nivel aplicativo, lo que reduce los costes
de desarrollo y mantenimiento.

Tipos de datos complejos .

por ejemplo. los experimentos científicos. presentan algunas deficiencias cuando se trata de aplicaciones más complejas o sofisticadas como. . el diseño y fabricación en ingeniería (CAD/CAM. los sistemas de información geográfica o los sistemas multimedia. de las aplicaciones de gestión tradicionales.Tipos de datos complejos Los modelos de bases de datos tradicionales (relacional. CIM). en cuanto a bases de datos. Sin embargo. red y jerárquico) han sido capaces de satisfacer con éxito las necesidades.

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. • Hace falta definir operaciones no estándar. . se necesitan nuevos tipos de datos para almacenar imágenes y textos. • Las transacciones son de larga duración.Tipos de datos complejos 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.

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. .Tipos de datos complejos 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. como las operaciones que se pueden aplicar sobre dichos objetos.

que puede llegar fácilmente a los Gigabytes. E incluso aún más grandes. • Tipos estructurados: Los tipos estructurados permiten representación directa de los atributos compuestos en los diagramas entidad-relación.Tipos de datos complejos Tipos de datos complejos: • Colecciones: También conocidos como conjuntos. etc. etc. como mapas de alta resolución. como libros. este tipo de datos clasifican los arrays y los conjuntos en que los elementos pueden aparecer varias veces. canciones. video. . • Objetos de gran tamaño: Desde ya hace varios años que se necesita almacenar datos con atributos muy grandes (Varios Mbytes).

Tipos estructurados y herencia en SQL .

Por ejemplo. ciudad varchar(20).Tipos estructurados y herencia en SQL Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. 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). codigo_postal varchar(9)) not final . apellidos varchar(20)) final create type Direccion as (calle varchar(20).

el tipo estructurado siguiente puede usarse para representar el atributo compuesto dirección: create type Direccion as (calle varchar(20). codigo_postal varchar(9)) not final Las especificaciones final indica que no se puede crear subtipos de nombre. ciudad varchar(20). mientras que la especificación not final de dirección indica que se pueden crear subtipos de dirección .Tipos estructurados y herencia en SQL De manera parecida.

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.Tipos estructurados y herencia en SQL En SQL estos tipos se denominan tipos definidos por el usuario. direccion Direccion. direccion Direccion. fecha_nacimiento date) create type TipoCliente as (nombre Nombre. Por ejemplo. fecha_nacimiento date) not final create table cliente of TipoCliente . se puede crear una tabla cliente de la siguiente manera: create table cliente ( nombre Nombre.

realizando una estructura más del tipo Cliente y generar la tabla a partir de ella: create type TipoCliente as (nombre Nombre.Tipos estructurados y herencia en SQL O bien. fecha_nacimiento date) not final create table cliente of TipoCliente . direccion Direccion.

ciudad from cliente . nombre. El acceso al atributo nombre devolvería un valor del tipo estructurado Nombre.Tipos estructurados y herencia en SQL Se puede tener acceso a los componentes de los atributos compuestos usando la notación “punto”. direccion. por ejemplo.apellido. La consulta busca el apellido y la ciudad de cada cliente.nombre_pila devuelve el componente nombre de pila del atributo nombre. La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. select nombre.

En primer lugar se considerará 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. un subtipo puede redefinir el efecto de un método declarándolo de nuevo. .Herencia: La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. Sin embargo. los métodos también se heredan por sus subtipos. y esto será lo que se conoce como sobre escritura (overriding) del método. al igual que los atributos.

se puede usar la herencia para definir en SQL los tipos estudiante y profesor: . Dado que los estudiantes y los profesores también son personas.Supóngase que se tiene la siguiente definición de tipo para las personas: create type Persona (nombre varchar(20). direccion varchar(20)) Puede que se desee almacenar en la base de datos información adicional sobre las personas que son estudiantes y sobre las que son profesores.

departamento varchar(20)) .create type Persona (nombre varchar(20). departamento varchar(20)) create type Profesor under Persona (sueldo Integer. direccion varchar(20)) create type Estudiante under Persona (grado varchar(20).

Herencia de tablas .

Por lo que cada tabla almacena todos los atributos heredados y definidos localmente. y los atributos definidos localmente.Cada tabla almacena la clave primaria. no será necesario guardarlos. podrán obtenerse mediante una reunión con la super tabla basada en la clave primaria. que se puede heredar de una tabla padre. El acceso a todos los atributos de una tupla es más rápido. Cuando se inserta una tupla. se almacena sólo en la subtabla en la que se inserta y su presencia se infiere en cada supertabla. aparte de la clave primaria. dado que no se requiere una reunión: . Los atributos heredados.

de la manera siguiente: create table estudiantes of Estudiante under personas create table profesores of Profesor under personas Subtabla .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 Supertabla A continuación se puede definir las tablas estudiantes y profesores como subtablas de personas.

estudiantes y profesores. si una consulta usa la tabla personas. Por tanto. Además. todos los atributos presentes en personas también están presentes en las subtablas. No obstante. todas las tuplas presentes en estudiantes y profesores pasan a estar también presentes de manera implícita en personas. cuando se declaran estudiantes y profesores como subtablas de personas. esa consulta sólo puede tener acceso a los atributos que están presentes en personas. Por tanto.Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. es decir. . sino también tuplas insertadas en sus subtablas. no sólo encuentra tuplas directamente insertadas en esa tabla.

La palabra clave only también puede usarse en las sentencias delete y update. aunque satisfagan las condiciones de la cláusula where. la instrucción delete from personas where P borrará todas las tuplas de la tabla personas. también borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes). . por ejemplo. la instrucción delete aplicada a una supertabla. las tuplas que se insertaron en las subtablas no se ven afectadas. que satisfagan P. así como de sus subtablas estudiantes y profesores. Si se añade la palabra clave only a la instrucción anterior. como personas. Sin la palabra clave only.SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas “only personas” en lugar de personas.

Tipos de arreglo multiconjunto en SQL .

de modo que se puede distinguir el primer autor del segundo autor. los tipos array se añadieron en SQL:1999. etc. incluido un conjunto de palabras clave para cada libro. a diferencia de los elementos de los multiconjuntos. los elementos de los arrays están ordenados. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos. en el que cada elemento puede aparecer varias veces. mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado. . Supóngase también que se deseara almacenar almacenar el nombre de los autores de un libro en forma de array. Supóngase que se desea registrar información sobre libros.SQL soporta dos tipos de conjuntos: arrays y multiconjuntos.

create type Editor as (nombre varchar(20). conjunto_palabras_clave varchar(20) multiset) create table libros of Libro . editor Editor. sucursal varchar(20)) create type Libro as (titulo varchar(20). fecha_publicacion date. array_autores varchar(20) array[10].

Creación y acceso a los valores de los conjuntos En versiones anteriores de SQL se puede crear un array de valores de esta manera: array[‘Silberschartz’. ‘Korth’. ‘Sudarshan’] . ‘Sudarshan’] De manera parecida. se puede crear un multiconjunto de palabras clave de la manera siguiente: multiset[‘Silberschartz’. ‘Korth’.

. ‘Santos’’]. new Editor(‘McGraw-Hill’. se puede crear una tupla definido por la relación libros como: insert into libros values (‘Compiladores’. multiset[‘análisis sintáctico’. ’sintáctico’]) Se puede tener acceso a los elementos del array o actualizarlos especificando el índice del array. array_autores[1]. ‘análisis’.Por lo tanto. array[‘Gómez’. ‘Nueva York’). por ejemplo.

se puede usar la consulta siguiente: select titulo from libros where ‘base de datos’ in (unnest(conjunto_palabras_clave)) . Las expresiones que se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre de una relación.Consulta de los atributos valorados como conjuntos Ahora se considerará la forma de manejar los atributos que se valoran como conjuntos. Si se desea averiguar todos los libros que contengan las palabras “base de datos” entre sus palabras clave. como las cláusulas from.

Identidad de los objetos y tipos de referencia en SQL .

Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. que es una referencia al tipo Persona. director ref(Persona) scope personas) create table departamentos of Departamento . de la manera siguiente: create type Departamento( nombre varchar(20). y la tabla departamentos del tipo Departamento. en SQL se puede definir el tipo Departamento con el campo nombre y el campo director. Por ejemplo.Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos.

la referencia está restringida a las tuplas de la tabla personas. y hace que las referencias se comporten como las claves externas.En este caso. denominado atributo autorreferenciable (self-referential attribute). La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. La restricción del ámbito de referencia a las tuplas de una tabla es obligatoria en SQL. Ese atributo. 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. Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. y la instrucción system generated especifica que la base de datos genera de manera automática el identificador. id_persona es el nombre del atributo. Se puede conseguir el valor del identificador de la tupla mediante una consulta. no una palabra clave. .

primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente: insert into departamentos values (‘CS’. para crear una tupla con el valor de referencia.id_persona from persona as p where nombre = ‘Martín’) where nombre = ‘CS’ . null) update departamentos set director = (select p.Por tanto.

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 . El tipo del atributo autoreferencial debe especificarse como parte de la definición de tipos de la tabla a la que se hace referencia.Una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores.

‘Av del Segura. 23’) nombre. direccion) values (‘01284567’. ‘Martín’. .Al insertar tuplas en personas hay que proporcionar el valor del identificador: insert into personas (id_persona.

Implementación de las características OR. .

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.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. por ejemplo. Las interfaces de programas de aplicación como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados. JDBC ofrece el método getObject() que devuelve un objeto Java Struct.

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.Lenguajes de programación persistentes Los lenguajes de las bases de datos se diferencian de los lenguajes de programación tradicionales en que trabajan directamente con datos que son persistentes.

El acceso a las bases de datos es sólo un componente de las aplicaciones del mundo real. Los lenguajes de programación persistentes pueden distinguirse de los lenguajes con SQL incorporado. se necesita un lenguaje de programación para implementar otros componentes de las aplicaciones como las interfaces de usuario o la comunicación con otras computadoras. de dos maneras: . Los lenguajes de programación persistentes son lenguajes de programación extendidos con estructuras para el tratamiento de los datos persistentes. al menos. La manera tradicional de realizar las interfaces de las bases de datos con los lenguajes de programación es incorporar SQL dentro del lenguaje de programación. Mientras que los lenguajes para el tratamiento de datos como SQL son bastante efectivos en el acceso a los datos.

.En los lenguajes incorporados el sistema de tipos del lenguaje anfitrión 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 anfitrión y SQL. Hacer que los programadores lleven a cabo esta tarea presenta varios inconvenientes: • El código para la conversión entre objetos y tuplas opera fuera del sistema de tipos orientado a objetos y. tiene más posibilidades de presentar errores no detectados.1.. por lo tanto.

puede suponer un porcentaje significativo del código total necesario para la aplicación.• La conversión en la base de datos entre el formato orientado a objetos y el formato relacional de las tuplas necesita gran cantidad de código. El código para la conversión de formatos. en los lenguajes de programación persistentes. el lenguaje de consultas se halla totalmente integrado con el lenguaje anfitrión y ambos comparten el mismo sistema de tipos. . los cambios de formato necesarios se realizan de manera transparente. junto con el código para cargar y descargar datos de la base de datos. Por el contrario. Los objetos se pueden crear y guardar en la base de datos sin ninguna modificación explícita del tipo o del formato.

en los lenguajes de programación persistentes. los programadores pueden trabajar con datos persistentes sin tener que escribir explícitamente código para buscarlos en la memoria o volver a guardarlos en el disco.. . Si se realizan actualizaciones. Por el contrario.2.Los programadores que usan lenguajes de consultas incorporados son responsables de la escritura de código explícito para la búsqueda en la memoria de los datos de la base de datos. los programadores deben escribir explícitamente código para volver a guardar los datos actualizados en la base de datos.

En muchas aplicaciones el soporte de las consultas declarativas resulta de gran importancia. pero los lenguajes de programación persistentes no soportan bien actualmente las consultas declarativas (SQL es un ejemplo). .Sin embargo. Dado que los lenguajes de programación suelen ser potentes. como la reducción de E/S de disco. resulte más difícil. resulta relativamente sencillo cometer errores de programación que dañen las bases de datos. los lenguajes de programación persistentes presentan ciertos inconvenientes que hay que tener presentes al decidir su conviene usarlos. La complejidad de los lenguajes hace que la optimización automática de alto nivel.

BDDO Colecciones Arrays Multiconjuntos Herencia de tipos Tipos Estructurados Objetos de gran tamaño Herencia de tablas Atributos Referenciales Generado por el sistema Generado por el usuario .