Chapter 6 Database Design Using the E-R Model PDF

6.5 Primary Key 6.5.1 257 Entity Sets Conceptually, individual entities are distinct; from a database perspective, however, the differences among them must be expressed in terms of their attributes. Therefore, the values of the attribute values of an entity must be such that they can uniquely ide...

6.5 Primary Key 6.5.1 257 Entity Sets Conceptually, individual entities are distinct; from a database perspective, however, the differences among them must be expressed in terms of their attributes. Therefore, the values of the attribute values of an entity must be such that they can uniquely identify the entity. In other words, no two entities in an entity set are allowed to have exactly the same value for all attributes. The notion of a key for a relation schema, as defined in Section 2.3, applies directly to entity sets. That is, a key for an entity is a set of attributes that suffice to distinguish entities from each other. The concepts of superkey, candidate key, and primary key are applicable to entity sets just as they are applicable to relation schemas. Keys also help to identify relationships uniquely, and thus distinguish relationships from each other. Next, we define the corresponding notions of keys for relationship sets. 6.5.2 Relationship Sets We need a mechanism to distinguish among the various relationships of a relationship set. Let R be a relationship set involving entity sets E1 , E2 , … , En . Let primary-key(Ei ) denote the set of attributes that forms the primary key for entity set Ei . Assume for now that the attribute names of all primary keys are unique. The composition of the primary key for a relationship set depends on the set of attributes associated with the relationship set R. If the relationship set R has no attributes associated with it, then the set of attributes primary-key(E1 ) ∪ primary-key(E2 ) ∪ ⋯ ∪ primary-key(En ) describes an individual relationship in set R. If the relationship set R has attributes a1 , a2 , … , am associated with it, then the set of attributes primary-key(E1 ) ∪ primary-key(E2 ) ∪ ⋯ ∪ primary-key(En ) ∪ {a1 , a2 , … , am } describes an individual relationship in set R. If the attribute names of primary keys are not unique across entity sets, the attributes are renamed to distinguish them; the name of the entity set combined with the name of the attribute would form a unique name. If an entity set participates more than once in a relationship set (as in the prereq relationship in Section 6.2.2), the role name is used instead of the name of the entity set, to form a unique attribute name. Recall that a relationship set is a set of relationship instances, and each instance is uniquely identified by the entities that participate in it. Thus, in both of the preceding cases, the set of attributes primary-key(E1 ) ∪ primary-key(E2 ) ∪ ⋯ ∪ primary-key(En ) forms a superkey for the relationship set. 258 Chapter 6 Database Design Using the E-R Model The choice of the primary key for a binary relationship set depends on the mapping cardinality of the relationship set. For many-to-many relationships, the preceding union of the primary keys is a minimal superkey and is chosen as the primary key. As an illustration, consider the entity sets instructor and student, and the relationship set advisor, in Section 6.2.2. Suppose that the relationship set is many-to-many. Then the primary key of advisor consists of the union of the primary keys of instructor and student. For one-to-many and many-to-one relationships, the primary key of the “many” side is a minimal superkey and is used as the primary key. For example, if the relationship is many-to-one from student to instructor — that is, each student can have at most one advisor— then the primary key of advisor is simply the primary key of student. However, if an instructor can advise only one student— that is, if the advisor relationship is manyto-one from instructor to student — then the primary key of advisor is simply the primary key of instructor. For one-to-one relationships, the primary key of either one of the participating entity sets forms a minimal superkey, and either one can be chosen as the primary key of the relationship set. However, if an instructor can advise only one student, and each student can be advised by only one instructor— that is, if the advisor relationship is one-to-one— then the primary key of either student or instructor can be chosen as the primary key for advisor. For nonbinary relationships, if no cardinality constraints are present, then the superkey formed as described earlier in this section is the only candidate key, and it is chosen as the primary key. The choice of the primary key is more complicated if cardinality constraints are present. As we noted in Section 6.4, we permit at most one arrow out of a relationship set. We do so because an E-R diagram with two or more arrows out of a nonbinary relationship set can be interpreted in the two ways we describe below. Suppose there is a relationship set R between entity sets E1 , E2 , E3 , E4 , and the only arrows are on the edges to entity sets E3 and E4 . Then, the two possible interpretations are: 1. A particular combination of entities from E1 , E2 can be associated with at most one combination of entities from E3 , E4 . Thus, the primary key for the relationship R can be constructed by the union of the primary keys of E1 and E2 . 2. A particular combination of entities from E1 , E2 , E3 can be associated with at most one combination of entities from E4 , and further a particular combination of entities from E1 , E2 , E4 can be associated with at most one combination of entities from E3 , Then the union of the primary keys of E1 , E2 , and E3 forms a candidate key, as does the union of the primary keys of E1 , E2 , and E4 . Each of these interpretations has been used in practice and both are correct for particular enterprises being modeled. Thus, to avoid confusion, we permit only one arrow out of a nonbinary relationship set, in which case the two interpretations are equivalent. 6.5 Primary Key 259 In order to represent a situation where one of the multiple-arrow situations holds, the E-R design can be modified by replacing the non-binary relationship set with an entity set. That is, we treat each instance of the non-binary relationship set as an entity. Then we can relate each of those entities to corresponding instances of E1 , E2 , E4 via separate relationship sets. A simpler approach is to use functional dependencies, which we study in Chapter 7 (Section 7.4). Functional dependencies which allow either of these interpretations to be specified simply in an unambiguous manner. The primary key for the relationship set R is then the union of the primary keys of those participating entity sets Ei that do not have an incoming arrow from the relationship set R. 6.5.3 Weak Entity Sets Consider a section entity, which is uniquely identified by a course identifier, semester, year, and section identifier. Section entities are related to course entities. Suppose we create a relationship set sec course between entity sets section and course. Now, observe that the information in sec course is redundant, since section already has an attribute course id, which identifies the course with which the section is related. One option to deal with this redundancy is to get rid of the relationship sec course; however, by doing so the relationship between section and course becomes implicit in an attribute, which is not desirable. An alternative way to deal with this redundancy is to not store the attribute course id in the section entity and to only store the remaining attributes sec id, year, and semester.2 However, the entity set section then does not have enough attributes to identify a particular section entity uniquely; although each section entity is distinct, sections for different courses may share the same sec id, year, and semester. To deal with this problem, we treat the relationship sec course as a special relationship that provides extra information, in this case the course id, required to identify section entities uniquely. The notion of weak entity set formalizes the above intuition. A weak entity set is one whose existence is dependent on another entity set, called its identifying entity set; instead of associating a primary key with a weak entity, we use the primary key of the identifying entity, along with extra attributes, called discriminator attributes to uniquely identify a weak entity. An entity set that is not a weak entity set is termed a strong entity set. Every weak entity must be associated with an identifying entity; that is, the weak entity set is said to be existence dependent on the identifying entity set. The identifying entity set is said to own the weak entity set that it identifies. The relationship associating the weak entity set with the identifying entity set is called the identifying relationship. The identifying relationship is many-to-one from the weak entity set to the identifying entity set, and the participation of the weak entity set in the relationship is total. 2 Note that the relational schema we eventually create from the entity set section does have the attribute course id, for reasons that will become clear later, even though we have dropped the attribute course id from the entity set section. 260 Chapter 6 Database Design Using the E-R Model The identifying relationship set should not have any descriptive attributes, since any such attributes can instead be associated with the weak entity set. In our example, the identifying entity set for section is course, and the relationship sec course, which associates section entities with their corresponding course entities, is the identifying relationship. The primary key of section is formed by the primary key of the identifying entity set (that is, course), plus the discriminator of the weak entity set (that is, section). Thus, the primary key is {course id, sec id, year, semester}. Note that we could have chosen to make sec id globally unique across all courses offered in the university, in which case the section entity set would have had a primary key. However, conceptually, a section is still dependent on a course for its existence, which is made explicit by making it a weak entity set. In E-R diagrams, a weak entity set is depicted via a double rectangle with the discriminator being underlined with a dashed line. The relationship set connecting the weak entity set to the identifying strong entity set is depicted by a double diamond. In Figure 6.14, the weak entity set section depends on the strong entity set course via the relationship set sec course. The figure also illustrates the use of double lines to indicate that the participation of the (weak) entity set section in the relationship sec course is total, meaning that every section must be related via sec course to some course. Finally, the arrow from sec course to course indicates that each section is related to a single course. In general, a weak entity set must have a total participation in its identifying relationship set, and the relationship is many-to-one toward the identifying entity set. A weak entity set can participate in relationships other than the identifying relationship. For instance, the section entity could participate in a relationship with the time slot entity set, identifying the time when a particular class section meets. A weak entity set may participate as owner in an identifying relationship with another weak entity set. It is also possible to have a weak entity set with more than one identifying entity set. A particular weak entity would then be identified by a combination of entities, one from each identifying entity set. The primary key of the weak entity set would consist of the union of the primary keys of the identifying entity sets, plus the discriminator of the weak entity set. course course_id title credits sec_course section sec_id semester year Figure 6.14 E-R diagram with a weak entity set. 6.6 Removing Redundant Attributes in Entity Sets 6.6 261 Removing Redundant Attributes in Entity Sets When we design a database using the E-R model, we usually start by identifying those entity sets that should be included. For example, in the university organization we have discussed thus far, we decided to include such entity sets as student and instructor. Once the entity sets are decided upon, we must choose the appropriate attributes. These attributes are supposed to represent the various values we want to capture in the database. In the university organization, we decided that for the instructor entity set, we will include the attributes ID, name, dept name, and salary. We could have added the attributes phone number, office number, home page, and others. The choice of what attributes to include is up to the designer, who has a good understanding of the structure of the enterprise. Once the entities and their corresponding attributes are chosen, the relationship sets among the various entities are formed. These relationship sets may result in a situation where attributes in the various entity sets are redundant and need to be removed from the original entity sets. To illustrate, consider the entity sets instructor and department: • The entity set instructor includes the attributes ID, name, dept name, and salary, with ID forming the primary key. • The entity set department includes the attributes dept name, building, and budget, with dept name forming the primary key. We model the fact that each instructor has an associated department using a relationship set inst dept relating instructor and department. The attribute dept name appears in both entity sets. Since it is the primary key for the entity set department, it is redundant in the entity set instructor and needs to be removed. Removing the attribute dept name from the instructor entity set may appear rather unintuitive, since the relation instructor that we used in the earlier chapters had an attribute dept name. As we shall see later, when we create a relational schema from the E-R diagram, the attribute dept name in fact gets added to the relation instructor, but only if each instructor has at most one associated department. If an instructor has more than one associated department, the relationship between instructors and departments is recorded in a separate relation inst dept. Treating the connection between instructors and departments uniformly as a relationship, rather than as an attribute of instructor, makes the logical relationship explicit, and it helps avoid a premature assumption that each instructor is associated with only one department. Similarly, the student entity set is related to the department entity set through the relationship set student dept and thus there is no need for a dept name attribute in student. 262 Chapter 6 Database Design Using the E-R Model As another example, consider course offerings (sections) along with the time slots of the offerings. Each time slot is identified by a time slot id, and has associated with it a set of weekly meetings, each identified by a day of the week, start time, and end time. We decide to model the set of weekly meeting times as a multivalued composite attribute. Suppose we model entity sets section and time slot as follows: • The entity set section includes the attributes course id, sec id, semester, year, build- ing, room number, and time slot id, with (course id, sec id, year, semester) forming the primary key. • The entity set time slot includes the attributes time slot id, which is the primary key,3 and a multivalued composite attribute {(day, start time, end time)}.4 These entities are related through the relationship set sec time slot. The attribute time slot id appears in both entity sets. Since it is the primary key for the entity set time slot, it is redundant in the entity set section and needs to be removed. As a final example, suppose we have an entity set classroom, with attributes building, room number, and capacity, with building and room number forming the primary key. Suppose also that we have a relationship set sec class that relates section to classroom. Then the attributes {building, room number} are redundant in the entity set section. A good entity-relationship design does not contain redundant attributes. For our university example, we list the entity sets and their attributes below, with primary keys underlined: • • • • • • • classroom: with attributes (building, room number, capacity). department: with attributes (dept name, building, budget). course: with attributes (course id, title, credits). instructor: with attributes (ID, name, salary). section: with attributes (course id, sec id, semester, year). student: with attributes (ID, name, tot cred). time slot: with attributes (time slot id, {(day, start time, end time) }). The relationship sets in our design are listed below: • inst dept: relating instructors with departments. • stud dept: relating students with departments. 3 We shall see later on that the primary key for the relation created from the entity set time slot includes day and start time; however, day and start time do not form part of the primary key of the entity set time slot. 4 We could optionally give a name, such as meeting, for the composite attribute containing day, start time, and end time. 6.6 Removing Redundant Attributes in Entity Sets • • • • • • • • 263 teaches: relating instructors with sections. takes: relating students with sections, with a descriptive attribute grade. course dept: relating courses with departments. sec course: relating sections with courses. sec class: relating sections with classrooms. sec time slot: relating sections with time slots. advisor: relating students with instructors. prereq: relating courses with prerequisite courses. You can verify that none of the entity sets has any attribute that is made redundant by one of the relationship sets. Further, you can verify that all the information (other than constraints) in the relational schema for our university database, which we saw earlier in Figure 2.9, has been captured by the above design, but with several attributes in the relational design replaced by relationships in the E-R design. We are finally in a position to show (Figure 6.15) the E-R diagram that corresponds to the university enterprise that we have been using thus far in the text. This E-R diagram is equivalent to the textual description of the university E-R model, but with several additional constraints. In our university database, we have a constraint that each instructor must have exactly one associated department. As a result, there is a double line in Figure 6.15 between instructor and inst dept, indicating total participation of instructor in inst dept; that is, each instructor must be associated with a department. Further, there is an arrow from inst dept to department, indicating that each instructor can have at most one associated department. Similarly, entity set course has a double line to relationship set course dept, indicating that every course must be in some department, and entity set student has a double line to relationship set stud dept, indicating that every student must be majoring in some department. In each case, an arrow points to the entity set department to show that a course (and, respectively, a student) can be related to only one department, not several. Similarly, entity set course has a double line to relationship set course dept, indicating that every course must be in some department, and entity set student has a double line to relationship set stud dept, indicating that every student must be majoring in some department. In each case, an arrow points to the entity set department to show that a course (and, respectively, a student) can be related to only one department, not several. Further, Figure 6.15 shows that the relationship set takes has a descriptive attribute grade, and that each student has at most one advisor. The figure also shows that section is a weak entity set, with attributes sec id, semester, and year forming the discriminator; sec course is the identifying relationship set relating weak entity set section to the strong entity set course. 264 Chapter 6 Database Design Using the E-R Model department course_dept dept_name building budget stud_dept inst_dept instructor student ID name salary ID name tot_cred advisor takes teaches section course course_id title credits course_id prereq sec_course prereq_id sec_id semester year grade time_slot sec_time_slot time_slot_id { day start_time end_time } sec_class classroom building room_number capacity Figure 6.15 E-R diagram for a university enterprise. In Section 6.7, we show how this E-R diagram can be used to derive the various relation schemas we use. 6.7 Reducing E-R Diagrams to Relational Schemas Both the E-R model and the relational database model are abstract, logical representations of real-world enterprises. Because the two models employ similar design principles, we can convert an E-R design into a relational design. For each entity set and for each relationship set in the database design, there is a unique relation schema to which we assign the name of the corresponding entity set or relationship set. 6.7 Reducing E-R Diagrams to Relational Schemas 265 In this section, we describe how an E-R schema can be represented by relation schemas and how constraints arising from the E-R design can be mapped to constraints on relation schemas. 6.7.1 Representation of Strong Entity Sets Let E be a strong entity set with only simple descriptive attributes a1 , a2 , … , an . We represent this entity with a schema called E with n distinct attributes. Each tuple in a relation on this schema corresponds to one entity of the entity set E. For schemas derived from strong entity sets, the primary key of the entity set serves as the primary key of the resulting schema. This follows directly from the fact that each tuple corresponds to a specific entity in the entity set. As an illustration, consider the entity set student of the E-R diagram in Figure 6.15. This entity set has three attributes: ID, name, tot cred. We represent this entity set by a schema called student with three attributes: student (ID, name, tot cred) Note that since student ID is the primary key of the entity set, it is also the primary key of the relation schema. Continuing with our example, for the E-R diagram in Figure 6.15, all the strong entity sets, except time slot, have only simple attributes. The schemas derived from these strong entity sets are depicted in Figure 6.16. Note that the instructor, student, and course schemas are different from the schemas we have used in the previous chapters (they do not contain the attribute dept name). We shall revisit this issue shortly. 6.7.2 Representation of Strong Entity Sets with Complex Attributes When a strong entity set has nonsimple attributes, things are a bit more complex. We handle composite attributes by creating a separate attribute for each of the component attributes; we do not create a separate attribute for the composite attribute itself. To illustrate, consider the version of the instructor entity set depicted in Figure 6.8. For the composite attribute name, the schema generated for instructor contains the attributes classroom(building, room number, capacity) department(dept name, building, budget) course(course id, title, credits) instructor(ID, name, salary) student(ID, name, tot cred) Figure 6.16 Schemas derived from the entity sets in the E-R diagram in Figure 6.15. 266 Chapter 6 Database Design Using the E-R Model first name, middle initial, and last name; there is no separate attribute or schema for name. Similarly, for the composite attribute address, the schema generated contains the attributes street, city, state, and postal code. Since street is a composite attribute it is replaced by street number, street name, and apt number. Multivalued attributes are treated differently from other attributes. We have seen that attributes in an E-R diagram generally map directly into attributes for the appropriate relation schemas. Multivalued attributes, however, are an exception; new relation schemas are created for these attributes, as we shall see shortly. Derived attributes are not explicitly represented in the relational data model. However, they can be represented as stored procedures, functions, or methods in other data models. The relational schema derived from the version of entity set instructor with complex attributes, without including the multivalued attribute, is thus: instructor (ID, first name, middle initial, last name, street number, street name, apt number, city, state, postal code, date of birth) For a multivalued attribute M, we create a relation schema R with an attribute A that corresponds to M and attributes corresponding to the primary key of the entity set or relationship set of which M is an attribute. As an illustration, consider the E-R diagram in Figure 6.8 that depicts the entity set instructor, which includes the multivalued attribute phone number. The primary key of instructor is ID. For this multivalued attribute, we create a relation schema instructor phone (ID, phone number) Each phone number of an instructor is represented as a unique tuple in the relation on this schema. Thus, if we had an instructor with ID 22222, and phone numbers 555-1234 and 555-4321, the relation instructor phone would have two tuples (22222, 555-1234) and (22222, 555-4321). We create a primary key of the relation schema consisting of all attributes of the schema. In the above example, the primary key consists of both attributes of the relation schema instructor phone. In addition, we create a foreign-key constraint on the relation schema created from the multivalued attribute. In that newly created schema, the attribute generated from the primary key of the entity set must reference the relation generated from the entity set. In the above example, the foreign-key constraint on the instructor phone relation would be that attribute ID references the instructor relation. In the case that an entity set consists of only two attributes— a single primary-key attribute B and a single multivalued attribute M — the relation schema for the entity set would contain only one attribute, namely, the primary-key attribute B. We can drop 6.7 Reducing E-R Diagrams to Relational Schemas 267 this relation, while retaining the relation schema with the attribute B and attribute A that corresponds to M. To illustrate, consider the entity set time slot depicted in Figure 6.15. Here, time slot id is the primary key of the time slot entity set, and there is a single multivalued attribute that happens also to be composite. The entity set can be represented by just the following schema created from the multivalued composite attribute: time slot (time slot id, day, start time, end time) Although not represented as a constraint on the E-R diagram, we know that there cannot be two meetings of a class that start at the same time of the same day of the week but end at different times; based on this constraint, end time has been omitted from the primary key of the time slot schema. The relation created from the entity set would have only a single attribute time slot id; the optimization of dropping this relation has the benefit of simplifying the resultant database schema, although it has a drawback related to foreign keys, which we briefly discuss in Section 6.7.4. 6.7.3 Representation of Weak Entity Sets Let A be a weak entity set with attributes a1 , a2 , … , am . Let B be the strong entity set on which A depends. Let the primary key of B consist of attributes b1 , b2 , … , bn . We represent the entity set A by a relation schema called A with one attribute for each member of the set: {a1 , a2 , … , am } ∪ {b1 , b2 , … , bn } For schemas derived from a weak entity set, the combination of the primary key of the strong entity set and the discriminator of the weak entity set serves as the primary key of the schema. In addition to creating a primary key, we also create a foreign-key constraint on the relation A, specifying that the attributes b1 , b2 , … , bn reference the primary key of the relation B. The foreign-key constraint ensures that for each tuple representing a weak entity, there is a corresponding tuple representing the corresponding strong entity. As an illustration, consider the weak entity set section in the E-R diagram of Figure 6.15. This entity set has the attributes: sec id, semester, and year. The primary key of the course entity set, on which section depends, is course id. Thus, we represent section by a schema with the following attributes: section (course id, sec id, semester, year) The primary key consists of the primary key of the entity set course, along with the discriminator of section, which is sec id, semester, and year. We also create a foreign-key 268 Chapter 6 Database Design Using the E-R Model constraint on the section schema, with the attribute course id referencing the primary key of the course schema.5 6.7.4 Representation of Relationship Sets Let R be a relationship set, let a1 , a2 , … , am be the set of attributes formed by the union of the primary keys of each of the entity sets participating in R, and let the descriptive attributes (if any) of R be b1 , b2 , … , bn . We represent this relationship set by a relation schema called R with one attribute for each member of the set: {a1 , a2 , … , am } ∪ {b1 , b2 , … , bn } We described in Section 6.5, how to choose a primary key for a binary relationship set. The primary key attributes of the relationship set are also used as the primary key attributes of the relational schema R. As an illustration, consider the relationship set advisor in the E-R diagram of Figure 6.15. This relationship set involves the following entity sets: • instructor, with the primary key ID. • student, with the primary key ID. Since the relationship set has no attributes, the advisor schema has two attributes, the primary keys of instructor and student. Since both attributes have the same name, we rename them i ID and s ID. Since the advisor relationship set is many-to-one from student to instructor the primary key for the advisor relation schema is s ID. We also create foreign-key constraints on the relation schema R as follows: For each entity set Ei related by relationship set R, we create a foreign-key constraint from relation schema R, with the attributes of R that were derived from primary-key attributes of Ei referencing the primary key of the relation schema representing Ei . Returning to our earlier example, we thus create two foreign-key constraints on the advisor relation, with attribute i ID referencing the primary key of instructor and attribute s ID referencing the primary key of student. Applying the preceding techniques to the other relationship sets in the E-R diagram in Figure 6.15, we get the relational schemas depicted in Figure 6.17. Observe that for the case of the relationship set prereq, the role indicators associated with the relationship are used as attribute names, since both roles refer to the same relation course. Similar to the case of advisor, the primary key for each of the relations sec course, sec time slot, sec class, inst dept, stud dept, and course dept consists of the primary key 5 Optionally, the foreign-key constraint could have an “on delete cascade” specification, so that deletion of a course entity automatically deletes any section entities that reference the course entity. Without that specification, each section of a course would have to be deleted before the corresponding course can be deleted. 6.7 Reducing E-R Diagrams to Relational Schemas 269 teaches (ID, course id, sec id, semester, year) takes (ID, course id, sec id, semester, year, grade) prereq (course id, prereq id) advisor (s ID, i ID) sec course (course id, sec id, semester, year) sec time slot (course id, sec id, semester, year, time slot id) sec class (course id, sec id, semester, year, building, room number) inst dept (ID, dept name) stud dept (ID, dept name) course dept (course id, dept name) Figure 6.17 Schemas derived from relationship sets in the E-R diagram in Figure 6.15. of only one of the two related entity sets, since each of the corresponding relationships is many-to-one. Foreign keys are not shown in Figure 6.17, but for each of the relations in the figure there are two foreign-key constraints, referencing the two relations created from the two related entity sets. Thus, for example, sec course has foreign keys referencing section and classroom, teaches has foreign keys referencing instructor and section, and takes has foreign keys referencing student and section. The optimization that allowed us to create only a single relation schema from the entity set time slot, which had a multivalued attribute, prevents the creation of a foreign key from the relation schema sec time slot to the relation created from entity set time slot, since we dropped the relation created from the entity set time slot. We retained the relation created from the multivalued attribute and named it time slot, but this relation may potentially have no tuples corresponding to a time slot id, or it may have multiple tuples corresponding to a time slot id; thus, time slot id in sec time slot cannot reference this relation. The astute reader may wonder why we have not seen the schemas sec course, sec time slot, sec class, inst dept, stud dept, and course dept in the previous chapters. The reason is that the algorithm we have presented thus far results in some schemas that can be either eliminated or combined with other schemas. We explore this issue next. 6.7.5 Redundancy of Schemas A relationship set linking a weak entity set to the corresponding strong entity set is treated specially. As we noted in Section 6.5.3, these relationships are many-to-one and have no descriptive attributes. Furthermore, the of a weak entity set includes the primary key of the strong entity set. In the E-R diagram of Figure 6.14, the weak entity set section is dependent on the strong entity set course via the relationship set sec course.