Transcript Object - ShareStudies.com

Object-Oriented Databases
(chapter 2/3)
Course
outlines
Object Persistence - Introduction
Persistent Programming Languages
Specifying Object Persistence via Naming and Reachability
Persistent Objects – Storage and Access issues
Persistent C++ Systems
Object Persistence – Using database
The ODMG Standard for Object Databases
OODBMS Features, OODB Evolution, Strategies for building OODBMS
ODMG Object Database Standard, and Components
An Architecture for OODBMS
Object Model
Object Definition Language (ODL)
Mapping Class Diagrams into ODL
Example - Reconsider the University schema…
Annex - DB Evolution and History
Object Persistence - Introduction
 One of the most critical tasks that applications have to perform is
to save and restore data
 Persistence is the storage of data from working memory so that it
can be restored when the application is run again
 In object-oriented systems, there are several ways in which
objects can be made persistent
 Object Serialization - Simple persistence method which provides a program
the ability to read or write a whole object to and from a stream of bytes
 Using Databases
 The choice of persistence method is an important part of the
design of an application
2
Persistence of Objects
Persistent Programming Languages
The concepts of object orientation can be incorporated into a
programming language that is used to manipulate the database.
 Object-relational systems – add complex types and object-orientation to relational language.
 Persistent programming languages – extend object-oriented programming language to deal
with databases by adding concepts such as persistence and collections.
Persistent Programming languages allow objects to be created and
stored in a database, and used directly from a prog-language
 allow data to be manipulated directly from the programming language (no need to go through
SQL).
 No need for explicit format (type) changes
 format changes are carried out transparently by system
 Without a persistent programming language, format changes becomes a burden on the programmer
(more code to be written, more chance of bugs)
 allow objects to be manipulated in-memory - no need to explicitly load from or store to the
database

Drawbacks of persistent programming languages
 Due to power of most programming languages, it is easy to make programming errors that damage the
database.
 Complexity of languages makes automatic high-level optimization more difficult.
 Do not support declarative querying as well as relational databases
3
Persistence of Objects
Specifying Object Persistence
Approaches to make transient
via Naming and Reachability: objects persistent include establishing
 Naming Mechanism: Assign an object a unique persistent name
through which it can be retrieved by this and other programs.
 Reachability Mechanism: Make the object reachable from some
persistent object.
Declare (root) persistent objects; objects are persistent if they are referred to
(directly or indirectly) from a root object.
 An object B is said to be reachable from an object A if a sequence of references in the object
graph lead from object A to object B.
 In traditional database models such as relational model, all objects are assumed to be persistent.
Root
In OO approach, a class declaration specifies only the
type and operations for a class of objects.
The user must separately define a persistent object of
type set (StudentSet) or list (StudentList) whose value is
the collection of references to all persistent STUDENT
objects
A
B
Object B is reachable from
A and from Root
4
Persistence of Objects - How to find objects in the database?
Persistent Objects – Storage and Access issues
Object Identity and Pointers
 A persistent object is assigned a persistent object identifier.
 Permanence of identity – identity persists throughout program executions and structural
reorganizations of data; required for object-oriented systems.
 In O-O languages such as C++, an object identifier is actually an in-memory pointer.
 Persistent pointer – persists beyond program execution; can be thought of as a pointer
into the database
Storage and Access of Persistent Objects
 Name objects (as you would name files)
 Cannot scale to large number of objects.
 Typically given only to class extents and other collections of objects, but not objects.
 Expose object identifiers or persistent pointers to the objects
 Can be stored externally.
 All objects have object identifiers.
 Store collections of objects, and allow programs to iterate over the collections to find
required objects
 Model collections of objects as collection types
 Class extent - the collection of all objects belonging to the class; usually maintained for all
classes that can have persistent objects.
5
Persistence of Objects
Persistent C++ Systems
C++ language allows support for persistence to be added without
changing the language
 Declare a class called Persistent-Object with attributes and methods to support
persistence
 Overloading – ability to redefine standard function names and operators (i.e., +, –,
the pointer deference operator –>) when applied to new types
 Template classes help to build a type-safe type system supporting collections and
persistent types.
Providing persistence without extending the C++ language is
 relatively easy to implement
 but more difficult to use
Persistent C++ systems that add features to the C++ language have
been built, as also systems that avoid changing the language
6
Persistence of Objects
Object Persistence – Using database
 Most Client-Server applications use a RDBMS as their data store while using an
object-oriented programming language for development
 Objects must be mapped to tables in the database and vice versa
 Applications generally require the use of SQL statements embedded in another
programming language
Goal of object-oriented design is to model a process
Goal of relational database design is normalisation
 The mapping from objects to tables can be difficult if the model contains
 complex class structures
 large unstructured objects
 object inheritance
The resulting tables may store data inefficiently, or access to data may be
inefficient
Refer to the annex
 There are essentially three approaches which have been developed for the
management of object storage in databases:
 the Object-Oriented Database Management System (OODBMS)
 the Object-Relational Database Management System (ORDBMS)
 Object Relational Mapping
7
The ODMG Standard for
Object Databases
Advanced Database
Technologies
Advanced Database Technologies
OODBMS Features
Object data model –
object identifiers, type inheritance, methods, complex objects
Integration with an OO programming language –
transparent or semi-transparent retrieval and storage of objects
Declarative query language –
usually an SQL like syntax
Advanced data sharing –
long transactions; optimistic concurrency; multiple versions of
data; private data check-out
Client-server architecture
9
Advanced Database Technologies
OODB Evolution
Programming Languages
Persistent Programming
Languages
DB Evolution and History
Databases
Extended Relational Systems
e.g. UniSQL, Oracle,Illustra
OODB
OOPL add db facilities
e.g. C++, Smalltalk
-> ObjectStore, Gemstone,POET
Model based systems
add language facilities to a
new data model.
RDBMS
Semantic Data Models
e.g. ER, UML, FDM
e.g O2, ODMG
10
Strategies for building OODBMS
Extend OO programming languages to be persistent
popular approach
programming viewpoint rather than a database one
no standard model; one programming language;
ObjectStore, POET, Gemstone
Use an object-oriented data model for the DBMS
database management viewpoint
need language bindings
query languages, transaction management etc
O2, lambda-DB
Standardization of model and services
ODMG 3 Standard; OMG (CORBA)
11
Object Database Management
ODMG Object Database Standard Group, formed 1991
The Object Database Management Group is an industry consortium
aimed at standardizing object-oriented databases, is intended to:
 provide a standard where previously there was none
 support portability between products
 standardize model, querying and programming issues
 Enables both designs and implementations to be ported between
compliant systems
 Currently on version 3.0, and 3.0 (which is ODMG-2.0 plus
extensions to Java)
 Vendors: Object Design,Objectivity, O2 Technology, POET, etc.
 URL: www.odmg.org
12
ODMG Object Database Standard
ODMG Components
 An architecture for OODBMS.
 An object model.
that will act as the logical model for all OODBMS and provide a level of
interoperability.
 A data definition language (ODL).
A concrete specification of the operations permitted over a schema defined
in the data model.
 A query language (OQL).
for posing ad-hoc queries but not for data definition or data manipulation.
 Language bindings to existing OOPL, (C++, Java, Smalltalk).
the object manipulation languages are the integration of a PL with the
ODMG model, so the OOPL’s get persistence and the OODB gets a flexible
and standard DB programming language.
13
ODMG Components - Architecture
An Architecture for OODBMS
Declaration in
ODL or PL ODL
Application Source code in PL
using ODMG language binding
Declaration
Pre-Processor
PL Compiler
ODBMS
Runtime
Application Binary
Metadata
Linker
Database
Data Access
Running Application
14
ODMG Components – Object Model
Object Model
1. Data Model
 state and structure of data
2. Behaviour model
 dynamics of the data
 operations on the data
Object identity
Complex objects
Types and classes
Inheritance hierarchies
Encapsulation
Late binding/overriding
Extensibility
Completeness
3. Persistence model
 the way the persistent and transient data is created & changes status
4. Naming model
 naming and accessing objects
15
ODMG Components – Object Model
Object Model - Object Identity
 An object’s unique identifier maintained throughout the object’s lifetime
 Not user visible
 System generated
 An object has an existence independent of its value (identity vs equality) thus
implying
 object sharing
 object updating
 supports referential integrity
 Objects can be cyclic
A
The composition graph is
an object network D
B
C
E
16
ODMG Components – Object Model
ODMG Model supports databases...
Built-in structured types which permit traditional database modelling
to be used
 Objects and Literals (atomic and complex)
 Relationships and Attributes
Transactions
nested transactions, where transaction semantics only apply to persistent data
Databases
built-in object types for databases, schemas and sub-schemas
Persistence
lifetime of object specified when created
Names
handles by which persistent information can be accessed
17
ODMG Components – Object Model
Objects, Literals and Mutability
Objects









Carole
are addressed through an object identifier name
address
are instances of classes
age
are packaged structures
can be shared
house
21
will be stored separately—the oid will be
street
stored in the containing structure
properties have different levels of visibility
new operations can be user-defined for
name
Ian
classes
address
mutable (components can be updated but it age
remains as the same object)
47
can be arranged into hierarchies
3
Arcacia Ave
18
ODMG Components – Object Model
Objects, Literals and Mutability
Literals
 do not have an identity: are
addressed by a physical address
 are instances of types
 are simple structures
 are not shared
 will be embedded in any containing
structure
 properties are all public
 no methods can be defined against
types
 immutable (the value is the identity,
so if one of the components change
its a different value)
 can’t be arranged into hierarchies
name
address
age
name
address
age
Ian
house 3
street Arcacia Ave
47
Carole
house 3
street Arcacia Ave
21
19
ODMG Components – Object Model
Complex Objects
Atomic built-in literal types:
 long, short, unsigned long, unsigned short, float, double,
string, boolean, char, any, octet
The simplest objects are made up of these atomic types
Complex objects are built from simple ones by applying
type constructors which can be nested
Type constructors
collections
record structures
20
ODMG Components – Object Model
Collections (1/2)
Supports both collection objects and collection literals






set unordered, no duplicates
bag unordered, duplicates
list ordered, elements can be inserted
array ordered, elements can be replaced
dictionary maps keys to values
enumerations (explicitly listed group of values, “Mr”, “Ms”)
Collection objects
Set<t>, Bag<t>, List<t>, Array<t>, Dictionary<t,v>
Collection literals
set<t>, bag<t>, list<t>, array<t>, dictionary<t,v>
 Subset containment relation defined only over sets
 Operations union, intersection and difference defined only over sets and bags
 No constraints over collections
21
ODMG Components – Object Model
Collections (2/2)
interface Collection : Object {
exception InvalidCollectionType{};
Sets
exception ElementNotFound{ Object element; };
class Set : Collection {
boolean is_empty();
attribute set<t> value;
Set create_union(in Set other_set);
...
Set create_intersection(in Set other_set);
boolean contains_element(in Object element);
Set create_difference(in Set other_set);
void insert_element(in Object element);
boolean is_subset_of(in Set other_set);
void removes_element(in Object element)
boolean is_proper_subset_of(in Set
raise (ElementNotFound);
other_set);
...
...
Iterator create_iterator(in boolean stable);
};
...
boolean query(in String OQL_predicate,
inout Collection result);
};
Bags
class Bag : Collection {
attribute bag<t> value ;
unsigned long occurrences_of(in Object element) ;
Bag create_union(in Bag other_bag) ;
Bag create_intersection(in Bag other_bag) ;
Bag create_difference(in Bag other_bag) ;
};
22
ODMG – Object Model
Attributes and Relationships
Attributes
Relationships
 Unidirectional
 Values could be literals and objects
 Single as well as multi-valued
Resort
name
location
beachType
numberOfBeaches
transferTime
addFacility(F)
showHotels(): set(H)
 Implicitly modelled as properties
whose values are objects
 Frequently bidirectional
 Bidirectional relationships require
inverses
 1:many, 1:1, many:many
1
Hotel
hotels
*
resort
name
address
numberOfRooms
isOverBooked
addFacility(F)
isChildFriendly(): B
checkAvailability(S,R)
23
ODMG – Object Model
Inheritance
Classes are organized into inheritance hierarchies
 The properties and operations of an object type are inherited by its
subclasses and so only need to be written once.
 Saves code through reuse
 Makes code simpler
 Provides a compact, well structured and easy to understand
Two kinds of inheritance supported:
 Inheritance of Behaviour or ISA denoted by “:”
 interface Person {…};
 class Student : Person {…};
 Inheritance of Statedenoted by “extends”
 class Vehicle {…};
 class Car extends Vehicle {…};
24
ODMG Object Database Standard – ODL
Object Definition Language (ODL)
 ODL is a specification language used to define the schema of an
ODMG compliant database.
 ODL supports all semantic constructs of the ODMG object model.
 ODL is independent of any programming language, and hence
provides means for the portability of database schema across
complaint OODBMSs.
 The database schema may comprise of:
 an ODL module (i.e. a higher level construct for grouping ODL
specifications),
 some generic object types using interface,
 some concrete object types using class, and
 some literal types using struct, etc.
25
ODMG Object Database Standard – ODL
Mapping Class Diagrams into ODL
In general, we are dealing with:
 classes, attributes, operations
 associations and inheritance.
Mapping (general case)
 Each UML class becomes an ODL class.
 Multi-valued attributes are declared by sets, bags or lists constructors
 Composite attributes are mapped into tuple constructors
 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}.
 Specify inheritance relationships via extends clause
 Map weak entity types in the same way as regular entities
…
26
ODMG - Mapping Class Diagrams into ODL
Bi-Directional Associations in ODL …
Implementing the to-one (1..1) relationship from Student to Course class.
relationship Course enrolledOn
inverse Course::students;
Implementing the to-many (0..*) relationship
from Course to Student class.
relationship set<Student> students
inverse Student::enrolledOn;
27
ODMG - Object Definition Language (ODL)
Mapping/translating a schema into ODL
class Person
{ attribute string name;
attribute string address;
attribute date birthDate;
short age();
};
class Lecturer extends Person (extent Lecturers)
{ attribute short room;
relationship set<Student> tutees
inverse Student::tutor;
};
…
class Student extends Person (extent
Students)
{ attribute string major;
relationship Lecturer tutor
inverse Lecturer::tutees;
};
…
28
ODMG - Mapping/translating a schema into ODL
Reconsider the University schema…
Person
name: string
address: string
birthDate: date
age(): integer
Student
tutor
tutees
*
1
major: string
register(C: Course): boolean
takeUnit(U: Unit): boolean
Lecturer
room: string
salary: float
joinDate: date
enrolledOn
*
Department
worksFor
*
teachUnit(U: Unit): bollean
takes *
staff deptId: string
name: string
1
getCourses(): Set(Course)
offers
takenBy *
students
Unit
unitCode: string
description: string
getCourses(): Set(Course)
Course
1
partOf
*
units
*
1
courseCode: string
name: string
dept
*
getUnits(): Set(Unit)
29
ODMG - Mapping/translating a schema into ODL
University schema in ODL
Person
name: string
address: string
birthDate: date
age(): integer
Student
tutor
tutees
*
1
major: string
register(C: Course): boolean
takeUnit(U: Unit): boolean
enrolledOn
*
takenBy *
Unit
unitCode: string
description: string
getCourses(): Set(Course)
partOf
*
Department
worksFor
*
teachUnit(U: Unit): bollean
takes *
class Department (extent Departments)
class Person
{ attribute string name;
{ attribute
string name;
attribute
string address;
relationship set<Lecturer> staff
attribute
date birthDate;
inverse Lecturer::worksFor;
short age(); };
relationship set<Course> offers
class Lecturer extends Person (extent Lecturers)
inverse Course::offeredBy; };
{ attribute
short room;
class Course (extent Courses)
relationship set<Student> tutees
{ attribute string name;
inverse Student::tutor;
relationship Department offeredBy
relationship Department worksFor
inverse Department::offers;
inverse Department::staff;
relationship set<Student> hasStudents
relationship set<Unit> teaches
inverse Student::enrolledOn;
inverse Unit::taughtBy;
relationship set<Unit> hasUnits
boolean teachUnit(in Unit U); };
inverse Unit::partOf; };
class Student extends Person (extent Students) class Unit (extent Units)
{ attribute
string major;
{ attribute string name;
relationship Lecturer tutor
attribute string code;
inverse Lecturer::tutees;
relationship set<Student> takenBy
relationship Course enrolledOn
inverse Student::takes;
inverse Course::hasStudents;
relationship set<Lecturer> taughtBy
relationship set<Unit> takes
inverse Lecturer::teaches;
inverse Unit::takenBy;
relationship set<Course> partOf
boolean register(in Course C);
inverse Course::hasUnits; };
boolean takeUnit(in Unit U); };
Lecturer
room: string
salary: float
joinDate: date
staff deptId: string
1 name: string
getCourses(): Set(Course)
offers
students
Course
1
units
*
courseCode: string
name: string
dept
*
getUnits(): Set(Unit)
30
1
Data Models: An overview
Annex
DB Evolution and History
Data Models: An overview
Data Models: 1st Generation
Hierarchical Data Model
 implemented primarily by IBM’s Information Management System (IMS)
 allows one-to-one or one-to-many relationships between entities
 an entity at a “many” end of a relationship can be related to only one entity at the
“one” end
 this model is navigational – data access is through defined relationships, efficient if
searches follow predefined relationships but performs poorly otherwise, e.g for adhoc queries.
Network Data Model
 standard developed by the Committee on Data Systems Languages
(CODASYL)
 allows one-to-one or one-to-many relationships between entities
 allows multiple parentage – a single entity can be at the “many” ends of
multiple relationships
 navigational
32
Data Models: An overview
Data Models: 2nd Generation
Relational Data Model
developed by Edgar Codd (1970)
data represented by simple tabular structures (relations)
relationships defined by primary keys and foreign keys
data accessed using high-level non-procedural language (SQL)
separates logical and physical representation of data
highly commercially successful (Oracle, DB2, SQL Server, etc)
SQL is not computationally complete
does not have the full power of a programming language
Applications generally require the use of SQL statements
embedded in another programming language.
33
Data Models: An overview
Data Models: 3rd Generation
most programming languages are now objectoriented
Object-Relational Model
 hybrid (or “post-relational”) model – objects can be stored within relational
database tables
 proposed by Stonebraker (1990)
 no accepted standards, but ORDBMS features supported by major
commercial RDBMSs such as Oracle
Object Data Model
 offers persistence to objects, including their associations, attributes and
operations
 requirements specified by Atkinson in 1989, standards proposed by Object
Data Management Group (ODMG)
 navigational – a step backwards from the relational model in some ways
34
Data Models: An overview
DB Evolution and History
35