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

Checkpoint 6.1

1.In Figure 6.6, why is BUILDING an entity and not an attribute of another entity?

2.In Figure 6.6, why is the room number attribute attached to the lives in relationship rather than the STUDENT entity?

3.What will make you decide whether an attribute should be connected to ENTITYA or ENTITYB or, on the relationship connecting ENTITYA and ENTITYB?

4.Why are all the lines leaving BUILDING (on Figure 6.6) single lines (partial participation)?

5.According Figure 6.6, does a student have to enroll in a course?

6.According to Figure 6.6, how many courses can an instructor teach?

More Evolution of the Database

Let us reconsider the ER diagram in Figure 6.6. As the diagram is analyzed, the user might ask, "Why is a room number attribute not included for the relationship, class?" Why is there no office number for the relationship, office? There may be several reasons for the omission: (1) the data was not mentioned in the analysis stage; (2) the data is not necessary (i.e., there may be only one classroom per building or office numbers may not be recorded for advisors); or (3) it was an oversight and the data should be added. Suppose now we decide that room number is important for all of the relationships or entities. Suppose that we want to identify the room number associated with instructors and buildings, courses and buildings, and students and buildings. We might "evolve" the diagram to that of Figure 6.7.

Figure 6.7: An ER Diagram Showing a STUDENT/COURSE/INSTRUCTOR/ BUILDING Database with the "room number" for the Three Relations

In this case, we have information attached to BUILDING: building occupancy, the maintenance supervisor, and the square footage of the building. We have room number as an attribute identifiable by two entities in each case.

Attributes that Evolve into Entities

This section illustrates, one more time, the idea that we have to model "what is" and not necessarily "what might be." Also, we again see how an attribute might become an entity. Consider, for example, the following data that will go into an ER diagram/database: a course name, course number, credits, instructor name, and book. Example:

'Database','COP 4710',3,'Earp','Elmasri/Navathe'

The beginning ER diagram might look like Figure 6.8, "An ER Diagram of the COURSE entity in a database." Why "might look like…"? The answer lies in eliciting correct requirements from our user.

Figure 6.8: An ER Diagram with COURSE Entity in a

Database

If all of the information that was ever to be recorded about this data was mentioned above, then this single entity ER diagram would describe the database. However, one could realistically argue that things that we have described as attributes could themselves be entities. Both the instructor and the book would be candidates for being diagrammed as entities if the envisioned database called for it.

Consider a scenario in which one might choose to expand or redesign the database to include information about instructors. If this were the case, we might want to go beyond recording the instructor name and also include such attributes as the instructor's department, date_hired, and the school where the instructor received the terminal degree. With the additional information about INSTRUCTORS, the ER diagram would have two entities and would look like Figure 6.9.

Figure 6.9: An ER Diagram of the COURSE–INSTRUCTOR

Database

In Figure 6.9, we have depicted the INSTRUCTOR entity as weak because of the presumed non-uniqueness of instructor names and the dependence on COURSE. If the instructor were identified uniquely with an attribute like instructor social security number, and if instructors could exist independent of course, then the entity could become strong and would look like Figure 6.10. The idea of this section, then, is to bring out the point that an entity is not an entity just because one might want to record information "someday." There would have to be some planned intent to include the data that would be identified by the entity. Further, the definition of weak or strong entity would depend on the identifying information that was to be provided.

Figure 6.10: An ER Diagram of the COURSE–INSTRUCTOR

Database

Finally, if no information about instructors were ever planned, then the first ER diagram (Figure 6.10) would well describe the database. We will leave as an exercise the extension of Figure 6.10 to include BOOK as an entity.

Recursive Relationships

A recursive relationship is where the same entity participates more than once in different roles. Recursive relationships are also sometimes called unary relationships.

Consider, for example, the idea of personnel relations in a company. Personnel are likely to have an employee number, a name, etc. In addition to existing as an entity for all employees of an organization, there are relationships between individuals of the entity set, PERSONNEL. The most obvious relationship is that of employee–supervisor or personnel–supervisor. How would we depict the personnel–supervisor relationship when we have only one entity? The answer is shown in Figure 6.11.

Figure 6.11: A Classic Recursive Relationship PERSONNEL–

SUPERVISOR

Figure 6.11 shows the entity, PERSONNEL, with some simple attributes. Then, the relationship of supervise is added and connected to PERSONNEL on both ends. The cardinality of the relationship is 1:N, which means that one employee (personnel) can supervise many other employees but can only be supervised by one employee. We use partial participation from the supervisor side because not all personnel are supervisors — an employee may supervise many employees. The participation of the supervised employee is also partial. Although most employees are supervised by some, one supervisor, some employee will be at the top of the hierarchy with no supervisor. In recursive relationships, we are representing a hierarchy. All hierarchies have a top spot with no "supervision." All hierarchies are always partial–partial.

So, when there arises a relationship between individuals within the same entity set, it would be improper to have two entities because most of the information in the entities is basically the same. If we created two entities, then we would have redundancy in the database. Using the above example,

if we used two different entities rather than a recursive relationship, then an employee would be recorded in two different entities.

Recursive Relationships and Structural Constraints

Recursive relationships can only have partial participation in relationships, but the cardinality can be one-to-one, one-to-many, or many-to-many. Full participation in a recursive relationship would mean that every instance of an entity participates in a relationship with itself, which would not make sense.

Next we look at some examples of cardinalities as interpreted in recursive relationships.

One-to-One Recursive Relationship (Partial Participation on Both Sides)

Figure 6A show us an example of an entity, PERSONNEL, that is related to itself through a married to relationship. This means that a person in this database can be married to one other person in this same database.

Figure 6A: One-to-One Recursive Relationship (Partial Participation on Both Sides)

Some instances of this relationship are shown in Figure 6B. From Figure 6B we can see that Seema is married to Dev Anand, Sumon is married to Rekha, etc.

Figure 6B: Instances of One-to-One Recursive Relationship (Partial Participation on Both Sides)

One-to-Many Recursive Relationship (Partial Participation on Both Sides)

This is the most common recursive relationship. An example of this relationship may be where one employee may supervise many other employees (as shown in Figure 6C). As mentioned before, this is a hierarchical relationship and is always partial–partial.

Figure 6.C: One-to-Many Recursive Relationship (Partial Participation on Both Sides)

Instances of this relationship are shown in Figure 6D. From Figure 6D we can see that Tom Smith supervises Sudip Bagui and Tim Vaney, Rishi Kapoor supervises Mala Sinha and Korak Gupta, Korak Gupta supervises Roop Mukerjee, etc.

Figure 6.D: Instances of One-to-Many Recursive Relationship (Partial Participation on Both Sides)

Many-to-Many Recursive Relationship (Partial on Both Sides)

In this example we could say that courses may be prerequisities for zero or more other courses. This relationship is depicted in Figure 6E. The sense of prerequisite here is not hierarchical, but more like a situation where there are many courses that are interrelated.