UNIDAD 7 - Bases de Datos Orientadas a objetos

7.1 Visión general

Los modelos de bases de datos tradicionales presentan deficiencias en cuento a aplicaciones más complejas o sofisticadas. Además son difíciles de utilizar cuando las aplicaciones que acceden a ellas están escritas en un lenguaje de programación orientado a objetos.

 La orientación a objetos ofrece flexibilidad, no está limitada por los tipos de datos y los lenguajes de consulta  de los sistemas de bases de datos tradicionales. La característica clave es la potencia que proporcionan al diseñador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos.

 Las BDOO se han diseñado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos. También están diseñadas para simplificar la POO. Almacenan los objetos en la BD con las mismas estructuras y relaciones que los lenguajes de POO. 

 Una SGBDOO es una SGBD que almacena objetos incorporando así todas las ventajas de la OO. Pueden  tratar directamente con objetos, no teniendo que hacer la traducción a tablas o registros. Sus objetos se conservan, pueden ser gestionados aunque su tamaño sea grande, pueden ser compartidos entre múltiples usuarios  y mantienen su integridad como sus relaciones.

 ODMG (Object Database Mangement Group) es el grupo de fabricantes de SGBDOO que propuso el estándar ODM-93 en 1993; en 1997 evolucionó a ODMG-2.0 y en enero de 2000 se publicó la última versión ODMG 3.0. El uso del estándar proporciona portabilidad (que se pueda ejecutar sobre sistemas distintos), interoperabilidad (que la aplicación pueda acceder a varios sistemas diferentes) y además permite que los usuarios puedan comparar entre distintos sistemas comerciales.

7.2 Tipos de datos complejos

Los elementos de datos básicos son registros bastante pequeños cuyos campos son atómicos. En los últimos años, ha crecido la demanda de formas de abordar tipos de datos más complejos. Considérense por ejemplo, las direcciones. Mientras que una dirección completa se puede considerar como un elemento de datos atómico del tipo cadena de caracteres, esa forma de verlo esconde detalles como la calle, la población y el código postal que pueden ser interesantes para las consultas. Por otra parte, si una dirección se representa dividiéndola en sus componentes, la escritura de las consultas sería más complicada.

Como ejemplo adicional, considérense los atributos multivalorados del modelo E-R. Esos atributos resultan naturales, por ejemplo, para la representación de números de teléfono, ya que las personas pueden tener más de un teléfono.

Con sistemas de tipos complejos se pueden representar directamente conceptos del modelo E-R, como los atributos compuestos, los atributos multivalorados, la generalización y la especialización, sin necesidad de una compleja traducción al modelo relacional

7.3 Tipos estructurados y herencia en SQL

Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, 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),

apellidos varchar(20))

final

De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto dirección:

create type Direccion as

(calle varchar(20),

ciudad varchar(20),

codigo_postal varchar(9))

not final

En SQL estos tipos se denominan tipos definidos por el usuario. Las especificaciones final indica que no se puede crear subtipos de nombre, mientras que la especificación not final de dirección indica que se pueden crear subtipos de dirección. 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. Por ejemplo, se puede crear una tabla cliente de la siguiente manera.

create table cliente (

nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

O bien, realizando una estructura más del tipo Cliente y generar la tabla a partir de ella:

create type TipoCliente as

(nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

not final

create table cliente of TipoCliente

Se puede tener acceso a los componentes de los atributos compuestos usando la notación “punto”; por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El acceso al atributo nombre devolvería un valor del tipo estructurado Nombre.

La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre.apellido, direccion.ciudad

from cliente

En SQL:1999 se usan funciones constructoras para crear valores de los tipos estructurados. Las funciones con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado. Por ejemplo, se puede declarar una función constructora para el tipo Nombre de esta manera:

create function Nombre(nombre_pila varchar(20), apellidos varchar(20))

returns Nombre

begin

set self.nombre_pila = nombre_pila;

set self.apellidos = apellidos;

end

De manera predeterminada, cada tipo estructurado tiene una función sin argumentos que configura los atributos con sus valores predeterminados. Cualquier otra función constructora hay que crearla de manera específica.

La instrucción siguiente ilustra la manera de crear una nueva tupla de la relación Cliente. Se da por supuesto que se ha definido una función constructora para Direccion, igual que la función constructora que se definió para Nombre.

insert into Cliente

values

(new Nombre(‘Martín’, ‘Gómez’),

new Direccion(‘Calle Mayor 20’, ‘Madrid’, ‘28045’),

date ‘22-8-1960’)

7.4 Herencia de tablas

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

A continuación se puede definir las tablas estudiantes y profesores como subtablas de personas, de la manera siguiente:

create table estudiantes of Estudiante

under personas

create table profesores of Profesor

under personas

Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Por tanto, todos los atributos presentes en personas también están presentes en las subtablas.

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

SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas “only personas” en lugar de personas. La palabra clave only también puede usarse en las sentencias delete y update. Sin la palabra clave only, la instrucción delete aplicada a una supertabla, como personas, también borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes); por ejemplo, la instrucción

delete from personas where P

borrará todas las tuplas de la tabla personas, así como de sus subtablas estudiantes y profesores, que satisfagan P. Si se añade la palabra clave only a la instrucción anterior, las tuplas que se insertaron en las subtablas no se ven afectadas, aunque satisfagan las condiciones de la cláusula where.

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se añadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces.

Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro. Supóngase también que se deseara almacenar almacenar el nombre de los autores de un libro en forma de array; a diferencia de los elementos de los multiconjuntos, los elementos de los arrays están ordenados, de modo que se puede distinguir el primer autor del segundo autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),

sucursal varchar(20))

create type Libro as

(titulo varchar(20),

array_autores varchar(20) array[10],

fecha_publicacion date,

editor Editor,

conjunto_palabras_clave varchar(20) multiset)

create table libros of Libro

7.5 Tipos de arreglo multiconjunto en SQL

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se añadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces.

Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro. Supóngase también que se deseara almacenar almacenar el nombre de los autores de un libro en forma de array; a diferencia de los elementos de los multiconjuntos, los elementos de los arrays están ordenados, de modo que se puede distinguir el primer autor del segundo autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),

sucursal varchar(20))

create type Libro as

(titulo varchar(20),

array_autores varchar(20) array[10],

fecha_publicacion date,

editor Editor,

conjunto_palabras_clave varchar(20) multiset)

create table libros of Libro

7.6 Identidad de los objetos y tipos de referencia en SQL

Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la manera siguiente:

create type Departamento(

nombre varchar(20),

director ref(Persona) scope personas)

create table departamentos of Departamento

En este caso, la referencia está restringida a las tuplas de la tabla personas. La restricción del ámbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas.

La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autorreferenciable (self-referential attribute), 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, id_persona es el nombre del atributo, no una palabra clave, y la instrucción system generated especifica que la base de datos genera de manera automática el identificador.

Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente:

insert into departamentos

values (‘CS’, null)

update departamentos set director = (select p.id_persona

from persona as p

where nombre = ‘Martín’)

where nombre = ‘CS’

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

Al insertar tuplas en personas hay que proporcionar el valor del identificador:

insert into personas (id_persona, nombre, direccion) values

(‘01284567’, ‘Martín’, ‘Av del Segura, 23’)

7.7 Implementación de las características O-R

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.

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

PASTOR GODINEZ OMAR

JUAREZ SANTIAGO HECTOR

Unidad 7 BASES DE DATOS ORIENTADAS A OBJETOS

BASES DE DATOS ORIENTADAS A OBJETOS

7.1 Visión general

El modelo de datos orientado a objetos es una adaptación para los sistemas de bases de datos del paradigma de la programación orientada a objetos. Se basa en el concepto de encapsular los datos en un objeto y el código que opera sobre ellos.

De manera parecida, los objetos estructurados se agrupan en clases. El conjunto de las clases se estructura en subclases y superclases basadas en una extensión del concepto ES del modelo entidad-relación.

 El valor de un elemento de datos de un objeto puede ser un objeto, haciendo posible representar los continentes de objetos, lo que da lugar a objetos compuestos.

En general, cada objeto está asociado con

• Un conjunto de variables que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R.

• Un conjunto de mensajes a los que responde; cada mensaje puede no tener parámetros, tener uno o varios.

• Un conjunto de métodos, cada uno de los cuales es código que implementa un mensaje; el método devuelve un valor como respuesta al mensaje.

7.2 Tipos de datos complejos

Considérense, por ejemplo, un conjunto de direcciones. Mientras una dirección completa puede ser vista como un elemento de datos atómico de tipo cadena de caracteres, esta forma de verlo escondería detalles como la calle, la población, la provincia, y el código postal que podrían ser interesantes para las consultas. Por otra parte, si una dirección se representa dividiéndola en componentes (calle, población, provincia y código postal) las consultas escritas serían más complicadas, pues tendrían que mencionar cada campo. Una alternativa mejor es permitir tipos de datos estructurados, que admiten un tipo dirección con subpartes calle, población, provincia y código postal.

Otro ejemplo: considérense los atributos multivalorados del modelo E-R. Tales atributos son naturales, por ejemplo, para la representación de números de teléfono, ya que las personas pueden tener más de un teléfono. La alternativa de normalización con la creación de una nueva relación es costosa y artificial para este ejemplo.

7.3 Tipos estructurados y herencia en SQL

Los tipos estructurados permiten la representación directa de atributos compuestos de los diagramas E-R.

Los tipos estructurados se pueden declarar y usar en SQL como en el siguiente ejemplo:

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-pub date,

editorial Editorial,

lista-palabras-clave setof(varchar(20)))

create table libros of type Libro

La primera instrucción define el tipo Editorial, que tiene dos componentes: un nombre y una sucursal. La segunda instrucción define el tipo Libro, que contiene título, array-autores, que es un array de autores, una fecha de publicación, una editorial (de tipo Editorial) y un conjunto de palabras clave. (La declaración de lista-palabrasclave como un conjunto usa la sintaxis extendida y no está soportada en la norma SQL) Los tipos ilustrados se denomina tipos estructurados en SQL.

La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas.

Herencia de tipos

Se dispone de la siguiente definición de tipos para las personas:

create type Persona

(nombre varchar(20),

dirección varchar(20))

Dado que los estudiantes y los profesores también son personas, se puede utilizar la herencia para  definir los tipos estudiante y profesor en SQL:

create type Estudiante

under Persona

(curso varchar(20),

departamento varchar(20))

create type Profesor

under Persona

(sueldo integer,

departamento varchar(20))

Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y dirección. Estudiante y Profesor se denominan subtipos de Persona y ésta, a su vez, es un supertipo de Estudiante y de Profesor.

Los métodos de un tipo estructurado se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarando de nuevo el método, usando overriding method en lugar de method en la declaración del método.

Supóngase ahora que se desea guardar la información sobre los ayudantes, que son simultáneamente estudiantes y profesores, quizás incluso en departamentos diferentes. Esto se puede hacer usando la herencia múltiple.

Por ejemplo, si el 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

Ayudante heredaría todos los atributos de Estudiante y de Profesor.

7.4 Herencia de tablas

Las subtablas en SQL se corresponden con la noción del modelo E-R de la especialización y la generalización. Por ejemplo, supóngase que se define la tabla personas de la manera siguiente:

create table persona of Persona

Se pueden definir entonces las tablas estudiantes y profesores como subtablas de persona:

create table estudiantes of Estudiante

under persona

create table profesores of Profesor

under persona

Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre. Por tanto, cada atributo presente en persona debe estar también presente en las subtablas. Si una consulta usa la tabla persona, encontrará no sólo las tuplas insertadas directamente en la tabla, sino también las tuplas insertadas en sus subtablas estudiantes y profesores. Sin embargo, sólo se puede acceder a los atributos que están presentes en persona.

7.5 Tipos de arreglo multiconjunto en SQL

Los conjuntos son ejemplares de los tipos colección. Otros ejemplares son los arrays y los multiconjuntos (es decir, colecciones sin orden donde un elemento puede aparecer varias veces). Las siguientes definiciones de atributos ilustran la declaración de un array:

array-autores varchar(20) array [10]

array-autores es un array de hasta 10 nombres de autor. Se puede acceder a los elementos del array especificando el índice del array, por ejemplo, array-autores[1]. Los arrays son el único tipo colección soportado en SQL la sintaxis usada es como en la declaración precedente. Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios kilobytes), tales como la fotografía de una persona, o muy grandes (del orden de varios megabytes o incluso gigabytes), tales como imágenes médicas de alta resolución o clips de vídeo. SQL proporciona por tanto nuevos tipos de datos para objetos de gran tamaño para datos de caracteres (clob) y binarios (blob). Las letras «lob» en estos tipos de datos son acrónimos de «Large OBject» (objeto grande). Por ejemplo, se pueden declararlos siguientes atributos:crítica-libro clob(10KB)imagen blob(10MB)

crítica-libro clob(10KB)

imagen blob(10MB)

película blob(2GB)

Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicación conseguiría un «localizador» de un objeto grande y lo usaría para manipularlo desde el lenguaje anfitrión. Por ejemplo, JDBC permite al programador extraer un objeto grande en pequeños trozos, en lugar de todo a la vez, de forma muy parecida a la extracción de datos de un archivo del sistema operativo.

7.6 Identidad de los objetos y tipos de referencia en SQL

La identidad de los objetos es un concepto de identidad más potente que el que suele hallarse en los lenguajes de programación o en los modelos de datos que no se basan en la programación orientada a objetos.

Ejemplos de identidad.

• Valor. Se utiliza un valor de datos como identidad. Esta forma de identidad se utiliza en los sistemas relacionales. Por ejemplo, el valor de la clave primaria de una tupla identifica a la tupla.

• Nombre. Se utiliza como identidad un nombre proporcionado por el usuario. Esta forma de identidad suele utilizarse para los archivos en los sistemas de archivos. Cada archivo recibe un nombre que lo identifica de manera unívoca, independientemente de su contenido.

• Incorporada. Se incluye el concepto de identidad en el modelo de datos o en el lenguaje de programación y no hace falta que el usuario proporcione ningún identificador. Esta forma de identidad se utiliza en los sistemas orientados a objetos. Cada objeto recibe del sistema de manera automática un identificador en el momento en que se crea.

Los lenguajes orientados a objetos proporcionan la posibilidad de hacer referencia a los objetos. El atributo de un tipo puede ser una referencia a un objeto de un tipo especificado. Por ejemplo, en SQL se puede definir un tipo Departamento, con campos nombre y director, que es una referencia al tipo Persona, y una tabla departamentos de tipo Departamento, como sigue:

create type Departamento(

nombre varchar(20),

director ref(Persona) scope persona

)

create table departamentos of Departamento

La referencia en este ejemplo está restringida a tuplas de la tabla persona. La restricción de scope de una referencia a las tuplas de una tabla es obligatoria en SQL y hace que las referencias se comporten comoclaves externas.

La tabla referenciada debe tener un atributo que almacene el identificador de la tupla. Este atributo, denominado atributo autorreferencial, se declara añadiendo la cláusula ref is a la instrucción create table.

create table persona of Persona

ref is ido system generated

Donde ido es un nombre de atributo, no una palabra clave. La subconsulta anterior podría usar

select p.ido en lugar de select ref(p).

Una alternativa a los identificadores generados por el sistema es permitir a los usuarios generar identificadores. El tipo del atributo autorreferencial se debe especificar como parte de la definición de tipos de la tabla referenciada, y la definición de tabla debe especificar que la referencia la genera el usuario (user generated).

create type Persona

(nombre varchar(20),

dirección varchar(20))

ref using varchar(20)

create table persona of Persona

ref is ido user generated

Al insertar una tupla en persona se debe proporcionar un valor para el identificador:

insert into persona values

(‘01284567’, ‘Juan’, ‘Plaza Mayor, 1’)

Ninguna otra tupla de persona o sus supertablas pueden tener el mismo identificador. Se puede entonces usar el valor del identificador al insertar una tupla en departamentos, sin necesitar una consulta separada para obtener el identificador.

insert into departamentos

values (‘Informática’, ‘01284567’)

7.7 Implementación de las características O-R

La orientación a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que se han organizado tomando como base conceptos del mundo real.
Los modelos orientados a objetos son útiles para comprender problemas, comunicarse con expertos en esa aplicación, modelar empresas, preparar documentación y diseñar programas y bases de datos.

    El beneficio principal no es un tiempo de desarrollo más reducido, el desarrollo orientado a objetos puede requerir más tiempo que el desarrollo convencional porque se pretende que promueva la reutilización futura y la reducción de los posteriores errores y el futuro mantenimiento.

    Las bases de datos orientadas a objetos unen dos tecnologías:

    La de las bases de datos y la de los lenguajes orientados a objetos. Los LPOO aportan gran capacidad en la manipulación de datos, pero no implementan el almacenamiento y consulta de grandes volúmenes de datos.

    Por el contrario, las bases de datos convencionales aportan un dominio de las técnicas de almacenamiento y consulta de grandes volúmenes de datos, aunque su capacidad de manipulación es limitada.

    Las bases de datos orientadas a objetos pretenden unir la capacidad de manipulación de datos de los LPOO con la capacidad de almacenamiento y consulta de los SGBD.

• Crear objetos
• Crear clases para organizar objetos
• Llamar métodos para acceder objetos específicos
• Estructuras jerárquicas de herencia para organizar clases y sub-clases

Facilidades de bases de datos estándar

·         Facilidades de queries no procedimentales para recuperar objetos

·         Procesamiento y optimización de queries automáticos

·         Cambios de esquemas dinámicos

·         Manejo de transacciones automáticas

·         Control de concurrencia

·         Seguridad e integridad

Enfoques de construcción de BDOO

ü    Primer enfoque

l          Utilizar código actual

l          No hay que implementar de cero

l          Se construyen los sistemas a partir de componentes ya probados

ü    Segundo enfoque

l          Extensión de la tecnología de las BD relacionales

l          Tercer enfoque

l          Nueva arquitectura optimizada

ü    Los lenguajes de programación orientado a objetos requieren que toda la interacción con los objetos se realiza mediante el envió de mensajes.

ü    Complejidad de modificación:

l          Adición de una clase

l          Eliminación de una clase

ü    Identidad de Objetos

l          Se debe asignar a cada objeto un OID

l          Debe ser inmutable

l          Se debe usar una sola vez

l          No debe No debe depender de la dirección física de almacenamiento

l          depender de ningún atributo

ü    Constructores Básicos

l          Constructores de átomos

l          Constructores de tuplas

l          Constructores de Conjuntos

Compatibilidad con Lenguajes de Programación

ü    Extender otros lenguajes de manejo de datos como SQL para que manejen tipos de datos complejos y la programación orientada a objetos

ü    Extender lenguajes de programación Orientada a Objetos para que trabajen con bases de datos

Manejo de Objetos Complejos

Ø    Ofrecer a la aplicación una porción del objeto antes de obtener el objeto completo

Ø    Usar técnicas de almacenamiento intermedio y caches para obtener anticipadamente porciones del objeto

Ventajas en BDOO

Ø    Esta su flexibilidad  y soporte para el manejo de tipos de datos complejos.

Ø    Manipula datos complejos en forma rápida y agilmente.

Desventajas de la BDOO

Ø    La inmadurez del mercado de BDOO constituye  una posible fuente de problemas por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar una línea de producción sustantiva.

Ø    Es la falta de estándar en la industria orientado a objetos.

Bibliografía:

Ø  Sistemas de bases de datos orientadas a objetos: Conceptos y arquitecturas. Editorial: Addison-Wesley / Diaz de Santos. Autores: Elisa Bertino, Lorenzo Martino.

Ø  Sistemas de bases de datos: Un enfoque práctico para diseño, implementación y gestión. 4ª Edición. Editorial: Pearson Addison- Wesley. Autores: Thomas M. Connolly, Carolyn E. Begg.

Ø  Fundamentos de Bases de datos. 5ª Edición. Editorial: McGraw Hill. Autores: Silberschatz, Korth, Sudarshan

INTEGRANTES

HÉCTOR JUÁREZ SANTIAGO
OMAR PASTOR GOINEZ