Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Associative Objects
This material was covered during lectures on January 26, 1997.
An associative object has many of the same properties that a relationship has. The main difference between a relationship and associative object is that an associative object (always) has attributes of its own, while a relationship never has these.
We can distinguish two different kinds of associative objects, by considering the number of different connections that can exist between a set of instances of the entities that the associative object links together:
In particular, suppose that an associative object links together k entities, E1, E2, ..., Ek (usually, k=2). Suppose Ij is an instance of the entity Ej, for j between 1 and k.
We'll almost always be dealing with the ``first kind'' of associative object in this course. The ``second kind'' might arise, for example, in a Hospital Information System, which includes entities called ``Patient'' and ``Medication,'' and an associative object called ``Prescription'' connecting ``Patient'' to ``Medication.'' There might be several prescriptions of the same medication to the same patient, but each would probably have been made on a different date - and date would probably be an attribute of the associative object ``Prescription,'' whose value is different on each instance connecting the same patient to the same medication.
Now that associative objects are available for use, a different entity-relationship diagram for Version Two of the Student Information System can be developed. Instead of using two relationships between ``Student'' and ``Course'' to model information about which students have registered in or passed which courses, we could use a single associative object, ``Participation,'' between these entities:
A plain text approximation of this picture is also available.
The associative object ``Participation'' has one attribute of its own - status, which can assume two possible values, one to indicate that the given student is currently registered in the given course, and the other to indicate that the given student has passed the given course.
The ``data table'' corresponding to the associative object ``Participation'' would have four columns: one for a student's ``ID number'' (the primary key for ``Student''), two more for ``discipline code'' and ``course number'' (the primary key for ``Course''), and a final column for ``status.''
The descriptions of the first two versions of the Student Information System indicated that a student who'd passed a course couldn't register in it again. This implies that there wouldn't ever be two or more rows in the data table with the same ID number, discipline code, and course number (but different values for ``status''), so ``Participation'' is an associative object of the first of the two kinds that are described above.
Of course, courses aren't always ``pass/fail,'' and the system would be more useful if it could represent the grades students receive. Suppose now that, on completion of a course section, a student receives a grade that is one of ``A+,'' ``A,'' ``A-,'' ``B+,'' ``B,''`` B-,'' ``C+,'' ``C,'' ``C-,'' ``D+,'' ``D,'' or ``F.''
Suppose, as well, that we now wish to keep track of the sections that a students withdraws from; we can also use the grade assigned to do this, by assigning the grade ``W'' if a student withdraws from a course section before a regular grade is assigned. Finally, a grade ``NA'' can be used to stand for the fact that a student is registered in a course section, hasn't withdrawn from it yet, and no regular grade has yet to be assigned.
We can also consider the grade earned by a given student for a given course to be the highest grade earned by that student for any section of the given course.
A more complete description of this system is also available.
An entity-relationship diagram for this system is as follows.
A plain text approximation of this picture is also available.
``Completion'' has a single attribute - grade. A data table for ``Completion'' would have seven columns - one for the primary key ``ID number'' of ``Student,'' five for the attributes ``discipline code,'' ``course number,'' ``term,'' ``year,'' and ``section number'' in the primary key for the weak entity ``Course Section,'' and one more for the additional attribute, ``grade.''
Note that, as mentioned above, a student's grade for a course could be computed as the highest grade earned by the student in any section of that course. Since the student's grade is computable from information already stored in the system's data tables - namely, the grades earned for the course sections - we will not store ``grades earned by students for courses'' in the system's data tables - we'd be introducing redundant data into the system's data table if we did - and, therefore, ``grade for course'' doesn't appear as an attribute for any entity, weak entity, or associative object in this system's ERD.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Associative Objects