はじめに

「データモデルは本当に必要か」の連載、第３回目となります。前回は、システムの開発、DB設計という観点でデータモデルの必要性について述べさせて頂きましたが、今回は、ビジネスの実態を把握するためにデータモデルを描きませんかという話です。

日本語でのビジネス実態の表現とそれをデータモデルで表現したものを対比してみます。自然言語、とりわけ日本語では曖昧だったり、人によって解釈が異なったりすることが想定されますが、データモデルで表わすことによって、厳格な表現が出来るので避けられると考えます。

ビジネス実態を表わす概念モデル　―分類して実態に近づく

ある製品を製造しているA社でのモデルで見てみます。

部品の調達先と完成した製品を販売する得意先があり、まとめて取引先と呼んでいます。調達先が得意先となることもあり、同じ取引先コードで管理しているという実態があります。これをデータモデルでは、共存関係の分類概念として表わしています。

A社では原材料を加工して製品を製造していますが、原材料を組み合わせた状態を中間製品と呼んでいます。原材料、中間製品、製品には、それらを識別するための品目コードを採番して管理しています。そして、製品または中間製品、原材料部品のいずれかに相当するかは品目区分で分類できます。この場合、製品、中間製品、原材料部品は排他関係にあることになります。

【図3-1.分類】

このように、取引先や品目を分類してより具体化して示すことにより、取引先や品目が何を表わしているのか、具体的にどんなものが入るのかがわかってきます。何よりも、日本語で長々と説明してきましたが、データモデルを見れば一目瞭然ではないでしょうか。

ビジネスを分り易く表現する　―階層構造を表現する

製品は多数の部品が組み合わされており、その親子関係が製品構成で定義されています。データモデルでは、品目から製品構成に２本関連線を引いて表現します。１本は親品目コード、もう１本は親品目に必要な部品あるいは中間製品を表わす子品目コードを表わします。このように、品目コードが関連先で名前を変えて登場する場合があります。もちろん、親品目と子品目は異なったデータを指すわけです。実際のデータ設定例を示しました。
​​​​

【図3-2.製品構成】

【図3-3.製品構成データ例】

わざわざ、製品構成という別のエンティティを用意しなくても、各品目に対して親品目コードを持たせて関連付けられれば良い思われる方もいらっしゃるかもしれませんが、「ｄ」品目のように親品目が「ａ」と「ｃ」の２つがある場合はギブアップとなります。自身の親を表わすものが1つであれば、エンティティ自身に関連付けを行う「自己参照関係」のモデルとして捉えることができます。

【図3-4.自己参照による表現】

このような品目の構成はBOM（Bill Of Material)と呼ばれていますが、社内組織を表わす場合も、これと似たような構造となります。データモデルでは、業務や業種が異なっても、同じパターンを適用することができる場合があるので、初めての業務であっても毛嫌いせず過去に経験したモデルの一部が適用出来ないか考えてみることによって、モデリングのスキルを向上させることができるでしょう。

ビジネスを分り易く表現する　―対称性

業務上現れるイベント（活動といっても良いでしょう）は、売りと買い、入金と出金、入庫と出庫、入社と退社といったように対で現れることが多く、そのモデルは対称形で表わすことができます。図では、発注→入荷→買掛と受注→出荷→売掛の関係を表わしています。

この図のように、発注と受注の関係は左右で対称となっていることが見てとれると思います。関係するマスタも取引先と商品で共通です。このように、片方、例えば発注側のモデルを描いた場合に、対となる受注側のモデルを捉えるように習慣づけることは、モデルの充足度や完成度を高める上で必要となります。

【図3-5.モデルの対称性】

では発注と受注は同じ構造になっているので、一つにまとめられないかと思われる方もいらっしゃるでしょう。発注と受注を1つのエンティティ「取引」としてまとめることは可能で、汎化すると言っています。システム的にはもちろん可能なのですが、データモデルで現わした場合、業務の実態が見えなくなってしまいます。取引エンティティには、発注と受注のデータが混在することになるので区分を設けてどちらのデータを対象としているのかを意識する必要があります。汎化することによって拡張性は広がりますが、ビジネス表現がわかりづらくなるので注意が必要です。ERPなどのパッケージでは広く適用できるように汎化されていることが多いですが、あくまで作る側に立ったモデルです。私たちが、ビジネス要求や要件を捉えるためのモデルでは汎化し過ぎると誰も理解出来ないものとなってしまいます。

【図3-6.汎化したモデル】

ビジネスとはお金を稼ぐことですから、多くは会計仕訳伝票に帰結することを念頭においてモデルを作成していくと良いでしょう。会計システムはスコープ外ということで、モデルから除外するのでは無く、少しだけ隣接領域に踏み込んでモデルを作成することをお薦めします。システム化にあたっては必ずインタフェースとして必要になってくるところです。

より洗練されたモデルはシンプルで関係線の錯綜も少なくなってきます。先に述べた対称性も念頭において見直すことで、業務を正確に投影したモデルとなっていきます。

ビジネスルールを表現する

唐突ですが、何処の会社においても企業システムには3大マスタと呼ばれる種類のマスタがあります。組織・社員に代表される社内のリソースに関わるもの、仕入先や得意先、顧客に代表される取引先関係、そして製品や商品あるいはサービスと呼ばれるビジネスの糧となるものの3つです。

通常、各々のマスタは取引先と得意先の関係や製品と原材料の関係など、それぞれの領域内で関連が定義されます。

ここで、販売価格は製品毎に標準単価が設定されていますが、得意先毎に異なった販売単価が設定されるという社内ルールになっているとします。データモデルでは得意先と製品の2つから関連付けられる「販売価格」エンティティ上に販売価格という属性を設定することで表わすことができます。このように、取引先と商品・サービスという2つの領域のエンティティを交差させて表現したものをビジネスルールと呼んでいます。ビジネスルールは、データモデルで表わせば一目瞭然ですよね。言葉や絵で説明するよりも明快で、関係者間での認識齟齬もなくなります。

原材料の調達についても同様で、調達価格は調達先と品目によって定まるというビジネスルールがあることがわかります。

【図3－7．ビジネスルール】