|
|
|
Question : 4th Normalization form
|
|
Here is an example of first 3 normal form...What will be 4th Normal form in this.
Unnormalized data :
Table : Meeting_history_table :
Meeting_no
meeting_date
meeting_attendees1
meeting_attendees2
meeting_attendes3
meeting_outcome1
meeting_outcome2
meeting_outcome3
meeting_conference_number
meeting_conf_key
In this way we are restricting the outcomes and attendees of the meeting
First Normal Form => Eliminate repeating groups in individual tables
Create a separate table for each set of related data.
Identify each set of related data with a primary key.
Tables should have only two dimensions. Since one meeting has several outcomes, these outcomes should be listed in a separate table. Fields outcomes 1, outcomes 2, & outcomes 3 in the above record are indications of design trouble.
Table : Meeting_history_table
Meeting_no
meeting_date
meeting_attendess
meeting_outcome
meeting_conference_number
meeting_conf_key
Second normal Form : ELIMINATE REDUNDANT DATA
Meet_no meet_date meeting_attend meeting_outcome conf_no conf_key
_____________________________________________________________
1 10 jan jolly abc 123 12
1 10 Jan jolly xyz 123 12
Make the separate table of attendee , to eliminate the redundant data.
Table : Meeting_history_table
Meeting_no
meeting_date
meeting_conference_number
meeting_conf_key
Table : Meeting_attendees
Meeting_no
Meeting_attendee
Table : Meeting_outcome
Meeting_no
Meeting_outcome
Third Normal Form : ELIMINATE DATA NOT DEPENDENT ON KEY
Since conference details are not depend on primary key ( Meeting No), make the separate table of conference details.
Table : Meeting_history_table
Meeting_no
meeting_date
Conf_id
Table : Meeting_attendees
Meeting_no
Meeting_attendee
Table : Meeting_outcome
Meeting_no
Meeting_outcome
Table : Conference_master
Conf_id
Conf_no
Conf_key
|
Answer : 4th Normalization form
|
|
jolly
Go here, http://www.bkent.net/Doc/simple5.htm, and you can read the definition as well as find examples of 4th and 5th normal form. Are you doing this for the mental exercise or are you doing this in the real world? It is important to keep in mind that while theory is valuable, it is not a theoretical world. For example, if you are a car manufacturer, then you might have some sort of "model" table. This table would contain all the models that you have ever built. In addition, most manufactures make less than 20 models per year (on average). In addition, Ithe manufacturer has a "sales" table that has 500000 rows per year. Sometime, the users like to query on sales table by model (is sale per model per quarter). Should the solution be to join "sales" and "model" by an "id" field or should model just be duplicated in the sales table. In the real world, I have seen both solutions. I would put model in the sales table. Why? Disks are cheaper then CPUs (speed or number)? I know that "model" is relatively static for inserts and that the sales table will probably be read(queried) 50-100 times more often than it has gets written (inserted). From your other posting, you are obviously trying to improve your skills. Just make sure you understand your "real world" environment and not just a theoretical one. When joeW, bret,grant 300 (bill) give an answer try to understand their approach as well as there solution. Hope this helps...
cheers
knel
|
|
|
|
|
|
|
