Talk:Fourth normal form

message: I think your explanation of multi-valued dependencies was misleading. A functional dependency is one where a field or fields determine the value of another field in the same row; whereas a multivalued dependency is the existence of some rows of data necessitate further rows of data in the same table, but not in the same row. I've been staring hard at the multivalued dependency article to get my head round it and I'll try and come up with a user-friendly description of what its on about. --VinceBowdren 14:11, 18 August 2006 (UTC)
thread_title:  Multi-valued dependencies 

message: ontent removedMichealT (talk) 11:54, 7 March 2010 (UTC)
thread_title:  Section added in error (wrong talk page) 

message: Hello fellow Wikipedians,
I have just modified one external link on Fourth 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:
*Added archive https://web.archive.org/web/20050404010227/http://www.aw-bc.com/catalog/academic/product/0,1144,0321197844,00.html to http://www.aw-bc.com/catalog/academic/product/0,1144,0321197844,00.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 00:44, 5 October 2017 (UTC)
thread_title:  External links modified 

message: Firstly, after a brief explanation that 4th normal form is part of database normalization, it needs to explain the problem with lower forms that this form solves. The reason normalization exists is to solve data redundancy and efficiency, etc. This must be clear. The audience of this article is presumably people who are new to relational database modeling and should have them in mind throughout. Each concept should be described in terms of the problem being solved. 
To do this, jargon should not be used without clear, plain language definitions (or links to the definitions). Any abstract representations of data should be only used in conjunction with real-world illustrations. 
Instead of using pizza types, vendors, I think a library catalog is probably the most apt model for understanding all forms from 1st to 5th. At 4th and 5th form, we start defining tables based on attributes that might regularly be null in a given table. As a database size increases, the risk of null columns in tables can become a liability and can result in some rigidity in entity definitions that may spell trouble later on. So in BCNF, which is what most database developers will ever need, one might break up a library catalog by title, author, publisher, edition, copies, locations etc. 
But in a 4th or 5th normal form, any column that is not required should have its own table. That is, any column that can have a NULL value should be replaced with a table for only the entities that have a value. 
For instance in a 3rd normal form data table for `book_editions` could have a value for both print (page_count) and audio-book (time_length). In a 4th and 5th normal forms, these attributes would be split into two separate tables: a `book_edition__page_count` and `book_edition__time_length`. Each table would have the book_edition_id and a the corresponding column for the data type.  In querying the data, one would left join all the related tables into a single "book edition". Since a given edition will have one or the other values, the abstract result will resemble the 3rd normal form table with one value populated and the other null. 
Another example would be for the author table.  For every unique author_id in the Author table, instead of having columns for first_name, last_name, middle_name, pen_name, prefix, suffix, each field would have it's own table with the value and related author_id. Since the vast majority of authors will not have a prefix title (Sir, Dame, Dr., etc.) or a suffix (Sr. Jr. Esq., etc.) those rows simply would not exist in the database for the given author_id. So this could account for a book by Aristotle, and one by Rev. Dr. Martin Luther King, Jr. . This could be further abstracted into a single table called name with the columns: author_id, name, type where type relatees to a third table of name types: first, last, middle, prefix, suffix, and even more rare concepts like titles of nobility: His Grace Franklin Bafflement Wingbats-Almond Tree, Jr. 7th Duke of The Dumpster. Each concept would be represented with its type in separate rows in the table all relating to the single author_id for the given author. So if this fictitious person's author_id was 5 and there was a table of name_types the rows would look like this:
author_id	name_string             	name_type_id
5        	His Grace               	4
5        	Franklin                	1
5        	Wingbats-Almond Tree    	2
5        	Bafflement              	3
5        	Jr.                     	5
5        	7th Duke of the Dumpster	6
With a table of name_types
name_type_id	type_string	name_position
1           	First Name 	2
2           	Last Name  	4
3           	Middle Name	3
4           	Prefix     	1
5           	Suffix     	5
6           	Noble Title	6
Theoretically the person table that stands as the parent "entity" could just have one field: author_id. This would be extreme, but it is entirely possible. 
General Ludd (talk) 02:01, 12 February 2020 (UTC)
thread_title:  Unnecessarily full of confounding jargon