JPH0724036B2 - データベース処理方法 - Google Patents

データベース処理方法

Info

Publication number
JPH0724036B2
JPH0724036B2 JP58242024A JP24202483A JPH0724036B2 JP H0724036 B2 JPH0724036 B2 JP H0724036B2 JP 58242024 A JP58242024 A JP 58242024A JP 24202483 A JP24202483 A JP 24202483A JP H0724036 B2 JPH0724036 B2 JP H0724036B2
Authority
JP
Japan
Prior art keywords
storage device
page
database
vector
search
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.)
Expired - Lifetime
Application number
JP58242024A
Other languages
English (en)
Other versions
JPS60134945A (ja
Inventor
啓二 小島
俊一 鳥居
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP58242024A priority Critical patent/JPH0724036B2/ja
Priority to US06/684,789 priority patent/US4644471A/en
Publication of JPS60134945A publication Critical patent/JPS60134945A/ja
Priority to US07/015,694 priority patent/US4785400A/en
Publication of JPH0724036B2 publication Critical patent/JPH0724036B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (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)
  • Complex Calculations (AREA)
  • Memory System (AREA)
  • Executing Machine-Instructions (AREA)

Description

【発明の詳細な説明】 〔発明の利用分野〕 本発明は、データベース処理方式に係り、特に大規模リ
レーシヨナル・データベースにおける検索要求の処理に
好適なデータベース処理方式に関する。
〔発明の背景〕
大量データの効率的管理を目的とするデータベース技術
が急速に発展している。データベースの大きな利点は、
データベース利用者が、データの物理的記憶構造を全く
意識せずに、データ操作用言語を通じてデータにアクセ
スすることが可能である点にある。
データベースに格納されているデータ（以下レコードと
呼ぶ）の、物理的な格納形式は、レコードの挿入・削除
等の操作に対する柔軟性の確保、レコードの格納効率の
向上、などを実現するために一般にかなり複雑な形式と
なつている。
従つて、ユーザによつて論理的にポイントされたレコー
ドに対し、その物理的な格納位置を求める処理（この処
理をデータベース処理におけるアドレス変換と呼ぶ）
も、レコードの物理的な格納形式の複雑さに対応して、
かなり高負荷の処理となつている。
従来のデータベース管理システム（以下DBMSという）で
は、レコードへのアクセスを１レコード単位で行なつて
いた。すなわち、あるレコードのデータベースからの取
り出しが必要となつた時点毎に、アドレス変換を行なつ
てレコードの物理アドレスを求めてそのレコードを取り
出していた。
しかし、かかるデータベース処理方式には、以下の様な
問題点がある。
第一の問題点は、大量レコードの一括処理を要求された
場合の性能上の問題である。
最近の、特にリレーシヨナル・モデルにもとづく高水準
のデータ操作用言語は、１コマンドによつて複数のレコ
ードの処理を行なうことができる。一方、近年のいわゆ
るスーパー・コンピユータの発達に示されるように、大
量データの一括処理の高速化には、パイプライン方式な
どによるベクトル処理が非常に効果的であることが知ら
れている。
しかし、１レコード毎にアドレス変換を行なう従来のDB
MSでは、前述の様にアドレス変換処理が複雑なため、複
数レコード処理のベクトル化が極めて困難である。
第二の問題点は、同一のレコードに対して複数回のアク
セスを行なう場合には、本質的には１度のアドレス変換
で済むはずであるが、従来方式では、レコードに対する
アクセス回数に等しい回数のアドレス変換を常に必要と
するという欠点がある。
〔発明の目的〕
本発明の目的は、複雑な構造のデータベースを高速に処
理できるデータベース処理方式を提供することを目的と
する。さらに、本発明の他の目的は、アドレス変換回数
が少なくて済むデータベース処理方式を提供することに
ある。
〔発明の概要〕
上記目的を達成するために、本発明では、計算機システ
ムは、データ処理装置と、それに接続された第１、第２
の記憶装置とを有し、該第１の記憶装置は、該第２の記
憶装置より高速にアクセス可能であり、該第２の記憶装
置は、データベースを保持し、該データベースは複数
行、複数列からなる複数のテーブルを含み、各テーブル
は複数のレコードを含み、各レコードは、そのレコード
が属するテーブルのいずれか一つの行に属し、かつ、そ
れぞれ該複数列の異なる列に属する複数のデータ要素を
含み、該複数のレコードは、該第２の記憶装置内の不均
一のアドレス間隔の位置に記憶されている計算機システ
ムにおいて、データベースは複数行、複数列からなる複
数のテーブルを含み、各テーブルは複数のレコードを含
み、各レコードは、そのレコードが属するテーブルにず
れか一つの行に属し、かつ、それぞれ該複数列の異なる
列に属する複数のデータ要素を含み、該複数のレコード
は、該第２の記憶装置内の不均一のアドレス間隔の位置
に記憶されている。
この計算機システムにおいて、 そのデータベースに対する検索要求が発生した時点で、
その検索要求が指定する検索処理の内容を解析して、該
データベースの内、該検索処理で使用される複数のテー
ブルと、それぞれのテーブルに属し、その検索処理で使
用される複数の列を判定し、 該判定された複数のテーブルの各々を構成する複数のレ
コードを該第２の記憶装置から該第１の記憶装置に読み
出し、 該判定されたテーブルの各々に対して読み出された複数
のレコードのデータ要素の内、上記検索処理で使用する
と判定されたの列の各々に属する複数のデータ要素を、
該第１の記憶装置内の一定のアドレス間隔を有する位置
に、そのテーブルのその列のデータ要素群として記憶
し、 上記検索処理が指定するいずれかのテーブルのいずれか
の列に対する処理を、そのテーブルのその列に対して上
記第１の記憶装置に記憶されたデータ要素群を使用して
実行するように、上記検索処理を実行する。
〔発明の実施例〕
以下、本発明の一実施例を図面に従つて詳細に説明す
る。第１図は、本発明をリレーシヨナル・データベース
の処理に適用した場合の一実施例を示すブロツク図であ
る。
第１図において、101は主記憶、108は二次記憶、110は
中央処理装置である。主記憶101には、データベース処
理プログラム（DBP）102が格納されている。また、主記
憶101には、データベース処理のための作業領域106およ
びI/Oバツフア領域401が確保されている。データベース
処理プログラム102は、ベクトル展開部103と、検索処理
制御部104と、ベクトル処理部105とから成る。二次記憶
108にはデータベース109が格納される。中央処理装置11
0はスカラ命令とベクトル命令の両方を処理できるベク
トル計算機の中央処理装置である。
データベース109は、テーブルとインデツクスとから成
り、テーブルのたて一欄をカラム、横一欄をローと呼
ぶ。
テーブル、インデツクスともに、ページと呼ばれる単位
に分割して二次記憶108に格納される。テーブルを格納
しているページをデータページ、インデツクスを格納し
ているページをインデツクスページと呼ぶ。
まず、データページの構造の例を第２図を用いて説明す
る。
データページ204内には、スロツト205と変位部207とが
あり、変位部207には、スロツト205の先頭アドレスと、
データページ204の先頭アドレスの差が格納される。デ
ータページには複数のスロツトが存在するので、それに
対応して変位部も複数存在する。変位部はデータページ
の終わりから順に配置され終わりに近い順から番号がつ
けられる。以下この番号をスロツト番号203と呼ぶ。
テーブルのローは、スロツト205に格納される。従つ
て、テーブルのローは、そのローが格納されているスロ
ツト205が存在するデータページの二次記憶108中でのペ
ージ番号202と、そのローが格納されているスロツト205
のスロツト番号203とのペア201（以下これをローIDと呼
ぶ）によつて二次記憶中で一意に指定される。スロツト
205はさらに、複数のカラム値から成る。
次に、インデツクスの構造について述べる。
インデツクスには平衡木（以下Ｂ−treeという）という
木構造が良く用いられ、本実施例でも、Ｂ−treeをイン
デツクスの構造として使用する。
Ｂ−treeの各ノードが１インデツクス・ページに対応す
る。
Ｂ−treeのルートに対応するページをルート・ページ，
リーフに対応するページをリーフ・ページと呼ぶ。
以下、インデツクス・ページの構造例について第３図を
用いて説明する。
インデツクス・ページの構造は、リーフ・ページとリー
フ以外のページとで異なる。
第３図において、301はリーフでないインデツクス・ペ
ージであり、308はリーフであるインデツクス・ページ
（リーフ・ページ）である。
インデツクス・ページには、複数のインデツクスエント
リ（以下エントリという）が存在する。
インデツクス・ページ301内のエントリのうち、最も小
さいキー値をもつエントリ304を、そのページの先頭エ
ントリと呼ぶ。各エントリの最後部には、インデツクス
・ページ301内で次に大きなキー値をもつエントリへの
ポインタが格納され、インデツクス・ページ301内の最
後のエントリ、すなわち、そのページ中で最も大きなキ
ー値をもつエントリの最後部305には、次のエントリが
存在しないことを示すマークが格納されている。変位部
306には、インデツクス・ページ301の先頭エントリのア
ドレスと、インデツクスページ301の先頭アドレスとの
差が格納されている。前方ページ番号307には、インデ
ツクス・ページ301の前方のインデツクス・ページの番
号が格納される。
その前方ページ内の任意エントリのキー値は、インデツ
クス・ページ301内の任意エントリのキー値より大き
い。
ここまでで説明したインデツクス・ページの構造は、リ
ーフ・ページとリーフ以外のインデツクス・ページとに
共通である。
リーフ以外のインデツクス・ページ301のエントリ302の
キー値に続く部分303には、下方のインデツクス・ペー
ジ（リーフ・ページ）308のページ番号が格納されてい
る。インデツクス・ページ（リーフ・ページ）308内の
任意のエントリのキー値は、エントリ302のキー値以上
の値を有する。
インデツクス・ページ（リーフ・ページ）308のエント
リ309のキー値に続く部分310には、そのキー値に属する
ローのローID（すなわち該インデツクスがつけられてい
るカラムの値がキー値に等しいようなローのローID）が
格納される。エントリ309のキー値に属するローが複数
個ある場合、エントリ309には複数のローIDが格納され
る。
Ｂ−treeでは、リーフ・ページの前方ページは必ずリー
フ・ページである。リーフ・ページのうち、他のどのリ
ーフ・ページからも参照されていないページが唯一つ存
在し、このリーフ・ページを最左リーフ・ページと呼
ぶ。最左リーフ・ページのページ番号は、ルート・ペー
ジから、ページの先頭エントリのキー値の最後に示され
ている下方ページを、リーフ・ページまでたどることに
より得られる。
また、テーブルの任意のローのローIDは、いずれかのリ
ーフ・ページのエントリ内に必ず格納されており、ま
た、インデツクス中にそのローIDが重複して格納される
ことはない。
従つて、最左リーフ・ページから次々と前方のリーフ・
ページをたどりながらそのページ内をスキヤンしていく
ことにより、テーブルの全ローのローIDを、キー値の昇
順に取り出すことができる。
さて、二次記憶108に格納されているデータ・ページお
よびインデツクス・ページは、主記憶101のI/Oバツフア
領域401に読み込まれてからデータベース処理プログラ
ム102によつて処理される。
第４図に、I/Oバツフア領域の構成例を示す。
I/Oバツフア領域401は、複数のバツフアから成る。各バ
ツフアには、I/Oバツフア領域401の中で一意な番号づけ
がなされており、この番号を以下バツフア番号と呼ぶ。
I/Oバツフア領域401内の各バツフアの主記憶101上での
アドレスは、バツフア番号より定まる。各バツフアのサ
イズは、二次記憶108におけるページのサイズに等し
い。
二次記憶108に格納されているデータ・ページまたはイ
ンデツクス・ページが、I/Oバツフア領域401のあるバツ
フア、例えばバツフア番号ｉのバツフア402に読み込ま
れると、バツフア・デイレクトリ403には、そのページ
のページ番号404と、そのバツフアのバツフア番号405の
ペアが登録される。
従つて、二次記憶108のあるページが、I/Oバツフア領域
401に存在するか否かは、バツフア・デイレクトリ403を
探索して、そのページのページ番号が登録されているか
否かによつて判定でき、かつ、そのページ番号とペアに
なつているバツフア番号からI/Oバツフア領域401中のど
のバツフアにそのページが読み込まれたかがわかる。
ところで、I/Oバツフア領域401内のバツフアに読み込ま
れたインデツクス・ページまたはデータ・ページの中の
インデツクス・エントリまたはスロツトを、データベー
ス処理プログラム102が処理するには、エントリもしく
は、スロツトの主記憶101におけるアドレスを知る必要
があり、ローIDから、そのローを格納しているスロツト
の主記憶101上のアドレスを調べる処理を、ローのアド
レス変換と呼ぶ。
また、インデツクス・ページ番号から、そのインデツク
ス・ページ内の先頭エントリのアドレスを調べる処理を
インデツクス・ページのアドレス変換と呼ぶ。
まず、ローのアドレス変換処理を第５図のフローチヤー
トを用いて説明する。
変数PAGE＃,SLOT＃にそれぞれ変換の対象であるローID
中のページ番号、スロツト番号を代入する（ステツプ50
1）。
次にバツフア・デイレクトリ403を探索して、そのペー
ジ番号が、バツフア・デイレクトリ403中に登録されて
いるか否かを調べ（ステツプ502）、登録されていれ
ば、そのページが読み込まれているバツフアのバツフア
番号から、そのバツフアのアドレスを計算して変数BUFF
Aに代入する（ステツプ504）。
登録されていない場合は、そのページを二次記憶108か
ら主記憶101のI/Oバツフア領域401の適当なバツフアに
読み込み、そのページ番号と、そのバツフアのバツフア
番号とのペアをバツフア・デイレクトリ403に登録（ス
テツプ503）した後、上述のステツプ504を実行する。
第２図で説明したデータ・ページの構造から明らかな様
に、スロツト番号（SLOT＃）203が示す該データページ2
04中の変位部207の内容とバツフア・アドレスBUFFAの和
を計算することにより該ローが格納されているスロツト
の主記憶101上のアドレスを知ることができる（ステツ
プ505,506）。
一方、インデツクス・ページのアドレス変換処理を、第
６図のフローチヤートを用いて説明する。まず、変換の
対象となるインデツクス・ページのページ番号を変数PA
GE＃に代入する（ステツプ601）。ステツプ602,603,604
は、ローのアドレス変換におけるステツプ502,503,504
と同一であり、そのインデツクス・ページが読み込まれ
ているバツフアの主記憶アドレスを求める処理である。
第３図で説明したインデツクス・ページの構造から明ら
かな様に、インデツクス・ページの変位部306の内容と
そのインデツクス・ページが読み込まれているバツフア
の主記憶101上のアドレスとの和を計算することによ
り、インデツクス・ページの先頭エントリのアドレスが
わかる（ステツプ605,606）。
以上、本発明の一実施例の構成と、基本となるデータ構
造と、アドレス変換処理の例を説明した。
以下、本発明のデータベース処理プログラム102の詳細
な動作例を、ある具体的な検索要求の処理手順を追いな
がら説明する。
本実施例で例題とする検索を第７図に示す。
検索対象テーブルは、TABLE（１）710,TABLE（２）711
の二つである。
TABLE（１）710はSTUDENTとCLASSの二つのカラムから、
TABLE（２）711はCLASSとTEACHERの二つのカラムからそ
れぞれ成つている。
TABLE（１）711のSTUDENTカラムと、TABLE（２）712のC
LASSカラムには、それぞれインデツクスINDEX（１）71
3、INDEX（２）714がつけられている。
検索要求701は、「TABLE（１）とTABLE（２）で、それ
ぞれのCLASSカラムの値が等しいようなローのペアからS
TUDENTカラムとTEACHERカラムの値のペアをすべて取り
出して検索結果702として出力せよ」というものであ
る。この様な異なるテーブルを結合する処理はリレーシ
ヨナル・モデルではジヨイン（join）と呼ばれている。
次に検索処理制御部104の動作例を第８図のフローチヤ
ートを用いて説明する。
検索処理制御部104は、検索要求701を解析する（ステツ
プ800）。検索要求701中には、TABLE（１）とTABLE
（２）の全カラムが引用されているので、検索処理制御
部104はTABLE（１）とTABLE（２）の全レコードのベク
トル化をベクトル展開部103に指示する（ステツプ801,8
02）。
ここでテーブルのベクトル化とは、第２図で示したよう
な構造で、データページ204内に格納されている該テー
ブルの各カラムを一次元配列（ベクトル）の形式で主記
憶101の作業領域106上に展開することを意味する。
すなわち、TABLE（１）のベクトル化の結果、TABLE
（１）の各ローのSTUDENTカラムの値をベクトル形式で
並べたベクトルD0およびCLASSカラムの値をベクトル形
式で並べたベクトルD1が作業領域106に格納される。
同様に、TABLE（２）のベクトル化の結果、TABLE（２）
の各ローのCLASSカラムの値のベクトルD2およびTEACHER
カラムの値のベクトルD3が作業領域106に格納される。
TABLE（１）およびTABLE（２）のベクトル化が完了する
と、検索処理制御部104は、ベクトル処理部105にステツ
プ801,802で作られたベクトルD0,D1を用いてベクトル型
の二進探索を行なうように指示する（ステツプ803）。
ベクトル処理部105における該ベクトル型二進探索が完
了すると、検索処理制御部104は、ベクトル処理部105
に、ベクトル処理部105によつて作業領域106に格納され
た該ベクトル型二進探索結果、およびベクトルD0,D3を
用いて検索結果を出力するよう指示する（ステツプ80
4）。
以上が、検索要求701が入力された場合の、検索処理制
御部104の動作である。
次に、第９図のフローチヤートを参照しながらベクトル
展開部103の動作を説明する。
ベクトル展開部103は、TABLE（１）のベクトル化を検索
処理制御部104に指示される（第８図ステツプ801）と、
カウンタｉをリセツトし、INDEX（１）の最左リーフ・
ページ番号を調べ、変数IXPAGE＃に代入する（ステツプ
901）。
次のステツプ902で、第６図のフローチヤートで示した
手順により最左リーフ・ページ番号IXPAGE＃のアドレス
変換を行なつてその最左リーフ・ページの先頭エントリ
の主記憶101上のアドレスを求め、変数ENTRYAにセツト
する（ステツプ902）。次にENTRYAによつて、ポイント
されるエントリの中から、ローIDを取り出し、第５図の
フローチヤートで示した手順によりそのローIDのアドレ
ス変換を行なつて、そのローが格納されているスロツト
の主記憶101上のアドレスを求め、定数SLOTAに代入し
（ステツプ903）、さらに、SLOTAでポイントされるスロ
ツトからTABLE（１）のSTUDENTカラムとCLASSカラムと
の値を取り出し、それぞれ作業領域106上のベクトルD0,
D1のｉ番目の要素D0（ｉ）,D1（ｉ）として格納する
（ステツプ904）。
そして、カウンタｉを＋１し（ステツプ905）、続いてE
NTRYAが指すエントリにまだ処理していないローIDが残
つているか否かをチエツクし（ステツプ906）、残つて
いればステツプ903へ戻り、未処理ローIDの処理を開始
する。残つていなければ、ENTRYAが指すエントリの最後
の部分を調べて、次のエントリがあるか否かをチエツク
する（ステツプ907）。もし次エントリがあれば、ENTRY
Aに次エントリの主記憶101上のアドレスをセツト（ステ
ツプ909）した後、ステツプ903へ戻り、次エントリの処
理を行なう。次エントリがなければ、現在処理中のイン
デツクス・ページ（ページ番号:IXPAGE＃）の前方ペー
ジがあるか否かをチエツクして（ステツプ908）、あれ
ば、IXPAGE＃に前方ページのページ番号をセツト（ステ
ツプ910）してから、ステツプ902へ戻り、前方ページの
処理を開始する。ステツプ908の判定の結果、前方イン
デツクス・ページがないと判明した場合、処理が終了す
る。
第３図のインデツクス・ページの説明において述べたよ
うに、最左リーフページから前方のリーフ・ページを次
々とたどることにより、テーブルの全ローを、インデツ
クスのついたカラムの値の昇順にアクセスすることがで
きるので、第９図の処理手順によつて、TABLE（１）の
全ローの、STUDENTカラム値とCLASSカラム値がそれぞれ
ベクトルD0とD1に格納される。また、INDEX（１）はSTU
DENTカラムにつけられたインデツクスであり、ベクトル
D0は、昇順にソートされている。
検索処理制御部104の指示により、TABLE（２）もTABLE
（１）と同様に、第９図の処理手順によつてベクトル化
される。すなわち、INDEX（２）の最左リーフページ番
号をIXPAGE＃にステツプ901でセツトしてからステツプ9
02以降を実行する（但しステツプ904でｊ＝2,3とする）
ことにより、TABLE（２）の全ローのCLASSカラム値と、
TEACHERカラム値とが、それぞれベクトルD2とD3に格納
される。INDEX（２）はCLASSカラムにつけられているの
でベクトルD2は昇順にソートされる。
第８図で説明した様に、ベクトル展開部103で、TABLE
（１）およびTABLE（２）が検索処理制御部104の指示に
よつてベクトル化されてベクトルD0〜D3が作業領域106
上に作られると、検索処理制御部104はD1を比較キーベ
クトルとしてD2内をベクトル型二進検索する様、ベクト
ル処理部105に指示する（ステツプ803）。
次に、ベクトル処理部105におけるベクトル型二進検索
の処理手順を第10図のフロー・チヤートを参照しながら
説明する。
まず、第10図のフローチヤートで用いられている変数の
意味を述べる。
N1は、TABLE（１）のCLASSカラム値のベクトルD1の長さ
であり、N2はTABLE（２）のCLASSカラム値のベクトルD2
の長さである。
ｉは、実行回数のカウンタである。L,U,Cはいずれも作
業領域106に置かれる長さN1のベクトルであり、Ｌは探
索範囲の下限、Ｕは探索範囲の上限、Ｃは探索範囲の中
央をそれぞれ示す。
Ｍは長さN1のビツト列であり、比較結果を格納する（以
下Ｍをマスクと呼ぶ）。
二進探索結果は、ベクトルＵに格納される。
第10図のベクトル型二進探索プログラムの機能は、ベク
トルD1の各要素、D1（ｊ）（ｊ＝0,……,N1−１）に対
し、ソート済みのベクトルD2内にD1（ｊ）と値が等しい
ようなD2（ｋ）があればｋをＵ（ｊ）に返すことであ
る。但し、D1（ｊ）に等しいようなD2の要素が複数存在
する場合、すなわちD2（k0），……D2（kl-1）がすべて
D1（ｊ）に等しい場合には、Ｕ（ｊ）にmin（k0,……,k
l-1）を返すこととする。
第10図のフローチヤートを参照しながら、ベクトル処理
部105における、ベクトル型二進探索の手順を説明す
る。
実行回数のカウンタｉをリセツトし（ステツプ1001）、
探索範囲の下限ベクトルＬと上限ベクトルＵを初期化す
る（ステツプ1002,1003）。最初の探索（ｉ＝０）で
は、探索範囲はD2全域であるので、下限ベクトルＬの全
要素は０であり、Ｕの全要素はN2−１である。ステツプ
1002,1003はともに、あるスカラ値をベクトルの全要素
に代入するようなベクトル命令によつて処理される。
そして、カウンタｉとlogN2を比較し（ステツプ100
4）、カウンタｉの値がlogN2以上であれば終了し、そう
でなければステツプ1005,1006および1007を実行し、カ
ウンタｉを＋１（ステツプ1008）してステツプ1004に戻
る。すなわち、ステツプ1005〜1007はlogN2回実行され
る。
ステツプ1005で、探索範囲の中での中央の位置の計算を
D1の各要素（つまり比較キー）毎に行なう。ステツプ10
05は、下限ベクトルＬと上限ベクトルＵを要素毎に加算
して２で割つた商を中央ベクトルＣの対応要素に格納す
るベクトル命令により実行される。次にD1の各要素D
1（ｊ）（ｊ＝0,……,N1−１）と、要素対応にステツプ
1005で計算された探索範囲の中央に位置するD2の各要素
D2（Ｃ（ｊ））（ｊ＝0,……,N1−１）とを比較し、D1
（ｊ）すなわち比較キーの方が小さければマスクＭの第
ｊビツトを０とし、そうでなければマスクＭの第ｊビツ
トを１とする（1006）。マスクＭの第ｊビツトが０、す
なわち、被比較値D2（Ｃ（ｊ））が比較キーD1（ｊ）よ
り小さい時は、各比較キーに対応する新しい探索下限Ｌ
（ｊ）としてＣ（ｊ）の値を格納し、マスクＭの第ｊビ
ツトが１、すなわち被比較値D2（Ｃ（ｊ））が比較キー
D2（ｊ）と等しいか、又は大きい時は、その比較キーに
対応する探索上限Ｕ（ｊ）としてＣ（ｊ）の値を格納す
る（ステツプ1007）。ステツプ1006,1007ともにベクト
ル命令で実行される。
ベクトルD2は昇順にソート済みであるのでステツプ1007
の結果、各比較キー対応にU,Lに記憶されている探索範
囲は半分となり、従つてステツプ1005〜1007をlog2N2回
繰返すことにより、各比較キーに等しいD2の要素を探索
することができる。ステツプ1006で、探索範囲の中央の
D2の要素と、キー値が等しい時には、ステツプ1007で中
央位置を、次の探索におけるキー値に対応する探索範囲
の上限としているので、探索終了時には、D2内にキーD1
（ｊ）に等しい要素が複数存在する場合にも、その複数
要素のうち、D2内で最初に現われる要素を位置が上限ベ
クトルＵ（ｊ）として得られる。
ベクトル処理部105によつて、第10図のフロー・チヤー
トに示したベクトル型二進探索が行なわれ、作業領域10
6上のベクトルＵに探索結果が得られると、第８図のフ
ローチヤートで説明した様に検索処理制御部104はベク
トル処理部105に、ベクトルD0,D3およびＵを用いて検索
要求701の結果を出力する様に指示する（ステツプ80
4）。
次に、ベクトル処理部105におけるジヨイン結果の作成
手順を第11図のフロー・チヤートを用いて説明する。
第11図において、ｉはD1の処理要素を示すポインタであ
り、ｊはD2の処理要素を示すポインタである。ｉのリセ
ツトを行なつた（ステツプ1101）後、ｊに、第10図に示
した処理手順によつて作成されたベクトル型二進探索結
果のベクトルＵの第ｉ番目の要素Ｕ（ｉ）を格納する
（ステツプ1102）。次にD1（ｉ）とD2（ｊ）を比較する
（ステツプ1103）。
D1（ｉ）とD2（ｊ）が等しい時、D1（ｉ）はTABLE
（１）のあるローのCLASSカラムの値であり、D2（ｊ）
はTABLE（２）のあるローのCLASSカラムの値である。従
つてD0（ｉ）とD3（ｊ）は、それぞれのCLASSカラム値
が等しいようなTABLE（１）のローのSTUDENTカラム値
と、TABLE（２）のローのTEACHERカラムの値であり、検
索要求701における検索条件を満たしているので検索結
果の１つとして出力する（ステツプ1104）。
D2はソートされており、かつ第10図のベクトル型二進探
索処理で説明したようにD2（ｊ）、すなわちD2（Ｕ
（ｉ））は、D1（ｉ）に等しいようなD2の要素のうち一
番最初の要素であるから、D1（ｉ）に等しいD2の要素が
複数ある場合には、D2（Ｕ（ｉ））から始まつて、D2内
で連続して並んでいる。
従つて、ｊを＋１して（ステツプ1105）ｊがＮ以上とな
るか（ステツプ1106）またはD1（ｉ）≠D2（ｊ）となる
（ステツプ1103）までD0（ｉ）とD3（ｊ）のペアを出力
する（ステツプ1104）ことにより、D1（ｉ）とD2（ｊ）
が等しいようなすべてのｊについて、D0（ｉ）とD
3（ｊ）を出力することができる。
D1（ｉ）とD2（ｊ）が等しくない時には、D1（ｉ）に等
しいD2の要素が存在しないから、ｉを＋１して（ステツ
プ1107）ｉがN1より小さいならば（ステツプ1108）、ス
テツプ1102に戻つてD1の次要素の処理を行なう。
判定ステツプ1108で、カウンタｉがN1以上となつた時に
は、D1の全要素の処理を完了し、検索結果の出力を終了
する。
ベクトル処理部105での第11図のフロー・チヤートで示
した処理の終了が検索処理制御部104に報告されると、
検索要求701の処理が終了する（ステツプ805）。
本実施例によれば、第９図で動作を説明したベクトル展
開部103によつて、テーブルをベクトル形式に変換する
ので、第10図で示したベクトル型の二進探索のように、
ベクトル命令を有効に用いた高速処理が可能となる。
また、本実施例の処理手順によれば、アクセス単位がテ
ーブルおよびインデツクスである、即ち、ローのアドレ
ス変換およびインデツクス・ページのアドレス変換をベ
クトル展開部103の中で、ローとインデツクス・ページ
のそれぞれについて一括してただ一度のみ行うので、従
来のローあるいはインデツクスページ単位のアクセスに
よるデータベース方式に比べてアドレス変換回数を大幅
に削減できる。
本実施例におけるアドレス変換回数の削減効果を示すた
めに、検索要求701の従来の処理方式による処理例を、
第12図を参照しながら説明する。
従来方式では、まずINDEX（１）を用いてTABLE（１）の
ローのローIDを一つ取り出してアドレス変換を施こし、
そのローIDを有するローを取り出し、そのローのCLASS
カラムの値Ｘを調べ（ステツプ1201〜1204）、次にＸを
比較キーとして、INDEX（２）内を、ルートページから
順にインデツクス・ページの変換を行ないながらリーフ
・ページまでＸに従つてたどる（1205）ことによつて、
TABLE（１）のローであつてそのCLASSカラム値がＸに等
しいものがあればすべて取り出して検索結果として出力
する（ステツプ1206〜1208）。
以下、次に処理するTABLE（１）のローを取り出した後
（1209→1203,1209→1210→1212→1203、または1209→1
210→1211→1213→1202→1203）、上記1204〜1208の処
理をINDEX（１）の全リーフ・ページを探索しつくすま
で繰り返していた。
すなわち、アドレス変換は、ローまたはインデツクス・
ページ単位に必要になり次第随時行なわれていた。
第12図に示した従来方式（レコード単位のアクセス）
と、本実施例（テーブル・インデツクス単位の一括アク
セス）との、それぞれにおけるアドレス変換回数の比較
を第13図に示す。
第13図において、N1はTABLE（１）のロー数、N2はTABLE
（２）のロー数、M1はINDEX（１）のページ数、M2はIND
EX（２）のページ数,N3は検索結果の出力数である。
従つて、従えば、一つの学級（CLASS）に一人の担任教
師（TEACHER）がおり、一学級（CLASS）には50人の生徒
がいるとすれば、教師の総数をＮ人とし、さらに１イン
デツクス・ページには、10個のローIDが格納されている
として、 N1＝50N,N2＝N,N3＝50N となる。
従つて従来方式では 本実施例では のアドレス変換が必要となり、これは、Ｎ＝100では、
従来方式が26860回、本実施例では5355回であり、約1/5
に削減される。
また、ベクトル展開部103で一度ベクトル化したテーブ
ルを別の検索に対して用いる時には、該検索に対するア
ドレス変換は全く不要となる。
本実施例では、テーブルのベクトル化の際、全てのカラ
ム値のベクトルを作成したが、メモリの効率的利用のた
めに、第９図に示したベクトル展開部103のステツプ904
におけるカラム値ベクトル作成の代わりにスロツト・ア
ドレスのベクトルを作成して、データ（カラム値）のベ
クトルは作成せず、スロツト・アドレス・ベクトルを用
いて、ローへのアクセスを行なつても良い。
さらに、検索処理において必要なカラムにインデツクス
が付与されている場合も例えば、TABLE（２）のCLASSカ
ラムに対するINDEX（２）が存在する場合、第９図のス
テツプ903,904を実行せずに、エントリ内のキー値をそ
のエントリ内のローIDの個数分だけ連続アドレスに格納
していくことにより、D2に等しいベクトルを作成でき、
TABLE（２）のベクトル化（ローIDの変換）は不要とな
る。
この時、キー値に属するローIDのベクトルも同時に作成
しておけば、ベクトル処理部105における第11図の処理
の中で、TABLE（２）のTEACHERカラム値（D3の要素）が
必要となつた時、そのローIDをアドレス変換して該カラ
ム値を取り出して出力することができる。
この方法によれば、第13図に示したTABLE（２）に対し
て必要なアドレス変換回数は、N3回となり、従来方式と
同一となる。
この方法は検索出力N3が少ないと予想される時に有効と
なる。
また、第９図に示したベクトル展開部103の動作では、
テーブルの全ローをベクトル展開したが、検索に全ロー
が不要な場合、例えば検索要求701で、TABLE（１）のCL
ASSカラムに対し、TABLE（１）のCLASS＜４という条件
が付加されている際には、INDEX（１）のリーフページ
のうち、キー値が４未満のリーフページに格納されてい
るローIDのみを変換して、TABLE（１）を部分的にベク
トル化することも容易である。こうすれば、アドレス変
換回数およびメモリ使用量の削減をさらにはかれる。
本実施例では、アドレス変換回数の削減効果について説
明したが、データベース処理システムにおける、レコー
ドへのアクセスに伴なう種々の処理、例えば複数のユー
ザが同一レコードにアクセスする可能性のある場合のレ
コードのロツク処理や、アクセス中のページの主記憶上
における位置の固定処理なども、全く同様の一括化によ
りその回数が削減される。
〔発明の効果〕
以上述べた様に、複雑な構造のデータベースを高速に処
理できる。とくに、アドレス変換回数が少なくて済む。
【図面の簡単な説明】
第１図は本発明の一実施例を示すブロツク図、第２図お
よび第３図は第１図のデータベースのデータ構造図、第
４図は第１図のI/Oバツフア領域401の詳細な構造図、第
５図はローのアドレス変換手順を示すフローチヤート、
第６図はインデツクスページのアドレス変換手順を示す
フローチヤート、第７図は第１図の実施例で処理される
検索例を示す説明図、第８図は第７図の検索例を処理す
る場合の第１図の検索処理制御部104の動作例を示すフ
ローチヤート、第９図は第７図の検索例を処理する場合
の第１図中のベクトル展開部103の動作例を示すフロー
チヤート、第10図および第11図は、第７図の検索例を処
理する場合の第１図中のベクトル処理部105の動作例を
示すフローチヤート、第12図は、第７図の検索例を従来
方式で処理する場合の処理手順を示すフローチヤート、
第13図は第７図の検索例の処理において、必要なアドレ
ス変換回数を、第12図の従来方式と第８図〜第11図の本
発明の一実施例における方式とで比較した説明図であ
る。 101……主記憶、102……データベース処理プログラム、
103……ベクトル展開部、104……検索処理制御部、105
……ベクトル処理部、106……作業領域、401……I/Oバ
ツフア領域、108……二次記憶、109……データベース、
110……中央処理装置。

Claims (4)

    【特許請求の範囲】
  1. 【請求項１】データ処理装置と、それに接続された第
    １、第２の記憶装置とを有し、該第１の記憶装置は、該
    第２の記憶装置より高速にアクセス可能であり、該第２
    の記憶装置は、データベースを保持し、該データベース
    は複数行、複数列からなる複数のテーブルを含み、各テ
    ーブルは複数のレコードを含み、各レコードは、そのレ
    コードが属するテーブルのいずれか一つの行に属し、か
    つ、それぞれ該複数列の異なる列に属する複数のデータ
    要素を含み、該複数のレコードは、該第２の記憶装置内
    の不均一のアドレス間隔の位置に記憶されている計算機
    システムにおいて、 そのデータベースに対する検索要求が発生した時点で、
    その検索要求が指定する検索処理の内容を解析して、該
    データベースの内、該検索処理で使用される複数のテー
    ブルと、それぞれのテーブルに属し、その検索処理で使
    用される複数の列を判定し、 該判定された複数のテーブルの各々を構成する複数のレ
    コードを該第２の記憶装置から該第１の記憶装置に読み
    出し、 該判定されたテーブルの各々に対して読み出された複数
    のレコードのデータ要素の内、上記検索処理で使用する
    と判定された複数の列の各々に属する複数のデータ要素
    を、該第１の記憶装置内の一定のアドレス間隔を有する
    位置に、そのテーブルのその列のデータ要素群として記
    憶し、 上記検索処理が指定するいずれかのテーブルのいずれか
    の列に対する処理を、そのテーブルのその列に対して上
    記第１の記憶装置に記憶されたデータ要素群を使用して
    実行するように、上記検索処理を実行するデータベース
    処理方法。
  2. 【請求項２】該データベースに含まれる該複数のレコー
    ドは、該第２の記憶装置内の複数の頁に分散して記憶さ
    れ、 該検索処理が使用する該複数のレコードの読み出しにお
    いては、 該複数のレコードを含む複数の頁を判別し、 該判別された複数の頁内のデータを該第２の記憶装置か
    ら該第１の記憶装置に読み出し、 該データ要素群を記憶するにあたっては、 該読み出された複数の頁内のデータのうち、該検索処理
    で使用される同一のテーブルの同一の列に属する、デー
    タ要素を選択して該第１の記憶装置内の一定のアドレス
    間隔の位置に転送して行う請求項１記載のデータベース
    処理方法。
  3. 【請求項３】該データ処理装置は、ベクトル命令とスカ
    ラ命令を実行可能であり、 該検索処理の実行は、該一定間隔に記憶された複数のデ
    ータ要素をベクトルデータとして扱うベクトル命令によ
    り行う請求項１記載のデータベース処理方法。
  4. 【請求項４】該第１、第２の記憶装置はそれぞれ該デー
    タ処理装置の主記憶装置および補助記憶装置である請求
    項１記載のデータベース処理方法。
JP58242024A 1983-12-23 1983-12-23 データベース処理方法 Expired - Lifetime JPH0724036B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP58242024A JPH0724036B2 (ja) 1983-12-23 1983-12-23 データベース処理方法
US06/684,789 US4644471A (en) 1983-12-23 1984-12-21 Method for processing a data base
US07/015,694 US4785400A (en) 1983-12-23 1987-02-17 Method for processing a data base

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP58242024A JPH0724036B2 (ja) 1983-12-23 1983-12-23 データベース処理方法

Publications (2)

Publication Number Publication Date
JPS60134945A JPS60134945A (ja) 1985-07-18
JPH0724036B2 true JPH0724036B2 (ja) 1995-03-15

Family

ID=17083130

Family Applications (1)

Application Number Title Priority Date Filing Date
JP58242024A Expired - Lifetime JPH0724036B2 (ja) 1983-12-23 1983-12-23 データベース処理方法

Country Status (2)

Country Link
US (2) US4644471A (ja)
JP (1) JPH0724036B2 (ja)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4888690A (en) * 1985-01-11 1989-12-19 Wang Laboratories, Inc. Interactive error handling means in database management
US5097408A (en) * 1985-01-11 1992-03-17 Wang Laboratories, Inc. Apparatus for specifying a result relation in a relational database system by selection of rows
US4769772A (en) * 1985-02-28 1988-09-06 Honeywell Bull, Inc. Automated query optimization method using both global and parallel local optimizations for materialization access planning for distributed databases
US4839799A (en) * 1985-07-29 1989-06-13 Hitachi, Ltd. Buffer control method for quickly determining whether a required data block is in the buffer
JP2644728B2 (ja) * 1986-01-27 1997-08-25 株式会社日立製作所 データディクショナリ・ディレクトリシステム
US4967341A (en) * 1986-02-14 1990-10-30 Hitachi, Ltd. Method and apparatus for processing data base
US4858146A (en) * 1986-08-13 1989-08-15 The Babcock & Wilcox Company Automated design of structures using a finite element database
US5123103A (en) * 1986-10-17 1992-06-16 Hitachi, Ltd. Method and system of retrieving program specification and linking the specification by concept to retrieval request for reusing program parts
US4918593A (en) * 1987-01-08 1990-04-17 Wang Laboratories, Inc. Relational database system
US4805099A (en) * 1987-04-17 1989-02-14 Wang Laboratories, Inc. Retrieval of related records from a relational database
US4791561A (en) * 1987-04-17 1988-12-13 Wang Laboratories, Inc. Interactive construction of means for database maintenance
US5058000A (en) * 1987-06-30 1991-10-15 Prime Computer, Inc. System for accessing remote heterogeneous database including formatting retrieved data into applications program format
US5072367A (en) * 1987-10-01 1991-12-10 International Business Machines Corporation System using two passes searching to locate record having only parameters and corresponding values of an input record
US4884218A (en) * 1987-10-01 1989-11-28 International Business Machines Corporation Knowledge system with improved request processing
US5008819A (en) * 1987-10-07 1991-04-16 Gorbatenko George G Memory spaced array
ATE147523T1 (de) * 1987-10-07 1997-01-15 George G Gorbatenko Speicherraumfeldanordnung zur speicherung von relationalen daten
EP0320266A3 (en) * 1987-12-11 1992-03-11 Hewlett-Packard Company View composition in a data base management system
US4961134A (en) * 1988-07-15 1990-10-02 International Business Machines Corporation Method for minimizing locking and reading in a segmented storage space
US5247665A (en) * 1988-09-30 1993-09-21 Kabushiki Kaisha Toshiba Data base processing apparatus using relational operation processing
US5197130A (en) * 1989-12-29 1993-03-23 Supercomputer Systems Limited Partnership Cluster architecture for a highly parallel scalar/vector multiprocessor system
US5623650A (en) * 1989-12-29 1997-04-22 Cray Research, Inc. Method of processing a sequence of conditional vector IF statements
US5222235A (en) * 1990-02-01 1993-06-22 Bmc Software, Inc. Databases system for permitting concurrent indexing and reloading of data by early simulating the reload process to determine final locations of the data
US5210870A (en) * 1990-03-27 1993-05-11 International Business Machines Database sort and merge apparatus with multiple memory arrays having alternating access
US5272628A (en) * 1990-04-16 1993-12-21 Microsoft Corporation Method and system for aggregating tables having dissimilar formats
US5287494A (en) * 1990-10-18 1994-02-15 International Business Machines Corporation Sorting/merging tree for determining a next tournament champion in each cycle by simultaneously comparing records in a path of the previous tournament champion
GB2252853B (en) * 1991-02-13 1994-06-01 Fexco Management Services Limi A data storage and retrieval apparatus
US5423038A (en) * 1992-10-14 1995-06-06 Davis; Marilyn Specialized data management method
GB2298941B (en) * 1993-10-22 1998-02-04 Fdc Inc Database using table rotation and bimapped queries
BR9407962A (pt) * 1993-11-02 1996-12-03 Paracom Corp Aparelho para processamento acelerado de transaçoes com base de dados de computador
CA2130065C (en) * 1994-08-12 1999-03-02 Michael Joel Cincinatus Utilizing pseudotables as a method and mechanism for providing database monitor information
US5819276A (en) * 1995-10-06 1998-10-06 International Business Machines Corporation Method for supporting multiple file-systems in file input/output operations
FR2791790B1 (fr) * 1999-04-02 2001-06-22 Bull Sa Procede de preconditionnement et de codage d'une table de donnees, et procede de mise en oeuvre de requetes tabulaires sur une machine a capacites vectorielles
US6507846B1 (en) * 1999-11-09 2003-01-14 Joint Technology Corporation Indexing databases for efficient relational querying
US6275822B1 (en) * 1999-11-09 2001-08-14 Joint Technology, Corporation Maintaining very large indexes supporting efficient relational querying
US6701424B1 (en) * 2000-04-07 2004-03-02 Nintendo Co., Ltd. Method and apparatus for efficient loading and storing of vectors
US6938031B1 (en) * 2001-10-19 2005-08-30 Data Return Llc System and method for accessing information in a replicated database
US20040223292A1 (en) * 2003-05-05 2004-11-11 Murphy David Mark Anthony Interconnection of software and consumer electronics functional modules in multifunction devices
US7734581B2 (en) * 2004-05-18 2010-06-08 Oracle International Corporation Vector reads for array updates
EP1787228A4 (en) * 2004-09-10 2009-09-09 Suggestica Inc USER PRODUCTION AND CLASSIFICATION OF EQUIPMENT FOR THE PERFORMANCE OF A SEARCH AND USER INTERFACE THROUGH A HIERARCHY-FREE QUANTITY OF THEMES
US20100241638A1 (en) * 2009-03-18 2010-09-23 O'sullivan Patrick Joseph Sorting contacts

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5621273A (en) * 1979-07-27 1981-02-27 Fujitsu Ltd Data base processing system
JPS583031A (ja) * 1981-06-30 1983-01-08 Fujitsu Ltd リレ−シヨナル・モデルにおけるジヨイン演算処理方式
US4631664A (en) * 1983-07-19 1986-12-23 Bachman Information Systems, Inc. Partnership data base management system and method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
情報処理学会第２６回（昭和５８年前期）全国大会講演論文集Ｐ．１６５−１６６
情報処理学会第２７回（昭和５８年後期）全国大会講演論文集Ｐ．６７７−６７８

Also Published As

Publication number Publication date
US4644471A (en) 1987-02-17
US4785400A (en) 1988-11-15
JPS60134945A (ja) 1985-07-18

Similar Documents

Publication Publication Date Title
JPH0724036B2 (ja) データベース処理方法
US7440947B2 (en) System and method for identifying query-relevant keywords in documents with latent semantic analysis
US5995962A (en) Sort system for merging database entries
JP3849279B2 (ja) インデクス作成方法および検索方法
US5560007A (en) B-tree key-range bit map index optimization of database queries
JP3914662B2 (ja) データベース処理方法及び実施装置並びにその処理プログラムを記憶した媒体
JPH083817B2 (ja) データベース検索方法
JP3205406B2 (ja) 参照対象変数決定処理方法および翻訳処理システム
WO2008038416A1 (fr) Dispositif de recherche de document et procédé de recherche de document
Bitton et al. Performance of complex queries in main memory database systems
JPH0652161A (ja) 文書処理方法及び文書処理装置
JP3653333B2 (ja) データベース管理方法およびシステム
Rahman et al. Analyze Database Optimization Techniques
JPH06348757A (ja) 文書検索装置および方法
JPH08235033A (ja) オブジェクト指向データベース管理システムにおける結合演算方式
JPS617936A (ja) 情報検索方式
JP3859044B2 (ja) インデクス作成方法および検索方法
JPH07210569A (ja) 情報検索方法および情報検索装置
JPS61141035A (ja) デ−タ検索方式
JPH06180717A (ja) データベース検索方式
JPS63118958A (ja) 索引フアイル記憶装置
Hawking High Speed Search of Large Text Bases On the Fujitsu Cellular Array Processor,"
JPH0752450B2 (ja) 辞書デ−タ検索装置
Gustavson The automatic revision of storage structures
JPH05314169A (ja) 並列データ処理装置および並列形態素抽出方法