Herencia o Generalizacion

ESCUELA SUPERIOR DE INFORMÁTICA DE CIUDAD REAL

Funcionalidad 1

Modelos de Bases de Datos Orientadas a Objetos y

Bases de Datos Objeto-Relacionales

Virginia Arcos Muñoz Ángel Escribano Santamaría

Silvia López Utrilla

Rocío Peña Gallego Sergio Susín Martínez

Francisco Antonio Utrilla Requena

Ciudad Real, 08 de febrero de 2008

Modelos Avanzados de Bases de Datos E.S.I. de Ciudad Real Funcionalidad 1: BBDDOO y BBDDOR Universidad de Castilla - la Mancha

2

Índice

Introducción ..................................................................................................................................3

Bases de Datos Orientadas a Objetos .............................................................................................3

Modelo de Objetos ....................................................................................................................3

Estándares de bases de datos de objetos ...................................................................................7

Ejemplo......................................................................................................................................8

Bases de Datos Objetos - Relacionales .........................................................................................10

Modelo Objeto - Relacional ......................................................................................................10

Ejemplo....................................................................................................................................14

Comparativa entre modelos .........................................................................................................15

Bibliografía...................................................................................................................................16

Tabla de Ilustraciones

Ilustración 1.- Diagrama de Ejemplo. ..............................................................................................9

Ilustración 2.- Ejemplo Tipos Distintos. .........................................................................................11

Ilustración 3.- Ejemplo Tipos Estructurados. .................................................................................12

Ilustración 4.- Ejemplos Tipos ROW y ARRAY. ...............................................................................13

Ilustración 5.- Ejemplo de Herencia. .............................................................................................14


3

Introducción

A finales de los años 80 y a principios de los 90, los expertos en base de datos enfrentaron

requerimientos de datos cada vez más complejos que eran difíciles de manejar con la tecnología

que existía en esos momentos. La composición cambiante de los datos modelados –la base de datos

podría incluir gráficos, vídeo, audio, diagramas, huellas digitales y sonido, así como números y

texto- motivó a reorganizar los sistemas de bases de datos existentes. Este esfuerzo de

reorganización condujo a una nueva oleada de tecnologías basadas en conceptos de programación

orientados a objetos, y a la adición de nuevas características a las bases de datos relacionales que

permitieron manejar mejor los datos complejos.

Dentro de estas nuevas tecnologías que aparecieron, este trabajo se centra en las bases de

datos objeto-relacionales y orientadas a objetos.

Bases de Datos Orientadas a Objetos

La orientación a objetos es una metodología de modelado y desarrollo basada en conceptos

orientados a objetos (OO). En concreto, la orientación a objetos se define como un conjunto de

principios de diseño y desarrollo basados en estructuras de computadoras conceptualmente

autónomas conocidas como objetos. Cada objeto representa una entidad del mundo real con la

capacidad de actuar consigo misma y de interactuar con otros objetos. Teniendo en cuenta este

concepto, las bases de datos orientadas a objetos (OODB) están diseñadas para capturar los datos

de un sistema de negocio, que puede ser considerado como un conjunto de objetos que interactúan

entre sí.

Modelo de Objetos

Para las OODB no ha existido un único modelo de datos, análogo al modelo relacional

difundido por Dr. Codd, sino que cada autor ha adoptado un modelo diferente. El modelo orientado

a objetos (OODM) que aquí se presenta tiene mucho en común con los modelos de datos

relacionales o E-R, también tiene algunas diferencias fundamentales. El resumen siguiente está

diseñado para ofrecer algunas comparaciones detalladas que aclaran las características de OODM

que se presenta en este apartado.

Objeto, entidad y tupla

El concepto OODM de objeto va más allá del concepto de entidad o tupla en otros modelos

de datos. Un objeto OODM tiene características adicionales a las de las entidades o tuplas, como

comportamiento, herencia y encapsulado. Tales características OODM hacen que el modelado OO


4

sea más natural que el modelado E-R y relacional. De hecho, los modelos E-R y relacionales a

menudo obligan al diseñador a crear entidades nuevas artificiales para representar entidades reales.

Atributos

Los objetos son descritos por sus atributos, conocidos como variables de instancia en un

ambiente OO. Cada atributo tiene un nombre único y un tipo de datos asociado a él. Los atributos

también tienen un dominio. El dominio agrupa y describe lógicamente el conjunto de todos los

valores posibles que un atributo puede tener. Es importante puntualizar que, al igual que en el

modelo E-R, el atributo de un objeto puede tener un valor único o valores múltiples. Además, los

atributos de objeto pueden hacer referencia a uno o más objetos. A nivel de ejecución, el OID del

objeto al que se referencia se utiliza para vincular ambos objetos, lo que permite la ejecución de

relaciones entre dos o más objetos. Esto es distinto al modelo relacional en el que el atributo de una

tabla puede contener sólo un valor que puede ser utilizado para unir filas (JOIN) en tablas

diferentes.

Identidad del objeto

La identidad del objeto está representada por el ID de objeto (OID), el cual es único de ese

objeto. El OID es asignado por el sistema al momento de la creación del objeto y no puede ser

cambiado en ninguna circunstancia. No debe confundirse con la clave principal del modelo

relacional, ya que esta última se basa en valores dados por el usuario de atributos seleccionados y

puede ser cambiada en cualquier momento. El OID puede ser eliminado sólo si el objeto es

eliminado, y ese OID no puede ser reutilizado.

Clase, conjunto de entidades y tabla

El concepto de clase puede ser asociado con los conceptos de conjunto de entidades y tabla

de los modelos E-R y relacional, respectivamente. No obstante, clase es un concepto más poderoso

que permite no sólo la descripción de la estructura de datos sino también la descripción del

comportamiento de los objetos clase. Además, el OODM introduce el concepto de tipos de datos

abstractos, permitiendo la definición de tipos de datos nuevos que posteriormente pueden ser

utilizados como cualquier otro tipo de datos base que acompaña a una base de datos,

incrementando así el contenido semántico de los objetos modelados.

Encapsulado y herencia

Estas dos características no son soportadas por los modelos de datos relacionales o E-R.


5

El encapsulado es la capacidad de ocultar los detalles internos del objeto (atributos y

métodos). Esta capacidad deriva de que la estructura interna de un objeto no puede ser accedida

directamente por otro objeto, garantizando la integridad del estado del objeto.

La herencia es la capacidad de un objeto dentro de una jerarquía de heredar la estructura de

datos y el comportamiento (métodos) de las clases sobre ella.

Relaciones

La principal propiedad de cualquier modelo de datos se encuentra en su representación de

relaciones entre los componentes de datos. Las relaciones en un OODM pueden ser de dos tipos:

relación interobjeto o herencia de jerarquía de clases.

Relaciones interobjeto: vínculos atributo-clase

Una relación atributo-clase o relación interobjeto, se crea cuando el atributo de un objeto

hace referencia a otro objeto de la misma o diferente clase. Existen dos tipos de relaciones

interobjeto: relaciones 1:M y M:N.

Relaciones 1:M

En contraste con el modelo relacional, el OODM soporta atributos multivaluados,

agregaciones conocidas como conjuntos o bolsas. Esta capacidad es esencial para representar

cualquier tipo de relaciones “a muchos”.

Para representar una relación 1:M se define un atributo en la clase “muchos” de la relación

para almacenar el identificador del objeto de la clase “uno”. En la clase “uno” se define un atributo

para almacenar un conjunto de valores, que serán los identificadores de los “muchos” objetos con

los que está relacionado.

Es importante tener en cuenta que aunque la relación es definida por los atributos en la

clase, en la propia base de datos las relaciones son entre objetos, es decir, las relaciones clave

primaria-clave ajena son entre filas específicas y no entre tablas completas.

Relaciones M:N

Debido a que una base de dato OO permite a los objetos tener atributos multivaluados, las

relaciones M:N pueden ser directamente representadas sin necesidad de crear entidades

compuestas. Para representar la relación M:N cada clase que participa en la relación define un

atributo que contendrá un conjunto de valores de las otras clases con las que está relacionada.

En principio, la capacidad de representar directamente relaciones M:N puede parecer una

gran ventaja de las bases de datos OO. Sin embargo, hay que tener mucho cuidado al usarlas

debido a que se produce pérdida de información.


6

Un tipo especial de relación M:N es la relación “parte de un todo”. En esta relación, un

producto puede estar compuesto de muchas partes y subpartes. Y, de la misma forma, la misma

parte o subparte puede ser usada en diferentes productos. La forma de implementar esta relación en

una base de datos es la misma que se ha comentado anteriormente, usando conjuntos de

identificadores de objetos en las dos clases que están relacionadas.

Relaciones de herencia de jerarquía de clases

Las relaciones de herencia de jerarquía de clases se utilizan para describir la relación entre

las clases de la jerarquía. Existen dos tipos de relaciones de herencia: la relación “is a” y “extends”.

Relaciones “is a”

La relación “is a”, también conocida como relación de generalización-especialización, crea

una jerarquía de herencia donde las subclases son tipos específicos de sus superclases. Este tipo de

herencia se denomina herencia de comportamiento, es decir, herencia de las operaciones de la

superclase a la subclase. Para implementar esta relación se requiere que la superclase sea una

interfaz y la subclase puede ser una clase u otra interfaz.

Relaciones “extends”

En la relación “extends”, una subclase extiende a su superclase más que restringirla a un

tipo más específico. Este tipo de herencia se utilizada para heredar el estado y el comportamiento

estrictamente entre clases.

Acceso

Los modelos E-R y relacionales dependen del uso de SQL para recuperar datos de la base

de datos. SQL es un lenguaje de consultas orientado a los conjuntos, que está basado en un modelo

matemático formalmente definido. Dada su herencia orientada a conjuntos, SQL utiliza métodos de

acceso asociativos para recuperar información relacionada de una base de datos, con base en el

valor de alguno de sus atributos.

A consecuencia del contenido de más semántica en su modelo de datos, el OODM produce

un esquema en el cual las relaciones forman parte de la estructura de la base de datos. El OODM

soporta tanto el acceso navegacional (registro a la vez) como el acceso orientado a conjuntos. El

acceso navegacional consiste en navegar a través de la estructura espacial del objeto desarrollado

por el diseñador utilizando las identidades de objeto.

El acceso orientado a conjuntos asociativo en el OODM debe ser provisto por métodos

explícitamente definidos, por consiguiente el diseñador debe ejecutar operaciones para manipular


7

las instancias de objeto en el esquema de objeto. La ejecución de esas operaciones afectará el

desempeño y la capacidad de la base de datos de manejar los datos. Aquí es donde aparece el

problema principal del modelo de objetos: la carencia de un modelo matemático subyacente

universalmente aceptado para la manipulación de los datos. Esto obliga a que cada ejecución cree

su propia versión de un lenguaje de consulta orientado a objetos (OQL).

Comparación de los componentes de los modelos OO y E-R.

Modelo de Datos Orientado a Objetos Modelo E - R

Tipo Definición de Entidad

Objeto Entidad

Clase Conjunto de Entidades

Variable de Instancia Atributo

Sin Correspondencia Clave Principal

OID Sin Correspondencia

Método Sin Correspondencia

Jerarquía de Clases Diagrama E – R

Estándares de bases de datos de objetos

En el diseño de OODB no existe una metodología estándar ampliamente aceptada que guíe

el proceso de diseño ni un conjunto de reglas (como las reglas de normalización en el modelo

relacional) para evaluar el diseño. Sin embargo, esta situación está mejorando. En 1989, un

consorcio de fabricantes de ODBMS formó el Object Management Group (OMG) para garantizar

la interoperabilidad entre todos los diferentes sistemas orientados a objetos (lenguajes, ambientes,

bases de datos, etc.). El OMG produce estándares y especificaciones independientes del proveedor

para componentes y sistemas basados en objetos.

El estándar propuesto por OMG se denomina ODMG (Object Data Management Group).

La primera versión de este estándar se publicó en 1993 y con el paso del tiempo se ha ido

refinando, llegando a su versión actual: ODMG 3.0.

Los principales componentes de este estándar son cuatro:

Modelo de objetos: el modelo de objetos está basado en el modelo de objetos de

OMG y lo extiende, añadiendo algunos componentes (como por ejemplo las

relaciones) para soportar las necesidades específicas de las bases de datos.

Lenguajes de especificación de objetos: el modelo de objetos de OMG soporta

dos lenguajes de especificación de objetos: el ODL (Object Definition Language) y

el OIF (Object Interchange Format). El ODL no es un lenguaje de programación


8

completo aunque es un lenguaje de definición independiente para la especificación

de objetos. La sintaxis del ODL extiende el lenguaje de definición de interfaces

(IDL) desarrollado por OMG. OIF es otro lenguaje de especificación que fue

introducido en la versión 2.0 del estándar y que se puede usar para intercambiar

objetos entre bases de datos, proporcionar documentación de bases de datos o guiar

un conjunto de pruebas de bases de datos.

Lenguaje de consulta de objetos (OQL): es un lenguaje declarativo para

consultar bases de datos. También proporciona algunos constructores para

actualizar los objetos de la misma. Aunque está basado en el lenguaje SQL, su

semántica no es la misma. OQL soporta capacidades más potentes con respecto al

resultado de la consulta, permitiendo obtener el mismo resultado en tipos

“colección” diferentes. Sin embargo, el resultado de una consulta SQL siempre es

una tabla.

Vinculación con lenguajes de programación: la actual versión del estándar tiene

vinculación con los lenguajes de programación C++, JAVA y Smalltalk. Estas

vinculaciones definen la correspondencia entre el ODL y los lenguajes de

programación correspondientes.

Ejemplo En la ilustración 1 se muestra un ejemplo que muestra un esquema de bases de datos

orientada a objetos, con una simbología semejante a UML.

En la ilustración 1, cada nodo representa una clase, y se compone de 3 niveles: nombre de

la clase, atributos y métodos. Los atributos que tienen el símbolo “*” son atributos multivaluados.

Los nodos se pueden conectar por dos tipos de arcos:

Un arco normal (línea delgada) indica que la clase del destino de la flecha es el

dominio de un atributo de la clase origen o el resultado de un método de la clase

origen. Esto se puede ver, por ejemplo, en el atributo documento de la clase

Proyecto, cuyo dominio es la clase Documento.

Un arco grueso indica que la clase origen de la flecha es una subclase de la clase

destino (herencia). Esta relación se puede apreciar entre las clases Informe Técnico

o la clase Artículo y Documento, siendo ésta última la superclase de las dos

anteriores.


9

En este ejemplo, además, se pueden contemplar relaciones interobjeto 1:M, como por

ejemplo entre Proyecto.documento y Documento.

Ilustración 1.- Diagrama de Ejemplo.


10

Bases de Datos Objetos - Relacionales

Las bases de datos objeto-relacionales son la evolución natural de las bases de datos

orientadas a objetos puras y las relacionales puras, debido a las limitaciones de ambas.

Las limitaciones presentadas por el relacional son las siguientes:

Debido a la imposición de la primera forma normal en el modelo relacional la

representación de los objetos es bastante pobre. A esto se une la falta de relaciones

anidadas. Como consecuencia de esto surge la necesidad de la utilización de

muchas tablas para dar soporte a estructuras complejas, como por ejemplo el uso

de tablas intermedias para resolver las relaciones de cardinalidad uno a muchos.

Al tratar estructuras recursivas o anidadas y en colecciones de datos que

correspondiendo al mismo tipo de entidad, el modelo no ofrece una respuesta

adecuada.

En el caso de la descomposición de los datos en múltiples tablas complica su

recuperación.

La creación de tipos está altamente limitada.

Ausencia de mecanismos de reutilización.

Con objeto de solucionar estas limitaciones, surge el modelo orientado a objetos puro, y

como una transición entre ambos aparece el modelo objeto-relacional, que vamos a tratar a

continuación.

Modelo Objeto - Relacional

Como se ha comentado en el punto anterior, una de las ventajas que aporta el modelo es la

posibilidad de tratar y/o definir tipos de datos más complejos.

Lobs

Es un tipo de dato que permite almacenar gran cantidad de información ( del orden de

Gigabytes). Existen dos tipos:


11

BLOB (Binary Large OBject): Se utiliza para guardar datos de tipo binario

(fotografía, audio, vídeo, etc.).

CLOB (Character Large OBject): Se usan para el almacenamiento de texto

(Libros, XML, etc.).

Dependiendo del SGBD y del tamaño de los LOBS, éstos se almacenan directamente en la

base de datos o una referencia hacia un fichero externo.

Tipos definidos por el usuario

Los usuarios pueden definir sus propios tipos de datos, a partir de los tipos básicos

provistos por el sistema o por otros tipos de datos predefinidos anteriormente por el usuario.

Existen dos tipos de datos definidos por el usuario, los tipos distintos y los tipos

estructurados.

Tipos distintos

En el modelo relacional, las columnas de una tabla se definen mediante tipos de datos

primitivos. De esta forma, dos columnas con distinta semántica y, por tanto, distinto

comportamiento, podían estar definidas bajo el mismo tipo de datos compartiendo la misma

representación. Se usan cuando dos tipos de datos comparten la misma representación pero tienen

distinto comportamiento. La definición de tipos distintos se basa en el renombrado de tipos, de tal

modo que el tipo distinto no es comparable con el tipo fuente.

Ilustración 2.- Ejemplo Tipos Distintos.

Tipos estructurados

Se pueden usar en cualquier sitio donde se pueda usar un tipo de datos predefinido. Están

formados por una agrupación de tipos predefinidos. Se podrían considerar como un “struct” en

lenguaje C.


12

Se pueden utilizar de dos formas diferentes:

Como tipo de una columna. Se utiliza un tipo compuesto como un atributo más de

una tabla.

Como tipo de una fila de una tabla (tabla tipada). Se utiliza el tipo compuesto para

definir de forma implícita la estructura de una tabla, es decir se creará una tabla

con la estructura necesaria para almacenar este tipo de datos, pudiéndose utilizar

como “objetos”. El SGBD se encarga de crear un atributo “REF” (Object

IDentification) que identificará de forma unívoca a una tupla, podríamos ver este

hecho como una abstracción del uso de “primary key”.

Ilustración 3.- Ejemplo Tipos Estructurados.

Tipos referencia

Podríamos entender los tipos referencia como la evolución de las “foreign key”. En la

definición de una tabla o de un tipo definido por el usuario, se podrá incluir una atributo de tipo

referencia, el cual almacenará el valor del OID del la fila de la tabla tipada referenciada.

Pueden ser usados en cualquier sitio donde pueda usarse otro tipo de datos.

Aunque como se ha apuntado podría verse como la evolución de las “foreign key” hay que

tener en cuenta que no tiene la misma semántica, La clave ajena implica integridad referencial y el

tipo referencia no, pudiendo tener referencia que no llevan a ninguna parte (“dangling references”).

Tipos colección

Una colección es un grupo de elementos homogéneos, primitivos o definidos por el

usuario. A grandes rasgos estos tipos permiten poder evitar las restricciones impuestas por la

primera forma normal en el modelo relacional, es decir se pueden utilizar como el tipo de datos de

una columna de una tabla. Podemos encontrar dos tipos de colecciones:

Array: Conjunto de elementos homogéneos e indexados (similar a un vector en un

lenguaje de programación de alto nivel) véase Ilustración 3.


13

Multiset: Conjunto de elementos homogéneos sin orden y permitiéndose

elementos repetidos, además se permiten colecciones anidadas.

Tipos ROW

Tipo de datos que agrupa atributos. Si una fila de una tabla es una instancia de un tipo

ROW, cada fila de la tabla tiene el mismo tipo. Con esto se consigue que un tipo de datos pueda

representar las filas de una tabla para ser almacenadas en variables, pasadas como argumentos a

rutinas y que sean devueltas por funciones. Estas características son las que diferencian los tipos

ROW de los tipos definidos por el usuario utilizados como descriptores de filas. Vemos un ejemplo

en la ilustración 4.

Ilustración 4.- Ejemplos Tipos ROW y ARRAY.

Herencia

La herencia de tipos indica que el subtipo hereda la estructura y el comportamiento del

supertipo, pudiendo además incluir características propias.

La herencia de tablas hace referencia a la parte extensional de un jerarquía, es decir , al

principio de clasificación por el que toda instancia del subtipo es también una instancia del

supertipo; para definir una jerarquía de tablas tanto la subtabla como la supertabla deben ser

tipadas. Las subtablas heredan los atributos, restricciones, disparadores, etc. De la supertabla.

La herencia de tipos como de tablas se especifica mediante la cláusula UNDER, y además

un tipo puede declarase como FINAL (si no puede tener subtipos) o como NOT FINAL (en caso

contrario):

En tipos: CREATE TYPE tipoFinca UNDER tipoPropiedad As () NOT FINAL;

En tablas: CREATE TABLE Finca OF tipoFinca UNDER Propiedad;

Sustitutabilidad

Se asegura que cualquier dato de un supertipo puede ser sustituido por un dato de

cualquiera de sus subtipos.

Personas

Nombre Dirección

Teléfono Calle Nº piso CP

Pepe Mata 59 5 13000 623987455 926547326

Mariano Paloma 2 3 13003 925786320 null


14

Vinculación dinámica

La herencia de tipos puede dar lugar a la sobrecarga o polimorfismo de métodos, es decir,

se puede redefinir la implementación de un método heredado al definir un subtipo.

Ilustración 5.- Ejemplo de Herencia.

Métodos

Los métodos son funciones SQL ligadas a un tipo estructurado que representan el

comportamiento de dicho tipo. La signatura del método se especifica junto a la definición del tipo

de datos al que va ligado. La especificación de su cuerpo se define separada.

Los métodos pueden ser llamados utilizando la notación “punto”.

Consultas

Una de las principales ventajas del modelo objeto-relacional es que permite la realización

de consultas navegacionales, permitiendo aumentar los tiempos de respuesta de las consultas

relacionales, al eliminarse la necesidad de hacer combinaciones.

Ejemplo

Utilizando la ilustración 1, en la que veíamos un diagrama que representa una estructura de

clases, vamos a ver cómo, utilizando el modelo objeto-relacional podríamos implementar en una

base de datos algunas de las características reflejadas en el mismo.

Podemos encontrar un ejemplo claro de un posible uso de tipos distintos en los atributos

código y título de la clase Documento. Ambos son de tipo STRING pero sus usos y posibles

estructuras están claramente diferenciados, y comparaciones entre ambos podrían suponer errores

semánticos. La clase Documento la podríamos modelar como una tabla tipada (procedente de un

tipo estructurado) de la cual heredarían “Informe Técnico” y “Artículo”. Además podríamos

enriquecer el diagrama con la inclusión de un atributo de tipo CLOB en la tabla tipada Documento,

el cual podría servir para almacenar el texto del mismo.

Si vemos la clase Proyecto observaremos que puede tener asociados uno o más

documentos, luego podríamos implementar esta particularidad mediante el uso de un tipo

MULTISET de tipos REFERENCIA, siendo estas últimas referencias a documentos (filas de la

tabla tipada Documento).


15

Haciendo una ligera modificación en el diseño podríamos incluir el uso de un tipo ROW en

Investigador, podríamos agrupar los atributos “salario” “bonificación” y “salario promedio” bajo

una denominación común, por ejemplo “SalarioInv”.

Ejemplos claros de uso de métodos los encontramos en diferentes ocasiones como para el

caso de la clase Investigador donde aparece el método “salario mensual()” así como en la clase

Proyectos encontramos métodos como “participantes()” y “balance()”.

Comparativa entre modelos

A continuación se ha realizado una tabla comparativa entre los dos modelos de bases datos

tratados a lo largo de este trabajo:

Característica Orientado a Objetos Objeto - Relacional

Contenido Semántico Incrementado mediante el uso de

objetos (atributos y métodos).

Incrementado mediante el tipo de

datos estructurado (atributos y

métodos).

Tipos de Datos Base Se extienden mediante el uso los

tipos de datos abstractos.

Se extiende mediante el uso de

nuevos tipos de datos (referencia,

colección y row) y definidos por el

usuario.

Tipos de Datos

Complejos Objetos Complejos. Tipos Estructurados Complejos.

Relaciones 1:M, M:N, “is a” y “extends” 1:M, M:N y “extends”.

Reutilización Mediante Herencia de Objetos. Mediante Herencia de Tipos

Estructurados y Tablas Tipadas.

Encapsulado Igual que en la Programación

Orientada a Objetos.

Igual que en la Programación

Orientada a Objetos.

Portabilidad Baja. Estándares poco aceptados. SQL 2003.

Modelo de Datos Sin Fundamento Teórico. Sin Fundamento Teórico.

Curva de Aprendizaje Elevada. Moderada.

Integridad Referencial Si, Referencias Cruzadas. Sólo con Claves Ajenas.

Comercialización Mercado Inmaduro. Más aceptado que el OO.

Acceso Navegacional y Orientado a

Conjuntos. Igual que en el Modelo Relacional.

Rendimiento Consultas eficientes gracias al uso

de referencias entre objetos.

Consultas eficientes gracias al uso de

referencias entre tipos de datos

estructurados.

Eficiencia

Optimiza el Acceso a Disco

(Agrupa los Datos Relacionados,

Objetos).

Semejante al Modelo Relacional.


16

Bibliografía

Bertino, E., Martino, L. “Sistemas de bases de datos orientadas a objetos. Concepto y

arquitecturas.”. Addison-Wesley/ Diaz de Santos 1995. USA.

Connolly, T. M., Begg, C. E. “Sistemas de bases de datos. Un enfoque práctico para

diseño, implementación y gestión”. 4ª edición. Addison-Wesley 2005.

Date, C. J. “Introducción a los sistemas de bases de datos”. 2001. México.

Harrington, J. L. “Object-Oriented Database Design. Clearly explained”. Morgan

Kaufmann 2000. USA.

Piattini, M., Marcos, E., Calero, C., Vela, B. “Tecnología y diseño de bases de datos”. Ra-

Ma 2006. España.

Rob, P., Coronel, C. “Sistemas de bases de datos. Diseño, implementación y

administración”. Thomson 2004. México.

Herencia o Generalizacion

Documents

Transcript of Herencia o Generalizacion