Transcript Database Design using UML

ODB Design: Handling Associations and
Inheritance in ODL
M. Akhtar Ali
School of CEIS
1
Lecture outline








Different ways of representing links between objects
Multiplicity of Associations in UML
Types of Associations in UML
Mapping Associations in ODL
Modelling with inheritance
Different kinds of inheritance
Handling inheritance in ODL
Summarizing OODB Design
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
2
Different ways of representing links

Single valued attribute
A

Single reference

Collection valued attribute

Collection of references
B
A
B
A
B1, B2, … Bn
A
B1
B2
Bn
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
3
Multiplicity of associations in UML




0..1 (to-one, optional)
1..1 (to-one, mandatory)
0..* (to-many, optional)
1..* (to-many, mandatory)
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
4
UNN-IS
COMPLETE
CLASS
DIAGRAM
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
5
Types of Associations: Bi-Directional




These are true relationships so they require automatic
referential integrity (in UML shown as lines without
arrows or symbols).
Since bi-directional, both participating classes (e.g., A
and B) know about each other.
Any changes to the
state (e.g., initialising
relationship) of an object of class A may affect the
state of some object(s) of class B and vice versa.
For example, when a Student object’s enrolledOn
relationship is initialised with a reference to a Course
object, that Course object’s students relationship will
be automatically updated to include that Student
object as one of the students enrolled on the course.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
6
Types of Associations: Aggregation

Aggregation represents a part-whole relationship
between two classes. Two kinds of Aggregation:

Weak or shared aggregation (shown by


Lets you model a part-whole relationship in which one object
owns another object, but yet other objects can own that object
as well. For example, several Person objects may share a
same Address object. However, if no Person or Department
object is associated with an Address object then that Address
object should be deleted.
Strong aggregation/composition (shown by

)
)
Lets you model the part-whole relationship where one object
exclusively owns another object. The life-time of the part
depends on the life-time of the whole object. For example, a
Person object owns a Passport object exclusively and whenever
a Person object is deleted any associated Passport objects are
also deleted.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
7
Bi-Directional Associations in ODL

Syntax diagram of relationship declaration in ODL
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
8
Bi-Directional Associations in ODL …

Implementing the to-one (1..1) relationship from
Student to Course class.
relationship Course enrolledOn
inverse Course::students;
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
9
Bi-Directional Associations in ODL …

Implementing the to-many (0..*) relationship from
Course to Student class.
relationship set<Student> students
inverse Student::enrolledOn;
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
10
Aggregation in ODL

Week Aggregation (part-whole relationship)





Maps onto an attribute in the aggregating class.
Single valued (if 0..1 or 1..1).
Collection valued (if 0..* or 1..*).
For example, a Course is a whole object made up of several
Module objects.
The modules aggregation in the Course class is defined as
follows:
attribute set<Module> modules;

The application need to maintain the integrity of modules
attribute and to make sure that the set must contain at least
one reference to a module object.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
11
Aggregation in ODL …

Strong Aggregation (part-whole relationship)






Maps onto an attribute in the aggregating class.
Single valued (if 0..1 or 1..1).
Collection valued (if 0..* or 1..*).
The aggregated class becomes a structured literal if it does not participate
in any association with another class. Otherwise, it becomes a self-standing
class.
For example, a Person object owns at least one or more Passport objects.
The aggregated class: Passport becomes a structure:
struct Passport {
string passportNum;
string nationality;
date issueDate;
date expiryDate; };

The passports aggregation in the Person class is defined as follows:
attribute set<Passport> passports;

There is no automatic referential integrity for the passports attribute.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
12
Association Classes

When the association is one-to-one



The association can be implemented as bi- or uni-directional
depending on the situation.
Add the attributes of the Association class to the participating class
whose objects are more likely to get involved in the relationship.
For example, suppose that every department has a chair who is one
of the lecturer’s in the department.
attribute Lecturer hasChair;
attribute date startDate;

It would be better to define the association as an attribute (unidirectional relationship) in Department including startDate as only
few lecturer will ever participate in the relationship.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
13
Association Classes …

When the association is one-to-many



The association can be implemented as bi- or uni-directional
depending on the situation though preferably bi-directional.
Add the attributes of the Association class to the participating
class on the to-many side.
For example, part-time lecturers works for a department for
certain hours.
class PartTimeLecturer {
...
relationship Department worksFor
inverse Department::partTimeStaff;
attribute unsigned short hours; };

It is better to use bi-directional relationship for the above.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
14
Association Classes …

When the association is many-to-many



The association class becomes a self-standing ODL class
with bi-directional relationships to both participating classes.
The attributes of the association class becomes attribute of
the ODL class representing it.
For example, the many-to-many association between Student
and Module (having the association class) becomes:
class StudentModule (extent AllStudentMoudles) {
attribute
unsigned short marks;
relationship
Student
ofStudent
inverse Student::takes;
relationship
Module
forModule
inverse Module::takenBy; };
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
15
Association Classes …

When the association is many-to-many …

The Student class will include to-many relationship with
StudentModule class:
relationship
list<StudentModule> takes
inverse
StudentModule::ofStudent;
 list is used to keep track of the order in which modules
were taken.

The Module class will include to-many relationship with
StudentModule class:
relationship
inverse
set<StudentModule> takenBy
StudentModule::forModule;
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
16
Association Classes …

But in some situations you may implement many-tomany Association classes differently.



That is you may embed the association class inside one of the
participating classes if navigation from both sides is not
desirable/required.
For example:
In the above case the association class can be embedded inside the
Invoice class if it is not necessary for products to have information
about invoices on which they appear.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
17
Association Classes …
struct ItemType {
unsigned short units;
Product item;
};
class Invoice (...) {
... // attributes etc
attribute set<ItemType> items;
};
class Product (...) {
... // attributes etc, no need to define attribute
// of type Invoice or ItemType or relationship
// with Invoice class.
};

Invoice objects will not be dependent upon Product objects or will
not require joins or navigation to obtain information about items.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
18
Modelling with Inheritance

Inheritance is usually termed as specialization/generalization
relationship among super-classes and sub-classes.




Generalization relationship specifies that a
generalizes the properties of several sub-classes.



Super-class: An entity type or class that includes one or more
distinct sub-groupings of its instances.
Sub-class: A distinct sub-grouping of instances of an entity type or
class.
Each instance of a sub-class is also an instance of the super-class.
super-class
The Super-class contains the properties and behaviour that the subclasses share.
All Sub-classes inherit the properties and behaviour of the superclass.
Specialization relationship specifies that several sub-classes are
in some way specialized form of the super-class.

A Sub-class may include properties not present in the super-class or
other sub-classes thereby making it distinguished.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
19
Specialization Process

The process of maximizing the differences between
members of an entity by identifying their distinguishing
characteristics.




It is a top-down approach to defining a set of super-classes
and their sub-classes.
Once super-classes and sub-classes are identified, attributes
and operations specific to sub-classes and their relationships
with other classes are then identified.
For example, having defined Person class, we then define
Lecturer and Student classes to be sub-classes of Person
class.
Given the Student class, there are differences between
under-graduate and post-graduate students e.g., undergraduate have personal tutors but post-graduates don’t. Also,
post-graduate write dissertation where as under-graduate
don’t.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
20
Generalization Process

The process of minimizing the differences between
members of an entity by identifying their common
characteristics.




It is a bottom-up approach which results in the identification
of a generalized super-class from the original entity types.
We try to identify similarities among the original entity types
e.g., common attributes, relationships, and operations.
For example, full-time lecturers may be module tutor and
supervise post-graduate’s dissertations, whereas part-time
lecturer only teach on certain modules and work for a
department for certain hours. This leads to a generalized
Lecturer as super-class
of more specialized classes
FullTimeLecturer and PartTimeLecturer as its sub-classes.
Generalization can be seen as reverse of specialization. In
practice, both processes are used to complement each other.
That’s we refer to them as specialization/generalization.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
21
Different kinds of inheritance

Single verses Multiple Inheritance



Inheritance of Behaviour



In Single inheritance, a sub-class has only one super-class.
In Multiple inheritance, a sub-class has more than one super-class.
A sub-class inherits only the behaviour (operations) of a superclass. The super-class in this case usually only defines operations
i.e., an interface. For example, defining a common interface for
students and lecturers.
It is also known as is-a or is-a-kind relationship.
Inheritance of State

When a sub-class extends a super-class by adding attributes,
operations or relationships and both of them are concrete classes.
The sub-class inherits every thing defined in the super-class. For
example, Lecturer and Student classes inherit all the attributes and
operations of Person class.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
22
Interface verses Class

An interface is a classifier that represents an abstract
collection of operations.
<<i nterf ace>>

Although Person class is superclass of Student and Lecturer, yet
it would be useful to define a
common interface.
Given the Identification interface,
we can have several classes that
would realize the same interface.


Ide ntification
get Age(): int eger
c hangeAddres s(addr:
Addres s)
get Birt hD at e(): dat e
get Nam e(): s tring
get Gender(): st ring
get Address es ():
s et (Addres s)
A class may have one or more interfaces, and an
interfaces can group operations of several different
classes.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
23
Example Class Diagram for UNN-IS
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
24
Handling inheritance in ODL

The inheritance of behaviour is represented by “:”

For example:
class Person : Identification {...};


Defines that Person class inherits all the operations defined in the
Identification interface. The object type after the : must be an
interface.
The inheritance of state is represented by “extends”

For example:
class Student extends Person {...};


Defines that Student class inherits all the operations, relationships
and attributes defined in the Person class.
A class extends another class, an interface may inherit from
another interface but not from a class.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
25
Implementing Inheritance in UNN-IS
interface Identification {
short getAge();
void changeAddress(in
Address addr);
date getBirthDate();
string getName();
string getGender();
set<Address> getAddresses();
};
class Person : Identification
{...};
class Student extends Person
{...};
class Lecturer extends Person
{...};
class UGStudent extends
Student {...};
class PGStudent extends
Student {...};
class FullTimeLecturer
extends Lecturer {...};
class PartTimeLecturer
extends Lecturer {...};
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
26
Summarizing OODB Design: Classes






Each UML class becomes an ODL class.
Each attribute or method in a UML class becomes an
attribute or operation of an ODL class with appropriate
types.
Specify a suitable extent name unless the class
diagram explicitly indicates otherwise.
Specify a unique key if one or more attributes of a
UML class are shown in bold or tagged with {PK}.
For a composite attribute, specify a structure literal
type.
Specify a suitable positive integer type (i.e.
unsigned short or unsigned long) if an attribute
/ operation of a UML class has type int {+} or integer
{+}.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
27
Summarizing OODB Design: Associations

Bi-Directional Associations


Define relationships in both classes with appropriate types
and inverses.
Aggregations


Week: Define a single or collection valued attribute of an
appropriate type in the aggregating class.
Strong: Define the aggregated class as and define a single or
collection valued attribute of the struct type in the
aggregating class.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
28
Summarizing OODB Design: Associations…

Association Classes



One-to-one: Define a single or collection valued attribute and
include the attributes of the association class in one of the
participating classes.
One-to-many: Define a bi-directional relationship in both
classes and include attributes of the association class in the
class on the to-many side.
Many-to-many: Define a new class for the association class
including all of its attributes. Define bi-directional
relationships between the new class and the participating
classes with appropriate types and inverses. In certain cases
(e.g. when navigation from classes at both ends of the
association is not required) it be desirable to embed the
association class in one of the classes that participate in the
association. See an example of this scenario near the end of
week 11 lecture.
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
29
Summarizing OODB Design: Inheritance

Single Inheritance
interface A {...};
class B {...};
class C : A {...};
interface D : A {...};

Multiple Inheritance
class E : D extends B {...};

Inheritance of Behaviour
class C : A {...};

Inheritance of State
class F extends E {...};
Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases
30