Академический Документы
Профессиональный Документы
Культура Документы
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.
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.
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.
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.
Cliente
ID Cliente Nombre Apellido 123 456 789 Rachel James Cesar Ingram Wright Dure
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]
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)
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
Licencia
Creative Commons Attribution-Share Alike 3.0 //creativecommons.org/licenses/by-sa/3.0/