Cơ sở dữ liệu - Chapter 9: Object ­ based databases

Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db­book.com for conditions on re­use  ©Silberschatz, Korth and SudarshanDatabase System Concepts Chapter 9: Object­Based Databases ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Chapter 9: Object­Based Databases n Complex Data Types and Object Orientation n Structured Data Types and Inheritance in SQL n Table Inheritance n Array and Multiset Types in SQL n Object Identity and Reference Types in SQL n Implementing O­R Features n Persistent Programming Languages n Comparison of Object­Oriented and Object­Relational Databases ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Object­Relational Data Models n Extend the relational data model by including object orientation and  constructs to deal with added data types. n Allow attributes of tuples to have complex types, including non­atomic  values such as nested relations. n Preserve relational foundations, in particular the declarative access to  data, while extending modeling power. n Upward compatibility with existing relational languages. ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Complex Data Types n Motivation: l Permit non­atomic domains (atomic ≡ indivisible) l Example of non­atomic domain:  set of integers,or set of  tuples l Allows more intuitive modeling for applications with  complex data n Intuitive definition: l allow relations whenever we allow atomic (scalar) values  — relations within relations l Retains mathematical foundation of relational model  l Violates first normal form. ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Example of a Nested Relation n Example:  library information system n Each book has  l title,  l a set of authors, l Publisher, and l a set of keywords n Non­1NF relation books ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. 4NF Decomposition of Nested Relation n Remove awkwardness of flat­books by assuming that the following  multivalued dependencies hold: l title       author l title       keyword l title       pub­name, pub­branch n Decompose flat­doc into 4NF using the schemas: l (title, author ) l (title, keyword ) l (title, pub­name, pub­branch ) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. 4NF Decomposition of flat–books ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Problems with 4NF Schema n 4NF design requires users to include joins in their queries. n 1NF relational view flat­books defined by join of 4NF relations: l eliminates the need for users to perform joins, l but loses the one­to­one correspondence between tuples and  documents. l And has a large amount of redundancy n Nested relations representation is much more natural here. ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Complex Types and SQL:1999 n Extensions to SQL to support complex types include: l Collection and large object types  Nested relations are an example of collection types l Structured types  Nested record structures like composite attributes  l Inheritance l Object orientation  Including object identifiers and references n Our description is mainly based on the SQL:1999 standard l Not fully implemented in any database system currently l But some features are present in each of the major commercial  database systems  Read the manual of your database system to see what it  supports ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Structured Types and Inheritance in SQL n Structured types can be declared and used in SQL       create type Name as     (firstname          varchar(20),      lastname           varchar(20))      final create type Address as     (street          varchar(20),      city    varchar(20),      zipcode   varchar(20)) not final l Note: final and not final  indicate whether subtypes can be created n Structured types can be used to create tables with composite attributes             create table customer ( name Name, address Address, dateOfBirth date) n Dot notation used to reference components: name.firstname ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Structured Types (cont.) n User­defined row types create type CustomerType as ( name Name, address Address, dateOfBirth date) not final n Can then create a table whose rows are a user­defined type create table customer of CustomerType ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Methods n Can add a method declaration with a structured type. method ageOnDate (onDate date) returns interval year n Method body is given separately. create instance method ageOnDate (onDate date) returns interval year for CustomerType begin return onDate ­ self.dateOfBirth; end n We can now find the age of each customer: select name.lastname, ageOnDate (current_date) from customer ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Inheritance n Suppose that we have the following type definition for people: create type Person (name varchar(20), address varchar(20)) n Using inheritance to define the student and teacher types create type Student under Person (degree varchar(20), department varchar(20)) create type Teacher under Person (salary integer, department varchar(20)) n Subtypes can redefine methods by using overriding method in place of method in the method declaration ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Multiple Inheritance n SQL:1999 and SQL:2003 do not support multiple inheritance n If our type system supports multiple inheritance, we can define a type for teaching assistant as follows: create type Teaching Assistant under Student, Teacher n To avoid a conflict between the two occurrences of department we can rename them create type Teaching Assistant under Student with (department as student_dept ), Teacher with (department as teacher_dept ) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Consistency Requirements for Subtables n Consistency requirements on subtables and supertables. l Each tuple of the supertable (e.g. people) can correspond to at most  one tuple in each of the subtables (e.g. students and teachers) l Additional constraint in SQL:1999: All tuples corresponding to each other (that is, with the same values  for inherited attributes) must be derived from one tuple (inserted into  one table).     That is, each entity must have a most specific type  We cannot have a tuple in people corresponding to a tuple each  in students and teachers  ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Array and Multiset Types in SQL n Example of array and multiset declaration:       create type Publisher as     (name             varchar(20),      branch            varchar(20))     create type Book as     (title                 varchar(20),      author­array   varchar(20) array [10],      pub­date         date,      publisher        Publisher,      keyword­set   varchar(20) multiset )           create table books of Book n Similar to the nested relation books, but with array of authors  instead of set ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Creation of Collection Values n Array construction array [‘ Silberschatz’ ,`Korth’ ,`Sudarshan’ ] n Multisets l multisetset [‘ computer’ , ‘ database’ , ‘ SQL’ ] n To create a tuple of the type defined by the books relation: (‘ Compilers’ , array[`Smith’ ,`Jones’ ], Publisher (`McGraw-Hill’ ,`New York’ ), multiset [`parsing’ ,`analysis’ ]) n To insert the preceding tuple into the relation books insert into books values (‘ Compilers’ , array[`Smith’ ,`Jones’ ], Publisher (`McGraw-Hill’ ,`New York’ ), multiset [`parsing’ ,`analysis’ ]) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Querying Collection­Valued Attributes n To find all books that have the word “database” as a keyword, select title from books where ‘database’ in (unnest(keyword­set )) n We can access individual elements of an array by using indices l E.g.: If we know that a particular book has three authors, we could write: select author­array[1], author­array[2], author­array[3] from books where title = `Database System Concepts’ n To get a relation containing pairs of the form “title, author­name” for each  book and each author of the book                select B.title, A.author from books as B, unnest (B.author­array) as A (author ) n To retain ordering information we add a with ordinality clause   select B.title, A.author, A.position from books as B, unnest (B.author­array) with ordinality as  A (author, position ) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Unnesting n The transformation of a nested relation into a form with fewer (or no)  relation­valued attributes us called unnesting. n E.g.       select title, A as author, publisher.name as pub_name,               publisher.branch as pub_branch, K.keyword       from books as B, unnest(B.author_array ) as A (author ), unnest (B.keyword_set ) as K (keyword ) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Nesting  n Nesting is the opposite of unnesting, creating a collection­valued attribute n NOTE: SQL:1999 does not support nesting n Nesting can be done in a manner similar to aggregation, but using the function  colect() in place of an aggregation operation, to create a multiset n To nest the flat­books relation on the attribute keyword: select title, author, Publisher (pub_name, pub_branch ) as publisher,             collect (keyword)  as keyword_set from flat­books groupby title, author, publisher n To nest on both authors and keywords:       select title, collect (author ) as author_set,              Publisher (pub_name, pub_branch) as publisher,              collect  (keyword ) as keyword_set from   flat­books group by title, publisher ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. 1NF Version of Nested Relation 1NF version of books flat­books ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Nesting (Cont.) n Another approach to creating nested relations is to use subqueries in  the select clause.  select title,  array ( select author    from authors as A    where A.title = B.title              order by A.position) as author_array,  Publisher (pub­name, pub­branch) as publisher,  multiset (select keyword    from keywords as K    where K.title = B.title) as keyword_set from books4 as B ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Object­Identity and Reference Types n Define a type Department with a field name and a field head which is a  reference to the type Person, with table people as scope:      create type Department (        name varchar (20),        head ref (Person) scope people) n We can then create a table departments as follows              create table departments of Department n We can omit the declaration scope people from the type declaration and  instead make an addition to the create table statement: create table departments of Department        (head with options scope people) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Initializing Reference­Typed Values n To create a tuple with a reference value, we can first create the tuple  with a null reference and then set the reference separately: insert into departments        values (`CS’, null) update departments      set head = (select p.person_id                  from people as p      where name = `John’)      where name = `CS’ ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. User Generated Identifiers n The type of the object­identifier must be specified as part of the type  definition of the referenced table, and n The table definition must specify that the reference is user generated         create type Person             (name varchar(20)              address varchar(20))            ref using varchar(20)         create table people of Person           ref is person_id user generated n When creating a tuple, we must provide a unique value for the identifier:        insert into people (person_id, name, address ) values       (‘01284567’, ‘John’, `23 Coyote Run’) n We can then use the identifier value when inserting a tuple into  departments l Avoids need for a separate query to retrieve the identifier:            insert into departments            values(`CS’, `02184567’) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. User Generated Identifiers (Cont.) n Can use an existing primary key value as the identifier:  create type Person       (name varchar (20) primary key,        address varchar(20))     ref from (name) create table people of Person     ref is person_id derived n When inserting a tuple for departments, we can then use insert into departments     values(`CS’,`John’) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Path Expressions n Find the names and addresses of the heads of all departments: select head – >name, head  – >address from departments n An expression such as “head– >name” is called a path expression n Path expressions help avoid explicit joins l If department head were not a reference, a join of departments  with people would be required to get at the address l Makes expressing the query much easier for the user ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Implementing O­R Features n Similar to how E­R features are mapped onto relation schemas n Subtable implementation l Each table stores primary key and those attributes defined in that  table or, l Each table stores both locally defined and inherited attributes ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Persistent Programming Languages n Languages extended with constructs to handle persistent data n Programmer can manipulate persistent data directly l no need to fetch it into memory and store it back to disk (unlike  embedded SQL) n Persistent objects: l by class ­ explicit declaration of persistence l by creation ­ special syntax to create persistent objects l by marking ­ make objects persistent after creation  l by reachability ­ object is persistent if it is declared explicitly to be  so or is reachable from a persistent object ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Object Identity and Pointers n Degrees of permanence of object identity l Intraprocedure: only during execution of a single procedure l Intraprogram: only during execution of a single program or query l Interprogram: across program executions, but not if data­storage  format on disk changes l Persistent: interprogram, plus persistent across data  reorganizations n Persistent versions of C++ and Java have been implemented l C++  ODMG C++  ObjectStore l Java  Java Database Objects (JDO) ©Silberschatz, Korth and Sudarshan9.Database System Concepts ­ 5th Edition, Aug 9, 2005. Comparison of O­O and O­R Databases n Relational systems l simple data types, powerful query languages, high protection. n Persistent­programming­language­based OODBs l complex data types, integration with programming language, high  performance. n Object­relational systems l complex data types, powerful query languages, high protection. n Note: Many real systems blur these boundaries l E.g. persistent programming language built as a wrapper on a  relational database offers first two benefits, but may have poor  performance. Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db­book.com for conditions on re­use  ©Silberschatz, Korth and SudarshanDatabase System Concepts End of Chapter