Perl Cd Bookshelf [Electronic resources] نسخه متنی

Database Schema and XML Documents

XML documents consist of text that conforms to a hierarchy or tree structure specified by a DTD or XML Schema. As distinct from other strictly relational databases, you can easily store this hierarchical data in an optimal internal form using Oracle’s object-relational tables, which serve as the foundation for the native XMLType storage. All the existing and future internal applications can work with the information in the most efficient way possible. When you retrieve information, for sharing with partners or other applications, you can present the appropriate view of data and document content specific to the task at hand as integrated XML. These XMLType views enable you to present data in any number of “logical” combinations, hiding any details of their underlying physical storage. You can effectively transform the structure of one or more underlying tables into a more useful or more appropriate structure for the demands of a specific application. When you link views of information with other views of related information, they quite naturally form “trees” or “graphs” of related data. When you represent database information as XML, the previous related views provide the foundation for many different tree-structured XML documents.

Here, we offer a simple example of how a database table would be expressed as an XML DTD:

<!DOCTYPE table [
<!ELEMENT table (rows)*>
<!ELEMENT rows (column1, column2, ...)>
<!ELEMENT column1 (#PCDATA)>
<!ELEMENT column2 (#PCDATA)>
...]>

Note, however, that the actual data types in these columns remain unspecified. We can instead use an XML Schema of the following form:

<xs:element name="table">
<xs:sequence>
<xs:element name="rows">
<xs:sequence >
<xs:element name="column1" type="xs:integer" xdb:SQLType="NUMBER"/>
<xs:element name="column2" type="xs:string" xdb:SQLType="CLOB"/>
. . .

This does provide us with the column data types through the type attribute which can further constrain the data as we will discuss later in the database chapters. However, a database provides even more capability to express rules than does a DTD or an XML Schema. The database schema defines type information and constraints—not only simple constraints, such as permissible value ranges, but also constraints between columns and tables. A database schema enables you to define relationships or dependencies. For example, your e-commerce business might receive orders as XML documents. By using a database, you can link customer and order information, and define a rule about not processing orders for closed accounts. In spite of the limitations in DTDs or XML Schemas, mapping a database schema to a DTD or an XML Schema presents the database as a virtual XML document to the tools that need XML documents as input.

Mapping XML Documents to a Database Schema

When mapping XML documents associated with an XML DTD or an XSD to a database schema for the purpose of storing XML in Oracle, three basic strategies exist:

Map the complete XML document as a single, intact object, such as an XMLType CLOB.

Store the data in relational or object-relational tables and create XMLType views over the data to present it as an XML document.

Map XML documents to an Oracle Native XMLType.

You can choose one of the previous approaches, depending on the structure of the XML document and the operations performed by the application. Each of these three approaches is described in turn next. You can also store the XML DTD or Schema in the database to validate the XML documents.

XML Documents Stored As XMLType CLOBs

Storing an intact XML document in an XMLType CLOB is a good strategy if the XML document contains static content that will only be retrieved as a whole or updated by replacing the entire document. Examples include written text such as articles, advertisements, books, legal briefs, and contracts. Applications that use a repository of this nature are known as document-centric and operate on the stored XML outside the database. Storing this kind of document intact within OracleX gives you the advantages of an industry-proven database and its reliability over file system storage. Upon insertion, XML documents are checked and only committed if well formed. Oracle Text can provide both content and path indexes to search, but data retrievals need to be done by processing the whole document. The Oracle XML Developer’s Kit (XDK) provides the functionality to use standards-based interfaces to access, modify, transform, and validate these documents.

XMLType CLOBs can also be used in conjunction with XMLType views and the Native XMLType described in the following sections. In these cases, the XML is a well-formed fragment that is treated as a whole.

XML Documents Stored As XMLType Views

When an application is using XML merely as an encapsulation of its data, it is considered to be data-centric. Typically, the XML document contains elements and attributes that have complex structures, but in reality this structure is simply metadata to convey the actual data of interest. Examples of this kind of document include sales orders, invoices, and airline flight schedules. In this case, there is value to maintaining the storage as SQL data because the actual data types need to be exposed to the application. Oracle Database 10g, with its XMLType object-relational extensions, has the capability to capture the structure of the data in the database present it in an XMLType view while still you can easily update, query, rearrange, and reformat as needed using SQL. The important distinction to remember is that this view cannot convey document order, comments, processing instructions, or the whitespace between elements and attributes that are preserved in the CLOB type.

Using XMLType views is especially useful when you are XML-enabling existing applications or database schemas. This view can serve to abstract the underlying database schema, thereby eliminating the need to modify it to support XML. In fact, since you can have multiple views of differing XML structure over the same database schema, you can directly support a different XML schema for each view without the need to apply XSL to transform the documents to a structure compatible with your database schema.

Applications built against XMLType views have the flexibility of using SQL and SQL-XML interfaces to process within the database and using the XDK to process either in JServer, middle tier, or client.

XML Documents Stored As Native XMLTypes

Finally, you can store an XML document as a Native XMLType, where the underlying storage is dictated and created by its XML schema. This type has the advantages of the other two types together because it stores the XML as SQL data and preserves byte-for-byte fidelity. Creating this native type is as simple as registering its XML schema, which not only creates the underlying database schema but also creates a database resource that can be used for access and updates with the Internet-standard protocols HTTP, FTP, and WebDAV.

Applications that need both a document and data view can make full use of this type, because an extensive array of SQL, PL/SQL, Java, C, and C++ interfaces is available. Inserts, updates, and deletes are simplified due to Native XMLType’s support for query rewrites, thereby eliminating the triggers needed by the XMLType views. The Native XMLType can, however, be used in conjunction with these views to expose differing or subset XML documents. To further support large documents, a “virtual” or “lazy” DOM is provided through the XDK to access only those elements that are needed at any one time.

While the native XMLType exposes broad functionality, you need to remember that the underlying storage is intimately tied to the XML schema that created it. Therefore, it will most likely not be the best choice for applications that need to support multiple schemas or a nontrivial evolving schema.