コラム・特集

3.5 マイクロ・データベース・システム (MDBS)

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

第3章 データベース管理

3.5 マイクロ・データベース・システム (MDBS)

概 観
MDBS6は,マイクロ・コンピュータ上で利用可能な非常に優れたデータベース・システムである。MDBSはネットワーク型モデルに基づいているが,他のどのデータベースでも利用できないような付加的な論理構造化の特徴をサポートしている。他のネットワーク型システム同様MDBSは,データ・アイテム・タイプ,レコード・タイ プ,セ ット・タイプの観点からデータベースを定義可能である(図表12.3.1aぉょび12.3.1bを思い出してい ただきたい)部品メーカーー部品のネットワーク型スキーマを図表12.3.11aに示した。ORDEREDセットは,多数のある特定部品が注文中であろうということを示している。SUPPLYセ ットは, これらの数量のそれぞれが,ある特定の部品メーカーに対応し,また多数の数量が,ある与えられた供給者に対応しているであろうということを示している。

マイクロ・データベース・システムは,N:Mセット・タイプ,セット・タイプの再帰的利用,複数オーナー/メンバー・セット・タイプを含むスキーマをもサポートしている。これら付加的な論理構造化の手段を,それぞれ手短に考察する。

データベース構造を設計する意図をもってアプリケーション領域を考察すると,多対多関係にしばしば出会う。たとえば,概念的に部品メーカーと部品との間には多対多(N対M)関係がある。すなわち,ある部品が多数の(N≧0)部品メーカーに注文中であるかもしれないし,多数の(M≧0)部品が,1つの部品メーカーに注文中であるかもしれない。図表12.3.11aのスキーマにおいて,SUPPLIERとPARTDSとの間の多対多関係は, SUPPLYセットとORDEREDセットによってとらえられ,このセットは,共通のメンバー・レコード・タイプとしてQUANTITYをもっている。

各部品メーカーは,(SUPPLYによって)多数の数量と対応することができるし,また,各数量は(ORDEREDによって)たかだか1つの部品と対応するので,この論理構造は,多数の部品がどの部品メーカーに注文中であるかもしれないということを表わしていることになる。反対に各部品は,(ORDEREDによって)多数の数量と対応できるし,各数量は(SUPPLYによって)たかだか1人の供給者と対応するので,スキーマはまた, 任意の部品が多くの部品メーカーに注文中であるということを表わしている。多対多関係を表現するこのネットワーク・アプローチは,部品や部品メーカーのデータの冗長性を全く招かない。

どの部品がどの部品メーカーに注文中であるかということの他にも,部品メーカーと部品の間に存在する他の多対多関係がある。すなわち,どの部品がどの供給者に注文可能であるかということである。この直接的な多対多関係には媒介する数量はまったく含まれていない。図表12.3 .11 bに示したように,直接多対多関係を表現するための標準的なネットワーク・アプローチは,人為的なレコード・タイプ(データ・アイテム・タイプを持たないレコード・タイプ)を利用することである 各部品メーカーは,(S1セットによって)Xの多数のオカレンスと対応しうるし,また,各Xのオカレンスは(S2セットによって)たかだか1つの部品と対応するので,このスキーマは,ある部品メーカーが多数の部品を供給できるということを表現するようになる。反対に,各部品は, (S2によって)多数のXのオカレンスと対応できるし,また各Xのオカレンスは,(S1によって)たかだか1つの部品メーカーと対応するので,スキーマはまた,ある部品が多数の部品メーカーによって供給されうるということを表現している。部品や部品メーカーのデータには冗長性はない。

人為的なレコード・タイプを使うこともなく,また冗長性を招くこともなく,多対多関係を表現するのを可能にするN:MセットはMDBSの革新である。N:Mセッ卜は,メ ンバー・レコードのオカレンス当たり,たかだか1つオーナー・レコードのオカレンスであるという制約がはずされているということを除けば ,伝統的なセットと似ている。したがって,図表12.3.11 Cに示したように ,部品メーカーと部品との間の直接的な多対多関係がN:Mセット(CAN―SUPPLY)によって処理され うる。どのレコード・タイプがN:Mセットのオーナーであるかについての決定は任意である。ある与えられたオーナー・オカレンスに対応するメンバー・オカレンスすべてに容易にアクセスできるのと同様,与えられたメ ンバー・レコード・オカレンスに対応するオーナー・レ コード・オカレンスのすべてに容易にアクセスできる。伝統的な人為的レコード・タイプ法に比べN:Mセットの利点は,

(1)構造の単純さと明快さの増大,
(2)記憶と処理の能率の増大,
(3)DML(データ操作言語)のプログ ラミングの努力の減少,
である。

複数オーナー/メ ンバー ・セットタイプは, 2つ以上 のオーナー・レコード ・タイプをもつか,あ るいは, 2 つ以上のメンバー ・レコード ・タイプをもつセット ・タイ プである。たとえば,同 じ部門にいるサラリーマンと時 間給労働者とでは,異なるデータ ・アイテム ・タイプを 必要とする。図 12.3.11  dでは,EMPLOYセ ットが2 つのメンバー・レコード・タイプを持っている。たいていのネットワーク ・システムでも複数のメンバー・レコ ード・タイプは可能であるが,(MDBSを除いて)複数のオーナー・レコード・タイプを許容していない マイクロ・データベース・システムは,セットを再帰的に利用することが許されている。これは,セ ットが,オーナーとしてもメンバーとしても両方とも同じレコードをもつということを意味している。図表12.3.11 eの 例では,MANAGEセ ットが,オーナーとメンバーとして同じレコード・タイプ(EMPLOYEE)を もっている。このセットが示すように,ある従業員が他の多くの従業員を管理(manage)できるが,ある従業員はたかだか1人の他の従業員によってしか管理されない N:Mセットも再帰的にも用いることができる。

データ記述言語
MDBSの データ記述言語 (data description language : DDL)は ,MDBSの論理構造のデータ・アイテム・タイプ,レコード・タイプ,セ ット・タイプを形式的に指定するのに用いられる。ステートメントは以下のとおりである。

1. RECORD RECORDステートメントは,レコ ード・タイプの名前を与える。

2.:TEM RECORDステートメントに続くITEM ステートメントは,レコード・タイプ内のデータ・アイテムの名前,タイプ,大きさを指定する。有効なタイプは,整数,実数,バイナリー,ロジカル, 文字である。大きさとは,データ・アイテムの値を保持するためにレコード・オカレンスに割り当てられたバイト長のことである 。

3. SET SETステートメントは,セット・タイプ名, セット,および伝統的(I:N)セットかN:Mセットかどうかの指示を指定する。AUTOとMANという2種類の記憶がある。AUTOの記憶法は,この セットにメンバー・レコード・タイプのオカレンスが作成されるときはいつでも,そのレコード・オカ レンスがセット・オカレン スに自動的に追加されることを表わしているMAN(manual:手 動 )が指定されると,ユーザーは,新しいメンバー・レコードを適当なセット・オカレンスに明示的に追加しなければならない。伝統的なネットワーク・システムは,メンバー・レコードに対してだけセット・オーダー (Setorder:セットの順序づけ)を許している。MDBSでは,セット・オーダーは,オーナー・レコ ードに対応するメンバー・レコードの順序(オーダー)と,(N:Mセットの場合は)メンバー・レコー ドに対応したオーナー・レコード 順序(オーダー) を決めるのにも用いられる。ここでいくつかのセット ・オーダーを説明する。ここでは述べない他のものもサポートされている。例として,図表12.3.11 CのCAN―SUPPLYは ,PARTNO 上でソートされたメンバーと,SNAME上でソートされたオーナーをもつことができるであろう。このことは,任意の部品メーカーに対応する部品が部品番号の順にアクセスしうることを意味する。また任意の部品に対応する部品メーカーは,部品メーカーの順にアクセスできる。
a.FIFO―一レコード・オカレンスがセットに追加されるとき,論理的にそのセットの最後のレコー ド・オカレンスとして置かれる。
b.LIFO――レコード・オカレンスがセットに追加されるとき,論理的にそのセットの最初のレコー ド・オカレンスとして置かれる。
c.SORTED――レコード・オカレンスがセットに追加されるとき,そのセットのソートされた順に 置かれる。最小のソート・キー値をもつレコード・オカレンスが論理的にセットの第1番目である。 セット・オーダーが並べ変えられるとき,データ・アイテム名が,そのセットのソート・キーとして指定されるであろう。さもなければ,レコード全体がソート・キーとして用いられる。
d.IMMAT――ユーザーは,セット内のレコード・オカレンスの順序に関心をもたない。IMMAT erial(重要でない)セット・オーダーを使用する。ことは,MDBSがアクセスの能率を最大にするようにレコードをセットに挿入するという合図をすることである。

4. OWNER,MEMBER この2つ のステートメン卜は,セット・タイプのオーナーとメン バーを定義するのに用いられる。MDBSス キーマはすべて,SYSTEMと呼ばれる 特別なレコード・タイプを含んでいなければならない。SYSTEMは,少なくとも1つのセットのオーナーでなければならない。マイクロ・データベース ・システムは,SYSTEMの1つのオカレンスを自動的に作成するが,これは, データベースヘのエントリー・ポイントとして役立つ。

図表12.3.11 fでは,SYSTEMは2つのセットのオーナーである 図表12.3.11 fの部品メーカーー部品スキーマに対するMDBSの DDL指定を図表12.3.12に示す。

データ操作
MDBSのデータ操作言語(DML)は,プログラマーが デー タベー スを 利用できるようにするインター フェイスを提供するスキーマ がDDLによって形式的に定義された。あらゆる データベースのデータを操 作するために, DMLコマンドを含むアプリケーション・プログラムを プログラマーは書くことができる。DMLコマンドは, サブルーチンを 呼び出すことによって実行される。
MDBSのDML ルーチンはBASIC,FORTRAN,COBOL, PL/1,機械語のホスト・プログラムから呼び出すことができる。 DML呼び出しの一般形は以下のとおりである磁密な形式はホスト言語ごとに異なる)

EO=CALL(A,「ルーチン名 ,引き数」 , ホスト言語の変数)

ここで, A=DMLエントリ・ポイント・アドレスルーチン名=DMLル ーチン(コマンド)名引き数=コンマで区切られた引き数のリストは , DMLルーチンが必要とする。データ・アイテム ,レコード・タィプ,セ ット,データ・ブロック名を与える。

ホスト言語の変数=コンマで区切られたホスト言語の変数は,DEFINEとEXTENDというDMLコマンドのなかでのみ用いられる(DEFINEコ マンドは,データ・ブロックをつくるために2つ以上のプログラム変数のリストに名前をつけるのに用いられる。データ・ブロックは,データをデータベースからプログラム変数に移す。およびその逆を行うのに用いられる。EXTENDコマンドは,追加するホスト言語変数を含むように既存のデータ・プロックの大きさを拡張するのに用いられる)。

ネットワーク・システムにおいては,データ操作は,カレンシー・イン ディケータ(currency indicator)に基づいている。MDBSは4種類のカレンシー・イン ディ ケーターを利用する。

1. レコード・タイプのカレント・レコード・オカレンス (current record occurrence :CRO)
2.セットゃN:Mセットのカレント・オーナー(current owner:CO)
3.セットやN:Mセットのカレント・メンバ ー (current member:CM)
4.ラン・ユニットのカレント(current of the run unit :CRU)

アプリケーション・プログラムの実行中いつでも,レコード・タイプのオカレンスの1つがそのCROと呼ばれる。プログラマーは,いかなる時にもどのレコード・タイプのオカレンスがカレントであるかを制御するのに ,DMLコマンドを用いることができる。各レコード・タイプに対して1つCROインディケーターがある。 したがってMDBSはいつでも,レコード・タイプそれぞれについて1 つのオカレンスの場所を「知っている」現在の場所がわかっているので,オカレンスのどれも,すぐに処理 (たとえば,オカレンスからプログラム変数へのデータの移転)することができる 。DMLコマンドは,別のオカレンス・カレントをつ くる (すなわち,MDBSにその場所を「知らせるJ)のに用いられる

アプリケーション・プログラムの実行中いつでも,セットのオーナー・ レコード・タイプの1つのオカレンスが, セットのCOと呼ばれる DMLコマンドは, どのオカレンスがカレントであるか (すなわち,MDBSが,どれを現在「知る」かあるいは「見る」か)を制御するのに用いられる。すべてのセットおよびN:Mセットそれぞれに対して1つのCOイ ンディケーターがある。どのセットないしN:Mセットのカレント・オーナーもすぐに処理することができるどのセットおよびN:Mセットも また,いつでも,カレント・メンバーを持っている。どのレコード ・オカレンスがある与えられたセットのCMであるかは,プログラマーがDMLコマ ンドによって制御する。最後にCRUというのは単に,アプ リケーション・プログラムが最後にアクセスしたレコー ドのことである。

もっとも¬般的に用いられるMDBSのDMLコマンドのいくつかをここに記す。他のコマンドは,MDBSのユーザー・マニュアルに詳しい。

1.DEFINE EO=CALL(Al,“DEFINE,データ・ブロッ名”,変数)。ユーザーが指定した名前をもつデータ・ブロックが,指示されたホスト言語変数からなるように定義する。
2. CRS(Create Record and Store data)
EO= CALL(AO,“ CRS, レコード・タイプ,データ・ブロック”)。指定されたレコード・タイプの新しいオカレンスが作成され,指定されたデータ・ブロックを構成する変数の内容を用いて初期化される。そのレコード・タイプが,AUTOセ ットのメンバーであるならば,新しいレコードは,自動的に,セットのカレント・オーナーであるレコード・オカレンスのメンバーになる(すなわち,そ のオカレンスにリンクされる)。
3.AMS(Add Member to Set)EO=CALL(AO,“AMS,レコード・タイプ ,セットタイプ “).指定されたレコード・タイプのCROを ,指定されたセットのCOによって明らかにされるセット・オカレンスに追加する。すなわち ,これが,そのセットの COであるレ コード・オカレンスのメンバーになる。
4. FMSK (Find Member based on Sort Key) EO=CALL(AO, “FMSK, セット・タイプ,データ・プロック”).指定されたセットのCOのメンバーを探索してデータ・ブロックの変数の値に等しい ソート・キー値をもつ論理的に最初のメンバーを見つける。
5.FFM(Find First Member) EO=CALL(A0,“FFM,セット・タイプ “)。指定されたセットのカレント・オーナーの最初のメンバーが,そのセットのCMになる。
6. FNM (Find Next Momber) EO=CALL(AO,“FNM,セット・タイプ’).指定されたセットのCMに続く論理的に次のメンバーが,そのセットの新しいCMになる。もし次のメンバーが見つかれば , EOには,0の値が返される。
7. GETM(GET data from current Member) EO=CALL(AO, “GETM,セット・タイプ,データ・プロック”).指示されたセットのCM内のすべてのデータ・アイテム値が,指定されたデータ・ブ ロックの変数に返される。
8.GFO(Get Field from current OwnOr)EO =CALL(AO, “GFO,データ・アイテム・タイプ, セット・タイプ,データ・ブロック”)。指定されたデータ・アイテム・タイプの値が,指定されたセットのCOから引き出される。この値は,データ・ブロックの変数に返される。
9.SOM (Set current Owner based on current Member) EO=CALL(AO, “SOM,セット1,セット2″)。セット2のCMであるレコードが,セット1の COになる。この新しいCOに対応するセ ットの1の最初のメンバーがセット1のCMになる。
10. SMM(Set current Member based on current Member) EO=CALL(AO,“SMM,セット1,セット2″)。セット2のCMであるレコードがセット1のCMにもなる この新しいCMに対応するセット1の論理的に最初のオーナーが,セット1の新しいCOになる。

図表12.3.13は, DMLコマンドがいかにして互いに結びついて用いることができるかを説明するアプリケーション・プログラムのサンプルである。このプログラム は,部品メーカーLEHRが供給する部品と数量のすべてのリストを生成する。

照会インターフェース (Query Interface)
DMLのユーザーはプログラマーである必要がある。 MDBSは,DMLに加え,非手続的で英語に似た照会言語(query language)をサポートしており,これは,プログラマーでない人が,アドホックどのMDBSデータ ベースにも質問することを可能にする MDBSの照会は次のような一般形をもっている 。

<コマンド><検索項(FIND CLAUSE)><条件項 (CONDITIONAL CLAUSE)><パス項 (PATH CLAUSE》>

1つのコマンドはLISTであるが,これはただ単に, 表(すなわち,ファイル,関係, リスト)を自動的に作り出 表の内容は他の項によって決まる 検索項は,データ・アイテム・タイプのリストからなり,その値は条件項で指示された条件のもとで検索される。パス項は, 照会に応答する際にどのセットを用いるかを指示する。 部品番号101を注文した部品メーカーのリストを得るには,次のような照会が用いられる。

LIST SNAME FOR PARTNO=`101′ THRU SETl,SUPPLY,>ORDERED

この場合,検索項はSNAME,条件項(常にFORで始まる )はFOR PARTNO=’101′,パス項(常にTHRUで始まる )はTHRU SET1,SUPPLY,>ORDEREDである。パスは常にSYSTEMが持っているセットから始まる。指定されたパスは,検索項と条件項で挙げられた。データ・アイテム・タイプを含むレコード・タイプすべてに到達するかあるいは通過しなければならない。この事例の場合にはパスは,SYSTEMから始まって,SNAME とPARTNOを含むレコード・タイプを通過するようにしなければならない。

図表12.3.11 f を参照すると,SET1,SUPPLY,>ORDEREDがまさそのようなパスであることは明白である。セット名の前にある 「>」 という 記号は,パスが,メ ン バー・レコード・タイプからオーナー・レコード・タイプに進むことによってセットを利用することを示している(たとえば,QUANTITYから PARTDSへ と,ORDEREDセットを通って「上流の方に」進む。

パス項が非常に重要なのは,照会するデータ・アイテム・タイプを訪れるのに代替的なパスが存在するかもしれないからである 図表12.3.11 fのスキーマが,図表 12.3.11Cに示したN:Mセット(CAN―SUPPLY)を含むように拡張されているとする。パス項がなければ,LIST SNAME FOR PARTNO=’101’は あいまいであ る。ユーザーが,部品101を注文した部品メーカーのリストが欲しいのか,部品101を注文できる部品メーカー のリストが欲しいのか明らかでない。後者の場合には次のように処理される。

LIST SNAME FOR PARTNO=’101′ THRU SETl,CAN SUPPLY

パス項に似たSEQUELは,SEQUEL WHERE項で異なる関係からのフィールドのマッチングであることに注意されたい。 算式やブール式を含む複雑な検索項や条件項がサポートされている次の照会により,自であるか重さが39/2以下であるような部品を注文した部品メーカー名と発注量の10分の1を表わす表を得られる。

LIST SNAME,QTY/10 FOR COLOR= `WHITE’ OR(WEIGHT*2)≦39 THRU SET1,SUPPLY,>ORDERED

LEHRに43以上の数量を注文したすべての部品の部品番号,色 ,重量,数量のファイルを得るには,その照会は

LIST PARTNO,COLOR,WEIGT ,QTY FOR SUPPLIER=’LEHR’AND QTY>43 THKU SET1,SUPPLY,>ORDERED

である。
明らかに,MDBS照会システムを利用すれば,図表12.3.13にあるようなプログラミングの努力から解放される要するに,照会システムは,欲しい表を生成するのに必要なDMLプログラムを,自動的に作成し,実行する。さらにMDBS照会システムは,STATや CHANGEといった他のコマンドをサポートしている。STATは,データ値をリストするというよりは,そ の値の統計を出力する CHANGEコマンドは,選択されたデータ値を修正するのを可能にする対話型コマンドである。 照会システムは,コ ントロール・ブレイク,標題の定義,テーブル 索引(table lookup)を含む数多くのレポート作成の特徴をもサポートしている 照会によって生成された表は,あらかじめ準備されたソフトウェア・パッケージのインプットとしてあとで利用するためにコンソール,プリンター,ディスク・ファイルに送ることができる。MDBS照会システムのこのような特徴や他の特徴は,MDBSの文献に詳しい。

スキーマの動的再構造化
動的再構造化システム(dynamic restructuring system :DRS)は,どのようなMDBSスキーマでも,データがすでにデータベースにロードされた後に変更する ことを可能にする。DRSがなければ,データベース内のすべてのデータをファイルにダンプし,DDLによってスキーマを再指定し,そして,新しいデータベースにデータをロードしなければならないであろう。このような煩わしいプロセスは,DRSによって避けられ,改訂されたスキーマに合うようにデータベース・レコードを自動的に再編成してくれるこれは,データをダンプしたり再ロードすることなく行われる。

たとえば,既存のレコード・タイプに新し いデータ・アイ テム・タイプを付け加えるには,対話型コマンドADI(Add Data Item)を与えるだけである DRSは,この新 しいデータ・アイテム・タイプの名前,大きさ,属するレコード・タイプなどを聞いてくる。データベースのスキーマを変更し,そのレコード・タイプのすべての既存のオカレンスに,このデータ・アイテム・タイプのためのスペー スを割り当てる DRSに よって行うこと のできる多く の種類のスキーマ変更がある_もっとも一 般的に用いら れるDRS コマンドにはADI の他に, ART(Add Record Type:レコード・ タイプの追加),AST(Add Set Type:セット・タイプの追加), DDI(Delete Data Item:データ・アイテムの削除, DRT(Delete Record Type:レコード・タイプの削除), DST(Delete Set Type:セット・タイプの削除 )がある。

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

関連記事一覧

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

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

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

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