» 【第115号】DBアーキテクチャ

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

■アーキテクチャへの関心
最近ITアーキテクトという肩書きの名刺を頂くことが多い、と思っていたら
ITアーキテクトという雑誌が登場しました。ITアーキテクチャに関する関
心の高まりを物語っているのでしょう。

一通り機械化ができてみると、開発の時期や担当者が違うためか、データの仕
様が違っていて、インターフェースが取りにくい、あるいは冗長データがあっ
て二重管理されているなど、いわゆる孤島システムの弊害が目立ってきました。
メインフレーム、C/S、Web、またERPや各種アプリパッケージ、オー
プンソース、レガシーなどからなるヘテロな環境を肯定した上で、ソフト負債
を資産に変えつつ、リアルタイムBIを含む、ビジネスニーズに即応すべきと
いう難題があります。ITアーキテクトには、これが突きつけられているのだ
と思われます。
■DBアーキテクチャを考察
最近話題のEA(エンタープライズ・アーキテクチャ)としては
 BA(ビジネス・アーキテクチャ)
 DA(データ・アーキテクチャ)
 AA(アプリケーション・アーキテクチャ)
 TA(テクノロジー・アーキテクチャ)
の4階層がひろく受け入れられているようですが、AAおよびTAはSIer
の課題となりつつあり、ユーザ企業としてはBAとDAが主題であると考えら
れます。そこで孤島システム解消に最もかかわりの深い、DAの上流に位置す
るDBアーキテクチャ(注1)について、以下考察していきたいと思います。
これはまた通常アプリ単位に開発を委託されるSIerにとっては、手の出し
にくい苦手の領域でもあります。
(注1)DAの上流にDBアーキテクチャが、下流に属性をエンティティタイ
プごとに仕分けるいわゆるデータモデルが位置づけられると考えます。また
DBとして物理DB(これはAAの課題)ではなく概念DBを、したがって正
確には「概念DBタイプおよび概念DBオカレンスの体系」を考えます。
■DBとは有限の通信場
ここでDBとは何かについて整理しておきたいと思います。当初は「構造を持っ
たデータのストレージ」といった認識が先行したかと思いますが、今や「実世
界の状態の写像、そして同時にハブ、すなわちn個の処理からなるシステムの
通信場」の意味が本質的だと考えられます。n<4では個別の、いわゆるPier
to Pierの通信でも良いのですが、n>4となるとPier to Pierではn(n-1)/2の
インターフェースが発生しうるため、早晩維持コストに耐えられなくなります。
このためDBを通信場として位置づけなければなりません。
n個の処理が通信するために、n個の処理はデータに関してその意味と形式と
値を共有しなければなりません。こうしてDBとこれを共有するn個の処理は
ひとつの文化圏を作ります。このため、意味と形式はメタデータとして規定し
リポジトリ/メタデータDBに記載され、値はリソースDBに記載されること
になります。この共有されるべき意味と形式と値は、事前にどこかに用意され
ているものではありません。実世界の画面・帳票上のデータを素材に、標準化
作業によって作られるべきものです。従って「DBとは標準化成果物」、ある
いは「DB設計とはデータ標準化作業(注2)」ということができます。
(注2)ここでのDBは概念DBですから、いわゆる物理DBにおけるパーフ
ォーマンス問題は含まれません。
標準化は過小な範囲で行っても意味は少なく、また過大な範囲で行うと文化圏
の異なる大勢の関係者間の調整が必要になり、作成に時間がかかると同時に維
持管理が難しくなります。またDBは実世界の写像ですから、矛盾を嫌います。
たとえば製品を5個出荷すれば、在庫は5個減った状態にしたうえで、1件落
着としなければなりません。このため原則として出荷データと在庫データは同
じDBに含まれる必要があります。このような加工・加工元データの関係が過
小な範囲のDBを作らないためのもうひとつの制約になります(注3)。
(注3)ここでは2フェーズコミットなどの機能は使わないことを原則とします。
そこで一般に、購買システムDB、半導体生産管理システムDB、重電営業シ
ステムDB、会計システムDB、人事システムDBなど、文化圏ごとの適切な
大きさのオペレーショナルDBが設定されることになります。この第1階層の
DBを筆者はP2P(Program to Program)の通信場と呼んでいます。
■通信場の階層
このような第1階層のDBとこれをアクセスするプログラム群は、ひとつの処
理システム−プログラムより1階層上の処理の単位−を形成しますが、この処
理システム間にも、一般にn>4でしょうから第2階層の通信場が必要です。
そこには発注データ、入庫データ、生産完成データ、受注データ、請求データ
など、オペレーショナルDBのデータ(イベント/トランザクション)のうち、
システム横断で使われるデータ−これを筆者はハイレベル・メッセージ/トラ
ンザクションと呼んでいます−が抽出されてストアされます。各種アプリケー
ションシステムは必要に応じてこれを参照することになります。これを筆者は
A2A(Application to Application)の通信場と呼んでいます。この更新は
特定の裏方プログラムが行い、各アプリケーションからのアクセスは参照に限
られますので、この通信場はリアルタイムに近いが、排他制御不要の一種の
DWH機能のDBとなります(注4)。
(注4)これを筆者はNCRに倣ってEDW(Enterprise Data Warehouse)と
呼んでいます。このDBは物理的に実装する考え方と、仮想的に定義するだけ
で実装しない考え方とがあります。物理的に実装すると冗長データをストアす
ることになりますが、発生源はオペレーショナルDBの1箇所になりますから
SVOT(Single Version of Truth)を損なう心配はありません。
このDBは、企業内あるいは関連企業群内におけるアプリケーション間の通信
場ですから、ここでの標準に準拠できるシステムはアプリケーション固有の標
準を持つ必要がありません。しかし、アプリケーション固有の標準を持つパッ
ケージやレガシーシステムを使う場合は、A2A通信場の標準に変換してコミ
ュニケーションすることになります。したがってERPの場合も、その中での
コミュニケーションは保証されるとしても、ERP外部とのコミュニケーショ
ンには、このA2Aの通信場を使うのが正解と思われます。すなわちERPを
大型の1個のアプリケーションとして扱うわけです。
さらにこの外、すなわち企業/関連企業群外とのコミュニケーションにおいて
は、そこでの通信場の標準に変換するか、これがなければ当面Pier to Pierの
約束をつくりコミュニケーションすることになると思われます。
このようにDBは、ユーザの意識するひとつの文化圏の核となり、最も重要な
アーキテクチャを決定することになります。従来、システム/DBのスコープ
は、スポンサーの予算や納期によって決まることも多々あり、また概念/実装
の分離も不十分で、必要以上に早く陳腐化し、ソフトは資産でなく負債である
と評価されることも多かったかと思われます。
■変化に強いシステム
ソフトは業務モデルの写像として作られ、業務モデルは日々変化しますので、
変化は避けられませんが、変化しにくい部分と変化の激しい部分とがあります。
これを分離して部品化しておけば、変化に対応して改定すべきところを局所化
することができます。端的に言うならば「インフラDBと使い捨てプログラム
から構成する」ということになりますが、最も安定したA2Aのメタデータと
リソースデータを中心に標準化を行うことによって、大きな効果を上げること
ができると考えます。
■DBアーキテクチャがEAの根幹
先に、EAにおけるユーザ企業の主題はBAとDAとであると述べましたが、
DBとこれを共有する処理はひとつの文化圏を作りますので、BAの上流と
DAの上流は一致するものと考えます。したがってDBアーキテクチャこそが、
ユーザ企業のEAの根幹となると考えます(注5)。一方実装従属のAAおよ
びTAはITの進化により変化しますが、実装独立のBA・DAによって、相
互の影響を軽微なものに抑えることができます。
(注5)これは「全体システムは、n個の処理からなる有限のDB通信場/文
化圏から構成される」から導かれたもので、データ中心アプローチが前提となっ
ています。EAにおいて人気のZachmann Framework とはかなり様相を異にしま
すが、その関係については検討未了です。