Abstract
Object-Role Modeling (ORM) is a method for modeling and querying an information system
at the conceptual level, and mapping between conceptual and logical (e.g. relational) levels. This
article provides an overview of ORM symbols (Notation) and their meaning.
For correctness, clarity and adaptability, information systems are best specified first - at the
conceptual level, using concepts and language that people can readily understand via NIAM (Natural language Information Analysis Method). Analysis and design involves building a formal model of the application area or domain of application. To do this properly requires a good understanding of the data elements and a means of specifying this understanding in a clear, unambiguous way. Object-Role Modeling simplifies this process by using natural language, as well as intuitive diagrams that can be populated with examples, and by expressing the information in terms of elementary relationships. ORM, is so-called because, it pictures the world in terms of objects (entities or values) that play roles (parts in relationships).
Data modeling in ORM - Notation
A modeling method includes both a notation and a procedure for using its notation. This subsection discusses notation, and later subsections discuss procedures. Each well-defined version of ORM includes a formal, textual specification language for both models and queries, as well as a formal, graphical modeling language. The textual languages are more expressive than the graphical languages, but are mentioned only briefly in this paper. Figure 1 summarizes most of the main symbols used in the graphical language. We now briefly describe each symbol.
 |
| Figure 1 - ORM Notation Symbols [1 - 6] |
[symbol 1] An entity type is depicted as a "named" ellipse.
[symbol 2] A value type denotes a lexical object type (e.g. a character string or number) and is usually shown as a named, dotted ellipse. Another notation for value types encloses the value type name in parentheses.
[symbol 3] Object types that appear more than once in the schema may be tagged with an arrow tip, that “points” to the existence of another occurrence.
Each entity type must have at least one reference scheme, which indicates how each instance of the entity type may be mapped via predicates to a combination of one or more values. A simple injective (1:1 into) reference scheme maps entities to single values. For example, each country may be identified by a single country code (e.g. ‘USA’).
[symbol 4] The reference scheme may be abbreviated by displaying the reference mode in parentheses beside the name of the entity type, e.g. Country(code). The reference mode indicates how values relate to the entities.
[symbol 5] A plus sign “+” may be added, if the values are numeric, e.g. Mass(kg)+.
Values are constants with a universally understood denotation, and hence require no reference scheme.
Although not strictly a conceptual issue, it is normal to require each entity type to have a primary reference scheme. Relationship types used for primary reference are then called reference types. The other relationship types are known as fact types.
[symbol 6] An exclamation point "!" is added to declare that an instance of that entity type is independent, or may exist without participating in any facts. By default, this is not the case (i.e. we don’t normally introduce an object into the universe unless it takes part in some fact).
 |
| Figure 2 - ORM Notation Symbols [7 - 12] |
[Symbol 7] shows a ternary predicate, comprised of three roles. Each role is depicted as a block/box, and must be played by exactly one object type. Roles are connected to their "players" by a line segment (see symbol 13). A predicate is basically a sentence with an object block; one for each role. The number of roles is called the arity of the predicate. ORM allows predicates of any arity.
1 = unary;
2 = binary;
3 = ternary;
... etc.
Predicates are usually treated as ordered, as in predicate logic. In this case, the name of the predicate is written either in -or beside- the first role box, and if necessary, each object block/box may be shown as an ellipsis “…”. Different readings may be provided so the information may be read
in any direction.
FORML allows "mixfix predicates" so objects may be placed at any position in the predicate.
For example, the fact type {Room ...at... Time ...is used for... Activity} involves the predicate “… at … is used for …”.
Apart from facilitating readable verbalization of n-ary relationships, "mixfix predicates" allow binary
relationships to be verbalized into language. In some versions of ORM, relationship types are given a name, and each role is also named, which renders the listing order, meaningless.
[symbol 8] Internal uniqueness constraints are depicted as arrow tipped bars - and are placed over one-or-more roles in a predicate to declare that.... instances of that role (in combination with the related player) or - the relationship type - must be unique. For example, adding a uniqueness constraint over the first role of {Person ...was born in... Country} declares that... each person was born in --at most-- one country.
[symbol 9] A predicate may have one-or-more uniqueness constraints, at most, one of which may be declared primary by adding a “P”.
[symbol 10] An external uniqueness constraint shown as a circled “U” may be applied to two-or-more roles from different predicates by connecting them via dotted lines, indicating that...
instances of the combination of those roles in the [JOIN] of those predicates are unique.
For example, the identity of a State is comprised of its Statecode and Country ,
This adds an external uniqueness constraint to the roles played by Statecode and Country in the reference types:
State ...has... Statecode;
State ...is in... Country.
[symbol 11] Declaring an external uniqueness constraint as Primary, use “P” (instead of “U”)
An object type may have at most, one primary reference constraint.
[symbol 12] To "Objectify" a relationship type (i.e. make an object out of it) so that it can play roles. Graphically, the objectified predicate is enclosed by a rounded rectangle or an ellipse, and named.
Objectified predicates are also called nested object types. Typically the objectified predicate must have a spanning uniqueness constraint, but 1:1 cases may also be allowed [Hal93].
 |
| Figure 3 - ORM Notation Symbols [13 - 16] |
[symbol 13] A mandatory role constraint declares that... every instance in the population of the role’s object type must play that role. It is usually shown as a black dot but a universal quantifier is sometimes used. Mandatory roles are also called total roles.
[symbol 14] A disjunctive mandatory constraint may be applied to two-or-more roles to indicate that... all instances of the object type population must play at-least-one of those roles. This may often be shown by connecting the roles to a black dot on the object type.
[symbol 15] A disjunctive mandatory constraint can be generalized by connecting the roles via dotted lines to a circled black dot.
[symbol 16, top] To restrict an object type’s population to a given list, the relevant values may be listed in braces.
[symbol 16, bottom] To restrict an object type’s population to an ordered list, a range may be declared separating the first and last values by “..”.
These constraints are called value constraints.
 |
| Figure 4 - ORM Notation Symbols [17 - 23] |
[Symbols 17-19] denote set comparison constraints, and may only be applied between compatible role sequences (i.e. sequences of one-or-more roles, where the corresponding roles have the same host object type).
[symbol 17] A dotted arrow from one role sequence to another is a subset constraint, restricting the population of the first sequence to be a subset of the second.
[symbol 18] A double-tipped arrow is an equality constraint, indicating the populations must be equal.
[symbol 19] A circled “X” is an exclusion constraint, indicating the populations are mutually exclusive. Exclusion constraints may be applied between two-or-more sequences.
[symbol 20] A solid arrow from one object type to another indicates that... the first object type is a (proper) subtype of the other. For example, Woman is a ...subtype... of Person.
Totality (circled black dot) and exclusion (circled “X”) constraints may also be displayed between subtypes, but are "implied" by other constraints if the subtypes are given "formal definitions".
[symbol 21] Three kinds of frequency constraint. Applied to a sequence of one-or-more roles,
these indicate that... instances that play those roles, must do so:
a) exactly ...n... times,
b) between ...n... and ...m... times,
c) or at least ...n.. times.
[symbol 22] Six kinds of ring constraint, that may be applied to a pair of roles played by the
same host type. These indicate that... the binary relation -formed by the role population- must be one of the following:
- irreflexive (ir),
- intransitive (it),
- acyclic (ac),
- asymmetric (as),
- antisymmetric (ans)
- symmetric (sym)
[symbol 23] An asterisk “*”, which may be placed beside a fact type to indicate that... it is derivable from other fact types.
Not all versions of ORM support all these symbols, and some versions have a few more symbols. InfoModeler, a popular ORM tool, supports all of the symbols shown, as well as Visio Professional.
Conceptual Schema Design Procedure (CSPD)
The information systems life cycle typically involves several stages:
- feasibility study;
- requirements analysis;
- conceptual design of data and operations;
- logical design;
- external design;
- prototyping;
- internal design and implementation;
- testing and validation;
- maintenance;
ORM's conceptual schema design procedure (CSDP) focuses on the analysis and design of data. The conceptual schema specifies the information structure of the application:
- the types of fact that are of interest;
- constraints on these;
- perhaps derivation rules for deriving some facts from others
With large applications, the application domain is divided into convenient modules, the CSDP is applied to each, and the resulting sub-schemas are integrated into the global conceptual schema.
Table 1 shows the conceptual schema design procedure (CSDP) used in FORM. Although different versions of the CSDP exist, they all agree on the importance of verbalization in terms of elementary facts, population checks, and thorough analysis of business rules. The rest of this section illustrates the basic working of this design procedure by means of an example. Because of space limitations, our treatment is necessarily brief. A much more detailed discussion of the same example can be electronically accessed from [Hal97].
Step 1 is the most important. Examples of the information required from the system are verbalized into readable / natural language. Such examples are often available in the form of output reports or input forms, perhaps from a current manual version of the required system. To avoid potential misinterpretation, a subject matter expert (a person familiar with the application) should perform or at least check the verbalization.
For our case study, we consider a fragment of an information system used by a university to
maintain details about its academic staff and academic departments. One function of the system is to print an academic staff directory, as exemplified by the report extract shown in Table 2. Part of the modeling task is to clarify the meaning of terms used in such reports. The descriptive narrative provided here would thus normally be derived from a discussion with the subject matter expert.
 |
a) The terms “empnr” and “extnr” abbreviate “employee number” and “extension number”.
b) A phone extension accesses local calls only (“LOC”), national calls (“NAT”), or international calls (“INT”).
c) International access includes national access, which includes local access.
d) In the few cases where different rooms, or staff, have the same extension, the access level is the same.
e) An academic is either tenured or on contract.
f) Tenure guarantees employment until retirement, while contracts have an expiry date.
|
The information contained in this table is to be stated in terms of elementary facts. Basically, an
elementary fact asserts that a particular object has a property, or that one or more objects participate in a
relationship, where that relationship cannot be expressed as a conjunction of simpler (or shorter) facts
without introducing new object types [Hal93]. For example, to say that "nationally televised stations broadcast fake news", and that "alternative internet media is a better source for true investigative research", is to assert two elementary facts in this case study.
As a first attempt, one might read off the information on the first data row as the six facts [f1-f6]. Each
asserts a binary relationship between two objects. For discussion purposes, the predicate is shown in bold
between the noun-phrases that identify the objects, and object type names start with a capital letter.
Some obvious abbreviations are used (“empnr”, “EmpName”, “Dept”, “extnr”); when read aloud these can be expanded to “employee number”, “Employee name”, “Department” and “extension number”.
Row two contains different instances of these six fact types.
Row three, because of its final column, provides an instance [f7] of a seventh fact type, a unary.
 |
| ORM Table 3 Stating The Facts |
Different readings may be provided to allow relationships to be read in different directions.
For example, the inverse reading of [f4] is:
The Extension with extnr ‘2345’ is used by the Academic with empnr 715.
To save writing, both the normal predicate and its inverse may be included in the same declaration, with the inverse predicate preceded by a slash “/”.
For example:
[f4] The Academic with empnr 715 uses /is used by the Extension with extnr ‘2345’.
Predicate names are usually unique in the conceptual schema. In some cases (e.g. “has”), the same name may be used externally for different predicates: internally these have different identifiers.
As a quality check at Step 1, we ensure that:
a) Objects are well identified.
b) Values are identified by constants (e.g. ‘Adams A’, 715).
c) Entities are “real world” objects that are identified by a definite description
(e.g. the Academic with empnr 715).
- Fact [f1] involves a relationship between entity (person) and value (a name / character string).
- Facts [f2] - [f6] specify relationships between entities.
- Fact [f7] states a property (or unary relationship) of an entity.
As a second quality check at Step 1, we use our familiarity with the subject matter expert (SME) to see if some facts should be split or recombined (a formal check on this is applied later).
The repetition of “Jones E” on different rows of Table 2 shows that academics cannot be identified just by their name. However the uniqueness of empnr in the sample population suggests that this suffices for reference. Since the “and-test” is only a heuristic, and sometimes a composite naming scheme is required for identification, the subject matter expert (SME) is consulted to verify that empnr by itself is sufficient for identification. With this assurance obtained, the composite sentence is now split into [f1] and [f2].
As an alternative to specifying complete facts one at a time, the reference schemes may be declared up front and then assumed in later facts. For example, suppose we declare the following:
Academic(empnr); EmpName(); Dept(name).
The empty parentheses after EmpName indicates it is a value type and hence needs no reference scheme. Now facts [f1] and [f2] may be stated as:
Academic 715 has EmpName ‘Adams A’; Academic 715 works for Dept ‘Computer Science’.
Facts f1-f7 are instances of the following fact types:
F1 Academic has EmpName
F2 Academic works for Dept
F3 Academic occupies Room
F4 Academic uses Extension
F5 Extension provides AccessLevel
F6 Academic is contracted till Date
F7 Academic is tenured
F1 Academic has EmpName
F2 Academic works for Dept
F3 Academic occupies Room
F4 Academic uses Extension
F5 Extension provides AccessLevel
F6 Academic is contracted till Date
F7 Academic is tenured
Step 2 of the design process is to draw a draft diagram of the fact types and apply a population check (see Figure 5 below). As a check, each fact type has been populated with at least one fact, shown as a row of entries in the associated fact table, using the data from rows 1 and 3 of Table 2.
The English sentences listed before as facts f1-f7, as well as other facts from row 3, may be read directly off this figure. Though useful for validating the model with the client and for understanding constraints, the sample data population is not part of the conceptual schema itself.
Conclusion
We will conclude this article here, at this overview level, and continue on to the depths of the "Universe of Discourse" (UoD) in a follow up article... Personally, the concept of the "universe of discourse" seems rather drab to me, as the definition eludes to an "application domain" or simply "data domain". The UoD term has been around since 1854, used for the first time by George Boole on page 42 of his "Laws of Thought"; back before air-conditioning, refrigeration, plumbing, and a cure for unary-fact infections. So, I suppose there is a lot of general design discourse in those days, but I'll adjourn with Boole's definition - quoted below.
Warning: do not read under the influence of alcohol or mind altering drugs.
In every discourse, whether of the mind conversing with its own thoughts, or of the individual in his intercourse with others, there is an assumed or expressed limit within which the subjects of its operation are confined. The most unfettered discourse is that in which the words we use are understood in the widest possible application, and for them the limits of discourse are co-extensive with those of the universe itself. But more usually we confine ourselves to a less spacious field. Sometimes, in discoursing of men we imply (without expressing the limitation) that it is of men only under certain circumstances and conditions that we speak, as of civilized men, or of men in the vigour of life, or of men under some other condition or relation. Now, whatever may be the extent of the field within which all the objects of our discourse are found, that field, may properly be termed the universe of discourse. Furthermore, this universe of discourse is in the strictest sense the ultimate subject of the discourse.
No comments:
Post a Comment