» 【第35号】データベース・アーキテクチャ

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

DRI通信35号「データベース・アーキテクチャ」  1999.8.1
盛夏、きりぎりすや蝉の元気な声を聞くと、暑くても何かほっとするこの頃
です。皆様、今夏はいかがお過ごしでしょうか。私はもう何年も、土日も仕
事を持ちかえってあくせくしていますが、今年は思い切って南アルプスの赤
石岳に登ろうかと計画しています。
時折,[DRI通信を楽しみにしています]とのメールをいただきます。やは
りそうなるといいかげんには書けないと、ついA4、2ページ以内の目標を
超えて長くなり勝ち、努力はしていますので、ご勘弁ねがいます。
さて今月は、私なりの「データベースアーキテクチャ」について、紹介して見
たいと思います。この用語は、私は1981年、日本システミックス時代の
「IRMニュースレター」で紹介していますが、その概念が一般に身近なもの
でないためでしょう、まだ一般化していません。しかしますます重要な概念に
なりつつあるように思われます。


■背景
かつてメインフレームのコンピュータが1台あればよかった時代は、そのニー
ズは見えなかったのでしょうが、UNIX、NT、モバイルほかデータベース
がいろいろなところにたくさん作られ、しかもデータ管理者(DA)として、
これを統一的に見なければならなくなると、これらの各種データベースの関係、
位置付けが気になります。
データベースは大部分開発の単位ごとに−−悪くいうと行き当たりばったりに
−−次々と作られてきたのでしょうが、それは一体本来あるべき姿になってい
るのでしょうか。そもそも本来あるべき姿とは何だろう。私がこの問題に取り
組み初めたのは、エンジニアリング会社のプロジェクトにおける購買管理の
データをどう位置付けるべきかを検討した30年も前になりますが、未だに進
みは微々たるもののようです。
開発者はとにかく動かすことが第一として、あまり関心を持ちません。そこで
これはやはり運用、とくに全社のデータ環境に責任を持つDAの立場から考え
ることになります。IRMニュースレターでは、その評価基準として
・運用にむだがなく人手がかからない
・運用に必要なコンピュータ資源が少ない
・トラブルが少なく、しかも局所化され、迅速に回復できる
・容易に高い整合性が保証できる
を挙げ、さらにこれらを達成するために、次の5個のサブシステムの独立性
・処理サイト独立性(他サイトの障害の影響を受けない)
・データベース独立性(他データベースの障害の影響を受けず、また個別
に更新、再編成、引退できる)
・ユーザ独立性(他ユーザのジョブのトラブルの影響を受けない)
・DBA独立性(他DBAと独立に作業できる)
・プログラム独立性(他プログラムの変更の影響を受けない)
が必要であるとしています。
20年前としてはまずまず、ただし開発時の、再利用の便などを補ったほう
が良いかと思われます。
■データベースとは
さてここでまずデータベースとは何かを考えて見ます。かつてはIMS、
ADABAS、DB2を用いて作られるファイル群をデータベースと呼んでい
たかと思います。今ではACCESSや桐の内容もデータベースと呼ぶでしょ
う。EXCELはいかがですか。ESSBASEやBOはどう考えますか。
レガシーのVSAMファイルはどうですか。さらに昔の手書きの顧客台帳はど
う位置付けますか。
かつては入れ物の物理構造や検索手段に関心が強かったわけですが、その技術
が解決されてくると、次第に関心が内容にシフトし、実務の実態を表現するデ
ータの集まりをすべてデータベースと呼ぶことにさほど抵抗がなくなっている
と思われます。そこで手書き顧客台帳もマニュアル・データベース
として扱う「広義のデータベース」を前提として以下話しを進めます。
■情報処理作業モデル
企業におけるホワイトカラーは、分業して基本的に情報処理作業を行っている
と考えられますが、そのときのデータベースとの関係を考えてみます。
まず受注情報をベースに出荷指図をするときを考えて見ます。たとえば次のよ
うなモデルとして表現することができるでしょう。
            [品#]ー(@)、[届先#]ー(倉#)
             ↓
[受#]ー(客#、   ┌────┐ [出#]ー((客#、届先#、
届先#、品#、Q、日)→│受注処理│→ 品#、Q、日)、
            └────┘  <売@>、<¥>、倉#)
すなわち、3種類のデータ/情報のからむ
     参照データ
     ↓
入力情報→処理→出力情報
のモデルです。手作業時代なら、机の前に参照データのための資料を山積みし
て、レポート用紙に書き込んで行くイメージです。
そこで理系卒業論文作成、工事資材の発注、工事引合いに対する提案書作成、
をこのモデルにあてはめてみましょう。
処理    入力情報  参照データ        出力情報
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
卒業論文  論文テーマ 既往の論文        当該論文
            物性定数など
            工業規格など
      
資材発注  資材要求書 資材発注実績データ    当該発注書
            ベンダーデータ
            資材単価データ
            
工事提案書 引合い情報 類似工事実績データ    当該提案書
作成          資材規格、単価データなど
            サブコンデータ 
ここから次のような特徴を読み取ることができます。
・ 入力情報はひとつ前のイベントの出力であり、一般に出力情報と同じデー
タベース−−目的データベース(ODB)と呼ぶものとする−−にストア
するのが普通である。
・ 参照データは、過去の(凍結された)ODBやリソース系のデータベース
−−参照データベース(RDB)と呼ぶものとする−−で、外部市販のも
のを含め複数個ありうる。厳密なことをいうとメタデータもしばしば参照さ
れるので、これをストアするリポジトリもRDBの一つとなる。
・ 基本的にODB−−一般的にOLTPの基幹業務を支えるデータベース−−
は、日中更新される不安定なデータベースであり、RDBは日中は参照だ
けの安定したデータベースである。RDBについては本来排他制御のロック
は不要である。
・ ODBとしては引合い/見積り、販売/契約、物流、設計、生産、購買、経
理、人事、など「分野」ごとに分けることができる。これは分業のための
組織、あるいはユーザに対応するとも言える。さらに生産では工場ごと、
工事ではプロジェクトごとにユーザが異なるので、分けるのが−−嫁、姑ご
とに台所を分けるのと同様−−自然である。営業も海外と国内などと、ユー
ザが分かれていれば、ODBを「対象」ごとに分けることができる。
■データベースタイプとデータベースオカレンス
現行のDBMSは、元来データベースはいきなりテーブルから構成されるもの
として設計されており、上述の「分野」や「対象」ごとに管理するコンセプト
を持ちません。ERwinなどでは「分野」を扱えるサブジェクトエリアの機
能を持っていますが、適用のコンセプトは提供していません。
そこでわれわれは、「分野」に対しデータベースタイプ(DBt)を、「対象」
に対しデータベースオカレンス(DBo)を、たとえば次のように定義してこ
れを扱うものとしました。
  DBt   DBo
  販売    販売(国内)、販売(海外)
  設計    設計(プロジェクト1)、設計(プロジェクト2)
  生産    生産(工場A)、設計(工場B)
  人事    人事
  リソース  リソース
すなわちDBtによって、扱うエンティティやデータ項目を区分し、DBoに
よって内容を区分します。言い換えるとデータベースの構造までをDBtで表\n現し、ユーザから見えるコンテンツはDBoによって表現することになります。
したがって、たとえば今プロジェクト終了時紙で作られることの多いプロジェ
クトレコードは、それぞれ1個のDBoとして扱うことになります。
■物理データベースとの関係
上述DBt、DBoの整理は、物理実装独立の「広義のデータベース」の概念
に基づくものです。今われわれがデータ分析して得ているものはDBtの仕様
です。またDBoとしては、たとえば上述、設計(プロジェクト1)の結果は
DB2上にあっても、NT上にあっても、紙の形で製本されていても同じもの
と考えますので、この3者を区別するには、物理データベース(DBp)の概
念を導入しなければなりません。
われわれとしては、DBt→DBo→DBpの間に1対nの関係があるように
設計すべきと考えますが、レガシーシステムなどでは、リソース系や複数の
分野を取り込んだ過大なDBpが見られます。
現行のDBMSはビジネスモデルの整理から設計されたものというより、アク
セスメソッドの延長として設計されたものであり、みずから管理する
DBpしか意識していません。このためはじめは、これに慣れ親しんだ開発担
当者にとって、DBtや特にDBoを認識するメリットが感じられず違和
感を持たれるかもしれません。しかし次の理由から、DBtおよびDBoを管
理するのが、ビジネスモデルによるアウトソーシングを控えて、今後の方向と
考えますがいかがでしょうか。皆様のご意見お待ちします。
・ ユーザニーズ(DBt、DBo)と実現方式(DBp)は別の観点であるか
ら、たとえこれが今一致していても何時一致しなくなるか分からない。
・ ユーザはDBt、DBoまで見えればよい。ユーザにとってITに影響され
るDBpが見えることは余分な負担を課することになる。
・ レガシーのDBpなどを改造するとき、ユーザに見えないまま、これを行う
ことができる。