(JF) Tutorial 2 ER Modelling Solutions 24oct2020

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 14

PgD/MSc IT

Database Design Comp11007


Tutorial Two – ER Modelling: Solutions
Question One – ER diagrams

a)
Company operates Department
1..1 *..*

employs
b) Department Employee
1..1 1..*

c) has
Employee hhas Dependent
1..1 0..*

Question Two – ER diagram

Company operates Department


1..1 *..*
1..1

employs
1..*
Dependent has Employee
0..* 1..1
Question Three
a) Entities and their attributes

Product {prodNo, description, price, cost, stock, reorderLevel, reorderQty}


prodNo: unique

Customer {custNo, name (firstName, lastName), address(street, city, postcode), phone, credit}
CustNo: unique
name, address: composite

Order {orderNo, status, dateDue, totalPrice }


orderNo: unique

b) Relationships and their attributes


Places {(Customer, Order)}
 Not every customer (min: 0) places an order but may place more than one order (max: *).
 Every order is placed by at least one Customer (min:1) and at most one Customer (max: 1).
 Cadinality ratio: (1:*). 'Places' is a one-to-many relationship.

Requests {(Order, Product)}; Attribute: quantity


 Every order requests one (min: 1) or more product (max: *).
 Not every product (min: 0) is requested in an order, but may be requested in more than one order (max: *).
 Cardinality ratio: (*:*). 'Requests' is many-to-many relationship.

HasComponent {(Product (as main product), Product (as Component product))}


 Not every product has components (min: 0), but may have many components (max: *).
 Not every product is a component of some product (min: 0) but can be a component of one product (max: 1).
 Cardinality ratio: (1:*). 'HasComponent' is one-to-many recursive relationship.
c) ER diagram (option A)

compProduct
0..*
HasComponent Product
Order
mainProduct prodNo{PK}
description Requests orderNo{PK}
0..1 price
1..* 0..* dateDue
cost totalPrice
stock quantity status
reorderLevel
recorderQty 0..*

Places
1..1
Customer
custNo{PK}
name
firstName
lastName
address
city
street
postCode
phone
credit
Option B:
If we have many entities and many relationships it is difficult to draw an ER diagram on a single page. In such cases:
 Draw partial ER diagrams of entities and their attributes;
 Draw a simplified ‘global’ ER diagram showing:
 Entities and a single attribute (primary key);
 Relationships, structural constraints, and attributes (if any);

d) Partial ER diagrams

Customer
Product Order
custNo{PK}
prodNo{PK} orderNo{PK} name
description dateDue firstName
price totalPrice lastName
cost status address
stock
city
reorderLevel
street
recorderQty
postCode
phone
credit
e) Simplifed ER diagram

compProduct
0..*
Product Order
HasComponent Requests
prodNo orderNo
mainProduct
1..* 0..*
0..1
quantity 0..*
Places

1..1
Customer
custNo
Question Four
a) Entities and their attributes

PrintJob {jobNo, description, startDate, completionDate, cost}


jobNo – unique

Publisher {name, address (town, street, postcode), phoneNo, faxNo, webAddress, eamilAddress}
name, phoneNo, faxNo, webAddress, emailAddress – unique
address – composite

PurchaseOrder {orderNo, orderDate, status, totalCost}


orderNo – unique

PrintItem {itemCode, name, description}


itemCode, name – unique

Employee {empNo, name (fName, lName), address, gender, dob, salary}


empNo – unique
name – composite

Book {ISBN, title, yearOfPublication, price, authors}


ISBN – unique
authors – multi-valued

b) Relationships and their attributes

Requests {(Publisher, PrintJob)}


 Each publisher (min: 1) request one or more (max: *) print jobs;
 Every print job (min: 1) is requested by one (max: 1) publisher at most;
 Cardinality ratio: 1:*
Places {(PrintJob, PurchaseOrder)}
 Each print job (min: 1) places one or more (max: *) purchase orders;
 Every purchase order is placed by at least one (min: 1) and at most one (max: 1) print job;
 Cardinality ratio: 1:*

RequestItem {(PurchaseOrder, printItem)}; Attribute: quantity


 Each purchase order (min: 1) requests one or more (max: *) print items;
 Not every print item (min: 0) is requested but may be requested by many (max: *) purchase orders;
 Cardinality ratio: *:*

AssignedTo {(PrintJob, Employee)}


 Each print job (min: 1) is assigned to one or more (max: *) employees;
 Not every employee (min: 0) is assigned to a print job but may be assigned to many (max: *) print jobs;
 Cardinality ratio: *:*

Publishes {(Publisher, Book)}


 Each publisher (min: 1) publishes many (max: *) books;
 Every book (min: 1) is published by one (max: 1) publisher;
 Cardinality ratio: 1:*
c) Partial ER diagrams

Publisher PurchaseOrder Employee


PrintJob
name{PK} orderNo{PK} empNo{PK}
jobNo{PK}
address orderDate name
description
town status fName
startDate
street totalCost lName
completionDate
postcode address
cost
phoneNo{AK} gender
faxNo{AK} dob
webAddress{AK} salary
emailAddress{AK}

PrintItem Book

itemCode{PK} ISBN{PK}
name{AK} Title
description yearOfPublication
price
authors[1..*]
d) Simplified ER diagram

Publisher Requests PrintJob Places PurchaseOrder

name 1..1 1..* jobNo 1..1 1..* orderNo

1..1 0..* 0..*

AssignedTo RequestItem quantity


Publishes

1..* 1..* 1..*


Book Employee PrintItem

ISBN empNo itemCode


Question Five
a)
i) Entities and their attributes
Instructor {nin, phone, name (fName, lName), dob}
nin - unique
name - composite;

ResearchProject {title (unique)}

TeachingTeam {teamNo (unique)}

Course {code (unique)}

TrainingSession {sessionNo (unique)}

Trainee {matricNo (unique)}


ii) Relationships and their attributes

Assigned {(Instructor, ResearchProject)}


 An instructor may be assigned to do a research project, so (min: 0) and (max: 1).
 Each research project is performed by one instructor only, so (min: 1) and (max: 1).
 Cardinality ratio: (1:1). 'Assigned' is one-to-one relationship.

PartOf {(Instructor, TeachingTeam)}


 ‘An instructor is assigned to a maximum of two teaching teams or may be assigned to do a research project’, which means that not
every instructor (min: 0) is part of a teaching team but can be member of up to two teaching teams (max: 2).
 Each teaching team can consist of up to 4 instructors so (min: 1) and (max: 4)
 Cardinality ratio: (*:*). 'PartOf' is many-to-many relationship.

Teaches {(TeachingTeam, Course)}


 Each teaching team teaches one (min: 1) or more than one course (max: *).
 Every course is taught by only one teaching team, so (min: 1) and (max: 1)
 Cardinality ratio: (1:*). 'Teaches' is one-to-many relationship.

OfferedIn {(Course, TrainingSession)}


 Every course is offered in more than one training session, so (min: *) and (max: *).
 Every training session offers one (min: 1) or more than one course (max: *).
 Cardinality ratio: (*:*). 'OfferedIn' is many-to-many relationship.

Joins {(Trainee, TrainingSession)}


 A trainee must join more than one training session, so (min: *) and (max: *).
 Every training session accommodates up to 100 trainees so (min: 1) and (max: 100).
 Cardinality ratio: (*:*). 'Joins' is many-to-many relationship.
iii) ER diagram
b) Instructor Assigned ResearchProject
No, because the pathway between Trainee and Course is ambiguous. There is a Fan trap between Trainee, TrainingSession, and
nin{PK} 1..1 0..1 title
Course.
name
fName
lName
dob
phone

1..4

PartOf

0..2
TeachingTeam Course OferedIn TrainingSession
Teaches
teamNo 1..1 1..* code 1..* *..* sessionNo
*..*
Joinstake. But we still cannot
Creating a relationship between the TRAINEE and COURSE we can answer the question: which courses did a trainee
answer the second question: which courses did he/she take and in which session? 1..100

To answer the second question, we need to remove the Fan trap by creating a ternary relationship betweenTrainee
Trainee, TrainingSession and course.
This will replace the two many-to-many ( *:*) relationships (OfferedIn, and Joins). matricNo

For further thinking: will the loss of the two binary relationships result in information loss, for example, we can no long capture what training
session a trainee joins?
c) Fan trap removed

Instructor Assigned ResearchProject


nin {PK} 1..1 0..1 title
name
fName
lName
dob
phone
1..4
PartOf
0..2
TeachingTeam Teaches Course
teamNo 1..1 1..* code

TrainingSession Trainee
sessionNo T-C-T
matricNo

You might also like