Contenido

Normalizacin de bases de datos .................................................................................................. 2

Terminologa relacional equivalente .......................................................................................... 2
Dependencia ................................................................................................................................. 3
Dependencia funcional ......................................................................................................... 3
Propiedades de la Dependencia funcional ...................................................................... 3
Propiedades deducidas ........................................................................................................ 4
Claves............................................................................................................................................. 5
Formas Normales ......................................................................................................................... 5
Primera Forma Normal (1FN) .............................................................................................. 6
Segunda Forma Normal (2FN) ............................................................................................ 6
Tercera Forma Normal (3FN) ............................................................................................... 7
Forma normal de Boyce-Codd (FNBC) ............................................................................. 7
Cuarta Forma Normal (4FN) ................................................................................................. 8
Quinta Forma Normal (5FN) ................................................................................................. 8
Reglas de Codd ............................................................................................................................ 8
Regla No. 1 - La Regla de la informacin ......................................................................... 8
Regla No. 2 - La regla del acceso garantizado ............................................................... 9
Regla No. 3 - Tratamiento sistemtico de los valores nulos ...................................... 9
Regla No. 4 - La regla de la descripcin de la base de datos..................................... 9
Regla No. 5 - La regla del sub-lenguaje Integral ............................................................ 9
Regla No. 6 - La regla de la actualizacin de vistas ...................................................... 9
Regla No. 7 - La regla de insertar y actualizar .............................................................. 10
Regla No. 8 - La regla de independencia fsica ............................................................ 10
Regla No. 9 - La regla de independencia lgica ........................................................... 10
Regla No. 10 - La regla de la independencia de la integridad .................................. 10
Regla No. 11 - La regla de la distribucin ...................................................................... 10
Regla No. 12 - Regla de la no-subversin...................................................................... 11
12 reglas de Codd .......................................................................................................................... 12
Reglas .......................................................................................................................................... 12

Normalizacin de bases de datos

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.
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea
considerada como una relacin tiene que cumplir con algunas restricciones:

Cada tabla debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

Terminologa relacional equivalente

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria.

Relacin = tabla o archivo

Registro = registro, fila , rengln o tupla

Atributo = columna o campo

Clave = llave o cdigo de identificacin

Clave Candidata = superclave mnima

Clave Primaria = clave candidata elegida

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

Clave Alternativa = clave secundaria

Dependencia Multivaluada = dependencia multivalor

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

1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional, que constituyen la
fuente terica 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. Una instancia de una tabla puede verse entonces como un subconjunto del producto
cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la
analoga matemtica, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente,
una tupla puede razonarse matemticamente como un elemento del producto cartesiano entre los
dominios.

Dependencia
Dependencia funcional

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 .
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento

Edad

De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas
dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstrong:

Dependencia funcional Reflexiva

Si "y" est incluido en "x" entonces x

A partir de cualquier atributo o conjunto de atributos 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 nombre.

Dependencia funcional Aumentativa

entonces
DNI

nombre

DNI,direccin

nombre,direccin

Si con el DNI se determina el nombre de una persona, entonces con el DNI ms la direccin tambin se
determina el nombre y su direccin.

Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente

de X y Z de Y,

pero X no

depende

funcionalmente

de Y,

se

dice

entonces

que Z depende

transitivamente de X. Simblicamente sera:

X

Z entonces X

FechaDeNacimiento
Edad

Edad

Conducir

FechaDeNacimiento
Entonces

tenemos

Edad

Conducir

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).
"C sera un dato simple (dato no primario), B,sera un otro dato simple (dato no primario), A, es la llave
primaria (PK). Decimos que C dependera de B y B dependera funcionalmente de A."

Propiedades deducidas
Unin
4

entonces

Pseudo-transitiva
y

entonces

Descomposicin
y

est incluido en

entonces

Claves
Una clave primaria es aquella columna (o conjunto de columnas) que identifica nicamente a una fila.
La clave primaria es un identificador que va a ser siempre nico para cada fila. Se acostumbra a poner
la clave primaria 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, generada mediante una
secuencia numrica incrementada automticamente cada vez que se inserta una fila.
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.
Una clave ajena (foreign key o clave fornea) es aquella columna que existiendo como dependiente
en una tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria,
pero que tambin puede identificar de forma nica a una fila dentro de una tabla. Ejemplo: Si en una
tabla clientes definimos el nmero de documento (id_cliente) como clave primaria, el nmero de seguro
social de ese cliente podra ser una clave alternativa. En este caso no se us como clave primaria
porque es posible que no se conozca ese dato en todos los clientes.
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 identificar como claves su DNI, o el conjunto de su nombre,
apellidos, fecha de nacimiento y direccin. Podemos usar cualquiera de las dos opciones o incluso todas
a la vez como clave primaria, pero es mejor en la mayora de sistemas la eleccin del menor nmero de
columnas como clave primaria.

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.

Diagrama de inclusin de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora
de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar Alanis.1

Primera Forma Normal (1FN)

Artculo principal: Primera forma normal.

Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son
indivisibles, mnimos.

La tabla contiene una llave primaria nica.

La llave primaria no contiene atributos nulos.

No debe existir variacin en el nmero de columnas.

Los Campos no llave deben identificarse por la llave (Dependencia Funcional)

Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los
datos cambian de orden no deben cambiar sus significados

Una tabla no puede tener mltiples valores en cada columna.

Los datos son atmicos (a cada valor de X le pertenece un valor de Y y viceversa).

Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN)

Artculo principal: Segunda forma normal.

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

es completamente

funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es

que

. Una dependencia funcional

si hay algunos atributos

es una dependencia parcial

que pueden ser eliminados de X y la dependencia todava se

mantiene, esto es

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

HORAS_TRABAJO
ID_PROYECTO}
DNI

dado

que

mantienen

ni

DNI

la

NOMBRE_EMPLEADO

HORAS_TRABAJO

dependencia.
es

parcialmente

ni

Sin

ID_PROYECTO
embargo

dependiente

dado

{DNI,
que

NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)

Artculo principal: Tercera forma normal.

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 dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna
clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la
siguiente figura. 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 relacion
dependencia funcional
1.

es superllave o clave.

2.

es atributo primo de

est en 3 Forma Normal Elmasri-Navathe,2 si para toda

, se cumple al menos una de las siguientes condiciones:

; esto es, si es miembro de alguna clave en

Adems el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Forma normal de Boyce-Codd (FNBC)

Artculo principal: Forma normal de Boyce-Codd.

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
planificadas, dejan de existir.
Formalmente, un esquema de relacin
funcional
1.

vlida en

, se cumple que

es superllave o clave.

De esta forma, todo esquema

esquema

est en FNBC, si y slo si, para toda dependencia

que cumple FNBC, est adems en 3FN; sin embargo, no todo

que cumple con 3FN, est en FNBC.

Cuarta Forma Normal (4FN)

Artculo principal: Cuarta forma normal.

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.

Quinta Forma Normal (5FN)

Artculo principal: Quinta forma normal.

Una tabla se encuentra en 5FN si:

La tabla est en 4FN

No existen relaciones de dependencias no triviales que no siguen los criterios de 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 se encuentra definida por las 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.

Regla No. 1 - La Regla de la informacin

Toda la informacin en un RDBMS est explcitamente representada 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 significa 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 metadatos (diccionario, catlogo) se
representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL)
para acceder a los datos y a los metadatos (regla 4)

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 significa 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 definicin de claves
primarias para todas las tablas es prcticamente obligatoria.

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.

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

Regla No. 5 - La regla del sub-lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de
datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones.
Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser
usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualizacin de vistas

Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.

La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de
actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

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'.
Esto significa 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. 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.
El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera
ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera
permanecer inalterado, independientemente de los cambios en la definicin fsica de sta.

Regla No. 9 - La regla de independencia lgica

Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente
inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la
base de datos.
La independencia lgica de los datos especifica 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 modificar estos programas de aplicacin.

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

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo,
no en el programa de aplicacin.

Las reglas de integridad

1. Ningn componente de una clave primaria puede tener valores en blanco o nulos (sta es la
norma bsica de integridad).
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.

Regla No. 11 - La regla de la distribucin

10

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

Regla No. 12 - Regla de la no-subversin

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.

11

12 reglas de Codd
Las 12 reglas de Codd son un sistema de reglas propuestas por Edgar F. Codd, del modelo
relacional para las bases de datos, diseado para definir qu requiere un sistema de administracin de
base de datos.1
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 aunque en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse
"ms relacional" cuanto ms siga estas reglas.

Reglas

Regla 0: el sistema debe ser relacional, base de datos y administrador de sistema. Ese sistema
debe utilizar sus facilidades relacionales (exclusivamente) para manejar la base de datos.

Regla 1: la regla de la informacin, toda la informacin en la base de datos es representada

unidireccionalmente, por valores en posiciones de las columnas dentro de filas de 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.

Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles sin ambigedad.
Esta regla es esencialmente una nueva exposicin del requisito fundamental para las llaves
primarias. Dice que cada valor escalar individual en la base de datos debe ser lgicamente
direccionable especificando el nombre de la tabla, la columna que lo contiene y la llave primaria.

Regla 3: tratamiento sistemtico de valores nulos, el sistema de gestin de base de datos debe
permitir que haya campos nulos. Debe tener una representacin de la "informacin que falta y de la
informacin inaplicable" que es sistemtica, distinto de todos los valores regulares.

Regla 4: catlogo dinmico en lnea basado en el modelo relacional, el sistema debe soportar un
catlogo en lnea, el catlogo relacional debe ser accesible a los usuarios autorizados. Es decir, los
usuarios deben poder tener acceso a la estructura de la base de datos (catlogo).

Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe soportar por lo menos
un lenguaje relacional que:
1.

Tenga una sintaxis lineal.

2.

Puede ser utilizado de manera interactiva.

3.

Soporte operaciones de definicin de datos, operaciones de manipulacin de datos

(actualizacin as como la recuperacin), seguridad e integridad y operaciones
de administracin de transacciones.

12

Regla 6: regla de actualizacin, todas las vistas que son tericamente actualizables deben ser
actualizables por el sistema.

Regla 7: alto nivel de insercin, actualizacin, y cancelacin, el sistema debe soportar suministrar
datos en el mismo tiempo que se inserte, actualiza o est borrando. Esto significa que los datos se
pueden recuperar de una base de datos relacional en los sistemas construidos de datos de filas
mltiples y/o de tablas mltiples.

Regla 8: independencia fsica de los datos, los programas de aplicacin y actividades del terminal
permanecen inalterados a nivel lgico cuandoquiera que se realicen cambios en las
representaciones de almacenamiento o mtodos de acceso.

Regla 9: independencia lgica de los datos, los cambios al nivel lgico (tablas, columnas, filas, etc.)
no deben requerir un cambio a una solicitud basada en la estructura. La independencia de datos
lgica es ms difcil de lograr que la independencia fsica de datos.

Regla 10: independencia de la integridad, las limitaciones de la integridad se deben especificar por
separado de los programas de la aplicacin y se almacenan en la base de datos. Debe ser posible
cambiar esas limitaciones sin afectar innecesariamente las aplicaciones existentes.

Regla 11: independencia de la distribucin, la distribucin de las porciones de la base de datos a las
varias localizaciones debe ser invisible a los usuarios de la base de datos. Los usos existentes
deben continuar funcionando con xito:

1.

cuando una versin distribuida del SGBD se introdujo por primera vez

2.

cuando se distribuyen los datos existentes se redistribuyen en todo el sistema.

Regla 12: la regla de la no subversin, si el sistema proporciona una interfaz de bajo nivel de
registro, a parte de una interfaz relacional, que esa interfaz de bajo nivel no se pueda utilizar para
subvertir el sistema, por ejemplo: sin pasar por seguridad relacional o limitacin de integridad. Esto
es debido a que existen sistemas anteriormente no relacionales que aadieron una interfaz
relacional, pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.

13