Capítulo 9: Bases de datos basadas en

objetos

Fundamentos de Bases de datos, 5ª Edición.

©Silberschatz, Korth y Sudarshan
Consulte www.db-book.com sobre condiciones de uso
 Chapter 9: Object-Based Databases
 Tipos de datos complejos y orientación a objetos
 Tipos estructurados y herencia en SQL
 Herencia de tablas
 Tipos array y multiconjunto en SQL
 Identidad de los objetos y tipos de referencia en SQL
 Implementación de las características O-R
 Lenguajes de programación persistentes
 Comparación entre bases de datos orientadas a objetos y bases de
datos relacionale orientadas a objetos

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.2 ©Silberschatz, Korth y Sudarshan

 Modelos de datos relacionales orientadas a
objetos
 Extienden el modelo de datos relacional incluyendo las
construcciones y la orientación de objetos para tratar con los tipos de
datos añadidos.
 Permiten a los atributos de las tuplas tener tipos complejos,
incluyendo valores no atómicos tales como las relaciones anidadas.
 Preservan las fundaciones relacionales, en particular el acceso
declarativo a los datos, mientras se extiende para modelar la
potencia.
 Compatibilidad ascendente con los lenguajes relacionales existentes.

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.3 ©Silberschatz, Korth y Sudarshan

 Tipos de datos complejos

 Motivación:
 Permite dominios no atómicos (atómico  indivisible)
 Ejemplo de dominio no atómico: conjunto de enteros, o
conjunto de tuplas
 Permite la modelación intuitiva de las aplicaciones con
datos complejos
 Definición intuitiva:
 Permite relaciones en cualquier momento que se
permitan los valores atómicos (escalares) — relaciones
dentro de relaciones
 Retiene la fundación matemática del modelo relacional
 Viola la primera forma normal.

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.4 ©Silberschatz, Korth y Sudarshan

 Ejemplo de una relación anidada
 Ejemplo: sistema de información de bibliotecas
 Cada libro tiene
 título,
 lista de autores,
 editorial y
 lista de palabras clave
 Relación libros sin 1FN

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.5 ©Silberschatz, Korth y Sudarshan

 Descomposición de 4FN de relaciones
anidadas
 Se anula la dificultad de los libros-planos asumiendo que las siguientes
dependencias multivaloradas incluyen:
 título autor
 título palabra clave
 título nombre_editorial, sucursal_editorial
 Se descompone doc-plano dentro de 4FN utilizando los esquemas:
 (título, autor)
 (título, palabra clave)
 (título, nombre_editorial, sucursal_editorial)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.6 ©Silberschatz, Korth y Sudarshan

 Descomposición 4FN de libros_planos

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.7 ©Silberschatz, Korth y Sudarshan

 Problemas con el esquema 4FN
 El diseño 4FN necesita que los usuarios incluyan reuniones en sus
consultas.
 La vista relacional 1NF libros-planos definida por la reunión de
relaciones 4FN:
 elimina la necesidad de que los usuarios realicen reuniones,
 pero se pierde la correspondencia una a una entre tuplas y
documentos.
 y tiene una gran cantidad de redundancia
 La representación de las relaciones anidadas es mucho más natural
aquí.

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.8 ©Silberschatz, Korth y Sudarshan

 Tipos complejos y SQL:1999
 Las extensiones de SQL para tipos complejos incluyen:
 Tipos colección y tipos de objetos de gran tamaño
 Las relaciones anidadas son un ejemplo de tipos de
colección
 Tipos estructurados
Estructuras de registro anidado como atributos compuestos

 Herencia
 Orientación a objetos
Se incluyen los identificadores y las referencias de objetos

 Nuestra descripción se basa principalmente en el estándar
SQL:1999
 Actualmente no está completamente implementado en ningún
sistema de bases de datos
 Pero están presentes algunas características en cada uno de
los mayores sistemas de las bases de datos comerciales
 Lea el manual de su sistema de base de datos para ver que
soporta

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.9 ©Silberschatz, Korth y Sudarshan

 Tipos estructurados y herencia en SQL
 Los tipos estructurados se pueden declarar y usar en SQL
create type Nombre as
(nombredepila varchar(20),
apellidos varchar(20))
create type Dirección as
(calle varchar(20),
ciudad varchar(20),
códigopostal varchar(20))
not final
 Nota: final y not final indican si se pueden crear subtipos
 Los tipos estructurados se pueden utilizar para crear tablas con
atributos compuestos
create table cliente (
nombre Nombre,
dirección Dirección,
fechaDeNacimiento date)
 Se utiliza la notación punto para referenciar componentes:
nombre.nombredepila

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.10 ©Silberschatz, Korth y Sudarshan

 Tipos estructurados (cont.)
 Tipos fila definidos por el usuario
create type TipoCliente as (
nombre Nombre,
dirección Dirección,
fechaDeNacimiento date)
not final
 Se puede crear una tablas cuyas filas sean tipos definidos por el
usuario
create table cliente of TipoCliente

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.11 ©Silberschatz, Korth y Sudarshan

 Métodos
 Se puede añadir una declaración de método con un tipo estructurado.
method edadAFecha (aFecha date)
returns interval year
 El cuerpo del método se escribe por separado.
create instance method edadAFecha (aFecha date)
returns interval year
for TipoCliente
begin
return aFecha - self.fechaDeNacimiento;
end
 Ya se puede obtener la edad de los clientes:
select nombre.apellidos, edadAFecha (current_date)
from cliente

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.12 ©Silberschatz, Korth y Sudarshan

 Herencia
 Supónga que se dispone de la siguiente definición de tipos para las personas:
create type Persona
(nombre varchar(20),
dirección varchar(20))
 Se utiliza la herencia para definir los tipos estudiante y profesor
create type Estudiante
under Persona
(curso varchar(20),
departamento varchar(20))
create type Profesor
under Persona
(sueldo integer,
departamento varchar(20))
 Los subtipos pueden redefinir métodos utilizando overriding method en lugar
de method en la declaración del método

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.13 ©Silberschatz, Korth y Sudarshan

 Herencia múltiple
 SQL:1999 y SQL:2003 no admiten herencia múltiple
 Si nuestro sistema de tipos permite la herencia múltiple, se puede definir
un tipo para los ayudantes de la manera siguiente:
create type Ayudante
under Estudiante, Profesor
 Para evitar un conflicto entre los dos ejemplares de departamento se les
puede cambiar el nombre
create type Ayudante
under
Estudiante with (departamento as departamento_estudiante),
Profesor with (departamento as departamento_profesor

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.14 ©Silberschatz, Korth y Sudarshan

 Requisitos de consistencia para las subtablas

 Requisitos de consistencia en las subtablas y las supertablas.

 Cada tupla de la supertabla (por ejemplo persona) puede
corresponder a lo sumo a una tupla de cada una de las subtablas
(por ejemplo estudiantes y profesores)
 Restricción adicional en SQL:1999:
Todas las tuplas que se corresponden con cada una de las otras
(es decir, con los mismos valores de atributos heredados) deben
proceder de una tupla (insertada dentro de una tabla).
 Es decir, cada entidad debe tener un tipo más específico
 No se puede tener una tupla de persona que corresponda a
una tupla de cada tupla de estudiantes y profesores

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.15 ©Silberschatz, Korth y Sudarshan

 Tipos array y multiconjunto en SQL
 Ejemplo de declaración de array y multiconjunto:
create type Editorial as
(nombre varchar(20),
sucursal varchar(20))
create type Libro as
(título varchar(20),
array_autores varchar(20) array [10],
fecha_publicación date,
editor Editor,
conjunto_palabras_clave varchar(20) multiset)
create table libros of Libro
 Similar a la relación anidada libros, pero con array de autores
en vez de conjunto

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.16 ©Silberschatz, Korth y Sudarshan

 Creación de valores colección
 Construcción de array
array [‘Silberschatz’,`Korth’,`Sudarshan’]
 Multiconjunto
 multisetset [‘computadora’, ‘base de datos’, ‘SQL’]
 Para crear una tupla del tipo definido por la relación libros:
(‘Compiladores’, array[`Gómez’,`Santos’],
Editor (`McGraw-Hill’,`New York’),
multiset [`análisis sintáctico’,`análisis’ ])
 Para insertar la tupla anterior en la relación libros
insert into libros
values
(‘Compiladores’, array[`Gómez’,`Santos’],
Editor (`McGraw-Hill’,`New York’),
multiset [`análisis sintáctico’,`análisis’ ])

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.17 ©Silberschatz, Korth y Sudarshan

 Querying Collection-Valued Attributes
 Para obtener todos los libros que tengan la palabra “base de datos” entre
sus palabras claves,
select título
from libros
where ‘base de datos’ in (unnest(conjunto_palabras_clave))
 Se puede acceder a los elementos de un array mediante índices
 Ej.: Si se sabe que un cierto libro tiene tres autores, se puede escribir:
select array_autores[1], array_autores[2], array_autores[3]
from libros
where título = `Fundamentos de bases de datos’
 Para obtener una relación con pares de la forma “título, nombr_autor” para
todos los libros y para cada uno de sus autores
select L.título, A.autores
from libros as L, unnest (L.array_autores) as A (autores)
 Para mantener información de orden se añade una cláusula with ordinality
select L.título, A.autores, A.posición
from libros as L, unnest (L.array_autores) with ordinality as
A (autores, posición)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.18 ©Silberschatz, Korth y Sudarshan

 Desanidamiento
 La transformación de una relación anidada en una forma con menos (o sin)
atributos de tipo relación se denomina desanidamiento.
 Por ejemplo
select título, A as autor, editor.nombre as nombre_editor,
editor.sucursal as sucursal.editor, P.palabras_clave
from libros as L, unnest(L.array_autores) as A (autores),
unnest (L.conjunto_palabras_clave) as P (palabras_clave)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.19 ©Silberschatz, Korth y Sudarshan

 Anidamiento
 Anidamiento es lo contrario de desanidamiento, se crea un atributo de
tipo colección
 NOTA: SQL:1999 no admite el anidamiento
 El anidamiento puede realizarse de manera similar a la agregación, pero
utilizando la función collect() en lugar de una operación de agregación,
para crear un multiconjunto
 Para anidar la relación libros_plana en el atributo palabras_clave:
select título, autores, Editor(nombre_editor, sucursal_editor) as editor,
collect(palabras_clave) as conjunto_palabras_clave
from libros-plana
groupby título, autor, editor
 Para anidar los autores y las palabras clave:
select título, collect(autores) as conjunto_autores,
Editor(nombre_editor, sucursal.editor) as editor,
set(palabra_clave) as conjunto_palabras_clave
from libros-plana
groupby título, editor

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.20 ©Silberschatz, Korth y Sudarshan

 Versión en 1FN de relación anidada
Versión en 1FN de libros

libros_plana

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.21 ©Silberschatz, Korth y Sudarshan

 Anidamiento (cont.)
 Otro enfoque para la creación de relaciones anidadas es usar
subconsultas en la cláusula select.
select título,
array ( select autores
from autores as A
where A.título=B.título
order by A.posición) as array_autores,
Editor(nombre_editor, sucursal_editor) as editor,
multiset (select palabra_clave
from palabras_clave as P
where P.título = L.título) as conjuto_palabras_clave
from libros4 as L

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.22 ©Silberschatz, Korth y Sudarshan

 Object-Identity and Reference Types
 Definir un tipo Departamento con un campo nombre y un campo
director que es una referencia al tipo Persona, con la tabla personas
como scope
create type Departamento(
nombre varchar(20),
director ref(Persona) scope personas)
 Se puede crear entonces una tabla departamentos de la forma
siguiente
create table departamentos of Departamento
 Se puede omitir la declaración scope persona de la declaración de
tipos y en su lugar añadirla a la instrucción create table:
create table departamentos of Departamento
(director with options scope personas)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.23 ©Silberschatz, Korth y Sudarshan

 Inicializar los valores de tipo referencia
 Para crear una tupla con un valor de referencia, se puede crear en
primer lugar la tupla con una referencia nula y después establecer la
referencia de forma separada
insert into departamentos
values (`CS’, null)
update departamentos
set director = (select ref(p.id_personal)
from persona as p
where nombre=`Martín’)
where nombre = `CS’

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.24 ©Silberschatz, Korth y Sudarshan

 Identificadores generados por el usuario
 El tipo de identificador de objetos se debe especificar como parte de la
definición del tipo de la tabla referenciable, y
 La definición de la tabla debe especificar que la referencia la genera el
usuario
create type Persona
(nombre varchar(20)
dirección varchar(20))
ref using varchar(20)
create table personas of Persona
ref is id_personal user generated
 Cuando se crea una tupla, se debe proporcionar un valor único para el
identificador:
insert into personas values
(‘01284567’, ‘Martín’, `Avenida del Segura, 23’)
 Se puede usar el valor del identificador cuando se inserta una tupla en
departmentos
 Se evita una consulta separada para obtener el identificador:
insert into departmentos
values(`CS’, `01284567’)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.25 ©Silberschatz, Korth y Sudarshan

 Identificadores generados por el usuario (cont.)

 Se puede utilizar un valor de clave primaria como identificador:

create type Persona
(nombre varchar (20) primary key,
dirección varchar(20))
ref from (nombre)
create table personas of Person
ref is id_personal derived
 Cuando se inserta una tupla en departmentos, se puede utilizar
insert into departmentos
values(`CS’,`Martín’)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.26 ©Silberschatz, Korth y Sudarshan

 Expresiones de camino
 Averiguar los nombres y direcciones de los directores de todos los
departamentos:
select director –>nombre, director –>dirección
from departamentos
 Una expresión como "director->nombre" se denomina una expresión
de camino
 Las expresiones de camino ayudan a evitar reuniones explícitas
 Si director de departamento no era una referencia, debería ser
necesario obtener en la dirección la reunión de departamentos
con persona
 Hace que se exprese la consulta de manera mucho más fácil para
el usuario

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.27 ©Silberschatz, Korth y Sudarshan

 Implementación de las características O-R

 Similar a como se se convierten las características E-R en esquemas

de relación
 Implementación de subtablas
 Cada tabla guarda la clave primaria y los atributos definidos en la
tabla
o,
 Cada tabla guarda tanto los atributos definidos localmente como
los atributos heredados

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.28 ©Silberschatz, Korth y Sudarshan

 Lenguajes de programación persistentes

 Los lenguajes se extienden con construcciones para manejar datos

persistentes
 El programador puede manejar directamente los datos persistentes
 no se necesita recuperarlos a la memoria ni volverlos a guardar al
disco (al contrario que en SQL incorporado)
 Objetos persistentes:
 Por clase – declaración explicita de persistencia
 Por creación – sintaxis especial para crear objetos persistentes
 Por marcas – los objetos se hacen persistentes tras su creación
 Por alcance – los objetos son persistentes si se declaran de esta
forma explícitamente o se pueden alcanzar a través de un objeto
persistente

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.29 ©Silberschatz, Korth y Sudarshan

 Identidad de los objetos y los punteros
 Grados de permanencia de las identidades de objetos:
 Dentro de los procedimientos – la identidad sólo persiste durante la
ejecución de un único procedimiento
 Dentro de los programas – la identidad sólo persiste durante la ejecución
de un único programa o una única consulta.
 Entre programas – la identidad persiste de una ejecución del programa a
otra, pero puede cambiar si se modifica la manera en que se guardan los
datos en el sistema de archivos
 Persistente – la identidad no sólo persiste entre las ejecuciones del
programa sino también entre las reorganizaciones estructurales de los
datos; necesaria para los sistemas orientados a objetos.
 Existen implementaciones de versiones en C++ y Java
 C++
 ODMG C++
 ObjectStore
 Java
 Java Database Objects (JDO)

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.30 ©Silberschatz, Korth y Sudarshan

 Comparación de bases de datos O-O y O-R

 Sistemas relacionales

Tipos de datos sencillos, lenguajes de consulta potentes,
protección elevada
 Bases de datos orientadas a objetos basadas en lenguajes de
programación persistente
 Tipos de datos complejos, integración con los lenguajes de
programación, elevado rendimiento
 Sistemas relacionales orientados a objetos
 Tipos de datos complejos, lenguajes de consulta potentes,
protección elevada
 Nota: Muchos sistemas reales no tienen en cuenta estos límites
 Ej. Los lenguajes de programación persistentes construidos sobre
una base de datos relacional ofrece las dos primeras ventajas, pero
puede presentar un rendimiento pobre.

Fundamentos de Bases de Datos – 5ª Edición, 2005 9.31 ©Silberschatz, Korth y Sudarshan

 Fin del capítulo

Fundamentos de Bases de datos, 5ª Edición.

©Silberschatz, Korth y Sudarshan
Consulte www.db-book.com sobre condiciones de uso