preliminary data model

This content is an extract from GetAhead in Business Analysis - the FULL course is in eBook and multimedia CD-Rom format.

Converting the list to a preliminary data model.
When the initial list of entities and relationships has been completed, these should be drawn on a preliminary data model. This diagram should then be refined, through a series of iterative steps. Clarity is aided by placing those entities involved in the greatest number of relationships near the center of the diagram and placing the detail entities beneath their master entities wherever possible. The relationship lines are then drawn, bending them where necessary to avoid crossing lines. Finally, 'bridges' are drawn where the crossing of lines cannot be avoided. Don't spend too much time perfecting these early diagrams, as they should only be seen as intermediate steps in the production of the final data model. Remember that one-to-one and many-to-many relationships are permitted on preliminary data models, even though they must be resolved in the final model.

Clarifying the Initial Diagram.
This exercise involves the drawing of a preliminary data model for a system in which 11 entities and 13 relationships have been identified. The first step to clarifying an initial diagram like this involves re-ordering the entities to minimize the crossing of lines and, where possible, to show detail entities below their master entities. When you have drawn your own solution for this, go to the next page to see the suggested solution. Remember, there are several ways in which any diagram may be drawn. The diagram can then be further clarified by bending any overlapping relationship lines and by drawing bridges where the crossing of relationship lines cannot be avoided. When you have drawn your own solution for this, go to the next page to see the suggested solution.
This redrawn data model is far clearer than the original diagram.

Checking the Preliminary Model.
The preliminary diagram should be refined in the following order: Check the diagram to ensure that all of the relationships drawn are necessary. In other words, that information would be lost if they were removed. Any areas of the diagram where relationships form loops should be given special consideration. However, it is important to think very carefully before removing apparently redundant relationships. This is illustrated in detail in the advanced exercises, later in this book. Next, compare the data model diagram with the business model diagram. This is derived using a technique called Business Modeling; as described in the sister course ‘GetAhead in Business Analysis’. Any inconsistencies between these two views should be resolved:

Question One. Does the business model show a process that will create, delete and, where appropriate, amend the data held for each entity type? If not there is an inconsistency that needs to be addressed.
Question Two. Verify that data stores in the business model have a simple relationship with the entities in the data model, ideally they should map directly to one another. No entity identified in either diagram should be split - that is they should not be only partially held within a data store.
Question Three. Can all elementary processes in the business model access their required information? If not, these areas will require more detailed analysis.

Resolving the Relationships.
The next step is the resolution of many-to-many relationships. This is normally done by the introduction of a link entity. Remember, the users of the system should be involved when naming the link entities and the relationship link phrases. One-to-one relationships also need to be resolved. These are normally removed either by merging the two entities involved, or by changing it into a one-to-many relationship. The final step is to identify and remove any connection traps. It is not always the case that because entities are connected on the diagram, association between individual entity occurrences is possible.
The existence of a relationship between two entity types does not automatically mean that specific occurrences can be linked. The best way to consider this problem is to think of individual occurrences and then see if direct mapping of them is possible. This failure to link specific occurrences is termed a 'connection trap' and is often resolved by introducing a link entity. You will see this process illustrated in the advanced exercises, later in this book.

This content is an extract from GetAhead in Business Analysis - the FULL course is in eBook and multimedia CD-Rom format. TOP