Your SlideShare is downloading. ×
0
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióN
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Unidad 5 TransformacióN Er A Relacional NormalizacióN

12,433

Published on

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
12,433
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
553
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Bases de Datos Unidad V Transformación Modelo ER a Relacional - Normalización Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática Docente Jornada Parcial Universidad Viña del Mar
  • 2. Transformación Modelo ER a Relacional Tres reglas básicas <ul><li>Las tres reglas básicas para convertir un esquema en el modelo E/R al relacional son las siguientes: </li></ul><ul><li>Todo tipo de entidad se convierte en una relación. </li></ul><ul><li>Todo tipo de relación M:M (muchos a muchos) se transforma en una relación. </li></ul><ul><li>Para todo tipo de relación 1:M se realiza lo que se denomina propagación de clave (regla general), o se crea una nueva relación. </li></ul>
  • 3. Transformación Modelo ER a Relacional Tres reglas básicas <ul><li>Debido a que el modelo relacional no distingue entre entidades y relaciones, ambos conceptos deben representarse mediante relaciones. Esto implica una perdida de semántica con respecto al esquema E/R: </li></ul><ul><ul><li>Las relaciones M:M no se distinguen de las entidades (ambas se transforman en tablas). </li></ul></ul><ul><ul><li>Las 1:M se suelen representar mediante una propagación de clave, desapareciendo incluso el nombre de la relación. </li></ul></ul>
  • 4. Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo LIBRO( Código , Título, Idioma, …, Editorial) EDITORIAL( Nombre_e , Dirección, Ciudad, País) AUTOR( Nombre_a, Nacionalidad, Institución) ESCRIBE( Nombre_a , Código ) CLAVE AJENA EDITORIAL LIBRO AUTOR EDITA ESCRIBE 1 n n n Nombre_e Codigo Nombre_a
  • 5. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Entidades Cada tipo de entidad se convierte en una tabla. La tabla se llamará igual que el tipo de entidad de donde proviene. Transformación de Atributos de Entidades Cada atributo de una entidad se transforma en una columna de la tabla a la que ha dado lugar la entidad. Teniendo en cuenta que existen atributos identificador principal, otros que son identificadores alternativos (únicos) y el resto de los atributos que no son identificadores – atributos no principales-. Esta regla se divide en subreglas.
  • 6. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de Atributos de Entidades </li></ul><ul><li>Atributos Identificadores </li></ul><ul><li>Los atributos que son identificadores principales pasan a formar la clave primaria de la tabla. </li></ul><ul><li>Atributos Identificadores Alternativos </li></ul><ul><li>Se les denomina mediante un cláusula denomina UNIQUE. </li></ul><ul><li>Atributos No Identificadores </li></ul><ul><li>Se representan solo como columnas de la tabla correspondiente. </li></ul>
  • 7. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Atributos de Entidades PROFESOR CREATE TABLE Profesor ( Cod_Prof Código, Nombre Nombres, DNI DNIS, NOT NULL Dirección Lugares, Télefono Nos_Teléfono, Materia Materias, PRIMARY KEY (Cod_prof), UNIQUE (DNI) ); PROFESOR Dirección Télefono Materia Cod_Prof Nombre DNI Materia Teléfono Dirección DNI Nombre Cod_prof
  • 8. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de Atributos de Entidades </li></ul><ul><li>Atributos Multivaluados </li></ul><ul><li>Puesto que el modelo relacional no permite dominios multivaluados, deberá crearse una nueva tabla cuyos únicos atributos ( y clave primaria ) será la concatenación de la clave primaria de la entidad original y el atributo multivaluado. </li></ul><ul><li>Además, se debe crear una clave ajena referenciado a la tabla primaria. </li></ul>PROFESOR Télefono Cod_Prof Nombre n Persona ( dni , nombre, ……) Telefonos ( dni , número ) CLAVE AJENA
  • 9. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones M:M Un tipo de relación M:M se transforma en una tabla que tendrá como clave primaria la concatenación de las claves primarias (CP) de los tipos de entidades que asocia. Además, cada uno de los atributos que forman la clave primaria de esta tabla también son claves ajenas que referencian a las tablas en que se han convertido las entidades relacionadas (claves primarias). Cod_prof Cod_curso Modelo Relacional PROFESOR ( Cod_prof , ….. ) CURSO ( Cod_curso ) IMPARTE ( Cod_curso , Cod_prof ) PROFESOR CURSO IMPARTE n n
  • 10. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de relaciones 1:N </li></ul><ul><li>Existen dos soluciones: </li></ul><ul><ul><li>Propagar la clave principal del tipo de entidad que tiene la cardinalidad máxima 1 a la que tiene N (propagación de clave). Esta es la regla habitual. </li></ul></ul><ul><ul><li>Transformar la relación en una tabla como si se tratara de una relación M:M; pero ahora la clave primaria de la tabla creada es sólo la clave primaria de la tabla a la que le corresponde la cardinalidad n. </li></ul></ul><ul><li>La opción b) se utiliza cuando: </li></ul><ul><ul><li>El número de ejemplares relacionados de la entidad que propaga su clave es muy pequeño y, por tanto, existirían muchos valores nulos en la clave propagada. </li></ul></ul><ul><ul><li>Se prevé que la relación en un futuro se convertirá en un tipo M:M </li></ul></ul><ul><ul><li>La relación tiene atributos propios y no es deseable propagarlos ( a fin de conservar la semántica ). </li></ul></ul>
  • 11. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones 1:N Modelo Relacional PROFESOR ( Cod_prof , ….., Cod_dep ) DEPARTAMENTO ( Cod_dep , … ) PROFESOR DEPARTAMENTO PERTENECE n 1 Cod_prof Cod_dep
  • 12. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de relaciones 1:1 </li></ul><ul><li>Una relación de tipo 1:1 es un caso particular de una relación 1:N, por lo que se puede aplicar las dos opciones ya comentadas: crear una nueva tabla o realizar propagación de clave, en este caso la propagación se puede hacer en ambos sentidos) </li></ul><ul><li>Los criterios para aplicar una u otra regla y para propagar la clave se basan: </li></ul><ul><ul><li>Las cardinalidades mínimas. </li></ul></ul><ul><ul><li>Recoger la mayor cantidad de semántica posible. </li></ul></ul><ul><ul><li>Evitar los valores nulos o aumentar la eficiencia. </li></ul></ul>
  • 13. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones 1:1 Si las entidades que se asocian poseen cardinalidades (0,1), suele ser conveniente transformar la relación 1:1 en una tabla. Modelo Relacional MATRIMONIO ( Cod_Hombre , Cod_Mujer) HOMBRE ( Cod_Hombre ) MUJER ( Cod_Mujer ) Clave Alternativa UNIQUE, NOT NULL HOMBRE MUJER MATRIMONIO (0,1) (0,1) Cod_Hombre Cod_Mujer
  • 14. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones 1:1 Si las entidades que participan en la interrelación poseen cardinalidades (0,1) y (1,1), conviene propagar la clave de la entidad con cardinalidades (1,1) a la tabla resultante de la entidad con cardinalidad. Modelo Relacional PROFESOR ( Cod_prof ) DEPARTAMENTO ( Cod_dep , Cod_prof ) Clave Ajena NOT NULL PROFESOR DEPARTAMENTO RESPONSABLE (1,1) (0,1) Cod_prof Cod_dep
  • 15. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones 1:1 En el caso de que ambas entidades presenten cardinalidad (1,1), se puede propagar la clave de cualquiera de ellas a la tabla resultante de la otra, teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a los datos de las tablas.
  • 16. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de atributos de relaciones Si la relación se transforma en una tabla, todos sus atributos pasan a ser columnas de la tabla. En caso de que la relación se transforme mediante propagación de clave, sus atributos migran junto a la clave a la tabla correspondiente. Cod_prof Cod_curso Nro_Horas Modelo Relacional PROFESOR ( Cod_prof , …..) IMPARTE ( Cod_prof , Cod_curso , Num_Hora ) CURSO ( Cod_curso , …) PROFESOR CURSO IMPARTE 1,n 1,n
  • 17. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Dependencias en Identificación y en Existencia. La manera de transformar una relación de este tipo es utilizar el mecanismo de propagación de clave, creando una clave ajena, con nulos no permitidos, en la tabla de la entidad dependiente, con la característica de obligar a una modificación y un borrado en cascada. Además, en el caso de dependencia en identificación la clave primaria de la tabla en la que se ha transformado la entidad débil debe estar formada por la concatenación de las claves de las dos entidades participantes. Modelo Relacional CURSO ( Cód_Curso , …. ) EDICION ( Cód_edicion, Cod_curso , ….) Clave Ajena – NOT NULL – On Delete Cascade – On Update Cascada. CURSO EDICION TIENE Cod_Curso Cod_Edición
  • 18. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de Generalización (tipos y subtipos) </li></ul><ul><li>Existen tres soluciones de transformación al modelo relacional: </li></ul><ul><ul><li>Englobar todos los atributos de la entidad y sus subtipos en una sola tabla. En general, se debe adoptar esta solución cuando los subtipos se diferencien en muy pocos atributos y las relaciones que los asocian con el resto de las entidades del esquema sean las mismas para todos (o casi todos) los subtipos. </li></ul></ul><ul><ul><li>Crear una tabla para el supertipo y tantas tablas como subtipos haya, con sus atributos correspondientes. Esta es la solución adecuada cuando existen muchos atributos distintos entre los subtipos y se quieren mantener de todas maneras los atributos comunes a todos ellos en una tabla. </li></ul></ul><ul><ul><li>Considerar tablas distintas para cada subtipo, que contengan, además de los atributos propios, los atributos comunes. Se elegirá esta opción cuando se den las mismas condiciones anteriores. </li></ul></ul>
  • 19. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Generalización (tipos y subtipos) Ejemplo: PROFESOR DOCTOR NO DOCTOR Año_doc Materia_doc
  • 20. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Generalización (tipos y subtipos) Ejemplo: Transformación Opción a) PROFESOR ( Cod_prof , nombre, ….., tipo, Año_doc, Materia_doc,..) Opción b) PROFESOR ( Cod_prof , Nombre, ….) DOCTOR ( Cod_prof , …… ) NO_DOCTOR ( Cod_prof , …..) Opción c) DOCTOR ( Cod_prof , Nombre, ……, Año_doc, ….) NO_DOCTOR ( Cod_prof , Nombre, ……)
  • 21. Transformación Modelo ER a Relacional Reglas detalladas de Transformación <ul><li>Transformación de Generalización (tipos y subtipos) </li></ul><ul><li>Aunque es posible elegir cualquiera de las tres estrategias para la transformación de un tipo y sus subtipos al modelo relacional, </li></ul><ul><li>desde un punto de vista exclusivamente semántico la opción b es la mejor. </li></ul><ul><li>desde el punto de vista de la eficiencia deberá tenerse en cuenta que: </li></ul><ul><ul><li>Opción a: el acceso a una fila que refleje toda la información de una determinada entidad es mucho más rápido (no hace falta combinar varias tablas). </li></ul></ul><ul><ul><li>Opción b: la menos eficiente aunque es la mejor desde un punto de vista exclusivamente semántico. </li></ul></ul><ul><ul><li>Opción c: Con esta solución se aumenta la eficiencia ante determinadas consultas ( las que afectan a todos los atributos, tanto comunes como propios, de un subtipo) pero se disminuye ante otras. Esta solución es la que pierde más semántica. </li></ul></ul>
  • 22. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Generalización (tipos y subtipos) Se deberá elegir una estrategia u otra dependiendo de que sea la semántica o la eficiencia la que prime para el usuario en un momento determinado.
  • 23. Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de atributos derivados No existe una representación directa. Por tanto, se deben tratar como atributos normales, que pasarán a ser columnas de la tabla correspondiente. Además se deberá, construir un disparador que calcule el valor del atributo derivado cada vez que se inserten o borren las ocurrencias de los atributos que intervienen en el calculo y añadir las restricciones correspondientes.
  • 24. Transformación Modelo ER a Relacional Ejercicios Transforme a modelo relacional los ejercicios que fueron resueltos por ustedes en la Tarea de Modelo E/R Ejercicio 1 Ejercicio 2
  • 25. Normalización Modelo Relacional <ul><li>La normalización es un concepto de las bases de datos relacionales, pero sus principios se aplican al modelamiento de datos conceptuales. </li></ul><ul><li>Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera. </li></ul><ul><li>Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relación son llamados anomalías. Los principales tipos son: </li></ul><ul><ul><li>Redundancia: la información se repite innecesariamente en muchas tuplas. </li></ul></ul><ul><ul><li>Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra. </li></ul></ul><ul><ul><li>Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación. </li></ul></ul>
  • 26. Normalización Modelo Relacional Primera Forma Normal 1FN <ul><li>Una relación está en primera forma normal si todo atributo contiene un valor atómico (valor unitario). </li></ul><ul><li>Es decir, cada atributo tiene un solo valor para cada ocurrencia de la entidad. Ningún atributo tendría valores repetidos o que conforman un grupo. </li></ul><ul><li>Ejemplos: </li></ul><ul><ul><li>Persona (cedula, nombre, apellido, sexo, teléfono, dirección ) </li></ul></ul><ul><ul><li>Los primeros cinco atributos son atómicos, lo que implica que esta relación Persona esta en 1FN. </li></ul></ul><ul><ul><li>Estudiante ( cedula, nombre, apellido, escuela, materias, notas ) </li></ul></ul><ul><ul><li>Los primeros cuatro atributos son atómicos, pero también es claro que los dos últimos no están en 1FN.Para convertirla a 1FN se proyecta en dos relaciones, obteniendo: </li></ul></ul><ul><ul><li>Estudiante (cedula, apellido, nombre, escuela) </li></ul></ul><ul><ul><li>Cursa (cedula, materia, nota ) </li></ul></ul>
  • 27. Normalización Modelo Relacional Segunda Forma Normal 2FN <ul><li>Una relación está en segunda forma normal si y solo si: </li></ul><ul><ul><li>La relación esta en 1FN </li></ul></ul><ul><ul><li>Todo atributo que no pertenece a una clave no puede depender de una parte de esa clave. </li></ul></ul><ul><li>Ejemplo: </li></ul><ul><ul><li>Proveedor ( codProv, codArt , dirProv, precio ) </li></ul></ul><ul><ul><li>Está relación esta en 1FN, pero dado lo siguiente: (codProv, codArt )  precio (precio depende de la clave primaria por completo ), (codProv)  dirProv (dirProv solo depende de una parte de la clave codProv). Por lo tanto está relación no está en 2FN, pues hay un atributo no clave (dirProv) que depende de una parte de la clave. </li></ul></ul>
  • 28. Normalización Modelo Relacional Segunda Forma Normal 2FN <ul><li>Ejemplo: </li></ul><ul><ul><li>Proveedor ( codProv, codArt , dirProv, precio ) </li></ul></ul><ul><ul><li>Para normalizar se proyecta en dos relaciones: </li></ul></ul><ul><ul><li>Proveedor ( codProv , dirProv) </li></ul></ul><ul><ul><li>ProveeArticulos ( codProv, codArt , precio) </li></ul></ul><ul><ul><li>Carro ( placa , marca, modelo, color) </li></ul></ul><ul><ul><li>Está relación está en 2FN. </li></ul></ul>
  • 29. Normalización Modelo Relacional Tercera Forma Normal 3FN <ul><li>Una relación está en tercera forma normal si y solo si: </li></ul><ul><ul><li>La relación está en 2FN. </li></ul></ul><ul><ul><li>Todo atributo que no pertenece a la clave no depende de un atributo que no es clave. </li></ul></ul><ul><li>Ejemplo: </li></ul><ul><ul><li>Carro ( placa , marca, modelo, color) </li></ul></ul><ul><ul><li>Está en 2FN, pero no en tercera forma normal, ya que el atributo marca depende del modelo y este no es parte de la clave primaria. Para normalizar se proyecta en dos relaciones. </li></ul></ul><ul><ul><li>Carro ( placa , modelo, color) </li></ul></ul><ul><ul><li>ModelosDeCarros ( modelo , marca) </li></ul></ul>
  • 30. Normalización Modelo Relacional Tercera Forma Normal 3FN <ul><li>Ejemplo: </li></ul><ul><ul><li>Orden ( id_orden , fecha, id_cliente, nombre_cliente ) </li></ul></ul><ul><ul><li>Está en 2FN pero no en 3FN, ya que el nombre del cliente depende del id_cliente que no es una clave primaria. Para normalizar se propaga de la siguiente forma: </li></ul></ul><ul><ul><li>Cliente ( id_cliente , nombre_cliente ) </li></ul></ul><ul><ul><li>Orden ( id_orden , id_cliente, fecha ) </li></ul></ul><ul><li>Un esquema normalizado hasta 3FN debe cumplir con el juramento siguiente: </li></ul><ul><li>Jura usted que cada columna de cada fila depende: </li></ul><ul><ul><li>De la clave (1FN). </li></ul></ul><ul><ul><li>De toda la clave (2FN). </li></ul></ul><ul><ul><li>Nada mas que de la clave (3FN). </li></ul></ul>
  • 31. Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) Dependencias Funcionales (FD) En el diseño de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar &quot;redundancia&quot;, otros factores sería el manejo de dependencias multivaluadas y las restricciones de integridad referencial. Una dependencia funcional en una relación R es una enunciado de la forma &quot;si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen los mismos valores para cada atributo), entonces deben concordar también con otro atributo B&quot; . Esta FD se escribiría como A1,A2,....An --> B y se dice que &quot;A1, A2,....An determina funcionalmente a B&quot;. Si por otro lado un conjunto de atributos A1,A2...An determina funcionalmente a más de un atributo. A1, A2, ……, An  B1; A1, A2, ……, An  B2 ; ….. ; A1, A2, ……, An  Bn
  • 32. Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) Dependencias Funcionales (FD) Ejemplo: Movies(title, year, length, filmType, studioName, starName) (title, year)  length; (title, year)  filmType; (title, year)  studiName; (title, year)  starName
  • 33. Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) <ul><li>Dependencias Funcionales (FD) </li></ul><ul><li>Quizás las dependencias funcionales más evidentes sean las llaves. </li></ul><ul><li>Decimos que un conjunto { A1, A2,....An } es una llave de un relación si: </li></ul><ul><ul><li>Esos atributos determinan funcionalmente a &quot;todos&quot; los demás atributos de una relación. </li></ul></ul><ul><ul><li>No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a &quot;todos&quot; los demás atributos (incluyendo al resto del conjunto { A1, A2,....An }) </li></ul></ul>
  • 34. Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) Definición FNBC Una relación esta en FNBC si y solo si las solas dependencias funcionales elementales son aquellas dentro de las cuales una clave determina un atributo. Ejemplo: Examen ( cedEst , codMat , cedProf, nota ) Dependencias Funcionales (cedEst, codMat)  cedProf (cedEst, codMat)  nota cedProf  codMat
  • 35. Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) Definición FNBC Ejemplo: Está en 3FN no esta FNBC. Para resolver el problema se proyecta para que cumpla con la FNBC: Examen ( cedEst , codMat , nota ) Dicta ( codMat , cedProf ) No se preserva la DFE (cedEst, codMat )  cedProf
  • 36. Bibliografía <ul><li>“ Introducción a los Sistemas de Base de Datos”, C. J. Date, Prentice Hall – Séptima Edición, 2001. </li></ul><ul><li>“ Bases de Datos Relacionales”, Matilde Celma Giménez & Juan Casamayor & Laura Mota, Prentice Hall, 2003. </li></ul><ul><li>Cátedra “Introducción a las bases de datos”, Profesor L. Marti, Universidad de Valparaíso, 2004. </li></ul>

×