自分流モデリング探しの旅(1)〜楽々ERDレッスン (CodeZine BOOKS)

データモデリングについては、これまで、その場その場で、
結構アバウトな自己流でやってきた節がある。
そこで、改めてデータモデリングについて見つめ直したいと思う。
最終的には、定義された自己流を構築したい。

という訳で、最初に読み直したのが、この本でした。

楽々ERDレッスン (CodeZine BOOKS)

半年くらい前に、一回読んでいたのですが、改めて、読み返しました。
「RDBMSが蓄積したデータは、その企業の経営資産だ（ただしアウトプットとして
活用できること）」
という言葉は、これからデータモデリングを時間をかけて考えていくことの
励みなります。なぜなら、その大切な経営資産を、使いやすいように、
アウトプットを効率よく切り出せるように、データ間の整合性の取れた状態で
保管することが、DB設計だと思うからです。
DBを加工するプログラムは、最終的には捨ててしまうこともできる。
しかし、DBはそうではないですよね、と。
また、システムの視点に立てば、「巨大なグローバル変数のようなもの」であるDBを
きちんと整理してあげることもDB設計の重要な役割であると考えられるわけですね。

この本において、特に重要なのが
「id(ポインタ)」の導入。

コードとキーは違いますよという話。
「コード体系はユーザがデータに到達するためのUI」
「コード体系はシステムの都合ではなくビジネスの都合によって決定される」
という考えから、entityのキーとして設定すべきなのは、
ビジネスで実際に用いる、従業員番号や品目コードではないということが
わかる。キーだから、そのコードを変更できない・重複できないというのは、
まさにシステムの都合であって、ビジネスの視点では、関係のないこと。

というわけで、ビジネス上の価値を持たない、ユニークなキーとして
idを全てのentityに振るわけですね。
この辺は、railsでも見られる考え方。

では、具体的にはどんな感じになるのか？
例えば、売上というeventを考え見る。

売上テーブル

1. 伝票番号
2. 売上日
3. 売上担当者

売上明細テーブル

1. 伝票明細番号
2. 伝票番号
3. 品目コード
4. 数量
5. 金額

品目テーブル

1. 品目コード
2. 単価

よくある感じですね。
しかし、この場合、品目コードの体系が変わったりすると、
データ移行などシステム的な手当ての考慮が必要となる。
idを導入すると以下のようになる。

売上テーブル

1. 売上ID
2. 伝票番号
3. 売上日
4. 売上担当者

売上明細テーブル

1. 売上明細ID
2. 伝票明細番号
3. 売上ID
4. 品目ID
5. 数量
6. 金額

品目テーブル

1. 品目ID
2. 品目コード
3. 単価

品目IDと品目コードが並んでいることに、奇異な印象を受けるが、
確かにこの構造であれば、そのデータの場所を指し示している場所、つまりid（ポインタ）は不変なため、品目コードの体系が変わろうと、そのデータを指し示す事実は変わらないことになります。

まとめ

entityにidを導入することで、コード体系に対する柔軟な設計を行うことができる。