MODELACIÓN DE BASES DE
DATOS Y SU IMPLEMENTACIÓN
EN SQL ESTÁNDAR .
CAPÍTULO 4
NORMALIZACIÓN DE LA
BASE DE DATOS.
Se divide en dos subtemas
4.1. Vicios del modelo relacional
4.2. El proceso de normalización
Vicios del modelo relacional
Son condiciones que dificultan o
complican el adecuado rendimiento y
confiabilidad de la base de datos.
Son 3:
Redundancia
Inconsistencia
Falta de integridad
Vicios del modelo relacional.
Redundancia.
Es el almacenamiento de los mismos datos
varias veces, dentro de una misma base de
datos.
Solo se permite la redundancia
controlada en el modelo relacional.
El problema de la redundancia:
Mantenerla es muy laborioso.
Vicios del modelo relacional.
Redundancia.
Ejemplo.
Solución.
Se elimina normalizando la base de
datos.
Los datos quedan en la tabla a la que
más profundamente pertenezcan.
Vicios del modelo relacional.
Inconsistencia
Es la diferencia de significado o codificación
de un mismo dato en diferentes partes de la
base de datos.
Se permiten mayúsculas y luego
minúsculas.
¿Cómo se presenta una Se permiten datos numericos y
inconsistencia? datos alfanuméricos
Dos claves diferentes de un
mismo concepto en los
catálogos.
Vicios del modelo relacional.
Inconsistencia
Ejemplo. Solución.
Categorizando de forma adecuada la
información.
Creando tablas de atributos
clasificados
Haciendo validaciones a nivel
campo
Vicios del modelo relacional.
Falta de integridad
Se presenta cuando teniendo dos tablas relacionadas se elimina en
la entidad fuerte, un registro que tiene asociados varios registros
de coincidencia en la entidad débil.
Vicios del modelo relacional.
Falta de integridad
Ejemplo. Solución.
Imponer restricciones
para que no se pueda
eliminar o modificar un
registro de una entidad
fuerte si se tiene un
registro relacionado en la
entidad débil.
El proceso de normalización
Consiste en aplicar reglas específicas que
permitan a los datos tener una estructura
de cohesión tal que permita llegar de
cualquier elemento del modelo a cualquier
otro elemento, utilizando relaciones entre
los elementos en un ambiente de
redundancia controlada.
Algunos de los beneficios de la
normalización son:
Se evita la redundancia innecesaria de datos.
Sólo se permite la redundancia de valores en los
atributos llave (primaria - foránea), y sólo con el fin de
que sean posibles las relaciones entre elementos.
Se evitan la inconsistencia de los datos.
Al evitarse la redundancia innecesaria, al actualizar un
dato, ese dato queda actualizado para cualquier
aplicación.
Se evita la falta de integridad de los datos.
Al formar relaciones obligatorias entre los elementos, se
evita la eliminación o actualización de en un elemento,
que son requeridos por otro elemento.
Formas normales básicas
Al conjunto de reglas que deben aplicarse
al modelo de datos para que sea
considerada normalizada, se le llaman
formas normales (normal forms, o NF).
Las formas normales son las
herramientas que te permitirán controlar
toda esta serie de problemas dentro del
uso de bases de datos.
Aunque hay un gran número de reglas en el álgebra relacional, para
efectos de las bases de datos, se consideran básicas las primeras tres
formas normales, que son:
1NF (Primera forma normal): Todos los
atributos son atómicos.
2NF (Segunda forma normal): Todos los
atributos no atómicos tienen dependencia
funcional completa con la llave primaria.
3NF (Tercera forma normal): No existen
dependencias funcionales transitivas.
Las formas normales son acumulativas, es decir, que cada forma normal exige el cumplimiento de la anterior.
ii) Caso práctico
Imagina que la facturación de una
compañía de venta de suministros de
cómputo está siendo mantenida en
una hoja electrónica de cálculo, y
desea ponerse en una base de datos.
Cada vez que un cliente realiza una
compra, se registra la información de la
factura, del cliente, de los productos
que está comprando y las promociones
que le fueron otorgadas. La compañía por lo pronto maneja un
límite máximo de 3 promociones por
producto, en cada venta.
ii) Caso práctico
PrecioVenta UMed:
Una parte de los registros están así:: Unidad de
: Precio al
Correos: Correos que se medida del
FechaFact: Fecha en PR2: Código de
electrónicos del producto
que se realiza la DescProd: Descripción promoción vendió el
cliente. vendido.
factura. del producto. aplicable. producto.
NumFact: NumClie: Número que
Número de la PR1: Código de
identifica a un CodProd: Código del
factura. PR3: Código de Cant: Cantidad DescUMed:
cliente. producto que se está promoción
promoción de unidades Descripción de la
comprando. 7. aplicable
aplicable. vendidas. unidad de
DescProd: Descripción
medida.
del producto.
Falta de integridad
Antes de entender las reglas de normalización, es necesario entender
el concepto de dependencias funcionales.
Una dependencia funcional es la circunstancia en la cual un atributo es
determinante de otro (X→ Y).
Existen diferentes tipos de dependencia funcional:
a) Dependencia Funcional Completa: Es cuando un atributo no primo
está determinado por la totalidad de la llave primaria.
b) Dependencia Funcional Parcial: Es cuando, existiendo una llave
primaria compuesta, un atributo no primo es determinado por parte
de la llave primaria, pero no por su totalidad.
c) Dependencia Funcional Transitiva: Es cuando un atributo no primo
es determinado por otro atributo no primo.
1NF (Primera Forma Normal)
Se cumple con la primera forma normal (1NF), sí y sólo sí:
Condición 1: La tabla tiene una llave primaria.
Condición 2: La llave primaria no contiene valores nulos.
Condición 3: Se tienen atributos uniformes a nivel registro.
Condición 4: Todos los atributos son atómicos.
Un atributo atómico es aquél que contiene un solo dato, y no puede dividirse.
La división puede darse de varias maneras: a) un atributo contiene varios
datos, o b) porque un mismo dato puede ponerse sin problemas en varios
atributos, dado que en esencia es lo mismo.
Por atributos uniformes, nos referimos a que en una tabla todos los
registros tienen el mismo número de atributos, es decir, no hay registros con
más o con menos atributos que otros; además, los datos contenidos en los
atributos tienen el mismo dominio, es decir, no se permite que, para un
registro, un dato sea numérico, y para otro registro sea alfabético.
En el ejemplo, se tiene una llave primaria, que es el número de factura, dado
que es lo que queremos registrar (NumFact). Se cumple la condición 1. Como
se puede ver, no se tienen valores nulos en los atributos primos, por lo que se
cumple la condición 2. Los atributos son uniformes (condición 3), puesto que
todos los registros tienen el mismo número de atributos, y la información
contenida es consistente en cuanto al dominio de tipo. Sin embargo, se dan
ciertas violaciones respecto a los atributos atómicos.
Por ejemplo, el campo Correo contiene más de un dato en su contenido.
La forma de resolverlo es generando copias del registro. Cada valor distinto
contenido en Correo constituye la variación entre uno y otro registro. La
tabla quedaría como sigue.
2NF (Segunda Forma Normal)
Se está en segunda forma normal (2NF), sí y sólo sí:
Condición 1: Se cumple con la primera forma normal (1NF).
Condición 2: Si todos los atributos no primos tienen dependencia funcional
completa con la llave primaria.
Condición 3: Si no existen dependencias funcionales parciales (sólo en el caso
de tablas con llave primarias compuestas).
Concentrémonos en la siguiente porción de datos de ejemplo, relacionada
con la factura 2345:
Queda claro que cuando NumFact es 2345, FechaFact siempre es
01/01/2011, y que NumClie siempre es 101; podemos decir, que tanto
FechaFact como NumClie tienen dependencia funcional completa con la
llave primaria.
Por otro lado, también puedes comprobar que cuando NumFact es 2345, los
campos CodProd, DescProd, PrecioVenta, Cant, UMed y DescUMed
pueden tener diferentes valores, por lo que se dice que no tienen
dependencia funcional completa.
3NF (TERCERA FORMA NORMAL)
Se está en tercera forma normal (3NF), si y sólo sí:
a) Condición 1: Se cumple con la segunda forma normal (2NF)
b) Condición 2: No existen dependencias funcionales transitivas
Una dependencia funcional transitiva se presenta cuando un atributo no
primo tiene dependencia funcional completa respecto a uno o varios
atributos no primos.
En este ejemplo, la única dependencia funcional transitiva se da en la tabla que
almacena el detalle de la factura
FIGURA 4.13: Depemdencia funcional transitiva.
En este caso, existe una dependencia funcional transitiva entre UMed y DescUMed; en
ese sentido, se debe decidir cuál de los dos campos es el que operará como llave, y es el
campo que permanecerá en la tabla.
Los campos que tienen la dependencia funcional pasarán a formar una nueva tabla, que
heredará la llave primaria, quedando como sigue.
FIGURA 4.14: Solución a la dependecia funcional transitiva.
BCNF (FORMA NORMAL BOYCE CODD)
Se le llama llave candidata al conjunto de atributos mínimo, suficiente y necesario
para identificar como único un registro dentro de una tabla, pero que no es la llave
primaria, aunque podría serlo.
Esto se da cuando se tienen dos posibles llaves que podrían actuar como llave
primaria. En nuestro ejemplo, la tabla curso tiene como llave primaria codigo_curso,
pero además tiene un campo llamado id_ue, que es un código equivalente que podría
funcionar como llave primaria.
Se está en BNF cuando:
Condición 1: Se cumple con la tercera forma normal (3NF).
Condición 2: Todos los atributos no primos tienen dependencia
funcional completa con las llaves candidatas.
Si un modelo está en BCNF, está indudablemente en 3NF, pero no todo el
modelo que está en 3NF, está en BCNF; esto principalmente sucede
cuando la llave primaria es compuesta, y la llave candidata es simple, lo
que nos lleva a cuestionar si no era más eficiente elegir llave primaria a la
candidata.
DESNORMALIZACIÓN
El proceso de desnormalización implica violar las formas normales con el fin
de proporcionarle al uso de la base prestaciones de desempeño o de
economía de recursos.
El modelo de base de datos relacional se basa en el álgebra relacional, y la
normalización es un proceso que ayuda a que el modelo esté estructurado y
pueda utilizarse de una manera eficiente. Esto es, al menos en teoría.
Existen tres formas básicas de desnormalizar:
a) Creación de llave primaria ficticia.
b) Partición horizontal.
c) Partición vertical.
La creación de llave primaria ficticia se da cuando, para no tener una llave
primaria compuesta de muchos campos, se genera una llave que no forma parte
de los datos inherentes a lo que se quiere registrar: generalmente es una clave
numérica consecutiva, y se pone sólo con el objeto de identificar. Esto origina que
los campos que originalmente eran la llave primaria se constituyen como una llave
candidata, y con ello se generen dependencias funcionales transitivas.
Cuando se divide una misma tabla, dejando una parte de los registros en una tabla
y el resto en otra, se le llama partición horizontal, y se provoca un escenario de
dos tablas con los mismos campos y las mismas llaves primarias, lo que se opone a
la normalización.
Otro uso muy común de las particiones horizontales son la división de datos por
periodo de tiempo, es decir, en la tabla de operación se dejan los datos del año en
curso, mientras que los datos de los años anteriores se guardan en una tabla de
datos históricos
También se da el caso que una tabla tenga una gran cantidad de atributos, pero
que una gran cantidad de ellos se encuentren sin datos para la mayoría de los
registros. En ese caso, se puede dejar una tabla con los atributos que
generalmente tienen contenido, y crear otra tabla con la misma llave, que
contenga los atributos que generalmente están vacíos o sin valor. A esta
división se le llama partición vertical
