First Normal Form

First normal form - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/First_normal_form
First normal form

From Wikipedia, the free encyclopedia
First normal form (1NF or Minimal Form) is a normal form used in database normalization. A relational database table that adheres to 1NF is one that meets a certain minimum set of criteria. These criteria are basically concerned with [1] and that it is ensuring that the table is a faithful representation of a relation [2] free of repeating groups. The concept of a "repeating group" is, however, understood in different ways by different theorists. As a consequence, there is no universal agreement as to which features would disqualify a table from being in 1NF. Most notably, 1NF as defined by some authors (for example, Ramez Elmasri and Shamkant B. [3] following the precedent established by Edgar F. Codd) excludes Navathe, relation-valued attributes (tables within tables); whereas 1NF as defined by other authors (for example, Chris Date) permits them.
Contents
1 1NF tables as representations of relations 2 Repeating groups 2.1 Domains and values 2.2 Repeating groups across columns 2.3 Repeating groups within columns 2.4 A design that complies with 1NF 3 4 5 6 7 8 Atomicity Normalization beyond 1NF See also References Further reading External links
1NF tables as representations of relations

According to Date's definition of 1NF, a table is in 1NF if and only if it is "isomorphic to some relation", which means, specifically, that it satisfies the following five conditions: 1. There's no top-to-bottom ordering to the rows. 2. There's no left-to-right ordering to the columns.
1 of 10
Monday 19 September 2011 09:39 AM
3. There are no duplicate rows. 4. Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else). 5. All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps]. Chris Date, "What First Normal Form Really Means", pp. 1278[4] Violation of any of these conditions would mean that the table is not strictly relational, and therefore that it is not in 1NF. Examples of tables (or views) that would not meet this definition of 1NF are: A table that lacks a unique key. Such a table would be able to accommodate duplicate rows, in violation of condition 3. A view whose definition mandates that results be returned in a particular order, so that the row-ordering is an intrinsic and meaningful [5] This violates condition 1. The tuples in true aspect of the view. relations are not ordered with respect to each other. A table with at least one nullable attribute. A nullable attribute would be in violation of condition 4, which requires every field to contain exactly one value from its column's domain. It should be noted, however, that this aspect of condition 4 is controversial. It marks an important [6] which made departure from Codd's later vision of the relational model, [7] explicit provision for nulls.
Repeating groups
Date's fourth condition, which expresses "what most people think of as the [8] is concerned with repeating groups. The following defining feature of 1NF", scenario illustrates how a database design might incorporate repeating groups, in violation of 1NF.
Domains and values

Suppose a novice designer wishes to record the names and telephone numbers of customers. He defines a customer table which looks like this:
2 of 10
Customer Customer ID First Name Surname Telephone Number 123 456 789 Robert Jane Maria Ingram Wright 555-861-2025 555-403-1659
Fernandez 555-808-9633
3 of 10
The designer then becomes aware of a requirement to record multiple telephone numbers for some customers. He reasons that the simplest way of doing this is to allow the "Telephone Number" field in any given record to contain more than one value: Customer Customer ID First Name Surname Telephone Number 123 456 789 Robert Jane Maria Ingram Wright 555-861-2025 555-403-1659 555-776-4100
Assuming, however, that the Telephone Number column is defined on some Telephone Number-like domain (e.g. the domain of strings 12 characters in length), the representation above is not in 1NF. 1NF (and, for that matter, the RDBMS) prevents a single field from containing more than one value from its column's domain.
Repeating groups across columns

The designer might attempt to get around this restriction by defining multiple Telephone Number columns: Customer Customer ID 123 456 789 First Name Robert Jane Maria Surname Ingram Wright Tel. No. 1 555-861-2025 555-403-1659 555-776-4100 555-403-1659 Tel. No. 2 Tel. No. 3
This representation, however, makes use of nullable columns, and therefore does not conform to Date's definition of 1NF (in violation to condition 4). Even if the view is taken that nullable columns are allowed, the design is not in keeping with the spirit of 1NF (in violation to condition 2). Tel. No. 1, Tel. No. 2., and Tel. No. 3. share exactly the same domain and exactly the same meaning; the splitting of Telephone Number into three headings is artificial and causes logical problems.
4 of 10
These problems include: Difficulty in querying the table. Answering such questions as "Which customers have telephone number X?" and "Which pairs of customers share a telephone number?" is awkward. Inability to enforce uniqueness of Customer-to-Telephone Number links through the RDBMS. Customer 789 might mistakenly be given a Tel. No. 2 value that is exactly the same as her Tel. No. 1 value. Restriction of the number of telephone numbers per customer to three. If a customer with four telephone numbers comes along, we are constrained to record only three and leave the fourth unrecorded. This means that the database design is imposing constraints on the business process, rather than (as should ideally be the case) vice-versa.
Repeating groups within columns

The designer might, alternatively, retain the single Telephone Number column but alter its domain, making it a string of sufficient length to accommodate multiple telephone numbers: Customer Customer ID First Name Surname 123 456 789 Robert Jane Maria Ingram Wright Telephone Numbers 555-861-2025 555-403-1659, 555-776-4100
This design is consistent with 1NF, but still presents several design issues. The Telephone Number heading becomes semantically non-specific, as it can now represent either a telephone number, a list of telephone numbers, or indeed anything at all. A query such as "Which pairs of customers share a telephone number?" is more difficult to formulate, given the necessity to cater for lists of telephone numbers as well as individual telephone numbers. Meaningful constraints on telephone numbers are also very difficult to define in the RDBMS with this design.
A design that complies with 1NF

A design that is unambiguously in 1NF makes use of two tables: a Customer Name table and a Customer Telephone Number table.
5 of 10
Customer Name Customer ID First Name Surname 123 456 789 Robert Jane Maria Ingram Wright Fernandez
Customer Telephone Number Customer ID Telephone Number 123 456 456 789 555-861-2025 555-403-1659 555-776-4100 555-808-9633
Repeating groups of telephone numbers do not occur in this design. Instead, each Customer-to-Telephone Number link appears on its own record. With Customer ID as key fields, a "parent-child" or one-to-many (1:M) relationship exists between the two tables, since a customer record (in the "parent" table, Customer Name) can have many telephone number records (in the "child" table, Customer Telephone Number), but each telephone number usually has one, and only one customer. In the case where several customers could share the same telephone number, an additional column is needed in the Customer Telephone Number table to represent a unique key. It is worth noting that this design meets the additional requirements for second and third normal form (3NF).
Atomicity
Some definitions of 1NF, most notably that of Edgar F. Codd, make reference to the concept of atomicity. Codd states that the "values in the domains on which [9] each relation is defined are required to be atomic with respect to the DBMS." Codd defines an atomic value as one that "cannot be decomposed into smaller [10] Meaning a field pieces by the DBMS (excluding certain special functions)." should not be divided into parts with more than one kind of data in it such that what one part means to the DBMS depends on another part of the same field. Hugh Darwen and Chris Date have suggested that Codd's concept of an "atomic value" is ambiguous, and that this ambiguity has led to widespread confusion [11][12] In particular, the notion of a "value about how 1NF should be understood. that cannot be decomposed" is problematic, as it would seem to imply that few, if any, data types are atomic: A character string would seem not to be atomic, as the RDBMS typically provides operators to decompose it into substrings. A fixed-point number would seem not to be atomic, as the RDBMS typically provides operators to decompose it into integer and fractional components. Date suggests that "the notion of atomicity has no absolute meaning":[13] a value
6 of 10 Monday 19 September 2011 09:39 AM
may be considered atomic for some purposes, but may be considered an assemblage of more basic elements for other purposes. If this position is accepted, 1NF cannot be dened with reference to atomicity. Columns of any conceivable data type (from string types and numeric types to array types and table types) are then acceptable in a 1NF tablealthough perhaps not always desirable (For example, it would be more desirable to separate a Customer Name eld into two separate elds as First Name, Surname). Date argues that relationvalued attributes, by means of which a eld within a table can contain a table, [14] are useful in rare cases.
Normalization beyond 1NF

Any table that is in second normal form (2NF) or higher is, by definition, also in 1NF (each normal form has more stringent criteria than its predecessor). On the other hand, a table that is in 1NF may or may not be in 2NF; if it is in 2NF, it may or may not be in 3NF, and so on. Normal forms higher than 1NF are intended to deal with situations in which a table suffers from design problems that may compromise the integrity of the data within it. For example, the following table is in 1NF, but is not in 2NF and therefore is vulnerable to logical inconsistencies: Subscriber Email Addresses Subscriber ID 108 252 252 360 Email Address steve@aardvarkmail.net carol@mongoosemail.org hclark@antelopemail.com Subscriber First Name Steve Carol Harriet Subscriber Surname Wallace Robertson Robertson Clark
crobertson@aardvarkmail.net Carol
The table's key is {Subscriber ID, Email Address}. If Carol Robertson changes her surname by marriage, the change must be applied to two rows. If the change is only applied to one row, a contradiction results: the question "What is Customer 252's name?" has two conflicting answers. 2NF addresses this problem. Note that Carol Robertson's record is appearing in the table twice because it has more than one email address related to it. A practical way to think of 1NF in the above table is to ask a series of questions about the relationships that records (rows) can have between entities (tables) or attributes (columns), based on given business rules or constraints. For example,
could a Subscriber record relate to many Email Address records? Could an Email Address record relate to many Subscriber records? In the above table we can see that Carol Robertson has more than one email address. We could answer the questions by saying there's a one-to-many relationship (1:M) between Subscriber and Email Address in the above table, since a subscriber can have many email addresses, and an email address usually has one, and only one subscriber. We would then create a separate table called Subscribers and move the Subscriber First Name and Subscriber Surname columns from the Subscriber Email Addresses table into the new Subscribers table, adding a third column Subscriber ID as the primary key. Thus, a one-to-many relationship exists between the Subscribers table (with Subscriber ID as the primary key) and the Subscriber Email Addresses table (with Subscriber ID as the foreign key). The tables would conform to 2NF in addition to 1NF.
See also
Attribute-value system Entity-attribute-value model Second normal form Third normal form
References
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. 120125. 3. ^ Elmasri, Ramez and Navathe, Shamkant B. Fundamentals of Database Systems, Fourth Edition (Addison8 of 10
4.
5.
6.
7.
8.
Wesley, 2003), p. 315. ^ Date, C. J. "What First Normal Form Really Means" (http://www.dbdebunk.com/page/page /629796.htm) pp. 127128. ^ Such views cannot be created using SQL that conforms to the SQL:2003 standard. ^ "Codd first defined the relational model in 1969 and didn't introduce nulls until 1979" Date, C. J. SQL and Relational Theory (O'Reilly, 2009), Appendix A.2. ^ 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. ^ Date, C. J. "What First Normal Form
9.
10.
11.
12.
Really Means" (http://www.dbdebunk.com/page/page /629796.htm) p. 128. ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6. ^ 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). ^ "[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 13. ^ Date, C. J. "What First Normal Form Really Means" (http://www.dbdebunk.com/page/page /629796.htm) p. 112. 14. ^ Date, C. J. "What First Normal Form Really Means" (http://www.dbdebunk.com/page/page /629796.htm) pp. 121126.
Further reading
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.). AddisonWesley 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. 120125 Date, C. J., & Darwen, H., & Pascal, F. Database Debunkings (http://www.dbdebunk.com)
External links
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/techresources/articles/intro-to-normalization.html) by Mike Hillyer. A tutorial on the first 3 normal forms (http://phlonx.com/resources/nf3/) by Fred Coulson Description of the database normalization basics
(http://support.microsoft.com/kb/283878)
by Microsoft
Retrieved from "http://en.wikipedia.org/wiki/First_normal_form" Categories: Database normalization This page was last modified on 11 September 2011 at 11:59. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of use for details. Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
10 of 10

First Normal Form

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

First Normal Form

Încărcat de

Drepturi de autor:

Formate disponibile

First normal form - Wikipedia, the free encyclopedia