Databases Reference
In-Depth Information
IBM DB2
takes a different approach to XML schema validation, one that embr-
aces the XML notion of interoperability rather than instance homogeneity (
Beyer
et al.
2005
). Rather than apply a single schema or schema set against an entire
collection of documents in a table or column, DB2 schema validation occurs on a
per-document basis. XML documents may be validated against a schema at the time
of insertion; however, the schema against which to validate the document is not
determined by the schema associated with the column, since there by definition is
no such schema. Rather, the schema is determined by attributes within the document
to be inserted, or by manually specifying a schema as an argument to the XMLVal-
idate function. Once a document has been validated, the document is adorned with
metadata that verifies that the document was validated as well as information to help
optimize query processing.
Like Oracle's schema registration service and SQL Server's schema collections,
DB2 requires one to register XML schemas in the system prior to use:
register xmlSchema 'foo://tempuri.com/schema.xsd'
from 'schema-v1.xsd' as schemaV1 complete
DB2 has no support for schema evolution per se, as different versions of the same
schema appear in the database repository as unconnected documents. One also does
not update document instances from one version of a schema to another, similar to
SQL Server. Researchers from IBM have described how to support schema version-
ing using a complete scenario (
Beyer et al. 2005
); the scenario involves a relational
table that correlates the currently registered schemas (and thus schema versions)
with the applications currently using them. All of the mitigation of schema version-
ing is handled by the tables and protocols set up in the scenario rather than inside
the engine.
Since the engine does not enforce document homogeneity, it allows documents
from multiple schemas and thus multiple schema versions to coexist in a single
corpus with full fidelity. Rather than automatically evolve instances, the documents
exist in their original form, associated with its original schema.
Native XML databases
, unlike relational systems, are built from the ground up
to support XML storage. Relatively few of these systems support XML schemas or
schema evolution. One notable exception is
Ta m i n o
(
Software AG 2006
).
Like Oracle, Tamino can store XML data in a fashion that is XML schema
dependent, i.e., the physical structures may be optimized, possibly by mapping to
relations, knowing that the XML data is regularly structured in some way. Also
similarly to Oracle, Tamino allows schemas to evolve under the same restrictions
as Oracle's in-place migration mechanism. One specifies a new schema version
wholesale - no mapping or incremental changes are possible - providing the entire
schema document, and passing it to the same
define
command to define an initial
version.
Where Tamino differs from Oracle is that Tamino allows the stored data to deter-
mine reverse compatibility rather than the schema document versions themselves.
One can pass a parameter to the
define
command to attempt to do some static
validation first - determining just from the documents themselves whether it is pos-
sible for reverse compatibility to be guaranteed - but eventually all documents are
