Deja
Se le ha pedido que desarrolle una base de datos para realizar un seguimiento del mantenimiento de varias
máquinas para un
fabricante de tamaño medio
. El mantenimiento programado es sencillo,
pero cuando algo sale mal, generalmente se llama a un equipo de trabajadores para resolver el
problema.
Mantenimiento de la
máquina ID de la máquina: A202 Fecha de compra: 23 de agosto de 2002
Ubicación: Piso C Gerente: Daniel Hugh
Dirección: 22 Castle Street, Luton Departamento: Fabricación
Fecha
programada
Finalidad Comentario del trabajador
2 de enero Comprobación de aceite Peter Wood Fine
5 de febrero Desalineación Darren Hill Fine
9 de febrero Reparación de ruedas Peter Wood Incompleta No
programada
Fecha Problema Especialidad del trabajador Descripción de la corrección
13 de enero Fallo del instrumento John Smith pospuesto Debe
normalizar la tabla en
tablas relacionales interconectadas
para que
se pueda diseñar una
base de datos en Microsoft Access de acuerdo con las tablas normalizadas.
A) Normalizar la tabla en tablas relacionales (a la 3ª Forma Normal); enumere los
atributos en cada tabla.
Clotilde
First Normal Form (1NF) establece las reglas muy básicas para una base de datos organizada:
* Elimina columnas duplicadas de la misma tabla.
* Cree tablas separadas para cada grupo de datos relacionados e identifique cada fila con una columna única (la clave principal).
¿Qué significan estas reglas al contemplar el diseño práctico de una base de datos? De hecho, es bastante simple.
La primera regla dicta que no debemos duplicar datos dentro de la misma fila de una tabla. Dentro de la comunidad de bases de datos, este concepto se conoce como la atomicidad de una tabla. Se dice que las tablas que cumplen con esta regla son atómicas. Exploremos este principio con un ejemplo clásico: una tabla dentro de una base de datos de recursos humanos que almacena la relación gerente-subordinado. Para los propósitos de nuestro ejemplo, impondremos la regla comercial de que cada gerente puede tener uno o más subordinados, mientras que cada subordinado puede tener solo un gerente.
Intuitivamente, al crear una lista u hoja de cálculo para rastrear esta información, podríamos crear una tabla con los siguientes campos:
* Gerente
* Subordinado1
* Subordinado2
* Subordinado3
* Subordinado4
Sin embargo, recuerde la primera regla impuesta por 1NF: eliminar columnas duplicadas de la misma tabla. Claramente, las columnas Subordinate1-Subordinate4 son duplicadas. Tómese un momento y reflexione sobre los problemas que plantea este escenario. Si un gerente solo tiene un subordinado, las columnas Subordinate2-Subordinate4 son simplemente espacio de almacenamiento desperdiciado (un bien valioso de la base de datos). Además, imagine el caso en el que un gerente ya tiene 4 subordinados: ¿qué sucede si contrata a otro empleado? Toda la estructura de la tabla requeriría modificaciones.
En este punto, a los principiantes en bases de datos se les suele ocurrir una segunda idea brillante: no queremos tener más de una columna y queremos permitir una cantidad flexible de almacenamiento de datos. Probemos algo como esto:
* Gerente
* Subordinados
Donde el campo Subordinados contiene múltiples entradas en el formulario "Mary, Bill, Joe"
Esta solución está más cerca, pero tampoco llega a la marca. La columna de subordinados sigue siendo duplicada y no atómica. ¿Qué sucede cuando necesitamos agregar o eliminar un subordinado? Necesitamos leer y escribir todo el contenido de la tabla. Eso no es gran cosa en esta situación, pero ¿y si un gerente tuviera cien empleados? Además, complica el proceso de selección de datos de la base de datos en consultas futuras.
Aquí hay una tabla que satisface la primera regla de 1NF:
* Gerente
* Subordinado
En este caso, cada subordinado tiene una sola entrada, pero los gerentes pueden tener múltiples entradas.
Ahora, ¿qué pasa con la segunda regla: identificar cada fila con una columna única o un conjunto de columnas (la clave principal)? Puede echar un vistazo a la tabla anterior y sugerir el uso de la columna subordinada como clave principal. De hecho, la columna de subordinados es un buen candidato para una clave primaria debido al hecho de que nuestras reglas de negocio especificaron que cada subordinado puede tener un solo administrador. Sin embargo, los datos que hemos elegido almacenar en nuestra tabla hacen que esta sea una solución menos que ideal. ¿Qué sucede si contratamos a otro empleado llamado Jim? ¿Cómo almacenamos su relación gerente-subordinado en la base de datos?
Es mejor utilizar un identificador verdaderamente único (como una identificación de empleado) como clave principal. Nuestra mesa final se vería así:
* ID de gerente
* ID de subordinado
2ª forma normal
Durante el último mes, hemos analizado varios aspectos de la normalización de una tabla de base de datos. Primero, discutimos los principios básicos de la normalización de bases de datos. La última vez, exploramos los requisitos básicos establecidos por la primera forma normal (1NF). Ahora, continuemos nuestro viaje y cubramos los principios de la segunda forma normal (2NF).
Recuerde los requisitos generales de 2NF:
* Elimine subconjuntos de datos que se aplican a múltiples filas de una tabla y colóquelos en tablas separadas.
* Crear relaciones entre estas nuevas tablas y sus predecesoras mediante el uso de claves externas.
Estas reglas se pueden resumir en una declaración simple: 2NF intenta reducir la cantidad de datos redundantes en una tabla extrayéndolos, colocándolos en nuevas tablas y creando relaciones entre esas tablas.
Veamos un ejemplo. Imagine una tienda en línea que mantiene la información del cliente en una base de datos. Pueden tener una sola tabla llamada Clientes con los siguientes elementos:
* CustNum
* FirstName
* LastName
* Address
* City
* State
* ZIP
Un breve vistazo a esta tabla revela una pequeña cantidad de datos redundantes. Estamos almacenando las entradas "Sea Cliff, NY 11579" y "Miami, FL 33157" dos veces cada una. Ahora, eso puede no parecer demasiado almacenamiento adicional en nuestro ejemplo simple, pero imagina el espacio desperdiciado si tuviéramos miles de filas en nuestra tabla. Además, si cambiara el código postal de Sea Cliff, tendríamos que realizar ese cambio en muchos lugares de la base de datos.
En una estructura de base de datos compatible con 2NF, esta información redundante se extrae y almacena en una tabla separada. Nuestra nueva tabla (llamémosla ZIP) podría tener los siguientes campos:
* ZIP
* Ciudad
* Estado
Si queremos ser súper eficientes, incluso podemos llenar esta tabla con anticipación: la oficina de correos proporciona un directorio de todos los códigos postales válidos y sus relaciones ciudad / estado. Seguramente, se ha encontrado con una situación en la que se utilizó este tipo de base de datos. Alguien que tomó un pedido podría haberle preguntado primero su código postal y luego haber sabido la ciudad y el estado desde el que estaba llamando. Este tipo de disposición reduce el error del operador y aumenta la eficiencia.
Ahora que hemos eliminado los datos duplicados de la tabla Clientes, cumplimos con la primera regla de la segunda forma normal. Todavía necesitamos usar una clave externa para unir las dos tablas. Usaremos el código postal (la clave principal de la tabla ZIP) para crear esa relación. Aquí está nuestra nueva tabla de Clientes:
* CustNum
* Nombre
* Apellido
* Dirección
* ZIP
¡Ahora hemos minimizado la cantidad de información redundante almacenada dentro de la base de datos y nuestra estructura está en la segunda forma normal!
3RD Forma normal
Hay dos requisitos básicos para que una base de datos esté en la tercera forma normal:
* Cumplir ya con los requisitos de 1NF y 2NF
* Eliminar columnas que no dependen completamente de la clave principal.
Imagine que tenemos una tabla de pedidos de widgets que contiene los siguientes atributos:
* Número de pedido
* Número de cliente
* Precio unitario
* Cantidad
* Total
Recuerde, nuestro primer requisito es que la mesa debe satisfacer los requisitos de 1NF y 2NF. ¿Hay columnas duplicadas? No. ¿Tenemos una clave principal? Sí, el número de pedido. Por lo tanto, cumplimos con los requisitos de 1NF. ¿Hay algún subconjunto de datos que se aplique a varias filas? No, también cumplimos con los requisitos de 2NF.
Ahora bien, ¿todas las columnas dependen completamente de la clave principal? El número de cliente varía con el número de pedido y no parece depender de ninguno de los otros campos. ¿Qué pasa con el precio unitario? Este campo podría depender del número de cliente en una situación en la que cobramos a cada cliente un precio fijo. Sin embargo, al observar los datos anteriores, parece que a veces cobramos precios diferentes al mismo cliente. Por lo tanto, el precio unitario depende completamente del número de pedido. La cantidad de artículos también varía de un pedido a otro, así que estamos bien.
¿Y el total? Parece que podríamos tener problemas aquí. El total se puede obtener multiplicando el precio unitario por la cantidad, por lo tanto, no depende completamente de la clave principal. Debemos retirarlo de la tabla para cumplir con la tercera forma normal. Quizás usemos los siguientes atributos:
* Número de pedido * Número de
cliente
* Precio unitario
* Cantidad
Ahora nuestra tabla está en 3NF. Pero, podría preguntarse, ¿qué pasa con el total? Este es un campo derivado y es mejor no almacenarlo en la base de datos. Podemos simplemente calcularlo "sobre la marcha" al realizar consultas a la base de datos. Por ejemplo, podríamos haber usado esta consulta anteriormente para recuperar números de pedido y totales:
SELECT OrderNumber, Total
FROM WidgetOrders
Ahora podemos usar la siguiente consulta:
SELECT OrderNumber, UnitPrice * Cantidad AS Total
FROM WidgetOrders
para lograr los mismos resultados sin violar las reglas de normalización.
Antes de comenzar nuestra discusión sobre las formas normales, es importante señalar que solo son pautas y pautas. De vez en cuando, es necesario alejarse de ellos para cumplir con los requisitos comerciales prácticos. Sin embargo, cuando se producen variaciones, es extremadamente importante evaluar las posibles ramificaciones que podrían tener en su sistema y tener en cuenta las posibles inconsistencias.