Introduction

On Monday, we began talking about our second high level data model, UML, that might be suitable for prototyping data organization before creating relational schemas.
We said UML, the Uniform Modeling Language, was originally developed (Booch, Jacobson, Rumbaugh at Rational Software 1995-1997) as a graphical notation for describing software designs in an object oriented style.
We gave a list of correspondences between how things are called in an E/R diagram versus a UML Diagram.
Then we said how classes, the concept equivalent to a entity set in the E/R model, are represented in UML (figure above).
We begin today by continuing our discussion of UML...

UML Associations

In UML, a binary relationship between classes is called an association.
There is no UML equivalent for the E/R concept of a multiway relation.
The figure above shows how to draw associations in UML - we use an edge between to classes.
Notice we label the edge with the name of the association and we label the end points of the edge with the degree constraints of the association.
In the figure above, we have two associations Owns and Stars-in.
The degree constraints on Owns indicate that at most 1 studio can own 0 or more (what the * means) movies.
If we don't label an endpoint it is assumed to mean 1..1.
If we write * alone as an endpoint, it is assumed to mean 0..*.

Self Associations

An association can have both ends at the same class.
In which case, it is called a self-association.
Rather than have a single label for the name of the association, in this case, we usually use two labels to describe the role of each instance of the class participating in the association.
So the above diagram, represents an association related to movie sequels.
Two instances of Movies participate in the association: TheOriginal Movies and TheSequel Movies.

Association Classes

In the E/R model, we allowed relationships to have attributes.
In UML we can add to association edge a class, called an association class, to contain the attributes of an association to convey similar information.
In the above, Compensation is an association class used to contain the salary and residual attributes of the StarsIn association.

Subclasses

In UML, subclasses are represented by rectangles in the same way as classes.
An edge with an open arrow is then used to indicate what class the subclass is a subclass of.
To simplify our diagrams we often join the edges of multiple subclasses of the same class into one before drawing the final connection arrow to the parent class.
So in the above figure, Murder-Mysteries, Cartoons, and Cartoon-Murder-Mysteries.
Each subclass will have all the properties (attributes and association) of the parent class, but additional properties can be indicated either in the subclasses rectangle or in association going from the subclasses rectangle.

Aggregation and Composition

An aggregation is a line between two classes that ends in an open diamond at one end.
The open diamond indicates that end of the relation has 0..1 as a constraint. I.e., the association is many-one.
In the above, a studio may have many movies. Any movie must have one studio.
A composition is a line between two classes that ends in an closed diamond at one end.
The closed diamond indicates that end of the relation has 1..1 as a constraint.
In the above, each studio must have a president. A president may or may not be a president of a studio.

UML to Relations

We now describe how a UML Diagram can be mapped to a relational schema:

Classes to Relations. For each class, create a relation whose name is the name of the class and whose attributes are the attributes of the class.
Associations to Relations. For each association create a relation with the name of the association. The attributes of this new class are the key attributes of the two connected classes. If there is a name collision, do an appropriate renaming. Then add any attributes, renaming as needed, of any association classes for this association.
Subclasses to Relations. Here we can use any of the techniques we used for mapping Isa relationships in the E/R setting. Perhaps the simplest is the Using Multiple Relations of the form Superclass and Subclass approach.
Aggregations and Compositions to Relations. We can use the same technique as the many-one mapping from the E/R diagram setting.

In-Class Exercise

Consider the diagrams on page 4, 6, 7, and 8.
For each one, give the relational schema that would result from our UML to relational mapping.
Post your solutions to the Oct 23 In-Class Exercise Thread.

Object Definition Language

ODL (Object Definition Language) is a text-based language for specifying the structure of databases in object-oriented terms.
Like UML, in ODL, there are classes which have a name, attributes, and methods.
The UML analog of associations are called relationships in ODL.
Relationship do not exist independent of classes, but are embedded in classes as an additional family of concepts.

Classes and Attributes in ODL

Classes in ODL are defined with a declaration of the form:
```
class <name> { 
  <list of properties>
};
```

The list of properties give the attributes for the class. Each has a type and a name. For example:

class Movie {
   attribute string title;
   attribute integer year;
   attribute integer length;
   attribute enum Genres {drama, comedy, 
      sciFi, teen} genre;
};

Notice the enumerated type is defined in a similar way to the C way of declaring enum's.

We can also use an analog of C-structs in declarations:

class Star {
   attribute string name;
   attribute Struct Addr {string street, 
       string city} address; 
};

If we want to elsewhere refer to the Addr used in the declaration of Star or the enum as used in the declaration of Movie, we can use Movie::Genre and Star::Addr respectively.

Relationships in ODL

Suppose we want to define a relationship between Star and Movie.

The way to do this is to add relationship properties to each of their declarations:

class Movie {
   attribute string title;
   attribute integer year;
   attribute integer length;
   attribute enum Genres {drama, comedy, 
      sciFi, teen} genre;
   relationship Set<Star> stars;
};

class Star {
   attribute string name;
   attribute Struct Addr {string street, 
       string city} address; 
   relationship Set<Movie> starredIn;
};

As given above the stars and starsIn relationships are not connected. To connect them, we use the inverse keyword. We would change the relationship statements above as follows:

   relationship Set<Star> stars;

becomes

   relationship Set<Star> stars
       inverse Star::starredIn;

and

   relationship Set<Movie> starredIn;

becomes

   relationship Set<Movie> starredIn
       inverse Movie::stars;

Using the keyword set indicates the relationship is many. So if both use set we have a many-many relationship.
If we just use the class name rather than the parameterized Set type, we can make one said a one relationship.

Types, Subclasses, and Keys in ODL

We have already seen that ODL supports enum's, Struct, and parameterized Set types.
It also supports parameterized Bag<T> (multiset), List<T> (order matters), Array<T, n> (fixed number of elements), and Dictionary<T, S> (key-value pairs).
One can say one class is a subclass of another in the same way as in Java, using the extends keyword:
```
class Cartoon extends Movie {
   relationship Set<Star> voices;
};
```
Keys in ODL are expressed after the name in a class definition:
```
class Movie (key (title, year)){ ...
```
The techniques to map ODL to relations are similar to those used for UML and E/R Diagrams.

Algebraic and Logical Query Languages

We now switch from data modeling to programming for relational databases.
We are going to consider two abstract database programming languages: one algebraic and the other logic-based.
The first will be a supped up version of the relational algebra we've considered earlier.
The second one will be called datalog.

Finish High Level Models, Algebraic and Logical Query Languages

Outline