Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Ingeniera de Sistemas
Sesin 12
Otras Formas de Normalizacin de
Datos
Pag. 106
Base de Datos I
Ingeniera de Sistemas
si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En trminos menos formales, una tabla est en FNBC si est en 3FN y los
nicos determinantes son claves candidatas.
Ejemplo:
Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada
departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos
una tabla con las columnas:
IDTrabajador, IDDepartamento, IDResponsable
La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).
Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle
produce una dependencia funcional ya que: Responsable Departamento
Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave
candidata. Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala
seleccin de clave. La repeticin del par [IDDepartamento + IDResponsable] es innecesaria y
evitable.
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo
de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor):
088-51-0074
31850
1078
088-51-0074
37921
1293
096-77-4146
46224
1480
072-21-2223
31850
Pag. 107
Base de Datos I
Ingeniera de Sistemas
Otra Formulacin
Una forma sencilla de comprobar si una relacin se encuentra en FNBC consiste en comprobar,
adems de que est en 3FN, lo siguiente:
(1) Si no existen claves candidatas compuestas (con varios atributos), est en FNBC.
(2) Si existen varias claves candidatas compuestas y stas tienen un elemento comn, puede no
estar en FNBC. Slo si, para cada dependencia funcional en la relacin, el determinante es una
clave candidata, estar en FNBC.
Para entender mejor an esto consideremos una afinidad (tabla) llamada estudiante que contiene
los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:
Clave
Especialidad
Curso
S01
Sistemas
Natacin
S01
Bioqumica
Danza
S01
Sistemas
Natacin
B01
Bioqumica
Guitarra
C03
Civil
Natacin
Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El
estudiante con clave S01 tiene su especialidad en sistemas y Bioqumica y toma los cursos de
Pag. 108
Base de Datos I
Ingeniera de Sistemas
Especialidad y
Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores
mltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente
uno de los atributos de valores mltiples.
Para nuestro ejemplo, las tablas correspondientes son:
Tabla Especialidad
Clave
Especialidad
S01
Tabla Curso
Clave
Curso
Sistemas
S01
Natacin
B01
Bioqumica
S01
Danza
C03
Civil
B01
Guitarra
C03
Natacin
Pag. 109
Base de Datos I
Ingeniera de Sistemas
Persona rica
DNI Persona rica
123
Millonario excntrico
124,543,621
456
Multimillonario malvado
6,553,228,893
789
012
Millonario malvado
495,565,211
Asuma que el dominio para la 'DNI Persona rica consiste en los DNI's de toda la gente rica en una
muestra predefinida de gente rica; el dominio para el Tipo de persona rica consiste de los valores
'Millonario excntrico', 'Multimillonario excntrico', 'Millonario malvado', y 'Multimillonario
Pag. 110
Base de Datos I
Ingeniera de Sistemas
malvado'; y el dominio para el Valor neto en dlares consiste de todos los nmeros enteros mayor
que o igual a 1.000.000.
Hay una restriccin que liga el Tipo de persona rica al Valor neto en dlares, incluso aunque no
podamos deducir uno del otro. La restriccin dicta que un Millonario excntrico o Millonario
malvado tendr un valor neto de 1.000.000 a 999.999.999 inclusive, mientras que un Multimillonario
excntrico o un Multimillonario malvado tendr un valor neto de 1.000.000.000 o ms. Esta restriccin
no es ni una restriccin de dominio ni una restriccin de clave; por lo tanto no podemos confiar en
las restricciones de dominio y las de clave para garantizar que una combinacin de anmala
de Tipo de persona rica / Valor neto en dlares no tenga cabida en la base de datos.
La violacin de la DKNF podra ser eliminada alterando dominio Tipo de persona rica para hacer
que sea consistente con solo dos valores, 'Malvado' y 'Excntrico' (el estatus de persona rica como
un millonario o un multimillonario es implcito en su Valor neto en dlares, as que no se pierde
ninguna informacin til).
DKNF es frecuentemente difcil de alcanzar en la prctica.
las
bases
de
datos
relacionales
que
guardan
hechos
multi-valores
aislando semnticamente relaciones mltiples relacionadas. Una tabla se dice que est en 5NF si y
slo si est en 4NF y cada dependencia de unin (join) en ella es implicada por las claves
candidatas.
Ejemplo:
Considere el siguiente ejemplo:
Psiquiatra-para-Asegurador-para-Condicin
Psiquiatra
Asegurador
Condicin
Dr. James
Healthco
Ansiedad
Dr. James
Healthco
Depresin
Dr. Kendrick
FriendlyCare
OCD
Dr. Kendrick
FriendlyCare
Ansiedad
Pag. 111
Base de Datos I
Ingeniera de Sistemas
Dr. Kendrick
FriendlyCare
Depresin
Esquizofrenia
Ansiedad
Demencia
El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condicin
dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja
las combinaciones vlidas posibles de psiquiatra, asegurador, y condicin, la tabla de tres
atributos Psiquiatra-para-Asegurador-para-Condicin es
necesaria
para
modelar
la
situacin
correctamente.
Sin embargo, suponga que la regla siguiente se aplica:
Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados
por el asegurador P, y el psiquiatra puede tratar la condicin C, entonces - en caso que el asegurador
P cubra la condicin C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a
los pacientes que sufren de la condicin C y estn asegurados por el asegurador P.
Con estas restricciones es posible dividir la relacin en tres partes.
Psiquiatra-para-Condicin
Psiquiatra
Condicin
Dr. James
Ansiedad
Dr. James
Depresin
Dr. Kendrick
OCD
Dr. Kendrick
Ansiedad
Dr. Kendrick
Depresin
Psiquiatra-para-Asegurador
Psiquiatra
Asegurador
Dr. James
Healthco
Dr. Kendrick
FriendlyCare
Pag. 112
Base de Datos I
Ingeniera de Sistemas
Asegurador-para-Condicin
Asegurador
Condicin
Healthco
Ansiedad
Healthco
Depresin
Healthco
Demencia
FriendlyCare
OCD
FriendlyCare
Ansiedad
FriendlyCare
Depresin
FriendlyCare
Trastorno emocional
FriendlyCare
Esquizofrenia
Note como esta disposicin ayuda a quitar redundancia. Suponga que el Dr. James se convierte en
un proveedor de tratamientos para FriendlyCare. En la disposicin anterior tendramos que
agregar dos nuevas entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por
FriendlyCare: ansiedad y depresin. Con la nueva disposicin necesitamos agregar una sola
entrada (en la tabla Psiquiatra-para-Asegurador).
Uso
Solamente en contadas ocasiones una tabla 4NF no se corresponde con una 5NF. stas son
situaciones en las cuales una restriccin compleja del mundo real, que limita las combinaciones
vlidas de los valores de atributos en la tabla 4NF, no est implcita en la estructura de esa tabla. Si
esa tabla no se normaliza a 5NF, la tarea de mantener la consistencia lgica de los datos dentro de
la tabla debe ser llevada en parte por la aplicacin responsable de inserciones, borrados, y
actualizaciones a ella; y hay un riesgo elevado de que los datos dentro de la tabla se vuelvan
inconsistentes. Por el contrario, el diseo 5NF excluye la posibilidad de tales inconsistencias.
Pag. 113
Base de Datos I
Ingeniera de Sistemas
Desnormalizacin
Hasta dnde hay que llegar? Es necesario llegar a quinta forma normal?
La principal ventaja de la normalizacin es que divide una gran tabla en tablas ms pequeas:
Pasamos de una tabla de 100 campos a 20 tablas de 5 campos cada una. Pero esto a la vez puede
generar un problema: La excesiva particin de las tablas y la aparicin de numerosas tablas que
dificulten el uso de la base de datos
Por eso nace el concepto de desnormalizacin: Volver atrs, asumiendo que nuestra solucin
puede generar redundancia, pero facilitando el uso de la base de datos.
A la hora de disear una base de datos es tan importante la normalizacin de la misma como la
facilidad de uso: Si una excesiva normalizacin complica la compresin y el uso de la base de
datos, es mejor dejarla en una forma normal anterior.
Pag. 114