Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Odds and Ends
This material was covered during lectures on January 20, 1997.
One ``final'' version of the Student Information System will be discussed in lab exercises and might also be part of assignments. This is an extension of Version Four that also keeps track of ``users of the system,'' including their login ids, passwords, and access levels. A more detailed description of this version of the system is available.
The entity-relationship diagram for this version of the system is as follows.
This picture is easy to describe. Add one entity called ``Registrar'' (that is, a rectangle with the word ``Registrar'' inside it) to the ERD for Version Four. This new entity isn't connected to the rest of the diagram in any way, so that the new diagram actually has two ``connected components.''
In previous years, quite a few students have asked about the difference between weak entities and subtypes, or have confused them.
Think of a subtype as being a kind of or perhaps a special case of its supertype. The subtype has exactly the same primary key as the supertype. It also has all the (other) attributes that the supertype does. If a relation in an ERD connects the supertype to some entity, then instances of the subtype can be connected to instances of the other entity, by that relationship. In other words, the subtype inherits the key, all the attributes, and any relationships of the supertype. The subtype might have additional attributes of its own and might participate in additional relationships (or both) - but, again, the primary key isn't changed.
If you are familiar with object-oriented design and programming, supertypes and subtypes in ERDs correspond to the use of ``single inheritance'' in an object-oriented design.
In contrast, (an instance of) a weak entity is not a special case or a kind of (an instance of) the entity it's associated with. Instead, it's a ``completely different thing.'' It happens that there's a different kind of ``close connection'' between the entity and the weak entity: Every instance of the weak entity ``corresponds to'' or depends on exactly one instance of the other entity. (However, ``in the other direction'': an instance of the ``other entity'' could have zero, one, or several instances of the weak entity that depend on it.)
The primary key for the weak entity will include all the attributes in the other object's primary key, plus one or more of the weak entity's own attributes. None of the ``other entity's'' non-key attributes will be attributes of the weak entity - so, the ``other entity's'' attributes will not generally be a subset of the weak entity's attributes, or vice-versa. The weak entity will have some attributes that are ``key'' attributes, in the sense that they're part of the weak entity's primary key, and the weak entity will generally have one or more non-key attributes, too.
A set of data tables for the system described by the ERD will generally include both a data table for the ``other'' entity and a data table for the weak entity - since both the ``other'' entity and the weak entity have instances of their own, and since an instance of the "other" entity is not also an instance of the weak entity, or vice-versa. In contrast, supertypes are often ``virtual entities'' (as has been previously described), and they don't have data tables of their own if this is the case.
When working on lab exercises and assignments, it's tempting to try to include all the ``components'' of ERDs that have been discussed. This is almost never necessary or correct - your system would need to be extremely complicated, in order for it to have an ERD including everything that has been described so far.
In fact, the ERD for Versions One and Two of the Student Information System are both very small and simple, but these two systems are complicated and large enough, so that they could serve as the basis for exercises and assignments for the rest of this course.
Thus, you should try to avoid the mistake of producing an ERD that's bigger or more complex than it needs to be, when working on exercises and assignments for this course. Keep it Simple, instead!
A lab exercise based on this material is available.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Odds and Ends