JPS595372A - File processing system - Google Patents

File processing system

Info

Publication number
JPS595372A
JPS595372A JP57114427A JP11442782A JPS595372A JP S595372 A JPS595372 A JP S595372A JP 57114427 A JP57114427 A JP 57114427A JP 11442782 A JP11442782 A JP 11442782A JP S595372 A JPS595372 A JP S595372A
Authority
JP
Japan
Prior art keywords
child
file
pointer
parent
key
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
Application number
JP57114427A
Other languages
Japanese (ja)
Inventor
Tadashi Yoshida
正 吉田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP57114427A priority Critical patent/JPS595372A/en
Publication of JPS595372A publication Critical patent/JPS595372A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

PURPOSE:To extract easily a desired value record group from plural record sets which differ in attribute and size by reading a master and a slave file on the basis of a key file. CONSTITUTION:The pointer area of the key file contains two kinds of pointers, i.e. master and slave pointers and starts at the final block of the file toward the BOE. The master pointers are linked mutually corresponding to the least significant indexes, one to one; each of them controls one master record respectively and also controls a chain of slave records with the same key. Each of the slave pointers control one slave record respectively. The slave pointers with the same key are chained and each chain is linked to the master pointer with the key.

Description

【発明の詳細な説明】[Detailed description of the invention]

〔発明の技術分野〕 本発明は、2個の順編成ファイルと、それらの順編成フ
ァイルの索引情報を収納するキー・ファイルとを設け、
キー・ファイルを用いて上記の2個の順編成ファイルを
アクセスするファイル処理システムに関するものである
・ 〔従来技術と問題点〕 端末レベルにおいて使用され
[Technical Field of the Invention] The present invention provides two sequential files and a key file that stores index information of these sequential files,
This relates to a file processing system that accesses the above two sequential files using a key file. [Prior art and problems] This system is used at the terminal level.

【いるファイルとしては順
編成ファイルや索引j−編成フアイルなどが用いられて
いる。索引順編成ファイルにおいては、1個のキーが1
個のレコードに対応しているが、1個のキーに複数のレ
コードを対応させることも可能である。これは関連する
複数個のレコードをポインタでチェインし、このレコー
ドのチェインを1個のキーに対応させることにより行わ
れる。しかし、チェインされるレコードの属性およ1個
の索引順編成ファイルの中に収容することは非常に困難
である0例えば、自動車販売店においては、顧客情報と
整備情報とを関連付け【所望の情報を累早く取得しよう
とい5要求があるが従来の索引順編成ファイルではこの
よ5な要求に応えることが出来ない。 〔発明の目的〕 本発明は、上記の考察に基づくものであって。 属性および大きさを異にする複数のレコードの集合の中
から関連する所望のレコード群を簡単に取得できるよう
にしたファイル処理システムを提供することを目的とし
ている。 〔発明の構成〕 そしてそのため0本発明のファイル処理システムは、複
数の親レコードを有する順編成ファイル構成の親ファイ
ル、複数の子レコードをもつammラフアイル構成子フ
ァイル、並びに親ポインタ。 子レコードをポイントする子ポインタ及び上記親レコー
ドの1デ一タ項目であるところのキーの値に基づいて対
応する親ポインタを選択するインデックス部を有し且つ
同一の親レコードに関連する子レコードをポイントスる
子ポインタがチェインを構成し上記親ポインタが親レコ
ードをポイントすると共に対応する子ポインタのチェイ
ンをポイントするように構成されたキー・ファイルを具
備し、親レコード及び子レコードの上記親ファ・「ルお
よび子ファイルからの読出し処理を、上記キー・ファイ
ルを参照して行うよう構成されたことを特徴とするもの
である。 〔発明の実施例〕 以下・本発明を図面を径間しつつ説明する。 m1図は本発明における鎖状ファイルの概念図。 第2図は親レコードと子レコードの具体例を示す図、第
3図はキー・ファイルのボリューム内の形式を示す図、
肌4図はキー・ファイルの形式を示す図、第5図はキー
・ファイルのインデックスの論理構造を示す図、第6図
はインデックス・ブロックの形式を示す図、第7図はイ
ンデックス・ブロックの関連図、駆8図はポインタの形
式を示す図、第9図は親ポインタと子ポインタの連鎖形
式を示す図、駆10図は未使用領域の概要を示す図。 第】1図は削除ポインタの管理方式を説明するための図
、第12図はアクセスの概要を示す図である− 第1図は本発明で使用される鎖状のファイルの概念図で
ある。第1図において、KFはキー・ファイル、MFは
親ファイル、SFは子ファイル。 FLBはファイル・ラベルをそれぞれ示している。 キー・ファイルKFは、ファイル・ラベルFLBやイン
デックス、親ポインタ、子ポインタなどを有している。 親ファイルMFは、順編成ファイルであり、複数の親レ
コードを有している・各親レコードは、親ポインタによ
ってポイントされている・子ファイルSFも順編成ファ
イルであり、複数の子レコードを有している。子レコー
ドは子ポインタによってポイントされている。第2図は
親レコードと子レコードの具体例を示す図である。 この例では親レコードは1wA客固有情報であり。 子レコードは各種の整備記録であり、キーは顧客NOで
ある。なお、矢印は連鎖(チェイン]を示している。 第3図はキー・ファイルKFのボリューム内における形
式を示している。ファイル領域は、ファイル・ラベルF
LB、キー・インデックス領域。 ポインタ領域および未使用領域から構成されている。フ
ァイル・ラベルFLBは、先頭256バイトを占有し、
ファイルの制御情報やキー・インデックスの管理を行う
、キー・インデックス領域は。 親ポインタをリンクするための数レベルのインデックス
を格納している。1個のインデックス・ブロックの大き
さは512バイトである。ポインタ領域は、親レコード
をポイントする親ポインタと。 子レコードをポイントする子ポインタとを格納する。未
使用領域は、キー・インデックス又はポインタの追加の
ためのリザーブ領域であり、この領域はファイル・ラベ
ルによりダイナミックに管理さえる0m4図は、キー・
ファイルのファイル形式を示し、第5図はインデックス
の論理構造を示している。 第6図はキー・インデックス・ブロックの形式を示す図
である・キー・インデックス領域は数レベルのインデッ
クス・ブロックから構成されている。IDはインデック
スの種別およびレベルを示す識別子である・Xマロ0マ
の識別子は、そのインデックスが最下位レベルのインデ
ックスであり。 親ポインタとl対lの対応していることを示し【いる、
Xマロ0マの識別子は、そのインデックスが最下位レベ
ルのインデックスではなく、下位レベルのインデックス
・ブロックとリンクしていることを示している。FPは
フロント・ポインタであり、この中には同一レベルのイ
ンデックス書ブロック内でキー値が次に大きいインデッ
クス・ブロックの相対レコード・アドレスが格納される
。BPはバック・ポインタであり、この中には同一レベ
ルのインデックス・ブロック内でキー値が次に小さいイ
ンデックス・ブロックの相対レコード・アドレスが格納
される・nnは、使用エントリ数。 即ちこのインデックス・ブロックに現在登録されている
エントリの数を示し【いる。インデックス・ブロックは
複数のエントリを有しているが、各り又は親ポインタを
ポイントしている一エントリは、キ一部とアドレス部と
から構成され【いる・このキ一部には、リンクしている
データ・レコードのキー、又はインデックス・ブロック
内の最大キー値が格納される。エントリのアドレス部に
は。 リンクしているインデックス・ブロックのアドレス又は
親ポインタのアドレスが格納される。 エントリが持っているアドレス情報は、インデックスの
種別により異なる構成をとる。ID=Xマ00マの場合
には、リンクする親ポインタの格納位置をもつ、従って
次の構成をとる。 X1nnnnLLマ nrLnnはブロック・アドレスを示し、11はブロッ
ク内のアドレスを示している。また、ID=XマOlマ
のインデックス・ブロックの場合には、リンクするイン
デックス・ブロックの格納位置を持つ・従って次の構成
をとる。 X1nnnn001 nnnrbはブロック・アドレスを示している0以上に
述べたインデックス・ブtffyりの相互関係の例は1
lE7図に示される。この例はインデックスのレベルが
4の場合を示している、 ポインタ領域は親ポインタと子ポインタの二種類のポイ
ンタから成り、ファイルの最終ブロックを起点としてB
 OE (Bgysnzny Of Extgnt)の
方に向って作成される。親ポインタは、最下位レベルの
インデックスとl対lの対応でリンクしており、それぞ
れは1個の親レコードを管理し。 また・同1じキーをもつ子レコードのチェインを管理す
る。第8図は親ポインタの構成を示している・アドレス
1は、リンクしている親ファイル内の親レコードのレコ
ード−アドレスを示しており、アドレス2はリンクして
いる子ポインタ群のうちチェインの先頭の子ポインタの
ポインタ・アドレスを示し、アドレス3はリンクしてい
る子ポインタ群のうちチェイン最稜の子ポインタのポイ
ンタ・アドレスを示している。なお、子ポインタとの連
鎖がないときには、アドレス2,3はXマoooooo
マとされる。 子ボンタも第8図に示されるような構成を有している。 子ポインタはそれぞれ1個の子レコードを管理するもの
である。また、同じキーを持つ子ポインタはチェインを
形成し、チェイン毎に同じキーをもつ親ポインタとリン
クされる。アドレス1はリンクしている子ファイル内の
子レコードのレコード・アドレスをポイントしており、
アドレス2は子ポインタのチェイン忙おいて次にリンク
している子ポインタのポインタ・アドレスを示している
。ただし、チェインの最終ポインタではXマooooo
oマにセットされる。アドレス3は、子ポインタのチェ
インにおいて一つ前にリンクしている子ポインタのポイ
ント・アドレスを示している。ただし、チェインの先頭
ポインタではXマロ00000マにセットされる。第9
図は親ポインタと子ポインタの連鎖形式を示している。 第10図は未使用領域の概要を示す図である。 キー・インデックス領域はBOEからEO′FJ(E+
bd Qf gxtgnt)へ向って拡張され、ポイン
タ領域はEOEからBOEに向って拡張される。未使用
領域は、キー・インテラクス領声とポインタ領域の中間
にあり、インデックス・ブロック又はポインタを追加す
る予備領域である。この領域は。 インデックス・ブロック又はポインタの追加によリダイ
ナミックに変化していく、未使用領域は。 ファイル・ラベル中の未使用先頭ブロック・アドレスと
未使用先頭ポインタ・アドレスにより管理される。 第11図は削除ポインタの管理形式を示すものである。 親レコードが削除された場合には、該当する親ポインタ
をそのポインタ内のアドレス2およびアドレス3により
、削除親ポインタ用のチェインにつなぐ、また、子レコ
ードが削除された場合(親レコードが削除された場合に
はそれにリンクしている子レコードも必然的に削除され
る)には、該当する子ポインタをそのポインタ内のアド
レス2およびアドレス3により、削除子ポインタ用のチ
ェインにつなぐ、このように、親ポインタおよび子ポイ
ンタの削除ポインタは、それぞれ別々のチェインにより
管理されている。従って、ポインタ領域で一度親ポイン
タとなったポインタは。 削除後に使用されるときも必ず親ポインタであり・子ポ
インタについても同様である。削除親ポインタのチェイ
ンは、ファイル・ラベルの削除親ポインタ先頭アドレ、
A34および削除親ポインタ末尾アドレスF’ 35に
より管理される。また、削除子ポインタは、ファイル・
ラベルの削除子ポインタ先頭アドレス36および削除子
ポインタ末尾アドレスF” 37により管理される。ポ
インタ内のアドレスlは、一度登録された後は使用/未
使用(削除)にかかわらず更新されることはない。即ち
。 削除ポインタを管理することが、そのま〜親ファイル又
は子ファイルのレコードの削除/再使用を管理すること
を意味する。 第12図はアクセスの概要を示すものである。 親レコードをREADするためには、先ずインデックス
および親ポインタを読み、しかる後に親ポインタに基づ
いて親レコードを読取る。子レコードなREADするた
めには、先ず子ポインタを読取り、しかる後に子ポイン
タに基づき子レコードを読取る・以下・同様な処理が繰
返えされる。 〔発明の効果〕 以上の説明から明らかなように1本発明によれば。 (イ) データ・ファイルは通常の順編成ファイルを用
いれば良く、従来の索引順編成ファイルのようにデータ
・ファイル中にインデックス部を設けたり、データ・レ
コード中にポインタ情報を付加する等の格納形式に関す
る変更が全く必要ない、従って、データ・ファイルを本
発明のアクセス方式でアクセスする一万で、単なる順編
成ファイルとしてアクセスすることも可能である・ ←) 1個のキー・ファイルで、親ファイルと子ファイ
ルを連鎖してアクセスすることが出来る。 fj  キー・アクセスのため情報を全てキー・ファイ
ルが持っているので、複数のキー・ファイルを用いて同
一の親ファイルおよび子ファイルをアクセスすることが
出来る・ 等の作用効果を奏することが出来る・
[The files used include sequential organization files and index J-organization files. In indexed sequential files, one key is one
However, it is also possible to have one key correspond to multiple records. This is done by chaining a plurality of related records using pointers and associating this chain of records with one key. However, it is very difficult to store the attributes of chained records in a single indexed sequential file. There are 5 requests to obtain 5 files as quickly as possible, but conventional indexed sequential files cannot meet these 5 requests. [Object of the Invention] The present invention is based on the above consideration. It is an object of the present invention to provide a file processing system that makes it possible to easily obtain a desired group of related records from a set of records having different attributes and sizes. [Structure of the Invention] Therefore, the file processing system of the present invention includes a parent file having a sequential file structure having a plurality of parent records, an amm rough file constituent child file having a plurality of child records, and a parent pointer. It has a child pointer that points to a child record and an index section that selects the corresponding parent pointer based on the value of a key which is one data item of the parent record, and which selects child records related to the same parent record. a key file configured such that the child pointers pointing to the parent record form a chain and the parent pointer points to a parent record and points to a corresponding chain of child pointers;・This invention is characterized by being configured such that reading processing from the key file and the child file is performed with reference to the key file. Figure m1 is a conceptual diagram of a chain file in the present invention. Figure 2 is a diagram showing a specific example of a parent record and child record, Figure 3 is a diagram showing the format of a key file in a volume,
Figure 4 shows the format of the key file, Figure 5 shows the logical structure of the index of the key file, Figure 6 shows the format of the index block, and Figure 7 shows the format of the index block. In the related diagrams, Figure 8 shows the format of a pointer, Figure 9 shows the chain format of a parent pointer and child pointer, and Figure 10 shows an outline of an unused area. FIG. 1 is a diagram for explaining a deletion pointer management system, and FIG. 12 is a diagram showing an overview of access. FIG. 1 is a conceptual diagram of a chained file used in the present invention. In Figure 1, KF is a key file, MF is a parent file, and SF is a child file. FLB indicates a file label. The key file KF has a file label FLB, an index, a parent pointer, a child pointer, etc. The parent file MF is a sequential file and has multiple parent records. Each parent record is pointed to by a parent pointer. The child file SF is also a sequential file and has multiple child records. are doing. Child records are pointed to by child pointers. FIG. 2 is a diagram showing a specific example of a parent record and a child record. In this example, the parent record is 1wA customer specific information. The child records are various maintenance records, and the key is the customer number. Note that the arrow indicates a chain. Figure 3 shows the format of the key file KF within the volume. The file area is defined by the file label F.
LB, key index area. It consists of a pointer area and an unused area. The file label FLB occupies the first 256 bytes,
The key index area manages file control information and key indexes. Contains several levels of indexes for linking parent pointers. The size of one index block is 512 bytes. The pointer area is the parent pointer that points to the parent record. A child pointer pointing to a child record is stored. The unused area is reserved for adding a key index or pointer, and this area is dynamically managed using file labels.
The file format of the file is shown, and FIG. 5 shows the logical structure of the index. FIG. 6 is a diagram showing the format of a key index block. The key index area is composed of several levels of index blocks. The ID is an identifier indicating the type and level of the index. - An identifier of Xmalo and 0ma indicates that the index is the lowest level index. Indicates that there is an l-to-l correspondence with the parent pointer.
The Xmalo0ma identifier indicates that the index is not linked to the lowest level index, but to a lower level index block. FP is a front pointer, which stores the relative record address of the index block with the next largest key value among the index blocks at the same level. BP is a back pointer, which stores the relative record address of the index block with the next smallest key value within the index blocks at the same level. nn is the number of entries used. That is, it shows the number of entries currently registered in this index block. The index block has multiple entries, and each entry pointing to a parent pointer consists of a key part and an address part. The key of the data record in the index block or the largest key value in the index block is stored. In the address part of the entry. The address of the linked index block or the address of the parent pointer is stored. Address information held by an entry has a different structure depending on the type of index. If ID=Xma00ma, it has the storage location of the parent pointer to be linked, and therefore has the following configuration. X1nnnnLLmannrLnn indicates a block address, and 11 indicates an address within the block. Furthermore, in the case of an index block with ID=XmaOlma, it has the storage location of the index block to be linked, and thus has the following configuration. X1nnnn001 nnnrb indicates the block address 0 An example of the correlation between the index blocks tffy described above is 1
Shown in Figure 1E7. This example shows the case where the index level is 4. The pointer area consists of two types of pointers, parent pointers and child pointers, and B
Created towards OE (Bgysnzny Of Extgnt). The parent pointer is linked to the lowest level index in an l-to-l correspondence, and each manages one parent record. Also manages chains of child records with the same key. Figure 8 shows the structure of the parent pointer.Address 1 shows the record address of the parent record in the linked parent file, and address 2 shows the record address of the chain of linked child pointers. The pointer address of the first child pointer is shown, and address 3 shows the pointer address of the child pointer at the edge of the chain among the group of linked child pointers. Note that when there is no chain with child pointers, addresses 2 and 3 are
It is said to be a ma. The secondary bonnet also has a configuration as shown in FIG. Each child pointer manages one child record. Further, child pointers having the same key form a chain, and each chain is linked to a parent pointer having the same key. Address 1 points to the record address of the child record in the linked child file,
Address 2 indicates the pointer address of the next linked child pointer in the child pointer chain. However, at the final pointer of the chain,
It is set to o. Address 3 indicates the point address of the child pointer linked immediately before in the chain of child pointers. However, the start pointer of the chain is set to X00000. 9th
The figure shows a chain format of parent pointers and child pointers. FIG. 10 is a diagram showing an outline of the unused area. The key index area is from BOE to EO'FJ (E+
bd Qf gxtgnt), and the pointer area is extended from EOE to BOE. The unused area is located between the key interaction area and the pointer area, and is a reserved area for adding an index block or a pointer. This area is. Unused space changes dynamically as index blocks or pointers are added. It is managed by the unused first block address and unused first pointer address in the file label. FIG. 11 shows a deletion pointer management format. When a parent record is deleted, the corresponding parent pointer is connected to the chain for deleted parent pointers by addresses 2 and 3 in that pointer, and when a child record is deleted (the parent record is deleted) (If the child record linked to it is also deleted), connect the corresponding child pointer to the chain for deleted child pointers using addresses 2 and 3 in the pointer, like this: , parent pointer, and child pointer deletion pointers are managed by separate chains. Therefore, a pointer that once became a parent pointer in the pointer area. When used after deletion, it is always the parent pointer; the same applies to child pointers. The deletion parent pointer chain is the deletion parent pointer start address of the file label,
A34 and the deletion parent pointer end address F'35. Additionally, the delete child pointer is
It is managed by the deletion child pointer start address 36 and the deletion child pointer end address F" 37 of the label. Once the address l in the pointer is registered, it cannot be updated regardless of whether it is used or unused (deleted). In other words, managing the deletion pointer means managing the deletion/reuse of records in the parent file or child file. Figure 12 shows an overview of access. Parent record To read a child record, first read the index and parent pointer, then read the parent record based on the parent pointer.To read a child record, first read the child pointer, then read the child record based on the child pointer. The following similar processing is repeated. [Effects of the Invention] As is clear from the above explanation, according to the present invention, (a) A normal sequential file may be used as the data file. Unlike conventional indexed sequential files, there is no need to change the storage format such as providing an index section in the data file or adding pointer information to the data record. It is also possible to access it as a simple sequential file by accessing it using the following access method. ←) With one key file, the parent file and child files can be accessed in a chain. fj key・Because the key file has all the information for access, it is possible to access the same parent file and child file using multiple key files.・

【図面の簡単な説明】[Brief explanation of the drawing]

第1図は本発明における鎖状ファイルの概念図。 第2図は親レコードと子レコードの具体例を示す図、第
3図はキー・ファイルのボリューム内の形式を示す図、
第4図はキー・ファイルの形式を示す図1M5図はキー
・ファイルのインデックスの論理構造を示す図、第6図
はインデックス・ブロックの形式を示す図、第7図はイ
ンデックス・ブロックの関連図、第8図はポインタの形
式を示す図、第9図は親ポインタと子ポインタの連鎖形
式を示す図、第10図は未使用領域の概要を示す図。 第11図は削除ポインタの管理方式を説明するための図
、第12図はアクセスの概要を示す図である・ KF・・・キー・ファイル、MP・・・親ファイル、S
F・・・子ファイル、FLB・・・ファイル・ラベル・
特許出願人  富士通株式会社 代理人弁理士  京 谷 四 部 ヤ1図 才2図 肯 8 図 ケ ′? 図 ヤ10 図 守12図
FIG. 1 is a conceptual diagram of a chain file in the present invention. Figure 2 is a diagram showing a specific example of a parent record and child record, Figure 3 is a diagram showing the format of a key file in a volume,
Figure 4 shows the format of the key file. Figure 1M5 shows the logical structure of the key file index. Figure 6 shows the format of the index block. Figure 7 shows the relationship between the index blocks. , FIG. 8 is a diagram showing the format of a pointer, FIG. 9 is a diagram showing a chain format of a parent pointer and child pointer, and FIG. 10 is a diagram showing an outline of an unused area. Figure 11 is a diagram for explaining the deletion pointer management method, and Figure 12 is a diagram showing an overview of access.KF...Key file, MP...Parent file, S
F...child file, FLB...file label
Patent Applicant Fujitsu Ltd. Representative Patent Attorney Kyotani Yobu Ya 1 Zu Sai 2 Zu Ken 8 Zu Ke'? Diagram 10 Diagram 12

Claims (1)

【特許請求の範囲】 複数の親レコードを有する順編成ファイル構成の親ファ
イル、複数の子レコードをもつ順編成ファイル構成の子
ファイル、並びに親ポインタ、子レコードをポイントす
る子ポインタ及び上記親レコードの1デ一タ項目である
ところのキーの値に基づいて対応する親ポインタを選択
するインデックス部を有し且つ同一の親レコードに関連
する子レコードをポイントする子ポインタがチェインを
構成し上記親ポインタが親レコードをポイントすると共
に対応する子ポインタのチェインをポイントするように
構成されたキー・ファイルを具備し。 親レコード及び子レコードの上記親ファイルおよび子フ
ァイルからの読出し処理を、上記キー・フとするファイ
ル処理システム・
[Scope of Claims] A parent file having a sequential file structure having a plurality of parent records, a child file having a sequential file structure having a plurality of child records, a parent pointer, a child pointer pointing to a child record, and a child pointer pointing to a child record, and a child file having a sequential file structure having a plurality of child records. Child pointers that have an index section that selects a corresponding parent pointer based on the value of a key, which is one data item, and that point to child records related to the same parent record form a chain, and the parent pointer a key file configured to point to a parent record and point to a corresponding chain of child pointers. A file processing system that uses the above key file to read parent records and child records from the above parent file and child files.
JP57114427A 1982-06-30 1982-06-30 File processing system Pending JPS595372A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP57114427A JPS595372A (en) 1982-06-30 1982-06-30 File processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP57114427A JPS595372A (en) 1982-06-30 1982-06-30 File processing system

Publications (1)

Publication Number Publication Date
JPS595372A true JPS595372A (en) 1984-01-12

Family

ID=14637440

Family Applications (1)

Application Number Title Priority Date Filing Date
JP57114427A Pending JPS595372A (en) 1982-06-30 1982-06-30 File processing system

Country Status (1)

Country Link
JP (1) JPS595372A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63261461A (en) * 1987-04-17 1988-10-28 Sanyo Electric Co Ltd Family relational data processing system in personal data processing
JPH02112067A (en) * 1988-10-21 1990-04-24 Nec Corp System for checking matching between tables
JPH04328680A (en) * 1991-04-26 1992-11-17 Tsubakimoto Chain Co Data storing method

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS52106641A (en) * 1976-03-05 1977-09-07 Hitachi Ltd Data record storage for high-speed sequential access

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS52106641A (en) * 1976-03-05 1977-09-07 Hitachi Ltd Data record storage for high-speed sequential access

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63261461A (en) * 1987-04-17 1988-10-28 Sanyo Electric Co Ltd Family relational data processing system in personal data processing
JPH02112067A (en) * 1988-10-21 1990-04-24 Nec Corp System for checking matching between tables
JPH04328680A (en) * 1991-04-26 1992-11-17 Tsubakimoto Chain Co Data storing method

Similar Documents

Publication Publication Date Title
JP4250190B2 (en) Efficient storage of objects in the file system
US5752243A (en) Computer method and storage structure for storing and accessing multidimensional data
EP0733238B1 (en) Extended attributes file system
US5274807A (en) Method for reducing magnetic storage volume for computer disk image backup
US8099421B2 (en) File system, and method for storing and searching for file by the same
JP3926857B2 (en) Metadata structure and method of handling the same
GB2207264A (en) Data processing system
JPS6115243A (en) Self-diffusion memory file
WO1996041283A1 (en) System and method for superimposing attributes on hierarchically organized file systems
JPH03191467A (en) Method of discriminating document at- tribute
US7310719B2 (en) Memory management tile optimization
CN111142780A (en) Large file storage file system and large file processing method
US6697817B2 (en) Variable-length database apparatus and method for accessing the same
JPS6115246A (en) Compression of data for memory
JPS595372A (en) File processing system
KR900018841A (en) Method and system for accessing byte range in file in distributed data processing system
JP2874810B2 (en) Key memory allocation method
JPS62287350A (en) Index integrally updating system
CN118567577A (en) Data access method and device based on distributed block storage and electronic equipment
JPH0557624B2 (en)
JPS60129852A (en) File managing method
JP2618029B2 (en) How to divide an indexed file
CN113741787A (en) Data storage method, device, equipment and medium
Bi A User Configurable B-tree Implementation as a Utility
JPS63239540A (en) Data management system in memory medium