JPS5994142A - インデツクスの一括メンテナンス制御方式 - Google Patents
インデツクスの一括メンテナンス制御方式Info
- Publication number
- JPS5994142A JPS5994142A JP57203420A JP20342082A JPS5994142A JP S5994142 A JPS5994142 A JP S5994142A JP 57203420 A JP57203420 A JP 57203420A JP 20342082 A JP20342082 A JP 20342082A JP S5994142 A JPS5994142 A JP S5994142A
- Authority
- JP
- Japan
- Prior art keywords
- index
- key
- logical
- file
- indexes
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up
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
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
（ａ）発明の技術分野 ・
本発明は、電子計算機において論理キーを基にして物理
アドレスを求めるインデックス処理装置に関し、インデ
ックスのメンテナンス処理の簡便化を実現するものであ
る。
アドレスを求めるインデックス処理装置に関し、インデ
ックスのメンテナンス処理の簡便化を実現するものであ
る。
（ｂｌ従来技術とその問題点
第１図は従来のインデックス処理装置を示す図で、物理
ファイル１中に同じフォーマントのデータがレコード２
・・・に記憶されている。例えば販売ファイルであると
すると、レコード２・・・は、それぞれ商品コードを記
憶するフィールド２１、顧客名を記憶するフィールド２
２および数量を記憶するフィールド２３・・・から構成
されている。このような物理ファイル１に記憶されてい
るデータの利用を効率化できるように、商品コードが成
る一定の条件を満たしたもの同士を抽出して、それを商
品コード順に整理した状態で、仮想的な論理ファイル３
１．３２・・・が作成される。ところがこのような物理
ファイル１と各論理ファイル３１．３２・・・とを対応
づけるために、インデックス４１．４２・・・を作成し
て介在させ、所要のインデックスを通して物理ファイル
ｌをアクセスすることにより、所要の論理ファイルを読
み出す。この方式は、１つのデータフィールドに対して
全レコードに対応する１個のインデックスを持つ方式の
ように、キー順の検索において不必要なページまで読ん
でしまい、検索時間が遅くなるといった問題が解消され
、所要のデータを高速で得ることができる。ところがこ
の場合、各インデックス４１．４２・・・は商品コード
をキー（識別子）としているものとすると、各インデッ
クス４１．４２・・・において同一の商品コードがダブ
った状態でキーとして使用されていることがある。その
ような場合、物理ファイル１中の成る１つの商品コード
が変更されたり、追加されたりすると、その商品コード
が各インデックス４１．４２・・・に共通している場合
は、各インデックス４１．４２・・・毎にキーとなる商
品コート′の変更や追加を行なわなければならない。そ
のために、商品コードの変更や追加などのようなメンテ
ナンス処理に時間を要し、非能率的である。また各論理
ファイルごとにインデックスを要するので、インデック
スの占有ページが増大する欠点がある。
ファイル１中に同じフォーマントのデータがレコード２
・・・に記憶されている。例えば販売ファイルであると
すると、レコード２・・・は、それぞれ商品コードを記
憶するフィールド２１、顧客名を記憶するフィールド２
２および数量を記憶するフィールド２３・・・から構成
されている。このような物理ファイル１に記憶されてい
るデータの利用を効率化できるように、商品コードが成
る一定の条件を満たしたもの同士を抽出して、それを商
品コード順に整理した状態で、仮想的な論理ファイル３
１．３２・・・が作成される。ところがこのような物理
ファイル１と各論理ファイル３１．３２・・・とを対応
づけるために、インデックス４１．４２・・・を作成し
て介在させ、所要のインデックスを通して物理ファイル
ｌをアクセスすることにより、所要の論理ファイルを読
み出す。この方式は、１つのデータフィールドに対して
全レコードに対応する１個のインデックスを持つ方式の
ように、キー順の検索において不必要なページまで読ん
でしまい、検索時間が遅くなるといった問題が解消され
、所要のデータを高速で得ることができる。ところがこ
の場合、各インデックス４１．４２・・・は商品コード
をキー（識別子）としているものとすると、各インデッ
クス４１．４２・・・において同一の商品コードがダブ
った状態でキーとして使用されていることがある。その
ような場合、物理ファイル１中の成る１つの商品コード
が変更されたり、追加されたりすると、その商品コード
が各インデックス４１．４２・・・に共通している場合
は、各インデックス４１．４２・・・毎にキーとなる商
品コート′の変更や追加を行なわなければならない。そ
のために、商品コードの変更や追加などのようなメンテ
ナンス処理に時間を要し、非能率的である。また各論理
ファイルごとにインデックスを要するので、インデック
スの占有ページが増大する欠点がある。
（ｃ１発明の目的
本発明は、従来のインデックスのメンテナンス処理にお
けるこのような問題を解消し、高速でキー変更できるよ
うにすることを目的とする。
けるこのような問題を解消し、高速でキー変更できるよ
うにすることを目的とする。
ｌｄ１発明の構成
この目的を達成するために本発明は、論理キーから物理
アドレスを求めるインデックス処理装置において、複数
のインデックスを共通に作成すると共に、各インデック
スにつき、使用される論理ファイル対応付けを作成して
おき、物理ファイル中のキーを変更する際は、該キーに
対応する論理ファイル対応付は情報を変更するような構
成を採っている。
アドレスを求めるインデックス処理装置において、複数
のインデックスを共通に作成すると共に、各インデック
スにつき、使用される論理ファイル対応付けを作成して
おき、物理ファイル中のキーを変更する際は、該キーに
対応する論理ファイル対応付は情報を変更するような構
成を採っている。
（ｅ１発明の実施例
次にこの発明によるインデックスの一括メンテナンス制
御方式の実施例を説明する。第２図はインデックスのメ
ンテナンス処理の効率化を可能にするためにインデック
スが共通化（マージ）されたインデックス処理装置を示
す図である。各論理ファイルＬＦ１、ＬＦ２・・・のう
ちインデックスのキーとなる商品コードは、例えばαは
論理ＬＦ１ とＬＦ２に共通して存在する。このよう
なαの場合、論理ＬＰ＋ に対応したビット位置と論理
ＬＦ２に対応したビット位置とに「１」をたて、βとγ
に対しては論理ＬＰ＋ に対応したビット位置に「１」
をたて、δに対しては、論理ＬＦ２に対応したビット位
置に「１」をたてる。このようなインデックスで８命理
フアイルＬＰ＋ （またはＬＦ２ ）を読み出すとき
は、その論理ファイルに対応したビット位置が「１」で
あるインデックスのキーを用いて物理ファイル１をアク
セスすればよい。
御方式の実施例を説明する。第２図はインデックスのメ
ンテナンス処理の効率化を可能にするためにインデック
スが共通化（マージ）されたインデックス処理装置を示
す図である。各論理ファイルＬＦ１、ＬＦ２・・・のう
ちインデックスのキーとなる商品コードは、例えばαは
論理ＬＦ１ とＬＦ２に共通して存在する。このよう
なαの場合、論理ＬＰ＋ に対応したビット位置と論理
ＬＦ２に対応したビット位置とに「１」をたて、βとγ
に対しては論理ＬＰ＋ に対応したビット位置に「１」
をたて、δに対しては、論理ＬＦ２に対応したビット位
置に「１」をたてる。このようなインデックスで８命理
フアイルＬＰ＋ （またはＬＦ２ ）を読み出すとき
は、その論理ファイルに対応したビット位置が「１」で
あるインデックスのキーを用いて物理ファイル１をアク
セスすればよい。
このように各インデックスの内キーの共通する部分は、
まとめて共通のインデックスを作成しておけば、キーの
変更、追加などの際のインデックスのメンテナンス処理
は、インデックス対応したビット位置のみを変更、追加
すればよいので、従来のように個々の論理ファイルに対
応したインデックスそれぞれについて変更、追加する必
要はなく、処理動作が効率化される。
まとめて共通のインデックスを作成しておけば、キーの
変更、追加などの際のインデックスのメンテナンス処理
は、インデックス対応したビット位置のみを変更、追加
すればよいので、従来のように個々の論理ファイルに対
応したインデックスそれぞれについて変更、追加する必
要はなく、処理動作が効率化される。
第３図はこのような共通インデックスを持つ場合のメン
テナンス制御装置のブロック図で、入力部５から入力し
たインデックスの更新データは、メンテナンス制御装置
６の更新フィールド認識部６１に入力し、該更新フィー
ルド認識部６１において、更新後のレコードを更新前の
レコードと対比させ５− ることにより、どのフィールドが更新されているかをｌ
ｉ＆する。その結果、レコードの内インデックスキーと
なる商品コードを含んでいるフィールドは変更されず、
インデックスキー以外の顧客名や数量などのフィールド
が変更されている場合は、インデックスは更新を要しな
いので、更新などのメンテナンスは実行されない。
テナンス制御装置のブロック図で、入力部５から入力し
たインデックスの更新データは、メンテナンス制御装置
６の更新フィールド認識部６１に入力し、該更新フィー
ルド認識部６１において、更新後のレコードを更新前の
レコードと対比させ５− ることにより、どのフィールドが更新されているかをｌ
ｉ＆する。その結果、レコードの内インデックスキーと
なる商品コードを含んでいるフィールドは変更されず、
インデックスキー以外の顧客名や数量などのフィールド
が変更されている場合は、インデックスは更新を要しな
いので、更新などのメンテナンスは実行されない。
インデックスキーが設けられているフィールドが変更さ
れているときは、条件比較部６２に制御が移される。こ
の条件比較部６２では、更新前のフィールド値および更
新後のフィールド値が対比され、その結果が次の削除・
挿入スケジュール部６３に移行する。いま第２図のよう
に、インデックスのキーαやα゛は、インデックスを論
理ファイルＬＰ＋とＬＦ２ とで使用される条件を満た
しており、他はこの条件を満たしていないものとする。
れているときは、条件比較部６２に制御が移される。こ
の条件比較部６２では、更新前のフィールド値および更
新後のフィールド値が対比され、その結果が次の削除・
挿入スケジュール部６３に移行する。いま第２図のよう
に、インデックスのキーαやα゛は、インデックスを論
理ファイルＬＰ＋とＬＦ２ とで使用される条件を満た
しており、他はこの条件を満たしていないものとする。
そしてキーαが、共通化使用されないβに変更された場
合と、共通化使用されるα゛に変更された場合を想定す
る。前者の場合は、インデックスの表からはオミソトす
る必要があり、後者の場合は共通イン６− デ・７クスとして登録する必要がある。また変更前の不
要になったキーαは削除する必要がある。このように更
新前のフィールド値および更新後のフィールド値につい
て、共通使用されるインデックスとしてセレクトすべき
かオミットすべきかが認識されると、次の削除・挿入ス
ケジュール部６３において、表１に従って削除・挿入処
理のスケジューリングが行なわれる。
合と、共通化使用されるα゛に変更された場合を想定す
る。前者の場合は、インデックスの表からはオミソトす
る必要があり、後者の場合は共通イン６− デ・７クスとして登録する必要がある。また変更前の不
要になったキーαは削除する必要がある。このように更
新前のフィールド値および更新後のフィールド値につい
て、共通使用されるインデックスとしてセレクトすべき
かオミットすべきかが認識されると、次の削除・挿入ス
ケジュール部６３において、表１に従って削除・挿入処
理のスケジューリングが行なわれる。
表１
即ちフィールド値が、更新前も更新後もセレクト／オミ
ソト条件に合致しておれば、更新前のインデックスレコ
ードをインデックスから削除すると共に、更新後のイン
デックススペースを挿入する。前記の例であれば、αを
削除してα′をその順序にあった位置へ、ＬＦｉｄビッ
トと共に挿入する。
ソト条件に合致しておれば、更新前のインデックスレコ
ードをインデックスから削除すると共に、更新後のイン
デックススペースを挿入する。前記の例であれば、αを
削除してα′をその順序にあった位置へ、ＬＦｉｄビッ
トと共に挿入する。
更新前のフィールド値はセレクト／オミソト条件に合致
しているが、更新後は合致しない場合は、更新前のイン
デックスレコードの削除を行なうのみで、挿入は行なわ
れない。即ち、キーαがβに変更されたような場合は、
キーαを含むレコード。
しているが、更新後は合致しない場合は、更新前のイン
デックスレコードの削除を行なうのみで、挿入は行なわ
れない。即ち、キーαがβに変更されたような場合は、
キーαを含むレコード。
の削除のみが行なわれる。
更新前はセレクト／オｔ７ト条件に合致しないが更新後
のキーが合致する場合、例えば前記例のキーβやγがα
またはα°などに変更された場合は、変更後のキーαや
α゛を含むインデックスレコードの挿入が行なわれる。
のキーが合致する場合、例えば前記例のキーβやγがα
またはα°などに変更された場合は、変更後のキーαや
α゛を含むインデックスレコードの挿入が行なわれる。
更新前も更新後もセレクト／オミソト条件に合致してい
ないときは、削除処理も挿入処理も行なう必要がない。
ないときは、削除処理も挿入処理も行なう必要がない。
このようにしてインデックスレコードの削除処理を要す
る場合は、削除処理部７１へ制御が移され、共通インデ
ックスからインデックスレコードが削除される。挿入を
要する場合は、リーフレコード作成部６４で、新なキー
を含んだリーフレコードが作成され、そのリーフレコー
ドを含んだ状態で、インデックス挿入処理部７２へ制御
が移され、共通インデックスに変更後のインデックスレ
コードが挿入される。
る場合は、削除処理部７１へ制御が移され、共通インデ
ックスからインデックスレコードが削除される。挿入を
要する場合は、リーフレコード作成部６４で、新なキー
を含んだリーフレコードが作成され、そのリーフレコー
ドを含んだ状態で、インデックス挿入処理部７２へ制御
が移され、共通インデックスに変更後のインデックスレ
コードが挿入される。
第４図は以上の制御部における削除／挿入スケジュール
部と、リーフレコード作成部をブロック図で示したもの
である。この図において、■の対称インデックススペー
ス認識部では、更新フィールドに対応するインデックス
スペース（その中にマージされたインデックスが格納さ
れている）が認識される。そして■の削除／挿入ストラ
テジー決定部では、表１に従って削除／挿入のストラテ
ジーが決定される。その結果削除の必要がある場合は、
当該インデックス・リーフレコードを読み込み、リーフ
レコード作成モジュールの削除ルーチンを呼び出し、削
除前処理が行なわれる。その後■で示されるように、イ
ンデックスリーフレコードの論理ファイル識別子より当
該論理ファイルの識別子を削除する。総ての識別子が削
除された９− ならば、当該インデックスリーフレコードも削除される
。
部と、リーフレコード作成部をブロック図で示したもの
である。この図において、■の対称インデックススペー
ス認識部では、更新フィールドに対応するインデックス
スペース（その中にマージされたインデックスが格納さ
れている）が認識される。そして■の削除／挿入ストラ
テジー決定部では、表１に従って削除／挿入のストラテ
ジーが決定される。その結果削除の必要がある場合は、
当該インデックス・リーフレコードを読み込み、リーフ
レコード作成モジュールの削除ルーチンを呼び出し、削
除前処理が行なわれる。その後■で示されるように、イ
ンデックスリーフレコードの論理ファイル識別子より当
該論理ファイルの識別子を削除する。総ての識別子が削
除された９− ならば、当該インデックスリーフレコードも削除される
。
削除／挿入ストラテジーの結果、挿入処理を要するとき
は、■の挿入前処理部で、当該インデックスリーフレコ
ードを読み込み（無い場合は、初期状態のインデックス
レコードを作成して）リーフレコード作成モジュールの
挿入ルーチンを呼び出す。その後■のリーフレコードへ
の挿入処理部で、与えられたインデックスリーフレコー
ドに当該論理ファイルの識別子が付加される。
は、■の挿入前処理部で、当該インデックスリーフレコ
ードを読み込み（無い場合は、初期状態のインデックス
レコードを作成して）リーフレコード作成モジュールの
挿入ルーチンを呼び出す。その後■のリーフレコードへ
の挿入処理部で、与えられたインデックスリーフレコー
ドに当該論理ファイルの識別子が付加される。
こうして削除／挿入スケジュールが完了すると、■で示
されるようにインデックスアクセスルーチン（インデッ
クス削除／挿入）が呼び出されて、インデックスの削除
／挿入が実行される。
されるようにインデックスアクセスルーチン（インデッ
クス削除／挿入）が呼び出されて、インデックスの削除
／挿入が実行される。
前記のようなインデックスの一括処理を可能にするため
の共通化（マージ）処理は、次のようにシステムの判定
基準に従って行なわれる。即ち各論理ファイルで作られ
るインデックスに対し、物理ファイルのフィールドの使
われ方およびインデックスから得られる統計値に基づい
て、システム１０− により共通化（マージ）処理の制御が行なわれる。
の共通化（マージ）処理は、次のようにシステムの判定
基準に従って行なわれる。即ち各論理ファイルで作られ
るインデックスに対し、物理ファイルのフィールドの使
われ方およびインデックスから得られる統計値に基づい
て、システム１０− により共通化（マージ）処理の制御が行なわれる。
この判定処理動作を第５図に基づいて説明する。
まず物理ファイル即ちＰＦを創成するときに、ＰＦの構
成フィールドの各々が検索主体のフィールド／更新主体
のフィールドのどちらかを宣言させ、更新主体フィール
ドのみをインデックスの共通化の対象とする。
成フィールドの各々が検索主体のフィールド／更新主体
のフィールドのどちらかを宣言させ、更新主体フィール
ドのみをインデックスの共通化の対象とする。
論理ファイル即ちＬＰを創成時に、キーフィールドが検
索主体のフィールドであるときは常に共通化をせず、更
新主体のフィールドのときのみ共通化の対象とする。
索主体のフィールドであるときは常に共通化をせず、更
新主体のフィールドのときのみ共通化の対象とする。
更新主体のフィールドでマージをしないと指定したとき
は、論理ファイル創成部でＬＰを創成した後、ユーティ
リティプログラムを流し、後述の条件式に基づいてイン
デックスのマージ判定部でマージの可能性をチェックす
る。
は、論理ファイル創成部でＬＰを創成した後、ユーティ
リティプログラムを流し、後述の条件式に基づいてイン
デックスのマージ判定部でマージの可能性をチェックす
る。
いま、インデックスＩ＋ 、Ｉ２のマージ条件を検討す
る。インデックスＩ＋ 、Ｉ２のキーの範囲をＲ＋ 、
Ｒ２とし、キーの重なり（共通）部分の範囲をＲとする
。またインデックスＩ＋、Ｉｉのインデックスレコード
の数をＮｌ 、Ｎ２ とすると、ただし、ηＣは、マー
ジによる順スキャンの速度低下を表す定数で、最悪ケー
スとして２倍まで速度低下が許されるとすると、ηＣ＝
２である。
る。インデックスＩ＋ 、Ｉ２のキーの範囲をＲ＋ 、
Ｒ２とし、キーの重なり（共通）部分の範囲をＲとする
。またインデックスＩ＋、Ｉｉのインデックスレコード
の数をＮｌ 、Ｎ２ とすると、ただし、ηＣは、マー
ジによる順スキャンの速度低下を表す定数で、最悪ケー
スとして２倍まで速度低下が許されるとすると、ηＣ＝
２である。
またこの式は、キー値が一様に分布し、１１と１２の間
にキーの重なりが無いものと仮定して導出されている。
にキーの重なりが無いものと仮定して導出されている。
ユーティリティプログラムの実行の結果、上記式に基づ
き、マージした方がよいと判断されたときは、ユーザの
手により、インデックスをマージするユーティリティプ
ログラムが流され、インデックスのマージ部でマージ処
理が実行される。
き、マージした方がよいと判断されたときは、ユーザの
手により、インデックスをマージするユーティリティプ
ログラムが流され、インデックスのマージ部でマージ処
理が実行される。
インデックスのマージにより、インデックスレコードに
ＬＰの識別子を付けなければならない。本方式では、そ
れを８ビツトのＯＮ／ ＯＦＦで管理する。
ＬＰの識別子を付けなければならない。本方式では、そ
れを８ビツトのＯＮ／ ＯＦＦで管理する。
これより、インデックスレコードを次のように構成する
。
。
（Ｋｅｙ 、ＲＲＮ、ＰＮＯ，Ｉｊ＋の１０）ここに、
Ｋｅｙ ：インデックスのキー値
ＲＲＮ ： ＰＦの相対レコード番号（当該レコード）
ＰＮＯｎ ＰＦ中のレコードが格納されているページ番
号 ＬＰのｒＤ：８ビツトでＬＰを識別するこれにより、最
大８個のマージが可能。
ＰＮＯｎ ＰＦ中のレコードが格納されているページ番
号 ＬＰのｒＤ：８ビツトでＬＰを識別するこれにより、最
大８個のマージが可能。
次に、この思想を適用した具体例を挙げる。
次は製品テーブルのＰＦである。
（製品番号１品名、 単価、 製造年月日、・・・）↑
↑ ↑ １ 検索主体 検索主体 更新主体 更新主体ここては、３
つのＬＰとしてＬＰ＋ 、ＬＰ２ 、ＬＰ３が作成され
ているとする。
↑ ↑ １ 検索主体 検索主体 更新主体 更新主体ここては、３
つのＬＰとしてＬＰ＋ 、ＬＰ２ 、ＬＰ３が作成され
ているとする。
一１３＝
表２（システムの制御表）
＊ＬＰ＋ 、ＬＰ２ 、ＬＰ３は、いずれも（製品番号
、品名、単価）より成り、レコードの選択条件が次のよ
うに定められているとする。
、品名、単価）より成り、レコードの選択条件が次のよ
うに定められているとする。
ＬＰ＋ ： １０１≦単価≦２００ＬＦ２ ：
１５１≦単価≦２５０ＬＦ３ ： ２０１≦単価
≦３００データベースのユーザがＩｉ 、１２ 、Ｉ３
についてインデックスのマージを行なおうとするとき次
のような手順を踏む。ここではη−２とする。
１５１≦単価≦２５０ＬＦ３ ： ２０１≦単価
≦３００データベースのユーザがＩｉ 、１２ 、Ｉ３
についてインデックスのマージを行なおうとするとき次
のような手順を踏む。ここではη−２とする。
（１１，Ｉｉ とＩ２のマージ可能性を、ユーティリテ
ィプログラムを流して關べる。条件式−１において、Ｎ
ｌ ／Ｎ２ ＝１．Ｒ＋ ／Ｒ＝Ｒｚ ／Ｒ＝２゜η。
ィプログラムを流して關べる。条件式−１において、Ｎ
ｌ ／Ｎ２ ＝１．Ｒ＋ ／Ｒ＝Ｒｚ ／Ｒ＝２゜η。
−１−１を代入すると、
１４−
２−１ ≦１≦２
となるので、システムは、マージ条件を満たすというメ
ソセージをユーザに通知する。
ソセージをユーザに通知する。
＋２１． ｆｉｌの結果より、Ｉ＋ 、Ｉ２をマージす
るユーティリティプログラムを流す。その結果作成され
るインデックスを１１２とすると、ＩＩ２のインデック
スレコード数Ｎ、２＝ １５０、レンジＲＩ２−１０１
〜２５０となる。このとき、１１２について、１０１〜
１５０．１５１〜２００．２０１〜２５０の範囲のイン
デックスレコードの１０は、おのおの０００００００１
、ｏｏｏｏｏ。
るユーティリティプログラムを流す。その結果作成され
るインデックスを１１２とすると、ＩＩ２のインデック
スレコード数Ｎ、２＝ １５０、レンジＲＩ２−１０１
〜２５０となる。このとき、１１２について、１０１〜
１５０．１５１〜２００．２０１〜２５０の範囲のイン
デックスレコードの１０は、おのおの０００００００１
、ｏｏｏｏｏ。
１１．００００００１０となる。
＋３１ 、 ｒ １２と１３のマージ可能性を、ユー
ティリ１ ティプログラムを流して調べる。Ｎ１２／Ｎ５＝４、１
−Ｉ Ｒ３／Ｒ＝２、Ｒ＋ｚ／Ｒ＝３より、２ ≦４≦３とな
るので、マージの条件を満たさないというメツセージを
ユーザに通知する。
ティリ１ ティプログラムを流して調べる。Ｎ１２／Ｎ５＝４、１
−Ｉ Ｒ３／Ｒ＝２、Ｒ＋ｚ／Ｒ＝３より、２ ≦４≦３とな
るので、マージの条件を満たさないというメツセージを
ユーザに通知する。
＋４１． ＋３１の結果より、ユーザは１１２とＩ３の
マージをあきらめる。
マージをあきらめる。
＊ ＬＰ２に対して、 １６１≦単価≦１７０のレコー
ドを取得するときは゛、次のように行なえばよい。
ドを取得するときは゛、次のように行なえばよい。
システムの制御表から、ＬＰ２のインデックスは１１２
であり、ＬＰのＩＤが００００００１０であるので、先
頭から７ビツト目がＯＮ″になっているインデックスレ
コードに対し、単価が１６１〜１７０までのレコードを
取得する。このとき、ＬＦｚのスキャン範囲が１５１〜
２５０とあるので、１５１から検索を始めることになる
。
であり、ＬＰのＩＤが００００００１０であるので、先
頭から７ビツト目がＯＮ″になっているインデックスレ
コードに対し、単価が１６１〜１７０までのレコードを
取得する。このとき、ＬＦｚのスキャン範囲が１５１〜
２５０とあるので、１５１から検索を始めることになる
。
このようにシステムの判定基準に基づいて、インデック
スのマージを行なうかどうかを判断し、マージを行なう
のが有利な場合のみマージを行なうことにより、インデ
ックスのマージによるインデックスメンテナンスの効率
化を実現することができる。
スのマージを行なうかどうかを判断し、マージを行なう
のが有利な場合のみマージを行なうことにより、インデ
ックスのマージによるインデックスメンテナンスの効率
化を実現することができる。
（ｆ１発明の効果
以上のように本発明によれば、論理キーから物理アドレ
スを求めるインデックス処理装置において、複数のイン
デックスの内、キーの共通ずるもののみまとめて共通の
インデックスを作成しておき、物理ファイル中のキーを
変更する際は、該キーに対応する共通インデックスのキ
ーも変更されるようを構成を採っている。そのため、従
来のように各インデックスごとに同様なインデックス更
新や追加を繰り返す必要がなく、インデックスメンテナ
ンスを効率的にかつ高速で行なうことができ、またイン
デックスによる占有ページ数も削減できる。
スを求めるインデックス処理装置において、複数のイン
デックスの内、キーの共通ずるもののみまとめて共通の
インデックスを作成しておき、物理ファイル中のキーを
変更する際は、該キーに対応する共通インデックスのキ
ーも変更されるようを構成を採っている。そのため、従
来のように各インデックスごとに同様なインデックス更
新や追加を繰り返す必要がなく、インデックスメンテナ
ンスを効率的にかつ高速で行なうことができ、またイン
デックスによる占有ページ数も削減できる。
第１図は従来のインデックス処理装置を示す図、第２図
以下は本発明の実施例を示す図で、第２図はインデック
ス処理装置を示す図、第３図はその制御ブロック図、第
４図はそのスケジューリング部のブロック図、第５図は
マージ要否の判定基準に基づくマージ処理部のブロック
図である。 図において、■は物理ファイル、２１は商品コードのフ
ィールド、２２は顧客名のフィールド、２３は数量のフ
ィールド、３１．３２・・・ＬＰ＋ 、ＬＰ２・・・は
論理ファイル、４１．４２・・・Ｉ＋ 、１２ ・・・
はインデックス、６はメンテナンス制御装置、６１は更
新フィールド認識部、６２は条件比較部、６３は削除・
挿入スケジュール部、６４はリーフレコード作成部、７
１は削除−１７＝ 処理部、７２はインデックス挿入処理部をそれぞれ示す
。 特許出願人 富士通株式会社代理人 弁理士
青 柳 稔１８−
以下は本発明の実施例を示す図で、第２図はインデック
ス処理装置を示す図、第３図はその制御ブロック図、第
４図はそのスケジューリング部のブロック図、第５図は
マージ要否の判定基準に基づくマージ処理部のブロック
図である。 図において、■は物理ファイル、２１は商品コードのフ
ィールド、２２は顧客名のフィールド、２３は数量のフ
ィールド、３１．３２・・・ＬＰ＋ 、ＬＰ２・・・は
論理ファイル、４１．４２・・・Ｉ＋ 、１２ ・・・
はインデックス、６はメンテナンス制御装置、６１は更
新フィールド認識部、６２は条件比較部、６３は削除・
挿入スケジュール部、６４はリーフレコード作成部、７
１は削除−１７＝ 処理部、７２はインデックス挿入処理部をそれぞれ示す
。 特許出願人 富士通株式会社代理人 弁理士
青 柳 稔１８−
Claims (1)
- 論理キーから物理アドレスを求めるインデックス処理装
置において、複数のインデックスを共通に作成すると共
に、各インデックスにつき、使用される論理ファイル対
応付けを作成しておき、物理ファイル中のキーを変更す
る際は、該キーに対応する論理ファイル対応付は情報を
変更するように構成されていることを特徴とするインデ
ックスの一括メンテナンス制御方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP57203420A JPS5994142A (ja) | 1982-11-19 | 1982-11-19 | インデツクスの一括メンテナンス制御方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP57203420A JPS5994142A (ja) | 1982-11-19 | 1982-11-19 | インデツクスの一括メンテナンス制御方式 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPS5994142A true JPS5994142A (ja) | 1984-05-30 |
Family
ID=16473775
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP57203420A Pending JPS5994142A (ja) | 1982-11-19 | 1982-11-19 | インデツクスの一括メンテナンス制御方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPS5994142A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05143431A (ja) * | 1992-04-22 | 1993-06-11 | Casio Comput Co Ltd | 電子フアイリング装置 |
-
1982
- 1982-11-19 JP JP57203420A patent/JPS5994142A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05143431A (ja) * | 1992-04-22 | 1993-06-11 | Casio Comput Co Ltd | 電子フアイリング装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US4912637A (en) | Version management tool | |
| US6385612B1 (en) | Method for sorting and storing data employing dynamic sort tree reconfiguration in volatile memory | |
| AU695765B2 (en) | Method and apparatus for data storage and retrieval | |
| EP0284664B1 (en) | Method of rapidly opening disc files identified by path names | |
| US6349305B1 (en) | Method and system for database processing by invoking a function related to index type definition, generating an execution plan based on index type name | |
| US5488717A (en) | MTree data structure for storage, indexing and retrieval of information | |
| US20070118547A1 (en) | Efficient index versioning in multi-version databases | |
| US20070250517A1 (en) | Method and Apparatus for Autonomically Maintaining Latent Auxiliary Database Structures for Use in Executing Database Queries | |
| JPH08195093A (ja) | 不揮発性メモリのファイル管理装置 | |
| JP3518933B2 (ja) | 構造化文書検索方法 | |
| US5519860A (en) | Central processor index sort followed by direct record sort and write by an intelligent control unit | |
| US4089027A (en) | Arrangement for retrieving information recorded on a semi-random access record carrier | |
| JPS5994142A (ja) | インデツクスの一括メンテナンス制御方式 | |
| CN87104487A (zh) | 在具有虚拟存储地址的数据处理系统中进行页面置换的装置和方法 | |
| US20050108201A1 (en) | Method to query an embedded database | |
| Gudes et al. | On evaluating Boolean expressions | |
| JP2615046B2 (ja) | レコード追加処理方法 | |
| JPH09305449A (ja) | データベース管理システム | |
| JPH0962696A (ja) | データベース管理システム | |
| CN114201487A (zh) | 智能合约的存储装置和方法 | |
| JPH10161915A (ja) | 後発ジョブ優先の排他制御を実現するデータ引き継ぎ方法 | |
| JP3468531B2 (ja) | データベース管理装置およびそのレコード格納方法 | |
| JPH04199338A (ja) | データベース管理システム | |
| JPH0317727A (ja) | レコード入出力管理方式 | |
| JPH08147328A (ja) | 文書検索方法及び装置 |