Ａ−ＶＸのデータベース（４）
-
入門レベルを少し外れるかもしれませんが、もう少し詳しく説明します。
- １ データファイル
-
Ａ−ＶＸ ＲＤＢの物理ファイルの実体は複数索引順編成ファイルです。複数索引順編成の上に表定義というものを被せたものがＡ−ＶＸ ＲＤＢになります。
このためＡ−ＶＸ ＲＤＢの動きや保守の方法、特徴などに複数索引順編成の影が見ることがあります。
Ａ−ＶＸ ＲＤＢには面白い特徴があります。
よくＯｒａｃｌｅやＳＱＬ Ｓｅｒｖｅｒ、ＭｙＳＱＬなど一般的なＲＤＢ（以下オープン系ＲＤＢと書きますね）の入門書には 「データは追加した順に格納されているわけではない」 と書いてありますが、Ａ−ＶＸ ＲＤＢには当てはまりません。
Ａ−ＶＸ ＲＤＢは追加した順（発生順）にデータが格納されています。
この特徴は重要で、Ａ−ＶＸの業務プログラムはこの特徴を利用して作られているものが多いです。
- ２ データファイルの再編成
-
データは追加した順（発生順）に格納されていると書きました。
データファイルは後ろの方に空き領域があって、前から順番にデータが入っていきます。
データを削除してもそこは再利用されません。データを削除していくと、だんだん歯抜けの状態になります。
上の図の�い妊譽魁璽稗討鯆媛辰垢襪箸�に、レコードＣを削除したところに書き込まない理由は次の通りです。レコードＣを削除したところに書き込むと、レコードＡ、レコードＢ、レコードＦ、レコードＤ、レコードＥという順番になり、Ａ−ＶＸ ＲＤＢの特徴である「追加した順（発生順）にデータを格納」という決まりに反してしまうからです。
データを削除した部分は再利用されないので、データを挿入したり削除したりを繰り返していくと、だんだん新規にデータを挿入できる空きの領域（未使用領域）が減っていき、そのうち未使用の領域が無くなって全く新規データを挿入できなくなってしまいます。
でも削除した部分は実際には利用されていない場所です。この削除した部分を再利用できれば、そこにまた新規データを挿入していくことができますよね。
この削除した部分を再利用できるようにすることを「データファイルの再編成」といいます。
データファイルの再編成が行われると、「追加した順」の関係が崩れないようにデータの入ったレコードを前に移動していき、後ろに削除した部分が集められて、そこが未使用領域に変わります。
データファイルの再編成を行うと、削除した部分を再利用できるようになります。
データファイルの再編成は時間が掛かります。データのサイズにもよりますが、数分かかる場合もあります。
普通はデータファイルは「自動アライン（自動再編成）」されるようになっており、ほとんど意識する必要はありません。
ただしこれには１つ問題があって、再編成を実行している最中はデータにアクセスできません。つまり業務中にいきなり一時的にデータアクセスが遅くなる、あるいは一時的に業務アプリが停止したような感じになることがあり得るわけで、シビアな状況でこれが起きると非常に困ることになります。
このため手動で強制的に再編成する方法もあり、サーバが暇な時間帯にバッチ処理で強制的に再編成をやってしまう、というようなことを行うこともできます。
Ａ−ＶＸ ＲＤＢでデータファイルがいっぱいになってこれ以上入らないという状態は２種類あって、１つは上で説明したように削除データがある状態、もう１つは本当にデータファイルにデータがいっぱいになっている状態です。
前者の方はデータファイルの再編成をして削除データを未使用状態に変更すれば又データを入れることができるようになるし、後者の方はさらにデータを入れたいのならば、データファイルを大きく拡張しなければならない、ということになります。
なお先に説明したキーファイルの再編成とデータファイルの再編成は別物（両方ともファイルの中身を整理するという点では同じですが）なので注意してください。
- ３ データベースをファイルとしてアクセス
-
最初にＡ−ＶＸ ＲＤＢは複数索引順編成ファイルの上に表定義というものを被せたものだと書きました。
テーブルのデータを見るときは、普通は表定義を通して、その下にある実データを見る形になります。
データファイルをＲＤＢとしてではなく、複数索引順編成ファイルとしてアクセスすることも可能です。表定義という布をピラッとまくって、隙間からファイルを覗くみたいな感じですね。これは特に禁止されていません。
とは言えＡ−ＶＸ ＲＤＢが関知しない状態でデータを見たり書き換えたりするということなので、いろいろと注意が必要です。
これら注意事項については難しい話になるのでＮＥＣの正式版のリレーショナル型データベース管理説明書を見てください。
