2
Getting Started with Oracle XML DB

This chapter provides some preliminary design criteria for consideration when planning your Oracle XML DB solution. It contains the following sections:

Getting Started with Oracle XML DB

Installing Oracle XML DB

Oracle XML DB is installed as part of the General Purpose Database shipping with Oracle9i Release 2 (9.2) database. If you need to perform a manual installation or de-installation of the Oracle XML DB, see Appendix A, "Installing and Configuring Oracle XML DB" for further information.

When to Use the Oracle XML DB

Oracle XML DB is suited for any application where some or all of the data processed by the application is represented using XML. Oracle XML DB provides for high performance ingestion, storage, processing and retrieval of XML data. Additionally, it also provides the ability to quickly and easily generate XML from existing relational data.

The type of applications that Oracle XML DB is particularly suited to include:

Business-to-Business (B2B) and Application-to-Application (A2A) integration
Internet applications
Content-management applications
Messaging
Web Services

A typical Oracle XML DB application has one or more of the following requirements and characteristics:

Large numbers of XML documents must be ingested or generated
Large XML documents need to be processed or generated
High performance searching, both within a document and across a large collections of documents
High Levels of security. Fine grained control of security
Data processing must be contained in XML documents and data contained in traditional relational tables
Uses languages such as Java that support open standards such as SQL, XML, XPath, and XSLT
Accesses information using standard Internet protocols such as FTP, HTTP/WebDav, or JDBC
Full queriability from SQL and integration with analytic capabilities
Validation of XML documents is critical

Designing Your XML Application

Oracle XML DB provides you with the ability to fine tune how XML documents will be stored and processed in Oracle9i database. Depending on the nature of the application being developed, XML storage must have at least one of the following features

High performance ingestion and retrieval of XML documents
High performance indexing and searching of XML documents
Be able to update sections of an XML document
Manage highly either or both structured and non-structured XML documents

Oracle XML DB Design Issues: Introduction

This section discusses the preliminary design criteria you can consider when planning your Oracle XML DB application. Figure 2-1 provides an overview of your main design options for building Oracle XML DB applications.

a. Data

Will your data be highly structured (mostly XML), semi- structured (pseudo- structured), or mostly non-structured? If highly structured, will your table(s) be XML schema-based or non-schema-based? See "Oracle XML DB Application Design: a. How Structured Is Your Data?" and Chapter 3, "Using Oracle XML DB".

b. Access

How will other applications and users access your XML and other data? How secure must the access be? Do you need versioning? See "Oracle XML DB Application Design: b. Access Models".

c. Application Language

In which language(s) will you be programming your application? See "Oracle XML DB Application Design: c. Application Language".

d. Processing

Will you need to generate XML? See Chapter 10, "Generating XML Data from the Database".

How often will XML documents be accessed, updated, and manipulated? Will you need to update fragments or the whole document?

Will you need to transform the XML to HTML, WML, or other languages, and how will your application transform the XML? See Chapter 6, "Transforming and Validating XMLType Data".

Does your application need to be primarily database resident or work in both database and middle tier?

Is your application data-centric, document- and content-centric, or integrated (is both data- and document-centric). "Oracle XML DB Application Design: d. Processing Models".

Will you be exchanging XML data with other applications, across gateways? Will you need Advanced Queueing (AQ) or SOAP compliance? See Chapter 24, "Exchanging XML Data Using Advanced Queueing (AQ) and Oracle Streams".

Storage

How and where will you store the data, XML data, XML schema, and so on? See "Oracle XML DB Design: Storage Models".

Note:

Your choice of which models to choose in the preceding four categories, a through d, are typically related to each other. However, the storage model you choose is orthogonal to the choices you make for the other design models. In other words, choices you make for the other design modeling options are not dependent on the storage model option you choose.

Figure 2-1 Oracle XML DB Design Options

Text description of adxdb039.gif follows

Text description of the illustration adxdb039.gif

Oracle XML DB Application Design: a. How Structured Is Your Data?

Figure 2-2 shows the following data structure categories and associated suggested storage options:

Structured data. Is your data highly structured? In other words, is your data mostly XML data?
Semi/pseudo-structured data. Is your data semi/pseudo-structured? In other words does your data include some XML data?
Unstructured data. Is your data unstructured? In other words, is your data mostly non-XML data?

XML Schema-Based or Non-Schema-Based

Also consider the following data modeling questions:

If your application is XML schema-based:
- For structured data, you can use either Character Large Object (CLOB) or structured storage.
- For semi- or pseudo-structured data, you can use either CLOB, structured, or hybrid storage. Here your XML schema can be more loosely coupled. See also "Oracle XML DB Design: Storage Models".
- For unstructured data, an XML schema design is not applicable.
If your application is non-schema-based. For structured, semi/ pseudo-structured, and unstructured data, you can store your data in either CLOBs in XMLType tables or views or in files in Repository folders. With this design you have many access options including path- and query-based access through Resource Views.

Figure 2-2 Data Storage Models: How Structured Is Your Data?

Text description of adxdb036.gif follows

Text description of the illustration adxdb036.gif

Oracle XML DB Application Design: b. Access Models

Figure 2-3 shows the two main data access modes to consider when designing your Oracle XML DB applications:

Navigation- or path-based access. This is suitable for both content/document and data oriented applications. Oracle XML DB provides the following languages and access APIs:
- SQL access through Resource/Path Views. See Chapter 15, "RESOURCE_VIEW and PATH_VIEW".
- PL/SQL access through DBMS_XDB. See Chapter 16, "Oracle XML DB Resource API for PL/SQL (DBMS_XDB)".
- Java access. See Chapter 17, "Oracle XML DB Resource API for Java".
- Protocol-based access using HTTP/WebDAV or FTP, most suited to content-oriented applications. See Chapter 19, "Using FTP, HTTP, and WebDAV Protocols".
Query-based access. This can be most suited to data oriented applications. Oracle XML DB provides access using SQL queries through the following APIs:
- Java (through JDBC) access. See Chapter 9, "Java API for XMLType".
- PL/SQL access. See Chapter 8, "PL/SQL API for XMLType".

These options for accessing Repository data are also discussed in Chapter 13, "Oracle XML DB Foldering".

You can also consider the following access model criteria:

What level of security do you need? See Chapter 18, "Oracle XML DB Resource Security".
What kind of indexing will best suit your application? Will you need to use Oracle Text indexing and querying? See Chapter 4, "Using XMLType" and Chapter 7, "Searching XML Data with Oracle Text".
Do you need to version the data? If yes, see Chapter 14, "Oracle XML DB Versioning".

Figure 2-3 Data Access Models: How Will Users or Applications Access the Data?

Text description of adxdb027.gif follows

Text description of the illustration adxdb027.gif

Oracle XML DB Application Design: c. Application Language

You can program your Oracle XML DB applications in the following languages:

Oracle XML DB Application Design: d. Processing Models

The following processing options are available and should be considered when designing your Oracle XML DB application:

XSLT. Will you need to transform the XML to HTML, WML, or other languages, and how will your application transform the XML? While storing XML documents in Oracle XML DB you can optionally ensure that their structure complies (is "valid" against) with specific XML Schema. See Chapter 6, "Transforming and Validating XMLType Data".
DOM. See Chapter 8, "PL/SQL API for XMLType". Use object-relational columns, VARRAYs, nested tables, as well as LOBs to store any element or Element-subtree in your XML Schema, and still maintain DOM fidelity (DOM stored == DOM retrieved). Note: If you choose the CLOB storage option, available with XMLType since Oracle9i Release 1 (9.0.1), you can keep white spaces. If you are using XML schema, see the discussion on DOM fidelity in Chapter 5, "Structured Mapping of XMLType".
XPath searching. You can use XPath syntax embedded in an SQL statement or as part of an HTTP request to query XML content in the database. See Chapter 4, "Using XMLType",Chapter 7, "Searching XML Data with Oracle Text", Chapter 13, "Oracle XML DB Foldering", and Chapter 15, "RESOURCE_VIEW and PATH_VIEW".
XML Generation and XMLType views. Will you need to generate or regenerate XML? If yes, see Chapter 10, "Generating XML Data from the Database".

How often will XML documents be accessed, updated, and manipulated? See Chapter 4, "Using XMLType" and Chapter 15, "RESOURCE_VIEW and PATH_VIEW".

Will you need to update fragments or the whole document? You can use XPath to specify individual elements and attributes of your document during updates, without rewriting the entire document. This is more efficient, especially for large XML documents. Chapter 5, "Structured Mapping of XMLType".

Is your application data-centric, document- and content-centric, or integrated (is both data- and document-centric)? See Chapter 3, "Using Oracle XML DB".

Messaging Options

Advanced Queueing (AQ) supports XML and XMLType applications. You can create queues with payloads that contain XMLType attributes. These can be used for transmitting and storing messages that contain XML documents. By defining Oracle objects with XMLType attributes, you can do the following:

Store more than one type of XML document in the same queue. The documents are stored internally as CLOBs.
Selectively dequeue messages with XMLType attributes using the operators existsNode(), extract(), and so on.
Define transformations to convert Oracle objects to XMLType.
Define rule-based subscribers that query message content using XMLType operators such as existsNode() and extract().
See Also:

Chapter 24, "Exchanging XML Data Using Advanced Queueing (AQ) and Oracle Streams"

Oracle9i Application Developer's Guide - Advanced Queuing

Oracle XML DB Design: Storage Models

Figure 2-4 summarizes the Oracle XML DB storage options with regards to using XMLType tables or views. If you have existing or legacy relational data, use XMLType Views.

Regardless of which storage options you choose for your Oracle XML DB application, Oracle XML DB provides the same functionality. However, the option you choose will affect your application's performance and the data fidelity (data accuracy).

Currently, the three main storage options for Oracle XML DB applications are:

LOB-based storage? LOB-based storage assures complete textual fidelity including whitespaces. This means that if you store your XML documents as CLOBs, when the XML documents are retrieved there will be no data loss. Data integrity is high, and the cost of regeneration is low.
Structured storage? Structured storage loses whitespace information but maintains fidelity to the XML DOM, namely DOM stored = DOM retrieved. This provides:
- Better SQL 'queriability' with improved performance
- Piece-wise updatability
Hybrid or semi-structured storage. Hybrid storage is a special case of structured storage in which a portion of the XML data is broken up into a structured format and the remainder of the data is stored as a CLOB.

The storage options are totally independent of the following criteria:

Data queryability and updatability, namely, how and how often the data is queried and updated.
How your data is accessed. This is determined by your application processing requirements.

What language(s) your application uses. This is also determined by your application processing requirements.

See Also:

Using XMLType Tables

If you are using XMLType tables you can store your data in:

CLOBs (unstructured) storage
Structured storage
Hybrid or semi-structured storage

Using XMLType Views

Use XMLType views if you have existing relational data. You can use the following options to define the XMLType views:

SQLX operators. Using these operators you can store the data in relational tables and also generate/regenerate the XML. See Chapter 10, "Generating XML Data from the Database".
Object Types:
- Object tables
- Object constructors. You can store the data in relational tables using object constructors.
- Object views

Figure 2-4 Structured Storage Options

Text description of adxdb035.gif follows

Text description of the illustration adxdb035.gif

2 Getting Started with Oracle XML DB