A real-world model is never "clean" or strictly hierarchic. It becomes more or less cluttered with different kinds of relations some representing structure others representing more technical relations such as "category" or time-limited, intermidiary or temporary relations. Even though these differences might have no direct technical consequences appyling conventions to be able to tell them apart is important for the overall understanding of the model.

This article covers relationships corresponding to the Classification stereotype found in RISE, see how to use stereotype for further details.

 

Trivial categorization, or classification, can be accomplished by adding an attribute, typically of string type, to the entity. In this case management of the category is entirely up to the application(s) using the information model. In the event of a limited number of valid values this approach could be strenghtened by placing a constraint on the attribute. Thus, forcing it to be within a "hard-coded" range of values.

 

A more flexible, yet easier to manage, approach with guaranteed integrity is to implement the category itself as an entity. A categorized entity would then be related to the category entity.

 

 

In the above examples the Document entity is related to a DocumentType entity. These relations should be seen as the document "having a" document type. The second example requires the document to have a document type where as the first example indicates that the document could have a type.

 

The second, mandatory, relation could easily be confused with a relation intended to structure the information (Building information structures). Let's first conclude that from a strictly technical point-of-view "it is an information structure". To differentiate this structure from a more "ownership based" structure we suggest an approach were categorization entity is named as an extension to entity it categorizes, e.g. DocumentType categorizes Document.

 

This example model consists of a specification, a folder structure, and a user directory. A specification is made up of specified items each related to all documents concering, or covering, the specifications regarding this item. Furhermore, a document is related to the user who - in this case - wrote it. All in all, though clearly limited and incomplete, this model resembles a real world model: Specifications with document support. We are dealing with three different, but related, information structures. Probably, an application built to operate on this model would address the model through one of these structures at a time, e.g. by allowing the user to work with a specification or browsing a folder structure. The "vertical" relations would then prove relevant only once a leaf has been selected in one of the structures. That is, once a specification item is selected it's relevant to find all documents concerning it and for a given document it's of interest to know who's written it. Is there a resonable way to make these distinctions clear when modeling?

 

The left-most, many-to-many, relation clearly denotes a non-structuring relation on its own (since it's symmetric). In an analysis model one might consider using one of the other many-to-many relations such as "1-many to 0-many" which in this case would mean that a document could not exist unless it concerns at least one item in the system. However, from a design and implementation point-of-view this is problably a bad idea since documents are most likely written first and related afterwards.

 

The relation between the user and the document is in no way technically different from the relation between the folder and document. Still, we tend to envision the document as stored in a folder but merely related to the user. One way of making this clear is by explicitly specifiying the role. In the model below we tag the user end-point of the relation with its purpose: Author. This way it becomes clear that this is not a general relation between the entities User and Document.