RE: [ubl-ndrsc] Functional Dependency and Normalization paper

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

This is a really clear paper Tim.  Your effort payed off.  I believe it
gives designers something tangible and useful on which to hang their hats.
Here's my detailed reactions:

In 1NF (in appendix A) at the point where you've found the one-to-many
relationship between "order" and "order item" and you've shown the need (in
the relational model) for the "linkage" from "order item" back to "order"
via the foreign key.  It seems worth noting at that point that this linkage
is explicit in the relational model but implicit in the (eventual) XML one.
This linkage between "order" and "order item" will be inferred from the
context -- an "order item" is associated with the "order" under which it
appears.  We'll see this again and again.

Next, I think it would help in Appendix A if in your schemas you adorned
foreign keys in a manner similar to the way you do with primary keys, e.g.:

order(PRIMARY IDENTIFIER [order number], buyer, account, order date, FOREIGN
KEY (account, seller[account]))
seller(PRIMARY IDENTIFIER [account], name)
order item(PRIMARY IDENTIFIER [ order number, item number], quantity,
FOREIGN KEY (order number, order[order number]) FOREIGN KEY (item number,
item[ item number]))
item(PRIMARY IDENTIFIER [item number], item description, unit price)

Then again, maybe you should just use SQL-92 for this instead of our
made-up-almost-SQL-92 language. 

Also, the attribute name "account" on the "order" relation is ambiguous.  I
recommend you call it seller-account.

Appendix B

Please do not use DTD in examples.  I realize it's terse, and that's nice,
but it continually runs us into problems.  Please rephrase in (verbose) XSD:

	<xs:complexType name="Order">
		<xs:sequence>
			<xs:element name="OrderNumber"/>
			<xs:element name="Buyer"/>
			<xs:element name="SellerAccount"/>
			<xs:element name="OrderDate"/>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="Seller">
		<xs:sequence>
			<xs:element name="Account"/>
			<xs:element name="Name"/>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="OrderItem">
		<xs:sequence>
			<xs:element name="OrderNumber"/>
			<xs:element name="ItemNumber"/>
			<xs:element name="Quantity"/>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="Item">
		<xs:sequence>
			<xs:element name="ItemNumber"/>
			<xs:element name="Description"/>
			<xs:element name="UnitPrice"/>
		</xs:sequence>
	</xs:complexType>

Next, I wouldn't use the term "n-ary" to stand for maxOccurs="unbounded".
"N-ary" is used in database lingo to refer to the "arity" of a relationship,
e.g. if we're relating four different kinds of things then the arity is four
and you might call the relationship a quaternary one.

In the interest of eliminating superfluous issues from our discussion I feel
like it's important to work out the rest of Appendix B using XSD instead of
DTD.  My experience is that DTD-think (a.k.a. global element think) is our
constant enemy.

Again, great paper Tim.

Regards,
Bill