| NIAM was once 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, 2001]. [2] [2] Your author is grateful to Dr. Halpin for providing information to supplement his book, and for his comments and suggestions about this appendix. Any remaining errors, however, are your author's and not his. ORM takes a different approach from the other methods described here. Rather than representing entity types as analogues of relational tables, it shows relationships (that contain one or more "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 entity types independently from relationships. The philosophy behind the language is that it describes "facts," where a fact is a combination of entity types, domains, and relationships. A sample ORM model is shown in Figure B.6 Figure B.6. An ORM Model.  Entity Types and Attributes As shown in Figure B.6, an entity type is portrayed by an ellipse containing its name. An ellipse may also represent a value type , which is similar to a domain. A value type's playing a role in a relationship with an entity type is equivalent to an "attribute" in an entity/relationship diagram. Entity-type labels play roles as identifiers, and these may be shown as dashed ellipses, although as a shorthand, identifying value types may also be shown within the entity-type ellipse in parentheses, below the entity-type name. Nonidentifying attributes always are portrayed as roles played by value typesellipses outside the entity-type ellipse. Thus, relationships not only connect entity types to each other but also value types to entity types as attributes. ORM is unique in being able to raise the question: What is the exact relationship of an attribute to its entity type? In particular, it can describe the optionality and cardinality of attributes. Attributes can be combined if they have the same domain or unit-based reference mode . For example, in Figure B.6, the list price of Product, the rate for a service, and the cost of a Line Item are all taken from the domain "Monetary amount". Similarly, this figure asserts that product names and service names are taken from the same set of names . Relationships ORM presents relationships between two entity types as "roles" that entity types and domains play in the organization's structure. Relationships are assembled from one or more adjacent boxes containing role names and connected to the entity types by solid lines. Relationships are not limited to being binary. Tertiary and higher-order relationships are permitted. Where most methods portray entity types in terms that allow them to be translated into relational tables, ORM portrays the relationships to 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 entity types. Attributes of one or more of the related entity types also then become part of a generated table. A relationship may be "objectified", when it takes on characteristics of an entity type. This is most common in the case of many to many relationships. Note in Figure B.7 that the many-to-many relationship between purchase order and product has been circled. Instead of creating a formal entity type, as is done in many other systems of notation (and as was done above), the relationship simply becomes a "nested fact type" or "objectified relationship". This nested fact type may then be treated as an entity type having other entity types or attributes related to it. In Figure B.7, for example, the nested fact type Line Item is bought in a quantity. Figure B.7. Objectified Relationships.  This is an alternative to simply defining line item as an entity type, as was done in Figure B.6. That was done in that figure because of the exclusive relationship between it and product and service. (See the discussion of constraints between relationships, below.) Cardinality/Optionality Cardinality is addressed differently in ORM than 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 type participating in the relationship. That is, if each Party may be the source of one or more Purchase Orders, then a Party's participation in the source of role is not unique. On the other hand, if each Purchase Order must be to one and only one Party, then Purchase Order's participation in the to role is unique. That is, there is only one occurrence of a Purchase Order's being to a Party. An entity type's uniqueness with respect to a relationship is represented in ORM by a double-headed arrow. If the relationship is one-to-many, the arrow is on the side of the relationship closest to the "many" sidethat is, closest to the side of the entity type that is related to only one other thing. So in our Purchase Order / Party example, the arrow is under the Purchase Order to role, since it is unique. As another example, in Figure B.6, the line item itself can appear only once in a part of role (that is, it can appear only once in a PURCHASE ORDER ) because of the double-headed arrow under part of . Each PURCHASE ORDER is to one and only one party, since the arrow is over " to ". The PURCHASE ORDER , on the other hand, can be composed of more than one LINE ITEM , because LINE ITEM can appear in the set of relationship occurrences more than once. This is shown by the absence of the double-headed arrow on the PURCHASE ORDER' s side of the relationship. If the relationship is one-to-one, the bar appears over each half. For example, there is a double-headed arrow over both sides of the relationship between the entity type PARTY and the domain "Name". This means that each party can have at most one "Name", and each "Name" can be used for at most one PARTY . This is a one-to-one relationship. 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 the objectified relationship model (Figure B.7) note the arrowheads over both bought via and to buy . Optionality : A relationship may be designated as mandatory by placing a solid circle next to the entity type which is the subject of the fact. For example, in Figure B.6, each PURCHASE ORDER must participate in the to relationship with party. Names Entity type and attribute names are the real-world names of the things they represent. Relationship names are verb phrases, and it is permitted to use "is" or "has". There is nothing to prevent use of the Barker convention, however, and that was done in this example. (This becomes problematic , however, in relationships that are not binary.) 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, as a data type), and "US$" (money, as a data type). Spaces may be removed from multiword entity-type names, but all words in a name 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-type ellipse in parentheses, below the entity-type name. If nothing else is shown, these are the unique identifiers of the entity type. 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 B.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 type, a special symbol is used. In Figure B.6, the combination of "number" being line number for a Line Item and Purchase Order being composed of a Line Item are required to identify uniquely an occurrence of the Line Item entity type. This is shown by the uniqueness constraint , represented with a circled "u" between the line number of and the composed of roles. This implies that a given number (such as "2"), while it is a line number 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 Number of" and purchase order must be unique, however. Sub-types A sub-type is represented as a separate entity type, with a thick arrow pointing from it to its super-type. In Figure B.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 B.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 the entity type and its "Type". In Figure B.6, the sub-types of party are exclusive, because the double-headed arrow over is an example of party type, meaning that a party is an example of one and only one party type. It is exhaustive because only the options "P" (person) and "O" (organization) are available for Party Type. Constraints between Relationships 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. The "X" in the symbol means that a Line Item may not be for both a Product and a Service. The dot over the middle of the "X" (  ) means that a Line Item must be for a Product or a Service, but not both. If there were a dot by itself, it would mean that one or the other must apply, but both could apply as well. With no constraint, one or the other, both, or neither could apply. (See the discussion of ORM constraints in Chapter 8 on pages 311332.) Comments 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 entity types and attributes. It is not oriented just toward entity types and relationships, but toward objects and the roles they playwhere an "object" may be an entity type or a value type (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 optionality is shown by making a relationship mandatory or not. Interestingly enough, this approach means the optionality 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, ORM makes domains explicit. All this expressiveness , however, is achieved at some aesthetic cost. A ORM model is necessarily 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 entity types, 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 multibox approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type. ORM also requires a great deal of space to give a separate symbol to each value type and relationship to it. All of this could be mitigated by a CASE tool that permitted a model to be drawn in one form and then converted automatically to the other. The entity/relationship version could be used to convey the overall shape of the model and the important relationships, while the ORM version could portray the relationships in more detail. | 
