This document describes different modeling techniques. It provides an overview of conceptual, logical, and physical models. Conceptual models describe important concepts and relationships in a problem domain. Logical models refine conceptual models and describe application architecture classes and relations. Physical models adapt logical models for specific technologies. The document discusses modeling tools, common modeling terms, and normalization techniques to reduce redundancies in logical models. An exercise examples modeling a book shop domain at different levels of normalization.

1. L0087 - 2010-09-19
Redistribution and other use of this material requires written permission from The RCP Company.
ITU - MDD – Modeling Techniques
This presentation describes different modeling techniques. It has three basic
purposes:
Give you an overview of some of the different types of models
Give you a set of tools to decide how to create a (good) model for a problem
Give you an overview of some of the different modeling techniques
This presentation is developed for MDD 2010 course at ITU, Denmark

2. L0087 - 2010-09-19
2
What is Data Modeling all About?
 It is primary a way to analyze and describe a problem domain in terms of the
objects and relationships that are relevant for the domain
 Often the result is also used to describe the functionality of the problem domain
in terms of who does what (UML term: interaction diagrams)
 The result is the abstract syntax for the problem domain
 Especially relevant for all problems that includes technologies like
 Object oriented languages like Java, C++ or C#
 Non-trivial data structures
 Relational databases
 … which is just about 95% of all interesting problems

3. L0087 - 2010-09-19
3
Agenda
 Types of Models
 Processes and Techniques
 Model Normalization
 Exercise

4. L0087 - 2010-09-19
4
Types of Models
 A question of abstraction!
 Information Model or Conceptual Model
 Describes the relationships between the important concepts of the model
 Data Model, Logical Model or Domain Model (DOM)
 Describes the corresponding relationships between the objects that are used
to realize the concepts
 Physical Model
 Describes the logical model in a form that can be directly implemented in the
target technology – e.g. Java or SQL
 It is often possible to automatically transform a logical model to a physical model
 Hibernate and JPA are examples of this
 The different types of models is not related to meta levels – these models exists
for M1-M3

5. L0087 - 2010-09-19
5
Conceptual Models
 The conceptual model
 describes the things or objects of significance to a specific problem domain

The “things” are not necessarily physical objects
 is meant to collect information, and characteristics of the objects in the
domain
 describes the most important associations between pairs of those things or
objects of significance
 is often used as the basis for the central use cases
 It can very often be a good start to write down statements about the problem
domain including the basic use cases before the model is started
 To describe the human body:

A human BODY consists of a TORSO, normally connected with two LEGS,
two ARMS, and a HEAD all called BODY PARTS
 To describe entity-relationship diagrams

An ENTITY can refer to a number of other entities via RELATIONS. An
entity can have ATTRIBUTES with DATA TYPES. REFERENCES between
ENTITIES can be bi-directional. ENTITIES can inherit RELATIONS and
ATTRIBUTES from a number of super-ENTITIES.

6. L0087 - 2010-09-19
6
Conceptual Model (cont’)
0..1
Attribute
Relation
Entity
Data Type
0..*
0..*
0..*
attributeType
opposite
superTypes
referenceType
0..*
0..*
Body Part
Torso
0..*
~
~
0..*

7. L0087 - 2010-09-19
7
Logical Model
 The logical model
 typically refines the conceptual model
 typically contains all the important data structures and classes from the
application architecture along with their relations
 is normally platform independent and can thus be implemented using all
types of technologies (e.g. Java or SQL)
 is often used as the basis for the detailed use cases
 All design choices must be made as part of the logical model!
 For large systems, the logical model exists in several layers with more detailed
models for different parts of the base model

8. L0087 - 2010-09-19
8
Logical Model (cont’)
 Constraints and invariants can often be implemented in the abstract syntax (the
model) as well as as dynamic constraints
 To keep the model understandable, the “plain data” for entities is often kept is
separate data dictionaries (including defined methods, etc for UML models) – this
can make it relatively difficult to normalize the model as it is difficult to get a
proper overview of the model
 You should not necessarily expect to find all the conceptual concepts in the
corresponding logical models!

9. L0087 - 2010-09-19
9
Torso
Logical Model (cont’)
Body Part
Torso
0..*
~
Leg Arm Head
0..2
Leg Arm Head
0..2 1
Torso
1
Leg Arm Head
1 1
X 2
X 2

10. L0087 - 2010-09-19
10
Logical Model (cont’)
~ Named Element
Model Element
0..1
Typed ElementClassifier
Structural Feature
Attribute
Reference
Class
Data Type
0..*
0..*
0..*
type
opposite
superTypes
0..*

11. L0087 - 2010-09-19
11
Physical Model
 The physical model
 normally closely mimics the logical model
 adapts the logical model to the technical constraints of the target platform
 adds or refines the information to be platform specific
 E.g.
 Data types are often more primitive – e.g. no enumerations or compound
types in SQL
 Bi-directional references are often resolved into multiple references
 Additional performance specific data can be added in the form of indexes and
storage specifications
B
*
A
*
RelA
*
B
*

12. L0087 - 2010-09-19
12
Common Terms
 Organization, Problem Domain or Universe – the area of interest, the “thing” that
most be modeled
 Entity – an object or concept from the problem domain – can also be data on
relations or associations
 Relation, Association or Reference – the connection between entities
 Aggregation, Composition or Containment – a relation that implies some sort of
ownership and shared life-cycle
 Attribute – a data item on an entity
 Key or Identifier – one or more attributes that are used to (uniquely) identify an
entity
 Structural Feature – common name for references and attributes
 Entity-Relationship Diagram (ER diagram)

13. L0087 - 2010-09-19
13
Model Notations
 Entity-Relationship Model or Diagram (ER
diagram)
 The overall common term for all the
notations
 Also allows data attributes on relations – can
always be converted to a simpler notation
 UML 2 Class Diagram
 OMG governed notation
 Very rich
 (I use a reduced UML notation when possible to
remove as much “noise” from the diagrams as
possible)
 ((Notations is the target of many religious
discussions – the end result is usually the same
though…))

14. L0087 - 2010-09-19
14
Notations

15. L0087 - 2010-09-19
15
Modeling Tools
 Hand written on paper or a white board!
 Eclipse Ecore Tools
 UML tools such as IBM RAD and similar IDEs

16. L0087 - 2010-09-19
16
The Typical Process
 “Modeling Techniques” are integrated and described in many different formal
development process
 Most processes encompass the following steps:
 Identify Entities – typically corresponding to the objects in the problem
domain
 Identify Relations – typically according to the ownership or interaction
between entities
 Introduce inheritance

to collapse common behavior

to allow to-many references
 Add attributes for all identifiers and specify constraints (especially cardinality
of relations)
 Apply generic model patterns and “normalize” the model to get the best
balance between consistency and performance
 Add all other “plain data” attributes
 Practice, practice, practice… Sorry, not easy road here

17. L0087 - 2010-09-19
17
Shop
Relations, References and Associations
 Two basic groups of relations:
 Aggregations, Composition and Containment
 Plain References (sometimes “Reference Relations”)
 Describes ownership and life-cycle
 UML has two concepts

Aggregation denotes a weak “has a”

Composition denotes a strong “has a”
Order
*
Customer
Order Item Shop Item
* *
*
*
*

18. L0087 - 2010-09-19
18
Techniques – One or More Relations
Torso
0..2
Leg Arm Head
0..2 1
Torso
1
Leg Arm Head
1 1
X 2
X 2

19. L0087 - 2010-09-19
19
Techniques – Inheritance
Torso
Body Part
Torso
0..*
Leg Arm Head
0..2
Leg Arm Head
0..2 1
Body Part
Torso
0..* Type := “Leg”, “Arm, “Head”

20. L0087 - 2010-09-19
20
Techniques – Attributes with Limited Value Set
 E.g. Colors, Fonts, Vendors, Zip codes, Employees, Flight No
 Model association as a string attribute
 Model association as an enumeration attribute
 Model association as a reference to a data entity (reference table)
 Model association as a reference to different sub-types (inheritance)
 Question: what is the meta level of the reference table?
 Question: What is the associated cost of changing the application for each
solution?
 Very much related to the notion of normal forms

21. L0087 - 2010-09-19
21
Techniques – Attributes with Limited Value Set
Body Part
Torso
0..* Type : String
Body Part
Torso
0..* Type := “Leg”, “Arm, “Head”
Body Part
Torso
0..*
Body Part Type0..*
1
Body Part
Torso
0..*
Leg Arm Head

22. L0087 - 2010-09-19
22
Model Normalization
 Model normalization is a process where certain types of redundancies are
removed from a logical model
 The primary aim is to avoid inconsistencies
 The price is typically an increased performance/execution cost – especially for
SQL based databases!
 First normal form (1NF) – An entity type is in 1NF when it contains no
repeating groups of data
 Second normal form (2NF) – An entity type is in 2NF when it is in 1NF and
when all of its non-key attributes are fully dependent on its primary key
 Third normal form (3NF) – An entity type is in 3NF when it is in 2NF and when
all of its attributes are directly dependent on the primary key

 Only one key attribute
 Very often a model will go through a number of normalization/de-normalization
cycles to find the right balance between consistency and performance

23. L0087 - 2010-09-19
23
Model Normalization Example (0NF)

24. L0087 - 2010-09-19
24
Model Normalization Example (1NF)

25. L0087 - 2010-09-19
25
Model Normalization Example (2NF)

26. L0087 - 2010-09-19
26
Model Normalization Example (3NF)

27. L0087 - 2010-09-19
27
Exercises
 We have a BOOK SHOP with a number of BOOKS on stock.
 The BOOKS are sold to CUSTOMERS. A single ORDER can include many different
BOOKS to a specific CUSTOMER.
 Exercise I: Build a conceptual model for the book shop
 What meta level does the model have (M0-M3)?
 Exercise II: Build the corresponding data model for the book shop
 What normal form does the model have? Can you make the model NF3? Is it
worth it?
 Exercise III: How must be models be changed if we need to track the price of
BOOKS over time so we can draw diagrams with PRICE versus ORDERS for specific
BOOKS

28. L0087 - 2010-09-19
28
Syllabus (”Pensum”)
 The reading materials for this lecture is in the form of the following three
articles:
 Wikipedia on Data Modeling - http://en.wikipedia.org/wiki/Data_modeling

Overview of the concepts behind data modeling
 “Data Modeling 101” by Scott Ambler -
http://www.agiledata.org/essays/dataModeling101.html

Good introduction to the modeling process
 “UML 2 Class Diagrams” by Scott Ambler -
http://www.agilemodeling.com/artifacts/classDiagram.htm

Good over the UML 2 Class Diagram Notation