apuntestema02

42
Bases de datos y sistemas de información 2-1 Contenido: 2. Modelos de bases de datos 2.1. Modelo entidad-relación 2.1.1. Conceptos 2.1.2. Diagramas entidad relación 2.1.3. Cuestiones de diseño 2.1.4. Restricciones 2.1.5. Diagramas entidad relación extendidos (EER) 2.1.6. Conclusiones 2.2. Modelo relacional 2.2.1. Terminología del modelo relacional 2.2.2. Paso del modelo ER al modelo relacional 2.2.3. Lenguajes formales del modelo relacional 2.3. Modelo de orientación a objetos 2.3.1. Modelo de datos orientado a objetos 2.3.2. Modelo de datos relacional orientado a objetos Bibliografía 2. Modelos de bases de datos 2.1. Modelo entidad-relación En este apartado se estudia un modelo de datos de alto nivel que nos permite diseñar el esquema conceptual de una BD. El modelo entidad-relación se incluye a veces entre los modelos orientados a objetos por lo noción de distinguibilidad de entidades (similar a la identidad de objetos). Se basa en los conceptos de: entidad, tipo de entidad, atributo y relación. Toda esta información se representará en los diagramas entidad-relación. 2.1.1. Conceptos Entidad: Def.: Menor objeto con significado en una instancia. Por Ej.:, para el análisis de la BD secretaría, el alumno con los siguientes datos: DNI = 01234567Z, nombre y apellidos = Manuel Vázquez Prieto, Teléfono = 91-12345678 domicilio = Calle del Jazmín 7, 4 Izq. COU = SI constituye una entidad. Igual sucede con cada asignatura concreta, cada profesor, etc. Intuición: En el caso del enfoque “clásico” correspondería a cada registro guardado en un fichero. Atributo: Def.: Componentes que determinan una entidad. Cada atributo tiene asociado un dominio: Conjunto de valores que puede tomar. Ej.: La entidad del Ej.: anterior viene determinada por los valores de sus atributos DNI, Nombre y Apellidos, Teléfono, Domicilio y COU. Notación: A veces, las entidades se representan como conjuntos de la forma {atrib1=v1,...atribn=vn} donde cada atributo de la entidad aparece una y sólo una vez. Ej.: {DNI=01234567Z, nombre y apellidos = Manuel Vázquez Prieto, Teléfono = 91- 12345678 , domicilio = Calle del Jazmín 7, 4 Izq, COU = SI} Intuición: En el enfoque clásico serían los campos de los registros. Atributos monovalorados y multivalorados:

description

apuntes

Transcript of apuntestema02

  • Bases de datos y sistemas de informacin

    2-1

    Contenido: 2. Modelos de bases de datos

    2.1. Modelo entidad-relacin 2.1.1. Conceptos 2.1.2. Diagramas entidad relacin 2.1.3. Cuestiones de diseo 2.1.4. Restricciones 2.1.5. Diagramas entidad relacin extendidos (EER) 2.1.6. Conclusiones

    2.2. Modelo relacional 2.2.1. Terminologa del modelo relacional 2.2.2. Paso del modelo ER al modelo relacional 2.2.3. Lenguajes formales del modelo relacional

    2.3. Modelo de orientacin a objetos 2.3.1. Modelo de datos orientado a objetos 2.3.2. Modelo de datos relacional orientado a objetos

    Bibliografa

    2. Modelos de bases de datos

    2.1. Modelo entidad-relacin En este apartado se estudia un modelo de datos de alto nivel que nos permite disear el esquema conceptual de una BD. El modelo entidad-relacin se incluye a veces entre los modelos orientados a objetos por lo nocin de distinguibilidad de entidades (similar a la identidad de objetos). Se basa en los conceptos de: entidad, tipo de entidad, atributo y relacin. Toda esta informacin se representar en los diagramas entidad-relacin.

    2.1.1. Conceptos Entidad:

    Def.: Menor objeto con significado en una instancia. Por Ej.:, para el anlisis de la BD secretara, el alumno con los siguientes datos: DNI = 01234567Z, nombre y apellidos = Manuel Vzquez Prieto, Telfono = 91-12345678 domicilio = Calle del Jazmn 7, 4 Izq. COU = SI constituye una entidad. Igual sucede con cada asignatura concreta, cada profesor, etc. Intuicin: En el caso del enfoque clsico correspondera a cada registro guardado en un fichero.

    Atributo: Def.: Componentes que determinan una entidad. Cada atributo tiene asociado un dominio: Conjunto de valores que puede tomar. Ej.: La entidad del Ej.: anterior viene determinada por los valores de sus atributos DNI, Nombre y Apellidos, Telfono, Domicilio y COU. Notacin: A veces, las entidades se representan como conjuntos de la forma {atrib1=v1,...atribn=vn} donde cada atributo de la entidad aparece una y slo una vez. Ej.: {DNI=01234567Z, nombre y apellidos = Manuel Vzquez Prieto, Telfono = 91-12345678 , domicilio = Calle del Jazmn 7, 4 Izq, COU = SI} Intuicin: En el enfoque clsico seran los campos de los registros.

    Atributos monovalorados y multivalorados:

  • Bases de datos y sistemas de informacin

    2-2

    Def.: Se llaman atributos multivalorados a aquellos que pueden contener ms de un valor simultneamente, y monovalorados a los que slo pueden contener un valor. Ej.: Una persona puede tener varios nmeros de telfono (casa, trabajo, mvil) y puede que nos interese tenerlos todos. En este caso haremos de telfono un atributo multivalorado.

    Atributos simples y compuestos: Def.: Se dice que un atributo es compuesto cuando puede descomponerse en otros componentes o atributos ms pequeos, y simple en otro caso. Ej.: En el caso del domicilio puede que nos interese descomponerlo a su vez en calle, el nmero y la ciudad por separado.

    Clave: Def: Atributo o conjunto de atributos cuyos valores identifican unvocamente cada entidad. Ej.: DNI es un atributo clave de la entidad Alumno.

    Tipo de entidad: Es el conjunto de entidades que comparten los mismos atributos (aunque con diferentes valores para ellos). Ej.: En nuestro caso Alumnos ser un tipo de entidad que representa cualquier multiconjunto de entidades en el que todas tengan como conjunto de atributos {DNI, Nombre y Apellidos, ...} y valores dentro de los dominios correspondientes. Asignaturas ser otro tipo de entidad, etc. Intuicin: En el enfoque clsico sera el tipo de los registros. Estamos describiendo el esquema.

    Relaciones: Def: Conjuntos de la forma {(e1, ..., en) | e1 E1, e2 E2, ..., en En} con ei entidades y Ei conjuntos de entidades del mismo tipo. Ej.: Sea {a1, a2, a3, a4} un conjunto de entidades de tipo alumno (i.e. alumnos concretos) y {b1,b2,b3} 3 asignaturas concretas. Una posible relacin: {(e1,b1), (e2,b1), (e1,b2) } diciendo que e1 est matriculado tanto en b1 como en b2 y e2 en b1.

    Tipos de relacin: Representan a todas las posibles relaciones entre conjuntos del mismo tipo. Se identifican mediante los tipos de entidades que relacionan (y los atributos si tienen). Es el producto cartesiano E1xE2x...xEn, siendo Ei conjuntos de entidades. Ej.: El tipo de relacin matrcula relaciona el tipo de entidad alumnos con el tipo de entidad asignaturas. Observacin: Las relaciones tambin pueden tener atributos. Cuando un mismo tipo de entidad aparece 2 o ms veces en un tipo de relacin se asigna un nombre a cada papel que hace el tipo de entidad en el tipo de relacin. Ej.: En el Ej.: de secretara, algunos profesores tienen un supervisor, por lo que definiremos un tipo de relacin supervisa que va de profesores a profesores, el primero (por Ej.:) tendr el papel de supervisor y el segundo de supervisado.

    Jerarquas Isa: Def: Se dice A isa B si el conjunto de entidades B es una generalizacin del conjunto de entidades A. attrib(B)attrib(A). A hereda de B (en el mismo sentido de la programacin orientada a objetos).

    Atributos clave prestados (borrowed key attributes) En una jerarqua Isa A isa B, los atributos clave de A pueden serlo tambin de B.

    2.1.1.1. Notacin: En el diseo del modelo E-R se describen tipos (de entidades y de relaciones). Cada tipo representa a un conjunto (de multiconjuntos de entidades o de relaciones). Sin embargo, a menudo diremos cosas del estilo: a) sea R un tipo de relacin y (a1,a2) R Esto es un abuso de notacin que se puede traducir como:

  • Bases de datos y sistemas de informacin

    2-3

    b) sea R un tipo de relacin, r una relacin de tipo R cualquiera y (a1,a2) ) r. Sin embargo utilizaremos la notacin a) porque est claro en que caso R representa un tipo o una relacin cualquiera del tipo.

    2.1.1.2. Observaciones: El diseo del modelo E-R a partir del anlisis inicial NO es directo. A un mismo anlisis le corresponden muchos diseos candidatos. Cul escoger? Muchos criterios, ninguno definitivo. De un buen diseo depende: - eficiencia: Muy importante en las BD (grandes cantidades de datos). - simplicidad del cdigo: Menos errores - flexibilidad: Fcil de modificar

    2.1.2. Diagramas entidad relacin Los componentes bsicos de los diagramas ER son los atributos, los tipos de entidades y los tipos de relaciones. Tipos de entidades: Rectngulos. Atributos: Elipses. Se conectan mediante lneas a los tipos de entidades o tipos de relacin. Atributos multivalorados: Una elipse con doble lnea: Atributos compuestos. Los componentes de un atributo se representan a su vez como

    atributos: Tipos de Relacin: Rombos conectados a los tipos de entidades que relacionan.

    Asignaturas

    Telfono

    Alumnos

    Matricula

    Alumnos

    Asignaturas

    Telfono

    Calle Nmero Ciudad

    Domicilio

  • Bases de datos y sistemas de informacin

    2-4

    2.1.3. Cuestiones de diseo Pasos en el diseo de un diagrama E-R: 1. Eleccin de los tipos de entidad y sus atributos. 2. Eleccin de los tipos de relacin.

    2.1.3.1. Eleccin de los tipos de entidad y sus atributos Del punto 1) de la especificacin del problema de la secretara se deduce que va ha haber un tipo de entidad alumnos, pero no cules son sus atributos: Debe incluir las asignaturas en las que est matriculado? La respuesta es NO y hacerlo as sera un error grave. Aparte de la idea filosfica (cada asignatura es un objeto con significado propio, es decir, una entidad), al mezclar en una sola entidad alumnos y asignaturas cometemos 4 errores: 1. Un alumno no tiene una asignatura asociada sino un conjunto de asignaturas asociadas. En

    cambio, s tiene un DNI asociado, una direccin asociada, etc. Por tanto las entidades sern de la forma {DNI=12345678V, Nomb.Ape=Luis Martnez, Telf.=01234567, Cod=MD, Ttulo=Matemtica Discreta, Crditos=9} {DNI=12345678V, Nomb.Ape=Luis Martnez, Telf.=01234567, Cod=IS, Ttulo=Ingeniera del Software, Crditos=X} {DNI=12345678V, Nomb.Ape=Luis Martnez, Telf.=01234567, Cod=LPI, Ttulo=Laboratorio de programacin I, Crditos=X} Redundancia! (inf. De alumnos repetida) Esto se puede solucionar si admitimos que los atributos contengan conjuntos de valores { DNI=12345678V, Nomb.Ape=Luis Martnez, Telf.=01234567, , Asignaturas={ {Cod=MD, Ttulo=}, {COD=IS,Ttulo=}, {Cod=LPI,Ttulo=} } } ( no es muy elegante que digamos y los siguientes 3 puntos no se pueden arreglar as)

    2. Las asignaturas son siempre las mismas, con lo que por cada alumno que se matricula en la

    misma asignatura hay que repetir toda la informacin: { DNI=12345678V, Nomb.Ape=Luis Martnez, Telf.=01234567, , Asignaturas={ {Cod=MD, Ttulo=}, {COD=IS,Ttulo=}, {Cod=LPI,Ttulo=} } } { DNI=0000001, Nomb.Ape=Eva Manzano, Telf.=01234567, , Asignaturas={ {Cod=MD, Ttulo=}, {COD=IS,Ttulo=}, {Cod=BDSI,Ttulo=} } } Redundancia! (en la inf. de las asignaturas).

    3. Por cada profesor hay que apuntar las asignaturas que imparte. La informacin de las

    asignaturas debe estar por tanto relacionada con la de los profesores, pero ya est incluida con los alumnos. Hay que repetir la informacin de las asignaturas ms redundancia.

    4. No se pueden guardar los datos de una asignatura hasta que no se matricule un alumno en

    ella. Puede ser que en secretara quieran meter los datos de las asignaturas antes de empezar el proceso de matrcula: No pueden. Una solucin sera incluirlos con los datos de los alumnos vacos (nulos). Chapuza!

    Por tanto hay que distinguir entre el tipo de entidad alumnos y el tipo de entidad asignaturas. Ambas se relacionarn mediante un tipo de relacin matrcula. Los restantes tipos de entidad sern: profesores y aulas. Los atributos de cada tipo de entidad: Alumnos: DNI, Apellidos y Nombre, Domicilio, telfono y COU Asignaturas: Cdigo, ttulo, nm. crditos

  • Bases de datos y sistemas de informacin

    2-5

    Profesores: DNI, Apellidos y nombre, Domicilio y telfono Aulas: Edificio y nm. edificio An nos falta un atributo, que es la nota : Dnde la ponemos? En alumnos NO (un alumno muchas notas) En asignaturas NO (una asignatura mucho alumnos) Va a ser un atributo del tipo de relacin matrcula .

    2.1.3.2. Eleccin de los tipos de relacin El primer tipo de relacin es matrcula que relaciona cada alumno con las asignaturas en las que est matriculado. Adems, est relacin tiene un atributo, nota, que se asocia cada tupla de la relacin. El segundo tipo de relacin es supervisa que va de profesores a profesores y que incluye los papeles supervisor y supervisado. La ltima es imparte que relaciona cada profesor con la asignatura que imparte y el aula en la que da esa asignatura. Aqu tambin surgen varias posibilidades: Hacer 2 relaciones binarias. Por Ej.:, profesor con asignatura y asignatura con aula. Hacer una relacin ternaria entre profesores, aulas y asignaturas. Hacer 3 relaciones binarias profesor-asignatura, profesor-aula, asignatura-aula Diferencias: 1. En las opciones a) y c) se permite que un profesor imparta una asignatura que an no tiene

    aula (esto puede ser deseable o no). 2. El problema de a) es:

    Profesor-asignatura = { ({DNI=6666666, NombreYApe=Rmulo Meln},{Cod=MD,.}) } Asignatura-Aula = { ({Cod=MD.},{Edif=Mates, NumAula=S103}), ({Cod=MD.},{Edif=Biolgicas, NumAula=104}) }

    Estas relaciones son posibles, hay ms de un curso de primero y por eso la misma asignatura se imparte en varias aulas. Ahora bien, Don Rmulo quiere saber en qu aula debe dar su clase de discreta, y pare ello pregunta en secretara. Qu se le contesta? Sin embargo, con la propuesta b) s se le puede asignar a cada profesor un aula concreta para cada una de sus asignaturas. El problema de c) sigue siendo el mismo: Profesor-asignatura = { ({DNI=6666666, NombreYApe=Rmulo Meln,},{Cod=MD,.}), ({DNI=6666666, NombreYApe=Rmulo Meln,},{Cod=IS,.}),} Asignatura-Aula = { ({Cod=MD.}, {Edif=Mates, NumAula=S103}), ({Cod=MD.}, {Edif=Biolgicas, NumAula=104}), ({Cod=IS.}, {Edif=Mates, NumAula=S103}), ({Cod=IS.}, {Edif=Biolgicas, NumAula=104}) } Profesor-Aula = { ({DNI=6666666, NombreYApe=Rmulo Meln,}, {Edif=Mates, NumAula=S103}), ({DNI=6666666, NombreYApe=Rmulo Meln,}, {Edif=Biolgicas, NumAula=104}), } Don Rmulo sabe que da 2 asignaturas, cada una en un aula, pero sigue sin saber a dnde tiene que ir a dar MD. Conclusin: Una relacin ternaria tiene en general ms informacin que 3 binarias.

  • Bases de datos y sistemas de informacin

    2-6

    AsignaturasAlumnos Matrcula

    Aulas Imparte

    Supervisa

    Profesores

    Apellidos y Nombre Domicilio Telfono

    Apell. y Nombre Telfono COU Cdigo TtuloNm.Crditos

    Edificio Nmero

    Nota

    DNI

    DNI

    SupervisadoSupervisor

    Calle Nmero Ciudad

    Domicilio

    2.1.4. Restricciones Con los elementos anteriores tenemos una primera aproximacin a los diagramas ER, en la que tenemos definidos los elementos principales de los diagramas. Sin embargo, en el modelo ER tambin se pueden definir numerosas restricciones sobre los tipos de entidades y tipos de relaciones. Ej.: En la relacin supervisa un profesor puede tener a lo sumo un supervisor, pero el diagrama anterior permite SUPERVISOR SUPERVISADO ({DNI=666666,}, {DNI=444444,}) ({DNI=000001,}, {DNI=444444,}) Que no debera ser una instancia vlida de la relacin. Def: Las restricciones son propiedades que se asocian a un tipo de entidad o de relacin. Las instancias vlidas del tipo de entidad o relacin son aquellas en las que se verifique el conjunto de restricciones asociadas. Observaciones: Las restricciones son parte del diseo de la BD igual que los tipos de entidades o de relaciones. Los SGBD se encargan de comprobar que la instancia verifica las restricciones ms usuales.

  • Bases de datos y sistemas de informacin

    2-7

    Ej.: En el caso anterior, una vez incluida la restriccin, el SGBD no nos permitira insertar la segunda tupla.

    2.1.4.1. Cardinalidad de un tipo de relacin ::REVISAR CARDINALIDADES Y PARTICIPACIONES:: Def: Cardinalidad de una entidad en una relacin (nivel de instancias) Sea r una relacin entre tipos de entidades E1, E2, , Ek, entonces se dice que: El cardinal de Ei en r es n si dados e1E1, , ei-1Ei-1, ei+1Ei+1,ekek

    cualesquiera, se verifica que existen exactamente n ei Ei tales que: r.

    El cardinal de Ei en r es menor o igual que n si dados e1E1, , ei-1Ei-1, ei+1Ei+1,,enEk cualesquiera, se verifica que existen a lo sumo n ei Ei tales que: r

    Ej.: Consideremos la siguiente relacin (instancia) de tipo AxBxC: A B C A1 B1 C1 1 A1 B1 C2 2 A2 B2 C1 3 A2 B2 C2 4 A3 B1 C1 5 A3 B1 C2 6 Para A: (B1,C1): A1 (1), A3 (5) (B1,C2): A1 (2), A3 (6) (B2,C1): A2 (3) (B2,C2): A2 (4) Para B: (A1,C1): B1 (1) (A1,C2): B1 (2) (A2,C1): B2 (3) (A2,C2): B2 (4) (A3,C1): B1 (5) (A3,C2): B1 (6) Para C: (A1,B1): C1 (1), C2(2) (A2,B2): C1 (3), C2(4) (A3,B1): C1 (5), C2(6) Si asumimos que en la instancia de la BD se tiene A = {A1,A2,A3}, B={B1,B2}, C={C1,C2} El cardinal de A en esta instancia es

  • Bases de datos y sistemas de informacin

    2-8

    PasRPersonas Nacida

    Cada persona tiene un nico pas de nacimiento, es decir, fijada una persona, existe un pas, Por lo que parece lgico poner la restriccin =1 para el tipo de entidad pas en el tipo de relacin nacida. Sin embargo, fijado un pas hay una cantidad no determinada en general de personas nacidas all, por lo que no ponemos ninguna restriccin sobre el tipo de entidad personas.

    2. Fijado un alumno puede haberse matriculado en cualquier nmero de asignaturas no hay

    restriccin sobre asignatura en la relacin matrcula. Fijada una asignatura, puede haberse matriculado sobre ella un nmero cualquiera de alumnos no hay restricciones sobre el tipo de entidad alumnos en la relacin matrcula.

    3. El supervisor de un profesor, si lo tiene, es nico. El tipo de entidades profesor, en el papel

    supervisor tiene cardinal

  • Bases de datos y sistemas de informacin

    2-9

    PasRPersonas Nacida

    O bien

    PasRPersonas Nacida=1

    2. Matrcula: Se queda como est. 3. Profesores y supervisores:

    Supervisa

    Profesor

    SupervisadoSupervisor

    4. Tipo de relacin imparte:

    Asignatura

    Profesor Aula

    Imparte

    2.1.4.2. Participacin de una entidad en una relacin Sea r una relacin definida sobre los tipos de entidades E1, , Em y sea Ej {E1,Em}: Participacin:

    Def.: Se dice que la participacin de la entidad e Ej en r es n ( n N) si e Ej aparece en n tuplas de la relacin.

    Participacin total: Def.: Se dice que Ej tiene participacin total en r si cada entidad ej Ej se encuentra en alguna tupla de r. En otro caso se dice que la participacin es parcial.

    Ej.: Consideremos la siguiente relacin r de tipo AxBxC:

  • Bases de datos y sistemas de informacin

    2-10

    A B C A1 B1 C1 A1 B1 C2 A2 B2 C1 A2 B2 C2 A3 B1 C1 A3 B1 C2 Con los multiconjuntos de entidades A = {A1,A2,A3}, B={B1,B2}, C={C1,C2} La participacin de A1, A2, A3 en esta instancia es =2, la de B1=4, la de B2=2 y la de C1=3 y la de C2=3. Restricciones de participacin en los esquemas

    - Def.: Una restriccin de participacin (min,max) (min N, max N) de un tipo de entidades Ej en un tipo de relacin R indica que en todas las instancias vlidas de la BD se verifica: e Ej participacin de e en R est entre min y max.

    - Def.: Una restriccin de participacin total de un tipo de entidades Ej en un tipo de relacin R indica que en todas las instancias vlidas de la BD, se verifica que Ej tiene una participacin total.

    Ej.:s 1. La participacin de alumno en matrcula tiene una restriccin de participacin total. 2. La participacin de profesor en imparte tiene una restriccin de participacin (0, 6). Diagramas ER La restriccin de participacin (min,max) se representa:

    Asignatura

    Profesor Aula

    Imparte

    (0,6)

    La restriccin de participacin total se representa como:

    Alumno Matrcula Asignatura

    2.1.4.3. Unicidad de entidades Las entidades deben poder distinguirse unas de otras a travs de los valores de sus atributos. Interesa encontrar un conjunto de atributos lo ms pequeo posible que nos permita distinguir unas entidades de otras. Estos conjuntos sern las claves.

  • Bases de datos y sistemas de informacin

    2-11

    2.1.4.3.1. Claves Superclave.

    Def.: Dado un tipo de entidades E en una BD, se llama superclave a cualquier conjunto de atributos que permita distinguir a todas las entidades de cualquier instancia vlida de E en la BD. Si alguno de los atributos de la superclave corresponde a otro tipo de entidad F se debe verificar: - E y F deben participar en un tipo de relacin binaria R en la que F debe tener una

    restriccin de cardinalidad

  • Bases de datos y sistemas de informacin

    2-12

    Diagramas ER En los diagramas ER los atributos de la clave primaria se representan con sus nombres subrayados.

    2.1.4.3.2. Tipos de entidad dbiles Un tipo de entidades que no tiene suficientes atributos para formar una clave primaria se denomina tipo de entidades dbil. Ej.: Supongamos que estamos diseando una BD para CDs de msica. Vamos a utilizar la siguiente informacin: CD : Ttulo del CD, intrprete, nm. serie Cancin: Ttulo, duracin Tambin deseamos relacionar las canciones con el CD al que pertenecen. Esta relacin ser de muchas a una entre canciones y CDs (a cada cancin le corresponde un CD).

    canciones CDsen

    ttuloCDintrprete

    Nm.seriettulo duracin

    Ahora bien: El nm.serie del CD no se puede repetir en dos CDs diferentes. En cambio, en diferentes CDs puede aparecer la misma cancin (mismo ttulo) y puede darse (desgraciada casualidad) con la misma duracin. Por Ej.: supongamos que la cancin Only You aparece en un CD de The Platters y en un CD de Cranberries y con la misma duracin. Sin embargo, son canciones diferentes (diferentes intrpretes), es decir, entidades diferentes: { {ttulo=Only You, Duracin=230}, { ttulo =Only You, Duracin=230}} ( multiconjunto! ) Por tanto {ttulo, duracin} no es superclave y el tipo de entidad no puede tener una clave primaria formada slo por sus atributos. Sin embargo, si incluimos el nm de serie del CD en la clave s que tendremos una superclave, clave candidata y clave primaria. Clave primaria del tipo de entidad canciones: {nm.serie, ttulo, duracin} . Utilidad de las entidades dbiles Tambin queremos relacionar cada cancin con su autor o autores. Un autor viene dado por su DNI que no puede repetirse.

  • Bases de datos y sistemas de informacin

    2-13

    canciones CDs

    ttuloCDintrprete

    Nm.seriettulo duracin

    en

    compositores

    Autor

    DNI

    Diagrama ER Los tipos de entidad dbiles se representan con rectngulos dobles, y el tipo de relacin (o los tipos) que permiten formar la clave se indican con un doble rombo.

    canciones CDs

    ttuloCDintrprete

    Nm.seriettulo duracin

    en

    2.1.5. Diagramas entidad relacin extendidos (EER) Los conceptos bsicos del modelo E-R pueden modelar la mayora de las situaciones, pero algunos aspectos se pueden modelar ms adecuadamente con el modelo E-R extendido. Nuevas caractersticas:

    - Generalizacin - Agregacin - Especializacin - Herencia de atributos - ...

    2.1.5.1. Generalizacin Def.: Un tipo de entidades E es una generalizacin de un tipo de entidades R cuando los atributos de E estn incluidos en los atributos de R. Ejs.: El tipo de entidades personas con atributos DNI, ApellidosyNombre y domicilio es una

    generalizacin de alumnos (que tiene adems el atributo COU). El tipo de entidades personas con atributos DNI, ApellidosyNombre y domicilio es una

    generalizacin de profesores. Un tipo de entidades pelcula puede ser una generalizacin de los tipos de entidades

    musical, documental, melodrama Observacin: La idea de generalizacin est prxima a la de herencia en la programacin orientada a objetos.

  • Bases de datos y sistemas de informacin

    2-14

    Diagramas EER La generalizacin se representa con un tringulo que incluye el texto is a

    alumnos profesores

    personas

    is a

    Apellidos y Nombre Domicilio TelfonoDNI

    COU

    2.1.5.2. Agregacin El modelo E-R no permite establecer relaciones entre relaciones. Def.: La agregacin consiste en considerar un conjunto de componentes (tipos de entidades o tipos de relaciones) como si fueran un nico tipo de entidades. Diagramas EER Se denota incluyendo en un rectngulo todos los componentes de la agregacin. Ej.: Queremos gestionar partidos de un deporte. Cada partido tiene lugar entre dos equipos (el que juega en casa y el que juega fuera) y tiene un resultado. A cada partido le corresponde tambin un rbitro. Nos interesa determinar: Qu equipos han jugado entre s y con qu resultado Quin ha arbitrado cada partido. Con el modelo E/R bsico:

    Casa

    Equipos

    rbitros

    Partido

    Resultado

    Fuera de casa

  • Bases de datos y sistemas de informacin

    2-15

    Sin embargo, si es necesario incluir las empresas que publicitan sus productos en un partido, cmo se logra? Sera necesario introducir un tipo de entidad Empresas y un tipo de relacin Anuncia. Anuncia debera relacionar Empresas con Partidos, pero no existe esta entidad. Posibilidad: una nueva entidad ternaria entre Equipos y Empresas, pero esto dara lugar a redundancia en los atributos de Partido. Solucin: una agregacin denominada Partidos, que se tratar como un tipo de entidad y que puede relacionarse con Empresas.

    Equipos

    rbitros

    Resultado

    Fuera de casa

    Juegacon

    Casa

    Arbitra

    Partidos

    Empresas

    Anuncia

  • Bases de datos y sistemas de informacin

    2-16

    Diagrama ER completado

    DNI

    AsignaturasAlumnos Matrcula

    Aulas Imparte

    Supervisa

    Profesores

    Apellidos y Nombre Domicilio Telfono

    Apell. y Nombre Telfono COU Cdigo Ttulo Nm.Crditos

    Edificio Nmero

    Nota

    DNI

    SupervisadoSupervisor

    Calle Nmero Ciudad

    Domicilio

    (0,6)

    Observaciones: - Adems de representar el diagrama se deben indicar todas las suposiciones que se han realizado (las especificaciones nunca son completas).

    2.1.6. Conclusiones Ventajas del modelo E-R:

    - Diseo de alto nivel: Expresa con bastante precisin el esquema conceptual - Los diagramas de E-R permiten mantener una visin global del diseo y favorece la

    comunicacin entre los diseadores. Desventajas del modelo E-R:

    - Carece de un soporte formal y los SGBD no suelen implementarlo directamente. Normalmente hay que transformarlo en un modelo de ms bajo nivel.

    Modelo ER Modelo ER | | | modelo X (ej. relacional) | | V V SGBD SGBD

  • Bases de datos y sistemas de informacin

    2-17

    2.2. Modelo relacional Creado por Codd a Principios de los 70 Modelo lgico de datos de no muy alto nivel, orientado a registro. Slida base terica. Implementado en muchos SGBD. El concepto principal es la relacin o tabla .

    OJO: No hay que confundir la tabla con las relaciones del modelo ER. Aqu las relaciones valen para tipos de relaciones igual que para tipos de entidades.

    2.2.1. Terminologa del modelo relacional Entidad: Igual que en el esquema ER. Tambin se les llama tuplas o filas de la relacin. Atributo: Igual que en el esquema ER. Tambin se le llaman columnas de la relacin.

    El dominio de los atributos tiene que ser simple: no se admiten atributos multivalorados ni compuestos.

    Esquema de una relacin: viene dado por el nombre de la relacin y una lista de atributos. Es el tipo de entidad.

    Conjunto de entidades: Relacin o tabla . Ej: alumnos(DNI, NombreYApellidos, domicilio, telfono, cou ) Obs.: El orden de los atributos en la lista no importa. Lo fijamos porque nos viene bien para representarlo como tabla, pero cualquier permutacin es vlida. Instancia de una relacin: Conjuntos de entidades. Cada entidad se representa como una

    tupla. Cada componente de la tupla corresponde con el valor del atributo correspondiente, segn el orden enunciado en el esquema de la relacin.

    Ej: Instancia de la relacin alumnos: { (01234567Z, Manuel Vzquez Prieto, Calle del Jazmn 7 4 Izq, 91-12345678, COU = SI), ....} Obs.: Ahora hablamos siempre de conjuntos de entidades, nunca de multiconjuntos. Nota: En el modelo relacional no se distingue entre tipos de entidades y tipos de relaciones. Representac in: En el modelo relacional no se representan diagramas del esquema de la BD. Se pueden representar instancias de una relacin de la siguiente forma: Ej.: Instancia de la relacin alumnos DNI NombreyApellidos Domicilio Telfono COU 01234567Z Manuel Vzquez Prieto Calle del Jazmn 7 4 Izq 91-12345678 SI

    2.2.2. Paso del modelo ER al modelo relacional Al traspasar informacin de ER al modelo relacional se pierde informacin (participacin). En cambio, algunos requisitos que no podan representarse en el modelo ER s van a poder indicarse aqu.

  • Bases de datos y sistemas de informacin

    2-18

    2.2.2.1. Definicin de tablas Tipos de entidades Para cada tipo de entidad que no sea dbil se crea una relacin con el mismo nombre y conjunto de atributos. Obs.: En este punto no se indica nada acerca de los tipos de relaciones en los que participa el tipo de entidades. Ej: En el caso de la BD de secretara los tipos de entidades dan lugar a las relaciones: Alumnos(DNI, Apellidos y Nombre, Domicilio, telfono, COU) Asignaturas(Cdigo, ttulo, nm crditos) Profesores(DNI, Apellidos y nombre, Domicilio, telfono) Aulas(Edificio, nm.Edificio) Tipos de relaciones Para cada tipo de relacin R se crea una relacin con atributos: Por cada tipo de entidad que participa en la relacin, los atributos de la clave primaria. Los atributos de la propia relacin. Nota: En ocasiones hay que renombrar atributos para evitar tener varios con el mismo nombre. Ej: En el caso de la BD de secretara los tipos de relacin dan lugar a las relaciones: Matrcula(DNI, Cdigo, Nota) Supervisa(DNI,DNI) Imparte(DNI, Cdigo, Edificio, NumAula) Tipos de entidades dbiles - El tipo de entidad dbil E se transforma en una relacin que incluye los atributos del tipo de relacin ms los atributos necesarios para la clave de E. - Los tipos de relaciones en los que participa E deben incluir todos los atributos de la clave de E. Obs.: - El tipo de relacin con el doble rombo, si es binaria, no aporta nada y se podr eliminar. Si tiene atributos, se pasan a la relacin del tipo de entidad dbil. Ej: Traspasar el siguiente diagrama entidad-relacin a modelo relacional:

    CDs

    ttuloCD intrpreteNm.serie

    en

    Autor

    compositores DNI

    canciones

    ttulo duracin

    NombreyApe

  • Bases de datos y sistemas de informacin

    2-19

    Solucin: compositores(DNI, NombreYApe) canciones(titulo, duracion,NmSerie) autor(DNI, titulo, duracin, NmSerie) en(titulo, duracin, NmSerie)

  • Bases de datos y sistemas de informacin

    2-20

    E1 E2R

    Superclave: c2 c) Varias a varias

    E1 E2R

    Superclave : c1 c2 Relaciones n-arias Supongamos que la relacin proviene de un tipo de relacin R entre tipos de entidad E1, E2, ..., Ek. - Si todos participan con cardinalidad varios en R, entonces una superclave es la unin de las

    claves de E1, E2, ..., Ek. - Si algunos tipos de entidad participan con cardinalidad una en R, entonces uno de ellos

    puede ser excluido de la superclave. Obs.: - Si los tipos de entidades E1, E2,...,Ek no intervienen en tipos de relacin adicionales y no

    hay otros requerimientos, la Def.: anterior nos proporciona una clave del tipo de relacin. Ej: BD secretara Alumnos(DNI, Apellidos y Nombre, Domicilio, telfono, COU) Asignaturas(Cdigo, ttulo, nm.crditos) Otra clave candidata: { ttulo } Profesores(DNI, Apellidos y nombre, Domicilio, telfono) Aulas(Edificio , nm.Edificio) Matricula(DNI, Cdigo, Nota) Supervisa(DNISupervisor,DNISupervisado) Imparte(DNI, Codigo, Edificio,NumAula) Ej: BD de canciones: compositores(DNI, NombreYApe) canciones(ttulo, duracin, NmSerie ) autor(DNI, ttulo, duracin, NmSerie) CDs(Nm.Serie , ttuloCD, intrprete)

    2.2.2.3. Cuestiones de diseo En ocasiones es posible combinar 2 o ms tablas en una sola: Ej:

    Personas PasesNacidaApell.

    DNI

    Nombre

  • Bases de datos y sistemas de informacin

    2-21

    Esquema de la BD: Personas(DNI, Apell.) Pases(Nombre) Nacida(DNI, Nombre) Nuevo Esquema: Personas(DNI,Apell, PaisNac) Pases(Nombre) Ej: Esquema de BD: personas(DNI, ApellidosyNombre, Domicilio, telfono). alumnos(DNI, COU) profesores(DNI) Esquema modificado: personas(DNI, ApellidosyNombre, Domicilio, telfono,AlumnOProfe, COU). Obs.: - Se admite la existencia de una valor nulo (NULL) en todo dominio de un atributo. - Los atributos que forman parte de una clave no pueden tomar el valor nulo en ninguna

    instancia vlida de la BD.

    ENTREGAR EJEMPLO !

    2.2.3. Lenguajes formales del modelo relacional Lenguajes que permiten manipular la B.D. Estos lenguajes sern implementados en los SGBD comerciales que veremos posteriormente. Se parte de los esquemas de relaciones y se define un lenguaje de manipulacin de datos.

    2.2.3.1. lgebra relacional Lenguaje de manipulacin de datos DML (Data Management Language) de tipo procedimental que permite consultar y modificar la BD. Define operaciones sobre una o dos relaciones que producen otra relacin. Operaciones fundamentales: seleccin, proyeccin, unin, diferencia de conjuntos, producto cartesiano y renombramiento. Agrupadas segn: - Operaciones entre conjuntos: unin, interseccin, diferencia,. - Operaciones que eliminan partes de una relacin: proyeccin (elimina columnas) y

    seleccin (elimina filas) - Operacin de renombramiento - Combinacin de tuplas de 2 relaciones: productos cartesianos, uniones naturales, productos,

    divisiones - Extensiones del lgebra relacional.

    2.2.3.1.1. Operaciones entre conjuntos: unin, interseccin, diferencia Son operaciones binarias que requieren: - Los dos esquemas deben tener idnticos atributos. - En el momento de efectuar la operacin se supone que el orden de las columnas es el

    mismo. Def.: Dados dos esquemas de relacin R(A1,....,An), S(A1,....,An) La operacin unin de R y S , que se denota R U S(A1,....,An),

  • Bases de datos y sistemas de informacin

    2-22

    produce un esquema cuyas instancias vlidas pueden escribirse de la forma (r U s), con r instancia vlida de R y s instancia vlida de S. La operacin interseccin de R y S , y se denota R S(A1,....,An), produce un esquema cuyas instancias vlidas pueden escribirse de la forma (r s), con r instancia vlida de R y s instancia vlida de S. La operacin diferencia de R y S , y se denota R \ S(A1,....,An), produce un esquema cuyas instancias vlidas pueden escribirse de la forma (r \s), con r instancia vlida de R y s instancia vlida de S. Ej.: - Deseamos formar un esquema de relacin con todos los empleados de la empresa.

    Empleados

  • Bases de datos y sistemas de informacin

    2-23

    C:= C:= C C C:= C C C:= C Donde representa operadores booleanos del dominio (=). Ejs.: - Cdigos de todos los proyectos en los que trabaja el empleado con DNI 4

    ProyectosDNI4

  • Bases de datos y sistemas de informacin

    2-24

    C

    2.2.3.1.4. Operaciones de combinacin de tuplas Producto Cartesiano Def.: Dadas dos relaciones R1, R2 esquemas de relacin , la operacin producto Cartesiano de R1, se denota por R1 x R2 y se define como: - Atributos: Los de R1 U los de R2. Si tienen algn nombre de atributo A comn, este se

    convierte en R1.A, R2.A - Instancias: Son de la forma r1xr2, con r1 instancia de R1, r2 instancia de R2. Ej.: Queremos conocer los nombres, direcciones y telfonos de los empleados que dirigen algn proyecto: 1 Datos de todos los empleados

    Empleados Programadores U Analistas Empleados(DNI, Nombre,Direccin,Telfono)

    2 Hacemos el producto cartesiano con los DNIs de los directores de proyecto:

    DNIDirPorEmpleados pDNIDir(Proyectos) x Empleados DNIDirPorEmpleados (DNIDir, DNI, Nombre,Direccin,Telfono)

    3 Nos quedamos con los datos de los directores de proyecto

    DatosDirProyecto pNombre, Direccin, Telfono( sDNIDir = DNI(DNIDirPorEmpleados)) DatosDirProyecto(Nombre,Direccin,Telfono)

    Join (reunin) Def.: Se define la reunin de R1 y R2 ( ) como:

    R1 R2 = sC(R1 x R2) Donde c es una conjuncin de operaciones booleanas: C= C1 AND C2 AND C3 ..... Ej.: Queremos conocer los nombres, direcciones y telfonos de los empleados que dirigen algn proyecto: 1. Datos de todos los empleados Empleados Programadores U Analistas Empleados(DNI, Nombre,Direccin,Telfono) 2. Datos de los directores de proyecto

    DatosDirProyecto pNombre, Direccin, Telfono( Proyectos Empleados) Ej.: Obtener los nombres de todos los empleados que trabajan en algn proyecto ms de 10 horas: Dos formas:

    NombresTrabajanMasde10 pNombre( Empleados Distribucin) Resultado Nombre Herminia

    C

    DNIDir=DNI

    DNIEmp=DNI AND Horas>10

  • Bases de datos y sistemas de informacin

    2-25

    Calixto Teodora Evaristo Equijoin (equirreunin) Def.: Se llaman operacin Equijoin a todo join natural cuya condicin es una conjuncin de igualdades. Obs.: Dada una instancia vlida de un equijoin con condicin C, se verifica que todas las tuplas tienen valores repetidos para los atributos de la condicin C. Ej.: R1(A,B) A B 1 B1 2 B2 2 B3 R2(C,D) C D 2 D1 2 D2 R1 |x|(A=C) R2 A B C D 2 B2 2 D1 2 B2 2 D2 2 B3 2 D1 2 B3 2 D2 Join natural Def.: Sean R1(A1,...,An) y R2(B1,...,Bm) dos esquemas de relacin y {C1,C2,...,Cj) la lista de los atributos comunes a ambas relaciones. La operacin join natural (reunin natural) de R1 y R2, Produce un esquema de relacin R1 R2 tal que: - Atributos: {A1,....,An} U {B1,...,Bm} (los atributos comunes slo aparecen una vez). - Instancias vlidas: Dada r1 instancia vlida de R1 y r2 de R2, se obtiene una instancia

    vlida de la unin natural combinando todas las tuplas u de r1 y v de r2 tales que u y v coinciden sobre {C1,C2,...,Cj}.

    Ej.: Datos personales de los directores de proyecto.

    DNIDirPro r (DNI) (pDNIDir(Proyectos)) DatosDirProyecto DNIDirPro (Programadores U Analistas) Teorema: Sean R1 y R2 dos esquemas de relacin con atributos comunes (C1,....,Cj), atributos de A son (A1,...,An,C1,...,Cj) Y los de B (B1,....,Bm,C1,....,Cj)

  • Bases de datos y sistemas de informacin

    2-26

    Entonces R1 R2 = (salvo el orden de los atributos)

    r A1,A2,...,An,B1,...,Bm,C1,...,Cj (pA1,A2,...,An,B1,...,Bm,R1.C1,...,R1.Cj ( s(R1.C1 = R2.C2 AND ,...,AND R1.Cj=R2.Cj)(R1 x R2) )) Ej.: R1(A,B) A B 1 B1 2 B2 2 B3 R2(C,D) A C 2 C1

    2 C2 R1 x R2 R1.A B R2.A C 1 B1 2 C1 1 B1 2 C2 2 B2 2 D1 2 B2 2 D2 2 B3 2 D1 2 B3 2 D2

    s(R1.A=R2.A)(R1 x R2 ) R1.A B R2.A C 2 B2 2 D1 2 B2 2 D2 2 B3 2 D1 2 B3 2 D2

    r(A,B,C) (p (R1.A,B,C) (s(R1.A=R2.A)(R1 x R2 )) A B C 2 B2 D1 2 B2 D2 2 B3 D1 2 B3 D2 Ej.: Obtener los datos de todos datos de los empleados que comparten domicilio con otro empleado. Empleados(dni,nombre,domicilio) DNI Nombre Domicilio 1 Aniceto Jazmn 1 2 Eulalia Rosa 3 3 Teodora Clavel 2 4 Macario Rosa 3 5 Anacleto Jazmn 1

  • Bases de datos y sistemas de informacin

    2-27

    sE1.DNIE2.DNI AND E1.Domicilio=E2.Domicilio(rE1(Empleados) x r E2(Empleados)) Observacin - Los expresiones booleanas NULL op X, X op NULL siendo op operador booleano son

    falsos (incluso el caso NULL = NULL). - Como resultado de lo anterior puede ser que alguna instancia vlida de R1 |x| R1 tenga

    menos tuplas que la correspondiente instancia de R1.

    Ej.: Analistas |x| Analistas DNI 4 5 6 Divisiones Idea: Se utilizan cuando se busca que algn atributo de una relacin tome (al menos) todos los valores de otro atributo en otra relacin. Def.: Sea R(A1,...,An), S(B1,...,Bm) con {B1,....,Bm}{A1,...,An}. Entonces la operacin divisin RS produce un esquema de relacin - Atributos: {C1,...,Cj} = {A1,...,An}\{B1,...,Bm} - Instancias vlidas: Dada r instancia vlida de R, s inst. vlida de S, Una tupla u est en R S cuando para todo v de S, la tupla que se obtiene al unir los valores de u y v est en R. Ej.: T = RS, STR R A B A1 B1 A2 B1 A3 B1 A4 B1 A1 B2 A3 B2 A2 B3 A3 B3 A1 B4 A2 B4 A3 B4 S A A1 A2 A3 T B B1 B4

  • Bases de datos y sistemas de informacin

    2-28

    Ej.: Determinar los datos personales de los empleados que trabajan en todos los proyectos que trabaja el empleado Jacinto

    DatosJacinto s(Nombre = Jacinto)(empleados)) ProyectosJacinto p(codigoPr)(( DatosJacinc to |x|(DNI=DNIEmp)(Distribucin)) DNIProyecto p(codigoPr, DNIEmp) (Distribucin) DNIBuscados DNIProyecto ProyectosJacinto

    DatosBuscados r(DNI)(DNIBuscados) |x| empleados

    2.2.3.2. Clculo relacional de tuplas Lenguaje no procedimental.

    2.2.3.2.1. Forma general de una consulta en clculo relacional de tuplas: {t | P(t) } = el conjunto de todas las tuplas que cumplen la condicin P. P es una frmula escrita en lgica de primer orden. Ejemplo Datos personales del empleado con DNI 3: {t | ((t Programadores) (t Analistas)) (t[DNI] = 3]) }

    2.2.3.2.2. Frmulas en el clculo relacional de tuplas Pueden ser tomos y frmulas compuestas. tomos.

    Los tomos tienen una de las siguientes formas: 1.- x r. Con x una variable de tupla y r un esquema de relacin. Una variable de tupla representa un fila genrica de una instancia vlida de r. 2.- t[A] q s[B], donde t y s son variables de tupla, A es un atributo de la relacin en la que est definida la variable de tupla t, B es un atributo de la relacin en la que est definida la variable de tupla s, y q es un operador de comparacin (,= ...) El dominio de los atributos A y B debe ser compatible. Con t[A] denotamos el valor de la tupla t en el atributo A. 3.- t[A] q c, donde t variable de tupla, A un atributo de la relacin en la que est definida la variable de tupla t, c un valor del dominio de A y q es un operador de comparacin (,= ...).

    Frmulas compuestas Para construir una frmula se usan las siguientes reglas: Las frmulas bsicas son frmulas. Si F es una frmula (F) y F tambin son frmulas. Si F1 y F2 son formulas entonces F1 F2, F1F2 y F1F2 tambin son frmulas. Se pueden usar "y $ para ligar las variables de tupla. Si F(t) es una frmula en la que aparece libre la variable de tupla t, entonces las siguientes tambin son frmulas: "tR, P(t) $ tR, P(t) Una variable de tupla que est cuantificada se dice ligada cuando aparece en una frmula afectada por un cuantificador (",$).

    2.2.3.2.3. Ejemplos

  • Bases de datos y sistemas de informacin

    2-29

    - Deseamos formar un esquema de relacin con todos los empleados de la empresa.

    {t | (t Programadores) (t Analistas)} t es libre - Queremos conocer a los empleados que son a la vez programadores y analistas.

    {t | (t Programadores) (t Analistas)} DNI: 4 - Empleados que son analistas no programadores (SoloAnalistas

  • Bases de datos y sistemas de informacin

    2-30

    Proyeccin Ej: - Determinar los cdigos de los proyectos en los que hay algn empleado trabajando. ProyectosEnMarcha

  • Bases de datos y sistemas de informacin

    2-31

    $ j ( j Programadores j Analistas) ( j[nombre] = Jacinto ("p Distribucion)

    ((p[DNIEmp] = j[DNI] ) $ u ((u Distribucion ) t[DNI] = u[DNIEmp] u[CodigoPr] = p[CodigoPr] ) )

    ) }

    2.2.3.2.5. Significado de una frmula. Frmulas seguras. Para que tengan una frmula {t | P(t)} del calculo relacional de tuplas tenga significado debe cumplir: 1. Todas las variables deben estar ligadas, exceptuando t que es libre. 2. Todas las variables que aparezcan en la frmula -condicin deben pertenecer a un esquema

    de relacin, menos quiz, t. 3. La frmula debe ser segura. Frmulas seguras: Es posible que el resultado de una expresin sea infinito, por ejemplo: {t | (t R)} Se introduce el concepto de dominio. dom(P) es el conjunto de todos los valores a los que P hace referencia Se dice que una expresin {t | P(t)} es segura si todos los valores que aparecen en el resultado son valores de dom(P). La expresin {t | (t R)} no es segura: dom( (t R)) es el conjunto de todos los valores que aparecen en R. Sin embargo, es posible tener una tupla t que no est en prstamo que contenga valores que no aparezcan en R.

    2.2.3.3. Clculo relacional de dominios El clculo relacional de dominios utiliza variables de dominio que toman sus valores del dominio de un atributo, en lugar de tomarlos de una tupla completa.

    2.2.3.3.1. Forma general de una consulta { | P(x1, x2, ..., xn)} con xi variables de dominio Ejemplo - cdigos de proyectos en los que trabaja el empleado con DNI 4 ::REVISAR:: ProyectosDNI4

  • Bases de datos y sistemas de informacin

    2-32

    En el clculo relacional de dominios se supone un orden predeterminado para los atributos de cada esquema.

    2.2.3.3.2. Frmulas en el clculo relacional de dominios Pueden ser - tomos - frmulas compuestas - tomos 1.- < x1, ..., xn > r donde r es una relacin con n atributos donde xi son variables de dominio o constantes de dominio. 2.- x q y, donde x y y son variables de dominio y q es un operador de comparacin (,= ...). 3.- x q c, donde x variable de dominio, c un valor del dominio de x y q es un operador de comparacin (,= ...). Frmulas Compuestas - Un tomo es una frmula. Si F es una frmula (F) y F tambin son frmulas. Si F1 y F2 son formulas entonces F1 F2, F1F2 y F1F2 tambin son frmulas. Se pueden usar "y $ para ligar las variables de tupla. Si F(t) es una frmula en la que aparece libre la variable de dominio x, entonces las siguientes tambin son frmulas: "x, P(x) $ x, P(x) Una variable de tupla que est cuantificada se dice ligada cuando aparece en una frmula afectada por un cuantificador (",$).

    2.2.3.3.3. Ejemplos - Deseamos formar un esquema de relacin con todos los empleados de la empresa.

    { | < dni,nom,dir,tel> (Programadores Analistas)} Seleccin - Trabajadores que trabajan entre 10 y 20 horas (ambas cantidades inclusive) en algn proyecto.

    Entre10Y20 =10 and Horas=10) (t[Horas]=10 h

  • Bases de datos y sistemas de informacin

    2-33

    1.2 Hacemos el producto cartesiano con los DNIs de los directores de proyecto:

    DNIDirPorEmpleados pDNIDir(Proyectos) x Empleados DNIDirPorEmpleados (DNIDir, DNI, Nombre,Direccin,Telfono) 1.3 Nos quedamos con los datos de los directores de proyecto

    DatosDirProyecto pNombre, Direccin, Telfono( sDNIDir = DNI(DNIDirPorEmpleados)) DatosDirProyecto(Nombre,Direccin,Telfono) {t | $u( ((u Analistas) (u Programadores)) (t[Nombre] = u[Nombre]) (t[Direccin] = u[Direccin]) (t[telfono] = u[telfono]) ($vProyectos( v[DNIDir] = u[DNI]) ) } { | $dni( (( Analistas) ( Programadores)) ($cod,descr (Proyectos) }

    2.2.3.3.4. Significado de una frmula. Frmulas seguras. Para que tengan una frmula {| P()} del calculo relacional de dominios tenga significado debe cumplir: 1. Todas la variables deben estar ligadas, exceptuando que es libre. 2. La frmula debe ser segura. Frmulas seguras: Son frmulas no-seguras las que contienen alguna subfrmula capaz de generar un nmero infinito de tuplas. { | ( programadores) } En el clculo relacional de dominios tambin hay que tener en cuenta la forma de las frmulas dentro de las instrucciones existe y para todo. Considrese la expresin { | $ y ( r) $ z ( ( r) P(x, z))} donde P es una frmula que implica a x y a z. Se puede probar la primera parte de la frmula, $ y ( r), tomando en consideracin slo los valores de r. Sin embargo, para probar la segunda parte de la frmula, $ z ( ( r) P(x, z)), hay que tomar en consideracin valores de z que no aparecen en r. Dado que todas las relaciones son finitas, no aparece en r un nmero infinito de valores. Por tanto, no resulta posible en general probar la segunda parte de la frmula $ z ( ( r) P(x, z)); hay que tomar en consideracin valores de z que no

  • Bases de datos y sistemas de informacin

    2-34

    aparecen en r. Dado que todas las relaciones son finitas, no aparece en r un nmero infinito de valores. Por tanto, no es posible en general probar la segunda parte de la frmula sin tomar en consideracin un nmero infinito de valores de z. En vez de eso, se aaden ligaduras para prohibir expresiones como la anterior. Condiciones de seguridad: Se dice que la expresin { | P(x1, x2, ..., xn)} es segura si se cumplen todas las condiciones siguientes: 1. Todos los valores que aparecen en las tuplas de la expresin son valores de dom(P). 2. Para cada subfrmula existe de la forma $ x (P1(x)), la subfrmula es cierta si y slo si

    hay un valor x en dom(P1) tal que P1(x) es verdadero. 3. Para cada subfrmula para todo de la forma " x (P1(x)), la subfrmula es verdadera si y

    slo si P1(x) es verdadero para todos los valores x de dom(P1). Teorema Es equivalente el poder expresivo de - el lgebra relacional - el clculo relacional de tuplas para frmulas seguras - el clculo relacional de dominios para frmulas seguras

  • Bases de datos y sistemas de informacin

    2-35

    2.3. Modelo de orientacin a objetos Motivacin: 1. Carencias del modelo de datos relacional.

    Lenguajes de consulta Turing-incompletos Tipos de datos muy limitados Fuertes carencias expresivas del modelo (valores nulos, consultas recursivas) Soporte escaso de restricciones de integridad

    2. Necesidad de tipos complejos. Atributos multivalorados y compuestos. 3. Propiedades activas. Propiedades (atributos) cuyo valor depende de ciertos parmetros. Por

    ejemplo, el nivel de consumo de un componente, que depende del voltaje. 4. Diseo de sistemas complejos. Ejemplo: Circuito digital. Tipos de componentes, instancias

    de componentes, referencias de los componentes (identificadores). 5. Desajuste de impedancia: diferencia entre el nivel de registros de los actuales lenguajes de

    programacin tpicos y el nivel de conjuntos de un lenguaje como SQL. 6. No hay que bajar el lenguaje de base de datos al nivel de registros (como los lenguajes de

    programacin orientadas a objetos), sino elevar el nivel de operacin (abstraccin) de los lenguajes al nivel de conjuntos. La mayora de estos lenguajes son de tercera generacin por naturaleza y, como consecuencia, difciles de transformar al nuevo nivel expresivo.

    Tipos de modelos de orientacin a objetos:

    - Modelo de datos orientado a objetos. - Modelo de datos relacional orientado a objetos.

    2.3.1. Modelo de datos orientado a objetos Conceptos:

    2.3.1.1. Objetos Objeto -> entidad (E/R) Variables -> atributos (E/R). Definen el estado del objeto. Mensajes (posiblemente con parmetros). Interfaz de comunicacin. Mtodos: Cdigo que implementa a los mensajes. Devuelven una respuesta. Pueden

    modificar el estado del objeto. Un atributo se define por una variable, un mtodo de lectura y otro de escritura.

    2.3.1.2. Clases Clase: tipo de objetos. -> Tipo de entidad (E/R) Instancia o ejemplar de una clase: objeto Ejemplo:

    class empleado { /* Variables */ string nombre; string direccin; date fecha-alta ; int sueldo; /* Mensajes */ int sueldo-anual (); string obtener-nombre (); string obtener-direccin ();

  • Bases de datos y sistemas de informacin

    2-36

    int establecer-direccin (string nueva-direccin); int antigedad(); };

    string obtener-direccin() { return direccin; } int establecer-direccin(string nueva-direccin) { direccin = nueva-direccin; } int antigedad(){ return today() - fecha-alta; }

    2.3.1.3. Herencia Jerarqua de clases: especializacin en el modelo entidad-relacin (relacin "ISA"). Se puede admitir herencia mltiple.

    persona

    ES

    empleado cliente

    ES

    administrativo cajero secretario

    Definicin en pseudocdigo de la jerarqua de clases: class persona { string nombre; string direccin; string obtener-nombre(); string obtener-direccin(); int establecer-direccin(string nueva-direccin ); }; class cliente isa persona { int inters-prstamo; }; class empleado isa persona { date fecha-alta ; int sueldo; int sueldo-anual(); int antigedad(); }; class administrativo isa empleado { int nmero-despacho; int nmero-cuenta-corriente ; }; class cajero isa empleado { int horas-semana; int nmero-ventanilla ; }; class secretario isa empleado {

  • Bases de datos y sistemas de informacin

    2-37

    int horas-semana; string jefe; };

    2.3.1.4. Identidad de los objetos Las tuplas de las tablas se identifican por sus valores. Los objetos conservan su identidad aunque cambien los valores de sus variables o sus mtodos. Tipos de identidad: Valor. Igual que el modelo relacional. Nombre. Nombre proporcionado por el usuario (Ej: sistemas de archivos). Incorporada o implcita. El concepto de identidad se incluye en el modelo de datos o en el

    lenguaje de programacin (hace falta que el usuario proporcione ningn identificador). El sistema aporta un identificador en el momento en que se crea.

    2.3.1.5. Lenguajes de programacin persistente Datos persistentes. Diferencias de los lenguajes de programacin persistente: 1. Desajuste de impedancia de lenguajes de tercera generacin con SQL incorporado. Los

    programadores son responsables de las conversiones de tipos entre el lenguaje anfitrin y SQL. Inconvenientes de los lenguajes POO de 3 generacin con SQL incorporado: El cdigo de conversin opera fuera del sistema de tipos orientado a objetos. La conversin entre formatos de datos (POO-SQL) necesita gran cantidad de cdigo. En los lenguajes de programacin persistente, el lenguaje de consulta est totalmente integrado con el lenguaje anfitrin y comparten el mismo sistema de tipos. No hay cambios de formato.

    2. Lenguajes de consulta incorporados: cdigo explcito para la bsqueda y actualizacin de

    los datos. En los lenguajes de programacin persistentes no es necesario.

    2.3.1.6. Ampliacin de los lenguajes POO para admitir persistencia

    2.3.1.6.1. Objetos persistentes Hacer permanentes los objetos transitorios. Enfoques: Persistencia por clases. Declaracin de clases persistentes. Persistencia por creacin. Declaracin explcita de los objetos persistentes. Persistencia por marcas. Marcar los objetos creados como persistentes. Persistencia por alcance. Se declaran uno o varios objetos raz como persistentes. Son

    tambin persistentes de forma automtica los que se puedan alcanzar desde la raz.

    2.3.1.6.2. Punteros persistentes Hacer persistentes los punteros transitorios. Grados de persistencia: Dentro de los procedimientos. Dentro de los programas. Entre programas. El puntero persiste de una ejecucin del programa a otra. Persistente. Los punteros persisten tambin entre las reorganizaciones estructurales de los

    datos.

    2.3.1.7. Sistemas persistentes C++ de ODMG

  • Bases de datos y sistemas de informacin

    2-38

    ODMG = Object Database Management Group class Sucursal : public d_Object { public: d_String nombre; d_String direccin; d_Long activo; }; class Cuenta : public d_Object { private: d_Long saldo; public: d_Long nmero_cuenta; d_Set titulares; d_Long calcular_saldo(); int actualizar_saldo(d_Long delta); }; class Persona : public d_Object { public: d_String nombre; d_String direccin; }; class Cliente : public Persona { public: d_Date alta;

    d_Long id_cliente; d_Ref sucursal_raz; d_Set cuentas;

    }; d_Object: Clase de objeto persistente (Ej. Sucursal es subclase de d_Object). d_Ref: Puntero persistente d_Set: Tipo conjunto. d_Rel_Set, d_Rel_Ref: Integridad referencial int crear_titular_cuenta(String nombre, String direccin) {

    d_Database bd_banco_obj; d_Database * bd_banco = &bd_banco_obj; bd_banco->open(BD-Banco); d_Transaction Trans; Trans.begin (); d_Ref cuenta = new(bd_banco,"Cuenta")Cuenta; d_Ref clien = new(bd_banco,"Cliente") Cliente; clien->nombre = nombre; clien->direccin = direccin; clien->cuentas.insert_element(cuenta); cuenta->titulares.insert_element(clien); ... Cdigo para inicializar id_cliente, nmero de cuenta, etc. Trans.commit(); bd_banco->close();

    }

  • Bases de datos y sistemas de informacin

    2-39

    2.3.2. Modelo de datos relacional orientado a objetos Necesidad de tipos de datos ms elaborados.

    2.3.2.1. Tipos coleccin Conjuntos:

    create table libros ( ... lista-palabras-clave setof(varchar(20)) ...

    ) Arrays:

    array-autores varchar(20) array [10]

    2.3.2.2. Tipos de objetos de gran tamao clob: objetos de gran tamao para datos de caracteres. blob: objetos de gran tamao para datos binarios. lob: Large Object crtica-libro clob(10KB) imagen blob(10MB) pelcula blob(2GB)

    2.3.2.3. Tipos estructurados Declaracin de tipos:

    create type Editorial as (nombre varchar(20), sucursal varchar(20)) create type Libro as (ttulo 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

    Declaracin de mtodos aplicables a los tipos:

    create type Empleado as ( nombre varchar(20), sueldo integer) method incrementar(porcentaje integer) El cuerpo del mtodo se crea separadamente:

  • Bases de datos y sistemas de informacin

    2-40

    create method incrementar(porcentaje integer) for Empleado begin set self.sueldo = self.sueldo + (self.sueldo*porcentaje)/100 end

    Funciones constructoras: create function Editorial (n varchar(20), s varchar(20)) returns Editorial begin set nombre = n; set sucursal = s; end Insercin de valores: insert into libros values ('Compiladores',array['Gmez', 'Santos'], 1998, Editorial('McGraw-Hill', 'Nueva York'), set(' traduccin, anlisis'))

    2.3.2.4. Herencia

    2.3.2.4.1. Herencia de tipos

    create type Persona (nombre varchar(20), direccin varchar(20))

    Herencia simple:

    create type Estudiante under Persona

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

    Herencia mltiple:

    create type Ayudante under Estudiante, Profesor

    2.3.2.4.2. Herencia de tablas Las subtablas en SQL:1999 se corresponden con la nocin del modelo E-R de la especializacin y la generalizacin. Si se define:

    create table persona of Persona

  • Bases de datos y sistemas de informacin

    2-41

    Se pueden definir las tablas estudiantes y profesores como subtablas de persona:

    create table estudiantes of Estudiante under persona create table profesores of Profesor under persona

    2.3.2.4.3. Tipos referencia

    create type Departamento ( nombre varchar(20), director ref(Persona) scope persona

    ) create table departamentos of Departamento

    Persona: Tipo persona: Tabla scope: definicin de integridad referencial. Ejemplo de insercin: insert into departamentos

    values ('Informtica', null) update departamentos set director = (select ref(p) from persona as p where nombre = 'Juan') where nombre = 'Informtica'

    2.3.2.4.4. Consultas con tipos complejos Acceso a atributos compuestos:

    select ttulo, editorial.nombre from libros

    Acceso a referencias: select director->nombre, director->direccin from departamentos Acceso a tipos coleccin:

    Listas select ttulo from libros where "base de datos" in (unnest(lista-palabras-clave))

    Arrays select array-autores[1], array-autores[2], array-autores[3] from libros where ttulo = 'Fundamentos de bases de datos'

    2.3.2.4.5. Funciones, procedimientos y mtodos Se definen mediante el componente procedimental de SQL:1999 o mediante un lenguaje de programacin:

  • Bases de datos y sistemas de informacin

    2-42

    Java, C, C++ o lenguajes de cuarta generacin (PL/SQL de Oracle y TransactSQL de SQL Server de Microsoft).

    Bibliografa [ACPT00] P. Atzeni, S. Ceri, S. Paraboschi y R. Torlone, Database Systems. Concepts,

    Languages and Architectures, McGraw-Hill, 2000. [Dat93] C.J. Date, "Introduccin a los Sistemas de Bases de Datos", Addison-Wesley,

    Reading Massachusetts, 1993. [EN00] R. Elmasri y S.B. Navathe, "Fundamentals of Data Base Systems", Addison-

    Wesley, 2000. [SKS98] A. Silberstachatz, Apartados