Representing Other Type Constructors

Representing Other Type Constructors

Above and beyond record structures and sets, an ODL class definition could use Bag, List, Array, or Dictionary to construct values. To represent a bag (multiset), in which a single object can be a member of the bag n times, we cannot simply introduce into a relation n the same tuples. Rather, we could add to the relation schema another attribute count representing the number of times that each element is a member of the bag. For example, assume that address in "Representing Set-Valued Attributes" Figure (a), were a bag instead of a set.  We could say that 123 Maple St., Hollywood is Carrie Fisher's address twice and 5 Locust Ln., Malibu is her address 3 times (whatever that may mean) by



A list of addresses could be represented by a new attribute position, indicating the position in the list. For example, we could show Carrie Fisher's addresses as a list, with Hollywood first, by:



A fixed-length array of addresses could be represented by attributes for each position in the array. For example, if address were to be an array of two street-city structures, we could represent Star objects as:



Finally, a dictionary could be represented as a set, but with attributes for both the key-value and range-value components of the pairs that are members of the dictionary. For example, assume that instead of star's addresses, we really wanted to keep, for each star, a dictionary giving the mortgage holder for each of their homes. Then the dictionary would have address as the key value and bank name as the range value. A hypothetical rendering of the Carrie-Fisher object with a dictionary attribute is:



Certainly attribute types in ODL may engage more than one type constructor. If a type is any collection type besides dictionary applied to a structure (e.g., a set of structs), then we may apply the techniques from "Representing Set-Valued Attributes" or "Representing Other Type Constructors" as if the struct were an atomic value, and then replace the single attribute representing the  atomic value by many attributes, one for each field of the struct. This strategy was used in the examples above, where the address is a struct.

There are various reasons to limit the complexity of attribute types to an optional struct followed by an optional collection type. We mentioned in "Elements of the E/R Model" (Entity Sets) that some versions of the E/R model permit exactly this much generality in the types of attributes, although we restricted ourselves to atomic attributes in the E/R model. We suggest that, if you are going to use an ODL design for the purpose of eventual translation to a relational database schema, you similarly limit yourself.


Tags