» 【136号】4種類のDB

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【136号】4種類のDB

■DBの分類
DB、といっても概念DBですが、これをどう分類するか、観点により、
人によりいろいろな考え方がありうると思われますが、私は次の4種類
・リソースDB ・イベント系DB
・DWH系DB ・メタ系DB(リポジトリ系DB)
に大分類したいと考えます。

欧米の文献なども見ていますが、この4分類を提案しているものは見か
けません。私だけが、言っているのかもしれませんが、以下のような意味
のあるものと考えます。
■リソースDB
リソースDBとは、通常マスターDBと呼ばれるものです。私は日頃から「社
員、顧客、商品が3大リソースだ」といっています。ビジネスの種類によらず、
この3つはビジネス遂行上不可欠なものだと考えるからです。リソースDBに
はこのほか、これらを分類する部署、事業部、地域、倉庫、商品分類などが含
まれます。また顧客に並んでサプライヤー、協力会社、そして商品に並んで原
材料、包材、さらに勘定科目、通貨、支払条件、取引区分などもリソースに含
まれます。われわれは、性別、年/年月/年月日などもリソースの1種と考え
ます。
これらは変更が少なく安定したインフラDBを形成します。業務横断の経営資
源という意味でリソースというわけですが、業務ごとに業務DBの中に作って
いる会社が非常に多くあります。これはリソースDBの意義を理解せず、「営
業システムを作りましょう」「生産システムを作りましょう」という業務DB
の開発のタイミングに、これに付随して開発してきたためと思われます。「わ
が社のリソースはこれこれ」と条件をつけないで、SIerに丸投げするとこ
うなるのは必然かと思われます。これによって無駄が発生したこともあります
が、不整合が発生し以後のトラブルの原因を作り、また保守を難しくした罪の
方が大きいといえます。
受注や生産などのイベントにおいて、社員や顧客はWhoやWhom、商品は
Whatを表すための用語として使われるので、リソースDBはいわばシステ
ムにおける広辞苑の役割を演ずるわけですが、業務別にこれを作ると鹿児島弁、
青森弁ができ話が通じなくなるわけです。このような状態のまま、ERP導入を
企画しても、投入できるリソースデータがないので、まずこれを整備すること
から始めなければなりません。
逆に全社共通のリソースDBが整備されている場合は、ERP導入の際これを
投入すれば、即イベント入力の画面を動かすことができます。このためビジネ
スの先頭から入力データを作り、順次テストしながら、カスタマイズを検討す
ることができます。実際、弊社の顧客の中に、このようなアプローチをTOA
(Test Oriented Approach)と称して、ERP導入をスムーズに進められた会
社があります。
原則としてアプリケーション・パッケージにはリソースデータはついてきませ
ん。全社で使える高品質のリソースデータは、いろいろな見方をする各アプリ
ケーションのニーズを調整・標準化して作られますから、簡単ではありません。
しかし、システム開発とはプログラムを作ることと考えて、パッケージ導入に
よって問題がほとんど解決すると勘違いしている人が多々あります。
■イベント系DB
イベント系DBとは、営業、購買、生産、経理、人事、商品開発などイベント
データ(トランザクションと呼ばれることも多い)をストアするDBです。イ
ベントとは出来事の記録ということになりますので、5W1H、すなわちWh
o、What、When、Where、Why、Howなどをあらわすための
リソースデータが含まれます。これらはコード/番号で表現され、上述の全社
一元化されたリソースDBを参照することによってその詳細仕様が分かる形式、
たとえば
 顧客番号→顧客名、住所、電話番号、・・
 品番→品名、単価、・・
が理想的といえます。
すなわち、ひとつのリソースがn個のイベントに登場する
リソースDB:イベント系DB=1:n
です。しかしレガシーやパッケージは、その中に相互に矛盾したリソースデー
タを内蔵していることが多々あります。この場合は、DB間でデータをやりと
りするために、リソースデータの変換が必要になります。
なお営業、購買、生産、経理などはバリューチェーン系、人事、商品開発など
はリソース整備系として、二つに分類することがあります。前者はリソースを
活用して付加価値を生み出し利益を得るためのもの、後者はリソースの新陳代
謝を管理するものと言えます。今注目のSCMはバリューチェーン系に、また
CRMはリソース整備系に属すると考えられます。
■DWH系DB
DWH系としては従来、経営戦略のためのADW(Analytical Data
Warehouse)やこれから生成されるデータマートが考えられてきましたが、も
う少し戦術よりのLOB(Line of Business)のためのEDW(Enterprise
Data Warehouse)を含めて考えるべきと思っています。
EDWは各イベントDBで発生し、かつ他のイベントシステムでも参照するイ
ベントデータをストアするDBです。すなわちアプリ間でやり取りされるイベ
ントデータ(当該イベントDB内でしか使われないものをロウレベルメッセー
ジと呼ぶため、これをハイレベルメッセージと呼ぶこともある)だけから成る、
アプリ間通信場で、原則として発生したハイレベルメッセージは、トランザク
ションログのように、ここに送り込まれ、各アプリケーションは必要に応じて
ここに読みに行く、プル型のコミュニケーションを実現するDBです。これに
よって、もはやアプリケーション同士が直接Peer to Peerでメッセージをやり
取りすることはありません。
EDWの設計に当たっては、ハイレベルメッセージを集めて、これを素材にD
B設計を行います。これがきちんとできればアプリ間インターフェースが確定
しますから、これを守って設計している限り、個別アプリの設計/改造が他ア
プリに影響を及ぼすことはありません。アプリケーション独立が保障されます
ので、保守合理化が期待できますし、アプリケーションパッケージ導入の検討
がやさしくなると思われます。EDWの役割は、このようにアプリケーション
独立を実現するわけですが、物を扱うビジネスにおいては、SCMなど大局的
な原材料や製品の需給を可視化するものと思われます。
なおEDWのコンテンツそのものは、各アプリDBに存在しますので、実装に
当たっては、EDWは適宜仮想化することができると思われます。その意味で
はEDWの真の実体は、そのメタデータリポジトリのコンテンツにあるという
こともできます。
EDWに含まれるイベントデータの寿命はかなり短いものであって、その役割
を終えたら、ADWに移されたり捨てられたりすることになります。たとえば、
出荷イベントであれば、顧客が検収し請求イベントが発生したら、EDWに存
在する必要がありません。一般には出荷実績としてADWに移されることにな
ると考えます。このためEDWのイベントデータに関してはステイタス管理が
重要になると考えます。
■メタ系DB
以上のような、リソースDB、イベント系DB、DWH系DBがあれば、これ
らとユーザの接点となる画面・帳票、それらを作るためのロジックや処理、こ
れらを実装するための物理DB、テーブル、プログラム、またCPU、ディス
ク、ネットワークなどが必要になります。メタ系DBはこれらの関係や仕様を
記述することになります。私はこれを次の3つ
・概念メタ:概念DB、エンティティタイプ、属性、ドメイン、概念IO、
業務プロセス、システム/サブシステム、論理組織、・・
・物理メタ:物理DB、テーブル、カラム、プログラム、・・
・ハードウエアメタ:CPU、ディスク、データセット、端末、ネットワーク、・・
に大分類しています。
このうち全体を統括すると言う意味で概念メタDBが最重要と考えますが、こ
の構造についてのコンセンサスは当分得られないかに見えます。その原因はど
のようなデータモデルによって記述すべきか、またこれを作るに当たっての素
材が決まっていないためです。われわれはシステム開発ドキュメント−THデー
タモデル図やIPFチャートなど−を素材にデータモデリングを行っています
が、現在はデータモデラーが属人的なモデルによって、素材を確定せず思い込
みでメタ部品を識別し記述している段階のように見えます。
■DBアーキテクチャ
以上DBを4種類に分けましたが、リソース、DWH系、メタ系は、全社ある
いは関連企業全体にかかわるのでインフラDBと呼ぶことができます。これら
のDBのスコープは確定です。一方、イベント系は事業と機能(販売、生産、
人事など)の組合せに対応するため、そのDBのスコープは協議して決めなけ
ればなりません。従来は予算を持つユーザ部門の長が決めていたきらいもあり、
過大や過小など必ずしも適切でなく、またM&Aなどで重複のあるケースが少
なくありませんでした。今後部分最適でなく全体最適が求められていく中で、
イベント系DBのスコープ/粒度の問題は、いま話題のSOAやSaaSとか
らんで大きな課題になっていくものと思われます。SOAは実装独立のサービ
スの中に処理を隠蔽しますので、正解のSOAのアーキテクチャ(注)はDO
Aと同じになり、ITからではなく、経営やビジネスの観点から検討すること
になると考えます。「4種のDB大分類」のアーキテクチャが何らかのお役に
立つものであれば幸いです。
(注)アプリケーションを個別にPeer to Peerで繋ぐEAIのようなSOAは、
アプリケーションがn個になると、n*nのパスが発生し行き詰る、いわば
「バンドエイドSOA」を作るので、SOAツールを使って作っても正解では
ありません。アプリ間を流通するハイレベルトランザクションを集めデータモ
デリングを行った結果得られる、ハイレベル通信場を前提としたSOAを正解
のSOAと考えます。