本稿では、2月9日に目黒雅叙園で開催された翔泳社主催のカンファレンス「Developers Summit 2006」から、スターロジック代表取締役兼CEO 羽生章洋氏のセッション「楽々ERDレッスン〜これが楽々DB設計の勘所！〜」の模様をレポートしたい。なお、羽生氏は、Seasarファウンデーションの理事を務めるなど、オープンソースソフトウェア開発コミュニティでも活躍中である。

さて、システム開発の現場において、データベースの設計は特に重要視されることが多い。では何故DB設計が重要なのか、という問いに対し、羽生氏は「DBはアプリケーションをまたがる『超グローバル変数』だから」だと語る。個別のプログラムにおいてさえグローバル変数の使用には注意が必要なのだから、時として複数のシステムに影響を及ぼすデータベースの設計に最大限の注意が必要なのは当然、というわけだ。データベースの設計がいい加減だと、開発プロジェクトは容易に「デスマーチ」に陥ってしまう。

羽生氏は、DB設計のコツとして、まずDB、すなわちデータが過去に行った「行為」の結果を記録したものであることに注目し、「イベント系のエンティティ」からデータの構造を見いだすことが重要だと説く。ここで言う「イベント」とは、業務の本流で発生する仕事のことだ。例えば、「請求する」「請求日」のように「○○する」「○○日」という言い方が成り立つものはイベントだが、「システムに顧客を登録する」といったマスタメンテ系の作業は、イベントではなく「リソース」であるという。「顧客する」「顧客日」が成り立たないのは、顧客の登録はあくまでも請求を行うためにシステムの都合で必要になる付帯業務だからだ。DB設計の上達には、こうしたリソースを扱うマスタメンテ系ではなく、お金に関わるプロセスを扱うイベント系の処理で訓練する必要がある、というのが羽生氏の説く第一のポイントだ。

次に、コード体系とIDを混同しないことも、DB設計には重要であるという。「商品コード」などはあくまでも「あだ名」である。あだ名は「同時にいろいろな呼ばれ方をする」「クラスや学校が変わるとあだ名も変わる」という性質のもので、一意性を保証する「Identifier(ID)」にはなり得ない。確かに、たとえ設計時点で一意なものとして規定したコードでも、運用上の制約から採番ルールが守れなくなるなど、コード体系自体が破綻してしまう例は多い。ID専用の列を設けて主キーとして定義することで、こういった運用開始後の心配が無くなるのは間違いないだろう。

また、羽生氏は所謂「外部キー(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氏の提唱した概念と、羽生氏の豊富な経験に裏打ちされた、非常に興味深い手法だったことだけお伝えしておきたい。興味のある方は、春に出版予定という氏の書籍や、今後の講演等に注目されては如何だろうか。