Term Project - week 8 - (17%):

You were just hired to create a database to track blood draws at a lab.
Discussions with the representatives focused on two entities, Blood Draws and Patients; the
following key points were agreed:
1 Each blood draw is assigned a unique DrawNum

From this we already have information about potential entity and DrawNum as attribute which will
be PK.

2 Each Patient has a unique PatID

From this we already have information about another potential entity and PatID as attribute which
will be PK.

3 The Contact Number may not be unique for each patient

Information is there to provide idea that contact number depends on PatID, but not vice versa.
Contact Number could be recognized by unique PatID, but through Contact Number we can’t find
unique PatID.

4 Each blood draw is taken from one patient, each patient may have more than one blood draw.

This tell us that relation between entities Blood_Draw and Patient are next: each blood draws is
linked to certain patient, while one patient may have more draws.

Although there is connection one to many we can thinking about additional entity which will keep
info about DrawNum and PatID only.

In that case this entity will have one to many relation with entities Blood_Draw and Patient.

5 No fields beyond those in the report / spreadsheet are needed

DrawNum is a unique number assigned to each blood draw, Date is the date of the blood draw,
Nvials is the number vials drawn, PatID is the ID for the patient – it is unique for each patient,
fName is the patient’s first name, lName is the patient’s last name, DOB is the patient’s date of
birth, Contact number is the contact number for the patient (patients may have the same number)

The objective of this exercise is to demonstrate an understanding of basic concepts covered in the
course. The exercise is a straight forward application of those concepts – there are no “hidden”
complexities – should you identify something in the key points or data that adds complexity,
contact the instructor before submission – you may be over thinking the exercise.

The sample data may not represent all possible values – consider each field’s domain during the
design.
The objective is to replace the following report / spreadsheet with a relational database. The
submission will consist of a word compatible document to record the design process, and an
Access DB. (A matching Excel spreadsheet is attached. This is provided to reduce typos - do not
assume the spreadsheet is a table in the normalized design.)

Here is the un-normalized table notation for the above report:

BloodDraws (DrawNum, Date, Nvials, PatID, fName, lName, DOB, ContactNum)

Considering on this listed data and mention that there are un-normalized we can conclude that
example excel data is in 1 NF.

The functional dependencies are:

DrawNum - - > Date, Nvials, PatID, fName, lName,DOB, ContactNum

PatID - - > fName, lName,DOB, ContactNum

After this kind of functional dependences we can count that we are near 2 NF when we create 2
entities.

The specific tasks to perform are listed below, the percentage corresponds to the grade weight for
each task: Organize your document to match the tasks.

Name your document Last Name_TermProject (i.e. Smith_TermProject). When you are asked to
provide an explanation or description, you must include sufficient content to demonstrate that you
understand the definition, term, concept, etc. and how it applies to this exercise.

SUGGESTION: Review the Terms and Concepts Forum, especially the Normalization One-To-Many
example. There is also a normalization MP4 file that can be downloaded from the Resources
section.

Follow the below outline in your submission –  include the section numbers – not the
questions or other content from the instructions.

1) Review the existing report, functional dependencies and sample data (consider field domains
and common knowledge) then document any assumptions you feel are appropriate (beyond those
in the key points) and identify the initial entities (person, place, thing). (10%)

Already mentioned some assumptions and conclusions based on provided dependencies and data
sample. Two initial entities will be Patient/Donor and BloodDonation.

2 Define functional dependency and explain each row of the functional dependencies provided
above (use field names and values). (15%) (you do not need to describe full, partial or transitive
dependency in this task)

Functional dependency is kind of relation between two attributes, usually it is between primary key
and other attributes in table.

DrawNum - - > Date, Nvials, PatID, fName, lName,DOB, ContactNum

Here we have situation that any other attribute can be recognize by DrawNum considering only
this column has unique value for each row.

Due this attribute is unique for each donor and fact we may have more donors in same day we
can’t use Date to recognize any other, but especially this attribute,

Nvials is just measurement and obviously we can check how many units is donated for certain
DrawNum, but not vice versa.

PatID is unique, but in sample data repeating due same donor may have more donation but each
donation has unique number.

Other attributes could be recognized by PatID and should be remove from this dependency during
normalization.

PatID - - > fName, lName,DOB, ContactNum

Obviously all other attributes depend on PatID, but vice versa isn’t possible.

If we check data in seventh and eight row we will see same fName and lName, but different PatID
and DOB.

It means that when we know PatID we know other attributes, while when we ask for birthday of
Nancy Johnson we can’t know which one.
DOB isn’t good candidate for any check due possibility that we have so many donors born on same
date.

3) Based on multiplicity – in plain English explain the relationship between the Entities provided in
the above description – (either one-to-many, or many-to-many). (15%)  

Due request that each donation has unique ID and information that donor may have more
donation we have relationship one to many between Patient and BloodDonation entities.

If we change initial request and allow that DrawNum may repeat ( register all donors in certain
moment using one DrawNum) we will have situations many to many and we will need to introduce
third entity B;oodDonation_Patient in order to avoid many to many.

4) Design: all tables and fields must be specified at each normal form level

a) First Normal Forum (1NF) assessment / action  10%

Copy the 1NF definition from the text (include quotes and page number)

Assess the UNF table provided and if necessary, make the changes needed to conform to the 1NF
definition. Explain any action taken and why.

Document the resulting 1NF table(s) using relational schema notation or spreadsheet format (see
the above example or page 111 Figure 4.2.6 of the text).

Explain how each table(s) meets the 1NF definition (use field names and values)

First Normal Form (1NF) - A relation in which the intersection of each row and column
contains one and only one value.

To transform the unnormalized table to First Normal Form we identify and remove
repeating groups within the table. A repeating group is an attribute, or group of
attributes, within a table that occurs with multiple values for a single occurrence of the
nominated key attribute(s) for that table. Note that in this context, the term ‘key’ refers
to the attribute(s) that uniquely identify each row within the unnormalized table. There
are two common approaches to removing repeating groups from unnormalized tables
(Thomas Connolly, Carolyn Begg, Database Systems: A Practical Approach to Design,
Implementation, and Management, 4th ed – 403 page)

DrawNum Date Nvials PatId fName lName DOB ContactNum

D000010 13-May-20 3 P000100 Sally Smith 15-Jan-01 746-777-1111
D000020 13-May-20 3 P000200 John Jones 20-Jul-90 756-666-2222
D000030 13-May-20 2 P000300 Samuel Rosenberg 15-Mar-99 723-555-3333
D000040 13-May-20 3 P000400 John Baron 15-Apr-96 232-888-5555
D000050 14-May-20 4 P000500 Jane Jackson 18-Jan-03 232-777-6666
D000060 14-May-20 2 P000100 Sally Smith 15-Jan-01 746-777-1111
D000070 14-May-20 3 P000600 Nancy Johnson 15-Feb-02 243-333-4444
D000080 14-May-20 3 P000700 Nancy Johnson 05-Sep-02 273-111-2222

Didn’t find reason to work on table due this data satisfied all request for 1 NF.
b) Second Normal Form (2NF) assessment / action   10%

Copy the 2NF definition from the text (include quotes and page number)

Assess the 1NF table(s) in the previous section and if necessary, make the changes needed to
conform to the 2NF definition. Explain any action taken and why.

Document the resulting 2NF table(s) using relational schema notation or spreadsheet format.

Explain how each table meets the 2NF definition (use field names and values)

Second Normal Form (2NF) - A relation that is in First Normal Form and every non-
primary-key attribute is fully functionally dependent on the primary key.

The normalization of 1NF relations to 2NF involves the removal of partial dependencies.
If a partial dependency exists, we remove the partially dependent attribute(s) from the
relation by placing them in a new relation along with a copy of their determinant.
(Thomas Connolly, Carolyn Begg, Database Systems: A Practical Approach to Design,
Implementation, and Management, 4th ed – 407 page)

BloodDonation

DrawNum Date Nvials PatId

D000010 13-May-20 3 P000100
D000020 13-May-20 3 P000200
D000030 13-May-20 2 P000300
D000040 13-May-20 3 P000400
D000050 14-May-20 4 P000500
D000060 14-May-20 2 P000100
D000070 14-May-20 3 P000600
D000080 14-May-20 3 P000700

Patient

PatId fName lName DOB ContactNum

P000100 Sally Smith 15-Jan-01 746-777-1111
P000200 John Jones 20-Jul-90 756-666-2222
P000300 Samuel Rosenberg 15-Mar-99 723-555-3333
P000400 John Baron 15-Apr-96 232-888-5555
P000500 Jane Jackson 18-Jan-03 232-777-6666
P000600 Nancy Johnson 15-Feb-02 243-333-4444
P000700 Nancy Johnson 05-Sep-02 273-111-2222

From my point of view data and above defined dependencies already satisfied rules for 2 NF. In
order to prepare for 3 NF we will create 2 tables.

One table is BloodDonation with key DrawNum. Other attributes are Date, Nvials and PatId
considering they full depend on key. Another one is Patient with key PatID and all other attributes
fName, lName, DOB, ContactNum which depend on unique key.
c) Third Normal Form (3NF) assessment / action  10%

Copy the 3NF definition from the text (include quotes and page number)

Assess the 2NF table(s) in the previous section and if necessary, make the changes needed to
conform to the 3NF definition. Explain any action taken and why.

Document the resulting 3NF table(s) using relational schema notation or spreadsheet format.
Explain how each table meets the 3NF definition (use field names and values)

Third Normal Form (3NF) - A relation that is in First and Second Normal Form and in
which no non-primary-key attribute is transitively dependent on the primary key.

The normalization of 2NF relations to 3NF involves the removal of transitive

dependencies. If a transitive dependency exists, we remove the transitively dependent
attribute(s) from the relation by placing the attribute(s) in a new relation along with a
copy of the determinant. (Thomas Connolly, Carolyn Begg, Database Systems: A
Practical Approach to Design, Implementation, and Management, 4th ed – 409 page)

BloodDonation

DrawNum Date Nvials PatId

D000010 13-May-20 3 P000100
D000020 13-May-20 3 P000200
D000030 13-May-20 2 P000300
D000040 13-May-20 3 P000400
D000050 14-May-20 4 P000500
D000060 14-May-20 2 P000100
D000070 14-May-20 3 P000600
D000080 14-May-20 3 P000700

Patient

PatId fName lName DOB ContactNum

P000100 Sally Smith 15-Jan-01 746-777-1111
P000200 John Jones 20-Jul-90 756-666-2222
P000300 Samuel Rosenberg 15-Mar-99 723-555-3333
P000400 John Baron 15-Apr-96 232-888-5555
P000500 Jane Jackson 18-Jan-03 232-777-6666
P000600 Nancy Johnson 15-Feb-02 243-333-4444
P000700 Nancy Johnson 05-Sep-02 273-111-2222

Following what we did above we can say with these 2 tables we already reached rule for 3NF.
There aren’t transitively dependent and wish to notice we also used online tool to confirm our
conclusions. http://www.ict.griffith.edu.au/~jw/normalization/ind.php
 Our attributes and defined dependencies

Find minimal cover – steps are below

Step 1: Rewrite the FD into those with only one attribute on RHS. We obtain:
DrawNum          Date   
DrawNum          Nvials   
DrawNum          PatId   
DrawNum          fName   
DrawNum          lName   
DrawNum          DOB   
DrawNum          ContactNum   
PatId          fName   
PatId          lName   
PatId          DOB   
PatId          ContactNum   

Step 2: Remove trivial FDs (those where the RHS is also in the LHS). We obtain:
DrawNum          Date   
DrawNum          Nvials   
DrawNum          PatId   
DrawNum          fName   
DrawNum          lName   
DrawNum          DOB   
DrawNum          ContactNum   
PatId          fName   
PatId          lName   
PatId          DOB   
PatId          ContactNum   

Step 3: Minimize LHS of each FD. We obtain:

DrawNum          Date   
DrawNum          Nvials   
DrawNum          PatId   
DrawNum          fName   
DrawNum          lName   
DrawNum          DOB   
DrawNum          ContactNum   
PatId          fName   
PatId          lName   
PatId          DOB   
PatId          ContactNum   

Step 4: Remove redundant FDs (those that are implied by others). We obtain:
DrawNum          Date   
DrawNum          Nvials   
DrawNum          PatId   
PatId          fName   
PatId          lName   
PatId          DOB   
PatId          ContactNum   
 Check confirm that we are already in 2 NF – steps are below

2NF

find all candidate keys. The candiates keys are { DrawNum}, The set of key attributes are:
{ DrawNum }
for each non-trivial FD, check whether the LHS is a proper subset of some candidate key or the
RHS are not all key attributes
checking FD: DrawNum --> Date,Nvials,PatId,fName,lName,DOB,ContactNum
checking FD: PatId --> fName,lName,DOB,ContactNum

3NF

find all cadnidate keys. The candiates keys are { DrawNum}, The set of key attributes are:
{ DrawNum }
for each FD, check whether the LHS is superkey or the RHS are all key attributes
checking functional dependency DrawNum --> Date,Nvials,PatId,fName,lName,DOB,ContactNum
checking functional dependency PatId --> fName,lName,DOB,ContactNum
The above FD violates definition of 3NF: it is non-trivial, LHS is not superkey, RHS contains a non-
key attribute.

BCNF

A table is in BCNF if and only if for every non-trivial FD, the LHS is a superkey.

The FD PatId --> fName,lName,DOB,ContactNum is non-trivial and its LHS is not a superkey. It
violates BCNF.
 3 NF – steps are below

Initially Tabel1 is the original table with the original functional dependencies.

In each round we check the FDs one by one to see if there is a violation of 3NF (there is a partial
or transitive dependency where the RHS includes non-key attributes). If yes, we decompose the
table into two.

Round1: checking table Tabel1

The table is not in 3NF.

Tabel2 = (PatId,fName,lName,DOB,ContactNum), with FDs:

PatId --> fName,lName,DOB,ContactNum

Tabel3 = (DrawNum,Date,Nvials,PatId), with FDs:

DrawNum --> PatId,Date,Nvials

Round2: checking table Tabel2

The table is in 3NF already, send it to output

Round3: checking table Tabel3

The table is in 3NF already, send it to output

5) Using the 3NF tables in your design, create an new MS Access database, load the sample data
provided, and ensure any table relationship are established.
Name your database Last Name_TermProject (i.e. Smith_TermProject). (5%).

Import initial excel table and save as InitialExcelTable. Create 2 tables BloodDonation and Patient.

Below is screen for relationship.

6) Create a Query, for the following request: List each Patient and their blood draws; include the
following fields PatID, fName, lName, DrawNum, date, and Nvials, sort Ascending by lName. Call
the Query BloodDraws. (5%)

Query result

7) Create a Form: for New Patient Input, label the form NewPatient. (5%)
Screen of form for one of existing records

Screen of form for insert new record

8) Create a Report: List all Blood Draws  (5%)

Screen of report

Upload the database to the assignment area as one of the deliverables

9) Submission content organization, clarity, spelling and grammar (10%)  

Contact the instructor with any questions. <o:p>