Database Modeling & Design Fourth Edition- P19 pdf

4.5 Entity Clustering for ER Models 77 • Dominance grouping • Abstraction grouping • Constraint grouping • Relationship grouping These grouping operations can be applied recursively or used in a variety of combinations to produce higher-level entity clusters, that is, clusters at any level of abstraction. An entity or entity cluster may be an Figure 4.9 Grouping operations (a) Dominance grouping (b) Abstraction grouping (c) Constraint grouping (d) Relationship grouping Teorey.book Page 77 Saturday, July 16, 2005 12:57 PM 78 CHAPTER 4 Requirements Analysis and Conceptual Data Modeling object that is subject to combinations with other objects to form the next higher level. That is, entity clusters have the properties of entities and can have relationships with any other objects at any equal or lower level. The original relationships among entities are preserved after all grouping operations, as illustrated in Figure 4.8. Dominant objects or entities normally become obvious from the ER diagram or the relationship definitions. Each dominant object is grouped with all its related nondominant objects to form a cluster. Weak entities can be attached to an entity to make a cluster. Multilevel data objects using abstractions such as generalization and aggregation can be grouped into an entity cluster. The supertype or aggregate entity name is used as the entity cluster name. Constraint-related objects that extend the ER model to incorporate integrity constraints, such as the exclusive- OR can be grouped into an entity cluster. Additionally, ternary or higher degree relationships potentially can be grouped into an entity cluster. The cluster represents the relationship as a whole. 4.5.3 Clustering Technique The grouping operations and their order of precedence determine the individual activities needed for clustering. We can now learn how to build a root entity cluster from the elementary entities and relationships defined in the ER modeling process. This technique assumes that a top- down analysis has been performed as part of the database requirement analysis and that the analysis has been documented so that the major functional areas and subareas are identified. Functional areas are often defined by an enterprise’s important organizational units, business activ- ities, or, possibly, by dominant applications for processing information. As an example, recall Figure 4.3 (reconstructed in Figure 4.10), which can be thought of as having three major functional areas: company organization (division, department), project management (project, skill, location, employee), and employee data (employee, manager, secretary, engineer, technician, prof-assoc, and desktop). Note that the functional areas are allowed to overlap. Figure 4.10 uses an ER diagram resulting from the database requirement analysis to show how clustering involves a series of bottom-up steps using the basic grouping operations. The fol- lowing list explains these steps. 1. Define points of grouping within functional areas. Locate the domi- nant entities in a functional area through natural relationships, local n-ary relationships, integrity constraints, abstractions, or Teorey.book Page 78 Saturday, July 16, 2005 12:57 PM 4.5 Entity Clustering for ER Models 79 Figure 4.10 ER diagram: clustering technique 1 1 1 N belongs-to N N is-allocated 1 1 has- allocated 1 1 is- managed-by contains is- headed-byhas d 1 1 N 1 1 11N Employee N 1 Project TechnicianEngineerSecretaryManager Prof-assocWorkstationDesktop skill-used assigned-to Department Division N N Location Skill is-allocated 1 1 is- married-to manages + N N Employee data functional area Project management functional area Company organization functional area Teorey.book Page 79 Saturday, July 16, 2005 12:57 PM 80 CHAPTER 4 Requirements Analysis and Conceptual Data Modeling just the central focus of many simple relationships. If such points of grouping do not exist within an area, consider a functional grouping of a whole area. 2. Form entity clusters. Use the basic grouping operations on elemen- tary entities and their relationships to form higher-level objects, or entity clusters. Because entities may belong to several potential clusters, we need to have a set of priorities for forming entity clus- ters. The following set of rules, listed in priority order, defines the set that is most likely to preserve the clarity of the conceptual model: a. Entities to be grouped into an entity cluster should exist within the same functional area; that is, the entire entity clus- ter should occur within the boundary of a functional area. For example, in Figure 4.10, the relationship between Department and Employee should not be clustered unless Employee is included in the company organization functional area with Department and Division. In another example, the relation- ship between the supertype Employee and its subtypes could be clustered within the employee data functional area. b. If a conflict in choice between two or more potential entity clusters cannot be resolved (e.g., between two constraint groupings at the same level of precedence), leave these entity clusters ungrouped within their functional area. If that func- tional area remains cluttered with unresolved choices, define functional subareas in which to group unresolved entities, entity clusters, and their relationships. 3. Form higher-level entity clusters. Apply the grouping operations recursively to any combination of elementary entities and entity clusters to form new levels of entity clusters (higher-level objects). Resolve conflicts using the same set of priority rules given in step 2. Continue the grouping operations until all the entity represen- tations fit on a single page without undue complexity. The root entity cluster is then defined. 4. Validate the cluster diagram. Check for consistency of the interfaces (relationships) between objects at each level of the diagram. Ver- ify the meaning of each level with the end users. The result of one round of clustering is shown in Figure 4.11, where each of the clusters is shown at level 2. Teorey.book Page 80 Saturday, July 16, 2005 12:57 PM 4.6 Summary 81 4.6 Summary Conceptual data modeling, using either the ER or UML approach, is par- ticularly useful in the early steps of the database life cycle, which involve requirements analysis and logical design. These two steps are often done simultaneously, particularly when requirements are determined from interviews with end users and modeled in terms of data-to-data relation- Figure 4.11 Clustering results Division/ Department Cluster is- managed-by is- headed-by has d N N 111 11N Employee Department Division 2.1 Manager cluster 2.3 Secretary cluster 2.4 Engineer cluster 2.5 Technician skill-used assigned-to Project management cluster 2.2 N Project Project P 1 N Skill Location is- married-to manages 1 1 1 N + Teorey.book Page 81 Saturday, July 16, 2005 12:57 PM . Conceptual data modeling, using either the ER or UML approach, is par- ticularly useful in the early steps of the database life cycle, which involve requirements analysis and logical design. These. entities and relationships defined in the ER modeling process. This technique assumes that a top- down analysis has been performed as part of the database requirement analysis and that the analysis. the functional areas are allowed to overlap. Figure 4.10 uses an ER diagram resulting from the database requirement analysis to show how clustering involves a series of bottom-up steps using