BASE DE DATOS II – CONFERENCIA – 02

CONTENIDO
Sistemas de Bases de Datos Orientados a
Objeto.
™ Características, ventajas y desventajas.
™ Implementación del Modelo de Objeto.
™ Representación de relaciones.
Consultas.
Sistemas de Bases de Datos Relacionales
Extendidos.
™ Transformación del Modelo de Objetos al
Modelo Relacional.
OBJETIVOS
™ Conocer los conceptos básicos de los
DBMS’ OO

™ Transformar un Modelo OO de Datos a su

correspondiente Modelo Relacional Extendido
DESARROLLO

Hay mas exigencias en los nuevos sistemas a modelar, por lo

que se asemejan mas a la realidad, de ahí que se necesita una
técnica para abstraer el mundo real y almacenarla en datos, es
así como surge el Sistema de Bases de Datos Orientados a
Objetos.

¿ Por que un sistema Orientado a Objetos ? por

que todo lo que nos rodea en el mundo real lo podemos
representar como objetos.

El Sistema de Bases de Datos Orientados a Objetos, no

es mas que una técnica que me permite abstraer los objetos del
mundo real, representarlos en un diagrama, almacenar los
objetos con sus características particulares, programar el rol de
trabajo de los objetos, para simular la actividad de los datos lo
mas cercano a la realidad.
IMPLEMENTACION DE LOS MODELOS
ORIENTADOS A OBJETOS

Dentro del contexto de los modelos relacionales

de datos, existen aplicaciones que por la
complejidad en la relación de los datos que
manipulan no pueden ser tratados utilizando
un modelo relacional. Es aquí donde surge la
necesidad de enfocar la construcción de estas
aplicaciones utilizando el modelo de datos
orientados a objetos. La programación
orientada a objeto a propiciado el desarrollo
de los sistemas de gestión de datos
orientados a objetos y estos se consideran
como una extensión de los mismos.
En este tema discutiremos como los modelos orientados a
objetos tienen un soporte en los lenguajes de
programación orientada a objetos. También
conoceremos de las necesidades en la implementación
de los DBMS’ OO.

Los lenguajes que soportan POO son mas descriptivos con

respecto a los lenguajes de base de datos relacionales.
Sin embargo existe una carencia de soporte para la
persistencia de los objetos, esto esta relacionado con la
necesidad de los objetos de conservar su estado
independientemente de una interfaz de usuario en
particular. Esta necesidad a propiciado el desarrollo de
los gestores de datos OO como una extensión de los
lenguajes que soportan POO.
Analicemos alguna de las características que los gestores de objetos deben
proporcionar a los lenguajes de POO:

1. Capacidad para manejar objetos complejos.

2. Capacidad para incorporar métodos que operen sobre los datos de un objeto.
3. Capacidad para implementar objetos como miembros de una clase.
4. Capacidad para representar jerarquías de objetos y clases.
5. Capacidad para representar las relaciones entre objetos.

La capacidad para manejar objeto esta asociada con la representación

conceptual de un objeto, ósea las clases. Veremos a continuación
como se puede implementar esta capacidad a través de C++ como
lenguaje de POO.
Abstracción de clases.

La abstracción esta relacionada a la forma en que un observador

concibe la realidad desde el punto de vista de objetos. Este
mecanismo nos permitirá llevar un objeto desde el modelo real hasta
un modelo conceptual representado en clases.

Tratemos el siguiente ejemplo: En la relación de un cliente con su

banco podemos abstraer lo siguiente. Observe que hemos utilizado la
notación UML en el diagrama de la figura 1.

™ De un cliente se puede controlar: identificación, nombre,

dirección y teléfono. Podemos citar el siguiente comportamiento
dentro del banco: abrir una cuenta corriente, depositar en esta cuenta
o retirar dinero de esta cuenta.
™ De las cuenta podemos controlar: el cliente que tiene
esta cuenta, el numero de cuenta y el saldo de la cuenta.
También podemos decir que cuando se deposita o se retira
dinero de esta cuenta se debe actualizar su saldo.

Cliente
identificacion : int Cuenta
nombre : char*
direccion : char* +$posee NoCuenta : int
saldo : double
telefono : char*
1..*
actualizar()
depositar()
retirar()

Figura 1 – Diagrama de clases para clientes y cuentas.

™ ™ De un cliente se puede controlar: identificación, nombre, dirección y teléfono.
Podemos citar el siguiente comportamiento dentro del banco: abrir una cuenta
corriente, depositar en esta cuenta o retirar dinero de esta cuenta.
™ ™ De las cuenta podemos controlar: el cliente que tiene esta cuenta, el numero de
cuenta y el saldo de la cuenta. También podemos decir que cuando se deposita o se
retira dinero de esta cuenta se debe actualizar su saldo.

Utilizando C++ para lograr una implementación de este modelo conceptual podríamos
tener las siguiente definición para el objeto cliente.

class CLIENTE
{protected:
int identificación;
char nombre[20];
char dirección[30];
char teléfono[15];
public:
void depositar(double monto, int cuenta);
void retirar(double monto, int cuenta);
};

void main()
{ CLIENTE cliente1, cliente2, cliente3; }
En la codificación anterior es fácil percibir que la
palabra class denota una declaración de clase.
CLIENTE es el nombre que se le ha dado ha esta
clase; el cuerpo de la clase “{}” define los
atributos y funciones miembros del objeto que
representa la clase. Observe que en la declaración
del cuerpo de la clase se han incluido las palabras
public y protected que definen el carácter
publico o privado de los datos y métodos de una
clase. Se ha incluido también la función de inicio
estándar de C++ “main” donde se declaran tres
objetos basado en la clase CLIENTE.
Clases derivadas o herencia simple.
Las herencia es el mecanismo mediante el cual se pueden crear
clase nuevas basadas en clases ya existentes. Cuando se
implementa la herencia teniendo como base una clases
existentes (clases abstractas) esta sede todo los atributos y
comportamientos a las clases nuevas (clases derivadas) que se
deriven de ella. Ha esto se conoce también como derivación de
clases.

En el caso de la relación de los clientes con sus cuentas en un

banco podríamos analizar por ejemplo que los clientes pueden
ser personas o instituciones y tendríamos que hacer una
derivación de la clase CLIENTE.
En la figura 2 se observa la representación de la herencia o
derivación utilizando la notación UML. La clase
CLIENTE_PERSONA y CLIENTE_INSTITUCIÓN al ser
derivadas de la clase CLIENTE tendrían los atributos
identificación, nombre, dirección, teléfono y los métodos
depositar, retirar.

C l ie n t e
i d e n t i fi c a c i o n : i n t C u e n ta
n o m b re : c h a r*
+ $posee N o C u e n ta : i n t
d ire c c io n : c h a r*
s a l d o : d o u b le
t e l e fo n o : c h a r * 1 .. *
a c tu a li z a r ( )
d e p o s it a r()
re t ira r()

C lie n t e _ P e rs o n a C l i e n t e _ In s t i t u c i ó n
sexo : char e m p l ea d o s : in t
fe c h a _ n a c : c h a r t ip o _ o r g : c h a r
p e r s _ c o n ta c t o : c h a r

Figura 2 – Diagrama de clases con derivación o herencia simple.

En cuanto a la construcción de la herencia
en C++ veremos que al declarar una clase
derivada de una existente solamente se
tendrá que incluir referencias a la clase que
le da origen, por ejemplo para declarar la
clase CLIENTE_PERSONA y
CLIENTE_INSTITUCIÓN el código C++
es el siguiente:
class CLIENTE_PERSONA: public CLIENTE
{
protected:
char sexo;
char fecha_nac[8];
};

class CLIENTE_INSTITUCIÓN: public CLIENTE

{protected:
int empleados;
char tipo_org;
char pers_contacto[30];
};

void main()
{ CLIENTE_PERSONA CP; CLIENTE_INSTITUCIÓN CI; }
Agregación
Ahora veremos que pasa con las relaciones de
agregación. Comenzaremos el análisis a partir del
modelo de la figura 3. Observemos que el objeto
VENTA esta compuesta por la agregación del objeto
PRODUCTO y el objeto PAIS. En una relación de
agregación los objetos agregados colaboran con el
objeto que los contiene para funcionar como un todo.
En este sentido se podría afirmar que el objeto
VENTA contiene dentro de si a los objetos PAIS Y
PRODUCTO.
 Producto
Id_Producto : int Pais
Descripcion : char* Nombre_Pais : char*

Venta
cantidad : int

Figura 3 – Diagrama de clases con agregación

class PRODUCTO
{protected:
int Id_producto;
char descripción[30];
};

class PAIS
{protected:
char nombre_pais[30];
};

class VENTA
{protected:
int cantidad;
PAIS p;
PRODUCTO prod;
};

void main()
{ VENTA esta_venta; }
Herencia múltiple
La herencia múltiple establece que se puede derivar una clase a
partir de dos o mas clases padres. Analicemos ahora que sucedería
en el ejemplo del banco si los empleados de este también pueden
ser clientes del banco.

El objeto resultante de la fusión de un CLIENTE con un

EMPLEADO contendrá tanto las características del cliente como
las del empleado. En este sentido, el empleado que es cliente del
banco podrá depositar o retirar dinero de una cuenta, pero también,
recibirá un salario por trabajar en un departamento del banco de
empeñándose en una ocupación determinada.

Cuando se de nombre a este tipo de objetos debe tenerse cuidado de

que el nombre seleccionado refleje la ambigüedad de su
comportamiento. Veamos una implementación de esta situación
que se refleja en el diagrama de la figura 4.
 Cliente
identificacion : int Cuenta
nombre : char*
NoCuenta : int
direccion : char* +$posee
saldo : double
telefono : char* 1..*
actualizar()
depositar()
retirar()

Empleado
Ocupacion Cliente_Institución
Departamento Cliente_Persona empleados : int
Salario sexo : char tipo_org : char
fecha_nac : char pers_c ontac to : char

Empleado_Cliente

Figura 4 - Diagramas de clases con herencia múltiple.

class CLIENTE
{protected:
int identificación;
char nombre[20];
char dirección[30];
char teléfono[15];
public:
void depositar(double monto, int cuenta);
void retirar(double monto, int cuenta);
};

class CLIENTE_PERSONA: public CLIENTE

{
protected:
char sexo;
char fecha_nac[8];
};

class EMPLEADO
{
protected:
char ocupación[8];
char departamento[8];
double salario;
};

class EMPLEADO_CLIENTE: public CLIENTE_PERSONA, public EMPLEADO

{
};
Relaciones de asociación o enlace
Las relaciones de enlace se define como el conocimiento de un objeto de la
existencia de uno o mas objetos. Esto define la necesidad de asociar objetos
bajo una funcionalidad común. Por ejemplo en el caso que hemos venido
tratando se define como una relación de asociación la que vincula a un
CLIENTE con todas las CUENTAS que este posea en el banco. Las
asociaciones de objetos están ligadas a una cierta cardinalidad. Para
implementar estas relaciones utilizaremos conceptos como colección de
objetos.

Una colección de objeto esta soportada bajo una estructura de datos, estas
pueden ser listas simplemente enlazadas, listas doblemente enlazadas, árboles o
grafos, la particularidad de estas estructuras es que contienen objetos. A la hora
de declarar un enlace múltiple en una clase entonces tendríamos que declarar
un puntero al primer elemento de la colección suponiendo que este tiene
enlazado el resto de los objetos a través de una lista.

Programas como C++ ya traen definida colecciones de objetos en sus

bibliotecas de clases; a continuación veremos como usar este tipo de estructura
de datos.
 Transformación del Modelo de Objetos al Modelo
Relacional.

1) Representación de Objetos simples.

EQU IPO
N um eroD eEquipo EQUIPO (NumeroDeEquipo, Descripción,
D es cripción
FechaD eAdquis ición
FechaDeAdquisición, CostoDeCompra)
C os toD eC om pra

a) Diagrama del Objeto EQUIPO b) Afinidad que representa a EQUIPO

 2 Transformación de Objetos Compuestos.
Un objeto compuesto es el que tiene uno o más atributos de valores múltiples simples o de
grupo, pero no posee atributos de objeto. La figura 2.(a) muestra un ejemplo de objetos
compuesto, CUENTA-HOTEL. Para representarlo, se crea una afinidad para el objeto
base, CUENTA-HOTEL, y una afinidad adicional para el atributo de grupo que se repite,
CargoDiario, Este diseño relacional se muestra CUENTA-HOTEL
NumeroDeFactura
(a) Diagrama del objeto CUENTA-HOTEL FechaDeCliente
NombreDeCliente
TotalAdecuado
CargoDiario
FechaDeCargo
CargoDeHabitación
CargoDeAlimentos
CargoDeAlimentos
CargoDeTelefono
CargosMiscelaneos
CargoPorImpuesto
CUENTA-HOTEL (NúmeroDeFactura, FechaDeLlegada,
NombreDeCliente, TotalAdecuado)

CARGO-DIARIO (NúmeroDeFactura, FechaDeCargo,

CargoDeHabitación, CargoDeAlimeintos, CargoDeTeléfono,
CargosMiscelaneos, CargoPorImpuesto)

(b) Afinidades que representan a CUENTA-HOTEL

Transformación de los objetos combinados uno a uno

Ejemplo de representación relacional de objetivos combinados 1:1 (a)

Ejemplo de objetos combinados 1:1 y (b) su representación.

SOCIO CASILLERO
CASILLERO
SOCIO ID NúmeroDeCasillero
ID NúmeroDeSocio ID NúmeroDeCasillero
ID NúmeroDeSocio
Nombre Tipo
Tipo
Nombre Combinación
Dirección
Dirección Combinación
Ciudad Ubicación
Ubicación
Ciudad
Estado
Estado
CodigoPostal SOCIO
SOCIO
CodigoPostal 0:1
0:1
CASILLERO
CASILLERO
1:1
1:1
(a)

SOCIO (NúmeroDeSocio, Nombre, Dirección, Ciudad, Estado, CodigoPostal,

NúmeroDeCasillo)

CASILLERO (NúmeroDeCasillero, Tipo, Combinación, Ubicación)

(b)
Ejemplo de representación relacional de objetos
combinados 1:N
(a) Objetos combinados 1:N y (b) su representación.
EQUIPO
EQUIPO
ID NúmeroDeSerie
REPARACION
REPARACION
ID NúmeroDeSerie
ID NúmeroDeFactura
ID NúmeroDeFactura
Tipo
Tipo
Modelo Fecha
Fecha
Modelo Descripcion
FechaDeAdquisición
FechaDeAdquisición Descripcion
CostoDeAdquisición Costo
Costo
CostoDeAdquisición
Ubicación
Ubicación EQUIPO
EQUIPO
REPARACION 1:N
1:N
REPARACION
0:N
0:N
(a)

EQUIPO (NúmeroDeSerie, Tipo, Modelo, FechaDeAdquisición, CostoDeAdquisición, Ubicación)

REPARACIÓN (NúmeroDeFactura, Fecha, Descripción, Costo, NúmeroDeSerie)

(b)
3) Representación de las relaciones uno a muchos y
muchos a uno
Representación relacional del ejemplo de objetos combinados
N:M (a) Objetos LIBRO y AUTOR
(b) Su representación relacional.
LIBRO
LIBRO AUTOR
AUTOR
ID
IDISBN
ID
ISBN IDNúmeroDeSeguroSocial
NúmeroDeSeguroSocial
Titulo Nombre
Titulo Nombre
NumeroDeSolicitud Dirección
NumeroDeSolicitud Dirección
LIBRO
LIBRO
AUTOR 1:N
AUTOR 1:N
1:N
1:N

(a)

LIBRO (ISBN, Titulo, NumeroDeSolicitud)

AUTOR (NúmeroDeSeguroSocial, Nombre, Teléfono)
LIBRO-AUTOR (ISBN, NumeroSeguroSocial)

(b)
REPRESENTACION DE RELACIONES MUCHOS A MUCHOS

OBJETO1
OBJETO1 OBJETO2
ID O1 OBJETO2
ID O1 ID O2
ID O2
.. ..
.. ..
.. ..
OBJETO2
OBJETO2 OBJETO1
N:N
N:N OBJETO1 O:N
O:N

R1 R2
O1
O1 .. .. .. O2
O2 .. .. ..

R3
O1
O1 02
02 .. .. ..
Ejercicio No. 1 Forma de Suscripción
La figura (a) muestra una forma de suscripción a una revista, muestre
el modelo Orientado a Objetos y el Modelo Relacional
considerando:
a) La compañia tiene una publicación y no tiene planes para
producir revistas adicionales.
b) Si la compañia tiene varias publicaciones y el cliente puede
suscribirse a mas de una de ellas

NEXOS Para suscribirse

•1 año (6 números) por $18 – 20% menos que el precio en

puestos de periódicos.
•2 años(12 números) por $34 – ahorre 24%
Nombre .
Dirección .

Ciudad .Estado . Código Postal .

Pago Incluido Pagaré al recibirla

 Solución del inciso (a)
SUSCRIPCION
SUSCRIPCION
ID
ID NúmeroDeSuscripción
NúmeroDeSuscripción
FechaInicial
FechaInicial
FechaFinal
FechaFinal
CantidadAdecuada
CantidadAdecuada
Nombre
Nombre
Dirección
Dirección
Ciudad
Ciudad
Estado
Estado
CodigoPostal
CodigoPostal
CodigoDePago
CodigoDePago

SUSCRIPCION
NúmeroDesuscripcion FechaInicial FechaFinal CantidadAdeudada Nombre

Dirección Ciudad Estado CodigodePago CodigoPostal

 Solución (b)

CLIENTE
CLIENTE SUSCRIPCION
ID
ID NúmeroDeCliente
SUSCRIPCION
NúmeroDeCliente ID
ID NúmeroDeSuscripcion
NúmeroDeSuscripcion
Nombre
Nombre FechaInicial
FechaInicial
Dirección
Dirección FechaFinal
FechaFinal
Ciudad
Ciudad CantidadAdeudada
CantidadAdeudada
Estado
Estado CodigoDePago
CodigoDePago
CodigoPostal
CodigoPostal
CLIENTE
CLIENTE
SUSCRIPCIÓN
SUSCRIPCIÓN 1:N
1:N
1:N
1:N

CLIENTE
NumeroDeCliente Nombre Dirección Ciudad Estado CodigoPostal

SUSCRIPCION
NúmeroDesuscripcion FechaInicial FechaFinal CantidadAdeudada CodigoDePago NumeroDeCliente
Ejercicion No. 2 Citatorio para amonestación vial

La siguiente figura, muestra una ocurrencia de una forma de

citatorio para una amonestación vial, usada en el estado de
Washington. El diseñador ha dado indicios acerca de los objetos
implicitos de esta forma. Observe que algunas partes de la forma
se distinguen: porque tienen esquinas redondeadas, lo que indica
las secciones diferentes que pertenecen a objetos distintos.
Algunos grupos de atributos tienen nombres, lo cual señala la
necesidad de atributos de grupo.
 AVISO DE INFRACCION PATRULLA DEL ESTADO DE WASHINTON

Nombre Aguirre David M Fecha de la Falta Dist. Destac.

Apellidos Nombre de pila Mes 11 dia 7 año Hora 9:35 2 17
Ubicación
Direccion 5053 88 Ave SE 17 Distancia E Sentido Enunckum Cuidad SR410
Codigo
Faltas
Ciudad Mercer Island Estado Wa Postal 98049 Escribiendo miestras conduce
Licencia del Cond. Estado M Fecha de Nac. Estatura Peso Ojos
Oficial Número
AA000 Wa F 2127 46 6 156 bl
Scott Personal 850
Licencia del Vehi. Estado Color Año Marca Tipo
AA3b2 Wa White 90 Saab 900 Esta es una amonestación. No hay acciones posteriores.
NIV ( Número de Identificación del Vehículo
Se autoriza traslado para reparación. Se prohibe la
operación en esta vialidad.
Propietario
Corrija las faltas de inmediato. Regrese esta tarjeta para
Registrado comprobación en 15 – 30 días (si se marca este recuadro)

X Firma del
conductor
Dirección:
AVISO-DE-INFRACCION CONDUCTOR
ID
ID Número
Nombre
CONDUCTOR 1:1 1:1 Apellido
VEHÍCULO 1:1 1:1 NombreDePila
OFICIAL 1:1
1:1 Inicial 1:1
FechaDeLaFalta Dirección
Mes Ciudad
Dia Estado
Año 1:1 CodigoPostal
Hora ID
ID Licencia
Dist. LicenciaDelConductor 1:1
Destac. Estado
Ubicación Sexo
Distancia FechaDeNacimiento
Sentido Estatura
Ciudad 1:1
Peso
Vialidad Ojos
Falta 1:N
1:N
AcciónRequerida AVISO-DE-INFRACCION 1:N
1:N
VEHICULO
VEHICULO OFICIAL
ID
ID Licencia
Licencia ID
ID NúmeroPersonal
LicenciaDelVehiculo
LicenciaDelVehiculo
Estado Nombre
Estado
Color
Color
Año
Año AVISO-DE-INFRACCION 1:N
1:N
Marca
Marca
Tipo
Tipo
ID
ID NIV
NIV
PropiedadRegistrado
PropiedadRegistrado
Dirección
Dirección

AVISO-DE-INFRACCION
AVISO-DE-INFRACCION 1:N
1:N