Vous êtes sur la page 1sur 36
Unidad V
Unidad V
Unidad V Bases de Datos Transformación Modelo ER a Relacional - Normalización Sergio Sánchez Rios. Ingeniero

Bases de Datos

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

Sergio Sánchez

Transformación Modelo ER a Relacional Tres reglas básicas
Transformación Modelo ER a Relacional
Tres reglas básicas

Las tres reglas básicas para convertir un esquema en el modelo E/R al relacional son las siguientes:

1) Todo tipo de entidad se convierte en una relación.

2) Todo tipo

relación.

de

relación M:M (muchos a muchos) se transforma en

una

3) 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.

Sergio Sánchez

Transformación Modelo ER a Relacional Tres reglas básicas
Transformación Modelo ER a Relacional
Tres reglas básicas

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:

  • Las relaciones M:M no se distinguen de las entidades (ambas se

transforman en tablas).

  • Las 1:M se suelen representar mediante una propagación de clave, desapareciendo incluso el nombre de la relación.

Sergio Sánchez

Codigo ESCRIBE Nombre_a Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo Nombre_e EDITORIAL 1
Codigo
Codigo
ESCRIBE
ESCRIBE
Nombre_a
Nombre_a
Codigo ESCRIBE Nombre_a Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo Nombre_e EDITORIAL 1

Transformación Modelo ER a Relacional

Tres reglas básicas - Ejemplo

Codigo ESCRIBE Nombre_a Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo Nombre_e EDITORIAL 1
Nombre_e
Nombre_e
EDITORIAL
EDITORIAL

1

EDITA
EDITA
LIBRO
LIBRO

n

n

 

AUTOR

 

n

LIBRO( Código, Título, Idioma, …, Editorial)
LIBRO( Código, Título, Idioma, …, Editorial)
Codigo ESCRIBE Nombre_a Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo Nombre_e EDITORIAL 1
Codigo ESCRIBE Nombre_a Transformación Modelo ER a Relacional Tres reglas básicas - Ejemplo Nombre_e EDITORIAL 1

AUTOR( Nombre_a, Nacionalidad, Institución)

ESCRIBE(Nombre_a, Código)

CLAVE AJENA

EDITORIAL( Nombre_e, Dirección, Ciudad, País)

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Atributos de Entidades Atributos Identificadores

Los atributos que son identificadores principales pasan a formar la clave primaria de la tabla.

Atributos Identificadores Alternativos

Se les denomina mediante un cláusula denomina UNIQUE.

Atributos No Identificadores

Se representan solo como columnas de la tabla correspondiente.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Atributos de Entidades

Dirección Cod_Prof Télefono Nombre PROFESOR Materia DNI
Dirección
Cod_Prof
Télefono
Nombre
PROFESOR
Materia
DNI
Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Atributos de Entidades Dirección Cod_Prof

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),

PROFESOR

Cod_prof

Nombre

DNI

Dirección

Teléfono

Materia

           
           

Sergio Sánchez

UNIQUE (DNI) );

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Atributos de Entidades Atributos Multivaluados

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.

Además, se debe crear una clave ajena referenciado a la tabla primaria.

Cod_Prof Nombre PROFESOR n Télefono
Cod_Prof
Nombre
PROFESOR
n
Télefono

Persona ( dni, nombre, ……)

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Atributos de Entidades  Atributos

CLAVE AJENA

Telefonos ( dni, número )

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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_prof
   
 

PROFESOR

 

n

IMPARTE
IMPARTE
 

n

   
 

CURSO

Cod_curso
Cod_curso
Modelo Relacional PROFESOR ( Cod_prof, ….. ) CURSO ( Cod_curso )
Modelo Relacional
PROFESOR ( Cod_prof,
…..
)
CURSO ( Cod_curso )

IMPARTE ( Cod_curso, Cod_prof )

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de relaciones 1:N

Existen dos soluciones:

  • 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.

  • 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.

La opción b) se utiliza cuando:

  • 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.

  • Se prevé que la relación en un futuro se convertirá en un tipo M:M

  • La relación tiene atributos propios y no es deseable propagarlos ( a fin de conservar la semántica ).

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de relaciones 1:N

Cod_prof
Cod_prof
   
 

PROFESOR

 

n

PERTENECE
PERTENECE
 

1

   
 

DEPARTAMENTO

Cod_dep
Cod_dep

Modelo Relacional

PROFESOR ( Cod_prof,

….., Cod_dep )
…..,
Cod_dep )

DEPARTAMENTO (Cod_dep, )

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de relaciones 1:1

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)

Los criterios para aplicar una u otra regla y para propagar la clave se basan:

  • Las cardinalidades mínimas.

  • Recoger la mayor cantidad de semántica posible.

  • Evitar los valores nulos o aumentar la eficiencia.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Cod_Hombre
Cod_Hombre
   
 

HOMBRE

 

(0,1)

MATRIMONIO
MATRIMONIO
 

(0,1)

   
 

MUJER

Cod_Mujer
Cod_Mujer

Modelo Relacional

MATRIMONIO (Cod_Hombre, Cod_Mujer)

HOMBRE ( Cod_Hombre ) MUJER ( Cod_Mujer )
HOMBRE ( Cod_Hombre )
MUJER ( Cod_Mujer )

Sergio Sánchez

Clave Alternativa UNIQUE, NOT NULL

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Cod_prof
Cod_prof
   
 

PROFESOR

 

(1,1)

RESPONSABLE
RESPONSABLE
 

(0,1)

   
 

DEPARTAMENTO

Cod_dep
Cod_dep

Modelo Relacional

PROFESOR ( Cod_prof )

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de relaciones 1:1 Si las entidades

DEPARTAMENTO ( Cod_dep, Cod_prof )

Sergio Sánchez

Clave Ajena NOT NULL

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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_prof
   
 

PROFESOR

 

1,n

Nro_Horas IMPARTE
Nro_Horas
IMPARTE
 

1,n

   
 

CURSO

Cod_curso
Cod_curso

Modelo Relacional

PROFESOR ( Cod_prof, ..)

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de atributos de relaciones Si la

IMPARTE ( Cod_prof, Cod_curso, Num_Hora )

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de atributos de relaciones Si la

CURSO ( Cod_curso, )

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Dependencias en Identificación y en
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.

Cod_Curso CURSO
Cod_Curso
CURSO
TIENE
TIENE
   

EDICION

Cod_Edición
Cod_Edición

Modelo Relacional CURSO ( Cód_Curso, . ) EDICION ( Cód_edicion, Cod_curso, .)

Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Dependencias en Identificación y en

Sergio Sánchez

Clave Ajena NOT NULL On Delete Cascade On Update Cascada.

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Generalización (tipos y subtipos)

Existen tres soluciones de transformación al modelo relacional:

  • a) 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.

  • b) 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.

  • c) 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.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Generalización (tipos y subtipos)

Ejemplo:

PROFESOR

   
Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Generalización (tipos y subtipos) Ejemplo:
Transformación Modelo ER a Relacional Reglas detalladas de Transformación Transformación de Generalización (tipos y subtipos) Ejemplo:
Año_doc
Año_doc
Materia_doc
Materia_doc
DOCTOR
DOCTOR

NO DOCTOR

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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, ……)

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
Transformación Modelo ER a Relacional
Reglas detalladas de Transformación

Transformación de Generalización (tipos y subtipos)

Aunque es posible elegir cualquiera de

las

tres

estrategias

para

la

transformación de un tipo y sus subtipos al modelo relacional,

  • desde un punto de vista exclusivamente semántico la opción b es la mejor.

  • desde el punto de vista de la eficiencia deberá tenerse en cuenta que:

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).

Opción b:

  • la

menos eficiente aunque es la

mejor desde un punto de vista

exclusivamente semántico.

  • 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.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Sergio Sánchez

Transformación Modelo ER a Relacional Reglas detalladas de Transformación
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.

Sergio Sánchez

Transformación Modelo ER a Relacional Ejercicios
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

Sergio Sánchez

Normalización Modelo Relacional
Normalización Modelo Relacional

La normalización es un concepto de las bases de datos relacionales, pero sus

principios se aplican al modelamiento de datos conceptuales.

Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera.

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:

Redundancia: la información se repite innecesariamente en muchas tuplas.

Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra.

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.

Sergio Sánchez

Normalización Modelo Relacional Primera Forma Normal 1FN
Normalización Modelo Relacional
Primera Forma Normal 1FN

Una relación está en primera forma normal si todo atributo contiene un valor

atómico (valor unitario).

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.

Ejemplos:

  • Persona (cedula, nombre, apellido, sexo, teléfono, dirección )

Los primeros cinco atributos son atómicos, lo que implica que esta relación Persona esta en 1FN.

  • Estudiante ( cedula, nombre, apellido, escuela, materias, notas )

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:

Estudiante (cedula, apellido, nombre, escuela) Cursa (cedula, materia, nota )

Sergio Sánchez

Normalización Modelo Relacional Segunda Forma Normal 2FN
Normalización Modelo Relacional
Segunda Forma Normal 2FN

Una relación está en segunda forma normal si y solo si:

  • La relación esta en 1FN

  • Todo atributo que no pertenece a una clave no puede depender de una

parte de esa clave.

Ejemplo:

  • Proveedor ( codProv, codArt, dirProv, precio )

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.

Sergio Sánchez

Normalización Modelo Relacional Segunda Forma Normal 2FN
Normalización Modelo Relacional
Segunda Forma Normal 2FN

Ejemplo:

  • Proveedor ( codProv, codArt, dirProv, precio )

Para normalizar se proyecta en dos relaciones:

Proveedor (codProv, dirProv) ProveeArticulos (codProv, codArt, precio)

  • Carro ( placa, marca, modelo, color) Está relación está en 2FN.

Sergio Sánchez

Normalización Modelo Relacional Tercera Forma Normal 3FN
Normalización Modelo Relacional
Tercera Forma Normal 3FN

Una relación está en tercera forma normal si y solo si:

  • La relación está en 2FN.

  • Todo atributo que no pertenece a la clave no depende de un atributo que

no es clave.

Ejemplo:

  • Carro (placa, marca, modelo, color)

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.

Carro (placa, modelo, color) ModelosDeCarros ( modelo, marca)

Sergio Sánchez

Normalización Modelo Relacional Tercera Forma Normal 3FN
Normalización Modelo Relacional
Tercera Forma Normal 3FN

Ejemplo:

  • Orden ( id_orden, fecha, id_cliente, nombre_cliente )

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:

Cliente ( id_cliente, nombre_cliente )

Orden ( id_orden, id_cliente, fecha )

Un esquema normalizado hasta 3FN debe cumplir con el juramento siguiente:

  • Jura usted que cada columna de cada fila depende:

    • De la clave (1FN).

    • De toda la clave (2FN).

    • Nada mas que de la clave (3FN).

Sergio Sánchez

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC)
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 "redundancia", 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 "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" . Esta FD se escribiría como

A2,....An

determina funcionalmente a B".

A1,A2,....An

--> B y se dice que "A1,

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

Sergio Sánchez

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC)
Normalización Modelo Relacional
Forma Normal de Boyce-Codd (FNBC)

Dependencias Funcionales (FD)

Ejemplo:

Movies(title, year, length, filmType, studioName, starName)

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC) Dependencias Funcionales (FD) Ejemplo: Movies(title, year, length, filmType,

(title, year) length; (title, year) filmType; (title, year) studiName; (title, year) starName

Sergio Sánchez

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC)
Normalización Modelo Relacional
Forma Normal de Boyce-Codd (FNBC)

Dependencias Funcionales (FD)

Quizás las dependencias funcionales más evidentes sean las llaves.

Decimos que un conjunto { A1, A2,

....

An

} es una llave de un relación si:

Esos atributos determinan funcionalmente a "todos" los demás atributos de una relación.

No hay un subconjunto de { A1, A2,

An

} que determine funcionalmente a "todos"

....

An })

.... los demás atributos (incluyendo al resto del conjunto { A1, A2,

Sergio Sánchez

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC)
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

Sergio Sánchez

Normalización Modelo Relacional Forma Normal de Boyce-Codd (FNBC)
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

Sergio Sánchez

Bibliografía
Bibliografía
  • “Introducción a los Sistemas de Base de Datos”, C. J. Date,

Prentice Hall Séptima Edición, 2001.

  • “Bases de Datos Relacionales”, Matilde Celma Giménez &

Juan Casamayor & Laura Mota, Prentice Hall, 2003.

  • Cátedra “Introducción a las bases de datos”, Profesor L. Marti,

Universidad de Valparaíso, 2004.

Sergio Sánchez