formas normales
TRANSCRIPT
-
Universidad ORT Uruguay
Facultad de Ingeniera
Licenciatura en Sistemas
Ctedra de Base de Datos
Formas Normales
David Gimnez 162027
Octubre 2012
-
David Gimnez 162027
Ctedra de Base de datos 2
NDICE
PREGUNTAS QUE INTENTA RESPONDER ESTE TRABAJO ..................................... 3 PREFACIO ............................................................................................................................... 4 PRIMERA FORMA NORMAL ............................................................................................ 10 SEGUNDA FORMA NORMAL ........................................................................................... 13 TERCERA FORMA NORMAL ............................................................................................ 16 FORMA NORMAL DE BOYCE-CODD ............................................................................. 18 CUARTA FORMA NORMAL .............................................................................................. 19 QUINTA FORMA NORMAL ............................................................................................... 22 CASO DE LA VIDA REAL: BASE DE DATOS DISTRIBUIDA DE DNS .................. 24 EPLOGO ............................................................................................................................... 25
-
David Gimnez 162027
Ctedra de Base de datos 3
PREGUNTAS QUE INTENTA RESPONDER ESTE TRABAJO
Como surgieron las Formas Normales?
Que son las formas normales?
Que beneficios brinda su aplicacin?
Cules son las formas normales?
Como aplicarlas?
Caso de estudio que permita el desarrollo del tema.
Caso de la vida real: Base de datos distribuida de DNS
-
David Gimnez 162027
Ctedra de Base de datos 4
PREFACIO
Como surgieron?
Desde el ingreso de la informtica en los procesos operaciones del gobierno y de las
empresas, se utilizaron bases de datos, aunque en diferentes formas, para el respaldo y
acceso posterior de la informacin.
Durante las dcadas de los 60s y 70s muchos proveedores generaron sistemas
generalizados de manejo de archivos, generando mucha diversidad en el campo, sin
estandarizacin aceptada. En este tiempo la mayora de las bases de datos se basan en un
modelo de red o una simple estructura de archivo plano.
Se toma como disciplina de estudio los manejadores de bases de datos, de forma de porder
lograr un estndar.
Todo esto cambi en el ao 1970 cuando Edgar Frank Codd (Cientfico informtico ingls 23
de agosto de 1923 - 18 de abril de 2003), investigador asociado de IBM, desarroll el
modelo relacional y public un artculo llamado: A Relational Model of data for Large Shared Banks.
El modelo relacional de Codd estaba basado en una teora de conjuntos matemticos que
serva para mltiples propsitos:
Abstraer la representacin de datos de su almacenaje fsico y manipularlos.
Minimizar la redundancia de datos, dividindolos en distintos grupos no duplicados
que pueden ser relacionados en un infinito nmero de formas para producir un
infinito nmero de representaciones.
Incrementar la consistencia de datos, por ejemplo si se cambia el nombre de un
cliente, este cambiara en todos los reportes que se hagan acerca de ese cliente,
porque esa parte es guardada en una sola parte pero genera varias vistas o
representaciones del dato.
Codd defini reglas matemticas que deban cumplir los datos dentro de una base de datos
relacional para que estos fueran confiables y seguros. A estas reglas se les denomina formas
normales. Siendo Codd quien defini las primeras 3 formas normales.
Con el modelo relacional de Codd las bases de datos relacionales cobraron mayor fuerza y
se desarrollaron varios manejadores, como es el caso de Larry Ellison quien desarrollo la
base de datos Oracle basndose en las ideas de Codd.
-
David Gimnez 162027
Ctedra de Base de datos 5
Que son las formas normales? Y que beneficios brinda su aplicacin?
Las FN son reglas matemticas que se basan en la teora de conjuntos que dan garanta de
que en las relaciones representadas no ocurren anomalas de actualizacin ni existe perdida
de informacin ni de dependencias entre los datos.
Son criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y
anomalas lgicas. Mientras sea ms alta la forma normal aplicable a una tabla, es menos
vulnerable a inconsistencias y anomalas.
Las formas normales proveen a los diseadores de bases de datos de lo siguiente:
Un marco formal para analizar los esquemas de relacin con base en sus calves y en
las dependencias funcionales entre sus atributos.
Una serie de pruebas que pueden efectuarse sobre esquemas de relacin
individuales de modo que la base de datos relacional pueda normalizarse hasta el
grado deseado.
La aplicacin de las formas normales no ayudan a:
Reducir valores redundantes en las tuplas. Esto es cuando el mismo dato aparece
almacenado en ms de un lugar en la base de datos.
Lo anterior ayuda a evitar problemas de actualizacin. Evitar modificar un dato en
una de sus ubicaciones pero no en la otra.
Lo que evita la generacin de valores contradictorios en las tuplas.
Evitar incoherencia de datos. Cuando esperamos cierta informacin dado un atributo
de la base de datos, pero encontramos otro tipo de informacin en ese atributo.
Reducir valores nulos en las tuplas.
Mejorar la semntica de los atributos.
Evitar reuniones de datos aditivas, es decir con datos no correspondientes o
errneos.
Evitar prdidas de datos en las reuniones de diferentes relaciones.
Es de significar que el mero uso de las formas normales no garantiza el mejor desempeo
de la base de datos. Deben considerarse otros factores, por lo que aunque siempre es
posible llevar una base de datos a una forma normal ms alta, no siempre puede ser
deseable, por razones de rendimiento por ejemplo.
-
David Gimnez 162027
Ctedra de Base de datos 6
Como aplicar las formas normales?
Las formas normales son aplicables a tablas individuales. A la forma normal ms alta
alcanzada por una tabla se le llama HNF: Highest Normal Form.
Una tabla satisface los requisitos de su HNF y de todas las formas normales inferiores.
Entonces se considera que una base de datos se encuentra en una forma normal N, si todas
sus tablas satisfacen los requisitos de esa esa forma normal N. Es decir la HNF de cada tabla
es igual o superior a N.
Para aplicar las formas normales NO es necesario comenzar por la 1ra, pasar a la 2da, luego
a la 3ra y as sucesivamente. En realidad un diseador de base de datos experimentado
podra realizar un primer diseo para una base de datos, cuya HNF sea desde el principio la
3NF o la 4ta o 5ta formal normal.
En el siguiente ejemplo y solo con fines didcticos nosotros plantearemos el caso de una
tabla que no se encuentra normalizada en ninguna medida y seguiremos un proceso
ordenado de normalizacin, haciendo pasar a la tabla por cada forma normal una a una.
Pero ser solo con fines demostrativos y no ser muestra de la forma normal de trabajo al
contrastar una base de datos con las formas normales.
Supongamos entonces el caso de una base de datos que desea guardar la informacin de
los tcnicos y los proyectos en los que trabajan.
Alguien sin experiencia en base de datos podra definir una tabla como la que sigue:
-
David Gimnez 162027
Ctedra de Base de datos 7
Caso de estudio:
Tecnico Cedula Telefono Universidad RUT
Universidad Habilidad
LugarDe
Residencia Equipo Proyecto CodProy Ao Supervisor AosDeExperiencia
Juan 1
Celular:
099-311-
2xx
Casa:
2400.2xxx
ORT
Uruguay 1 Redes Montevideo A X 1 2012 Carlos 10
Luis 2
Juega
bien al
futbol
UDELAR 2 Programacin Canelones A X 1 2012 Carlos 12
Andrs 3 2411.10xx Infraestructura Montevideo B Y 2 2011 Antonio 5
Carlos 1 No tiene 2 Base de Datos Montevideo C Z 3 2012 Antonio 3
Indicando adems que las personas que se encuentran en los primeros diez lugares son jefes, y el resto son empleado.
-
David Gimnez 162027
Ctedra de Base de datos 8
Este diseo presenta mltiples problemas:
Hay datos repetidos que pueden guardar inconsistencias. A quien le pertenece la
cdula 1? Son las misma persona?
Hay atributos que no almacenan ningn dato o permiten almacenar cualquier dato.
El encabezado "Telfono" llega a ser semnticamente difuso, puede representar un
nmero de telfono, una lista de nmeros de telfono, o de hecho cualquier cosa.
Una consulta como "Qu pares de Tcnicos comparten un nmero telefnico?" es
virtualmente imposible de formular.
Hay informacin que no es almacenada o distinguida por la relacin. Como quien es
jefe y quien es empleado.
Con este diseo es imposibles definir restricciones claras para los atributos.
-
David Gimnez 162027
Ctedra de Base de datos 9
Cules son las formas normales? Y como aplicarlas?
La primera forma normal habla bsicamente el concepto de relacin y su representacin. La
segunda y tercera forma normal se basan en las dependencias funcionales respecto de las
claves primarias, la forma normal de Boyce-Codd es una versin ms estricta de la 3FN que
incluye a las claves candidatas. La cuarta y quinta formal normales hablan de los join no
aditivos sin perdida y la conservacin de dependencias.
Edgar Frank Codd defini las tres primeras formas normales. Estas se pueden resumir
requiriendo que todos los atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto la clave".
Las cuarta y quinta formas normales se ocupan especficamente de la representacin de las
relaciones muchos a muchos y uno muchos entre los atributos.
-
David Gimnez 162027
Ctedra de Base de datos 10
PRIMERA FORMA NORMAL Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mnimo de criterios.
La tabla es una representacin fiel de una relacin.
La tabla est libre de "grupos repetitivos".
Las tablas como representaciones fiel de una relacin
Segn la definicin de Christopher Date (nacido en 1941) de la 1NF, una tabla est en 1FN
si y solo si es isomorfa a alguna relacin", lo que significa, especficamente, que satisface
las siguientes cinco condiciones:
1. No hay orden de arriba a abajo en las filas.
2. No hay orden de izquierda a derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila y columna contiene exactamente un valor del
dominio aplicable (y nada ms).
5. Todas las columnas son regulares (es decir, las filas no tienen componentes
como IDs de fila, como los nmeros en las filas de Excel).
La violacin de cualquiera de estas condiciones significara que la tabla no es estrictamente
relacional, y por lo tanto no est en 1FN. Algunos ejemplos de tablas que no satisfacen esta
definicin de 1FN son:
Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas duplicadas, en violacin de la condicin 3.
Una tabla cuya definicin exige que los resultados mantengan un orden particular, de modo que el orden de la fila sea un aspecto intrnseco y significativo de la misma. Esto viola la condicin 1. Las tuplas en relaciones verdaderas no estn ordenadas una con respecto de la otra.
Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estara en violacin de la condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe observarse que este aspecto de la condicin 4 es controvertido. Muchos autores consideran que una tabla est en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan stos para atributos (campos) que no sean clave.
Grupos repetidos
La cuarta condicin de Date, que expresa "lo que para la mayora se entiende como la
caracterstica que define la 1FN, concierne a grupos repetidos. En el ejemplo mencionado
-
David Gimnez 162027
Ctedra de Base de datos 11
se muestra la repeticin de grupos, en violacin de la 1NF. Para guardar mltiples nmeros
telefnicos para algunos tcnicos, la manera ms simple es permitir que el campo
"Telfono" contenga ms de un valor en cualquier registro dado.
Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio
de nmero telefnico (por ejemplo, el dominio de cadenas de 16 caracteres de longitud), la
representacin de arriba no est en 1FN.
La 1FN prohbe a un campo contener ms de un valor de su dominio de columna, por lo que
una primera aproximacin al problema podra ser como sigue.
Cdula Nombre Departamento Telfono1 Telfono2 Fecha
Nacimiento Concepto
1 Juan
Prez Finanzas
2900-11-
00 25-05-1981
Buen
empleado
2 Carlos
Gmez
2900-25-
15
1
Juan
Carlos
Perez
Produccin 2900-15-
02
240050-25
20-08-1978 No trabaja
bien
3 Luis Finansas 2925-11-
11
Buen tipo
21-07-
1987
Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por
lo tanto no se conforman con la definicin de la 1NF de Date. Incluso si se contempla la
posibilidad de columnas con valores nulos, el diseo no est en armona con el espritu de
1NF. Telfono 1 y Telfono 2, comparten exactamente el mismo dominio y exactamente el
mismo significado; el dividir del nmero de telfono en dos encabezados es artificial y causa
problemas lgicos. Estos problemas incluyen:
Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como "Qu empleados tienen el telfono X?" y "Qu empleados comparten un nmero de telfono?".
La imposibilidad de hacer cumplir la unicidad las relaciones Cliente-a-Telfono por medio del RDBMS. Al empleado 2 se le puede dar equivocadamente un valor para el Telfono 2 que es exactamente igual que el valor de su Telfono 1. Y eso que significara?.
Restringe la realidad en cuanto a la cantidad de telfono por empleados a dos. Si viene un empleado con cuatro nmeros de telfono, estamos obligados a guardar solamente dos y dejar los restantes sin guardar. Esto significa que el diseo de la base de datos est imponiendo restricciones al proceso del negocio, en vez de a la inversa como debe ser.
-
David Gimnez 162027
Ctedra de Base de datos 12
Atomicidad
Codd hace referencia al concepto de atomicidad. Indica que "se requiere que los valores
sean atmicos con respecto al DBMS en los dominios en los que cada relacin es definida.
Define un valor atmico como uno que "no puede ser descompuesto en pedazos ms
pequeos por el DBMS (excepto por ciertas funciones especiales).
Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atmico" es
ambiguo, y que esta ambigedad ha conducido a una extensa confusin sobre cmo debe
ser entendida la 1NF. En particular, la nocin de un "valor que no puede ser descompuesto"
es problemtica, pues parecera implicar que pocos, si algn, tipos de datos son atmicos:
Una cadena de caracteres parecera no ser atmica, ya que el RDBMS tpicamente proporciona operadores para descomponerla en subcadenas.
Una fecha parecera no ser atmica, ya que el RDBMS proporciona tpicamente operadores para descomponerla los componentes de da, mes, y ao.
Un nmero de punto fijo parecera no ser atmico, ya que el RDBMS proporciona tpicamente operadores para descomponerlo en componentes de nmeros enteros y fraccionarios.
Date sugiere que "la nocin de atomicidad no tiene ningn significado absoluto"; un valor
puede ser considerado atmico para algunos propsitos, pero puede ser considerado un
ensamblaje de elementos ms bsicos para otros propsitos.
La atomicidad debe ser considerara en base al concepto representado. En el ejemplo de los
nmeros de telfonos, la atomicidad estara dada porque cada campo contuviese un nico
nmero de telfono y no varios.
-
David Gimnez 162027
Ctedra de Base de datos 13
Un diseo conforme con 1FN
Un analista con poca experiencia podra sugerir una solucin como la siguiente: La cual se encuentra inequvocamente en 1 FN.
Cedula Cedula idTipoTelefono Cedula Cedula Tecnico Telefono TipoTelefono RUTUniversidad Habilidad idTipoTelefono Universidad LugarDeResidencia (Cedula-RUTUniversidad) (Cedula --> LugarDeResidencia ) (Cedula-Universidad)
Codigo Cedula CodProy CodProy Equipo Codigo Proyecto Ao CodProy Supervisor Experiencia
En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso, cada enlace Tcnico-a-Telfono aparece en su propio
registro.
TECNICOS TelefonosTecnico TiposTelefonos TecnicoUniversidades TecnicoHabilidad
Equipos TecnicoEquipoProyecto Proyectos ProyectoSupervisor
-
David Gimnez 162027
Ctedra de Base de datos 14
SEGUNDA FORMA NORMAL
La segunda forma normal se basa en el concepto de dependencia funcional.
Una tabla est en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la clave candidata, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella.
Aqu debemos entender claramente el concepto de dependencia funcional. X -> Y. esto indica que un atributo o conjunto de atributos X definen a un atributo o conjunto de atributos Y. El reciproco no tiene por qu ser verdadero, es mas es probable que no lo sea (Y -> X). Entindase que la dependencia es en base a la semntica de la realidad representada, aunque tambin pueden inferirse dependencias funcionales que no son semnticamente obvias.
En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave candidata. Entindase atributo no-principal como uno que no pertenece a ninguna clave candidata.
Esto es: sea X:{x1, x2} e Y:{y1}. Entonces Si {x1, x2} -> {y1} para que la tabla este en 2da forma normal no puede darse que {x1} -> {y1} ni que {x2} -> {y1}. Es decir que si X es descompuesta Y deja de dependen funcionalmente de su valor.
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
En el ejemplo trabajado, en la tabla TecnicoHabilidad, el campo LugarDeResidencia presenta varios problemas:
Si un tcnico posee ms de una habilidad el valor de lugar de residencia aparecera repetido y podra ser vulnerable a anomalas de actualizacin, dejando la posibilidad para que en un registro diga un lugar y en otro registro se contradiga con otro lugar.
Los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el lugar de residencia del tcnico X?".
Adems el dato lugar de residencia es lgicamente dependiente nicamente de la cdula del tcnico y no de la habilidad que posea, por lo que depende solamente de parte de la clave y no de toda la clave.
-
David Gimnez 162027
Ctedra de Base de datos 15
Un alternativa conforme a 2NF de este diseo representara la misma informacin en dos tablas:
Cedula Cedula Tecnico Habilidad LugarDeResidencia
Estas tablas estn en 2NF.
2NF y las claves candidatas
Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria est tpicamente, pero no siempre, en 2NF. Adems de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningn atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas.
Las mltiples claves candidatas ocurren en la siguiente tabla: (ejemplo de Wikipedia)
Modelos elctricos de cepillo de dientes
Fabricante Modelo Nombre completo del modelo Pas del fabricante
Forte X-Prime Forte X-Prime Italia
Forte Ultraclean Forte Ultraclean Italia
Dent-o-Fresh EZBrush Dent-o-Fresh EZBrush USA
Kobayashi ST-60 Kobayashi ST-60 Japn
Hoch Toothmaster Hoch Toothmaster Alemania
Hoch Contender Hoch Contender Alemania
TECNICOS TecnicoHabilidad
-
David Gimnez 162027
Ctedra de Base de datos 16
Aun si el diseador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no est en 2NF. {Fabricante, Modelo} es tambin una clave candidata, y Pas del fabricante es dependiente en un subconjunto apropiado de l: Fabricante.
-
David Gimnez 162027
Ctedra de Base de datos 17
TERCERA FORMA NORMAL La tercera forma normal (3NF) definida por Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se mantienen:
La tabla est en segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave
candidata.
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata.
Una dependencia transitiva es una dependencia funcional:
X Y e Y Z entonces X Z,
Aqu Z no es inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez depende de X.
Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo en 1982, es sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionales X A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A X es una superclave1 A es un atributo primario (es decir, A est contenido dentro de una clave candidata)
La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario").
"Nada excepto la clave"
Un resumen de la definicin de Codd de la 3NF, fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada ms excepto la clave".
1 Una superclave, es un atributo o conjunto de atributos de una relacin que nos permite identificar cada tupla que contiene la
relacin como nica. Una clave candidata de una relacin es una superclave C de la relacin que cumple que ningn
subconjunto de atributos propio de C es superclave. Es decir que no puede ser descompuesta en sus atributos o dejara de ser
clave, dejara de identificar a las tuplas de la relacin. Entonces una SuperClave siempre es clavecandidata, pero una clave
candidata no siempre es superclave.
En una relacin EMPLEADOS (CI, Credencial, nombre, apellido, telfono), algunas de las superclaves de la relacin seran los
siguientes subconjuntos de atributos: {CI, Credencial, nombre, apellido, telfono}, {CI, apellido}, {CI} y {Credencial}, pero
solo {CI} y {Credencial} son claves candidatas.
-
David Gimnez 162027
Ctedra de Base de datos 18
Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla est en 2NF; un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla est en 3NF.
Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
CodProy CodProy Proyecto Ao Supervisor
Experiencia
La nica clave candidata de ProyectoSupervisor es {CodProy, Ao}.
La violacin de la 3NF ocurre porque el atributo no primario Experiencia es dependiente transitivamente de {CodProy, Ao} va el atributo no primario Supervisor. El hecho de que la Experiencia del supervisor es funcionalmente dependiente en el Supervisor hace la tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes datos de experiencia en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
CodProy CodProy Supervisor Proyecto Ao Experiencia Supervisor
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.
Proyectos ProyectoSuperviso Supervisores
Proyectos ProyectoSupervisor
-
David Gimnez 162027
Ctedra de Base de datos 19
FORMA NORMAL DE BOYCE-CODD La Forma Normal de Boyce-Codd (o FNBC) es una versin ligeramente ms fuerte de tercera forma normal (3FN).
La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata.
En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ).
Se dice que una tabla est en FNBC si y solo 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
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo de tal tabla que no satisface FNBC es:
Cedula Cedula Tecnico RUTUniversidad
LugarDeResidencia Universidad El propsito de la tabla TecnicoUniversidad es mostrar a que Universidades asisti cada tcnico. Las claves candidatas de TecnicoUniversidades son (Cedula-RUTUniversidad), (Cedula-Universidad).
Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las claves candidatas.
Recordar que la 2NF prohbe dependencias funcionales parciales de atributos no-primarios en las claves candidatas, y la 3NF prohbe dependencias funcionales transitivas de atributos no-primarios en claves candidatas. Dado que la tabla de arriba carece de cualquier atributo no-primario, est en 2NF y 3NF.
La FNBC es ms rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidata.
La dependencia de RutUniversidad - Universidad es ese tipo de dependencia. Por consiguiente, la tabla de arriba no est en FNBC
TECNICOS TecnicoUniversidades
-
David Gimnez 162027
Ctedra de Base de datos 20
Cualquier tabla que sea insuficiente en satisfacer FNBC ser vulnerable a inconsistencias lgicas. En la tabla de arriba poda ser representada una combinacin inconsistente de RutUniversidad - Universidad.
En este caso, corregir el problema sera una simple cuestin de usar solo un esquema de identificacin para las universidades: o el RUT o el Nombre, pero no ambos.
Cedula Cedula RUT Tecnico RUT Universidad LugarDeResidencia
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, no est en FNBC.
En el ejemplo existen dos claves candidatas y ambas comparten el atributo Cedula, por lo tanto no est en FNBC.
TECNICOS TecnicoUniversidades Universidades
-
David Gimnez 162027
Ctedra de Base de datos 21
CUARTA FORMA NORMAL La cuarta forma normal (4NF) se asegura de que las dependencias multivaluadas independientes sean correctas y eficientemente representadas en un diseo de base de datos.
Una tabla est en 4NF si y solo si est en 3NF o en BCNF (cualquiera de ambas) y no posee dependencias multivaluadas no triviales.
Una tabla con una dependencia multivaluada es una donde la existencia de dos o ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.
Considere el siguiente ejemplo:
TECNICO EQUIPO PROYECTO 1 A X 2 A X 3 B Y 4 B Y 1 A Z 2 A Z
Cada fila indica que un Equipo de trabajo asignado a un proyecto determinado est integrado por determinados tcnicos.
Note que debido a que la tabla tiene una clave nica y ningn atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que los tcnicos asignados a un equipo de trabajo son independientes del proyecto asignado para ese equipo, hay redundancia en la tabla: por ejemplo, nos dicen dos veces que el equipo A trabaja sobre el proyecto X, y si el mismo equipo comienza a trabajar sobre el proyecto Z nos dir dos veces que los tcnicos 1 y 2 pertenecen a ese equipo, porque necesitaremos agregar mltiples registros, uno para cada una de los tcnicos integrantes del equipo.
En trminos formales, esto se describe como que Tcnico est teniendo una dependencia multivalor en Equipo.
Tcnicos
Equipos
Proyectos
-
David Gimnez 162027
Ctedra de Base de datos 22
Para satisfacer la 4NF, debemos poner los hechos sobre las integrantes de los equipos en una tabla diferente de los hechos sobre los proyectos sobre los que trabaja cada equipo:
Tecnico Equipo Equipo Proyecto 1 A A X 2 A B Y 3 B A Z 4 B
De hacer un join natural entre estas dos tablas, obtendramos la tabla de la que partimos sin
prdida de informacin y sin datos aditivos.
Notar que esta solucin depende fuertemente de la realidad a representar: Ya que si los componentes de los equipos variara por proyecto, la tabla original de las tres columnas satisfara la 4NF.
Aqu vemos un caso de lo mencionado al principio, como demostr Ronald Fagin siempre posible alcanzar la 4NF pero no siempre deseable.
Tcnicos Equipos Proyectos
-
David Gimnez 162027
Ctedra de Base de datos 23
QUINTA FORMA NORMAL
La quinta forma normal (5FN), tambin conocida como forma normal de proyeccin-unin (PJ/NF), es para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislados semnticamente.
Una tabla se dice que est en 5NF si y solo si est en 4NF y cada dependencia de unin (join) en ella es implicada por las claves candidatas.
Es difcil descubrir dependencias de reunin en bases de datos reales de cientos de tributos, es por eso que en la prctica real se les presta poca atencin.
Las dependencias de inclusin se definieron para formalizar las restricciones entes relaciones, como la de clave fornea.
Generalmente esta forma normal solo se encuentra al estudiar cuidadosamente las restricciones de la realidad.
Por ejemplo si tuviramos Proyectos, Componente y Proveedor, donde debe representarse que cada proyecto requiere de cierto componente, que es provisto por cierto proveedor. Con una relacin ternaria estara bien para representar esa realidad.
Proveedor Componente Proyecto Juan Chips A Juan Roms B Laura Chips B Carlos Roms C Carlos Roms B Laura Chips A
Pero si la realidad indicara que si un proveedor P suministra el componente C, y un Proyecto Y consume el componente C, y el proveedor P es quien suministra al Proyecto Y entonces lo
Proveedor
Componente
Proyecto
-
David Gimnez 162027
Ctedra de Base de datos 24
suministra del componente C. Entonces la realidad debera modelarse con tres tablas diferentes que permitan la reunin sin prdida de informacin.
ProveedorComponente Proveedor Componente
Juan Chips Juan Roms Laura Chips Carlos Roms
ProyectoComponente Proyecto Componente
A Chips B Chips B Roms C Roms
ProyectoProveedor Proyecto Proveedor
A Juan A Laura B Laura B Juan C Carlos
Proveedor
Componente
Proyecto
-
David Gimnez 162027
Ctedra de Base de datos 25
CASO DE LA VIDA REAL:
BASE DE DATOS DISTRIBUIDA DE DNS
DNS: Sistema de Nombres de Dominio. Es una base de datos distribuida, organizada de forma jerrquica cuya estructura se mantiene hasta hoy da casi idntica a como lo era cuando se cre.
Est basada en conjuntos de etiquetas agrupados bajo un nombre jerrquico en comn y almacenados mayoritaria mente en archivos de texto separados por cada dominio. Es decir que cada dominio (.com, .uy, .com.uy) mantendr su propia base de datos con la informacin de las maquinas que pertenecen a su dominio.
La estructura genrica de un registro en una base de datos DNS es la siguiente:
Registro {Nombre, TTL, Clase, Tipo, Valor}
Nombre: Hace referencia al nombre del registro DNS buscado. Ej: www.ort.edu.uy. Es un campo alfanumrico que no puede estar vaco.
TTL: Time to live: Tiempo de vida. Indica cuanto tiempo en segundos es guardado en cache la informacin contenida en el registro. Depender de cuan estable es el registro. Es un campo numrico.
Clase: Indica que informacin almacena el registro. Ej: IN Internet Information. Es un campo de texto que no puede estar vaco.
Tipo: Tipo de registro al que hace referencia la informacin almacenada. Ej: A: address direccin de un host; Mx: Mail Box direccin de servidores de correo, NS: Name Server, nombres de los servidores de dominio, etc. Este es un campo de texto que no puede estar vaco.
Valor: Puede ser un nmero, un nombre de dominio, una cadena de texto, u otro tipo de dato, dependiendo de la semntica que se encuentre en el campo Tipo.
Un ejemplo de una tabla del servidor de dominio de ort.edu.uy. podra ser como sigue:
NOMBRE TTL TIPO CLASE VALOR aulas 3600 A IN 200.33.21.50
ort.edu.uy. 3600 NS IN ns1.ort.edu.uy. www 86400 CNAME IN Aulas ns1 3600 A IN 200.33.21.14
Lab1 86400 TXT IN PC1 en
laboratorio 1 planta baja.
-
David Gimnez 162027
Ctedra de Base de datos 26
Evidentemente esta tabla no cumple ninguno de los requisitos planteados en ninguna de las formas normales. Ni siquiera de la primera forma normal, ya que el dominio del campo valor puede ser virtualmente cualquier cosa.
La pregunta es: Funciona mal el servicio de internet basado en DNS por no encontrase normalizadas sus tablas?
Una respuesta adecuada a tan subjetiva pregunta podra ser que el servicio cumple su cometido y nadie ha planteado de forma seria cambiarlo o ajustarlo.
Podra funcionar mejor si la base de datos de DNS fuera normalizada?
Bueno esa pregunta quedar abierta para discusin porque sin duda existen muchos ms aspectos a considerar que solamente la estructura lgica de los datos.
En definitiva hay que considerar que existen en produccin muchas bases de datos que no se apegan a los criterios de bases de datos normalizadas y que usamos da a da sin inconvenientes.
Por lo que las formas normales nos brinda un marco de correctitud y seguridad en cuanto a los datos contenidos en nuestras bases de datos, pero no son requisitos esenciales para su funcionamiento.
Sin embargo tambin deberamos mencionar que al trabajar sobre una base de datos que no se apegue a los requisitos de formalidad que dan las formas normales, debemos tener mayores consideraciones y seguramente ms hora de programacin sobre los software que interacten con esas bases para asegurar la correctitud de los datos.
-
David Gimnez 162027
Ctedra de Base de datos 27
EPLOGO
Las formas normales son una herramienta formal para el diseo y estructuracin de las bases de datos relacionales.
No es necesaria su aplicacin para que una base de datos funcione. Pero si es una forma de lograr seguridad en los datos, que de otra manera deberan ser garantizadas por la programacin de las reglas del negocio en el sistema desarrollado sobre la base de datos.
El analista de datos no debera pasar por alto las formas normales y las reglas de normalizacin al momento de brindar una solucin de base de datos ante una realidad planteada, de forma de tener ciertas garantas de eficiencia y seguridad en los datos a almacenar.
Quedar a discrecin de cada diseador y sus necesidades, el grado de aplicacin de las formas normales, para llevar sus relaciones a las formas normales ms altas.
-
David Gimnez 162027
Ctedra de Base de datos 28
BIBLIOGRAFA
Sistemas de Bases de Datos Conceptos Fundamentales Elmasri / Navathe. 2da Edicin.
Wikipedia: Formas Normales.
Documentos publicados por la ctedra de Redes de Datos de la Facultad de Ingeniera de la Universidad ORT (esto en lo que refiere al anlisis de DNS).