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

an Intersection Attribute, wholesale_price

Figure 7.1B: A Binary Relationship of PRODUCT and CUSTOMER and an Intersection Attribute, retail_price

Some sample data for Figure 7.1A would be:

Some sample data for Figure 7.1B would be:

PRODUCT–CUSTOMER customerID productId retail_price

Now consider a different scenario. Suppose the customer buys products but the price depends not only on the product, but also on the supplier. Suppose you needed a customerID, a productID, and a supplierID to identify a price.

Now you have an attribute that depends on three things and hence you have a relationship between three entities (a ternary relationship) that will have the

intersection attribute, price. This situation is depicted in Figure 7.2.

Figure 7.2 represents the entities PRODUCT, SUPPLIER, and CUSTOMER, and a relationship, buy, among all three entities, shown by a single relationship diamond attached to all three entities.

Some sample data for Figure 7.2 would be:

PRODUCT–SUPPLIER–CUSTOMER customerID productID supplierID price

Figure 7.2: An ER Diagram (with Only Primary Keys) Showing a ThreeWay Relationship

This ternary case is more realistic because customers generally pay different prices for the same product by different manufacturers or suppliers. For different suppliers, one might also assume different prices for a product at different points in time. Also, for customers, one might assume that some items are bought on sale, some not. Another intersection attribute (see Figure 7.2) could be date, which could be the date of the sale of a product to a customer by a supplier.

In the case of higher-order relationships, they are most often found by finding an attribute that necessitates the existence of the n-ary relationship. Next we look at the structural constraints of ternary relationships.

Structural Constraints for Ternary Relationships

Ternary relationships can have the following types of structural constraints: one-to-one-to-one (1:1:1), one-to-one-to-many (1:1:M), one-to-many-to- many (1:M:M), and many-to-many-many (M:M:M), with full or partial participation on each one of the sides. Below is an example of the (M:M:M) with partial participation on all sides:

Many-to-Many-to-Many (M:M:M) Structural

Constraint

Figure 7A shows an example of a M:M:N relationship using three entities: PRODUCT, SUPPLIER, and CUSTOMER. This figure shows that many customers can buy many products from many suppliers, at different prices.

Figure 7A: An ER Diagram Showing a Ternary Many-to-Many-to-Many Relationship (Partial Participation on All Sides)

Instances of this relationship can be illustrated as shown in Figure 7B.

Figure 7B: Instances of a Ternary Many-to-Many-to-Many for CUSTOMER:PRODUCT:SUPPLIER Relationship

Checkpoint 7.1

1.What is a ternary relationship?

2.What is an n-ary relationship?

3.What are "higher order" relationships?

4.Using the three entities used above (PRODUCT, SUPPLIER, and CUSTOMER), draw an ER diagram that depicts the following: A customer must buy one and only one product from a supplier at a particular price on a particular date.

5.Using the three entities used above (PRODUCT, SUPPLIER, and CUSTOMER), draw an ER diagram that depicts the following: A supplier must supply many products to many customers at different prices on different dates.

6.Think of some more intersection attributes for the PRODUCT, SUPPLIER, and CUSTOMER ternary example given above.

7.What situations might create each of the following structural constraints?

a.PRODUCT: SUPPLIER: CUSTOMER::1:1:1, partial participation on all sides.

b.PRODUCT: SUPPLIER: CUSTOMER::1:M:M, partial participation on all sides.

c.PRODUCT: SUPPLIER: CUSTOMER::1:1:1 full participation on all sides.

Example of n-ary Relationship

An n-ary relationship describes the association among n entities. For our ternary example, we said that the price was dependent on a PRODUCT, SUPPLIER, and CUSTOMER. If we now say that the price is dependent on a PRODUCT, SUPPLIER, CUSTOMER, as well as STATE, then we are saying that the attribute price is dependent on four entities, and hence an n- ary (in this case, a 4-ary) relationship. In an n-ary (or, in this case, 4-ary) relationship, a single relationship diamond connects the n (4) entities, as shown in Figure 7.3. Here, too, the intersection attribute is price. More attributes on the entities would be expected.

Figure 7.3: An ER Diagram Showing an n-ary

Relationship

n-ary Relationships Do Not Preclude Binary

Relationships

Just because there is a ternary relationship does not mean that binary relationships among the entities may not exist. Using a similar example of CUSTOMERS, VENDORS, and PRODUCTS, suppose retail vendors and suppliers of products have a special relationship that does not involve customers — such as wholesaling with an entirely different price structure. This binary relationship can be shown separately from, and in addition to, a ternary relationship. See Figure 7.4 for a basic version of this two-way (binary) relationship and three-way (ternary) relationship ER diagram in the same database.

Figure 7.4: An ER Diagram (with Only Primary Keys) Showing a ThreeWay and a Two-Way Relationship

The semantics of Figure 7.4 tell us that we have a binary relationship, buy wholesale, between PRODUCT and VENDOR, with all PRODUCTs and VENDORs participating. Both the VENDOR and the CUSTOMER buy the PRODUCT, but in the VENDOR/PRODUCT relationship, the action is wholesale buying and hence the relationship is labeled buy wholesale. We changed the ternary relationship to read buy retail to distinguish the two relationships.

Methodology and Grammar for the n-ary Relationship

We need to revisit step 6 in the ER design methodology to cover the possibility of the n-ary relationship. The old version was:

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 to B, 1 to Many, and from B back to A, Many to 1.

We add the following sentence to step 6:

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.

The grammar for the n-ary relationship must involve all of the entities linked to it and, therefore, a suitable informal sentence would go something like this:

ENTITY1 Relationship (from/to/by)

ENTITY2 (and) (from/to/by) ENTITY3. It is understood that attribute will necessitate naming all n entities to identify it.

Here, if we choose some combination for Entity1, …, Entityn, this process resolves into:

Entity1 : CUSTOMER

Relationship: buy

Relationship attribute: retail price

Entity2: PRODUCT

Entity3: SUPPLIER

CUSTOMERS buy PRODUCTS from SUPPLIERS. It is understood that retail price will necessitate referencing all three entities to identify it.

With a binary relationship, we have to state two relationships. One would think that with ternary relationships, we would be bound to state three. Because the relationship attribute has already been stated, let us look at the other possibilities:

Entity1: CUSTOMER

Entity2: SUPPLIER

Entity3: PRODUCT

CUSTOMERS buy from SUPPLIERS, PRODUCTS.

For the same value of Entity1, the sense of the statement is really repeated and adds no information to the process. Suppose that:

Entity1: PRODUCT

Entity2: CUSTOMER

Entity3: SUPPLIER

PRODUCTS are bought by CUSTOMERS from SUPPLIERS.

In the informal version of the statement from the diagram, little information is gained by repetition. It is suggested that other combinations be tried. But, in the informal statement, it seems likely that one statement, inferred from the semantics of the situation, would suffice to informally declare the nature of the relationship.