Tema 4: Transformación del esquema conceptual al
relacional
Grados de
normalización
Existen
básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda
Forma Normal (2NF) y Tercera Forma Normal (3NF) a la que se conoce como forma normal de Boyce‑Codd
(FNBC). Todas estas formas normales se basan en las
dependencias funcionales entre los atributos de una relación. Más adelante se
propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de
dependencias multivaluadas y dependencias de reunión, respectivamente. Cada
una de estas formas tiene sus propias reglas.
Cuando una
base de datos se conforma a un nivel, se considera normalizada a esa forma de
normalización. Por ejemplo, supongamos que una base de datos cumple con todas
las reglas del segundo nivel de normalización. Se considera que está en la
Segunda Forma Normal. Sin embargo, no siempre es conveniente tener una base de
datos conformada en el nivel más alto de normalización. Puede llevar a un nivel
de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de
normalización.
Primera Forma
Normal
Es
la más elemental de todas.
La regla de la
Primera Forma Normal establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas. Estas
nuevas tablas heredan la clave primaria de la relación
Observemos el
esquema de la tabla MClientes de la base de datos.
MClientes
ID Cliente
Nombre
Apellidos
Dirección
Nombre_Producto1
Costo_Producto1
Nombre_Producto2
Costo_Producto2
Fecha_Pedido
Cantidad_Pedido
ID_Cia_Envios
Nombre_Cia_Envios
La tabla tiene
varias columnas repetidas. Éstas se refieren principalmente a los productos y
pedidos de estos. De acuerdo con la regla, deben eliminar las columnas
repetidas y crearles su propia tabla.
Eliminación de
columnas repetidas en una base de datos
|
MClientes
ID_Clientes
Nombre
Apellidos
Dirección
Número_Pedido
Fecha_Pedido
Cantidad_Pedido
ID_Producto
Cantidad_producto
ID_Cia_Envios
Nombre_Cia_Envios
| <><>
MProducto
ID_Producto
Nombre_Producto
Costo_Producto
| <><>
Así, se han relaciones
donde el cliente tendrá muchos productos que podrá comprar, sin importar
cuántos otros clientes quieran comprarlos también. Además, el cliente
necesitará haber pedido un producto para ser un cliente y ya no estamos
obligados a añadir un cliente cada vez que se añade un nuevo producto al
inventario.
Poner la base
de datos en la Primera Forma Normal resuelve el problema de los encabezados de
columna múltiples (Producto1, Producto2...). Muy a menudo, se comete el error
de crear columnas que representen los mismos datos, algo similar a una tabla no
normalizada.
La
normalización ayuda a hacer mas clara la base de datos, así como a organizarla
en partes más pequeñas y más fáciles de entender. En lugar de tener que
entender una tabla enorme que tiene muchos diferentes aspectos, solo tenemos
que entender elementos pequeños y más manejables, así como las relaciones que
guardan con otros elementos también pequeños, lo que nos lleva a que un mejor
entendimiento del funcionamiento de la base de datos conducirá a un mejor aprovechamiento
de su información.
Segunda Forma
Normal
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 de la tabla
para identificarlos. En la base de datos de muestra, la información de pedidos
está en cada uno de los registros. Sería mucho más simple utilizar únicamente
el número del pedido. El resto de la información podría residir en su propia
tabla. Una vez que se haya organizado la información de pedidos.
Eliminación de
las dependencias parciales -Segunda Forma Normal
|
MClientes
ID_Clientes
Nombre
Apellidos
Dirección
| <><>
MProducto
ID_Producto
Nombre_Producto
Costo_Producto
| <><>
EPedido
ID_Pedido
Fecha_Pedido
Cantidad_Pedido
ID_Producto
Cantidad_producto
ID_Cia_Envios
Nombre_Cia_Envios
| <><>
Una forma
sencilla de ver la segunda forma normal es que, para que una relación se
encuentre en ésta debe estar en primera forma normal y además todos los
atributos que no sean claves sean dependientes de modo irreducible de la clave
primaria.
Al haber
alcanzado la Segunda Forma Normal, podemos disfrutar de algunas de las ventajas
de las bases de datos relacionales. Por ejemplo, pueden añadirse nuevas
columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo
mismo aplica para las otras tablas. Alcanzar este nivel de normalización
permite que los datos se acomoden de una manera natural dentro de los límites esperados.
Una vez que ha
alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de
los problemas de lógica. Pueden insertarse registros sin un exceso de datos en
la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes,
vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El
siguiente nivel de normalización explicará cómo solucionar esto.
Tercera Forma
Normal
La regla de la
Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que
no sea clave. El valor de esta columna debe depender de la clave. Todos los
valores deben identificarse únicamente por la clave. En la base de datos de
muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se
identifica únicamente por la clave. Podría separar estos datos de la tabla y
ponerlos en una tabla aparte.
Eliminación de
los datos que no son claves para la Tercera Forma Normal
|
MClientes
ID_Clientes
Nombre
Apellidos
Dirección
| <><>
MProducto
ID_Producto
Nombre_Producto
Costo_Producto
| <><>
EPedido
ID_Pedido
Fecha_Pedido
Cantidad_Pedido
| <><>
DPedido
ID_Pedido
ID_Producto
Cantidad_producto
| <><>
MCias_Envios
ID_Cia_Envios
Nombre_Cia_Envios
|
El Diagrama ER simplificado sería:
Ahora todas
las tablas están en la Tercera Forma Normal. Esto da más flexibilidad y
previene errores de lógica cuando se insertan o borran registros. Cada columna
en la tabla está identificada de manera única por la clave, y no hay datos
repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y
expandir.
4.2
Diccionario de Datos
Cuando
diseñamos una base de datos, para hacer su tratamiento lo mas fácil posible, le
asignamos descriptores o “alias” a cada campo mediante el cual nos referimos a
él para su manipulación, por lo tanto es necesario dar una descripción de dicho
campo que estamos definiendo bajo determinado nombre, es por ello que se
requiere contar con un diccionario de datos, el cual contiene información
explicativa sobre los campos para facilitar a los desarrolladores el implementar
aplicaciones para manejar la base de datos y al mismo tiempo permite al mismo
diseñador mantener la noción de los mismos datos.
Siguiendo el
mismo ejemplo, tendríamos que el diccionario de datos para la entidad Clientes
sería:
ID_Cliente:
Identificador del cliente
Nombre: Nombre
del cliente
Apellidos:
Apellidos del cliente
Dirección:
Dirección del cliente
Veamos ahora
el caso de la entidad EPedido:
ID_Pedido:
Identificador del pedido
ID_Cliente:
Identificador del cliente que realiza el pedido
Fecha_Pedido:
Fecha en que se levanta el pedido
Numero_Pedido:
Número de control del pedido
ID_Cia_Envios:
Identificador de la compañía de envíos a utilizar
Podemos
observar en este último caso que la fecha del pedido se especifica si debe ser
la fecha en que se levanta el pedido. Si bien los atributos son intuitivos,
puede haber malentendidos en caso de no contar con el diccionario de datos,
como el pensar que la fecha mencionada pueda ser la fecha en la que se envía el
pedido.
4.3 Reducción
a tablas
El proceso de
reducción a tablas tiene algunas reglas:
Entidades
Ø Cada
entidad genera una tabla en la que cada atributo (simple) ocupa una columna y
el identificador será la llamada llave primaria de la tabla.
Ø Una
entidad débil genera una tabla en la que cada atributo (simple) ocupa una
columna y la llave primaria será el identificador o clave de la entidad de la
que dependen más los atributos.
Relaciones
Ø Las
relaciones 1:1 no generan tablas.
Ø Las
relaciones N:M generan tabla que incluye las claves de las entidades que se
relacionan además de su propio identificador que será su llave primaria.
Observa el siguiente gráfico qure ilustra el proceso:
Notación
para las llaves
Llave
primaria (*) Es un
atributo simple o compuesto que sirve para identificar un objeto de manera
univoca, es decir, debe ser única
Llave
foránea (**) Es aquel
atributo que es llave primaria en una entidad y que se relaciona con una
segunda entidad. En la segunda entidad se llama llave foránea
Llave
secundaria (*) Es
cualquier atributo que va a servir para realizar búsquedas dentro de una misma
entidad
Llave
compuesta (***) Atributos
que sirven para identificación único esta llave es utilizada solamente en caso
de que no exista un atributo que pueda identificar por si solo a un objeto de
otro
Dando
seguimiento al ejemplo, la definición de nuestra tabla de Clientes será
la siguiente:
|
ID_Cliente
| <><>
Nombre
| <><>
Apellidos
| <><>
Dirección
| <><>
|
*
| <><>
***
| <><>
***
| <><>
***
| <><>
El campo
ID_Cliente será la llave primaria, que será única e irrepetible para
diferenciar los registros entre sí.
Para la
entidad DPedido, la tabla es:
|
ID_DPedido
| <><>
ID_Pedido
| <><>
ID_Producto
| <><>
Cantidad_Pedidos
| <><>
Costo_Pedido
| <><>
|
*
| <><>
**
| <><>
**
| <><>
***
| <><>
***
| <><>
La llave
primaria será el campo ID_DPedido, y se incluyen además los campos ID_Pedido
junto con ID_Producto, pues sin un pedido encabezado no puede haber detalles
del pedido, al mismo tiempo que sin productos, no puede haber pedido detallado.
La tabla de la
entidad EPedido sería:
|
ID_Pedido
| <><>
ID_Cliente
| <><>
Fecha_Pedido
| <><>
ID_Cia_Envios
| <><>
|
*
| <><>
**
| <><>
***
| <><>
**
| <><>
Si bien no
puede haber un pedido encabezado sin pedido detallado (que tiene la información
de los productos), ya hemos relacionado ambas tablas mediante el campo
ID_Pedido en la tabla DPedido, lo que cobra más sentido al imaginar cómo se
llenan las tablas. Cuando un cliente haga un pedido, primero se registrará en
el sistema la información de EPedido, y posteriormente se registrarán los
valores en la tabla DPedido con la información de los productos seleccionados y
el pedido maestro al que pertenecen, pudiendo llenar varios registros en DPedido
con el mismo valor de ID_Pedido, es decir, el mismo pedido encabezado.
No hay comentarios:
Publicar un comentario