0% found this document useful (0 votes)
34 views

(JF) Tutorial 2 ER Modelling Solutions 24oct2020

The document contains sample questions and solutions for an ER modeling assignment. It includes ER diagrams showing entities like Company, Department, and Employee and their relationships. It also provides examples of partial and simplified ER diagrams to represent multiple entities and relationships. Sample entity attributes and cardinalities of relationships are defined.

Uploaded by

Ayaz Azeem
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views

(JF) Tutorial 2 ER Modelling Solutions 24oct2020

The document contains sample questions and solutions for an ER modeling assignment. It includes ER diagrams showing entities like Company, Department, and Employee and their relationships. It also provides examples of partial and simplified ER diagrams to represent multiple entities and relationships. Sample entity attributes and cardinalities of relationships are defined.

Uploaded by

Ayaz Azeem
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 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