View
224
Download
3
Category
Preview:
Citation preview
1
Chap. 8 Object-Oriented Databases
서울대학교 컴퓨터공학부SNU Internet Data Base Lab
교수 김 형 주
OBJECT-ORIENTATION by Khoshafian and Abnous
2
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
3
Introduction
Object-Oriented Databases
Object Orientation
Abstract Data TypingInheritanceObject Identity
Database Capabilities
PersistenceConcurrencyTransactionsRecoveryQueryingVersioningIntegritySecurityPerformance
4
Overview of DBMS Concepts (1)
Persistence the ability of objects to persist different program
invocations
Transactions units are executed either entirely or not at all
(atomicity).
Concurrency control to guarantee database and transaction
consistency
5
Overview of DBMS Concepts (2) Recovery
three types of failures: transaction failure system failure media failure
Querying queries are used to select subsets and subobjects fro
m database collection objects or sets Versioning
consists of tools & constructs to automate or simplify the construction & organization of versions or configuration
6
Overview of DBMS Concepts (3)
Integrity the predicates that capture the consistency of
a database
Security Encryption algorithms User access control mechanism
Performance issues indexes or accelerators clustering techniques query optimization
7
Approaches to OODB (1)
Novel database data model/data language approach the most aggressive approach for incorporating OO capabiliti
es into DB ODMG93: ODL, OQL. OML
Extending an existing DB language with OO capabilities e.g. extending SQL with object-oriented constructs Intelligent SQL UniSQL
8
Approaches to OODB (2)
Extending an existing OOPL with DB capabilities e.g. OODB extensions have been incorporated in C++
and Smalltalk as language extension Gemstone’s OPAL (Smalltalk extension)
Providing extendible OODBMS system libraries C++ client library for database management Ontos, Versant
9
Approaches to OODB (3)
Embedding OODB language constructs in a host language e.g. O2 provides embedded extensions for C and
Basic
Application-specific products with an underlying OO DBMS Echelon: OODBMS for XML Multimedia content server
10
Approaches to OODBs: Summary
Novel database data model/data language approach
Extending an existing DB languages with OO capabilities
Extending an existing OOPL with database capabilities
Providing extendible OODBMS libraries Embedding OODB language constructs in a host
language Application-specific products with an underlying
OODBMS
11
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
12
Foundation and Evolution of OODBs
The hierarchical data model The network data model The relational data model Set-and-Tuple complex object models Semantic data models
13
Hierarchical Data Model
This model represents the structures of the persistent DB as a collection of tree node ( a set of objects of the same type ) relationship ( one-to-many (parent: child) )
70’s: IBM IMS
COBOL, PL/I
14
Parent
Child #1 Child #N………….
< The hierarchical data model >
15
Desktop 2 Desktop 1
Folder 13Folder 12
Document 112
Document 111
Folder 11
A hierarchical representation of desktops, folders, documents
16
Network Model
This model is more general than the hierarchical model. same record type can be
owner (parent) member (child)
70’s: System 2000
COBOL, PL/I
17
Owner #1 Owner #n
Member B
………………..
< The network model >
Member A Member C
18
Desktop
Folder
Drawer
Cabinet
Contains
Contains
Contains
Contains
1 N
1
NN
1N
1
1-to-M relationships supported by the network model
19
Relational Model Navigational (how)
in a hierarchical or a navigational DB Declarative (what)
in a relational DB Constitution of RDB
relation(table) : row+column
1970, E.F. Codd (IBM) Relational Calculus, Relational Algebra
1976: Ingres (UC Berkely), System/R (IBM SanJose)
20
FoldersDesktops
Documents
Intelligent Office Tables
C1 C2 CN
Columns
Ro
ws
Relational DB for Intelligent offices
21
Set-&-Tuple complex object Model
1985: Khoshafisian & Bancillon Set-&-Tuple complex object model
have been proposed to the relational model with nested relations attribute values can be tuples or sets
Set valued attributes Relation valued attributes
Extending SQL extending relational calculus permitting sets extending relational algebra permitting sets
22
Semantic Data Model Semantic data model
node --- entity, object link --- relationship
semantic v.s. object-oriented model entity type v.s. class entity v.s. instance attribute v.s. instance variable
So many proposals (1980-1986) GEM, Association Model, SDM, RM/T, ……
23
Integrity Constraints for OODBs
Unique/primary key constraints Existential constraint NOT NULL constraint Integrity rules Triggers Pre- and postconditions for methods Disjointness constraint Covering constraint
24
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
25
Persistence in OODBs Ways to create and maintain persistent objects
3 strategies to create & identify persistent objects: persistent classes and class extensions persistence through reachability persistence instances
26
Persistent classes and class extensions
System built-in persistent classes Subclasses of built-in persistent classes are persistent
Understand as ADT constructor and Container classes
Most cases: COLLECTION classes (set, bag, list, array) Iterators (for navigating persistent instances)
27
PersistentObject Space
TransientObject Space
DB X Y
Z
Application’s Object Space
Persistence through Reachability
28
ArchivalDocuments
Accounts
Invoices
Query Result
New Folder
Persistent Instances Transient Instances
Declaring Persistent & Transient instances
29
Main Stream to Manipulate Persistent OODBs
Strategies for persistence in OODBs extending a DB language with OO capability
extending SQL with OO features IntelligentSQL, UniSQL
extending an OO language with DB capabilities language extension: making Smalltalk an OODBMS extendible library: Ontos, Versant
30
Extending SQL with OO
SQL standards SQL-89 SQL-92
Currently SQL-3 standardization effort incorporates OO features user-defined abstract data typing inheritance set, collection types object identity
31
Case Study (ORDB): Intelligent SQL
Prototype developed at Ashton-Tate that extended SQL and the InterBase DB engine
Main concepts of object orientation abstract data types inheritance tuples and object identity extended dot “.” notation identity
32
Intelligent SQL: Abstract Data Type
CREATE CLASS Stack[T] { INSTANCE VARIABLE ( ARRAY StArr[M] of T, Top INTEGER); METHODS ( push ….. ( ……); pop ….. (…….); }
CREATE TABLE Account( AccountNumber INTEGER, Location CHAR(20) Payables Stack[Dollar])
SELECT AccountNumber, Pop(Payables) FROM AccountWHERE Location = “New York”
33
Intelligent SQL: Inheritance
CREATE TABLE OfficeWorker ( Name CHAR(20), Address CHAR(100), Workeroffice CHAR(10), Salary FLOAT, DateOfBirth DATE)
CREATE TABLE Manager SPECIALIZES OfficeWorker ( Title CHAR(10))
CREATE TABLE VicePresident SPECIALIZES Manager (AdminAssistant CHAR(20))
SELECT Address FROM Manager WHERE Salary > 60K
CREATE TABLE HighlyPaidWorker SPECIALIZES OfficeWorkers WHERE Salary > 60,000
34
Intelligent SQL: Tuple and OID
CREATE TUPLE ADDRESS ( Number INTEGER, StrtName CHAR (20), AptNo INTEGER, City CHAR(20), State CHAR(20), Zip INTEGER);
CREATE TABLE Persons ( Name CHAR (20), Age INTEGER, HomeAddr ADDRESS);
CREATE TABLE Persons( Name CHAR(20), Age INTEGER, HomeAddr TUPLE ( Number INTEGER, StrtName CHAR (20), AptNumber INTEGER, City CHAR(20), State CHAR(20), Zip INTEGER) )
35
Case Study (ORDB): UniSQL
Won Kim at UniSQL, Inc. SQL/X is an extension of the SQL-89 with OO extensi
ons direct reference to table records ability to associate procedures or methods with table definit
ions support of table inheritance support of collection types in relations
36
UniSQL
CREATE CLASS IMAGE ( Size INTEGER, Type INTEGER, Content …)
CREATE CLASS PERSON ( Name CHAR (32), … Picture IMAGE);
CREATE CLASS MAP ( MapName CHAR(32), MapRegion CHAR(32); MapImage set IMAGE)
37
Extending OOPL with DB Capabilities Two alternatives
use language extensions that enrich the OO language with database capabilities GemStone’s OPAL by ServioLogic
provide extendible OODBMS libraries C++ libraries for database management by Ontos, Versant,
Objectivity, and ObjectDesign
38
Case Study (PL Ext): OPAL
Making Smalltalk as a DB language OPAL is the GemStone’s DDL and DML Defining a class in OPAL
Receiving_class_name subclass ‘Name_subclass’ instVarName: ListofInstanceVariables
classVars: ListofClassVariables poolDictionaries: ListofCommonVariables inDictionary: DictionaryName constraints: ListofDomainConstraints InstanceInvariant: False/True isModifiable: False/True
39
Case Study (PL Ext): OPAL
Richworker := Workers select: {:aworker | aworker.salary > 60000}
Jones := Workers select: { :aworker | (aWorker.age > 21) & (aWorker.name.last = “Jones”)}
40
C++ Classes for DB capabilities
Class libraries supporting persistence and DB capabilities constructors new with various parameters methods to destroy the persistent object methods to read/write object from/to DB methods to lock/unlock the object predicate to check the object’s modification
Persistent classes are defined by their inheritance from a root persistent class
41
PersistentObject
PersistentFolder PersistentWorker PersistentPeripheral
PersistentAccountFolder
PersistentSalesPersion
PersistentScanner
< Persistent classes routed at PersistentObject >
42
Case Study (Library): Versant
OODBMS from Versant Object Technology Supports C, C++, and Smalltalk interface Persistent root class PObject provides
new operator delete method className(), isPersistent(), isInstanceOf(),... object management methods version management methods
43
Case Study (Library): ObjectStore (1)
ObjectStore ODBMS from ObjectDesign, Inc. A number of high-performance capability Any object type can be persistent or transient
// Create an instance of office_typeOfficeapp *officeobject = new(officedb, office_type)
// Declare binding of a variable to a databaseDatabase *officedb;……………..officedb = os_database::open(“/office/officedb”);
44
Case Study (Library): ObjectStore (2)
Collections and Querying in ObjectStore ObjectStore collection classes :
os_Collection, os_Set, os_Bag, os_List The general form for executing a query is :
<collection-object>.os_query( <element type name>, <query string>, <database> )
corporateOffices[: size > 200 :];
45
Persistent Complex Object Storage Strategies(Fast Object Access!!!)
Two complementary storage techniques indexing to accelerate the searches
conventional indexing techniques are applicable B-tree, primary/secondary index, hashing, etc.
clustering to store objects that are accessed together as close as possible graph structured object space are mapped onto physical
storage units such as pages, segments
46
Persistent Object Space
Page 1
Page 2
Physical Disk Pages
…………..
Mapping complex object spaces onto secondary-storage disk pages
47
Case Study (Clustering): ObjectStore
ObjectStore persistent address space
concurrently sharable its size is larger than that of virtual address space
theoretical 2^29 bytes/DB Main memory < Virtual Memory < Persistent Memory Several disks can be used for persistent memory A database can have many segments Clustering objects in the segments improve the performa
nce
48
Physical memory
VMPersistentMemory
OS Paging System
ObjectStore & VM extend views of memory in similar way
49
Case Study (Clustering): GemStone
GemStone specify how objects should be clustered
(e.g.) MyObject cluster
clusterPersonself cluster.name cluster.age cluster.Soc-sec-num cluster.Address cluster.
address streetNum clusteraddress streetName clusteraddress State cluster
50
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
51
Transactions in OODBMS (1)
Constructs begin transaction end(commit) transaction abort transaction
to undo all work and terminate the transacation without its updates
52
Transactions in OODBMS(2)
Properties(ACID) Atomicity: a program that either is executed
entirely or is not executed at all Consistency: all associated semantic integrity
constraints are satisfied Isolation: the safeguard provided by the
database system against mutual interference between concurrent transactions
Durability: preserve the effects of all committed transactions as well as db consistency in the presence of system and media failures
53
Folders
Documents
Workers
State S1
All integrity constraintsare satisfied
Folders
Documents
Workers
State S2
All integrity constraintsare satisfied
Transaction
Transactions maintain consistency
54
Long Transactions
Advanced database applications CAD, CAM, GIS, telecommunication, etc.
Issues on long transactions on a failure, the entire transactions has to be rolled
back the more complex and large a transaction, the
more conflicts with other transactions computer supported cooperative work
Long transaction management techniques nested transaction cooperating transaction
55
SD1 SD1
SD1 SD1
First Draft
DocumentOutline
SubdocumentsIntegrated for
First Draft
Second Draft Draft 2
FinalDraft
Reviews cumulating in 2nd Drft
Integrating Figures,Charts, Etc. , for
Final Draft
The multiple steps to complete a complex document
+
56
Nested Transactions
Introduced by Moss (1981) Transactions have a tree structure
ST1
ST12ST11
ST2
ST21 ST22
Top Level Transaction
57
FinalDraft
Draft 2
Draft 1
Subtransaction for Draft 2:integrate annotations
……...
Subtransaction for Graphics
Subtransaction forGraphics
Integrate
Subtransaction forDraft 1
Final DraftTop-level Transaction
Nested transaction in document-preparation example
58
Cooperating Transactions
Some advanced application involve users who need to cooperate
Each workers come up with rules to regulate the coordination synchronize their individual subtransactions
59
Concurrency Control
The activity of synchronizing the actions of transactions occurring at the same time Protocol
Algorithms based on Locking: Two-phase locking, Multiple-granularity
locking Timestamp ordering Commit time certification
60
Lock based Concurrency Control
Two-phase locking protocol separate the transaction into a growing phase and a s
hrinking phase Multigranularity locking
physical storage organization classes and instances class hierarchy locking complex or composite object locking
61
Other Concurrency Control Mechanisms
Multiversion concurrency control creates a new version of a database for each update tra
nsaction garbage collection to get rid of old versions
Optimistic concurrency control perform any operation on a database object determine whether a transaction’s commit can be safely
processed
62
Case Study (Concurrency control)
GemStone both optimistic and pessimistic (locking) concurrency control read (Shared), write, exclusive lock modes
Versant write, intention write, update, read, intention read, and null lock mod
es Objectivity/DB
read, update lock modes multiple granularity locking check-in/check-out protocol
ONTOS both optimistic and pessimistic (locking) concurrency control read, write, and write intent lock
63
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
64
Recovery in OODBs (1)
Types of failures transaction failures
a transaction fails to commit systems failures
hardware or software problems media failures
hard disk crashes or other nonrecoverable errors on the hard disk
65
Recovery in OODBs (2)
Recovery manager log
is used to record & store the before & after image of updated objects
Undo log Redo log
data replication or mirroring shadowing
66
Case Study (Recovery)
GemStone create replicas of the persistent database
SystemRepository replicateWith: <file name> all replicas are updated before the transaction commi
ts
ODB-II from Fusitsu transaction recovery with roll back system recovery with log
67
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
68
Versioning
System facility for keeping track of previous states or alternate states of objects
A version set contains all the versions of the object
Important in design-oriented environment Operations
Create a version, derive a version Retrieve a version, update a version, delete a version Check-in/out
check-in : from private DB to public DB check-out : from public DB to private DB
69
``
Workstation Server: Private DB
Designer’s PC:Public DB
Check-out
Check-in
< Check-in & check out in versioning >
70
Version Set of O1:
V1: Original Version
V2 V3
V4 V5 V6
V7:Final Version
Alternative Versions
Design Object: O1
{V1,V2,V3,V4,V5,V6,V7} : the version set of O1V1-V3-V6-V7 : a linear version of O1{V2,V3} : alternative version of V1
71
Version Creation
Language constructs Check-out and check-in object versions retrieve successors or predecessors of versions
Different approaches for creating versioned objects inheritance from Version class explicit property with versioned declaration
72
class class
MethodSignatureInheritance
(is-a)Method Name
PersistentObject
Folder Version
VersionFolder
Retrieve predecessor
Retrieve successor
Version Version
Version Version
Versioned objects through multiple inheritance
73
Configuration
Collections of objects that must be maintained mutually consistently
A unit for locking and versioning Each object within the configuration can
have a history of versions Version percolation: If a new version of
any component object in a configuration is derived, a new version of the configuration is also derived.
74
Object 1
V1 V2 V3 V4
Object 2
V1 V2 V3 V4
Object 3
V1 V2 V3 V4
Time
Object 1V1 V2 V3 V4
Object 2V1 V2 V3 V4
Object 3 V1 V2 V3 V4
Configuration 1 Configuration 2
Versions of objects & configurations
75
Check-out/Check-in Model and Versioning
Algorithm for accessing objects concurrently in client/server architectures step1. begin transaction step2. navigate or locate the object(s) to be manipulated step3. check out the objects with either read or write lock,
depending on intent step4. manipulate the object(s), possibly updating it step5. check in object(s) back to common area (repository),
possibly creating a new version
step6. commit transaction
76
Versioning in OODBs
ITASCA automatic versioning of objects tagged as versioned
ONTOS versioning and alternative mechanisms configuration objects
ObjectDesign configurations and versioning with alternatives
77
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
78
Client/Server Architectures and OODBs
Client/Server architecture file servers database servers
Distributed databases homogeneous distributed database heterogeneous distributed database
Standardization effort CORBA(Common Object Request Broker
Architecture) by OMG Client/Server Paradigm + OO Paradigm
79
C/S Architecture: File Servers
Concurrent resource sharing among multiple users
File servers file, block, page level I/O buffering, locking, concurrent access back-up, authorization, transaction
The client side execution of the application
80
Application
DBMS(Front End)
ClientOS
Network OS API
Application
DBMS(Front End)
ClientOS
Network OS API
Data FilingComputationsGUI Front End
< File server architecture >
81
C/S Architecture: Database Servers
Programming interfaces to database servers tools or programs used to interact with the server constitute the client side of the software that is
used to interact with the server
Partitioning functions between clients and server peer-to-peer architecture
each node has the potential of becoming both a client and a server
local and personal databases check-out/check-in model of application development
82
Client/Server and OODBMS
Partition of functionality between C/S of OODBMS object-server architecture
the server manages objects queries and methods can be executed on the server node thin client
page-server architecture the server does not process queries or execute methods,
these are performed on the client side heavy client
file-server architecture
83
Two types of object accesses
Navigational variable “reachable” objects are accessed through attr
ibute values or elements of referencing or parent objecs
Query(or declarative) access a search mechanism through a query
84
A (possible) layered Architecture of OODBMS
Query Manager,Accessor/Update Manager
Query Optimizer
Complex Object Manager
Storage and Index Manager
Buffer Manager
Physical I/O
Concurrency Controland Transaction Manager
Recovery Manager
85
Alternative strategies on the server side
Query and accessor/update/method interface the highest level that could be supported by the server
Complex object interface the server provides a slightly lower level interface than t
he query or method access option Storage and index manager layer interface Physical file and block I/O
is similar file server architectures except that the management and concurrency control of the the I/O blocks is performed by OODBMS
86
Server process:Query and Evaluate
Client process:SELECT ….
< Server processing high-level query statements >
Descriptor(Result)
High-level Query
87
Case Study (Client/Server)
Objectivity/DB : page server architecture Server does page read/write and lock based
concurrency control Client does other modules Heavy client
Versant : object server architecture Server does most parts of processing Dual buffer: Server cache, Client cache Thin client
88
Client
Cache
Server
Cache
ObjectObject
Requests
< Versant’s client/object server architecture >
89
Distributed Databases
Interconnected LANs/ Mulitple Servers Characteristics
Autonomy: the degree to which sites within the distributed database system may operate independently
Distribution transparency: the extent to which the distribution of data to sites is shielded from users and application
Heterogeneity: different hardware and operating system may use different data representation
Total isolation: each site in the distributed database system is a stand-alone server and is unaware of the other sites
90
LAN
DBServer
FileServer
LAN
DBServer
FileServer
LAN
DBServer
FileServer
LAN/WANInterconnect
< Distributed database on interworked LANs >
91
Client
Server #1:Folders
Server #2:Workers
Server #3:Peripherals
DATABASE: Folders Workers Peripherals
< One logical database distributed across various servers >
92
Distributed transaction management
Requirements for atomic commitment each participant must arrive at the same
commit or abort decision each participant has veto power each participant must not reverse its decision
once a unanimous decision is reached
Two-phase commit protocol
93
Coordinator
Site #1
Site #2
Site #3
prepare
OK
OK
OKPhase I
Coordinator
Site #1
Site #2
Site #3
Commit
CommitCommitPhase II
COMMIT in 2-phase commit protocol for distributed transactions
94
Coordinator
Site #1
Site #2
Site #3
prepare
OK
Failed
OKPhase I
Coordinator
Site #1
Site #2
Site #3
Abort
AbortAbortPhase II
ABORT in 2-phase commit protocol for distributed transactions
95
Case Study (Distributed OODB)
ONTOS object database database can be physically distributed to
many servers two-phase commit protocol
Open ODB from HP the server part: An object manager and
underlying RDB engine (ALLBASE/SQL) two-phase commit protocol
96
Contents
Introduction Foundation and Evolution of OODBs Persistence in OODBs Transactions & Concurrency Control in OODBs Recovery in OODBs Versioning Client/Server Architecture and OODBs
Recommended