SFDV3007

Chapter 3: Object Database Management

Systems

Overview of Chapter 3

• Brief review & rationale• The ODMG object model• The object/relational approach• Other approaches

2

Brief review and rationale

3.1Why use objects in

databases?

A brief history of objects

• Late 1960’s: Simula– Simula was a simulation programming language that introduced some

of the basic ideas of object orientation (e.g., objects and encapsulation).

• Early 1970’s: Smalltalk– Smalltalk was the first true OO language, designed to teach

programming to children

• Late 1980’s: C++, early object DBMSs• Early-mid 1990’s: Java, early ODBMS standardisation

(ODMG 1.0 & 2.0)• 1999–2000: ODMG 3.0, SQL:1999• 2003: SQL:2003

4

Reminder: The key concepts of objects

(Silberschatz §8.2)

• Object (instance) vs. object class:– complex internal structure (state)– behaviour (methods)

• Identity: each object instance unique• Encapsulation: object internals hidden• Inheritance: of structure & behaviour from other classes• Polymorphism: same operation applies to multiple

classes– Polymorphism is not strictly an OO concept. – you can do polymorphism in Oracle PL/SQL, which is definitely not an OO

language.

5

We may need to storeobjects in databases

(Kifer §14.1–14.2; Silberschatz §8.1)

• Persistence for object-based application programs.

• Early attempts extended existing languages.– no high-level DDL or DML– no integrity– no multi-user access control, etc.

⇒ need for object data storage.

6

Data of any kind need to be persistent(Silberschatz §8.4)

• Application data are transient.– Transient data disappear at application termination because they

are not stored in a permanent medium.

• Persistent data stay around between runs.– Persistence is important for any data, not just object data.

• Custom data files vs. DBMS.– Most object DBMSs tend to be more application-centric than

database-centric, as they tend to de-emphasise the DBMS as an independent entity and focus more on application programming, whereas RDBMSs tend to be more database-centric.)

7

How to incorporate objects into a DBMS

(Kifer §14.2–14.3; Silberschatz §9.7)

• Build DBMS with objects from ground up (pure object).

• Extend existing DBMS with objects (e.g., object/relational):– Extension of BLOBs– Extension of user-defined data types

• Extending user-defined data types (UDTs) is a more flexible and appropriate approach

8

Pure object DBMS (ODBMS)• Data stored and manipulated as objects.

– So the basic storage element in an ODBMS is the object, compared with the relation in an RDBMS.

• Names or Examples : Versant, O2, Poet, ObjectStore, …

• Many now use ODMG model.• Often used for multimedia or web applications.

– ODBMS are often touted for web applications, but for most typical applications they really aren’t any better than relational systems.

– These days, XML support is more important for these kinds of system.

• Scalability still an issue.– Relational systems are usually better for very large databases.

Pure ODBMS may havesome advantages

• Better models of reality? (Good design.)– We should get good models of reality from good

analysis and modelling.

• Code/object reuse? (Not specific to OO.)– OO just makes code reuse easier.

10

Note: many so-called “advantages” of objects vs. relational are based on physical-level

arguments!

Pure ODBMS may have some advantages

• Low “impedance mismatch” with object programming languages? (A red herring?)– impedance mismatch is a set of conceptual and technical

difficulties that are often encountered when a (RDBMS) is being used by a program written in an Object oriented style

– A red herring is something that misleads or distracts from a relevant or important issue.

– Impedance mismatch is pushed as a big problem with RDBMS, but this is really a red herring.

– Translate structures from objects into relational. Any decent middleware layer should be able to do this for you anyway. Products are now being released that hide most or all of the impedance mismatch.

11

Some typical (and scary) misconceptions

12

• “ODBMS only load the required objects into memory, whereas RDBMS load entire tables including related and unrelated data”

– Rubbish! This is a physical-level problem.– This misconception probably arises because people

mistakenly think table = object (instance). – The correct equation is row = object. – This misconception is possible because of the rather weak

separation of the physical and logical levels in ODBMS (they are often identical or at least very similar),

– In RDBMS, these levels are (usually) more strictly separated.

– Modern RDBMSs are intelligent enough to only load the records that are required into memory, rather than entire tables.

Some typical (and scary) misconceptions

13

• “RDBMS can’t store complex objects”– Of course they can! Programmers are just too

lazy to normalise them into a relational structure.

– This misconception is just the same old impedance mismatch argument again.

– Yes, you might have to break the complex objects down (i.e., normalise them), but you can hide this at the conceptual level if necessary.

– Again, decent middleware should look after this for you.

Some typical (and scary) misconceptions

14

• “ODBMS allow a wide range of data types in the same database.”

– Perhaps they should look at Oracle some time. This has nothing to do with object vs. relational.

– The third misconception is really just a restatement of the second from a different angle. What they really mean is “RDBMS can only store simple data types like numbers and text”, which is clearly wrong.

The pure object approach

3.2The ODMG Object Model

16

We are here…

• Brief review & rationale• The ODMG object model• The object/relational approach• Other approaches

The ODMG model (v3.0)(Kifer §14.5; Silberschatz §8.5, 8.6)

• Object Data Management Group.– ODMG 3.0 can work with RDBMS and ORDBMS

• Consortium (Association) of object DBMS and related software companies.

• Main goal: universal interface to simplify database access for object programming languages.

• Originally pure ODBMS only.

17

ODMG 3.0 specifies an object model

Basically, it includes everything that you would expect from a database model

•Objects, properties, operations, etc.•Metadata specifications.•Locking and concurrency control.•Transactions (including distributed).•Compare with relational, especially SQL.

18

ODMG 3.0 specifies three languages

• Object Definition Language(ODL)– ODL is clearly the equivalent of SQL data definition

language

• Object Query Language(OQL)– OQL is the equivalent of SQL data manipulation

language

• Object Interchange Format(OIF)– OIF is a serialisation format for exchanging object data

between ODMG-compliant products.

19

ODMG 3.0 specifies several other features

• Java, C++, Smalltalk support.• Related to CORBA (Common

Object Request Broker Architecture).

• ODL is derived from CORBA IDL.

20

An overview of theODMG object model

Types– Interfaces, classes, literals– Inheritance– Extents– Identifiers, names and keys

Properties– Attributes– Relationships

Operations

21

Everything in ODMG isof a particular type

• External specification (ODL).• One or more internal implementations

(Java, C++, Smalltalk).• Specify properties, operations and

exceptions.• Note: “type” ≠ “object”!

22

Independent specificationand implementation

• Specification completely independent of implementation details like data structures.– The separation of specification and implementation is

effectively a form of physical data independence

• Specifications bound (mapped) to programming language ⇒ implementation (cf. conceptual ERD → relational).

23

Independent specificationand implementation

• Specifications bound (mapped) to programming language ⇒ implementation (cf. conceptual ERD → relational).– In the conceptual ERD → relational translation we are

binding the ERD specification to an SQL implementation. – We have to map conceptual many-to-many relationships onto

an associative table in SQL. – Similar issues can occur when binding ODL to a language.

For example, ODL supports struct data types, but Java does not.

24

ODMG type specifications

(Adapted from The Object Data Standard: ODMG 3.0, Figure 2–1)

25

interface literal

Abstract behaviour(operations)

Abstract state(properties)

class

• This shows the relationships between the different kinds of type in the ODMG model.

• Classes sit at the intersection of the two.

Interfaces and classesare object types

These two are “object types” effectively means that they get all the

usual features we would expect of objects: inheritance, etc.

Interface– Specify behaviour only (no state).– Definition of “behaviour” seems broad.– Cannot create instances (cf. Java abstract classes).

Class– Specify both state and behaviour.– Can create instances.ODMG interfaces are not the same thing as Java interfaces

26

Literals are not object types

• Literal is a value or constant • Specify state only (no behaviour).• No OID (Object Identifier).• Can create occurrences (not

instances).• Effectively “traditional” structured

data types (e.g., Pascal record, C++ struct).

27

ODMG has two forms of inheritance

Subtyping– “Normal” inheritance (specialisation).– Limited multiple inheritance of behaviour.– Single inheritance of state.interface Professor : Academic {...};

professor is a subtype of academic

extends– Classes inherit state and behaviour from another class or interface

without being a subtype.– Single inheritance only.class Platypus extends Duck : Mammal {...};

extends effectively enables a class to “steal” functionality from another without being directly derived from it. (So in the example above, a Platypus has some of the features of a duck, but is actually a subtype of mammal, not bird).

28

Object instances arecollected into extents

(Kifer p. 549; Silberschatz §8.5.2.1)

• Set of all instances of a class (including subtypes) within database.

• Maintained automatically by DBMS (preferred) or manually by applications.

29

Object identifiers uniquely identify

instancesKeys are generally user-defined and visible to user and applications. ODMG OIDs generally aren’t.

•System-generated.•Not a key.•Not part of object’s state•Cannot be changed by users.•No OIDs for literals or interfaces.

– Literals don’t have OIDs because they aren’t object types. Interfaces don’t have OIDs because you can’t create instances of them.

30

Object names uniquelyidentify instances

• Meaningful, user-generated unique name for single object instance.

• Not a key.• Not part of object’s state.• One or more names per instance.• Often used to identify “root” objects in database.

– A “root” object is (should be) one from which any other object in the database can be reached by following object references. For example, departments might be good root objects in a University database

31

Object keys uniquelyidentify instances

(Kifer p. 549)

• Unique identifier built from object attributes, i.e., part of object’s state.

• Compare with relational candidate keys.

• In the relational model, PKs are required, but in the ODMG model, object keys are optional.

32

ODMG objects have properties

• User-accessible.• No public vs. private like Java,

C++.

33

Attributes are a kind of property

(Kifer pp. 549–550; Examples 3–3, 3–4 & 3–5)• Object, literal or “constructed” types

(enumerations, sets, arrays, etc.).• Not the same as a data structure:

– can specify “attributes” in interfaces that are implemented by methods

– implementation language may not support specified data type (e.g., no struct in Java)

– An example might be an age “attribute” that is implemented as a method that calculates the age based on the value of the date of birth attribute

34

Relationships are anotherkind of property(Kifer pp. 550–552; Examples 3–3 & 3–4)

• Binary association between two object types.• One-to-one, one-to-many, many-to-many.• No participation (optional/mandatory).• Pairs of traversal paths.• ODBMS maintains referential integrity.• Traversal paths can be thought of as being like

references or pointers from one object to another (compared to FKs in the relational model).

35

ODMG objects have operations

(Kifer p. 550; Examples 3–3 & 3–5)

• Specify a set of operation signatures:– name of operation– names and types of any parameters– return value(s)– any exceptions that could be raised

• Operation implementation written in an object programming language.

• Polymorphism supported.

36

Making an instance persistent

• Pass instance to Database.makePersistent() static method (binding-specific).

• Give instance a name.• Persistence via reachability (Java only); instance X

reachable from instance A if:– A references X directly (A → X); or– A → B → C → … → X

A persistent ⇒ B, C, …, X persistent.

• If we don’t do any of these, then the object instance will be transient, and disappear when the application ends.

37

The Object Definition Language

(Kifer §14.5.1; Silberschatz §8.5.1 [for C++]; Figure 3–2)

• Pure DDL (cf. SQL) for object data.• Objects implemented using object

programming language• Extension of CORBA Interface

Definition Language (IDL).

38

The Object Query Language

(Kifer §14.5.2; Silberschatz §8.5.2.5 [for C++]; Example 3–6)• Pure query language for object data, deliberately similar to

SQL/92.• Relies on ODMG object model.• Not a DML:

– no delete, insert, update– direct object manipulation from, e.g., Java

• Execute in programs using OQLQuery class.• Object manipulation is done using the usual programming language

conventions, e.g., in Java, you use new to create a new instance and call appropriate mutator methods to update values. There is no equivalent of delete in Java because Java instances are simply garbage collected when they are no longer referenced.

39

A brief summary ofthe ODMG model

• Aims to provide universal way of defining and accessing object data in any ODBMS, RDBMS or ORDBMS.

• Now mainly Java-oriented.• Heavy emphasis on persistent

object data for application programs.

40

Object/relational approach

3.3Objects in Oracle10g

and SQL:2003

Oracle10g has object support

(PL/SQL User’s Guide and Reference ch. 12; Oracle10g Application Developer’s Guide—Object-Relational Features)

• Extension of user-defined data types.– single inheritance– FINAL objects

• FINAL objects can’t be subtyped or overridden (the same as in Java)

– [NOT] INSTANTIABLE objects• NOT INSTANTIABLE objects are equivalent to Java abstract classes.

• Use anywhere standard data types are used. • Object tables and views.

– Object views in particular provide a very good way to implement proper logical data independence.

• Application: nested tables.

42

Object methods in Oracle10g

(Example 3–11)• Member, static, comparison.• Comparison methods (mutually exclusive):

– map: returns “value” of current object• MAP is used to generate a “value” for an object instance that can then be

used in comparison operations

– order: is current object >, =, < some other object?• ORDER returns 1, 0 or -1 for >, = or <, respectively.

• Method implementations using CREATE TYPE BODY.

• PL/SQL, Java, C.

43

Oracle10g’s objects have several limitations

• No true encapsulation :– bypass object methods using SQL.– methods cannot INSERT, UPDATE or DELETE

if called from a SELECT

• Cannot cluster tables containing objects.

• No constraints or defaults in object type definitions (but OK in object tables).

44

SQL:2003 has object support

(Kifer §14.4; also SQL-99 Complete, Really by Gulutzan & Pelzer, ch. 27)

• Similar to Oracle10g.• Oracle implements many SQL:2003

features.• No full implementations yet!

45

End of Chapter 3—what’s next?

Chapter 4: Decision Support Systems– What are they?– Data warehouses

• characteristics• logical & physical design

– Online analytical processing (OLAP)– Data mining

46