Impact of XML on Data Modeling
An interesting thread on the xmlschema-dev list about the impact of xml on data modeling.
Scott Tsao starts off talking about how to define different kinds of data models. The Conceptual, Logical, and Physical. He says that Xml Schema is the logical model and the binding to a database would be the physical one.
Essam Mansour says: "Conceptual: the model at this level is platform-independent and also could be logically modeled using any modeling technique, ERD, OO model, or XML Schema. Logical: is also platform-independent but it is based on specific modeling technique. Physical: is platform dependent."
This strikes me as pretty close on. Xml Schema can do any of these models, it is the semantic concepts that are different.
Anthony B. Coates says what I think is very common and have come across many times. He says Xml Schema is the physical and UML is the conceptual. This is in fact how they each tend to be used. But I have also found strong support for Xml Schema at the conceptual level. Anthony goes on to say that the conceptual (UML) is the business representation and the physical (XSD) is the technicians' view. This again is what I have come across with my clients. But it is not rigid. The line between business and technical is often blurry, and reality creeps in. But the broad separation of these if often seen as an "ideal".
Michael Kay, who is everywhere and one of the smartest folks I've read, says the concepts are separate. A conceptual model gives you abstraction that can benefit data modeling. So while the concepts are separate, there is an underlying standardized data model.
This is where already standardized data models such as OAGIS and HR-XML come in to play. They can give you a heads up on creating a new model (whether in UML or in XSD) or they can be considered an open source data sharing model for B2B transactions.
With some support for the conceptual=UML and physical=XSD, the discusssion then goes on to ask "can xsd also model the conceptual?" See Scott Tsao.
I totally agree with Scott in that it "can" play that role. And I've seen it done that way. The bottom line is to use the modeling tool that is most usable and comfortable to you. If it is UML, then use it. If XSD, then use it. I've seen it done both ways and I don't think there are any musts here.
The big problem with UML and XSD is translating between them. But I'll blog on that topic separately.
Scott Tsao starts off talking about how to define different kinds of data models. The Conceptual, Logical, and Physical. He says that Xml Schema is the logical model and the binding to a database would be the physical one.
Essam Mansour says: "Conceptual: the model at this level is platform-independent and also could be logically modeled using any modeling technique, ERD, OO model, or XML Schema. Logical: is also platform-independent but it is based on specific modeling technique. Physical: is platform dependent."
This strikes me as pretty close on. Xml Schema can do any of these models, it is the semantic concepts that are different.
Anthony B. Coates says what I think is very common and have come across many times. He says Xml Schema is the physical and UML is the conceptual. This is in fact how they each tend to be used. But I have also found strong support for Xml Schema at the conceptual level. Anthony goes on to say that the conceptual (UML) is the business representation and the physical (XSD) is the technicians' view. This again is what I have come across with my clients. But it is not rigid. The line between business and technical is often blurry, and reality creeps in. But the broad separation of these if often seen as an "ideal".
Michael Kay, who is everywhere and one of the smartest folks I've read, says the concepts are separate. A conceptual model gives you abstraction that can benefit data modeling. So while the concepts are separate, there is an underlying standardized data model.
This is where already standardized data models such as OAGIS and HR-XML come in to play. They can give you a heads up on creating a new model (whether in UML or in XSD) or they can be considered an open source data sharing model for B2B transactions.
With some support for the conceptual=UML and physical=XSD, the discusssion then goes on to ask "can xsd also model the conceptual?" See Scott Tsao.
I totally agree with Scott in that it "can" play that role. And I've seen it done that way. The bottom line is to use the modeling tool that is most usable and comfortable to you. If it is UML, then use it. If XSD, then use it. I've seen it done both ways and I don't think there are any musts here.
The big problem with UML and XSD is translating between them. But I'll blog on that topic separately.
posted by Paul at
3:13 PM
