¤ Prepare the preliminary data structure diagram:
Detailed diagram conventions and the method of constructing the diagram vary according to the target DBMS. This subtask is composed of these elements:
Entity types that are partitioned are expanded into a hierarchy of entity types, allowing one for each subtype.
For example:
Expansion of multi-valued attributes (if these have been allowed to remain in the data model) involves the creation of a new entity type that has a many-to-one mandatory relationship with the multi-valued attribute's entity type. The multi-valued attribute is then transferred to the new entity type.
For example:
Note that the data model is not changed. This is merely a working step. When no attribute expansion is performed, the designed maximum and minimum number of occurrences of the field representing the multi-valued attribute must be defined for technical design phase.
Many-to-many relationships (i.e., M:M) are rarely left in a data model. The reasons for such a complex relationship almost invariably provide significant attributes that belong to the intersection entity type. If the relationships do remain in the model, you will find that many-to-many relationships are not usually directly supported by a database management system. In such cases, an additional entity type and two one-to-many relationships are substituted for the natural relationships.
For example:
Draw a data structure diagram, in which:
* Each entity type (whether original or added) is mapped to a record type and placed on the data structure diagram
* Each relationship is mapped to a linkage (of the same cardinality) on the data structure diagram
Sometimes this simple mapping results in a construct that does not conform to the structuring rules for the target DBMS. You must then create extra record types and linkages to ensure conformity with the DBMS structuring rules.
The selection conditions identified in the information usage summary are now mapped to entry points.
Here are the mappings for six main categories of direct selection condition:
» Creates deliverable D4.7.1 Preliminary Data Structure Design.
¤ Document design elements:
In this task, the elements are identified, named, and described. The record types, linkages, and some integrity rules are formally documented.
The main design elements are:
* Record types
* Linkages
* Fields
- Fields:
Some fields have already been identified because they appeared in entry points. Others may have been identified while you were mapping relationships, depending on the target DBMS.
Now inspect each attribute within the scope of the project and ensure that it is mapped to a field. Normally, the field will be placed in the record that corresponds to the entity type of the source attribute.
For example:
Integrity rules are essential to the design. These rules have four main sources:
* Integrity conditions: These conditions, involving attributes and relationships, are defined during BAA. They are now mapped into integrity rules, which are expressed in terms of fields and linkages. This is normally a straightforward mapping.
* Relationship optionality: The mandatory and optional natures of relationships must be preserved in the design. When this can be achieved through the inherent structure of the target DBMS, there is no need to define an integrity rule. Otherwise, a rule that all procedures must follow is now defined.
* Subtyping: Subtyping results in exclusive, mandatory, and optional linkages, so the resulting integrity rules must now be defined.
* Duplication of data: Whenever data are duplicated, an integrity rule is required to ensure that the two or more field values are kept consistent. Whenever derived field values are stored, a rule is required to ensure consistency between the derived field value and the source field values. Duplication of data may be introduced in the preliminary data structure design in order to circumvent the DBMS's structuring rules. In such cases, a rule must now be documented. Further duplication may be introduced in technical design phase.
¤ Refine the data structure diagram:
The resulting data structure diagram may now be altered to meet privacy or integrity requirements.
When an entity type has some attributes whose values are to be widely available and others whose values are private, the record type may be split in two to enhance the security of the private data. Similarly, certain entity occurrences in the population may contain attribute values that have a high security level, whereas other occurrences may not. The solution could be to use two record types for the two sets of entities in the population.
When high integrity is required for certain attribute values, the answer may involve duplicating the values, or maintaining check-totals or check-digits. You can now choose to add further fields to the design, or to subdivide the record types with special integrity requirements. This topic will be considered again during the "Design system structure" task, so it is not necessary to make a final decision at this point.
So far, the data structure design mirrors the inherent structure of the data, so that it is easy to use and more resilient to changes in processes. During technical design, the performance of the total system design is checked to make sure that the system meets the given performance criteria and that it is feasible on the chosen hardware.
» Creates deliverable D4.7.2 Refined Data Structure Diagram.
¤ Quantify record types and linkages -
Document the number of occurrences of each record type and the cardinality of each linkage: average, minimum, and maximum. This documentation can be done on a data usage summary diagram.
These figures are based on the equivalent figures collected during the Business Area Analysis project. When the record type or linkage has a 1:1 correspondence with an entity type or relationship, determining the equivalence is trivial. Otherwise, the figures must be decomposed or merged where processes have been decomposed or merged to form procedures.
» Creates deliverable D4.7.6 Data Usage Summary Diagram.
Previous : A4.3.2
Activity Overview : A4.3
Stage Overview : Design Stage
Overview : Table of Contents