![]() | Databases C‑class ( inactive) | ||||||
|
A commonly overlooked violation of 1NF is building intelligence into an identifier. The VIN for an automobile is not atomic, besides a sequence number it contains:
1) A code identifying the region where the vehicle was manufactured;
2) A code identifying the manufacturer;
3) Several codes identifying attributes of the vehicle;
4) A code indicating the vehicle model year;
5) A code indicating the plant where the vehicle was made;
Sadly, the VIN is probably the primary key to many tables in existence today. Business persons have a natural tendency to build inteligent keys. There is no mention of this in the main article, it only addresses the classic textbook example of eliminating redundant columns. Mooredc 17:56, 16 August 2006 (UTC)
I don't know if this is the right place to add my two pence, but I was wondering if it wouldn't be a good idea to have some kind of links in the bottom of the article to move from 1NF to 2NF to 3NF and so on, instead of having to go back to the normalization in order to move from the article on one normal form to the other. ray 17:04, 21 August 2006 (UTC)
I mean, take this:
First Name | Last Name | Middle Name |
---|---|---|
John | Public | Q |
J | Hacker | Random |
John | Doe |
“Has no middle name” is a valid answer, yet having a nullable column seems to violate that requirement — Random832 20:28, 19 September 2007 (UTC)
Person ID | First Name | Last Name |
---|---|---|
1 | John | Public |
2 | J | Hacker |
3 | John | Doe |
4 | George | Bush |
Person ID | Middle Name Sequence Num | Middle Name |
---|---|---|
1 | 1 | Q |
2 | 1 | Random |
4 | 1 | Herbert |
4 | 2 | Walker |
The article contains the following:
A view whose definition mandates that results be returned in a particular order, so that the row-ordering is an intrinsic and meaningful aspect of the view.[5] This violates condition 1. The tuples in true relations are not ordered.
However, when I followed the link for tuple, the formal definition said that tuples are ordered. —Preceding unsigned comment added by 84.75.117.176 ( talk) 10:44, 30 September 2007 (UTC)
So the link for tuple contradicts the second point of the definition - that there is no left to right column ordering - by saying that the elements of a tuple have an intrinsic order. Michealt ( talk) 23:57, 16 August 2011 (UTC)
Please revise the 1NF Example as it can be an example of 2NF also. —Preceding unsigned comment added by 122.164.254.49 ( talk) 11:14, 1 October 2007 (UTC)
How is the example given under the heading "Normalization Beyond 1NF" a 1NF table? IF you assume the customer ID is the primary key here, then isn't there a violation of having unque key in rows 2 and 3? - Henry —Preceding unsigned comment added by 192.193.164.8 ( talk) 07:52, 7 August 2008 (UTC)
Pure 1NF Example mention seems to me necessary:
Customer ID | First Name | Surname | Telephone Number |
---|---|---|---|
123 | Robert | Ingram | 555-861-2025 |
456 | Jane | Wright | 555-403-1659 |
456 | Jane | Wright | 555-776-4100 |
789 | Maria | Fernandez | 555-808-9633 |
This 1NF design, not in 2NF, is relational and allows further normalization. The new PK is (CustomerId,TelephoneNr). EnriqueVillar Jan 12, 2011 —Preceding unsigned comment added by 88.31.77.59 ( talk) 17:32, 12 January 2011 (UTC)
Seems like there should be some mention of the importance of atomicity instead of just explaining that Date disagrees with Codd and listing the ways atomicity can be taken to extremes. Ostensibly, Codd was trying to say that putting a field in a field isn't generally a good idea. For example, you wouldn't want a flight number field to contain the codes for the airports of departure and arrival. That's the common sense way to interpret atomicity. Seems like that should be mentioned first instead of not at all. Then talk about all the theoretical mumbo jumbo that has limited practical value to someone just learning about 1NF. -- Trweiss ( talk) 22:09, 12 May 2008 (UTC)
The requirement that tables represent mathematical relations (no duplication or implicit ordering of rows) is not part of 1NF, but is prior to the idea of 1NF; if Date says otherwise he is wrong. The article should reflect Codd's original article, which proceeds in two steps: first, the proposal to base data modeling on mathematical relations, and second, the proposal of "normalization", later called 1NF, which is the systematic elimination of "non-simple" value domains. The article should not confuse these two things like it does now. Rp ( talk) 14:50, 3 February 2009 (UTC)
There is a blatant contradiction between the between "isomorphic to a relation" and number 2 in the list of 5 conditions. A relation is nothing more or less that a subset of the cartesian product of several domains: each element is therefore an ordered finite sequence of values. The attributes don't have names. If a table is to be isomorphic to a relation, the columns must be ordered. This is an error on Date's part.
A better statement would be that a table must be a map between attribute names and values. One could also say that when a total order is assigned to the map's set of attribute names and is used to order the values in each each map element so as to produce a tuple (sequence of values) for each map element: the set of such tuples is required to be a relation (a fairly meaningless statement, as it's easy to show that any such construction from a finite map will generate a relation).
Of course it's possible to get the attribute names into a relation (replace each attribute domain by the cartesian product of the singleton set containing the attribute name and the original attribute domain) but the description is rather far-fetched and requires a lot of mental gymnastics to explain how one can handle the concept os the domain with attribute-name "pet" in one table holding a value equal to one in the domain with attribute-name "dog" in another table (redefining equality is such fun) and even then the order is still there - there's no way of eliminating it from a relation. So I prefer to say that a table must be (isomorphic to) a set-theoretic map, so that the fields are accessed by name and not by order. MichealT ( talk) 13:04, 7 March 2010 (UTC)
The lead paragraph is too technical. It is my understanding that an 1NF can roughly be summarized as a table where the fields only contain one piece of information (no lists items). This statement may not be technically rigorous but it at least tries to capture the gist of the situation so that beginners can gain a basic understanding of the topic. The sentence, "A [1NF] table is a faithful representation of a relation and that it is free of repeating groups" absolutely inaccessible to the bulk of the readership. It is an instant turnoff that belongs nowhere in the lead. Technical jargon should be appear after a more down-to-earth introduction. I don't feel like I have the background to wisely word a less technical lead, so hopefully one of you can do it. Jason Quinn ( talk) 14:48, 16 June 2011 (UTC)
:Of course, even this could be misleading to a beginner, because a value may be a relation value (and may therefore contain more than one primitive values); so to give beginners a basic understanding of the topic (i.e. not lead them into believing things which appear obvious but are fundamentally incorrect), we might—counterintuitively— need to give more, rather than fewer, technical details. This is because the beginner might think it is obvious what "data value" means, where it is not.-- Boson ( talk) 20:37, 16 June 2011 (UTC)"At every row-and-column position within the relation [table], there is always exactly one data value, never a set of multiple values. In other words, first normal form just means no repeating groups (loosely speaking).
One big difference between the Date and Codd formulations of first normal form is that Codd regarded primary keys as crucial - every relation must have one or more primary keys (today those would be called candidate keys) and the definition of the relation must specify which of these primary keys is to be the primary key. The importance of the primary key is that it, together with an identification of the relation, is the means by which a row is identified by a user of the relational system - so the primary key is something meaningful to the user. As a consequence of the requirement for a primary key, a relation can not contain duplicate rows. The Date view seems to be that it is fundamental that there are no duplicate rows; so there is at least one superkey (the whole row) and so there must be at least one minimal superkey, that is at least one candidate key, and any one of those can be picked as the primary key. When it comes to views, since duplicates are eliminated from projections there is still guaranteed to be a primary key. Superficially, these two approaches look the same; in fact they turn out to have very different consequences, and probably explain why Codd could envisage a relation permitting attributes that could be NULL, while this is anathema to Date (Codd in his later work doiesn't require derived relations to have primary keys - but Date's starting from the position that there can never be duplicates and needing the existence of a primary key to be a consequence of this for base relations, can't allow nulls); it also leads to a difference of views about whether the meanigfulness (to users) of primary keys is or is not fundamental. It is a great pity that teh article does not treat primary keys at all - but I suppose it is an inevitable consequence of it s being written from a perspective based on Date's approach, instead of Codd's. I think the article could be greatly improved by inclusion of both approaches, instead of just one. Michealt ( talk) 00:21, 17 August 2011 (UTC)
Hello Jerome Potts. The new lead sentence references normal form. This is likely to confuse new readers who will feel the need to read the Database normalization#Normal forms section in order to understand what first normal form is. It isn't easy to understand the linked section, and it isn't necessary in order to understand the definition. It is sufficient to say 'First normal form is a property of a relation', and reference the normal forms section later, for further reading. - Crosbie 18:43, 21 March 2013 (UTC)
The second sentence of the main article reads: "A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain."
There are two problems with this:
So, something should be done to this page, which I'm willing to do, but I thought some discussion might be in order first. The choices that come to mind are:
It will be hard to phrase my second choice because while Employee1, Employee2, etc., appear to be a repeated column, in fact they are not. An example that better illustrates the problem would be a table with columns FirstName, MiddleName, LastName, which is very frequent. Is every table in the world with these columns in violation of 1NF? Probably most people would say they are not. But, suppose it's observed that first, middle, and last names don't apply to many cultures, and therefore better column names would be Name1, Name2, Name2. Not it looks like it's in violation of 1NF. But it's a bad rule that depends on how the columns are named. A good rule should be about the structure of the table, not what choices are made for column names (as long as they're distinct, that is). — Preceding unsigned comment added by Rochkind ( talk • contribs) 14:02, 7 May 2013 (UTC)
I think it will be difficult to explain this to the average reader without discussing the relationship between the real world and the physical tables, via the conceptual data model and the logical (ER) data model, etc. It is easy to see that
can lead to different types of employee, but - unless the table is seen in isolation - it is not easy to see how you can end up with a table containing a column Employee1 and a column Employee2, both of which must in effect be foreign keys referring to the same table, unless the two references derive from two different relationships (for instance if Employee2 expresses a relationship like "manages/is managed by").
To keep the discussion at the level of the relation, perhaps it would be useful to introduce the concept of "external predicates", the word "external" indicating that we are talking about "what relations mean to the user, rather than to the system". The "heading" of a relation "can be regarded as denoting a certain predicate . . . [and ] each tuple in the body . . . can be regarded as denoting a certain proposition (i.e., a statement that is unconditionally either true or false)" (this can be sourced, for instance, to Date, Darwen, Lorentzos: Temporal Data and the Relational Model).
Another thing that occurs to me is the historical perspective, which may help explain why certain ideas about atomicity may have evolved. I'm not sure how much can be stated without involving original research, but I suspect that the development of object-oriented systems served by relational back-ends and the "integration" of data models and object models may have helped emphasize the idea of single devoper-defined operations on complicated data types, supporting a different understanding of atomicity.
Perhaps we also need to separate different perspectives:
We might need to think about what information goes in which articles (including Database normalization, Relation (database), and the various normal forms). After all, this article and the other nNF articles are sub-articles of Database normalization. Perhaps all the articles should put more emphasis on the process of normalization - stressing that you don't start with the final database, but without giving the impression that one actually (as opposed to notionally?) progresses through different normal forms. At the moment I would be hard-pressed to define the readership that this article is targeted at. -- Boson ( talk) 15:40, 11 May 2013 (UTC)
As per the article, Date’s definition states that there’s no top-to-bottom ordering of the rows. If that’s the case, is a common representation of a tree structure, such as the table below, not in 1NF?
ID | Name | Mother ID |
---|---|---|
1 | Jane Doe | |
2 | Alice Doe | 1 |
3 | Bob Doe | 1 |
4 | Edgar Doe | 2 |
I find it hard to believe so there must be something else going on. It would be good if someone explicitly mentioned this or gave an example of a table which is not in 1NF because of the top-to-bottom ordering.— mina86 ( talk) 16:16, 9 September 2015 (UTC)
ID | Name | Mother ID |
---|---|---|
3 | Bob Doe | 1 |
4 | Edgar Doe | 2 |
1 | Jane Doe | |
2 | Alice Doe | 1 |
Hello fellow Wikipedians,
I have just modified one external link on First normal form. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
{{
dead link}}
tag to
http://www.elsevier.com/wps/product/cws_home/680662When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 15:15, 1 October 2017 (UTC)
As someone coming here to learn about this stuff for the first time, with my only related knowledge being professional experience with some pretty basic SQL, I read the whole article a few times and still am not sure I know what 1NF is.
I think some tables violating each of the different restrictions would be helpful, especially with corrected versions. The only example given is about atomicity, but also makes a kind of confusing note about the spirit of related groups being violated, but maybe not technically being violated?
Is this table in 1NF? Does it violate the Eliminate repeating groups in individual tables rule from the bullets in the lead? Additionally, does it violate the Identify each set of related data with a primary key rule?
Name | Grade |
---|---|
Paul | 3 |
Paul | 3 |
Alice | 4 |
Name | Grade |
---|---|
Paul | 3 |
Alice | 4 |
Name | Grade |
---|---|
Alice | 4 |
Paul | 3 |
Related, would this be an example of violating the Eliminate repeating groups in individual tables rule?
Name | Guardian | Guardian |
---|---|---|
Paul | Sarah | Michael |
Paul | Jaime | Dora |
Alice | Bob | Charlie |
Name | Guardians |
---|---|
Paul | Sarah, Michael |
Paul | Jaime, Dora |
Alice | Bob, Charlie |
What is an example of something that violates Create a separate table for each set of related data? Based on the atomicity section, It looks like both of these sets of relations are allowed, even though Option 2 appears to have data that can be separated into a different table.
Option 1:
|
|
Option 2:
Customer ID | First Name | Surname | Telephone Number |
---|---|---|---|
123 | Pooja | Singh | 555-861-2025 |
123 | Pooja | Singh | 192-122-1111 |
456 | San | Zhang | 182-929-2929 |
456 | San | Zhang | (555) 403-1659 Ext. 53 |
789 | John | Doe | 555-808-9633 |
Would this violate the primary key requirement? Why?
FirstName | LastName | Grade |
---|---|---|
Paul | Smith | 3 |
Paul | Rodríguez | 3 |
Alice | Oto | 4 |
FirstName | LastName | Grade |
---|---|---|
Paul | Smith | 3 |
Paul | Smith | 4 |
Paul | Rodríguez | 3 |
Alice | Oto | 4 |
nhinchey ( talk) 19:55, 31 October 2018 (UTC)
Does anyone else feel that the use of contractions in "1NF tables as representations of relations" chapter's 5 rules is inappropriate for a formal article such as this?
I wonder why it is written with contractions "there's" in the first 2 rules but without them in the other rules, e.g. "there's no top-to-bottom" instead of "there is no top-to-bottom"
I am not a native English speaker so it is possible I am drawing the wrong conclusions here... Aethalides ( talk) 19:01, 15 December 2022 (UTC)
![]() | Databases C‑class ( inactive) | ||||||
|
A commonly overlooked violation of 1NF is building intelligence into an identifier. The VIN for an automobile is not atomic, besides a sequence number it contains:
1) A code identifying the region where the vehicle was manufactured;
2) A code identifying the manufacturer;
3) Several codes identifying attributes of the vehicle;
4) A code indicating the vehicle model year;
5) A code indicating the plant where the vehicle was made;
Sadly, the VIN is probably the primary key to many tables in existence today. Business persons have a natural tendency to build inteligent keys. There is no mention of this in the main article, it only addresses the classic textbook example of eliminating redundant columns. Mooredc 17:56, 16 August 2006 (UTC)
I don't know if this is the right place to add my two pence, but I was wondering if it wouldn't be a good idea to have some kind of links in the bottom of the article to move from 1NF to 2NF to 3NF and so on, instead of having to go back to the normalization in order to move from the article on one normal form to the other. ray 17:04, 21 August 2006 (UTC)
I mean, take this:
First Name | Last Name | Middle Name |
---|---|---|
John | Public | Q |
J | Hacker | Random |
John | Doe |
“Has no middle name” is a valid answer, yet having a nullable column seems to violate that requirement — Random832 20:28, 19 September 2007 (UTC)
Person ID | First Name | Last Name |
---|---|---|
1 | John | Public |
2 | J | Hacker |
3 | John | Doe |
4 | George | Bush |
Person ID | Middle Name Sequence Num | Middle Name |
---|---|---|
1 | 1 | Q |
2 | 1 | Random |
4 | 1 | Herbert |
4 | 2 | Walker |
The article contains the following:
A view whose definition mandates that results be returned in a particular order, so that the row-ordering is an intrinsic and meaningful aspect of the view.[5] This violates condition 1. The tuples in true relations are not ordered.
However, when I followed the link for tuple, the formal definition said that tuples are ordered. —Preceding unsigned comment added by 84.75.117.176 ( talk) 10:44, 30 September 2007 (UTC)
So the link for tuple contradicts the second point of the definition - that there is no left to right column ordering - by saying that the elements of a tuple have an intrinsic order. Michealt ( talk) 23:57, 16 August 2011 (UTC)
Please revise the 1NF Example as it can be an example of 2NF also. —Preceding unsigned comment added by 122.164.254.49 ( talk) 11:14, 1 October 2007 (UTC)
How is the example given under the heading "Normalization Beyond 1NF" a 1NF table? IF you assume the customer ID is the primary key here, then isn't there a violation of having unque key in rows 2 and 3? - Henry —Preceding unsigned comment added by 192.193.164.8 ( talk) 07:52, 7 August 2008 (UTC)
Pure 1NF Example mention seems to me necessary:
Customer ID | First Name | Surname | Telephone Number |
---|---|---|---|
123 | Robert | Ingram | 555-861-2025 |
456 | Jane | Wright | 555-403-1659 |
456 | Jane | Wright | 555-776-4100 |
789 | Maria | Fernandez | 555-808-9633 |
This 1NF design, not in 2NF, is relational and allows further normalization. The new PK is (CustomerId,TelephoneNr). EnriqueVillar Jan 12, 2011 —Preceding unsigned comment added by 88.31.77.59 ( talk) 17:32, 12 January 2011 (UTC)
Seems like there should be some mention of the importance of atomicity instead of just explaining that Date disagrees with Codd and listing the ways atomicity can be taken to extremes. Ostensibly, Codd was trying to say that putting a field in a field isn't generally a good idea. For example, you wouldn't want a flight number field to contain the codes for the airports of departure and arrival. That's the common sense way to interpret atomicity. Seems like that should be mentioned first instead of not at all. Then talk about all the theoretical mumbo jumbo that has limited practical value to someone just learning about 1NF. -- Trweiss ( talk) 22:09, 12 May 2008 (UTC)
The requirement that tables represent mathematical relations (no duplication or implicit ordering of rows) is not part of 1NF, but is prior to the idea of 1NF; if Date says otherwise he is wrong. The article should reflect Codd's original article, which proceeds in two steps: first, the proposal to base data modeling on mathematical relations, and second, the proposal of "normalization", later called 1NF, which is the systematic elimination of "non-simple" value domains. The article should not confuse these two things like it does now. Rp ( talk) 14:50, 3 February 2009 (UTC)
There is a blatant contradiction between the between "isomorphic to a relation" and number 2 in the list of 5 conditions. A relation is nothing more or less that a subset of the cartesian product of several domains: each element is therefore an ordered finite sequence of values. The attributes don't have names. If a table is to be isomorphic to a relation, the columns must be ordered. This is an error on Date's part.
A better statement would be that a table must be a map between attribute names and values. One could also say that when a total order is assigned to the map's set of attribute names and is used to order the values in each each map element so as to produce a tuple (sequence of values) for each map element: the set of such tuples is required to be a relation (a fairly meaningless statement, as it's easy to show that any such construction from a finite map will generate a relation).
Of course it's possible to get the attribute names into a relation (replace each attribute domain by the cartesian product of the singleton set containing the attribute name and the original attribute domain) but the description is rather far-fetched and requires a lot of mental gymnastics to explain how one can handle the concept os the domain with attribute-name "pet" in one table holding a value equal to one in the domain with attribute-name "dog" in another table (redefining equality is such fun) and even then the order is still there - there's no way of eliminating it from a relation. So I prefer to say that a table must be (isomorphic to) a set-theoretic map, so that the fields are accessed by name and not by order. MichealT ( talk) 13:04, 7 March 2010 (UTC)
The lead paragraph is too technical. It is my understanding that an 1NF can roughly be summarized as a table where the fields only contain one piece of information (no lists items). This statement may not be technically rigorous but it at least tries to capture the gist of the situation so that beginners can gain a basic understanding of the topic. The sentence, "A [1NF] table is a faithful representation of a relation and that it is free of repeating groups" absolutely inaccessible to the bulk of the readership. It is an instant turnoff that belongs nowhere in the lead. Technical jargon should be appear after a more down-to-earth introduction. I don't feel like I have the background to wisely word a less technical lead, so hopefully one of you can do it. Jason Quinn ( talk) 14:48, 16 June 2011 (UTC)
:Of course, even this could be misleading to a beginner, because a value may be a relation value (and may therefore contain more than one primitive values); so to give beginners a basic understanding of the topic (i.e. not lead them into believing things which appear obvious but are fundamentally incorrect), we might—counterintuitively— need to give more, rather than fewer, technical details. This is because the beginner might think it is obvious what "data value" means, where it is not.-- Boson ( talk) 20:37, 16 June 2011 (UTC)"At every row-and-column position within the relation [table], there is always exactly one data value, never a set of multiple values. In other words, first normal form just means no repeating groups (loosely speaking).
One big difference between the Date and Codd formulations of first normal form is that Codd regarded primary keys as crucial - every relation must have one or more primary keys (today those would be called candidate keys) and the definition of the relation must specify which of these primary keys is to be the primary key. The importance of the primary key is that it, together with an identification of the relation, is the means by which a row is identified by a user of the relational system - so the primary key is something meaningful to the user. As a consequence of the requirement for a primary key, a relation can not contain duplicate rows. The Date view seems to be that it is fundamental that there are no duplicate rows; so there is at least one superkey (the whole row) and so there must be at least one minimal superkey, that is at least one candidate key, and any one of those can be picked as the primary key. When it comes to views, since duplicates are eliminated from projections there is still guaranteed to be a primary key. Superficially, these two approaches look the same; in fact they turn out to have very different consequences, and probably explain why Codd could envisage a relation permitting attributes that could be NULL, while this is anathema to Date (Codd in his later work doiesn't require derived relations to have primary keys - but Date's starting from the position that there can never be duplicates and needing the existence of a primary key to be a consequence of this for base relations, can't allow nulls); it also leads to a difference of views about whether the meanigfulness (to users) of primary keys is or is not fundamental. It is a great pity that teh article does not treat primary keys at all - but I suppose it is an inevitable consequence of it s being written from a perspective based on Date's approach, instead of Codd's. I think the article could be greatly improved by inclusion of both approaches, instead of just one. Michealt ( talk) 00:21, 17 August 2011 (UTC)
Hello Jerome Potts. The new lead sentence references normal form. This is likely to confuse new readers who will feel the need to read the Database normalization#Normal forms section in order to understand what first normal form is. It isn't easy to understand the linked section, and it isn't necessary in order to understand the definition. It is sufficient to say 'First normal form is a property of a relation', and reference the normal forms section later, for further reading. - Crosbie 18:43, 21 March 2013 (UTC)
The second sentence of the main article reads: "A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain."
There are two problems with this:
So, something should be done to this page, which I'm willing to do, but I thought some discussion might be in order first. The choices that come to mind are:
It will be hard to phrase my second choice because while Employee1, Employee2, etc., appear to be a repeated column, in fact they are not. An example that better illustrates the problem would be a table with columns FirstName, MiddleName, LastName, which is very frequent. Is every table in the world with these columns in violation of 1NF? Probably most people would say they are not. But, suppose it's observed that first, middle, and last names don't apply to many cultures, and therefore better column names would be Name1, Name2, Name2. Not it looks like it's in violation of 1NF. But it's a bad rule that depends on how the columns are named. A good rule should be about the structure of the table, not what choices are made for column names (as long as they're distinct, that is). — Preceding unsigned comment added by Rochkind ( talk • contribs) 14:02, 7 May 2013 (UTC)
I think it will be difficult to explain this to the average reader without discussing the relationship between the real world and the physical tables, via the conceptual data model and the logical (ER) data model, etc. It is easy to see that
can lead to different types of employee, but - unless the table is seen in isolation - it is not easy to see how you can end up with a table containing a column Employee1 and a column Employee2, both of which must in effect be foreign keys referring to the same table, unless the two references derive from two different relationships (for instance if Employee2 expresses a relationship like "manages/is managed by").
To keep the discussion at the level of the relation, perhaps it would be useful to introduce the concept of "external predicates", the word "external" indicating that we are talking about "what relations mean to the user, rather than to the system". The "heading" of a relation "can be regarded as denoting a certain predicate . . . [and ] each tuple in the body . . . can be regarded as denoting a certain proposition (i.e., a statement that is unconditionally either true or false)" (this can be sourced, for instance, to Date, Darwen, Lorentzos: Temporal Data and the Relational Model).
Another thing that occurs to me is the historical perspective, which may help explain why certain ideas about atomicity may have evolved. I'm not sure how much can be stated without involving original research, but I suspect that the development of object-oriented systems served by relational back-ends and the "integration" of data models and object models may have helped emphasize the idea of single devoper-defined operations on complicated data types, supporting a different understanding of atomicity.
Perhaps we also need to separate different perspectives:
We might need to think about what information goes in which articles (including Database normalization, Relation (database), and the various normal forms). After all, this article and the other nNF articles are sub-articles of Database normalization. Perhaps all the articles should put more emphasis on the process of normalization - stressing that you don't start with the final database, but without giving the impression that one actually (as opposed to notionally?) progresses through different normal forms. At the moment I would be hard-pressed to define the readership that this article is targeted at. -- Boson ( talk) 15:40, 11 May 2013 (UTC)
As per the article, Date’s definition states that there’s no top-to-bottom ordering of the rows. If that’s the case, is a common representation of a tree structure, such as the table below, not in 1NF?
ID | Name | Mother ID |
---|---|---|
1 | Jane Doe | |
2 | Alice Doe | 1 |
3 | Bob Doe | 1 |
4 | Edgar Doe | 2 |
I find it hard to believe so there must be something else going on. It would be good if someone explicitly mentioned this or gave an example of a table which is not in 1NF because of the top-to-bottom ordering.— mina86 ( talk) 16:16, 9 September 2015 (UTC)
ID | Name | Mother ID |
---|---|---|
3 | Bob Doe | 1 |
4 | Edgar Doe | 2 |
1 | Jane Doe | |
2 | Alice Doe | 1 |
Hello fellow Wikipedians,
I have just modified one external link on First normal form. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
{{
dead link}}
tag to
http://www.elsevier.com/wps/product/cws_home/680662When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 15:15, 1 October 2017 (UTC)
As someone coming here to learn about this stuff for the first time, with my only related knowledge being professional experience with some pretty basic SQL, I read the whole article a few times and still am not sure I know what 1NF is.
I think some tables violating each of the different restrictions would be helpful, especially with corrected versions. The only example given is about atomicity, but also makes a kind of confusing note about the spirit of related groups being violated, but maybe not technically being violated?
Is this table in 1NF? Does it violate the Eliminate repeating groups in individual tables rule from the bullets in the lead? Additionally, does it violate the Identify each set of related data with a primary key rule?
Name | Grade |
---|---|
Paul | 3 |
Paul | 3 |
Alice | 4 |
Name | Grade |
---|---|
Paul | 3 |
Alice | 4 |
Name | Grade |
---|---|
Alice | 4 |
Paul | 3 |
Related, would this be an example of violating the Eliminate repeating groups in individual tables rule?
Name | Guardian | Guardian |
---|---|---|
Paul | Sarah | Michael |
Paul | Jaime | Dora |
Alice | Bob | Charlie |
Name | Guardians |
---|---|
Paul | Sarah, Michael |
Paul | Jaime, Dora |
Alice | Bob, Charlie |
What is an example of something that violates Create a separate table for each set of related data? Based on the atomicity section, It looks like both of these sets of relations are allowed, even though Option 2 appears to have data that can be separated into a different table.
Option 1:
|
|
Option 2:
Customer ID | First Name | Surname | Telephone Number |
---|---|---|---|
123 | Pooja | Singh | 555-861-2025 |
123 | Pooja | Singh | 192-122-1111 |
456 | San | Zhang | 182-929-2929 |
456 | San | Zhang | (555) 403-1659 Ext. 53 |
789 | John | Doe | 555-808-9633 |
Would this violate the primary key requirement? Why?
FirstName | LastName | Grade |
---|---|---|
Paul | Smith | 3 |
Paul | Rodríguez | 3 |
Alice | Oto | 4 |
FirstName | LastName | Grade |
---|---|---|
Paul | Smith | 3 |
Paul | Smith | 4 |
Paul | Rodríguez | 3 |
Alice | Oto | 4 |
nhinchey ( talk) 19:55, 31 October 2018 (UTC)
Does anyone else feel that the use of contractions in "1NF tables as representations of relations" chapter's 5 rules is inappropriate for a formal article such as this?
I wonder why it is written with contractions "there's" in the first 2 rules but without them in the other rules, e.g. "there's no top-to-bottom" instead of "there is no top-to-bottom"
I am not a native English speaker so it is possible I am drawing the wrong conclusions here... Aethalides ( talk) 19:01, 15 December 2022 (UTC)