> 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. So
applying the concept to a data model that doesn't use relations is pretty
dicey.
Obviously (b) doesn't have any relevance to a hierarchic data model, and (a)
doesn't have much relevance to a model in which objects have intrinsic
identity (as nodes in an XML infoset do).
> 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.
>
> Second normal form:
> -------------------
> Data is in second normal form if the entire primary key is needed to
> predict each field value. The effect is to split the one and
> many parts
> of a one-to-many relationship into separate tables. For example, store
> sales order header information and line item information in separate
> tables.
>
> This form exists in the relational model to avoid duplicate
> data: if you
> store sales order header and line item data in the same table, the
> header information gets repeated on each line item row. XML
> doesn't have
> this problem -- it stores hierarchies quite nicely without duplicate
> data -- so I don't think the second normal form really applies.
On the contrary, I think it applies quite strongly! Second normal form is
telling us to attach attributes to the objects to which they properly apply,
for example you don't store the name of the publisher as part of the book
record, because it doesn't depend on the whole ISBN, it only depends on part
of the ISBN. (Of course, no-one actually applies this rule in practice, but
that's another matter.)
I believe this rule applies just as much to a hierarchical data model as to
a relational one.
>
> Third normal form:
> ------------------
> Data is in third normal form if you can't predict one non-key
> field from
> another non-key field. ...
>
> I think that this does apply to XML, but that you need to
> decide when it
> is useful to apply this form. That is, if you want truly normal XML
> data, you should store this sort of data in a separate
> document and link to it from your main document.
>
Yes, it 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.
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.
When we design XML for storage and query, however, the partitioning of data
into documents is an important design decision, and I have seen no adequate
set of rules or guidelines for doing it (I've made some up on occasions,
when pressed!). Certainly Codd's rules don't help at all, in my view.
Michael Kay
Software AG
home:
work:
