1

www.monash.edu.au

IMS 5024

Data Modelling

www.monash.edu.au2

Content

• Second assignment• Nature of data modelling• Tools/Techniques used in data modelling• Place in ISD• Evaluation of data modelling• Reading list

www.monash.edu.au3

Assignment 2 – OO modelling

• Due Wednesday 5 October 2005 - week 11

• Undertake in pairs from the same tute group

• Individual submissions accepted (decide this week)

www.monash.edu.au4

Assignment Pitfalls

• Not starting early

• Not confirming your understanding with the tutor

• Not starting early • Not integrating the separate elements of

the models• Not starting early

www.monash.edu.au5

Data modelling describe:

• Structure

• Meaning• Relationship

Of Data

www.monash.edu.au6

Data modelling help us to grasp:

• Static Data in the organisation• Fundamental building block of

the system• Two perspectives (Process and

Data)

2

www.monash.edu.au7

Techniques used in Data modelling

• Entity relationship diagrams

• Normalisation• Data Dictionary

• What difference?• Use both?

www.monash.edu.au8

Entity

• Entity – things of interest to the business

• Identification of an entity is subjective• Entities can be:

§ Real eg product§ Abstract eg Quota§ Event remembered eg sale§ Role played eg employee

Employee

www.monash.edu.au9

Relationship

• Relationship Between entities

• Cardinality (eg. One to many, one to one ect.)

• Degree of relationship (Unary, Binary, Ternary)

DepartmentEmployee

www.monash.edu.au10

Examples of Cardinalities

PATIENTHISTORY

PATIENT

PROJECT

EMPLOYEE

PERSON

Mandatorycardinalities

Optional and mandatorycardinalities

Optionalcardinalities

HasIs

assigned to

Is married

to

www.monash.edu.au11

Relationship Cardinality Summary

Mandatory 1 cardinality

Many cardinality (1,2 …m)

Optional (0 or 1) cardinality

Optional (0 or many) cardinality

www.monash.edu.au12

Unary Relationship

• Also called a recursive relationship

PERSON

One to manyOne to one

Ismarried

toManagesEMPLOYEE

3

www.monash.edu.au13

Binary Relationship

• A binary relationship is a relationship between instances of two entity types.

PROJECT

EMPLOYEE CUSTOMER

ITEM

SUPPLIER

One to one One to many Many to many

Leads Places Supplies

SALESORDER

www.monash.edu.au14

Ternary Relationship

• A ternary relationship is a relationship between instances of three entity types.

PART

suppliesVENDOR CUSTOMER

www.monash.edu.au15

Attributes

• What we want to know about the entity or a relationship

• Types:– Derived,– multi -valued, – Composite,– Simple

www.monash.edu.au16

Example of attributes

EMPLOYEE

Emp-no

Name Address

Skill

www.monash.edu.au17

Why normalisation?

• Remove redundancy and incompleteness

• Bottom up process

• Rely on Maths – well researched

www.monash.edu.au18

Determining columns

• One fact per column

• Hidden data• Derivable data• Determining the key

4

www.monash.edu.au19

Steps in Basic Normalisation

• Basic Normalisation is most often accomplished in three stages (these are the three basic normal forms)

First Normal Form

Second Normal Form

Third Normal Form

Unnormalisedtable

Remove repeating groups

Remove partial dependencies

Remove transitive dependencies

www.monash.edu.au20

First normal form

Step 1: Remove the repeating group• Why is repeating groups a problem?• Determine the key for the new group.

Order-Item (Order#, Customer#, (Item#, Desc, Qty))Order-Item (Order#, Item#, Desc, Qty)Order (Order#, Customer#)

www.monash.edu.au21

Second and Third normal forms

• Eliminate redundancy

• Determinates – one or more columns which determines other column values

www.monash.edu.au22

Second and third normal form procedure

• Identify any determinates (other than the key)

• Establish a separate table for each determinate and the columns it determines

• Name the new tables• Remove the determined columns from

the original table

www.monash.edu.au23

Third normal form

A table is in third normal form if the only determinates of nonkey columns are candidate keys

www.monash.edu.au24

Advanced normalisation

• A set of tables can be in 3NF and still not be fully normalised

• Further stages of normalisation are BCNF, 4NF, 5 NF and Domain key NF

5

www.monash.edu.au25

Higher Normal forms

• Occur infrequently

• Most tables in 3 NF is already in BCNF, 4NF and 5 NF

• Data in 3NF but not in 5NF has– Redundancy– Insert/update/delete anomalies– Difficulty in storing facts independently

www.monash.edu.au26

BC NF

Example

Branch-customer relationship (customer no, branch no, visiting frequency, date relationship established, salesperson no)

BRANCHCUSTOMER

RELATIONSHIP

CUSTOMERBRANCH

SALES-PERSON

www.monash.edu.au27

Problem

• Salesperson branch no• Overlapping and candidate keys

Customer no and branch no&

Customer no and salespersonBranch-customer relationship (customer no, salesperson no,

branch no, visiting frequency, date relationship established)

Customer salesperson relationship (customer no, salesperson no, visiting frequency, date relationship established)

Salesperson (Salesperson No, branch no)

www.monash.edu.au28

B-C NF

Every determinant must be a candidate key (must have overlapping keys)

BRANCHCUSTOMER

RELATIONSHIP

CUSTOMER

BRANCH

SALES-PERSON

www.monash.edu.au29

Fourth and Fifth NF

• Apply to all-key tables, degree > 2

INSTRUMENTDEALER

LOCATION

www.monash.edu.au30

Problems are the result of multi-valued dependencies

6

www.monash.edu.au31

Fifth NF

Keep splitting tables until:

– Any further splitting would lead to tables unable to be joined to produce the original table

– The only splits left are trivial

www.monash.edu.au32

Dealing authority problem

www.monash.edu.au33

Many to many relationships resolved

www.monash.edu.au34

Combined table

www.monash.edu.au35

Combined table which cannot be split

www.monash.edu.au36

Other normalisation issues

• Normalisation and redundancy– Overlapping classifications– Derivable data

• Selecting primary keys

7

www.monash.edu.au37

Thinking in Data modelling

• Hard Vs Soft ??

• Perspective– Objective vs Subjective– Nature of the organisation

www.monash.edu.au38

Evaluation of Data modelling

Levels of abstraction

Stepwise refinementProof of correctnessData abstractionJSPObject oriented programming

PSL/PSA

JSDVDM

Formal

Structured designObject oriented design

Structured analysisEntity relationship modellingLogical construction of systemsModern structured analysisObject oriented analysis

Concep-tual

Product orientedProblem oriented

www.monash.edu.au39

Advantages of Data modelling

• Data model is not computer oriented (agree??) • Model understandable by technologist and

users• Does not show bias• UoD can vary (whole organisation or

department)• Readily transformable into other models• Different data analysis techniques• Data modelling is rule-based

www.monash.edu.au40

Disadvantages

• Does not encourage/support user participation

• Your view on the organisation –people or data

• The idea that the model is THE model• Subjective view• One-side ito data• Others??

www.monash.edu.au41

Advantages of Normalisation

• Rid the data of redundancy and other problems

• Very well researched• Math basis for normalisation

www.monash.edu.au42

Disadvantages of normalisation

• Does not encourage/support user participation

• Your view on the organisation –people or data

• One-side ito data• Can be done mechanistically without

thought• Others??

8

www.monash.edu.au43

Process modelling view of ISD

Development group

Objectives

Environment

Object system

ObjectsystemChange

process

Hirschheim et al see reading list

www.monash.edu.au44

Reading for next week

• Johnstone, M.N., McDermid, D.C. (1999). Extending and validating the business rules diagram method. Proceedings of the 10 thAustralian Conference on Information Systems.

• Chapter 2 of Curran, Keller, Ladd (1998). SAP R/3 the business blueprint: Understanding the business process reference model. Prentice Hall.