Representing ODL Relationships

Representing ODL Relationships

Generally, an ODL class definition will include relationships to other ODL classes. As in the E/R model, we can create for each relationship a new relation  that connects the keys of the two related classes. However, in ODL, relationships come in inverse pairs, and we must create only one relation for each pair.

The complete definition of the Movie and Studio classes

Example (a):  Look at the declarations of the classes Movie and Studio, which we repeat in Figure (a). We see that title and year form the key for Movie and name is a key for class Studio. We may create a relation for the pair of relationships owns and ownedBy. The relation requires a name, which can be arbitrary; we shall pick StudioOf as the name. The schema for StudioOf has attributes for the key of Movie, that is, title and year, and an attribute that we shall call studioName for the key of Studio. This relation schema is thus:

StudioOf (title, year, studioName)

Some typical tuples that would be in this relation are:

When a relationship is many-one, we have an option to combine it with the relation that is constructed for the class on the "many" side. Doing so has the effect of combining two relations that have a common key, as we discussed in "Combining Relations". It therefore does not cause a BCNF violation and is a legitimate and commonly followed option.

Example (b):  Rather than creating a relation StudioOf for relationship pair owns and ownedBy, as we did in Example (a), we may instead change our relation schema for relation Movies to include an attribute,  say studioName, to represent the key of Studio. If we do, the schema for Movies becomes

Movies(title, year, length, filmType, studioName)

and some typical tuples for this relation are:

Note that title and year, the key for the Movie class, is also a key for relation Movies, since each movie has a unique length, film type, and owning studio.

We should keep in mind that it is possible but unwise to treat many-many relationships as we did many-one relationships in Example (b) of this article. Actually, Example (b) in "Combining Relations" was based on what happens if we try to combine the many-many stars relationship between movies and their stars with the other information in the relation Movies to get a relation with schema:

Movies(title, year, length, filmType, studioName, starName)

There is a resulting BCNF violation, since {title , year, starName} is the key, yet attributes length, filmType, and studioName each are functionally determined by only title and year.

Similarly, if we do combine a many-one relationship with the relation for a class, it must be the class of the "many". For example, combining owns and its inverse ownedBy with relation Studios will lead to a BCNF violation.