Documentos de Académico
Documentos de Profesional
Documentos de Cultura
IV SEMESTRE 402A
UNIDAD vi
JUNIO 2011
Contenido
INTRODUCCIN ...................................................................................................................................................... 3 UNIDAD 6 BASES DE DATOS RELACIONALES ORIENTADA A OBJETOS...................................................................... 4 6.1 RELACIONES ANIDADAS BASES DATOS ........................................................................................................................... 4 6.2 TIPOS COMPLEJOS. ........................................................................................................................................... 6 6.3 HERENCIA. ........................................................................................................................................................ 8 6.4 TIPOS DE REFERENCIA. ................................................................................................................................... 10 6.5 CONSULTAS CON TIPOS COMPLEJOS. .............................................................................................................. 11 6.6 COMPARACIN ENTRE LAS BASES DE DATOS ORIENTADAS A OBJETOS Y LAS BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS. ..................................................................................................................................... 13 CONCLUSIN ........................................................................................................................................................ 14 BIBLIOGRAFA ...................................................................................................................................................... 15
Introduccin
Los Sistemas de Bases de Datos Orientadas a Objetos soportan un modelo de objetos puro, en la medida de que no estn basados en extensiones de otros modelos ms clsicos como el relacional: Estn fuertemente influenciados por los lenguajes de programacin orientados a objetos Pueden verse como un intento de aadir la funcionalidad de un SGBD a un programacin. lenguaje de
Se basan en las relaciones (tablas bidimensionales) como nico medio para representar los datos del mundo real Lenguaje estndar SQL
Se han creado complejas teoras y patrones para encajar objetos o estructuras jerarquizadas en bases de datos relacionales.
Titulo
Lista-atores
Lista-palabra-clave
Puede verse que, si se define una relacin para la informacin anterior, varios de los dominios sern no atmicos. Autores. Un libro puede tener varios autores. No obstante, puede que se desee hallar todos los documentos entre cuyos autores estuviera Santos. Por tanto, hay inters en una parte del elemento del dominio conjunto de autores.
Palabras clave. Si se guarda un conjunto de palabras clave de cada documento se espera poder recuperar todos los documentos cuyas claves incluyan una o varias de las palabras clave especificadas. Editorial. A diferencia de palabras clave y autores, editorial no tiene un dominio de tipo conjunto. Sin embargo, se puede considerar que editorial consiste en los sub-campos nombre y sucursal. Esta manera de considerarlo hace que el dominio de editorial no sea atmico. Puede verse que, si se define una relacin para la informacin anterior, varios de los dominios sern no atmicos. Autores. Un libro puede tener varios autores. No obstante, puede que se desee hallar todos los documentos entre cuyos autores estuviera Santos. Por tanto, hay inters en una parte del elemento del dominio conjunto de autores. Palabras clave. Si se guarda un conjunto de palabras clave de cada documento se espera poder recuperar todos los documentos cuyas claves incluyan una o varias de las palabras clave especificadas. Editorial. A diferencia de palabras clave y autores, editorial no tiene un dominio de tipo conjunto. Sin embargo, se puede considerar que editorial consiste en los sub-campos nombre y sucursal. Esta manera de considerarlo hace que el dominio de editorial no sea atmico. Los atributos tienen dominio atmico El modelo relacional anidado es una extensin del modelo relacional en la que los dominios pueden ser atmicos o no. Por tanto el valor de las tuplas de los atributos puede ser una relacin, y las relaciones pueden guardarse en otras relaciones. Por tanto los objetos complejos se pueden representar mediante una nica tupla de las relaciones anidadas.
1. Relaciones Anidadas Ej: Considrese un sistema para la recuperacin de documentos en el que se guardan, por cada documento, la siguiente informacin: Ttulo del documento Lista de autores Fecha de obtencin Lista de palabras clave Puede verse que si se define una relacin para la informacin anterior, varios de los dominios no sern atmicos.
2. Relaciones Anidadas Autores: los documentos pueden tener varios autores. No obstante, puede que se desee hallar todos los documentos entre cuyos autores estuviera Santos. Por tanto, hay inters en una parte del elemento del dominio conjunto de autores. Palabras clave: si se guarda un conjunto de palabras clave de cada documento, se espera poder recuperar todos los documentos cuyas claves incluyan una o varias de las palabras clave especificadas. Por tanto, se considera que el dominio de lista-palabrasclave es no atmico.
En lenguajes de programacin un tipo de dato es un atributo de una parte de los datos que indica al ordenador (y/o al programador) algo sobre la clase de datos sobre los que se va a procesar. Esto incluye imponer restricciones en los datos, como qu valores pueden tomar y qu operaciones se pueden realizar. Tipos de datos comunes son: enteros, nmeros de coma flotante (decimales), cadenas alfanumricas, fechas, horas, colores, coches o cualquier cosa que se nos ocurra. Por ejemplo, en Java, el tipo "int" representa un conjunto de enteros de 32 bits cuyo rango va desde el 2.147.483.648 al 2.147.483.647, as como las operaciones que se pueden realizar con los enteros, como la suma, resta y multiplicacin. Los colores, por otra parte, se representan como tres bytes denotando la cantidad de rojo, verde y azul, y una cadena de caracteres representando el nombre del color; las operaciones permitidas incluyen la adicin y sustraccin, pero no la multiplicacin. ste es un concepto propio de la informtica, ms especficamente de los lenguajes de programacin, aunque tambin se encuentra relacionado con nociones similares de las matemticas y la lgica.
6.3 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 Supngase que se dispone de la siguiente definicin de tipos para las personas: Crate 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. crate type Estudiante under Persona (curso varchar(20), departamento varchar(20))
o o o o
Ayudante: heredara todos los atributos de Estudiante y de Profesor. 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: crate type Ayudante under Estudiante with(departamento as dep-estudiante) Profesor with(departamento as dep-profesor)
Como veis, la herencia se ve a simple vista. La clase invitado es una clase abstracta de la cual heredan tanto el representante, como el proveedor, cliente y trabajador. Para resolver la herencia a nivel de modelo relacional las cuatro tablas inferiores guardan foreign key contra invitado. Adems podris ver que en la tabla LINEA_CONVOCATORIA se tiene referencia a la tabla INVITADO, con esto hacemos algo similar a pasar a un mtodo por parmetro la clase abstracta, para que luego en tiempo de compilacin, y segn el objeto que se pase (y que obligatoriamente tendr que heredar de invitado), se actue en consecuencia. Problemas de esto? Mantener a base de datos puede ser como mnimo extrao. El campo CO_INVITADO de todas las tablas debera admitir NULL (por cierto hay una errata en el diagrama al respecto ya que como podis ver es NOT NULL, y por eso la carnalidad hacia INVITADO aparece siempre como 1, cuando debera ser 0.1. Adems, fijaros en el detalle de que la tabla INVITADO tiene un campo llamado TABLA. All almacenaramos el nombre de la tabla donde realmente est el invitado. Aqu es donde se pierde la historia y me deja de gustar el tema, pero es la nica manera que se me ocurri resolver de dnde sacar de dnde viene el invitado cuando empezamos a buscar a partir de la tabla LINEA_CONVOCATORIA, es decir, lo que sera en tiempo de compilacin que se te pasara un objeto INVITADO y resolver dependiendo de si el objeto es un proveedor, cliente
Esto solucin resulta como mnimo curiosa. Se os ocurre cmo mejorarla? Proponis alternativas? En el curso se dijo de resolver esto a nivel de Triggers, y dejarse de historias. A mi sinceramente, no me gustan los Triggers, pero eso no quiere decir que no sean la mejor forma de resolver este tipo de problemas.
Si se desea guardar en la base de datos ms informacin sobre las personas que sean estudiantes y sobre las que sean profesores, podemos utilizar la herencia para definir los tipos estudiante y profesor de la manera siguiente: create type Estudiante (curso MiCadena, departamento MiCadena) under Persona create type Profesor (sueldo integer, departamento MiCadena) under Persona El atributo de un tipo puede ser una referencia a un objeto de un tipo especificado. lista-autores setof(ref(Persona)) Las tuplas de las tablas tambin pueden tener referencias dirigidas a ellas. Se puede hacer referencia a las tuplas de las tablas utilizando la clave primaria de las mismas. De manera alternativa, cada tupla de una tabla puede tener un identificador de tuplas como atributo implcito y la referencia a la tupla ser sencillamente su identificador. Las sub-tablas heredan de manera implcita el atributo del identificador de las tuplas, igual que heredan de las sper tablas otros atributos.
10
Para referenciar los campos de los atributos complejos. 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. Atributos de tipo coleccin Ahora se considera la forma de manejar los atributos de tipo coleccin. Los arrays son el nico tipo coleccin soportado por SQL: Si se desea hallar todos los documentos que tienen las palabras base de datos entre sus palabras clave se puede utilizar la consulta siguiente: select ttulo from libros wherebase de datos in (unnest(lista-palabras-clave))
Obsrvese que se ha usado unnest (lista-palabras-clave) en una posicin en la que SQL sin relaciones anidadas habra exigido una sub-expresin select-from where. Si se sabe que un libro en particular tiene tres autores, se podra escribir: select array-autores [1], array-autores [2], array-autores [3] from libros where ttulo = Fundamentos de bases de datos
11
ANIDAMIENTO
DESANIDAMIENTO
La transformacin de una relacin anidada en una forma con menos (o sin) atributos de tipo relacin se denomina desmandamiento. El proceso inverso de transformar una relacin 1FN en una relacin anidada se denomina anidamiento. El anidamiento puede realizarse mediante una extensin de la agrupacin en SQL La consulta siguiente anida la relacin en el atributo palabra-clave: 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
Si se desea anidar tambin el atributo autor y volver a convertir, por tanto, la tabla libros-planos, en 1FN. se puede utilizar la consulta siguiente:
Select ttulo, set(autor) as array-autores, Editorial (nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave From libros-planos Group by ttulo, editorial
Los sistemas de tipos complejos y la programacin orientada a objeto permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multivariados y la generalizacin y la especializacin, se representen directamente sin que haga falta una compleja traduccin al modelo relacional.
12
Los puntos fuertes de los varios 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. Muchos sistemas de bases de datos relacionales orientados a objetos se construyen sobre bases de datos relacionales existentes. Para ello, los tipos de datos complejos soportados por los sistemas relacionales orientados a objetos necesitan traducirse al sistema de tipos ms sencillo de las bases de datos relacionales. Para comprender como se realiza la traduccin solo es necesario examinar la forma en que algunas caractersticas del modelo E-R se traducen en relaciones. Por ejemplo, los atributos multivariados del modelo E-R se corresponden con los atributos de tipo conjunto del modelo relacional orientado a objetos. Los atributos compuestos se corresponden modo con los tipos estructurados. Las jerarquas ES del modelo E-R se corresponden con la herencia de tablas en el modelo relacional orientado a objetos.
13
Conclusin
Las bases de datos orientadas a objetos estn diseadas para simplificar la programacin orientada a objetos. Almacenan los objetos directamente en la base de datos, y emplean las mismas estructuras y relaciones que los lenguajes de programacin orientada a objetos. Las bases de datos orientadas a objetos unen dos tecnologas: La de las bases de datos y la de los lenguajes orientados a objetos. Los puntos fuertes de los varios 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.
14
Bibliografa
http://www.softwarelibre.net/ http://informatica.uv.es/iiguia/DBD/Practicas/boletin_1.pdf
15