El documento describe el proceso de normalización de una base de datos para una agencia de recuperación de vehículos. Inicialmente, las tablas no estaban normalizadas y contenían atributos redundantes y dependencias funcionales incorrectas. Tras aplicar las primeras y segunda formas normales, las tablas se dividen y los atributos se reorganizan para eliminar redundancias y asegurar la integridad referencial. Las tablas resultantes ahora cumplen con las reglas de normalización hasta la segunda forma normal.

1. Normalización de la Base
de Datos
Agencia de Recuperación de Vehículos
Instituto Politécnico Nacional
UPIITA-IPN
• Espindola Pizano Ariel Tonatiuh
• Zepeda Tinoco Jorge
Grupo 2TM2 - 2 de marzo de 2015
NORMALIZACIÓN AGENCIA 1

2. Introducción
Dentro de la Teoría de la Normalización de Bases de Datos, existen cinco formas
normales que son un conjunto de reglas que se deben seguir para garantizar la integridad
de los de datos eliminando dependencias funcionales como la reflexiva, aumentativa y
transitiva (redundancia) en el modelo relacional.
En el diseño de esta base de datos, se llevará a cabo la normalización hasta la tercera
forma normal Boyce-Codd . Además de que solo se mostrará la normalización de a lo más
dos tablas, a modo de simplificar este documento. El procedimiento de normalización
para una tabla es muy similar al resto de las tablas de la base de datos.
Por otro lado, después de normalizar , en consecuencia se tiene que re-diseñar la
relación entre las tablas lo cual será explicado mas adelante.
Antes de Normalizar
Planteamiento del problema
En una agencia de seguridad pública y recuperación de autos, se trabaja en conjunto para saber ciertos
datos acerca de autos robados en los últimos 3 meses o el periodo especificado por el usuario, para ello
se desea construir una base de datos para consultar, modificar y gestionar el proceso o etapa en el que
se encuentra el vehículo.
La organización clasifica tres etapas, denuncia, búsqueda y recuperación.
Cuando el propietario o conductor del vehículo hace la denuncia tiene que proporcionar sus datos y los
del vehículo, así como también el lugar, fecha y hora del acontecimiento. La denuncia también debe
contener folio y un indicio de sospecha.
De los datos de la persona que denuncia se desea almacenar, su nombre completo, domicilio, teléfono,
e-mail , edad (+18 ) y en caso de haber testigos se necesita solo nombre y teléfono de cada uno.
En cuanto a los datos del vehículo deben almacenarse : nombre del propietario actual, placas, No. de
serie (VIN), modelo, marca, color y nacionalidad.
Y el sistema deberá mostrar un dato adicional del vehículo tale como, el status actual del mismo ya sea
recuperado, desaparecido, buscando o perdido, con base en el transcurso de la investigación.
En la etapa de recuperación se debe hacer un diagnóstico por uno de los peritos reconocidos de la
agencia, se debe tener en cuenta que el caso se clasifica de acuerdo a las condiciones en las que se
encontró el auto, completo o siniestrado, si el auto es siniestrado, debe de tomarse en cuenta si las
condiciones son de pérdida total o perdida parcial.
NORMALIZACIÓN AGENCIA 2

3. A la agencia también le interesa saber quién realizó ese diagnóstico, cuándo y a qué hora.
Si el auto no es recuperado a lo más en 3 meses, se extiende la búsqueda a un mes más, en caso de
que no se encuentre, se considera como desaparecido y finaliza la etapa búsqueda. En caso contrario, si
el auto es recuperado, se procede a la entrega con el cliente corroborando los datos del propietario y del
vehículo. Al término de ello, queda guardado un historial del auto recuperado en ésta agencia.
Modelo Relacional de la problematica
Se observa a simple vista, que puede existir redundancia en las tablas. Eso y más, será
comprobado. Ahora procederemos a seguir las reglas de normalización, y conforme se
avance, se irán notando los cambios en la Base de Datos.
NORMALIZACIÓN AGENCIA 3

4. Normalización
1FN - Primera forma normal
Se dice que una relación esta en primera forma normal si y solo si tiene un número fijo de
atributos y estos toman valores atómicos (indivisibles) de un dominio.
Cada tupla de una tabla debe representar una entidad y las entidades deben ser
únicas, por lo que se necesita establecer una llave primaria. Tomaremos la tabla “Persona”
para normalizar.
Persona (curp, nombre, domicilio, e-mail, edad, tipo, teléfono)
De acuerdo con la 1FN, esta entidad debe tener una llave que identifique de manera
única cada registro dentro de la tabla, en este caso se observa que la “curp”, es irrepetible,
entonces es único, pero en el planteamiento del problema no se habla de este tipo de
identificación entonces se elimina y en su lugar se determina un atributo “idPersona”, que
también será único e irrepetible ademas de permitir la identificación de la tabla “Persona”
con un dígito de menor longitud que del curp.
Los atributos deben ser atómicos, es decir indivisibles. En este caso el atributo
“nombre” se puede dividir por “apellido_paterno”, “apellido_materno”, también la
dirección se puede dividir por “calle”, “numero”, “colonia”,”delegacion”, “estado” y
“codigo_postal”. Quedando la tabla de la siguiente manera.
Se realiza el mismo procedimiento con el resto de las tablas de la base de datos.
NORMALIZACIÓN AGENCIA 4
Persona (idPersona, nombre, apellido_paterno, apellido_materno, e-mail,
edad, tipo, teléfono ,codigo_postal,colonia, calle, numero, delegacion,
estado, telefono)

5. La tabla “Recuperacion” contiene datos que no son necesarios, por ejemplo “tipo”, que
indica en qué etapa se encuentra la búsqueda , entonces existen errores de diseño, en su
lugar quedan dos atributos que son “perdida” y “condicion”. Por lo que se decide crear
únicamente una tabla “Recuperados”. Quedando de la siguiente manera.
El atributo “condicion” es de tipo entero que puede tomar valores {0,1}, uno indica
siniestrado (chocado) y cero indica completo.
Donde “perdida” es de tipo entero cuyo dominio es {0,1,2}, el cero indica que no hay
pérdida, el uno indica que es pérdida parcial, el dos significa que es pérdida total.
Cabe mencionar que sus respectivas validaciones se incluyen en la lógica de negocio a
nivel de programación. “Debido a la condición, se asigna el valor de perdida”
Dado que las estructuras de las tablas se van modificando, podemos darnos cuenta que
algunas no tienen razón de ser con base en planteamiento del problema. Como es el caso
de la tabla “Busqueda”, debido a que la información que contiene puede ser más
manejable a nivel de programación dentro de la aplicación.
En la tabla “Vehículo” se conservan los mismos atributos.
Ahora vamos con la tabla “Denuncia”, la cual tiene los siguientes atributos:
Denuncia (folio,idPersona, hora, ubicacion, datos_vehiculo, indicio_sospecha)
Podemos observar que el atributo “datos_vehiculo”, no tiene razón de ser porque para
esos datos existe la tabla vehículo cuyos datos puede obtenerse través de idPersona, por lo
tanto se elimina y la nueva tabla con atributos atómicos y correctamente identificada es la
siguiente:
NORMALIZACIÓN AGENCIA 5
Recuperados (idRecuperados, perdida, condicion,hora,fecha,
nombre_perito,apellido_paterno,apellido_materno)
Denuncia (idDenuncia, idPersona,
sospecha,hora_sucedido,fecha_sucedido,
lugar_sucedido,descripcion_sucedido)

6. Entonces la tabla “Testigo” queda de la siguiente manera.
2FN - Segunda forma normal
Sea R(A,B,C,D), un esquema de relación, se dice que R esta en 2FN si:
1.- Está en 1FN
2.- Todo atributo no clave V contenido en R, depende funcionalmente de la clave (o claves) y
no de ninguna subconjunto propio de ella (o ellas).
Esto nos quiere decir que toda columna que no sea clave debe guardar relación
directa con la llave primaria. Estos es muy útil para separar la semántica de cada tabla.
Por ejemplo en la tabla “Persona”, los atributos “calle”, “numero”, “colonia”,
”delegacion”, “estado”, “codigo_postal” no tienen relación directa o dependencia
funcional con la persona, sino con la dirección de la persona. Al hacer esto se crea una
nueva tabla llamada “Domicilio”, que a su ves también debe tener una llave única que la
identifique. Entonces las tablas quedarían, como sigue.
Se asigna una PK “idDomicilio” que será creada con datos del domicilio y persona,
lo cual se llevara a cabo a nivel de programación, para más detalles de esto pasar a la
sección de Lógica de Negocio. Para fines prácticos, el atributo se ha configurado como
autoincremental en el GBD por el momento.
NORMALIZACIÓN AGENCIA 6
Testigo (idTestigo, idDenuncia, nombre, telefono)
Domicilio(idDomicilio, codigo_postal, calle, numero, colonia,
delegacion,estado)
Persona (idPersona, idDomicilio, nombre, e-mail, edad, tipo, telefono)

7. De manera similar sucede con la tabla “Recuperados”, ya que los atributos:
“nombre_perito”, “apellido_paterno”,”apellido_materno” son NO CLAVE y
dependen funcionalmente de un subconjunto propio que puede ser llamado PERITOS,
entonces no esta normalizada a 2FN.
Además, cabe mencionar en incluso los atributos “fecha” y “hora” no guardan
relación directa con la llave primaria “idRecuperados” porque para que se establezca hora
y fecha previamente debe existir un diagnóstico, por lo tanto un subconjunto puede
llamarse DIAGNOSTICOS.
Acto seguido, un perito es quien realiza uno o más diagnósticos, por lo tanto si
creamos una tabla llamada “Diagnostico”, ésta contendría una referencia hacia PERITOS.
Es importante decir que cada nueva tabla que se crea debe de ser identificada de
manera única con una respectiva llave primaria. Al crear una tabla para cada subconjunto,
el esquema queda de la siguiente manera:
“VIN” es una llave propagada (o foránea) de la tabla “Vehículo” que se pone como
llave primaria para identificar a esta tabla de manera única e irrepetible, ya que por cada
auto que existe en la tabla “Vehículo” debe haber o no uno recuperado (puede que
todavía no se recupere) , esto garantiza la integridad referencial entre las tablas.
Los atributos “hora”, “fecha” y “idPeritos”, dependen funcionalmente de la clave
primaria, es decir del diagnóstico.
Esto se puede leer como sigue para entender mejor la dependencia: “El perito DEL
diagnóstico, la hora DEL diagnóstico y la fecha DEL diagnóstico”
NORMALIZACIÓN AGENCIA 7
Recuperados (VIN,Diagnostico_folio, perdida, condicion)
Diagnostico (folio,idPeritos, hora, fecha)

8. Esta tabla queda perfectamente identificada y con relación directa entre la llave
primaria y los atributos no clave contenidos en la tabla.
La tabla “Denuncia”, es evidente que no está normalizada a 2FN, por lo que se
procede con los mismos pasos de las tablas anteriores dando como resultado las siguientes
tablas.
Nota: Entre la tabla “Denuncia” y “Testigo”, existe una relación N:M (muchos a muchos)
ya que una denuncia puede tener varios testigos pero también un testigo puede estar en varias
denuncias.
La tabla “Denucia ” tiene atributos que no guarda relación directa con la llave
primaria como es el caso de “hora”, “fecha”, “lugar”, “descripción” son de lo sucedido, no
de la denuncia. Entonces se puede interpretar un nuevo subconjunto llamado
ACONTECIMIENTO.
Entonces ahora sí se puede leer, queda de la siguiente forma: “La persona DE la
denuncia y el acontecimiento DE la denuncia”. Se cumple con la relación directa de los
atributos no clave con la llave principal.
NORMALIZACIÓN AGENCIA 8
Peritos (idPeritos, nombre, apellido_paterno, apelido_materno)
Denuncia (idDenuncia, idPersona, idAcontecimiento)
Acontecimiento (idAcontecimiento, hora, fecha, lugar, descripcion,
sospecha)
Testigo (idTestigo, nombre, telefono)

9. Esta tabla representa la relación muchos a muchos en el modelo relacional.
3FN - Tercera forma normal (Eliminación de dependencia Transitiva)
Un esquema de relación R esta en 3FN si:
1.- Está en 2FN
2.- Todo atributo no clave no depende funcionalmente de ningún atributo no clave.
Para que no haya dependencia transitiva se debe crear una nueva entidad con los
atributos no clave que dependan funcionalmente uno de otro. Si no se realiza este paso, se
tendrán datos repetidos en las tablas, por ende serán mas grandes y será un poco más
confuso identificar algún dato dentro de una consulta.
Hasta el momento se ha normalizado detenidamente la base de datos hasta la 2FN,
donde se analizó tabla por tabla las dependencias funcionales de los atributos, por lo tanto
todas las tablas se encuentran normalizadas en 3FN a excepción de la tabla
“Recuperados”. A continuación se explica por qué.
Recordando que ésta tabla contiene los atributos “perdida” y “condicion”, se puede
observar de acuerdo con la lógica de negocio y el diseño de la base de datos que dada una
CONDICIÓN, se determina el tipo de PÉRDIDA, por ejemplo si “condicion = 0” (sin
daños) entonces “perdida = 0” (no hay pérdida).
Entonces se ve una dependencia funcional entre atributos no clave, por lo tanto hay
una dependencia transitiva. Para eliminarla se propone una nueva tabla “Resultado”, la
cual va ligada con “Diagnostico” ya que es el resultado del diagnóstico realizado por el
perito, con relación 1:N (un resultado puede estar en varios diagnósticos pero un
diagnóstico no puede tener varios resultados).
NORMALIZACIÓN AGENCIA 9
Testigo_Denuncia (idTestigo, idDenuncia)

10. “condicion” o estado es un hecho del resultado (idResultado) de un diagnóstico
previo, así como también “perdida” depende del resultado (idResultado) donde se
cumpla cierta condición del estado del vehículo.
De esta manera se elimina la dependencia transitiva en consecuencia la tabla
“Recuperados” jamas tendrá valores repetidos
BCFN - Forma Normal de Boyce-Codd
Un esquema de relación R esta en 3FN si y solo si PARA TODAS sus dependencias
funcionales elementales de la forma X->Y, se verifica que X es una clave de R.
Definiciones:
X->Y : Es una dependencia funcional trivial si y solo si Y esta contenida en X.
X->Y: Es una dependencia funcional completa si y solo si no depende funcionalmente de
ningún subconjunto de X.
Una dependencia funcional completa y no trivial , se dice que es una dependencia
funcional elemental.
Esta regla se aplica básicamente para ignorar una de las llaves candidatas (siendo el
caso) y utilizar una solamente para identificar el atributo que esté en cuestión.
NORMALIZACIÓN AGENCIA 10
Resultado (idResultado, condicion, perdida)
Recuperados (VIN ,Diagnostico_folio)
Diagnostico (folio,idPeritos, idResultado,hora, fecha)

11. De acuerdo al análisis puntual previo en toda la base de datos, se puede decir que
todas las tablas esta en BCNF a excepción de la tabla “Recuperados”, la cual tiene
dos llaves que son únicas, una que es “VIN” la llave primaria y
“Diagnostico_folio” como llave candidata ya que también es única y puede
identificar a la tabla. Es decir, no es dependencia funcional completa.
Tras analizar la tabla “Recuperados” se observa que no tiene razón de existir, ya
que solo contiene el “VIN” propagado de la tabla “Vehiculo” y el “folio” del
diagnóstico , por lo tanto puede haber una relación directa entre DIAGNOSTICO y
VEHICULO si necesidad de pasar por “Recuperados”.
La relación que se forma es de 1:N (varios vehículos tienen un diagnóstico, es decir
por cada vehículo hay un diagnostico pero no pueden haber varios diagnósticos
por cada vehículo).
Es muy importante decir que un vehículo puede estar registrado en la
DENUNCIA, pero puede ser que aún no sea diagnosticado, por lo tanto en este
caso la llave foránea que se genera de la tabla “Vehiculo” por parte de la tabla
“Diagnostico” se puso como atributo OPCIONAL, es decir puede que sea NULO, si
es nulo, entonces no existe la referencia las tablas “Diagnostico”, “Peritos” y
“Resultado”. Esto es obvio porque puede que un VEHICULO ya haya sido
diagnosticado o no. En caso de que sí, pues existe nuevamente la referencia a los
datos de estas tablas mencionadas.
También existe una llave candidata “placas” en la tabla “Vehiculo”, en este caso no
se hizo modificación porque de acuerdo al diseño de la base de datos también es
importante conocer las placas del vehículo ademas del VIN.
Como resultado las siguientes tablas:
NORMALIZACIÓN AGENCIA 11
Diagnostico (folio,idPeritos, idResultado,hora, fecha)
Vehiculo (VIN,idPersona, Diagnostico_folio,placas, modelo, color, marca,
estado)

12. Finalmente a continuación se muestra la Base de Datos Normalizada hasta la
forma normal Boyce-Codd
Hay un cambio abismal y notorio en comparación con la Base de Datos con que se
comenzó.
Las reglas de normalización son muy útiles cuando empezamos a realizar el modelo
relacional directamente sin una previa conceptualización.
Todavía puede normalizarse más la Base de Datos hasta una 5FN, pero se considera buena
hasta la 4FN (Boyce-Codd) ya que se cuenta con datos consistentes y se garantiza la
integridad de los mismos.
NORMALIZACIÓN AGENCIA 12