Primera forma normal
La primera forma normal (1FN o forma mnima) es una forma normal usada
en normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a
la 1FN es una que satisface cierto conjunto mnimo de criterios. Estos criterios se refieren
bsicamente a asegurarse que la tabla es una representacin fiel de una relacin1 y est libre
de "grupos repetitivos".2
Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por
diferentes tericos. Como consecuencia, no hay un acuerdo universal en cuanto a qu
caractersticas descalificaran a una tabla de estar en 1FN. Muy notablemente, la 1FN, tal y
como es definida por algunos autores excluye "atributos relacin-valor" (tablas dentro de
tablas) siguiendo el precedente establecido por (E.F. Codd) (algunos de esos autores son:
Ramez Elmasri y Shamkant B. Navathe3 ). Por otro lado, segn lo definido por otros autores, la
1FN s los permite (por ejemplo como la define Chris Date).
ndice
[ocultar]
1 Las tablas 1FN como representaciones de relaciones
2 Grupos repetidos
o
2.1 Ejemplo 1: Dominios y valores
2.2 Ejemplo 2: Grupos repetidos a travs de columnas
2.3 Ejemplo 3: Repeticin de grupos dentro de columnas
2.4 Un diseo conforme con 1FN
3 Atomicidad
4 Normalizacin ms all de la 1NF
5 Notas y referencias
6 Vase tambin
7 Lectura adicional
8 Enlaces externos
Las tablas 1FN como representaciones de relaciones [editar]
Segn la definicin de Date de la 1FN, una tabla est en 1FN si y solo si es "isomorfa a alguna
relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila-y-columna contiene exactamente un valor del
dominio aplicable (y nada ms).
5. Todas las columnas son regulares [es decir, las filas no tienen componentes
como IDs de fila, IDs de objeto, o timestamps ocultos].
Chris Date, "What First Normal Form Really Means", pp. 127-8 4
La violacin de cualesquiera de estas condiciones significara que la
tabla no es estrictamente relacional, y por lo tanto no est en 1FN.
Algunos ejemplos de tablas (o de vistas) que no satisfacen esta
definicin de 1FN son:
Una tabla que carece de una clave primaria. Esta tabla podra
acomodar filas duplicadas, en violacin de la condicin 3.
Una vista cuya definicin exige que los resultados sean
retornados en un orden particular, de modo que el orden de la fila
sea un aspecto intrnseco y significativo de la vista. 5 Esto viola la
condicin 1. Las tuplas en relaciones verdaderas no estn
ordenadas una con respecto de la otra.
Una tabla con por lo menos un atributo que pueda ser nulo. Un
atributo que pueda ser nulo estara en violacin de la condicin 4,
que requiere a cada campo contener exactamente un valor de su
dominio de columna. Sin embargo, debe observarse que este
aspecto de la condicin 4 es controvertido. Muchos autores
consideran que una tabla est en 1FN si ninguna clave candidata
puede contener valores nulos, pero se aceptan stos para
atributos (campos) que no sean clave, segn el modelo original
de Codd sobre el modelo relacional, el cual hizo disposicin
explcita para los nulos.6
Grupos repetidos[editar]
La cuarta condicin de Date, que expresa "lo que la mayora de la
gente piensa como la caracterstica que define la 1FN",7 concierne a
grupos repetidos. El siguiente ejemplo ilustra cmo un diseo de base
de datos puede incorporar la repeticin de grupos, en violacin de la
1FN.
Ejemplo 1: Dominios y valores[editar]
Suponga que un diseador principiante desea guardar los nombres y
los nmeros telefnicos de los clientes. Procede a definir una tabla de
cliente como la que sigue:
Cliente
ID Cliente
Nombre
Apellido
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659
789
Cesar
Dure
555-808-9633
En este punto, el diseador se da cuenta de un requisito para
guardar mltiples nmeros telfonicos para algunos clientes. Razona
que la manera ms simple de hacer esto es permitir que el campo
"Telfono" contenga ms de un valor en cualquier registro dado:
Cliente
ID Cliente
Nombre
Apellido
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659
555-776-4100
789
Cesar
Dure
555-808-9633
Asumiendo, sin embargo, que la columna "Telfono" est definida en
algn tipo de dominio de nmero telefnico (por ejemplo, el dominio
de cadenas de 12 caracteres de longitud), la representacin de arriba
no est en 1FN. La 1FN (y, para esa materia, el RDBMS) prohbe a
un campo contener ms de un valor de su dominio de columna.
Ejemplo 2: Grupos repetidos a travs de
columnas[editar]
El diseador puede evitar esta restriccin definiendo mltiples
columnas del nmero telefnico:
Cliente
ID Cliente
Nombre
Apellido
Telfono 1
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659
789
Cesar
Dure
555-808-9633
Telfono 2
555-776-4100
Sin embargo, esta representacin hace uso de columnas que
permiten valores nulos, y por lo tanto no se conforman con la
definicin de la 1NF de Date. Incluso si se contempla la posibilidad de
columnas con valores nulos, el diseo no est en armona con el
espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3, comparten
exactamente el mismo dominio y exactamente el mismo significado;
dividir los nmeros de telfono en tres encabezados es artificial y
causa problemas lgicos. Estos problemas incluyen:
Dificultad en hacer consultas a la tabla. Es difcil contestar
preguntas tales como "Qu clientes tienen el telfono X?" y
"Qu pares de clientes comparten un nmero de telfono?".
La imposibilidad de hacer cumplir la unicidad los enlaces Clientea-Telfono por medio del RDBMS. Al cliente 789 se le puede dar
equivocadamente un valor para el Telfono 2 que es exactamente
igual que el valor de su Telfono 1.
La restriccin de los nmeros de telfono por cliente a tres. Si
viene un cliente con cuatro nmeros de telfono, estamos
obligados a guardar solamente tres y dejar el cuarto sin guardar.
Esto significa que el diseo de la base de datos est imponiendo
Telfon
restricciones al proceso del negocio, en vez de (como idealmente
debe ser el caso) al revs.
Ejemplo 3: Repeticin de grupos dentro de
columnas[editar]
El diseador puede, alternativamente, conservar una sola columna de
nmero de telfono, pero alterando su dominio, haciendo una cadena
de suficiente longitud para acomodar mltiples nmeros telefnicos:
Cliente
ID Cliente
Nombre
Apellido
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659, 555-776-4100
789
Cesar
Dure
555-808-9633
ste es defendiblemente el peor diseo de todos, y otra vez no
mantiene el espritu de la 1NF. El encabezado "Telfono" llega a
ser semnticamente difuso, ya que ahora puede representar, o un
nmero de telfono, o una lista de nmeros de telfono, o de hecho
cualquier cosa. Una consulta como "Qu pares de clientes
comparten un nmero telefnico?" es virtualmente imposible de
formular, dada la necesidad de proveerse de listas de nmeros
telefnicos as como nmeros telefnicos individuales. Con este
diseo en la RDBMS, son tambin imposibles de definir significativas
restricciones en nmeros telefnicos.
Un diseo conforme con 1FN[editar]
Un diseo que est inequvocamente en 1FN hace uso de dos tablas:
una tabla de cliente y una tabla de telfono del cliente.
Cliente
ID Cliente
123
Nombre
Rachel
Apellido
Ingram
456
James
Wright
789
Cesar
Dure
Telfono del cliente
ID Cliente
Telfono
123
555-861-2025
456
555-403-1659
456
555-776-4100
789
555-808-9633
En este diseo no ocurren grupos repetidos de nmeros
telefnicos. En lugar de eso, cada enlace Cliente-a-Telfono
aparece en su propio registro. Es valioso notar que este diseo
cumple los requerimientos adicionales para la segunda (2NF) y la
tercera forma normal (3FN).
Atomicidad[editar]
Algunas definiciones de 1NF, ms notablemente la de E.F. Codd,
hacen referencia al concepto de atomicidad. Codd indica que "se
requiere que los valores sean atmicos con respecto al DBMS en
los dominios en los que cada relacin es definida". 8 Codd define
un valor atmico como uno que "no puede ser descompuesto en
pedazos ms pequeos por el DBMS (excepto ciertas funciones
especiales)".9
[Hugh Darwen] y [Chris Date] han sugerido que el concepto de
Codd de un "valor atmico" es ambiguo, y que esta ambigedad
ha conducido a una extensa confusin sobre cmo debe ser
entendida la 1NF.10 11 En particular, la nocin de un "valor que no
puede ser descompuesto" es problemtica, pues parecera
implicar que pocos, si algn, tipos de datos son atmicos:
Una cadena de caracteres parecera no ser atmica, ya que
el RDBMS tpicamente proporciona operadores para
descomponerla en subcadenas.
Una fecha parecera no ser atmica, ya que el RDBMS
proporciona tpicamente operadores para descomponerla los
componentes de da, mes, y ao.
Un nmero de punto fijo parecera no ser atmico, ya que el
RDBMS proporciona tpicamente operadores para
descomponerlo en componentes de nmeros enteros y
fraccionarios.
Date sugiere que "la nocin de atomicidad no tiene ningn
significado absoluto":12 un valor puede ser considerado atmico
para algunos propsitos, pero puede ser considerado un
ensamblaje de elementos ms bsicos para otros propsitos. Si
esta posicin es aceptada, la 1NF no puede ser definida con
referencia a la atomicidad. Las columnas de cualquier tipo de
datos concebible (desde tipos de cadenas y tipos numricos
hasta tipos de arreglos y tipos de tabla) son entonces aceptables
en un tabla 1NF - aunque quizs no siempre deseable. Date
discute que los atributos relacin-valor, por medio de los cuales
un campo dentro de una tabla puede contener una tabla, son
tiles en casos raros.13
Normalizacin ms all de la 1NF[editar]
Cualquier tabla que est en la segunda forma normal (2NF) o
ms arriba, tambin est, por definicin, en 1NF (cada forma
normal tiene criterios ms rigurosos que su precursor). Por una
parte, una tabla que est en 1NF puede o no puede estar en
2NF; si est en 2NF, puede o no puede estar en 3NF, y as
sucesivamente.
Las formas normales ms arriba que la 1NF son pensadas para
ocuparse de las situaciones en las que una tabla sufre de
problemas de diseo que pueden comprometer laintegridad de
los datos dentro de ella. Por ejemplo, la tabla siguiente est en
1NF, pero no est en 2NF y por lo tanto es vulnerable a
inconsistencias lgicas:
Direccin de correo del subscriptor
ID del
subscriptor
Direccin de correo
Primer nombre
del subscriptor
Apell
subsc
108
[email protected]
Steve
Wallace
252
[email protected]
Carol
Robertso
252
[email protected]
Carol
Robertso
360
[email protected]
Harriet
Clark
La clave de la tabla es {ID del subscriptor, Direccin de correo}.
Si Carol Robertson cambia su apellido por el de matrimonio, el
cambio debe ser aplicado a dos filas. Si el cambio es aplicado
solamente a una fila, resulta en una contradiccin: la pregunta
"cul es nombre del cliente 252?" tiene dos respuestas que estn
en conflicto. La 2NF aborda este problema.
