Entity Type Name: Synonyms and Homonyms
Use a singular noun that, if possible, is well known to the users.
Two or more names for the same entity type are often found in different parts of a business; these may be synonyms. If a choice of synonyms exists, use the least ambiguous. Keep this standard throughout the analysis, and document the synonyms.
Similar problems occur with homonyms (i.e., where the same name is used for two or more entity types). If this occurs, unambiguous names must be chosen for the entity types, and the homonyms must be documented as synonyms of the affected entity types.
Entity Type Definition
Define what the entities are, not how they are represented as data. Include:
* A definition of scope, or what the entities are, preferably using well-defined and recognizable terms
* A qualification, or method of distinguishing entities, using terms known from names or definitions of other business objects
* It is useful to describe any excluded factors in a definition
* It is extremely useful to give examples of entities of the type
Example of excluded factors
Transport Facility: The vehicles used for distribution of products and transfer of assemblies between factories, but excluding the supply of raw materials, which is subcontracted.
Example of scope and qualifications
Supplier: An organization or person (scope) who supplies (relationship type name) goods or services (entity types) purchased by (relationship type name) a division or department (entity subtypes) (qualification).
Example of entities of an entity type
Solitary Entity Types
If the definition implies that the entity type is solitary (i.e., there is only one entity of its type, such as the enterprise itself), the analysis may be incorrect. Ask if there will always be only one entity (e.g., FACTORY and COMPUTER CENTER may initially be solitary, but there may be plans to build more).
If this entity is relevant, seek another entity type (e.g., ORGANIZATIONAL UNIT) whose definition and relationships may be extended to encompass the entity.
Naming a Relationship Membership
Syntax: Entity Type VERB Entity Type
Use a verb relating the two entity types in a meaningful clause (e.g., CUSTOMER places ORDER). Use an active verb, one used in the name of the process that associates the entity types. Construct an inverse name relating the two entity types in reverse order (e.g., ORDER placed by CUSTOMER). The verb in the inverse name is normally passive. Relationship memberships should be named in the same way.
Name both relationship memberships
Because it is useful to be able to read a relationship from both memberships, both relationship memberships should be named.
Avoid time implications
Allow the relationship name to include past and present (e.g., PERSON sometimes is "employed by" ORGANIZATIONAL UNIT). Specific time implications (e.g., PERSON "previously employed by" ORGANIZATIONAL UNIT) are used only where selectivity is meaningful.
A relationship type can be read in terms of either of its two relationship memberships. It can also be read to include the optionality and cardinality of the chosen membership. The optionality determines whether the relationship may or must hold for a membership. The cardinality determines whether the relationship is to exactly one or to one or more entities for a membership.
Format for Relationship Memberships
The basic format for stating a relationship membership is:
Example of one-to-many relationship type:
Can be read as:
* A BOOK sometime appears as one or more EDITIONs
* An EDITION always is of one BOOK
Example of many-to-many relationship type:
Can be read as:
* An AUTHOR sometimes writes one or more BOOK.
* A BOOK always is written by one or more AUTHORs.
Example of exclusive memberships
If two relationship memberships are exclusive, the two phrases for the memberships can be joined by "OR." Similarly, two inclusive relationship memberships can be joined by "AND."
Each PAYMENT always pays for one or more BOOKs or pays for one or more MACHINEs.
It is possible to think of a relationship between a given entity type and almost every other entity type in a business area. Many of these will associate entity types that are also indirectly associated through other entity types. For example, BOOK stocked in WAREHOUSE is also represented by two other relationships: BOOK held as STOCK, and STOCK held in WAREHOUSE.
Each grouping of a specific book in warehouses can be derived from the BOOK held as STOCK groupings, because a book is stocked only in warehouses where it is allocated to be held as stock. Therefore, the relationship BOOK stocked in WAREHOUSE gives no additional information and is redundant.
A relationship is redundant only if it is so at all times. That is, all the pairings it implies can be derived from other relationships. When you decide whether or not a relationship is redundant, you must consider the optionality of the relationships and the defined meaning of each relationship.
Example of a Redundant Relationship
In this example, REVISION is always of an EDITION, which is always of a BOOK. Because a REVISION must always be of a BOOK, the relationship between REVISION and BOOK is redundant. However, if a book could be revised separately from an edition's being printed (e.g., before the book is formally published), then the relationship between REVISION and EDITION is fully optional. Thus the relationship between REVISION and BOOK is no longer redundant because there will be occasions when there will be no relationship through an edition to a book.
Two exclusive relationships should have the same cardinality and optionality. Treat any exceptions to this with extreme suspicion; the following example is fine.
If different cardinality or optionality is found, show it as:
This situation is rare and suspect.
This example says that either one A entity may be related to one B entity, or a number of A entities must be related to a number of C entities. The two relationships have a very different effect on A. In practice, almost every case where this is required can be resolved as either having the same relationship or not being exclusive in the first place. In many, if not most, cases, it is the same relationship name as well, so most exclusive relationship memberships are for the same type of relationship, they just relate to different entity types.
The most common type of relationship type has the form:
By contrast, fully mandatory one-to-one and many-to-many relationships almost never occur. Treat these cases with caution and suspicion. It is likely that at least one of the memberships is optional.
Fully mandatory one-to-one relationships suggest that the two entity types are the same thing. For example, in the case:
SALABLE ITEM is probably a synonym for PRODUCT because every PRODUCT must be one SALABLE ITEM and vice versa.
You often need to model the structure of the organization you are analyzing, and the module must be as resilient as possible to change. Organizations may change their structure frequently, however, so it is best to model with a generalization. One way of achieving this is by having a single box represent the organization, with an involuted relationship representing the structure. If the organization is structured hierarchically, there will be a one-to-many involution; if it is structured as a matrix, there will be a many-to-many involution.
Other organizations are also modeled (e.g., customers with a head office and subsidiary companies). These are modeled with involutions, as well.
Isolated entity types, (i.e., entity types with no identified relationships) are very rare. If you find one, consider if there have been any relationships missed or if that entity type is really useful. Can it be useful if it has no firm association with any other information relevant to the enterprise?
Consider one-to-one relationships to see if the related entity types are the same thing. This is likely if you find a mandatory, one-to-one relationship. Similarly, if you find partly optional one-to-one relationships, consider whether the entity types are the same over time (e.g., PROSPECT becomes CUSTOMER in which case, treat PROSPECT as a state in the life of CUSTOMER) or if one is a subtype of the other. An alternative may be that over-time, the relationship is one-to-many or many-to-many.
If you find many-to-many relationships, hypothesize a third entity type that participates in two many-to-one relationships with the original entity types. If you find attributes for this third entity type, keep them and define them. If none can be found, there is a true many-to-many relationship.
For example, the original diagram shows a M:N relationship type.
This is resolved through the creation of a third entity type, AUTHOR CONTRIBUTION.
You can find attributes for this entity type of "Contribution Amount," "Data" and so on; therefore, it is a valid entity type.
The original relationship type (i.e., AUTHOR writes BOOK) is now redundant and can be removed. All the information can be gained through the use of AUTHOR CONTRIBUTION.
Many to Many Relationship Type
A common example of a many-to-many relationship is found in a bill of materials structure in which a PART may be "made from" many other PARTs.
Drawing a diagram is a good way of identifying possible additional relationships. The following guidelines will help create a readable document.
* Place subject entity types on the top of the diagram.
* Place plural entity types below a single entity type in a one-to-many relationship.
* Place entity types participating in one-to-one and many-to-many relationships alongside each other.
* Group closely related entity types when possible. Try to keep the length of relationship lines as short as possible. Also try to minimize the number of changes of direction in a single line.
* Lay out the diagram with minimal line crossing.
* Show the most relevant relationship name. One name must always be shown.
Another way to draw diagrams by hand is to use different-sized entity type boxes instead of bending a line. For example, instead of:
The following can be effective in manually prepared presentations.
General Approach
An entire entity relationship diagram should not be presented to an audience; it should be presented bit by bit and should build up to the complete diagram. The presentation should start with subject entity types.
Initially, a single entity type should be presented, its definition and significance described, and the concept of entity type briefly explained. Next, one of its relationships should be shown, the concept of relationship, optionality, and cardinality explained, and the related entity type and its definition described.
This continues, with more and more concepts being shown at a time, until the complete diagram is displayed. The best method of achieving this is to have a series of overhead projector slides prepared, each with more on it than on the slide before.
Drawings for Working Sessions
If the session is for feedback, as opposed to being a formal presentation of deliverables, it is best to avoid carefully drawn diagrams because people may be reluctant to change them.
Audience Involvement
Try to get your audience involved in the presentation and questioning of every property on the diagram.
Presentation of Entity Types
When presenting an entity type, give its name, definition, and some examples of entities (this will necessitate a discussion of some of the main attributes).
Level of Detail
It is possible to simplify the diagram presented (e.g., by not showing optionality or relationship type names), but it is usually best to present complete detail using the above guidelines.
Previous : Rules
Section Overview : Entity Relationship Modeling Technique
Techniques Overview : Techniques
Overview : Table of Contents