2004年10月16日 作成 データ・ディクショナリ と リポジトリ >> 目次 (テーマ ごと)
2008年11月16日 補遺  


 
 データ・ディクショナリ (Data Dictionary) と リポジトリ (repository)は、専門用語として、ちがう概念である。
 ただ、同じように使うことが多い。

 データ・ディクショナリ は、DD/DS という考えかたとして提示された。DD/DS とは、Data Dictionary/ Directory System の略語である。ディレクトリ (directory) は、DBMS (Data Base Management System) の 1つの管理 ツール として、ディスク のなかに記憶されている ファイル の管理情報 (ファイル 名称や、そのほかの物理的定義情報) を収録している。ディレクトリ は、ファイル・キャビネット (a filing cabinet) の 「抽き出し (a drawer)」 のなかにある フォルダ (a folder) として考えてもよい。1つの フォルダ には、複数の物理的 ファイル が収録されている。すなわち、ディレクトリ には、[ machine-readable な ] データストア (data store) 情報が収められている。

 いっぽう、ディクショナリ は、IRM (Information Resource Management) の観点から提示された。
 [ machine-readable な ] 物理的情報を作る前に、データ の構造を、まず、設計する。データ 設計には、以下の 3つの段階がある [ 280 ページ を参照されたい ]。
 (1) 概念設計
 (2) 論理設計
 (3) 物理設計

 それらの設計情報を収めて、(情報を収録する) データベース と、(情報を使う) 事業の 「橋渡し (接点)」 として作用する ツール が、ディクショナリ である。言い換えれば、ディクショナリ は、「データベース のなかに収録される情報」 に関する記述を収めていて、データベース を 「一元管理」 する ツール である。
 言い換えれば、ディレクトリ のなかに収められている データ は、データベース のなかに ロード された実 データ に対する 「メタ・データ」 であり、ディクショナリ のなかに収められる データ は、(ディレクトリ の 「メタ・データ」 を定義する) 「メタ・メタ・データ」 である。ディクショナリ のなかに定義される情報には、たとえば、物理設計の アウトプット であれば、以下のような情報がある。

 (1) データ 情報 (database、area、file、record、field、key、element、dataview など)
 (2) アプリケーション 情報 (system、job、step、module、program、report、panel など)
 (3) セキュリティ 情報 (person、authorization など)
 (4) 分散処理情報 (node など)

 ちなみに、データ・ディクショナリ が、DBMS に対して作用する形態 (データ・オペレーション 形態) として、「active」 という言いかた がある。「active」 とは、ディクショナリ が、DBMS を一元管理して、ディクショナリ のなかに定義されない情報は、DBMS のなかにも定義されない──逆に言えば、DBMS のなかで使う情報は、かならず、ディクショナリ のなかに定義されなければならない──ということである。その形態のことを 「dictionary-driven (ディクショナリ 駆動型)」 ともいう。

 1980年代前半、いくつかの データ・ディクショナリ が出てきた。それぞれ、特徴のある ディクショナリ であった。
 しかし、たとえば、2種類の DBMS を導入した際、2種類の DD/DS を導入することになって、本来、一元管理されるべき情報資源が、事実上、(仕様および管理手法がちがう) 2つの ディクショナリ のなかに散らばってしまい、2つの ディクショナリ のあいだでは、データ の移植性・互換性が確約されていなかった。
 「情報資源管理用 ツール の情報資源を管理する ツール」 を考えなければならない、という事態に陥ってしまった。

 そういう事態を避けるために、ANSI (American National Standards Institute) が、「標準的な」 ディクショナリ 仕様を、IRDS (Information Resource Dictionary System) として、1988年に公表した。ANS/IRDS」と略称されることが多い。

 DD/DS および IRM の観点から、ディクショナリ が論点になっていた頃、リポジトリ という用語は、ディクショナリ の性質を定義するための一般名詞にすぎなかった。たとえば、「Data Dictionary is a repository...」。

 いっぽう、1980年代後半、CASE (Computer-Aided Software Engineering) ツール が出てきた。
 CASE は、以下の 2点を狙いとしていた。

 (1) 構造化手法の自動化
 (2) SDLC の自動化

 つまり、SDLC のそれぞれの工程 (分析工程・設計工程・製造工程・保守工程) のなかで使われている手法 (構造化手法) を自動化して、SDLC の全工程を自動化することを狙いとしていた。
 しかし、構造化手法を自動化しても、それぞれの工程を結ぶことができなかった。(参考)

 SDLC の全工程を自動化した CASE ツール を 「I-CASE (Integrated CASE)」 といい──たとえば、テキサスインスツールメンツ 社 の IEF (Information Engineering Facilities) は、I-CASE であった──、1つ以上の構造化手法を自動化したけれど、全工程を自動化しない CASE ツール を「C-CASE (Component CASE)」 という──たとえば、DFD の自動化 ツール とか、ER 手法の自動化 ツール とか、プログラム・ジェネレータ とか。

 C-CASE を接続するために、IBM 社が、AD/Cycle (Application Development Cycle) のなかで、「リポジトリ」 を使う (作る) 構想を、1989年に公表した。IBM 社の 「リポジトリ」 は、AD/Cycle のなかで使われる C-CASE を接続して、かつ、DB2 の ディクショナリ として使うことを目的としていた。
 すなわち、リポジトリ は、(DB2 に対する ディクショナリ であると同時に、) C-CASE を接続する役割を担う。言い換えれば、リポジトリ は、C-CASE が使っている ダイアグラム 法をも対象にしている。

 ディクショナリ が出た頃には、CASE は出ていなかった。したがって、ディクショナリ は、ダイアグラム の生成を考慮していなかった。いっぽう、リポジトリ は、C-CASE を接続するために出てきたので、ダイアグラム の生成を考慮している。すなわち、CASE ツール が、ダイアグラム のなかで オブジェクト を生成しても、その オブジェクト に対応する定義を、自動的に、ディクショナリ のなかに生成することができなければ、「ディクショナリ 型」 の ツール である。あるいは、ディクショナリ のなかに、直接、情報を入力して、その情報に対応する ダイアグラム を生成できなければ、「ディクショナリ 型」 ツール である。

 したがって、単純に言い切ってしまえば、リポジトリ は、データベース に対する ディクショナリ としての役割のほかに、ダイアグラム に対する配慮を加味した、と理解してよい。

 
(参考)
 「構造化手法の自動化」 と 「全工程の自動化」 は、二律背反の関係にある。
 全工程を自動化した IEF は、DFD を使わないで、「サブジェクト・エリア (subject area)」 という概念を導入した。
 なお、「構造化手法の自動化」 と 「全工程の自動化」 の二律背反については、拙著 「リポジトリ 入門解説」 (SRC 刊) を参照されたい。



[ 補遺 ] (2008年11月16日)

 Data Dictionary と Repository は、かつて (1990年代はじめ頃まで)、私の専門技術の ひとつでした。いま、私は、その領域を研究していません。3年前 (2005年) に、ISO/IRDS の説明を聴いて以来、私は、この領域を学習していません──私の興味が他のほう (モデル) に移ったので。モデルは、以下のように、語彙と文法を前提にして構成されます。

 (1) 語彙
  (1)-1 論理学の語彙 (たとえば、AND、OR、IF、クラス概念など)
  (1)-2 観察述語 (事業のなかで使われている語彙)
 (2) 文法 (たとえば、PM の公理系など)

 ISO/IRDS は、(1)-2 を 「Ontology (Reference Ontology)」 として考えて Backus-Naur Form (BNF) を使って記述して 、(2) を 「abstract syntax」 として考えています。そして、それらを前提にして、MMF (Meta Model Facility) が メタ・モデル を生成します。したがって、ISO/IRDS は、モデル の観点から判断して、きわめて、「妥当な」 構造となっています。ただ、個人的に言えば、私は、語彙を記述する際、BNF を使うことに対して抵抗を覚えます──その理由を ここで綴れば長くなるので割愛して、拙著 「論理 データベース 論考」 173 ページ を参照してください。

 さて、IBM/Repository も ISO/IRDS も 「概念」 「技術」 (concepts and skills) の観点から判断して りっぱな ツール だと思うのですが、IBM/Repository が公表された当時に、「Semantically powerful, but difficult to use」 という評が出たように、それらの ツール は専門的技術を満載したがために、逆に使い難くなったのではないでしょうか。
 モデル の評価は、以下の 3点を調和して判断されるべきだと私は思っています。

 (1) 「ききめ」 がある (有効性)
 (2) 使いやすい (単純性)
 (3) 妥当な構成である (理論的整合性)

 ひとつの学問領域が分割・細分されて、細分化された領域では、それぞれ、専門的な観点で 厳正な定義・概念・技術を使わなければならないので、どうしても、専門家どうしのあいだで通用する厳正さを守らなければならないのですが、「モデル」 の考えかたが一般に疎通していない所に──ここで言う 「一般に疎通していない」 という意味は、コンピュータ 産業の或る領域 (ユーザ 企業の システム 化を仕事にしている 「分析・設計」 段階) において 「一般に疎通していない」 ということですが──、はたして、ISO/IRDS の概念・技術を理解できるのか は疑問だと私は感じています。ANS/IRDS の──IBM/Repository や ISO/IRDS に較べて──「単純な」 構成すら、当時、理解されなかったというのが事実です。さらに、DD や リポジトリ の構造を論ずる前に、マーケット では、それらの ツール に対して ほとんど興味を抱いていないというのが事実でしょうね。

 私は、専門家たちが専門語を駆使して夢中で説明しはじめたら、その場から 「逃げる」 ことにしています。私は、つねに、ユーザ の代表でありたい。たぶん、モデル を学習してきた私が理解できなことは、ユーザ も理解できないでしょうね。学問を真摯に追究している専門家たちに私は敬意を払っていますが、ただし、「専門家であることを セールス 点にする」 輩に対して私は拒絶反応を起こします──たとえば、或る事象が起こったときに、テレビ に出演して、じぶんの専門的知識があれば [ 勿論、その事象は、その専門領域の対象として判断されるのですが ]、事象を説明できると思いこんでいる タレント 学者とか。そういう輩に対して、皮肉を ひとつ、

  Our American professors like their literature clear, cold, pure and very dead.
  (Sinclair Lewis)

 専門というのは、専門という限りにおいて、ひとつの視点にすぎないのであって、事象は、ひとつの視点を超えた豊富な事態であるという当然のことを外さなければ宜しい。DD あるいは リポジトリ は、それらの ツール そのものに存在理由がないのであって、あくまで、システム を作るときの管理 ツール であるということを外さないようにしたいですね。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識