1. AND OBJECT-ORIENTED DATABASES OBJECT-RELATIONAL DATABASES

2. NOTE Some information has been taken from http://www.amazon.com/Database-Systems- Application-Oriented- Approach/dp/0321268458/ref=sr_1_2?ie=UTF8&qid=1 361919837&sr=8-2&keywords=kifer+bernstein+lewis

3. PROBLEMS WITH PRE-OBJECT-ERA RELATIONAL DATABASE SYSTEMS Extreme impedance mismatch Atomic values are only common data type Complex objects demand many-way joins and relational dbs are not optimized for this Difficult to create similar but different table structures, like cars and red-cars You must program with two very different languages Difficult to represent objects that are collections

4. AN OVERRIDING PROBLEM: ONLY VALUE-BASED SEMANTICS No notion of object identity We make assumptions about object identity based on key values We manipulate tuples that represent properties of objects, not the objects themselves We can look cardinality information about object sets by doing selections No notion of versioning We must simulate versions or time-based variations by using multiple tuples and temporal/version fields

5. WHAT IS A RELATIONAL DB? Collections of tables A set of tuples, with atomic domains Keys, FKs, null limits, FDs and MVDs, and triggers Manipulated with SQL We extract semantics at runtime

6. WHAT IS (OR WOULD BE) AN OBJECT DATABASE? Collections of classes Defined by types Including behavioral encapsulation Subtypes allowed Components of an object can be sets, tuples, other objects Manipulated with an object-oriented language extended with an SQL derivative that includes path expressions

7. OBJECT IDENTITY The key questions: are these the same object or are they two objects that look the same? What is all the relevant information about this particular object? Object IDs are immutable: different ID, different object A relational PK only tells us that this description of some object out there is unique

8. AN OBJECT IS A… Pair (OID, value) The oid is unseen The value can have structure, such as… A flat tuple A tuple with a collection attribute A tuple with an oid value attribute

9. MORE PRECISELY, A VALUE IS… Primitive – like an integer or char string A reference value, i.e., an oid A tuple (at1: value1, at2:value2, …, atn: valuen) A set {}

10. A CLASS IS… A group of objects structured by a type Three parts Type Method signatures An extent – the objects in the class Classes are organized in a class hierarchy

11. ODMG Group of object db vendors Developed a standard ODL – object definition language OQL – object query language A transaction protocol Language bindings for c++, smalltalk, java

12. THE BIG IDEA BEHIND OBJECT DATABASES Objects in the host language are identical in nature to the ones in the DB Objects can become persistent “selectively” Manipulating an object or a group of objects is the same in the host language and the db language – because it is a single language This is a “persistent programming language” No more JDBC connectivity needed No more embedding SQL in the host language No more impedance mismatche

13. A NOTE ON MULTIPLE LANGUAGE BINDINGS C++, Java, Smalltalk, C# are similar, but not identical So we need a “reference data model” to map these languages to

14. WHY DID THEY DIE? Demands a new application stack New database New query language Not optimized for set selection The perceived need apparently wasn’t there We are used to forms and tables Potential user domains needed so much more, like engineering constraints, solid modeling, animation, complex version hierarchies

15. OBJECTS IN THE SMALL: THE SQL OBJECT EXTENSION First, all legacy relational databases are valid A relation is A set of tuples OR… A set of objects An object is an oid and a tuple-value A tuple value is (at1: value1, at2:value2, …, atn: valuen)

16. A VALUE IS Primitive Reference (an oid) Another tuple A collection Multiset Fixed sized array

17. NOTE A tuple can have complex internal structure without having to be an object Thus, we call this “objects in the small”

18. EXAMPLE TABLE students CREATE TABLE students ( Name CHAR(30), Address row(Number INTEGER, Street CHAR(20), ZIP CHAR(5)) )

19. EXAMPLE QUERIES SELECT students.name student s s FROM student s s WHERE s.address.zip = ‘80309’ students INSERT INTO students(Name, Address) VALUES (‘John Doe’, row “123 Elm, ‘80309’))

20. USER DEFINED TYPES (UDTS) These encapsulate structural and behavioral content A UDT can serve as the domain of an attribute

21. EXAMPLE TYPE PersonType CREATE TYPE PersonType AS ( Name CHAR(20), Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5)) ); StudentTypePersonType CREATE TYPE StudentType UNDER PersonType AS ( Id INTEGER, Status CHAR(2) ) BOOLEAN METHOD award_degree() RETURNS BOOLEAN; StudentType CREATE METHOD award_degree() FOR StudentType LANGUAGE C EXTERNAL NAME ‘file:/home/admin/award_degree’;

22. EXAMPLE TABLE CREATION As an attribute type: TRANSCRIPT CREATE TABLE TRANSCRIPT ( StudentType Student StudentType, CrsCode CHAR(6), Semester CHAR(6), Grade CHAR(1) ) As a table type: STUDENTStudentType CREATE TABLE STUDENT OF StudentType; typed table. Such a table is called typed table.

23. IMPORTANT DISTINCTION Only typed tables contain objects (ie, tuples with oids) Compare: STUDENTStudentType CREATE TABLE STUDENT OF StudentType; and STUDENT1 CREATE TABLE STUDENT1 ( Name CHAR(20), Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5)), Id INTEGER, Status CHAR(2) ) Both contain tuples of exactly the same structure STUDENTSTUDENT1 Only the tuples in STUDENT – not STUDENT1 – have oids

24. EXAMPLE COLLECTION TYPE Set (multiset) data type was added in SQL:2003. StudentTypePersonType CREATE TYPE StudentType UNDER PersonType AS ( Id INTEGER, Status CHAR(2), CourseType Enrolled REF(CourseType) MULTISET )