Formas Normales

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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).

Formas Normales

Documents

Transcript of Formas Normales