CPSC 333: Weak Entities

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Weak Entities

This material was covered during Lectures on January 23, 1997.



The Student Information System, Version Three

The next version of the student information system can also keep track of sections of courses. In order to provide timetabling information, it is necessary to keep track of the term (fall, winter, spring, or summer) and year in which a section is running, as well as the name of the instructor, weekly meeting's start time, duration, and the location of each lecture. (Clearly we're still dealing with a ``simplified'' system, since it's assumed that each course section meets only once each week).

It is possible for more than one section of a course to be run during the same academic term, so each section of a course also has a section number. The associated course, and the course section's year, term, and section number are sufficient to identify any course section.

Now, students register in specific course sections, instead of in courses. However (as far as the system is concerned), they still pass courses - because a student is considered to have passed a course if that student has passed any section of it.

A more complete description of this version of the system is available. However, these are all the details that we will need at this point.

An Unsatisfactory Entity-Relationship Diagram

One might seem reasonable to make course section a new entity in the entity-relationship diagram. Since students now register in course sections instead of courses, the relationship ``is registered in'' would need to be changed, so that it is connected to ``course section'' instead of ``course.'' Finally, it seems reasonable to add a relationship between course sections and courses, so that the course ``corresponding to'' any given course section can be determined. The resulting entity-relationship diagram would like the following.

Picture of Incorrect Third ERD

A plain text approximation of this picture is also available.

The attributes of ``Student'' and ``Course'' would not change. The attributes of ``Course Section'' would include ``section number,'' ``term,'' ``year,'' ``instructor,'' ``start time,'' ``duration,'' and ``location.''

Unfortunately, a problem arises (which explains why this diagram is ``unsatisfactory'') as soon as we try to choose a primary key for the entity ``Course Section.''

If section numbers had been described differently - so that no course sections in the same term and year could have the same section number - then the set of attributes (only) including ``section number,'' ``term,'' and ``year'' would form a key for this entity, and could be used as its primary key.

However, section number weren't described this way; it was only guaranteed that section numbers could be used to distinguish among the sections of the same course running in a given term and year. Thus, section numbers are similar to those used here at the University of Calgary (where, for example, course sections for CPSC 313 and CPSC 333 running this term and year both have section number ``1'').

Now, while the section number, term, and year are sufficient to identify a course section if we also know which course the desired course section corresponds to, we really do need to know the associated course - there is no set of attributes of ``Course Section'' alone that forms a primary key for this ``entity.''

Definition of a Weak Entity

A weak entity (``W'') is a component of an entity-relationship diagram that has all the characteristics of an entity, except that there is no set of attributes of the weak entity that forms a key, and such that there is an entity (or another weak entity) E, such that

Thus the primary key of a weak entity is not a subset of (just) the set of the weak entity's attributes; it includes attributes from another entity as well (or, maybe even several other entities, if this weak entity is associated to another weak entity).

Note, by the way, that this definition does not imply that each instance of the ``strong'' entity E must have an instance of W associated to it. In fact, an instance of E could have zero, one, or even many instances of W associated to it.

A Correct Entity-Relationship Diagram for This System

Instead of making ``Course Section'' an entity, we will make it a ``weak entity,'' as defined above. Instances of ``Course Section'' are associated with instances of the entity ``Course'' (as described above, in the definition of ``weak entity''). The resulting entity-relationship diagram is as follows.

Picture of Third ERD

A plain text approximation of this picture is also available.

As this example should suggest, you should use a weak entity when you would use a (regular) entity, but you find that a key can't be formed from the available attributes, and when each instance of the new weak entity is associated with - or depends on - exactly one instance of some entity in your diagram.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] [Relationships]


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca