Моделирование бизнес-процессов / Моделирование бизнес-процессов / ER-диаграмы / 0849315484 Entity-Relationship Diagrams

Here, we have some partial participations and a 1-relationship. Using the grammar presented above, we have the following outcome:

STUDENT:GRADUATION:FACULTY::M:1:M

Short: Students may attend one graduation with many faculty.

Long: Students, that are recorded in the database, may attend (b = 1) one and only one graduation.

with

(c = m) many (one or more)] faculty.

No student attends more than one graduation [with many faculty].

We put the [with many faculty] in square brackets because it is not really needed to make sense of the diagram.

Similarly:

Faculty that are recorded in the database may attend one graduation with many students. Some faculty do not attend graduation [with many students].

Graduations must be attended by some students and some faculty. No graduation takes place without some students and some faculty.

Ternary Relationships from Relationship– Relationship Situations

Another scenario in which ternary relationships become necessary is where we have a scenario developing that results in a relationship of a relationship. Chen-like ER diagrams do not allow relationships of relationships; so, to represent this situation correctly, we need to develop a ternary relationship.

For example, let us start with two entities: BOOK_PUBLISHER and MANUSCRIPT. We can initially relate the two entities as shown in Figure 7.6A. A BOOK_PUBLISHER reviews a MANUSCRIPT.

Figure 7.6A: A Binary Relationship of BOOK_PUBLISHER and

MANUSCRIPT

At a later stage, if some MANUSCRIPTs result-in a BOOK after being reviewed, this calls for a relationship of a relationship, as shown in Figure 7.6B. This relationship of a relationship becomes necessary here because the BOOK_PUBLISHER, review, and MANUSCRIPT taken together will result-in a BOOK, as shown in Figure 7.6C.

Figure 7.6B: A Relationship of a Relationship

In Figure 7.6C, this BOOK_PUBLISHER, the reviews relationship, and MANUSCRIPT taken together is like creating a higher-level aggregate class composed of BOOK_PUBLISHER, review, and MANUSCRIPT. This aggregate class (of the two entities and a relationship) then needs to be related to BOOK, as shown in Figure 7.6C.

Figure 7.6C: A Relationship of a Relationship

To represent this situation correctly in the ER model schema presented in this book, and because we cannot show a relationship of a relationship to represent this situation, we need to create a weak entity (i.e., REVIEW) and relate it to BOOK_PUBLISHER, MANUSCRIPT, and BOOK as shown in Figure 7.6D. The intersection attribute, BMR, has to have a BOOK_PUBLISHER, MANUSCRIPT, and REVIEW. This review may

results-in a BOOK (as shown in Figure 7.6D).

Figure 7.6D: A Relationship of a Relationship Resolved into a Ternary Relationship

n-ary Relationships that May Be Resolved into Binary Relationships

Just because three entities are related does not necessarily imply a ternary relationship. In this section, we show how some ternary relationships can be resolved into binary relationships, and then we give another example of how a ternary relationship cannot be resolved into binary relationships (a real ternary relationship).

Just as the binary M:N relationship can be decomposed into two 1:M relationships, so can many n-ary relationships be decomposed. First, note the decomposition of the M:N into two 1:M's in Figure 7.7. The idea is to make the relationship an entity, and hence form two simpler binary relationships.

Figure 7.7: An ER Diagram of an M:N Relationship That Has Been Replaced with Two 1:M Relationships

Next, look again at Figure 7.5. If we decompose Figure 7.5 into three binary relationships, we obtain Figure 7.8. In Figure 7.8, note that the new entity ATTENDANCE is weak and depends on the three entities — FACULTY, STUDENT, and GRADUATION — for its existence. The sense of ATTENDANCE would be a roll of attendees for a GRADUATION ceremony event.

Figure 7.8: An ER Diagram (with Only Primary Keys) Showing a ThreeWay Relationship "Decomposed" into Three Binary

Relationships

There are situations, however, in which a relationship inherently associates more than two entities. Take Figure 7.2 as an example. Here, if we had another attribute like an order that a customer places to a supplier for a product, this attribute would require all three entities (i.e., CUSTOMER, PRODUCT, and SUPPLIER) at the same time. An order would specify that a supplier would supply some quantity of a product to a customer. This relationship cannot adequately be captured by binary relationships. With binary relationships we can only say that a customer placed an order for a product, or a supplier received an order for a product. The fact that a customer places an order for a product does not imply that the customer C is getting the product P from a supplier S unless all three entities are related.

Checkpoint 7.2

1.Can all ternary relationships be expressed in the form of binary relationships? Explain.

2.Come up with some attributes and entities of a relationship that you think could be a ternary relationship. Can this relationship be expressed in the form of a binary relationship?

Mapping Ternary Diagrams to a Relational Database

In this section we develop mapping rules to map n-ary relationships to a relational database because this will also cover ternary relationships.

M6 — For n-ary relationships — For each n-ary relationship, create a new relation. In the relation, include all attributes of the relationship. Then include all keys of connected entities as foreign keys and make the concatenation of the foreign keys the primary key of the new relation. Qualify all foreign keys.

For example, referring to Figure 7.2, you have a ternary relationship called buy relating PRODUCT, SUPPLIER, and CUSTOMER. There is an intersection attribute, price. The mapped relation (with some sample data) would be:

PRODUCT productID …

TAG1

TAG2

TAG3

…

SUPPLIER supplierID …

F1

G25

G20

…

CUSTOMER customerID …

PENS MOB DEL

…

Checkpoint 7.3

1.Could Figure 7.3 be described in the form of binary relationships? Discuss.

2.What mapping rules would you follow to map Figure 7.3?

3.Map Figure 7.3 to a relational database and show some sample data.

Our ER design methodology has now finally evolved to the following:

ER Design Methodology

Step 1: Select one primary entity from the database requirements description and show attributes to be recorded for that entity. Label keys if appropriate and show some sample data.

Step 2: Use structured English for entities, attributes, and keys to describe the database that has been elicited.

Step 3: Examine attributes in the existing entities (possibly with user assistance) to find out if information about one of the entities is to be recorded.

(We change "primary" to "existing" because we redo step 3 as we add new entities.)

Step 3a: If information about an attribute is needed, make the attribute an entity, and then

Step 3b: Define the relationship back to the original entity.

Step 4: If another entity is appropriate, draw the second entity with its attributes. Repeat steps 2 and 3 to see if this entity should be further split into more entities.

Step 5: Connect entities with relationships (one or more) if relationships exist.

Step 6: State the exact nature of the relationships in structured English from all sides. For example, if a relationship is A:B::1:M, then there is a relationship from A(1) to B(M) and from B(M) back to A(1).

For ternary and higher order (n-ary) relationships, state the relationship in structured English, being careful to mention all entities for the n-ary relationship. State the structural constraints as they exist.

Step 6a: Examine the list of attributes and determine whether any of them need to be identified by two (or more) entities. If so, place the attribute on an appropriate relationship that joins the two entities.

Step 6b: Examine the diagram for loops that might indicate redundant relationships. If a relationship is truly redundant, excise the redundant relationship.

Step 7: Show some sample data.

Step 8: Present the "as-designed" database to the user, complete with the English for entities, attributes, keys, and relationships. Refine the diagram as necessary.

Chapter Summary

Binary relationships are, by far, the most commonly occurring kind of relationships, and some ER diagram notations do not have expressions for ternary or other, higher-order relationships; that is, everything is expressed in terms of a binary relationship. In this chapter we showed how the need for ternary relationships arises from unique situations; for example when there is an intersection attribute that needs all three entities together, or when relationships of relationships develop. Ternary relationships can also be developed through reverse-engineering, and this is discussed in Chapter 9 where reverse-engineering is discussed. Also in this chapter, we discussed in detail the structural constraints of ternary relationships and their grammar, and showed how some ternary or n-ary relationships can be resolved into binary relationships, but how some cannot be resolved into binary relationships. The final section of this chapter discussed mapping rules of n- ary relationships.