Unidad III. Base de Datos 1 Normalización NORMALIZACION DE BASE DE DATOS RELACIONALES Términos Básicos para Investigar
Views 275 Downloads 15 File size 892KB
Unidad III. Base de Datos 1 Normalización
NORMALIZACION DE BASE DE DATOS RELACIONALES Términos Básicos para Investigar Clave primaria Clave candidata tupla Dependencias multivaluadas Dependencias parciales
Prof. Verónica Carreño
Dependencias transitivas Dependencias funcionales Dependencias triviales Dependencia parcial
Qué es la normalización La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos. La normalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo, desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos más simple agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de referencia para simplificar una estructura de datos compleja. Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera. Existen seis niveles formas de normalización: Primera Forma Normal (1NF), Segunda Forma Normal (2NF), Tercera Forma Normal (3NF), Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesitamos. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.
Primera Forma Normal (1FN)
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Una tabla se encuentra en primera forma normal si impide que un atributo de una tupla pueda tomar más de un valor Los Pasos a seguir son: Tenemos que eliminar los grupos repetidos. Tenemos que crear una nueva tabla con la clave de la tabla base y el grupo repetido.
Segunda Forma Normal (2FN)
La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la a primaria de la tabla para identificarlos. Es decir, ocurre si una tabla está en primera forma normal y además cada atributo que no sea clave, depende de forma funcional completa respecto de cualquiera de las claves. Toda la clave principal debe hacer dependientes al resto de atributos, si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos atributos formarán otra tabla. Los Pasos a seguir son: Determinar cuáles columnas que no son clave no dependen de la clave primaria de la tabla. Eliminar esas columnas de la tabla base. Crear una segunda tabla con esas columnas y la(s) columna(s) de la clave de la cual dependen
Tercera Forma Normal (3FN)
Una tabla está normalizada en esta forma si todas las columnas que no son clave son funcionalmente dependientes por completo de la clave primaria y no hay dependencias transitivas. Una dependencia transitiva es aquella en la cual las columnas que no son clave son dependientes de otras columnas que tampoco son clave Es decir, sucede cuando una tabla está en 2FN y además ningún atributo que no sea clave depende transitivamente de las claves de la tabla, es por ello que no ocurre cuando algún atributo depende funcionalmente de atributos que no son clave. Los Pasos a seguir son: Determinar las columnas que son dependientes de otra columna no clave. Eliminar esas columnas de la tabla base. Crear una segunda tabla con esas columnas y con la columna no clave de la cual son dependientes
Forma Boyce Codd (BCNF)
Es una versión ligeramente más fuerte de la 3FN. La forma normal de BoyceCodd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales). Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En términos menos formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.
4º Forma Normal (4FN)
Una tabla está en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. Una dependencia multivaluada de una tabla con atributos X, Y, Z de X sobre Z (es decir X->>Z) ocurre cuando los posibles valores de Y sobre cualquier par de valores X y Z dependen sólo del valor de X y son independientes de Z. Se refiere a posibles valores (en plural) y se trata de que los valores de ese atributo siempre son los mismos según el valor de un atributo y no del otro La definición de la 4NF confía en la noción de una dependencia multivaluada, para suprimir la redundancia de relaciones muchos a muchos. Los Pasos a seguir son: Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples. Construir varias tablas, donde cada una almacena datos para solamente uno de los atributos de valores múltiples.
¿Qué tan lejos debe llevar la normalización?
La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de nosotros. Si nuestra base de datos va a proveer información a un solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo exagerado. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel más alto no tenga sentido ¿Se están dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que nosotros como diseñadores de la base de datos, necesitamos decidir, y la experiencia y el sentido común nos pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta, más bien subjetiva.
Ejemplos 1º Ejemplo
ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio) Ordenes Id_orden
Fecha
Id_client e
Nom_client e
Estado
Num_art
nom_art
Precio
Red Raqueta Paq-3
can t 3 6 8
2301
23/02/11
101
Martin
Caracas
3786 4011 9132
2302
25/02/11
107
Herman
Coro
5794
Paq-6
4
5,00
2303
27/02/11
110
Pedro
Maraca y
4011 3141
Raqueta Funda
2 2
65,00 10,00
35,00 65,00 4,75
Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohibe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son: » Tenemos que eliminar los grupos repetidos. » Tenemos que crear una nueva tabla con la tabla base y el grupo repetido. Los registros quedan ahora conformados en dos tablas que llamemos ORDENES y ARTICULOS_ORDENES Ordenes Id_orde Fecha n 2301 23/02/1 1 2302 25/02/1 1 2303 27/02/1 1 Articulos_ordenes Id_orde Num_ar n t 2301 3786 2301 4011 2301 2302
9132 5794
Id_clien te 101
Nom_clien te Martin
107
Herman
110
Pedro
nom_ar t Red Raquet a Paq-3 Paq-6
cant
Estad o Caraca s Coro Marac ay
3 6
Preci o 35,00 65,00
8 4
4,75 5,00
2303
4011
2303
3141
Raquet a Funda
2
65,00
2
10,00
Ahora procederemos a aplicar la 2FN, es decir, tenemos que eliminar cualquier columna no clave que no dependa de la clave primaria de la tabla La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN. Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen. Ordenes (id_orden, fecha, id_cliente, Ordenes Id_orde Fecha Id_clien Nom_clien Estad n te te o 2301 23/02/1 101 Martin Caraca 1 s 2302 25/02/1 107 Herman Coro 1 2303 27/02/1 110 Pedro Marac 1 ay Articulos_ordenes (id_orden, num_art, cant) Articulos_ordenes Id_orde Num_a cant n rt 2301 3786 3 2301 4011 6 2301 9132 8 2302 5794 4 2303 4011 2 2303 3141 2 Articulos ( num_art, nom_art, precio) Articulos Num_ar nom_ar Preci t t o 3786 Red 35,00 4011 Raquet 65,00
Nom_cliente,
estado)
9132 5794 3141
a Paq-3 Paq-6 Funda
4,75 5,00 10,00
La 3FN nos dice que tenemos que eliminar cualquier columna no clave que sea dependiente de otra columna no clave. Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria. Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se muestran a continuación. Articulos_ordenes (id_orden, num_art, cant) Articulos_ordenes Id_orde Num_a cant n rt 2301 3786 3 2301 4011 6 2301 9132 8 2302 5794 4 2303 4011 2 2303 3141 2 Articulos ( num_art, nom_art, precio) Articulos Num_ar nom_ar Preci t t o 3786 Red 35,00 4011 Raquet 65,00 a 9132 Paq-3 4,75 5794 Paq-6 5,00 3141 Funda 10,00 ordenes (id_orden, fecha, id_cliente) Ordenes Id_orde Fecha Id_clien n te 2301 23/02/1 101 1 2302 25/02/1 107
2303
1 27/02/1 110 1
Clientes (id_cliente, nom_cliente, estado) Ordenes Id_clien Nom_clien Estad te te o 101 Martin Caraca s 107 Herman Coro 110 Pedro Marac ay 2º Ejemplo Normalizar la siguiente tabla
Visualmente la 1º tabla no una tabla relacional (lo que en terminología de bases de datos relacionales se llama (Relación). No cumple la primera forma normal. Lo cumpliría si: 1FN
En la 2º tabla suponiendo que el DNI y el código de curso formen una clave principal para esta tabla, sólo la nota tiene dependencia funcional completa. El nombre y los apellidos dependen de forma completa del DNI. La tabla no es 2FN, para arreglarlo 2FN
La Provincia depende funcionalmente del código de provincia, lo que hace que no esté en 3FN. El arreglo sería 3FN
3º Ejemplo A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con un ejemplo simplificado de una base de datos para una pequeña biblioteca. CodLibro
Titulo
Autor
Editorial
NombreLector
FechaDev
1001
Variable compleja
Murray Spiegel
McGraw Hill
Pérez Juan
15/04/2005
1004
Visual Basic 5
E. Petroustsos
Anaya
Ríos Terán, Ana
17/04/2005
1005
Estadística
Murray Spiegel
McGraw Hill
Roca, René
16/04/2005
1006
Nancy Oracle University Greenberg Priya Nathan
García Luis
Roque,
20/04/2005
1007
Clipper 5.01
Pérez Juan
Gómez,
Ramalho
y Oracle Corp.
McGraw Hill
Gómez,
18/04/2005
Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos, pues el nombre del lector es un campo que puede (y conviene)
descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla. 1NF CodLibro Titulo
Autor
Editorial
Paterno Materno Nombres FechaDev
1001
Variable compleja
Murray Spiegel
McGraw Hill
Pérez
Gómez
Juan
15/04/2005
1004
Visual Basic 5
E. Petroustsos
Anaya
Ríos
Terán
Ana
17/04/2005
1005
Estadística
Murray Spiegel
McGraw Hill
Roca
René
16/04/2005
1006
OracleUniversity NancyGreenberg Oracle Corp. García
Roque
Luis
20/04/2005
1006
OracleUniversity Priya Nathan
Oracle Corp. García
Roque
Luis
20/04/2005
1007
Clipper 5.01
McGraw Hill
Gómez
Juan
18/04/2005
Ramalho
Pérez
Como se puede ver, hay cierta redundancia característica de 1NF. La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro. Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra tabla. 2NF CodLib Titulo ro
Autor
Editorial McGraw H ill
1001
Variable compleja
Murray Spieg el
1004
Visual Basic 5
E. Petroustso Anaya s
1005
Estadística
Murray Spieg el
1006
Oracle Univer NancyGreenb Oracle Cor sity erg p.
1006
Oracle Univer Priya Nathan sity
Oracle Cor p.
1007
Clipper 5.01
McGraw H ill
Ramalho
McGraw H ill
La nueva tabla sólo contendrá datos del lector.
CodLec Pater Mater Nombr tor no no es 501
Pérez
Góme Juan z
502
Ríos
Terán
503
Roca
504
Garcí Roque Luis a
Ana René
Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de la base de datos necesita que exista otra tabla para mantener la información de qué libros están prestados a qué lectores. Esta tabla se muestra a continuación: CodLi bro
CodLec FechaD tor ev
1001
501
15/04/2 005
502
17/04/2 005
1005
503
16/04/2 005
1006
504
20/04/2 005
1007
501
18/04/2 005
1004
Para la Tercera Forma Normal (3NF) la relación debe estar en 2NF y además los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. También recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente información sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa. En nuestro ejemplo en 2NF, la primera tabla conserva información acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF. 3NF
CodLibr Titulo o 1001
Variable compleja
1004
Visual Basic 5
1005
Estadística
1006
Oracle Univers ity
1007
Clipper 5.01
CodAut Autor or 801
Murray Spiegel
802
E. Petroustsos
803
Nancy Greenb erg
804
Priya Nathan
806
Ramalho
CodEditori Editorial al 901
McGraw Hi ll
902
Anaya
903
Oracle Cor p.
Aunque hemos creado nuevas tablas para que cada una tenga sólo información acerca de una entidad, también hemos perdido la información acerca de qué autor ha escrito qué libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.
CodLibr codAut o or 1001
801
1004
802
1005
801
1006
803
1006
804
1007
806
CodLibr codEditori o al 1001
901
1004
902
1005
901
1006
903
1007
901
Y el resto de las tablas no necesitan modificación. CodLe ctor
Pater Mater Nombr no no es
501
Pérez Góme Juan z
502
Ríos
503
Roca
504
Garcí Roque Luis a
Terán
Ana René
CodLibro CodLector FechaDev 1001
501
15/04/2005
1004
502
17/04/2005
CodLibro CodLector FechaDev 1005
503
16/04/2005
1006
504
20/04/2005
1007
501
18/04/2005
4º Ejemplo Aplique la forma Boyce Codd
Esa tabla está en tercera forma normal (no hay dependencias transitivas), pero no en forma de Boyce - Codd, ya que (DNI, Asignatura) →Tutor y Tutor→Asignatura. En este caso la redundancia ocurre por mala selección de clave. La redundancia de la asignatura es completamente evitable. La solución sería:
En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podría perder información por una mala descomposición 5º Ejemplo Aplique la 4FN
La dependencia multivaluada es funcional, entonces quedan dos tablas
Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y y X,Z reproducen sin perder información lo que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN 6º Ejemplo Consideremos una afinidad (tabla) llamada estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura: Clave
Especialidad
Curso
S01
Sistemas
Natación
S01
Bioquímica
Danza
S01
Sistemas
Natación
B01
Bioquímica
Guitarra
C03 Civil Natación En esta tabla existen dependencias de valores múltiples Las dependencias de valores múltiples se definen de la siguiente manera: Clave ->->Especialidad y Clave->->Curso; Esto se lee "Clave multidetErmina a Especialidad, y clave multidetermina a Curso" Para nuestro ejemplo, las tablas correspondientes son: Tabla Especialidad Clave Especialidad S01 B01 C03
Sistemas Bioquímica Civil
Tabla Curso Clave Curso S01
Natación
S01
Danza
B01
Guitarra
C03
Natación
7º Ejemplo En la siguiente tabla aplique la 4FN
Y su solución se presentaría de la siguiente manera:
8º Ejemplo
Un ejemplo de una tabla BCNF es la siguiente, teniendo en cuenta que cada estudiante puede tener más de un tutor:
Referencia cruzada de Tutor/Estudiante El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la tabla son: • {ID Tutor, ID Estudiante} • {Número de seguro social del tutor, ID Estudiante} Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las claves candidatas. La FNBC es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidato (o superconjunto de eso). La dependencia de ID Tutor en Número de seguro social del tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba no está en FNBC Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la tabla de arriba podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor. En este caso, corregir el problema sería una simple cuestión de usar solo un esquema de identificación para los tutores: o el ID, o el número del seguro social, pero no ambos. ID TUTOR ID ESTUDIANTE 1078 31850 1078 37921 1293 46224 1480 31850
Ejercicios Propuestos 1. FACTURA DE COMPRA VENTA: La empresa COLOMBIAN SYSTEMS lo ha contratado como el “Ingeniero Encargado” para sistematizar la facturación. En la siguiente FACTURA DE COMPRA VENTA, usted debe analizar toda la información disponible y aplique el proceso de normalización, hasta llegar a la Tercera Forma Normal. Se pide realizar la respectiva justificación detallada de cada uno de los pasos que conduzcan al resultado final. Factura(NUM_FAC, FECHA_FAC, NOM_CLIENTE, DIR_CLIENTE, RIF_CLIENTE, CIUDAD_CLIENTE, TELEF_CLIENTE, CATEGORIA, COD_PROD, DESP_PROD, VAL_UNIT, CANT_PROD) Donde: NUM_FAC: Número de la factura de compra venta FECHA_FAC: Fecha de la factura de compra venta NOM_CLIENTE: Nombre del cliente DIR_CLIENTE: Dirección del cliente RIF_CLIENTE: Rif del cliente CIUDAD_CLIENTE: Ciudad del cliente TELEF_CLIENTE: Teléfono del cliente CATEGORIA: Categoría del producto COD_PROD: Código del producto DESCRIPCION: Descripción del producto VAL_UNIT: Valor unitario del producto CANT_PROD: Cantidad de productos q compra el cliente La llave primaria es Número de Factura de venta: NUM_FAC 2. EMPRESA DE ENVIO DE MERCANCIA: a continuación se agrupan todos los atributos que hacen parte de la base de datos para aplicarle las reglas de normalización. Donde se incluyen los nombres de los atributos con su significado * GUIA_NO = Numero de Guia * GUIA_FECHA= Fecha de la Guia * GUIA_HORA= Hora de la Guia * ORGN_RIF = Identificacion de Empresa Origen * ORGN_NOM = Nombre de Empresa Origen * ORGN_ACT = Actividad Comercial de Empresa Origen * ORGN_CIUDAD= Ciudad de Empresa Origen * ORGN_DIR = Direccion de Empresa Origen * ORGN_TEL = Telefono de Empresa Origen
* ORGN_CEL = Celular de Empresa Origen * DEST_ID = Identificacion del destinatario * DEST_NOM = Nombre del destinatario * DEST_COD_CIUDAD = Codigo de la ciudad del destinatario * DEST_CIUDAD= Ciudad del destinatario * DEST_DIR = Direccion del destinatario * DEST_TEL = Telefono del destinatario * DEST_KM = Distancia kilometraje de Ciudad origen a ciudad del destinatario * CODIGO = Codigo del paquete * TIPO = Tipo de paquete * NOMBRE = Nombre del paquete * DESCRIPCION = Descripción del paquete * VALR_ FLETE = Valor del flete 3. Video club: En una tienda de video se necesita mantener información de alrededor de 3000 casetas cada uno de los casetes tiene asignado un número por cada `película se necesita conocer un titulo y categoría por ejemplo: comedia, suspenso, drama, acción, ciencia ficción, etc. Se mantienen algunas copias de muchas películas. Se le da a cada película una identificación y se mantiene seguimiento de lo que contiene cada casete. Un casete puede venir en varios formatos y una película es grabada en un solo casete; frecuentemente las películas son pedidas de acuerdo a un actor especifico Tom Cruise y Demi More son los más populares es por esto que se debe mantener información de los actores que pertenecen a cada película. No en todas las películas actúan artistas famosos, a los clientes de la tienda le gusta conocer datos como el nombre real del actor, y su fecha de nacimiento. En la tienda se mantienen información solo de los actores que aparecen en las películas y que se tiene a disposición. Solo se alquila videos a aquellos que pertenecen al club de videos. Para pertenecer al club se debe tener un buen crédito. Por cada miembro del club se mantiene una ficha con su nombre, teléfono y dirección, cada miembro del club tiene asignado un número de membresía. Se desea mantener información de todos los casetes que un cliente alquila, cuando un cliente alquila un casete se debería conocer el nombre de la película, la fecha en la que se alquila y la fecha de devolución. Se pide aplicar las reglas de normalización hasta la tercera forma normal, teniendo las siguientes entidades con sus respectivos atributos: Alquiler (cod_alquiler, num_membresia, cod_cliente, nom_cliente, dir_cliente, telef_cliente, cod_cassette, fecha_alquiler, fecha_dev, valor_alquiler, cantidad) Cassettte (cod_cassette, num_copias, formato, cod_pelicula, titulo, categoría, cod_actor, nom_actor, fechanac_actor, cod_tipo)
Donde: cod_alquiler = Codigo del alquiler num_membresia = Numero de membresia cod_cliente = código del cliente nom_cliente = nombre del cliente dir_cliente = dirección del cliente telef_cliente = teléfono del cliente cod_cassette = código del cassette fecha_alquiler = fecha del alquiler del al película fecha_dev = fecha de devolución de la pelicula valor_alquiler = valor del alquiler de la película cantidad = cantidad de película alquilada num_copias = números de copias de cassette formato = formato del cassette titulo = nombre de la película categoría = categoría de la película cod_actor = código del actor nom_actor = nombre del actor fechanac_actor = fecha de nacimiento del actor cod_tipo = código del tipo de película. 4. Dada la siguiente relación PRESTAMO_LIBROS (Colegio, profesor, asignatura_habilidad, aula, curso, libro, editorial, fecha_prestamo) que contiene información relativa a los prestamos que realizan las editoriales a los profesores de primaria de los colegios para su evaluación en alguna de las asignaturas/habilidades que imparten. Se pide aplicar las reglas de normalización y obtener su modelo relacional, indicar sus claves, atributos principales. Colegio
Profesor
Asignatura/ habilidad
Aula
Curs o
C.P Cervante s
Juan Pérez
Pensamient o Lógico
1.A0 1
1er Grado
C.P Cervante s
Juan Pérez
Escritura
1.A0 1
1er Grado
C.P Cervante s
Juan Pérez
Pensamient o Numérico
1.A0 1
1er Grado
C.P Cervante
Alicia García
Pensamient o Espacial,
1.B0 1
1er Grado
Libro Aprender y enseñar en educación infantil Preescola r Rubio,N5 6 Aprender y Enseñar en educación infantil Educación Infantil N9
Editoria l
Fecha_prestam o
Graó
09/09/2010
Técnica s Rubio
05/05/2010
Graó
05/05/2010
Prentice Hall
06/05/2010
Temporal y causal
s C.P Cervante s
Alicia García
Pensamient o Numérico
1.B0 1
1er Grado
C.P Cervante s
Andrés Fernánde z
Escritura
1.A0 1
2do Grado
C.P Cervante s
Andrés Fernánde z
Ingles
1.A0 1
2do Grado
C.P Quevedo
Juan Méndez
Pensamient o Lógico
2.B0 1
1er Grado
C.P Quevedo
Juan Méndez
Pensamient o Numérico
2.B0 1
1er Grado
Aprender y enseñar en educación infantil Aprender y enseñar en educación infantil Saber educar: guía para Padres y Profesore s Saber educar: guía para Padres y Profesore s Aprender y enseñar en educación infantil
Graó
06/05/2010
Graó
09/09/2010
Temas de Hoy
05/05/2010
Temas de Hoy
18/12/2010
Graó
06/05/2010
5. Se tiene una relación del REPORTE_MATRICULA (código_alumno, nombre_alumno, especialidad, código_curso, nombre_curso, nombre_docente, oficina, sección) se pide aplicar las reglas de normalización llegando hasta las 3FN Código/ alumno 382145 A 382145 A 382145 A 360247 k 360247 k 360247
Nombre/ alumno Luis Zuloaga Luis Zuloaga Luis Zuloaga
Especialid ad
Código/ curso
Nombre_curs o
Industrial
MA123
Matemática 2
Industrial
QU514
Física Química
Industrial
AU521
Descriptiva
Raúl Rojas
Sistemas
PA714
Investigación 1
Raúl Rojas
Sistemas
MA123
Matemática 2
Raúl Rojas
Sistemas
AU511
Dibujo
Nombre/ docente Carlos Arambulo Petra Rondinel Víctor Moncada Cesar Fernadez Carlos Arambulo Víctor
Oficina
curs o
CB-214
U
CB-110
U
CB-120
W
SC-220
V
CB-214
V
CB-120
U
k
Moncada
6. Se presenta una base de datos de una biblioteca, aplicar las reglas de normalización simplificando hasta la tercera forma normal. Prestamos_libro (codLibro, Titulo, Autor, Editorial, NombreLector, Fechadev) codLibro
Titulo
Autor
Editorial
nombreLector
Fechadev
Variable compleja
Murray Spiegel
McGraw Hill
Pérez Gómez, Juan
15/04/2005
1004
Visual Basic 5
E. Petroustsos
Anaya
Ríos Terán, Ana
17/04/2005
1005
Estadística
Murray Spiegel
McGraw Hill
Roca, René
16/04/2005
1006
Oracle University
Nancy Greenberg y Priya Nathan
Oracle Corp.
García Roque, Luis
20/04/2005
1007
Clipper 5.01
Ramalho
McGraw Hill
Pérez Gómez, Juan
18/04/2005
1001
7. UTILIZACIÓN DE RECURSOS DE LA UNIVERSIDAD: Dada la siguiente relación UTILIZACIÓN (DNI_Prof, Nombre_Prof, Despacho_Prof, Recurso, Ubicación, Fecha_inicio, Fecha_fin,) que contiene información relativa a la utilización de los recursos de la universidad por parte de los profesores en periodos de tiempo DNI_Prof 33456456 44556689 33456456 11223344 99771122 33456456 99887766 33456456
Nombre_Prof P. Martínez L. Moreno P. Martínez E. Castro D. Cuadra P. Martínez F. Calle P. Martínez
Despacho_Prof 2.2.B05 2.2.A10 2.2.B05 2.2.B23 2.1.B23 2.2.B05 2.1.C11 2.2.B05
Recurso R122 R100 R200 R122 R200 R300 R300 R122
Descripción Tablet PC Impresora Portátil Tablet PC Portátil Scaner Scaner Tablet PC
Fecha_inicio 1-1-2007 1-1-2007 12-1-2007 16-1-2007 23-1-2007 1-1-2007 1-2-2007 1-2-2007
Fecha_fin 15-1-2007 15-1-2007 22-1-2007 31-1-2007 26-1-2007 15-1-2007 6-2-2007 6-2-2007
8. TURNOS DE TRABAJO: Dada la siguiente relación ASIGNACIÓN (DNI, Nombre, Código_Tienda, Dirección_Tienda, Fecha, Turno) que contiene información relativa a la asignación de los turnos de trabajo de los empleados de los distintos centros de una cadena de tiendas de moda: DNI 33456456 44556689 99771122 33456456 11223344
Nombre P. Martín L. Sanz D. Díaz P. Martín E. López
Código_Tienda 100A 100A 100A 200B 300C
Dirección _Tienda Avd. Mayor, 23, Alcorcón Avd. Mayor, 23, Alcorcón Avd. Mayor, 23, Alcorcón C/ Sur 13, Alcorcón Pl. Central, Getafe
Turno M M T T M
Fecha 2/9/06 2/9/06 2/9/06 3/9/06 3/9/06
99887766 11223344 99887766 44556689 33456456
F. Monte E. López F. Monte L. Sanz P. Martín
200B 300C 100A 100A 200B
C/ Sur 13, Alcorcón Pl. Central, Getafe Avd. Mayor, 23, Alcorcón Avd. Mayor, 23, Alcorcón C/ Sur 13, Alcorcón
M M M T M
3/9/06 4/9/06 4/9/06 4/9/06 5/9/06
9. ACTIVIDADES DEPORTIVAS: Dada la siguiente relación SE REALIZA(Cod_Actividad, Nombre_Actividad, DNI_Monitor, Nombre_monitor, Sala, Fecha, Hora_I, Hora_F) utilizada para almacenar información sobre la fecha y duración de las actividades deportivas que se organizan en un colegio Se pide: