Ejemplo de Normalización con Modelo Entidad Relación y Modelo Relacional

1/21 Prof. Dubraska Delgado
A la hora de levantar información en
una organización, es frecuente que el
personal esté inmerso en sus
actividades rutinarias y no
cuente con el tiempo necesario
para otorgar todos los detalles
requeridos en una entrevista.
Los formatos utilizados en la
empresa para el registro de sus
transacciones u operaciones son
una fuente fiable de información,
algunos por su simplicidad no
requiere de tantos detalles para
comprenderlos y otros es
conveniente analizarlos con información o detalles que permitan facilitar el análisis de los elementos
constitutivos.
¿Qué debo hacer en caso de tener un formato?
La sugerencia siempre es considerar todo lo que observa en el documento, cada detalle cuenta, por tal
motivo, puede emplear cualquier estrategia que considere, ir de izquierda a derecha, de arriba, abajo, pero
recuerde incluir todo lo observable en el Documento:
o Dia/Mes/año
o Nº Factura
o Razón Social/ Señor
o R.I.F./C.I.
o Dirección
o Vendedor
o TOTAL
o Cantidad
o Descripción
o Precio Unitario
o Sub Total
o Iva___%
o Total
Listar es una forma de ver agrupaciones sin dejar de lado datos relevantes, que pueden no mostrarse de
forma continua o agrupada en el documento, la recomendación es marcar o tachar los elementos que ya
consideraste para identificar el final del proceso.
A partir de aquí se sigue la rutina que ya conoces, pero tu experiencia en materia de identificación de
entidades es fundamental para facilitar el proceso.
Día/Mes/Año: / /
.
Nº FACTURA:
.
FACTURA
Razón
Social/Señor:
R.I.F./C.I.
:
Dirección
:
Vendedor:
Cantidad Descripción Precio Unitario Total
Subtotal
Iva ____%
TOTAL
NORMALIZACIÓN
EJERCICIO RESUELTO PARTIENDO DE FORMATOS

Como no se cuenta con una descripción, la lógica te ayudará a establecer agrupaciones adecuadas de
elementos. Es importante destacar que el nombre del documento siempre es una entidad, porque toda
transacción debe ser reflejada, no es un objeto real sino más bien abstracto, en este caso estamos
trabajando con una Factura, la definición es esencialmente la misma, refleja las ventas de una empresa,
en el que describe cada uno de los productos adquiridos por un cliente; pero la forma de presentación y
los detalles que incluye varían de una organización a otra.
A la hora de trabajar un formato uno debe hacerse preguntas claves para ayudarte a determinar las
entidades, como siempre reflejan transacciones hay preguntas ineludibles tales como:
¿Quién emite el documento?
¿Cuál es el nombre del formato documento que se emite?
¿A quién se Emite el documento?
Estas interrogantes definen la transacción, que siempre involucra dos partes interesadas, pero es
importante identificar el contenido, porque desde esa óptica hay otro conjunto de datos relevantes, cuál es
el producto o bien que se intercambia, o qué se desea controlar, son ejemplos de interrogantes que puedes
formularte. La esencia de esa interrogante es Por qué o para qué se emite el documento? Son preguntas
claves acerca del contenido o la justificación que tiene un formato específico.
Partiendo de las ideas previas iniciemos nuestro análisis:
¿Quién lo emite?
La empresa u organización, en nuestro caso representado por un vendedor
¿Cuál es el nombre del formato que se emite?
Nuestro formato es la Factura
¿A quién se Emite?
Al cliente
¿Por qué se emite el documento?
Para detallar los productos adquiridos por un cliente en una fecha específica
Por lo tanto, nuestras entidades potenciales son: FACTURA, VENDEDOR, CLIENTE, PRODUCTO,
recuerde que siempre las entidades se escriben en letras mayúsculas y en singular.
ENTIDADES POTENCIALES
VENDEDOR
FACTURA
CLIENTE
PRODUCTO
Identificar Entidades
Paso 1:

En este punto nos centraremos en el listado de elementos asignando a las entidades potenciales que
definimos en el paso previo las características o atributos del documento listados inicialmente.
Es de resaltar que todos los elementos deben pertenecer a una entidad, es posible que te surjan dudas a la
hora de asignar los atributos en ese caso siempre es recomendable iniciar por lo más simple, lo que puedas
hacer a simple vista sin complicarte, eso reduce tiempo y nos libra de estrés innecesario lo restante se deja
en la última entidad que casi siempre es el documento que analizamos. Si la lógica te dice que algo no está
del todo bien, y definitivamente piensas que algunos elementos no tienen cabida en las entidades existentes
entonces debes formularte interrogantes que te permitan incorporar entidades que resuelvan tu inquietud.
En nuestro caso nos centraremos en lo que evidenciamos originalmente, partiremos de lo más evidente a
lo más complejo
LISTADO DE ATRIBUTOS ENTIDAD
o Dia/Mes/año
o Nº Factura
o Razón Social/ Señor
o R.I.F./C.I.
o Dirección
o Vendedor
o Cantidad
o Descripción
o Precio Unitario
o Total
o Sub Total
o Iva___%
o TOTAL
VENDEDOR( nombre
CLIENTE(Razón Social/Señor, RIF/CI,
Dirección
PRODUCTO(cantidad, descripción, precio
Unitario, Total
Luego de esta asignación nos queda claro que tributos van en la entidad FACTURA. Empleamos la
técnica de descarte, dado que no siempre es evidente que elementos a incorporar. Quedando
definitivamente de la siguiente manera:
ENTIDADES POTENCIALES CANDIDATAS A ENTIDAD
VENDEDOR VENDEDOR (nombre, )
FACTURA FACTURA (NºFactura, fecha, Iva, subtotal,TOTAL)
CLIENTE CLIENTE (Razón Social/Señor, RIF/CI, Dirección)
PRODUCTO PRODUCTO (cantidad, descripción, precio Unitario, Total)
Asignar atributos
Paso 2:

Este es un paso importante en la definición del modelo, busquemos las posibles Llaves primarias partiendo
de los datos presentes, luego de lo que nosotros conocemos acerca de la transacción o reglas del negocio
para establecer su análisis. Siga las siguientes consideraciones:
a. Para cada Entidad Potencial busquemos en los atributos presentes, aquel o aquellos que permiten
identificarlo de manera única.
b. Si alguna entidad no tiene un atributo o combinación de atributos que los identifique de manera
única proceda a incorporar una llave primaria.
c. Puede completar información a las entidades, recuerde que debe ser coherente, aún cuando no se
necesite para este formulario en particular forma parte de la definición de una entidad específica.
Apliquemos las recomendaciones a las entidades verificando cada uno de sus atributos:
a. En la entidad VENDEDOR en nuestro análisis previo sólo consideramos el nombre del vendedor,
este atributo por si solo no identifica de manera única ya que puede darse el caso que dos vendedores
tengan el mismo nombre, a tal efecto debe agregarse atributos, y considerar dos posibles llaves
primarias: Cédula o asignar un número de vendedor, adicionalmente puede incluir otros atributos
en este caso incluimos: apellido, dirección, teléfono… hasta completar la mínima información básica
b. En la entidad FACTURA, consideramos como llave primaria Nº Factura
c. En la entidad CLIENTE, la llave primaria RIF/CI y el teléfono para completar los datos básicos
d. En la entidad PRODUCTO agregamos un atributo CódigoProducto pues en los presentes no se
tiene ninguno que lo defina de manera única, podríamos pensar en el atributo Descripción como
posible llave primaria pero puede darse el caso que existan dos descripciones exactamente iguales
por tal motivo la descartamos, tomando así el Códigoproducto
Luego de lo cual nuestro análisis conduce a la siguiente definición:
CANDIDATAS A ENTIDAD
VENDEDOR (nombre, CódigoVen, cédula, apellido, dirección Teléfono )
FACTURA (NºFactura, fecha, Iva, Subtotal, TOTAL)
CLIENTE (Razón Social/Señor, RIF/CI, Dirección, teléfono)
PRODUCTO (cantidad, descripción, precio Unitario, Total, codigoProducto)
Definir Claves Principales
Paso 3:

Las relaciones se construyen en pares, las interrogantes que formulamos en el primer paso para
reconocer las entidades funciona para establecer las relaciones principales, las secundarias
atienden a las reglas que la lógica establezca o al conocimiento que se tiene de un sistema determinado.
Partiendo de ello estableceremos las relaciones básicas que identificamos en el PASO 1
Un Cliente Emite una Factura
La Factura es emitida a un cliente
La Factura tiene productos
Note que desde esta perspectiva evitamos una relación errónea entre Cliente- Vendedor, que si bien
es cierto que se comunican y llegan acuerdos no necesariamente conducirá a una venta efectiva, a las
organizaciones les he indiferente la cantidad de clientes que atiende pero es muy importante lograr la
venta pues finalmente es esa la transacción que interesa registrar y que dirá que tan buen vendedor es
el empleado.
En otras palabras, aunque cliente y vendedor se vinculan, no lo hacen de manera directa sino a través
de la transacción que en este caso es la FACTURA
Un VENDEDOR ¿Cuántas FACTURAS emite? Emite muchas Facturas
Una FACTURA ¿Es emitida por cuántos VENDEDORES? Es emitida por un solo Vendedor
A un CLIENTE se le emiten ¿Cuántas FACTURAS ? se le puede emitir muchas Facturas
Y esa FACTURA ¿Es emitida a cuántos CLIENTES? Es emitida A un solo CLIENTE
Una factura ¿contiene Cuántos PRODUCTOS? Contiene muchos Productos
Un PRODUCTO ¿Está contenido en cuántas FACTURAS? Está contenida en muchas
FACTURAS
Estableciendo Relaciones
Paso 4:
VENDEDOR FACTURA
Emite
CLIENTE FACTURA
Emite
PRODUCTO FACTURA
contiene

En esta fase se integra todos los pasos previos en la diagramación de un modelo, en este caso partiremos
del Modelo Entidad- Relación. Siguiendo las siguientes recomendaciones:
o Ubicar siempre la entidad asociada al documento manejado en el centro, pues todos los
objetos están vinculados al mismo.
o Cuidar la ubicación de las entidades evitando en lo posible los cruces de líneas.
o Recuerde que en este modelo se considera la definición de entidades
o Muestre las entidades en singular con letras mayúsculas, los atributos en letras minúsculas
y las llaves primarias subrayadas y con un asterico (*)
Construir el Modelo
Paso 5:
RazonSocia
Direcció
Teléfon
*RIF/C
I
CLIENTE
VENDEDOR
nombre
Direcció
Teléfon
*CodVe
ndeor
Apellid
cédul
Emi
Emi
Tot
PRODUCTO
PrecioUnitario
Descripció
Cantida
*CodigoProd
Contien
Fech
Iva Subtota
*NroFactur
a
TOTAL
FACTURA

Para convertir al modelo relacional se siguen reglas muy básicas:
 En las Relación Uno a uno, es independiente de cual clave principal se convierte en llave
foránea.
 En la relación Uno a muchos; la clave principal del lado Uno de la relación pasa a formar
parte de la tabla del lado mucho para establecer la relación entre las entidades.
 En la relación Muchos a muchos; se crea una nueva Tabla, cuya clave principal es la
unión delas claves principales de ambas entidades.
En nuestro ejercicio tenemos una relación Muchos a muchos por eso se crea una nueva tabla, las otras
relaciones son del tipo Uno a muchos, así que lo que se hace es incorporar un nuevo atributo en la
entidad del lado mucho
Convertir a Modelo Relacional
Paso 6:
Razón Social
*RIF/CI
Direccion
Teléfono
CLIENTE
Nombre
*CódigoVen
Cédula
Apellido
Dirección
Teléfono
VENDEDOR
CódigoVen
fecha,
Iva
RIF/CI
SubTotal
TOTAL
*NºFactura
FACTURA
Precio Unitario
*CódigoProducto
Descripción
Cantidad
Total
PRODUCTO
* NºFactura
*CódigoProducto
PROD/FACT
∞
1
∞
∞
1
1
∞
1

La Normalización es una técnica de refinamiento que busca mejorar el diseño inicial de nuestro
modelo, realizando sistemáticamente cambios, hasta minimizar la redundancia o la presencia de
datos innecesarios o mal ubicados.
Se puede partir del modelo relacional inicial, y se aplicar el análisis de las Formas Normales entidad,
por entidad hasta completar el diseño, se realizan los cambios pertinentes, dibujando nuevamente
el modelo mejorado, y estas acciones se repiten hasta completar el estudio de la última forma
normal.
Para que se cumpla la primera forma normal se debe:
a. Eliminar de la relación los atributos calculados o derivados, es decir aquellos que se obtienen de
otros valores contenidos en la misma Tabla o entidad.
b. Se debe eliminar los datos repetidos.
c. Lograr que todos los atributos esté en forma atómica, es decir, en su mínima expresión de
forma tal que no pueda descomponerse.
Comencemos el análisis Entidad por Entidad, estudiando todos y cada uno de los atributos
TABLA CLIENTE
¿Existen campos calculados o Derivados?
No se presentan campos calculados o que puedan obtenerse a partir de otros
atributos en la misma tabla
¿Existen grupos de datos Repetidos?
En este caso no hay grupos de datos repetitivos, sin embargo cuando uno se está
iniciando en el proceso, no es tan evidente, por tal razón, es bueno presentar
registros de una entidad o Tuplas para que analice los registros y verifique que no
hay datos que se repita en varios registros
Razón Social *RIF/CI Dirección Teléfono
Pasteles Morán C.A. J123456789-2 Av los Caobos, esquina Palo Verde,
edificio Arauca
0269-2321143
Israel Moronta 25.280.322 Urb. Cristal Azul, calle Zafiro casa 32,
Centro
0414-1112233
Israel Moronta 17.123.345 Urb. Cristal Azul, calle Gema casa 123 0416-4445566
Aplicar Formas Normales
Paso 7:
PRIMERA FORMA NORMAL (1FN)
Una relación está en 1FN si y solo si cada uno de los atributos contiene
un único valor para una tupla determinada (valor atómico), es decir,
cuando está formada por una estructura plana, en la que no existen
grupos repetitivos, en la que cada dato toma un solo valor.
Razón Social
*RIF/CI
Dirección
Teléfono
CLIENTE

Notemos que aunque tenemos dos clientes cuyo nombre y apellido coinciden no se refiere a la misma
persona o razón social, ningún registro tiene conjunto de datos exactamente iguales por eso se dice
que no hay grupo de datos repetitivos.
¿Todos los atributos están en forma atómica?
En otras palabras se puede descomponer en más partes? los atributos RazónSocial, teléfono y RIF
aunque están constituidos por varias palabras son visto como una unidad inseparable por lo cual se
puede concluir que se presentan en forma atómica
Ahora bien, el atributo Dirección puede ser descompuesto en varios elementos como: calle o AV.,
casa o Edificio, Número, sector, ciudad.
Luego de los cambios gestados la tabla CLIENTE quedaría
TABLA VENDEDOR
No se presentan campos calculados o que puedan obtenerse a partir de otros
atributos en la misma tabla
Veamos Algunos registros o tuplas para verificar si existen grupos de datos
repetitivos.
Nombre Apellido *Código
Vendedor
Dirección Teléfono
Yolanda Anaís Vera
Puerta
15921345 Av los Caobos, esquina Palo
Verde, edificio Arauca
0269-2321143
Santiago José Cruz
Duarte
23.280.122 Urb. Cristal Azul, calle Zafiro
casa 32, Centro
0414-1112233
Nati Andreína Salas
Quiróz
27.123.344 Urb. Cristal Azul, calle Gema
casa 123
0416-4445566
Nati Amelia Salas
Quiróz
27.123.345 Urb. Cristal Azul, calle Gema
casa 123
0416-4445527
Como puede observarse aunque hay registros que a primera vista parecen coincidir, vemos que los
pequeños detalles marcan las diferencias, por lo tanto, no existen grupos de datos repetitivos-
Calle/Av
Numero
Casa /Edificio
Sector
Ciudad
Dirección
Razón Social
*RIF/CI
Dirección
Teléfono
CLIENTE
Razón Social
*RIF/CI
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
CLIENTE
Nombre
*CódigoVen
Cédula
Apellido
Dirección
Teléfono
VENDEDOR

Los registros previos pueden ayudarnos a conocer si la entidad tienen todos sus atributos de forma
atómica, observe que los campos nombre, apellido, Dirección pueden descomponerse en sub grupos o
partes que tienen sentido en sí mismos.
El campo nombre no se presenta de manera atómica ya que puede ser dividido en: Primer Nombre y
segundo Nombre, igual se cumple con el campo apellido que puede ser subdividido en: Primer y
Segundo Apellido, por su parte la dirección se puede subdividir tal como lo hicimos con la dirección
del Cliente en:calle o AV., casa o Edificio, Número, sector, ciudad. El resto de los campo se presentan
en forma atómica.
Luego de los cambios gestados la tabla VENDEDOR quedaría
TABLA FACTURA
Si se tiene campos calculados o que puedan obtenerse a
partir de otros atributos en la misma tabla, Por ejemplo
los atributos Iva, se obtiene al aplicar un porcentaje de
impuesto que es un valor constante multiplicado por el subtotal, SubTotal se
determina sumando los resultados parciales de cada producto adquirido y el
TOTAL, representa la suma del Iva y el Subtotal.
Veamos Algunos registros o tuplas para verificar si existen grupos de datos repetitivos.
CódigoVen Fecha RIF/CI Iva Subtotal Total *NroFactura
0001 10/03/2021 J123456789-2 1280000,00 6720000,00 8000000,00 1252
0002 10/03/2021 25.280.322 160000,00 840000,00 1000000,00 1253
0003 10/03/2021 17.123.345 16000,00 84000,00 100000,00 1254
0003 10/03/2021 25.280.322 160000,00 840000,00 1000000,00 1255
En este caso se observa que no existen grupos de datos repetitivos.
Efectivamente los registros previos muestran que los datos están en forma atómica.
Apellido Paterno
Apellido Materno
Apellido
Primer Nombre
Segundo Nombre
Nombre
Nombre
*CódigoVen
Cédula
Apellido
Dirección
Teléfono
VENDEDOR
Calle/Av
Numero
Casa /Edificio
Sector
Ciudad
Dirección
Primer Nombre
Segundo Nombre
*CódigoVen
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR
CódigoVen
fecha,
Iva
RIF/CI
SubTotal
TOTAL
*NºFactura
FACTURA

Luego de los cambios gestados la tabla FACTURA quedaría
TABLA PRODUCTO
Si se tiene campos calculados o que puedan obtenerse
a partir de otros atributos en la misma tabla, Por
ejemplo el atributo Total, se obtiene al aplicar la cantidad de producto por el
precio unitario, por tanto debe ser eliminado de la Entidad
Veamos Algunos registros o tuplas para verificar si existen grupos de datos
repetitivos.
PrecioUnitario *CódigoProducto Descripción Cantidad Total
2000000 P0001 Pulpa de fresa 5 10000000
2500000 P0002 Harina de Trigo 10 25000000
3000000 P1000 Pasta de Tomate 2 6000000
1500000 P1250 Polvo de Hornear 2 3000000
No existen grupos de datos repetitivos
En las tuplas o registros previos se observa datos en forma atómica.
Luego de los cambios gestados la tabla PRODUCTO quedaría
TABLA PROD/FACT
No Tiene campos calculados o derivados
Aunque el mismo producto pudiese estar en varias facturas, no coincidirían los
registros, por tanto no hay grupos de datos repetitivos
*CódigoProducto *NroFactura
P0001 1252
P0002 1253
P1000 1254
P1250 1255
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
Precio Unitario
*CódigoProducto
Descripción
Cantidad
Total
PRODUCTO
Precio Unitario
*CódigoProducto
Descripción
Cantidad
PRODUCTO
*CódigoProducto
*NºFactura
PROD/FACT

No existen grupos de datos repetitivos
En las tuplas o registros previos se observa datos en forma atómica.
Luego de los cambios gestados la tabla PROD/FACT quedaría
El modelo luego de Aplicar la Primea Forma Normal releja los siguientes
cambios:
Entidad Campos Calculados Eliminados
FACTURA IVA
Subtotal
TOTAL
PRODUCTO Total
*CódigoProducto
*NºFactura
PROD/FACT
*CódigoVen
Primer Nombre
Segundo Nombre
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR
Razón Social
*RIF/CI
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
CLIENTE
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
* NºFactura
*CódigoProducto
PROD/FACT
Precio Unitario
*CódigoProducto
Descripción
Cantidad
PRODUCTO
∞
∞
1
1
∞
1
∞
1

Para que se cumpla la segunda forma normal se debe:
1) Estar en Primera Forma Normal; es decir:
2) Todos los atributos deben depender funcionalmente de la clave principal completa, y no solo de
una parte de ella.
Recordemos que el análisis de las Formas normales se hace tabla por tabla. En este punto
debemos garantizar que cada Entidad cumpla con la primera forma normal y
adicionalmente detallar todos y cada uno de los atributos para verificar que dependan
funcionalmente de la clave principal
TABLA CLIENTE
Del análisis precedente sabemos que las entidades cumplen con la primera forma
normal, analicemos los atributos que no son llave primaria para ver si dependen
funcionalmente de la Llave primaria.
INTERROGANTE RESPUESTA
¿Esta es la razón social que corresponde a este número de
RIF/CI?
Si está razón social depende
funcionalmente del RIF/CI
¿Esta es la calle/Av que corresponde a este número de RIF/CI? Si está calle/Av depende
¿Este es el nro de casa/edificio que corresponde a este número
de RIF/CI?
Si este nro de casa/edificio
depende funcionalmente del
RIF/CI
¿Esta es la Casa/edificio que corresponde a este número de
RIF/CI?
Si esta casa/edificio depende
SEGUNDA FORMA NORMAL (2FN)
Una relación está en 2FN si y solo si está en 1FN y además todos sus
atributos que no son clave primaria tienen una dependencia funcional
completa con la clave definida.
Razón Social
*RIF/CI
Calle/Av
Número
Casa/edificio
Sector
Ciudad
Teléfono
CLIENTE

¿Este es el sector que corresponde a este número de RIF/CI? Si este sector depende
¿Esta es la ciudad que corresponde a este número de RIF/CI? Si esta ciudad depende
¿Este es el teléfono que corresponde a este número de RIF/CI? Si este teléfono depende
Por lo tanto la Entidad CLIENTE al estar en primera forma normal y todos los
atributos que no son clave dependen funcionalmente de la llave primaria. Se dicen
que está EN SEGUNDA FORMA NORMAL
TABLA VENDEDOR
estamos seguro que la Tabla VENDEDOR se encuentra en primera forma
normal, iniciemos el análisis de la dependencia funcional de los atributos que no
son clave principal.
¿Este es el Primer nombre que corresponde a este códigoVen? Si este Primer nombre depende
funcionalmente del códigoVen
¿Este es el Segundo nombre que corresponde a este
códigoVen?
Si este Segundo nombre depende
¿Esta es la cédula que corresponde a este códigoVen? Si esta cédula depende
¿Este es el Primer apellido que corresponde a este códigoVen? Si este Primer apellido depende
¿Este es el Segundo apellido que corresponde a este
códigoVen?
Si este Segundo apellido depende
¿Esta es la calle/Av que corresponde a este códigoVen? Si está calle/Av depende
¿Este es el nro de casa/edificio que corresponde a este
códigoVen?
Si este nro de casa/edificio
depende funcionalmente del
códigoVen
¿Esta es la Casa/edificio que corresponde a este códigoVen? Si esta casa/edificio depende
¿Este es el sector que corresponde a este códigoVen? Si este sector depende
¿Esta es la ciudad que corresponde a este códigoVen? Si esta ciudad depende
Primer Nombre
Segundo Nombre
*CódigoVen
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR

¿Este es el teléfono que corresponde a este códigoVen? Si este teléfono depende
Los datos personales siempre tienen una dependencia funcional de la llave primaria
y adicionalmente sabemos que la Entidad VENDEDOR al estar en primera forma
normal; se concluye que está EN SEGUNDA FORMA NORMAL
TABLA FACTURA
Esta Entidad cumple con la primera forma normal, analicemos los atributos
que no son clave principal exceptuando de dicho análisis las llaves foráneas, en
este caso RIF/CI y CódigoVen, para verificar la dependencia funcional de la
Llave primaria.
¿Por qué no se analizan las llaves foráneas?
Porque aunque están incorporadas en la tabla su presencia se debe a un atributo con
capacidad de servir como índice, mas no es miembro de la entidad, solo para el
establecimiento de la relación.
¿Esta es la fecha que corresponde a este número de Factura? Si está fecha depende
funcionalmente del Nro Factura
Por lo tanto la Entidad FACTURA está en primera forma normal y todos los atributos
que no son clave dependen funcionalmente de la llave primaria. Se dicen que está EN
SEGUNDA FORMA NORMAL
Ahora bien en la tabla Factura está es la fecha que se emitió la factura, emitida al cliente con el Número
de RIF/CI , y atendido por el vendedor cuyo número es CódigoVen, por lo tanto dependen funcionalmente
de la Llave primaria NºFactura.
TABLA PRODUCTO
Esta Entidad cumple con la primera forma normal, analicemos los atributos
que no son clave principal, para constactar la dependencia funcional de la
Llave primaria.
¿Este es el precio Unitario que corresponde a este código de
producto?
Si este precio unitario depende
funcionalmente del
CódigoProducto
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
Precio Unitario
*CódigoProducto
Descripción
Cantidad
PRODUCTO

¿Esta es la Descripción que corresponde a este código de
producto?
Si esta descripción depende
funcionalmente del
CódigoProducto
¿Esta es la cantidad que corresponde a este código de
producto?
Aunque esta cantidad tiene una
relación con el CódigoProducto,
no depende funcionalmente de él,
pues representa la cantidad que se
compra de un producto específico
en una factura determinada
Por lo tanto la Entidad FACTURA está en primera forma normal y un atributo que
no es clave NO depende funcionalmente de la llave primaria, por tanto, debe ser
eliminado de la tabla. Para que cumpla la SEGUNDA FORMA NORMAL
Aún cuando el atributo Cantidad depende en cierta medida de la entidad producto no refleja
parte de su definición, pues la cantidad a la cual se hace referencia es a las unidades
pedidas en la factura de ese producto y no a la cantidad en existencia por tal motivo debe
salir de la Entidad Producto.
La tabla Producto quedaría de la siguiente forma
TABLA PROD/FACT
Esta Entidad cumple con la primera forma normal, y la segunda forma normal,
pues no tiene otros atributos además de la llave primaria.
Luego de analizar todas las entidades y verificar que cumple con las reglas
de la segunda forma normal construimos el modelo depurado, quedando
de la siguiente manera:
Precio Unitario
*CódigoProducto
Descripción
PRODUCTO
*CódigoProducto
*NºFactura
PROD/FACT

Entidad Campos Eliminados
PRODUCTO Cantidad
*CódigoVen
Primer Nombre
Segundo Nombre
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR
Razón Social
*RIF/CI
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
CLIENTE
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
* NºFactura
*CódigoProducto
PROD/FACT
Precio Unitario
*CódigoProducto
Descripción
PRODUCTO
∞
∞
1
1
∞
1
∞
1
NOTA:
El atributo sale momentáneamente,
hasta descubrir en cual tabla ubicarlo,
pues no es un campo calculado

Para que se cumpla la TERCERA forma normal se debe:
1) Estar en Primera Forma Normal; es decir:
2) Todos los atributos deben depender funcionalmente de la clave principal completa, y no solo de
una parte de ella.
3) No Debe existir dependencia Transitiva; es decir, todos los atributos que no sean llave primaria no
deben depender de otros atributos que tampoco sean llave primaria.
TABLA CLIENTE
Del análisis precedente sabemos que las entidades cumplen con la SEGUNDA forma
normal, veamos si existen Dependencias Transitivas. La comparación es todos
contra todos…exceptuando las llaves principales y foráneas
Atributo a Comparar Atributos a Constractar Conclusión
Razón Social depende de…
Calle/Av, Número,
Casa/Edificio, Sector; Ciudad,
Teléfono?
Aunque estos atributos están
asociados, ninguno de ellos
depende de la Razón Social
para existir, por tanto no hay
dependencia transitiva
Calle/Av depende de… Razón Social,
Numero, Casa/Edificio,
Sector; Ciudad, Teléfono?
No existe dependencia
funcional
Número depende de… Razón Social,
Calle/Av, Casa/Edificio,
Sector; Ciudad, Teléfono?
No hay dependencias
funcionales
TERCERA FORMA NORMAL (2FN)
Una relación está en 3FN si y solo si es una relación que está en 2FN y en
la que todo atributo que no pertenece a la clave primaria no depende de
un atributo que no es clave..
Razón Social
*RIF/CI
Calle/Av
Número
Casa/edificio
Sector
Ciudad
Teléfono
CLIENTE

Casa/Edificio depende de… Razón Social,
Calle/Av, Número, Sector;
Ciudad, Teléfono?
No dependen funcionalmente
Sector depende de… Razón Social,
Calle/Av, Numero,
Casa/Edificio, Ciudad,
Teléfono?
No dependen funcionalmente
Ciudad depende de… Razón Social,
Calle/Av, Numero,
Casa/Edificio, Sector;
Teléfono?
No hay dependencia funcional
Teléfono depende de… Razón Social,
Calle/Av, Numero,
Casa/Edificio, Sector; Ciudad?
No existe dependencias
funcionals
Se concluye que al no existir dependencias funcionales y estar en segunda forma normal, es decir,
todos los atributos que non clave dependen funcionalmente de la llave primaria y está en primera
forma normal, lo que implica que noy hay grupos de datos repetitivos, ni calculados y los atributos
están en forma atómica.
La entidad CLIENTE cumple con la tercera forma normal. Ste mismo an{alsisi se eectúa para el
resto de las entidades.
TABLA VENDEDOR
La Tabla VENDEDOR se encuentra en segunda forma normal, se debe
verificar si existen dependencias funcionales transitivas, entre los atributos que
no son clave principal
Algunos de los atributos que pudiese generar dudas acerca de la dependencia,
por ejemplo el Segundo Nombre para existir no depende del primer Nombre
(Aclarando: si el segundo nombre es María no es una condición que el primer
nombre deba ser Luisa). Así se realiza con todos los atributos y observamos
que no existe dependencia funcional entre ellos por lo tanto es están en Tetá en
Tercera Forma normal (3FN).
TABLA PRODUCTO
Esta Entidad cumple con la tercera forma normal, los dos únicos atributos
que no son clave principal, no dependen funcionalmente uno del otro. Por lo
tanto, está en Tercera Forma Normal
Primer Nombre
Segundo Nombre
*CódigoVen
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR
Precio Unitario
*CódigoProducto
Descripción
PRODUCTO

TABLA FACTURA
Esta Entidad cumple con la segunda forma normal, excluyendo las llaves
foráneas, solo queda un atributo, por tanto no existen dependencias
funcionales. Y se concluye que está en Tercera Forma Normal.
TABLA PROD/FACT
Esta Entidad cumple con la segunda forma normal, y al no tener atributos se
sabe que cumple con la Tercera Forma Normal.
Ahora bien, en el análisis precedente en la segunda orma Normal eliminamos el atributo Cantidad
de la Entidad Producto. Retomemos ese punto y notaremos que esa cantidad efectivamente no es un
campo calculado sino básico pero asociado a dos entidades simultáneamente Producto y factura,
pues representa la cantidad que se compró del PRODUCTO X en la FACTURA Y, así que el
atributo cantidad depende de los dos simultáneamente por lo tanto debe Ubicarse en la tabla
PRODUC/FACT.
Quedando la tabla de la siguiente manera, incluso con este nuevo atributo cumple con la tercera
Forma Normal
El modelo Final quedaría de la Siguiente manera:
El modelo Normalizado quedaría de la siguiente manera
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
*CódigoProducto
*NºFactura
PROD/FACT
*CódigoProducto
*NºFactura
Cantidad
PROD/FACT

Para efectos de evaluación, debe presentar los cambios que se
gestan en el diseño del modelo en cada ase, el último diseño que
presente estará normalizado y listo para ser creada una base de
datos.
*CódigoVen
Primer Nombre
Segundo Nombre
Cédula
Primer Apellido
Segundo Apellido
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
VENDEDOR
Razón Social
*RIF/CI
Calle/Av
Número
Casa/dificio
Sector
Ciudad
Teléfono
CLIENTE
CódigoVen
fecha,
RIF/CI
*NºFactura
FACTURA
* NºFactura
*CódigoProducto
Cantidad
PROD/FACT
Precio Unitario
*CódigoProducto
Descripción
PRODUCTO
∞
∞
1
1
∞
1
∞
1

Ejemplo de Normalización con Modelo Entidad Relación y Modelo Relacional

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Ejemplo de Normalización con Modelo Entidad Relación y Modelo Relacional

Similar a Ejemplo de Normalización con Modelo Entidad Relación y Modelo Relacional (20)

Más de Damelys Bracho

Más de Damelys Bracho (17)

Último

Último (20)

Ejemplo de Normalización con Modelo Entidad Relación y Modelo Relacional