BASE DE DATOS ORIENTADA A OBJETOS

UNIDAD 7

BASE DE DATOS ORIENTADA A OBJETOS

7.1 VISIÓN GENERAL

El modelo de datos relacional orientado a objetos extiende el modelo de datos relacional ofreciendo un sistema de tipos más rico que incluye tipos de datos complejos y orientación a objetos. Hay que extender de manera acorde los lenguajes de consulta relacionales, en especial SQL, para que puedan trabajar con este sistema de tipos más rico. Los sistemas de Bases de Datos Relacionales basadas en objetos, es decir, los sistemas de Bases de Datos basados en el modelo Objeto-Relación, ofreces un medio de migración cómodo para los usuarios de las Bases de Datos Relacionales que deseen usar características Orientadas a Objetos. Un obstáculo es la dificultad de acceso a los datos de la Base de Datos desde los programas escritos en lenguajes de programación como C++ o JAVA. La mera extensión de sistema de tipos soportado por las bases de datos no resulta suficiente para resolver completamente este problema. Tener que expresar el acceso a la Base de Datos mediante un lenguaje (SQL) que es diferente del lenguaje de programación también hace más difícil el trabajo del programador. El termino sistemas de Base de Datos Orientadas a Objetos se usa para hacer referencia a los sistemas de Bases de Datos que soportan sistemas de tipos Orientados a objetos y permiten el acceso directo a los datos desde los lenguajes de programación orientados a objetos usando el sistema de tipos nativo del lenguaje.

7.2 TIPOS DE DATOS COMPLEJOS

Las aplicaciones de Bases de Datos tradicionales consisten en tareas de procedimientos de datos, tales como la banca y la gestión de nominas. Dichas aplicaciones presentan conceptualmente tipos de datos simples. Los elementos de datos básicos son registros bastante pequeños y cuyos campos son atómicos, es decir, no contienen estructuras adicionales y en los que se cumple la Primera Forma Normal. Como ejemplo, 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. La alternativa de la normalización mediante la creación de una nueva relación resulta costosa y artificial para este ejemplo. 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

Antes de SQL: 1999 el sistema de tipos de SQL consistía en un conjunto bastante sencillo de tipos predefinidos. SQL: 1999 añadió un sistema de tipos extenso a SQL, lo que permite los tipos estructurados y la herencia de tipos.

Titulo Array_autores Editor Conjunto_palabras_clave

(nombre, sucursal)

Compiladores

Redes [Gómez, Santos]

[Santos, Escudero] (McGraw, Nueva York)

(Oxford, Londres) {Análisis sintáctico, análisis}

{internet, web}

Relación de libros que no están en la 1FN, libros.

Titulo Autor Posición

Compiladores

Compiladores

Redes

Redes Gomes

Santos

Santos

Escudero 1

2

1

2

Autores

Titulo Palabra_Clave

Compiladores

Compiladores

Redes

Redes Análisis sintáctico

Análisis

Internet

Web

Palabras_Clave

Titulo Nombre_Editor Sucursal_Editor

Compiladores

Redes McGraw-Hill

Oxford Nueva York

Londres

Libros4

Versión en la 4FN de la relación libros

7.4 HERENCIA DE TABLAS.

Las tablas de SQL se corresponden con el concepto de especialización general de E-R. Por ejemplo, supóngase que se define la tabla personas de la manera siguiente:

create table personas of persona

A continuación no 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 personas 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 o en profesores pasan a estar también presentes de manera implícita en personas. Por tanto, si una consulta usa la tabla personas, no solo encuentra tuplas directamente insertadas en esa tabla, si no también tuplas insertadas en sus subtablas, es decir, estudiante y profesores.

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 súper tabla, 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

borrara todas las tuplas de las tablas personas, así como de sus subtablas estudiantes y profesores, que satisfagan P.

Teóricamente, la herencia múltiple es posible con las tablas, igual que con los tipos. Por ejemplo, se puede crear una tabla del tipo Profesor Ayudante:

create table profesores_ayudantes

of Profesor ayudante

under estudiantes, profesores

Como secuencia de la declaración, todas las duplas presentes en la tabla profesores_Ayudantes también se hallan presentes de manera implícita en las tablas profesores y estudiantes

...