1PalGov © 2011

أكاديمية الحكومة اإللكترونية الفلسطينية

The Palestinian eGovernment Academy

www.egovacademy.ps

Session 1.3

Conceptual Analyses

Tutorial 1: Data and Business Process Modeling

Prof. Mustafa Jarrar

Sina Institute, University of Birzeit

mjarrar@birzeit.edu

www.jarrar.info

Reviewed by

Prof. Marco Ronchetti, Trento University, Italy

2PalGov © 2011

About

This tutorial is part of the PalGov project, funded by the TEMPUS IV program of the

Commission of the European Communities, grant agreement 511159-TEMPUS-1-

2010-1-PS-TEMPUS-JPHES. The project website: www.egovacademy.ps

University of Trento, Italy

University of Namur, Belgium

Vrije Universiteit Brussel, Belgium

TrueTrust, UK

Birzeit University, Palestine

(Coordinator )

Palestine Polytechnic University, Palestine

Palestine Technical University, PalestineUniversité de Savoie, France

Ministry of Local Government, Palestine

Ministry of Telecom and IT, Palestine

Ministry of Interior, Palestine

Project Consortium:

Coordinator:

Dr. Mustafa Jarrar

Birzeit University, P.O.Box 14- Birzeit, Palestine

Telfax:+972 2 2982935 mjarrar@birzeit.edu

3PalGov © 2011

© Copyright Notes

this material, or part of it, but should properly useEveryone is encouraged to

(logo and website), and the author of that part. cite the project

in any form or by any reproduced or modified No part of this tutorial may be

from the project, who have the full written permissionmeans, without prior

copyrights on the material.

Attribution-NonCommercial-ShareAlike

CC-BY-NC-SA

This license lets others remix, tweak, and build upon your work non-

commercially, as long as they credit you and license their new creations

under the identical terms.

4PalGov © 2011

Tutorial Map

Topic Time

Module I: Conceptual Data Modeling

Session 0: Outline and Introduction

Session 1.1: Information Modeling 1

Session 1.2: Conceptual Data Modeling using ORM 1

Session 1.3: Conceptual Analyses 1

Session 2: Lab- Conceptual Analyses 3

Session 3.1: Uniqueness Rules 1.5

Session 3.2: Mandatory Rules 1.5

Session 4: Lab- Uniqueness & Mandatory Rules 3

Session 5: Subtypes and Other Rules 3

Session 6: Lab- Subtypes and Other Rules 3

Session 7.1: Schema Equivalence &Optimization 1.5

Session 7.2: Rules Check &Schema Engineering 1.5

Session 8: Lab- National Student Registry 3

Module II: Business Process Modeling

Session 9: BP Management and BPMN: An Overview 3

Session 10: Lab - BP Management 3

Session 11: BPMN Fundamentals 3

Session 12: Lab - BPMN Fundamentals 3

Session 13: Modeling with BPMN 3

Session 14: Lab- Modeling with BPMN 3

Session 15: BP Management & Reengineering 3

Session 16: Lab- BP Management & Reengineering 3

Intended Learning ObjectivesModule 1 (Conceptual Date Modeling)

A: Knowledge and Understanding

11a1: Demonstrate knowledge of conceptual modeling notations and concepts

11a2: Demonstrate knowledge of Object Role Modeling (ORM) methodology.

11a3: Explain and demonstrate the concepts of data integrity & business rules

B: Intellectual Skills

11b1: Analyze application and domain requirements at the conceptual level,

and formalize it using ORM.

11b2: Analyze entity identity at the application and domain levels.

11b4: Optimize, transform, and (re)engineer conceptual models.

11b5: Detect &resolve contradictions & implications at the conceptual level.

C: Professional and Practical Skills

11c1: Using ORM modeling tools (Conceptual Modeling Tools).

Module 2 (Business Process Modeling)

A: Knowledge and Understanding

12a1: Demonstrate knowledge of business process modeling notations and concepts.

12a2: Demonstrate knowledge of business process modeling and mapping.12a3: Demonstrate understand of business process optimization and re-engineering.

B: Intellectual Skills

12b1: Identify business processes.

12b2: Model and map business processes.

12b3: Optimize and re-engineer business processes.

C: Professional and Practical Skills

12c1: Using business process modeling tools, such as MS Visio.

5PalGov © 2011

Session ILOs

After completing this session students will be able to:

11b1: Analyze application and domain requirements at the

conceptual level, and formalize it using ORM.

11b2: Analyze entity identity at the application and domain levels.

6PalGov © 2011

Conceptual Analyses

• Given an application domain, e.g. hospital, and three information

modelers, what steps do you suggest they start with, to build the

hospital‟s conceptual model?

• There is no strict or perfect modeling process or procedure!

• You may start with any step you think suitable, taking into account the

complexity of the domain, available resources, modelers‟ prior

knowledge about the domain, etc.

• It is recommended that you modularize the domain into sub-domains,

build a conceptual schema for each sub-domain, then integrate all sub-

schemes into one conceptual schema.

• The following procedure (7 steps) is to help you model a sub-domain,

but you don‟t have to strictly follow these steps.

7PalGov © 2011

Conceptual Schema Design Steps

1. From examples to elementary facts

2. Draw fact types and apply population check

3. Combine entity types

4. Add uniqueness constraints

5. Add mandatory constraints

6. Add set, subtype, & frequency constraints

7. Final checks, & schema engineering issues

8PalGov © 2011

Elementary Facts and Fact Types

– Person smokes.

– Person drives car.

– Person was born in a city.

– Person smokes and drives car.

– If a Person was born in a city and this City is part of a

country, then this person was born in that country.

What is a fact type?

What is a fact?

– Rami smokes.

– Rami drives car.

– Rabab was born in Ramallah.

– Rami smokes and drives car.

– If Rabab was born in Ramallah and Ramallah is part of

Palestine, then Rabab was born in Palestine.

A fact must be either true or false

9PalGov © 2011

Elementary Facts and Fact Types

– Person smokes.

– Person drives car.

– Person was born in a city.

– Person smokes and drives car.

– If a Person was born in a city and this City is part of

a country, then this person was born in that country.

What is an elementary fact type?

An elementary fact type cannot be split.

10PalGov © 2011

1. From examples to elementary facts

Conceptual Schema Design Steps

11PalGov © 2011

1. Make elementary facts from examples

• Mustafa teaches Knowledge Engineering.

• Rami is enrolled in Knowledge Engineering.

• Knowledge Engineering is offered by the University of Birzeit.

The person (ID4514) that has the name Mustafa teaches the course (SC242)

that has the title Knowledge Engineering.

The person (ID123) that has the name Rami is enrolled in the course (CS242)

that has the title Knowledge Engineering.

The course (CS242) that has the title Knowledge Engineering is offered by the

university that has the name University of Birzeit.

The person that has the name Mustafa teaches the course that has the title

Knowledge Engineering.

The person that has the name Rami is enrolled in the course that has the title

Knowledge Engineering.

The course that has the title Knowledge Engineering is offered by the

university that has the name University of Birzeit.

More precise

From examples to fact types

12PalGov © 2011

Conceptual Schema Design Steps

1. From examples to elementary facts

2. Draw fact types and apply population check

13PalGov © 2011

2. Draw fact types and apply population check

University(Name)

Person(nr)

Course(Code)

IsOf/Has

Name

TitleTeaches/

EnrolledIn/

Has/IsOf

OfferedBy /Offers

The Person (ID4514) that has the name Mustafa teaches the course (SC242)

that has the title Knowledge Engineering.

The Person (ID123) that has the name Rami is enrolled in the course (CS242)

that has the title Knowledge Engineering.

The course (CS242) that has the title Knowledge Engineering is offered by the

university that has the name University of Birzeit.

Draw Fact Types

14PalGov © 2011

2. Draw fact types and apply population check

Person(nr)

Course(Code)

IsOf/Has

Name

TitleTeaches/

EnrolledIn/

Has/IsOf

The Person (ID4514) that has the name Mustafa teaches the course (SC242)

that has the title Knowledge Engineering.

The Person (ID123) that has the name Rami is enrolled in the course (CS242)

that has the title Knowledge Engineering.

The course (CS242) that has the title Knowledge Engineering is offered by the

university that has the name University of Birzeit.

Test with population

Mustafa ID4154

Rami ID123

SC242 Knowledge Engineering

SC242 Birzeit University

ID4154 SC242

ID123 SC242

University(Name)

OfferedBy /Offers

15PalGov © 2011

Basic ORM Constructs and Syntax

• Object and Value Types

• Roles and relations

• Unary relations

• Ternary relations

• Nested Fact Types

• Ring Fact Types

16PalGov © 2011

Object and Values Types

Person Car

Adams B 235PZN

Jones E 235PZN

Jones E 108AAQ

Person

has

PersonName

Car

RegNr

refers to

has

refers to

drives / is driven by

„Adams B‟„Jones E‟

„235PZN‟

„108AAQ‟

drivesCarPerson

has has

PersonName RegNr

Value Type (lexical)

It is always a value of an

Object Type.

Object Type (non lexical)You cannot lexicalize, or refer to a

person without using a value of

its properties.

17PalGov © 2011

Roles and Relations

Called Binary Relation

It consists of two roles

(“drives” and “is driven by”)

Called Role

which is part of a relation

Called Role

which is part of a relation

18PalGov © 2011

Unary Relations

Pat smokes

Lee smokes

Shir does not smoke

Called Unary Relation

as it has one role

(“smokes”)

You can transform unary fact types into binary:

19PalGov © 2011

Ternary Relations

Called Ternary Relation

as it has three roles

(“… for … scored…”)

20PalGov © 2011

Nested Fact Types

Called Nested Fact Type

The fact type “Student enrolled in

Subject” is objectified, i.e., the whole

Fact type is seen as an Object Type

21PalGov © 2011

Ring Fact Types

Same object type is connected to two roles in the same relation

22PalGov © 2011

The ORM Syntax (Test)

An object type can be only connected with roles.

Each role can be connected with only one object type.

23PalGov © 2011

References

1. Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design, Terry Halpin (ISBN 1-55860-672-6) – Chapter 3.