Example-3 mentioned previous time is taken again, to open up argument on so-called "header-detail" format of tuple (record):

　　｛order-NO, supplier-NO, order-DATE｝
　　｛order-NO, item-NO, quantity｝
　　｛item-NO, item-name, price｝
　　｛supplier-NO, supplier-name｝

　The tuple (record) of｛order-NO, supplier-NO, order-DATE｝is said to be "order-HEADER" record, and the tuple of｛order-NO, item-NO, quantity｝is "order-DETAIL".

　Before normalizing data, the "header-detail" is originally formed as below:

　　｛order-NO, supplier-NO, order-DATE, item-NO, quantity｝

　｛item-NO, quantity｝is a repeating group in Codd's notation, and it can be normalized by removing into a separate table (flat file), and it must have keys which uniquely identify the tuples as below:

　　｛order-NO, item-NO, quantity｝

　Let us consider the "header-detail" format, the four tables is described as below:

　　SUPPLIER:
　　｛supplier-NO, supplier-name｝[ R ]

　　ITEM:
　　｛item-NO, item-name｝[ R ]

　　order-HEADER:
　　｛order-NO, supplier-NO(R), order-date｝[ HDR ]

　　order-DETAIL:
　　｛order-NO(R), line-NO, item-NO(R), quantity｝[ DTL ]

　
　The header record has the identifier of "order-NO", and the detail has the RE-USED identifier of "order-NO", and the detail has "line-NO" which uniquely identifies a detail record (among many) instead of "assortment-code."　Let's take a shipment (delivery) "on-hire" (split-off) basis as below:

　　order-HEADER:
　　｛order-NO, supplier-NO(R), order-date｝[ HDR ]

　　order-DETAIL:
　　｛order-NO(R), line-NO, item-NO(R), quantity｝[ DTL ]

　　delivery:
　　｛delivery-NO, line-NO(R), delivery-date｝[ E ]

　
　In the above example, "order-NO(R)" (of order-DETAIL) cannot be re-used in "delivery" event, because it's re-used just from "order-HEADER."　Let's take the values of data, "order-NO" and "line-NO", as below:

　　order-NO：

　　001, 002,...

　　line-NO：

　　01, 02, 03,...

　
　If and when the value of "delivery-NO", 001, has the value of "line-NO", 02, the value of "line-NO" cannot be uniquely identified to which "order-NO", 001 or 002.

　Bring the definition of "event" to mind, "an 'event' type of entity must have an attribute of 'DATE' while a 'resource' cannot.

　According to the definition, the detail record of "order" CANNOT function as "event" because the "order-date" is the attribute of the header record, not of the detail record.
　As a matter of reality, however, the detail works as "event", it has relationship to "delivery", and we need the "order-NO" in "delivery" while something can be urged in justification for re-using "order-NO" in "delivery."

　Bring it to mind that we never take "relation (in aRb)" as mathematical function of "R(a, b)"--"relation" is one degree higher than "a" and "b", and in other words that both of a and b, therefore, are "resources" and R is an "event" when viewed in perspective of "Entity and Relationshp" diagram.

　The following is the most acceptable explanation of "HEADER-DETAIL" in the light of "Entity and Relationshp" diagram :
　　(1) An "order" is an "event" (a relationship between resources)
　　　 as in "R" between "a" and "b".
　　(2) An "event" of "order" has relationship in itself: HEADER and DETAIL.
　　(3) A "HEADER-DETAIL" is a "double-decker" bus of relationship--that is to say,
　　　"a relationship is, by itself and for itself, an entity."
　　(4) The "header" and the "detail" works as "event" respectively.

　For describing the "double-decker" bus of relationship in T-formed ERD, therefore, "HEADER-DETAIL" is portrayed as below:

　　order-HEADER:
　　｛order-NO, supplier-NO(R), order-date｝[ HDR ]

　　order-DETAIL:
　　｛order-NO, line-NO, item-NO(R), quantity｝[ DTL ]

　（「HDR-DTL」形式に関するＴ字形 ER手法の正確な記述は拙著を参照されたい。）