Вы находитесь на странице: 1из 7

Primera forma normal

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 relacin[1] y est libre de "grupos repetitivos".[2] 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[3]). 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]. Chris Date, "What First Normal Form Really Means", pp. 127-8[4] La violacin de cualesquiera 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.[5] 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.[6]

Primera forma normal

Grupos repetidos
La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la caracterstica que define la 1FN",[7] 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 123 456 789 Rachel James Cesar Ingram Wright Dure Telfono 555-861-2025 555-403-1659 555-808-9633

En este punto, el diseador se da cuenta de un requisito para guardar mltiples nmeros telfonicos 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 123 456 Rachel James Ingram Wright Telfono 555-861-2025 555-403-1659 555-776-4100 555-808-9633

789

Cesar

Dure

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 123 456 789 Rachel James Cesar Ingram Wright Dure Telfono 1 555-861-2025 555-403-1659 555-776-4100 555-808-9633 Telfono 2 Telfono 3

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; el dividir del nmero de telfono en tres encabezados es artificial y causa problemas lgicos. Estos problemas incluyen:

Primera forma normal 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 123 456 789 Rachel James Cesar Ingram Wright Dure Telfono 555-861-2025 555-403-1659, 555-776-4100 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 conforme 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 456 789 Rachel James Cesar Ingram Wright Dure

Primera forma normal

Telfono del cliente


ID Cliente 123 456 456 789 Telfono 555-861-2025 555-403-1659 555-776-4100 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".[8] Codd define un valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos por el DBMS (excepto ciertas funciones especiales)".[9] [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.[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 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":[12] 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 un 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.[13]

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:

Primera forma normal

Direccin de correo del subscriptor


ID del subscriptor 108 252 252 360 Direccin de correo steve@aardvarkmail.net carol@mongoosemail.org Primer nombre del subscriptor Apellido del subscriptor Steve Carol Wallace Robertson Robertson Clark

crobertson@aardvarkmail.net Carol hclark@antelopemail.com Harriet

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.

Notas y referencias
[1] "[T]he overriding requirement, to the effect that the table must directly and faithfully represent a relation, follows from the fact that 1NF was originally defined as a property of relations, not tables." Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 128. [2] "First normal form excludes variable repeating fields and groups." Kent, William. "A Simple Guide to Five Normal Forms in Relational Database Theory" (http:/ / www. bkent. net/ Doc/ simple5. htm), Communications of the ACM 26 (2), Feb. 1983, pp. 120-125. [3] Elmasri, Ramez and Navathe, Carlos C, Shamkant B. Fundamentals of Database Systems, Fourth Edition (Addison-Wesley, 2003), p. 315. [4] Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) pp. 127-128. [5] Such views cannot be created using SQL that conforms to the SQL:2003 standard. [6] The third of Codd's 12 rules states that "Null values... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type." Codd, E.F. "Is Your DBMS Really Relational?" Computerworld, October 14, 1985. [7] Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) p. 128. [8] Codd, E.F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). [9] Codd, E.F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6. [10] Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992). [11] "[F]or many years," writes Date, "I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations." Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 108 [12] Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) p. 112. [13] Date, C.J. "What First Normal Form Really Means" (http:/ / www. dbdebunk. com/ page/ page/ 629796. htm) pp. 121-126.

Lectura adicional
Litt's Tips: Normalization (http://www.troubleshooters.com/littstip/ltnorm.html) Rules Of Data Normalization (http://www.datamodel.org/NormalizationRules.html) Date, C. J., & Lorentzos, N., & Darwen, H. (2002). Temporal Data & the Relational Model (http://www. elsevier.com/wps/product/cws_home/680662) (1st ed.). Morgan Kaufmann. ISBN 1-55860-855-9. Date, C. J. (1999), An Introduction to Database Systems (http://www.aw-bc.com/catalog/academic/product/ 0,1144,0321197844,00.html) (8th ed.). Addison-Wesley Longman. ISBN 0-321-19784-4. Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory (http://www.bkent.net/ Doc/simple5.htm), Communications of the ACM, vol. 26, pp. 120-125 Date, C.J., & Darwen, H., & Pascal, F. Database Debunkings (http://www.dbdebunk.com)

Primera forma normal

Enlaces externos
Database Normalization Basics (http://databases.about.com/od/specificproducts/a/normalization.htm) by Mike Chapple (About.com) An Introduction to Database Normalization (http://dev.mysql.com/tech-resources/articles/ intro-to-normalization.html) by Mike Hillyer. Normalization (http://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.html) by ITS, University of Texas. Rules of Data Normalization (http://www.datamodel.org/NormalizationRules.html) by Data Model.org A tutorial on the first 3 normal forms (http://phlonx.com/resources/nf3/) by Fred Coulson Free PDF poster available (http://www.marcrettig.com/poster/) by Marc Rettig Description of the database normalization basics (http://support.microsoft.com/kb/283878) by Microsoft

Fuentes y contribuyentes del artculo

Fuentes y contribuyentes del artculo


Primera forma normal Fuente: http://es.wikipedia.org/w/index.php?oldid=69898068 Contribuyentes: Carmin, Diegusjaimes, GermanX, HermanHn, Hprmedina, Humberto, Jkbw, Juvalen, Laura Fiorucci, Poxqo, Reyiyo, Rosarino, Savh, VictorAnyakin, Wikijandro, 53 ediciones annimas

Licencia
Creative Commons Attribution-Share Alike 3.0 //creativecommons.org/licenses/by-sa/3.0/

Вам также может понравиться