Normalizacin de bases de datos

Clave Ajena (o fornea) = clave externa o clave fornea

El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas
tras el paso del modelo entidad-relacin al modelo relacional.

Clave Alternativa = clave secundaria

Dependencia Multivaluada = dependencia multivalor

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.

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.

En el modelo relacional es frecuente llamar tabla a una Los trminos Relacin, Tupla y Atributo derivan del
relacin, aunque para que una tabla sea considerada como lgebra y clculo relacional, que constituyen la fuente teuna relacin tiene que cumplir con algunas restricciones: rica del modelo de base de datos relacional.
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
No puede haber dos las iguales. No se permiten los un subconjunto del producto cartesiano entre los domiduplicados.
nios de los atributos. Sin embargo, suele haber algunas
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. Fitipo.
nalmente, una tupla puede razonarse matemticamente
como un elemento del producto cartesiano entre los dominios.

Terminologa relacional equivalente

2 Dependencia
2.1 Dependencia funcional

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

Cdigo es la Clave Primaria.

B es funcionalmente dependiente de A.

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 .

Relacin = tabla o archivo

Registro = registro, la , rengln o tupla
Atributo = columna o campo

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

Clave = llave o cdigo de identicacin

FechaDeNacimiento Edad

Clave Candidata = superclave mnima

De la normalizacin (lgica) a la implementacin (fsica

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

Clave Primaria = clave candidata elegida

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 aquella columna (o conjunto de
columnas) que identica nicamente a una la. La clave
Si con el DNI se determina el nombre de una persona, enprimaria es un identicador que va a ser siempre nico
tonces con el DNI ms la direccin tambin se determina
para cada la. Se acostumbra a poner la clave primaria
el nombre y su direccin.
como la primera columna de la tabla pero es ms una
conveniencia que una obligacin. Muchas veces la clave
primaria es numrica auto-incrementada, es decir, gene2.2.3 Dependencia funcional transitiva
rada mediante 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 otro cimiento y direccin. Podemos usar cualquiera de las dos
dato simple (dato no primario), A, es la llave primaria opciones o incluso todas a la vez como clave primaria,
(PK). Decimos que C dependera de B y B dependera fun- pero es mejor en la mayora de sistemas la eleccin del
cionalmente de A.
menor nmero de columnas como clave primaria.

4.2

Segunda Forma Normal (2FN)

Formas normales

Las formas normales son aplicadas a las tablas de una base

de datos. Decir que una base de datos est en la forma
normal N es decir que todas sus tablas estn en la forma
normal N.

4.2 Segunda Forma Normal (2FN)

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
principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben
depender nicamente de la clave principal).
En otras palabras podramos decir que la segunda forma
normal est basada en el concepto de dependencia completamente 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
Diagrama de inclusin de todas las formas normales.
trabajo por semana trabaja un empleado en dicho
proyecto) es completamente funcional dado que ni
En general, las primeras tres formas normales son suDNI HORAS_TRABAJO ni ID_PROYECTO
cientes para cubrir las necesidades de la mayora de las
HORAS_TRABAJO mantienen la dependencia.
bases de datos. El creador de estas 3 primeras formas norSin embargo {DNI, ID_PROYECTO} NOMmales (o reglas) fue Edgar F. Codd.[1]
BRE_EMPLEADO es parcialmente dependiente dado
que DNI NOMBRE_EMPLEADO mantiene la
dependencia.

4.1

Primera Forma Normal (1FN)

Una tabla est en Primera Forma Normal si:

4.3 Tercera Forma Normal (3FN)

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, La tabla se encuentra en 3FN si es 2FN y si no existe ninmnimos.
guna dependencia funcional transitiva entre los atributos
que no son clave.
La tabla contiene una clave primaria nica.
Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de relacin R es una
La clave primaria no contiene atributos nulos.
dependencia transitiva si hay un conjunto de atributos Z
No debe existir variacin en el nmero de columnas. que no es un subconjunto de alguna clave de R, donde se
mantiene X->Z y Z->Y.
Los Campos no clave deben identicarse por la clave
Por ejemplo, la dependencia SSN->DMGRSSN es una
(Dependencia Funcional)
dependencia transitiva en EMP_DEPT de la siguien Debe Existir una independencia del orden tanto de te gura. Decimos que la dependencia de DMGRSSN
las las como de las columnas, es decir, si los datos el atributo clave SSN es transitiva va DNUMBER
cambian de orden no deben cambiar sus signicados porque las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es
Una tabla no puede tener mltiples valores en cada un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN
columna.
sobre DNUMBER es indeseable en EMP_DEPT dado
Los datos son atmicos (a cada valor de X le perte- que DNUMBER no es una clave de EMP_DEPT.
nece un valor de Y y viceversa).
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:

REGLAS DE CODD

5.1 Regla No. 1 - La Regla de la informacin

2. A es atributo primo de R ; esto es, si es miembro de
1. X es superllave o clave.
alguna clave en R .

Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla.

Adems el esquema debe cumplir necesariamente, con las

Cualquier cosa que no exista en una tabla no existe del tocondiciones de segunda forma normal.
do. Toda la informacin, incluyendo nombres de tablas,
nombres de vistas, nombres de columnas, y los datos de
4.4 Forma normal de Boyce-Codd (FNBC) las columnas deben estar almacenados en tablas dentro de
las bases de datos. Las tablas que contienen tal informaLa tabla se encuentra en FNBC si cada determinante, atri- cin constituyen el Diccionario de Datos. Esto signica
buto que determina completamente a otro, es clave can- que todo tiene que estar almacenado en las tablas.
didata. Deber registrarse de forma anillada ante la presencia de un intervalo seguido de una formalizacin per- Toda la informacin en una base de datos relacional se
petua, es decir las variantes creadas, en una tabla no se representa explcitamente en el nivel lgico exactamente
llegaran a mostrar, si las ya planicadas, dejan de existir. de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) se representan exactamente
Formalmente, un esquema de relacin R est en FNBC, igual que los datos de usuario. Y puede usarse el mismo
si y slo si, para toda dependencia funcional X A lenguaje (ej. SQL) para acceder a los datos y a los metavlida en R , se cumple que
datos (regla 4)
1. X es superllave o clave.
De esta forma, todo esquema R que cumple FNBC, est
adems en 3FN; sin embargo, no todo esquema R que
cumple con 3FN, est en FNBC.

4.5

Cuarta Forma Normal (4FN)

Una tabla se encuentra en 4FN si, y slo si, para cada

una de sus dependencias mltiples no funcionales X->>Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

4.6

Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si:

La tabla est en 4FN

5.2 Regla No. 2 - La regla del acceso garantizado

Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la tabla, su
clave primaria, y el nombre de la columna.
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.
Por esta razn la denicin de claves primarias para todas
las tablas es prcticamente obligatoria.

5.3 Regla No. 3 - Tratamiento sistemtico

de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de valores nulos

No existen relaciones de dependencias no triviales

que no siguen los criterios de las claves. Una tabla Un RDBMS (Sistema Gestor de Bases de Datos Relacioque se encuentra en la 4FN se dice que est en la nales) debe ser capaz de soportar el uso de valores nulos
5FN si, y slo si, cada relacin de dependencia se en el lugar de columnas cuyos valores sean desconocidos.
encuentra denida por claves candidatas.

Reglas de Codd

Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que
hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste
public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de
realizar. Un sistema podr considerarse ms relacional
cuanto ms siga estas reglas.

5.4 Regla No. 4 - La regla de la descripcin

de la base de datos
La descripcin de la base de datos es almacenada de la
misma manera que los datos ordinarios, esto es, en tablas y
columnas, y debe ser accesible a los usuarios autorizados.
La informacin de tablas, vistas, permisos de acceso de
usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de
sentencias de SQL (o similar).

5.10

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

5.5

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
administrar completamente la base de datos.
5.10

5.6

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

Regla No. 6 - La regla de la actualizaTodas las restricciones de integridad deben ser denibles
cin de vistas
en los datos, y almacenables en el catlogo, no en el pro-

Todas las vistas que son tericamente actualizables, deben

ser actualizables por el sistema mismo.

grama de aplicacin.

La mayora de las RDBMS permiten actualizar vistas 5.10.1 Las reglas de integridad
simples, pero deshabilitan los intentos de actualizar vistas
complejas.
1. Ningn componente de una clave primaria puede tener valores en blanco o nulos (sta es la norma bsica
de integridad).
5.7 Regla No. 7 - La regla de insertar y ac-

tualizar
La capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o consulta
de datos, sino tambin para la insercin, actualizacin y
borrado de datos.

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.

Esto signica que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE 5.11 Regla No. 11 - La regla de la distribucin
e INSERT en SQL) deben estar disponibles y operables,
independientemente del tipo de relaciones y restricciones
El sistema debe poseer un lenguaje de datos que pueda soque haya entre las tablas o no.
portar que la base de datos est distribuida fsicamente en
distintos lugares sin que esto afecte o altere a los programas
5.8 Regla No. 8 - La regla de independen- de aplicacin.

cia 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.

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.

El comportamiento de los programas de aplicacin y de

la actividad de usuarios va terminales debera ser prede- 5.12 Regla No. 12 - Regla de la nocible basados en la denicin lgica de la base de datos, y
subversin
ste comportamiento debera permanecer inalterado, independientemente de los cambios en la denicin fsica
Si el sistema tiene lenguajes de bajo nivel, estos lenguade sta.
jes de ninguna manera pueden ser usados para violar la
integridad de las reglas y restricciones expresadas en un
5.9 Regla No. 9 - La regla de independen- lenguaje de alto nivel (como SQL).

cia lgica

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que
Los programas de aplicacin y las actividades de acce- hace posible la subversin (violacin) de las restricciones
so por terminal deben permanecer lgicamente inalteradas 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

Text and image sources, contributors, and licenses

8.1

Text

Normalizacin de bases de datos Fuente: http://es.wikipedia.org/wiki/Normalizaci%C3%B3n%20de%20bases%20de%20datos?oldid=

77654796 Colaboradores: Dovidena, Angus, Rosarino, Ecelan, Dodo, Jynus, Truor, Rsg, Tostadora, Elwikipedista, Valyag, Xatufan, Almorca, FAR, Airunp, Taichi, Edtruji, Magister Mathematicae, Goofys, RobotQuistnix, Akhram, Pabloab, Yrbot, Maleiva, Mortadelo2005,
Barct, Gaeddal, GermanX, Deniel77, Eskimbot, Baneld, Milestones, Er Komandante, Filipo, Mencey, Kuanto, Paintman, Jago84, Juandiegocano, BOTpolicia, CEM-bot, Laura Fiorucci, Alexav8, Pacovila, Antur, Hernan Beati, Eluseche, Tyrannosaurusreex, PabloCastellano,
Yeza, RoyFocker, 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, 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, SuperBraulio13,
Acardh, Manuelt15, Xqbot, Jkbw, Rubinbot, Botarel, D'ohBot, Hprmedina, TobeBot, Diego diaz espinoza, Fgtez, CVBOT, Angelito7,
Humbefa, ManuelMontiel, EmausBot, Savh, Grillitus, Jhtan, Emiduronte, Jcaraballo, ChuispastonBot, MadriCR, Felipecanol, WikitanvirBot, SHeLoo, Rezabot, TeleMania, Carliitaeliza, Elvisor, MahdiBot, Addbot, Laverde0 y Annimos: 551

8.2

Images

Archivo:DependenciaFunional.png Fuente: http://upload.wikimedia.org/wikipedia/commons/2/25/DependenciaFunional.png Licencia:

CC-BY-SA-3.0-2.5-2.0-1.0 Colaboradores: Trabajo propio Artista original: Edtruji
Archivo:DependenciaFunional2.png Fuente: http://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: http://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: http://upload.wikimedia.org/wikipedia/commons/a/a1/TablaRelacional2.png Licencia: CC-BY3.0 Colaboradores: Trabajo propio Artista original: Edgardo Trujillo

8.3

Content license

Creative Commons Attribution-Share Alike 3.0