normalización de bases de datos (hasta boyce-codd)

Normalización de la Base de Datos Agencia de Recuperación de VehículosInstituto Politécnico Nacional UPIITA-IPN

• Espindola Pizano Ariel Tonatiuh• Zepeda Tinoco Jorge

Grupo 2TM2 - 2 de marzo de 2015

NORMALIZACIÓN AGENCIA �1

IntroducciónDentro 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.


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

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.


Persona (idPersona, nombre, apellido_paterno, apellido_materno, e-mail, edad, tipo, teléfono ,codigo_postal,colonia, calle, numero, delegacion,

estado, telefono)

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:


Recuperados (idRecuperados, perdida, condicion,hora,fecha, nombre_perito,apellido_paterno,apellido_materno)

Denuncia (idDenuncia, idPersona, sospecha,hora_sucedido,fecha_sucedido,

lugar_sucedido,descripcion_sucedido)

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 1FN2.- 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.


Testigo (idTestigo, idDenuncia, nombre, telefono)

Domicilio(idDomicilio, codigo_postal, calle, numero, colonia, delegacion,estado)

Persona (idPersona, idDomicilio, nombre, e-mail, edad, tipo, telefono)

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”


Recuperados (VIN,Diagnostico_folio, perdida, condicion)

Diagnostico (folio,idPeritos, hora, fecha)

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.


Peritos (idPeritos, nombre, apellido_paterno, apelido_materno)

Denuncia (idDenuncia, idPersona, idAcontecimiento)

Acontecimiento (idAcontecimiento, hora, fecha, lugar, descripcion, sospecha)

Testigo (idTestigo, nombre, telefono)

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 2FN2.- 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).


Testigo_Denuncia (idTestigo, idDenuncia)

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


Resultado (idResultado, condicion, perdida)

Recuperados (VIN ,Diagnostico_folio)

Diagnostico (folio,idPeritos, idResultado,hora, fecha)

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:


Diagnostico (folio,idPeritos, idResultado,hora, fecha)

Vehiculo (VIN,idPersona, Diagnostico_folio,placas, modelo, color, marca, estado)

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 de bases de datos (hasta boyce-codd)

Technology