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 was generalized to "Natural language Information Analysis Method". Indeed, practitioners now also use a still more general name, "Object-role Modeling", or ORM. [Halpin 1995] ^*

ORM takes a different approach from the other methods described here. Rather than representing entities as analogs of relational tables, it shows relationships ("roles" in ORM parlance) to be such analogs. Like Mr. Barker’s notation, 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 ORM, 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.

An entity is portrayed by an ellipse (usually a circle, actually) containing its name. (Figure 6 shows our example described in ORM terms.) Each attribute is also shown in an ellipse, attached to the entity it describes and containing the attribute’s name.

Entity labels (attributes which are 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. ORM is unique in being able to raise the question: what is the exact relationship of an attribute to its entity? In particular, it can describe the optionality and cardinality of attributes.

Domains are explicitly shown as attribute definitions, including those which are simply terms of reference.

Attributes can be combined if they have the same domain or unit based reference mode. For example, in Figure 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.

Instead of relationships between two entities, ORM presents the "roles" that entities, attributes and domains play in the organization’s structure. Indeed, these roles define the relationships between entities. 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, ORM 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 7 that the many to many relationship between purchase order and product has 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 7, for example, the nested fact type line item is bought in a quantity.

This is an alternative to simply defining line item as an entity, as was done in Figure 6 This was done in the Figure because of the exclusive relationship between it and product and service. (See the discussion of constraints between relationships, below.)

As mentioned above, relationships need not be binary. Tertiary and higher-order relationships can be specified by simply concatenating together more relationship segments.

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 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 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"), while it is for only one line item, could apply to more than one purchase order and a given purchase order could be related to more than one line number. The combination of "Line nr" and purchase order must be unique, however.

A sub-type is represented as a separate entity, with a thick arrow pointing from it to its super-type. In Figure 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 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 between party and "PartyType".

In Figure 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.

In the ORM system of notation, constraints between relationships are shown as circles linked to the relationships involved. An "exclusion constraint" (shown in the Figure between the product and service relationships from line item) says that one or the other relationship may apply, but not both. In the example, both line item to buy product and line item to buy 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 circles between the relationships and the entities were 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.

An "inclusion constraint" would have the same structure, but the symbol, instead of having an x in the circle would have an x and a dot. This would allow a line item to buy both a product or a service. If the uniqueness constraint were missing altogether, then a line item would have to be to order both.

In many ways, ORM is the most versatile and most descriptive of the modeling techniques presented here. It has an extensive capability for describing constraints that apply to sets of entities and attributes. It is not oriented just towards entities and relationships, but toward objects and the roles they play — where an "object" may be an entity, an attribute, or a domain. It is constructed to make it easy to describe diagrams in English, although it lacks a discipline for constructing the English sentences.

Cardinality is shown via uniqueness constraints, and ordinality is shown by making a relationship mandatory. Interestingly enough, this approach means the ordinality and cardinality of attributes can be treated in exactly the same way. Must there be a value for an attribute? Can there be more than one?

Unlike all the flavors of entity/relationship modeling described here, it makes domains explicit.

All this expressiveness, however, is achieved at some aesthetic cost. A ORM model of necessity is much more detailed than an equivalent data model, and as a consequence, it is often difficult to grasp the shape or purpose of a particular drawing. Also, because all entities, attributes and relationships carry equal visual weight, it is hard to see which elements are the most important.

While it does permit showing multiple inheritance and multiple type hierarchies, the multi-box approach to sub-types takes up a lot of room on the drawing, limiting the number of other entities that can be placed on it. It also requires a great deal of space to give a separate symbol to each attribute and each relationship. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.

Perhaps one day a CASE tool will make it possible to create a data model for purposes of verifying the overall structure of things, and then convert that to an ORM model for the purpose of exploring the intricacies of rules and constraints that apply to that structure.