私が所属している企業は、プロダクト・サービス/データインテグレーション(プロフェッショナルサービスのようなもの)という２本の事業の柱を持っています。
私自身も、キャリアの多くをSIで過ごしてきましたが、直近ではプロダクト開発に軸足を置いています。
SIのようなエンタープライズ向けのシステム開発と、プロダクト開発においては大きな違いがあります。
一番大きいのは前者においては物事を考える単位がプロジェクトであり、有期性があるというところです。
何か問題が起きたときの対応にも考え方の違いがあります。
有期性のあるプロジェクトでは、たとえば何かインシデントが発生して対処をしたあとに、今回のプロジェクト範囲内で類似の漏れがないかを横断的に確認をし、対応完了とします。これはいわば外科的または西洋医学的な対応といえます。
一方で、プロダクト開発はある程度期間の継続が見込まれるために、インシデントが発生した場合には、どこのどういうプロセスにエラーがあるか特定して改善を試みます。
これはまさに体質改善で内科的もしくは東洋医学的な対応と言えるでしょう。
もちろんこれはあくまで軸足の違いであり、どちらかしかやらないということは現実的にはないでしょう。
エンジニアリングのプラクティスがいかに整備されたとしても、それが企業活動の一部を担う以上、おかれている状況によって考え方の違いが生まれるのはある意味当たり前のことといえます。
最近、当社では100人規模のデータマネジメントのトレーニングを実施しました。
トレーニングを進める中で、データモデリングの考え方も状況によって大きく異なるということにあらためて気づきましたので、以下に代表的な例を書いていきます。
サロゲートキーとナチュラルキー
リレーショナルデータベースを利用したアプリケーション(OLTP)において、現時点でプライマリキーに何を置くかというと、サロゲートキーが選択されることが多いと思います。
これには時系列的な背景があります。
以前はナチュラルキーが一般的でしたが、その限界が見えてきたためサロゲートキーへ移行してきました。
ナチュラルキーの限界というのは、企業活動を実施していると業務ルールの変更に応じてプライマリーキーが変更されることがある、つまりドメイン依存が強いというのがわかってきたことを指します。
店舗コードをプライマリキーにしていたものの、店舗再編などによりキーを更新したいような状況は何度も目にしてきました。
今選択するのであれば、サロゲートキーでキー設計をしたうえで、必要に応じてナチュラルキーにあたるものにユニークキーを割り当てた方が弾力性があるという結論になると思います。
ただし企業向けアプリケーションであれば、あえてユニークキーを貼らないという選択肢もありえます。
これはやはりドメイン追従性を重視し、弾力性・変更容易性を確保するためです。
また、ITベンダー開発ではスキーマ変更に追加費用が発生することもあり、その意味でも制約を弱くする判断が取られることがあります。
一方で、データ利活用領域に目を移すと、様相が変わります。
データエンジニアリングに従事したことがある方は経験があるかもしれませんが、多くのものがナチュラルキーで設計されています。
最初に重要な前提情報として、多くのDWHでプライマリキーが制約として機能しないということを述べておきます。
プライマリキーが制約として機能しないのに、なぜ存在するかというと、メタデータとしての価値があるからです。
多くのデータエンジニアはカーディナリティとディストリビューションからデータを紐解こうとします。
そのときにプライマリキーとしてナチュラルキーが設定されていると認知負荷が大きく下がります。
そのキーが人間にとって意味を持つため、データを読むスピードが圧倒的に上がるということですね。
もちろんこれはデータカタログや設計ドキュメントなどで補うことはできる情報ですが、それらの整備が追いついていないのもありますし、何より、データだけ見ればわかるというのは大きなメリットです。
ひとつだけ補足すると、エンタープライズにおいてデータ基盤に集めるデータはかなり歴史ある基幹システムなどが中心となります。
元データがナチュラルキーで設定されているので、DWHもナチュラルキーで設定している、というケースも多いです。
スタースキーマやスノーフレークスキーマのようなデータ活用に寄ったデータモデリング手法がクローズアップされやすいですが、こちらも意識されづらいが重要な違いだと思います。
ポリモーフィック関連に対する扱い
SQLアンチパターンの中に、ポリモーフィック関連というものがあります。
これは1つの外部キーで複数のテーブルを参照できるようにする設計で、参照整合性を保てなくなります。
具体的には、外部キー制約が貼れなくなったり、ORM が対応していないケースがあったりと、DB レイヤーでの整合性保証が難しくなります。
SQLアンチパターンに記載されるくらいですから、一般的にはよくないこととされています。
私がプロダクト開発に関わったときに、一番驚いたのがこのポリモーフィック関連に対する考え方でした。
（アンチパターンとして知識では知っていたものの、エンタープライズ開発では普通に使われていたため、そのギャップに驚きました）
ポリモーフィック関連は、ある条件下ではドメイン追従のための変更に工数をかけない選択でもあります。
エンタープライズ向け開発では、競争力維持のための業務変更が頻繁に起こるため、ドメイン追従が非常に重要です。
その前提で、ドメイン整合性をどこで担保するかというと、データベースではなくアプリケーションで担保する判断が多くなります。
合理的に考えると、DB レイヤーで表現すべきルールをアプリケーションで実装していることになりますが、変更されることを前提にするならアプリケーションレイヤーのほうが変更容易性が高いためです。
一方で、プロダクトはその性質にもよりますが、ドメインモデルが頻繁に変わることは比較的少ないです。
そのため、変化しにくいドメインでは データベースレイヤーで取るべき整合性はデータベース側で確保するのが最も合理的ですし、
テーブル設計自体がドメインの制約を表現しているほうが構造としてシンプルになります。
たとえば、Aテーブルが「条件に応じて B・C・D のいずれか」を参照するロジックがあるとします。
ポリモーフィック関連を採用する場合
A テーブルには以下だけを持てばよい
- 参照区分（B/C/D など）
- 参照先のキー
ここに新たに D テーブルが追加される際は、
- 区分値に「D」を追加する
- アプリケーションのロジックを修正する
だけで済みます。
Aテーブル自体は一切変更不要 です。
これはエンタープライズ開発では調査工数が少なく済むという大きなメリットがあります。
ポリモーフィック関連を避ける（正規の参照設計にする）場合
A テーブルには以下のカラムが並ぶことになります
- Bテーブル用参照キー
- Cテーブル用参照キー
- Dテーブル用参照キー（今回新設）
つまり D 対応のために A テーブルのスキーマ変更が必須 になります。
調査工数は増える可能性がありますが、A テーブルを見ただけで
「AはB/C/D のどれと関係しうるのか」を把握でき、ドメインモデルの限界がテーブル構造として明確に表現されるというメリットがあります。
ポリモーフィック関連がアンチパターンとされるのには明確に理由があります。
ただし、状況によっては合理的な選択になるケースもあるという例だと思います。
さいごに
データモデリングの中で特に状況によって考え方の違う２点をピックアップして述べてきました。
同じデータモデリングという行為でも、前提が違えば判断基準も選択肢も変わります。
結局のところ、データモデリングは技術の話ではなく前提の話だとも言えるでしょう。
長くエンジニアを続けていると、急にデータエンジニアになったり、急にプロダクト開発をすることになったりということもあるでしょう。
なぜ、それが選択されているかという点で、その背景に思いを巡らせてみるのも面白いと思います。