Copyright © 1997 Essential Strategies, Inc.

         

NIAM/ORM 

References: G. M. Nijssen and Terry Halpin, Conceptual Schema and

Relational Database Design, (Prentice Hall, Sydney:1989). 

Your author is grateful to Mr. Halpin for providing information to

supplement his book, and for his comments and suggestions about this
article. Any remaining errors, however, are your author's, not his. 

[NOTE: Since this was written, he has published a 2nd edition of this
book.]

 NIAM was originally an acronym for "Nijssen's Information Analysis

Methodology", but more recently, since G. M. Nijssen was only one of many
people involved in the development of the method, it has been generalized to
"Natural language Information Analysis Method". Indeed, practitioners now also
use a more general name, "Object-role Modeling", or ORM. 
NIAM takes a different approach from the other methods described here.
Rather than representing entities as analogs of relational tables, it
shows relationships ("roles" in NIAM parlance) to be such analogs. Like the
CASE*Method [It is called "the CASE*Method" throughout this document. -dh],
it makes extensive use of language in making the models accessible to the public,
but unlike any of the other modeling techniques, it has much greater capacity to
describe business rules and constraints. 
With NIAM, it is difficult to describe entities independently from
relationships. The philosophy behind the language is that it describes "facts,"
where a fact is a combination of entities, attributes, domains, and relationships. 

Entities and Attributes 

 An entity is portrayed by an ellipse (usually a circle, actually) containing its
name. (Figure A-6 shows our example described in NIAM terms.) Each attribute
is also shown in an ellipse, attached to the entity it describes and containing the
attribute’s name. 
 Entity labels (identifiers) may be shown as dashed ellipses, although as a
shorthand, they also may be shown within the entity ellipse in parentheses, below
the entity name. Alternatively, below the entity name may be shown just the
format of the identifier. For example, "nr" represents a numeric field, "dmy" a
date field, etc. A plus sign (+) after nr indicates that it is a calculable number —
typically a system-generated sequence number. Non-identifying attributes always
are portrayed by ellipses outside the entity ellipse. Relationships not only
connect entities to each other but also attributes to entities. (NIAM is unique in
being able to raise the question: what is the exact relationship of an attribute to
its entity?) 
 Domains are explicitly shown as attribute definitions, including those which
are simply terms of reference. In Figure A-6, "date" is shown as an ordinary
attribute, related to purchase order. The same attribute definition (domain) could
be related to any other entity as a domain, where a date reference was required
("delivery date", etc.) The relationship would specify how "date" was used (its
role)

. 
 Figure 6: A NIAM Mode

 Attributes can be combined if they have the same domain or unit based
reference mode. For example, in Figure A-6, the list price of product, the rate
per hour of service, and the actual cost of line item are all taken from the domain
value (or money). Similarly, this Figure asserts that product names and service
names are taken from the same set of names. Surname and party name are shown
separately, implying that the same name could not be put to more than one of
those uses. 

Relationships 
Instead of relationships between two entities, NIAM presents the "roles" that
entities, attributes and domains play in the organization’s structure. Indeed, these
roles define the relationships between entities (for example), but the meaning is
subtly different. Roles (Relationships for our purposes here) are represented by
adjacent boxes containing the two or more relationship names and connected to
the entities by solid lines. Relationships are not limited to being binary. Tertiary
and higher order relationships are permitted. 
Where most methods portray entities in terms that allow them to be
translated into relational tables, NIAM portrays the relationships so that they can
be converted to tables. That is, the two parts (or more) of the relationship become
columns in a "relation" (table). In effect, these are the foreign keys to the two
entities. Attributes of one or more of the related entities also then become part of
a generated table. 
A relationship may be "objectified", when it takes on characteristics of an
entity. This is most common in the case of many to many relationships. Note in
Figure A-7 that the many to many relationship between purchase order and
producthas been circled. Instead of creating a formal entity, as is done in many
other systems of notation, the relationship simply becomes a "nested fact type."
This nested fact type may then be treated as an entity having other entities or
attributes related to it. In Figure A-7, for example, the nested fact type line
item is bought in a quantity. 
Line item was converted to a full entity in Figure A-6, because of the
exclusive relationship between it and product and service. (See the discussion of
arcs, below.) 
 Figure 7: Objectified Relationships

As mentioned above, relationships need not be binary. Tertiary and higher-

order relationships can be specified by simply concatenating more relationship
segments. 

Cardinality / Optionality 
 Cardinality is addressed differently in NIAM from the way it is in the other
methods. Here it is tied up with the uniqueness of occurrences of a fact
(relationship). By definition, each occurrence of a fact applies to a single
occurrence of each entity participating in the relationship. That is, while each
party may be the source of one or more purchase orders, each occurrence of a
party’s being the source of  a purchase order, by definition, applies only to one
party and to one purchase order. 
An entity’s uniqueness with respect to a relationship is represented in NIAM
by a double-headed arrow. For example, in Figure A-6, above, purchase order
uniquely identifies occurrences of the table derived from the is from / is the
source of relationship. That means that each purchase order is from only one
party. (If purchase order were not unique, it would be from more than one party.)
If the relationship is one-to-one, the bar appears over each half. If the
relationship is many-to-many, the arrow crosses both halves of the relationship,
showing that both halves are required to identify uniquely each occurrence of the
relationship.
  In Figure A-6, the line item itself can only appear once in a line
item/purchase order relationship, because of the double headed arrow under is in.
The purchase order, on the other hand, can be to buy more than one line item,
because it can appear in the set of relationship occurrences more than once. This
is shown by the absence of the double-headed arrow on its side of the
relationship. 
 Note that we have put a double headed arrow over both sides of the
relationship between the entity party and the attribute "party name". This means
that each party can have at most one "party name", and each "party name" can be
used for at most one party. 
 Optionality: A relationship may be designated as mandatory by placing a
solid circle next to the entity which is the subject of the fact. For example, in
Figure A-6, each purchase order must participate in theis from relationship with
party. 

Names 
Entity and attribute names are the real-world names of the things they
represent. Relationship names are verb phrases, usually incorporating "is" or
"has". In some usages, past tense is used to designate temporal relationships that
occurred at a point in time, while present tense is used to designate permanent
relationships. Some standard abbreviations are used, such as "nr" (number), and
"$" (money, as a data type). Spaces are removed from multi-word entity names,
but all words have an initial capital letter. 

Unique Identifiers 
As described above, labels may be shown as dashed ellipses, although as a
shorthand, they also may be shown within the entity ellipse in parentheses, below
the entity name. If nothing else is shown, these are the unique identifiers of the
entity. Where both a label and some other identifier are involved (such as a
system-generated unique identifier), the unique identifier is shown under the
name, and the label is shown as another attribute, (albeit with the dashed circle).
For example, in Figure A-6, party is shown as identified by "ID," but it also
is  named with the label party name. 
If two or more attributes or relationships are required to establish uniqueness
for an entity, a special symbol is used. 
 In Figure A-6, the combination of has "line number" and is in purchase
order are required to identify uniquely an occurrence of the line
item relationship. This is shown by the "uniqueness constraint", represented with
a circled "u" between the "line number" attribute and the purchase order entity.
This implies that a given line number (such as "2") could apply to more than one
purchase order and a given purchase order could be related to more than one line
number. 

Sub-types 
A sub-type is represented as a separate entity, with a thick, shaded arrow
pointing from it to the super-type. In Figure A-6, organization and person are
each sub-types of party, as shown by the arrows. In addition, a "type" attribute is
defined as the flag which distinguishes between occurrences of the sub-types
("party type" in Figure A-6). If the sub-types are exhaustive (covering all
occurrences of the super-type), a constraint is shown next to the "type" attribute.
If they are exclusive (non-overlapping), a double-headed line is shown over half
of the relationship. 
In Figure A-6, the sub-types of party are exclusive, because of the double-
headed arrow over is of party type, meaning that a party is of one and only one
party type. It is exhaustive because only the options "P" (person) and "O"
(organization) are available for partytype. 

Relationships 
 In the NIAM system of notation, arcs are shown as "exclusion constraints",
with the symbol "x" in a circle, linked to the relationships it excludes. In the
example, both to order  product and to order service terminate with a solid circle
at line item. This means that each occurrence of line item must be to order either
a product or a service. If the circle was absent, the relationships would be
optional. That would mean that a line item could exist without being related to
either. The exclusion constraint still means that it cannot be both. If the
uniqueness constraint were missing, then a line item could be to order both.