Sei sulla pagina 1di 13

UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA

CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION


PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Apuntes complementarios Normalizacion

Formas normales1
Una vez obtenido el esquema relacional resultante del esquema entidad/relacin que
representa la base de datos, normalmente tendremos una buena base de datos. Pero
otras veces, debido a fallos en el diseo o a problemas indetectables, tendremos un
esquema que puede producir una base de datos que incorpore estos problemas:
- Redundancia. Se llama as a los datos que se repiten continua e innecesariamente
por las tablas de las bases de datos. Cuando es excesiva es evidente que el diseo
hay que revisarlo, es el primer sntoma de problemas y se detecta fcilmente.
- Ambigedades. Datos que no clarifican suficientemente el elemento al que
representan. Los datos de cada fila podran referirse a ms de un ejemplar de esa
tabla o incluso puede ser imposible saber a qu ejemplar exactamente se estn
refiriendo. Es un problema muy grave y difcil de detectar.
- Prdida de restricciones de integridad. Normalmente debido a dependencias
funcionales. Ms adelante se explica este problema. Se arreglan fcilmente
siguiendo una serie de pasos concretos.
- Anomalas en operaciones de modificacin de datos. El hecho de que al insertar un
solo elemento haya que repetir tuplas en una tabla para variar unos pocos datos. O
que eliminar un elemento suponga eliminar varias tuplas necesariamente (por
ejemplo que eliminar un cliente suponga borrar seis o siete filas de la tabla de
clientes, sera un error muy grave y por lo tanto un diseo terrible).
El principio fundamental reside en que las tablas deben referirse a objetos o situaciones
muy concretas, relacionados exactamente con elementos reconocibles por el sistema de
informacin de forma inequvoca. Cada fila de una tabla representa inequvocamente un
elemento reconocible en el sistema. Lo que ocurre es que conceptualmente es difcil
agrupar esos elementos correctamente.
En cualquier caso la mayor parte de problemas se agravan si no se sigue un modelo
conceptual y se decide crear directamente el esquema relacional. En ese caso, el diseo
tiene una garanta casi asegurada de funcionar mal.
Cuando aparecen los problemas enumerados, entonces se les puede resolver usando
reglas de normalizacin. Estas reglas suelen forzar la divisin de una tabla en dos o ms
tablas para arreglar ese problema
Las formas normales se corresponden a una teora de normalizacin iniciada por el
propio Codd y continuada por otros autores (entre los que destacan Boyce y Fagin).
Codd defini en 1970 la primera forma normal, desde ese momento aparecieron la
segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.

1
http://www.jorgesanchez.net/bd/gbd2012.pdf
2 curso de administracin de sistemas informticos en red autor: Jorge Snchez www.jorgesanchez.net
Normalizacion-GD-2016 Pgina 1
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Una tabla puede encontrarse en primera forma normal y no en segunda forma normal,
pero no al contrario. Es decir los nmeros altos de formas normales son ms restrictivos
(la quinta forma normal cumple todas las anteriores).
La teora de formas normales es una teora absolutamente matemtica, pero en el
presente manual se describen de forma ms intuitiva.
Hay que tener en cuenta que muchos diseadores opinan que basta con llegar a la
forma Boyce-Codd, ya que la cuarta, y sobre todo la quinta, forma normal es polmica.
Hay quien opina que hay bases de datos peores en quinta forma normal que en tercera.
En cualquier caso debera ser obligatorio para cualquier diseador llegar hasta la forma
normal de Boyce-Codd.

PRIMERA FORMA NORMAL (1FN)


Es una forma normal inherente al esquema relacional. Es decir toda tabla realmente
relacional la cumple.
Se dice que una tabla se encuentra en PRIMERA FORMA NORMAL si impide que un atributo
de una tupla pueda tomar ms de un valor.

No cumple la primera forma normal. Esa tabla s esta en primera forma normal.

Visualmente es una tabla, pero no una tabla


relacional (lo que en terminologa de bases de
datos relacionales se llama relacin).

DEPENDENCIAS FUNCIONALES

Por ejemplo el nombre de una PERSONA depende funcionalmente del DNI; es decir para un
DNI concreto slo hay un nombre posible. En la tabla del ejemplo anterior, el
DEPARTAMENTO no tiene dependencia funcional, ya que para un mismo DNI puede haber
ms de un departamento posible. Pero el nombre s que depende del DNI.

Normalizacion-GD-2016 Pgina 2
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Por ejemplo en una tabla de CLIENTES, el conjunto de atributos formado por el nombre y el
DNI producen una dependencia funcional sobre el atributo apellidos. Pero no es plena ya
que el DNI individualmente, tambin produce una dependencia funcional sobre apellidos.
El DNI s produce una dependencia funcional completa sobre el campo apellidos.

Por ejemplo si X es el atributo Nmero de Clase de un INSTITUTO, e Y es el atributo Cdigo


Tutor. Entonces XY (el TUTOR depende funcionalmente del nmero de CLASE). Si Z
representa el Cdigo del departamento, entonces YZ (el cdigo del departamento
depende funcionalmente del cdigo tutor, cada TUTOR slo puede estar en un
DEPARTAMENTO). Como ocurre que Y-/X (el cdigo de la clase no depende funcionalmente
del cdigo tutor, un cdigo tutor se puede corresponder con varios cdigos de clase).
Entonces X Z (el cdigo del departamento depende transitivamente del cdigo de la
clase).

Normalizacion-GD-2016 Pgina 3
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

SEGUNDA FORMA NORMAL (2FN)


Ocurre si una tabla est en primera forma normal y adems 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 slo de parte de la clave, entonces esa parte de la clave y esos atributos
formarn otra tabla.
La tabla no es 2FN. Esta tabla s esta 2FN.

Suponiendo que el DNI y el cdigo de curso formen


una clave principal para esta tabla, slo la nota
tiene dependencia funcional completa. El nombre y
los apellidos dependen de forma completa del DNI.

TERCERA FORMA NORMAL (3FN)


Ocurre cuando una tabla est en 2FN y adems ningn atributo que no sea clave
depende transitivamente de las claves de la tabla.
Es decir no ocurre cuando algn atributo depende funcionalmente de atributos que no
son clave.
La tabla no est 3FN. Esta tabla s esta 3FN.

La Provincia depende funcionalmente del cdigo


de provincia.

Normalizacion-GD-2016 Pgina 4
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

FORMA NORMAL DE BOYCE-CODD (FNBC O BCFN)


Ocurre si una tabla est en tercera forma normal y adems todo determinante es una
clave candidata.

No est en FNBC. Si est en FNBC.

La cuestin es que un trabajador o trabajadora puede


trabajar en varios departamentos. En dicho
departamento hay varios responsables, pero cada
trabajador slo tiene asignado uno. El detalle
importante que no se ha tenido en cuenta, es que el o
la responsable slo puede ser responsable en un
departamento.
Este detalle ltimo produce una dependencia funcional
ya que: RESPONSABLE DEPARTAMENTO En las formas de Boyce-Codd
Por lo tanto hemos encontrado un determinante que hay que tener cuidado al
no es clave candidata. No est por tanto en FNBC. descomponer ya que se podra
perder informacin por una
En este caso la redundancia ocurre por mala seleccin
mala descomposicin
de clave. La redundancia del departamento es
completamente evitable.

DEPENDENCIAS MULTIVALUADAS
Para el resto de formas normales (las diseadas por Fagin, mucho ms complejas), es
importante definir este tipo de dependencia, que es distinta de las funcionales. Si las
funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd),
stas son la base de la cuarta forma normal.

Normalizacion-GD-2016 Pgina 5
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Se refiere a posibles valores (en plural) y se trata de que los valores de ese atributo
siempre sean los mismos segn el valor de un atributo y no del otro.
La tabla cursos, profesores y materiales del curso.

La tabla est en FNBC ya que no hay dependencias transitivas y todos los atributos son
clave sin dependencia funcional hacia ellos.
Sin embargo hay redundancia. Los materiales se van a repetir para cualquier profesor
dando cualquier curso, ya que los profesores van a utilizar todos los materiales del
curso (de no ser as no habra ninguna redundancia). Los materiales del curso dependen
de forma multivaluada del curso y no del profesor en una dependencia multivaluada (no
hay dependencia funcional ya que los posibles valores son varios). Para el par N de
curso y Profesor podemos saber los materiales; pero lo sabemos por el curso y no por
el profesor.

CUARTA FORMA NORMAL (4FN)


Ocurre esta forma normal cuando una tabla est en forma normal de Boyce Codd y toda
dependencia multivaluada no trivial es una dependencia funcional.
Son triviales aquellas dependencias multivaluadas en las que el conjunto formado por el
determinante y el implicado no forman la clave primaria de la tabla y adems el
implicado no forma parte del determinante: es decir si X->>Y y adems Y X y X,Y no
es la clave de la tabla, tenemos una dependencia multivaluada no trivial (como ocurre
en el ejemplo anterior). Para la tabla anterior la solucin seran dos tablas:

Normalizacion-GD-2016 Pgina 6
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

DEPENDENCIAS DE JOIN
Una proyeccin de una tabla es la tabla resultante de tomar un subconjunto de los
atributos de una tabla (se trata de la operacin proyeccin, , del lgebra relacional). Es
decir una tabla formada por unas cuantas columnas de la tabla original. La operacin
JOIN procedente tambin del lgebra relacional, consiste en formar una tabla con la
unin de dos tablas. La tabla resultante estar formada por la combinacin de todas
las columnas y filas de ambas, excepto las columnas y filas repetidas.

QUINTA FORMA NORMAL (5FN) O FORMA NORMAL DE PROYECCIN-UNIN


Ocurre cuando una tabla est en 4FN y cada dependencia de unin (JOIN) en ella es
implicada por las claves candidatas.
Es la ms compleja y polmica de todas. Polmica pues no est claro en muchas
ocasiones est muy claro que el paso a 5FN mejore la base de datos. Fue definida
tambin por Fagin. Es raro encontrarse este tipo de problemas cuando la normalizacin
llega a 4FN. Se deben a restricciones semnticas especiales aplicadas sobre la tabla.

Indican cdigos de material suministrado por un proveedor y utilizado en un


determinado proyecto. As vista la tabla, no permite ninguna proyeccin en la que no
perdamos datos.
Pero si ocurre una restriccin especial como por ejemplo: Cuando un proveedor nos ha
suministrado alguna vez un determinado material, si ese material aparece en otro
proyecto, haremos que el proveedor anterior nos suministre tambin ese material para
el proyecto.
Eso ocurre en los datos como el proveedor nmero 1 nos suministr el material nmero
1 para el proyecto 2 y en el proyecto 1 utilizamos el material 1, aparecer la tupla
proveedor 1, material 1 y proyecto 1. Si un nuevo proyecto necesitara el material 1,
entonces habr que pedirlo a los proveedores 1 y 2 (ya que en otros proyectos les henos
utilizado)
La dependencia de reunin que produce esta restriccin es muy difcil de ver ya que es
lejana.
Para esa restriccin esta proyeccin de tablas sera vlida:

Normalizacion-GD-2016 Pgina 7
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Esa descomposicin no pierde valores en este caso, sabiendo que si el proveedor nos
suministra un material podremos relacionarle con todos los proyectos que utilizan ese
material.
Resumiendo, una tabla no est en quinta forma normal si hay una descomposicin de
esa tabla que muestre la misma informacin que la original y esa descomposicin no
tenga como clave la clave original de la tabla.

FORMA NORMAL DE DOMINIO CLAVE (FNDC)


Se la conoce ms con sus siglas en ingls DKNF. Se trata de una forma normal
enunciada tambin por Fagin en 1981 al darse cuenta de los problemas de redundancia
que ocurran con algunos dominios.
En este caso no se bas en dependencias entre los datos, sino que se bas en
restricciones de dominio y restricciones de clave.
- RESTRICCIONES DE DOMINIO. Se trata de la restriccin que hace que un determinado
atributo obtenga slo ciertos valores, los que estn de acuerdo a la definicin de un
determinado dominio.
- RESTRICCIN DE CLAVE. Es la restriccin que permite que un atributo o un conjunto de
atributos forme una clave candidata.
Fagin dice que una tabla est en FNDC si toda restriccin sobre la tabla es consecuencia
lgica de aplicar las restricciones de dominio y clave sobre la misma.
Fagin demostr que si esto ocurra la tabla incluso estaba en 5FN

Normalizacion-GD-2016 Pgina 8
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Observando los datos de la tabla se observa que cuando la nota es superior a 9, en el


nivel aparece la palabra alto, cuando es un 7 o un 8 medio, y un 5 o 6 sera medio. Es
decir tenemos restricciones que no son ni de dominio ni de clave en esa tabla.
Lo lgico sera:

No se pierde informacin al disear las tablas de esta forma y de hecho es ms eficiente


para la base de datos.

Normalizacion-GD-2016 Pgina 9
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

Gua de Ejercicios
Aplicar las reglas de normalizacin los siguientes ejercicios.
1. Un dato sin normalizar no cumple con ninguna regla de normalizacin. Para explicar
con un ejemplo en qu consiste cada una de las reglas, vamos a considerar los datos
de la siguiente tabla.

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado Num_art nom_art cant Precio
2301 23/02/11 101 Martin Caracas 3786 Red 3 35,00
2301 23/02/11 101 Martin Caracas 4011 Raqueta 6 65,00
2301 23/02/11 101 Martin Caracas 9132 Paq-3 8 4,75
2302 25/02/11 107 Herman Coro 5794 Paq-6 4 5,00
2303 27/02/11 110 Pedro Maracay 4011 Raqueta 2 65,00
2303 27/02/11 110 Pedro Maracay 3141 Funda 2 10,00

PRIMERA FORMAL NORMAL (1FN)


Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido
para NUM_ART, NOM_ART, CANT y PRECIO. La 1FN prohbe 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 PK de la tabla base y el grupo repetido.
Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y
ARTICULOS_ORDENES

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado)


Articulos_ordenes (id_orden, num_art, nom_art, cant, precio)

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado
2301 23/02/11 101 Martin Caracas
2302 25/02/11 107 Herman Coro
2303 27/02/11 110 Pedro Maracay
Articulos_ordenes
Id_orden Num_art nom_art cant Precio
2301 3786 Red 3 35,00
2301 4011 Raqueta 6 65,00
2301 9132 Paq-3 8 4,75
2302 5794 Paq-6 4 5,00
2303 4011 Raqueta 2 65,00
2303 3141 Funda 2 10,00

SEGUNDA FORMAL NORMAL (2FN)


Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar
cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a
seguir son:

Normalizacion-GD-2016 Pgina 10
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

- Determinar cules columnas que no son llave no dependen de la llave 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 PK de la cual
dependen.
La tabla ORDENES est en 2FN. Cualquier valor nico de ID_ORDEN determina un slo
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 NOM_ART son dependientes de NUM_ART, pero no son
dependientes de ID_ORDEN. Lo que haremos a continuacin 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.
Las tablas quedan ahora de la siguiente manera.

Articulos_ordenes (id_orden, num_art, cant)

Articulos_ordenes
Id_orden Num_art cant
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_art nom_art Precio
3786 Red 35,00
4011 Raqueta 65,00
9132 Paq-3 4,75
5794 Paq-6 5,00
3141 Funda 10,00

TERCERA FORMAL NORMAL (3FN)


La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave
que sea dependiente de otra columna no llave. Los pasos a seguir son:
- Determinar las columnas que son dependientes de otra columna no llave.
- Eliminar esas columnas de la tabla base.
Crear una segunda tabla con esas columnas y con la columna no llave de la cual son
dependientes.
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.

Normalizacion-GD-2016 Pgina 11
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

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

ordenes (id_orden, fecha, id_cliente)

Ordenes
Id_orden Fecha Id_cliente
2301 23/02/11 101
2302 25/02/11 107
2303 27/02/11 110

Clientes (id_cliente, nom_cliente, estado)

Ordenes
Id_cliente Nom_cliente Estado
101 Martin Caracas
107 Herman Coro
110 Pedro Maracay
Por lo tanto la base de datos queda de la siguiente manera:
ordenes (id_orden, fecha, id_cliente)
Clientes (id_cliente, nom_cliente, estado)
Articulos ( num_art, nom_art, precio)
Articulos_ordenes (id_orden, num_art, cant)

2. La empresa COLOMBIAN SYSTEMS lo ha contratado como el Ingeniero Encargado


para sistematizar la facturacin. En la siguiente FACTURA DE COMPRA VENTA, usted
debe analizar toda la informacin disponible y aplique el proceso de normalizacin,
hasta llegar a la Tercera Forma Normal.
Se pide realizar la respectiva justificacin 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: Nmero de la factura de compra venta
FECHA_FAC: Fecha de la factura de compra venta
NOM_CLIENTE: Nombre del cliente
DIR_CLIENTE: Direccin del cliente
RIF_CLIENTE: Rif del cliente
CIUDAD_CLIENTE: Ciudad del cliente
TELEF_CLIENTE: Telfono del cliente
CATEGORIA: Categora del producto
COD_PROD: Cdigo del producto
DESCRIPCION: Descripcin del producto
VAL_UNIT: Valor unitario del producto
CANT_PROD: Cantidad de productos q compra el cliente
La llave primaria es Nmero de Factura de venta: NUM_FAC

Normalizacion-GD-2016 Pgina 12
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI

3. Dada la siguiente relacin PRESTAMO_LIBROS (Colegio, profesor, asignatura_habilidad, aula,


curso, libro, editorial, fecha_prestamo) que contiene informacin relativa a los prestamos que
realizan las editoriales a los profesores de primaria de los colegios para su evaluacin en
alguna de las asignaturas/habilidades que imparten.
Se pide aplicar las reglas de normalizacin y obtener su modelo relacional, indicar sus claves,
atributos principales.
Asignatura/
Colegio Profesor Aula Curso Libro Editorial Fecha_prestamo
habilidad
Aprender y
C.P 1er
Juan Prez Pensamiento Lgico 1.A01 ensear en Gra 09/09/2010
Cervantes Grado
educacin infantil
C.P 1er Preescolar Tcnicas
Juan Prez Escritura 1.A01 05/05/2010
Cervantes Grado Rubio,N56 Rubio
Aprender y
C.P Pensamiento 1er
Juan Prez 1.A01 Ensear en Gra 05/05/2010
Cervantes Numrico Grado
educacin infantil
Pensamiento
C.P Alicia 1er Educacin Infantil Prentice
Espacial, Temporal 1.B01 06/05/2010
Cervantes Garca Grado N9 Hall
y causal
Aprender y
C.P Alicia Pensamiento 1er
1.B01 ensear en Gra 06/05/2010
Cervantes Garca Numrico Grado
educacin infantil
Aprender y
C.P Andrs 2do
Escritura 1.A01 ensear en Gra 09/09/2010
Cervantes Fernndez Grado
educacin infantil
Saber educar:
C.P Andrs 2do Temas de
Ingles 1.A01 gua para Padres 05/05/2010
Cervantes Fernndez Grado Hoy
y Profesores
Saber educar:
C.P Juan 1er Temas de
Pensamiento Lgico 2.B01 gua para Padres 18/12/2010
Quevedo Mndez Grado Hoy
y Profesores
Aprender y
C.P Juan Pensamiento 1er
2.B01 ensear en Gra 06/05/2010
Quevedo Mndez Numrico Grado
educacin infantil

4. Se tiene una relacin del REPORTE_MATRICULA (cdigo_alumno, nombre_alumno,


especialidad, cdigo_curso, nombre_curso, nombre_docente, oficina, seccin) se pide aplicar
las reglas de normalizacin llegando hasta las 3FN.
Cdigo/ Nombre/ Cdigo/ Nombre/
Especialidad Nombre_curso Oficina curso
alumno alumno curso docente
382145A Luis Zuloaga Industrial MA123 Matemtica 2 Carlos Arambulo CB-214 U
382145A Luis Zuloaga Industrial QU514 Fsica Qumica Petra Rondinel CB-110 U
382145A Luis Zuloaga Industrial AU521 Descriptiva Vctor Moncada CB-120 W
360247k Ral Rojas Sistemas PA714 Investigacin 1 Cesar Fernadez SC-220 V
360247k Ral Rojas Sistemas MA123 Matemtica 2 Carlos Arambulo CB-214 V
360247k Ral Rojas Sistemas AU511 Dibujo Vctor Moncada CB-120 U

5. Se presenta una base de datos de una biblioteca, aplicar las reglas de normalizacin
simplificando hasta la tercera forma normal.
Prestamos_libro (codLibro, Titulo, Autor, Editorial, NombreLector, Fechadev)
codLibro Titulo Autor Editorial nombreLector Fechadev
1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ros Tern, Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca, Ren 16/04/2005
1006 Oracle University Nancy Greenberg y Priya Nathan Oracle Corp. Garca Roque, Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Gmez, Juan 18/04/2005

Normalizacion-GD-2016 Pgina 13

Potrebbero piacerti anche