112/1/97 P-1Object-Oriented DatabasesChapter 2212/1/97 P-2Limitations of theRelational Model• limited constraints expressible• limited types of relationships• normalization leads to atomization,inefficiency• Limited built-in datatypes– No support for multimedia types: images,video, sound, designs, texts, etc.– BLOBs (binary large objects) are oneworkaround12/1/97 P-3Language Fit• COBOL and DB grew up together– COBOL pioneered the "record" construct– character-based types• Poor fit to today's languages like C++12/1/97 P-4Versioning• In some applications, old versions of datamust be accessible– designs (architecture, CAD, etc.)– documents– multimodule systems• Often are complex relationships betweenversions• Not necessarily an OO concept.12/1/97 P-5A Look Back• Before we look ahead...• Hierarchical and Network (CODASYL)models were popular before relational– Network had extremely rich semantics– Complex relationships directly expressed (nojoins)– Primarily "navigational"• Custom programs locate data via knowledge ofschema, following pointers• No standardized query languages12/1/97 P-6Object-Oriented Trends• Trends in OO Programming seempromising for databases– Rich, user-defined data types (support of newmedia, lift 1NF restriction)– Inheritance (important type of relationship)– Encapsulation of data and functions– Increasing emphasis on components andreusability; cross-platform– Tighter integration with C++212/1/97 P-7Review of OO ProgrammingConcepts• Class: description of data structure andoperations (i.e. a data type)– encapsulation: data and ops are wrappedtogether; only an interface is externally visible.• Object: an instance of a class• Class B inherits from class A: B has all theproperties of A, plus some new or alteredproperties (data/functions)12/1/97 P-8Strict OO Viewpoint• Where possible: model the behavior andrelationships of the real world• Everything is an object• Objects communicate only by passingmessages– In practice, a message is a function name plus aset of arguments• Types can be determined at run-time• Smalltalk is the model: untyped;interpreted; interactive12/1/97 P-9Hybrids and Compromises• Example: C++– retains all features of non-OO C language, addsclasses, inheritance, polymorphism• OODBs tend to be compromises– May retain relational facilities: ORDBMS– Add OO features such as: user-defined types &classes, inheritance, etc.– Add features like "persistence" and versioning– SQL3 will have OO features12/1/97 P-10OIDs• Object Identifiers (OID)• Unique (database-wide) identifier for eachobject– independent of key• One object can reference another via OID– Allows complex embedding12/1/97 P-11Challenges for Query Languages• DDL: coordinating PL with QL• Encapsulation issues– how much is visible?– must all operations be predefined?• Multimedia– what does "query" mean?– how to display results?12/1/97 P-12Persistence• The idea: it's easy for a program to work witha complex data structure in memory, but hardto flatten it into a file. It would be convenientif some variables were persistent, i.e., couldexist on disk between executions of theprogram, i.e., be part of the DB.• Not strictly on OO concept• One challenge: mapping OIDs between in-memory pointers and disk addresses– "pointer swizzling"312/1/97 P-13Deductive Databases• Another (non-OO) approach to relievingrelational limitations• DB viewed as a set of facts and rules– a row can be viewed as a fact which satisfies apredicate• Logic-based languages– Datalog: DB extension of Prolog• Excellent at expressing complex constraints,making deductions and discoveries,
View Full Document
Unlocking...