5.

Definir los siguientes términos usados en normalización y aportar un ejemplo

de cada uno de ellos:
a) Dependencia funcional - Dada una relación que contiene los atributos 'X' e 'Y',
se dice que 'Y' depende funcionalmente de 'X' (o que 'X' determina a 'Y',
representándolo como X  Y), si para cada valor de 'X' hay asociado un único
valor de 'Y'.

b) Dependencia funcional completa - Dada una relación que contiene los

atributos: X1, X2, X3, …, Xi, …, Xj, … Xn siendo {X1, ..., Xi} el atributo clave de la
relación, se dice que el atributo Xj tiene dependencia funcional completa
respecto de la clave si toda la clave determina al atributo Xj pero ninguno de los
atributos de la clave {X1, ..., Xi} por separado (ni un subconjunto de ellos)
determina a Xj.
c) Dependencia transitiva - Si 'X', 'Y' y 'Z' son atributos de una relación, se dice que
'X' determina a 'Z' de manera transitiva a través de 'Y', si la dependencia se
establece indirectamente a través de un atributo intermedio 'Y'.

d) Determinante funcional - el atributo, o conjunto de ellos, del cual depende

funcionalmente otro atributo. Por ejemplo, si almacenamos los datos de los
ciudadanos de un país el D.N.I. es un determinante funcional pues atributos
como nombre, dirección, localidad, etc, dependen de él.
e) Dependencia multivaluada - restricción entre dos conjuntos de atributos de una
relación, que requiere que ciertas tuplas estén presentes en la misma.
6. Explicar las siguientes formas normales con las propias palabras y aportar un
ejemplo de cada una de ellas:
a) La primera forma normal 1FN – para cada tupla ha de existir una clave que se
única y no nula que esté formada por uno o varios atributos clave y cada
atributo tiene la tupla sólo puede tener un valor. No se permiten atributos
multivaluados ni compuestos.
En el ejemplo el atributo
asignatura que puede ser
múltiple, un alumno puede
cursar varias asignaturas, se
desglosa en una nueva tabla
para evitar el atributo
multivalor.
b) La segunda forma normal 2FN – la segunda norma contempla que no puede
haber atributos que no dependan completamente del identificador principal.
En caso de no depender completamente de él deben ser colocados en una
tabla diferente en la que sí que dependan de un UID.
 En el ejemplo se ve que es necesario crear una nueva tabla de proveedor ya
que número de proveedor y nombre de producto no dependen de forma
completa de número producto. Al crear la nueva tabla se solventa eso ya que
todos los atributos de cada tabla dependen del correspondiente UID.
c) La tercera forma normal 3FN – de acuerdo con
la 3ª forma normal los atributos que no son
clave deben depender exclusivamente de la
clave y no de otros atributos, prohíbe
explícitamente las dependencias transitivas
que pueden ser permitidas en 1FN y en 2FN.
En el ejemplo de la derecha se ve que
dirección de la tienda depende de nombre de
la tienda por lo que para que cumpla la 3FN ha
de crearse una nueva entidad Tienda donde
nombre y dirección dependen de la clave
principal de la entidad.

d) La Forma Normal de Boyce-Codd FNBC – es

una versión más estricta de la 3FN en la que se necesita que el determinante de
todos los atributos sea clave candidata de dicha tabla. Es decir, no admite
dependencias funcionales en las que el determinante no sea clave candidata.
 La tabla del ejemplo (clave primaria DNI) no cumple con la FNBC ya que tutor es
determinante de asignatura por lo que debemos descomponerla en dos para
que si se cumpla.

e) La cuarta forma normal 4FN – esta forma trata de evitar la redundancia de las
dependencias multivaluadas. Para esto
es necesario que se cumplan o la 3FN o
la FNBC. Para que esta norma se cumpla
no deben existir redundancias en caso
de que existan dependencias
multivaluadas en la tabla.
En el ejemplo de al lado se ve que existe
una redundancia ya que el tipo de
variedad es independiente del área de
envio por lo que si lo separamos en dos
tablas evitamos las reduncias derivadas
de tener varias entradas repetidas.

f) La quinta forma normal 5FN – se trata de la siguiente forma de normalización

que sólo se puede dar si la tabla cumple con la 4FN. De acuerdo con esta norma
las dependencias que se den en relaciones con multivalor han de estar
relacionadas a través de claves candidatas.
 En la tabla de ejemplo la clave primaria ha de ser la combinación de los tres
atributos presentes ya que sino no es posible representar todas las opciones
posibles.

Si lo dividimos en tres tablas y establecemos las claves primarias para cada

tabla podemos cubrir de manera más eficiente y con menos redundancia la
misma información que en el primer caso.

7. Realizar las siguientes revisiones partiendo del modelo relacional propuesto por
el/la consultor/a en el tablón del aula:
 a. Revisar si las tablas de este modelo relacional cumplen con la 1FN. De no ser
así, indica el cambio en la(s) tabla(s) y/o crea nuevas tablas para normalizar.
Marca los cambios en rojo.
Habría que añadir una nueva entidad/tabla N_TELEFONO con PK NIF y teléfono
como atributo ya que teléfonos puede ser un atributo multivalor. Esta manera
se crea una nueva tabla donde NIF referencia a Proveedor.
PROVEEDOR (NIF, Empresa, contacto, dirección, mail, web, registro)
TELEFONO (NIF, teléfono)
En el resto de las tablas no es necesario realizar más ajustes ya que cumplen con la
1FN, todos los atributos existentes en las tablas no pueden tener más de un valor.
b. Revisar si en el modelo resultante del punto a. las tablas cumplen con la 2FN. De no ser
así, indica el cambio en la(s) tabla(s) y/o crea nuevas tablas para normalizar. Marca los
cambios en verde.
No considero que sea necesario añadir tablas para 2FN ya que todos los atributos de las
entidades dependen siempre del identificador por lo que no es necesario ampliar la BD
con más tablas.
Entro en duda al respecto de PVP e IVA de COMADA_ELABORADOS ya que
dependen del código de producto por lo que creo que debería incluirse dentro de la
entidad ELABORADO, al igual que sucede en PLATO, ya que el PVP y el IVA de
COMANDA_PLATOS y COMANDA_ELABORADOS entiendo que se referencian en
Id_Comanda, Codigo_Plato y en Id_Comanda, Codigo_Elaborado ya que hacen
referencia al total de la comanda en vez de el precio de cada producto.
ELABORADO (Codigo_Producto, PVP, IVA)
donde {Codigo_Producto} referencia PRODUCTO
COMANDA_PLATOS (Id_Comanda, Codigo_Plato, cantidad, PVP, IVA)
donde {Id_Comanda} referencia COMANDA
donde {Codigo_Plato} referencia PLATO
COMANDA_ELABORADOS (Id_Comanda, Codigo_Producto, cantidad, PVP,
IVA)
donde {Id_Comanda} referencia COMANDA
donde {Codigo_Producto} referencia ELABORADO
c. Revisar si en el modelo resultante del punto b. las tablas cumplen con la 3FN. De no ser
así, indica el cambio en la(s) tabla(s) y/o crea nuevas tablas para normalizar. Marca los
cambios en azul.
A diferencia de lo que mis compañeros comentan en el foro de la actividad no veo que
los atributos nombre de PLATO y de PRODUCTO provoquen que se rompa la 3FN ya
que todos los demás atributos de las entidades dependen del código de producto y del
código de plato a mi parecer, es decir, es perfectamente viable identificar el producto o
el plato sin necesidad de conocer el nombre; tan solo con el identificador sería
suficiente. Por lo tanto, no existe una dependencia transitiva.
Tengo cierta duda al respecto de PVP e IVA en general, pero tras mucho reflexionarlo
no veo como se le puede hacer de otra manera por lo que decidí dejarlo como está.

Por lo tanto el resultado de normalizar la BD de la AA3 sería la siguiente:

PROVEEDOR (NIF, Empresa, contacto, dirección, mail, web, registro)
TELEFONO (NIF, teléfono)
donde {NIF} referencia a PROVEEDOR
PROVEEDOR_CATEGORÍA (NIF,idCategoría)
donde {idCategoría} referencia CATEGORIA
donde {NIF} referencia PROVEEDOR
CATEGORIA (idCategoría, Categoría)
PRODUCTO (Codigo_Producto, Nombre, unidad, Alerta_Stock, idCategoría)
donde {idCategoría} referencia CATEGORIA
INGREDIENTE (Codigo_Producto, Conservación)
donde {Codigo_Producto} referencia PRODUCTO
ELABORADO (Codigo_Producto, PVP, IVA)
donde {Codigo_Producto} referencia PRODUCTO
ALERGENO (Alergeno)
ALERGENOS_PRODUCTO (Codigo_Producto, Alergeno)
donde {Codigo_Producto} referencia PRODUCTO
donde {Alergeno} referencia ALERGENO
COMPRAS_PRODUCTO (Codigo_Producto, NIF, fecha, cantidad, precio, IVA,
caducidad)
donde {Codigo_Producto} referencia PRODUCTO
donde {NIF} referencia PROVEEDOR
DONACIONES (fecha)
DETALLE_DONACION (fecha, línea, codigo_Producto, cantidad, observaciones)
donde {Codigo_Producto} referencia PRODUCTO
TIPO_PLATOS (id_Tipo, tipo_de_plato)
PLATO (Codigo_Plato, NombrePlato, tipo_plato, Elaboración, PVP, IVA, en_menú)
donde {id_Tipo} referencia TIPO_PLATOS
INGREDIENTES_PLATO (Codigo_Plato, Codigo_Producto, Cant_Bruta,
Cant_Neta, Unidad)
donde {Codigo_Plato} referencia PLATOS
donde {Codigo_Producto} referencia INGREDIENTE
COMANDA (Id_Comanda, Fecha, Mesa, Hora, Comensales, Ticket)
COMANDA_PLATOS (Id_Comanda, Codigo_Plato, cantidad, PVP, IVA)
donde {Id_Comanda} referencia COMANDA
donde {Codigo_Plato} referencia PLATO
COMANDA_ELABORADOS (Id_Comanda, Codigo_Producto, cantidad, PVP, iva)
donde {Id_Comanda} referencia COMANDA
donde {Codigo_Producto} referencia ELABORADO