Re: [xml-dev] Normalizing XML [was: XML information modeling best practices]

[Ronald Bourret <rpbourret@rpbourret.com>]

Michael Kay wrote:
> 
> > First normal form:
> > ------------------
> > Data is in first normal form if it (a) has a primary key and
> > (b) has no repeating fields.
> 
> Actually, *data* can't be in first normal form - only *relations* can.

You're correct -- poor wording on my part.

> So
> applying the concept to a data model that doesn't use relations is pretty
> dicey.

Agreed.

What I'm curious about is whether there is a concept analogous to
normalization that can be applied to the XML data model. This might be
useful in proposing XML information modeling best practices, which was
Simon's original goal.

> Obviously (b) doesn't have any relevance to a hierarchic data model,

That depends on how you choose to interpret what "repeating fields"
means. If you choose to view B in:

   <!ELEMENT A (B+)>

as a (pardon the expression) single, multi-valued attribute, then the
above content model has no repeating fields while the following content
model does:

   <!-- B1 and B2 represent the same real-world entity -->
   <!ELEMENT A (B1, B2)>

> > In XML terms, this
> > implies that you only store one "thing" per document
> 
> You've made a magic jump from "data" being normalized to "documents" being
> normalized, and you seem to be assuming that a document should represent one
> tuple in a relation - that's a mighty big jump.

That was my intention from the start, but I obviously wasn't clear about
it.

> Yes, [3NF] does apply to XML, but it certainly doesn't tell us how to split our
> data into multiple documents. It does tell us how to design our hierarchies,
> but not how to partition those hierarchies across documents.

I think it does tell us how to partition documents. It says that data
shared across multiple documents needs to reside in separate documents.
Sales orders are a bad example here, since the "XML normalized" form is
virtually identical to the relational normalized form. Semi-structured
data is probably a better example, since documents containing
semi-structured data are likely to be substantially different than their
relational counterparts.

> But all this presupposes that we are designing XML documents for storage and
> query. Most XML documents are designed for messaging of some kind (between
> humans or between software components). Within the context of a message,
> duplication is far less of a problem, for example it doesn't matter if I
> hold product code, description, and price as part of each order-line in an
> order. Many XML databases are actually archives of such messages, so
> duplication of data is a fact of life; and since it's an archive, the update
> problem doesn't arise.

This is the conclusion I came to.

-- Ron