|2003年 6月 1日||HEADER-DETAIL||BACK >> 目次|
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｝
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:
01, 02, 03,...
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.
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 :
For describing the "double-decker" bus of relationship in T-formed ERD, therefore, "HEADER-DETAIL" is portrayed as below:
|<< もどる||HOME||すすむ >>|