3.2. Conceptual Schema Design Procedure
When developing an information system, we first specify what is required and produce a design to meet these requirements. For reasons outlined earlier, we recommend first developing this design at the conceptual level using Object-Role Modeling. This entails describing the structure of the UoD formally in terms of an ORM conceptual schema. If an ORM context is understood, we’ll often shorten “ORM conceptual schema” to just “conceptual schema”.
The procedure for designing a conceptual schema small enough to manage as a single unit is referred to as the Conceptual Schema Design Procedure (CSDP). Large business domains are first divided into subareas (which may overlap). These subareas are normally prioritized to determine which ones to develop first, and a conceptual subschema is designed for each using the CSDP. With a team of modelers, a consensus on terminology is reached, so the same names are used for the same concepts. Later the subschemas are integrated or merged into a global conceptual schema that covers the whole UoD. This integration is often performed iteratively. This top-down design approach may be summarized as follows:
Divide the universe of discourse into manageable subareas.
Apply the CSDP to each subarea.
Integrate the subschemas into a global conceptual schema.
For each manageably sized business domain or subarea, the conceptual schema design is performed in seven steps:
1. | |
2. | Draw the fact types, and apply a population check. |
3. | Check for entity types to be combined, and note any arithmetic derivations. |
4. | Add uniqueness constraints, and check the arity of fact types. |
5. | Add mandatory role constraints, and check for logical derivations. |
6. | Add value, set-comparison, and subtyping constraints. |
7. | Add other constraints and perform final checks. |
Often all seven steps are performed for each model component as it is discussed with the domain expert, rather than applying step 1 to all components, then step 2 and so on.
The procedure begins with the analysis of examples of information to be output by, or input to, the information system. Basically, the first three steps are concerned with identifying the fact types. In later steps we add constraints to the fact types. Throughout the procedure, checks are performed to detect derived facts and to ensure that no mistakes have been made. The rest of this chapter considers the first three steps in detail.
With large business domains, the preliminary segmentation and final integration add two further stages, resulting in nine steps overall. Although the CSDP is best learned in the sequence of steps shown, in practice we might apply the steps somewhat differently. For example, we might add constraints as soon as the fact types are entered, rather than waiting for all the fact types to be entered before adding any constraints.
In the commercial world, there are many existing applications that have been implemented using lower level approaches, resulting in database designs that may be inconsistent, incomplete, inefficient, or difficult to maintain. Such systems are often poorly documented. These problems can be overcome by reengineering the existing applications using conceptual modeling techniques. For example, sample populations from existing database tables can be used as input to the CSDP.
Even without sample populations, an existing database schema can be reverse engineered to a tentative conceptual schema by using information about constraints and data types and by making assumptions about use of names. The conceptual design can then be validated and completed by communicating with a domain expert. The conceptual schema can then be forward engineered by applying a conceptual optimization procedure and then mapping to the target database system to provide an improved and maintainable implementation. This reengineering approach is discussed in a later chapter.