でぶさみ　羽生章洋氏「楽々ERDレッスン〜これが楽々DB設計の勘所！〜」

modeling

●【レポート】Developer Summit 2006 - DBは超グローバル変数、どう設計するか (MYCOM PC WEB) http://pcweb.mycom.co.jp/articles/2006/02/14/ds2/

  • 「イベント系のエンティティ」からデータの構造を見いだすことが重要
  • マスタメンテ系の作業は、イベントではなく「リソース」であるという。「顧客する」「顧客日」が成り立たないのは、顧客の登録はあくまでも請求を行うためにシステムの都合で必要になる付帯業務だからだ。
  • 「外部キー(FK)」の扱いについても、「とにかく交差エンティティにしろ」
  • コード体系とIDを混同しないこと。「あだ名」は、一意性を保証する「Identifier(ID)」にはなり得ない。
  • 「Activity Based Data Model」

また、羽生氏は所謂「外部キー(FK)」の扱いについても、「とにかく交差エンティティにしろ」と語る。例えば「仕入先」と「商品」の関係を定義する場合、多くの設計者は商品マスタに「仕入先ID」列を作成し、これを仕入先マスタへの外部キーとするだろう。しかし、この設計では、一つの商品を複数の仕入先から仕入れることになった場合に対応できない。結果、アプリケーション側にIf文を記述して対処せざるを得なくなってしまうのだ。つまり、本来データ構造で表現すべきことにも関わらず、プログラムのアルゴリズムに頼ることになるため、DB設計としては失敗なのである。これを避けるためには、仕入先マスタと商品マスタの間に、仕入先IDと商品IDの関係を保持する「m:m」のテーブルを用意すればよい。テーブルが増えると、SQLクエリのJOIN句が複雑化してしまうという意見もあるが、羽生氏は「サブクエリやOUTER JOINがスラスラ書けない人は、DBの設計をすべきでない」と断言する。DBの設計は、プログラムの都合を一切忘れて行わねばならない、というのが氏の主張するところである。

なおセッション後半では、羽生氏の「とっておきの隠し球」として、「Activity Based Data Model」によるDB設計の手法が解説された。受講者限定の隠し球を本稿で紹介するのは「ルール違反」と思われるので、残念ながらここで詳細は書かない。が、RDBMSの生みの親Edgar F. Codd博士や、ERモデルの発案者Peter P. Chen氏の提唱した概念と、羽生氏の豊富な経験に裏打ちされた、非常に興味深い手法だったことだけお伝えしておきたい。興味のある方は、春に出版予定という氏の書籍や、今後の講演等に注目されては如何だろうか。


▼んー、「Activity Based Data Model」ってどういうの？　>> id:habuakihiro