Declaring Keys in ODL

Declaring Keys in ODL

ODL is different from the other models studied so far in that the declaration and use of keys is optional. That is, in the E/R model, entity sets require keys to distinguish members of the entity set from  one another. In the relational model, where relations are sets, all attributes collectively form a key unless some accurate subset of the attributes for a given relation can serve as a key. Either way, there must be at least one key for a relation.

Nevertheless, objects have a unique object identity, as we discussed in "The Type System" under "Object Identity". Accordingly, in ODL, the declaration of a key or keys is optional. It is completely appropriate for there to be various objects of a class that are indistinguishable by any properties we can examine; the system still keeps them distinct by their internal object identity

In ODL we may declare one or more attributes to be a key for a class by using the keyword key or keys (it doesn't matter which) followed by the attribute or attributes forming keys. If there is more than one attribute in a key, the list of attributes must be surrounded by parentheses. The key declaration itself appears, along with the extent declaration, inside parentheses that may follow the name of the class itself in the first line of its declaration.

Example (a) : To declare that the set of two attributes title and year form a key for class Movie, we could begin its declaration:

class Movie
      (extent Movies key (title, year))
{
      attribute string title;
        . . .  

We could have used keys in place of key, even though only one key is declared. Likewise, if name is a key for class Star, then we could begin its declaration:

class Star
     (extent Stars key name)
{
     attribute string name;
       . . .

It is possible that some sets of attributes are keys. If so, then following the word key(s) we may place several keys separated by commas. As usual, a key that comprises more than one attribute must have parentheses around the list of its attributes, so we can disambiguate a key of several attributes from several keys of one attribute each.

Example (b) :  As an example of a situation where it is suitable to have more than one key, consider a class Employee, whose complete set of attributes and relationships we shall not explain here. On the other hand, assume that two of its attributes are empID, the employee ID and ssNo, the Social Security number. Then we can declare each of these attributes to be a key by itself with

class Employee
    (extent Employees key empID, ssNo)
          . . .

Because there are no parentheses around the list of attributes, ODL interprets the above as saying that each of the two attributes is a key by itself. If we put parentheses around the list (empID,  ssNo) , then ODL would interpret the two attributes together as forming one key. That is, the implication of writing

class Employee
    (extent Employees key (empID, ssNo))
      . . .

is that no two employees could have both the same employee ID and the same Social Security number, although two employees might agree on one of these attributes.

The ODL standard also allows properties other than attributes to appear in keys. There is no basic problem with a method or relationship being declared a key or part of a key, since keys are consultative statements that the DBMS can take advantage of or not, as it wishes. For example, one could declare a method to be a key, meaning that on distinct objects of the class the method is guaranteed to return distinct values.

When we allow many-one relationships to appear in key declarations, we can get an effect similar to that of weak entity sets in the E/R model. We can declare that the object O1 referred to by an object O2 on the "many" side of the relationship, perhaps together with other properties of O2 that are contained in the key, is unique for different objects O2. Therefore, we should remember that there is no requirement that classes have keys; we are never obliged to handle, in some special way, classes that lack attributes of their own to form a key, as we did for weak entity sets.

Example (c) :  Let us review the example of a weak entity set Crews in "Weak Entity Sets" Figure (a). Remember that we hypothesized that crews were identified by their number, and the studio for which they worked, while two studios might have crews with the same number. We might declare the class Crew as in following Figure (a). Note that we need to amend the declaration of Studio to contain the relationship crews0f that is an opposite to the relationship unit0f in Crew; we omit this change.

A ODL declaration for crews

What this key declaration declares is that there cannot be two crews that both have the same value for the number attribute and are related to the same studio by unit0f. Notice how this declaration looks like the implication of the E/R diagram in "Weak Entity Sets" Figure (a), which is that the number of a crew and the name of the related studio (i.e., the key for studios) distinctively determine a crew entity.



Tags