Chapter 2

Database System Design

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

University of ManitobaAsper School of Business

3500 DBMSBob Travica

Updated 2015

DDBB

SSYYSSTTEEMMSS

DBS Development

Specifications for storage & access methods (indexes), and forms & reports

Class diagram (classes & relationships) and write business rules.

Business &information needs.

Pros & cons.

Systemrequire-ments.

Businesscase.

Analysis

Create data model.

Customer(CID, Name,..)

SalesPerson(EID, Name..)

Order(OrderID, EID, CID, OrderDate..)

Adjust data model toa database technology(e.g., relational).

Designstorage &input/output.

List or diagram of normalized tables (schema).

Design ( Logical, Physical ) ConstructionT

AS

KR

ES

ULT

2 of 17

DDBB

SSYYSSTTEEMMSS

Unified Modeling Language (UML)

Trendy notation for analyzing systems and often used with the object orientation (OO) approach.

Contains specific sorts of diagrams:

• The class diagram is most important for DB systems.

• Similar to the old Entity-Relationship diagram (E-R diagram) but more compact.

Class diagram A static model of classes and their relationships

Use case diagram Shows actors (users) and system functions.

Sequence diagram Interactions among objects with a timeline indicated.

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

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

3 of 17

DDBB

SSYYSSTTEEMMSS

Class Diagram – Concepts

Entity: The aspect of reality recorded in the system.

Class: Description of an entity, which includes its attributes (properties) and behavior (methods, procedures).

Object: One instance of a class with specific data; a record in a database.

Attribute: A data property of a class; an aspects of an entity.

Behavior: Procedures (methods, processes, functions) performed by the class.

Association: A connection between classes or between entities.

4 of 17

DDBB

SSYYSSTTEEMMSS

Entity: Customer

Class: Customer, includes attributes and behavior (below)

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

Attributes: CustID, Name...

Behavior: AddCustomer, DeleteCustomer... (CRUD)

Association: Class Customer is related to class Order reflecting relationship between entities Customer and Order.

Examples from Pet Store Application

5 of 17

DDBB

SSYYSSTTEEMMSS

Associations

Associations (Relationships) reflect business specified in business rules*

Sometimes common-sense rules (Figure A)

NOTE: Assumed way of reading is left-right and top-down. If the relationship is drawn that way, the arrowhead is not necessary. Arrowheads needed when these rules are not followed (Figure B).

places

(A) Customer Order

belongs to

(B) Customer Product Search Profile

Sometimes rules unique to an organization (Figure B)

6 of 17

DDBB

SSYYSSTTEEMMSS

Association Degree refers to the number of classes involved in an association:

1) Class with itself – unary (below); rare

Degree of Association

Employee manager

worker

manages

2) Between 2 classes – binary (previous slide); most frequent and most important!)

3) Between 3 or more classes – N-ary; rare

7 of 17

DDBB

SSYYSSTTEEMMSS

Example: An employee must work in only one department, and one (each) department has one or more employees.

Multiplicity (Cardinality*) of Associations

• Multiplicity refers to the number of objects participating in a relationship.

DepartmentEmployee

works in

1..11..*

• Just maximum multiplicity is often used, and associations are

classified on it as well.

DepartmentEmployee

works in

1*

Example: many-to-one (M:1) relationship

8 of 17

DDBB

SSYYSSTTEEMMSS

One-to-many (1:M)

- examples: Customer—Order, Client—Account

Many-to-many (M:N)

- examples: Order—Item, Student—Course

One-to-one (1:1)

- example: Customer—BillingAddress, Citizen--

SocaiInsuranceUser (IncomeTaxPayer…)

Types of Associations based on Multiplicity

9 of 17

DDBB

SSYYSSTTEEMMSS

Procedure for Determining Multiplicity (Form A question)

And…

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?

Minimally, maximally?

DepartmentEmployee

works in

DepartmentEmployee

works in

1 .. 1

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

10 of 17

DDBB

SSYYSSTTEEMMSS

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?

Minimally, maximally?

DepartmentEmployee

<employs

1..1

DepartmentEmployee

<employs

1..1 1..*

4. Write the numbers/asterisks on the left side.

Or Note: You need to memorize the multiplicity question!

11 of 17

DDBB

SSYYSSTTEEMMSS

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

one (each) object on the right side?

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

Procedure for Determining Multiplicity (Form B question)

Note: We usually need to ask just about maximum multiplicity.

3. How many objects on the right side are associated with

one (each) object on the left side?

4. Write the numbers/asterisks on the right side.

DepartmentEmployee

works in

1..11..*

12 of 17

DDBB

SSYYSSTTEEMMSS

NOTE: Some imprecision in Fig. 2.8 p. 49 in 5th ed. (p. 46 4th ed.): “Order” is called “Sale” in sentence two.

Notation for Multiplicity

Multiplicity options:

0 (zero)

1 (one)

* (many); also labeled as M or N

specific number, if known (3, 10); e.g., in

part-whole relationship

Customer

Order

Item

1..1

1..*

0..*

1..*

.

places

containsOrder_Item

13 of 17

DDBB

SSYYSSTTEEMMSS

Business Rules for Cardinality - Read/Write

1) One customer can place one or more orders,

and each order is placed by

one

and only one customer.

2) Each order can contain one or more items,

and an item can be listed on no (0) order or on many orders. *

Business Rules:

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

Customer

Order

Item

1..1

1..*

0..*

1..*

.

places

contains

Order_Item

14 of 17

DDBB

SSYYSSTTEEMMSS

N-ary Association

Degree of association => 3. The above diagram shows ternary association, not three binary associations.

Components are assembled into Products by Employees. Simultaneous, inter-dependent relationships. Read multiplicity.

Support to inventory scheduling, quality control, performance measurement.

But, the data model is not complete as shown!

Employee

Component

Product

***

*

**

NOTE: Some imprecision in Fig. 2.9 on p. 49 in 5th ed. (p. 46 in 4th ed.). An association between Employee and Component missing; incorrect way of stating M:M multiplicity.

assembled by

assembles

assembled in

15 of 17

DDBB

SSYYSSTTEEMMSS

N-ary Association with Associative Class

N-ary associative class Assembly introduced.

ProductProdIDName

EmployeeEmpIDName

ComponentCompIDTypeName

Assembly DateTime

EmpID ProdID CompID Date Time11 A3222 563 2013/01/02 07:1511 A3222 872 2013/01/02 07:3011 A5411 563 2013/01/02 07:4511 A5411 872 2013/01/02 07:5512 A3222 563 2013/01/02 13:0012 A3222 882 2013/01/03 15:30

         

asse

mbl

ed b

y assembles

assembled in

The key in Assembly combines keys from source associated classes. Its own attributes are Date and Time.

Table Assembly:

16 of 17

DDBB

SSYYSSTTEEMMSS

Focus on Keys: Generic vs. Unique

Product: specific model of car (ProdID is a generic key

signifying a group of things, many instances)

Component: car door (CompID is a generic key)

Employee: assembly worker (EmpID is a unique key

signifying a specific person, one and only one instance)

This design can use unique keys (e.g., serial numbers) for

products and components.

17 of 17