Normalizacin de bases de datos

La normalizacin de bases de datos es un proceso que

consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin
al modelo relacional.

Clave Alternativa = clave secundaria

Las bases de datos relacionales se normalizan para:

RDBMS = Del ingls Relational Data Base Manager System que signica, Sistema Gestor de Bases de
Datos Relacionales.

Dependencia Multivaluada = dependencia multivalor

Evitar la redundancia de los datos.

Disminuir problemas de actualizacin de los datos
en las tablas.

1FN = Signica, Primera Forma Normal o 1NF del

ingls First Normal Form.

Proteger la integridad de los datos.

Los trminos Relacin, Tupla y Atributo derivan del
En el modelo relacional es frecuente llamar tabla a una lgebra y clculo relacional, que constituyen la fuente terelacin, aunque para que una tabla sea considerada como rica del modelo de base de datos relacional.
una relacin tiene que cumplir con algunas restricciones: Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar.
Cada tabla debe tener su nombre nico.
Una instancia de una tabla puede verse entonces como
un subconjunto del producto cartesiano entre los domi No puede haber dos las iguales. No se permiten los nios de los atributos. Sin embargo, suele haber algunas
duplicados.
diferencias con la analoga matemtica, ya que algunos
Todos los datos en una columna deben ser del mismo RDBMS permiten las duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemticamente
tipo.
como un elemento del producto cartesiano entre los dominios.

Terminologa Equivalente
2 Dependencias
2.1 Dependencia funcional

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde

Cdigo es la Clave Primaria.
B es funcionalmente dependiente de A.

Relacin = tabla

Una dependencia funcional es una conexin entre uno o

ms atributos. Por ejemplo si se conoce el valor de DNI
tiene una conexin con Apellido o Nombre .

Registro = registro, o tupla

Atributo = columna o campo
Clave = llave o cdigo de identicacin

Las dependencias funcionales del sistema se escriben utilizando una echa, de la siguiente manera:

Clave Candidata = superclave mnima

FechaDeNacimiento Edad

Clave Primaria = clave candidata elegida

De la normalizacin (lgica) a la implementacin (fsica

o real) puede ser sugerible tener estas dependencias funcionales para lograr la eciencia en las tablas.

Clave Externa = clave ajena o clave fornea

1

2.2

3 CLAVES

Propiedades de la dependencia funcio- 2.3 Propiedades deducidas

nal
2.3.1 Unin

Existen tres axiomas de Armstrong:

x y y x z entonces x yz
2.2.1

Dependencia funcional reexiva

Si y est incluido en x entonces x y

2.3.2 Pseudo-Transitiva

A partir de cualquier atributo o conjunto de atributos x y y wy z entonces wx z

siempre puede deducirse l mismo. Si la direccin o el
nombre de una persona estn incluidos en el DNI, entonces con el DNI podemos determinar la direccin o su 2.3.3 Descomposicin
nombre.
x y y z est incluido en y entonces x z
2.2.2

Dependencia funcional Aumentativa

x y entonces xz yz

3 Claves

DNI nombre
Una clave primaria es el conjunto mnimo de columnas
que identica unvocamente a cada la. La clave primaria
Si con el DNI se determina el nombre de una persona, enes un identicador que va a ser siempre nico para cada
tonces con el DNI ms la direccin tambin se determina
la. Se acostumbra a poner la clave primaria como la priel nombre y su direccin.
mera columna de la tabla pero es ms una conveniencia
que una obligacin. Muchas veces la clave primaria es numrica auto-incrementada, es decir, generada mediante
2.2.3 Dependencia funcional transitiva
una secuencia numrica incrementada automticamente
cada vez que se inserta una la.
DNI,direccin nombre,direccin

En una tabla puede que tengamos ms de una columna

que puede ser clave primaria por s misma. En ese caso se
puede escoger una para ser la clave primaria y las dems
claves sern claves candidatas.
Dependencia funcional transitiva.

Una clave ajena (foreign key o clave fornea) es aquella

columna que existiendo como dependiente en una tabla,
Sean X, Y, Z tres atributos (o grupos de atributos) de la es a su vez clave primaria en otra tabla.
misma entidad. Si Y depende funcionalmente de X y Z
de Y, pero X no depende funcionalmente de Y, se dice Una clave alternativa es aquella clave candidata que no
entonces que Z depende transitivamente de X. Simbli- ha sido seleccionada como clave primaria, pero que tambin puede identicar de forma nica a una la dentro de
camente sera:
una tabla. Ejemplo: Si en una tabla clientes denimos el
X Y Z entonces X Z
nmero de documento (id_cliente) como clave primaria,
el nmero de seguro social de ese cliente podra ser una
FechaDeNacimiento Edad
clave alternativa. En este caso no se us como clave priEdad Conducir
maria porque es posible que no se conozca ese dato en
FechaDeNacimiento Edad Conducir
todos los clientes.
Entonces tenemos que FechaDeNacimiento determina a
Edad y la Edad determina a Conducir, indirectamente podemos saber a travs de FechaDeNacimiento a Conducir
(En muchos pases, una persona necesita ser mayor de
cierta edad para poder conducir un automvil, por eso se
utiliza este ejemplo).

Una clave compuesta es una clave que est compuesta

por ms de una columna.

La visualizacin de todas las posibles claves candidatas

en una tabla ayudan a su optimizacin. Por ejemplo, en
una tabla PERSONA podemos identicar como claves su
DNI, o el conjunto de su nombre, apellidos, fecha de naC ser un dato simple (dato no primario), B, ser un cimiento y direccin. Podemos usar cualquiera de las dos
otro dato simple (dato no primario), A, es la llave prima- opciones o incluso todas a la vez como clave primaria,
ria (PK). Decimos que C depender de B y B depender pero es mejor en la mayora de sistemas la eleccin del
funcionalmente de A.
menor nmero de columnas como clave primaria.

4.3

Tercera Forma Normal (3FN)

Formas normales

principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben
Las formas normales son aplicadas a las tablas de una base depender nicamente de la clave principal).
de datos. Decir que una base de datos est en la forma En otras palabras podramos decir que la segunda forma
normal N es decir que todas sus tablas estn en la forma normal est basada en el concepto de dependencia comnormal N.
pletamente funcional. Una dependencia funcional x y
es completamente funcional si al eliminar los atributos
A de X signica que la dependencia no es mantenida,
esto es que A X, X {A} Y . Una dependencia funcional x y es una dependencia parcial si
hay algunos atributos A X que pueden ser eliminados de X y la dependencia todava se mantiene, esto es
A X, X {A} Y .
Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y
el ID de un proyecto sabemos cuntas horas de
trabajo por semana trabaja un empleado en dicho
proyecto) es completamente funcional dado que ni
DNI HORAS_TRABAJO ni ID_PROYECTO
HORAS_TRABAJO mantienen la dependencia.
Sin embargo {DNI, ID_PROYECTO} NOMDiagrama de inclusin de todas las formas normales.
BRE_EMPLEADO es parcialmente dependiente dado
que DNI NOMBRE_EMPLEADO mantiene la
En general, las primeras tres formas normales son su- dependencia.
cientes para cubrir las necesidades de la mayora de las
bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.[1]
4.3 Tercera Forma Normal (3FN)

4.1

Primera Forma Normal (1FN)

Una tabla est en Primera Forma Normal si:

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos
que no son clave.

Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de relacin R es una
Todos los atributos son atmicos. Un atributo es at- dependencia transitiva si hay un conjunto de atributos Z
mico si los elementos del dominio son simples e in- que no es un subconjunto de alguna clave de R, donde se
divisibles.
mantiene X->Z y Z->Y.
La tabla contiene una clave primaria nica.
La clave primaria no contiene atributos nulos.
No debe existir variacin en el nmero de columnas.
Los Campos no clave deben identicarse por la clave
(Dependencia Funcional)
Debe Existir una independencia del orden tanto de
las las como de las columnas, es decir, si los datos
cambian de orden no deben cambiar sus signicados

Por ejemplo, la dependencia SSN->DMGRSSN es una

dependencia transitiva en EMP_DEPT de la siguiente gura. Decimos que la dependencia de DMGRSSN
el atributo clave SSN es transitiva va DNUMBER
porque las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es
un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN
sobre DNUMBER es indeseable en EMP_DEPT dado
que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relacin R est en 3 Forma Normal Elmasri-Navathe,[2] si para toda dependencia
Esta forma normal elimina los valores repetidos dentro de funcional X A , se cumple al menos una de las siuna Base de Datos.
guientes condiciones:

4.2

Segunda Forma Normal (2FN)

1. X es superllave o clave.

2. A es atributo primo de R ; esto es, si es miembro de

alguna clave en R .
Dependencia Funcional. Una relacin est en 2FN si
est en 1FN y si los atributos que no forman parte de
ninguna clave dependen de forma completa de la clave Adems el esquema debe cumplir necesariamente, con las

condiciones de segunda forma normal.

4.4

REGLAS DE CODD

5.1 Regla No. 1 - La Regla de la informacin

Forma normal de Boyce-Codd (FNBC) Toda la informacin en un RDBMS est explcitamente re-

La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deber registrarse de forma anillada ante la presencia de un intervalo seguido de una formalizacin perpetua, es decir las variantes creadas, en una tabla no se
llegaran a mostrar, si las ya planicadas, dejan de existir.
Formalmente, un esquema de relacin R est en FNBC,
si y slo si, para toda dependencia funcional X A
vlida en R , se cumple que

presentada de una sola manera por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de tablas,
nombres de vistas, nombres de columnas, y los datos de
las columnas deben estar almacenados en tablas dentro de
las bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de Datos. Esto signica
que todo tiene que estar almacenado en las tablas.

Toda la informacin en una base de datos relacional se

representa explcitamente en el nivel lgico exactamente
de una manera: con valores en tablas. Por tanto los meta1. X es superllave o clave.
datos (diccionario, catlogo) se representan exactamente
igual que los datos de usuario. Y puede usarse el mismo
De esta forma, todo esquema R que cumple FNBC, est lenguaje (ej. SQL) para acceder a los datos y a los metaadems en 3FN; sin embargo, no todo esquema R que datos (regla 4).
cumple con 3FN, est en FNBC.

4.5

Cuarta Forma Normal (4FN)

5.2 Regla No. 2 - La regla del acceso garantizado

Una tabla se encuentra en 4FN si, y slo si, para cada Cada tem de datos debe ser lgicamente accesible al ejeuna de sus dependencias mltiples no funcionales X->- cutar una bsqueda que combine el nombre de la tabla, su
>Y, siendo X una super-clave que, X es o una clave can- clave primaria, y el nombre de la columna.
didata o un conjunto de claves primarias.
Esto signica que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna
requerida, deber encontrarse uno y solamente un valor.
4.6 Quinta Forma Normal (5FN)
Por esta razn la denicin de claves primarias para todas
las tablas es prcticamente obligatoria.
Una tabla se encuentra en 5FN si:
La tabla est en 4FN
No existen relaciones de dependencias de reunin
(join) no triviales que no se generen desde las claves. Una tabla que se encuentra en la 4FN se dice
que est en la 5FN si, y slo si, cada relacin de
dependencia de reunin (join) se encuentra denida
por claves candidatas. Por lo que si se aplicara una
consulta entre al menos tres relaciones independientes entre s dentro de la 4FN y se obtuvieran tuplas
espurias, entonces no estara dentro de la 5FN.

5.3 Regla No. 3 - Tratamiento sistemtico

de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de valores nulos
Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos
en el lugar de columnas cuyos valores sean desconocidos.

Se reconoce la necesidad de la existencia del valor nulo,

el cual podra servir para representar, o bien, una informacin desconocida (ejemplo, no se sabe la direccin de
un empleado), o bien una informacin que no aplica(a un
empleado soltero no se le puede asignar un nombre de
5 Reglas de Codd
esposa). As mismo, consideremos el caso de un alumno
Codd se percat de que existan bases de datos en el mer- que obtiene 0 puntos en una prueba y el de un alumno que
cado las cuales decan ser relacionales, pero lo nico que no present la prueba.
hacan era guardar la informacin en las tablas, sin es- Hay problemas para soportar los valores nulos en las
tar estas tablas literalmente normalizadas; entonces ste operaciones relacionales, especialmente en las operaciopublic 12 reglas que un verdadero sistema relacional de- nes lgicas, para lo cual se considera una lgica trivaluabera tener, en la prctica algunas de ellas son difciles de da, con tres (no dos) valores de verdad: Verdadero, Falso
realizar. Un sistema podr considerarse ms relacional y null. Se crean tablas de verdad para las operaciones lcuanto ms siga estas reglas.
gicas:

5.8

Regla No. 8 - La regla de independencia fsica

null AND null = null

Verdadero AND null = null
Falso AND null = Falso
Verdadero OR null = Verdadero, etc.

5.4

5.8 Regla No. 8 - La regla de independencia fsica

El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en
los datos almacenados, o sean cambiados los mtodos de
acceso a los datos.

Regla No. 4 - La regla de la descripcin

El comportamiento de los programas de aplicacin y de
de la base de datos

la actividad de usuarios va terminales debera ser predeLa descripcin de la base de datos es almacenada de la cible basados en la denicin lgica de la base de datos, y
misma manera que los datos ordinarios, esto es, en tablas y ste comportamiento debera permanecer inalterado, incolumnas, y debe ser accesible a los usuarios autorizados. dependientemente de los cambios en la denicin fsica
de sta.
La informacin de tablas, vistas, permisos de acceso de
usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas de- 5.9 Regla No. 9 - La regla de independenben ser accesibles igual que todas las tablas, a travs de
cia lgica
sentencias de SQL (o similar).

5.5

Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas
Regla No. 5 - La regla del sub-lenguaje cuando quiera que se hagan cambios (segn los permisos
asignados) en las tablas de la base de datos.
Integral

Debe haber al menos un lenguaje que sea integral para soportar la denicin de datos, manipulacin de datos, denicin de vistas, restricciones de integridad, y control de
autorizaciones y transacciones.

La independencia lgica de los datos especica que los

programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o
modicar estos programas de aplicacin.

Esto signica que debe haber por lo menos un lenguaje

con una sintaxis bien denida que pueda ser usado para
5.10
administrar completamente la base de datos.

5.6

Regla No. 10 - La regla de la independencia de la integridad

Regla No. 6 - La regla de la actualiza- Todas las restricciones de integridad deben ser denibles
en los datos, y almacenables en el catlogo, no en el procin de vistas
grama de aplicacin.

Todas las vistas que son tericamente actualizables, deben

ser actualizables por el sistema mismo.
5.10.1 Las reglas de integridad
La mayora de las RDBMS permiten actualizar vistas
1. Ningn componente de una clave primaria puede tesimples, pero deshabilitan los intentos de actualizar vistas
ner valores en blanco o nulos (sta es la norma bsica
complejas.
de integridad).

5.7

Regla No. 7 - La regla de insertar y actualizar

2. Para cada valor de clave fornea deber existir un

valor de clave primaria concordante. La combinacin de estas reglas aseguran que haya integridad
referencial.

La capacidad de manejar una base de datos con operandos simples se aplica no slo para la recuperacin o consulta de datos, sino tambin para la insercin, actualiza- 5.11
cin y borrado de datos.
Esto signica que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE
e INSERT en SQL) deben estar disponibles y operables,
independientemente del tipo de relaciones y restricciones
que haya entre las tablas o no.

Regla No. 11 - La regla de la distribucin

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en
distintos lugares sin que esto afecte o altere a los programas
de aplicacin.

El soporte para bases de datos distribuidas signica que

una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas y distintos
sistemas operativos y que est conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en una sola mquina.

5.12 Regla No. 12 - Regla de la nosubversin

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la
integridad de las reglas y restricciones expresadas en un
lenguaje de alto nivel (como SQL).
Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que
hace posible la subversin (violacin) de las restricciones
de integridad. Esto no debe ser permitido.

Vase tambin
1NF - 2NF - 3NF - BCNF - 4NF - 5NF - DKNF 6NF - Denormalizacin
Edgar Frank Codd
Base de datos

Referencias

[1] A Relational Model of Data for Large Shared Data Banks

Communications of the ACM, Vol. 13, No. 6, June 1970,
pp. 377-387
[2] Fundamentals of DATABASE SYSTEMS Addison-Wesley;,
ISBN-10: 0321122267, ISBN-13: 978-0321122261,

E.F.Codd (junio de 1970). A Relational Model of

Data for Large Shared Databanks. Communications of the ACM.
C.J.Date (1994). An Introduction to Database Systems. Addison-Wesley.

REFERENCIAS

Origen del texto y las imgenes, colaboradores y licencias

8.1

Texto

Normalizacin de bases de datos Fuente: https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos?oldid=94741029

Colaboradores: Dovidena, Angus, Rosarino, Ecelan, Dodo, Jynus, Truor, Rsg, Tostadora, Elwikipedista, Valyag, Xatufan, Almorca, FAR,
Airunp, Taichi, Edtruji, Magister Mathematicae, Goofys, RobotQuistnix, Superzerocool, Akhram, Pabloab, Yrbot, Maleiva, Mortadelo2005, Barct, Gaeddal, GermanX, Deniel77, Gaijin, Eskimbot, Baneld, Kepler Oort, Er Komandante, Filipo, Mencey, Kuanto, Paintman,
Jago84, Juandiegocano, BOTpolicia, CEM-bot, Laura Fiorucci, Alexav8, Pacovila, Antur, Hernan Beati, Eluseche, Tyrannosaurusreex,
PabloCastellano, Yeza, RoyFocker, Max Changmin, Isha, Egaida, Vitorres, Gusgus, Verajm, Rayleon, Jugones55, Miguelo on the road,
Mansoncc, TXiKiBoT, Millars, Humberto, Netito777, Merlyn333, Nioger, Bedwyr, Changa, Plux, BL, Snakeyes, Technopat, C'est moi,
Queninosta, Gatra~eswiki, Libertad y Saber, Matdrodes, DJ Nietzsche, BlackBeast, Lucien leGrey, U.gonzalez, Fama.arciniega, Muro Bot,
Edmenb, Jkarretero, SieBot, Mushii, RafaRamirez, PaintBot, Loveless, BOTarate, Manw, Tirithel, Montehermoso-spain, Javierito92, Cumanacr, Alagoro, Leonpolanco, Pan con queso, Botito777, Walter closser, Darkicebot, VanBot, Rrupo, UA31, AVBOT, David0811, MarcoAurelio, Diegusjaimes, Arjuno3, Saloca, Andvarp, Andreasmperu, Luckas-bot, Spirit-Black-Wikipedista, Ptbotgourou, Elielsardanons,
Thiamath, ArthurBot, Algerion, SuperBraulio13, Acardh, Manuelt15, Xqbot, Jkbw, Rubinbot, Botarel, D'ohBot, Hprmedina, TobeBot,
Diego diaz espinoza, Fgtez, PatruBOT, CVBOT, Angelito7, Humbefa, Foundling, ManuelMontiel, EmausBot, Savh, Sergio Andres Segovia, Grillitus, Jhtan, Emiduronte, Jcaraballo, ChuispastonBot, MadriCR, Felipecanol, Waka Waka, WikitanvirBot, SHeLoo, Rezabot,
TeleMania, MetroBot, Carliitaeliza, Elvisor, MahdiBot, Addbot, Laverde0, Jarould, Ks-M9, Pequeo columba y Annimos: 607

8.2

Imgenes

Archivo:DependenciaFunional.png Fuente: https://upload.wikimedia.org/wikipedia/commons/2/25/DependenciaFunional.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Edtruji
Archivo:DependenciaFunional2.png Fuente: https://upload.wikimedia.org/wikipedia/commons/3/36/DependenciaFunional2.png Licencia: CC-BY-SA-3.0 Colaboradores: Trabajo propio Artista original: Edtruji
Archivo:FormasNormalesBD.png Fuente: https://upload.wikimedia.org/wikipedia/commons/5/59/FormasNormalesBD.png Licencia:
CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Syscall
Archivo:TablaRelacional2.png Fuente: https://upload.wikimedia.org/wikipedia/commons/a/a1/TablaRelacional2.png Licencia: CC BY
3.0 Colaboradores: Trabajo propio Artista original: Edgardo Trujillo

8.3

Licencia del contenido

Creative Commons Attribution-Share Alike 3.0