DATA MODELING FUNDAMENTALS (P9) pps

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-2

CUSTOMER and BANK-ACCOUNT The members of this relationship set are pairs sisting of single customer entity instances and single account entity instances.

con-When you face a design issue such as this, you have to examine the nature of the butes and make your decision as to whether to show just a relationship or to includeanother entity type Figure 6-28 shows the two configurations

attri-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 Theinformation requirements of the real-world situation will dictate the choice In many situ-ations, 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 Goback 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 thepresence of a relationship that relates to a relationship set or to an entity set or a secondrelationship set Sometimes, the choice is further guided by the need to express relation-ship constraints

Binary orN-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.

be present in a data model based on information requirements Generally, you can break uphigher degree (or N-ary, where N is any number greater than 4) relationships and replacethem with a set of binary relationships This is a design issue.

Binary relationships can be simpler and easier to understand When you walk through adata model with domain experts and user groups, you will find it less complicated todiscuss and to confirm the requirements When you have ternary or quaternary relation-ships, you will find it hard to explain the composition of relationship sets With higherdegree relationships, the difficulty increases even more

However, if you restrict your data model to contain only binary relationships, you mayhave to face other types of problems As you break down a higher degree relationship, youwill have to create additional entity sets, more binary relationship sets, and identifyingattributes This increase in data model components may add to the complexity Otherthe 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 theoptions carefully First, you have to decide if you can leave the higher degree relationshipintact in the data model This may be the wise choice in some cases If you have to replacethe higher degree relationship with multiple binary relationships, clearly define theadditional entity types, relationships, and extra identifying attributes

Figure 6-29 shows a quaternary relationship and its break-down into binary ships Study the figure carefully to understand the choices Observe how the binaryrelationships represent the original quaternary relationship

consider a few questions about the relationship Here the main issue is whether to preservethe relationship and keep the two entity types intact in the data model The other choice ismerging of the two entity types into a single entity type and including all the attributes ofboth entity types in the merged entity type.

Let us work with a generic example Some data modeling practitioners advocate theelimination of one-to-one relationships altogether Most database systems supportone-to-one relationships It is up to you to make the choice depending on the particularsituations Let us examine the generic example and offer some suggestions Thisexample consists of two generic entity types A and B with a one-to-one relationshipbetween them Consider the possible cases in terms of participation constraints

Mandatory at Both Ends Each instance of A associates with an instance of B Fromthe other side, each instance of B associates with an instance of A When you look at aninstance of A and the corresponding instance of B, the attributes of this association will becombination 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 Theidentifier of either of A or B can serve as the identifier for the merged entity type The attri-butes 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, therelationship 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 meansnot all instances of A participate in the relationship For some instances of A there are nocorresponding instances of B This is the case where A could represent customers and Brepresent contact persons for the customers Not all customers may have distinct contactpersons

Assume that you want to merge the two entity types into one as you did in the previouscase Then, for many instances of the merged entity types, values of attributes of B will benull 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 conceptualdata model So, consider your particular situation and make the decision on thisdesign issue

Optional at Both Ends This possibility refers to the case where not all instances ofeither A or B may participate in the relationship If you take a particular instance of A,

it may not be part of the relationship Again, considering a particular instance of B, itmay not participate in the relationship

Let us say you want to merge the two entity types and eliminate the one-to-one ship What you will find is as follows: some merged entity instances will lack the attributevalues of B and other merged entity instances will not have the attribute values of A So,there will be many partial entity instances

relation-In general, merging of entity types is not advisable in this case You want to avoid manyentity occurrences with the likely prospect of having a lot of null values for the attributes

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 ships as well Let us look at a specific example In a product warehouse, some of the pro-ducts need industry standard certification Other products do not The certificationprocedure designates the quality rating for the products that need certification In order

relation-to represent this business requirement, you start designing entity types and relationships.You will come up with entity types CERTIFICATION and PRODUCT Note these twowill form a one-to-many relationship What about the participation constraints? At eitherend, participation of entity instances is optional We know that some products do not needcertification; 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 depictsthe 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 relatedentity instances Figure 6-30 shows the one-to-many relationship and possible way ofeliminating the optional condition on the CERTIFICATION side You will note thatproducts are separated out into certified products and others

If the business requirements are not transmitted correctly, this is a likely result ibly, parent–child relationships are reversed Or a many-to-many relationship couldhave been mistaken as a one-to-many relationship Nevertheless, circular structurescause problems and must be resolved.

Poss-Let us work out a partial data model for a manufacturing company Each of its duction divisions supplies different product lines Each product line gets sold in multipleterritories Each territory relates to one or more divisions Create a data model with entitytypes DIVISION, PRODUCT-LINE, and TERRITORY Establish the three one-to-manyrelationships Figure 6-31 presents this circular structure

pro-First, we want to reverse the cyclical progression of relationships A better approachwould be to introduce additional entity types and resolve the circular structure ofparent–child relationships Then we want to make each relationship amplified and clari-fied Figure 6-32 illustrates a refinement of the circular structure Note the additionalentity types and new relationships introduced in the data model

FIGURE 6-31 Circular structure.

FIGURE 6-32 Refinement of circular structure.

Redundant Relationships

As you go through iterations in the data modeling process, you will come across redundantrelationships In your review, you will specifically look for such redundancies and elim-inate 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 aset 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 producttypes These entities form various relationships Now consider the entity types DEPART-MENT, PRODUCT-TYPE, and PRODUCT DEPARTMENT to PRODUCT-TYPE is aone-to-many relationship; PRODUCT-TYPE to PRODUCT is also a one-to-many relation-ship You create the data model showing these relationships Then you realize the departmentsand products are also associated in one-to-many relationship So, you add another relationshipline between DEPARTMENT and PRODUCT This last relationship is redundant and youhave 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 relationshipgets removed

Multiple Relationships

At times, two entity types may be related to each other in multiple ways Two or moretypes of associations are possible between entity instances A manufacturing plant mayserve both as a production unit as well as a storage area for products In this case, twoentity 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 ships with two relationships lines, one representing the “produces” relationship and onethe “stores” relationships

relation-FIGURE 6-33 Triad and its resolution.

DESIGN ISSUES 221

When you have multiple relationships between the same two entity types, representedwith multiple relationship lines, problematic consequences may follow The cardinalitiesand 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 Representation of multiple relationships mayalso result in the data model becoming confusing and vague

If you encounter situations with multiple relationships between the same two entitytypes, carefully scrutinize the cardinalities and participation constraints If you traceany 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-34shows multiple relationships between circuit boards and professionals who design, main-tain, and fabricate them Note the entity types PROFESSIONAL and BOARD and observethe three types of relationships between them Also, study the resolution achieved by theintroduction of two other entity types

RELATIONSHIP VALIDATION CHECKLIST

Our detailed discussions of relationship are about to end So far, in this chapter, wecovered several topics We revisited the concept of relationship as associations of individ-ual entity occurrences This led us to the concept of relationship sets A relationship setconsists of combinations of single entity instances taken one from each participatingentity type If relationships themselves have attributes, then the attribute values relate tomembers of the relationship sets

FIGURE 6-34 Multiple relationships and resolution.

We reviewed useful examples of binary, ternary, and quaternary relationships Thedegree of a relationship determines how individual entity instances combine to makethe relationship set The significance of cardinality and optionality constraints on relation-ships cannot be overemphasized Participation constraints play an important role in repre-senting relationship properly in a data model.

We brought the discussions to completion by considering special cases and importantdesign issues You looked at several types of situations where resolution of relationshipsbecomes necessary You have gone over examples of resolutions

As you go through the data modeling process, at each stage, you need to check the datamodel for completeness and correctness Again, remember that data modeling is an itera-tive process After defining the entity types and their attributes, defining of relationshipsfollows You may even begin representing relationships as soon as you have the firstcut 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 datamodel Two checklists are presented: one to verify completeness and the other to verifycorrectness of relationships These checklists should come in handy to conduct thereview process for relationships

Completeness

Requirements Review Go over the information requirements for each relationshipshown 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 relationshipeither 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 tions of cardinality and participation constraints in the supplementary documentation

descrip-Cardinality Constraints Go through every relationship Be certain that the cardinalityindicators 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 notedweak 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

Relationship Attributes Wherever attributes are shown for relationships, make surethese attributes are truly attributes of the relationships and not of any of the participatingentity types.

Cardinality Constraints Go over each maximum cardinality indicator or any othernotation used to signify cardinality constraint Make sure that these represent cardinalitiescorrectly

Participation Constraints Verify each minimum cardinality indicator or any othercorresponding notation Ensure each optional or mandatory condition accurately reflectsthe 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 resent the aggregation instead of a ternary relationship

rep-Access Pathways Check access pathways to proceed from each entity instance andtrace 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 potentialproblems

Relationship Review Review each relationship to ensure that it need not be replaced

Circular Structures Look for circular structures If found, resolve these

Triads Carefully examine the data model for triads If found, remove the redundantrelationships.

Multiple Relationships Scrutinize binary relationships If you suspect multiplerelationships between the participating entity types, resolve this design issue

CHAPTER SUMMARY

. Relationships between two entity types are associations between specific instances ofone 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 betweenentities of the first entity type and entities of the second entity type

. A relationship itself may have attributes apart from the attributes of participatingentity types

. The degree of a relationship in a data model refers to the number of entity types thatparticipate 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 pate in associations with instances of another entity type Participation may be partial

partici-or total

. Identifying and nonidentifying relationships are two types of relationships An tifying relationship is between a weak entity type and its corresponding strong entitytype

iden-. Minimum cardinality indicator denotes optional or mandatory nature of arelationship

. Aggregation is used to resolve the issue of expressing relationships of relationships

. Triads must be resolved A triad consists of redundant relationships

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

G Merging of entity types in a one-to-one relationship is not advisable when therelationship is optional at both ends.

H Only some relationships have two sides

I In a ternary relationship, the relationship entity set consists of triplets

J Ambiguous access pathways can usually be resolved by recasting therelationships

2 A relationship is two-sided Explain this statement with an example

3 Show with an example how a relationship itself can have attributes

4 What is a ternary relationship? Give an example

5 Give two examples of many-to-many relationships Describe the associations ofentities in each example

6 What is partial participation in a relationship? Explain with an example

7 Give an example with optional conditions at both ends of the relationship Describethe associations of entities

8 What is a gerund in terms of relationships? How do you identify a gerund? Provide

DATA MODEL IMPLEMENTATION

227

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 in-depth coverage of the model transformation method

Walk through transformation of each model component

In an earlier chapter, we reviewed the different information levels that exist in anorganization You need to model the information requirements of the organization atthese levels to satisfy different purposes We looked at data models at the different infor-mation levels We started with an introduction to the conceptual data model This is at thehighest level of abstraction A conceptual data model serves as a communication tool toconverse about and confirm information requirements with domain experts

Elaborate coverage of the conceptual data model spread over the previous chapters.This data model provides the initial expression and representation of the data content ofthe eventual database Therefore, we studied the components of the conceptual datamodel in great detail However, we now need to proceed further on the path toward data-base design and implementation The next step in the process consists of creating a logicaldata model Naturally, the logical data model has to be derived from the conceptual datamodel The steps following logical data modeling consummate in designing the physicaldetails and implementing the database

229 Data Modeling Fundamentals By Paulraj Ponniah

Copyright # 2007 John Wiley & Sons, Inc.

For us, the relational data model will be the logical model of choice As you know, thelogical data model is to serve as a blueprint for database construction We have selectedthe relational model because this has proved to be superior to other models such as hier-archical and network models Relational databases are the most popular ones, and thesework based on the relational data model.

Figure 7-1 shows the data models at different levels Note how the figure illustrates thetransition from one level to the next

Before we deal with the transition of a conceptual to a relational data model, we need tocover the fundamentals of the relational model in sufficient detail We have to study thevarious components of that model so that you may appreciate the transition steps Afterthe comprehensive coverage of the fundamentals, we will move into the mapping andtransformation of model components from conceptual to logical This method is themodel transformation method

We will also consider another method for creating a relational data model—a moretraditional or informal method That method has elements of intuition, and trial anderror We will do a quick review of the data normalization method In a way, this is rela-tional data modeling from scratch

The above figure shows physical data modeling as a final modeling step Physical datamodeling comes very close to implementation Specific target DBMS and hardware con-figurations directly influence physical design Considerations of specific commercialDBMSs or hardware components do not fall within the scope of our discussions in thisbook Therefore, we will exclude physical data modeling from our scope You mayconsult the several good books available on database design and implementation tolearn about that topic

FIGURE 7-1 Data models at different levels.