JPS62262154A - Data file device - Google Patents
Data file deviceInfo
- Publication number
- JPS62262154A JPS62262154A JP61104807A JP10480786A JPS62262154A JP S62262154 A JPS62262154 A JP S62262154A JP 61104807 A JP61104807 A JP 61104807A JP 10480786 A JP10480786 A JP 10480786A JP S62262154 A JPS62262154 A JP S62262154A
- Authority
- JP
- Japan
- Prior art keywords
- record
- file
- data
- records
- stored
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000006870 function Effects 0.000 claims description 8
- 230000008520 organization Effects 0.000 abstract description 20
- 238000012545 processing Methods 0.000 abstract description 19
- 238000000034 method Methods 0.000 description 14
- 238000012546 transfer Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 239000008280 blood Substances 0.000 description 1
- 210000004369 blood Anatomy 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
【発明の詳細な説明】
〔発明の目的〕
(産業上の利用分野)
本発明はデータの取出し・書込みスピードを速めたデー
タファイル装置に関する。DETAILED DESCRIPTION OF THE INVENTION [Object of the Invention] (Field of Industrial Application) The present invention relates to a data file device with increased data retrieval/writing speed.
(従来の技術)
計算機システムの基本ソフトウェアのひとつとして1通
常、ファイル管理システムと呼ばれるデータ管理機構が
存在する。このファイル管理システムは一定の規則の元
にデータを編成・管理し。(Prior Art) As one of the basic software of a computer system, there is a data management mechanism usually called a file management system. This file management system organizes and manages data based on certain rules.
アプリケージ1ンソフトウエアからのデータの取出し・
書込み(以下これをデータのアクセスと呼ぶ、)要求を
受けて、データを格納場所より取出してアプリケージ1
ンソフトへ与えたり、あるいは逆に書込むサービスを提
供している。Retrieving data from the AppCage 1 software
Upon receiving a write (hereinafter referred to as data access) request, the data is retrieved from the storage location and the application cage 1
We provide a service for providing and writing to software.
ファイル管理システムで許されるデータの編成方法には
通常何種類か有り、代表的なものとしては次のものがあ
る。There are usually several types of data organization methods allowed in file management systems, and the following are typical ones:
ω 順編成ファイル(シーケンシャル・ファイル)ファ
イルは一般的に、第7図の如く、レコードと呼ばれるプ
ログラムでの入出力単位となるデータのまとまりの規則
的な繰返しで構成されている。ω Sequential File A file is generally made up of regular repetitions of a group of data called a record, which is a unit of input/output in a program, as shown in FIG.
順編成ファイルは、この構造に対するアクセス方法とし
てアクセス開始位it(レコード番号で与える。)を指
定した後、レコード番号(以下レコード魔と呼ぶ)&の
順方向あるいは逆方向へ順次アクセスすることのできる
ファイル種類をいう。A sequential file can be accessed sequentially in the forward or reverse direction of the record number (hereinafter referred to as record number) & after specifying the access start position it (given by record number) as an access method to this structure. Refers to the file type.
■ 相対編成ファイル(リレイティブ ファイル)ファ
イルの構造は第7図に示す順編成ファイルと同じである
が、アクセス方法として、レコード−をランダムに指定
する任意位置レコード・アクセスの可能なファイル種類
をいう。(2) Relative file The structure of the file is the same as the sequential file shown in FIG. 7, but the access method is a file type in which records can be accessed at arbitrary positions by randomly specifying records.
■ 索引付順編成ファイル(インデックスト シーケン
シャルファイル)上記■、■のファイルの如く、物理的
な位置指定(レコード覧指定)でレコード・アクセスす
るのではなく、論理的なレコード名称(以下これをKE
Yと呼ぶ、)を用いてレコードのランダム・アクセスが
可能なファイル種類をいう、ただし、レコードを入/出
力するには論理的レコード名称であるKEYを物理位置
のレコード動に変換する必要がありこの処理は、ファイ
ル管理システムが行う、変換の方法は種々考えられてい
るが、代表的な例として最近よく使用されるB−tre
e方式と呼ばれる階層構造を持つ方式で説明する。第8
rAに示す最下層のデータ部りを除く各層は総称して索
引部と呼ばれ、最上層に必ず1個だけ存在するルートイ
ンデックス・ブロックBより、tree構造に各層のイ
ンデックス・ブロックCが展開される。■ Indexed sequential file (indexed sequential file) Like the files in ■ and ■ above, records are not accessed by physical position specification (record list specification), but by logical record name (hereinafter referred to as KE).
This is a file type that allows random access to records using the filename (Y).However, in order to input/output a record, it is necessary to convert the logical record name KEY to a record movement of the physical position. This process is performed by a file management system. Various conversion methods have been considered, but a typical example is B-tre, which is often used recently.
A method with a hierarchical structure called the e method will be explained. 8th
Each layer except the data section of the lowest layer shown in rA is collectively called the index section, and the index block C of each layer is expanded into a tree structure from the root index block B, which always exists in the top layer. Ru.
層の深さは、ファイル管理システム毎に適当なる範囲で
管理されており1通常は最大レコード数nに依存してい
る。データ部の直上層を除く、インデックスブロックは
、すべて、次層の各インデックスブロック個々が、どこ
から、どこまでのKEYを管理しているかの情報を有し
ており、あるKEYが与えられると、そのKEYは1次
層のどのブロックで管理されているかが、判定できる。The depth of the layer is managed within an appropriate range for each file management system, and usually depends on the maximum number of records n. All index blocks, except for the layer directly above the data section, have information about where and how many keys each index block in the next layer manages, and when a certain key is given, It is possible to determine which block in the primary layer is managing the data.
また、データ部の直上層のインデックス・ブロックは他
のインデックス・ブロックと違って、ひとつひとつのK
EYに対するレコード−を有しており。Also, unlike other index blocks, the index block immediately above the data section is
We have a record for EY.
この層にたどりついた段階で、該当KEYに対するデー
タ部のレコード島が判明する。従って、KEYによるア
クセス要求が発生すると、ルートインデックス・ブロッ
クより検索が開始され、順次。When this layer is reached, the record island of the data section for the corresponding KEY is known. Therefore, when an access request by KEY occurs, the search starts from the root index block, and the search is performed sequentially.
各段層を経て、最終的にデータ部が、レコードNαでア
クセスされる。After going through each stage, the data section is finally accessed by record Nα.
インデックスブロックの最下層がそのまま、データ部と
なっている管理方法も存在するが考え方に大差はない。There is also a management method in which the lowest layer of the index block is used as the data section, but the idea is not much different.
この索引付順編成ファイルの特徴は、■、■のファイル
編成法の如く、物理位置指定(レコード淘指定)による
アクセスをアプリケーションプログラムが行う必要がな
く、論理的なKEYで良い為、アプリケーションプログ
ラム完成後、何らかの要因でファイルのレコード並びに
変化が生じた場合にでもそのアプリケーションプログラ
ムが必要とするレコードのKEYに変化がなければ、ア
プリケーションプログラム側では、何ら修正の必要がな
いというメンテナンス性の良さである。The feature of this indexed sequential file is that the application program does not need to perform access by specifying a physical position (specifying record selection) as in the file organization methods described in ① and ②.A logical key can be used, so the application program can be completed. After that, even if the records in the file change for some reason, if the KEY of the record required by the application program remains the same, there is no need to make any modifications on the application program side, which is good maintainability. .
しかしながらこの索引付順編成ファイルは論理的なKE
Yを物理的なレコード嵐に変換する作業を必要とする為
に、アクセス・スピードが遅いという欠点を有している
。この欠点は、スピードの要求される場合は、特にファ
イル中に信子というオーダーのレコードを有し、かつ、
その全レコードをきめられた短い時間内に処理しなけれ
ばならない場合には、きめられた時間内に処理しきるこ
とが困難となり、メンテナンス性の良さにもかかわらず
、使用されない場合が多々あった。However, this indexed sequential file is
Since it requires the work of converting Y into a physical record storm, it has the disadvantage of slow access speed. The disadvantage of this is that if speed is required, especially if the file has a record of the order Nobuko, and
If all the records had to be processed within a short time, it would be difficult to complete the processing within the specified time, and despite the ease of maintenance, the system was often not used.
(発明が解決しようとする問題点)
すなわち、発明が解決しようとする問題点は、メンテナ
ンス性のよいファイル構成にするとアクセス速度が遅く
なってしまい、アクセス速度が速いファイル構成にする
とメンテナンス性が低下することである。(Problem to be solved by the invention) In other words, the problem to be solved by the invention is that a file structure with good maintainability slows down access speed, and a file structure with fast access speed reduces maintainability. It is to be.
したがって本発明の目的は、アクセス速度が速く、かつ
メンテナンス性の良いデータファイル装置を提供するこ
とにある。Therefore, an object of the present invention is to provide a data file device that has high access speed and is easy to maintain.
(問題点を解決するための手段)
本発明のデータファイル装置は、プログラムでの入出力
単位となるデータのまとまりであるレコードを複数個有
し、このレコードのアクセスをレコードの物理的な位置
を表わすレコード番号にて行う第1および第2のファイ
ルと、前記レコードを複数個有し、このレコードのアク
セスを、各レコード毎に設定された論理的なレコード名
称を用いて行う第3のファイルとを備えている。(Means for Solving the Problems) The data file device of the present invention has a plurality of records, each of which is a group of data serving as an input/output unit in a program, and accesses to these records are controlled by the physical location of the record. The first and second files are accessed using the record numbers shown in the table, and the third file has a plurality of the records and accesses the records using a logical record name set for each record. It is equipped with
そして、前記第1および第2のファイルの互いに対応す
るレコード間でデータの授受を行うために、前記第3の
ファイルの各レコードには、前記第1および第2のファ
イルのデータの授受を行う互いに対応するレコード番号
をそれぞれ格納する。In order to exchange data between corresponding records of the first and second files, each record of the third file is configured to exchange data of the first and second files. Record numbers corresponding to each other are stored.
また、第1のファイルの各レコードには、そのレコード
番号を格納した第3のファイルの対応するレコードのレ
コード名称と、データと、前記第2のファイルの対応す
るレコードのレコード番号とを格納する。さらに、第2
のファイルの各レコードには、そのレコード番号を格納
した第3のファイルの対応するレコードのレコード名称
と、データとを格納する。Furthermore, each record in the first file stores the record name and data of the corresponding record in the third file that stores the record number, and the record number of the corresponding record in the second file. . Furthermore, the second
Each record in the file stores the record name and data of the corresponding record in the third file that stores the record number.
また、これらの制御機能として、第1のファイルの各レ
コードを、そのレコード番号により順次取出す手段と、
この取出されたレコードに格納されているレコード番号
により前記第2のファイルの該当するレコードを取出す
手段と、これら取出されたレコードにそれぞれ格納され
たレコード名称が一致するか判断し一致した場合はこれ
らレコード間にてデータの授受を行わせる手段と、前記
取出された各レコードに格納されたレコード名称が、不
一致の場合は、一方のレコードに格納されたレコード名
称を用いて第3のファイルをアクセスして対応するレコ
ードを取出しそのレコードに格納されている第2のファ
イルのレコード番号を前記第1のファイルのレコードに
相手側レコード番号として記憶させる手段とを設けた。Further, as these control functions, means for sequentially extracting each record of the first file according to its record number;
Based on the record number stored in the retrieved record, a means for retrieving the corresponding record from the second file is used to determine whether or not the record name stored in each of the retrieved records matches, and if they match, these records are If the means for exchanging data between records and the record name stored in each retrieved record do not match, the third file is accessed using the record name stored in one record. means for extracting the corresponding record and storing the record number of the second file stored in the record in the record of the first file as the record number of the other party.
(作用)
本発明は、通常のデータ授受のためのアクセスは、レコ
ード番号によるアクセスを行い、アクセス速度を速く保
つようにし、項目の追加、変更。(Function) In the present invention, access for normal data exchange is performed by record number, keeping the access speed fast, and adding and changing items.
削除等によりレコード並びがずれた場合のように、メン
テナンスを要する場合はレコード番号のメンテナンス用
に論理的なレコード名称により索引するファイルを用い
、これによりメンテナンスを容易に行えるようにしたも
のである。When maintenance is required, such as when records are misaligned due to deletion, etc., a file indexed by logical record names is used to maintain record numbers, thereby facilitating maintenance.
(実施例)
以下本発明の一実施例を図面を参照して説明する。第3
図において、計算機の中央演算処理装置(CP U)は
主メモリ、及び補助外部メモリとそれぞれパスで結ばれ
ている。アプリケーション・プログラムは主メモリ上で
動作し、処理に必要なデータは、通常補助外部メモリに
存在するデータ・ファイルより、都度入/出力する。(Example) An example of the present invention will be described below with reference to the drawings. Third
In the figure, the central processing unit (CPU) of the computer is connected to the main memory and auxiliary external memory through paths. Application programs operate on the main memory, and the data necessary for processing is input/output from data files usually stored in auxiliary external memory.
また機能的には第4図に示す如く、データファイルと、
アプリケーションプログラムとの間にオペレーティング
システムの一部、あるいはオペレーティング・システム
と、アプリケーションプログラム間のサポート機能とし
てのファイル管理システムが存在し、前述の各種ファイ
ルの編成法をサービスしている。Also, functionally, as shown in Figure 4, data files and
A file management system exists as a part of the operating system or as a support function between the operating system and the application programs, and provides services for the various file organization methods described above.
第1図に本発明のファイル構成の一例を示す。FIG. 1 shows an example of the file structure of the present invention.
索引付順編成ファイルEの各レコード内機成Hは索引用
のレコード名称であるKEY及び実際に各種データを有
する相対編成ファイルF及びGの。The internal structure H of each record of the indexed sequential file E is the record name KEY for indexing and the relative organization files F and G that actually have various data.
上記各KEYに該当するレコード翫を持っており。I have record rods that correspond to each of the above keys.
ファイルFあるいはGの構成に変化がある場合には、必
ず一緒にアプリケーション機能側でKEYに該当するレ
コード−の整合を取り、常に正しいレコード翫データを
保有する。ここで上記相対編成ファイルGを第1のファ
イル、Fを第2のファイルとし、かつ索引付順編成ファ
イルEを第3のファイルとし、この第3のファイルを以
降、「KEY−レコード嵐対応ファイル」と呼ぶ。If there is a change in the configuration of file F or G, the application function always matches the records corresponding to KEY to always maintain correct record data. Here, the above relative organization file G is the first file, F is the second file, and the indexed sequential organization file E is the third file. ”.
相対編成の第2のツアイルFの各レコード内構酸−工は
、前記第3のファイルEのKEY及びそのKEYに関す
るデータ(この例では該KEYで示されるプロセス現在
値、)を有している。以降「現在値ファイル」と呼ぶ。Each record component of the second file F in the relative organization has the KEY of the third file E and data regarding the KEY (in this example, the current process value indicated by the KEY). . Hereinafter, it will be referred to as the "current value file."
相対編成の第2のファイルGの各レコード内構成Jは、
前記第3のファイルEのKEY及びそのKEYに関する
データ(この例では該KEYで示されるプロセス値の1
分毎時系列データ)を有している。以降、r分単位時系
列ファイル」と呼ぶ。The structure J in each record of the second file G with relative organization is as follows:
KEY of the third file E and data related to the KEY (in this example, 1 of the process value indicated by the KEY)
minute-by-minute time series data). Hereinafter, it will be referred to as "r-minute unit time series file".
各ファイルの最大レコード数n、腫、α悲は異なる。す
なわちファイルFに存在するデータがファイルには無い
場合等がある。また、各ファイル中のレコードの並びは
、相互に一致してはいない。The maximum number of records n, number, and α of each file are different. In other words, there are cases where data that exists in file F does not exist in the file. Furthermore, the order of records in each file does not match each other.
第5図に示すファイル構成例は以下に示す機能を実現す
る場合の例である。The file configuration example shown in FIG. 5 is an example for realizing the following functions.
プロセスを監視し、そのデータを時系列的に記録するシ
ステムにおいて、次の様に1分毎の時系列データを作成
する。まず1分毎に第1のファイルである分単位時系列
ファイルGの各レコードを順次取出し、該当する第2の
ファイルである現在値ファイルF上のレコードを読出し
て、現在値を得、時系列最新値として、ffi込んだ後
、分単位時系列ファイルの元の位置へ再び格納する。こ
の機能を実現する為の本ファイル構成例に基づく動作を
第2図のフローチャートに示す。In a system that monitors processes and records the data in time series, time series data is created every minute as follows. First, every minute, each record of the minute time series file G, which is the first file, is sequentially retrieved, and the corresponding record in the current value file F, which is the second file, is read to obtain the current value, and the time series After importing ffi as the latest value, it is stored again in the original position of the minute-by-minute time series file. The operation based on this file configuration example for realizing this function is shown in the flowchart of FIG.
通常の動作としては、太線ルートで示す如く。The normal operation is as shown by the thick line route.
分単位ファイルGのレコードを順次取出しくステップ■
)、記憶されている現在値ファイルF上の該当レコード
島を用いて現在値ファイルFより最新データを読出す(
ステップ■■)、この値が間遠いないかを相互のKEY
を照合チェックする(ステップ■■)ことで確認した後
、最新値を組込んだ時列系データを分単位時系列ファイ
ルの元の位置へ格納する(ステップ■)、これを全ての
レコードにつき繰返す(ステップ■)、注目すべきこと
は。Steps to sequentially retrieve records of minute file G■
), reads the latest data from the current value file F using the corresponding record island on the stored current value file F (
Step ■■), check whether this value is far from the mutual key
After confirming by cross-checking (step ■■), store the time series data incorporating the latest value to the original position of the minute-by-minute time series file (step ■), and repeat this for all records. (Step ■), what should be noted.
この場合に、分単位時系列ファイルG及び現在値ファイ
ルFに対する。すべてのファイルアクセスが、レコード
翫を用いた相対編成ファイルへのアクセスのみであるこ
とであり、これにより、処理スピードが大巾に向上する
。In this case, for the minute-by-minute time series file G and the current value file F. All file accesses are only accesses to relatively organized files using the recorder, which greatly improves processing speed.
索引付順編成ファイルである、KEY−レコード虱対応
ファイル(第3のファイル)Eを、アクセスしなければ
いけない場合も存在し、これは以下の2つの場合である
。There are cases in which it is necessary to access the KEY-record correspondence file (third file) E, which is an indexed sequential file, and these are the following two cases.
■ 分単位時系列ファイルGへ新しく追加された項目(
レコード)があり、該当する現在値ファイルF上のレコ
ードNaが未記憶である。■ Newly added items to minute time series file G (
record), and record Na on the corresponding current value file F has not yet been stored.
■ 現在値ファイルFのレコード並びが何らかの要因(
項目の追加、変更、削除等)によりずれて、記憶してい
たレコードNoが用をなさなくなった。■ The record order of the current value file F may be affected by some reason (
(Adding, changing, deleting items, etc.), the stored record numbers become obsolete.
■に対しては、第2131のフローチャート上のレコー
ド島の記憶有/fAチェック(ステップ■)で。For (2), use the record island storage presence/fA check (step (2)) on the 2131st flowchart.
また■に対しては、同じ<、KEYの照合チェック(ス
テップ■)で判定されろ、いずれの場合も、KEY−レ
コード鬼対応ファイルEを読込んで、正しいレコード血
へと自動補正しくステップ0@)、補正されたレコード
翫で現在値ファイルF上の該当レコードを読み込む(ス
テップOo)。Also, for ■, it is determined by the same <, KEY verification check (step ■). In either case, read the KEY-record demon correspondence file E and automatically correct the correct record blood in step 0 @ ), the corresponding record on the current value file F is read using the corrected record (step Oo).
いずれの場合も、索引付JIIiIg成ファイルである
KEY−レコード島対応ファイルEを読込むのは一度の
みであり1次回からは、レコード魚アクセスのみの通常
ルート走行が可能となる。In either case, the KEY-record island corresponding file E, which is an indexed JIIIiIg file, is read only once, and from the first time onwards, normal route travel with only record access is possible.
比較の為に上述の処理における現在値ファイルと分単位
時系列ファイルを両方とも索引付順編成ファイルとして
構成した場合の動作を第6図のフローチャートに示す、
この場合、処理方法は単純となるが、すべてのファイル
・アクセスがKEYを用いた索引付順編成ファイルへの
アクセスとなり、処理スピードは遅い。For comparison, the flowchart in Figure 6 shows the operation when both the current value file and the minute-by-minute time series file in the above process are configured as indexed sequential files.
In this case, the processing method is simple, but all file accesses are to indexed sequential files using KEY, and the processing speed is slow.
上述のように、現在値ファイル、分単位時系列ファイル
の両方を索引付順編成ファイルとして構成した場合(a
とする)に比べ1本発明のようにKEY−レコード翫対
応ファイルEとして索引付順、編成ファイル機能部を分
離し、現在値ファイルF。As mentioned above, if both the current value file and the minute-by-minute time series file are configured as indexed sequential files (a
1) The present invention separates the indexing order and organization file function section as a KEY-record corresponding file E, and creates a current value file F.
分単位時系列ファイルGはともに相対編成ファイルとし
た場合(bとする)の処理スピードの向上をいくつかの
仮定を置いて、試算する1本実施例の様な、ファイリン
グ処理において処理スピードはほとんど主メモリと補助
記憶装置間の入/出力(これを転送と呼ぶ、)回数で決
まり、他の処理部の処理時間は、転送に要する時間に比
べてほとんど無視し得る程度である。The improvement in processing speed when both minute-by-minute time-series files G are relative organization files (referred to as b) is calculated based on several assumptions.As in this embodiment, the processing speed is almost negligible in filing processing. It is determined by the number of input/outputs (this is called transfer) between the main memory and the auxiliary storage device, and the processing time of other processing units is almost negligible compared to the time required for transfer.
またこの転送は一般的なファイル管理システムでは、ブ
ロックと呼ばれるいくつかのレコードのまとまり単位で
行なわれる。In general file management systems, this transfer is performed in units of several records called blocks.
以下の仮定を置く。We make the following assumptions.
(i)索引付順編成ファイルはB tree形式で、索
引部は3階層構成とする。(i) The indexed sequential file is in B tree format, and the index section has a three-layer structure.
(…)索引付順編成ファイル、相対編成ファイルはすべ
てのブロック長が256バイト構成とし、各ブロックへ
のレコード格納率は100%を原則とする。(...) For indexed sequential files and relative files, all blocks have a length of 256 bytes, and the record storage rate in each block is, in principle, 100%.
(■)各レコード長は下記とする。(■) The length of each record is as follows.
第1,211m索引部・・・1シ(イト第3 〃
・・・12)<イト
(肘)索引付順編成ファイルの索引部ブロックは一度主
メモリへ持って来られた後は、処理終了まで主メモリ上
に存在する。1st, 211m index section... 1st (item 3rd)
. . . 12) Once the index block of the indexed sequential file is brought to the main memory, it remains in the main memory until the end of processing.
、(マ)索引付順編成ファイルのデータ部のヒツト率(
前回主メモリへ転送して来ているブロック中に今回アク
セスするレコードが含まれる率)は−率50%とする。, (Ma) Hit rate of data part of indexed sequential file (
The rate at which the record to be accessed this time is included in the block transferred to the main memory last time is -50%.
すなわちデータ部は2回に1回はブロック転送が発生す
る。In other words, block transfer occurs once every two times in the data section.
(vi)相対編成としての現在値ファイルを分単位時系
列ファイルのデータ並びで読込む場合のヒツト率も50
%とする。(vi) The hit rate is also 50 when reading the current value file as a relative organization in the data arrangement of the minute-by-minute time series file.
%.
以上の仮定に基づくデータ総点数1024 (全ファイ
ル1024レコードとする。)の場合の索引付順編成フ
ァイル各部のブロック数は第5図に示す如くであり、こ
の値は一般的なファイル管理システムにおいて妥当な値
である。Based on the above assumptions, when the total number of data points is 1024 (all files are 1024 records), the number of blocks in each part of the indexed sequential file is as shown in Figure 5, and this value is This is a reasonable value.
このとき前記aの場合のファイル構成方法での転送回数
は以下の回数となる。In this case, the number of transfers using the file configuration method in case a is as follows.
ルート・インデックス・ブロックの転送lX2=2回
(両ファイルで)第2階層インデックスブロックの転送
6X2=1211 (両ファイルで)第3階層インデ
ックスブロックの転送86 X 2=172回(両ファ
イルで)データ部の転送r分単位時系列ファイル
256回(現在値ファイル 部×き172回計
614回一方、bの
場合の転送回数は以下の回数となる。Root index block transfer lX2 = 2 times
(For both files) 2nd layer index block transfer 6 x 2 = 1211 (for both files) 3rd layer index block transfer 86 x 2 = 172 times (for both files) Data section transfer r minute unit time series file
256 times (current value file section x 172 times total)
614 times On the other hand, the number of transfers in case b is as follows.
現在値ファイル 86X2=l)2回計
428回この結果、上
記両者は次の通りとなる。Current value file 86X2=l) 2 times total
As a result of this 428 times, both of the above become as follows.
上式から明らかなように、転送回数の大巾剤減、すなわ
ち処理スピードの向上が図れる。As is clear from the above equation, the number of transfers can be significantly reduced, that is, the processing speed can be improved.
またbの構成におても、現在値ファイル、分帛位時系列
ファイルともに、KEY−レコード翫対応ファイルを経
由すれば、KEYによる論理的なアクセスを行うことが
可能であり、メンテナンス性を保ったままで処理スピー
ドの向上が図れている。In addition, in configuration b, both the current value file and the fractional time series file can be logically accessed by KEY via the KEY-record correspondence file, which maintains maintainability. The processing speed has been improved without changing the settings.
このように、KEYによる索引部をひとつのファイルと
して独立させた索引付順編成ファイルとし、データ部は
レコード中にKEYを含む相対編成ファイルとして構成
し、また参照相手の相対編成ファイルのレコードhをフ
ァイル・データとして記憶する。このようなファイル構
成とすると。In this way, the index section by KEY is made into an independent indexed sequential file as one file, the data section is configured as a relative organization file containing KEY in the record, and the record h of the relative organization file to be referenced is Store as file data. If you have a file structure like this.
KEYによる論理的なアクセスはKEY−レコード島対
応ファイルとしての索引付順編成ファイルを経由して望
むデータを有する相対編成ファイルをアクセスできると
共に、メンテナンス性を保持したままで処理スピードが
必要とされる機能からは、レコード島アクセスのみによ
り、処理スピードを確保することができ、従来、処理ス
ピードが遅くなるがゆえにメンテナンス性を犠牲にして
いた機能部へも索引付順編成ファイルのメリットを適用
することが可能となる。Logical access using KEY allows access to a relative organization file containing desired data via an indexed sequential organization file as a KEY-Record Island compatible file, and processing speed is required while maintaining maintainability. In terms of functionality, processing speed can be ensured only by accessing record islands, and the benefits of indexed sequential files can also be applied to functional sections that traditionally sacrificed maintainability due to slow processing speed. becomes possible.
以上のように本発明によればレコードのアクセスを物理
的なレコード位置であるレコード番号によって行うこと
により処理スピードを速め、しかもメンテナンスが必要
であっても、データの論理的な名称を用いてアクセスす
るファイルを独立して用いているため、これによってメ
ンテナンス性を損うことがない、すなわち、従来困難で
あった、メンテナンス性の向上と処理スピードの向上を
同時に可能としたものである。As described above, according to the present invention, processing speed is increased by accessing records using the record number, which is the physical record position, and even if maintenance is required, data can be accessed using the logical name of the data. Since the files are used independently, this does not impair maintainability. In other words, it is possible to improve maintainability and processing speed at the same time, which was difficult in the past.
第1図は本発明によるデータファイル装置の一実施例を
示すファイル構成図、第2図は第1図で示したものの動
作を説明するフローチャート、第3図および第4図は本
発明を実行する装置構成の概略を示すブロック図、第5
図は索引付順編成ファイルのブロック数の関係を説明す
るための図。
第6図は本発明装置との比較のために示す従来の動作例
のフローチャート、第7図は一般的な順編成及び相対編
成ファイル構造を示す図、第8図は一般的な索引付順編
成ファイルの構造を示す図である。
E・・・索引付順編成ファイル、
F、G・・・相対編成ファイル、
H,I、J・・・各ファイルのレコード内容、。
代理人 弁理士 則 近 憲 佑
同 三俣弘文
第1図
第2図
第4図
第5図
第6図
第7図
第8図FIG. 1 is a file configuration diagram showing one embodiment of a data file device according to the present invention, FIG. 2 is a flowchart explaining the operation of the device shown in FIG. 1, and FIGS. 3 and 4 are diagrams for carrying out the present invention. Block diagram showing the outline of the device configuration, No. 5
The figure is a diagram for explaining the relationship between the number of blocks in an indexed sequential file. Fig. 6 is a flowchart of a conventional operation example shown for comparison with the device of the present invention, Fig. 7 is a diagram showing general sequential organization and relative organization file structures, and Fig. 8 is a general indexed sequential organization. FIG. 3 is a diagram showing the structure of a file. E... indexed sequential file, F, G... relative file, H, I, J... record content of each file. Agent Patent Attorney Nori Ken Yudo Hirofumi MitsumataFigure 1Figure 2Figure 4Figure 5Figure 6Figure 7Figure 8
Claims (1)
るレコードを複数個有し、このレコードのアクセスを、
レコードの物理的な位置を表わすレコード番号にて行う
第1および第2のファイルと、前記レコードを複数個有
し、このレコードのアクセスを各レコード毎に設定され
た論理的なレコード各称を用いて行う第3のファイルと
を備え、前記第1および第2のファイルの互いに対応す
るレコード間でデータの授受を行うために、前記第3の
ファイルの各レコードには、前記第1および第2のファ
イルのデータの授受を行う互いに対応するレコード番号
がそれぞれ格納され、第1のファイルの各レコードには
、そのレコード番号を格納した第3のファイルの対応す
るレコードのレコード名称と、データと、前記第2のフ
ァイルの対応するレコードのレコード番号とが格納され
、 第2のファイルの各レコードには、そのレコード番号を
格納した第3のファイルの対応するレコードのレコード
名称とデータとが格納され、これらの制御機能として、 第1のファイルの各レコードを、そのレコード番号によ
り順次取出す手段と、 この取出されたレコードに格納されているレコード番号
により前記第2のファイルの該当するレコードを取出す
手段と、 これら取出されたレコードにそれぞれ格納されたレコー
ド名称が一致するか判断し一致した場合はこれらレコー
ド間にてデータの授受を行わせる手段と、 前記取出された各レコードに格納されたレコード名称が
不一致の場合は、一方のレコードに格納されたレコード
名称を用いて第3のファイルをアクセスして対応するレ
コードを取出しそのレコードに格納されている第2のフ
ァイルのレコード番号を前記第1のファイルのレコード
に相手側レコード番号として記憶させる手段と を備えたデータファイル装置。[Claims] It has a plurality of records that are a group of data that are input/output units in a program, and access to these records is as follows:
It has first and second files that are accessed using record numbers that represent the physical locations of records, and a plurality of records, and access to these records is performed using logical record names set for each record. In order to exchange data between records corresponding to each other in the first and second files, each record of the third file includes a third file containing the first and second files. Record numbers corresponding to each other for sending and receiving data of the files are stored, and each record of the first file contains the record name and data of the corresponding record of the third file that stores the record number, The record number of the corresponding record of the second file is stored, and each record of the second file stores the record name and data of the corresponding record of the third file that stores the record number. , these control functions include means for sequentially retrieving each record of the first file according to its record number, and means for retrieving the corresponding record of the second file according to the record number stored in the retrieved record. a means for determining whether record names stored in each of the retrieved records match and, if they match, transmitting and receiving data between these records; and a record name stored in each of the retrieved records. If they do not match, the third file is accessed using the record name stored in one record, the corresponding record is retrieved, and the record number of the second file stored in that record is assigned to the first file. A data file device comprising means for storing a record number of the other party in a record of a file.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP61104807A JPS62262154A (en) | 1986-05-09 | 1986-05-09 | Data file device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP61104807A JPS62262154A (en) | 1986-05-09 | 1986-05-09 | Data file device |
Publications (1)
Publication Number | Publication Date |
---|---|
JPS62262154A true JPS62262154A (en) | 1987-11-14 |
Family
ID=14390694
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP61104807A Pending JPS62262154A (en) | 1986-05-09 | 1986-05-09 | Data file device |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPS62262154A (en) |
-
1986
- 1986-05-09 JP JP61104807A patent/JPS62262154A/en active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6289359B1 (en) | File managing method | |
JP4233564B2 (en) | Data processing apparatus, data processing program and recording medium | |
US6442553B1 (en) | Hash system and hash method for transforming records to be hashed | |
US6003025A (en) | Data transformer system for accessing database information | |
JP4314126B2 (en) | Concurrent execution control method and apparatus | |
JPS62262154A (en) | Data file device | |
JP2675958B2 (en) | Information retrieval computer system and method of operating storage device thereof | |
JP2874810B2 (en) | Key memory allocation method | |
JP2980610B2 (en) | Transaction management device | |
JP2560610B2 (en) | Data processing device | |
JP2874421B2 (en) | Sort work file space management method | |
JPH0456344B2 (en) | ||
JP2604787B2 (en) | Two-dimensional data storage method | |
JPS62287350A (en) | Index integrally updating system | |
JP2615046B2 (en) | Record addition processing method | |
JPH02259942A (en) | Data base generation management processing system | |
JP2679761B2 (en) | Data management system | |
JP2658097B2 (en) | Secondary file creation method | |
JPS61278932A (en) | Method of processing data addition | |
JPS6058492B2 (en) | Database search method | |
JPH02127742A (en) | Idle area retrieving system | |
JP3031944B2 (en) | Data processing device | |
JP2001022622A (en) | File managing method | |
JPH04182749A (en) | Data storage system for relational data base | |
JP2817911B2 (en) | Access control method for keyed files |