Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Bases de Datos Normalizacion
Bases de Datos Normalizacion
FN/PR (5FN)
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
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.
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
ESTATUS 2 4 5 1 2 2
NOM_PROV
NUM_PROV
CIUDAD
ESTATUS
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):
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
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
CIUDAD
ESTADO
2 4 6
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.
MATERIAS
NOTA: La flecha de NEMP a CLAVE en ambos casos, indica que el profesor determina la materia, puesto que solo imparte una.
MATR,
NEMP
, CLAVE
MATR
NEMP
GRUPOS
CLAVE
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
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:
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
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
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:
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
PNO P1
JNO J2
12
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
13
14