CASE*Method: Entity Relationship Modeling Barkers 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. 97-112. Lecture Notes in Computer Science. Berlin: Springer
Herre H., Heller. B., GOL Manual in Press
Slide 2
Overview 1. Introduction: conceptual modeling 2. Elements of
Barkers notation 3. Refinements of the model 4. Ontological
extension
Slide 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
Slide 4
Introduction: data modeling techniques / Barker's notation Data
Modeling Techniques 1976, Entity Relationship modeling introduced
by Peter Chan In the late 1980s 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
Slide 5
Barker's notations: elements Basic Elements: Entity Attribute
Relationship Unique identifiers Additional Constructs: Subsumption
of entities Constraints on relationships
Slide 6
Entity 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
Slide 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 oOptional Attribute
Slide 8
Subtypes of entities All subtypes inherit the attributes of a
supertype Exclusive subtypes overlapping of subtypes is not allowed
Presented as boxes inside the entity PILOT * authorization
PASSENGER o phone PERSON * name * surname
Slide 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
Slide 10
Relationship endings Relationship ending reading notation
optional may mandatorymust Cardinality = 1exactly one Cardinality
>= 1 one or many
Slide 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)
Slide 12
Relationships PILOT * authorization PASSENGER o phone PERSON *
name * surname FLIGHT # flight no * status Involved in 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
Slide 13
Relationships LOCATION * city * country FLIGHT # flight no *
status destination Between two entities may be more than one
relationship from to start
Slide 14
Unique identifiers 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 FLIGHT # flight no * status AIRPLANE #
serial no model capacity usesperforms
Slide 15
Constraints exclusive or is presented as an arc joining two
relationships CARGO * substance * weight * capacity PILOT *
authorization PASSENGER o phone PERSON * name * surname FLIGHT #
flight no * status in Takes part in Transported in
Slide 16
Refining the model 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 PASSENGER # id
* name * surname o phone FLIGHT # flight no * status PASinFLIGHT
flight no pas id
Slide 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
Slide 18
Ontological refinement Identification of the models underlying
upper-level ontology or ontologies. Annotation of the model
elements to the elements of an underlying upper-level ontology.
Constraint specification.
Slide 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
# flight no * status
Slide 20
Ontological refinements example: ontological markers 1. GOL
category of process is assigned by marker 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;
Slide 21
Ontological refinements example: ontological markers 4. Missing
data may be added FLIGHT # flight no * status * time dep * time arr
FLIGHT # flight no * status TIME dep arr a) b)
Slide 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
