apunte 4

Vista previa del material en texto

Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 1 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
DISEÑO DE BASES DE DATOS RELACIONALES. 
 
 
 
OBJETIVOS. 
 
Como hemos visto, cada Relación “Entidad”, o simplemente “Entidad”, contiene un 
conjunto de atributos y una Base de Datos Relacional es un conjunto de entidades, de 
relaciones entre esas entidades y de restricciones. 
 
Los atributos que se agrupan para formar la cabecera de una entidad son los que indican 
el sentido común del diseñador de la base de datos. Sin embargo, no hemos definido 
normas para tales agrupamientos ni para decidir si un agrupamiento es mejor que otro o 
no. 
 
El objetivo del diseño de bases de datos es aprender a elegir buenas cabeceras de 
entidades, es decir, medir formalmente las razones por las cuales un conjunto de atributos 
es mejor que otro. 
 
 
 
MEDIDAS INFORMALES DE CALIDAD PARA EL DISEÑO. 
 
Definiremos cuatro medidas informales: 
 
1. Semántica de los atributos. 
2. Reducción de los valores redundantes de las tuplas. 
3. Reducción de los valores nulos de las tuplas. 
4. Prohibición de tuplas espúreas. 
 
Semántica de los atributos de una entidad. 
 
Hemos visto que una entidad es un conjunto de hechos o enunciados. Este significado, o 
semántica, indica cómo deben interpretarse los valores de los atributos almacenados en 
una tupla, o sea, qué relación hay entre los valores de los atributos de una tupla. 
 
Por ejemplo, en la entidad Alumnos que hemos definido anteriormente, cada tupla 
representa a un alumno, con valores para su número de libreta universitaria, su número 
de documento de identidad, su nombre, su domicilio, su teléfono y el código de la carrera 
que cursa. El atributo Código de Carrera es la clave foránea que representa la relación 
entre la entidad Alumnos y la entidad Carreras. 
 
Así, este esquema puede considerarse como un buen esquema en lo que respecta a la 
claridad de su semántica. 
 
La pauta es diseñar cabeceras de entidades para las cuales sea fácil explicar su 
significado. 
 
Reducción de los valores redundantes de las tuplas. 
 
Si en nuestra entidad Alumnos hubiésemos incorporado como atributo también el nombre 
de la carrera que cursa el alumno, estaríamos frente a una entidad que posee un atributo 
redundante. 
 
Esta redundancia no solo no optimiza el espacio de almacenamiento de los datos, sino 
que trae aparejados serios problemas de falta de consistencia. 
 
La pauta es diseñar cabeceras de entidades que no contengan atributos redundantes. 
 
Reducción de los valores nulos de las tuplas. 
 
Si algún atributo no se aplica a la tupla, tendremos en ella una gran cantidad de valores 
nulos. Esto dificulta el significado de los atributos. 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 2 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
 
Por ejemplo, sin en nuestra entidad Alumnos hubiésemos incorporado como atributo el 
número de documento de identidad del padre del alumno, notaríamos que como el dato 
no está disponible en general, los valores correspondientes a este atributo son 
mayoritariamente nulos en cada una de las tuplas. 
 
Prohibición de tuplas espúreas. 
 
Una tupla será espúrea cuando no puede reunirse con las tuplas correspondientes según 
la relación definida entre dos entidades. 
 
Por ejemplo, si en nuestra entidad Alumnos en vez de relacionar con la entidad Carreras a 
través del Código de Carrera lo hubiésemos hecho a través del nombre de la carrera, 
cualquier modificación en la sintaxis del nombre de la carrera impediría asociar las tuplas 
resultantes de la relación. 
 
Por lo tanto, las entidades deben diseñarse de tal manera que puedan reunirse 
condiciones de igualdad sobre atributos que sean claves primarias o claves foráneas. 
 
 
 
DEPENDENCIA FUNCIONAL. 
 
Definición: 
 
Dada una relación R, un conjunto de atributos Y de R depende funcionalmente de un 
conjunto no vacío de atributos X de R si y solo si, siempre que dos tuplas coincidan en el 
valor de X, necesariamente deben coincidir en su valor de Y. Denotamos: 
 
R.X - - - > R.Y 
 
y leemos "R.X determina funcionalmente a R.Y", o bien, "R.Y depende funcionalmente de 
R.X". 
 
Supongamos que hemos definido la siguiente relación Listado, que contiene datos de los 
alumnos de una determinada Facultad, con la restricción de que cada alumno puede 
cursar una única carrera en tal Facultad: 
 
LU DNI Nombre Domicilio 
 
 
en ella vemos que, cuando se asigna el número de LU a un alumno, el resto de los 
valores que contendrá esa tupla quedan definidos en función de ese número de libreta 
universitaria. Esto es porque el número de libreta universitaria es único y, entonces, 
permite identificar a un alumno determinado que tiene DNI, Nombre y Domicilio 
determinados. 
 
Dicho de otra manera: cada vez que encontremos el mismo valor de LU, encontraremos 
asociados exactamente los mismos valores de DNI, de Nombre y de Domicilio. 
 
Lo representamos: 
LU - - - > DNI 
LU - - - > Nombre 
LU - - - > Domicilio 
 
o bien, para simplificar: 
 
LU - - - > DNI, Nombre, Domicilio. 
 
Observando los atributos de la relación Listado, también podemos decir: 
 
DNI - - - > LU, Nombre, Domicilio 
 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 3 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
puesto que, como cada alumno puede cursar una sola carrera, el resto de los atributos de 
la relación Listado quedan determinados al fijarse el DNI. 
 
También podemos asegurar que: 
 
Nombre - -/- - > Domicilio 
 
pues, efectivamente, podríamos tener dos alumnos distintos con el mismo nombre pero 
no necesariamente con el mismo domicilio. 
 
Es claro que, para cualquier relación, los atributos deben depender funcionalmente de la 
clave primaria de esa relación, por definición de clave primaria. Esto es extensivo para 
cualquier clave candidata de la relación. Sin embargo, la definición de dependencia 
funcional no requiere que el atributo X sea una clave candidata. 
 
Vamos a representar las dependencias funcionales que hemos encontrado en nuestra 
relación Listado en un diagrama de dependencias funcionales: 
 
 
 
 
 
 
 
 
 
 
 
Veamos otro ejemplo. Supongamos que tenemos una relación, de nombre Fea, donde 
queremos guardar datos referentes a las asignaturas en las que se inscriben los alumnos 
de una determinada carrera y que está definida de la siguiente manera: 
 
LU DNI Nombre CPostal Localidad CodMat Año Condición 
1 1000000
0 
Juan 4400 Salta 1 1998 Regular 
1 1000000
0 
Juan 4400 Salta 2 1999 Regular 
1 1000000
0 
Juan 4400 Salta 3 1999 Libre 
2 2000000
0 
Pedro 4400 Salta 1 2000 Libre 
3 3000000
0 
María 4401 San 
Lorenzo 
2 1999 Regular 
3 3000000
0 
María 4401 San 
Lorenzo 
3 2000 Libre 
 
cuyas claves candidatas son (LU, CodMat, Año) y (DNI, CodMat, Año) y CodMat es una 
clave foránea que referencia a alguna otra relación donde CodMat es clave primaria 
donde, además, está especificado, al menos, el nombre de la materia. 
 
Está claro que: 
 
(LU, CodMat, Año) - - - > DNI, Nombre, CPostal, Localidad, Condición 
(DNI, CodMat, Año) - - - > LU, Nombre, CPostal, Localidad, Condición 
LU - - - > DNI, Nombre, CPostal, Localidad 
DNI - - - > LU, Nombre, CPostal, Localidad 
CPostal - - - > Localidad 
 
La dependencia funcional de los atributos Nombre, CPostal, Localidad y Condición con 
respecto a las claves candidatas ya está comentada y también tenemos ejemplos de 
atributos como DNI, Nombre, CPostal y Localidad que dependen funcionalmente de LU o 
de LU, Nombre,CPostal y Localidad que dependen funcionalmente de DNI y como 
Localidad que depende funcionalmente de CPostal cuando ni LU, ni DNI, ni CPostal son 
claves candidatas. 
 
Comencemos por tratar un poco más profundamente lo que sucede con las dependencias 
funcionales de DNI, Nombre, CPostal y Localidad con respecto a LU o de LU, Nombre, 
CPostal y Localidad con respecto a DNI. 
 
DNI 
Nombre 
Domicilio 
LU 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 4 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
Definición: 
 
Dada una relación R, se dice que un conjunto de atributos Y de R, depende 
funcionalmente en forma completa de un conjunto no vacío de atributos X de R si 
depende funcionalmente de X y no depende funcionalmente de ningún subconjunto propio 
de X. 
 
En el ejemplo anterior, DNI, Nombre, CPostal y Localidad dependen funcionalmente de 
(LU, CodMat, Año), pero no es una dependencia funcional completa, o dependen 
funcionalmente de (LU, CodMat, Año) pero no en forma completa. 
 
Lo mismo sucede con LU, Nombre, CPostal y Localidad, que dependen funcionalmente 
de (DNI, CodMat, Año), pero no es una dependencia funcional completa, o dependen 
funcionalmente de (DNI, CodMat, Año) pero no en forma completa. 
 
En adelante nos referiremos a dependencia funcional con DF y a dependencia funcional 
completa con DFC. 
 
Así, para nuestra relación Fea, el diagrama de dependencias funcionales adquiere el 
siguiente aspecto: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
La dependencia funcional es un concepto semántico. Reconocer las dependencias 
funcionales es parte del proceso de entender qué significan los datos. Miremos nuestro 
ejemplo: el hecho de que, en la relación Fea, el atributo Nombre tenga una DFC de LU 
significa que, en el mundo real, el número de libreta universitaria es único para cada 
alumno y esa restricción debe hacerse cumplir de alguna manera en la base de datos. La 
forma de hacerla cumplir es especificarla en los esquemas, para que el DBMS pueda 
aplicarla. 
 
Como hemos dicho, debemos someter nuestro esquema de relación a una serie de 
pruebas para certificar su calidad. Esta serie de pruebas son las definidas en un proceso, 
denominado Proceso de Normalización, que fue introducido por Codd en el año 1.972. 
Consiste en descomponer esquemas de relación insatisfactorios repartiendo sus atributos 
entre esquemas de relación más pequeños que poseen propiedades deseables. 
 
Para ello, estudiaremos las formas normales propuestas por Codd, que proveen al 
diseñador de bases de datos: 
 
 un marco formal para analizar los esquemas de relación en base a sus claves y a 
las dependencias entre sus atributos, 
 
 una serie de pruebas que pueden efectuarse sobre esquemas de relación 
individuales de modo que la base de datos relacional pueda normalizarse hasta el 
grado deseado. 
 
LU 
Año 
Nombre 
CPostal 
Localidad 
CodMat 
Condición 
DNI 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 5 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
Esto de grado deseado debe entenderse como que el diseñador de la base de datos no 
tiene obligación de normalizar hasta el grado más alto posible. Las relaciones pueden 
dejarse en formas normales más bajas por razones de rendimiento, por ejemplo. 
 
Antes de continuar, formalizaremos la siguiente 
 
Definición: 
 
Un atributo primo es un atributo de una relación R que forma parte de cualquier clave 
candidata de R. 
 
Por ende, un atributo no primo de una relación R es el que no forma parte de ninguna 
clave candidata de R. 
 
En el ejemplo de la relación Fea, LU, DNI, CodMat y Año son atributos primos y el resto 
de los atributos son no primos. 
 
 
 
PRIMERA FORMA NORMAL (1FN). 
 
Definición: 
 
Una relación R está en 1FN si y solo si todos los dominios de sus atributos contienen 
valores atómicos. 
 
Esta 1FN surgió originalmente por la necesidad de prohibir los atributos multivaluados. 
Posteriormente, al definirse el conjunto de restricciones del Modelo Relacional, esta 1FN 
se incorporó como Restricción de Dominio. 
 
Una inferencia inmediata de ello es que podemos asegurar que, en el Modelo Relacional, 
toda relación está en 1FN. 
 
 
SEGUNDA FORMA NORMAL (2FN). 
 
Si a esta altura alguien considera que basta con que una relación esté en 1FN, debería 
volver a mirar la relación Fea que hemos propuesto como ejemplo. 
 
Pensemos nada más en que al alumno de nombre Pedro, cuya LU = 2, por algún motivo 
se le debe dar de baja. Al eliminar las tuplas correspondientes en la relación Fea, no solo 
perdemos los datos con respecto al año en que cursó cada asignatura, sino también todos 
sus datos personales. De igual manera, cada vez que un alumno se inscriba para cursar 
una asignatura, se dará de alta una tupla que, nuevamente, contendrá los datos 
personales: la redundancia es obvia. También tenemos problemas si un mismo alumno 
cambia su domicilio. Por ejemplo, si María que vivía en San Lorenzo se muda al centro, 
deberemos buscar todas las tuplas con valor LU = 3 y actualizar el domicilio y, ¿ si nos 
olvidamos de alguna ?. Y aunque no nos olvidemos . . . . 
 
Y esto pasa porque los datos personales del alumno solamente tienen que ver con su 
número de libreta universitaria o con su número de documento de identidad. Esto es: 
 
LU - - - > DNI, Nombre, CPostal, Localidad 
ó 
DNI - - - > LU, Nombre, CPostal, Localidad 
 
o sea, los atributos DNI, Nombre, CPostal y Localidad de la relación Fea, dependen 
funcionalmente de la clave candidata (LU, CodMat, Año), pero no en forma completa, pero 
sí hay una DFC entre los atributos citados y el atributo LU de la relación Fea. 
 
Lo mismo sucede con los atributos LU, Nombre, CPostal y Localidad que dependen 
funcionalmente de la clave candidata (DNI, CodMat, Año), pero no en forma completa, 
pero sí hay una DFC entre los atributos citados y el atributo DNI. 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 6 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
 
Definición: 
 
Una relación R está en 2FN si todo atributo no primo depende funcionalmente en forma 
completa de toda clave candidata de R. 
 
En el diagrama de dependencias funcionales efectuado para la relación Fea, vemos que 
los atributos no primos: Nombre, CPostal y Localidad no dependen funcionalmente en 
forma completa de ninguna de las claves candidatas. 
 
Pensando en contar con alguna relación a la que nos referiremos como „4. Materias‟ y que 
tiene, minimamente, el código y el nombre de las materias, separemos la relación Fea en 
dos relaciones: 
 
1. Alumnos1 2. Inscripciones 
LU DNI Nombre CPostal Localidad LU CodMat Año Condición 
CC1 CC2 CC1 CC1 CC1 
@ @ @ @ 
 FK(1) FK(4) 
 
y veamos que ahora en la relación Alumnos1: 
 
LU - - - > DNI, Nombre, CPostal, Localidad 
DNI - - - > LU, Nombre, CPostal, Localidad 
CPostal - - - > Localidad 
 
y en la relación Inscripciones: 
 
(LU, CodMat, Año) - - - > Condición 
 
La siguiente descomposición es otra alternativa: 
 
1. Alumnos1* 2. Inscripciones* 
LU DNI Nombre CPostal Localidad DNI CodMat Año Condición 
CC1 CC2 CC1 CC1 CC1 
 @ @ @ @ 
 FK(1) FK(4) 
 
ya que ambas satisfacen todas las restricciones del Modelo Relacional. 
 
En general, dadas: 
 
R (A, B, C, D) 
PK = (A, B) 
A - - - > D 
 
la descomposición de la relación R, en dos relaciones R1 y R2 donde: 
 
R1 (A, D) 
PK = A 
 
R2 (A, B, C) 
PK = (A, B) 
FK = A, que referencia a R1 
 
es una descomposición sin pérdida de información, dado que elnexo entre las relaciones 
R1 y R2 se efectúa a través de la clave foránea A de R2 que referencia a R1 y, por lo 
tanto, siempre es posible reconstruir el conjunto de tuplas que inicialmente contenía R. 
 
 
 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 7 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
DEPENDENCIA TRANSITIVA. 
 
El hecho de que en la relación Alumnos1, que se encuentra en 2FN, el atributo Localidad 
tenga una DFC con respecto al atributo CPostal, sigue trayendo problemas de anomalías 
de actualización. 
 
Analicemos su diagrama de dependencias funcionales de Alumnos1: 
 
 
 
 
 
 
 
 
 
 
 
 
La dependencia de Localidad con respecto a LU y a DNI es, de hecho una DFC. Pero, 
además, Localidad depende también en forma transitiva de LU y de DNI, a través de 
CPostal: cada valor de LU o de DNI determina un valor de CPostal y ese valor CPostal, a 
su vez, determina un valor de Localidad. 
 
En términos generales, si en una relación R: 
 
A - - - > B  B - - - > C  A - - - > C 
 
decimos que C depende transitivamente de A, o que C tiene una dependencia transitiva 
respecto de A, a través de B. 
 
 
 
TERCERA FORMA NORMAL (3FN). 
 
Definición: 
 
Una relación R está en 3FN si y solo si está en 2FN y, además, todos los atributos no 
primos dependen de manera no transitiva de toda clave candidata de R. 
 
Esta definición es equivalente a la siguiente: 
 
Una relación R está en 3FN si y solo si está en 2FN y, además, no hay dependencias 
funcionales entre atributos no primos. 
 
Nuevamente, la solución es hacer una descomposición sin pérdidas. En nuestro caso, 
descomponemos nuestra relación Alumnos1 en dos relaciones: 
 
1. Alumnos 3. Localidades 
LU DNI Nombre CPostal CPostal Localidad 
CC1 CC2 CC1 
@ @ 
 FK(3) 
 
de modo que para la relación Alumnos: 
 
LU - - - > DNI, Nombre, CPostal 
DNI - - - > LU, Nombre, CPostal 
 
y, para la relación Localidades: 
 
CPostal - - - > Localidad 
LU 
Nombre 
CPostal 
Localidad 
DNI 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 8 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
 
garantizando la descomposición sin pérdidas el hecho de que CPostal es clave foránea en 
la relación Alumnos. 
 
En general, dada una relación R del tipo: 
 
R (A, B, C) 
PK = A 
B - - - > C 
 
la disciplina de normalización recomienda sustituir R por dos relaciones R1 y R2, tales 
que: 
R1 (B, C) 
PK = B 
 
R2 (A, B) 
PK = A 
FK = B, que referencia a R1. 
 
Volvemos a insistir en que el nivel de normalización de una relación es una cuestión de 
semántica y no una cuestión de valores que pueden llegar a tomar los atributos. De 
hecho, no es posible observar los valores de las tuplas en un momento dado y de esos 
valores inferir si la relación está, por ejemplo, en 3FN. Es necesario, además, conocer el 
significado de los datos, es decir, las dependencias, antes de emitir una conclusión. 
 
 
 
FORMA NORMAL DE BOYCE-CODD (FNBC). 
 
La FNBC introduce nuevos elementos que agregan mayores condicionamientos a la 3FN. 
Para poder definirla, veamos primero el concepto de determinante. 
 
Un determinante es un atributo o conjunto de atributos del cual depende funcionalmente 
en forma completa algún otro atributo. Por ejemplo, en nuestra relación Fea: (LU, CodMat, 
Año), (DNI, CodMat, Año), LU, DNI y CPostal son todos determinantes. 
 
Definición: 
 
Una relación R está en FNBC si y solo si todo determinante es una clave candidata. 
 
En otras palabras: una relación está en FNBC si los únicos determinantes son las claves 
candidatas, o sea, si las únicas flechas del diagrama de dependencias funcionales salen 
de las claves candidatas. 
 
En lo conceptual, la definición es más sencilla que la de 3FN por cuanto no hace 
referencia explícita a la 2FN ni al concepto de dependencia transitiva. Además, sigue 
siendo cierto que cualquier relación puede descomponerse sin pérdidas en un conjunto de 
relaciones todas en FNBC. 
 
Por otra parte, los conceptos de clave primaria, de dependencia funcional completa y de 
dependencia funcional transitiva son útiles en la práctica, porque dan idea del proceso 
real que debe seguir el diseñador de la base de datos para reducir una relación arbitraria 
a un conjunto equivalente de relaciones en alguna forma normal deseada. 
 
Esta FNBC define una forma normal estrictamente más fuerte que la 3FN. De hecho, 
aunque la definición no indica explícitamente la condición de que una relación se 
encuentre en 2FN o en 3FN para que se encuentre en FNBC, podemos asegurar: 
 
 Una relación que se encuentra el FNBC se encuentra en 2FN. 
Efectivamente, si una relación se encuentra en FNBC, todo determinante es una 
clave candidata, así que podemos asegurar que todos los atributos no primos 
dependen funcionalmente en forma completa de toda clave candidata. 
Es decir, toda clave candidata determinará funcionalmente en forma completa a 
todos los atributos no primos de la relación. 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 9 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
Por ejemplo, supongamos un esquema de relación R (A, B, C, D, E, F), cuyas 
claves candidatas son (A, B) y (C, D) y que se encuentra en FNBC. A partir de esto, 
obtenemos el siguiente diagrama de dependencias funcionales: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Una relación que se encuentra en FNBC se encuentra en 3FN. 
Si una relación se encuentra en FNBC, todo determinante es una clave candidata. 
Esto implica que ningún atributo no primo será un determinante y, por lo tanto, no 
habrá dependencias transitivas. Además, como toda relación que está en FNBC 
está en 2FN, se completan las condiciones para que esté en 3FN. 
 
Veamos algunos ejemplos de relaciones y determinemos si se encuentran en FNBC. 
 
La relación Alumnos1, cuyos atributos son LU, DNI, Nombre, CPostal y Localidad, no está 
en FNBC pues el atributo CPostal es determinante y no es clave candidata. 
 
La relación Alumnos, cuyos atributos son LU, DNI, Nombre y CPostal, está en FNBC 
porque los únicos determinantes son los atributos LU y DNI, y ambos son claves 
candidatas. 
 
El esquema de relación R (A, B, C, D), cuyas claves candidatas son A y B, que tiene el 
siguiente diagrama de dependencias funcionales: 
 
 
 
 
 
 
 
 
 
 
está en FNBC, pues las únicas flechas salen de claves candidatas. 
 
Aparte de la definición de 2FN y 3FN, vimos una técnica para descomponer una relación 
que no estaba en 2FN en un conjunto de relaciones en 2FN y para descomponer una 
relación que no estaba en 3FN en un conjunto de relaciones en 3FN. Veamos cómo 
descomponer una relación dada que no está en FNBC en un conjunto de relaciones que 
estén en FNBC. 
 
Como sabemos que para que una relación esté en FNBC solamente tenemos que exigir 
que todo atributo determinante sea una clave candidata, la lógica indica que debemos 
descomponer la relación dada en un conjunto de relaciones formado por: 
 
 una relación por cada conjunto de atributos de la relación R dada que sea 
determinante en R pero no clave candidata de R, junto a los atributos que determina 
funcionalmente en forma completa y que, a su vez, no dependen de otro 
determinante. 
 
 una relación del conjunto de relaciones formado por los determinantes de R que son 
claves candidatas de R, más todos los atributos que determinan funcionalmente en 
forma completa. 
 
A B 
C D 
E 
F 
A 
B 
C 
D 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas.Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 10 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
Apliquemos esta idea a nuestra relación Fea. En ella hay tres determinantes que no son 
claves candidatas: LU, DNI y CPostal, así que, en principio deberíamos tener tres 
relaciones: 
 
R1 (LU, DNI, Nombre, CPostal) 
R2 (DNI, LU, Nombre, CPostal) 
R3 (CPostal, Localidad) 
 
pero, como vemos que R1 = R2, obtenemos: 
 
R1 (LU, DNI, Nombre, CPostal) 
R2 (CPostal, Localidad) 
 
donde LU y DNI son ambas claves candidatas en R1 y CPostal es clave candidata en R2. 
 
Como los determinantes de Fea que son claves candidatas son (LU, CodMat, Año) y 
(DNI, CodMat, Año) y el atributo no primo Condición tiene una DFC de ambas, el conjunto 
de relaciones formado por un determinante más los atributos que tienen una DFC de ese 
determinante es: 
 
R3 (LU, CodMat, Año, Condición) 
R4 (DNI, CodMat, Año, Condición) 
 
de entre las cuales elegimos R3, cuya única clave candidata es (LU, CodMat, Año). 
 
Así, obtenemos el siguiente conjunto de relaciones, cada una de las cuales está en 
FNBC: 
 
1. Alumnos 
 
LU DNI Nombre CPostal 
CC1 CC2 
@ 
 FK(3) 
 
2. Inscripciones 
 
LU CodMat Año Condición 
CC1 CC1 CC1 
@ @ @ 
FK(1) FK(4) 
 
3. Localidades 
 
Costal Localidad 
CC 
@ 
 
 
conjunto del cual forma parte, obviamente, la relación „4. Materias‟, a la cual hemos hecho 
referencia precedentemente. 
 
Una vez más, garantizamos la descomposición si pérdidas a través de las claves foráneas 
en la relación que corresponde. 
 
 
OTRAS DEPENDENCIAS Y FORMAS NORMALES. 
 
La Teoría de la Normalización y temas afines, lo que ahora se conoce como Teoría de las 
Dependencias, ha crecido notablemente. Las investigaciones en el área continúan y, de 
hecho, aportan nuevas definiciones constantemente. 
Universidad Nacional de Salta. 
Facultad de Ciencias Exactas. 
Tecnicatura Universitaria en Programación 
BASES DE DATOS Página 11 
 
Lic. Patricia Mac Gaul – Lic. Martín Díaz - Lic. Guillermo Villanueva 
 
Por ejemplo, podemos preguntarnos: ¿ bastará que en la relación Alumnos se indique el 
CPostal de cada uno de ellos o será necesario separar esta relación en un conjunto de 
relaciones tales cada una de ellas contenga solamente a los alumnos que viven en una 
misma localidad?. La Teoría de la Normalización que hemos estudiado no puede 
contestar a tal pregunta. 
 
En lo que a nosotros respecta, el proceso de normalización no es más que una 
herramienta para validar la calidad de una relación. La abstracción de la realidad 
representada en un Diagrama Entidad-Relación tienden a producir con naturalidad 
relaciones normalizadas siempre y cuando el conjunto de atributos que se le asigne a 
cada una de las entidades definidas en el DER sea el correcto. 
 
Las cualidades del esquema conceptual son: 
 
 compleción, 
 corrección, 
 minimalidad, 
 expresividad, 
 legibilidad, 
 autoexplicación, 
 flexibilidad, 
 normalidad. 
 
Estas cualidades deben guiar el proceso de diseño, deben comprobarse varias veces 
mientras de diseña una base de datos y deben considerarse cuidadosamente al final del 
esquema conceptual. 
 
 
 
DESNORMALIZACIÓN. 
 
La desnormalización es un proceso a través del cual se toma una relación, o un conjunto 
de relaciones, que se encuentra en una determinada forma normal y, a través de 
sucesivos pasos, se la convierte en una relación o conjunto de relaciones que se 
encuentran en una forma normal más baja que la inicial. 
 
Y ¿ por qué querríamos hacer semejante cosa, con la ventaja que implica elevar el nivel 
de forma normal de una relación ?. Porque, a veces, los condicionamientos encontrados 
durante el diseño de los procesos que actuarán sobre nuestra base de datos así lo 
requieren. 
 
Esto es aún más cierto cuando los procesos son críticos, esto es, la eficiencia del proceso 
debe prevalecer y, quizá, para ello sea necesario que algunas de las relaciones que 
forman parte de nuestra base de datos se encuentren en, por ejemplo 2FN. 
 
La Teoría de la Normalización, al definir las formas normales de tal manera que cada 
condición que se obliga a cumplir a una relación asegura su aumento de nivel a una forma 
normal superior, establece también, por el camino inverso, las pautas para tomar una 
relación en alguna forma normal y llevarla a otra más baja.