前置き
12月から個人有料会員になっているDAMAというデータマネジメント協会コミュニティ内にある、データモデリング分科会のオフラインイベントに参加してきました。
今回のテーマは、
「データモデリングで工夫していること」「よいデータモデルの特徴」です。
また、概念・論理データモデリングの部分にテーマを絞り、物理の部分はスコープ外としていました。
なぜデータモデリングが必要なのか？
そもそもなぜデータモデリングが必要なのでしょうか？
まずはよいデータモデルの特徴から触れていきましょう。
よいデータモデルの特徴
よいデータモデルの特徴として、以下が挙げられました。
解読しやすい
拡張性に富んでいる
シンプルである
One Fact in One Placeである。
1つの事実が1つの場所にのみ存在する ということ
これ以外にも、個人的に以下があると感じます。
トランザクション境界の位置がわかりやすい
吉村さんトーク
吉村さんによると、三段階に分かれるという。
全社レベルとしての品質
システム要件品質
設計の品質
既存のデータ構造の可視化の際に必要
今持っているシステムと、システムごとのデータのAsIsの可視化のために
データモデルを作成することで理解がしやすいからとのこと。
システム単位でのリバースモデリング→全システムのデータモデルを作成
という順で、ミクロレベルからマクロレベルへリバースし、全体像を把握しやすくできるからとのこと。
どんなシステムが存在していて、それらの間にどのような関連っがあるのか？
を可視化するうえで、データモデルを作成することはマストである。
どういうデータがシステム間を動くのか？というデータの動きをDFDで表現したいときに
データモデルの必要性を感じるためでもある。
データの静的な側面のモデルだけでなく、
データの動的な側面のDFDのモデルも必要であることはアーキテクチャ原理。
メタデータの際に必要
データマネジメント的な話で、
どんなデータが、どこにあって、どんな目的で使われるのか？というデータの意図が、
不透明なことが多々ある。
そのようなデータの意図が説明させたデータをメタデータと言い、
それを考える際に、どうしてもデータモデリングが必須であるからとのこと。
たとえば、社内の他のシステム内に同じぽい名前のデータ(同意義のデータ)ないか？
とか、データのコンテキスト境界などを考える際に、メタデータがないと大変。
作るのは大変だけども、ないと後々大変
お客さんが描いたなんちゃってデータモデルよりも、キー制約とかの構造のわかるモデルがないと大変。
これは、ヘッダと明細パターンのように、テーブル同士の親子関係の可視化など、
業務の深い理解があるデータモデリング知識が必要。
個人的主観
全社レベルのエンタープライズデータモデルがあることによって、
再利用できるテーブルのグループ(サブジェクト)なんかも認知しやすい。
パッケージのデータモデル
再利用できるパッケージのデータモデルの話も飛び交いました。
具体では異なるデータモデルでも、汎化したら似たようなデータモデルのパッケージ製品。
そのデータモデルが、どうやらあまりにも具体的すぎるという問題があるそうです。
この解消のためには、複数の具体なデータモデルをいくつか並べて
そこから帰納法を使って汎化されたデータモデルを作ることが求められるように感じます。
ですので、是非データモデラーさんたちには帰納法や演繹法をマスターしていただきたく思います。
ただしその際に注意したいことは、
汎化したデータモデルだからと言って、あまりにも抽象的な属性名や
テーブル名のモデルにはしてはならないということ。
この注意点に関しては、次のジェネリックモデルで触れます。
ジェネリックモデルとスペシフィックモデル
まずジェネリックとスペシフィックの言葉の定義から。
ジェネリックモデルの説明
利用意図として上記の汎用パッケージ化を目的に、
カラム定義やテーブル名がやや抽象的で曖昧に表現されたもののことを指す。
スペシフィックモデルの説明
固有の具体的な部分を表現することが目的のモデルであり、
カラム定義やテーブル名が具体的であるものを指す。
両モデルを使う
両方にはそれぞれの良さと悪さを持っている。
エンタープライズデータモデルすべてをスペシフィックで表すと、
すべてを０から構築しないといけないため、非常にコストがかかってしまう。
かといってすべてをジェネリックで表現しては、
ビジネスの競争優位性を発揮する差別化された箇所のデータモデルが一切ない状態となる。
そこで、差別化を図る必要がない所には、適度にジェネリックモデルを取り入れることで、
コストを投下すべき箇所、つまりスペシフィックモデルの部分に集中させやすくなる。
私個人が思う良いデータモデルの特徴
私の思う良いデータモデルの特徴をいくつか列挙したいと思います。
① 方針が明言されている
データモデルの分割、グルーピングの仕方の方針が定義されていること。
これがないと、どこで区切ったりなんて全くもって議論になりません。
分割された各サブジェクトの中では、それぞれの方針があるものの、
全体に対して一定のポリシーは必要です。
② コンテキスト境界の位置が一目瞭然
①の上で、各サブジェクトの境界の位置が明確であること。
分けられたグループは、グループ内のテーブル同士の結合状態よりも疎でないと
意図に反します。
この考え方は、アプリケーションにおける高凝集・疎結合の思想と一緒です。
③ トランザクションが考慮されている
「ここは強い整合性」「ここは弱い整合性でいい」
といったことが矛盾なく外部キー制約で表現されていることです。
②とも関連が強い内容ですが、「このテーブルとこのテーブル間は強い整合性」といっているのにもかかわらず、異なるサブジェクトに置かれているというのは明らかに矛盾しています。
どこの範囲内において強い整合性が求められるのか？
その境界位置を考えるためには、データモデルだけの考察だけでなく、
トランザクション単位の考察まで踏み込んだ状態で、トランザクションの境界位置の議論をしなくてはなりません。
その内容をもとに再度データモデルに戻ってきて、キー制約などを定義します。
キー制約によって強く結合されたテーブル同士の間に境界を定義するなんてことは絶対にしたいと思わないです。
④ ステークホルダーの視座と関心に応じたデータモデル
データモデルを全体的にマクロに見たいのか？
それとも一部分だけをミクロに見たいのか？
それはステークホルダーの関心に対応した視座の高さに応じて異なります。
経営層ならば、詳細に表現されたデータモデルではなく、全体をマクロに俯瞰したものがほしいはずです。
しかもテーブルの各属性なんて、この視座から見たらミクロすぎるので、関心に含まない方がいいでしょう。
エンジニアであったとしても、全体感を見なくてはならない人であるならば、
属性は除外して、各サブジェクトの代表テーブル同士の関係性だけで十分でしょう。
こんな感じで、対象のステークホルダーの関心に応じて、
属性を表示した詳細なデータモデルであっても、関心の外にある属性に関しては、
モデルに出さない というのが守られているべきものです。
AsIs→ToBeの際の問題点
AsIsのデータモデルにおける境界位置と、ToBeデータモデルのサブジェクト境界位置は
大きく異なっているかもしれない。
その際に問題になってくるのが、AsIsの主キー制約の呪い。
これは、キー制約を強制的に無理やり解除するという、
比喩するなら接着剤でべったりくっついたテーブル同士を無理やり引きはがす行為。
そのため、一度定義されたキー制約を変えるのことは容易でない。
一応その手法は、以下の書籍の６章【業務データの分解】で触れられている。
しかしながら、超絶めんどくさいし、以下の理由で非常にコストのかかる行為である。
・脅威モデリングなどの手法を用いて、境界位置を無理やり剝がすことの副作用分析を行う。
・価値駆動モデリングを用いて、境界位置をToBeに向けて変えるリターン分析を
キー制約をはがしてToBeに移行させるコスト踏まえた状態で行う。
これらを行い、天秤にかける必要性と定量化は不可能なので定性評価しなくてはならない。
トップダウン or ボトムアップ式か
モデリングをどう進めるといいのか？という議論も出ました。
大きくトップダウン的アプローチと、ボトムアップ的アプローチがあります。
データモデリングでは、トップダウンとボトムアップにはそれぞれのメリデメがある。
それを表にして以下にまとめました。
新しいビジネスを行いたいときには、トップダウン式。
既存のものをシステム化したいって時には、ボトムアップ式。
ただ実際には、割合の程度の差はあれども、両軸からのアプローチがよくとられます。
それは新しい価値を創造しつつも、既存のものを自動化したいという思いからと思われます。
アンチパターン集
このトピックの中でアンチパターンについても触れられていました。
主に以下の３つに触れられましたので、順に書きたいと思います。
① As-Isの呪い
これはよくあるパターンです。
既存のものや、既存の技術的制約に縛られたデータモデルを定義するケース。
出来上がったものは、すでにあるものとほぼ同じようなものがただ自動化されただけ
という感じになります。
これは逆算思考ない状態の時によく起こることのように感じます。
対処法としては、まず目標であるToBeを描く際には、
既存のデータモデルや技術的制約は一切忘れて自由に描く。
そのうえで、ボトムから今の制約を踏まえて、あまりにもToBeまでの道のりが遠いのなら、
データモデルのロードマップを描く という感じです。
ロードマップに関しては、TOC(制約理論)のアンビシャスターゲットツリー
の考え方を用いることで、論理的におかしくない道筋を立てられます。
そして、そのロードマップ中の各中継地点をマイルストーンとして、
データモデルを進化させていく感じになります。
② 同じものなのに別システム使ってる
同じものを作っていて、しかも同じ事業であるにもかかわらず、
全く異なるシステムを使っているケース。
これは全体をマクロに見たデータモデルを理解していないがゆえに起こる。
そのためこのケースでは、工場のラインの置き方などが個別最適になりやすい。
対処法としては、いきなり視野を広げることは現実的でないため、
チームトポロジーの連携モードパターンなどを用いて、
他のチームと密に連携し、徐々に全体のデータモデルを明らかにする。
そして、俯瞰スキルの高い少数チームにて、
その全体感を見て、
重複をなくす作業や名前寄せ含めたデータモデルの改善
サブジェクトの境界位置の検討の上、どこに投資すべきなのか検討
といった戦略的データモデリングを行うといった感じである。
③ To-Beしかなくてデータ移行できない
これはたまにあるある現象。
AsIsなくて、しかも制約条件もわかっていない状態で、ToBeだけしかない状態。
これでは、物理データモデルまで落とし込むことは不可能。
対処法としては、ToBe論理データモデルに対する、AsIs論理データモデルの差分の可視化。
および現状の制約条件、たとえばRDBを１つしか使えないといった制約を明らかにする。
そしてその差分を埋めるためのロードマップを描く。
これは上記のTOCアンビシャスターゲットツリーの考え方と同様である。
豆知識
トップダウンアプローチは過去のうまくいった事例などのドメイン知見がないと
なかなか厳しそう。
これはたしかに上記の③を考えると容易に想像がつく。
画期的なToBeデータモデルを思いついたとしても、そこまでのロードマップを描きなければ
宙に浮いた状態になってしまう。
過去のベストプラクティス以外にも、アンチパターンとそのメカニズムをどれだけ理解しているのかも、トップダウンアプローチには必要と思われる。