L14-Normalización

Materia: Base de Datos I

Profesor: Calixto Maldonado- 1 -

Normalización

La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Las ventajas de la normalización son las siguientes:

• Evita anomalías en inserciones, modificaciones y borrados. • Mejora la independencia de datos. • No establece restricciones artificiales en la estructura de los datos.

En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la relación se debe descomponer en varias relaciones que sí la cumplan.

La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma normal. Las restantes formas normales son opcionales. Sin embargo, es recomendable llegar al menos a la tercera forma normal, un modelo de tablas que cumple con la tercera forma normal se lo denomina como “Normalizado”.

Primera forma normal (1FN)

Una relación está en primera forma normal si y sólo si, todos los dominios de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la intersección de cada fila con cada columna.

Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas redundancias se eliminarán después mediante las restantes formas normales. La segunda forma de eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte, heredando la clave primaria de la relación en la que se encontraban.

Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos.

Segunda forma normal (2FN)

Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no está en la clave primaria es dependiente de la clave primaria completa.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones.



Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva relación con una copia de su determinante (los atributos de la clave primaria de los que dependen).

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada atributo que no está en la clave primaria no depende transitivamente de la clave primaria. La dependencia es transitiva si existen las dependencias A � B, siendo A y B, atributos o conjuntos de atributos de una misma relación.

Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en una nueva relación con una copia de su determinante (el atributo o atributos no clave de los que dependen).

Forma normal de Boyce-Codd (BCFN)

Una relación está en la forma normal de Boyce-Codd si, y sólo si, todo determinante es una clave candidata.

La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en 3FN.

La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relación viola la BCFN si tiene dos o más claves candidatas compuestas que tienen al menos un atributo en común

Ampliando con Ejemplos en cada una de las Formas No rmales

Según la definición de Date de la 1FN, una tabla está en 1FN “si y solo si” es "isomorfa” a alguna relación", lo que significa, específicamente, 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 intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada más). 5. Todas las columnas son regulares (es decir, las filas no tienen componentes como IDs de fila, IDs de objeto, o timestamps ocultos). (date,1998)

La violación de cualquiera de estas condiciones significaría que la tabla no es estrictamente relacional, y por lo tanto no está en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisface esta definición de 1FN son:



• Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición 3.

• Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Esto viola la condición Nro. 1. Las tuplas en relaciones verdaderas no están 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 estaría en violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe ser observado que este aspecto de la condición 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, según el modelo original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.

2. Grupos repetidos

La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como la característica que define la 1FN", concierne a grupos repetidos. El siguiente ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupos, en violación de la 1NF.

2. 1. Ejemplo 1: Dominios y valores

Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente ID Cliente Nombre Apellido Teléfono

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100

789 Maria Fernández 555-808-9633

Figura 1 Tabla cliente

En este punto, el diseñador se da cuenta de un requisito para guardar múltiples números telefónicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado:

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no está en 1FN. La 1FN (y, para esa materia, el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna.



2. 2. Ejemplo 2: Grupos repetidos a través de colum nas

El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:

Cliente

ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3

123 Osvaldo Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100

789 María Fernández 555-808-9633

Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del número de teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas incluyen:

• Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué clientes tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de teléfono?".

• La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que es exactamente igual que el valor de su Teléfono 1.

• La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revés.

2. 3. Ejemplo 3: Repetición de grupos dentro de col umnas

El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos:

Cliente ID Cliente Nombre Apellido Teléfono 123 Rachel Ingram 555-861-2025 456 James Wright 555-403-1659, 555-776-4100 789 Maria Fernández 555-808-9633

Éste es el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar o un número de teléfono o una lista de números de teléfono o, de hecho, cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de números telefónicos así como números telefónicos



individuales. Con este diseño en la RDBMS, son también imposibles de definir significativas restricciones en números telefónicos.

2. 4. Un diseño conforme con 1FN

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente.

Cliente

Cliente ID Cliente Nombre Apellido 123 Rachel Ingram 456 James Wright 789 Maria Fernandez

Teléfono del cliente

ID Cliente Teléfono 123 555-861-2025

456 555-403-1659

456 555-776-4100

789 555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro.

3. Atomicidad

Algunas definiciones de 1NF, más notablemente la de E.F. Codd [codd,1970], hacen referencia al concepto de atomicidad. Codd indica que "se requiere que los valores sean atómicos con respecto al DBMS en los dominios en los que cada relación es definida". Codd define un valor atómico como uno que "no puede ser descompuesto en pedazos más pequeños por el DBMS (excepto ciertas funciones especiales)".

Hugh Darwen y Chris Date [Date, 1998] han sugerido que el concepto de Codd de un "valor atómico" es ambiguo, y que esta ambigüedad ha conducido a una extensa confusión sobre cómo debe ser entendida la 1NF. En particular, la noción de un "valor que no puede ser descompuesto" es problemática, pues parecería implicar que pocos, si algún, tipos de datos son atómicos:

• Una cadena de caracteres parecería no ser atómica, ya que el RDBMS típicamente proporciona operadores para descomponerla en subcadenas.

• Una fecha parecería no ser atómica, ya que el RDBMS proporciona típicamente operadores para descomponerla los componentes de día, mes, y año.

• Un número de punto fijo parecería no ser atómico, ya que el RDBMS proporciona típicamente operadores para descomponerlo en componentes de números enteros y fraccionarios.

4. Normalización más allá de la 1NF



Cualquier tabla que esté en la segunda forma normal (2NF) o más arriba, también está, por definición, en 1NF (cada forma normal tiene criterios más rigurosos que su precursor). Por una parte, una tabla que está en 1NF puede o no puede estar en 2NF; si está en 2NF, puede o no puede estar en 3NF, y así sucesivamente.

Las formas normales más arriba que la 1NF son pensadas para ocuparse de las situaciones en las que una tabla sufre de problemas de diseño que pueden comprometer la integridad de los datos dentro de ella. Por ejemplo, la tabla siguiente está en 1NF, pero no está en 2NF y por lo tanto es vulnerable a inconsistencias lógicas:

Dirección de correo del subscriptor ID del subscriptor Dirección de correo nombre del

subscriptor nombre del subscriptor

108 [email protected] Steve Wallace 252 [email protected] Carol Robertson 252 [email protected] Carol Hall 360 [email protected] Harriet Clark

Figura 2. Direcciones de correo del subscriptor

La clave primaria de la tabla es {ID del subscriptor, Dirección de correo}.

Si Carol Robertson cambia su apellido (Robertson) por el de matrimonio (Hall), el cambio debe ser aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una contradicción: la pregunta "cuál es nombre del cliente 252?" tiene dos respuestas que están en conflicto. La 2NF aborda este problema

La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2NF definida originalmente por E.F. Codd en 1971. Una tabla que está en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF 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.

En términos levemente más formales: una tabla 1NF está en 2NF si y sólo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto apropiado) de una clave candidata. (Un atributo no-principal es uno que no pertenece a ninguna clave candidata).

Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en más de un atributo), la tabla está automáticamente en 2NF.

1. Ejemplo

Considere una tabla describiendo las habilidades de los empleados:

Empleado (CP) Habilidad (CP) Lugar actual de trabajo



Jones Mecanografía 114 Main Street Jones Taquigrafía 114 Main Street Jones Tallado 114 Main Street Bravo Limpieza ligera 73 Industrial Way Ellis Alquimia 73 Industrial Way Ellis Malabarismo 73 Industrial Way

Figura 3. Habilidades de los empleados

La clave primaria de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente sólo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:

Ganadores del torneo Torneo Año Ganador Fecha de nacimiento del ganador

Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977 Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975 Cleveland Open 1999 Bob Albertson 28 de octubre de 1968 Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975 Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Figura 4. Tabla de Ganadores del Torneo

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3NF).

Una tabla o relación que tiene una clave primaria simple, está en 2FN, por no poder existir una dependencia parcial con parte de la clave, por que ésta tiene un solo atributo o columna.

Por lo que en tablas donde la clave primaria es compuesta es necesario realizar el análisis de que los atributos no clave dependan de toda la clave primaria compuesta.



La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si y sólo si las dos condiciones siguientes se mantienen:

• La tabla está en la segunda forma normal (2NF) • Ningún 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 → Z en la cual Z no es inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X → Z por virtud de X → Y y Y → Z.

"Nada excepto la clave"

Un memorable resumen de la definición de Codd de la 3NF, siendo paralelo al compromiso tradicional de dar evidencia verdadera en un tribunal de justicia, fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada más excepto la clave".Una variación común complementa esta definición con el juramento: "con la ayuda de Codd".

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.

Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterización" de la 3NF, y observa que con una ligera adaptación puede servir como definición ligeramente más fuerte de la forma normal de Boyce-Codd: "Cada atributo debe representar un hecho acerca de la clave, la clave entera, y nada excepto la clave". [5] La versión 3NF de la definición es más débil que la variación de BCNF de Date, pues el anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes en las claves. [Date, 1998].

2. Ejemplo

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975 Cleveland Open 1999 Bob Albertson 28 de octubre de 1968 Des Moines Masters

1999 Al Fredrickson 21 de julio de 1975

Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Figura 4. Tabla de Ganadores del Torneo



La clave primaria es {Torneo, Año}.

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.

Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Ganadores del torneo

Torneo Año Ganador

Indiana Invitational 1998 Al Fredrickson Cleveland Open 1999 Bob Albertson Des Moines Masters 1999 Al Fredrickson Indiana Invitational 1999 Chip Masterson

Información del jugador

Jugador Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 julio de 1975

Bob Albertson 28 septiembre de 1968

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.

3. Normalización más allá de la 3NF

La mayoría de las tablas 3NF están libres anomalías de actualización, inserción, y borrado. Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran, son afectadas por tales anomalías; éstas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales más altas 4NF o 5NF.

Ejemplo paso a paso

Digamos que queremos crear una tabla con la información de usuarios, y los datos a guardar son el nombre, la empresa, la dirección de la empresa y algún e-mail, o bien URL si las tienen. En principio se encuentra en una situación como la siguiente definiendo la estructura de una tabla como esta:



Normalización CERO

Usuarios

nombre empresa dirección _ empresa url1 url2

Joe ABC 1 Work Lane abc.com xyz.com

Jill XYZ 1 Job Street abc.com xyz.com

Tabla 1. Sin forma normal

Diríamos que la anterior tabla esta en nivel de Normalización Cero porque ninguna de nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y url2 ¿Qué haremos cuando en nuestra aplicación necesitemos una tercera url? ¿Quieres tener que añadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu código PHP? Se quiere crear un sistema funcional que pueda crecer y adaptarse fácilmente a los nuevos requisitos. Aplicaremos las reglas del Primer Nivel de Formalización-Normalización.

Primera Forma Normal (F/N)

1. Eliminar los grupos repetitivos de las tablas. 2. Crear una tabla separada por cada grupo de datos relacionados. 3. Identificar cada grupo de datos relacionados con una clave primaria.

Es notable que la tabla esta rompiendo la primera regla cuando repetimos los campos url1 y url2 ? ¿Y que pasa con la tercera regla, la clave primaria? Las columnas definidas no permiten identificar cada fila, porque ¿Qué pasaría si tuviéramos dos usuarios llamados Joe y queremos diferenciarlos? Para este problema se puede definir una clave artificial que se puede implementar en los motores de base de datos con un campo auto incrementable o con el uso de un objeto secuencia. Veamos como quedó la tabla:

Usuarios

userId Nombre empresa dirección _ empresa

url

1 Joe ABC 1 Work Lane abc.com

1 Joe ABC 1 Work Lane xyz.com

2 Jill XYZ 1 Job Street abc.com

2 Jill XYZ 1 Job Street xyz.com

Tabla 2. Primera forma normal

Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos solucionado el problema de la limitación del campo url. Pero sin embargo vemos otros problemas....Cada vez que introducimos un nuevo registro en la tabla usuarios , tenemos que duplicar el nombre de la empresa y del usuario. No sólo nuestra BD crecerá muchísimo, sino que será muy fácil que la BD



se corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos pues la segunda Forma Normal:

Segunda Forma Normal

1. Crear una tabla aparte con los datos repetitivos 2. Relacionar estas tablas mediante una clave externa.

Hemos separado el campo url en otra tabla, de forma que podemos añadir más en el futuro si tener que duplicar los demás datos. También vamos a usar nuestra clave primaria para relacionar estos campos:

Usuarios

userId nombre Empresa dirección _ empresa

1 Joe ABC 1 Work Lane

2 Jill XYZ 1 Job Street

Urls

urlid relUserId url

1 1 abc.com

2 2 xyz.com

3 1 abc.com

4 2 xyz.com

Tabla 3. Segunda forma normal

Hemos creado tablas separadas y la clave primaria en la tabla usuarios , userId, esta relacionada ahora con la clave foránea en la tabla urls , relUserId.

Se agrega una columna que numera las relaciones usuarios y url, llamada urlid que también puede implementarse con una secuencia. ¿Pero que ocurre cuando queremos añadir otro empleado a la empresa ABC? ¿O 200 empleados? Ahora tenemos el nombre de la empresa y su dirección duplicándose, otra situación que puede inducirnos a introducir errores en nuestros datos. Así que tendremos que aplicar el tercer nivel de F/N:

Tercer nivel de F/N.

1. Crear otra tabla y llevar a aquellos campos que no dependan de la clave.

Nuestro nombre de empresa y su dirección no tienen nada que ver con el campo userId, así que tienen que tener su propio empresaId:



Usuarios

userId Nombre relEmpresaId

1 Joe 1

2 Jill 2

Empresas

emprId empresa dirección _ empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

Urls

Urlid relUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Tabla 4. Tercera forma normal

Ahora tenemos la clave primaria emprId, en la tabla empresas, relacionada con la clave externa recEmpresaId en la tabla usuarios , y podemos añadir 200 usuarios mientras que sólo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicación ni corrupción de datos. Es normalmente aceptado que el tercer nivel de Forma Normal es suficiente. (Font, 2009)

RESUMEN

En la tabla siguiente se describe brevemente cada una de las reglas

Regla Descripción

Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.

Segunda Forma Normal (2FN) Asegura que todas las columnas que no son clave sean completamente dependientes de la clave primaria (PK).

Tercera Forma Normal (3FN)

Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son clave son dependientes de otras columnas que tampoco son clave.



Referencias Bibliográficas [codd,1970] [codd,1970] Comunications of ACM Vol. 13, Number 6 Pagina377 Junio 1970 Ver también www.seas.upenn.edu/~zives/03f/cis550/codd .pdf [Date, 1998] Date, Chris, Introducción a los Sistemas de Base de Datos. - DATE - Quinta y Septima - 1998 - addison-wesley - Mexico

[Font, 2009] Normalización de Bases de Datos y Técnicas de diseño ( Por Barry Wise)Traducido por. J.M.Font http://www.lawebdelprogramador.com/temas/tecdiseno.php - visitado en Septiembre 2009

[Grayson, 2002] Thomas H. Grayson - Diseño de bases de datos relacionales: principios básicos de diseño 23 de enero de 2002

[mysql, 2009] Normalización de bases de datos - http://www.mysql-hispano.org/page.php?id=16&pag=1 - Visitado Agosto 2009 [wap,2009] Wiki: Normalización de bases de datos - Enciclopedia para celulares http://wapedia.mobi/es/Normalizacion_de_bases_de_datos - Visitado Agosto 2009

L14-Normalización

Documents

Transcript of L14-Normalización