C.B.T.I.S 243

CATEDRATICO:

LIC. ALBERTO CORNELIO PEREZ MENDEZ

ALUMNO:

JUAN DANIEL VELAZQUEZ PEREZ

TRABAJO:

INVESTIGACION

TEMA:

3 FORMAS NORMALES

SEMESTRE Y GRUPO:

5 A

ESPECIALIDAD:

OFIMATICA

MATERIA:

MODULO II

FECHA DE ENTREGA:

23 DE SEPTIEMBRE DEL 2015.

MOTOZINTLA DE MENDOZA, CHIAPAS.

En esta investigacin conoceremos lo que son las 3 formas normales para aplicar

en un diseo de BD.

Donde le daremos a demostrar los importantes principios tratados, tomaremos el

clsico ejemplo De una Factura y la llevaremos hasta la Tercera Forma Normal.

Tambin Construiremos, por el camino, un Modelo Entidad - Relacin de la Base

de Datos (BD). Ya que esta informacin nos ayudar a poder descubrir bien las

formas que existen con debido a un diseo de base de datos.

PRIMERA FORMA NORMAL

La primera forma normal (1FN o forma mnima) es una forma normal usada

en normalizacin de bases de datos. Una tabla de base de datos relacional que se

adhiere a la 1FN es una que satisface cierto conjunto mnimo de criterios. Estos

criterios se refieren bsicamente a asegurarse que la tabla es una representacin

fiel de una relacin1 y est libre de "grupos repetitivos".

Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras

por diferentes tericos. Como consecuencia, no hay un acuerdo universal en cuanto

a qu caractersticas descalificaran a una tabla de estar en 1FN. Muy notablemente,

la 1FN, tal y como es definida por algunos autores excluye "atributos relacin-valor"

(tablas dentro de tablas) siguiendo el precedente establecido por (E.F. Codd)

(algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe). Por otro

lado, segn lo definido por otros autores, la 1FN s los permite (por ejemplo como la

define Chris Date).

Las tablas 1FN como representaciones de relaciones

Segn la definicin de Date de la 1FN, 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, IDs de objeto, o timestamps ocultos].

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 (o de vistas) 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 vista cuya definicin exige que los resultados sean retornados en un

orden particular, de modo que el orden de la fila sea un aspecto intrnseco y

significativo de la vista. 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, segn el modelo original

de Codd sobre el modelo relacional, el cual hizo disposicin explcita para los

nulos.

Grupos repetidos

La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa

como la caracterstica que define la 1FN", concierne a grupos repetidos. El siguiente

ejemplo ilustra cmo un diseo de base de datos puede incorporar la repeticin de

grupos, en violacin de la 1FN.

Ejemplo 1: Dominios y valores

Suponga que un diseador principiante desea guardar los nombres y los nmeros

telefnicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente

ID Cliente Nombre Apellido Telfono

123 Rachel ingre 555-861-2025

456 James Wright 555-403-1659

789 Cesar Dure 555-808-9633

En este punto, el diseador se da cuenta que un requerimiento es

guardar mltiples nmeros telefnicos para algunos clientes. Razona que la manera

ms simple de hacer esto es permitir que el campo "Telfono" contenga ms de un

valor en cualquier registro dado:

Cliente

ID Cliente Nombre Apellido Telfono

123 Rachel Ingre 555-861-2025

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

789 Cesar Dure 555-808-9633

Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de

dominio de nmero telefnico (por ejemplo, el dominio de cadenas de 12 caracteres

de longitud), la representacin de arriba no est en 1FN. La 1FN (y, para esa

materia, el RDBMS) prohbe a un campo contener ms de un valor de su dominio

de columna.

Ejemplo 2: Grupos repetidos a travs de columnas

El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero

telefnico:

Cliente

ID Cliente Nombre Apellido Telfono 1 Telfono 2 Telfono 3

123 Rachel ingre 555-861-2025

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

789 Cesar Dure 555-808-9633

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, Telfono 2, y Telfono 3, comparten

exactamente el mismo dominio y exactamente el mismo significado; dividir los

nmeros de telfono en tres encabezados es artificial y causa problemas lgicos.

Estos problemas incluyen:

Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales

como "Qu clientes tienen el telfono X?" y "Qu pares de clientes

comparten un nmero de telfono?".

La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono

por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un

valor para el Telfono 2 que es exactamente igual que el valor de su Telfono

1.

La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente

con cuatro nmeros de telfono, estamos obligados a guardar solamente tres

y dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos

est imponiendo restricciones al proceso del negocio, en vez de (como

idealmente debe ser el caso) al revs.

Ejemplo 3: Repeticin de grupos dentro de columnas

El diseador puede, alternativamente, conservar una sola columna de nmero de

telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud

para acomodar mltiples nmeros telefnicos:

Cliente

ID Cliente Nombre Apellido Telfono

123 Rachel ingre 555-861-2025

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

789 Cesar Dure 555-808-9633

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu

de la 1NF. El encabezado "Telfono" llega a ser semnticamente difuso, ya que

ahora puede representar, o un nmero de telfono, o una lista de nmeros de

telfono, o de hecho cualquier cosa. Una consulta como "Qu pares de clientes

comparten un nmero telefnico?" es virtualmente imposible de formular, dada la

necesidad de proveerse de listas de nmeros telefnicos as como nmeros

telefnicos individuales. Con este diseo en la RDBMS, son tambin imposibles de

definir significativas restricciones en nmeros telefnicos.

Un diseo con 1FN

Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de

cliente y una tabla de telfono del cliente.

Cliente

ID Cliente Nombre Apellido

123 Rachel ingre

456 James Wright

789 Cesar Dure

Telfono del cliente

ID Cliente Telfono

123 555-861-2025

456 555-403-1659

456 555-776-4100

789 555-808-9633

En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de

eso, cada enlace Cliente-a-Telfono aparece en su propio registro. Es valioso notar

que este diseo cumple los requerimientos adicionales para la segunda (2NF) y la

tercera forma normal (3FN).

Atomicidad

Algunas definiciones de 1NF, ms notablemente la de E.F. Codd, hacen referencia

al concepto de atomicidad. Codd indica que "se requiere que los valores sean

atmicos con respecto al DBMS en los dominios en los que cada relacin es

definida". Codd define un valor atmico como uno que "no puede ser descompuesto

en pedazos ms pequeos por el DBMS (excepto ciertas funciones especiales)".

[Hugh Darwin] 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.10 11 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 sus cadenas.

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

esta posicin es aceptada, la 1NF no puede ser definida con referencia a la

atomicidad. Las columnas de cualquier tipo de datos concebible (desde tipos de

cadenas y tipos numricos hasta tipos de arreglos y tipos de tabla) son entonces

aceptables en una tabla 1NF - aunque quizs no siempre deseable. Date discute

que los atributos relacin-valor, por medio de los cuales un campo dentro de una

tabla puede contener una tabla, son tiles en casos raros.

Normalizacin ms all de la 1NF

Cualquier tabla que est en la segunda forma normal (2NF) o ms arriba, tambin

est, por definicin, en 1NF (cada forma normal tiene criterios ms 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 ms arriba que la 1NF son pensadas para ocuparse de las

situaciones en las que una tabla sufre de problemas de diseo 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

lgicas:

Direccin de correo del subscriptor

ID del subscriptor

Direccin de correo Primer nombre del subscriptor

Apellido del subscriptor

108 steve@aardvarkmail.net Steve Wallace

252 carol@mongoosemail.org Carol Robertson

252 crobertson@aardvarkmail.net Carol Robertson

360 hclark@antelopemail.com Harriet Clark

La clave de la tabla es {ID del subscriptor, Direccin de correo}.

Si Carol Robertson cambia su apellido por el de matrimonio, el cambio debe ser

aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una

contradiccin: la pregunta "cul es nombre del cliente 252?" tiene dos respuestas

que estn en conflicto. La 2NF aborda este problema.

SEGUNDA FORMA NORMAL

La segunda forma normal (2NF) es una forma normal usada en normalizacin de

bases de datos. La 2NF fue definida originalmente por E.F. Codd en 1971. Una tabla

que est en la primera (1NF) debe satisfacer criterios adicionales para calificar para

la segunda forma normal. Especficamente: una tabla 1NF est en 2NF si y solo si,

dada una clave primaria y cualquier atributo que no sea un constituyente de la clave

primaria, el atributo no clave depende de toda la clave primaria en vez de solo de

una parte de ella.

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 primaria (Un atributo no-principal es uno que no

pertenece a ninguna clave primaria).

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.

Ejemplo

Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados

Empleado Habilidad Lugar actual de trabajo

Jones Mecanografa 114 Main Street

Jones Taquigrafa 114 Main Street

Jones Tallado 114 Main Street

Bravo Limpieza ligera 73 Industrial Way

Ellis Alquimia 73 Industrial Way

Ellis Malabarismo 73 Industrial Way

Harrison Limpieza ligera 73 Industrial Way

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

El atributo restante, Lugar actual de trabajo, es dependiente solo 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 anomalas de actualizacin: por ejemplo, es posible actualizar el lugar del trabajo

de Jones en sus registros "Mecanografa" y "Taquigrafa" y no actualizar su registro

"Tallado". Los datos resultantes implicaran respuestas contradictorias a la pregunta

"Cul es el lugar actual de trabajo de Jones?".

Un alternativa 2NF a este diseo representara la misma informacin en dos tablas:

Empleados

Empleado Lugar actual de trabajo

Jones 114 Main Street

Bravo 73 Industrial Way

Ellis 73 Industrial Way

Harrison 73 Industrial Way

Habilidades de los empleados

Empleado Habilidad

Jones Mecanografa

Jones Taquigrafa

Jones Tallado

Bravo Limpieza ligera

Ellis Alquimia

Ellis Malabarismo

Harrison Limpieza ligera

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales

estn en 2NF.

Sin embargo, no todas las tablas 2NF estn libres de anomalas de

actualizacin. Un ejemplo de una tabla 2NF que sufre de anomalas de

actualizacin es:

Ganadores del torneo

Torneo Ao 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 septiembre de 1968

Des Moines Masters

1999 Al Fredrickson 21 de julio de 1975

Indiana Invitational 1999 Chip Master son

14 de marzo de 1977

Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas

por una clave completa {Torneo, Ao} y no son partes de ella, particularmente

las combinaciones Ganador /Fecha de nacimiento del ganador son mostradas

redundantemente en mltiples registros. Este problema es tratado por la tercera

forma normal (3NF).

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:

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

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.

TERCERA FORMA NORMAL

La tercera forma normal (3NF) es una forma normal usada en la normalizacin de

bases de datos. La 3NF fue definida originalmente por E.F. Codd1 en 1971. La

definicin de Codd indica que una tabla est en 3NF si y solo si las tres condiciones

siguientes se cumplen:

La tabla est en la segunda forma normal (2NF)

Ningn atributo no-primario de la tabla es dependiente transitivamente de

una clave primaria

Es una relacin que no incluye ningn atributo clave

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 e Y Z.

Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo2 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 superclase,

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 memorable resumen de la definicin 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 ms excepto la clave. Una variacin comn

complementa esta definicin 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 caracterizacin"

de la 3NF, y observa que con una ligera adaptacin puede servir como definicin

ligeramente ms 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". La versin 3NF de la definicin es ms dbil que la variacin de BCNF de

Date, pues el anterior se refiere solamente a asegurarse de que los atributos no-

clave son dependientes en las claves. Los atributos primarios (que son claves o

partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno

de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o

toda la clave en s misma. Debe ser observado que esta regla se aplica solamente

a los atributos funcionalmente dependientes, ya que aplicndola a todos los

atributos prohibira implcitamente claves de candidato compuestas, puesto que

cada parte de cualquiera de tales claves violara la clusula de "clave completa"..

Ejemplo

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

es:

Ganadores del torneo

Torneo Ao Ganador Fecha de nacimiento del ganador

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968

Des Moines Masters

1999 Al Fredrickson 21 de julio de 1975

Indiana Invitational 1999 Chip Masterson

14 de marzo de 1977

La nica clave candidata es {Torneo, Ao}.

La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento

del ganador es dependiente transitivamente de {Torneo, Ao} va 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 lgicas, 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 Ao Ganador

Indiana Invitational 1998 Al Fredrickson

Cleveland Open 1999 Bob Albertson

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational 1999 Chip Masterson

Fecha de nacimiento del jugador

Ganador Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 de julio de 1975

Bob Albertson 28 de septiembre de 1968

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales

estn en 3NF.

Derivacin de las condiciones de Zaniolo

La definicin de 3NF ofrecida por Carlo Zaniolo en 1982, y dada arriba, es

probada as: Sea X A un FD no trivial (es decir, uno donde X no contiene a

A) y sea A un atributo no clave. Tambin sea Y una clave de R. Entonces Y

X. Por lo tanto A no es dependiente transitivo de Y, si y solo si el X Y, es decir,

si y solo si X es una superclase.

Normalizacin ms all de la 3NF

La mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin,

y borrado. Ciertos tipos de tablas 3NF, que en la prctica raramente se

encuentran, son afectadas por tales anomalas; 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 ms altas 4NF o 5NF.

Con esta investigacin he conocido las tres formas normales para aplicar a un

diseo de base de datos. Ya que con esta informacin lo podre utilizar en una

carrera que nosotros emprenderemos, pero esta investigacin ha sido muy

importante porque vemos algunos ejemplos para aplicar a una base de datos y pues

no servir mucho.

Finalmente si tomamos en cuenta las tablas de con su respectivo detalle ya sea de

venta o cualquier otro detalle puede contener un volumen de millones de registros,

al haberle aplicado las 3 formas normales donde nos estaremos ahorrando varios

formas de tamao en dicha tabla y por supuesto mejorado notablemente la

performance y el diseo en el que se encuentra nuestra tabla en las 3 formas

normales. Esperando que esta investigacin lo podamos servir en la especialidad

que llevemos.

https://es.wikipedia.org/wiki/Primera_forma_normal

https://es.wikipedia.org/wiki/Segunda_forma_normal

https://es.wikipedia.org/wiki/Tercera_forma_normal