Diseo de Base de Datos

DISEO Y NORMALIZACIN DE LAS BASES DE DATOS. Concepto de Normalizacin.

Normalizacin: Normalizacin es el proceso de convertir una relacin (Tabla) en otras de forma tal que se cumplan ciertas restricciones. El proceso de normalizacin consiste bsicamente en obtener un conjunto de tablas, dichas tablas se obtendrn utilizando proyecciones de la tabla original. Una caracterstica fundamental de dichas proyecciones es que deben ser sin perdida ni ganancia, esto se refiere a que debe ser posible deducir de las tablas proyectadas la informacin original, ni ms ni menos. Formas Normales: Dentro de la literatura se han definido diversas formas normales, pero las ms difundidas se ilustran en la siguiente figura:
Universo de relaciones Normalizadas y no Normalizadas 1FN 2 FN 3 FN FNBC 4 FN

FN/PR (5FN)

Primera, Segunda y Tercera Formas Normales.

Primera Forma Normal (1FN) Una relacin esta en primera forma normal (1FN) sii (lase si solo si) todos los dominios base de los campos tienen valores atmicos. Es decir, un campo solo tiene un valor y no un conjunto de valores. Tomemos como ejemplo el caso de una relacin para llevar la informacin de materias y calificaciones de alumnos, un posible diseo seria el siguiente:

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

MATRICULA 331678 337890 337777 446789 CALIFS CB-001 10, MA-001 9 FS-001 7, HD-002 8 CB-002 7, CS-056 8 MA-031 7, CB-072 8, HD-002 9

Observando la relacin anterior nos damos cuenta que el dominio del campo MATRICULA si cumple la caracterstica de tener valores atmicos, pero el campo CALIFS tiene el problema de que el dominio utilizado proporciona un conjunto de valores, es decir, no esta en 1FN. Por lo tanto, se deduce que toda relacin normalizada se encuentra en 1FN. Un posible mejor diseo seria entonces:
MATRICULA 331678 331678 337890 337890 337777 337777 446789 446789 446789 CLAVE CB-001 MA-001 FS-001 HD-002 CB-002 CS-056 MA-031 CV-072 HD-002 CALIF 10 9 7 8 7 8 7 8 9

Revisando esta relacin observamos que todos los dominios de los campos proporcionan valores atmicos, es decir, ninguno de los campos tiene un conjunto de valores; por lo tanto esta relacin ya esta en 1FN. Segunda Forma Normal (2FN) Una relacin est en segunda forma normal sii est en 1FN y adems cumple la condicin de que cada atributo no-llave depende de la llave primaria. La llave primaria es el conjunto mnimo de atributos que cumplen la caracterstica de unicidad y que se escogi para ser la llave. Si existe ms de un conjunto mnimo de atributos que cumplen la unicidad, al conjunto escogido como llave se le llama llave primaria y a los dems conjuntos se les llama llaves candidato. Supongamos que tenemos una relacin que permite llevar la informacin de los proveedores de una empresa junto con las partes y la cantidad en la que son suministradas:
MCE. Jess Carlos Snchez Guzmn 2

Diseo de Base de Datos

NUM_PROV S1 S1 S2 S2 S2 S3 S3 S3 S4 S5 S5 S6 NOM_PROV JUAN JUAN PEDRO PEDRO PEDRO ANA ANA ANA RENE PATRICIA PATRICIA RENATA CIUDAD ACAPULCO ACAPULCO MERIDA MERIDA MERIDA TIJUANA TIJUANA TIJUANA DF REYNOSA REYNOSA OAXACA ESTATUS 2 2 4 4 4 5 5 5 1 2 2 2 NO_PARTE P1 P2 P1 P3 P5 P3 P4 P5 P1 P1 P4 P5 CANTIDAD 10 10 200 10 300 200 10 300 200 10 200 10

Considerando que la llave primaria es NUM_PROV, NUM_PARTE, tendramos las siguientes relaciones de dependencia entre los campos no llave y los campos de la llave candidato:

NOM_PROV

NUM_PROV

CIUDAD

ESTATUS

NUM_PARTE

CANTIDAD

De la figura anterior podemos deducir que: Los atributos NOM_PROV, CIUDAD y ESTATUS dependen de NUM_PROV, mientras que el atributo CANTIDAD depende de NUM_PROV + NUM_PARTE. De lo anterior podemos concluir que la relacin no est en 2NF (pero si est en 1FN) debido a que no todos los campos llave dependen de la llave primaria, pues existen dependencias de otros atributos no-llave como lo es el atributo NUM_PARTE del cual depende el valor de CANTIDAD, dicho de otro modo, la CANTIDAD depende de NUM_PARTE.

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

Para normalizar esta relacin es necesario realizar una proyeccin dando como resultado una tabla con los atributos que se muestran a continuacin a la cual podramos denominar Tabla S.

NUM_PROV S1 S2 S3 S4 S5 S6

NOM_PROV JUAN PEDRO ANA RENE PATRICIA RENATA

CIUDAD ACAPULCO MERIDA TIJUANA DF REYNOSA OAXACA

ESTATUS 2 4 5 1 2 2

NOM_PROV

NUM_PROV

CIUDAD

ESTATUS

Adems obtendremos una tabla ms denominada tabla SP la cual se muestra a continuacin:

NUM_PROV S1 S1 S2 S2 S2 S3 S3 S3 S4 S5 S5 S6 NUM_PARTE P1 P2 P1 P3 P5 P3 P4 P5 P1 P1 P4 P5 CANTIDAD 10 10 200 10 300 200 10 300 200 10 200 10 NUM_PROV CANTIDAD NUM_PARTE

As pues podemos concluir que: Dado que en las dos tablas obtenidas los atributos no-llave dependen solo del atributo llave, ambas tablas se encuentran en la 2FN. Tercera Forma Normal (3FN):

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

Una relacin esta en 3FN sii esta en 2FN y adems se cumple que todos los atributos de la relacin no dependen transitivamente de la llave primaria. Es decir no se da la situacin de que un campo dependa de la llave y otro dependa del primero. Tomando como ejemplo la tabla siguiente:

NUM_PROV

NOM_PROV

CIUDAD

ESTADO

S1 S2 S3 S4 S5 S6

JUAN PEDRO ANA RENE PATRICIA RENATA

ACAPULCO MERIDA MERIDA ACAPULCO REYNOSA REYNOSA

2 4 4 2 6 6

Haciendo un anlisis de los atributos de la relacin anterior, podemos observar que el atributo ESTADO depende realmente de CIUDAD y no directamente del NUM_PROV, es decir se tiene la siguiente relacin de dependencia: ms claramente;
NOM_PROV NUM_PROV NUM_PROV CIUDAD CIUDAD ESTADO ESTADO NOM_PROV

Para poder normalizar la relacin anterior es necesario realizar dos proyecciones y las tablas resultantes serian:
NUM_PROV NOM_PROV CIUDAD

S1 S2 S3 S4 S5 S6

JUAN PEDRO ANA RENE PATRICIA RENATA

ACAPULCO MERIDA MERIDA ACAPULCO REYNOSA REYNOSA

CIUDAD

ESTADO

ACAPULCO MERIDA REYNOSA

2 4 6

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

Forma Normal Boyce-Code

Forma Normal de Boyce-Codd (FNBC) Para ilustrar la necesidad de una forma normal adicional daremos un ejemplo: Supongamos que deseamos llevar la informacin de qu materias lleva cada alumno y qu profesor se las imparte. Se sabe adems de que: 1. Un alumno lleva una o ms materias. 2. Un profesor imparte slo una materia. 3. Una materia puede ser impartida por uno o ms profesores. 4. En una materia puede haber inscritos uno o ms alumnos. Un posible diseo sera (considerando que ya se definieron previamente los atributos de cada entidad):
MATR , NOM_ALU, CARR ALUMNOS NEMP , NOMBRE, GRADO PROFESORES

MATR, NEMP , CLAVE

GRUPOS

CLAVE, NOM_MATERIA,

MATERIAS

Pero como un profesor slo imparte una materia no es posible que un alumno lleve dos o ms materias con el mismo profesor, de donde concluimos que no se requiere que la llave primaria de la relacin GRUPOS sea MATR+NEMP+CLAVE sino solamente MATR+CLAVE MATR+NEMP. Es decir que tenemos dos llaves candidato.

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

De tal forma que dos mejores diseos serian:

MATR , NOM_ALU, CARR ALUMNOS NEMP , NOMBRE, GRADO PROFESORES

MATR, NEMP , CLAVE MATR GRUPOS NEMP CLAVE, NOM_MATERIA, CLAVE

MATERIAS

NOTA: La flecha de NEMP a CLAVE en ambos casos, indica que el profesor determina la materia, puesto que solo imparte una.

MATR , NOM_ALU, CARR ALUMNOS

NEMP , NOMBRE, GRADO PROFESORES

MATR,

NEMP

, CLAVE

MATR

NEMP

GRUPOS

CLAVE

CLAVE, NOM_MATERIA, DESCRIPCION

MATERIAS

En cualquiera de los dos casos podemos observar que la relacin GRUPOS est en 3FN porque todos los campos no-llave no dependen transitivamente de la llave primaria. Pero an as la relacin tiene ciertas anomalas. Por ejemplo: si solo se tiene a un alumno inscrito en una materia impartida por un profesor, al dar de baja a dicho alumno, se pierde la informacin de que materia imparte dicho profesor. Para evitar este tipo de anomalas se ha definido la FNBC que dice: Una relacin est en FNBC sii cada determinante es una llave candidato.
MCE. Jess Carlos Snchez Guzmn 7

Diseo de Base de Datos

Un Determinante es cualquier atributo o conjunto de atributos del cul otro atributo es dependiente funcionalmente en forma completa. Analizando el diagrama de dependencias y las llaves candidato tenemos lo siguiente: Las llaves candidato son: MATR+CLAVE MATR+NEMP Los determinantes son: MATR+CLAVE MATR+NEMP NEMP (Puesto que determina la CLAVE) De donde concluimos que la relacin GRUPOS no est en FNBC. Para poner a GRUPOS en FNBC tenemos que analizar sus posibles proyecciones:
PROYECCION GRUPOS[MATR,CLAVE] COMENTARIO Se pierde la informacin de que profesor le da clase s un alumno, puesto hay varios profesores para una materia

GRUPOS[MATR,NEMP]

OK, pero se requiere adicionalmente la proyeccion GRUPOS [NEMP,CLAVE] para tener la informacion original.

GRUPOS[NEMP,CLAVE]

OK, pero se requiere adicionalmente la proyeccion GRUPOS [MATR,NEMP] para recuperar la informacin original.

As concluimos que la relacin grupos debe descomponerse en las proyecciones: GRUPO[MATR,NEMP] y GRUPOS[NEMP,CLAVE], teniendo as el diseo de la base de datos de la siguiente manera:

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

MATR , NOM_ALU, CARR ALUMNOS NEMP , NOMBRE, GRADO PROFESORES

MATR, NEMP

NEMP , CLAVE

ALU_PROF

PROF_MAT

CLAVE, NOM_MATERIA,

MATERIAS

De lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda llave) y que PROF_MAT ya est en FNBC puesto que solo existe un determinante (que es NEMP). Adicionalmente se puede verificar que la anomala de perder informacin de que materia da un profesor al borrar al nico alumno que estaba inscrito se ha evitado. Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves candidato se traslapan.
MATR , NOM_ALU, CARR ALUMNOS NEMP , NOMBRE, GRADO PROFESORES

MATR, NEMP

NEMP , CLAVE

ALU_PROF

PROF_MAT

CLAVE, NOM_MATERIA,

MATERIAS

De lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda llave) y que PROF_MAT ya est en FNBC puesto que solo existe un determinante (que es NEMP). Adicionalmente se puede verificar que la anomala de perder informacin de que materia da un profesor al borrar al nico alumno que estaba inscrito se ha evitado. Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves candidato se traslapan.
MCE. Jess Carlos Snchez Guzmn 9

Diseo de Base de Datos

Cuarta Forma Normal.

Existen algunas relaciones que a pesar de estar en FNBC presenta cierto grado de redundancia. Lo cual a su vez tiene como consecuencia que tengamos anomalas al realizar altas y cambios. Para ilustrar esto, consideraremos que en una universidad se desea llevar el control de materias, profesores y libros de texto. Se tienen las siguientes reglas del negocio: Una materia puede ser impartida por uno o ms profesores. Una materia tiene asociados uno o ms libros de texto. Un profesor puede impartir una o ms materias Un profesor al impartir una materia usa todos los libros de texto de esa materia. Un libro de texto puede ser utilizado en una o ms materias.

De este modo un posible diseo sera:

Analizando en detalle la relacin GRUPOS nos podemos dar cuenta que requiere que todos los atributos sean la llave, puesto que: Un mismo libro se puede repetir para diferentes combinaciones de profesor y materia. Un mismo profesor se puede repetir para diferentes combinaciones de materias y libros. Una misma materia se puede repetir para diferentes combinaciones de profesor y libro. En este sentido al ser todos los atributos la LLAVE ya est en FNBC pero tiene algunos problemas: Al dar de alta a un nuevo profesor para una materia tenemos el problema de dar de alta tantos registros como libros haya para la materia.
MCE. Jess Carlos Snchez Guzmn 10

Diseo de Base de Datos

Al dar de alta un libro para una materia, se tienen que dar de alta tantos registros como profesores haya para la materia. La FNBC no nos ayuda a corregir estos problemas, por lo que se requiere una forma normal adicional: Una relacin esta en Cuarta Forma Normal (4FN) sii al tener dependencias multivaluadas de la forma A-->>B todas las dependencias funcionales dependen de A. Es decir todas las dependencias multivaluadas son dependencias funcionales. Para el caso de la relacin analizada tenemos: CLAVE -->> NEMP CLAVE -->> LIBRO Para este caso un mejor diseo separara las dependencias multivaluadas dando:

Quinta Forma Normal (PJ/NF 5FN)

Dentro del proceso de normalizacin presentado, se ha visto que se realizan proyecciones sin prdida y sin ganancia. Normalmente se tiene que una relacin es descompuesta en dos de sus proyecciones y al realizar el JOIN de dichas proyecciones se recupera la tabla original. Existen algunas relaciones en las cuales el realizar dos proyecciones de la tabla original no es suficiente para tener una descomposicin sin perdida ni ganancia. Tomemos el caso de PROVEEDORES, PARTES y PROYECTOS en donde se tiene que: Un proveedor puede suministrar diferentes partes a diferentes proyectos.
MCE. Jess Carlos Snchez Guzmn 11

Diseo de Base de Datos

Una parte puede ser usada por diferentes proyectos y suministrada por diferentes proveedores. Un proyecto puede usar diferentes partes las cuales pueden ser suministradas por diferentes proveedores En este sentido un posible diseo sera:

Al analizar la relacin SPJ podemos ver que se requiere que toda sea llave y una posible descomposicin sera: SP (SNO, PNO) y PJ(PNO,JNO) Considerando que el contenido de SPJ es:
SNO S1 S1 S2 S1 PNO P1 P2 P1 P1 JNO J2 J1 J1 J1

Entonces SP sera:
SNO S1 S1 S2 PNO P1 P2 P1

y PJ sera:
PNO P1 P2 P1 JNO J2 J1 J1

Al realizar el join de SP con PJ produce:

SNO S1
MCE. Jess Carlos Snchez Guzmn

PNO P1

JNO J2
12

Diseo de Base de Datos

S1 S1 S2 S1

P1 P2 P1 P1

J1 J1 J2 J1

De donde se concluye que se tiene un registro adicional que es S2, P1, J2. Para poder tomar proyecciones sin prdida ni ganancia de la tabla SPJ es necesario tomar 3 proyecciones, y realizar joins entre ellos. La proyeccin que hace falta es: SJ(SNO, JNO) Que al realizar el join de ((SP JOIN PJ) JOIN SJ) produce la tabla original eliminando la ganancia obtenida. De lo anterior concluimos que: SI, Sx Py aparece en SP Y Py, Jw aparece en PJ Y Sx, Jw aparece en SJ Entonces: Aparece Sx, Py, Jw en SPJ. En este sentido se define la dependencia al join (JD) de la siguiente forma: Una relacin satisface una JD sii la relacin original se produce por la juntura de las proyecciones indicadas en JD Si la relacin R consta de campos A, B, C satisface la dependencia JD(AB, AC) sii R se produce de AB JOIN AC Corolario: Esto implica que:
A-->>B y A-->>C es decir que JD es mas general que las dependencias multivaluadas, o que las dependencias multivaluadas son un caso especial de las dependencias a la juntura (JD).

De este modo la definicin de la 5FN es: Una relacin esta en 5FN sii cada dependencia a la juntura es una consecuencia de sus llaves candidato. Es decir si se pueden deducir las dependencias de la juntura directamente de sus llaves candidatos. Para el caso de SPJ se satisface JD(SP, PJ, SJ) pero esto no puede ser deducido de la llave candidato (SNO, PNO, JNO) por lo que no esta en 5FN. Pero las relaciones SP, PJ, SJ si estn en 5FN. Comprobacin de la 5 forma normal

MCE. Jess Carlos Snchez Guzmn

13

Diseo de Base de Datos

MCE. Jess Carlos Snchez Guzmn

14