Object-Oriented Database Systems
(OODBS)
25/2-2002
Contains slides made by
Arthur M. Keller, Vera Goebel
Overview
9 OO concepts and OODBS’ properties
object identity/object identifier (OID), objects &
values, extent (instances of class), complex objects, type
constructors, operators, types/classes, user-definable
types/classes, programming language compatibility
(seamlessness), encapsulation (information hiding),
type/class hierarchies, inheritance, polymorphism
9 ODL
classes, attributes, relationships, methods, type system,
extents, keys, inheritance
INF 212 – database theory
2002 Pål Halvorsen
1
Data Models & Database System Architectures
- Chronological Overview 9 Network Data Models
(1964)
9 Hierarchical Data Models
(1968)
9 Relational Data Models
(1970)
9 Object-oriented Data Models
(~ 1985)
9 Object-relational Data Models
(~ 1990)
9 Semistructured Data Models (XML 1.0) (~1998)
INF 212 – database theory
2002 Pål Halvorsen
Why Object-Oriented Database Systems?
concepts of
object-oriented systems
concepts of
traditional DBS
object-oriented
database systems
new (nonstandard)
requirements for DBS,
e.g.
complex objects,
arbitrary relationships,
complex data types,
version, ...
INF 212 – database theory
2002 Pål Halvorsen
2
OO concepts and OODBS’
properties
Object-Oriented Concepts (General)
9 Model mini-world (Universe of Discourse, UoD) as collection of
cooperating, related units, called objects
9 Abstraction and autonomy:
object: <value, {operators}>
value: data structure
encapsulation (information hiding)
request of performance from other objects
9 Classification:
common description (intension)
summary of similar objects (extension, class)
9 Taxonomy:
super-/sub-classes
inheritance of properties
polymorphism
INF 212 – database theory
2002 Pål Halvorsen
3
Task of the Data Model
UoD
database
data model
?
record oriented
data model
database
1:N
object oriented
data model
database
1:1
2002 Pål Halvorsen
INF 212 – database theory
Advantages of OO Data Modeling
UoD
object oriented
data model
database
1:1
9 “Naturalness” (compared to traditional data models)
¾ meaningful abstraction / high modularity
¾ control of complexity
¾ separation of interface and implementation
9 Evolutionary system design
¾ incremental programming
¾ reusability
INF 212 – database theory
2002 Pål Halvorsen
4
Object-Oriented Database Systems
OODBS
=
DBS
with
OO Data Model
9 OO Database = collection of objects
9 Object = <OID, value, {operators}>
9 An object has specific properties....
2002 Pål Halvorsen
INF 212 – database theory
OODBS and Object Values
Object = <OID, value, {operators}>
Value example:
class athlete {
text name;
integer salary;
}
V1 = tuple of (name: ”Solskjær”,
V2 = tuple of (name: ”Berg”,
V3 = tuple of (name: ”Dæhli”,
INF 212 – database theory
salary: 4.000.000)
salary: 1.000.000)
salary: 6.000.000)
O1 = < •, V1, •>
O2 = < •, V2, •>
O3 = < •, V3, •>
2002 Pål Halvorsen
5
OODBS and Object Operators
Object = <OID, value, {operators}>
9 Value operators:
¾ Processing of entire objects - depending on actual structure
¾ Modify values
9 Generic operators:
¾ Processing of individual object levels - structure irrelevant
9 One-level / multi-level operators (composite objects)
9 Also: selection, navigation, ....
2002 Pål Halvorsen
INF 212 – database theory
Properties of OODBS
Must have:
9 object identity
Should have:
9
object versions
9
complex (composite) objects
9
9
types/classes
specific realization (implementation)
of concepts
9
user-definable types
9
9
language completeness
distribution
(client/server architectures)
9
encapsulation
9
9
inheritance: type/class hierarchies
specific processing aspects,
e.g., new transaction mechanisms
9
polymorphisms:
overloading/overriding/late binding
9
rule-based mechanisms
(active/deductive features)
Ö
... all orthogonal.
INF 212 – database theory
... and many more
2002 Pål Halvorsen
6
Object Identifier (OID)
9 Objects exist independently of their (current) values
¾ Modifications of any kind result in “same” object
¾ No misleading references to objects
¾ “identity” =/= “equality” (both needs to be expressible)
9 OIDs cannot (reliably) be based on ordinary values
provided by application (value orientation)
... but on surrogates: OIDs are
¾
¾
¾
¾
(system-wide) unique
unchanged during object lifetime
not reused after object deletion
generally system-managed
INF 212 – database theory
“generic” object operators:
• object comparison
• object retrieval
• ...
based on OID
2002 Pål Halvorsen
Complex (Composite) Objects
Two types of complex objects:
9 Unstructured: long fields (BLOBs - binary large objects)
9 Structured:
INF 212 – database theory
2002 Pål Halvorsen
7
Types / Classes
9 Intension (common description of
similar objects)
Class
Op1 Op2
9 Creation of instances - instantiation
9 Extension (set of
actually existing instances)
instantiation
object_1
object_2
object_3
Op1, Op2
Op1, Op2
Op1, Op2
9 Users are allowed to
define their own types
2002 Pål Halvorsen
INF 212 – database theory
Encapsulation
Visible for user
of class
Hidden for user
of class
Definition of
operator interfaces
Definition of value type
(data structures for object state)
Implementation of
operator bodies
INF 212 – database theory
2002 Pål Halvorsen
8
Inheritance:
Type/Class Hierarchies
9 Object types not always independent of each other:
generalization/specification ⇒ subtypes/supertypes
9 Instances of subtypes INHERIT properties from
supertypes
9 Forms: simple inheritance (type hierarchy),
multiple inheritance (type lattice)
9 Advantages of the inheritance principle:
¾ code reusability (when operators are inherited)
¾ representation of additional semantics
¾ design discipline (stepwise refinement)
2002 Pål Halvorsen
INF 212 – database theory
Polymorphism:
Overloading, Overriding, Late Binding
9 Overloading:
use of same name for different operators (in different types)
9 Overriding:
reimplementation of operator bodies on lower level of type hierarchy
9 Late binding:
bind an operator name to an associated implementation later, i.e.,
made individually for each object at run-time
print_geometric_object (o: g_obj)
(implemented for circles, rectangles, triangles etc)
for all x do print_geometric_object(x);
vs.
for all x do case
INF 212 – database theory
x is circle:
x is rectangle:
x is triangle:
otherwise
print_circle(x);
print_rectangle(x);
print_triangle(x);
exception handling);
2002 Pål Halvorsen
9
Object Description Language
(ODL)
Object-Oriented DBMS Standardization
9 ODMG:
Object Data Management Group an OO standard for databases.
9 ODL:
Object Description Language design in the OO style.
9 OQL:
Object Query Language queries an OO database with an ODL
schema, in a manner similar to SQL.
INF 212 – database theory
2002 Pål Halvorsen
10
ODL Class Declarations
9 Class declarations include:
¾ Name.
¾ Key declaration(s), which are optional.
¾ Extent declaration: name for the set of currently
existing objects of a class.
¾ Element declaration(s): an element is
an attribute, a relationship, or a method.
9 Syntax:
class <name> {
<elements = attributes, relationships, methods>
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Element Declarations:
Attributes - I
9 Attributes:
involve non-object values,
e.g., integers, strings
9 Syntax:
attribute <type> <name>;
9 Example:
name
addr
Bars
INF 212 – database theory
license
class Bars {
attribute string name;
attribute Struct addr {
string street,
string city
} address;
attribute Enum lic {
full, beer, none
} licenseType;
}
2002 Pål Halvorsen
11
ODL Element Declarations:
Attributes - II
9 Structured types have names and bracketed lists of field-type pairs.
attribute Struct addr {string street, string city} address;
9 Enumerated types have names and bracketed lists of values
attribute Enum lic {full, beer, none} licenseType;
9 Why name structures and enumerations?
name
addr
Bars
license
name
Frequents
addr
Drinkers
class Drinkers {
attribute string name;
attribute Struct Bars::addr address;
}
NOTE 1:
Reuse of the
Struct addr
attribute in the
class Bars
NOTE 2:
Elements from
another class is
indicated by
<class>::<name>
2002 Pål Halvorsen
INF 212 – database theory
ODL Element Declarations:
Relationships - I
9 Relationships involve objects, is a reference
9 Syntax:
relationship <type> <name>;
9 Examples:
¾
relationship Set<Person> hasKids;
¾
relationship Person hasWife;
¾
relationship Set<Car> ownCars;
INF 212 – database theory
2002 Pål Halvorsen
12
ODL Element Declarations:
Relationships - II
9 Relationships come in inverse pairs:
Serves between beers and bars is represented by a
relationship in bars, giving the beers sold, and a
relationship in beers giving the bars that sell it.
Bars
Serves
Beers
class Bars {
relationship Set<Beers> serves inverse Beers::servedAt;
}
class Beers {
relationship Set<Bars> servedAt inverse Bars::serves;
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Element Declarations:
Relationships - III
Bars
9 Only binary relations supported:
Multiway relationships require
a “connecting” class
NOTE 1:
Inverses for theBar, theBeer
must be added to Bars, Beers
TheBar
price
Prices
Serves
Beers
BBP
TheBeer
ThePrice
class Prices {
Bars
Beers
Price
attribute real price;
relationship Set<BBP> toBBP inverse BBP::thePrice;
}
class BBP { /*beers-bars-prices*/
NOTE 2:
relationship Bars theBar inverse ...
might in this case use only
relationship Beers theBeer inverse ... attribute price
relationship
Prices
thePrice inverse Prices::toBBP;
attribute
float
price;
}
INF 212 – database theory
2002 Pål Halvorsen
13
ODL Element Declarations:
Relationships - IV
9 Many-many relationships have a set type in each
direction.
Bars
Serves
Beers
class Bars {
relationship Set<Beers> serves inverse Beers::servedAt;
}
class Beers {
relationship Set<Bars> servedAt inverse Bars::serves;
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Element Declarations:
Relationships - V
9 Many-one relationships have a set type for the one, and
a simple class name for the many.
Manufacturer
made
by
Beers
class Manufacturer {
relationship Set<Beers> produceBeers inverse ...;
}
class Beers {
relationship Manufacturer producedBy inverse ...;
}
INF 212 – database theory
2002 Pål Halvorsen
14
ODL Element Declarations:
Relationships - VI
9 One-one relations have simple class names for both.
Manufacturer
Bestseller
Beers
class Manufacturer {
relationship Beers isBestSellingBeer inverse ...;
}
class Beers {
relationship Manufacturer hasBestSellingBeer inverse ...;
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Element Declarations:
Methods
9 A piece of executable code which may be applied to the
objects of the class
9 Parameters: in, out, and inout. The object itself is a
“hidden” parameter
9 The method itself may have return values
9 May raise exceptions
9 Only signatures are defined in ODL classes; the code is
written in a host language – not part of ODL
9 Example:
class Bars {
....
void availableBeers(out Set<Beers>);
}
INF 212 – database theory
2002 Pål Halvorsen
15
ODL Type System
9 Basic types:
integer, real, float, character, string,
enumerated types, boolean, etc.
9 Type constructors:
¾ Struct for structures
¾ Collection types:
ƒ Set<T> unordered set of different objects of type T.
ƒ Bag<T> unordered collection of objects of type T, duplicates allowed.
ƒ List<T> ordered collection of objects of type T.
ƒ Array<T> ordered, indexed collection of objects of type T.
ƒ Dictionary<T> set of object pairs of type T.
9 Relationship types may only be classes or a collection of a class.
2002 Pål Halvorsen
INF 212 – database theory
ODL Keys
9
Keys are optional in ODL. The OID suffices to distinguish objects that have the
same values in their elements.
9
Indicate with key (or keys) and a list of attributes forming the key.
9
Several lists may be used to indicate several alternative keys.
9
Parentheses group members of a key, and also group key to the declared keys.
9
key(a1,a2 , … , an) = “one key consisting of all n attributes.”
9
key a1,a2 , … , an
9
Example: single, single-valued key
class Beers (key name) {
attribute string name;
}
9
Example: multiple, multi-value keys
class Courses (key (dept, number), (room, hours)) {
...
}
9
Properties other than attributes are allowed to appear in keys
INF 212 – database theory
= “each ai is a key by itself where again each
ai may be multi-valued, i.e., ai =(b1,b2 , … , bn).”
2002 Pål Halvorsen
16
ODL Extents (Instantiated Classes)
9 Difference between the class definition and set of objects
of a class
9 Indicate with extent and a name that we have an extent
(set of existing objects) of a class.
9 A class can be instantiated, i.e., it may have an associated
set of objects (objects may be created), if it is defined with
the keyword class.
9 Example:
class Student (extent students key SSN){
...
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Signature Classes
9
ODL provides support for interfaces, which are essentially classes without
associated objects.
9
Useful if we have several classes that have different extents, but similar properties,
e.g., students and teachers are both persons.
9
Signature classes are defined with keyword interface.
9
Signature classes can not be instantiated and are used only as an auxiliary concept
to define other classes. Thus, it is not meaningful to use the keywords extent
and key in the class interface of a signature class.
9
Example:
interface Person {
attribute integer SSN;
}
class Student : Person (extent students key SSN){
...
}
class Teacher : Person (extent teachers key SSN){
...
}
INF 212 – database theory
2002 Pål Halvorsen
17
ODL Subclasses/Inheritance - I
9 A subclass inherits all the properties from its superclass, e.g., objects of the Ales class acquire all the
attributes and relationships of the Beers class.
9 Indicate by the super-class “prefixed” by:
name
manf
Beers
¾ colon (:) in signature classes
¾ keyword extends in instantiated classes
isa
9 Example: Ales are Beers with a Color
class Ales extends Beers {
Ales
attribute string color;
color
}
9 Signature classes can only inherit from other
signature classes.
2002 Pål Halvorsen
INF 212 – database theory
ODL Subclasses/Inheritance - II
9 Multiple inheritance:
color
¾ Indicate by keyword extends and a
list of classes separated by colon (:).
¾ Example:
class Amphibian
extends car:boat {
...
}
¾ Naming conflicts are not allowed, and it is the
responsibility of the user to avoid them.
manf
color
manf
car
boat
isa
isa
amphibian
¾ All classes can inherit from arbitrary many signature classes, but an
(instanciated) class can only inherit from one instantiated class, i.e., a
class can only be extension of one class.
INF 212 – database theory
2002 Pål Halvorsen
18
ODL Example - I
name
number
hours
money
SSN
controls
name
addr
works
on
Project
Person
manages
Department
name
number
works
for
isa
Employee
salary
addr
2002 Pål Halvorsen
INF 212 – database theory
ODL Example - II
name
controls
number
Project
hours
money
works
on
manages
number
addr
addr
Person
isa
works
for
salary
interface Person {
attribute integer SSN;
attribute string name;
attribute Struct address {
string street, string city
} addr;
}
INF 212 – database theory
name
Employee
Department
name
SSN
NOTE:
Signature (interface) class
Æ no extent or key
2002 Pål Halvorsen
19
ODL Example - III
name
controls
number
hours
money
SSN
works
on
Project
isa
Employee
Department
number
addr
Person
manages
name
name
addr
works
for
salary
NOTE 1:
NOTE 2:
NOTE 3:
NOTE 4:
inherits all the properties relationships come with “MANY” relationships “ONE” relationships
of signature class Person inverse pairs
have a set type
don’t have a set type
class Employee : Person (extent employees key SSN) {
attribute integer salary;
relationship Department works_for inverse Department::has_Emp;
relationship Department manages inverse Department::manager;
relationship Set<Project> works_on inverse Project::members;
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Example - IV
name
controls
number
Project
hours
money
works
on
manages
number
addr
name
addr
Person
isa
Employee
Department
name
SSN
works
for
salary
NOTE:
reuse of address from
the Person class
class Department (extent departments key number) {
attribute integer number;
attribute string name;
attribute Struct Person::address addr;
relationship Employee manager inverse Employee::manages;
relationship Employee has_Emp inverse Employee::works_for;
relationship Set<Project> controls inverse Project::contr_by:
}
INF 212 – database theory
2002 Pål Halvorsen
20
ODL Example - V
name
controls
number
hours
money
SSN
works
on
Project
isa
Employee
Department
number
addr
Person
manages
name
name
addr
works
for
salary
class Project (extent projects key number) {
attribute integer number;
attribute string name;
attribute integer money;
relationship Department contr_by inverse Department::controls;
relationship Set<Employee> members inverse Employee::works_on;
}
2002 Pål Halvorsen
INF 212 – database theory
ODL Example - VI
name
controls
number
Project
hours
money
SSN
works
on
addr
isa
Employee
Department
number
addr
Person
manages
name
name
works
for
salary
NOTE 1:
NOTE 2:
only binary relationships inverse must be added to
Project, Employee
are supported
the
project
Working
Hours
the
employee
hours
Project
Employee
class WorkingHours {
attribute integer hours;
relationship Project theProject inverse Project::emp_hours;
relationship Employee theEmployee inverse Employee::proj_hours;
}
INF 212 – database theory
2002 Pål Halvorsen
21
Summary
9 OO concepts and OODBS properties
9 ODL
¾ classes:
¾
¾
¾
¾
signature and instantiated classes
superclasses/subclasses Æ inheritance
relationships
type system
extents
keys
INF 212 – database theory
2002 Pål Halvorsen
22