Documente Academic
Documente Profesional
Documente Cultură
Implicaciones
Hay ocasiones en las que los diseadores de las BD confeccionan la BD para satisfacer
necesidades lgicas y funcionales de una aplicacin, por ejemplo almacenando los datos en un
formato que luego la aplicacin se encarga de transformar. Esto es bastante tpico cuando el
diseador es el programador de la aplicacin, y lo hace por comodidad o falta de conocimiento.
La moraleja es que una BD debe ser independiente de la aplicacin, es mejor as. Segn las reglas
de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (tpicamente
SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada
desde la aplicacin). Con esto conseguiremos que mediante el SQL no se puedan realizar
operaciones que hagan que la aplicacin no funcione (introduciendo datos en un formato
inesperado para la aplicacin, por ejemplo), y entre otras cosas, que si tenemos que realizar
informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que
parsear (desfrizar una sintaxis en el cdigo) ni realizar consultas sobre consultas.
1FN:
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas.
Afirma que el dominio de un atributo solo debe incluir valores atmicos (simples o indivisibles) y
que el valor de cualquier atributo en una tupla debe ser una valor simple del dominio de ese
atributo
Como por ejemplo tres nmeros de telfono, o dos direcciones e-mail. Lo tpico en estos casos es
separar los datos por comas, espacios u otro carcter y despus procesarlo mediante la aplicacin.
Para evitar esto hay que definir una nueva tabla que tendr el identificador de la tabla de la que
parte y el campo multivaluado, haciendo juntos de clave nica compuesta (se puede definir otra
incremental si se desea "recomendado", pero el conjunto de los otros dos campos tiene que ser
nico). Adems en esta tabla se puede agregar campos que ayuden a describir el tipo de registro.
No
se
permiten
grupos
repetidos
en
varias
columnas
Esto es una variante de lo anterior: separamos los campos de un mismo dominio en varias
columnas, haciendo un grupo difcilmente procesable a la hora de consultarlo. En el ejemplo
anterior sera tener el campo teleClien1, telClien2 y as. Es evidente que este fallo del diseo es
incluso peor que el anterior pues habr muchos campos nulos, y en caso de necesitar ms
tendramos que redimensionar la tabla con un nuevo campo (telClien3). Pero la solucin es
sencilla.
Ejemplo:
No
se
permiten
campos
nulos
Esta regla es algo discutible, pero tiene su lgica. Para empezar, si un campo va a tener valores
nulos, qu proporcin de registros tendrn ese campo con valor nulo? En mi opinin esta regla
nos ayuda a separar unas relaciones de otras, porque si una cantidad de registros tienen unos
atributos que otros no, no ser que pertenecen a otra clase? Por ejemplo, si en una tabla de
TBPRODUCTOS definimos los campos TallaProd, KilatesProd y potenciaProd se ve que los
productos tendrn clases diversas y entonces habr que crear una relacin para cada clase (ropas,
joya y elctricos, por ejemplo) construyendo lo que se llama una generalizacin.
Ejemplo:
2FN:
Como vemos en la tabla TBLINEASPEDIDO del ejemplo incorrecto, la nica clave candidata es
PK_TBLINEASPEDIDO + IDProducto, ya que en conjunto son nicas en la tabla (podramos tener
un IDLinea_pedido nico tambin, pero an as esos dos campos seguiran siendo una clave
candidata). El campo CantidadPed es dependiente de la clave candidata, pues el cliente ha pedido
de ese producto una cantidad determinada de artculos, pero el nombre en cambio es dependiente
slo del producto, no del cliente. Si dejaremos esa tabla como est, tendramos por una parte una
redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla
de productos, y adems podran darse inconsistencias de datos si cambiamos el nombre del
producto en un registro cul sera el nombre real del producto 1 si en varios registros tiene un
nombre distinto?
Conclusiones
2FN:
Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves
candidatas (compuestas), que identifican de manera nica el registro; comprobar que los campos
que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni
IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el
segundo
paso
puede
ayudar
preguntarse
lo
siguiente:
puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave
candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el anlisis esto requiere
un mnimo de agudeza, pues puede que casualmente el valor de un campo se repita para una
parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en
cantidades
de
5)
pero
sabemos
que
no
es
dependiente
de
ella.
Por ltimo, aclarar que hay ocasiones en las que el anlisis no tiene que ser tan cerrado, ya que a
veces las apariencias engaan. Un ejemplo de ello es una tabla de facturas que tiene el nombre,
direccin, NIF, y dems datos del cliente: a simple vista esos datos estn duplicados y dependen
del cliente y no de la factura, pero resulta que esos datos deben permanecer ah pues fisicalmente
debemos saber a qu datos se emiti una factura; esos datos son realmente dependientes de la
factura, no del cliente. Si no los incluyramos en la tabla de facturas, al modificar el registro del
cliente en la tabla de clientes no sabramos a qu datos fiscales se emiti la factura. As que hay
que tomar como referencia el estudio de factibilidad, necesidades de cliente y el minimundo, y no
solo
aplicar
normas.
3FN:
La relacin est en 2NF.
Una tabla est normalizada en esta forma si todas las columnas que no son llave son
funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas.
Una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen
de otras columnas que tampoco son llave.
Todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen
nicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta:
ningn campo que no sea parte de la clave candidata puede depender
de
otro
campo
que
no
sea
la
clave
candidata.
Por ejemplo:
pedido(pedido_id, fecha, cliente_id, cliente_nombre)
- satisface 1FN y 2FN con clave primaria pedido_id
- pero cliente_nombre cambia si cambia cliente_id
- As que debemos dividir la tabla en:
- pedido(pedido_id, fecha, cliente_id)
- cliente(cliente_id,cliente_nombre)
Otro
ejemplo:
Imagina que una tabla se encarga de registrar el primer servicio que ms carga los servidores cada
da. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha, PK_TBCARGADIARIA son la
clave candidata, pues identifican de manera nica los registros. Analizando vemos que el
IDServicio, que no es un campo primario, depende nicamente de la clave candidata, y que la
carga tambin. Pero resulta que el Nombre_servicio depende de esa clave candidata pero tambin
depende del IDServicio, pues con el IDServicio podemos averiguar qu Nombre_servicio tiene el
registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el
IDServicio para que sea la clave principal pues es el campo del que depende.
Y con este ejemplo vemos qu fcil es librarnos de las inconsistencias de no cumplir la tercera
forma normal, y de la redundancia de datos. Si no hubiramos normalizado tendramos que en un
registro el IDServicio 3 es Apache y nadie nos asegura que en otro el IDServicio 3 tambin lo sea
pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un
histrico de 500 servidores durante 1000 das, tendramos 500 mil registros con un campo
innecesario que estara duplicado muchsimas veces
1.
.
2.
3.
4.
FN1
A'(a0, a1,a3)
Cajena: {a0, a1} A
A (a0, a1, a4, a5)
FN2
A (a0, a1, a4, a5)
Cajena: {a1} A2
A2 (a1, a2)
FN3
A' (a4, a5)
A (a0, a1, a4)
Cajena: {a4} A'
5.
FN2
A(a0,a2)
Enunciado 2.
CAMPAMENTO (cod_nio, cod_monitor, {fecha_inicio},
num_dias, nom_nio, nom_monitor, edad_nio,
titulo_monitor)
FN1
CAMPAMENTO' (cod_nio, cod_monitor, fecha_inicio)
Cajena: {cod_nio, cod_monitor} Campamento.
CAMPAMENTO(cod_nio, cod_monitor, num_dias, nom_nio, nom_monitor, edad_nio,
titulo_monitor)
FN2:
CAMPAMENTO(cod_nio, cod_monitor, num_dias)
Cajena: {cod_nio} Nio
Cajena: {cod_monitor} Monitor
NIO (cod_nio, nom_nio, edad_nio)
MONITOR (cod_monitor, nom_monitor, titulo_monitor)
Enunciado 3.
ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edicin},
nom_autor, especialidad_autor, editorial)
ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edicin}, nom_autor, especialidad_autor, editorial)
FN1
ESCRIBIR_LIBRO' (isbn, dni, tipo, edicion)
Cajena: {isbn, dni} ESCRIBIR_LIBRO
ESCRIBIR_LIBRO (isbn, dni, num_pag, nom_autor, especialidad_autor, editorial)
FN2:
ESCRIBIR_LIBRO(isbn, dni)
Cajena: {isbn} Libro
Cajena: {dni} Autor
LIBRO (isbn, num_pag, editorial)AUTOR(dni, nom_autor, especialidad_autor)
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, {aux_vuelo}, hora_salida)
Enunciado 4.
VUELO (num_vuelo, dni, cod_avion, nom_piloto,
num_asientos, {aux_vuelo}, hora_salida)
FN1
VUELO' (num_vuelo, dni, cod_avion, aux_vuelo)
Cajena: {num_vuelo, dni, cod_avion} VUELO
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, hora_salida)
FN2
VUELO (num_vuelo, dni, cod_avion)
VIAJE(num_vuelo, hora_salida)
AVION(cod_avion, num_asientos)
PILOTO (dni, nom_piloto)
El proceso de normalizacin
El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est
en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.
Un ejemplo completo
Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado,
de modo que las condiciones salariales estn determinadas por el puesto. Se ha creado el
siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails)
nss
nombre
puesto
salario
emails
111
Juan Prez
Jefe de rea
3000
juanp@ecn.es; jefe2@ecn.es
222
Jos Snchez
Administrativo
1500
jsanchez@ecn.es
333
Ana Daz
Administrativo
1500
adiaz@ecn.es; ana32@gmail.
...
...
...
...
...
En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la
cual:
Se incluye un nuevo atributo M' que solo puede contener valores simples,
de modo que si R'[M'] es uno de los valores que tenamos en R[M],
entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores
duplicados en M, en la nueva relacin habr n tuplas, que slo varan en
que cada una de ellas guarda uno de los valores que haba en M.
La clave primaria de R' es (K, M'), dado que podr haber valores
de K repetidos, para los valores multivaluados en M.
nss
nombre
puesto
salario
111
Juan Prez
Jefe de rea
3000
juanp@ecn.es
111
Juan Prez
Jefe de rea
3000
jefe2@ecn.es
222
Jos Snchez
Administrativo
1500
jsanchez@ecn.e
333
Ana Daz
Administrativo
1500
adiaz@ecn.es
333
Ana Daz
Administrativo
1500
ana32@gmail.c
...
...
...
...
...
nss
nombre
puesto
sa
111
Juan Prez
Jefe de rea
30
222
Jos Snchez
Administrativo
15
333
Ana Daz
Administrativo
15
...
...
...
Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email):
nss
111
juanp@ecn.es
111
jefe2@ecn.es
222
jsanchez@ecn.es
333
adiaz@ecn.es
...
333
ana32@gmail.com
...
...
Eliminar de R el atributo M.
Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que
depende, que llamaremos K'.
La clave primaria de la nueva relacin ser K'.
Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen
dependencia incompleta:
nss
nombre
puesto
sa
111
Juan Prez
Jefe de rea
30
222
Jos Snchez
Administrativo
15
333
Ana Daz
Administrativo
15
...
...
...
...
nss
111
juanp@ecn.es
111
jefe2@ecn.es
222
jsanchez@ecn.es
333
adiaz@ecn.es
333
ana32@gmail.com
...
...
Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin
para el problema de 1FN.
nss
nombre
puesto
111
Juan Prez
Jefe de rea
222
Jos Snchez
Administrativo
333
Ana Daz
Administrativo
...
...
...
En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.