Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML: logical and/or physical model?
 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, i.e: - 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
