Talk:Database normalization

message: Throughout this article, there is discussion of 3NF and then EKNF (which is between 3NF and BCNF) and then 4NF, with no mention of BCNF. Why was this left out? Contributors themselves have noted that EKNF is not discussed much in the literature, so I am not sure why it is mentioned but not BCNF.
--StatsJunkie (talk) 04:22, 23 October 2022 (UTC)
replies: text: It is listed in various places and a link to its own article is provided. I'm sure a new subsection Satisfying BCNF would be most welcome. Rp (talk) 18:55, 24 October 2022 (UTC)
thread_title:  Why is Boyce-Codd Normal Form Not Discussed More? 

message: How would I know if I had reached the most normalised/optimised stage? Is there any tool like Karnaugh map that lists all permutations/combinations?Anwar (talk) 13:01, 22 May 2008 (UTC)
replies: text: I don't know, but for small schemas (say, 20 relations or less) this is easy to see.  A related issue is that there may be implicit dependencies that have not been marked explicitly in the database schema - determining those is not so easy, see e.g.  Rp (talk) 08:49, 7 July 2009 (UTC)

text: We can use the concept of normalization only for the time of removing the redundancy data in the databases. When the data gets the unique data in the records, may get reach the normalised stage.  —Preceding unsigned comment added by 210.212.230.196 (talk) 09:52, 18 December 2010 (UTC)

text: Normal forms are defined as conditions; you can simply check whether the required conditions hold to know whether a database schema is in a particular normal form. Rp (talk) 23:38, 26 December 2010 (UTC)
thread_title:  Karnaugh map 

message: The article does not explain the trade-offs suffered with normalisation. For instance, a highly normalised database needs more tables each stripped to the bare minimum. So serving a singular query would require pulling data from several tables. This costs time and money. In a way, the business process is not optimised (though the database is!).Anwar (talk) 13:18, 22 May 2008 (UTC)
replies: text: Do you have an article or a computing paper where this is explained, so we can add it better to the article? --Enric Naval (talk) 11:43, 24 May 2008 (UTC)

text: A normalization, and thus pulling data from several tables doesn't cost significantly more time. In fact, a database that is not normalized will take much more CPU time and Disk I/O to process, requiring more resources as query load increases. Then your business will either need to purchase more hardware, or re-architect it's database and code base, and trust me, that costs alot more. Common sense always dictates that you "Do it right the first time" 71.231.132.75 (talk) 14:38, 24 December 2009 (UTC)
replies: text: This is not correct - certainly deviations from normal form can cost a lot of space and query time, but denormalization can also help performance - for instance, if certain joins are very frequent, it may pay off to denormalize the database over those joins. Rp (talk) 21:56, 26 December 2009 (UTC)

text: A general guideline is that transactional databases (intended for high-concurrency, high-volume interactive updates, inserts and deletes to the data - such as databases used for E-commerce transactions) SHOULD be maximally normalized, because if you don't, changes to certain data elements have to be made in two (or more) places.  Denormalization is normal practice for data marts/warehouses, which are read-only when operated interactively (their contents are generated by scripts from a transactional database) to improve query performance. Sometimes, de-normalization can be extreme, as when precomputing aggregates at various levels of hierarchy - e.g., grand sales total, total by division, region, salesperson, product, etc.  Prakash Nadkarni (talk) 01:20, 11 May 2020 (UTC)
thread_title:  Trade-off 

message: The statement, "It has never been proven that this denormalization itself provides any increase in performance, or if the concurrent removal of data constraints is what increases the performance." needs more backup on that argument or needs to be revised or removed.
Volomike (talk) 12:53, 17 January 2009 (UTC)
replies: text: It's wrong.  Denormalization doesn't remove data constraints.  It just means that instead of maintaining two tables, you maintain their join.  This can be faster if you often need that join. Rp (talk) 21:13, 1 July 2009 (UTC)

text: PS the article should bother to explain this. Rp (talk) 21:19, 1 July 2009 (UTC)
replies: text:  Agreed.  99.60.1.164 (talk) 17:13, 22 August 2009 (UTC)
thread_title:  Denormalization 

message: this article has the ugliest tables i've seen  —Preceding unsigned comment added by 67.187.187.128 (talk) 00:42, 27 November 2009 (UTC)
replies: text: You noticed that too? 71.231.132.75 (talk) 14:40, 24 December 2009 (UTC)
thread_title:  ugly tables 

message: This article should include EKNF (given this name in 1982 by Zaniolo, in his paper "A new normal form for the design of database schemata ), a normal form which is stronger (more faithful to the principal of separation) than 3NF and which has the "complete representation" property proposed in 1976 by Philip A Bernstein (Bernstein P.A., "Synthesizing third normal form relations from functional dependencies" ) as a criterion for schema synthesis algorithms.MichealT (talk) 11:57, 7 March 2010 (UTC)
replies: text: Please add it - and while you're at it, perhaps you can remove Date's 6NF which really doesn't fit in with the rest, but I hesitate to touch it. Rp (talk) 23:40, 26 December 2010 (UTC)
thread_title:  Elementary Key Normal Form 

message: : From where I stand, there is an important aspect of Data Normalization that is completely missing in this article.  That aspect is the use of these procedures in the design process of any database - or even for the evaluation of how well classes have been partitioned in object-oriented coding.
: I have been programming professionally since 1971 and have found these NF definitions useful since I have started using them - decades now.
: The point of DN is not that it is an implementation goal, but that it is an powerful design tool.  Any data base, regardless of how it is to be implemented, should be fully normalized (at a minimum, 3NF) during the design process because that discipline will reduce the chances that the purpose behind the data fields is being missed.  DN forces the designer to ask the right kind of questions and collect the required data so that the system, once implemented, will perform productively.
: In the case where there is an existing system which is simply being automated, when interviewing the users of that system, they will described the data fields in the common tougue - very loose terms that barely touch on the purpose of a field.  Only on careful investigation can keys and dependencies be determined, and once determined they will commonly result in discoveries that result in more user interviews.  As that information is collected, it needs to be recoded and the "common tongue" is not good enough.  The simplest comprehensive form for describing the database at this stage in the design process is by describing it in terms of a normalized database.
: Once the database has been documented in this form, the next stage of the desgn process is how it will be implemented.  At this point the designer needs to consider precisely how and when backups and restores will be done, whether the harware will support various query and update transactions, etc.  At this stage, the database implementation will be described and, except for rare or trivial cases, substantial denormalizations will be applied.
Scott Bowden (talk) 16:08, 9 February 2012 (UTC)
replies: text: I would say that probably belongs mainly under Data model, Data modeling, Entity-relationship model, etc., but there doesn't appear to be much in the way of linking to those articles. Perhaps a short section here with a hatnote pointing to those articles? Adding links wouldn't hurt, anyway. --Boson (talk) 20:42, 9 February 2012 (UTC)
thread_title:  The Design Exercise 

message: "Even by the removal of {Employee ID} functional dependency still holds between {Employee Address} and {Skill}."
How can there be a functional dependency between {Skill} and {Employee Address}?, consider two people living in the same house.  — Preceding unsigned comment added by Prathik Rajendran M (talk • contribs) 13:21, 29 December 2012 (UTC)
thread_title:  Example for Full functional dependency seems to be inconsistent 

message: The Mike Chapple article on About.com mentioned at the bottom is Ghostwritten, it's copied verbatim from the Microsoft Access Manuals it seems.. 
If you look in the 2NF reference, there is a a reference to "Sea Cliff, NY 11579" and "Miami, FL 33157" which does not have a corresponding figure on about.com, to locate 
the figure I did a search on google and found a number of documents, including a PDF of a technicians manual at AIMS.. Which leads me to to believe Mike is either outright 
plagiarizing, or its ghostwritten by a foreign outsourcer.. There probably isn't a copyright infringement as it seems Microsoft owns 5% of IAC which is the parent company of About.com . 
It should go noted.. 172.0.207.115 (talk) 02:43, 13 February 2014 (UTC)
thread_title:  References 

message: I realize that some links are duplicates since they exist in the body of some preceding paragraphs but I thought it would be better to duplicate them in a complete list instead of calling the section "Other Normal Forms" and only listing forms not discussed in the rest of the article.  Andrew S. (talk) 15:15, 24 July 2015 (UTC)
thread_title:  Added section to list ALL the normal forms for which there are Wikipedia articles (with links) 

message: By way of disclaimer, I am not a database expert myself — far from it. I'm simply a novice web developer seeking to advance his understanding of databases and relational theory. I've made the following changes; in all cases, please correct me if I'm mistaken.
# My understanding is that normal forms are, by definition, the formal end-goal of database normalization. As such, I have edited the lead section to redefine normalization in terms of normal forms, and extracted the list of internal links to various normal forms out of the "See also" section into its own "Normal forms" section.
# I've also removed bits that appeared redundant to me, as well as the bit about "achieving the optimal structure composed of atomic elements" (which, in my understanding, relates only to 1NF).
More importantly, I'm requesting the following changes from an expert:
# a broad overview of what normal forms are exactly; e.g., the property that each normal form requires all prior normal forms to be met (currently, it only features a brief history of when they were proposed and a list of links to each one); and
# a modest reorganization to ensure that no terms are used before they are clearly defined or linked to corresponding articles (currently, "Objectives" mentions normal forms, which aren't defined anywhere, and "Normal forms" mentions update/insertion/deletion anomalies, which are defined in "Objectives").
Pennbrook (talk) 03:42, 10 January 2018 (UTC)
thread_title:  Expanding on normal forms & clarifying terminology 

message: I've added a step by step normalization example illustrating each normal form. I've ceased to think of an example for EKNF though... I'm by all means no expert on databases, so I welcome any corrections... Honzikec (talk) 21:29, 23 January 2019 (UTC)
replies: text: Thanks  I think that's super helpful. I just went over it and fixed two problems, hopefully I didn't do anything wrong. I think one remaining problem is that right now it's not clear what's the difference between ETNF and 5NF as the example seems to be essentially saying the same things. --a3nm (talk) 20:25, 21 April 2019 (UTC)
thread_title:  A step by step normalization example 

message: Not sure of how to fix it, but the step-by-step example seems to have another problem: after the 3NF step, the schema is not actually in 3NF because the dependency removed in the BCNF case also violates 3NF. Pinging , in case you have an idea of how to fix the example? --a3nm (talk) 22:20, 27 May 2019 (UTC)
replies: text: , we could probably replace the BCNF example with some reservations inspired by the Wiki article on BCNF (https://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form) ... I currently don't have time to address this in detail though :( Honzikec (talk) 14:11, 29 May 2019 (UTC)
replies: text:  , thanks for your input. No worries if you can't do it, but just to be sure, you agree that there's currently a problem, right? Also, if you see a way to integrate the examples from the BCNF article in a way that fits with the running example of this article, this would be interesting. (As for actually doing it, maybe I could take care of it.) --a3nm (talk) 15:09, 29 May 2019 (UTC)

text: I have realized the same issue while reading the article. So your contribution is very welcome. Please go ahead. — Maggyero (talk) 11:30, 21 June 2020 (UTC)
thread_title:  Problem with 3NF in the step by step example 

message: Having First and Last name in the same column isn't atomic. If you want to sort by last name, you can't do it without parsing.  — Preceding unsigned comment added by Grr (talk • contribs) 00:41, 9 July 2020 (UTC)
replies: text: Whether a particular field is atomic or not depends on how it will be used. Having first name and last name seperated may be neccessary if sorting by last name is something you want to do, but this may not be neccessary in the given scenario. I think the example is acceptable as is. AntPraxis (talk) 10:48, 17 February 2021 (UTC)
replies: text: "Atomic" is really a simplification of 1NF. The definition is to eliminate non-simple domains, which means collection types. A string type is considered a simple domain, while a column which allowed an array or set of strings as value would would be non-simple. Deciding on one or two columns for a name depends on business requirements, but is unrelated to the issue of normalization, since in either case the attribute domains are the same: a string.  --80.62.117.218 (talk) 11:00, 9 June 2021 (UTC)
thread_title:  1NF Example isn't right 

message: This table has a transitive dependency {Title} → {Author} → {Author Nationality}, which violates 3NF.
Unfortunately, fixing this is not trivial since later in the section about BCNF this same dependency is described to violate BCNF and is decomposed to illustrate the process of normalizing a database from 3NF up to BCNF. But, as I said, the table is not in 3NF in the first place!
Therefore, the sections: #Satisfying_3NF and #Satisfying_BCNF are incorrect and misleading.
Also see this reddit thread that discusses this Wikipedia page.  — Preceding unsigned comment added by 5.173.128.7 (talk) 10:03, 12 August 2020 (UTC)
replies: text: The incorrect example you removed appears to have been re-added. Also the BCNF example is problematic because author name is unlikely to be unique. Author-Nationality (which should just be called Author) should have a surrogate key, because there could be two authors with the same name from two different countries. In fact if we consider duplicate author names, author name does not even functionally determine author nationality. AntPraxis (talk) 11:09, 17 February 2021 (UTC)
thread_title:  The table shown as an example of 3NF does NOT conform to 3NF! 

message: The problem is about the subject column isn't atomic. Giving the subject a own table is to normalize this 1NF example, but why is for the publisher column also given a own table? There is even no word about the publisher in the problem description at all. 80.208.142.162 (talk) 16:12, 25 April 2021 (UTC)
thread_title:  1NF example: why give publisher a own table? 

message: In the normalization grid, the first step is UNF (Unnormalized form) which is described as requiring primary keys. I think this is potentially confusing. "Unnormalized form" have no exact definition AFAIK, but can be used to refer to "free-form" data like an Excel sheet which allow duplicate rows and inconsistent columns. But Codd defines normalization as starting with relations, which means it is already assumed there is no duplicates, no intrinsic order, a well defined number of attributes and domains and so forth. The terms 0NF (zeroth normal form) and NFNF (non-first normal form) is often used to describe data which is in relational form but does not conform to first normal form (i.e may have nested relations). Therefore I suggest we create a separate page (perhaps called 0NF or NFNF) which describes the constraints of a relational form of data as separate from unnormalized data.  --80.62.117.218 (talk) 10:47, 9 June 2021 (UTC)
thread_title:  Reference to UNF/Unnormalized form 

message: "Until the new faculty member, Dr. Newsome, is assigned to teach at least one course, their details cannot be recorded."
"Their"? Who are they? At first I was confused, and then I thought that it probably is the new "inclusive" language. Who cares about the sex of an imaginary example doctor other than some crazy zealots? Use a singular pronoun. I suggest using "his", but this is only because that is the tradition. Again, I do not mind the sex of an imaginary doctor. If you think female representation is needed in fictional examples, use "her". Sin Jeong-hun (talk) 12:11, 11 June 2022 (UTC)
thread_title:  Use "his" 

message: After looking at the definition of "primary key" I find it surprising that the term would be involved in the definitions and descriptions of the normal forms at all. The "primary key" concept seems to be an implementation detail of RDBMSs that doesn't even necessarily have to exist on a given implementation.
The part that states "As a prerequisite to conform to the relational model, a table must have a primary key, which uniquely identifies a row." doesn't seem true.
The Relational Model article states "Usually one candidate key is chosen to be called the primary key and used in preference over the other candidate keys, which are then called alternate keys." which implies that it is not strictly necessary to choose a primary key.
It seems like the formal and informal definitions in "Every non-prime attribute has a full functional dependency on a candidate key (attributes depend on the complete primary key)" disagree. If any candidate key can be chosen as the primary key and the informal definition is assumed to be correct, then that implies that the formal definition should say "on each candidate key" rather than "on a candidate key" because we don't know which candidate key will be chosen as the primary key.
I don't know how the canonical texts on normalization define these, but the definitions in this article seem problematic. If "primary key" is not used in the formal definitions, perhaps the use of the term should be relegated to one section that clearly explains that the informal definitions aren't strictly correct and should only be used as an convenience to help guide intuition. Since the large example section accounts for most of the explanation of the normal forms and heavily make use of the term "primary key" it makes it seem as though the term is part of the real definition. 172.10.118.68 (talk) 17:25, 2 April 2023 (UTC)
replies: text: You are right. The use of the phrase primary key is wrong and inconsistent. Candidate keys are what matter. Oradium (talk) 22:09, 8 April 2023 (UTC)
thread_title:  Using "primary key" in normal form definitions and examples 

message: I can't recall a time I've ever left Wikipedia to go and learn the basics of a topic elsewhere, because the Wikipedia article was too complicated. But I just did that, for this topic. I'm a software engineer and even for me, this article is very difficult to follow. Due the fact that I don't yet understand the topic, I can't really fix it. But I (and presumably others) would be grateful if someone could dumb this one down some. At least the introduction and early parts of it. This article seems to assume a high degree of familiarity with a lot of material, and knowledge of a lot of specific jargon. That people coming here may not have. As this is covering a pretty high level and general topic. JaHolo (talk) 21:35, 1 August 2023 (UTC)
replies: text: This is where I wound up and 15 seconds in, I felt I had a much better understanding of what Database Noramlization is, than I did in several headache inducing minutes trying to figure this one out. https://www.lifewire.com/database-normalization-basics-1019735 JaHolo (talk) 21:39, 1 August 2023 (UTC)
replies: text: Ok, with a tiny bit of knowledge one thing I can say is that the 'Objectives' section seems to assume an understanding of what the Normal Forms are. When that isn't even covered until the next section. And there, it's covered in a pretty technical way. A paragraph of introduction on the normal forms - at the end of the introduction or before 'Objectives' would be extremely helpful. JaHolo (talk) 22:50, 1 August 2023 (UTC)

text: That article isn't a very reliable technical source. It appears to be a blog. "Dumb it down" isn't one of the goals of Wikipedia. Andre🚐 21:50, 23 November 2023 (UTC)
thread_title:  Overly Technical and Complicated