» 【118号】i−DBMSはいかが

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【118号】i−DBMSはいかが

さきに114号で「リレーショナルモデルの問題点」として、次の4つ
 ①実装独立の概念モデルでない
 ②加工・加工元データの整合性について言及がない
 ③DBのスコープの設定について言及がない
 ④DB設計の素材について言及がない
を挙げましたが、対策については特に述べませんでした。そこで今回は①、②
の対策として、i-DBMS(インテリジェントDBMS)を提案してみます。

■強力すぎるプログラムの機能\nDBのないシステム開発など、ほとんど
見かけなくなった今日、正しいDBさえ設計できれば、「後は任せてください」と
いった開発者が多いと思われます。
データの世界とプログラムの世界をSQLで繋ぎ、プログラムの世界は「お任
せください」というわけです。リレーショナルモデルに問題があろうが、RD
BMSパッケージは商品として確立し、これを活用したアプリケーションが立
派に役割を果たしており、またこれ以外の選択肢は当面考えられない状況では
尤もなことかと思われます。
この場合、しかし作られるプログラムは10人いれば10通りのプログラムが
できてくるのではないでしょうか。各人が創造性を発揮できる、ある意味で人
間的な楽しい仕事ともいえますが、属人的職人の仕事になり、運用・保守に大
きな問題を残すおそれが少なくありません。これはプログラムの機能が強力で
「何でもできちゃう」からであり、保守性を高めるために属人性を制限すると、
必然的にプログラム型にはめ、機能を制限することになります。したがって、
必要十分なガバナンスを持たせるための「はめるべき型」はどうあるべきか、
が問題になります。
■i−DBMSのアーキテクチャ
以下に述べるi―DBMSも、この型にはめるためのひとつの、おそらく非常
に強力な、考え方かと思われます。カラムとタプルから成る物理的リレーショ
ンを意識するSQLにとらわれていて分かりづらい方は、一旦今のRDBMS
を忘れていただく方が良いかと思われます。
アーキテクチャとしては、下記のように、DBMS(RDBMSに限らなくて
も良い)の外に仮想的なi−DBMSがあるとし、アプリケーションプログラ
ム(AP)は、これとインターフェースを持つものと考えます。
            リポジトリ
              |
  ユーザ←→AP←→i−DBMS←→DBMS←→物理DB
物理DBは、在庫データや月次売上金額、各種エンジニアリング(加工)デー
タなど、現行DBMSが未達のDI(Derivation Integrity、注1)を要する
データを含んでいるものとしますが、一方APの中で扱われる中間加工データ
やチェックデータ(注2)などは、含まないものとします。i−DBMSはリ
ポジトリを脇に抱えていますので、APに対しては概念DBがあるかのように
振舞います。したがって、そのデータが物理DBにあるか否かに関係なく、ユー
ザから見えるデータは定義され、DIを含め、すべての整合性が保証されるも
のとします。
(注1)
加工元データが変化した時、加工データにこれを反映する整合性。たとえば1
0個出荷したら、在庫が10個減るはずですが、今はこの整合性保証がAPに
任されています。リポジトリに記述された出庫数(加工元)と在庫数(加工)
との関係から、i−DBMSはこれをメンテしますので、APとしては「10
個出荷した」とさえ通達すれば在庫は自動的にメンテされます。DRI通信3
3号参照。
(注2)
在庫ステイタス(1:自動発注要/2:手配要/3:十分あり)などのデータ
は、通常物理DBにはスペースを用意されず、AP内に一瞬登場するデータか
と思われます。しかしi−DBMSの見せる概念DB上には立派なデータ項目
として登録されます。リポジトリに登録された在庫ステイタスの仕様(在庫数
や安全在庫数からの加工仕様)に基づいてi−DBMSは、必要な自動発注や
メッセージ出力を行います。
■i−DBMS下のAPの機能
このように、加工データや整合性保証の問題がすべてi−DBMSに任される
と、APの役割は、残るユーザとの折衝および画面・帳票における物理的配置
になるかと思われます。ユーザとの折衝は、折衝のパターン化によって、ほと
んど汎用的スーパバイザーに任せることができると考えられます。物理的配置
も一覧表、ヘッダー・デテイルなどのパターン化により汎用化できるものが多
いと思われます。このようなi−DBMSによるAPの定型化により、プログ
ラミングレスへの道が見えてくるのではないでしょうか。
ここまではi−DBMSは、AP機能の定型化ための仮想的な存在として考え
てきましたが、既存のRDBMSを活用することによって、その実現もさほど
難しいものではないと思われます。鍵はおそらくリポジトリの設計、および高
品質のリポジトリコンテンツをいかに作り維持するかであると考えます。これ
は従来のプログラミングと保守に代わるもので、新しい教育投資を行うための
意思決定がひとつの鍵になるように思われます。
■変革マネジメント
i−DBMSは概念データモデルを前提に、DIを保証しますので、物理DB
での発想を脱却し、また加工データの導出過程をモデル図上でトレースする習
慣を身に付ける必要があります。結果的には、従来、プログラム設計工程で行っ
ていた作業を、データモデリング工程で行うことになります。これは設計合理
化の原則「上流でできることは上流でやる」に則っているといえます。
加工・加工元関係は、サブタイプ対応に異なることが多く、したがって加工デー
タをトレースすることによって、ザブタイプが洗い出され、データモデルの品
質が向上するケースを多く経験します。これは開発工程での手戻りを激減させ、
またシステムテストの時間・工数を激減させるものと思われます。
保守は従来、プログラムに人が張り付いて、行っていたわけですが、今度はリ
ポジトリコンテンツの保守ということになります。保守対象が(メタ)データ
になり、属人化が減り守備範囲が拡大し、新規ニーズへの対応が迅速化される
と期待されますが、逆に「俺でなければ」という責任感が希薄になる心配はあ
りますので、データオウナーをしっかりと決めた新しい管理体制が必要になる
と思われます。
このような変革は、従来のプログラミング技術習得のための投資を一部捨てる
ことになり、短期的ROIを悪化させることになりますが、中長期的には正解
に違いないとわれわれは考えています。i−DBMSへの変革、いかがでしょ
うか。