Building the Analysis Model › Refining the Model › Modeling History and Time

Modeling History and Time

Modeling the existence of entities over time needs more thought from the analyst than representing simply what is found at a single point in time. Converting a "snapshot" model may involve adding entity types, adding or moving attributes, and reconsidering the optionality of attributes and relationship memberships.

Consider, for example, the following three fragments of an Entity Relationship Diagram.

The ERDs in the illustration show versions in the understanding by the analyst of the situation in which departments employ employees.

• Version 1—For a single point in time, the model fragment for Version 1 represents this situation well enough. A department employs many employees, each of who has a Job Title.

Considering the history of this situation, the analyst realizes that many employees have been employed in a number of departments, and therefore a department has employed many more employees than it has at present. The analyst must check that this is indeed a business requirement before further elaborating the model.

• Version 2—This fragment corresponds to the change to the model, but there are information needs which are not yet represented:
  • Job Titles of employees in their previous departments
  • When they worked in those departments

This is an example of hidden information, which is discussed in the section Information Hidden in an M:N Relationship.

• Version 3—Adding an employment entity type to the first fragment, to give Version 3, allows the information needs to be satisfied.

The analyst also notes that there are now two attributes named Job Title, and so changes the name of employee Job Title.

Employment is identified by its Start Date and by relationship memberships with department and employee. In fact, employment, with its Start Date and End Date attributes, is a typical active entity type.

The analyst then realizes that for the employment entities of today, there are no End Date values, so End Date is an optional attribute.

Business staff point out that they need to plan new departments and future employment, and so do not agree with the relationship names employed and formerly employed by. While changing these names, the analyst realizes that the relationship department employs employee is redundant, since the entity type employment and its relationships can represent the past, the future, and the present. Redundant relationships are discussed in Refining the Model. Nor is employee Current Job Title now needed.

Since a new planned department may not yet have any planned employment, the employs relationship membership must be optional. Employment Start Date can have a value in the future, so no further change to the model is needed.

With this improved understanding and consensus, the analyst makes further refinements to produce the fragment shown in the following illustration.