1. CASE*Method: Entity Relationship Modeling
Barker‘s ERD notation and ist ontological extensions
References:
Barker, R., "CASE Method -- Entity Relationships Modelling", Oracle Corporation UK Limited, Addison-Wesley Publishing Company, 1990
Guizzardi, G., Herre, H., Wagner, G. „On the General Ontological Foundations of Conceptual Modeling“ In: Proceedings of 21th International Conference on Conceptual Modeling, (ER2002), 2002 Okt 07-11; Tampere, Finland. pp Lecture Notes in Computer Science. Berlin: Springer
Herre H., Heller. B., „GOL Manual“ in Press

2. Overview 1. Introduction: conceptual modeling
2. Elements of Barker’s notation
3. Refinements of the model
4. Ontological extension

3. Introduction: conceptual modeling
Definition
Conceptual modeling is an activity concerned with identifying, analyzing and describing the essential concepts and constraints of a domain with the help of a modeling language that is based on a small set of basic meta-concepts
Guizzardi, Herre and Wagner
The output of the conceptual modeling is a conceptual model (data model)
No matter what is an adopted software life cycle model it is better not to skip conceptual modeling

4. Introduction: data modeling techniques / Barker's notation
1976, Entity Relationship modeling introduced by Peter Chan
In the late 1980’s the introduction of "object oriented modeling"
mid-1990's, the introduction of the UML
Barker's Notation:
originally developed by the British consulting company CACI
promoted by Richard Barker
adopted by the Oracle Corporation as a "CASE*Method"
Barker's notation is supported by the CASE tool: Oracle Designer
Business Process and Functions
Data Flows
Entity Relationships

5. Barker's notations: elements
Basic Elements:
Entity
Attribute
Relationship
Unique identifiers
Additional Constructs:
Subsumption of entities
Constraints on relationships

6. Entity Components: Notation: PASSENGER # id * name * surname o phone
An entity is a thing of significance,real or imagined, about which the information needs to be known.
From an object oriented point of view an entity is a class
From the perspective of relational db it is a relation
Components:
Name – singular form
At least two attributes
Notation:
round cornered rectangle with a name, attributes and their types labels displayed inside it
PASSENGER
# id
* name
* surname
o phone

7. Attributes
Attributes are aspects or properties that describe an entity
Can be defined for existing entities only
They can represent columns in a relation
Components:
unique name
Type label
Datatypes and domains are not included in the notation
Attributes types:
# Unique Identifier (UID), with # are marked attributes that constitute UID
* Mandatory Attribute
o Optional Attribute

8. Subtypes of entities PERSON * name * surname PILOT * authorization
All subtypes inherit the attributes of a supertype
Exclusive subtypes – overlapping of subtypes is not allowed
Presented as boxes inside the entity
PERSON
* name
* surname
PILOT
* authorization
PASSENGER
o phone

9. Relationships
Relationships are named significant associations between two entities
Each relationship has:
a name – proposition
2 endings
Each relation ending has
a name
its optionality
its cardinality

10. Relationship endings Relationship ending reading notation optional may
mandatory
must
Cardinality = 1
exactly one
Cardinality >= 1
one or many

11. Relationships M:1 (Mandatory to Optional) M:1 (Optional to Optional)
M:1 (Optional to Mandatory)
M:1 (Mandatory to Mandatory)
M:M (Optional to Optional)
M:M (Mandatory to Optional)
1:1 (Mandatory to Optional)
1:1 (Optional to Optional)
1:1 (Mandatory to Mandatory)

12. Relationships PERSON * name * surname FLIGHT # flight no * status
PILOT
* authorization
Involved in
PASSENGER
o phone
Takes part in
Each PILOT may be involved in one or many FLIGHTS
In each FLIGHT must be involved exactly one PILOT
One or many PASSENGERS can take part in one or many FLIGHTS
In each FLIGHT must be involved one or many PASENGERS

13. Relationships LOCATION * city FLIGHT * country # flight no * status
Between two entities may be more than one relationship
LOCATION
* city
* country
FLIGHT
# flight no
* status
start
from
destination to

14. Unique identifiers AIRPLANE # serial no model capacity FLIGHT
UID is any combination of attributes and relationships which uniquely identifies an instance of an entity
Attributes which are part of the UI are marked with #
Relations are marked by a short line across the relationship near the entity being identified
UID is a primary key
Foreign keys are not displayed at the diagram
AIRPLANE
# serial no
model
capacity
FLIGHT
# flight no
* status
uses
performs

15. exclusive “or” is presented as an arc joining two relationships
Constraints
exclusive “or” is presented as an arc joining two relationships
PERSON
* name
* surname
FLIGHT
# flight no
* status
PILOT
* authorization in
PASSENGER
o phone
Takes part in
CARGO
* substance
* weight
* capacity
Transported in

16. Refining the model FLIGHT # flight no * status PASSENGER # id * name
Dealing with many-to-many relationships
There are no means to implement in relational db many-to-many (M:M) relationship
M:M relationships are omitted by the introduction of the intersection entity
n-arity (where n>2) relations are introduced by means of the intersection entities too
FLIGHT
# flight no
* status
PASSENGER
# id
* name
* surname
o phone
PASinFLIGHT
flight no
pas id

17. Comments
Few distinct and intuitive symbols – easy to read for untrained users
Optionality of attributes displayed
Subtypes displayed inside an entity – unables modeling of deep hierarchical structures
Relationships named by propositions not by verbs
Constraints on relationships

18. Ontological refinement
Identification of the model’s underlying upper-level ontology or ontologies.
Annotation of the model elements to the elements of an underlying upper-level ontology.
Constraint specification.

19. Ontological refinements example: ontological markers
Entity is something important in the modeled domain
Everything can be an Entity
For specifying what is an entity ontologies and specially upper-level ontologies can be used
Ontological Concepts can be introduced to the model by means of ontological markers
Analogously attributes and relationschips can be ontologically annotated
FLIGHT <proc>
# flight no
* status

20. Ontological refinements example: ontological markers
1. GOL category of process is assigned by marker <proc> to an entity FLIGHT.
2. Two following axioms of GOL are considered
x (Proc (x)   y ( Chron (y)  prt(x,y)) (e1)
x (Chron(x)  ! y ! z (lb(x,y)  rb(x,z)) (text)
3. Missing datas are found: Chron, prt, lb, rb;

21. Ontological refinements example: ontological markers
4. Missing data may be added
TIME <Chron>
FLIGHT <proc>
# flight no
* status
dep <lb> a)
arr <rb>
FLIGHT <proc>
# flight no
* status
* time dep <lb>
* time arr <rb> b)

22. Ontological Refinement - Benefits
validity checking, searching missing constraints
providing well grounded foundations (formal semantics) for the models
simplification of the modeling process
Model integration based on underlying ontologies