Scribd
Upload
433 views

Normalization Exercise Dentistry

The document discusses normalizing a database for a dentistry practice. It contains a table of sample data and functional dependencies. To normalize it: 1) The "appointment" attribute was decomposed into "appointment date" and "appointment time" to achieve first normal form. 2) One of the functional dependencies was chosen as the primary key, and relations were created for the other functional dependencies to achieve second normal form. 3) An additional relation was created from the remaining functional dependency to achieve third normal form.

Uploaded by

HARIPRASATH PANNEER SELVAM
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
433 views

Normalization Exercise Dentistry

The document discusses normalizing a database for a dentistry practice. It contains a table of sample data and functional dependencies. To normalize it: 1) The "appointment" attribute was decomposed into "appointment date" and "appointment time" to achieve first normal form. 2) One of the functional dependencies was chosen as the primary key, and relations were created for the other functional dependencies to achieve second normal form. 3) An additional relation was created from the remaining functional dependency to achieve third normal form.

Uploaded by

HARIPRASATH PANNEER SELVAM
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Normalization Exercise

Consider the following table of values:

Assume the following functional dependencies:

• {staffNo} → {dentistName}

• {patientNo} → {patientName} – Assume that the patient names and the dentist names are not
unique. The only way to uniquely identify these individuals is by their respective number.

• {staffNo, appointment} → {dentistName, patientNo, patientName, surgeryNo} – Essentially, a


given member of the staff can only perform one surgery at a time.

• {patientNo, appointment} → {staffNo, dentistName, patientName, surgeryNo} – A given patient


might have several appointments over time, but they cannot participate in more than one surgery
at a time.

There are two candidate keys here. Remember first that a candidate key is a superkey, meaning that the
functional dependency A → B covers all of the columns in the table. Further, a candidate key is minimal.
The third and the fourth functional dependencies both meet those requirements.

To get it into first normal form, we simply need to decompose appointment into its two components:
appointment date and appointment time. This is an example of an attribute that’s not atomic. It’s not
multi-valued, nor is it repeating, but I’m arguing that we have two values in one as it stands.

Regardless of which of the two candidate keys that you choose to use for the primary key, we have some
work to do to get it into 2nd normal form. If you use functional dependency #3, then {staffNo} →
{dentistName} is a subkey in which the subkey is part of the primary key. If you go with functional
dependency #4 for the primary key, then {patientNo} → {patientName} is a subkey that is part of the
primary key.

Then, to address third normal form, we see that if we use the 3rd functional dependency as the primary
key, then {patientNo} → {patientName} requires that we split that out into a relation of its own to get into
3rd normal form. In a parallel fashion, if we use the 4th functional dependency as our primary key, then
we have to factor out the {staffNo} → {dentistName} functional dependency.

Normalization Exercise Dentistry.docx 3/27/2020 9:58:00 AM 1


From here on out, we will choose the 3rd functional dependency as our choice for the primary key. At this
point we have just decomposed appointment into its constituents, identified the primary key, and left it
at that. So this relation (such as it is) is in first normal form.

The {staffNo} → {dentistName} functional dependency means that our previous structure violated 2nd
normal form since staffNo is part of the primary key. Refactoring that functional dependency out into a
separate scheme gives us the above relation scheme model. We still are not in 3rd normal form because
of the {patientNo} → {patientName} functional dependency. We did not address that last functional
dependency yet because it’s not part of the primary key.

Normalization Exercise Dentistry.docx 3/27/2020 9:58:00 AM 2


Factoring the {patientNo} → {patientName} functional dependency out, we arrive at 3rd normal form.

Hopefully, this looks like a many to many with history. It is with history because a given dentist could
perform a surgery on the same patient more than once. You could say that {appointment date,
appointment time} forms the discriminator for this many to many with history, but I’d cringe a little at
that because the primary key of Dental Appointment does not require the patientNo.

I will leave it as an exercise to the student to work through 2nd and third normal form if you had decided
to go with the 4th functional dependency as your primary key.

Normalization Exercise Dentistry.docx 3/27/2020 9:58:00 AM 3

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy