|
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.
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).
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.
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.)
As mentioned above, relationships need not be binary. Tertiary and higher-order relationships can be specified by simply concatenating more relationship segments.
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 the is from relationship with party.
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.
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.
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.
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.
In many ways, NIAM 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. It intentionally does not include specification of cardinality and optionality in it sentences, because it is deemed that this information will be added later, after people have agreed to the basic roles.
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 NIAM 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.
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 a NIAM model for the purpose of exploring the intricacies of rules and constraints that apply to that structure.