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

Figure 10.1: Barker/Oracle-Like Notation: An ER Diagram with One Entity and Five Attributes

Figure 10.1 shows an ER diagram with one entity, STUDENT, and the following attributes: name, address, school, phone, and major. In the Oraclelike version of the Barker/Oracle-like ER diagram, the data type is also listed

— see Figure 10.1A.

Figure 10.1A: Barker/Oracle-Like Notation: An ER Diagram with One Entity and Five Attributes (Data Types Added)

Attributes in the Barker/Oracle-Like Model

All attributes in a Barker/Oracle-like model are considered simple or atomic, as in relational databases. The Barker/Oracle-like model does not have the concept of composite attributes. So, our Barker/Oracle-like adaptation will show parts of the composite attributes using a dot (.) notation, as shown in Figure 10.2.

Figure 10.2: Barker/Oracle-Like Notation: An ER Diagram with a Composite Attribute — name

Optional versus Mandatory Attributes

When designing a database, it is necessary to know whether or not an entity can contain an unknown value for an attribute. For example, in the STUDENT entity (shown in Figure 10.1), suppose that the address was optional. That is, if data was recorded for a student on a paper data entry form, we could demand that the person fill out his name and student number but allow him to have the address blank (i.e., unknown). We would say that the name and the student number are "mandatory," and address is "optional." A missing value is called a "null." Hence, the mandatory attribute is said to be "not null." Not null means that on no occasion would an instance of the entity exist without knowing the value of this mandatory attribute. In the Barker/Oraclelike ER model, we will show the optional attribute without the "not null" depiction and the mandatory attribute by adding the phrase "not null" to the description (as shown in Figure 10.3). A mandatory attribute could be a key but it is not necessarily a key. Mandatory and optional attributes are usually not indicated explicitly in the Chen-like model.

In our Barker model, the primary key has a "#" in front of the name of the attribute (as shown in Figure 10.3). A primary key has to be a mandatory attribute in a relational database, but again, all mandatory attributes here are not necessarily unique identifiers.

Figure 10.3: Barker/Oracle-Like Notation: An ER Diagram with a Primary Key or Unique Identifier Attribute and Optional and Mandatory Attributes

Checkpoint 10.1

1.What do mandatory attributes (in the Barker/Oracle-like model) translate into in the Chen-like model? Discuss with examples.

2.What do optional attributes (in the Barker/Oracle-like model) translate into in the Chen-like model? Discuss with examples.

3.How are the primary keys being shown diagrammatically in the Barker/Oracle-like model?

Relationships in the Barker/Oracle-Like Model

In the Barker/Oracle-like model, a relationship is represented by a line that joins two entities together. There is no diamond denoting the relationship (as we saw in the Chen-like model). The relationship phrase for each end of a relationship is placed near the appropriate end (entity) in lower case, as shown in Figure 10.4. In this model, from the STUDENT entity to the SCHOOL entity, we would say (informally) that:

Students attended schools

And, from the other direction, from the SCHOOL entity to the STUDENT entity, we would say that:

Schools are attended by students.

Figure 10.4: Barker/Oracle-Like Notation: The STUDENT Entity with a Relationship to the SCHOOL Entity

Structural Constraints in the Barker/Oracle-Like

Model

In the Barker/Oracle-like notation, the cardinality of 1 is shown by a single line leading up to the entity. In Figure 10.5, a single line joins the two entities, so this is a 1:1 relationship between STUDENT and AUTOMOBILE. This means that one student can be related to one and only one automobile, and one automobile can be related to one and only one student.

Figure 10.5: 1:1 Relationship in the Barker/Oracle-Like

Notation

The dashed line leading up to an entity signifies optional (partial) participation of an entity in a relationship. In Figure 10.5, both the STUDENT entity and the AUTOMOBILE entity are participating optionally in the relationship.

An enhanced grammar from the STUDENT entity to the AUTOMOBILE entity would be:

A student may drive one and only one automobile

And for the AUTOMOBILE entity to the STUDENT entity would be:

An automobile must be driven by one and only one student.

A continuous (solid) line coming from an entity (as shown in Figure 10.6) signifies mandatory (full) participation of that entity in a relationship. So, according to Figure 10.6, students must occupy dorms, but a dorm may have students.

A cardinality of M (many) is shown by "crowsfoot" structure leading to the respective entity. Figure 10.6 is an example of a 1:M relationship between DORM and STUDENT. The exact grammar of Figure 10.6 would be:

A dorm may be occupied by zero or more students

or

A student must occupy one and only one dorm.

Figure 10.6: 1:M Relationship in the Barker/Oracle-Like

Notation

Checkpoint 10.2

1.How is the "optional" relationship shown diagrammatically in the Barker/Oracle-like model?

2.How is the "many" relationship shown diagrammatically in the Barker/Oracle-like model?

3.Show the following using the Barker/Oracle-like notation:

a.A movie theater must show many movies and movies must be shown in a movie theater.

b.A movie theater may show many movies and movies may be shown in a movie theater.

Dealing with the Concept of the Weak Entity in the Barker/Oracle-Like Model

The Barker/Oracle models do not have a concept of the "weak entity," and the weak entity notation is not used in Oracle literature either. We will extend the concept of the unique identifier in a relationship to include the weak entity. In the Barker/Oracle-like model, the unique identifier in a relationship can be diagrammatically shown by a bar cutting across the contributing relationship, as shown in Figure 10.7. In Figure 10.7, to uniquely identify a dependent, one needs the employee's social security number. This means that the DEPENDENT entity cannot independently stand on its own, and hence is a weak entity. However, here the weak entity would be mapped as per the mapping rules discussed in Chapter 5.

Figure 10.7: Unique Identifier Shown by Placing Bar across Contributing Relationship Line(s)

Dealing with the Concept of Multi-Valued Attributes in the Barker/Oracle-Like Model

Again, although the Barker/Oracle models do not have the concept of the "multi-valued" attribute, multi-valued attributes can be shown as in Figure 10.8.

Figure 10.8 shows that a student may have attended many schools. In the Barker/Oracle-like model, the foreign key is shown in the appropriate entity, whereas in the Chen-like model, foreign keys are not "discovered" until the database is mapped. We will signal a foreign key with an asterisk (*) in front of the attribute (see Figure 10.8). An instance of this database shown in Figure 10.8 is:

Figure 10.8: Unique Identifier Shown by Placing Bar across Contributing Relationship Line(s) [Note: "*" shows a foreign key.]

As you can see, the multi-valued attribute is mapped to tables as it is depicted in the Barker/Oracle-like notation. In the Chen-like model, the multivalued attribute is kept in the diagram and then mapped using the mapping rules (see mapping rule M1c).

Checkpoint 10.3

1.Does the Barker-like model or the Oracle-like model have the concept of the "weak entity"? Discuss.

2.Show the following using the Barker/Oracle-like notation: For a student, we are trying to store the student's name, address, phone, books (i.e., books that the student borrows from the library). Map this to a relational database and show some sample data.

Treatment of Foreign Keys

In the original Barker model, foreign keys are not marked. In the Oracle model, however, foreign keys are included in the respective relations. For example, in Figure 10.9, which says:

A student may drive many automobiles

and

An automobile must be driven a student.

The primary key from the STUDENT relation (the 1 side), student number, is included in the AUTOMOBILE relation (the N side). In our Barker/Oracle-like model, we will precede the foreign key with an "*" (as shown in Figure 10.9).

Figure 10.9: Barker/Oracle-Like Notation Showing Foreign

Key