Vous êtes sur la page 1sur 28

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

Snchez Manuel Ortiz Eduardo Garca Wagner Estevez Jose Felix Pabn Lissette Addas Amado Estvez Jos Flix

INTRODUCCION

Las bases de datos orientadas a objetos (BDOO) son aquellas cuyo modelo de datos est orientado a objetos , almacenan y recuperan objetos en los que se almacena estado y comportamiento. Los modelos de datos relacionales orientados a objetos extienden el modelo de datos relacional.

Relaciones anidadas
El modelo relacional anidado es una extension del modelo relacional en la que los dominios pueden ser atomicos o de relacion.

Un dominio es atmico si los elementos del mismo se consideran unidades indivisibles.

Tipos de Referencia
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. create type Departamento( nombre varchar(20), director ref(Persona) scope persona )

TIPOS COMPLEJOS
Las Bases de Datos relacionales Orientadas a Objetos facilitan el manejo de tipos de datos complejos. Dentro de lo que llamamos tipos de datos complejos podemos definir los siguientes:

Colecciones

Objetos de gran tamao(LOB)

Tipos Estructurados

Constructores

COLECCIONES
Los conjuntos son ejemplares de los tipos coleccin. 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 declaracin de un array:

array-autores varchar(20) array [10]

OBJETOS DE GRAN TAMAO (LOB)

Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (KB, MB,GB). Las BD relacionales orientadas a objetos permiten utilizar clobs y blobs. Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL.

TIPOS ESTRUCTURADOS

Los tipos estructurados permiten la representacin directa de atributos compuestos de los diagramas E-R. Un tipo estructurado puede tener mtodos definidos sobre el. Los mtodos se declaran como parte de la definicin de tipos de un tipo estructurado.

CONSTRUCTORES
De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predenidos. Cualquiera otra funcin constructora tiene que crearse explcitamente. Puede haber mas de una constructora para el mismo tipo estructurado; aunque tengan el mismo nombre, solo tienen que ser distinguibles por el nmero de argumentos y sus tipos.

HERENCIA

La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerar la herencia de los tipos y despus en el nivel de las tablas. Herencia de tipos Herencia de tablas

HERENCIA DE TIPOS
Supngase que se dispone de la siguiente definicin de tipos para las personas: create type Persona (nombre varchar(20), direccin varchar(20)) Puede que se desee guardar en la base de datos ms informacin sobre las personas que sean estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores tambin son personas, se puede utilizar la herencia para definir los tipos estudiante y profesor en SQL:1999: create type Estudiante under Persona (curso varchar(20), departamento varchar(20))

HERENCIA DE TIPOS

create type Profesor under Persona (sueldo integer, departamento varchar(20)) Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y direccin. Estudiante y Profesor se denominan subtipos de Persona y sta, a su vez, es un supertipo de Estudiante y de Profesor.

HERENCIA DE TIPOS
Supngase ahora que se desea guardar la informacin sobre los ayudantes, que son simultneamente estudiantes y profesores, quizs incluso en departamentos diferentes. Esto se puede hacer usando la herencia mltiple. Si el sistema de tipos permite la herencia mltiple, se puede definir un tipo para los ayudantes de la manera siguiente:

create type Ayudante under Estudiante, Profesor


Ayudante heredara todos los atributos de Estudiante y de Profesor. Pero surge un problema, sin embargo, dado que los atributos nombre, direccin y departamento se hallan presentes en Estudiante y en Profesor.

HERENCIA DE TIPOS
Los atributos nombre y direccin se heredan en realidad de un origen comn, Persona. As que no se provoca ningn conflicto al heredarlos de Estudiante y de Profesor. Sin embargo, el atributo departamento se define de manera separada en Estudiante y en Profesor. De hecho, los ayudantes pueden ser estudiantes de un departamento y profesores de otro. Para evitar un conflicto entre los dos ejemplares de departamento se les puede cambiar el nombre utilizando una instruccin as como se muestra en la siguiente definicin del tipo Ayudante: create type Ayudante under Estudiante with (departamento as dep-estudiante) Profesor with (departamento as dep-profesor)

HERENCIA DE TABLAS
Corresponde a la nocin del modelo E-R de la especializacin y la generalizacin. Por ejemplo, supngase 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 tambin presente en las subtablas. Adems, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla presente en estudiantes o profesores tambin estn presentes implcitamente en persona.

HERENCIA DE TABLAS

Es posible la herencia mltiple con las tablas, como con los tipos. Por ejemplo, se puede crear una tabla del tipo Ayudante: create table ayudantes of Ayudante under estudiantes, profesores Como resultado de la declaracin, cada tupla presente en la tabla ayudantes tambin est presente implcitamente en las tablas profesores y estudiantes, y a su vez en la tabla persona.

CONSULTAS CON TIPOS COMPLEJOS


select ttulo, editorial.nombre from libros

Consultas con tipos complejos


select director>nombre, director>direccin from departamentos

Atributos de tipo coleccin


select ttulo from libros where base de datos in (unnest(lista-palabrasclave))

CONSULTAS CON TIPOS COMPLEJOS


Atributos de tipo coleccin
select array-autores[1], array-autores[2], array-autores[3] from libros where ttulo = Fundamentos de bases de datos
select B.ttulo, A from libros as B, unnest(B.array-autores) as A

Anidamiento y desanidamiento
select ttulo, A as autor, editorial.nombre as nombre-edit, editorial.sucursal as sucursal.edit, K as palabra-clave from libros as B, unnest(B.array-autores) as A, unnest(B.lista-palabras-clave) as K

CONSULTAS CON TIPOS COMPLEJOS


Anidamiento y desanidamiento
select ttulo, autor, Editorial(nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave from libros-planos Group by ttulo, autor, editorial select ttulo, set(autor) as array-autores, Editorial (nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave from libros-planos groupby ttulo, editorial

CONSULTAS CON TIPOS COMPLEJOS


select ttulo, (select autor from libros-planos as M where M.ttulo = O.ttulo) as lista-autores, Editorial(nombre-edit, sucursal-edit) as editorial, (select palabra-clave from libros-planos as N where N.ttulo = O.ttulo) as lista-palabras-clave, from libros-planos as O

PROCEDIMIENTOS Y FUNCIONES
Procedimiento-Una serie de declaraciones de aceptar y / o devolver cero o ms variables.

Funcin-Una serie de estados que aceptan cero o ms variables que devuelve un valor.

EJEMPLO DE STORED PROCEDURE

Ejemplo de Funciones

Ejecucin de SP

Ejecucin de funcin

Comparacin entre BDOO y BDROO


Ambos tipos se encuentran en el mercado, y los diseadores de bases de datos deben escoger el tipo de sistemas que resulte ms adecuado para las necesidades de la aplicacin.
Las extensiones persistentes de los lenguajes de programacin y los sistemas relacionales orientados a objetos se han dirigido a mercados diferentes. La naturaleza declarativa y la limitada potencia (comparada con la de los lenguajes de programacin) del lenguaje SQL proporciona una buena proteccin de los datos respecto de los errores de programacin y hace que las optimizaciones de alto nivel, como la reduccin de E/S, resulten sencilla.

COMPARACIN ENTRE BDOO Y BDROO


Los lenguajes de programacin persistentes se dirigen a las aplicaciones que se ejecutan en memoria principal y que realizan un gran nmero de accesos a la BD, y que requieren elevados rendimientos. Proporcionan acceso alos datos persistentes con poca sobrecarga y eliminan la necesidad de la traduccin de los datos si hay que tratarlos utilizando un lenguaje de programacin.
En cambio son mas susceptibles de deteriorar los datos debido a los errores de programacin y no suelen disponer de grandes posibilidades de consulta.

Comparacion entre BDOO y BDROO


Los Sistemas Relacionales Orientados a Objetos (SROO) se dirigen a la simplificacin de la realizacin de los modelos de datos y de las consultas mediante el uso de tipos de datos complejos. Las aplicaciones tpicas incluyen el almacenamiento y la consulta de datos complejos, incluyendo los datos multimedia. Los lenguajes declarativos como SQL, imponen una reduccin significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan en la memoria principal y realizan gran nmero de accesos a la base de datos.

Comparacin entre BDOO y BDROO


Los puntos fuertes de los distintos tipos de sistemas de bases de datos pueden resumirse de la manera siguiente: Sistemas relacionales: Tipos de datos sencillos, lenguajes de consulta potentes, proteccin elevada. Bases de datos orientadas a objetos basadas en lenguajes de programacin persistentes: Tipos de datos complejos, integracin con los lenguajes de programacin, elevado rendimiento. Sistemas relacionales orientados a objetos: Tipos de datos complejos, lenguajes de consulta potentes, proteccin elevada.

Vous aimerez peut-être aussi