| 2005年10月16日 作成 | データ の独自性 （data-independence） | >> 目次 （作成日順） |
| 2009年11月16日 補遺 | ||
|
（1） データベース の物理的な構造 それらの区域 （定義域） を 「層」 として考えたならば、以下のような 3つの 「層」 として考えることができるでしょう。
（1） 内部層 （internal layer） 内部層は、物理的な データ 構造 （格納方式） や アクセス・メソッド を扱い、概念層は、「論理的な」 データ 構造 や 演算法を扱い、外部層は、それぞれの アプリケーション が対象とする データ 構造 や 操作法 （たとえば、伝票とか 表などの形式を操作すること） が扱われます。したがって、それらの 3つの 「層」 では、データ 構造は、それぞれ、違う構造になっています。それぞれの 「層」 のなかで扱われる データ 構造のことを 「スキーマ （schema）」 といい、それぞれ、内部 スキーマ ・ 概念 スキーマ ・ 外部 スキーマ といいます。この 3つの 「層」 の考えかたは、ANSI が提示して、データベース・システム を考える際、「標準的な」 構造となっています。 データベース 設計の領域では、「概念・論理・物理」 という言いかたをすることが多いのですが、それらの用語法を使えば、内部 スキーマ は物理 スキーマ に対応して、概念 スキーマ は論理 スキーマ と云われ、外部 スキーマ は概念 スキーマ と云われています──「概念」 という用語と 「論理」 という用語が、（ANSI の用法とは） ズレ て使われているので、注意して下さい。 どうして、こういうふうに、用語法の混乱が起こったのか、と言えば、それぞれの 「層」 の対応関係を考えるときに使われた用語が関与しているようです。というのは、内部層と概念層には相互作用があり、概念層と外部層にも相互作用があります──内部層と外部層との直接的な相互作用を回避している点に注目して下さい。 内部層の データ 構造と概念層の データ 構造を相違する構造にする理由は、「データ の独立性」 を実現するためです。すなわち、物理的な構造と独立して、「論理的な データ 構造」 を作れば、たとえば、コンピュータ 技術が進歩して、物理的な構造を作る技術が変化しても、データ 構造そのものを変えないで対応できるようにするためです。このことを、「物理 データ 独立性 （physical data independence）」 といいます。 また、概念層の データ 構造と外部層の データ 構造を相違する構造にする理由は、「データ の独立性」 を実現するためです。たとえば、外部的世界 （現実的世界） のなかで営まれている仕事の流れが変化しても、あるいは、組織構成が変化しても、あるいは、アプリケーション・プログラム が修正されても、変更・修正の影響度を、最小限に抑えるためです。このことを、「論理 データ 独立性 （logical data independence）」 といいます。 つまり、3つの 「層」 に切り離した理由は、それぞれの 「層」 のあいだで、「物理 データ 独立性」 と 「論理 データ 独立性」 を実現するためなのです。この 2つの独立性を総称して、「データ の独立性 （データ の独自性）」 と云っています。そして、この 「論理 データ 独立性」 の 「論理」 という用語が、「論理設計」として使われて、概念層の データ 構造を「論理 スキーマ」 というようになったのかもしれないですね──ただし、概念層の データ 構造を 概念 スキーマ というふうに云う人たちもいます。
さて、いずれにしても、データ 設計では、「データ の独立性 （データ の独自性）」 が最大の目的であって、およそ、データベース 設計法であれば、この独立性を実現するために、技術が作られています。 |
|
[ 補遺 ] （2009年11月16日）
データ・モデル の目的を一言でいえば、「データ の独立性」 を実現することでしょうね。 歴史の偶然に遭遇して、私は、1980年代、日本に RDB を導入・普及する仕事に就きました。そして、プロダクト としての RDB を説明するいっぽうで、コッド 氏が示した 「（データ の） 正規形」 を実地に適用できるように 「正規化手続き」 を 当時 説明していました。ただ、私は、当時、コッド 氏の論文を誤読していて──かれは 「全順序」 を前提した モデル （代数体系） を作ったのですが、かれの有名な論文 「A Relational Model of Data for Large Shared Data Banks」 のなかで Relation （関数、全順序） の代わりに、Relationship という日常語を使ってもいいという記述があったので、私は、コッド 正規形を チェン ERD （Entity-Relationship Diagram） で記述しても良いというふうに考えて、その やりかた を日本中に撒き散らしてしまった、、、（苦笑）──、のちのち、私の間違いを訂正するのに一苦労しました。その一苦労というのが、（私の間違いを懺悔するいっぽうで、） チェン ER を捨て コッド 正規形を できるかぎり本来の思想を活かしつつ実地に適用できるように工夫することでした。その工夫が TM （Ｔ字形 ER手法の改良版） です。 コッド 関係 モデル は、（ANSI の用語法で云うならば） 「概念層」 で構成される 「論理的意味論」 の モデル です。いっぽう、チェン ER は、（ANSI の用語法で云えば） 「外部層」 で記述される 「記述的意味論」 です。チェン 氏は、かれの論文のなかで、ERD から コッド 正規形に変換する やりかた を説いていますが、コッド 関係 モデル は ロジック を基底にしているので──第一階述語の コンパクト性を実現しているので──、ロジック を使って構成しない やりかた は邪道 （あるいは、都度の対応） にすぎないでしょう。この意味で、私は、チェン ER を 毛頭 信頼していない。勿論、私は 「記述的意味論」 を排除するつもりなど更々ないのであって、私が謂いたいことは 「記述的意味論」 が 「健全かつ完全である」 ことを証明してほしいということです。というのは、もし、「概念層」 の モデル が 「真」 であるためには、その前提 （前件） となる 「外部層」 の モデル が 「真」 でなければならないでしょう──そして、勿論、推論 [ チェン 氏が示した変換法 ] が一つの公理系として無矛盾であることが前提です （！） もし、それが実現できないなら、「論理的意味論」 として モデル を作って無矛盾性を実現して、さらに、その モデル を現実的事態と対比して完全性を実現するほうが よっぽど簡単な やりかた です。この意味において、私は、コッド 関係 モデル 派です。 1980年代、日本では 「DOA （Data-Oriented Approach）」 という ことば が生まれました。当時、私は、DOA を標榜していました。しかし、DOA の流派のほとんどが──たぶん、コッド 関係 モデル 派を除いた すべての流派が──外部層の スキーマ を作ることに専念していました。DOA が謳った点は 「データ の独立性」 でした。その意味では、私は DOA に属すると思うのですが、外部層の スキーマ を作る流派が ほとんどである状態のなかで、私は 「浮いていました （I was out of place、I was not part of it）」。1990年代に入って、私は、ますます、「論理的意味論」 を進めてきて、とうとう、2005年以後から私は DOA という ことば を嫌うようになりました。そして、たぶん、2007年頃に、私は公の場で 「私は DOA の流派ではない」 というようになりました。ただし、（本 エッセー で テーマ にした） 「データ の独自性」 を私は今でも信奉しています。今の私は、「データ の独立性」 を重視した 「論理的意味論」 派であると云っていいでしょう──勿論、私は、前述したように 「記述的意味論」 を排除しないし、事業そのものを記述した絵 （diagram） を 「見える化」 と称して描くことには 毛頭 反対しないけれど、それは モデル ではない、と謂っているだけです。モデル とは、現実的事態の 「形式的構成」 です──勿論、「形式的」 というのは ロジック （無矛盾性・完全性を実現する ロジック） を使うということと同義です。 |
| << もどる | HOME | すすむ >> | |
| ▼ ベーシックス | |||