You are on page 1of 2

Normalización de bases de datos

El proceso de normalización de bases de datos consiste en aplicar una serie de reg


las a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo
relacional.
Las bases de datos relacionales se normalizan para:
• Evitar la redundancia de los datos.
• Evitar problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.
Terminología relacional equivalente

Figura 1.0: Trabajo (Código, Nombre, Posición, Salario), donde Código es la Clave Prim
aria
Terminología relacional equivalente
• Tupla = registro, fila o renglón
• Atributo = columna o campo
• Clave Primaria = clave candidata elegida
• Clave Ajena = clave externa o clave foránea
• 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que u
na base de datos está en la forma normal N es decir que todas sus tablas están en la
forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las ne
cesidades de la mayoría de las bases de datos. El creador de estas 3 primeras form
as normales (o reglas) fue Edgar F. Codd.
Primera Forma Normal (1FN)
Una tabla está en Primera Forma Normal sólo si
• Todos los atributos son atómicos. Un atributo es atómico si los elementos del domin
o son indivisibles.
• La tabla contiene una clave primaria.
• La tabla no contiene atributos nulos. Sin embargo, debe ser observado que este a
specto es controvertido. Muchos autores consideran que una tabla está en 1FN si ni
nguna clave candidata puede contener valores nulos, pero se aceptan éstos para atr
ibutos (campos) que no sean clave
• Si no posee ciclos repetitivos.

Grupos repetidos
La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como
la característica que define la 1FN", concierne a grupos repetidos. El siguiente e
jemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupo
s, en violación de la 1NF.
Ejemplo 1: Dominios y valores
Suponga que un diseñador principiante desea guardar los nombres y los números telefóni
cos de los clientes. Procede a definir una tabla de cliente como la que sigue:
Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
789 Maria Fernandez 555-808-9633
En este punto, el diseñador se da cuenta de un requisito debe guardar múltiples número
s telefónicos para algunos clientes. Razona que la manera más simple de hacer esto e
s permitir que el campo "Teléfono" contenga más de un valor en cualquier registro da
do:
Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
555-776-4100
789 Maria Fernandez 555-808-9633
Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de domin
io de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de long
itud), la representación de arriba no está en 1FN.
Ejemplo 2: Grupos repetidos a través de columnas
El diseñador puede evitar esta restricción definiendo múltiples columnas del número tele
fónico:
Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Osvaldo Ingram 555-861-2025
456 James Wright 555-403-1659 555-776-4100
789 Maria Fernandez 555-808-9633
Sin embargo, esta representación hace uso de columnas que permiten valores nulos,
y por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si se
contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía c
on el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mi
smo dominio y exactamente el mismo significado; el dividir del número de teléfono en
tres encabezados es artificial y causa problemas lógicos. Estos problemas incluye
n:
• Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales com
o "¿Qué cliente tiene el teléfono X?"
• La restricción de los números de teléfono por cliente a tres. Si viene un cliente c
cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el cu
arto sin guardar. Esto significa que el diseño de la base de datos está imponiendo r
estricciones al proceso del negocio, en vez de (como idealmente debe ser el caso
) al revés.
Un diseño conforme con 1FN
Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente
y una tabla de teléfono del cliente.

You might also like