Solution - Department of Informatics
Solution - Department of Informatics
Solution - Department of Informatics
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
5CCS02DB Database Systems<br />
Lecturer: Sophia Tsoka<br />
Teaching Assistants: Yiannis Siantos, Christos Hadjinikolis<br />
October 14, 2013 – 3rd Tutorial <strong>Solution</strong>s<br />
Exercise 1. Consider the following set <strong>of</strong> requirements for a university database that is used to<br />
keep track <strong>of</strong> students transcripts.<br />
• The university keeps track <strong>of</strong> each students name, student number, social security number,<br />
current address and phone, permanent address and phone, birth date, gender, year <strong>of</strong> study<br />
(1st year, 2nd year etc). Some user applications need to refer to the city, and post code<br />
<strong>of</strong> the students permanent address, and to the students last name. Both social security<br />
number and student number have unique values for each student.<br />
• Each department is described by a name, department code, <strong>of</strong>fice number, <strong>of</strong>fice phone,<br />
and college. Both name and code have unique values for each department.<br />
• Each course has a course name, description, course number, number <strong>of</strong> semester hours,<br />
level, and <strong>of</strong>fering department. The value <strong>of</strong> course number is unique for each course.<br />
Some courses may be <strong>of</strong>fered by multiple departments (e.g. interdisciplinary courses).<br />
• Each section has an instructor, semester, year, course, and section number. The section<br />
number distinguishes different sections <strong>of</strong> the same course that are taught during the same<br />
semester/year; its values are 1, 2, 3, ...; up to the number <strong>of</strong> sections taught during each<br />
semester.<br />
• Each section may be part <strong>of</strong> multiple courses.<br />
course <strong>of</strong>fering them<br />
Sections are only identified through the<br />
• Each student belongs to a major department and optionally to a minor department and is<br />
following a single course (e.g. B.A. in Music, B.Sc. in <strong>Informatics</strong> etc).<br />
Design an ER schema for this application, and draw an ER diagram for that schema. Specify<br />
key attributes <strong>of</strong> each entity type and structural constraints on each relationship type. Note any<br />
unspecified requirements, and make appropriate assumptions to make the specification complete.<br />
On Page 2 you may find the updated solution. Note that since we have chosen to represent<br />
cardinalities the way they are represented, then total participation relationships need to be<br />
specified.<br />
1
Answer.<br />
Current Phone<br />
Permanent Phone<br />
Student Number<br />
Name<br />
SSN<br />
Build. Name/Number<br />
Date Of Birth<br />
Student<br />
1<br />
Major<br />
Post Code<br />
Current Address<br />
Year<br />
Address<br />
Gender<br />
1<br />
1<br />
Full Address<br />
City<br />
Country<br />
Minor<br />
Follows<br />
N<br />
2<br />
N<br />
Number<br />
Semester<br />
Level<br />
CNumber<br />
Phone<br />
Name<br />
N<br />
Section<br />
N<br />
Course Section<br />
N<br />
Course<br />
N<br />
Offers<br />
N<br />
<strong>Department</strong><br />
Number<br />
Year<br />
Instructor<br />
Name<br />
Description<br />
Hours<br />
Office
Exercise 2. Convert the E-R diagram <strong>of</strong> exercise 1, from tutorial 2, to a relational database<br />
schema.<br />
State any key, entity, referential integrity, domain and semantic constraints that are applicable.<br />
The domain constraints do not need to be precise (i.e. “String” is sufficient to specify that<br />
something is a string, we do not need to specify maximum lengths at this point).<br />
Answer. Entity Integrity Constraints: Entity Keys will be underlined. Relationship keys<br />
are composite keys consisting <strong>of</strong> the primary key <strong>of</strong> each <strong>of</strong> the entities which participate in the<br />
relationship.<br />
Referential Integrity Constraints: Foreign Keys are Double Underlined. The way they<br />
are named is < tableName > < attributeName >.<br />
Domain Constraints: Will be specified next to each attribute name.<br />
Semantic Constraints: Doctor.DOB, Patient.DOB, Contract.StartDate should all be past<br />
dates.<br />
Specialities should be actual doctor specialities (i.e. not just any string). We will also assume<br />
that a doctor can have multiple specialities.<br />
All the characters <strong>of</strong> Company.Phone and Pharmacy.Phone should be numbers with the<br />
exception <strong>of</strong> the first character which may be “+”<br />
3
Patient<br />
ID:Integer First Name:String Last Name:String DOB:Date Doctor SSN:Integer<br />
Doctor<br />
SSN:Integer First Name:String Last Name:String DOB:Date Start Date:Date<br />
Doctor Speciality<br />
Doctor SSN:Integer Speciality:Speciality String<br />
Medicine<br />
Name:String<br />
Active Ingredient:String<br />
Company<br />
Name:String<br />
Phone:String<br />
Pharmacy<br />
Name:String Phone:String Buiding Name-Number:String Post Code:String<br />
Doctor Prescribes Medicine To Patient<br />
Patient Id:Integer Doctor SSN:Integer Medicine Name:String<br />
Pharmacy Sells Medicine<br />
Pharmacy Name:String Medicine Name:String Price : Currency<br />
Company Manufactures Medicine<br />
Pharmacy Name:String Medicine Name:String<br />
Pharmacy Contracts Company<br />
Pharmacy Name:String Company Name:String Start Date:Date End Date:Date Contents:String<br />
4