DATA MODELING FUNDAMENTALS (P6) pdf

Relationship of each entity type with other entity types Just like homonyms, if synonyms are not resolved, the resulting data model will beimprecise and have redundancies.. A weak entity

terminology One department may refer to workers as employees whereas another ment may call them associates.

depart-Resolution of synonyms is harder than that of homonyms Homonyms may be trackedwith comparative ease because of similarly spelled names or similar sounding words But

FIGURE 4-7 Nonreconciled homonyms.

FIGURE 4-8 Homonyms embodied in one entity type.

in the case of synonyms, you will have to sift through hundreds of terms to detect them.During the initial iterations of the data modeling process, as soon as you suspect that twoentity types could be synonymous, put them through a thorough examination.

Determine the degree of similarity between two entity types by studying the following:

. Definition of the entity types

. Attributes of the two entity types (however, the attributes may themselves have ent names)

differ-. Identifier for each of the two entity types

. Relationship of each entity type with other entity types

Just like homonyms, if synonyms are not resolved, the resulting data model will beimprecise and have redundancies Data consistency and data integrity could also becompromised

Figure 4-9 presents a set of unsolved synonyms and also indicates how these synonymsare resolved

Category of Entity Types

In the rest of this chapter, we will explore the various categories of entity types in detail.Therefore, at this point, we just want to express that a data model will contain differentcategories of entity types All entity types shown in a data model represent a set ofsimilar business objects You know that a CUSTOMER entity type symbolizes the set

of all the individual customers of an organization An ORDER entity type represents

FIGURE 4-9 Resolution of synonyms.

ENTITY TYPES OR OBJECT SETS 127

the set of all the orders received by an organization Similarly, an ORDER-DETAIL entitytype denotes the set of all the line-item details of all the orders.

However, variation in categories of entity types arise based on a few differences in ditions and functions Some entity types are different because of existence conditions.Another entity type is different because of its special function in a certain type of relation-ship Some entity types may be derived from other general entity types Let us list themajor categories of entity types

con-Weak Entity Type This entity type represents a set of individual entities that cannotexist by themselves in a database A weak entity type needs another strong entity type

in the data model A weak entity type depends on the related strong entity type for its ence Without the presence of strong entities and the association with these entities, weakentities cannot stand on their own in the data system

exist-Here are a few examples:

Weak Entity Type Related Strong Entity Type

In addition to the strong entity types noted above, the following are a few moreexamples of regular entity types:

Strong or Regular Entity TypeSTUDENT

FACULTYCOURSETEXTBOOKEXAM-TYPE

Supertypes and Subtypes As you already know, you find this category of entitytypes in a data model because of generalization and specialization In the real world,business objects occur that are special cases of other types of business objects On theother hand, when you examine certain sets of business objects, you will discover thatthese can be separated out into subsets of similar business objects Such entity types arecategorized as subtypes and supertypes

Note the following examples of supertypes and the corresponding subtypes of entities:

Association or Intersection Entity Type If you have two entity types inmany-to-many relationship, in a conceptual data model diagram you can show thesetwo entity types and mark their relationship as many-to-many In a data model at the con-ceptual data model, expressing many-to-many relationships is perfectly standard.However, when you want to transform the conceptual data model into a logical modelfor relational databases, you run into a problem In a relational model, the two entitytypes transform into two relational tables But when you try to transform themany-to-many relationship using foreign keys, you have to address the question ofwhere to place the foreign key—in the first table, or the second table, or in both.The intersection entity type resolves this problem In order to transform amany-to-many relationship, you have to introduce a new entity type, called the intersec-tion entity type, into your data model You may do this in the conceptual data modelitself in preparation of its transformation into a relational model down the line Chapter

7 covers this topic in more detail At this point, take a look at Figure 4-10 showing anexample of intersection entity type

Aggregation Entity Type Consider three entity types: WAREHOUSE, METHOD, and ORDER When you want to identity a particular shipment and describe

SHIP-it, you need to include warehouse, shipping method, and order data A shipment of aspecific order takes place from a particular warehouse and using a certain shippingmethod Therefore, we need an entity type SHIPMENT to indicate the three-way relation-ship among WAREHOUSE, SHIP-METHOD, and ORDER The identifier for this new

FIGURE 4-10 Intersection entity type.

ENTITY TYPES OR OBJECT SETS 129

entity type SHIPMENT has to be the aggregation of the identifiers of the three related ties Aggregation entity type denotes three-way, four-way, and sometimes, higher degreerelationships.

enti-Figure 4-11 illustrates the formation of an aggregation entity type for the above way relationship:

three-EXPLORING DEPENDENCIES

Earlier in this chapter we reviewed methods for identifying entity types As soon as youidentify an entity type, you need to recognize which category the entity type wouldbelong to Depending on the category, your representation of that entity type will varyfrom others By taking into account the category and proper representation of the entitytype, you are paving the way for correct implementation of that entity type in the finaldatabase Proper representation enables you to impose the right constraints in theimplemented database

One aspect of such scrutiny relates to exploring dependencies What do we mean bythat? Let us say that you have identified an entity type called ORDER Examine the indi-vidual entities being represented by this entity type These individual entities or businessobjects are single orders Now, ask the question Does the existence of a single orderdepend on the existence of entities of another entity type in the database? Does the exist-ence of an order number 1234 depend on the existence of the corresponding customernumber 2244 in the database? If you delete customer number 2244 from the database,does that mean that you have to delete order number 1234 also from the database to pre-serve data integrity? The answers to these questions determine the dependency of ORDERentity type on CUSTOMER entity type This is the process of exploring dependencies ofentity types

FIGURE 4-11 Aggregation entity type.

Let us say you determine that ORDER entity type is dependent on CUSTOMER entitytype Your representation of these two entity types and their relationship will be differentfrom how you will show other entity types and relationships Differentiation in this respectachieves two purposes Your data model will reflect the information requirements truly;proper constraints will be imposed on the implemented database.

Dependent or Weak Entity Types

Let us pursue the example of CUSTOMER and ORDER entity types Let us suppose thatwhen you gather the information requirements, you find out more details about customersand orders You determine how orders are received and how they are recorded You notewhat is allowed to happen when orders are received from new customers

Two cases are possible In both cases, ORDER entity type is dependent of CUSTOMERentity type for its existence

Some Independent Orders In this case, independent orders are allowed to exist in thedatabase even if it is for a short while If an order is received from a new customer beforethe customer data is recorded in the database, the order processing department wants torecord the order in the database and get a head-start on the fulfillment of the order.Later on, when the customer data is recorded in the database, the connection betweenorder and customer will be made

How do you distinguish this condition in the data model? You will make the distinction

by means of a minimum cardinality indicator on the relationship between the two entitytypes Still the data model will show ORDER as a weak entity type depending on the cor-responding strong entity type CUSTOMER If a customer occurrence gets deleted from thedatabase, all of the pertinent order occurrences must be deleted from the database.Every Order Dependent On the other hand, the organization does not permit anyorders to be recorded in the database before the relevant customer data is recorded Evenfor a new customer, first the customer data must be recorded and then the order must berecorded The order processing department must ensure this sequence of data entry

In this case, the data model will simply show ORDER as a weak entity type depending

on the corresponding strong entity type CUSTOMER There is no need to distinguish therelationship further with minimum cardinality indicators

Figure 4-12 illustrates these two cases of weak entity types

FIGURE 4-12 Dependence and partial independence.

EXPLORING DEPENDENCIES 131

Weak entities may be classified into two groups based on how exactly they depend ontheir corresponding strong entities If ORDER is dependent on CUSTOMER, what exactly

is the nature of the dependency? Examining a number of weak entities and their cies, we can establish that we can put weak entities into two classifications Let us discussthese groupings

dependen-ID Dependency Entities in some weak entity type cannot be uniquely identified bytheir own attributes The entities in such entity types will have to be identified bymeans of their association with entities in the corresponding strong entity types Let ustake a few examples

Suppose we have a weak entity type ORDER-LINE Each entity in this entity type resents a line-item of the corresponding order The line-items will contain product, quan-tity, and price data The line-items on every order will usually be numbered sequentiallybeginning with “01” and proceeding with higher numbers depending on how many line-items there are on the order The entities in every ORDER-LINE entity type will havethe same sequence numbers None of the attributes—line item number, product, quantity,

rep-or price—can be used as an identifier frep-or ORDER-LINE entity type What is the solution?Each entity in ORDER-LINE weak entity type can be uniquely identified only throughits association with the relevant entity in the corresponding ORDER strong entity type Ifyou want to identify and locate the third line-item on order number 123456, then you canuse the concatenation of “123456” and “03” for purposes of identification Thus, the enti-ties in ORDER-LINE depend on the entities in ORDER for identification This is ID(identification) dependency The dependency of weak entity type ORDER-LINE onstrong entity type ORDER is an ID dependency

Let us consider another example Here, the weak entity type is CHILDREN depending

on strong entity type of EMPLOYEE The relationship is established to associate childrenwith their parents for insurance coverage The attributes of CHILDREN are name of child,age, type of insurance, and, perhaps, a generic sequence number similar to the one used fororder line-items None of the attributes of CHILDREN is of any use as a unique identifier.CHILDREN entity type has to depend on entity type EMPLOYEE for identification This

is also a case of ID dependency

Because the strong entity type identifies the corresponding weak entity type, the strongentity type is also known as an identifying entity type The relationship between the strongentity type and the weak entity type is called an identifying relationship

Existence Dependency Let us revisit the above two examples We determined thatthe dependency of ORDER-LINE on ORDER is an ID dependency Similarly,CHILDREN depends on EMPLOYEE for identification The weak entity types need

their corresponding strong entities for identification But ID dependency also impliesexistence dependency.

Entities in ORDER-LINE cannot exist in the database without their relevant entities inORDER The existence of entities in ORDER-LINE depends on the existence of corre-sponding entities in ORDER If certain orders get deleted from the database, their corre-sponding line-items must also be deleted The line-items cannot exist in the database ontheir own The dependency is not only ID dependency, it is also existence dependency.Similarly, the dependency of CHILDREN on EMPLOYEE is both ID dependency andexistence dependency Entities of CHILDREN cannot exist in the database without theexistence of their corresponding entities in EMPLOYEE If an employee is deletedfrom the database, all the corresponding children must also be removed from the database.Although ID dependency implies existence dependency, the converse need not be true.Consider a data model where two entity types are represented One entity type is CUSTO-MER and the other is CREDIT-CARD This model needs to show credit card informationfor each customer In the database, we need to record credit card data for each customer Acustomer may have more than one credit card Examine these two entity types Entities inCREDIT-CARD cannot exist unless their corresponding entities in CUSTOMER alsoexist So, this is existence dependency However, examine the attributes of CREDIT-CARD: CardNo, CardType, ExpirationDate, and IssuedBy In this case, clearly CardNocan uniquely identify entities in CREDIT-CARD These entities do not have to depend

on the corresponding entities in CUSTOMER for identification Thus, this not IDdependency

Representation in the Model

Let us illustrate the dependencies by showing how they are indicated in data model grams Carefully note the following figures Observe the strong and weak entities and

dia-FIGURE 4-13 ID dependency.

EXPLORING DEPENDENCIES 133

the relationship lines with arrowheads Notice the double boxes symbolizing weak entitytypes Also, in the case of ID dependencies, make a note of the discriminator attributes inthe weak entity types These are just partial identifiers By themselves, they cannotuniquely identify occurrences of weak entities Identification is possible only when the dis-criminators are combined with the identifiers of the strong entity type.

ID Dependency Figure 4-13 shows two examples of ID dependency Note the letter “I”

on the relationship line indicating ID dependency

Existence Dependency Figure 4-14 shows two examples of existence dependency.Note the letter “E” on the relationship line indicating existence dependency

GENERALIZATION AND SPECIALIZATION

A true data model must reflect every aspect of real-world information If there arepeculiarities about certain business objects, then the model must represent those specialconditions If some relationships are different from the regular ones, then the datamodel must portray those special relationships A realistic data model should displayeverything about the set of real-world information requirements Frequently, you willfind that some of the attributes and relationships are the same for more than one object.Generalization and specialization of object sets is a common occurrence when youobserve business objects in the real world

Take the case of modeling the real-world information for a medical center One of themain business objects to be modeled is the PATIENT entity type Think about coming up

FIGURE 4-14 Existence dependency.

with a model for this entity type Modeling any object requires considerations of thepossible and relevant attributes for the object Also, you must consider the relationshipsthat instances of this object have with instances of other objects As you proceed tomodel the entity type PATIENT, you realize that there are inpatients, outpatients, andemergency room patients Your model must include all these patient categories Nowexamine these patient categories for attributes You notice that all these three categories

of patients have common attributes such as PatientID, PatientName, Address, Diagnosis,and so on But, you also realize that each category of patients has attributes that are notcommon to the other two categories of patients For example, inpatients have attributessuch as AdmissionDate, DischargeDate, LengthOfStay, TypeOfMeals, and so on, that arenot shared by outpatients and E-R patients Further, inpatients are related to anotherentity type in the model, namely, ROOM Inpatients may be transferred from oneroom to another

You see that there is something special about the three categories of patients in the waythey share their attributes and in the manner in which some attributes are specific to eachcategory Clearly, all patients in the medical center cannot be modeled with one entity typePATIENT Then what are the options? You can opt to model the patients with three sep-arate entity types INPATIENT, OUTPATIENT, and ERPATIENT If you make thischoice, then your model will repeat several attributes and perhaps relationships for each

of the three entity types

Step back and look at the four entity types PATIENT, INPATIENT, OUTPATIENT,and ERPATIENT It appears as though an entity type PATIENT is a supertype objectand that the other three are subtypes whose attributes and relations may be derivedfrom the supertype object You will find it best to use these four objects in your datamodel to truly represent the real-world information in the case of the medical center.Figure 4-15 explains the need for this method of representation in the model

What you have noticed is the concept of generalization and specialization in a datamodel This concept enables special types of objects to be represented in a data model

As you examine the information requirements of any business, you will observe thesetypes of objects

FIGURE 4-15 PATIENT object: supertype and subtypes.

GENERALIZATION AND SPECIALIZATION 135

The initial version of the E-R modeling technique lacked provision for generalizationand specialization However, later versions called enhanced entity relationship (EE-R)techniques included these concepts and presented symbols for the representations.

Why Generalize or Specialize?

Generalization structures enable the data modeler to partition an entity type into subsets.Each subset is a part of the whole For example, trucks, cars, ships, and airplanes may beconsidered as subtypes of the supertype called vehicle This modeling structure preservescohesiveness in a model

Attributes: Common and Variable Sharing of attributes results in a supertype andsubtype representation Each subtype may share most of its attributes with all the othersubtypes These shared attributes may then be grouped together as the attributes of thesupertype Further, certain attributes of each subtype may be different Variation in attri-butes necessitates representation of multiple subtypes in a model

Variations in attributes produce subtypes In the case of trucks, cars, ships, and planes, each of these have specific attributes to make them distinct Because of these vari-able attributes, you have to show these four distinct subtypes in your model

air-At the same time, these four entity types have a number of common attributes They allrepresent objects that are used in transportation The common attributes can, therefore, beincluded in the supertype entity type as a generalized entity type Generalization structuresenable the data modeler to partition an entity type into subsets

Relationships: Common and Variable Similar to sharing of attributes, sharing ofrelationships results in a supertype and subtype representation Most of the relationshipswith other entity types may be shared among all the subtypes These shared relationshipsmay then be regarded as the relationships of the supertype with the other entity types.Again, some of the relationships of each subtype may be different Variation in relation-ships makes it necessary to represent multiple subtypes in a model

For example, all subtypes INPATIENT, OUTPATIENT, and ERPATIENT may have arelationship with another entity type called SERVICE Thus, this relationship may be gen-eralized as a relationship between SERVICE and the supertype PATIENT But, on theother hand, only inpatients have associations with an entity type called ROOM So, youneed to represent this variation by separating out inpatients into a distinct subtypeINPATIENT

Effect of Generalization/Specialization When attributes and relationships areshared among entity types, if you represent the shared concepts with several entitytypes, you will be unnecessarily introducing duplicate descriptions in your data model.Generalization avoids such duplication You will be representing significant semanticcontent in a concise form

Generalization hierarchies improve the stability of the data model by allowing changes

to be made only to those entity types germane to the changes They simplify the model byreducing the number of entity types, attributes, and relationships Generalization andspecialization make the data model more readable

When to be Used Generalization and specialization should be used when

. A large number of entity types appear to be of the same type

. Attributes are repeated for multiple entity types

. Relationships with other entity types are repeated for multiple entity types

. The model is continually evolving

Supertypes and Subtypes

We looked at the example of car being a subset of the superset known as vehicle Whenyou come to think of this, is car an instance of the set vehicle or is it a subset of vehicle?How do you make the determination? You have to examine the natural use of the set ofcars Is this a distinct set within the set of vehicles? Or is car considered as just anothervehicle?

Defining criteria indicating whether one set is a subset of another superset:

. How the domain experts or users define the set

. The similarities and differences in the definitions

. What the users think about the member of the set

. The number of members in the set

. Inferences from sample data

In practice, how do you notice these special entity types while modeling the mation requirements? You may adopt the top-down or the bottom-up approach Youmay look at several entity types and realize that these may be subtypes of some supertypeentity Conversely, you may examine an entity type and determine that it would breakdown into subtypes

infor-Let us explore these two approaches

Generalization Generalization proceeds from the recognition of common features ofattributes and relationships of individual entity types It is a bottom-up approach whereyou minimize differences among similar entity types You suppress the differences toarrive at the common features and name an entity type with these common features.Create boxes in the data model to represent every possible category of business objects.Examine the objects and determine if some of these may be subtypes of some otherbusiness object Suppress the differences between the subtypes, identify the common attri-butes and relationships Generalize to define the supertype

Figure 4-16 illustrates the generalization approach for medical center patients

Specialization Specialization results from emphasizing differences among attributesand relationships among similar objects It is a top-down approach where you recognizedifferences among similar entity types You magnify relevant differences to arrive at aset of distinct entity types and define these as the subtypes of the original entity typethat gets represented as the supertype

Create boxes in the data model for only the high-level business objects That is, ignoreany possible variations in the set of attributes for instances within each high-level object

GENERALIZATION AND SPECIALIZATION 137

In the case of a medical center, first you will come up with the PATIENT entity type Thenexamine the instances within the object and note the differences in the sets of attributes forthe instances Separate out the instances that possess the same set of attributes as a specialsubtype for the supertype PATIENT.

Figure 4-17 illustrates the specialization approach for medical center patients

Generalization Hierarchy

Refer back to Figure 4-17 showing the subtypes and the supertype representing patients in

a medical center As certain attributes for a subtype are derived from the supertype, thesupertype and its subtypes form a hierarchy in the arrangement of these entity types in

a data model The hierarchical, top-down arrangement with the supertype box above thesubtype boxes gives indication of how the supertype provides the common attributes tothe subtypes in real-world situations

That figure shows two levels of the hierarchy, PATIENT at the higher level and theother three subtypes one level down Sometimes, you will come across more than twolevels in the generalization/specialization hierarchy Figure 4-18 shows three levels inthe hierarchy for POLICY and shows levels of subtypes for insurance policies

What about the instances in the supertype and each of the subtypes? The set of instanceswithin the supertype is a collection of all the instances in the lower level subtypes If aparticular instance is present in subtype AUTOPOLICY, then that instance also exists

in the supertype POLICY Cardinality indicator “1,1” between the supertype and eachsubtype will be shown to signify this

There is no theoretical limit to the number of levels in a generalization hierarchy.However, more than three or four levels are comparatively rare in practice More levels

FIGURE 4-16 Patient: generalization approach.

FIGURE 4-17 Patient: specialization approach.

FIGURE 4-18 POLICY: generalization /specialization hierarchy levels.

GENERALIZATION AND SPECIALIZATION 139

become cumbersome and unwieldy representations in a data model defeating the wholepurpose of the structure itself.

Inheritance of Attributes

A significant feature of a supertype and its subtypes is the inheritance of the attributes byeach subtype from the supertype These are the attributes that are common to all the sub-types In the case of the objects for a medical center as discussed earlier, all the subsetsshare common attributes such as PatientID, PatientName, Address, and Diagnosis.Because the subtypes share these attributes, there is no point in repeating these as attributes

of each of the subtypes In a data model diagram, you may, therefore, show these as butes of the supertype The principle of inheritance of attributes by the subtypes from thesupertype implies that each of the subtypes has these attributes In addition, each subtypemay have other attributes specific only to that subtype

attri-Figure 4-19 illustrates the principle of inheritance of attributes by the subsets Note thecommon attributes shown at the supertype level Also, observe the attributes specific toindividual subtypes

Inheritance of Relationships

Let us take an example of a company leasing vehicles to customers A lease agreementcovers a particular leasing arrangement with a customer Examining the informationrequirements, you can come up with two initial entity types, namely, VEHICLE andAGREEMENT Of course, there would be other entity types But let us consider thesetwo entity types for now Over a period of time, the same vehicle would relate to differentlease agreements That is, when a vehicle comes out of one lease agreement, it would be

FIGURE 4-19 Subtypes: inheritance of attributes.