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