Re: Modeling Data for XML instead of SQL-DBMS

mAsterdam wrote:
> <Annotations>
>
> dawn wrote:
> > If working on a software project where all data are persisted
> /persisted/
>
> Ah, we are talking software development on an island, not
> about shared data.

Sure, we could assume that if it helps.

> > in XML
>
> Ah, we are talking about documents, not about data.

Yes, data, but data stored in documents, aka files, not employing a DBMS.
> > documents and not in an SQL-DBMS, the tools would not require that the
> > data model be in 1NF or the use of the SQL NULL.
>
> /data model/
> ?? document model!

No, it is the data model that is of interest to me, while the use of the XML document for storage happens to be an implementation where perhaps I can get the question across. My interest here is to figure out what information is out there in the way of best practices for data modeling outside of the SQL-DBMS environment.

>- ok, no 1NF.
> /NULL/ (sigh of relief) - not about NULL.
>
> > How would an excellent logical data model designed for this XML
> /logical data model for XML/
> No such thing.

Perhaps I need different terminology. There must still be a design for the data in these documents, perhaps specified with a dtd or xsd. I'm pretty sure that some designs are better than others, so what would be a good way to approach the design for this (these) data?

> > implementation differ from the corresponding data model developed for
> > an SQL-DBMS?
>
> /corresponding/
> No real correspondence.

I will try to be more precise, but there will still be room for miscommunication, I'm sure. Given a conceptual data model (not built to take any particular implementation into account), how would an implementation data model (aka logical data model) for XML differ from an implementation data model for a SQL-DBMS?

Take a simple conceptual data model for pizza orders, for example ;-) perhaps specified using an old-fashioned ERD or UML (only because I'm a novice with ORM).

Pizza(pizzaId, pizzaName, toppings*)
Customer(customerId, name, phone)
Order(orderId, customerId, pizzaId, addToppings*, removeToppings*)

• zero to many values possible (maybe 1 to many in the first case, but simplifying here) Simplying in several ways, including not permitting 1/2 pizza toppings for our purposes here

Would there be a difference in the data model if such data were designed for storage in XML documents compared to if designed for storage using an SQL-DBMS?

> The next (XML, but it doesn't matter)
> document created by dumping a database

This would not be a database dump, but the creation of an application using XML documents (yes, I realize this isn't a highly scalable approach to building an app, so we can assume the data volume will be small if that helps set the scene -- perhaps these are pizza orders for a school sale)

> may differ from the previous, even if the (SQL, but it doesn't matter)
> database content stayed the same.
> Arbitrary order would have to be added to prevent this.
>
> > What would be some best practices for modeling data in
> > this environment?
>
> /this environment/
> A marketing environment? Fantasy island?

Yes, mAsterdam, let's say that it is a pizza sale for a school on Fantasy Island.

> </Annotations>
>
> > I'm guessing some will think that the exact same logical data model
> > would be appropriate for both targets, but hopefully many will agree
> > that it is unlikely that the best implemented data model would be
> > identical in each environment. In that case, what would the
> > differences be? What best practices would apply to data modeling for
> > XML documents compared to data modeling for a SQL-DBMS?
>
> Can't really answer that except "You don't".
> The question by it self shows to much wrongs.

There is a question here that is legitimate, even if I have not yet hit the nail on the head. I've tried to ask this question a number of times in various ways, as you know, but each time the question is considered abberant. If we paint the scenario with what might be termed an "embedded database" that is not an SQL-DBMS, perhaps Berkeley-DB or Cache' or Pick so that we have the same ability to remove 1NF and 3VL-style of NULL-handling, then ask the same question, would it be a legitimate question? If so, then same question.

I'm certain that over the past half-century of software development, some data design patterns have shown themselves to be better than others for such target environments. I'm wondering what both theorists and practitioners think would be best practices when data modeling for these environments.

Thanks. --dawn Received on Wed Oct 25 2006 - 13:18:02 CEST