Josu Olivera Hernndez 10 de junio de 2011

INSTITUTO Tecnolgico SUPERIOR Jess DE CARRANZA

ING. SISTEMA COMPUTACIONALES

ING. Idalicio herir Calixto

Josu olivera Hernndez

IV SEMESTRE 402A

UNIDAD vi

Fundamentos de base de datos

JESUS CARRANZA, VER.

JUNIO 2011

Josu Olivera Hernndez 10 de junio de 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

Josu Olivera Hernndez 10 de junio de 2011

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.

Josu Olivera Hernndez 10 de junio de 2011

Unidad 6 Bases de datos relacionales orientada a objetos

6.1 Relaciones Anidadas Bases Datos
El modelo relacional anidado es una extensin del modelo relacional en la que los dominios pueden ser atmicos o de relacin. Por tanto, el valor de las tuplas de los atributos puede ser una relacin, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una nica tupla de las relaciones anidadas. Si se consideran las tuplas de las relaciones anidadas como elementos de datos, se tiene una correspondencia uno a uno entre los elementos de datos y los objetos de la vista de la base de datos del usuario. Un dominio: Es atmico si los elementos del mismo se consideran unidades indivisibles. Las relaciones anidadas se ilustran mediante Un ejemplo extrado de una biblioteca. Considrese que para cada libro se almacena la informacin siguiente: Ttulo del libro Lista de autores Editorial Lista de palabras clave

Titulo

Lista-atores

Fecha (Dia,mes,ao) 1-abril-89 17-junio-94

Lista-palabra-clave

Plan de ventas Informe de situacin

Gmez ,santo Santo, Escudero

Beneficio, estrategia Beneficio, personal

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.

Josu Olivera Hernndez 10 de junio de 2011

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.

Josu Olivera Hernndez 10 de junio de 2011

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.

6.2 TIPOS COMPLEJOS.

La definicin de dato, los diferentes tipos de datos desde simples caracteres y nmeros hasta colecciones y cmo definir un tipo de datos propio. Dato es uno de esos trminos que todos usan pero pocos entienden. Mi diccionario lo define como: Dato: "hecho o valor a partir del cual se puede inferir una conclusin; informacin" Los datos son aquello que un programa manipula. Sin datos un programa no funcionara correctamente. Los programas manipulan datos de manera muy diferente segn el tipo de dato del que se trate. Las relaciones anidadas son slo un ejemplo de las extensiones del modelo relacional bsico. Otros tipos de datos no atmicos, como los registros anidados, tambin se han mostrado tiles. El modelo de datos orientado a objetos ha creado la necesidad de caractersticas como la herencia y las referencias a los objetos. Los sistemas de tipos complejos y la programacin orientada a objetos permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multi-valorados y la generalizacin y la especializacin. Se representen directamente sin que haga falta una compleja traduccin al modelo relacional. Una base de datos hay muchos objetos similares. Por similar se entiende que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y del mismo tipo. Sera un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos parecidos se agrupan para formar una clase. Cada uno de estos objetos se denomina ejemplar de su clase. Todos los objetos de una clase comparten una definicin comn, posee a que se diferencien en los valores asignados a las variables.

Josu Olivera Hernndez 10 de junio de 2011 Tipos de datos

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.

Josu Olivera Hernndez 10 de junio de 2011

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

crate type Profesor under Persona (sueldo integer, departamento varchar(20))

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.

Josu Olivera Hernndez 10 de junio de 2011

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

Josu Olivera Hernndez 10 de junio de 2011

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.

6.4 TIPOS DE REFERENCIA.

Puede hallarse en el nivel de los tipos o en el nivel de las tablas. La Herencia de los Tipos. create type Persona (nombre MiCadena, dni integer)

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

Josu Olivera Hernndez 10 de junio de 2011

6.5 CONSULTAS CON TIPOS COMPLEJOS.

Notacin con un punto select titulo,fecha.ao from doc

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

Josu Olivera Hernndez 10 de junio de 2011

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

Josu Olivera Hernndez 10 de junio de 2011

6.6 COMPARACIN ENTRE LAS BASES DE DATOS ORIENTADAS A OBJETOS Y LAS

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS.
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 proporcionan 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 relativamente sencillas. Los sistemas relacionales orientados a objetos 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.

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

Josu Olivera Hernndez 10 de junio de 2011

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

Josu Olivera Hernndez 10 de junio de 2011

Bibliografa
http://www.softwarelibre.net/ http://informatica.uv.es/iiguia/DBD/Practicas/boletin_1.pdf

http://es.wikipedia.org/wiki/Base_de_datos_objeto-relaciona http://html.rincondelvago.com/base-de-datos-relacional.html http://edinunez.wordpress.com/2008/05/07/base-de-datos-orientado-a-objetos/ http://foros.softonic.com/programacion/bases-datos-orientados-objetos-53754

15