TKDatabase Solutions

オブジェクトデータモデル、オブジェクト指向とは、オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方のこと。オブジェクト指向は、当初プログラムの構造をオブジェクト群の相互作用の関係として捉えてプログラムコードを書き表すオブジェクト指向プログラミングから始まっていますが、その後、システム開発における要求分析フェイズにおいて、開発しようとする対象領域の構成要素をオブジェクトとして抽出・定義していくオブジェクト指向分析、システムの動作や構造をオブジェクトとクラスとして記述するオブジェクト指向設計のための、技術としても広く発展・普及することとなりました。オブジェクト指向の枠組みが持つ道具立ては、一般的で強力な記述能力を持ちます。特に複雑なシステム記述、巨大なライブラリの記述においては、現実問題としてオブジェクト指向の考え方は必須であるといえるでしょう。

オブジェクト指向分析が提唱される以前には、システム分析のレベルにおいては、データ構造を中心としたシステムの分析技法である構造化技法が存在していました。また、プログラミングのレベルでは、プロラムの実行の流れを決められた制御構造の組み合わせとして書き下す構造化プログラミングや、カプセル化を促すモジュールプログラミング、多態に対応するデータ指向プログラミングという技法が存在していました。これらに対し、オブジェクト指向手法はそれらを一般化しさらに推し進めたものであるという考え方があります。オブジェクト指向分析やオブジェクト指向設計に基づいてシステムを実際に開発する際には、オブジェクト指向プログラミング言語 を用いる必要は必ずしもありません。しかし、オブジェクト指向によるシステム分析結果を実装するには、プログラム構造とのセマンティクスギャップが少ないオブジェクト指向プログラミング言語を用いるのが普通であるとされています。オブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、英語のobjectには「目的語」、または「目的となる対象物」という意味があります。従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語です。

オブジェクト指向開発の方法論として、Booch法、オブジェクトモデル化技法 (OMT) 、オブジェクト指向ソフトウェア工学などが提唱されていました。近年、これらの各種の方法論で使用するダイアグラムの表記法は、OMGによってUMLとして1997年に標準化されており、以降はほとんどのオブジェクト指向開発方法論においてUMLが採用されています。

オブジェクト指向分析設計は、ソフトウェア工学において、ソフトウェア (システム) を相互作用するオブジェクトの集まりとしてモデル化 (オブジェクト指向モデリング) する、オブジェクト指向に基づくソフトウェア開発の方法です。オブジェクト指向の理論的枠組みに基づくソフトウェア開発、すなわちオブジェクト指向開発を行う際のソフトウェア開発工程において、分析工程であるオブジェクト指向分析と、設計工程であるオブジェクト指向設計の総称。プログラミング工程は、オブジェクト指向プログラミングといいます。 オブジェクト指向開発の具体的な方法論を、オブジェクト指向開発方法論 といいます。

オブジェクト指向プログラミングとは相互にメッセージを送りあうオブジェクトの集まりとしてプログラムを構成する技法のこと。この技法をサポートするプログラミング言語はオブジェクト指向プログラミング言語と呼ばれています。オブジェクト指向プログラミングには必ずしもオブジェクト指向プログラミング言語を用いる必要はありませんが、オブジェクト指向プログラミング言語の備えるクラスとその継承などの仕組みを利用するほうが格段に開発効率は向上するようです。

カプセル化とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいいます。データ隠蔽と勘違いされやすいですが、データ隠蔽はカプセル化の具体例の1つにすぎず、同一のものではありません。例えば、カプセル化の第一の利点は変更に対する耐久性です。いま色の内部表現がRGB (光の三原色) で保持されているとして、これが何らかの都合でCMYK (色の三原色) に変更されたとします。外部のプログラムがデータ内部に直接アクセスを行っていた場合、このデータにアクセスしていたすべての箇所を同時に変更しなければなりません。ですが公開メソッドを用いていれば、変更は内部表現から外部表現への公開メソッド内のみで済み、変更の影響を局所にとどめる事ができるのです。第二の利点は概念の抽象化です。そもそも「色」という概念にとって、その内部表現がRGBであるかCMYKであるかは主要な問題ではなく、必要なら望みの形式がとりだせる抽象的な「色」であることが望ましいのです。その他の表現形式が追加されたとしても「色」の意味は変化するべきではありません。このように、できるだけ形式と意味を分離する手段としてカプセル化は有効となります。

インヘリタンス（継承）とはオブジェクト指向を構成する概念の一つです。あるオブジェクトが他のオブジェクトの特性を引き継ぐ場合、両者の間に「継承関係」があると言われています。主にクラスベースのオブジェクト指向言語で、既存クラスの機能、構造を共有する新たなクラスを派生することができ（サブクラス化）、そのようなクラスは「親クラス（スーパークラス）を継承した」といいます。具体的には変数定義や操作などが引き継がれます。またJavaのインタフェース継承のように機能セットの仕様のみを引き継ぐ場合もあります。一般的に、BがAを継承する場合、B is a A.BはAの一種であるという意味的な関係が成り立ちます。従って、同じふるまいを持つからと言って、意味的に無関係なクラス間に継承関係を持たせるのは適切でない場合が多いのです。プロトタイプベースのオブジェクト指向言語のように「クラス」という概念を持たない場合でも、クローン元となるオブジェクトを指して「継承」と呼びます。

ポリモーフィズムまたはポリモルフィズムとは、プログラミング言語の型システムの性質を表すもので、プログラミング言語の各要素（定数、式、メソッド、オブジェクト、変数、関数など）についてそれらが複数の型に属することを許すという性質を指します。多態性、多相性、多様性とも呼ばれています。対義語はモノモーフィズム、単態性、単相性で、プログラミング言語の各要素が唯一つの型に属するという性質を指します。

ダイナミックバインディング（動的型付け）はプログラミングパラダイムの一つです。一般に多くのプログラミング言語は処理するデータを数字型、文字列型、それらの複合型（構造型）のような型によって分類するのが普通です。これはデータの型付けによって信頼性（型安全） （機能（関数）は形式に合った正しい型のデータのみを処理すべき）、最適化（型の定義が精密であるほど実行性能を引き出しやすい）の2つの問題に対処できるからです。この方向性に基づき、全ての機能と変数において処理する対象の型をプログラムの定義時点で決定し、たとえみかけの構造が同じであっても型が異なるデータを受け付けない立場を静的型付けといいます。これに対し定義上では型の限定を行わず、実行時に合致するデータが渡されると期待する、または合致するデータであるかを判定し、必要なら適切な変換を施したり別の機能に委譲するような立場を動的型付けといいます。期待する型とは異なるデータが渡された場合、エラーとして扱うものを強い動的型付け、積極的に型の変換などを試みるものを弱い動的型付けと呼びます。

ナビゲーショナルデータベースとは、ネットワーク型データモデルと階層型データモデルを包含したデータベースインターフェイスです。ナビゲーショナル技術は「ポインタ(pointer)」と「パス(path)」を使ってデータレコード間で誘導(navigate)を行います。対照的にリレーショナルデータモデルでは「宣言型(declarative)」または論理プログラミング技法を使います。一般にリレーショナルデータベースへの問い合わせは『what』 であるのに対して、ナビゲーショナルデータベースへの問い合わせは『how』となります。階層型データモデルもナビゲーショナルの一種と考えられます。階層型データモデルを扱うとき、上位に登ったり、下位に下ったりする「パス」があり、これは階層型ファイルシステムのパスに類似しています。一般にナビゲーショナルシステムはパスと前置詞の組み合わせを用います。

ナビゲーショナルデータベースという用語はチャールズ・バックマンが講演で用いたのが最初です。その中で彼は、自身の提唱する種類のデータベースにアクセスするプログラマを「ナビゲータ」と称しました。データベースの一種でもある階層型ファイルシステムを除いて、ナビゲーショナル技術は1980年代には凋落することとなりました。しかし、オブジェクトデータベースとXMLによってナビゲーション技術に再び関心が集まり、議論を発生させたのです。現在使われているナビゲーショナルな構造の例として、JavaScriptと密接に関連してWebブラウザで使われているDocument Object Modelがあります。DOMエンジンは軽量なナビゲーショナルデータベースの一種です。

リレーショナルモデル（関係モデル）はエドガー・F・コッドが集合論と述語論理に基づいて考案したモデルであり、関係データベース（リレーショナルデータベース）の基礎となっています。

関係モデル（リレーショナルモデル）における基本的な前提は、あらゆるデータは『n項』の関係で表現されるということです。数学における関係は二項関係をいいますが、関係モデルでは関係の概念をn項に拡張しています。 一つのn項の関係は、n個の定義域の直積集合の部分集合となります。数学モデルでは推論は二値の述語論理で行います。つまり個々の命題について真か偽かのいずれかの評価を行います。数学の命題は真か偽かの二値で「未知の値」や「不適切な値」
のような第三の値はありません。 なおコンピュータ科学では「未知の値」や「不適切な値」はしばしばnullに対応づけられます。関係モデルにおいては、二値論理が関係モデルの重要な要素であり三値論理を許容すべきでないと考える人々と、三値論理を関係モデルで許容できると考える人々がおり、研究者の間で見解が分かれているようです。関係モデルではデータの演算は関係代数あるいは関係論理を使って行います。関係代数と関係論理は同等の演算能力をもちます。関係モデルを活用することにより、関係データベースでデータベースを設計する人はデータベースに格納する対象となる情報を、整合性を備え論理的に表現することができます。情報の整合性は、データベース設計で制約の宣言を行うことで実現することができるのです。ここでいうデータベース設計は論理設計（スキーマ）と呼ばれることが多いようです。

リレーショナルモデルはエドガー・F・コッドによりデータの一般モデルとして考案されました。その後クリス・デイトやヒュー・ダーウェンなどの人々によりモデルの修整と開発が行われています。彼らは著書『The Third Manifesto』において、関係モデルがその基本原理を損なうこと無く望ましい形でオブジェクト指向機能に対応する技法を提示しました。関係モデルの重要な基礎をなすものとしては、ゲオルク・カントールと D・L・チャイルズの業績があります。カントールは19世紀のドイツの数学者であり多数の論文を公表し集合論を考案しました。チャイルズはアメリカ合衆国の数学者であり論文 “Description of a Set-Theoretic Data Structure” は、コッドの画期的な1970年の論文 “A Relational Model of Data for Large Shared Data Banks” で引用されました。 チャイルズの考案した集合論データ構造は、集合論をデータ検索の基礎として使っていました。このデータ検索では和、交わり、定義域、範囲、制限、濃度、直積などの集合演算を使っていたのです。集合と集合演算を採用することにより物理的データ構造からの独立性が実現されました。これは当時としては先駆的な業績でありました。

ナビゲーショナル技術に批判的な人々は、これを「構造化されていないスパゲッティのめちゃくちゃ状態」と見なし、構造化プログラミング以前のGoto文のようなものと言います。つまり、制御構造にとってのGoto文とデータ構造にとってのナビゲーショナル技術を似たような関係と見るのです。この観点では、リレーショナルモデルに基づくリレーショナル技術 (リレーショナルデータベース) は集合論と述語論理に基づいてデータ構造とその使用法に洗練された規則と一貫性をもたらします。ですが実際には、リレーショナルモデルではデータセットを可能な限り小さくする必要があります。これがリレーショナルモデル固有の問題なのか、将来の実装技術の改善によって解決される問題なのかは現時点では不明です。一部の人々はリレーショナル理論全体ではなくSQL言語に批判的です。また、現状のリレーショナルデータベース製品が固定カラム幅と事前定義された型に依存しすぎているとの指摘もあるようです。このため、リレーショナルデータベースをちょっとした仕事に素早く利用するのは難しいとされています。一部の人々は、リレーショナルデータベースに比較してナビゲーショナルデータベースエンジンの方が構築が簡単でメモリ消費も少ないと指摘します。ですが、SQLをサポートしていなかった1980年代終盤のリレーショナルデータベースのエンジンは非常に小さく、この指摘が当てはまらないことを意味していまうｓ。理由はどうあれ、小さな構造を扱う場合、ナビゲーショナル技術はよく使われています。興味深いことに、データ構造図の形式として一般に使われているものは全てネットワーク型データモデルに基づくグラフィカル表現です。これは、ナビゲーショナルな構造の方が視覚的に自然であることを示唆しています。相対的な多次元データを視覚化することは難しいのですが、リレーショナルモデルを擁護する人々は、相対主義はリレーショナルデータモデルの一部に過ぎないと主張するのです。