Universidad de Los Andes Escuela de Ingeniería de ... › ingenieria › ibc › bd ›...

Universidad de Los Andes

Escuela de Ingeniería de Sistemas

Departamento de Computación

Tema 3. Bases de datos orientadas por objetos

Tema 3. Bases de datos orientadas

por objetos

2020EISULA. Dpto. De Computación. Isabel Besembel C. Base de Datos. Sem. U-192

Contenido:

Modelo estándar del grupo ODMG 3.0.

Jerarquía de tipos.

Lenguajes de definición (LDO) y manipulación de objetos (LMO). Ejemplos en OQL

Objetivo:

Desarrollar habilidades en el modelado de bases de datos orientado por objetos

Actividades:

Leer: ODMG 3.0, Elmasri y Navathe, cap. 21 y Cattell y Barry, cap. 2, 3 y 4

Realizar los ejercicios de este documento

Realizar el ejercicio 3

Estándar ODMG


Concebido en 1991 como una iniciativa conjunta entre las empresas productoras de software en Sistemas Manejadores de Bases de Datos Orientados por Objetos (SMBDOO)

Actualmente la versión 3.0 (www.odbms.org)

Modelo de objetos:

La primitiva es el objeto con identificador y el literal sin identificador

Objetos y literales se pueden categorizar en tipos, un objeto puede ser referido como una instancia de un tipo

El estado de un objeto lo describen los valores de sus propiedades, que pueden ser de sus atributos o de relaciones entre él y otros objetos. El estado puede cambiar en el tiempo

El comportamiento de un objeto lo define el conjunto de sus operaciones

ODMG v3.0 Modelo de objetos


Un modelo de objetos especifica los objetos, literales, tipos, operaciones, propiedades, atributos, relaciones, etc.

El modelo de objetos de una aplicación es su esquema

Tipos (Type): Especificación e implementaciones

Define estado y comportamiento de sus instancias

Extensión: conjunto de todas las instancias del tipo

Estado y comportamiento se denominan las características del tipo

Especificación

Interface: define el comportamiento abstracto de un tipo y no puede ser instanciado directamente, ej: interface Empleado {…};

ODMG v3.0


Class: es una interfaz extendida con el esquema ODMS y

son instanciables, ej: class Persona {…};

Literal: define el estado abstracto de un tipo Literal, ej:

struct Complejo {float real; float imaginaria;};

Implementaciones

consiste de una representación y un conjunto de métodos

Representación: estructura de datos

ODMG v3.0


Implementaciones

Método: cuerpo procedimental normalmente asociado a una operación del tipo

Jerarquía

Los tipos se organizan en un grafo de subtipos y supertipos

Un subtipo hereda de sus supertipos, pudiendo definir nuevas características para él

interface TrabajadorUniversitario {…};

interface Profesor : TrabajadorUniversitario {…};

interface ProfesorAsociado : Profesor {…};

Traba j ado rUn i ve rsi ta ri o

P ro feso r

P ro feso rAsoci adoesUn(a)

ODMG v3.0


Herencia La relación EXTENDS permite la herencia de estado y

comportamiento entre clases (class) y los que no son literales

La relación (:) ESUN(A) permite la herencia de comportamiento entre tiposclass Persona{ attribute string nombre;

attribute Date fechaNac;};class Empleado extends Persona : Trabajador{ attribute Date fechaIngreso;

attribute Currency salario;relationship Gerencia asignadoA inverse

Gerencia::empleados;};class Gerente extends Empleado{ relationship set<Trabajador> subordinados inverse

Trabajador::jefe;relationship Gerencia esJefe inverse Gerencia::gerente;

};

Persona

- nombre :string

- fechaNac :Date

Empleado

- fechaIngreso :Date

- salario :Currency

Trabajador

Gerencia Gerente

-subordinados 1..*

-jefe 1

-empleados 1..*

-asignadoA «extends»

«extends»

-gerente

1

-esJefe

Extensión y claves


La extensión de un tipo es el conjunto de todas las instancias del tipo

Un objeto que es instancia del tipo A, es miembro de la extensión de A

Si A es un subtipo de B, entonces la extensión de A es un subconjunto de la extensión de B

Si se quiere mantener la extensión se debe indicar con la palabra extent

Un objeto se puede identificar con predicados sobre sus características

En el tipo se pueden declarar qué valores de las propiedades son suficientes para identificar unívocamente los objetos en su extensión

Se indican con la palabra key, la cual puede ser simple (key) o compuesta (keys)

El alcance de la unicidad de una clave es la extensión del tipo

ODMG v3.0 creación de objetos


Cuando se crea un objeto se especifica su implementación la cual puede cambiarse dinámicamente después

Los objetos tienen estado, comportamiento e identidad

Los objetos mutables, no literales, pueden cambiar los valores de sus atributos y sus relaciones con otros objetos, pero su identidad es invariante a lo largo de su vida

El identificador del objeto tiene como dominio la base de datos donde existe y es generado por el SMBDOO

Un nombre refiere a un objeto único en un determinado alcance

Si un objeto tiene varios nombres dentro de un alcance es posible determinar a tiempo de ejecución todos esos nombres

Objetos pueden ser: transientes (transient) o persistentes (persistent)

La estructura del objeto puede ser atómica o compuesta por otros objetos

El tiempo de vida de un objeto es ortogonal al tipo del objeto

ODMG v3.0


Los tipos del sistema se organizan como un árbol, pero los definidos por el usuario pueden formar un digrafo acíclico(dag)

Jerarquía de tipos ODMG

Los atributos se definen para cada tipo de objeto tomando literales como valores y sin tener oid

Su individualidad se determina por el objeto individual al cual se aplica

Ej: attribute short edad default 0;

Se provee el valor nulo para cada literal

Los atributos no son de primera clase y no pueden tener a su vez atributos ni relaciones

Tomado de Cattell & Barry, 2000

Literales


Valores sin oid que pueden ser atómicos o complejos

Literales atómicos: soportados por el modelo: enteros, reales, lógicos, caracteres y enumerados, generado con enum nombre {…}

Colecciones de literales: Conjunto, bolsa, lista, arreglo y diccionario, generados de forma análoga a los objetos collection, pero no tienen oid y pueden contener tanto literales como objetos

Literales estructurados: tienen un número fijo de elementos, donde cada uno tienen un nombre de variable y puede contener un valor o un objeto, ejemplo: fecha, intervalo, hora y fechaHora, structnombre{ string nom; string ape; }

Creación de objetos


Mediante la invocación de la operación new de

ObjectFactory

Hereda implícitamente la estructura y las operaciones

de la interface Object que contiene

Cualquier acceso, creación, modificación y eliminación

de objetos persistentes debe realizarse dentro de una

transacción

Para manejo transaccional

Comparación de identidades

Copia


Objetos complejos


Colección de objetos de un mismo

tipo pasado por parámetro t

Heredan también las operaciones de

Object

Pueden tener iteradores


Conjuntos y bolsas


Set

Colección desordenada de

elementos que NO admite

duplicados

Bag

Colección

desordenada de

elementos que admite

duplicados


Listas


List

Colección ordenada

de elementos cuyo

índice se inicia en cero


Arreglos


Array

Colección ordenada

de elementos que

pueden ser localizados

por su posición

relativa al inicio del

arreglo y su tamaño es

actualizado

dinámicamente Tomado de Cattell & Barry, 2000

Diccionarios



Dictionary

Secuencia desordenada de

pares (clave-valor) que NO

admiten claves duplicadas.

Cada par es una instancia

de la estructura

Struct Association {Object key;

Object value;);

Fecha



Intervalo, Hora y FechaHora



Interval

Representan

duración de

tiempo para

Time y

Timestamp

Time Timestamp

En GTM

Propiedades de objetos


Declaradas en la especificación de la clase

Atributos

Relaciones entre tipos Binarias: uno-a-uno, uno-a-muchos o muchos-a-muchos,

dependiendo de cuantas instancias participan en la relación

N-arias: no definidas en el modelo


Operaciones


Modelan el comportamiento de los objetos Se define asociada a un tipo y se especifica con su firma

(signature) El nombre dado a la operación debe ser único para el tipo Si se usa el mismo nombre en diferentes tipos hay

sobrecarga, que se resuelve según el objeto asociado (operation dispatching)

Usa el modelo single-dispatch por consistencia con C++, Java, Smalltalk y OMG CORBA

Recomienda el uso de pre y pos condiciones e invariantes Asume una ejecución secuencial de las operaciones


Creación de bases de datos


Mediante la instanciación de

DatabaseFactory

La base de datos puede ser

manipulada según la interfaz

Abrir y cerrar una base de

datos son las únicas

operaciones que pueden

ejecutarse fuera de una

transacción


Lenguaje de definición de objetos



LDO



Ejemplo


class Persona

( extent Personas

key(apellidos))

{

attribute String nombres;

attribute String direccion;

attribute String apellidos;

boolean cambiaPersona();

boolean creaPersona();

boolean eliminaPersona()

};

class Pasajero extends Persona

( extent Pasajeros

key(nroIdentificacion))

{

attribute String nroIdentificacion;

attribute Set<String> telefonos;

relationship Set<Reservacion> reservas inverse

Reservacion::reservadaPor;

boolean despliegaPasajero();

boolean modificaPasajero();

boolean nuevoPasajero();

boolean suprimePasajero()

};

class reserv ación

Pasajero

- nroIdentificacion: String

- telefonos: SetOf<String>

+ despliegaPasajero(): Boolean

+ modificaPasajero(): Boolean

+ nuevoPasajero(): Boolean

+ suprimePasajero(): Boolean

Persona

- apell idos: String

- direccion: String

- nombres: String

+ cambiaPersona(): Boolean

+ creaPersona(): Boolean

+ eliminaPersona(): Boolean

«extends»

Autoevaluación


1. ¿Qué es el estándar ODMG?

2. ¿Cómo es su modelo de objetos?

3. ¿Cuáles son los tipos de herencia que soporta?

4. ¿Cómo es la creación de objetos en ODMG?

5. ¿Cómo es la jerarquía?

6. ¿Cuáles son los literales?

7. ¿Cuáles son los objetos complejos?

8. ¿Cómo se indican las propiedades y las operaciones

de los objetos?

9. ¿Cómo se crea una base de datos en ODMG?

Ejercicio


Realice el modelo y esquema en LDO para representar

el siguiente diagrama de clases UML Estudiante

- CI: D1-TipoCIoRIF- nombre: D2-TipoNombre- apellido: D2-TipoNombre

+ inscribirEst(): bool+ listarEst(): Estudiante+ cambiarEst(): bool+ retirarEst(): bool

«dataType»D1-TipoCIoRIF

constraints{Cadena(10) en {V, P, E, -, digitos}}

«dataType»D2-TipoNombre

constraints{Cadena(32) en {letras, ', }}

«dataType»D3-TipoCodigo

constraints{Cadena(4) en {digitos}}

Asignatura

- codAsig: D3-TipoCodigo- nomAsig: D2-TipoNombre

+ abrirAsig(): bool+ cambiarAsig(): bool+ listarAsig(): Asignatura+ listarPrelaA(): list<Asignatura>+ listarPrelaciones(): list<Asignatura>+ cerrarAsig(): bool

Seccion

- nro: D4-TipoEntero+- sem: D5-TipoSemestre

+ abrirSecAsig(): bool+ cambiarSecAsig(): bool+ cerrarSecAsig(): bool+ listarSecAsig(): Seccion+ listarSeccionesAsig(): list<Seccion>

«dataType»D4-TipoEntero+

constraints{Entero >= 0}

«dataType»D5-TipoSemestre

constraints{Cadena(4) en {A, B, U, -, digitos}}

Nota

- notas: D6-TipoNota [1..20] {ordered}- pesos: D7-TipoPeso [1..20] {ordered}- definitiva: D6-TipoNota

+ asignarNota(D6-TipoNota, D1-TipoCIoRIF): bool+ listarNotasXestudiante(D1-TipoCIoRIF): Nota+ listarNotasXseccion(D4-TipoEntero+, D5-TipoSemestre): list<Nota>+ listarNotasXseccionYestudiante(D1-TipoCIoRIF, D4-TipoEntero+, D5-TipoSemestre): Nota

Profesor

- CI: D1-TipoCIoRIF- nomProf: D2-TipoNombre- feContratacion: D2-TipoNombre

«abstract»Educador

«dataType»D6-TipoNota

constraints{0 <= float <= 20}

«dataType»D7-TipoPeso

constraints{0 <= float <= 100}

-prelaA *

prelacion

-preladaPor *

«extends»

-cursadaPor

5..50

-cursa

1..*

-asigna *

-prof 1

Universidad de Los Andes Escuela de Ingeniería de ... › ingenieria › ibc › bd ›...

Documents

Transcript of Universidad de Los Andes Escuela de Ingeniería de ... › ingenieria › ibc › bd ›...