その２

この記事はいい記事だと思います。
はてなブックマークでも人気だし。
でも、いい記事なだけに「あえての」イチャもんつけをしたいと。

第一正規形から第三正規形はいいです。
理解できます。
でも、ボイスコッド正規形に入ったとこで、
「フツーこんなテーブルつくるか？？」
と思わざるをえないわけで。
この記事に限らず、正規形の説明はよく
「こんなんありえへんやろ」
と思ってしまう例題を出してくるわけで。
それが理解しにくい原因の１つかと思うわけで。

例題はこんなんです。これをボイスコッド正規形にします。

学生	科目	講師
佐藤	国語	山田先生
佐藤	数学	丸岡先生
佐藤	英語	志水先生
鈴木	国語	宮本先生
鈴木	数学	水野先生

「｛学生, 科目｝→講師」「講師→科目」の2つの関数従属性があります、と。

ちょちょと待って。
間違ってもいきなりこんなテーブルありえないでしょ。
大前提で学生エンティティ、科目エンティティ、講師エンティティに分けるでしょ。

で、制約はこんなんです。

・学生と科目が決まると講師が決まる（1科目を複数の講師から教えられることはない）
・1人の講師は1科目だけを担当する。同じ科目を担当する講師は複数いる
・1人の学生は複数の科目を履修する

だったら、こんなんでええんちゃうの。

なんか話がややこしくなってるのは
「履修する」というエンティティとエンティティの関連がいきなりドーーーンと登場してしまうからだと思う。
はっ、これがPOAか。

たぶん、つづく。

追記：いい記事かと思ってたけど、ダメな記事のように思えてきた。
ダメじゃないかもしれないけど、自分の考え方と合わない。

稼働しているシステムのテーブル構造を変えるのは非常に大変な作業です。できればこういったビジネスルールはテーブル構造に実装するのではなく、アプリケーションプログラムとして実装した方が保守性の高いシステムとなります。

稼働しているシステムのプログラムを変えるのも大変な作業です。
どっちかというと、プログラム「だけ」変える方が大変だと思います。
保守性が高いとは断言できないと思います。

これらはビジネスの都合により変更される可能性が大いにあります。例えば、学生は科目を選択するだけで講師を特定する必要がなくなったり、1人の講師が複数の科目を担当できるようになることは十分に考えられます。

学生は科目を選択するだけで講師を特定する必要がなくなったとしたら、
「どの講師を割り当てるか」というビジネスルールが新たに発生するはずです。
ビジネスルールをすべてプログラムに押し付けるのでしょうか。
1人の講師が複数の科目を担当できるようになることは十分に考えられるとおもいます。
それなら最初から１：ｎの関連エンティティをつくっておくのが手だと思います。