Draw an Entity Relationship Data Model that describes the content and structure of the data held by Petcare. Specify the cardinality ratio and participation constraint of each relationship type.
Answer:
Draw an Entity Relationship Data Model
To design the database system for Petcare, we need to draw and Entity Relationship Diagram to show all and entities and the relationship between the enteritis. The ERD models the static relationships amongst this information that are preserved and maintained by the database. The ERD shows how items of data relate, statically, to each other.
1.1.1 Entities of the ERD
First step, we need to define the entities in the database.
According the requirement of the Petcare, the below entities should be involved in the database system to record the Petcare’s information;
– Information of the pet included the type, breed, sex, age and their owner
– Information of the pet owner included their name, address, home telephone number and mobile telephone number
– Information included the pet the appointment is for, the owner of the pet, the particular branches of Petcare, the attending veterinary Veterinarian and the date and time of the appointment.
– Information of the veterinary Veterinarian included their name, address, home telephone number, mobile telephone number, which branch they report to and their specialize.
– The outcome of the appointment which included the prescription and the charge made.
1.1.2 Entities relationship
Next step is to define the relationship of each entity. The relationship included Participation Constraint and Cardinality Ratio.
Participation Constraint
There are two types of participation constraint named ‘Total’ and ‘Partial’ participation.
A ‘Total’ participation (mandatory participation) constraint specifies that every member in the entity must participate as a member of another linked entity in the generalization.
A ‘Partial’ participation (optional participation) constraint specifies that a member of the entity does not belong to any member of another linked entity in the generalization.
Cardinality Ratio
Three types of cardinality is described as below:
One-to-one (1:1) – Relation between two entities which is linked each other with their primary key(s) only.
Many-to-many (M:N) – Relation between two entities which is linked each other without any primary key. It also have the chance to create the redundancy error.
Therefore it is better to break into two relations such as one-to-many and many-to-one.
One-to-many (1:M) or Many-to-one (M:1) – Relation between two entities which is linked each other from the primary key(s) to foreign key(s).
The relationship of Pet – The pet was raised by the owner; each pet should only have 1 owner but the owner can keep more then 1 pet. The owner also can keep difference kind of pets. There fore, the relationship of Pet and Owner is Total and one to many.
Relationship of Owner – The pet owner would make appointment with the Veterinarian. In the real case, an owner would make more then 1 appointment, also the Veterinarian also not handle 1 case only. A relational database is not allowed this condition. To solve the issue another entity ‘Appointment’ was added between Owner and Veterinarian. The Owner may make the appointment before visit the veterinarian, also they also can walk-in but without appointment. In order to simple the database design, we see the walk-in also as a new appointment. Therefore, the relationship of Owner and Appointment is Total and one to many.
Relationship of Appointment – the appointment was created by the pet owner and was handled be the Veterinarian. However, some Veterinarian may respond to the special case and would not handle the appointment. Therefore, the relationship of Appointment and Veterinarian is Partial and many to one relationship.
Relationship of Veterinarian – On the above we already mentioned a Veterinarian would attend more then one appointment. Also the Veterinarian would issue more then 1 diagnosis. Diagnosis is the outcome of the appointment which was issued by the veterinarian. The relationship of Veterinarian and Diagnosis is Total and one to many.
1.1.3 Entity Relationship Diagram (ERD)
According the above entities and relationship design we got the first ERD as below; The ERD was showed the logical database design of the Petcare. The ERD identifies a list of data elements that must be included in the database.
Fig. 1. The ERD of Petcare.
Task 2
Produce the resulting normalized tables clearly indicating the primary and foreign keys.
Answer:
Normalization
After complete the logical design of the database and draw the ERD, we can start the physical design of the database. The first thing is to create the table and define the data-set need to store in the database. A good database design should make the content of each table is only related to its own entity. In order to meet this requirement, normalization process should be implemented.
The normalization process needs step by step to transform the database and each step have specify name, called;
Un-normal Form – UNF
First Normal Form – 1NF
Second Normal Form – 2NF
Third Normal Form – 3NF
Boyce-Codd Normal Form – BCNF
The below steps should be carried out for the normalization.
Collect the data-set
Transform the un-normalized form tables into first normal form
Transform the first normal form tables to second normal form
Transform the second normal form tables to third normal form
First Normal Form (1NF)
According the ERD design and the requirement of Petcare, the Tables of the database were created as below; also some attributes were added to indentify the data-sets, e.g. PetID, which attributes also the Primary of the table.
Fig. 2. The Un-normal Form table
The above tables were included all requested data and information requested by Petcare. However, some of attributes are the same in difference tables. The tables are a un-normal form table. We need to make the content of each table is only related to its own entity. Therefore the normalization process should be implemented.
The first step is transforming the un-nornalized form table into first normal form. The definition of first normal form is ‘all non-key attributes in relation is if, and only if, functionally dependent upon primary key.
According the definition of first normal form, we should avulse the non-key attributes which are not relate to the primary key and create another table for this attribute.
For example; in the table Veterinarian, the Branch and Specialise are not related to the Primary key, so we need avulse these attributes and create another table, Branch & Specialise. Another table Diagnosis also the same issue.
Fig. 3. Normalized table
Fig. 4 Normalized table 2
After the process of first normalized, we got the First Normal Form table as below;
Fig. 5. First Normal Form table
Second Normal Form (2NF)
The second step is transfer first normal form to second normal form. The definition of second normal form is ‘all relations are, and only if, it is in first normal form and every non-key attribute are fully functionally dependent on the primary key.
After second normalization, we got the below tables;
Fig. 6. Second Normalized tables
Third Normal Form (3NF)
The definition of third normal form is ‘all relations are if, and only if, it is in second normal form and every non-key attributes in nor-transitively dependent on the primary key. Because the second normalized tables already meet the equipment. Therefore, it is third normal form.
Primary Key and Foreign Key
The next step to design the physical database is defining the Primary Key and the Foreign key. This step also defining the relationship of each table. The Primary Key is used to identify the record in each table. The Foreign Key is the key attribute to link other table.
The final normalized table with details relationship, Primary key and Foreign key were showed on the below diagram.
Fig. 7. Final table design
Data Dictionary
The last step of design the database is define the property of each attribute. The property of attribute is design the coding of the attribute. A good coding design is very important because a good coding design can let use easy to understand and take less mistake when input the data, and also determined the usability and extensibility of the database.
A good coding design should meet below requirements;
Uniqueness – only one value of the code may be applied to an entity.
Expandability – must have sufficient space for the entry of new items.
Conciseness – should use the minimum number of characters to define each item.
Uniform size & format – no addition of prefixes or suffixes.
Simplicity – simple to apply and understand.
Versatility – easy to modify for changes in conditions.
Sortability – may not be the code itself as long as it can be correlated with a sortable code.
Stability – should not need regular updating as this is costly.
Meaningful – in some circumstances it is useful for the code to reflect the characteristics of the coded entities.
Operability – the code should be sufficient to meet the current and future needs of data identification but also minimise the clerical and system resources required to operate it.
Other then the coding design, the sequence of table create also very important as the table may has relation with other tables. We should first create the table which has not relate to other tables, then create the table relate to this table. The sequence of table create list as the sequence of the Data dictionary.
According the above requirements, the tables and attributes were created and the details were listed on the Data Dictionary below;
Data Dictionary of Petcard
Table Name
Field Name
Type
Size
Status
Description
Owner
OwnerID
char
6
PK
The ID of owner
　
O_Name
char
30
Not NULL
Name of owner
　
O_Address
varchar
100
NULL
Address of owner
　
O_Phone
char
15
NULL
Phone number of owner
　
O_Mobile
char
15
NULL
Mobile number of owner
　
　
　
　
　
　
PetType
TypeID
char
1
PK
The ID of pet type
　
P_Type
char
15
Not NULL
name of pet type
　
　
　
　
　
　
Breed
BreedID
char
2
PK
The ID of breed type
　
B_type
char
15
Not NULL
Name of Breed type
　
TypeID
char
1
FK
relate to PetType
　
　
　
　
　
　
Pet
PetID
char
6
PK
The ID of the Pet
　
OwnerID
char
6
FK
relate to Owner
　
PetName
char
20
Not NULL
Name of the pet
　
Sex
char
1
Not NULL
sex of the pet
　
Age
numeric
2
Not NULL
age of the pet
　
Breedid
char
2
FK
relate to Breed
　
　
　
　
　
　
Branch
BranchID
char
1
PK
The ID of branch
　
B_Name
char
15
Not NULL
Name of branch
　
B_Address
char
50
Not NULL
Address of branch
　
B_Phone
char
15
Not NULL
Phone number of branch
　
　
　
　
　
　
Specialisation
SpeID
char
2
PK
The ID of specialize
　
Specialise
char
10
Not NULL
Name of the specialization
　
　
　
　
　
　
Veterinarian
VetID
char
3
PK
The ID of veterinaria
　
V_Name
char
30
Not NULL
Name of veterinaria
　
V_Address
varchar
100
Not NULL
Address of veterinaria
　
V-Phone
char
15
Not NULL
Phone number of veterinaria
　
V_Mobile
char
15
Not NULL
Mobile number of veterinaria
　
SpecID
char
2
FK
relate to Specialisation
　
BranchID
char
1
Not NULL
The branch of the veterinaria is working
　
　
　
　
　
　
Appointment
AppID
char
10
PK
The ID of appointment
　
VetID
char
3
FK
relate to Veterinarian
　
OwnerID
char
6
FK
relate to owner
　
BranchID
char
1
FK
relate to Branch
　
PetID
char
6
FK
relate to Pet
　
Date
date
8
Not NULL
date of appointment
　
Time
time
4
Not NULL
time of appointment
　
　
　
　
　
　
Drug Type
D_TypeID
char
2
PK
The ID of Drug Type
　
D_Type
char
20
Not NULL
Name of drug type
　
　
　
　
　
　
Drug
DrugID
char
4
PK
The ID of drug
　
D_typeID
char
2
FK
relate to DrugType
　
DrugName
char
30
Not NULL
Name of the drug
　
Category
char
20
Not NULL
How to use the drug
　
Period
char
2
Not NULL
Number of day to use the drug
　
　
　
　
　
　
Prescription
PrescID
char
10
PK
The ID of Prescription
　
Drug1
char
4
FK
relate to Drug
　
Drug2
char
4
FK
relate to Drug
　
Drug3
char
4
FK
relate to Drug
　
　
　
　
　
　
Diagnosis
DiagID
char
6
PK
The ID of diagnosis
　
VelID
char
3
FK
relate to Velerinarian
　
PrescID
char
10
FK
relate to Prescription
Price
Numeric
6
Not NULL
The price of diagnosis
Task 3
Using a Database Management System (DBMS) set-up all of the above normalized tables, and populate them with well-designed test data..
Answer:
Create tables on DBMS
After completely designed the database, we should start to create it. Concerning to popularity and easy to use, we determined to use Microsoft Access as the Database Management System (DBMS) of the Petcare database. We should use SQL command to create the tables, attributes and relationships of tables.
Create tables
The SQL command of create tables was lists below;
Create the table Owner
CREATE TABLE Owner
(OwnerID CHAR(6) PRIMARY KEY,
O_Name CHAR(30),
O_Address VARCHAR(100),
O_Phone CHAR(15),
O_Mobile CHAR(15) );
Create the table PetType
CREATE TABLE PetType
(TypeID CHAR(1) PRIMARY KEY,
P_Type CHAR(15) );
Create the table Breed
CREATE TABLE Breed
(BreedID CHAR(2) PRIMARY KEY,
B_type CHAR(15),
TypeID CHAR(1) REFERENCES PetType(TypeID) ON DELETE CASCADE ON UPDATE CASCADE );
Create the table PetType
CREATE TABLE Pet
(PetID CHAR(6) PRIMARY KEY,
OwnerID CHAR(6) REFERENCES Owner(OwnerID) ON DELETE CASCADE ON UPDATE CASCADE,
PetName CHAR(20),
Sex CHAR(1),
Age NUMERIC(2)
BreedID CHAR(2) REFERENCES Breed(BreedID) ON DELETE CASCADE ON UPDATE CASCADE );
All the tables also used the similar SQL command to create, we would not repeat all there. After all tables, attributes and relationships were created. The whole table diagram was showed as below figure;.
Fig. 8. Tables in MS Access
Test Data
After the table creation finished. We should input the test data to the database to test the database functioned as expended. We would input at least 5 records to each table.
The below screen showed the test data of all tables;
Fig. 9. Table Owner, Pet, PetType, Breed
Fig. 10. Table Veterinarian, Specialization, Appointment, Branch
Fig. 11. Table Prescription, Diagnosis, Drug, DrugType
The Printout of tables please refers to appendix.
Task 4
Set-up and test all of the following queries using Structured Query Language (SQL).
Answer:
Set-up test queries
In order to test the database design and data input correct, we need to query the data form the database. The below 2 case can test the database meet the Petcare’s requirements.
Query 1
Requirement:
Display the names and addresses of the branches of Petcare and the names of all the veterinary doctors working at each of the branches. Any specialism(s) of the veterinary doctors should also be shown.
This is a very general query in database, to goal the requirement we need to the join the Branch, Veterinarian and Specialization 3 tables and select the requested data. The query statement and result were listed below;
SELECT
Branch.b_name AS Branch,
Branch.b_address AS Address,
Veterinarian.v_name AS VetName,
Specialization.specialise AS Specialization
FROM
(Branch INNER JOIN Veterinarian ON Branch.branchid=Veterinarian.branchid)
INNER JOIN Specialization ON Veterinarian.SpecID=Specialization.SpecID
ORDER BY Branch.b_name;
Fig. 12. Result of Query 1.
Query 2
Requirement:
Display all the appointments for the whole of the Petcare organization. This should be ordered by date. The result should display the branch the appointment is at, the name of the veterinary doctor the appointment is with, the date and time of the appointment, the name of the animal the appointment is for, the type of animal and the breed of the animal.
Case two is more difficulty; we need to join Appointment, Branch, Veterinary, Pet, PetType and Breed total 6 tables. The query is very complex and easy to make mistake. The query statement and query results were showed below;
SELECT
Branch.b_name AS Branch,
Veterinarian.v_name AS VetName,
Appointment.date,
Appointment.time,
Pet.petname AS PetName,
PetType.P_Type AS Type,
Breed.breed AS Breed
FROM
((((Appointment INNER JOIN Veterinarian ON Appointment.vetid=Veterinarian.vetid)
INNER JOIN Branch ON Veterinarian.branchid=Branch.branchid)
INNER JOIN Pet ON Appointment.petid=Pet.petid)
INNER JOIN Breed ON Pet.breedid=Breed.breedid)
INNER JOIN PetType ON Breed.TypeID=PetType.TypeID)
ORDER BY Appointment.date;
Fig. 13. Result of query 2
Task 5
Explain any assumptions you have made when analyzing, designing and implementing the above database..
Answer:
Assumption and alternative
Each appointment ID is for one pet only. Same owner bring more than 1 pets to Petcare whould see as a new appointment.
One prescription maximum list 3 drugs. Normally 3 drugs are enough for 1 case. If the pet has more than 1 issue need more then 3 drugs, veterinary should open multi prescription for difference type of drugs. E.g. need skin medication & Painkiller.
Walk-in also sees as a new appointment.
Work Improvement
In this assignment, the database system for PatCare has not included the user interface. The database system is used for store data and the DBMS is used for manager the database or it can be sees as a bridge of Database and User interface. DBMS is not designed for user, it mainly use command line to manager the database and query the data. Even some new DBMS; system such as MS Access and SQL have GUI but also hard for a normal user to use the database and query data.
In order to let users easy to use the database, User Interface is a must. The user interface let user easy to input data, update records and check the records. And also we can per-set some forms and reports for user print out.
The user interface not need very gorgeous or complex. A good user interface is simple, convenient and easy to understand and easy to use. We should design a web base interface because the web base interface is simple and easy to manage. The most important is the web base interface does not need install additional programs, therefore not additional budget for buy other applications.
Cite This Work
To export a reference to this article please select a referencing style below:
