はじめに

システムの再構築、MDM、データ活用のためのDWH作成時等で、現在保有しているデータが何処にどのような型式で格納されているのかを把握する必要があります。そのためにデータモデルを作ろうというのが今回のテーマです。ASISのデータモデルは現在のデータベースの構造を単にER図として表わすことではありません。即ち、現状のテーブル関連図ではなく、業務視点からデータを捉えたものを作成することです。

ASISのデータモデルの作成は、現状を知るとともに、次期システムのためのTOBEモデル作成の一里塚でもあります。

何を基にデータモデルを作成するか

ASISのデータモデル作成にあたっては、まずテーブル定義書が出発点となります。定義書が無い場合は、テーブル定義の基となるDDL文や実装されているDBMSのデータディクショナリをリバースすることになります。

リバースしただけでは、なぜそのようなデータ構造になっているのかが不明な場合には、オペレーションマニュアルや業務マニュアルやシステム構築したときのドキュメントを手がかりにリバースしたモデルを補完していきます。実データを見ることが出来れば、テーブル間の関係や、ある区分値によって設定されるデータが変わってくる場合に、実際の値で確認できるため、特に有効です。さらにシステム運用者またはシステム利用部門へのヒアリングにより疑問点を解消していきます。

【図5-1.ASISデータモデルの源泉】

テーブル定義をリバースして作成

図のようなテーブル定義書をリバースしても、テーブルをエンティティとしておいただけでエンティティ間の関連付けも出来ません。ASISのテーブルそのものであり、モデルとはいえない状態です。

テーブル定義書を見ると、主キーが設定されていますが「受注ID」、「受注出荷明細ID」といったように、エンティティ内のデータを一意設定するための無意味連番に過ぎません。これでは、受注と受注出荷明細の関連がどうなっているかは分かりませんね。テーブル定義上の主キーは、システムとして実装するために設定したもので、業務からみてデータを一意に定めるものでは無いケースをよく目にします。特にパッケージではそのような設定が多いようです。現に、受注IDや受注出荷明細IDというデータ項目は、画面上何処にも現れずビジネス上も使用されていないものです。

​​​​

【図5-2.テーブル定義書（抜粋）】

【図5-3.テーブル定義書をリバース】

本当のキーを見極める

最初にテーブルに定義されている属性の中から、業務から見て一意になるための本来のキー属性を探すこととなります。受注テーブルの中に「受注番号」という属性があり、これが受注データを一意に定めているデータ項目であろうことが想像できます。その項目が、本当にキーとなっているか否かは、実際のアプリケーションの画面や、データの中味を見ることにより確認することができます。「〇〇ID」は、システムを作る都合から作られた人工的なキーであるのに対して、受注番号のように実務上存在しているデータ項目からキーを捉えるのでナチュラルキーとも呼ばれます。ナチュラルキーで捉えると受注と受注出荷明細は受注番号で関連付けされていることが分かります。

さらに受注出荷明細の属性定義を見ていくと、出荷番号と出荷明細番号があることに気付きます。よって、受注出荷には出荷指示からも関連付けが行われることになります。即ち、受注出荷明細は受注と出荷の両方に拘わる明細データが格納される器であることがわかります。受注か出荷のいずれであるかを識別しているのが受注出荷区分であることが想定されるわけです。

【図5-4.ナチュラルキーの発見と関連付け】

ビジネスルールを読み取る

受注明細と出荷明細の間には、1：ｎ関連があることが想定されます。必ずしも受注の単位で出荷が行われる訳ではないということを表わしています。即ち、1回の受注に対して分割出荷が行われる。同一製品でも引当可能数量分で出荷されることがありうるということです。元々のテーブル構造的には、このようなビジネスルールがあり得るということが類推できるわけですが、実態がどうなっているかはヒアリングあるいは実データを入手して検証してみる必要があります。

重要なのは、現状のテーブル定義を基にそれらの関連を紐解き、どのようなビジネス形態となり得るかを想定して見ることです。モデルを描く、正確には描こうとする際に、曖昧さを無くすためにヒアリングやデータを見ることによって明らかにしていくことです。

【図5-5.ビジネスルールの読み取り】

データのスコープを決める　―関連するマスタを掌握する

受注、出荷には「顧客コード」や「製品コード」が登場していることから、顧客コードを主キーとした顧客マスタや製品コードを主キーとした製品マスタが別に存在しているなということが容易に想像されます。そうしたら、それらのマスタの構造がどうなっているか、定義書やデータのサンプルを入手して調査範囲を広げていきます。

同じ顧客コードとしていますが、受注した顧客と出荷先の顧客は別の顧客コードかも知れません。その真偽を探るために、顧客マスタの構造を調査し、受注や出荷の実データを参照してみることが必要となります。このようにしてASISのデータ構造を概念化して表わしたモデルが作成されます（図では便宜上エンティティのみの表示としています）。これと実装されているテーブルとを紐づけておくことになります。
 

【図5-6.ASISモデルの概念化】

システム更改時にデータ整備対象の範囲を何処までとすればよいか悩まされることがありますが、エンティティ間の関連から捉えることが出来ます。ASISモデルとは、現状のテーブル定義を配置して関連付けをしたものではなく、ビジネスの実態を見えるように概念化したものです。概念モデルと実態のテーブルとの関係を定義しておくことにより、業務からデータへ、逆に実装されているデータから業務でどのように利用されているかを知ることが出来ます。

ASISモデルの先にあるもの　―データアーキテクチャに向けて

ここまで描いたモデルは、特定の業務の一部のモデル、即ち地域地図にすぎません。ここから日本地図、世界地図へと領域を広げていけば、企業内（一部は外部のデータも含むでしょう）のデータの所在が明らかとなる地図が完成します。これがデータアーキテクチャといわれるものです。

実際には、世界地図からどのように分解して日本地図にするか、さらに日本地図をどのようにして地域地図に分解していったらよいかという、やや難しい問題があります。これは、サブジェクトモデルと呼ばれているものです。

データのアーキテクチャを起点として、データがどの業務でいかように使われているかのビジネスとの関わり、業務システムの何処で参照されているか、何処でデータが塗り替えられているかのアプリケーションとの関わりまで含めて整備することがデータアーキテクチャには求められます。

おわりに

以上で全５回に渡って、なぜデータモデリングが必要かというテーマで記させて頂きました。データモデルは、システムを作る側でのドキュメントとして必要なだけでなく、システムやデータの利用者である業務部門との意思疎通を図るためのツールとしての役割が大きくなってきています。

データモデルを描くことについて、１つでも納得して頂けたところがあれば幸いです。