Gkerpini Nikol: 3766926
Group Number 3
Final Paper Assignment
Object-Role Modeling (ORM/NIAM)
Nikol Gkerpini
Department of Information and Computing Sciences
Utrecht University
Utrecht, The Netherlands
n.gkerpini @ students.uu.nl
Abstract. Object-Role Modeling (ORM) is a method for analysing and
modeling data by using concepts. In order to position ORM design
procedure (CSDP) in the IS Lifecycle and to illustrate its activities and
their connection with the deliverables, a meta-model of the method will
be presented. The ORM meta-model can be considered a helpful tool not
only for IS Analysts, Data Designers and other practitioners, but also for
method engineers, interested in extending, modifying or even
reconsidering the method or fragments of the method.
Keywords: Object-Role Modeling, conceptual level, Information
Systems Lifecycle, ORM meta-model, Process-Deliverable Diagram
April, 2012
1
1
Introduction
An Overview
The need of modeling Information Systems using easily understood natural language and
mapping the conceptual level with the logical level, led researchers to the development of
a fact-oriented modeling approach (Halpin, 1997). Object-Role Modeling (ORM) is a
method for modeling and querying information systems using concepts. The deliverables
of ORM provide a formal representation of the Universe of Discourse (UoD), i.e. the
domain area. In other words, this method is aimed at depicting reality by defining objects
(value types and entities) that play roles and take part in relationships (Halpin, 1998).
Other methods of the same domain are Entity-Relationship (ER) and Object-Oriented
(OO) approaches, such as the widely acknowledged Unified Modeling Language (UML).
The basic difference between ORM and the other approaches is that the former does not
explicitly use attributes (Haplin, 1998). For example, instead of using Building as an
attribute of Classroom, the relationship Classroom is located in Building would be used.
Attributes are parts of entities or relationships and, thus, are sensitive to changes in the
model and may need to be reformed to relationships. On the contrary, the lack of attributes
proves stability to the models created with ORM (Balsters & Halpin, 2007).
The method originated back in the 1970s. The concept of verbalizing representative
instances of facts of the reality, gained the interest of many researchers. Falkenberg was
the first to establish a framework which allows n-ary relationships (Halpin, 1998) and then
Nijssen (1976) initiated Natural Language Information Analysis Method (NIAM). Later,
in 1989 his colleague, Halpin, continued the research on the topic, described thoroughly
the method and renamed it as Object-Role Modeling to highlight that its purpose is to
objectify facts and explicitly describe the roles and relationships (Halpin, 1997).
Nijssen and Halpin worked together till 1989 and gave a description of conceptual
database design procedure for NIAM in nine steps, usually referred to as “cookbook”
(Navathe & Pernul, 1992). When Halpin renamed and extended the method in 1989, he
provided his own structure of ORM (Halpin, 1997). The so called Conceptual Schema
Design Procedure (CSDP) consists of seven particular steps. This study focuses on this
version of the method, due to the fact that it is the latest and because most of the
extensions are based on it.
Conceptual Schema Design Procedure (CSDP)
The Information Systems Lifecycle (Figure 1) involves typically requirements analysis,
conceptual design (data analysis and data design), logical mapping, and, in case of DBMS,
querying (Halpin, 1998). Thus, the CSDP describes the Data Analysis and the Data Design
of IS that use as inputs the deliverables of the requirements analysis and provide output to
the Logical and Querying activities. All these activities lead to a complete data modeling
solution.
Requirements
Analysis
Data
Data
Analysis
Analysis
CSDP
Data
Data
Design
Design
Logical
Mapping
Querying
Data
Modeling
Solution
Figure 1: CSDP position in the Information Systems Lifecycle
2
The actors that are taking part in the procedure are the IS Analyst, the Data Designer and
the UoD expert from the side of the client (Halpin, 1997). The first two roles are not
clearly distinguished, but as the meta-model aims to clarify the activities, hence their
actors too, in this paper we will consider that IS Analyst is taking part into the Data
Analysis and the Data Designer in the Data Design activity.
The Conceptual Schema Design Procedure as analysed in Halpin’s paper (1998) and a
description of the steps provided by the author, are given below.
Step 1: Transform familiar information examples into elementary facts, and apply quality
check.
The analyst discusses with experts on the domain area (UoD) over the verbalization of
examples of information that needs to be conceptualized. This means that the information
is transformed into facts expressed in natural language, understandable to the client. Then
the experts are able to control the quality of the result by checking whether the objects are
well identified.
Step 2: Derive fact types, apply population check and draw draft conceptual schema
The analyst derives the fact types from the fact table that should be populated with at least
one fact (Halpin, 1998). The client is able to check the validity of the model and the
analyst draws a draft conceptual schema consisting of objects and roles.
Step 3: Check for entity types that should be combined, add values and note arithmetic
derivations
Different degrees of same information may be combined into one entity and described by
entity types. Values types should be added. Arithmetic notes may be derived by counting
objects that take part in a specific relationship (see example).
Step 4: Add uniqueness constraints, check arity of fact types
The designer adds these constraints to roles that depict one-to-one or one-to-many
relationships. The arity of fact types should be defined at this point. Unary, binary or n-ary
predicates are added.
Step 5: Add mandatory role constraints, and check for logical derivation
In this step roles that are mandatory should be distinguishable from optional roles with a
dot added in the line segment of the draft conceptual schema. Logical derivations will be
noted in case that any fact type can be derived from another without using arithmetic.
Step 6: Add value, set comparison and sub-typing constraints
The designer may need to restrict or compare the population of an object type by using
value constraints and comparison constraints. Additionally, the designer needs to add subtyping constraints in order to show the hierarchy or generalization of object types.
Step 7: Add other constraints and perform final checks.
To finish the conceptual schema, the designer may add other constraints (frequency, ring
and asterisk constraints) not to be further analysed in the context of this paper, and to
check the validity of the final version of the conceptual schema with the client.
CSDP dismantled
Before providing an example of the procedure it is very important to clarify the
activities and the actors involved in the CSDP. From the description of the steps, it
is logically ensued that there are discernible sub-steps that are performed by
different actors, executed in a specific order and that consist part of either Data
Analysis or Data Design phase. These issues will be the criteria to inevitably
3
dismantle the CSPD, in order to later be able to design a meta-model of ORM
method. Table 1, consists of 4 columns containing the original steps of the CSDP,
the sub-steps derived after applying the aforementioned criteria, the actors
performing the sub-step, and the phase that the sub-step is logically involved in.
The table maps the original steps with the sub-steps and is the preliminary
elaboration of the meta-modeling design.
CSDP
Step
Step 1
Step 2
Step 3
SubStep
1
2
3
4
5
6
Step 5
7
8
9
10a
Step 6
10b
11
Step 4
Step 7
12
13
Sub-Step Description
Transform information into
elementary facts
Perform quality checks
Derive fact types
Perform population check
Draw Objects and Roles based
on Facts
Combine Entity Types and
Values
Note Arithmetic Derivations
Check Arity of Fact Types
Add Uniqueness Constraints
Add Mandatory Role
Constraints
Note Logical Derivations
Add Value, Comparison and
Sub-typing Constraints
Add other Constraints
Perform final checks
Actor
Phase
IS Analyst
Data Analysis
UoD Expert
IS Analyst
IS Analyst
Data Designer
Data Analysis
Data Analysis
Data Analysis
Data Design
Data Designer
Data Design
Data Designer
Data Designer
Data Designer
Data Designer
Data Design
Data Design
Data Design
Data Design
Data Designer
Data Designer
Data Design
Data Design
Data Designer
Data Designer
Data Design
Data Design
Table 1: The mapping of the original CSDP steps to the dismantled sub-steps, the relevant
actors and the IS Lifecycle phase.
An example of the procedure is provided in the second part of the paper in order to
make the steps clearer to the reader. The third part contains an illustration of the
ORM method depicted using a Process-Deliverable Diagram. Finally, the forth part
of the paper, provides a literature review in order to complete the overview of the
subject.
2
Example
In the next paragraphs an example is presented in order to explain the procedure of
designing conceptual schemas with ORM method. The example shows the creation of a
conceptual model that a company needs for developing a database of its employees’
information.
Step 1 - Transform familiar information examples into elementary facts, and apply quality
checks: The analyst discuss transforms UoD examples into facts expressed in natural
language, understandable to the client. For example the instances (i) of the real world are
written down by the analyst as elementary facts (Table 2):
4
i1
Instances
Employee with EmpNum
EmpName ‘George Smith’
i2
i3
Facts
‘381’
has
f1
Employee has EmpName
Employee with EmpNum ‘381’ works for
Department named ‘Marketing’
f2
Employee works for
Department
Employee with EmpNum ‘381’ works on
Project named ‘Advertising X Product’
f3
Employee works on Project
Table 2: Transforming instances into elementary facts and fact types
This column is produced by the sub-step 1. Then the experts control the quality of the
result by checking whether the objects are well identified. Informally, sub-step 2, is a note
that recognizes the approval of the instances. In the APPENDIX, the template provided in
the Appendix (Table 5) contains additionally one column to formalize this approval.
Step 2 – Derive fact types, apply population check and draw draft conceptual schema:
The analyst derives the fact types from the fact table that should be populated with at least
one fact (sub-step 3) and the right column of Table 2 is completed. The client is able to
check the validity of the model (sub-step 4). Figure 2 shows the draft schema that depicts
the aforementioned facts (Table 2) drawn by the designer (sub-step 5).
Works for
has
EmpName
Department
(DeptName)
Employee
(EmpNum)
Works on
Project
(ProjName)
Figure 2: Draft schema of fact types mentioned in Step 1
Step 3 – Check for entity types that should be combined and add values and note
arithmetic derivations: In figure 3 someone may notice that the entity Contract (Figure 3)
may combine (sub-step 6) the two different types of contract (part-time contract and fulltime contract) using the codes ‘P’ and ‘F’. EmpName is considered a value. Step three is
also about deriving arithmetic notes. One may wonder how many employees are working
part-time and that is derivable if and only if there is a way to count it in the schema (substep 7).
Step 4 – Add uniqueness constraints, check arity of fact types: In our example an
employee is working for only one department, so the uniqueness constraint is added below
the role ‘works for’ (sub-step 8). The arity of fact types may differ (unary, binary, ternary).
To depict the fact ‘Employee has Contract till Date’ where Contract is defined as an entity,
a ternary predicate is needed, as shown in Figure 3 (sub-step 9).
Step 5 – Add mandatory role constraints, and check for logical derivations: In our
example (Figure 3), every employee works for a department and this role is mandatory.
The black dot is added in the line segment in order to distinguish it from optional roles
(sub-step10a). Sometimes the designer is able to derive logically information from the
schema (sub-step 10b). This may be noted to avoid later changes. The two sub-steps are
not ordered.
5
Step 6 – Add value, set comparison and sub-typing constraints: A value constraint is that
Contract code is restricted to (‘P’, ‘F’) as mentioned before. To give an example of sub
typing constraints, Manager and OfficeEmployee are defined as subcategories of the
Entity Employee. A comparison constraint is drawn in the figure (dotted arrow between
‘works for’ and ‘manages’) to show that the Manager who manages a department must
work for the same department. Step 6 is mapped to sub-step 11.
Step 7 – Add other constraints and perform final checks: To finish the conceptual schema,
the designer may add other constraints, such as frequency, ring and asterisk constraints
(sub-step 12), and to check the validity of the final version with the client (sub-step 13).
OfficeEmployee
Manager
{‘P’,’ F’}
Manages/is managed
ContractCode
Date
(mdy)
Until….. Signed…….has
has
EmpName
Works for
Employee
(EmpNum)
Works on
Department
(DeptName)
Project
(ProjName)
Figure 3: Final Conceptual Schema
Once the final Conceptual Schema is designed it is delivered to the IS modelers and
usually is mapped to a relational database schema. The description of the Database
Management System is well communicated to the client by showing an easily
understandable and close to the natural language schema.
3
PDD, Deliverable Table and Activity Table
Process-Deliverable Diagram (PDD)
In this part, the Object Role Modeling method will be depicted using Process-Deliverable
Diagram, a meta-modeling technique, designed in 2008 by Weerd and Brinkkemper. The
technique combines UML activity and class diagrams, in order to reveal the relations
between the activities and the deliverables of the illustrated method (Weerd &
Brinkkemper, 2008).
As mentioned in the introductory part, ORM is a data modeling method widely used for
the development of DBMS. In other words, ORM provides a data modeling solution
taking into consideration the customers needs of data structures and providing input for the
logical mapping and querying development of a DBMS (Figure 1). The naming of the
activities represents the phases of IS Lifecycle (noun), whereas the naming of the sub
activities represents the steps of the CSDP (sentence starting with verb). This procedure
and its deliverables will be illustrated in Figure 5.
A closer view on the PDD
On the left side of the PDD (Figure 5) the procedure of the method is presented as a set of
activities and sub-activities. The seven steps of the Conceptual Schema Design Procedure
6
(CSDP) are depicted in detail. Data Analysis and Data Design are the basic activities
broken down into sub-activities that illustrate the sub-steps mentioned in Table 1.
Due to the uniformity of some sub-steps concerning constraints addition, a second PDD is
designed. The reason of this division is to simplify the view of the PDD and to facilitate
the reader that is not interested in designing details. This decision led to the creation of the
open sub-activity ‘Add Constraints’, which is further analysed in the sub-PDD. The rest of
the DBMS development activities are illustrated as closed activities (Requirements
Analysis, Logical Mapping and Querying) as their details will not add important
information to the context of the paper. However, it is important to depict them, so as to
position the CSDP in the IS Lifecycle and illustrate its inputs and outputs.
The right side of the PDD, presents the deliverables (concepts) of the activities. Some
concepts (closed) are deliberately not analysed in detail for two reasons; either because
they are not considered relevant with the method (REQUIREMENTS, LOGICAL
SCHEMA, QUERY), or, because their extensive analysis would complicate and unbalance
the diagram and disorient the reader from the actual goal of this paper (ROLE, OBJECT,
ENTITY, VALUE).
The advantages of the design method of the ORM PDD are multiple. First, the previously
unclear roles of the sub-steps are being clarified. Second, the activities are being
distributed in the CSDP phases. Finally, the division of the original steps into sub-steps
simplifies the view of the PDD. This is because most of the sub-steps (sub-activities)
produce one or at most two deliverables, whereas the original steps would all produce
more than two.
The sub-PDD
The creation of the sub-PDD, facilitates the observation and understanding of the main
PDD and provides double-level abstraction. Readers that are interested in detailed Data
Design may easily distinguish the number of constraints and the order of their addition to
the conceptual schema. On the other hand, readers interested in a lower lever of
abstraction may skip the sub-PDD and have an overview of the method.
CONSTRAINT
Add Constraints
Add Uniqueness Constraints
Data Designer
UNIQUENESS
CONSTRAINT
Add Mandatory Role Constraints
Data Designer
MANDATORY ROLE
CONSTRAINT
C
VALUE
CONSTRAINT
Add Value, Comparison and Subtyping
Constrains
Data Designer
COMPARISON
CONSTRAINT
SUBTYPING
CONSTRAINT
Add other Constrains
Data Designer
OTHER
CONSTRAINT
Figure 4: The sub-Process-Deliverable Diagram. Depicts the sub-activity ‘Add Constraints’
of the main PDD and delivers to it the open concept CONTRAINT.
7
Requirements Analysis
DATA MODELING
SOLUTION
REQUIREMENT
IS Analyst
SolutionID
FragementID
DateIssued
Author
1..*
Derives from
Data Analysis
1..*
ELEMENTARY FACT
Transform information into elementary facts
IS Analyst
Number
Description
Quality Check
Fact Type Number
Perform quality checks
UoD Expert
1..*
1..*
[else]
[approved]
1
1
FACT
TABLE
1
FACT TYPE
1
Number
Description
Population Check
Arity
1..*
consists of
consists of
Perform population check
IS Analyst
[else]
[approved]
1..*
1
1
is based on
Derive fact types
IS Analyst
Data Design
1
CONCEPTUAL
SCHEMA
1
1
DRAFT
CONCEPTUAL
SCHEMA
1..*
ROLE
1..*
1..*
plays
1..*
Draw Objects and Roles based on Facts
Data Designer
OBJECT
Combine Entity Types and Values
Data Designer
Note Arithmetic Derivations
Check Arity of Fact Types
1
0..*
1..*
D
ENTITY
VALUE
Data Designer
Data Designer
Add Constraints
Data Designer
0..*
ARITHMETIC
NOTE
0..*
CONSTRAINT
0..*
LOGICAL
DERIVATION
Note Logical Derivations
Data Designer
Perform final checks
Data Designer
[else]
Is mapped to
[approved]
1..*
Logical Mapping
IS Modeler
LOGICAL
SCHEMA
1
derives
1..*
Querying
IS Developer
1..*
QUERY
Figure 5: The main Process Deliverable Diagram (PDD) of Object-Role Modeling (ORM) method.
The figure depicts the activities and concepts of ORM method.
8
Activity Table
Apart from the Concept table, a PDD is accompanied with an Activity table (Table 3).
This table enlists the activities with the relevant sub-activities and sub-sub-activities (from
the sub-PDD) and their descriptions. The description not only defines the sub-activities,
but also verbalizes the derivation of concepts depicted in PDD (Figure 5).
Activity
Sub-Activity
Sub-SubActivity
Requiremen
ts Analysis
Data
Analysis
The IS Analyst interviews the client, user
or UoD expert to collect their needs
(REQUIREMENTs) for data structure. This
information is used to derive
ELEMENTARY FACTs.
REQUIREMENTS are used to derive
conceptual examples of the UoD
(ELEMENTARY FACTs) by the IS Analyst.
Transform
information
into elementary
facts
Perform
Quality Checks
Derive Fact
Types
Perform
population
check
Data
Modeling
Description
Draw objects
and roles based
on facts
Combine
Entity Types
Note
Arithmetic
Derivation
Check Arity of
Fact Types
Add
Constraints
Add
Uniqueness
Constraints
Add
Mandatory
Constraints
The UoD Expert uses his experience to
check the validity of the derived
ELEMENTARY FACTs.
If check of the ELEMENTARY FACTs is
approved, IS Analyst derives FACT TYPEs
from them.
The IS Analyst checks whether each FACT
TYPE has been populated with at least one
fact. FACT TYPES and associated
ELEMENTARY FACTs are depicted in a
FACT TABLE (see example in Table 2).
The FACT TABLE is added in the DATA
MODELING SOLUTION.
If population check is approved, the Data
Modeler draws OBJECTs and ROLEs to
create a DRAFT CONCEPTUAL SCHEMA
(see example in Figure 2).
On the DRAFT CONCEPTUAL SCHEMA
the Data Modeler redefines ENTITY(ies) to
eliminate duplicate types.
The Data Modeler enriches the DRAFT
CONCEPTUAL SCHEMA with
ARITHMETIC NOTEs when there are
possible computational opportunities.
The property Arity of each FACT TYPE is
calculated by the Data Modeler.
The Data Modeler enriches the DRAFT
CONCEPTUAL SCHEMA with a set of
CONSTRAINTs in order to add
information into the drawing.
The Data Modeler enriches the DRAFT
CONCEPTUAL SCHEMA with
UNIQUENESS CONSTRAINTs.
The Data Designer enriches the DRAFT
CONCEPTUAL SCHEMA with
MANDATORY CONSTRAINTs.
9
Add value, set
comparison
and
sub
typing
constraints
Add
other
constraints
The Data Designer enriches the DRAFT
CONCEPTUAL SCHEMA with VALUE
CONSTRAINTs, COMPARISON
CONSTRAINTs and SUBTYPING
CONSTRAINTs.
The Data Designer enriches the DRAFT
CONCEPTUAL SCHEMA with OTHER
CONSTRAINTs.
Note Logical
Derivation
The Data Designer enriches the DRAFT
CONCEPTUAL SCHEMA with LOGICAL
DERIVATIONs.
Perform Final
Checks
The Data Designer checks the enriched
DRAFT CONCEPTUAL SCHEMA in order
to formalize it into a final CONCEPTUAL
SCHEMA (see example in Figure 3), which
will become part of the DATA MODELING
SOLUTION.
If the final CONCEPTUAL SCHEMA is
Logical
Mapping
approved, the IS Designer abstracts its data
content into a LOGICAL SCHEMA, that is
added to the DATA MODELING
SOLUTION.
The IS Developer creates QUERIES that
correspond to the LOGICAL SCHEMA in
order to provide code for the DATA
MODELING SOLUTION. Sometimes this
activity is atomized. The QUERY(ies) are
added to the DATA MODELING
SOLUTION.
Querying
Table 3: Activity Table - Enlists the activities and sub-activities of the PDD.
Concept Table
Along with the PDD, it is important to list the concepts and their descriptions. The
description of each concept consists of its definition and presents the relationships with
other concepts. Table 4 enlists all the concepts that are illustrated in the PDD (Figure 5).
Concept
Description
REQUIREMENT
A REQUIREMENT is gathered information about customer’s DBMS needs
(Naiburg & Maksimchuck, 2001)
An ELEMENTARY FACT is a verbalized expression of UoD examples
derived from REQUIREMENTs (Halpin, 1993).
A FACT TYPE is an expression that models its associated ELEMENTARY
FACTs. FACT TYPEs consist of OBJECTs and ROLEs (Halpin, 1998).
A FACT TABLE is a table that consists of the association of
ELEMENTARY FACTs and FACT TYPEs (Halpin, 1998). It is part of the
DATA MODELING SOLUTION and it creates a mapping of the instances
A ROLE is a participation in a relationship between one or more OBJECTs
(Halpin, 1998). It is part of the DRAFT CONCEPTUAL SCHEMA thus the
CONCEPTUAL SCHEMA too (Halpin, 1998).
A VALUE is a lexical OBJECT type (Halpin, 1998). It is part of the DRAFT
CONCEPTUAL SCHEMA thus the CONCEPTUAL SCHEMA too (Halpin,
1998).
ELEMENTARY
FACT
FACT TYPE
FACT TABLE
ROLE
VALUE
10
ENTITY
OBJECT
ARITHMETIC
NOTE
LOGICAL
DERIVATION
UNIQUENESS
CONSTRAINT
MANDATORY
ROLE
CONSTRAINT
VALUE
CONSTRAINT
COMPARISON
CONSTRAINT
SUBTYPING
CONSTRAINT
OTHER
CONSTRAINT
CONSTRAINT
DRAFT
CONCEPTUAL
SCHEMA
CONCEPTUAL
SCHEMA
LOGICAL
SCHEMA
QUERY
DATA
MODELING
SOLUTION
ENTITY is an OBJECT distinguishable from other OBJECTS and refers to a
thing, person, event or concept of real life or Universe of Discourse (UoD)
(Pol & Ahuja, 2007).
OBJECT is either an ENTITY or VALUE (Halpin, 1998) that plays ROLES.
It is part of the DRAFT and formal CONCEPTUAL SCHEMA (Halpin, 1998).
ARITHMETIC NOTE is a rule derived from FACT TYPEs and noted in
order to add arithmetic information to a CONCEPTUAL SCHEMA (Halpin,
1993).
LOGICAL DERIVATION is a rule derived from FACT TYPEs. It expresses
functional relationships of interest that are not omitted so far. It consists part of
a DRAFT and formal CONCEPTUAL SCHEMA (Halpin, 1993).
UNIQUENESS CONSTRAINT is a type of CONSTRAINT used to declare
that instances for a ROLE are unique (Halpin, 1998).
MANDATORY CONSTRAINT is a type of CONSTRAINT used to declare
that instances in the ROLE’s OBJECT type must play that role (Halpin,
1998).
VALUE CONSTRAINT is a type of CONSTRAINT that its OBJECT type’s
population is restricted to certain values (Halpin, 1998).
COMPARISON CONSTRAINT is a CONSTRAINT that indicates whether a
ROLE is subset of, equal to or excluded from another ROLE (Halpin,
1998).
SUBTYPING CONSTRAINT is a CONSTRAINT that indicates that one
OBJECT is subtype of another (Halpin, 1998).
OTHER CONSTRAINT is a CONSTRAINT that may indicate frequency,
irreflexibility, intransitivity, acyclicity, asymmetry, anti-symmetry or
symmetry (Halpin, 1998).
CONSTRAINT is the generalization of UNIQUENESS CONSTRAINTs,
MANDATORY
ROLE
CONSTRAINTs,
VALUE
CONSTRAINTs,
COMPARISON CONSTRAINTs, SUBTYPING CONSTRAINTs and
OTHER CONSTRAINTs.
DRAFT CONCEPTUAL SCHEMA is a schema that initially consists of
ROLEs and OBJECTs and during the Data Modeling activity is enriched
with CONSTRAINTS, ARITHMETIC NOTEs and LOGICAL DERIVATIONs.
If checked for validity, it consists the basis for a formal CONCEPTUAL
SCHEMA (Halpin, 1998).
CONCEPTUAL SCHEMA is an enriched DRAFT CONCEPTUAL SCHEMA
validated through a check process (Halpin, 1998). It consists of ROLEs,
ENTITIEs,
CONSTRAINTs,
LOGICAL
DERIVATIONs
and
ARITHMETIC NOTEs (Halpin, 1998).
LOGICAL SCHEMA is a schema that abstracts the data content of a
CONCEPTUAL MODEL into database implementation specifications
(Yeung & Hall, 2007).
QUERY is a part of database language code, used for the development of a
database.
DATA MODELING SOLUTION is the document that derives from the
procedure of analysing and modeling data structures based on ORM, a
fact-oriented approach (Halpin, 2003). It consists of a FACT TABLE, a
CONCEPTUAL SCHEMA, a LOGICAL SCHEMA and QUERY(ies).
Table 4: Concept Table - Enlists the concepts of the PDD.
11
4
Related Literature
The field of information modeling has been extensively researched during the past 40
years. Falkenberg was the first researcher that came up with the idea of using n-ary
relationships to represent the conceptual level of information systems (Halpin, 1998).
Nijssen (1976) presented the fact-oriented modeling method, NIAM that was later
renamed as ORM and refined by Halpin (1997). Other approaches of conceptual modeling
are Entity-Relationship model (ER) and Unified Modeling Language (UML). Halpin
(1998) and Balsters (2007) made a comparison between the three modeling methods and
argue that the lack of attributes in ORM provide semantic-stability to its deliverables.
Apart from being a modeling method for database management systems and querying
method for information systems, Object-Role Modeling is applied in a variety of fields.
Some of them are the illustration of complex business rules (Halpin, 1996), domain
modeling (Proper, Bleeker & Hoppenbrouwers, 2004), design of XML-Schemas (Bird,
Goodchild & Halpin, 2000), creation of metadata repositories (Shelstad, Hallock, Dela
Cruz & Barden, 2007).
Extensions of both the NIAM and the ORM method have been developed. Bakema, Zwart
and Lek (1996) introduced an extension of NIAM, called Fully Communication Oriented
Information Method (FCO-IM) that focuses on modelling the conceptual aspects of
communication that a DBMS should support and excluding implementation elements. In
2005, Halpin presented a second revised version of ORM. ORM 2 suggested changes in
the graphical notation of the method that would save the designer time, would provide
more compact deliverables than the first version, and would improve the tooling
perspective.
Commercial tools for Object-Role Modeling are available. Halpin, in collaboration with
Microsoft have automated the procedure with Microsoft Visio for Enterprise Architects.
CaseTalk is a fact based information workbench supporting FCO-IM. Other open source
tools are ORMLite, NormaModeler and Dogma.
5
Conclusions
This paper aimed at presenting an extended overview of the ORM conceptual design
method by adding a helpful meta-model in the related literature. The meta-model has
positioned the method’s design procedure in the IS Lifecycle, has clarified the necessary
inputs and has specified the contributed deliverables during the DBMS design.
The Process-Deliverable Diagram has been proven a substantial meta-modeling technique
to achieve the aforementioned objectives. First, because it provides (a) a clear distribution
of ORM activities in the IS Lifecycle, (b) a graphically presented order of the CSDP steps
and (c) and clarification of their actors for each one of them. Second, because the PDD is
accompanied with the activity and concept tables that provide an explicit description of
activities and deliverables. These can be considered as the dictionary of the ORM method.
Third, because the CSDP dismantled version occurred during the meta-modeling design.
Moreover, the creation of a sub-PDD that supports the main PDD, gives the opportunity to
the reader to obtain a level of abstraction, high or low, based on his needs. It is therefore
obvious that ORM meta-model, is a helpful tool for ORM practitioners, such as IS
Analysts, Database Designers, Modelers and Developers. Method Engineers, interested in
extending, modifying, reconsidering or using fragments of the ORM method may find the
meta-model useful too.
12
6
References
Bakema, G., Zwart, J., & Van der Lek, H. (1996). Fully Communication Oriented
Information Modeling (1st ed.). The Hague: Ten Hagen Stam.
Balsters, H., & Halpin, T. (2007). Modeling Data Federations in ORM. In R. Meersman,
Z. Tari, & P. Herrero (Eds.), On the Move to Meaningful Internet Systems 2007:
OTM 2007 Workshops, Lecture Notes in Computer Science (Vol. 4805, pp. 657–
666). Springer Berlin
Bird, L., Goodchild, A., & Halpin, T. A. (2000). Object-role modeling and XML
schema. Proceedings from 19th International Conference on Conceptual Modeling.
Salt Lake City, Utah: Springer.
Halpin, T. A. (1993). What is an elementary fact. Retrieved from www.orm.net
HU
U
Halpin, T. A. (1996). Business rules and Object-Role Modeling. In Halpin, T.A. (Ed.),
Database Programming and Design: Vol. 9.
Halpin, T. A. (1997). Object-Role Modeling: An Overview. Retrieved from www.orm.net
HU
U
Halpin, T. A. (1998). Object-Role Modeling (ORM/NIAM). In Bernus, P., Mertins, K. &
Schmidt, G. (Eds.). (2005) Handbook on architectures of information systems (pp.
81-101). Berlin: Springer-Verlag.
Halpin, T., Evans, K., Hallock, P. & MacLean B. (2003). Database Modeling with
Microsoft Visio for Enterprise Architects. San Francisco: Morgan Kaufmann
Publishers, ISBN 1-55860-919-9.
Halpin, T. A. (2005). ORM 2. In Meersman, R., Tari, Z., Herrero, P. et al. (Eds.) On the
move to Meaningful Internet Systems (pp. 676-687). Heidelberg: Springer.
Naiburg, E. J., & Maksimchuck, R.A. (2001). Requirements Definition. In UML for
database design (pp. 53-74). Boston: Addison-Wesley Professional
Navathe, S. B., Pernul, G. (1992). Conceptual and Logical Design of Relational Databases.
In Marshall, C. Y. (Ed.), Advances in Computers (pp. 1-78). London: Academic
Press Limited.
Nijssen, G. M. (Eds.). (1976). A gross architecture for the next generation database
management systems. Proceedings of IFIP Working Conf. on Modelling in Data
Base Management Systems. Freudenstadt, Germany: North-Holland Publishing.
Pol, A. A., & Ahuja, R.K. (1998). Entity-Relationship Modeling. In A.A. Pol (Ed.),
Developing Web-Enabled Decision Support Systems (pp. 33-82). Belmont,
Massachusetts: Dynamic Ideas.
Proper, H. A., Bleeker, A. I., & Hoppenbrouwers, S. J. B. A (2004). Object-role modelling
as a domain modelling approach. In Proceedings of Workshop on Evaluating
Modeling Methods for Systems Analysis and Design. Riga, Latvia.
Shelstad, B., Hallock, P., Dela Cruz, N., & Barden, D. (2007). Object Role Modeling
Enabled Metadata Repository. In Meersman, R., Tari, Z., Herrero, P. et al. (Eds.)
On the move to Meaningful Internet Systems (pp. 635-646), Berlin: SpringerVerlag.
13
Weerd, I. van de, & Brinkkemper, S. (2008). Meta-modeling for situational analysis and
design methods. In M.R. Syed, & S.N. Syed, (Eds.), Handbook of Research on
Modern Systems Analysis and Design Technologies and Applications (pp. 38-58).
Hersbey: Idea Group Publishing.
Yeung, A.K.W., & Hall, G.B. (2007). Database Models and Data Modeling. In A.K.W.
Yeung, & G.B. Hall (Eds.), Spatial database systems: design, implementation and
project management (pp.55-92). Dordrecht: Springer Netherlands.
14
APPENDIX
SOLUTION ID:
FRAGMENT ID:
DATE ISSUED:
AUTHOR:
<code>
<code>
<date>
<name>
FACT TABLE AND APPROVAL
INSTANCE
CODE
INSTANCE DESCRIPTION
FACT CODE
i1
f1
i2
f2
i3
f3
in
fn
FACT DESCRIPTION
QUALITY
CHECK
Table 5: Template of Example of Table 2
15
Notice of Originality
I declare that this paper is my own work and that information derived from
published or unpublished work of others has been acknowledged in the text and
has been explicitly referred to in the list of references. All citations are in the text
between quotation marks (“ ”). I am fully aware that violation of these rules can
have severe consequences for my study at Utrecht University.
Signed:
Name: Nikol Gkerpini
Date: 13/05/2012
Place: Utrecht
16