主キーが「圧倒的多数の関数従属性が成立しないことを保証する」ものならば、受注ヘッダに顧客名を置いてはならないのだろうか

渡辺先生がミステリアスな記事をupしている。

http://watanabek.cocolog-nifty.com/blog/2014/08/post-b7d8.html
つまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、
むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。その責任の重大さがおわかりだろうか。

これはわからない。
情報処理試験なんかに出てくる主キー設計手順では、テーブル上の複数の候補キーから主キーを選択するのではなかったか。
であれば「主キーじゃない候補キー → その他の属性」という関数従属性がテーブル内にあるのは普通のことではないのか。

具体例を考えてみる。
元記事のセミナーの例に倣って、こんな受注ヘッダを想定する。

{ 受注番号(PK), 顧客番号(PK), 顧客名, 受注日時 }

実データにおいて、関数従属性

(受注番号, 顧客番号)→顧客名

が成り立つだろう。また同時に

(受注日時, 顧客番号)→顧客名

も成り立ってしまう(元記事における"{a,d}→c"のケース)。
この関数従属性が「禁じられている」と考えるなら、何らかの手当(顧客名か受注日時を外出しにするとか?)をしなくてはならないが、向こうの流派ではいったいどうするのだろうか。

マスタとトランザクションの違い

くどいが「受注ヘッダに顧客名は要らないだろ」という人のため補足すれば、現実世界の顧客名は時間とともに変わるから、俺は上記の受注ヘッダにおいて

顧客番号→顧客名

という関数従属性は成り立っていないと考えている。だから顧客名を受注ヘッダ上に置いており、「必要なら顧客マスタから拾ってくればよいデータ」ではないと考えている。またこれが受注ヘッダではなく顧客マスタであれば「顧客番号→顧客名」は当然成り立つと思っている。
これは我々の業界でいうマスタ/トランザクションの違いであり、オントロジーでいうendurant/perdurantの違いだ。
perdurantなもの(=出来事, イベント)は特定の時刻に固定されており、その属性は時刻を指定しなくては値を特定できない。

もしかして

渡辺先生もこんなことわかってて書いていて、元記事の「主キー」を「候補キー」と読み替えればいいだけの話なのだろうか。