University of Manitoba

Asper School of Business

3500 DBMS
Bob Travica

Chapter 2
Database System Design

Based on G. Post, DBMS: Designing & Building Business Applications

Updated 2010

1
D Development Activities
B Analysis Design ( Logical, Physical )
Implement-
ation
Business & Create Adjust data model to Design
information data model. a database storage &

S needs.

Pros & cons.

technology
(e.g., relational).
input/output.

Y
S System
Class diagram
(classes &
List or diagram of
normalized tables
Specifications
for storage &
access methods
T require-
ments.
relationships)
and write
business rules.
(schema). (indexes), and
forms & reports

E Business
case.
Customer( CID, Name, …)
SalesPerson(EID, Name..)

M Order(OrderID, EID, CID,

OrderDate..)

S
2 of 18
D Unified Modeling Language (UML)
B Trendy notation for analyzing systems and often used with the
object orientation (OO) approach.

S Contains specific diagramming techniques:

Class diagram

Y Use case diagram

A static model of classes and their relationships

Shows actors (users) and system functions.

S Sequence diagram Interactions among objects with a timeline indicated.

Activity diagrams The steps within a function (or procedure, use case).

T Implementation diagrams The structure of the code or of the run-time modules.

E The class diagram is most important for DB systems.

M Similar to the old Entity-Relationship diagram (E-R diagram).

S
3 of 18
D Class Diagram – Concepts
B
Entity: The “thing” in the real world tracked by the system.

S Class: Description of an entity, that includes its attributes

(properties) and behavior (methods, procedures).
Y Object: One instance of a class with specific data; a record.
S Attribute: A characteristic, an aspect, some quality that
describes a class or entity.
T Behavior: Procedures (methods, processes, functions)
E performed by the class.

M Association: A relationship between classes.

S
4 of 18
D
B Examples from Pet Store Application

Entity: Customer
S Class: Customer, includes attributes and behavior (below)

Y Object: 12257, Joe Jones... (a specific customer)

S Attributes: CustID, Name...

Behavior: AddCustomer, DeleteCustomer...

T Association: Customer is related to orders that he/she places.
E
M
S
5 of 18
D Associations
B  Associations (Relationships) represent business rules
Sometimes common-sense rules (Figure A)

S (A) Customer Order

Y places 

S Sometimes rules unique to an organization (Figure B)

T
Product Search
(B) Customer Profile

 belongs to
E
NOTE: Assumed way of reading is left-right and top-down.
M If the relationship is drawn that way, the arrowhead is not necessary.
Arrowheads help when these rules are not followed (Figure B).
S
6 of 18
D Degree of Association
B According to Number of classes:

 Between 2 classes (previous slide; most used, most

S important!) - binary
 Between 3 or more classes – N-ary
Y  Class with itself (below) - unary
S manages

T worker

E Employee manager

M
S
7 of 18
D Multiplicity (Cardinality) of Associations
B
• Specification of the number of objects participating in a relationship.

Example:
S An employee must work in only one department, and one (each)
department has one or more workers.
Y
1..*
S Employee
works in
1..1 Department

T • Just maximum multiplicity is often used, and relationships are

named after it.
E Example: many-to-one (M:1) relationship

M * 1 Department

S
Employee
works in

8 of 18
D Types of Associations based on
B Multiplicity

S  One-to-many (1:M)

- examples: Customer—Order, Client—Account

Y
 Many-to-many (M:N)
S
- examples: Order—Item, Student—Course
T
 One-to-one (1:1)
E
- example: Customer—BillingAddress
M
S
9 of 18
D Procedure for Determining Multiplicity
(Form A)
B 1. Ask the multiplicity question:
One (each) object on the left side of the association is
associated with how many objects on the right side?
S Minimally, maximally?

Y Employee Department

S
works in

T 2. Write the numbers/asterisks on the right side.

E Employee
1 .. 1
Department

M works in

S And… 
10 of 18
D
B 3. Ask the same question from the other side of the
relationship:
One (each) object on the right side of the association is
associated with how many objects on the left side?
S Minimally, maximally?

Y Employee
1..1 Department

S <employs

4. Write the numbers/asterisks on the

T left side.

E 1..* 1..1
M Employee Department
<employs

S Note: You have to know multiplicity question by heart!

Or 
11 of 18
D Procedure for Determining Multiplicity
(Form B)
B
1..* 1..1 Department
Employee

S works in 

Y 1. How many objects on the left side are associated with

S one (each) object on the right side?

2. Write the numbers/asterisks of the left side.

T
3. How many objects on the right side are associated with
E one (each) object on the left side?
M 4. Write the numbers/asterisks on the right side.
S
Note: We usually specify just maximum multiplicity.
12 of 18
D
Notation for Multiplicity
B
 Multiplicity options:
Customer
 0 (zero)
S  1 (one)
1..1

places
Y  * (many); in older notations – M, N
 specific number, if known (3, 10); e.g., in
S part-whole relationship
Order
1..*

T 0..*

E Order_Item contains

M 1..*

Item
S .

NOTE: Some imprecision on Fig. 2.7 on p. 39 (3 rd ed.); Fig 2.8 on p 46 (4th ed.). 13 of 18
D Business Rules for Cardinality - Read/Write
B Business Rules:
 1) One customer can place one or Customer
more orders,
S and each order is placed by
1..1

one places
Y and only one customer.

S  2) Each order can contain one or

1..*

Order
more items,
T and an item can be listed on no 0..*
order or on many orders. contains
E Order_Item

M • If min. multiplicity >= 1, association is mandatory;

• If min. multiplicity = 0, association is optional.
1..*

Item
S .

14 of 18
D N-ary Association
B
*
Employee
*
*
S Component
* *
* Product
Y
S
 Degree of association >= 3.

 Components are built into Products by Employees.

T Or, Products contain Components built in by Employees.

E  Support to inventory scheduling, quality control, performance

measurement.

M  But, the data model is not complete as shown!

S
NOTE: Some imprecision on Fig. 2.8 on p. 40 (3 rd Ed.); Fig 2.9 on p. 46 (4th ed.). 15 of 18
D N-ary Association with Associative Class

B N-ary associative class Employee

Assembly introduced. EmployeeID
Name
Each Assembly record
Name
S
lists one employee, one ProductID
component, and one A3222 Corvette
product. A5411 Camaro

Y Component
ComponetID
Assembly Product
ProductID
S Type
Name
Name

T Assembly
EmployeeID
E ProductID
CompID

M
S
16 of 18
D N-ary Association

B Classes “loose” direct

Employee
EmployeeID
relationships and get related Name
via the association class
Assembly, each creating a 1:M
1 Name
S relationship with Assembly. ProductID
A3222 Corvette
*
A5411 Camaro

Y Component
ComponentID
1 * Assembly * 1
Product
ProductID
S Type
Name
Name

T Assembly
EmployeeID
E CompID
ProductID

M
S
17 of 18
D
Focus on Keys: Generic vs. Unique
B
 Product: specific model of car (ProductID is generic key

S signifying a group of things)

 Component: car door (ComponentID is a generic key)
Y  Employee: assembly worker (EmoployeeID is a unique key
S signifying a specific person)

T  Note: The N-nary design in previous slides can be improved by

using unique keys (e.g., serial numbers) for products and
E components. This would make it completely clear what worker
builds a specific component in a specific car (see Assembly
M rows with values 11, 563, A3222 and 12, 563, A3222).
S
18 of 18