Transcript of CASE*Method: Entity Relationship Modeling Barker‘s ERD notation and ist ontological extensions...
- Slide 1
- 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