DATA MODELING FUNDAMENTALS (P8) doc

You may also study the associations by choosingone employee entity and ﬁnd the project entities associated with that employee entity.. A relationshipbetween two entity types constitutes

Trang 1

entity type Take a little time to grasp the signiﬁcance of the meaning and role of ships symbolized in data model diagrams The connection shown between two entity typeboxes simply indicates that the instances are related with one another The name of therelationship as written within the diamond applies to each link between instances.

relation-Relationship: Two-Sided

Consider a relationship between two entity types PROJECT and EMPLOYEE Thisrelationship represents associations between project entities and employee entities Youmay select one project entity and look for the employee entities associated with thatproject entity Here you proceed to review the relationship from one side of the relation-ship, namely, the PROJECT entity type You may also study the associations by choosingone employee entity and ﬁnd the project entities associated with that employee entity This

is the other side of the relationship

Every relationship has two sides to it Figure 6-3 illustrates the two-sided nature of therelationship between PROJECT and EMPLOYEE

Relationship from PROJECT Let us review the relationship from the PROJECT side.Note the association lines connecting individual instances of the two entity types Fromthis side of the relationship, each project consists of certain employees

Take speciﬁc examples Look at one project instance that has the ProjectName

“Design.” Trace the association lines These lines connect the “Design” project withemployee instances of “Mary Brown,” “Samuel Raymo,” and “Tabitha Daniels.” Thatmeans the design project consists of three employees Mary Brown, Samuel Raymo, and

FIGURE 6-3 Relationship: two-sided.

186 CHAPTER 6 RELATIONSHIPS IN DETAIL

Trang 2

Tabitha Daniels Tracing the relationship from PROJECT helps ﬁnd employees working

on particular projects

Later on, when the data model gets implemented, searches for employees working on aspeciﬁc project will make use of the relationship from this side Also, when you examinethe relationship from this side, you understand the cardinality of how many employeesmay be associated with one project

Relationship from EMPLOYEE Now look at the relationship from the other side,namely, from EMPLOYEE Note the association lines connecting individual instances

of EMPLOYEE and PROJECT For this side of the relationship, each employee isassigned to a certain project

Let us check speciﬁc instances Look at the employee instance Robert Solomon Tracethe association line This line connects the instance to the project instance “Programming.”There are no other association lines from the employee instance Robert Solomon Whatdoes this mean? It conveys the information that the employee is assigned to oneproject This is different from looking at the relationship from the other side

We therefore note that the relationship is a one-to-many relationship as seen from thePROJECT side One project may have one or many employees On the other hand, oneemployee is assigned to only one project

Relationship Sets

When we consider an entity type, we refer to the set of entities of the same type Forexample, the EMPLOYEE entity type refers to a set of employees This is a set of instanceswith similar attributes The notion of a set may be extended to relationships as well.Take an example of the relationship between entity types EMPLOYEE and DEPART-MENT Find the associations between employee entities and department entities Concen-trate on one association such as Jerry Stone working in Sales Department This association

is one instance of several such associations between employee instances and departmentinstances Figure 6-4 shows the relationship between the two entity types and the associ-ations among the individual instances

Let us list the associations shown in the ﬁgure: (Sales—Jerry Stone), (Sales—MarthaJohnson), (Finance—Rudy Brunner), (Finance—Ashlee Thomas), and so on

What are these associations? These associations form a set of pairs What does this set

of associations indicate? The relationship between the entity types DEPARTMENT andEMPLOYEE may be reckoned as a set of the associations noted above A relationshipbetween two entity types constitutes a set of associations between entities of the ﬁrstentity type and entities of the second entity type

Double Relationships

In the relationships considered so far, the entities of one entity type are associated withentities of the other entity type in only one way For example, in the relationshipbetween EMPLOYEE and DEPARTMENT, the relationship indicates employeesworking in departments or, looking at it from the other side, departments having emp-loyees Nevertheless, the relationship expresses only one type of relationship

Sometimes, two entity types may have dual relationships That is, entities of one entitytype may be associated with entities of another entity type based on one type of

RELATIONSHIPS 187

Trang 3

association Again, entities for the same two entity types may be associated with each otherbased on a different criterion for the relationship.

Let us review a few examples of dual relationships

Professor – Student Dual Relationship Consider two entity types PROFESSORand STUDENT A professor entity may be associated with a student entity when theprofessor is teaching a class where the student is in the class This is one type of relation-ship between the two entity types

In another case, a professor entity may be associated with a student entity in the sense ofthe professor being a dissertation advisor for the student Here, although the professor andstudent entities are related, the relationship is of a different nature

See Figure 6-5 illustrating the dual relationship

Customer – Address Dual Relationship Take another example for considering dualrelationship Look at the requirements for relating orders with billing and shippingaddresses Customers place orders, and for the orders there could be billing and shippingaddresses For some orders, no such separate addresses may exist

The entity types in question are CUSTOMER, ORDER, and ADDRESS Hereaddresses are not reckoned as attributes of customers; addresses have separate existence.When residential, billing, and shipping addresses may apply to customers, you gain advan-tage by not expressing the addresses as attributes If you do so, you will have to permitnulls and allow empty spaces on many customer instances that do not have such separateaddresses

Figure 6-6 shows the entity types and the relationships

FIGURE 6-4 Employee and department: relationship and associations.

Trang 4

Observe how address and order entities are related in a dual relationship A speciﬁcaddress entity may be related to one or more order entities where the address is thebilling address Again, some other address entity may be associated with one or moreorder entities where the address is the shipping address.

Relationship Attributes

When we discussed attributes in detail in the previous chapter, we presented attributes asdescriptors of entities An entity type has descriptive attributes Values of each attributesdescribe particular entities If an entity type WATER-HEATER in a model for an appli-ance store has attributes SerialNo and Color, then for each water heater in the store,there are distinct values for SerialNo and Color The entity type WATER-HEATER

FIGURE 6-5 Professor– Student: dual relationship.

FIGURE 6-6 Order– Address: dual relationship.

RELATIONSHIPS 189

Trang 5

comprises the set of all water heaters in the store Values for attributes SerialNo and Colorare associated with each member of this set.

Earlier, we considered relationships as being sets The members of this relationship setconsist of pairs indicating entities from participating entity types Take an example oftwo entity types RENTER and PROPERTY for a real estate rental organization Arelationship “rents” exists between these two entity types This relationship forms a set

of pairs of entities, one from each entity type—(renter1 to property3), and so on Each

of these pairs itself has speciﬁc values such LeaseStartDate, LeaseEndDate, andMonthlyRent What are these speciﬁc values? These values describe each pair in therelationship set These are attributes for the relationship between entity typesRENTER and PROPERTY

Figure 6-7 illustrates attributes for relationships themselves

Note the relationship between RENTER and PROPERTY and the attributes for therelationship apart from the attributes of the entity types themselves

DEGREE OF RELATIONSHIPS

From the examples of relationships seen so far, you note that entity types are related intwos or threes That is, instances of two entity types are associated with each other, orinstances of three entity types are associated to form a combination

The degree of a relationship in a data model refers to the number of entity types thatparticipate in the relationship A three-way relationship is a ternary relationship with

FIGURE 6-7 Relationship attributes.

Trang 6

degree three; two-way, a binary relationship with degree two; one-way, a unary ship with degree one A unary relationship is also known as a recursive relationship as theentities of the same entity type associate with one another Relationships with degree fourare known as quaternary relationships These are quite rare Mostly, real-world situationscontain binary relationships.

relation-When you examine a relationship and note the degree of the relationship, the degreespeciﬁes how members of the relationships are constituted Each relationship symbolizes

a relationship set As we mentioned earlier, the relationship between two entity typesforms a set consisting of entity pairs, one entity from the ﬁrst entity type pairing withone entity from the second entity type Thus a binary relationship indicates a set ofentity pairs If the binary relationship has an attribute, then each entity pair in the relation-ship set pertains to a speciﬁc value for this attribute

What about a ternary relationship? How is this relationship constituted? A ternaryrelationship set contains triplets of entities formed by one entity from each of the threeparticipating entity types Thus, if the ternary relationship has an attribute, then eachentity triplet in the relationship set points to a particular value for this attribute

We may extend the notion of constituents of a relationship set to quaternaryrelationships and relationships with degrees higher than four This is the main pointabout relationship degrees The degree determines how members of the relationship setare formed—whether they are entity pairs, triplets, quadruplets, and so on

Let us examine a few examples of relationships with varying degrees When you look ateach example, observe how the relationship set for the example gets formed

Unary Relationship

As you already know, a unary relationship links an entity type with itself Entities of asingle entity type associate with entities within itself For forming an association, wetake an entity of the single entity type and revert back to the same entity type to ﬁndthe associative entity

In a unary relationship, the relationship set consists of entity pairs, taking entities fromthe same entity type In the relationship pair, entities from the same entity types recur Inthe entity pair, an entity is taken for an entity type, and again another entity is picked fromthe same entity type Therefore, the name recursive relationship applies to a unaryrelationship

Figure 6-8 illustrates unary relationship with two examples

In each example, explore how entity pairs from the same entity type form the ship set Also, note the attributes in each unary relationship We expressed that relation-ships in data model diagrams symbolize associations or logical links

relation-Binary Relationship

You have seen several examples of binary relationships When you scrutinize any datamodel, you will notice that most of the associations are binary relationships Providinganother example of a binary relationship may strike you as being redundant Nevertheless,

we want to show a common example of a binary relationship between STUDENT andCOURSE However, in this example we want to examine the contents of the relationship.Figure 6-9 shows the binary relationship

DEGREE OF RELATIONSHIPS 191

Trang 7

FIGURE 6-8 Unary relationship: examples.

FIGURE 6-9 Binary relationship and relationship set.

Trang 8

Carefully examine the ﬁgure with the binary relationship In particular, review themembers of the relationship set As you know, the pairs made up of student and courseentities form the set Note each member and values of the attribute for this relationship.

Ternary Relationship

Although binary relationships outnumber other types of relationships in a data model, youwill have occasion to design ternary relationships When you run into attributes thatdepend on three entities, one from each of three entity types, representing a three-wayrelationship becomes essential

Let us consider two examples The ﬁrst example relates to product shipments Usually,shipments involve entities from more than two entity types This example covers the entitytypes PRODUCT, VENDOR, and WAREHOUSE

The second example deals with doctors, patients, and offices In a group practice havingseveral locations, doctors may see patients in any of the offices of the group practice.Therefore, the date and time of an appointment depend on entity triplets fromDOCTOR, PATIENT, and OFFICE Here you find a ternary relationship

See Figure 6-10 for the two examples of ternary relationship Note the attributes of therelationships and how the attribute values depend on triplets formed by entities from each

of the three entity types

Quaternary Relationship

You may rarely run into a relationship with four participating entity types Such a resentation becomes necessary only when attribute values rely on entities from four inde-pendent entity types This does not happen too often in real-world situations

rep-Let us look at one example of a quaternary relationship A company procures loans toits clients from lending institutions for properties Agents bring this business to the

FIGURE 6-10 Ternary relationship: examples.

DEGREE OF RELATIONSHIPS 193

Trang 9

company The company charges a small fee for its services based on speciﬁc ations of the type of property, lending institution, and rates for agents The fee relates

consider-to the client, property, lending institution, and agent We note a four-way relationship.Figure 6-11 illustrates the quaternary relationship with four participating entity types.The ﬁgure also shows the quadruplets that make up the relationship set and their corres-ponding values for fee

STRUCTURAL CONSTRAINTS

Constraints are restrictions or rules that apply to any component of a data model If the datamodel represents real-world information requirements accurately, it must portray allaspects of the requirements including any business rules that govern the informationcontent Business rules may apply to the way each entity type gets constituted Severalbusiness rules affect attributes and their values Now, we want to consider how businessrules in an organization inﬂuence relationships among entity types

Let us work with a familiar example In any organization, different types of projectsexist Employees get assigned to the project When you symbolize the assignment ofemployees to projects, you create entity types of PROJECT and EMPLOYEE Therelationship between these two entity types expresses the assignment of employees toprojects Associations between employee entities and project entities exist

With regard to these associations, the business rules may give rise to different scenarios.How are these two types of entities related? How many entities of one type may be associatedwith how many entities of the second type? Should every employee entity be associated withone or more of the project entities? What about the opposite direction of the association?Figure 6-12 indicates the relationship between PROJECT and EMPLOYEE expressingsome possible scenarios about the associations of individual entities

FIGURE 6-11 Quaternary relationship and relationship set.

Trang 10

When you study the types of questions that arise regarding the associations, you willnote that business rules can impose two types of constraints on relationships The ﬁrstrelates to the question: How many of one entity type with how many of another entitytype—one, none, several? This type of constraint, as you know, relates to thecardinality of relationship—deals with numbers of associated entities The second type

of constraint relates to the question: Whether an entity must be part of an association ornot? This constraint tells about whether the association is optional or mandatory This con-straint type is known as optionality constraint It is also called participation constraintbecause it indicates whether individual entities may or may not participate in the relation-ship Sometimes, the term nullability constraint also refers to this type of constraint

We will note some examples of these two types of relationship constraints In the nextsection, we will elaborate on the cardinality and participation constraints with moreexamples using the concept of maximum and minimum cardinalities

Cardinality Constraint

Business rules stipulate how many of an entity type may be associated with how many of asecond entity type The cardinality indicators placed on the relationship line denotes thecardinality constraint Let us revisit the three common types of cardinality constraint:one-to-one, one-to-many, and many-to-many

As you already know, a relationship between two entity types actually indicates thenature of associations or links between individual instances of the two entity types.Only occurrences of individual entities are connected—that is what the relationship linebetween two entity types symbolizes Let us review an example for each of the threetypes of cardinality constraint

Cardinality Constraint: One-to-One Take the example of executives responsible toadminister company divisions This responsibility differs in various organizations Whenyou create a data model to show this relationship, you have to replicate the business rulegoverning the administration in your organization

FIGURE 6-12 Relationship between PROJECT and EMPLOYEE.

STRUCTURAL CONSTRAINTS 195

Trang 11

Let us consider a business rule about the administration of divisions and its tation a data model.

represen-Business rule:

In the organization, one executive is responsible for one division and not more than one sion Also, one division is supervised by one executive and not by more than one executive.

divi-Representation of relationship constraint:

Each executive entity is associated with one division entity and not with more than one sion entity Each division entity is associated with one executive entity and not with more than one executive entity.

divi-Figure 6-13 represents the one-to-one cardinality constraint Note the individual ations between entities shown in the diagram

associ-Cardinality Constraint: One-to-Many For an example of this type of constraint,let us consider the information requirements for an airlines company where you have toaccount for individual planes in the fleet by airplane type Your model must reflect therelationship between AIRPLANE-TYPE and AIRPLANE The entity type AIRPLANE-TYPE represents the various types of airplanes in the fleet such as Boeing 767, Boeing

747, Airbus 311, and so on whereas the entity type AIRPLANE includes the individualplanes in the ﬂeet

In this case, the business rule is fairly obvious The associations between type entitiesand plane entities must follow the basic business rule about types and instances

Business rule:

In the airline company, one airplane type may have one or several planes of this type On the other hand, every single plane belongs to only one airplane type.

FIGURE 6-13 Cardinality constraint: one-to-one.

Trang 12

Representation of relationship constraint:

Each airplane type entity is associated with one or many plane entities Each plane entity is linked to one and only one airplane type entity.

Figure 6-14 represents the one-to-many cardinality constraint Observe the individualassociations between entities shown in the diagram Notice how one type entity getslinked to one or more of the plane entities From the other side, one plane entity gets con-nected to one and only one type entity One-to-many constraint from one side of therelationship implies many-to-one constraint from the other side of the relationship

Cardinality Constraint: Many-to-Many This type of constraint is quite common inreal-word situations Take the familiar example of students enrolled in courses Your modelmust reflect the relationship between STUDENT and COURSE entity types For a specificstudent, you must be able to ascertain which courses he or she is enrolled in Also, the databaseimplementation should provide information on students enrolled for a particular course.The business rule in the university dictates how students may enroll in a course.Usually, there are no restrictions as to the number of courses a student may enroll in.However, your data model must reflect the actual business rule governing the specific situ-ation about enrollment

Business rule:

In the university, one student may enroll in one or more courses Also, one course may have one or more students.

Each student entity is associated with one or more course entities Each course entity is linked

to one or more student entities.

FIGURE 6-14 Cardinality constraint: one-to-many.

Trang 13

Figure 6-15 shows the many-to-many cardinality constraint Pay attention to the vidual associations between entities shown in the diagram Notice how one student entityconnects to one or more of the course entities Also, the same type of linkage happens fromthe other side, too From the other side, one course entity gets connected to one or manystudent entities Many-to-many constraint is a symmetrical constraint on the relationshipfrom either side, though the exact numbers of associated entities may vary.

indi-Participation Constraint

Other terminology also refers to participation constraints Participation constraints dealwith whether participation of individual entities in a relationship between entity types ismandatory or optional Participation constraints are also known as optionality in therelationship

Let us reconsider the relationship between EMPLOYEE and PROJECT and examine ifparticipation constraint could apply to this relationship In this relationship, employeeinstances or occurrences associate with project occurrences Suppose the relationshipbetween PROJECT and EMPLOYEE is one-to-many This means one project entity isassociated with one or more employee entities, and one employee entity is associatedwith one and only one project entity This is the cardinality constraint

In addition to stipulating the numbers or cardinalities, the business rule for the ship may include another type of constraint For example, the business may specifywhether employee entities need to participate in the relationship Two cases arise regard-ing the participation We will examine the two cases

relation-Partial Participation It is likely that in an organization, some employees belong tospecial cadres or work on routine operations Such employees will not be working onprojects Our data model must reﬂect this information about the relationship in addition

to the cardinality

FIGURE 6-15 Cardinality constraint: many-to-many.

Trang 14

We need to show how employee entities are associated with project entities both interms of numbers and participation The data model must represent how participationapplies to the relationship Let us review the business rule relating to partial participation.Business rule:

In the company, one project has at least one employee assigned to it Some employees may not

be working on any project at all.

Every project entity is associated with at least one employee entity An employee entity may not be associated with any project entity; if associated, an employee entity is linked to only one project entity.

Figure 6-16 shows the relationship between EMPLOYEE and PROJECT indicatingpartial participation of employee entities The diagram denotes the partial participation

by means of a broken line meaning that the participation of entities from the EMPLOYEEend is partial or optional However, from the PROJECT end, the participation is not partial.Every project entity participates in the relationship Indication of partial participation withbroken lines is one method of representation Other symbols such as single line for partialparticipation and double lines for total participation are also in usage

Total Participation In this case, there are no exceptions; every employee works onsome project This is typical of consulting companies where every employee is working

on one or more client projects The data model must reﬂect this information about therelationship in addition to the cardinality

Our data model has to show how employee entities are associated with project entities both

in terms of numbers and participation The data model must represent how participationapplies to the relationship Let us review the business rule relating to total participation.Business rule:

In the company, one project has at least one employee assigned to it Every employee works

on one or more projects.

Every project entity is associated with at least one employee entity Every employee is linked

to at least one project entity.

FIGURE 6-16 Participation constraint: partial participation.

Trang 15

Figure 6-17 shows the relationship between EMPLOYEE and PROJECT indicatingtotal participation of employee entities The diagram denotes the total participation bymeans of a solid line meaning that the participation of entities from the EMPLOYEEend is total or mandatory Also, from the PROJECT end, the participation is total.Every project entity participates in the relationship.

DEPENDENCIES

In Chapter 4, we covered weak entities that depend on strong or regular entities for theirexistence We will now revisit existence conditions for entities and also study relationshipsbetween entity types in this context

Exploring relationships in terms of entity existence conditions has a strong impact onimplementation of these in the database When we study transformation of conceptual datamodel into a logical data model, especially the relational framework, you will grasp thesigniﬁcance of existence-dependent relationships

Entity Existence

In a data model, entity types represented by rectangular boxes in the E-R technique do notpresent themselves as isolated and separate You know that entity types participate inrelationships However, the relationships do not always determine whether entity typesmay exist independently

As we have already seen earlier, many entity types do exist independently irrespective

of their relationships with other entity types Most of the entity types fall into this category.However, you will note occasions when some entity types need other entity types for theirexistence Let us review some examples

Independent Existence Let us say you have a data model for a university Twoimportant entity types are COURSE and INSTRUCTOR The COURSE entity type rep-resents all the courses offered in the university Similarly, the INSTRUCTOR entitytype comprises all the instructors that teach the courses

In fact, these two entity types are related because instructors teach courses Individualinstructor entities associate with distinct course entities Take a speciﬁc example: instruc-tor Kassia Silverton teaches Data Modeling course Irrespective of this association, theinstance of INSTRUCTOR, namely, Kassia Silverton, will exist in the database In thesame manner, the instance of COURSE, namely, Data Modeling, will exist in the databaseindependent of the association

FIGURE 6-17 Participation constraint: total participation.

Định dạng
Số trang	30
Dung lượng	631,15 KB