OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML: logical and/or physical model?

[ Lists Home | Date Index | Thread Index ]

On May 28, 2004, at 10:52 AM, David Megginson wrote:

> I'd suggest a slightly different focus: the physical model is private 
> while the logical model is public.  XML is designed to handle the 
> public, logical part so that people can share information without 
> being forced to use the same physical models.
> Date's speech rants not against XML itself but against XML encroaching 
> on the physical side.  Granted, he doesn't like SQL much either, but 
> he might be right about XML, unless object-oriented and XML databases 
> are performing and scaling a lot better than they were the last time I 
> looked.

I'm sortof sorry to perpetuate the logical/physical terminology outside 
the world of relational modeling where it is reasonably well defined, 
- Conceptual models are of business concepts and relationships, e.g. 
products, customers, invoices and are the domain of business analysts
- Logical models map those concepts onto relations, types, and tuples 
(or tables, columns, rows, if you prefer) and are the domain of 
database designers/programmers
- Physical models map those onto machines, files, partitions, indexes, 
etc. and are the domain of DBAs

My argument is basically that XML allows you to munge these all into a 
conceptually messy but pragmatically appealing whole:  An invoice 
(conceptual) can be modeled directly with an XML schema (logical) and 
manipulated as an XML instance in a text file, RDBMS CLOB, NDXB entry, 
DOM tree, SAX event stream, whatever.  So, yes people can share 
information because it is all "XML" irrespective of the 
implementation-level representation as a file, DBMS record, event 
stream, etc.  That's not quite the same as the relational 
logical-physical mapping, because in XML that's a completely mechanical 
process of parsing/serializing, and the relational world it requires 
human intelligence and deep expertise to do well.   As Date is fond of 
reminding us, both are in short supply.

So, XML succeeds for the familiar 80:20 reason -- it handles (well 
enough) a lot of familiar situations such as document-driven business 
processes with few impedance mismatches between the conceptual/end-user 
level to the physical/implementation-level technologies without 
demanding the scarce skills of effectively normalizing conceptual 
models into relations, implementing DBMS that efficiently support N-way 
joins as N gets large, and hiding all this implementation detail from 
the conceptual and logical layers. There's certainly a cost -- I'm not 
going to be the Anti-Date and say that XML is all you ever need, just 
that there are plenty of cases where munging the 
conceptual/logical/implementation layers into the single abstraction of 
an XML instance is very practical.

I'm not sure what is meant by "XML encroaching on the physical side" or 
"he might be right about XML, unless object-oriented and XML databases 
are performing and scaling a lot better than they were the last time I 
looked".  It seems to me that a lot of the demand for XML is driven by 
the very practical challenges of modeling relatively unstructured 
information within the relational paradigm in a way that allows decent 
performance and scalability on existing RDBMS products.  I have obvious 
Day Job biases here, but there are real performance benefits possible 
from XML databases (or, to be fair, native XML CLOB types in an RDBMS) 
that basically come from avoiding joins.  Date is certainly right that 
the "assembling a car from its components" metaphor conflates the 
logical and physical levels, but AFAIK the simple fact is that existing 
(relatively pure) RDBMS technologies don't support the distinction very 
well, at least for hierarchical and ordered data such as XML.  All the 
benchmarks I know about that compare a native XML implementation to a 
normalized relational implementation show that the more complex the 
hierarchy (i.e., the more joins necessary to reconstruct the conceptual 
model), the slower the pure RDBMS approach is compared to the pure XML 
approach.  The question in my mind is whether we will bridge the 
logical-implementation gap by better RDBMS that physically maintain the 
car intact while logically treating it as a collection of parts, or 
whether something [perhaps like Childs' stuff? ] that unifies the 
logical - physical and relational - hierarchical conceptions will be a 
better way forward.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS