Reglas Para La Normalización 1FN
22
Reglas para la normalización 1FN, 2FN y 3FN. El diseño de base de datos El diseño de la base de datos se realiza tomando en cuenta el análisis de requisitos con todas las personas que van a hacer uso de los datos y revisando nuestro estudio de factibilidad, aunque también se toma en cuenta según los requisitos de la aplicación se realiza el diseño de la base de datos. Es importante realizar una buena normalización a la base de datos para que no halla probabilidad de fallos en el programa cuando se este desarrollando o ya este realizado. El proceso de Normalización, tal y como fue propuesto en un principio por Codd (1972) hace pasar un esquema de relación por una serie de comprobaciones para certificar que satisface una determinada forma normal. La normalización de datos puede considerarse como un proceso de análisis de un esquema de relación, para conseguir una BD relacional, basado en sus DF. Y sus claves principales, para obtener las propiedades deseables, de (1) minimizar la redundancia y (2) minimizar las anomalías de inserción, borrado y actualización. Se divide en formas normales, 1FN, 2FN, 3FN, 4FN, 5FN etc. en la mayoría de los casos realizar hasta la 3FN es suficiente para que la base de datos este normalizada. Se realiza analizando el conjunto de campos (atributos) y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de facturación podemos partir de los datos del cliente añadiendo la clave del cliente, y según vayamos normalizando nos saldrán todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irán saliendo otras tablas subordinadas. Implicaciones Hay ocasiones en las que los diseñadores de las BD confeccionan la BD para satisfacer necesidades lógicas y funcionales de una aplicación, por ejemplo almacenando los datos en un formato que luego la aplicación se encarga de transformar. Esto es bastante típico cuando el diseñador es el programador de la aplicación, y lo hace por comodidad o falta de conocimiento.
-
Upload
bryan-omar-yauri-santa-cruz -
Category
Documents
-
view
232 -
download
9
description
Tarea
Transcript of Reglas Para La Normalización 1FN
Reglas para la normalización 1FN, 2FN y 3FN.El diseño de base de datosEl diseño de la base de datos se realiza tomando en cuenta el análisis de requisitos con todas las personas que van a hacer uso de los datos y revisando nuestro estudio de factibilidad, aunque también se toma en cuenta según los requisitos de la aplicación se realiza el diseño de la base de datos.
Es importante realizar una buena normalización a la base de datos para que no halla probabilidad de fallos en el programa cuando se este desarrollando o ya este realizado.
El proceso de Normalización, tal y como fue propuesto en un principio por Codd (1972) hace pasar un esquema de relación por una serie de comprobaciones para certificar que satisface una determinada forma normal.
La normalización de datos puede considerarse como un proceso de análisis de un esquema de relación, para conseguir una BD relacional, basado en sus DF. Y sus claves principales, para obtener las propiedades deseables, de (1) minimizar la redundancia y (2) minimizar las anomalías de inserción, borrado y actualización.
Se divide en formas normales, 1FN, 2FN, 3FN, 4FN, 5FN etc. en la mayoría de los casos realizar hasta la 3FN es suficiente para que la base de datos este normalizada.
Se realiza analizando el conjunto de campos (atributos) y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de facturación podemos partir de los datos del cliente añadiendo la clave del cliente, y según vayamos normalizando nos saldrán todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irán saliendo otras tablas subordinadas.
ImplicacionesHay ocasiones en las que los diseñadores de las BD confeccionan la BD para satisfacer necesidades lógicas y funcionales de una aplicación, por ejemplo almacenando los datos en un formato que luego la aplicación se encarga de transformar. Esto es bastante típico cuando el diseñador es el programador de la aplicación, y lo hace por comodidad o falta de conocimiento.
La moraleja es que una BD debe ser independiente de la aplicación, es mejor así. Según las reglas de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (típicamente SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada desde la aplicación). Con esto conseguiremos que mediante el SQL no se puedan realizar operaciones que hagan que la aplicación no funcione (introduciendo datos en un formato inesperado para la aplicación, por ejemplo), y entre otras cosas, que si tenemos que realizar informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que parsear (desfrizar una sintaxis en el código) ni realizar consultas sobre consultas.
1FN: La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas.Afirma que el dominio de un atributo solo debe incluir valores atómicos (simples o indivisibles) y que el valor de cualquier atributo en una tupla debe ser una valor simple del dominio de ese atributo
Como por ejemplo tres números de teléfono, o dos direcciones e-mail. Lo típico en estos casos es separar los datos por comas, espacios u otro carácter y después procesarlo mediante la aplicación.Para evitar esto hay que definir una nueva tabla que tendrá el identificador de la tabla de la que parte y el campo multivaluado, haciendo juntos de clave única compuesta (se puede definir otra incremental si se desea "recomendado", pero el conjunto de los otros dos campos tiene que ser único). Además en esta tabla se puede agregar campos que ayuden a describir el tipo de registro.
No se permiten grupos repetidos en varias columnasEsto es una variante de lo anterior: separamos los campos de un mismo dominio en varias columnas, haciendo un grupo difícilmente procesable a la hora de consultarlo. En el ejemplo anterior sería tener el campo teleClien1, telClien2… y así. Es evidente que este fallo del diseño es incluso peor que el anterior pues habrá muchos campos nulos, y en caso de necesitar más tendríamos que redimensionar la tabla con un nuevo campo (telClien3). Pero la solución es sencilla.
Ejemplo:
No se permiten campos nulosEsta regla es algo discutible, pero tiene su lógica. Para empezar, si un campo va a tener valores nulos, ¿qué proporción de registros tendrán ese campo con valor nulo? En mi opinión esta regla nos ayuda a separar unas relaciones de otras, porque si una cantidad de registros tienen unos atributos que otros no, ¿no será que pertenecen a otra clase? Por ejemplo, si en una tabla de TBPRODUCTOS definimos los campos TallaProd, KilatesProd y potenciaProd se ve que los productos tendrán clases diversas y entonces habrá que crear una relación para cada clase (ropas, joya y eléctricos, por ejemplo) construyendo lo que se llama una generalización.
Ejemplo:
2FN:
La relación está en 1NF.La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la clave primaria de la tabla para identificarlos.Cada atributo no principal tiene dependencia funcional completa respecto a la clave primaria.Si un campo de la tabla no depende totalmente de una clave única (que pueden ser compuestas), debe sacarse fuera con la parte de la clave principal de la que es dependiente.
Ejemplo:
Como vemos en la tabla “TBLINEASPEDIDO” del ejemplo incorrecto, la única clave candidata es PK_TBLINEASPEDIDO + IDProducto, ya que en conjunto son únicas en la tabla (podríamos tener un IDLinea_pedido único también, pero aún así esos dos campos seguirían siendo una clave candidata). El campo CantidadPed es dependiente de la clave candidata, pues el cliente ha pedido de ese producto una cantidad determinada de artículos, pero el nombre en cambio es dependiente sólo del producto, no del cliente. Si dejaremos esa tabla como está, tendríamos por una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla de productos, y además podrían darse inconsistencias de datos si cambiamos el nombre del producto en un registro… ¿cuál sería el nombre real del producto 1 si en varios registros tiene un nombre distinto?
Conclusiones 2FN:
Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves candidatas (compuestas), que identifican de manera única el registro; comprobar que los campos que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el segundo paso puede ayudar preguntarse lo siguiente:¿puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave
candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el análisis esto requiere un mínimo de agudeza, pues puede que casualmente el valor de un campo se repita para una parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en cantidades de 5) pero sabemos que no es dependiente de ella.
Por último, aclarar que hay ocasiones en las que el análisis no tiene que ser tan cerrado, ya que a veces las apariencias engañan. Un ejemplo de ello es una tabla de facturas que tiene el nombre, dirección, NIF, y demás datos del cliente: a simple vista esos datos están duplicados y dependen del cliente y no de la factura, pero resulta que esos datos deben permanecer ahí pues fisicalmente debemos saber a qué datos se emitió una factura; esos datos son realmente dependientes de la factura, no del cliente. Si no los incluyéramos en la tabla de facturas, al modificar el registro del cliente en la tabla de clientes no sabríamos a qué datos fiscales se emitió la factura. Así que hay que tomar como referencia el estudio de factibilidad, necesidades de cliente y el minimundo, y no solo aplicar normas.
3FN:
La relación está en 2NF.Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.
Todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen únicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta: ningún campo que no sea parte de la clave candidata puede dependerde otro campo que no sea la clave candidata.
Por ejemplo:pedido(pedido_id, fecha, cliente_id, cliente_nombre)- satisface 1FN y 2FN con clave primaria pedido_id- pero cliente_nombre cambia si cambia cliente_id- Así que debemos dividir la tabla en:- pedido(pedido_id, fecha, cliente_id)- cliente(cliente_id,cliente_nombre)
Otro ejemplo:
Imagina que una tabla se encarga de registrar el primer servicio que más carga los servidores cada día. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha, PK_TBCARGADIARIA son la clave candidata, pues identifican de manera única los registros. Analizando vemos que el IDServicio, que no es un campo primario, depende únicamente de la clave candidata, y que la carga también. Pero resulta que el Nombre_servicio depende de esa clave candidata pero también depende del IDServicio, pues con el IDServicio podemos averiguar qué Nombre_servicio tiene el registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el IDServicio para que sea la clave principal pues es el campo del que depende.
Y con este ejemplo vemos qué fácil es librarnos de las inconsistencias de no cumplir la tercera forma normal, y de la redundancia de datos. Si no hubiéramos normalizado tendríamos que en un registro el IDServicio 3 es Apache y nadie nos asegura que en otro el IDServicio 3 también lo sea pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un histórico de 500 servidores durante 1000 días, tendríamos 500 mil registros con un campo innecesario que estaría duplicado muchísimas veces
Ejercicios, PASO A 1FN, 2FN y 3FN (BASES DE DATOS) Ejercicios: Pasar a 3FN los esquemas relacionales:
1. A (a0, b0, c1, c2) siendo c2 c1
. C (c1, c2)
A (a0, b0, c1)
Cajena: {c1} → C
2. ALUMNO (num_exp, curso, localidad, provincia) siendo provincia localidad
Provincia (localidad, provincia)
Alumno (num_exp, curso, localidad)
Cajena: {Localidad} → Provincia
3. NOTA (cod_asig, num_exp, nom_asig, nom_alumno, dir_alumno,
nota) siendo nom_alumno, dir_alumno num_exp y siendo nom_asig cod_asig
FN2:
Nota (cod_asig, num_exp, nota)
Cajena: {cod_asig} → Asignatura
Cajena: {num_exp} → Alumno
Alumno (num_exp, nom_alumno, dir_alumno)
Asignatura (cod_asig, nom_asig)
4. A (a0, a1, a2, {a3}, a4, a5) siendo a2 a1 y siendo a5a4
FN1
A'(a0, a1,a3)
Cajena: {a0, a1} → A
A (a0, a1, a4, a5)
FN2
A (a0, a1, a4, a5)
Cajena: {a1} → A2
A2 (a1, a2)
FN3
A' (a4, a5)
A (a0, a1, a4)
Cajena: {a4} → A'
5. A (a0, {a1}, a2) siendo a2 a0
FN1
A' (a0, a1)
Cajena: {a0} → A'
A (a0, a2)
FN2
A(a0,a2)
Realiza el proceso de normalización de las siguientes relaciones y para cada uno de los enunciados, crea un excel con tablas de datos de ejemplo.Enunciado 1.FCT (num_expediente, cod_empresa, nom_alumno, nom_empresa, fecha_inicio, fecha_fin)FCT (num_expediente, cod_empresa, fecha_inicio, fecha_fin)
Cajena: {num_expediente} → ALUMNO
Cajena: {cod_empresa} → EMPRESA
ALUMNO (num_expediente, nom_alumno)
EMPRESA (cod_empresa, nom_empresa)
Enunciado 2.CAMPAMENTO (cod_niño, cod_monitor, {fecha_inicio}, num_dias, nom_niño, nom_monitor, edad_niño, titulo_monitor)FN1
CAMPAMENTO' (cod_niño, cod_monitor, fecha_inicio)
Cajena: {cod_niño, cod_monitor} → Campamento.
CAMPAMENTO(cod_niño, cod_monitor, num_dias, nom_niño, nom_monitor, edad_niño, titulo_monitor)
FN2:
CAMPAMENTO(cod_niño, cod_monitor, num_dias)
Cajena: {cod_niño} → Niño
Cajena: {cod_monitor} → Monitor
NIÑO (cod_niño, nom_niño, edad_niño)
MONITOR (cod_monitor, nom_monitor, titulo_monitor)
Enunciado 3.ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edición}, nom_autor, especialidad_autor, editorial)ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edición}, nom_autor, especialidad_autor, editorial)
FN1
ESCRIBIR_LIBRO' (isbn, dni, tipo, edicion)
Cajena: {isbn, dni} → ESCRIBIR_LIBRO
ESCRIBIR_LIBRO (isbn, dni, num_pag, nom_autor, especialidad_autor, editorial)
FN2:
ESCRIBIR_LIBRO(isbn, dni)
Cajena: {isbn} → Libro
Cajena: {dni} → Autor
LIBRO (isbn, num_pag, editorial)AUTOR(dni, nom_autor, especialidad_autor)
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, {aux_vuelo}, hora_salida)
Enunciado 4.VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, {aux_vuelo}, hora_salida)FN1
VUELO' (num_vuelo, dni, cod_avion, aux_vuelo)
Cajena: {num_vuelo, dni, cod_avion} → VUELO
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, hora_salida)
FN2
VUELO (num_vuelo, dni, cod_avion)
VIAJE(num_vuelo, hora_salida)
AVION(cod_avion, num_asientos)
PILOTO (dni, nom_piloto)
El proceso de normalización de bases de datos relacionales
La normalización de bases de datos relacionales toma un esquema relacional y le aplica un
conjunto de técnicas para producir un nuevo esquema que representa la misma información
pero contiene menos redundancias y evita posibles anomalías en las inserciones,
actualizaciones y borrados.Breve recordatorio del modelo (formal) relacional
El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relación, que se define por una serie de atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restricción que nos indica que cada entidad representada por una tupla tiene que ser diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos valores identifiquen unívocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave ajena.El proceso de normalización
El proceso de normalización consiste en comprobar en secuencia si el esquema original está en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.Un ejemplo completo
Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.
nss nombre puesto salario emails
111 Juan Pérez Jefe de Área 3000 [email protected]; [email protected]
222 José Sánchez Administrativo 1500 [email protected]
333 Ana Díaz Administrativo 1500 [email protected]; [email protected]
... ... ... ... ...
Primera forma normal (1FN)
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.Solución 1: duplicar los registros con valores repetidos
En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:
El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si
R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M.
La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email):
nss nombre puesto salario email
111 Juan Pérez Jefe de Área 3000 [email protected]
111 Juan Pérez Jefe de Área 3000 [email protected]
222 José Sánchez Administrativo 1500 [email protected]
333 Ana Díaz Administrativo 1500 [email protected]
333 Ana Díaz Administrativo 1500 [email protected]
... ... ... ... ...
Solución 2: separar el atributo que viola 1FN en una tabla
En general, esta solución pasa por:
sustituir R por una nueva relación modificada R' que no contiene el atributo M.
Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.
La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)
nss nombre puesto salario
111 Juan Pérez Jefe de Área 3000
222 José Sánchez Administrativo 1500
333 Ana Díaz Administrativo 1500
... ... ... ...
Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):
nss email
... ...
Segunda forma normal (2FN)
Un esquema está en 2FN si:
Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tablaEMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta:
nss nombre puesto salario
111 Juan Pérez Jefe de Área 3000
222 José Sánchez Administrativo 1500
333 Ana Díaz Administrativo 1500
... ... ... ...
Y al eliminar de la tabla original estos atributos nos quedaría:
nss email
... ...
Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el problema de 1FN.Tercera forma normal (3FN)
Una relación está en tercera forma normal si, y sólo si:
está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicionalN el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
Por lo tanto la descomposición sería la siguiente:
nss nombre puesto
111 Juan Pérez Jefe de Área
222 José Sánchez Administrativo
333 Ana Díaz Administrativo
... ... ...
En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.
