データベース設計で派生関係は難しい

@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。
下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。
気になった点をメモしておく。
理解できたことをラフなメモ書き。

【元ネタ】
Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR

ソーシャルゲームのためのデータベース設計 from Yoshinori Matsunobu

【1】可用性や整合性に関する要求が意外と多い
たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。
データモデリングはアーキテクチャ設計につながる。

【2】派生関係
データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向設計（OOA）と同様に存在する。
但し、データベース設計の派生関係はOOAとはニュアンスが若干異なる。
DOAの派生関係の方がOOAよりもはるかに難しい。

DOAでは、派生関係は1対0..1の関係になる。
但し、完全・不完全、排他・共有の2種類の意味を持つ。

完全の派生関係は、スーパータイプのインスタンスは必ずどれかのサブタイプに属すること。
例えば、会員のサブタイプを個人会員と法人会員の2種類に分けて、会員は必ず個人会員又は法人会員のいずれかに属する場合、完全な派生関係になる。
不完全は完全の逆。
不完全の派生関係の場合、どのサブタイプにも属さないスーパータイプのインスタンスが存在する。

共有の派生関係は、スーパータイプのサブタイプが複数のサブタイプに属すること。
例えば、取引先をスーパータイプ、仕入先や得意先をサブタイプにした場合、仕入先かつ得意先でもある取引先があるなら、共有の派生関係になる。
排他は共有の逆。

上記の資料では、アイテムをスーパータイプに持つ場合、攻撃アイテム、防御アイテム、補助アイテムはおそらく完全の派生関係になるようにモデリングしていると思われる。
アイテムは、攻撃・防御・補助のいずれかに分類されるだろうから。

又、ユーザIDを主キーに持つテーブル群であるゲーム共通情報、ゲームのメイン情報、イベント中のユーザ情報などは、共有の派生関係になるようにモデリングしていると思われる。
共通情報・メイン情報・イベント中のユーザ情報のいずれにも含まれるユーザIDは存在するだろうから。

本来、派生関係を導入してモデリングすることによってモデルを綺麗に見せるようにするためにあるのに、DOAの派生関係が難しい理由は、完全・不完全と排他・共有の2種類の派生関係を混乱しがちであることと、概念データモデルを実装レベルのER図に落とす場合にスーパータイプとサブタイプの関係をそのまま射影するとは限らないからだ。

佐藤正美さんが提唱するT字形ERでも、サブセット(サブタイプ)の生成はSEの腕の見せ所、という表現がある。
多分、そういう意味が込められているのだろうと推測する。

【3】階層型部品表
ゲームに登場する人物(戦士、武闘家、僧侶など)を階層型部品表で設計しているのは面白い。
この設計手法は再帰型でモデリングしているのと同じ。
となると、LLC(階層の深さ)が問題になるはずだが、どうやって制御しているのか、気になる。

【4】連関エンティティ(対照表、対応表)
ユーザID＋αで一意になるテーブルは、ユーザと別のリソース系マスタから生成される連関エンティティを指す。
つまり、ユーザID＋αが複合キーになる。

「ユーザID+αで主キー/一意キーになるものはレコード数が 飛躍的に跳ね上がる」意味は、ユーザと別のリソース系マスタの組合せだから、当然レコード数は大幅に増えるはず。

また、人と人の関係を管理するために、連関エンティティがイベント系テーブルになっているのも興味深い。
この設計手法が使えるのは、ユーザマスタのサブタイプを細かく作っているから、それらのサブタイプを組み合わせれば、連関エンティティ(対応表)が発生するからだ。

佐藤正美さんが提唱するT字形ERで、リソースの数が多いほどトランザクションをたくさん生成できるので、ビジネスの可能性があるという指摘を連想させる。

【5】スキーマ、トランザクション、インデックスはもっと評価されるべき
RDBだろうがNoSQLだろうが、結局、ディスク性能(I/O)が一番のボトルネックになる。

Insert処理をメインメモリ上で関係させるためにインデックスサイズを小さくする、ないしはインデックスを作らないようにするとは、テーブルを徹底的に正規化することなのだろう。
つまり、NULL値を持つカラムは派生関係を使って排除し、インデックスの発生源となる候補キーを無駄にたくさん作らないようにすればいいのだろう。

【6】楽観ロックによる整合性管理
トランザクションの更新は楽観的制御を用いた方が楽ということなのだろう。
Versionパターンとは、トランザクションテーブルのカラムにVersionというNumber型のカラムを作っておき、更新する度にインクリメントさせて、二つのトランザクションが競合する時、Versionカラムの値を比較してロックの制御をかけるという意味だろう。

【7】イノベーションは現場で起きている
データモデリングも理論ばかりではなく現場の経験も大事であり、現場の実例があるからこそ、次への飛躍につながる。
この言葉は、特に下流工程で技術革新が起きている最近で言えるように思う。
データモデリングだけでなく、プロジェクト管理も品質管理技術も、最近はツールを上手に使えば、現場での経験値を増やすことで、プログラマもそれらの技術をマスターしやすくなっている現状がある。

データベース設計に関しては又まとめていく。