Download OO Databases & XML

Chapter 8: Object-Oriented Databases
 Need for Complex Data Types
 The Object-Oriented Data Model
 Object-Oriented Languages
 Persistent Programming Languages
 Persistent C++ Systems
Database System Concepts
8.1
©Silberschatz, Korth and Sudarshan
Need for Complex Data Types
 Traditional database applications in data processing had
conceptually simple data types
 Relatively few data types, first normal form holds
 Complex data types have grown more important in recent years
 E.g. Addresses can be viewed as a
 Single string, or
 Separate attributes for each part, or
 Composite attributes (which are not in first normal form)
 E.g. it is often convenient to store multivalued attributes as-is,
without creating a separate relation to store the values in first
normal form
 Applications
 computer-aided design, computer-aided software engineering
 multimedia and image databases, and document/hypertext
databases.
Database System Concepts
8.2
©Silberschatz, Korth and Sudarshan
Object-Oriented Data Model
 Loosely speaking, an object corresponds to an entity in the E-
R model.
 The object-oriented paradigm is based on encapsulating code
and data related to an object into single unit.
 The object-oriented data model is a logical data model (like
the E-R model).
 Adaptation of the object-oriented programming paradigm (e.g.,
Smalltalk, C++) to database systems.
Database System Concepts
8.3
©Silberschatz, Korth and Sudarshan
Object Structure
 An object has associated with it:
 A set of variables that contain the data for the object. The value of
each variable is itself an object.
 A set of messages to which the object responds; each message may
have zero, one, or more parameters.
 A set of methods, each of which is a body of code to implement a
message; a method returns a value as the response to the message
 The physical representation of data is visible only to the
implementor of the object
 Messages and responses provide the only external interface to an
object.
 The term message does not necessarily imply physical message
passing. Messages can be implemented as procedure
invocations.
Database System Concepts
8.4
©Silberschatz, Korth and Sudarshan
Object Classes
 Similar objects are grouped into a class; each such object is
called an instance of its class
 All objects in a class have the same
 Variables, with the same types
 message interface
 methods
The may differ in the values assigned to variables
 Example: Group objects for people into a person class
 Classes are analogous to entity sets in the E-R model
Database System Concepts
8.5
©Silberschatz, Korth and Sudarshan
Class Definition Example
class employee {
/*Variables */
string name;
string address;
date
start-date;
int
salary;
/* Messages */
int
annual-salary();
string get-name();
string get-address();
int
set-address(string new-address);
int
employment-length();
};
 Methods to read and set the other variables are also needed with
strict encapsulation
 Methods are defined separately
 E.g. int employment-length() { return today() – start-date;}
int set-address(string new-address) { address = new-address;}
Database System Concepts
8.6
©Silberschatz, Korth and Sudarshan
Inheritance (Cont.)
 Place classes into a specialization/IS-A hierarchy
 variables/messages belonging to class person are
inherited by class employee as well as customer
 Result is a class hierarchy
Note analogy with ISA Hierarchy in the E-R model
Database System Concepts
8.7
©Silberschatz, Korth and Sudarshan
Class Hierarchy Definition
class person{
string name;
string address:
};
class customer isa person {
int credit-rating;
};
class employee isa person {
date start-date;
int salary;
};
class officer isa employee {
int office-number,
int expense-account-number,
};
..
.
Database System Concepts
8.8
©Silberschatz, Korth and Sudarshan
Example of Multiple Inheritance
Class DAG for banking example.
Database System Concepts
8.9
©Silberschatz, Korth and Sudarshan
Object-Oriented Languages
 Object-oriented concepts can be used in different ways
 Object-orientation can be used as a design tool, and be
encoded into, for example, a relational database

analogous to modeling data with E-R diagram and then
converting to a set of relations)
 The concepts of object orientation can be incorporated into a
programming language that is used to manipulate the
database.
 Object-relational systems – add complex types and
object-orientation to relational language.
 Persistent programming languages – extend object-
oriented programming language to deal with databases
by adding concepts such as persistence and collections.
Database System Concepts
8.10
©Silberschatz, Korth and Sudarshan
End of Chapter
Chapter 9: Object-Relational Databases
 Nested Relations
 Complex Types and Object Orientation
 Querying with Complex Types
 Creation of Complex Values and Objects
 Comparison of Object-Oriented and Object-Relational
Databases
Database System Concepts
8.12
©Silberschatz, Korth and Sudarshan
Object-Relational Data Models
 Extend the relational data model by including object orientation
and constructs to deal with added data types.
 Allow attributes of tuples to have complex types, including non-
atomic values such as nested relations.
 Preserve relational foundations, in particular the declarative
access to data, while extending modeling power.
 Upward compatibility with existing relational languages.
Database System Concepts
8.13
©Silberschatz, Korth and Sudarshan
Example of a Nested Relation
 Example: library information system
 Each book has
 title,
 a set of authors,
 Publisher, and
 a set of keywords
 Non-1NF relation books
Database System Concepts
8.14
©Silberschatz, Korth and Sudarshan
1NF Version of Nested Relation
 1NF version of books
flat-books
Database System Concepts
8.15
©Silberschatz, Korth and Sudarshan
4NF Decomposition of Nested Relation
 Remove awkwardness of flat-books by assuming that the
following multivalued dependencies hold:
 title
author
 title
keyword
 title
pub-name, pub-branch
 Decompose flat-doc into 4NF using the schemas:
 (title, author)
 (title, keyword)
 (title, pub-name, pub-branch)
Database System Concepts
8.16
©Silberschatz, Korth and Sudarshan
4NF Decomposition of flat–books
Database System Concepts
8.17
©Silberschatz, Korth and Sudarshan
Problems with 4NF Schema
 4NF design requires users to include joins in their queries.
 1NF relational view flat-books defined by join of 4NF relations:
 eliminates the need for users to perform joins,
 but loses the one-to-one correspondence between tuples and
documents.
 And has a large amount of redundancy
 Nested relations representation is much more natural here.
Database System Concepts
8.18
©Silberschatz, Korth and Sudarshan
Structured and Collection Types
 Structured types can be declared and used in SQL
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 setof(varchar(20)))
 Note: setof declaration of keyword-set is not supported by SQL:1999
 Using an array to store authors lets us record the order of the authors
 Structured types can be used to create tables
create table books of Book
 Similar to the nested relation books, but with array of authors
instead of set
Database System Concepts
8.19
©Silberschatz, Korth and Sudarshan
Structured Types (Cont.)
 We can create tables without creating an intermediate type
 For example, the table books could also be defined as follows:
create table books
(title varchar(20),
author-array varchar(20) array[10],
pub-date date,
publisher Publisher
keyword-list setof(varchar(20)))
 Methods can be part of the type definition of a structured type:
create type Employee as (
name varchar(20),
salary integer)
method giveraise (percent integer)
 We create the method body separately
create method giveraise (percent integer) for Employee
begin
set self.salary = self.salary + (self.salary * percent) / 100;
end
Database System Concepts
8.20
©Silberschatz, Korth and Sudarshan
Inheritance
 Suppose that we have the following type definition for people:
create type Person
(name varchar(20),
address varchar(20))
 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))
 Subtypes can redefine methods by using overriding method in place
of method in the method declaration
Database System Concepts
8.21
©Silberschatz, Korth and Sudarshan
Multiple Inheritance
 SQL:1999 does not support multiple inheritance
 If our type system supports multiple inheritance, we can define a
type for teaching assistant as follows:
create type Teaching Assistant
under Student, Teacher
 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)
Database System Concepts
8.22
©Silberschatz, Korth and Sudarshan
Collection Valued Attributes (Cont.)
 We can access individual elements of an array by using indices
 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’
Database System Concepts
8.23
©Silberschatz, Korth and Sudarshan
SQL Functions
 Define a function that, given a book title, returns the count of the
number of authors (on the 4NF schema with relations books4
and authors).
create function author-count(name varchar(20))
returns integer
begin
declare a-count integer;
select count(author) into a-count
from authors
where authors.title=name
return a=count;
end
 Find the titles of all books that have more than one author.
select name
from books4
where author-count(title)> 1
Database System Concepts
8.24
©Silberschatz, Korth and Sudarshan
Procedural Constructs
 SQL:1999 supports a rich variety of procedural constructs
 Compound statement
 is of the form begin … end,
 may contain multiple SQL statements between begin and end.
 Local variables can be declared within a compound statements
 While and repeat statements
declare n integer default 0;
while n < 10 do
set n = n+1
end while
repeat
set n = n – 1
until n = 0
end repeat
Database System Concepts
8.25
©Silberschatz, Korth and Sudarshan
Procedural Constructs (Cont.)
 For loop
 Permits iteration over all results of a query
 E.g. find total of all balances at the Perryridge branch
declare n integer default 0;
for r as
select balance from account
where branch-name = ‘Perryridge’
do
set n = n + r.balance
end for
Database System Concepts
8.26
©Silberschatz, Korth and Sudarshan
Comparison of O-O and O-R Databases
 Summary of strengths of various database systems:
 Relational systems
 simple data types, powerful query languages, high protection.
 Persistent-programming-language-based OODBs
 complex data types, integration with programming language, high
performance.
 Object-relational systems
 complex data types, powerful query languages, high protection.
 Note: Many real systems blur these boundaries
 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
8.27
©Silberschatz, Korth and Sudarshan
End of Chapter
Chapter 10: XML
Introduction
 XML: Extensible Markup Language
 Defined by the WWW Consortium (W3C)
 Originally intended as a document markup language not a
database language
 Documents have tags giving extra information about sections of the
document
 E.g. <title> XML </title> <slide> Introduction …</slide>
 Derived from SGML (Standard Generalized Markup Language), but
simpler to use than SGML
 Extensible, unlike HTML
 Users can add new tags, and separately specify how the tag should
be handled for display
 Goal was (is?) to replace HTML as the language for publishing
documents on the Web
Database System Concepts
8.30
©Silberschatz, Korth and Sudarshan
XML Introduction (Cont.)
 The ability to specify new tags, and to create nested tag structures
made XML a great way to exchange data, not just documents.
 Much of the use of XML has been in data exchange applications, not as a
replacement for HTML
 Tags make data (relatively) self-documenting
 E.g.
<bank>
<account>
<account-number> A-101 </account-number>
<branch-name>
Downtown </branch-name>
<balance>
500
</balance>
</account>
<depositor>
<account-number> A-101 </account-number>
<customer-name> Johnson </customer-name>
</depositor>
</bank>
Database System Concepts
8.31
©Silberschatz, Korth and Sudarshan
XML: Motivation
 Data interchange is critical in today’s networked world
 Examples:
 Banking: funds transfer
 Order processing (especially inter-company orders)
 Scientific data
– Chemistry: ChemML, …
– Genetics:
BSML (Bio-Sequence Markup Language), …
 Paper flow of information between organizations is being replaced
by electronic flow of information
 Each application area has its own set of standards for
representing information
 XML has become the basis for all new generation data
interchange formats
Database System Concepts
8.32
©Silberschatz, Korth and Sudarshan
XML Motivation (Cont.)
 Earlier generation formats were based on plain text with line
headers indicating the meaning of fields
 Similar in concept to email headers
 Does not allow for nested structures, no standard “type” language
 Tied too closely to low level document structure (lines, spaces, etc)
 Each XML based standard defines what are valid elements, using
 XML type specification languages to specify the syntax
 DTD (Document Type Descriptors)
 XML Schema
 Plus textual descriptions of the semantics
 XML allows new tags to be defined as required
 However, this may be constrained by DTDs
 A wide variety of tools is available for parsing, browsing and
querying XML documents/data
Database System Concepts
8.33
©Silberschatz, Korth and Sudarshan
Structure of XML Data
 Tag: label for a section of data
 Element: section of data beginning with <tagname> and ending
with matching </tagname>
 Elements must be properly nested
 Proper nesting
 <account> … <balance> …. </balance> </account>
 Improper nesting
 <account> … <balance> …. </account> </balance>
 Formally: every start tag must have a unique matching end tag,
that is in the context of the same parent element.
 Every document must have a single top-level element
Database System Concepts
8.34
©Silberschatz, Korth and Sudarshan
Example of Nested Elements
<bank-1>
<customer>
<customer-name> Hayes </customer-name>
<customer-street> Main </customer-street>
<customer-city> Harrison </customer-city>
<account>
<account-number> A-102 </account-number>
<branch-name>
Perryridge </branch-name>
<balance>
400 </balance>
</account>
<account>
…
</account>
</customer>
.
.
</bank-1>
Database System Concepts
8.35
©Silberschatz, Korth and Sudarshan
Motivation for Nesting
 Nesting of data is useful in data transfer
 Example: elements representing customer-id, customer name, and
address nested within an order element
 Nesting is not supported, or discouraged, in relational databases
 With multiple orders, customer name and address are stored
redundantly
 normalization replaces nested structures in each order by foreign key
into table storing customer name and address information
 Nesting is supported in object-relational databases
 But nesting is appropriate when transferring data
 External application does not have direct access to data referenced
by a foreign key
Database System Concepts
8.36
©Silberschatz, Korth and Sudarshan
Structure of XML Data (Cont.)
 Mixture of text with sub-elements is legal in XML.
 Example:
<account>
This account is seldom used any more.
<account-number> A-102</account-number>
<branch-name> Perryridge</branch-name>
<balance>400 </balance>
</account>
 Useful for document markup, but discouraged for data
representation
Database System Concepts
8.37
©Silberschatz, Korth and Sudarshan
Attributes
 Elements can have attributes
<account acct-type = “checking” >

<account-number> A-102 </account-number>
<branch-name> Perryridge </branch-name>
<balance> 400 </balance>
</account>
 Attributes are specified by name=value pairs inside the starting
tag of an element
 An element may have several attributes, but each attribute name
can only occur once
 <account acct-type = “checking” monthly-fee=“5”>
Database System Concepts
8.38
©Silberschatz, Korth and Sudarshan
Attributes Vs. Subelements
 Distinction between subelement and attribute
 In the context of documents, attributes are part of markup, while
subelement contents are part of the basic document contents
 In the context of data representation, the difference is unclear and
may be confusing
 Same information can be represented in two ways
– <account account-number = “A-101”> …. </account>
– <account>
<account-number>A-101</account-number> …
</account>
 Suggestion: use attributes for identifiers of elements, and use
subelements for contents
Database System Concepts
8.39
©Silberschatz, Korth and Sudarshan
More on XML Syntax
 Elements without subelements or text content can be abbreviated
by ending the start tag with a /> and deleting the end tag
 <account number=“A-101” branch=“Perryridge” balance=“200 />
 To store string data that may contain tags, without the tags being
interpreted as subelements, use CDATA as below
 <![CDATA[<account> … </account>]]>
 Here, <account> and </account> are treated as just strings
Database System Concepts
8.40
©Silberschatz, Korth and Sudarshan
XML Document Schema
 Database schemas constrain what information can be stored,
and the data types of stored values
 XML documents are not required to have an associated schema
 However, schemas are very important for XML data exchange
 Otherwise, a site cannot automatically interpret data received from
another site
 Two mechanisms for specifying XML schema
 Document Type Definition (DTD)
 Widely used
 XML Schema
 Newer, not yet widely used
Database System Concepts
8.41
©Silberschatz, Korth and Sudarshan
Document Type Definition (DTD)
 The type of an XML document can be specified using a DTD
 DTD constraints structure of XML data
 What elements can occur
 What attributes can/must an element have
 What subelements can/must occur inside each element, and how
many times.
 DTD does not constrain data types
 All values represented as strings in XML
 DTD syntax
 <!ELEMENT element (subelements-specification) >
 <!ATTLIST element (attributes) >
Database System Concepts
8.42
©Silberschatz, Korth and Sudarshan
Element Specification in DTD
 Subelements can be specified as
 names of elements, or
 #PCDATA (parsed character data), i.e., character strings
 EMPTY (no subelements) or ANY (anything can be a subelement)
 Example
<! ELEMENT depositor (customer-name account-number)>
<! ELEMENT customer-name(#PCDATA)>
<! ELEMENT account-number (#PCDATA)>
 Subelement specification may have regular expressions
<!ELEMENT bank ( ( account | customer | depositor)+)>
 Notation:
– “|” - alternatives
– “+” - 1 or more occurrences
– “*” - 0 or more occurrences
Database System Concepts
8.43
©Silberschatz, Korth and Sudarshan
Bank DTD
<!DOCTYPE bank [
<!ELEMENT bank ( ( account | customer | depositor)+)>
<!ELEMENT account (account-number branch-name balance)>
<! ELEMENT customer(customer-name customer-street
customer-city)>
<! ELEMENT depositor (customer-name account-number)>
<! ELEMENT account-number (#PCDATA)>
<! ELEMENT branch-name (#PCDATA)>
<! ELEMENT balance(#PCDATA)>
<! ELEMENT customer-name(#PCDATA)>
<! ELEMENT customer-street(#PCDATA)>
<! ELEMENT customer-city(#PCDATA)>
]>
Database System Concepts
8.44
©Silberschatz, Korth and Sudarshan
XML Schema
 XML Schema is a more sophisticated schema language which
addresses the drawbacks of DTDs. Supports
 Typing of values
 E.g. integer, string, etc
 Also, constraints on min/max values
 User defined types
 Is itself specified in XML syntax, unlike DTDs
 More standard representation, but verbose
 Is integrated with namespaces
 Many more features
 List types, uniqueness and foreign key constraints, inheritance ..
 BUT: significantly more complicated than DTDs, not yet widely
used.
Database System Concepts
8.45
©Silberschatz, Korth and Sudarshan
XML Schema Version of Bank DTD
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<xsd:element name=“bank” type=“BankType”/>
<xsd:element name=“account”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=“account-number” type=“xsd:string”/>
<xsd:element name=“branch-name”
type=“xsd:string”/>
<xsd:element name=“balance”
type=“xsd:decimal”/>
</xsd:squence>
</xsd:complexType>
</xsd:element>
….. definitions of customer and depositor ….
<xsd:complexType name=“BankType”>
<xsd:squence>
<xsd:element ref=“account” minOccurs=“0” maxOccurs=“unbounded”/>
<xsd:element ref=“customer” minOccurs=“0” maxOccurs=“unbounded”/>
<xsd:element ref=“depositor” minOccurs=“0” maxOccurs=“unbounded”/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Database System Concepts
8.46
©Silberschatz, Korth and Sudarshan
Querying and Transforming XML Data
 Translation of information from one XML schema to another
 Querying on XML data
 Above two are closely related, and handled by the same tools
 Standard XML querying/translation languages
 XPath
 Simple language consisting of path expressions
 XSLT
 Simple language designed for translation from XML to XML and
XML to HTML
 XQuery
 An XML query language with a rich set of features
 Wide variety of other languages have been proposed, and some
served as basis for the Xquery standard
 XML-QL, Quilt, XQL, …
Database System Concepts
8.47
©Silberschatz, Korth and Sudarshan
Tree Model of XML Data
 Query and transformation languages are based on a tree model of
XML data
 An XML document is modeled as a tree, with nodes corresponding
to elements and attributes
 Element nodes have children nodes, which can be attributes or
subelements
 Text in an element is modeled as a text node child of the element
 Children of a node are ordered according to their order in the XML
document
 Element and attribute nodes (except for the root node) have a single
parent, which is an element node
 The root node has a single child, which is the root element of the
document
 We use the terminology of nodes, children, parent, siblings,
ancestor, descendant, etc., which should be interpreted in the above
tree model of XML data.
Database System Concepts
8.48
©Silberschatz, Korth and Sudarshan
XPath
 XPath is used to address (select) parts of documents using
path expressions
 A path expression is a sequence of steps separated by “/”
 Think of file names in a directory hierarchy
 Result of path expression: set of values that along with their
containing elements/attributes match the specified path
 E.g.
/bank-2/customer/name evaluated on the bank-2 data
we saw earlier returns
<name>Joe</name>
<name>Mary</name>
 E.g.
/bank-2/customer/name/text( )
returns the same names, but without the enclosing tags
Database System Concepts
8.49
©Silberschatz, Korth and Sudarshan
XSLT
 A stylesheet stores formatting options for a document, usually
separately from document
 E.g. HTML style sheet may specify font colors and sizes for
headings, etc.
 The XML Stylesheet Language (XSL) was originally designed
for generating HTML from XML
 XSLT is a general-purpose transformation language
 Can translate XML to XML, and XML to HTML
 XSLT transformations are expressed using rules called
templates
 Templates combine selection using XPath with construction of
results
Database System Concepts
8.50
©Silberschatz, Korth and Sudarshan
XQuery
 XQuery is a general purpose query language for XML data
 Currently being standardized by the World Wide Web Consortium
(W3C)
 The textbook description is based on a March 2001 draft of the standard.
The final version may differ, but major features likely to stay unchanged.
 Alpha version of XQuery engine available free from Microsoft
 XQuery is derived from the Quilt query language, which itself borrows
from SQL, XQL and XML-QL
 XQuery uses a
for … let … where .. result …
syntax
for
 SQL from
where  SQL where
result  SQL select
let allows temporary variables, and has no equivalent in SQL
Database System Concepts
8.51
©Silberschatz, Korth and Sudarshan
FLWR Syntax in XQuery
 For clause uses XPath expressions, and variable in for clause
ranges over values in the set returned by XPath
 Simple FLWR expression in XQuery
 find all accounts with balance > 400, with each result enclosed in
an <account-number> .. </account-number> tag
for
$x in /bank-2/account
let
$acctno := $x/@account-number
where $x/balance > 400
return <account-number> $acctno </account-number>
 Let clause not really needed in this query, and selection can be done
In XPath. Query can be written as:
for $x in /bank-2/account[balance>400]
return <account-number> $X/@account-number
</account-number>
Database System Concepts
8.52
©Silberschatz, Korth and Sudarshan
Storage of XML Data
 XML data can be stored in
 Non-relational data stores
 Flat files
– Natural for storing XML
– But has all problems discussed in Chapter 1 (no concurrency,
no recovery, …)
 XML database
– Database built specifically for storing XML data, supporting
DOM model and declarative querying
– Currently no commercial-grade systems
 Relational databases
 Data must be translated into relational form
 Advantage: mature database systems
 Disadvantages: overhead of translating data and queries
Database System Concepts
8.53
©Silberschatz, Korth and Sudarshan
Storing XML in Relational Databases
 Store as string
 E.g. store each top level element as a string field of a tuple in a database
 Use a single relation to store all elements, or
 Use a separate relation for each top-level element type
– E.g. account, customer, depositor
– Indexing:
» Store values of subelements/attributes to be indexed, such as
customer-name and account-number as extra fields of the
relation, and build indices
» Oracle 9 supports function indices which use the result of a
function as the key value. Here, the function should return the
value of the required subelement/attribute
 Benefits:
 Can store any XML data even without DTD
 As long as there are many top-level elements in a document, strings are
small compared to full document, allowing faster access to individual
elements.
 Drawback: Need to parse strings to access values inside the elements;
parsing is slow.
Database System Concepts
8.54
©Silberschatz, Korth and Sudarshan
Storing XML as Relations (Cont.)
 Tree representation: model XML data as tree and store using
relations
nodes(id, type, label, value)
child (child-id, parent-id)
 Each element/attribute is given a unique identifier
 Type indicates element/attribute
 Label specifies the tag name of the element/name of attribute
 Value is the text value of the element/attribute
 The relation child notes the parent-child relationships in the tree
 Can add an extra attribute to child to record ordering of children
 Benefit: Can store any XML data, even without DTD
 Drawbacks:
 Data is broken up into too many pieces, increasing space overheads
 Even simple queries require a large number of joins, which can be slow
Database System Concepts
8.55
©Silberschatz, Korth and Sudarshan
Storing XML in Relations (Cont.)
 Map to relations
 If DTD of document is known, can map data to relations
 Bottom-level elements and attributes are mapped to attributes of relations
 A relation is created for each element type
 An id attribute to store a unique id for each element
 all element attributes become relation attributes
 All subelements that occur only once become attributes
– For text-valued subelements, store the text as attribute value
– For complex subelements, store the id of the subelement
 Subelements that can occur multiple times represented in a separate
table
– Similar to handling of multivalued attributes when converting ER
diagrams to tables
 Benefits:
 Efficient storage
 Can translate XML queries into SQL, execute efficiently, and then
translate SQL results back to XML
 Drawbacks: need to know DTD, translation overheads still present
Database System Concepts
8.56
©Silberschatz, Korth and Sudarshan