コラム・特集

3.2 3つのデータ・モデル

IEハンドブック
第12部 コンピュータと情報処理システム

第3章 データベース管理

3.2 3つのデータ・モデル

階層型,関係型,ネットワーク型のデータ・モデル (data model)は,データベースの論理構造を定義するのに異なる用語法を採用している。さらには,同じデータモ デルに対応した2つのデータベース・システム (たとえば 2つの階層型システム)でも異なった用語法を用いている場合もある。このような表現は,1971年の画期的な CODASYL『 データベース作業グループ報告 (Data Base Task Group Report)』 にある以下の定義に基づいている。

1.デ ータ・アイテム・タイプ (Data ltem Type)データ・アイテムとは名前のつけられたデータの最小単位である。たとえば部品メーカー名(SNAME)や部品メーカーの住所 (ADDRESS)はデータ・アイテム・タイプである。

2.アイテム・オカレンス(Item Occurrence)データ・アイテムの実際のオカレンス (出現)ないし事実がアイテム・オカレンスである SNAMEに対するアイテム・オカレンスの例はSmith(スミス)である。

3. レコード・タイプ (Record Type)レコード・タイプとはデータ・アイテム・タイプの集まりである。たとえば,SUPPLIERと呼ばれるレコード・タイプは, SNAMEとADDRESというデータ・アイテム・タイプからなるものと定義されるであろう 。

4. レコー ド・オカレンス (Record Occurrence)(あるいは単にレコード(Record)レコー ド・オカレンスとは,ある特定のレコード・タイプの事実ないしオカレンス (出現)である SUPPLIERというレコード・タイプのオカレンスの例はSmith,740 Main Streetという複数のアイテム・オカレンスからなるであろう。

5,セ ット・タイプ(Set Type)(あるいは単にセット (Set))セットとは,名前のつけられたレコード・タイプ間の関係である。一方のレコード・タイプ はセットのオーナ(owner)と呼ばれ,他方のレコー ド・タイプはセットのメンバー (member)と呼ばねる。セットは 1対多 (1対N,ここでN≧0) の関係を表わし,この関係においては,オーナー・レコード・タイプのどの1つのオカレンスも,メンバー・レコード・ タイプの多数 (N)のオカレンスに対応するであろうが,どのメンバー ・オカレンスも,オ ーナー・レコー ド・タイプの 2つ以上のオカ レンスに対応することはできない。たとえば,1人の顧客は多くの注文をすることができるが,いかなる注文も2人以上の顧客がすることはできない。したがって,オーナーとしてCUSTOMERというレコード・タイプと, メンバーとしてORDERというレコード・タイプをもつセット(これをPLACESと呼ぶ)を定義できる。

6 セット・オカレンス(Set Occurrence)セット・オカレンスは,オーナー・レコード・タイプのオカレンスと,すべての対応するメンバー・レコードのオカレンスからなる(たとえば,あ る特定の顧客のレコード・オカレンスに対応するすべての注文のレコード。

前述の定義は,階層型システム,関係型システム ,ネットワーク型システムの用語法を理解するための基礎として役立つ 3つの用語法のあいだの対応を図表12.3.1 (a)に示したが明らかにデータモデルのあいだにある。共通性が見出される。

3種類の論理構造のあいだの差異は, 図表12.3.1(b)か ら12.3.1(d)までの論理構造の例を考察 すれば明白である。長方形はレコード・タイプ(セグメント・タイプ,関係スキーマ)を表わしている。矢印のついた線はオーナー・レコード・タイプ(親セグメント・タイプ)からメンバー・レコード・タイプ(子セグメント・タイプ)へのセット(親子関係)を表わしている。

ネットワーク型モデルでは,どのレコード・タイプも, 多数のセットのオーナーであると同時にメン バーにもなりうる。階層型モデルでは,セグメント・タイプはたかだか1つの親子関係で子になりうる。関係型モデルの場合には,何らかのアプリケーションの論理構造の設計者は, 2つのレコード・タイプ間の関係を明示的に定義することは許されていない。しかしながら, 2つの異なっ たレコード・タイプ(すなわち,2つの異なった関係スキーマ)に同じアトリビュートを繰り返すことによって 関係を暗黙に定義することができる。このことは ,後に, システムRの議論のなかで例示する。

これら3つのアプローチは,それぞれ情報システム内でモデル化されるアプリ ケーションの性質についての考え方を組織化する異なった方法を提供する。これらは,現実の世界の見方,ないしモデル化の異なる方法を提供する。すなわち,ネットワークとして,樹形として,表の集まりとして.データベースの論理構造を特定化する際の,このような基本的差異のために,データ操作の手段が違ってくる。階層型モデルとネットワーク型モデルの場合には,レコード・タイプのあいだの関係を明示的に表現するから,データ操作は,これらの関係(すなわちセット)によって行われる関係型モデルの場合には表があるだけである。したがって,データ操作は,共通なアトリビュートに基づいてデータ表を結びつけ,SELECT,PROJECT,JOINといったオペレーターによって表からデータを抽出することによって行われる。

以下の節では, IMS,システムR,MDBSのデータ の記述と操作を示すが,なんらかの顕著な特徴を強調する。たとえば,IMSの場合には,論理構造とともに 物理的記憶構造の指定が必要である。他の2つのシステムの場合には,データベースのレコードの物理的な場所にはあまりとらわれず,レコードのクラスタリングに対して限られた制御しかしない。IMSによって利用可能な物理的記憶構造は議論されるが,他のシステムでのクラスタリング手法には触れない。システムRについては,デ―夕操作言語であるSEQUELを強調する。MDBSの場合には,(他のネットワーク型システムの手法より進んでいる)革新的な論理構造化手法を強調する。

 本コラムは絶版となっている「IEハンドブック(サルベンティ編・日本能率協会訳・1986)」をアーカイブとして掲載するものです。このハンドブックの各章は多くの事例と理論を通して生産性向上に対するアイデアを提供するべく専門家によって執筆されています。基盤をなしているIEの考え方・原則はインダストリアル・エンジニアリングにかかわるすべてのひとに有用でしょう。

関連記事一覧

2019ものづくり公開セミナーガイド

B2Bデジタルマーケティングセミナー

ものづくり人材育成ソリューション

マーケティング分野オンラインセミナー