DATA MODELING FUNDAMENTALS (P9) pps

CUSTOMER and BANK-ACCOUNT. The members of this relationship set are pairs con- sisting of single customer entity instances and single account entity instances. When you face a design issue such as this, you have to examine the nature of the attributes and make your decision as to whether to show just a relationship or to include another entity type. Figure 6-28 shows the two configurations. Ternary Relationship or Aggregation? When you run into three-way relationships, this design issue may confront you. At that time, you need to decide whether to introduce aggregation or stay with a ternary relationship. The information requirements of the real-world situation will dictate the choice. In many situations, ternary relationships will be adequate to represent the requirements in the data model. We have already looked at this issue partially when we covered aggregation earlier. Go back and look at Figure 6-22 and study why aggregation was introduced in that example. Mostly, the decision to choose between aggregation and ternary relationship rests on the presence of a relationship that relates to a relationship set or to an entity set or a second relationship set. Sometimes, the choice is further guided by the need to express relationship constraints. Binary or N-ary Relationship? In the earlier sections, you have seen examples of ternary and quaternary relationships. Relationships of higher degrees with more than four participating entity types may also FIGURE 6-28 Relationship versus entity type. 216 CHAPTER 6 RELATIONSHIPS IN DETAIL be present in a data model based on information requirements. Generally, you can break up higher degree (or N-ary, where N is any number greater than 4) relationships and replace them with a set of binary relationships. This is a design issue. Binary relationships can be simpler and easier to understand. When you walk through a data model with domain experts and user groups, you will find it less complicated to discuss and to confirm the requirements. When you have ternary or quaternary relationships, you will find it hard to explain the composition of relationship sets. With higher degree relationships, the difficulty increases even more. However, if you restrict your data model to contain only binary relationships, you may have to face other types of problems. As you break down a higher degree relatio nship, you will have to create additional entity sets, more binary relationshi p sets, and identifying attributes. This increase in data model components may add to the complexity. Other the other hand, if you leave the N-ary relationship in the data model, you may be able to show the participation of several entity types with different participation constraints. Therefore, whenever you are faced with higher degree relationships, consider the options carefully. First, you have to decide if you can leave the higher degree relationship intact in the data model. This may be the wise choice in some cases. If you have to replace the higher degree relationship with multiple binary relationships, clearly define the additional entity types, relationships, and extra identifying attributes. Figure 6-29 shows a quaternary relationship and its break-down into binary relationships. Study the figure carefully to understand the choices. Observe how the binary relationships represent the original quaternary relationship. One-to-One Relationships A one-to-one relationship associates one instance of the first entity type to one instance of the second entity type. Whenever you design a one-to-one relationship, you need to FIGURE 6-29 Quaternary into binary relationships. DESIGN ISSUES 217 consider a few questions about the relationship. Here the main issue is whether to preserve the relationship and keep the two entity types intact in the data model. The other choice is merging of the two entity types into a single entity type and including all the attributes of both entity types in the merged entity type. Let us work with a generic example. Some data modeling practitioners advocate the elimination of one-to-one relationships altogether. Most database systems support one-to-one relationships. It is up to you to make the choice depending on the particular situations. Let us examine the generic example and offer some suggestions. This example consists of two generic entity types A and B with a one-to-one relationship between them. Consider the possible cases in terms of participation constraints. Mandatory at Both Ends. Each instance of A associates with an instance of B. From the other side, each instance of B associates with an instance of A. When you look at an instance of A and the corresponding instance of B, the attributes of this association will be combination of the attributes of both A and B. Usually, this means that representation of the requirements as two separate entity types is unnecessary. Combine the two entity types into one with a meaningful entity name. The identifier of either of A or B can serve as the identifier for the merged entity type. The attributes of the merged entity type will consist of the complete set of attributes from both A and B. Optional at One End. In this case, two possibilities exist. The relationship at the A end is mandatory and it is optional at the B end. Or the converse may be true. In either case, the relationship is mandatory at one end and optional at the other end. As these are symmetri- cal, we can consider one possibility and apply the discussion to the other possibility. Let the relationship be optional at the A end and mandatory at the B end. This means not all instances of A participate in the relationship. For some instances of A there are no corresponding instances of B. This is the case where A could represent customers and B represent contact persons for the customers. Not all customers may have distinct contact persons. Assume that you want to merge the two entity types into one as you did in the previous case. Then, for many instances of the merged entity types, values of attributes of B will be null. If you have a much larger number of A occurrences compared with B occurrences, this is not a recommended option. You can leave the two entity types in your conceptual data model. So, consider your particular situation and make the decision on this design issue. Optional at Both Ends. This possibility refers to the case where not all instances of either A or B may participate in the relationship. If you take a particular instance of A, it may not be par t of the relationship. Again, considering a particular instance of B, it may not participate in the relationship. Let us say you want to merge the two entity types and eliminate the one-to-one relationship. What you will find is as follows: some merged entity instances will lack the attribute values of B and other merged entity instances will not have the attribute values of A. So, there will be many partial entity instances. In general, merging of entity types is not advisable in this case. You want to avoid many entity occurrences with the likely prospect of having a lot of null values for the attributes. 218 CHAPTER 6 RELATIONSHIPS IN DETAIL Ascertain the participation constraints and if you have optional conditions at both ends, choose to leave the relationship in the data model. One-to-Many Relationships Sometimes, participation constraints may lead to design issues in one-to-many relationships as well. Let us look at a specific example. In a product warehouse, some of the products need industry standard certification. Other products do not. The certification procedure designates the quality rating for the products that need certification. In order to represent this business requirement, you start designing entity types and relationships. You will come up with entity types CERTIFICATION and PRODUCT. Note these two will form a one-to-many relationship. What about the participation constraints? At either end, participation of entity instances is optional. We know that some products do not need certification; these product instances will not participate in the relationship. Similarly, there may some certification scores for which there are no products yet. When you are faced with this type of issue, carefully examine if the data model depicts the business rules correctly. Later on, when you transform your conceptual data model into a logical data model for implementation, you may run into problems for linking related entity instances. Figure 6-30 shows the one-to-many relationship and possible way of eliminating the optional condition on the CERTIFICATION side. You will note that products are separated out into certified products and others. Circular Structures Occasionally, you will run into what are known as circular structures or circular refer- ences. You will create three entity types A, B, and C; you will then find A as the parent of B, B as the parent of C, and C as the parent of A. Each relationship tends to be a one-to-many relationship. This is a cyclical set of relationships. FIGURE 6-30 Optional one-to-many relationship. DESIGN ISSUES 219 If the business requirements are not transmitted correctly, this is a likely result. Poss- ibly, parent–child relationships are reversed. Or a many-to-many relationship could have been mistaken as a one-to-many relationship. Nevertheless, circular structures cause problems and must be resolved. Let us work out a partial data model for a manufacturing company. Each of its production divisions supplies different product lines. Each product line gets sold in multiple territories. Each territory relates to one or more divisions. Create a data model with entity types DIVISION, PRODUCT-LINE, and TERRITORY. Establish the three one-to-many relationships. Figure 6-31 presents this circular structure. First, we want to reverse the cyclical progression of relationships. A better approach would be to introduce additional entity types and resolve the circular structure of parent–child relatio nships. Then we want to make each relationship amplified and clari- fied. Figure 6-32 illustrates a refinement of the circular structure. Note the additional entity types and new relationships introduced in the data model. FIGURE 6-31 Circular structure. FIGURE 6-32 Refinement of circular structure. 220 CHAPTER 6 RELATIONSHIPS IN DETAIL Redundant Relationships As you go through iterations in the data modeling process, you will come across redundant relationships. In your review, you will specifically look for such redundancies and eliminate them. When you show two dependency paths between the same two entity types, in effect, you create a triad involving a redundant relationship. Typically, you will see a set of three entity types tangled as a triad with a redundant relationship. Let us take an example. A supermarket has various departments such as paper goods, meat, dairy, and so on. Each of these departments offers product types. Products belong to product types. These entities form various relationships. Now consider the entity types DEPART- MENT, PRODUCT-TYPE, and PRODUCT. DEPARTMENT to PRODUCT-TYPE is a one-to-many relationship; PRODUCT-TYPE to PRODUCT is also a one-to-many relationship. You create the data model showing these relationships. Then you realize the departments and products are also associated in one-to-many relationship. So, you add another relationship line between DEPARTMENT and PRODUCT. This last relationship is redundant and you have created a triad. You have to resolve by eliminating the redundant relationship. Figure 6-33 illustrates the triad and its resolution. Note how the redundant relationship gets removed. Multiple Relationships At times, two entity types may be related to each other in multiple ways. Two or more types of associations are possible between entity instances. A manufacturing plant may serve both as a production unit as well as a storage area for products. In this case, two entity types BUILDING and PRODUCT may be used to represent the entities as well as two types of relationships between them. You probably want to represent the relationships with two relationships lines, one representing the “produces” relationship and one the “stores” relationships. FIGURE 6-33 Triad and its resolution. DESIGN ISSUES 221 When you have multiple relationships between the same two entity types, represented with multiple relationship lines, problematic consequences may follow. The cardinalities and participation constraints may be in conflict among the multiple relationships. Some- times, multiple relationships may tend to represent process logic. A data model should be devoid of process logic representation. Represen tation of multiple relationships may also result in the data model becoming confusing and vague. If you encounter situations with multiple relationships between the same two entity types, carefully scrutinize the cardinalities and participation constraints. If you trace any conflicts, resolve multiple relationships. If you note that process logic is being inter- jected into the data model, again look for ways of resolving multiple relationships. This is a significant design issue for relationships. Let us present an example of multiple relationships and the resolution. Figure 6-34 shows multiple relationships between circuit boards and professionals who design, main- tain, and fabricate them. Note the entity types PROFESSIONAL and BOARD and observe the three types of relationships between them. Also, study the resolution achieved by the introduction of two other entity types. RELATIONSHIP VALIDATION CHECKLIST Our detailed discussions of relationship are about to end. So far, in this chapter, we covered several topics. We revisited the concept of relationship as associations of individual entity occurrences. This led us to the concept of relationship sets. A relationship set consists of combinations of single entity instances taken one from each participating entity type. If relationships themselves have attributes, then the attribute values relate to members of the relationship sets. FIGURE 6-34 Multiple relationships and resolution. 222 CHAPTER 6 RELATIONSHIPS IN DETAIL We reviewed useful examples of binary, ternary, and quaternary relationships. The degree of a relationship determines how individual entity instances combine to make the relationship set. The significance of cardinality and optionality constraints on relationships cannot be overemphasized. Participation constraints play an important role in representing relationship properly in a data model. We brought the discussions to completion by considering special cases and important design issues. You looked at several types of situations where resolution of relationships becomes necessary. You have gone over examples of resolutions. As you go through the data modeling process, at each stage, you need to check the data model for completeness and correctness. Again, remember that data modeling is an iterative process. After defining the entity types and their attributes, defining of relationships follows. You may even begin representing relationships as soon as you have the first cut of the entity types. In the iterative process, you may refine the model by adding or mod- ifying previously included relationships. What follows is a task list for validation of relationships as represented in your data model. Two checklists are presented: one to verify completeness and the other to verify correctness of relationships. These checklists should come in handy to conduct the review process for relationships. Completeness Requirements Review. Go over the information requirements for each relationship shown in the data model. Ensure that no relationships are missing. Regroup entity types by pairs and make sure that no relationship between qualifying pairs is left undefined. Relationship Names. Review each verb or verb phrase that indicates a relationship either recording within the diamond symbol or written over the relationship line. Think of connotation of each verb phrase and ensure that all relationships are properly described. Relationship Descriptions. Provide clarifications for all relationships and descriptions of cardinality and participation constraints in the supplementary documentation. Cardinality Constraints. Go through every relationship. Be certain that the cardinality indicators are shown for each end of each relationship line. Optionality Constraints. Wherever business rules indicate participation constraints, make sure these constraints are represented in the data model. Identifying Relationships. Search for all weak entity types. Wherever you have noted weak entity types, ensure the presence of identifying relationships. Gerunds. Make certain that all gerunds are identified and represented in the data model. Aggregations. Review pairs of entity types to verify if any aggregations are necessary. If so, aggregate the qualifying entity types. RELATIONSHIP VALIDATION CHECKLIST 223 Correctness Relationship Representation. Ensure that each relationship represents the associations correctly. Relationship Verb Phrases. Make sure that all verbs or verb phrases used to specify relationships reflect the exact nature of the associations. Ensure that the verbs or verb phrases are not vague or ambiguous. Relationship Attributes. Wherever attributes are shown for relationships, make sure these attributes are truly attributes of the relationships and not of any of the participating entity types. Cardinality Constraints. Go over each maximum cardinality indicator or any other notation used to signify cardinality constraint. Make sure that these represent cardinalities correctly. Participation Constraints. Verify each minimum cardinality indicator or any other corresponding notation. Ensure each optional or mandatory condition accurately reflects the business rules. Gerunds. Validate each gerund and justify formation of the gerund. Aggregation. Review each aggregation to verify its correctness in terms of the grouping of entity types and relationships. Make sure the correct decision has been made to represent the aggregation instead of a ternary relationship. Access Pathways. Check access pathways to proceed from each entity instance and trace through associated entity instances in the related entity types, one after the other in sequence. Make sure that the pathways are unambiguous and present. If any pathway is ambiguous or missing, recast the entity types and relationships to resolve potential problems. Relationship Review. Review each relationship to ensure that it need not be replaced by an entity type. N-ary Relationships. Check each higher degree relationship to determine if these should be broken up into binary relationships. One-to-One Relationships. Verify each one-to-one relationship for participation constraints. If necessary, merge participating entity types into a single entity type. One-to-Many Relationships. Check each one-to-many relationships with optional participation at both ends of the relationships. If necessary, resolve problematic one-to-many relationships. Circular Structures. Look for circular structures. If found, resolve these. 224 CHAPTER 6 RELATIONSHIPS IN DETAIL Triads. Carefully examine the data model for triads. If found, remove the redundant relationships. Multiple Relationships. Scrutinize binary relationships. If you suspect multiple relationships between the participating entity types, resolve this design issue. CHAPTER SUMMARY . Relationships between two entity types are associations between specific instances of one entity type with particular occurrences of another entity type. . Every relationship has two sides to it with respective cardinalities. . A relationship between two entity types constitutes a set of associations between entities of the first entity type and entities of the second entity type. . A relationship itself may have attributes apart from the attributes of participating entity types. . The degree of a relationship in a data model refers to the number of entity types that participate in the relationship. . Three common types of cardinality constraints of relationships are one-to-one, one-to-many, and many-to-many. . Participation constraint refers to whether instances of one entity type need to participate in associations with instances of another entity type. Participation may be partial or total. . Identifying and nonidentifying relationships are two types of relationships. An identifying relationship is between a weak entity type and its corresponding strong entity type. . Minimum cardinality indicator denotes optional or mandatory nature of a relationship. . Aggregation is used to resolve the issue of expressing relationships of relationships. . Triads must be resolved. A triad consists of redundant relationships. REVIEW QUESTIONS 1. True or false: A. A relationship constitutes a set of associations between entities of two entity types. B. Quaternary relationships are the most common form of relationship in real- world situations. C. Cardinality constraint refers to the numbers of entities participating in a relationship. D. Total participation also means mandatory nature of the relationship. E. A weak entity type sometimes may have independent existence. F. Minimum cardinality indicator of “0” means mandatory relationship. REVIEW QUESTIONS 225 [...]... following logical data modeling consummate in designing the physical details and implementing the database Data Modeling Fundamentals By Paulraj Ponniah Copyright # 2007 John Wiley & Sons, Inc 229 230 CHAPTER 7 DATA MODELING TO DATABASE DESIGN FIGURE 7-1 Data models at different levels For us, the relational data model will be the logical model of choice As you know, the logical data model is to serve... 238 CHAPTER 7 DATA MODELING TO DATABASE DESIGN FIGURE 7-8 Relational tables Data Integrity Constraints It is essential that a database built on any specific data model must ensure validity of data The data structure must be meaningful and be truly representative of the information requirements Constraints are rules that make sure proper restrictions are imposed on the data values in a database The purpose... creating the conceptual data 244 CHAPTER 7 DATA MODELING TO DATABASE DESIGN FIGURE 7-12 Relational data model: design approaches model, you may use the E-R data modeling technique Some other modeling techniques would also produce conceptual data models Here are the general steps in this design approach: Gather the information requirements of the organization Create a conceptual data model to truly... relationship representation? Give an example and show how to refine a circular structure III DATA MODEL IMPLEMENTATION 227 7 DATA MODELING TO DATABASE DESIGN CHAPTER OBJECTIVES Make the transition from data modeling to database design Focus on the relational data model as the logical model of choice Study significant fundamentals of the relational model Examine the leading transition approaches Provide... properties that ensure data correctness and consistency in a relational data model First, let FIGURE 7-9 Relational data model: notation RELATIONAL MODEL: FUNDAMENTALS 239 us establish the reasons for ensuring data integrity A database is said to possess data integrity if the data values will provide a correct and valid representation of the characteristics of the entities or objects Data integrity includes... consider another method for creating a relational data model—a more traditional or informal method That method has elements of intuition, and trial and error We will do a quick review of the data normalization method In a way, this is relational data modeling from scratch The above figure shows physical data modeling as a final modeling step Physical data modeling comes very close to implementation Specific... without any room for exceptions The data model must consist of well-structured relations with minimum data redundancy Data manipulations in a relational database must not result in any data inconsistencies First, we will consider the basic relational properties that support data integrity and data consistency Next, we will address three special cases that further enhance data integrity Basic Relational... the data content of the eventual database Therefore, we studied the components of the conceptual data model in great detail However, we now need to proceed further on the path toward database design and implementation The next step in the process consists of creating a logical data model Naturally, the logical data model has to be derived from the conceptual data model The steps following logical data. .. data model for completeness Take each component of the conceptual data model at a time and examine it Transform each component of the conceptual data model into a corresponding component of the relational data model Pull together all the components of the relational data model resulting from the transformation from the conceptual data model Complete the relational data model Review the relational data. .. out in a disciplined manner 232 CHAPTER 7 DATA MODELING TO DATABASE DESIGN Simple and Familiar View The model provides a common and simple view of data in the form of two-dimensional tables Users can easily perceive how data is organized; they need not be concerned with how data is actually stored in the database Logical Links for Relationships Other data models such as hierarchical and network use . DETAIL III DATA MODEL IMPLEMENTATION 227 7 DATA MODELING TO DATABASE DESIGN CHAPTER OBJECTIVES . Make the transition from data modeling to database design . Focus on the relational data model. logical data model has to be derived from the conceptual data model. The steps following logical data modeling consummate in designing the physical details and implementing the database. 229 Data Modeling. method. In a way, this is relational data modeling from scratch. The above figure shows physical data modeling as a final modeling step. Physical data modeling comes very close to implementation.