Object - ShareStudies.com
Download
Report
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