2004年 1月16日 作成 データ 設計法 （意味論と データベース 設計論） >> 目次 （テーマ ごと）
2008年 2月16日 補遺 　


　
　データベース 設計 （database design） は、一般的には、次の 3つの作業から構成される、と考えられている。

　　（1） 概念設計 （conceptual design）
　　（2） 論理設計 （logical design）
　　（3） 物理設計 （physical design）

　概念設計とは、データベース 化の対象を調べる作業である。現実世界のなかで扱われている情報の構造や、情報の使いかたを調べることを目的としている。
　論理設計とは、概念設計のなかで記述された対象を、論理的な データ 構造や演算系として変換する作業である。
　物理設計とは、論理設計のなかで記述された対象を、実際に使う DBMS （Data Base Management System） 向けの実装形を用意する作業である。

[ 参考 ]
　論理設計の 「論理」 は、「特定の IT ミックス （ハードウェア、OS、DBMS、言語） を考慮しない」 という意味であり、物理設計の 「物理」 は、「特定の IT ミックス を考慮した」 という意味である。したがって、スキーマ 構成のなかでいわれている論理 スキーマ・物理 スキーマ の論理・物理とは違うので注意されたい。スキーマ 構成については、後日、述べる。

　
　概念設計では、データベース 化の対象を 「モノ」 として考えて、「モノ」 の構造を記述する。「モノ」 のことを、「主体 （entity）」 という──「実体」 という訳語も使われている。それぞれの 「主体」 を記述する固有の情報を 「性質 （attribute）」 とよぶ──「属性」 という訳語も使われている。或る主体集合と他の主体集合の間には、相互作用が成立する。この相互作用のことを 「関連 （relationship）」 あるいは 「関係 （relation）」 という。

[ 参考 ]
　「性質」 のことを 「述語」 ということもあるが、性質と述語は違う。単項述語論理では、「性質 ＝ 述語」 だが、多項述語論理では、述語は 「関係」 と同値である （「述語＝関係」）。すなわち、対象を 「共通の性質」 で総括して 1つの集合を形成するなら、 単項述語論理式 P (x) の P は 「述語 ＝ 性質」 であるが、単項述語論理式 P (x) のなかの変項が 2項になれば、P (x, y) として 2項述語論理式になる。一般的にいえば、変項が 2つ以上の命題関数を一括して多項述語論理式という。2項述語論理式 P (x, y) の述語 P は、x と y との関係を記述するので、「x と y の関係の述語」 あるいは単純に x と y の 「関係」 という。
　言い換えれば、「関係 （Relation）」 は、数学的には、「関数」 である──数学上、正確には、関係 R (x, y) と 関数 f (x, y)　は違うが、一般的には、数学では、関係を関数として考えると思っていて良いでしょう。したがって、「関連」 と 「関係」 は違う。

　
　概念設計には、次の 2つの やりかた がある。

　　（1） ER モデル （Entity-Relationship Model）
　　（2） 意味論 データモデル （Semantic Data Model）

　ER モデル は、主体集合の間に成立する相互作用を 「関連 （relationship）」 という概念を使って記述するのが特徴であり、チェン （Chen P.） 氏が、1976年に提示した。詳細については、以下の文献を参照されたい。

　　"The Entity-Relationship Model Toward a Unified View of Data", Chen P., ACM, 1976

　
　意味論 データモデル には、様々な モデル （EER モデル、DAPLEX、SDM など） がある。
　様々な モデル があるが、おおかた、以下の考えかたが共通して使われている。

　　（1） 汎化 （generalization） と特化 （specialization）
　　（2） 集約 （aggregation） と切断 （partitioning）
　　（3） 抽象化 （abstraction） と具体化 （instantiation）

　（1） は、「is-a」 関係を記述し、（2） は「part-of」 関係を記述し、（3） は「instance-of」 関係を記述する。
　詳細については、以下の文献を参照されたい。

　　"A Logical Design Methodology for Relational Database Using the Extended Entity-Relationsip Model",
　　Teorey T. et al, ACM, 1986

　　"The Functional Data Model and the Data Language DAPLEX", Shipman D., ACM, 1981

　　"Data Description with SDM : A Semantic Database Model", Hammer M. adn D. McLeod, ACM, 1981

　
　なお、小生は、概念設計に対して、ほとんど、興味がない、という点を正直に言っておきます。
　事業過程の分析は、論理設計のなかで、できる、というのが小生の考えかたです。それを具体的に実現した手法がＴ字形 ER手法です。Ｔ字形 ER手法は、「ER」 という言いかたをしているので、往々にして、概念設計の手法として理解されていますが、Ｔ字形 ER手法が起点としたのは「コッド 正規形」 であり、「コッド 正規形」 の弱点を補充するために、意味論を、若干、導入しましたが、Ｔ字形 ER手法の基本的な考えかたは、「言語 （コード 体系） を対象にして論理 データベース を設計する」 ことであって、現実の世界を対象にして 「モノ」 を記述することを、金輪際、考えていない。
　もし、Ｔ字形 ER手法を概念設計のなかで扱うとするなら、「言語の形態論」 と言ったほうが的確でしょうね。



[ 補遺 ] （2008年 2月16日）

　今回から暫くのあいだ、データ 設計に関して、「補遺」 を綴りますが、私 （佐藤正美） の立場は 「論理的意味論 （logical semantics）」 であるという点を、まず、はっきりと述べておきます。すなわち、私は、数学 （あるいは、ロジック） の観点に立って、「モデル」 を考えています。したがって、「モデル」 は、かならず、以下の 2点を示していなければならないと考えています。

　（1） 構文論 （生成規則）
　（2） 意味論 （指示規則）

　そして、TM （Ｔ字形 ER手法の改良版） は、それらの規則を示した 「経験論的な言語 L」 のひとつであると。
　したがって、私は、記述的意味論を信じていない──ただし、「記述的意味論を排除している訳ではない」 という点に注意して下さい。私は、記述的意味論を排除しないけれど、記述的意味論の見地に立っている人たちに問いたい点は、記述的意味論で記述された 「構成」 が 「無矛盾で完全である」 ことを証明してほしいという点です。なぜなら、われわれ システム・エンジニア は、いかなる やりかた をとろうが、最終 アウトプット として、ひとつの構成物を作るのだから。しかも、その構成物が、たとえ、概念設計の アウトプット であろうが、概念設計は、その直後に続く過程 （論理設計） の インプット とされるなら、論理設計が 「真」 となるためには、その前提である概念設計が 「真」 であることを要請するのは当然でしょう。

　もし、概念設計では、まず、管理対象を概説して、次の過程で、それらを細分するというのであれば、細分化された管理対象に関する制約・束縛の すべて を──事業過程・管理過程を実地におこなうことができる状態での制約・束縛の すべて を──記述できるとでも システム・エンジニア は考えているのかしら、、、ひとつの事業は、ひとりの トップマネジメント が作った訳でもなければ、ひとりの エンドユーザ が作った訳でもないのであって、事業過程・管理過程は、数多くの人たちが関与して、数年あるいは数十年を費やして 「改良」 してきた活物であって、改めて ゼロ （零） から作り直すなどということはできないでしょう [ もし、「できる」 と思っていれば、システム・エンジニア が自惚れに酔っているにちがいない ]。

　意味論上、管理対象を とらえることは、さほど難しいことではない。意味論で いちばんに難しい点は、制約・束縛を いかにして網羅するか──言い換えれば、制約・束縛の網羅性を いかに実現するか──という点です。 ER （Entity-Relationship） と称して、「箱と線」 で絵を描くのが概念設計ではない。だから、私は （データベース 設計としての） 概念設計を信じていない。ただし、制約・束縛の網羅性を請けあってくれる概念設計法があれば、この限りではないことも断っておきます。




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