Re: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalizationpaper

[Tim McGrath <tmcgrath@portcomm.com.au>]

Burcham, Bill wrote:

>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.
>
I see the terms linkage, relationship and association as fairly similar. 
 In a relational model these are implemented by foreign keys, in XML by 
including the associated element within the container (sorry, the 
language gets in the way here - maybe we should just get down to 
diagrams!).  It is just different ways to implement the same concept. 
 Not sure i like 'explicit' and 'implicit' - we could just say that one 
may be more elegant.

>
>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. 
>
thanks i agree - let me know how it should look. i learnt SQL in 1984 so 
i didn't know it had such as beast.

>
>Also, the attribute name "account" on the "order" relation is ambiguous.  I
>recommend you call it seller-account.
>
yes, eve had problems with this as well.  we should keep the naming as 
simple as possible.

>
>
>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>
>
thanks again. i was trying to keep in alignment with the other papers. 
 i actually know XSD better than DTD so it is easier for me to do this. 
 NB your example nneds some tidying up but i get the point.  i know some 
may disagree, but i think XSD also shows the structure more meaningfully 
for non-SGML people.

>
>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.
>
good grief , you're right again. what i should have said was 'when the 
potential cardinality of the relationship is greater than 1'.

>
>
>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.
>
not another constant enemy - how will i sleep at nights!

>
>Again, great paper Tim.
>
>Regards,
>Bill
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>.
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142