前のページへ サイトマップへ ホームへ
 
DOAコラム一覧へ次のコラムへ
DOA Evangelist:小見山 昌雄


  データ中心アプローチの特長を表すのに、「プログラムは不安定だが、安定しているデータに依拠している」と言いますが、最初にその話を聞いた時、私が思ったのは「そんな馬鹿な」でした。
 「確かにプログラムは保守工程に入ってから修正も度重なり安定している状態であるとは言えませんが、データは、一旦登録された後も、日別・締め別・月別などと処理の中で次々と更新されており、これを安定しているとは言えないだろう」と言うのが正直な感想でした。
 もちろんこれは、ビジネス上の事実を記録したデータと、そのデータから二次的に導出されるデータの違いなど、データの区別と性質が理解出来ていなかったためです。
 と言うことで、今回は先ず、データの安定性を中心にデータの種類と、その特徴について説明します。
 ISO9000シリーズなどのおかげで、今や「文書」と「記録」の違いは常識となりました。
 文書は、必要に応じて適宜改訂・変更し、版を重ねて使いますが、記録に変更はありません。
 「記録」は存在や発生などの事実を記録したものなので、誤って記録してしまったことを正すことはあっても、記録を改訂したり変更したりすることは有り得ないのです。
 (一旦発生した「売上」と言う事実は無かったことには出来ません。 これを記録した売上データも変更や削除は出来ません。 ちなみにキャンセルや金額変更などは新しい別の事実として記録します。)
 「記録」は全て事実に基づいて行われるので、これを恣意的に変更することを「改竄」、作ることを「捏造」、消すことを「隠蔽」と表現しますが、これらは何れも通常悪用する場合の表現です。
 ビジネスの要素を説明し、記録するために必要なデータ項目は、ビジネスによって決まっているので、ユーザインターフェースの要求やシステム・プログラムの作りなどに左右されることがありません。
 つまり、データ中心アプローチは、変更されることの無い、記録としてのデータを拠り所としているので、安定したシステム構築が可能となると言う理屈です。
 確かに、現実のビジネスで起こった事実を記録するデータだけであれば、その発生の単位を把握することも容易で、データ分析も簡単に出来るでしょう。
 しかし、一方に冒頭紹介したような頻繁に更新されるデータが存在することも事実です。
 つまり、データは1種類で全てが同じ性質であるという訳では無いのです。
 これを適切に分類し、それぞれの類型ごとに適切な扱いをしていかないとデータ中心アプローチは成り立ちません。
 安定したデータに依拠したつもりが、不安定なデータを頼りにしていたのでは、安定したシステムを構築するのは難しくなってしまいます。
 そこで、それぞれに適切な扱いを考えるために、データの分類を検討して見たいと思います。
 なお、文中「データ」と表現しているのは、もちろん「データ項目」(売上数量・商品名称)のことで、「データ」自体(3個・チョコレート・300円など)のことではありません。
 話(文章)の調子で一々「データ項目」とは断っていませんが、ここで3個・チョコレート・300円に関する議論はないので、このあとも全て「データ」は「データ項目」とご理解下さい。


 データの分類を考える場合にいくつかの分類観点があります。
 表に代表的な分類観点を列挙します。
分類観点 分類要領
・入力 ・入力する「入力データ」と入力せずシステム内部で導出する「非入力データ」または「内部導出データ」に分類
・導出 ・「売上金額」=「売上数量」×「商品単価」などの導出ルールを持つ「導出データ」と持たない「非導出データ」に分類
・Fact/View ・「顧客氏名」の「顧客」や「売上数量」の「売上」のように、そのデータ項目が説明しようとするビジネスの構成要素が明確な「Fact」とそれ以外(「View」)に分類
1.入力データと導出データ
 当然のことながら、システムで使うデータは入力しなければなりません。
 また、入力されたデータを元に、システムの内部での計算処理で新しいデータを作ることも可能です。
 前者を「入力データ」、後者を「導出データ」とした場合、これを対立概念と考えると調子が良いのですが、『「売上金額」(ここでは、売上金額を「商品」が持つ「単価」と「売上」が持つ「売上個数」から導出される導出項目と考えます)を入力させて、システム内部で再計算した値と突合させて関連するデータをチェックする』のように、導出データを入力する場合もあるので、これを直接の対立概念とすることは出来ません。
 そのため上の表のような分類観点として整理しますが、ここで必要な判断は、そのデータは安定しているか、そのデータはデータ分析の対象かと言う事です。

 *注:「データ分析の対象」とは、
 データ分析は、成果物としてデータモデルを作りますが、そのデータモデルの中に書かれるデータは、データ分析の対象であり、書かれないデータは分析対象では無いことになります。
 例えば、「受注数量」などは、分析対象ビジネスの構成要素「受注」を説明しているデータなので、データモデルの中に「受注」を説明するデータ項目として書かれますが、その「受注数量」から導出した「取引先別・月別受注金額合計」などは、それによって、直接説明されるビジネス上の存在も、行為・出来事も無いので、データモデルの中に居場所がありません。
 本来は居場所の無いデータを、無理に描き込んだデータモデルを良く見ます。 データベースのDDL定義をデータモデル作成ツールからジェネレートする都合で、分かって書いているなら良いのですが、知らないで分析しようとすると、結果的に無関係なビジネス要素の説明として付け加えたり、架空のビジネス要素を作ったりとモデルを混乱させる原因になり増す。
 但し、データモデルの中には書かないと言う事は、管理しなくて良いと言う事ではありません。
 データディクショナリとかリポジトリなどのデータ項目管理機能を使って、一元管理する対象である事には変わりありません。
 また、データベースと同様にテーブルとして実装するので、データを管理する単位も必要となります。


 入力データは、そこに含まれる導出項目も併せて、事実の記録でありそれが対象とするビジネス上の存在も明らかなので、当然データ分析の対象となります。
 なお、入力データの中で、導出データ以外のものについては特定を容易にするために「発生データ」と名前を付けておきます。
2.導出データの分類
 さて、導出データは更に二種類に分類されます。
導出項目の種類 特徴と性質
・帰属データ ・帰属するビジネスの構成要素が存在する
・非帰属データ ・ビジネスの構成要素に帰属しない
 帰属データは、売上金額が売上に帰属するように、何れかのビジネス構成要素に帰属(帰属とは、そのビジネス要素の説明をしていることを示す表現です)が明らかなものです。
 非帰属データは、ビジネスの構成要素に帰属しないもので、一旦、ビジネスシステムに記録された複数のデータを様々な切り口で加工して作られるデータ群です。

 これらのデータを、目的に応じた視点からの見方と言う意味で「View」とか「Viewデータ」と呼びますが、複数の記録に亘るデータを扱うので、作られたデータを元の記録と同じ単位で扱うことが出来なくなります。

3.Viewデータの分類
  Viewデータにも、上図で説明されているデータの様に、記録されたデータを過去の一定期間ごとに集計するデータと、新しい事実が記録される都度、現在の値を計算するための中間値データとして記録しておくものがあります。


 前者は、既に確定した過去の記録を集計するので、入力データと同様に更新の発生する余地はありません。
 これに対して後者のViewデータは、本来の導出ルールがΣ売上−Σ入金などで、次に売上や入金があれば、値を更新する必要があります。 このケースで最も一般的なデータは在庫関係のデータです。
 これらのデータは一般的に、関係する要素が変化する都度、再計算しないとビジネスの実態と値は違って来るので、結果的に頻繁な更新を誘発するので不安定です。
4.まとめ
 以上を整理するとデータは下表の様に分類されます。
データの類型 特徴
・入力データ ・発生データ ・ビジネスの記録で、値は安定しビジネス要素への帰属が明確
・導出データ ・帰属データ
・非入力データ
・非帰属データ
(Viewデータ)
・中間データ ・データの追加で更新が発生、値は現時点の中間値で不安定
・集計データ ・記録の集計値で安定
 本節最初の表の、Factデータ以外の部分について、その関係と特徴を整理して来ました。
 Factデータの概念は、はっきりしませんが、呼ばれている状況からすると、ビジネスの構成要素への帰属が決められるデータ群を指していると思われるので、Fact/Viewの分類とは、帰属/非帰属の分割と重複すると考えられます。
 以上分類したデータを、データモデルの目的に応じて、データ分析の対象として取捨選択します。
 例えば、ビジネスの構成要素を解析してBPRを検討するときに、Viewデータが混入していては、ビジネスのモデルとしては不適切ですし、データベースの設計をしようと言うケースでは、Viewデータも、月別・顧客別・商品別などの単位別に整理されている必要がある(データモデルに組み込むと言う意味では無いので要注意)などの使い分けです。
 詳細は、データモデルの書き方を説明するコラムで説明させてもらいますが、ここでは、実はデータは多様で、その全てを同じに扱うことは出来ないことをご理解頂ければと思います。
 ところで、ここではビジネスデータの分類を検討していましたが、データはビジネスデータ以外にも存在します。
 このコラムの最後に業務データと管理データの類別について述べたいと思います。


 概念データモデルは、ビジネスをデータ構造で表現するものです。
 と、言う事は、ビジネスに関係の無いデータ項目を書き加えることは、意味が無いばかりか、ビジネスのデータ構造を把握するには邪魔になります。
 確かに、データベースとして実装されたところでは、「登録日」や「登録時間」、「登録プログラム」や「登録端末番号」など運用管理を円滑に行うためのデータ項目が存在します。
 運用管理データは、もちろんビジネスの実態の中には登場しないので、これを業務の概念モデルに持ち込む必要はありません。(データベースの管理モデルとして別に概念モデルを描くことは有益な対応です)
 と言う訳で、前節で仕分けしたビジネスデータとは別に、管理データについても、業務のデータ分析対象としないように注意する必要があります。
データの種類 特徴
・業務データ ・ビジネスの記録とその加工データ
・運用管理データ ・データベースの管理や運用管理に使用するデータ


 データを分類してみましたが、実は分類の視点も幾つかあります。
 ここで説明したデータ項目の分類の中で、ビジネスをモデルで現すデータモデルとして分析対象となるのは、Factデータのみです。
 他のデータ項目は、業務の構成要素に対応する(そのデータ項目が属する)ものがないので、データ分析のやりようがないのです。
 と言うことで、データモデルを作るには先ず、データを整理し、データ分析の対象となる業務データを整理する必要があります。
 また、他のデータ項目は、データモデルに表現する場所が無いと言うだけで、管理しなくて良い訳ではありません。
 どのデータ項目からどのデータ項目を計算するのかなどの関連性と言う意味での整合性の整理はデータモデル外のデータ項目も対象にしなくては、一元管理とはいえません。
 その方法やリポジトリの利用については、別の回で説明したいと思います。 

ページトップへ