Relational Database Systems. Anastassia ... Basic Object-Oriented Model. ❑
Everything is an object ... Same type system between DBMS and API. ❑
Expressive ...
Object-Oriented and ObjectRelational Database Systems Anastassia Ailamaki http://www.cs.cmu.edu/~natassa
Basic Object-Oriented Model !
Everything is an object Complex vs. simple objects Object identity ! encapsulation ! !
!
Classes and types !
! !
Class extent
Instances … and everything else !
Concurrency, recovery, persistence, queries… © 2001 Anastassia Ailamaki
2
Optional Features ! ! ! ! !
Multiple inheritance Type checking Distribution Long or nested (design) transactions Versioning
© 2001 Anastassia Ailamaki
3
1
ObjectStore !
! ! ! !
Tightly integrated language interface to traditional DBMS features Persistent storage Transaction management (CC / recovery) Client/server computing environment Associative queries
© 2001 Anastassia Ailamaki
4
C++ Extensions ! ! ! !
Persistence Collection facilities Explicit relationships Queries
© 2001 Anastassia Ailamaki
5
Product Goals ! !
Ease of learning (this is why they picked C++) No impedance mismatch !
! ! ! ! !
Same type system between DBMS and API
Expressive power Reusability of existing code libs Conversion of apps from files to DBMS Type checking of persistent data @ compile time High performance ! !
Temporal and spatial locality Fine interleaving (note importance of data load!)
© 2001 Anastassia Ailamaki
6
2
Programming Interfaces ! ! !
C library C++ library Extended C++ library !
Provides integration to queries/relationships
© 2001 Anastassia Ailamaki
7
Features !
Persistence is orthogonal to type !
!
An instance of any type can be persistent int foo; // transient foo persistent int foo; // persistent int foo // in database db Why is it difficult to achieve?
!
No notion of type extent
!
Inheritance = C++ inheritance mechanisms
!
!
Multiple top-level collections can be of the same type Early versions restricted use of multiple inheritance © 2001 Anastassia Ailamaki
8
Example: Dept-Emp class employee { public: string name; int salary; employee* mgr; } class department { public: os_Set employees; void add_employee(employee* e) { employees->insert(e); } int works_here (employee* e) { return employees->contains(e); } } © 2001 Anastassia Ailamaki
9
3
Example: Create Database main() { database* db; // create a new database at this path db = database::create (“/company/records”); // declare a persistent department object persistent department eng_dept; } © 2001 Anastassia Ailamaki
10
Transactions main() { database* db; db = database::open (“/company/records”); persistent department* eng_dept; // Name lookup on the string “eng_dept” in *db // Top-level named persistent objects: “persistent roots” transaction::begin(); // start a new transaction employee* emp = new (db) employee (“Fred”); emp->salary = 1000; eng_dept->add_employee (emp); transaction::commit(); // commit the transaction } © 2001 Anastassia Ailamaki
11
Transactions (cont.) main() { database* db; float total=0; int count=0; db = database::open (“/company/records”); persistent department* eng_dept; // iterate through all employees in engineering dept foreach (employee* e, eng_dept->employees) { total += e->salary; count++; } cout insert(e); } int works_here (emp* e) { return emps->contains(e); } } © 2001 Anastassia Ailamaki
13
Use of 1-M Relationship (cont.) !
whenever an emp is inserted into a dept’s set of emps, emp is automatically updated to refer to the dept (and vice versa). Example: emp* e = new (db) emp (“Fred); e->salary = 1000; eng_dept -> add_employee (e);
…automatically sets e->dpt to eng_dept; !
If delete emp, it automatically removes ptr to emp from set of emps for the dept the emp works for => auto maintain referential integrity
© 2001 Anastassia Ailamaki
14
Collections !
Types of collections Lists – ordered collections Bags – with duplicates ! Sets – without duplicates ! !
!
Operations supported: Insertion Iteration ! Deletion ! Set-theoretic operations ! !
© 2001 Anastassia Ailamaki
15
5
Relationships !
Like pairs of inverse pointers
!
Automatically maintained by the system
!
Types of relationships
!
!
A points to B, B points back to A If A is deleted, B’s pointer to A is set to NULL
One-to-one One-to-many ! Many-to-many ! !
!
Example: department-employees © 2001 Anastassia Ailamaki
16
Associative Queries !
[: :] is the ObjectStore syntax for queries
! !
os_Set& overpaid_employees = all_employees [:salary > 100000:] contained expression is the selection predicate gets applied to all the elements of the set
!
If index exists on “salary”, it will be used No full joins (can’t compose new types on the fly) Queries do not have to be against top-level sets
!
department* eng_dept eng_dept->employees [: salary > 100000 :] Nesting: all_employees [:dept->employees [:salary > 100000:]:]
! !
© 2001 Anastassia Ailamaki
17
Path Indices ! !
Unique opportunity in OO systems Department -> employee (manager) // create a path os_index_path mgr_name_path=pathof (department*, mgr->name); // add an index on the path (assume existence of all_depts) all_departments.add_index (mgr_name_path)
!
Optimization through use of the index all_departments [: mgr->name == “smith” :]
© 2001 Anastassia Ailamaki
18
6
Architecture / Implementation ! !
Client/server architecture Server deals only with pages Provides CC+recovery Page-level locking ! Write-ahead logging ! Xtions on multiple servers: 2-phase commit ! !
!
Client processor ! !
Cache of recently-used pages Need transparent access to persistent data 19
© 2001 Anastassia Ailamaki
Memory-Mapping at Client Side !
DB STATE BEFORE FIRST ACCESS
ENTRY PTR
A
B
D
!
TRANSIENT MEMORY UPON ACCESS TO ENTRY POINTER
!
TRANSIENT MEMORY UPON ACCESS TO VM PAGE A'
ENTRY PTR
ENTRY PTR
A'
A'
B'
D'
© 2001 Anastassia Ailamaki
20
Problems with this Approach? ! ! ! !
A Xtion can access only up to VM size of data Relies on OS calls (not totally portable) Page-level concurrency control and recovery Hard to do buffer management ! !
Once pages are in MM, DBMS loses track Solution: simulate clock using protection mechanism
© 2001 Anastassia Ailamaki
21
7
Object-Relational DBMSs O/R DBMS, the next wave (Stonebraker) Query
Relational DB
Word Processor
No Query
File System
Simple Data
Complex Data 22
© 2001 Anastassia Ailamaki
RDBMSs ! ! !
Market: $10B/year, growing at > 25% every year Systems: Sybase, Oracle, DB2, Informix… Working on: ! ! ! ! ! !
Running well on SMPs (and on all hardware) Interfacing to TP monitors Provide gateway to orher vendors’ DBMSs Parallel query execution Internet, warehouses, mining 7x24
23
© 2001 Anastassia Ailamaki
Object-relational DBMSs (cont.) Query
Relational DB RDBMS CAD or floor space planning
Word Processor
No Query
File System
Simple Data
Complex Data
© 2001 Anastassia Ailamaki
24
8
Example: Floor Space Planning create table emps (
name varchar(30), space polygon, adjacency set_of(emps)) number integer, asf swiss_cheese_polygon))
create table floors (
main() { read all emps and floors; compact(); write all emps; }
persistent language
!
main() { compact(); } 25
© 2001 Anastassia Ailamaki
Which DBMS to use? !
Security nightmare
!
File system: not good Relational systems: not good either
!
!
! ! ! !
!
!
Application data in client address space)
Don’t do complex objects Not a query in sight App/DBMS boundary crossing intolerable SQL updates awkward
“O” companies: Objectivity, Object Design, Ontologic, Versant, Servio, O2, Matisse Market: $100/year (perhaps 1% of RDBMSs) 26
© 2001 Anastassia Ailamaki
Object-relational DBMSs (cont.) Query
water resource data slides
Relational DB RDBMS
File System
CAD or floor space planning OODBMS
Simple Data
Complex Data
Word Processor
No Query
© 2001 Anastassia Ailamaki
27
9
The Tough Applications !
Database of 500,000 slides ! !
Hard to find slide by content Hard to index (and is quickly obsolete)
Possible schema design create table slides ( id integer, date date, caption document, picture photo_CD_image)) create table landmarks ( name varchar(30), location point))
!
© 2001 Anastassia Ailamaki
28
Queries select from where
! !
id slides P, landmarks L S sunset(P.picture) and contains (P.caption, L.name) and L. location |20| S.location and S.name = “Sacramento”;
SQL-92 cannot do this! Persistent programming languages: no queries © 2001 Anastassia Ailamaki
29
Requirements / Potential ! !
Interface: “pan-and-zoom” (no business forms) Performance !
! ! !
!
need new optimization / access method technology
Security: need it! Quadrant is small with big potential Problems in this quadrant: medical imaging, digital library, asset management, scientific DB. Problems moving to this quadrant: insurance.
© 2001 Anastassia Ailamaki
30
10
Object-relational DBMSs (cont.) Query
No Query
RDBMS
ORDBMS
FILE SYSTEM
OODBMS
Simple Data
Complex Data
© 2001 Anastassia Ailamaki
31
Object-Relational DBMS !
Complex objects ! ! ! !
!
Composites Sets Arrays References
Inheritance ! !
Like class hierarchies in C++ Separate type specification / extent declaration
!
Base-type extensions
!
Optimization for really expensive functions
!
Specialized types (Informix US data blades)
© 2001 Anastassia Ailamaki
32
11
