Ａ−ＶＸのファイル　その２

ＮＥＣのマニュアル「データ管理説明書」の補足をしようとする試みですが、データ管理説明書の最初の「第１章　基礎知識」のところは、今ではあたりまえなので書くものもないかと思ったのですが、書いておいた方が後で他の説明もしやすそうなので、下に簡単に説明しておきます。だいたいＮＥＣの公式のマニュアルに書いてあるのがすべてなので、そのマニュアルからの引用だけです。

１　フィールド

ＮＥＣのマニュアルには次のような説明が書いてあります。

フィールドとは、データの論理的な最小単位であり、ユーザプログラムにおける最小の処理単位である。フィールドはデータ記述情報（例えば、ＣＯＢＯＬのデータ部）の中で定義され、固有のフィールド名によって識別される。 「データ管理説明書（２００９年１１月版）」−「１．１ 用語の定義」より

ＣＯＢＯＬでいうとデータ項目に相当するものです。

２　レコード

同じくＮＥＣのマニュアルからの引用。

レコードとは、上記フィールドの集まりであり、プログラムの論理的入出力（例えば，ＣＯＢＯＬのＲＥＡＤ・ＷＲＩＴＥ命令）における単位である。 「データ管理説明書（２００９年１１月版）」−「１．１ 用語の定義」より

下の図の「顧客番号」「送状番号」「発注日付」「発送日付」「支払日付」がそれぞれフィールドで、それが集まったものがレコードです。

データベースを知っている人なら、データベースのテーブルと列の関係と同じものが、Ａ−ＶＸのファイルにもある（レコードとフィールド）ということが認識できるはずです。

３　ブロック

これもＮＥＣのマニュアルからの引用。

ブロックとは，レコードの集まりであり，主記憶と二次記憶の間のデータの転送単位である。プログラムの入出力命令の単位がレコードという論理的なものであるのに対してブロックは物理的な単位であり、物理レコードともいわれる。１ブロックは１レコードあるいは２レコード以上で形成されるが、２レコード以上で形成することにより主記憶と二次記憶間のデータ転送回数を減らすことができる。 「データ管理説明書（２００９年１１月版）」−「１．１ 用語の定義」より

１レコード毎にハードディスクから読み込みしていると、１０レコード読み込もうとすると１０回、１万レコードを読み込もうとすると１万回ハードディスクから読み込まないといけないので非効率です。
そこで１回に複数レコードをまとめて読み込んで効率化を図ろういうことが考えられました。複数レコードを１つにまとめたものをブロックといいます。そしてブロック単位にハードディスクからメモリに転送を行います。ブロック単位でメモリに転送したブロックはいったんメモリ上に置いておき、プログラムの要求毎に１レコードづつプログラムに読み込まれます。
例えば１０レコードを１ブロックにまとめれば１０レコード読み込む場合もハードディスクからの転送は１回ですみます。ブロック単位でハードディスクから転送しても、プログラム側から見るとレコード単位で読み書きすることになるので、プログラム側は意識する必要はありません。

そうすると「１ブロックを１万レコードにまとめればいいのではないか」、という話も出てくると思います。ブロックをあまり大きなサイズにしてもメモリを消費するし、例えば保守などで１レコードだけ必要な時も１万レコードをメモリに転送しないといけないので、逆に効率が悪くなります。それ以前にブロックの最大サイズも決まっているので（最大で４０９６バイト）、実際はバランスを取って現実的な値にします。

下の表はファイル編成とブロック長およびレコード長の関係です。ファイル編成は後程説明します。

ファイル編成	磁気ディスク		フロッピーディスク
	レコード長	ブロック長	レコード長	ブロック長
順編成	１〜４０９６	１〜４０９６	１〜１０２４	１〜１０２４
相対編成	１〜４０９６	１〜４０９６	１〜５１２	１〜５１２
索引順編成	５〜４０９６	５〜４０９６	５〜５１２	５〜５１２
複数索引順編成 （データファイル）	５〜４０９６	５〜４０９６	−	−

ハードディスク（表の磁気ディスクのこと）で順編成ファイルを作るとき、レコード長の最大値は４０９６バイトです。ブロック長も４０９６バイトになります。つまり、レコード長を４０９６バイトにすると、１つのブロックに１つのレコードの構成になります。レコード長を１２８バイトにすると１つのブロックに最大３２レコードまで構成することができます。

１ブロック最大２５６レコードまでという制約もあります。このため１バイトのレコードを４０９６個で１ブロックにするということもできません。

フロッピーディスクはハードディスクと比べて、レコード長やブロック長が小さいファイルしか作れません。

４　ファイル

またもやＮＥＣのマニュアルからの引用。

ファイルは論理的に関係のあるレコードの集まりであり，データ処理における最も基本的な単位である。例えば、送り状の１行を１フィールドとみなせば、完全な１枚の送り状は１レコードであり、さらにこのレコードの集まりがファイルである。 「データ管理説明書（２００９年１１月版）」−「１．１ 用語の定義」より

ファイルはＷｉｎｄｏｗｓやＬｉｎｕｘのファイルと同じ意味です。レコードが集まったものがファイルです。（０個のレコード＝０バイトのファイルもあります。）

５　ボリューム

またもやＮＥＣのマニュアルからの引用。

ボリュームとは、取りはずしできる記憶装置の最小単位である。取りはずしできない二次記憶装置の場合は、その装置上の記憶装置をいう。例えば、一巻の磁気テープ、一台の固定ディスクなどをボリュームという。一つのボリューム上には１個のファイルのみを含む場合と２個以上のファイルを含む場合があり，磁気ディスク、フロッピィディスクおよび磁気テープにのみ一つのボリューム上に２個以上のファイルを含むことができる。 「データ管理説明書（２００９年１１月版）」−「１．１ 用語の定義」より

Ａ−ＶＸのハードディスクのＭＳＤ０００やＭＳＤ００１などのようにＭＳＤｘｘｘがそれぞれ１つのボリュームです。ボリューム名というものがあって、ボリュームに名前が付けられます。例えばＭＳＤ０００に「VOL1」とか「SAKURA」とか任意の名前が付けられます。

フロッピーディスクの１枚１枚がそれぞれが１つのボリュームです。フロッピーディスクのボリュームにもボリューム名が付けられます。

ボリューム名を付けて何が良いかというと、ユーティリティでチェックすることができることです。Ａ−ＶＸのユーティリティは何かボリュームに対して操作するとき、装置名とボリューム名をきいてきます。装置名かボリューム名のどちらかは省略できますが、両方入力することによって間違いを防ぐことができます。
例えば２台のオフコンがあって、オフコンＡのＭＳＤ０００のボリューム名が「sakura」、オフコンＢのＭＳＤ０００のボリューム名が「fuji」とします。＃ＡＢＣでボリュームを初期化するときにＭＳＤ０００だけ入力してボリューム名を省略することができますが、このときオフコンＢのＭＳＤ０００を初期化するつもりで間違ってオフコンＡ上で操作してしまうとボリューム名を省略しているので、そのままオフコンＡのＭＳＤ０００を初期化してしまいます。一方、ボリューム名も入力するようにすれば「fuji」と「sakura」と異なるので、ユーティリティがエラーを出して、気が付くことができます。

ハードディスクもフロッピーディスクも１つのボリュームに複数のファイルを作ることができます。これはＷｉｎｄｏｗｓも同じですよね。ＷｉｎｄｏｗｓはＣドライブに沢山のファイルを作ることができます。

フロッピーディスクは複数のボリュームに１つのファイルを入れることもできます。フロッピーディスクは１枚の容量が１．２メガバイトしかないので、５メガバイトとか１０メガバイトのファイルは入りません。この時は複数のフロッピーディスク（つまり複数のボリューム）を使って、１つのファイルを入れることになります。これをマルチボリュームファイル（複数ボリュームファイル）といいます。
１つのボリュームだけに入っているファイルをシングルボリュームファイルといいます。

６　セクタ

ハードディスクやフロッピーディスクなどはセクタという単位で区切られて管理されています。

今は、１セクタは２５６バイトです。

ＮＥＣの説明書には１セクタが何バイトなのかあまり明確に書いていないようです。（昔は１セクタ１２８バイトとか、１セクタがいろいろなハードディスクやフロッピーディスクがあったため、説明書には明確に書かれていないようです。要は説明書では書けないので、それぞれのハードディスクの仕様を見てくれということ。）

ブロックのところでは、レコードとブロックの関係について説明しましたが、ここではセクタとレコード、ブロックの関係について説明してみます。

ここで、あるデータファイルに１２８バイトのデータ（レコード）を４件格納するとします。まずはブロック化しない場合を考えてみます。

上の図のように、１セクタに１レコードずつしか格納されず、４件格納するのに４セクタ必要になります。１セクタごとに１２８バイトの空き領域ができて、利用効率が悪いです。

そこで、ブロック化してレコードを格納することにします。２つのレコードを１つのブロックとして扱い、格納することにします。

このようにすると空き領域が無くなり、２セクタで４件のレコードが格納できるようになり、効率がよくなります。１ブロック中のレコードの数をブロック化係数といい、今回の場合はブロック化係数が２ということになります。また、レコード長×ブロック化係数をブロック長といい、今回のブロック長は２５６となります。
ブロック長は最大で４０９６バイトとなります。

さて、ここでブロック化係数を３にするとどうなるかです。

１ブロックに２セクタ使用しますが、２セクタ毎に１２８バイト空き領域ができます。ブロック化係数を４にすると、またピッタリになります。

レコード長が１２８バイトの場合は、ブロック化係数が２，４，６，８・・のときに効率が良さそうです。そうなると、２，４，６，８・・・のどれがいいか？ですが、そこはブロックのところで説明した通り、メモリに転送する回数で考えます。順アクセスする場合は、１回に読み込むデータを多くした方がよいので、なるべくブロック化係数を大きな値にします。ランダムアクセスなら、１回にあまりたくさん読み込んでも効率が悪いので、ブロック化係数は２ぐらいでいいかもしれません。

今までは、１レコード１２８バイトというキリの良い数値でしたが、一般的には１レコード２００バイトとか３１６バイトとか、いろいろなレコード長です。

例えば、１レコード１５０バイト、ブロック化係数１の場合は下の図のようになります。

１レコード１５０バイト、ブロック化係数３の場合。

１レコード３８０バイト、ブロック化係数１の場合。

セクタ、レコード、ブロックの関係から、ブロック化係数は次のように決めます。

• データの格納効率を考えて、なるべくブロック長が２５６バイトの倍数か、それより少し少ない長さにする
• データのアクセス効率を考えて、順アクセスの場合はなるべくブロック化係数は大きな数値にする、ランダムアクセスの場合はなるべく少ない値にする
• ブロックの最大長は４０９６バイト、１ブロック最大２５６レコードまでという制限があるので、その範囲内で