(8) Generic XML Storage

• Relational databases are the state of the art since 1976
  • this is long enough to build highly optimized and robust systems
  • this is long enough to have ER hard-wired into some brains
• XML is more powerful than ER
  • repetitions of elements do not map well
  • choices do not map well
  • ordered content does not map well
  • mixed content does not map well
• Storing XML in a relational database is hard
  • it can be done by piggybacking structural information as content
  • using the resulting structures is awkward and very inefficient

(9) Tree Table

ID Type Name Value Parent Left 1 Root 2 Element a 1 3 Element b 2 4 Element c 2 3 5 Text Text 3 6 Attribute att 42 4

(11) Why XML and Databases?

• XML is becoming increasingly popular
  • XML as a document format was first used as wire format
• What is XML for an application?
  • an (increasingly popular) way to represent the data?
  • the data itself?
  • currently, the representation perspective is more popular
  • as XML is increasingly penetrating applications, this may change

(12) XML Interchange

(13) XML Support in DBMS

(14) XML DBMS

(16) Model Mapping

• Relational databases are not good tools for storing XML
  • they might be appropriate if the schema disallows problematic constructs
  • they often are already deployed and applications must live with them
• If the data model is ER-oriented, relational databases are good tools
  • metadata typically is a good fit for tables
• If the XML is not visible in the model, it can be structurally inaccessible
  • e.g., a product catalog may contain product descriptions in XHTML rich text snippets
  • for managing the product catalog data, the XHTML is not relevant
• If the XML is part of the model, it should be accessible structurally
  • if the product catalog XHTML contains links to other products, these links are important
  • if they are hidden in the XHTML, all XHTML snippets have to be parsed
  • ideally, the database should be able to query the XHTML snippet

(17) XML is Text

• XML documents can be stored as text
  • databases typically have various datatypes for text storage
  • if the database supports Unicode, any XML document can be stored
• The XML structure is completely invisible to the database
  • working with the XML requires querying and parsing the XML text
  • this kind of storage does not allow any querying of the XML content

(18) XML → ∗LOB

(19) XML as a Datatype

• SQL supports a wide variety of datatypes
  • typed values are better than untyped values (they enable type-specific operations)
  • XML can be regarded as just another data type
• Introducing a datatype lets the database recognize the data
  • XML data can be stored in some format (a persistent DOM)
  • databases can provide functionality avoiding parsing/serialization (DOM-based)

(20) XML Datatype

(21) Mapping XML to Models

• Model-relevant data must be mapped to the database structures
  • this assumes there is a ER-model which describes the database structure
  • mapping XML is easy by definition because the XML is ER-compliant
• Is the data accessed as table data?
  • if shredded data is only used to assemble it again, it is just performance overhead
  • if shredded data is accessed relationally, then shredding makes sense

(22) Shredding (XML → Columns)

(23) XML as First-Class Citizen

• The XML Datatype [XML Datatype (1)] defines XML as a sub-concept of ER
  • the overall structure of the database is relational
  • attributes may be of type XML, which means storing trees in tables
• Tables are not the only way to see the world
  • XML trees are an alternative to tables, not a datatype
  • XML-centric applications should not be forced to use tables at all
• XML can be regarded as replacing the ER-concept altogether
  • the database simply stores XML documents
  • applications can store, query, update, and manage XML documents in the database

(24) XML DBMS

(26) RDBish XML

• XML schemas can be designed with databases in mind
  • avoid unbounded repetitions of elements
  • avoid choices
  • avoid ordered content
  • avoid mixed content
  • avoid recursion
• Many XML schemas are designed RDBish for compatibility reasons
  • it was decided that the XML should allow easy mapping to tables
  • the person designing the schema thinks in ER
  • the schema has been generated from a relational database schema

(27) Problematic XML

• XML in its full glory is too much for tables
  • XML has been developed as a document format
  • XML is about hierarchy (which intentionally have been left out of ER)
  • XML is about highly irregular structures
• XML often is said to have two flavors
  • data-oriented XML: regular data which can be easily mapped to tables
  • document-oriented XML: irregular structures which are hard to map to tables
  • real-world XML often is a bit of both (e.g., content and metadata)
• Hybrid approaches sometimes are a good solution
  • data-oriented can be shredded and stored in tables
  • the document-oriented rest is stored as one object (text or XML)

(33) Tables and Trees don't Mix

• Tables and trees are different metamodels
• Different technologies are used to handle these different models
• Think before choosing the wrong tool

(34) Database Technologies do Mix

• Relational databases are good tools for regular data
• XML databases are good tools for documents
• SQL/XML:2007 defines a database that supports both
• Applications can choose the best mix of tables and trees