RE: [xml-dev] XML Database Decision Tree?

["Magick, Brian" <Brian.Magick@COMPAQ.com>]

<<<   I may be digressing, but an implication of an XML DBMS support for
efficient
   storage/retrieval of well-formed XML is that you can get many
benefits of
   using a DBMS without going through the agonies of data modelling,
database
   design, and performance tuning that RDBMS-based applications
traditionally
   suffer.>>>

Hmm.....I see your point in terms of not needing to do data modeling in
the traditional sense in order to put a production database in place.
In a traditional (RDBMS) database implementation a team of logical data
modelers would get together to review business rules, perform analysis,
and iteration after iteration of conceptual/logical data models would be
put forward until a mature enough model is handed to the physical
database designers to denormalize most of what was done anyways.
<cynical data architect remark...>

I don't see however the "agonies" of data modeling going away, I just
see its role moving to a different place in the process.  With XML
databases we lose the traditional rigid structure of an RDBMS and the
need to create a logical model at the database level.  One is misled and
truly at a cross-roads in their understanding of your companies data
needs if however, they feel that data modeling need not be done at all.
XML provides the Schema which is very much analogous with a data model
and it is disturbing to me how few developers have embraced the Schema
or put 2 + 2 together and asked Data Architecture teams for assistance
creating them.

One of the biggest challenges I have encountered in my work as a Data
Architect (I consider myself an XML Data Architect at this point) is
taking the toys out of the hand of developers.  This is very much like
taking away a toy from a child who may have not yet learned the rules of
the game.  XML came along very rapidly and was the toy of choice for
many developers.  They implemented really "cool" applications that did
simple messaging or integration functions/tasks, they created a few
simple web applications that showed the promise of mastering XML and
added new developers to the fold, but they did not understand that XML
IS DATA!  Yes, in the truest sense XML is data just as a traditional
RDBMS is data.  DATA = DATA.  It's a simple equation but one that some
developers just don't get.  

Now this isn't a new struggle.  Data Architecture historically has had
an uphill battle for acceptance, I won't get into the specifics of that
struggle here.  XML Data Architecture will certainly face many of the
same battles but should be guided by the same Data Architecture
principles.  These vary slightly by organization but typically include
things like standard definitions that facilitate consistency and
data/data structure reuse, strong definition and capture of metadata
(which XML EXCELLS AT!), high degree of data quality, one source for
like data, etc..  The XML Schema is the mechanism to achieve these
principles and thus the responsibility to develop these should be put in
the hands of the Data Architects, not in the hands of the developers.
The Data Architects of an organization need to embrace XML quickly so
that these Schemas can be developed and implemented (with validation,
but this is another post and another battle to be fought) and be managed
in a way that supports consistency, common definitions, reuse, etc..

While it true that with XML data modeling is not at the database level
we must consider that XML can be managed without a database.  With this
said you can clearly see that each XML document itself acts as a
pseudo-database (remember RDBMS = DATA, XML = DATA), and that each
document's Schema needs to be given the same care and attention one
would put into crafting a table in an RDBMS.  

In terms of the XML database I think the term database might be bit
misleading (I personally think repository fits better) but the fact that
it is not a database in the traditional sense DOES NOT lend credence to
the total absence of data modeling for your XML data.

Brian Magick

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com] 
Sent: Saturday, October 27, 2001 3:31 PM
To: Mike.Champion@SoftwareAG-USA.com
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] XML Database Decision Tree?

   Date: Sat, 27 Oct 2001 15:58:15 -0400
   From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>

   I may be digressing, but an implication of an XML DBMS support for
efficient
   storage/retrieval of well-formed XML is that you can get many
benefits of
   using a DBMS without going through the agonies of data modelling,
database
   design, and performance tuning that RDBMS-based applications
traditionally
   suffer. 

I don't think it's so much that XML means you don't need those
agonies.  Whether you need them really depends on the role that your
DBMS plays on your organization.

Having a strongly-enforced strict and structured schema has benefit
and costs, which depend on the use case.  That is, depending on what
you're trying to do, the costs might outweight the benefits or vice
versa.

In the classic "database of record" "standard corporate database" use
case, you've got a large corpus of critical long-lived corporate data,
and there are lots of different applications that might read and write
it (plus ad hoc queriers).  To make sure that none of those
applications breaks another by writing something into the database
that another one can't read, you have to set up ground rules that all
the applications must follow.  The classic RDBMS schema is part of
that set of ground rules, and there are these DBA guys who act as
judges (or perhaps "as bouncers") in order to prevent car crashes.  I
think the need for these ground rules is pretty much independent of
what data model the DBMS is using.

(That is, if somehow someone ended up with a native XML database
playing such a role -- even though I keep saying that I don't think
that'll happen and that's not what native XML databse systems are
intended for! -- then you'd still want a schema for the same reason.)

In other use cases, rigid conformity may provide less benefit, and the
ability to manage semi-structured data may be more pressing.  For
example, to again repeat the comments that you (Mike) made at the
NEJUG talk in Burlington, if a purchase order for $1M comes in, you
don't want to automatically turn it away just because it doesn't
conform perfectly 100% to your pre-defined schema!  Semi-structured
data arises in more and more situations these days, including the
integration of data from multiple disparate sources.  (Anyone
interested might want to do Web searches for papers about
semi-structure data.)  I think this is one of the areas of opportunity
for native XML databases.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>