1. Entity

　We have data of "business partner (trading partner)" with the identifier of "BP-NO", "business partner" is an entity, and it's described as noted below:

　　Business Partner:｛BP-NO, BP-name,...｝[ R ]

　
2. Subsets

　If and when there is, in the "business partner" set, a "partition" code of "classification by business relations" with the value of "1" for "consignor" and "2" for "supplier", then the entity must be divided into two subsets as noted below:

　　Business Partner:｛BP-NO, BP-name, by business relations, ...｝[ R ]
　　　｜
　　　｜
　　　× by business relations
　　　｜
　　　｜＿＿＿＿ consignor
　　　｜
　　　｜
　　　｜＿＿＿＿ supplier

　
3. Verification for subsets

　A business partner, with the value of 001 in BP-NO, may be BOTH a consignor AND a supplier.
　Subsets can be formed in the exclusive "OR" relation, so that the subset "consignor" and "supplier" NEVER be theoretically compatible, and we've got to get them to the right way.

　If we leave them as they are, an application program must be complicated with nested-IF statements so that the following cases are embedded in control-flow of statements:
　(1) both "consignor" and "supplier" are TRUE
　(2) either "consignor" or "supplier" is TRUE
　　(if "consignor" is validated first in IF statement, then "supplier" is in ELSE statement, and vice versa.)

　
4. taisyohyo (combination-table)

　The "partition" code of "business relations" must NOT be legitimate, they are NOT a "partition" code in the way they must be, so that it's NOT an attribute belonging to the "business partner" set.

　We must get it back on the right track as noted below:

　　Business Partner:｛BP-NO, BP-name,...｝[ R ]
　　Business Relation:｛BR-CODE,...｝[ R ]
　　Business Partner. Business Relation. combination-table:｛BP-NO(R), BR-CODE(R)｝[ taisyohyo ]

　You can see that "nested-IF" statements can be reduced into a statement, because the combination table (of "BP.BR. taisyohyo") works as a "truth table."