From ODL Designs to Relational Designs

From ODL Designs to Relational Designs

As the E/R model is meant to be converted into a model such as the relational model when we put into operation the design as an actual database, ODL was initially meant to be used as the specification language for real, object-oriented DBMS's. Nevertheless ODL, like all object-oriented design systems, can also be used for beginning design and converted to relations prior to implementation. In this section we shall study how to convert ODL designs into relational designs. The process is analogous in many ways to what we introduced in "From E/R Diagrams to Relational Designs" for converting E/R diagrams to relational database schemas. However some new problems occur for ODL, including:
1. Entity sets must have keys, but there is no such guarantee for ODL classes. Therefore, in some situations we must invent a new attribute to serve as a key when we construct a relation for the class.

2. As we have required E/R attributes and relational attributes to be atomic, there is no such restriction for ODL attributes. The conversion of attributes that have collection types to relations is tricky and ad-hoc, frequently resulting in unnormalized relations that must be redesigned by the techniques of "Design of Relational Database Schemas / Anomalies".

3. ODL permits us to specify methods as part of a design, but there is no easy way to convert methods directly into a relational schema. We shall visit the issue of methods in relational schemas in "From ODL Designs to Object-Relational Designs" and again in "Object-Orientation in Query Languages" covering the SQL-99 standard. For now, let us suppose that any ODL design we wish to convert into a relational design does not include methods.

From ODL Attributes to Relational Attributes

As a first point, let us suppose that our objective is to have one relation for each class and for that relation to have one attribute for each property. We shall see many ways in which this approach must be modified, but for the moment, let us examine the simplest possible case, where we can really convert classes to relations and properties to attributes. The limitations we suppose are:

1. All properties of the class are attributes (not relationships or methods).

2. The types of the attributes are atomic (not structures or sets)

Example : The following Figure (a) is an example of such a class. There are four attributes and no other properties. These attributes each have an atomic type; title is a string, year and length are integers, and filmType is an enumeration of two values.

Attributes of the class Movie

We create a relation with the same name as the extent of the class, Movies in this case. The relation has four attributes, one for each attribute of the class. The names of the relational attributes can be the same as the names of the corresponding class attributes. Therefore, the schema for this relation is

Movies(title, year, length, filmType)

For each object in the extent Movies, there is one tuple in the relation Movies. This tuple has a component for each of the four attributes, and the value of each component is the same as the value of the corresponding attribute of the object.