● 提示されたテーマは ...
以下の問題を材料にして、Ｔ字形ＥＲ図の読みかたを、佐藤正美が実演する。
テクニカル・エンジニア（データベース）の試験問題 [ 平成16年度、午後２ 問題１ ]
前回は、「event」 の読みかたを実演した。今回は、「resource」の読みかたを実演する。
なお、今回、前半 （19:00〜20:00） は、「余談」として、IRDS について述べて、後半 （20:00〜21:00） に、ＥＲ図の読みかたを実演した。
● IRDS、オントロジー （ontology） とは ...
来る ５月20日、DOA＋コンソーシアムでは、「ISO/IRDS と MOF」を協議する。
「ISO/IRDS と MOF」 の協議を理解しやすいように、前提知識として習得していなければならない「IRDS の歴史」について述べた。
（１） IRDS は、Information Resource Dictionary System の略称である。
すなわち、「情報資源を管理する Data Dictionary の構造」をいう。
（２） 1980年代、ＲＤＢ （Relational Data Base） が使われるようになった。
ＲＤＢには、ＤＢを一元管理するために、ＤＤ（Data Dictionary）が搭載されている。
ＤＤ には、以下の情報が定義される。
- データ構造
- アプリケーション構成
- authorization
- NODE
（３） ＤＤ の定義と ＤＢ の実態が乖離しないことを 「active」 という。
つまり、ＤＤ が ＤＢ を動的にコントロールしている状態をいう。
ＤＤ を、データ構造に対して 「active」 にすることは実現できる。
しかし、プログラムに対して 「active」 にすることは、むずかしい。
（４） 複数のベンダーの様々な ＲＤＢ が使われ、ＤＤ の仕様も、様々であった。
そのために、ＤＤ を、統一的に管理する ＤＤ がいる、という事態になった。
ANSI が、1988年、統一ＤＤ の仕様を提示した。それを、通常、ANS/IRDS と云う。
（５） 1980年代、いっぽうで、CASE ツールが使われるようになった。
CASE は、Computer-Aided Software Engineering の略称である。
CASE ツールは、SDLC （分析・設計・製造・保守） の自動化を目的にしていた。
CASE ツールのほとんどすべては、それぞれの工程ごとの自動化ツールであった。
- SDLS のすべてを自動化するツールを I-CASE と云う。
- SDLC のそれぞれの工程ごとの自動化ツールを C-CASE という。
[ 略語： I-CASE とは Integrated-CASE、C-CASE とは Component-CASE 。]
（６） 1989年、IBM 社は、それぞれの工程の C-CASE を接続する構想を公表した。
C-CASE を接続して--SDLC を自動化して--、ＤＢ２用ＤＤを作る構造であった。
C-CASE 群を接続するツールを Reposiory/Manager という。
（７） ＤＤ とリポジトリ （Repository） という ２つの用語が使われるようになった。
前述した歴史から判断できるように、ＤＤ とリポジトリには、以下の違いがある。
- ＤＤ は、character-based である （diagramming ツールを対象にしていない）。
- リポジトリは、diagramming の定義を収録している。
（８） ANS/IRDS は、ISO/IRDS の基礎にはならなかった--いくつかの国が反対した。
ISO/IRDS は、ANS/IRDS と違う構造になっている。
（９） いっぽう、UML の仕様を基礎にして、MOF が公表された。
MOF は、Meta Object Facility の略称である。
（10） 「意味の共有」を実現するために、概念記述として、以下のような取り組みがある。
- RDF （Resource Descriptive Framework）
- OWL （Web Ontology Language）
- ODL （Ontology Definition language）
（11） Ontology は、以下の意味である。
- 哲学、論理学では、「存在論、形而上学」 のことをいう。
- 一般には、「概念分類体系」の意味として使われている。
（12） 哲学・論理学では、「存在」とか「意味」に関して、以下の ２つの考えかたがある。
- 関係主義、内包・外延の論理学
- 実体主義、様相の論理学
フレーゲ氏は、内包 （性質） を記述して、外延 （集合） を考える体系を整えた。
そして、内包・外延の論理学および 「関係主義」 が、多数派となった。
クリプキ氏が、「様相」を前提にして、「実体論 （形而上学）」 を再評価した。
（13） ＴＭ と ＴＭ’は、いま、クリプキ氏の哲学を尺度にして、認知番号を検討している。
以上が、前半の「余談」であった。
後半は、前回のＥＲ図を対象にして、「resource」 の読みかたを実演した。
● 「Resource」 を読む （個々の 「resource」 の性質を確認する） ...
「Resource」 の読みかたには、以下の ２つのステップ （手順） がある。
（１） 個々の 「resource」 の性質を検証する。
（２） 「Resource」 のあいだに成立する関係を検証する。
個々の 「resource」 を検証する際、ＥＲ図の全体を観て、まず、以下の２点を調べる。
（１） 「Resource」 の数と 「event」 の数を比較する。
（２） 「Resource」 の右側 （性質） の数を調べる。
（１） に関しては、「resource」 の数が、「event」 の数に比べて、多いほうが良い （事業過程の再編成に対して役立つ） ことを、すでに、いくども言及してきたので、割愛する。
（２） に関しては、以下の２点を確認する。
- ５つ以上あるかどうか。
- 空白かどうか （性質が １つも記述されていない状態か）。
「５つ以上あるかどうか」 を確認する理由は、「resource」 の基本的な性質として、「名称、長さ、重さ、容積、色」などが列挙でき、（長さは サイズ・コードを付与されることが多いし、色は カラー・コードを付与されることが多いので、それぞれ、単独の entity として認知されるので、） 数は多くないのが、ふつうである。したがって、「resource」 の性質が、５つ以上、記述されている状態というのは、ＶＥ として扱う性質が混入していることが多いので注意されたい。たとえば、「顧客」 「支店」 や 「派遣スタッフ」 に関して、以下の項目は、ＶＥとしたほうが良い。
- 電話番号
- FAX 番号
- 電子メール・アドレス
「空白 （性質が １つも記述されていない）」 状態というのは、認知番号が、複合語的キー （compound-key）--たとえば、マスター・キーなど--の一部として使われていて、いままで、単独の 「resource」 として認知されてこなかったことを示している。そのような状態なら、「名称」は、プログラムのなかで、記述されていることが多いので、注意されたい。
以上を確認したら、（今回は、試験問題なので、対応できないが、実地のデータ設計では、） システムを作り直す「目的」を考慮して、それぞれの 「resource」 に対して、新たに管理すべき （管理したほうが良い） データ項目はないのか--新たに追加するデータ項目はないのか--、という点を、ユーザと協議する。
● 「Resource」 を読む （「resource」 のあいだに成立する関係を確認する） ...
個々の 「resource」 の性質を確認したら、次に、「resource」 のあいだに成立する関係を検証する。そのためには、「リレーションシップの検証表」 を使う。
「リレーションシップの検証表」 は、実地では、「情報 （画面、帳票など）」 ごとに作成するが、今回は （試験問題なので、） １つの検証表を作成する。（参考）