-
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 [email protected] Steve Wallace
252 [email protected] Carol Robertson
252 [email protected] Carol Robertson
360 [email protected] 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