1. Mary Norwood & Oberon Ilano
Chapter 4: High-Level Database Models Unified Modeling Language UML Diagrams to Relations Object Definition Language ODL Designs to Relational Designs
Mary Norwood & Oberon Ilano

2. UML Topics UML Classes Keys for UML classes Associations
Self-Associations
Association Classes
Subclasses in UML
Aggregations and Compositions
UML-to-Relations Basics
From UML Subclasses to Relation
From Aggregations and Compositions to Relations
The UML Analog of Weak Entity Sets

3. What is UML(Unified Modeling Language)?
UML was first used as a graphical representation for describing software designs in an object- oriented style.
UML was modified and extended to be a popular representation for describing database designs.
It has the same abilities as the Entity/Relationship model, except for multiway relationships.
It offers the ability to treat entity sets as true classes, with methods as well as data.

4. Comparison between UML and E/R terminology
These are the shared concepts, with different terms.
E/R Model
Entity set
Binary relationship
Attributes on a relationship
Isa hierarchy
Many-one relationship
Many-one relationship with referential integrity
UML
Class
Association
Association Class
Subclass
Aggregation
Composition

5. UML Classes Object-Oriented Class Name Attribute(s) Method(s)
Note: Neither the E/R model nor the relational model provides methods.

6. Keys for UML classes
To declare a key for an UML class, we just put the key by the letters PK, (primary key) after the attributes.
There is no appropriate way to specify that several attributes or sets of attributes are each key.

7. Associations
Association is a set of pair of objects, one from each of the classes it connects.
A multiway relationship must be broken into binary relationships because there is no equivalent of multiway relationships in UML.
Every association has constraints on the number of objects from each of its classes that can be linked to an object of the other class.
They are labeled by form m…n at each end to indicate the constraints. The meaning of this label is that each object at the other end is connected to at least m and at most n objects.

8. Association Example
UML association between two classes is implied by drawing a line between them and giving the line a name.
An * in place of n, as in m..*, stands for “infinity” which means there is no upper limit.
An * alone, in place of m…n, stands for the range 0..* which means no constraint at all on the number of objects.
A label that is taken to be 1..1 is “exactly one.”

9. Example mirroring the E/R diagram
Each department is required to have at least one technician. There is still no upper limit on how many technicians a department can have.
A technician must be working for exactly one department.

10. Another Example A manager must be managing exactly one department.
Manage by
A manager must be managing exactly one department.
A department can have at the most one manager or no manager at some point.

11. Self-Associations
An association can have both ends at the same class. It is given two names, one for each end.
For a movie to be a sequel, there must be exactly one movie that is original.
The original can have any number of sequels.
Note: A sequel is a sequel of the original, not of the previous movie in the sequence.

12. More Self-Associations Examples
ApartmentResident
Renter

13. Association Classes
In UML, an association class is part of an association relationship between two other classes. It is identical to other classes and can contain name, operations, and attributes.
For this example, the information is not associated with the employee nor with the department because different employee get different salaries/benefits and the employee can get different salaries/benefits for different department.

14. Subclasses in UML
UML allows a class C to have four different kinds of subclasses (Complete, Partial or Incomplete, Disjoint, and Overlapping) depending on our choices of the answer to the two questions.
Is every object in class C a member of some subclass? If so, the subclasses are complete; otherwise they are incomplete (partial).
Are the subclasses disjoint (an object cannot be in two of the subclasses)? If an object can be in two or more of the subclasses, then the subclasses are said to be overlapping.

15. Incomplete, Disjoint Example

16. Complete, Overlapping Example
Note: The decisions are taken at each level of a hierarchy and may be made independently at each point.

17. Aggregations
An aggregation is a special type of association that models a whole- part relationship between aggregate and its parts.
It is implied by a line between two classes, that ends in an open diamond at one end.
The indication of the open diamond is that the label at that end must be 0..1.
It does not need to be named because it will never be used in a relational implementation.
Ex: Automobile is the Parent Class and Car is the Child Class. If Automobile Class is deleted, the Car Class will still exist.

18. Compositions
A composition is a special type of aggregation which denotes strong ownership between two classes when one class is a part of another class.
The label at the diamond end must be 1..1 which means the opposite end from the diamond must be connected to exactly one object at the diamond’s end.
Compositions are distinguished by making the diamond solid black.
Ex: House Class is the Parent Class and Room is the Child Class. Rooms will never separate into a House.

19. Aggregation & Composition Example
There is an aggregation from Technician to Department that is 0.. 1, implied by an open diamond which means that at least one Technician works for 1 or less Department.
There is a composition from Manager to Department that is 1.. 1, implied by the solid diamond which means that every manager manage exactly one department.
The implication of the composition is that Manager objects will contain a reference to a Department object and that this reference cannot be null.
Manage by

20. UML-to-Relations Basics
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.
Technician(name, id, hours, gender)
Project(name, location, number)
Department(location, name)

21. Association-to-Relations Basics
For each association, create a relation with the name of that association. The attributes of the relation are the key attributes of the two connected classes.
If there is a coincidence of attributes between the two classes, rename them appropriately.
Works-on(techName, technID, projectName)
Works-for(techName, techID, deptLocation)
Note: The names of attributes can be changed for clarity of intention, but it is not required.

22. Association Class-to-Relations Basics
If there is an association class attached to the association, include the attributes of the association class among the attributes of the relation
Works-for(employeeName, employeeID, deptLocation, salary, benefits)
Note: There is no relation made for Earnings itself.

23. From UML Subclasses to Relation
The three options were used in Section 4.6 is also applies to UML subclass hierarchies.
If we have information about whether subclasses are disjoint or overlapping, and complete or partial, then we may find one or another method more appropriate.
If a hierarchy is disjoint at every level, then an object-oriented representation is suggested to consider every possible tree of subclasses when creating relations
Each object can belong to only one class and its ancestors in the hierarchy.
There is no possibility of number of relations being created.
If the hierarchy is both complete and disjoint at every level, then the task is even simpler. If we use the object-oriented method, then we have only to construct relations for the classes at the leaves of the hierarchy.
If the hierarchy is large and overlapping at some or all levels, then the E/R approach is indicated and likely to need so many relations that the relational database schema becomes to be difficult to carry.

24. From Aggregations and Compositions to Relations
It suggests that aggregations and compositions be treated normally in this way.
Construct no relation for the aggregation or composition.
Add to the relation for the class at the nondiamond end the key attribute(s) of the class at the diamond end.
In the case of an aggregation (but not a composition), it is possible that these attributes can be null.

25. Example
The aggregation from Technician to Department is represented by putting the key location for Department among the attributes for the relation Technician.
The composition from Manager to Department is represented by adding the key for Department to the relation Manager as well.
Relation:
Management(lengthOfexperience, address, phone)
Manager(lengthOfExperience, location)
Department(location, name)
Technician(name, id, hours, genre, deptLocation)
Manage by
Note: We can change the names of attributes to make our intentions clear.

26. The UML Analog of Weak Entity Sets
In UML, to use a composition is like supporting relationships for weak entity sets in the E/R model.
A small box attached to the weak class with “PK” and will serve as the anchor for the supporting composition.
The implication is that the key attribute(s) for the supporting class at the other end of the composition is part of the key of the weak class, along with any of the attributes of the weak class that are marked “PK.”
There can be several supporting compositions and classes, and those supporting classes could themselves be weak, in which case the rule just described is applied recursively.

27. Example
A Weak class Crews supported by a composition and the class Studios.
Studios(name, address)
Crews(number, crewChief, studioName)

28. UML Diagram Example

29. Object Definition Language

30. ODL Topics Object Definition Language From ODL Classes to Relations
Class Declarations
Attributes in ODL
Relationships in ODL
Inverse Relationships
Multiplicity of Relationships
Types in ODL
Subclasses in ODL
Declaring Keys in ODL
From ODL Classes to Relations
Complex Attributes in Classes
Representing Set-Valued Attribute
Representing Other Type Constructors
Representing ODL Relationships

31. What is OBL (Object Definition Language)?
Like UML, ODL – Object Definition Language – is a language that takes an object - oriented approach to defining database structures.
ODL uses classes. Each class in ODL has a name and can contain attributes, relationships, and methods.

32. 4.9.1 Class Declarations The syntax for declaring a class in ODL:
class <name> {
<list of properties> };
This looks really similar to C++.
In ODL, every line ends with a semicolon just like in C++.
A property can be an attribute, a relationship, or a method.

33. 4.9.2 Attributes in ODL 1) class Cars { 2) attribute string make;
3) attribute string model;
4) attribute integer year;
5) attribute integer miles; };
The attribute is the simplest kind of property.
An attribute is named with the keyword attribute, the type of the attribute, and the name of the attribute.
In line (2), the type of the attribute is string and the name of the attribute is make.

34. 4.9.2 Attributes in ODL
If we want to specify that the make can only be an element from the set {BMW, Chevy, Ford, Honda, Tesla, Toyota} then we can use the type enumeration. An enumeration is “a list of symbolic constants.”
1) class Cars {
2) attribute enum Makes
3) {BMW, Chevy, Ford, Honda, Tesla, Toyota} make;
4) attribute string model;
5) attribute integer year;
6) attribute integer miles;
7) };
Instead of writing string we write enum Makes {BMW, Chevy, Ford, Honda, Tesla, Toyota}
Makes is the name of the enumeration. We name the enumeration so that later we can just say its name if we want to use the same type again.

35. 4.9.2 Attributes in ODL
Here is what the book says in the box on page 185:
“Why Name Enumerations and Structures?
“The enumeration-name Genres in Fig 4.44 appears to play no role. However, by giving this set of symbolic constants a name, we can refer to it elsewhere, including in the declaration of other classes. In some other class, the scoped name Movie::Genres can be used to refer to the definition of the enumerated type of this name within the class Movie.”

36. 4.9.2 Attributes in ODL
For example, we could have the attributes interiorColor and exteriorColor in the Cars class:
1) class Cars {
2) attribute enum Makes
3) {BMW, Chevy, Ford, Honda, Tesla, Toyota} make;
4) attribute string model;
5) attribute integer year;
6) attribute integer miles;
7) attribute enum Colors
8) {Red, Orange, Yellow, Green, Blue, Indigo, Violet} interiorColor;
9) attribute Colors exteriorColor;
10) };
The second time we use the enumerated type Colors, we do not have to define its set of possible values.

37. 4.9.2 Attributes in ODL Attribute Types:
ODL has two types, primitive types and complex types. The primitive types are: integer, float, character, character string, boolean, and enumerations. A complex type is made up of primitive types. A struct is an example of a complex type. Here is an example similar to the book:
1) class Driver {
2) attribute string name;
3) attribute Struct Addr;
4) {int number, string street, string city, string state, int zip} address;
5) };
The address attribute is a record structure.
“In general, one can define record structure types in ODL by the keyword Struct and curly braces around the list of field names and their types.”

38. 4.9.3 Relationships in ODL
“An ODL relationship is declared inside a class declaration, by the keyword relationship, a type, and the name of the relationship.”
A driver must own a car. Let’s say that a driver can own multiple cars.
Using only the relational database tools we had in the beginning, we might have issues with redundancy by listing the same driver information over and over again for each car. What we really want to do is say that each driver has a set of cars, and that set can contain many or few cars - we don’t know the exact number of cars each driver has. ODL helps us represent that.

39. 4.9.4 Inverse Relationships
Let’s say we have a class called Teams and a class called Players.
class Teams {
attribute string name;
attribute Set<Players> players; };
class Players {
attribute Set<Teams> teams;
If Joe is in the set of players for Alabama, then Alabama is in the set of teams for Joe.
If Alabama is in the set of teams for Joe, then Joe is in the set of players for Alabama.

40. 4.9.5 Multiplicity of Relationships
A pair of inverse relationships on ODL can be classified as either many-many, many-one in either direction, or one-one.
If we have a many-many relationship between classes C and D, then in class C the type of relationship is Set<D>, and in class D the type is Set<C>.
If the relationship is many-one from C to D, then the type of the relationship in C is just D, while the type of the relationship in D is Set<C>.
If the relationship is many-one from D to C, then the roles of C and D are reversed in (2) above.
If the relationship is one-one, then the type of the relationship in C is just D, and in D it is just C.

41. 4.9.6 Types in ODL
A type system is built from a basis of types that are defined by themselves. In ODL, the basis consists of:
Primitive types: integer, float, character, character string, boolean, and enumerations. The latter are lists of symbolic names, such as drama in line (5) of Fig
Class names, such as Movie, or Star, which represent types that are actually structures, with components for each of the attributes and relationships of that class.

42. 4.9.6 Types in ODL
The types are combined into structures with the following type constructors:
Set – Set<T> is a type which is a set of finite elements of type T.
Bag – Bag<T> is a type which is a bag of finite elements of type T.
List – List<T> is a type which is a list of finite elements of type T.
Array – Array<T, i> is a type which is an array of i elements of type T.
Dictionary – Dictionary<T,S> is a type which is a set of finite pairs where each pair consists of key type T and range type S.
Structures – Struct N <T1 F1, T2 F2, . . ., Tn Fn) is a type named N which is a structure of n fields. The T’s are types and the F’s are names of its fields.

43. 4.9.6 Types in ODL
Here is the books explanation on Sets, Bags, and Lists:
“To understand the distinction between sets, bags, and lists, remember that a set has unordered elements, and only one occurrence of each element. A bag allows more than one occurrence of an element, but the elements and their occurrences are unordered. A list allows more than one occurrence of an element, but the occurrences are ordered. Thus, {1,2,1} and {2,1,1} are the same bag, but (1,2,1) and (2,1,1) are not the same list.”

44. 4.9.6 Types in ODL
Sets, bags, lists, arrays, and dictionaries are called collection types.
Collection types are helpful when we do not know the exact number of things we need, such as the not knowing how many cars each driver has.
Structures and primitive types are not collection types.

45. 4.9.6 Types in ODL Relationship types cannot involve structures.
Relationship types cannot involve primitive types.
Relationship types cannot involve two applications of collection types

46. 4.9.8 Declaring Keys in ODL
It is not necessary to declare a key in ODL because it assumes all objects have an object-identity.
We can declare a key using the keyword key or keys and placing the key inside parentheses.
class Movie (key (title, year)) {
<list of properties> };

47. 4.9.7 Subclasses in ODL
If we want to take an existing class and use that as a basis for another class with some additional properties, we can make a new class a subclass of the existing class using the word extends. class Parent { attribute string lastname; attribute Cars::Color eyecolor; }; class Child extends Parent { attribute Cars::Color haircolor;

48. 4.10.1 From ODL Classes to Relations
The restrictions we assume are:
All properties of the class are attributes (not relationships or methods).
The types of the attributes are primitive (not structures or sets).
1) class Cars {
2) attribute string make;
3) attribute string model;
4) attribute integer year;
5) attribute integer miles; };
Relation: Cars(make, model, year, miles)

49. 4.10.2 Complex Attributes in Classes
Since we have to use primitive types, to break down a structure, use each field of the structure as an attribute for the relation.
1) class Driver {
2) attribute string name;
3) attribute Struct Addr;
4) {int number, string street, string city, string state, int zip} address; };
Relation: Driver (name, number, street, city, state, zip)

50. 4.10.3 Representing Set-Valued Attribute
Values can also be built using type constructors Set, Bag, List, Array, and Dictionary from Section
Each presents its own problems (ex: anomalies) when migrating to the relational model.
There are several options regarding how to handle set-valued attributes that appear in a class declaration along with other attributes, set-valued or not. BCNF and 4NF are included to this option.

51. 4.10.4 Representing Other Type Constructors
To place a restriction on a collection type we can add an attribute to the relation schema.
To place a limit on the number of elements that can be repeated in a bag, we add to the relation schema another attribute called count which is the number of times each element is in the bag.
If we want something to appear multiple times in a relation, it is technically possible but not recommended to add n identical tuples into the relation. It is better to use add one attribute for the count.

52. 4.10.5 Representing ODL Relationships
“In ODL, relationships come in inverse pairs, and we must create only one relation for each pair.
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.
It therefore does not cause a BCNF violation and is a legitimate and commonly followed option.”

53. Sources
“UML, ODL.” Database Systems: the Complete Book, by Hector Garcia-Molina et al., 2nd ed., Pearson Prentice Hall, 2009, pp. 171–201.