>Paul,
>
>In your description you don't give us enough information to answer the question. A good relational design closely matches the actual entities and relationships that exist in the business being modeled. To determine if a particular design approach is going to be effective one must know details about the business and the nature of the data being recorded.
>

Yeah, I was afraid I wasn't giving a specific enough example. Here's the specific table layout I was thinking about when I made the post (partial tables):

OrderedParts
------------------------
iid
fk_RO
fk_Vendor
OrderDate
ExpectedDate
ReceivedDate
OrderStatus
fk_Invoice

Invoice
------------------------
iid
fk_RO
fk_Vendor
InvoiceDate

The specific sequence of events I'm attempting to model is: A new RO (Repair Order, which we use as a Purchase Order number) is opened. Parts are ordered for this RO, which are tracked by the OrderedParts table. When the invoice comes in for these parts they are "costed" to the lines (ie. each individual part that is on the invoice are partially posted against the lines in the RO, so that the total of the lines = the invoice total). My original thought was to then link each of the ordered parts back to the invoice, which was what gave rise to my original question.

After reading the responses, and re-reading Appendix 2 in your book, it looks like I really should have an intermediate table instead, that links OrderedParts and the Invoice table, and remove the fk_invoice from OrderedParts. Would this be a correct assumption?