JP3980326B2 - データ管理方法およびコンピュータ読み取り可能な記録媒体 - Google Patents
データ管理方法およびコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP3980326B2 JP3980326B2 JP2001335175A JP2001335175A JP3980326B2 JP 3980326 B2 JP3980326 B2 JP 3980326B2 JP 2001335175 A JP2001335175 A JP 2001335175A JP 2001335175 A JP2001335175 A JP 2001335175A JP 3980326 B2 JP3980326 B2 JP 3980326B2
- Authority
- JP
- Japan
- Prior art keywords
- row
- facade
- data
- address value
- data management
- 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 - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ管理方法およびデータを管理するプログラムを格納したコンピュータ可能な記録媒体に関し、さらに詳細には、計算機などの主記憶上に構成され、あるいは計算機などにおいて実行可能な各種アプリケーションシステムにおいて用いるのに好適なデータ管理方法およびコンピュータ読みとり可能な記録媒体に関する。
【０００２】
【従来の技術】
計算機を用いて実行されるアプリケーションシステムにおいて、データベースは通信と並んで中核技術に位置づけられ、特に性能や拡張可能性を決定する重要な要因となっている。現在、「データベース」といえば、ＯＯＤＢ（Object Oriented DataBase）なども一部では利用されているが、通常はＲＤＢ（Relational DataBase）をさすことが多い。
【０００３】
ＲＤＢを始めとする従来のＤＢＭＳ（DataBase Management System）は、「スキーマ」と呼ばれるデータ管理の枠組みを使っている。スキーマを用いた管理とは、予めデータを組織化するための枠組み（スキーマ）を決めておき、データを、スキーマを構成する「データ項目(attribute)」と呼ばれる単位データの集合に基づいて、登録、更新、削除、検索を行うものである。ＲＤＢにおいては、データを登録する枠組みは「テーブル」、登録されるデータレコードは「タプル」と呼ばれる。
【０００４】
スキーマは、１つのテーブルに登録される複数のタプルの構成を１つに規定するものである。ユーザは予めスキーマを定めたいくつかのテーブルに、スキーマによって定められた構成のタプルを登録したり、スキーマに規定された範囲内でタプルの内容を変更することによって、データの保存及び処理（更新）を行う。このような方式においては、少数のテーブルのそれぞれに同じ構成の多数のタプルを登録すれば事足りる場合以外は、次に述べるような点でデータの保存及び処理が効率的に行えないという問題がある。このため、効率低下が著しく、実用に耐えないということも希ではなかった。
【０００５】
まず、本来可変長であるデータを扱う必要がある場合でも、データベース上ではそれを固定長のデータとして扱わざるをえない。このため、データ保存のための記憶領域が増加したり、余計な処理手順が必要になったりする。例えば、一個人が複数の自動車を所有することは珍しくないが、長大な個人情報のレコードの一部にこのような同種のデータが不定個数含まれる場合、従来のデータベースでこれを扱うには次のような方法が一般的である。
【０００６】
（１） 不定個数の最大値を想定してその数だけデータ項目を備えたスキーマを使用する。
【０００７】
（２） そのデータ項目を１個としたスキーマを使用し、そのデータ項目の値を複数含むようなデータを扱う場合は、そのデータ項目の値のみが異なり、他のデータ項目の値は同一のタプルを複数登録する。
【０００８】
（１）の方法は空値を含むタプルを登録するという点で効率を低下させるおそれがある。（２）の方法もまた、１つのデータ項目を除いて他が全て同じタプルを重複して登録するという点で効率を低下させるおそれがある。これらの効率の低下を防ぐには、空値や重複を効率良く圧縮する特別な手段を追加する必要がある。
【０００９】
特に、そのようなデータ項目が複数種類（例えば自動車だけでなく、保険契約も）１つのデータ（個人情報）に含まれる場合、（２）の方法による効率低下は顕著になる。これを避けるために、不定（可変）個数のデータ項目は別のテーブルとし、そのテーブルのタプルと元のタプルとの関連を、両者に共通のユニークな識別子データを含ませることによって実現する。このような場合に、本来のデータには無かった余分な識別子データ項目が導入されることがある。
【００１０】
【発明が解決しようとする課題】
このような扱いの問題点は、本来ひとまとまりとして扱うべきデータが複数のテーブルに分散してしまう上に、それらを相互にアクセスするためには識別子をキーとする検索というコストがかかる操作を要することである。
【００１１】
（１）の方法に関しても、効率低下だけでなく想定した最大値をさらに越えた数の同種データを含むデータを扱う必要が生じた際に、スキーマを変更してデータベースを再生成しなければならないという別の問題点がある。このような場合に限らず、スキーマを用いる従来のデータベースではスキーマの変更を伴うようなアプリケーションの拡張・変更に際しては、アプリケーションへのサービスを停止してデータベースを再生成する必要があるので、連続稼働を要求されるアプリケーションシステムの随時拡張は困難であった。
【００１２】
以上説明したように、これらの問題は全てスキーマに起因して生じるものである。
【００１３】
本発明は、以上詳述した課題の認識に基づいてなされたものであり、その目的は、データベースを作成してアプリケーションへのサービスを開始した後に、当初の想定と異なる形式のデータを扱う必要が生じた場合でも、アプリケーションへのサービスを中断すること無く柔軟かつ効率的にデータベースの拡張を行うことができるデータ管理方法を提供することにある。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明の一態様のデータ管理方法は、アドレスで識別される複数の記憶領域にそれぞれ別々のインデクスを対応付け、記憶領域へのアドレス値を含むレコードに対応するエントリを、含まれるアドレス値毎に対応付けて作成し、そのポインタで識別される記憶領域に対応付けられたインデクスに登録することを特徴とする。
【００１５】
なお、前記インデクスは前記エントリをソートして管理し、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードの内容を使用しても良い。
【００１６】
なお、前記エントリのソート順を決定するキーは、エントリ毎に指定しても良い。
【００１７】
なお、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値で指示される記憶領域の内容を使用しても良い。
【００１８】
なお、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値そのものを使用しても良い。
【００１９】
なお、前記アドレス値を含むレコードの更新に伴って、前記インデクス中のエントリの各キーがソート順に矛盾しないように必要に応じてエントリの順序を修正しても良い。
【００２０】
なお、前記アドレス値の参照先記憶領域の内容の更新に伴って、前記インデクス中のエントリの各キーがソート順に矛盾しないように必要に応じてエントリの順序を修正しても良い。
【００２１】
なお、指定されたキーでインデクスを検索するようにしても良い。
【００２２】
なお、指定した内容を持つ前記記憶領域を決定し、その記憶領域に対応付けられた前記インデクスを検索しても良い。
【００２３】
なお、前記インデクスを検索した結果得られたエントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値の参照先記憶領域に対応付けられたインデクスを更に検索しても良い。
【００２４】
さらに、これらのデータ管理方法を実行可能な各種の形態のソフトウエアも、本発明に含まれる。さらに、これらのデータ管理方法を応用した各種のアプリケーションも、本発明に含まれるものである。
【００２５】
ここで、「記録媒体」とは、例えば、ハードディスク（ＨＤ）、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＯＭ、フレキシブル・ディスク（ＦＤ）やＣＤ−ＲＯＭなどの他に、ＲＡＭやＲＯＭなどの各種メモリも含む。
【００２６】
また、これらの媒体に記録されるべきプログラムを暗号化したり、変調をかけたり、圧縮したような状態で、イントラネットやインターネットなどの有線回線や無線回線を介してあるいは記録媒体に格納して頒布しても良い。
【００２７】
以上説明したように、本発明は単位データを指示するアドレス値に対応するエントリを、単位データに対応づけられたインデクスに登録することによって、スキーマを用いることなく検索可能な形にデータを組織化するものである。この方法を採用することによって、固定的なスキーマを使用する従来のデータベースでは扱うことが困難であった可変長のデータが容易に扱えるようになるだけでなく、従来のデータベースではスキーマの変更を伴うので非常に効率が悪かったデータ形式の変更が、通常のデータ更新と同様の操作によって行うことができる。
【００２８】
それ故、本発明によれば、データベースを作成してアプリケーションへのサービスを開始した後に、当初の想定と異なる形式のデータを扱う必要が生じた場合でも、データベースの再生成等によって、アプリケーションへのサービスを中断すること無く柔軟かつ効率的にデータベースの拡張を行うことができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しつつ本発明の実施の形態について説明する。
【００３０】
本発明は、データの構築単位（以下、インスタンスとも云う）として、その記号表現（コード）を格納するための領域（セル）に、それに関連した複数のインスタンスの間の関係をポインタの列で表すデータ（ロウ）を格納する領域（ファサード）を付随させたデータ構造を採用することによって、データの効率的な操作（登録、更新、削除、検索）を実現するものである。
【００３１】
図１は、セルの構造を表す概念図である。セルは、同図に表したように、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）などのプログラム言語における１次元配列に相当する。セルに格納するコードには種々のデータの「データ型」を用いることができる。
【００３２】
データ型には、文字、ｂｙｔｅストリームデータ、符号なし整数値（ビット長：８／１６／３２／６４）、符号付き整数値（ビット長：８／１６／３２／６４）、浮動小数点実数値、倍精度浮動小数点実数値、などがある。以下の説明では、図１に例示したように、セルの図表現を矩形により表し、セルに格納するコードを矩形の中に記すことにする。セルはデータ管理技術一般における「単位データ」すなわちデータ項目の個々の値を格納する機能に相当する概念である。
【００３３】
図２は、インスタンスの構成を表す概念図である。セルとファサードは１つのインスタンスの構成要素として同時に生成される。インスタンス（セルとファサード）はその領域を識別するアドレスで同定する。セルに格納されたコードは単独でインスタンスを同定するものではないが、後述するようにレキシコンの中でのインスタンスの検索や、ファサードの中のロウの検索のように限定された文脈での識別に使用される。
【００３４】
ファサードには後述するコンテクストを検索するためのロウが登録される。ファサードはデータ管理技術一般における「インデクス」に類する概念であり、ロウはそのインデクスに登録される「エントリ」に対応する概念である。インスタンスは、データをコードとして格納する手段であるセルと、データ（インスタンス）間の関係をロウとして格納する手段であるファサードを一体化したものである。本発明では、データの格納手段（セル）とデータの管理手段（ファサード）とが一つの構造（インスタンス）で扱われているので、ＲＤＢのようにデータ管理のための特別なデータ（テーブル）のようなものがなくても、データを構造化することができる。
【００３５】
セルとファサードの図表現は、図２のように、セルとファサードそれぞれを上下に連続した２つの矩形により表現する。上部がセルで、下部がファサードである。なお、セルにはファサードが必ず付随するが、ファサードには必ずしもロウが登録されているとは限らない。すなわち、空のファサードもありうる。ファサードにロウが登録されているかどうかを区別するため、図面においては、空のファサードと、ロウが登録されているファサードとを適宜区別して表す。また、セル及びファサードはインスタンス作成時に予め固定の大きさの領域を割り付ける必要がなく、格納されるコードの量やロウの数に応じて記憶領域を割り付けるような実現方法をとることも可能である。
【００３６】
インスタンスは「レキシコン」により管理される。すなわち、「レキシコン」とは、「データ集団名」に相当する概念である。
【００３７】
図３は、レキシコンにより管理されたインスタンス群を例示する概念図である。同図に例示したように、インスタンスは、必ずどこかのレキシコンに登録される。レキシコンは、複数存在し、それらは「レキシコン・セット」により管理される。それぞれのレキシコンには固有の名前が与えられており、この名前によってレキシコン・セットから特定のレキシコンを検索できる。アプリケーションはその処理に必要なレキシコンをその名前によってレキシコン・セットから検索し、次に、そのレキシコンの下に管理されているセルをその内容によって検索することにより、欲しいセルを得ることができる。
【００３８】
図３は、レキシコン・セットから“従業員”レキシコンを検索し、次に、"佐藤"インスタンスを検索するプロセスを例示している。
【００３９】
セルに格納するコードはそのセルのインスタンスが所属するレキシコンの下には基本的には１つしか存在しないものとすることができる。つまり、同じコードを持つ別のインスタンスは存在せず、重複を許さないことを基本とすることができる。この場合には、レキシコン中という限定された範囲でセルのコードは、インスタンスを識別・検索するキーとして機能する。
【００４０】
これに対して、セルの変数的な使い方もできる。この場合には、同じコードを異なるインスタンスのセルに格納することも可能である。これは、アプリケーションでどのようなデータを扱いたいかで決めれば良い。例えば、人名には「同姓同名」が存在する（つまり同姓同名で別人がある）が、それらを別物として管理したければ、同じコードではあるが別々のインスタンスのセルに格納すれば良い。
【００４１】
インスタンスがレキシコンに登録されただけでは、単に単位データがバラバラに存在するだけであり、セルの内容によりレキシコンから検索できるだけである。
【００４２】
図４は、ある従業員データを構成する個々の要素をインスタンスとし、"従業員"レキシコンに登録した状態を例示する概念図である。この状態では、インスタンスがバラバラにレキシコンに連なっているだけで、インスタンス同士の関連を扱うことはできない。データベースが通常扱うデータは、これら単位データを組み合わせたり関連づけたりしたものである。ＲＤＢにおけるタプルやファイルのレコードがこれに当たる。このようなデータの例として図２２に示すデータを使用して、インスタンス間の関連を扱う方法を説明する。
【００４３】
すなわち、この図２２に示す例においては、姓、入社年度、所属部門、役職、内線により区分された従業員の情報が与えられている。
【００４４】
本発明によれば、このような管理すべきデータが、図４に例示したようにバラバラにインスタンスのセルに格納される。ここで、本発明の特徴のひとつは、重複したデータをひとつのセルで管理できる点にある。例えば、図２２において、「入社年度」を見ると、６名の従業員のうちの３名の入社年度は「１９８１」である。このような場合に、本発明においては、「１９８１」に対応する３つのデータを格納する必要がなく、図４に例示したように、「１９８１」が格納されたセルを有するインスタンスをひとつ管理すれば良い。後に詳述するように、必要に応じて、このインスタンスを何回でも指定できるからである。これは、「所属部門」や「役職」に関する重複データについても同様である。本発明によれば、このように重複するデータがある場合に、データ格納領域を大幅に節約できるという効果が得られる。
【００４５】
次に、図４に表したように、"従業員"レキシコンに登録されているバラバラのデータを、図２２の１行のデータ列、例えば「斎藤・１９８１・工場・課長・３６９１」のような１つの意味のあるデータ群として扱う方法手段として、本発明においては図５に示すような「コンテクスト」という構造を用いる。コンテクストはデータ管理技術一般における「レコード」に類する概念である。
【００４６】
すなわち、「コンテクスト」は、インスタンスを参照するポインタデータの１次元配列である。つまり、コンテクストにはデータの実体（コード）は格納されず、コードを管理するインスタンスを指し示すポインタが格納される。この実施形態においては、インスタンスが格納される各領域のアドレスが、インスタンスに対するポインタとして用いられる。コンテクストは、関連させたい複数個のセルのインスタンスを指定するように形成される。そして、コンテクストに格納されているポインタデータから、セルを参照することができる。
【００４７】
本発明において、リンクを図表現する際は、セル同様矩形で表し、ポインタの指し示すセルを（）で囲ってポインタ表現とする。例えば、（斎藤）は、斎藤という内容を持つセルのインスタンスを参照するポインタを表す。
【００４８】
コンテクストによって、インスタンスに格納された要素データ間の関係を表すが、データの関連性は、図２２のような設計データの静的な関連だけでなく、アプリケーションが必要とする検索方式にも依存する。従って、コンテクストは、アプリケーションにおける設計データを基にアプリケーションが必要とする検索方式を加味して構成することになる。
【００４９】
図６は、設計データとコンテクストとの関係を表す概念図である。
【００５０】
また、図７は、コンテクストを構成する処理手順を表すフローチャートである。
【００５１】
図６に表した例では、図６（ａ）の表の設計データを２種類の検索パターンで検索するアプリケーションを開発したいとする。これをデータ管理装置で実装するには、まず２種類の検索パターンを表現するデータを設計データに追加する必要がある。このデータは、後で説明するように、「ファサード」として機能することになる。このために、まず、図７にステップＳ１及びＳ２として表したように、検索パターンのそれぞれにファサード名を割り当てる。例えば、２つの検索パターンにそれぞれ”分類１”と、”分類２”という名前を付ける。さらに、図４に表したように、これら検索パターンのデータ（「分類１」と「分類２」）をレキシコンにも追加しておく。
【００５２】
次に、ステップＳ３において、元の設計データの１行のデータを取り出す。そして、ステップＳ４において、検索パターンのファサード名を各行のデータ列に追加する。この段階では、１行のデータは実体コードのデータ列である。この実体コードのデータ列を、コードを管理するインスタンスを指し示すポインタ列に置き換えるとコンテクストができあがる。これらの処理はステップＳ５により、検索パターンの数だけ繰り返し、さらにステップＳ６により、設計データの行数だけ繰り返す。
【００５３】
この例では、図６（ｂ）に表したように、設計データに対応した６種類のコンテクストができる。
【００５４】
次に、複数のコンテクストを纏めたり、それらを検索したりできるように、コンテクストの複数の要素（ポインタ）を選択して並べ替えたもの（コンテクストの要素の順列）を、「ロウ」としてその先頭の要素が参照するインスタンスのファサードに登録する。
【００５５】
なお、コンテクストもロウも、それぞれ個別にアドレスを持っており、インスタンス同様にアドレスで（ポインタとして）アクセスすることができる。そして、データ管理装置による検索などの処理結果の戻り値にこれらのアドレスを用いる。
【００５６】
ロウとその元になったコンテクストとは、ポインタで関連付けておき、ロウの各要素とコンテクストの各要素との対応関係が相互に決定できるようにする。ファサードにロウを登録する際には、先頭から何番目の要素までを連結キーとしてファサード内のロウの順序付け（ソーティング）に使用するかを指定する。
【００５７】
「連結キー」とは、優先順位付きのキー（この場合はロウ（コンテクスト）の要素）の集まりである。連結キー同士の比較においては、上位のキーが全て同一の場合に限り、下位のキーの比較順序を連結キーとしての比較順序とする。それらが一致しない場合は、一致しない上位のキー間の関係（順序）がそれらの間の比較結果として取られる。各要素がキーとして比較される場合には、それらが参照するインスタンスのセルのコードが比較される。
【００５８】
図８は、ファサードに登録されたロウの一例を表す概念図である。ポインタ（分類１）を格納した要素を先頭とするロウがインスタンス”分類１”のファサードに登録されている。
【００５９】
また、コンテクストをロウとしてファサードに登録する際には、コンテクストのすべてのデータを登録する必要はない。例えば、図８の例では”分類１”ファサードに登録したロウには、他の検索で使用する”分類２”は使う必要が無いので、”分類２”はロウには含まれていない。さらにロウの全ての要素が連結キーとして使用されるわけではなく、先頭から指定した個数だけが使用される。例えば、図８の例では、”分類１”ファサード内の５番目のロウは、このロウに対応するコンテクスト内に含まれる（１９８１）、（本社）をそれぞれ第１キー、第２キーとして用い、ロウの残りの要素はファサード内のロウのソート順には関係しない。
【００６０】
以上の説明から分かるように、ロウはコンテクストを元にしてファサードに登録されるが、その内容はロウとして登録する際に指定した順序で以下の如く並びかえられたものである。
【００６１】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類1)(1981)(本社)(佐藤)(課長)(6354)
ロウの（分類１）は登録ファサードを、(１９８１)は第１キーを、(本社)は第２キーを、それぞれ示し、(佐藤)(課長)(6354)はキーとして使用されない
以上で説明したデータ管理方式の実現方法であるが、例えばこの構造、特にファサード−ロウの部分を、スプレイ・ツリー・アルゴリズムで実装することが考えられる。なお、スプレイ・ツリー・アルゴリズムについて開示した文献としては、例えば、Robert E. Tarjan, "Data Structure and Network Algorithms", the Society for Industrial and Applied Mathematics,1983 を挙げることができる。スプレイ・ツリー・アルゴリズムは、動的に変化する２分木で、データアクセスが発生する毎にスプレイ操作を実行する。
【００６２】
図９は、スプレイ・ツリー・アルゴリズムにおけるスプレイ操作を例示する概念図である。図９において、スプレイ操作は、次のようなステップで行う。例えば、検索処理を行うとルートからノードを検索キーと比較しながら降りてきて、最終的に検索対象に到達する。そのノードを（ｘ）とすると、（ｘ）の前後のツリーの構造が図９に表した３種類のパターンのいずれかに該当するので、それを選んでツリーの構造を変える。この処理で、（ｘ）はツリーの構造を１段上がることになるが、今度は新しい位置で、再度（ｘ）の前後のツリー構造を見て図９のいずれかの構造を選び、同様に処理する。この処理を続けると、最終的にはツリーのルート（頂点）に到達する。
【００６３】
このようなスプレイ操作を通じて、偏りのあるデータアクセス適応して効率的に検索・更新を処理する２分木ができる。これをファサードにおけるロウの管理に用いることでデータを、効率的にソートして管理することができる。
【００６４】
スプレイ・ツリー・アルゴリズム以外にもソートされたデータの管理法は各種知られているが、これらのデータ管理方式を用いても同様の効果を得ることができる。本発明においては、図１乃至図８に関して前述したデータ管理構造の方式が本質的な部分であり、物理的な実装方式には依らずに上記効果を発揮することができる。
【００６５】
（具体例）
以下、具体的なデータに即して、データの登録及び検索の方法を具体的に説明する。
【００６６】
まず、本実施例における問題設定を説明する。扱いたいデータは、図２２に表した従業員データである。
【００６７】
データ項目は、「姓」、「入社年度」、「所属部門」、「役職」、「内線」の５種類であり、全部で６件のデータからなる。本実施例では、このようなデータを２種類の検索パターンで分類する。第１の検索パターンは、入社年度を第１キーに、所属部門を第２キーにするもので、第２の検索パターンは内線を第１キーにするものである。
【００６８】
以下、各データに関してコンテクストからどのようにロウが形成され、どのようにファサードに登録されるかを説明する。
【００６９】
図１０は、本実施例におけるデータ管理方法の手順を表すフローチャートである。
【００７０】
まず、最初に、ステップＳ１１において、設計データを構成するインスタンスをレキシコンに登録する。図１１は、インスタンスがレキシコンに登録された状態を表す概念図である。図示した如く、レキシコンとインスタンスのツリーができあがる。
【００７１】
次に、ステップＳ１２においてコンテクストを形成する。本実施例におけるコンテクストは、例えば、図１１の右下に表したようになる。
【００７２】
次に、ステップＳ１３において、これらのコンテクストからロウを形成し、これを所定のファサードに登録する。本実施例においては、コンテクストは、”分類１”と”分類２”のそれぞれのインスタンスのファサードに、図１２及び図１４に表された検索パターンで登録される。
【００７３】
具体的には、まず、最初に、図１２に表したように、”分類１”ファサードに、同図に表した検索パターンに従ったロウを登録する。
【００７４】
その結果、図１３に表したように、”分類１”ファサードには１件のロウが登録される。すなわち、コンテクストから、登録ファサード、第１キー、第２キー、その他の順に要素を選択して並べたロウを作成して登録する。
【００７５】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類1)(1981)(本社)(佐藤)(課長)(6354)
なお、ここで、(分類２)がこのロウには含まれないこと、及び、先頭の(分類１)がロウの登録ファサードのインスタンスを参照していることに注意されたい。この登録の結果として、”分類１”ファサードには１件のロウが登録されるが、その他のインスタンスのファサードは相変わらず空のままである。
【００７６】
次に、ステップＳ１４において上述のロウ登録操作を検索パターンの数だけ繰り返す。
【００７７】
具体的には、図１４に表したように、”分類２”ファサードにロウを登録する。この際には、同図に表したキー順位で登録する。その結果、”分類２”ファサードには１件のロウが図１５のように登録される。すなわち、コンテクストから、登録ファサード、第１キー、第２キー、その他の順に要素を選択して並べたロウを作成して登録する。
【００７８】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類2)(6354)(佐藤)(本社)(課長)
ここでも、”分類１”ファサードへの登録と同様に、(分類１)および(1981)がこのロウには含まれないこと、及び、先頭の(分類２)がロウの登録先ファサードのインスタンスを参照していることに注意されたい。この登録の結果として、”分類１”ファサードと”分類２”ファサードにはそれぞれ１件のロウが登録されるが、その他のインスタンスに付随するファサードは空のままである。
【００７９】
以下、ステップＳ１５において、上述のコンテクスト形式（ステップＳ１２）以降の処理をコンテクストの件数、すなわちデータの件数だけ繰り返す。
【００８０】
まず、２番目のコンテクストを、前と同様に”分類１”ファサードと”分類２”ファサードに登録する。図１６は、このようにしてそれぞれのファサードに２件のロウが登録された状態を表す概念図である。ロウはそれぞれのファサードで連結キー順にソートされている。
【００８１】
以下、このようにして６件すべてのデータのコンテクストを形成し、それぞれを検索するためのロウをファサードに登録する。図１７は、６件のコンテクストと１２件のロウが登録された状態を表す概念図である。これですべてのデータが登録され、検索の準備ができたことになる。
【００８２】
次に、本発明のデータ管理方法における検索手順について説明する。
【００８３】
図１８は、本検索手順を表すフローチャートである。
【００８４】
また、図１９は、本検索手順を説明するための概念図である。
【００８５】
本発明においては、検索のために、まずステップＳ２１において、検索したいパターンに対応するファサードを検索する。具体的には、まず最初に、与えられたレキシコン・セットから、アプリケーションの処理に必要となるレキシコンをその名前により検索する。例えば、本実施例の場合は、"従業員"レキシコンを検索する。
【００８６】
次に、必要とするデータをそのレキシコンにおいて検索する。最初にファサードを探してこなくてはならないが、これは上記ファサードを含むインスタンスをレキシコンから探せば良い。本実施例では、”分類１”インスタンスを、コード”分類１”をキーとしてレキシコンから検索してくる。
【００８７】
次に、ステップＳ２２において、ファサード内に登録されているロウを所望のキーで検索する。本実施例の場合は、第１キー＝”１９８１”、第２キー＝”本社”により検索して所望のロウを獲得する。
【００８８】
次に、ステップＳ２３において、ロウの中の要素から所望のインスタンスを、ポインタを参照することにより求める。すなわち、得られたロウの中からアプリケーションで必要なデータを見つけ出す。例えば、本具体例においては、検索されたデータの「姓」の項が欲しいので、ロウ内の４番目の要素であるポインタが指し示すインスタンスのセルから、所望のデータである”佐藤”を得る。
【００８９】
以上説明した具体例の場合は、ロウから直接セルを参照しているが、もっと複雑な検索の場合は、コンテクストに溯って別なデータへアクセスしたりすることも可能である。いずれにしても、基本となる検索手順はファサードからロウを確定することであり、これを中心に検索処理を組み立てればよい。
【００９０】
なお、上記説明では、”分類１”インスタンスをレキシコンから検索して得たが、”分類１”インスタンスを得る方法は、これに限られるものではない。例えば、”分類２”インスタンスのファサードからそこに登録されたエントリに対応するコンテクストを得、そのコンテクストの先頭要素を参照先として”分類１”インスタンスを得ることができる。すなわち、ファサードは通常のデータ検索の手段によって決定することができるのであり、この点が、スキーマやメタデータの管理手段が通常のデータ管理手段と別になっている従来のデータベースと根本的に異なっている。
【００９１】
次に、本発明のデータ管理方法を実行可能なデータ管理装置について説明する。
【００９２】
図２０は、上述したデータ管理方法をハードウェア上に実現したデータ管理装置の概観を例示する鳥瞰図である。
【００９３】
また、図２１は、その要部構成を例示したブロック図である。
【００９４】
このデータ管理装置８０の本体は、データ入力部８０Ａと、データ処理制御部８０Ｂと、データ記憶部８０Ｃと、データ出力部８０Ｄと、を有する。
【００９５】
データ入力部８０Ａは、管理すべきデータを外部から入力する役割を有し、その入力手段としては、例えば、フレキシブルディスク装置（フレキシブルディスクドライブ）８１、光ディスク装置（光ディスクドライブ）８２などを具備している。フレキシブルディスクドライブ８１に対してはフレキシブルディスク８３を、また光ディスクドライブ８２に対してはＣＤ−ＲＯＭあるいはＤＶＤディスクなどの光ディスク８４をその挿入口から挿入し、所定の読み出し操作を行うことにより、これらの記録媒体に格納されたデータをシステム内に入力することができる。また、所定のドライブ装置を接続することにより、例えば半導体メモリ装置としてのＲＯＭ８５や、磁気テープ装置としてのカセットテープ８６を用いることもできる。さらに、キーボード８７によりデータを入力したり、ネットワーク回線８８を介して、他のコンピュータあるいはデータ出力装置からデータを入力することもできる。
【００９６】
このようにして入力されたデータは、データ記憶部８０Ｃに格納される。この際に、図１乃至図１９に関して前述したように、レキシコン・セット、レキシコン、セル、ファサード、コンテクスト、ロウなどが適宜形成される。これら一連の処理は、データ処理制御部８０Ｂにより実行される。また、ロウのソーティングや、ファサードに格納されたデータのスプレイングも、データ処理制御部８０Ｂにより実行される。
【００９７】
このようにして管理され、ソートされたデータは、必要に応じてデータ出力部８０Ｄにより出力される。データ出力部８０Ｄは、例えば、ディスプレイ８９や、フレキシブルディスク８３などの各種の媒体、あるいはネットワーク回線８８を介して所望のデータを外部に出力する。
【００９８】
後に詳述するように、本発明においては、データを格納するデータ記憶部８０Ｃとして、ＲＡＭなどの半導体メモリを用いることができる。その結果として、高速にデータを展開、管理することが可能となり、データ管理の性能を従来よりも大幅に改善することができる。
【００９９】
なお、本発明は、図１乃至図１９に関して前述したようなデータ管理方法が実行可能なソフトウエアも包含する。このようなソフトウエアは、データ読み取り部８０Ａに関して前述したものと同様に、光ディスク８４などの記録媒体に格納して、管理装置８０のデータ処理制御部８０Ｂにダウンロードすることが可能である。または、このようなソフトウエアは、ネットワーク回線８８を介してダウンロードすることもできる。
【０１００】
以上説明した本発明のデータ処理方法及びデータ処理装置の作用および効果を、引き続き実例データに即して説明する。
【０１０１】
まず、図２２において、扱うべきデータのうち、”斉藤”について、電話番号”２４０６”が”３６９１”に加えて割り付けられることになった場合について説明する。この状況は、例えば、図２３のように示される。
【０１０２】
本発明では、このように、データによって要素の個数が異なる場合でも、全てのコンテクストの要素数を最大個数に揃えたり、一部の要素だけが異なって他は同一のコンテクストを複数作成したりしなくても良い。また、１件のデータを複数のコンテクストに分割する必要もなく、それに伴う余分な識別データを追加する必要もない。すなわち、”斉藤”のデータに対応するコンテクストは、例えば図２４のように生成すれば良い。
【０１０３】
本実施例では、ロウをコンテクストから作成してファサードに登録する場合、ロウの登録ファサードを決定するロウの先頭要素とコンテクストの要素は１対１に対応するという制約がある。つまり、１つのコンテクストから作成できるロウの数の上限はその要素数に等しく、また、登録できるファサードは各要素が参照するインスタンスのファサードに限られる。そこで、同一のファサードに複数のロウを登録したい場合には、同一のインスタンスを参照する複数の要素を含ませる必要がある。この実例の問題設定では電話番号を第１キーとしてデータが検索できなければならないから、電話番号を２つ備えたデータについては、”分類２”ファサードで２つの電話番号をそれぞれキーとするロウを登録する必要がある。すなわち、”斉藤”のデータに対応するコンテクストからは”分類２”ファサードに登録する２つのロウを作成する必要があるので、電話番号を”2406”を参照する要素だけでなく、”分類２”インスタンスを参照する要素がもう１つ追加されている。
【０１０４】
この末尾に追加された（分類２）の要素を先頭とするロウは、アプリケーションが必要とする図２５に示す検索パターンに従って、図２６に示すように作成する。この検索パターンは姓が単なる属性ではなく第２キーに指定されている点で図１４に示す検索パターンと異なっている。これは、”2406”を第１キーとするロウが既にファサード中にあるので、これとの一意な識別を可能にするために連結キーを追加したのである。これに対応して、既にファサード中に存在した”2406”を第１キーとするロウについても、上記の新たに追加するロウとの一意な識別を可能にするために、図３１に示す姓を第２キーとする検索パターンに合致するようにロウの連結キーの個数を変更する。
【０１０５】
一方、同じく”分類２”ファサードに登録するロウでも、”3691”を第１キーとするロウは、登録前のファサードに”3691”を第１キーとするロウは含まれていないので、”3691”を第１キーとし他は単なる属性とする図３０の検索パターンで生成したロウを登録すれば一意に識別できる。これらのロウを登録及び修正した結果、”分類２”でファサードは図２７に示すようになる。
【０１０６】
また、”分類１”ファサードの各ロウには、対応するコンテクストに含まれる内線番号が要素として含まれている必要があるので、（分類１）を先頭とするロウの検索パターンとしては、他のロウより要素が１つ多い図３２の検索パターンからロウを生成する。
【０１０７】
図２７には、”分類１”、”分類２”ファサード及びコンテクスト、レキシコンを含めて、実例データから本実施例のデータ管理方法で作成・登録されたデータ構造が全て示してある。これをみると、”斉藤”のデータのみ形式が異なる６件の入力データそれぞれに対応して６つのコンテクストが作成されているので、元のデータとデータベースに登録されたデータ（コンテクスト）との対応関係は、良く保たれており、分割や複製によって、対応付けに余分な手間がかかることはない。更に、データの形式を一様にするために、空値の要素を追加する必要もなく、元のデータの形式が不揃いならそれを保ったままデータベースに登録ができる。また、コンテクスト毎にアプリケーションが必要とする検索パターンを自由に設定してロウをファサードに登録することができるので、データ（コンテクスト）の形式・内容がまちまちであっても、アプリケーションに必要な内容を過不足無く検索できるようにデータベースにロウを登録できる。上記の例に即して云えば、電話番号を２つ含むデータ（コンテクスト）はそれぞれの番号をキーとして、１つのファサードから検索できるようになっている。
【０１０８】
さて、本発明においては、形式の異なるコンテクストを、ロウを登録するという操作によって、ファサード単位に組織するとともに、連結キーによる検索の対象とすることができる。ファサードは、比較可能な（比較してソートすることに意義がある）ほどに類似したデータをまとめることができるという点で、従来のＲＤＢのテーブルやビューに相当する機能を保持する。しかしながら、各ファサードにおいては、そこに登録されるロウに関して、その先頭の要素がそのファサードのインスタンスを参照するコンテクストの要素であるということ以外は、何ら制約を設けない。したがって、従来のデータベースにおいて、データをまとめる機構に付随して必要であった、まとめられるデータの形式や内容に関する制約情報（いわゆるスキーマ情報）を保存・管理する必要がない。このため、従来のデータベースでは、スキーマの変更として扱わざるを得ないような変更も、単なるデータの変更として扱うことができるので、通常のアプリケーションへのサービスを一旦停止して、データベースを再生成するという特別な操作（アプリケーション）を行う必要がない。
【０１０９】
上記の実例データに即して説明する。図２８に示すような形式のデータのみが扱えればよいという前提でデータベースを設計し、実際にデータベース（レキシコン、インスタンス、コンテクスト、及びロウ）を生成してアプリケーションの用に供した後で、図２９に示すように、内線番号が２つある別の形式のデータを扱う必要が生じた場合を考える。
【０１１０】
本発明のデータ管理方法では、この形式のデータから上記のコンテクストを生成してロウをファサードに登録する手続を新たに用意する必要はあるものの、図２８のデータから生成された既存のデータベースに、ほとんど変更を加える必要がない。もちろん、再生成の必要もない。
【０１１１】
以上説明したように、本発明のデータ管理方法は、スキーマを用いる従来のデータベースでは、困難であった不揃いな形式のデータの扱いや、データの形式・内容の動的変更にも容易に対応できるデータ管理システムを提供することができる。更に、本発明のデータ管理方法によれば、既に登録されているデータが更新されている場合も、効率良くこれを処理することができる。単にデータを追加する場合については、データ登録処理として既に述べた。ここでは、登録されているコンテクストの一要素が変更される場合について説明する。
【０１１２】
引き続き、上記の実例データに関して、コンテクスト
（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(2406)(分類2)
の（2406)が、インスタンス”2406”ではなく、インスタンス”2409”を参照するように変更された場合を考える。この結果、コンテクストは、
（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(2409)(分類2)
に変更される。これに伴って、ロウ
(分類2)(2406)(斉藤)(工場)(課長)
は、
(分類2)(2409)(斉藤)(工場)(課長)
に変更されるので、”分類２”ファサード内でソート順を維持するために、このロウを
(分類2)(2409)(小林)(研究所)(部長)
の直後に移動する。これに対して、第１キーが（2409）のロウが２つになるが、このロウの一意な識別を可能にするためには、（小林）を第２キーとするように連結キーの個数を変更するだけでよい。同じコンテクストから、作成された他の２つのロウ
(分類2)(3691)(斉藤)(1981)(工場)(課長)
(分類1)(1981)(工場)(斉藤)(課長)(3691)(2406)
は、キーに変更が及ばないので、ファサード内の順序を移動する必要がない。これらの判断及び操作は、コンテクストの各要素とそれを含むロウとの対応が管理されているので効率よく行うことができる。
【０１１３】
なお、コンテクスト（ロウ）の要素の参照先を変更するのではなく、インスタンス”2406”のセルの内容を”2406 ”から”2409”に変更した場合は、同一のインスタンスを参照していた２つのロウ
(分類2)(2406)(斉藤)(工場)(課長)
(分類2)(2406)(藤原)(研究所)(主任)
を同時に
(分類2)(2409)(斉藤)(工場)(課長)
(分類2)(2409)(藤原)(研究所)(主任)
に変更することができ、”分類２”ファサードのロウの順序はこれに応じて図３３に示すように変更される。これらのロウの（2409）の参照先インスタンスは、
(分類2)(2409)(小林)(研究所)(部長)
の（2409）の参照先インスタンスとセルの内容は同一でも依然として異なるインスタンスである。”斉藤”と”藤原”が１つの内線番号を共有している。これは、インスタンスがセルの内容ではなく、アドレスで識別されることによる効果である。
【０１１４】
このように、既に登録されたデータの変更を行う場合でもデータの部分的な修正で全て済ますことができるので、多量のデータ登録のやり直しが必要になることはない。
【０１１５】
【発明の効果】
以上説明したように、本発明のデータ管理方法によれば、種々の形式のデータを柔軟かつ動的に扱うことができ、しかも効率的な検索・更新が可能である。
【図面の簡単な説明】
【図１】本発明におけるセルの構造を表す概念図である。
【図２】本発明におけるインスタンスの構造を表す概念図である。
【図３】レキシコンにより管理されたインスタンス群を例示する概念図である。
【図４】ある従業員データを構成する個々の要素をインスタンスとし、"従業員"レキシコンに登録した状態を例示する概念図である。
【図５】コンテクストを説明するための概念図である。
【図６】設計データとコンテクストとの関係を表す概念図である。
【図７】コンテクストを構成する処理手順を表すフローチャートである。
【図８】ファサードに登録されたロウの一例を表す概念図である。
【図９】スプレイ・ツリー・アルゴリズムにおけるスプレイ操作を例示する概念図である。
【図１０】本発明の実施例におけるデータ管理方法の手順を表すフローチャートである。
【図１１】インスタンスがレキシコンに登録された状態を表す概念図である。
【図１２】”分類１”ファサードに、同図に表した構成でロウを登録する様子を表す概念図である。
【図１３】”分類１”ファサードに１件のロウが登録された様子を表す概念図である。
【図１４】”分類２”ファサードにロウを登録する様子を表す概念図である。
【図１５】”分類２”ファサードに１件のロウが登録された状態を表す概念図である。
【図１６】それぞれのファサードに２件のロウが登録された状態を表す概念図である。
【図１７】６件のコンテクストの各ロウが登録された状態を表す概念図である。
【図１８】本発明における検索手順を表すフローチャートである。
【図１９】本発明における検索手順を説明するための概念図である。
【図２０】本発明のデータ管理方法をハードウェア上に実現したデータ管理装置の概観を例示する鳥瞰図である。
【図２１】本発明のデータ管理装置の要部構成を例示したブロック図である。
【図２２】インスタンス間を関連づけたデータの例を示す図である。
【図２３】図２２のデータに新たに電話番号が割り付けた場合の例を示す図である。
【図２４】”斉藤”のデータに対応するコンテクストの例を示す図である。
【図２５】検索パターンの例を示す図である。
【図２６】”分類２”の要素を先頭とするロウの例を示す図である。
【図２７】図２６に示すロウを登録した場合の、”分類２”ファサードの例を示す図である。
【図２８】本発明の作用を説明するのに用いられる図である。
【図２９】本発明の作用を説明するのに用いられる図である。
【図３０】本発明の作用を説明するのに用いられる図である。
【図３１】本発明の作用を説明するのに用いられる図である。
【図３２】本発明の作用を説明するのに用いられる図である。
【図３３】本発明の作用を説明するのに用いられる図である。
【符号の説明】
８０ データ管理装置
８０Ａ データ入力部
８０Ｂ データ処理制御部
８０Ｃ データ記憶部
８０Ｄ データ出力部
８１ フレキシブルディスク装置（フレキシブルディスクドライブ）
８２ 光ディスク装置（光ディスクドライブ）
８３ フレキシブルディスク
８４ 光ディスク
８５ ＲＯＭ
８６ カセットテープ
８７ キーボード
８８ ネットワーク回線
８９ ディスプレイ
【発明の属する技術分野】
本発明は、データ管理方法およびデータを管理するプログラムを格納したコンピュータ可能な記録媒体に関し、さらに詳細には、計算機などの主記憶上に構成され、あるいは計算機などにおいて実行可能な各種アプリケーションシステムにおいて用いるのに好適なデータ管理方法およびコンピュータ読みとり可能な記録媒体に関する。
【０００２】
【従来の技術】
計算機を用いて実行されるアプリケーションシステムにおいて、データベースは通信と並んで中核技術に位置づけられ、特に性能や拡張可能性を決定する重要な要因となっている。現在、「データベース」といえば、ＯＯＤＢ（Object Oriented DataBase）なども一部では利用されているが、通常はＲＤＢ（Relational DataBase）をさすことが多い。
【０００３】
ＲＤＢを始めとする従来のＤＢＭＳ（DataBase Management System）は、「スキーマ」と呼ばれるデータ管理の枠組みを使っている。スキーマを用いた管理とは、予めデータを組織化するための枠組み（スキーマ）を決めておき、データを、スキーマを構成する「データ項目(attribute)」と呼ばれる単位データの集合に基づいて、登録、更新、削除、検索を行うものである。ＲＤＢにおいては、データを登録する枠組みは「テーブル」、登録されるデータレコードは「タプル」と呼ばれる。
【０００４】
スキーマは、１つのテーブルに登録される複数のタプルの構成を１つに規定するものである。ユーザは予めスキーマを定めたいくつかのテーブルに、スキーマによって定められた構成のタプルを登録したり、スキーマに規定された範囲内でタプルの内容を変更することによって、データの保存及び処理（更新）を行う。このような方式においては、少数のテーブルのそれぞれに同じ構成の多数のタプルを登録すれば事足りる場合以外は、次に述べるような点でデータの保存及び処理が効率的に行えないという問題がある。このため、効率低下が著しく、実用に耐えないということも希ではなかった。
【０００５】
まず、本来可変長であるデータを扱う必要がある場合でも、データベース上ではそれを固定長のデータとして扱わざるをえない。このため、データ保存のための記憶領域が増加したり、余計な処理手順が必要になったりする。例えば、一個人が複数の自動車を所有することは珍しくないが、長大な個人情報のレコードの一部にこのような同種のデータが不定個数含まれる場合、従来のデータベースでこれを扱うには次のような方法が一般的である。
【０００６】
（１） 不定個数の最大値を想定してその数だけデータ項目を備えたスキーマを使用する。
【０００７】
（２） そのデータ項目を１個としたスキーマを使用し、そのデータ項目の値を複数含むようなデータを扱う場合は、そのデータ項目の値のみが異なり、他のデータ項目の値は同一のタプルを複数登録する。
【０００８】
（１）の方法は空値を含むタプルを登録するという点で効率を低下させるおそれがある。（２）の方法もまた、１つのデータ項目を除いて他が全て同じタプルを重複して登録するという点で効率を低下させるおそれがある。これらの効率の低下を防ぐには、空値や重複を効率良く圧縮する特別な手段を追加する必要がある。
【０００９】
特に、そのようなデータ項目が複数種類（例えば自動車だけでなく、保険契約も）１つのデータ（個人情報）に含まれる場合、（２）の方法による効率低下は顕著になる。これを避けるために、不定（可変）個数のデータ項目は別のテーブルとし、そのテーブルのタプルと元のタプルとの関連を、両者に共通のユニークな識別子データを含ませることによって実現する。このような場合に、本来のデータには無かった余分な識別子データ項目が導入されることがある。
【００１０】
【発明が解決しようとする課題】
このような扱いの問題点は、本来ひとまとまりとして扱うべきデータが複数のテーブルに分散してしまう上に、それらを相互にアクセスするためには識別子をキーとする検索というコストがかかる操作を要することである。
【００１１】
（１）の方法に関しても、効率低下だけでなく想定した最大値をさらに越えた数の同種データを含むデータを扱う必要が生じた際に、スキーマを変更してデータベースを再生成しなければならないという別の問題点がある。このような場合に限らず、スキーマを用いる従来のデータベースではスキーマの変更を伴うようなアプリケーションの拡張・変更に際しては、アプリケーションへのサービスを停止してデータベースを再生成する必要があるので、連続稼働を要求されるアプリケーションシステムの随時拡張は困難であった。
【００１２】
以上説明したように、これらの問題は全てスキーマに起因して生じるものである。
【００１３】
本発明は、以上詳述した課題の認識に基づいてなされたものであり、その目的は、データベースを作成してアプリケーションへのサービスを開始した後に、当初の想定と異なる形式のデータを扱う必要が生じた場合でも、アプリケーションへのサービスを中断すること無く柔軟かつ効率的にデータベースの拡張を行うことができるデータ管理方法を提供することにある。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明の一態様のデータ管理方法は、アドレスで識別される複数の記憶領域にそれぞれ別々のインデクスを対応付け、記憶領域へのアドレス値を含むレコードに対応するエントリを、含まれるアドレス値毎に対応付けて作成し、そのポインタで識別される記憶領域に対応付けられたインデクスに登録することを特徴とする。
【００１５】
なお、前記インデクスは前記エントリをソートして管理し、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードの内容を使用しても良い。
【００１６】
なお、前記エントリのソート順を決定するキーは、エントリ毎に指定しても良い。
【００１７】
なお、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値で指示される記憶領域の内容を使用しても良い。
【００１８】
なお、前記エントリのソート順を決定するキーとして、前記エントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値そのものを使用しても良い。
【００１９】
なお、前記アドレス値を含むレコードの更新に伴って、前記インデクス中のエントリの各キーがソート順に矛盾しないように必要に応じてエントリの順序を修正しても良い。
【００２０】
なお、前記アドレス値の参照先記憶領域の内容の更新に伴って、前記インデクス中のエントリの各キーがソート順に矛盾しないように必要に応じてエントリの順序を修正しても良い。
【００２１】
なお、指定されたキーでインデクスを検索するようにしても良い。
【００２２】
なお、指定した内容を持つ前記記憶領域を決定し、その記憶領域に対応付けられた前記インデクスを検索しても良い。
【００２３】
なお、前記インデクスを検索した結果得られたエントリを対応付けたアドレス値を含むレコードに含まれる他のアドレス値の参照先記憶領域に対応付けられたインデクスを更に検索しても良い。
【００２４】
さらに、これらのデータ管理方法を実行可能な各種の形態のソフトウエアも、本発明に含まれる。さらに、これらのデータ管理方法を応用した各種のアプリケーションも、本発明に含まれるものである。
【００２５】
ここで、「記録媒体」とは、例えば、ハードディスク（ＨＤ）、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＯＭ、フレキシブル・ディスク（ＦＤ）やＣＤ−ＲＯＭなどの他に、ＲＡＭやＲＯＭなどの各種メモリも含む。
【００２６】
また、これらの媒体に記録されるべきプログラムを暗号化したり、変調をかけたり、圧縮したような状態で、イントラネットやインターネットなどの有線回線や無線回線を介してあるいは記録媒体に格納して頒布しても良い。
【００２７】
以上説明したように、本発明は単位データを指示するアドレス値に対応するエントリを、単位データに対応づけられたインデクスに登録することによって、スキーマを用いることなく検索可能な形にデータを組織化するものである。この方法を採用することによって、固定的なスキーマを使用する従来のデータベースでは扱うことが困難であった可変長のデータが容易に扱えるようになるだけでなく、従来のデータベースではスキーマの変更を伴うので非常に効率が悪かったデータ形式の変更が、通常のデータ更新と同様の操作によって行うことができる。
【００２８】
それ故、本発明によれば、データベースを作成してアプリケーションへのサービスを開始した後に、当初の想定と異なる形式のデータを扱う必要が生じた場合でも、データベースの再生成等によって、アプリケーションへのサービスを中断すること無く柔軟かつ効率的にデータベースの拡張を行うことができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しつつ本発明の実施の形態について説明する。
【００３０】
本発明は、データの構築単位（以下、インスタンスとも云う）として、その記号表現（コード）を格納するための領域（セル）に、それに関連した複数のインスタンスの間の関係をポインタの列で表すデータ（ロウ）を格納する領域（ファサード）を付随させたデータ構造を採用することによって、データの効率的な操作（登録、更新、削除、検索）を実現するものである。
【００３１】
図１は、セルの構造を表す概念図である。セルは、同図に表したように、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）などのプログラム言語における１次元配列に相当する。セルに格納するコードには種々のデータの「データ型」を用いることができる。
【００３２】
データ型には、文字、ｂｙｔｅストリームデータ、符号なし整数値（ビット長：８／１６／３２／６４）、符号付き整数値（ビット長：８／１６／３２／６４）、浮動小数点実数値、倍精度浮動小数点実数値、などがある。以下の説明では、図１に例示したように、セルの図表現を矩形により表し、セルに格納するコードを矩形の中に記すことにする。セルはデータ管理技術一般における「単位データ」すなわちデータ項目の個々の値を格納する機能に相当する概念である。
【００３３】
図２は、インスタンスの構成を表す概念図である。セルとファサードは１つのインスタンスの構成要素として同時に生成される。インスタンス（セルとファサード）はその領域を識別するアドレスで同定する。セルに格納されたコードは単独でインスタンスを同定するものではないが、後述するようにレキシコンの中でのインスタンスの検索や、ファサードの中のロウの検索のように限定された文脈での識別に使用される。
【００３４】
ファサードには後述するコンテクストを検索するためのロウが登録される。ファサードはデータ管理技術一般における「インデクス」に類する概念であり、ロウはそのインデクスに登録される「エントリ」に対応する概念である。インスタンスは、データをコードとして格納する手段であるセルと、データ（インスタンス）間の関係をロウとして格納する手段であるファサードを一体化したものである。本発明では、データの格納手段（セル）とデータの管理手段（ファサード）とが一つの構造（インスタンス）で扱われているので、ＲＤＢのようにデータ管理のための特別なデータ（テーブル）のようなものがなくても、データを構造化することができる。
【００３５】
セルとファサードの図表現は、図２のように、セルとファサードそれぞれを上下に連続した２つの矩形により表現する。上部がセルで、下部がファサードである。なお、セルにはファサードが必ず付随するが、ファサードには必ずしもロウが登録されているとは限らない。すなわち、空のファサードもありうる。ファサードにロウが登録されているかどうかを区別するため、図面においては、空のファサードと、ロウが登録されているファサードとを適宜区別して表す。また、セル及びファサードはインスタンス作成時に予め固定の大きさの領域を割り付ける必要がなく、格納されるコードの量やロウの数に応じて記憶領域を割り付けるような実現方法をとることも可能である。
【００３６】
インスタンスは「レキシコン」により管理される。すなわち、「レキシコン」とは、「データ集団名」に相当する概念である。
【００３７】
図３は、レキシコンにより管理されたインスタンス群を例示する概念図である。同図に例示したように、インスタンスは、必ずどこかのレキシコンに登録される。レキシコンは、複数存在し、それらは「レキシコン・セット」により管理される。それぞれのレキシコンには固有の名前が与えられており、この名前によってレキシコン・セットから特定のレキシコンを検索できる。アプリケーションはその処理に必要なレキシコンをその名前によってレキシコン・セットから検索し、次に、そのレキシコンの下に管理されているセルをその内容によって検索することにより、欲しいセルを得ることができる。
【００３８】
図３は、レキシコン・セットから“従業員”レキシコンを検索し、次に、"佐藤"インスタンスを検索するプロセスを例示している。
【００３９】
セルに格納するコードはそのセルのインスタンスが所属するレキシコンの下には基本的には１つしか存在しないものとすることができる。つまり、同じコードを持つ別のインスタンスは存在せず、重複を許さないことを基本とすることができる。この場合には、レキシコン中という限定された範囲でセルのコードは、インスタンスを識別・検索するキーとして機能する。
【００４０】
これに対して、セルの変数的な使い方もできる。この場合には、同じコードを異なるインスタンスのセルに格納することも可能である。これは、アプリケーションでどのようなデータを扱いたいかで決めれば良い。例えば、人名には「同姓同名」が存在する（つまり同姓同名で別人がある）が、それらを別物として管理したければ、同じコードではあるが別々のインスタンスのセルに格納すれば良い。
【００４１】
インスタンスがレキシコンに登録されただけでは、単に単位データがバラバラに存在するだけであり、セルの内容によりレキシコンから検索できるだけである。
【００４２】
図４は、ある従業員データを構成する個々の要素をインスタンスとし、"従業員"レキシコンに登録した状態を例示する概念図である。この状態では、インスタンスがバラバラにレキシコンに連なっているだけで、インスタンス同士の関連を扱うことはできない。データベースが通常扱うデータは、これら単位データを組み合わせたり関連づけたりしたものである。ＲＤＢにおけるタプルやファイルのレコードがこれに当たる。このようなデータの例として図２２に示すデータを使用して、インスタンス間の関連を扱う方法を説明する。
【００４３】
すなわち、この図２２に示す例においては、姓、入社年度、所属部門、役職、内線により区分された従業員の情報が与えられている。
【００４４】
本発明によれば、このような管理すべきデータが、図４に例示したようにバラバラにインスタンスのセルに格納される。ここで、本発明の特徴のひとつは、重複したデータをひとつのセルで管理できる点にある。例えば、図２２において、「入社年度」を見ると、６名の従業員のうちの３名の入社年度は「１９８１」である。このような場合に、本発明においては、「１９８１」に対応する３つのデータを格納する必要がなく、図４に例示したように、「１９８１」が格納されたセルを有するインスタンスをひとつ管理すれば良い。後に詳述するように、必要に応じて、このインスタンスを何回でも指定できるからである。これは、「所属部門」や「役職」に関する重複データについても同様である。本発明によれば、このように重複するデータがある場合に、データ格納領域を大幅に節約できるという効果が得られる。
【００４５】
次に、図４に表したように、"従業員"レキシコンに登録されているバラバラのデータを、図２２の１行のデータ列、例えば「斎藤・１９８１・工場・課長・３６９１」のような１つの意味のあるデータ群として扱う方法手段として、本発明においては図５に示すような「コンテクスト」という構造を用いる。コンテクストはデータ管理技術一般における「レコード」に類する概念である。
【００４６】
すなわち、「コンテクスト」は、インスタンスを参照するポインタデータの１次元配列である。つまり、コンテクストにはデータの実体（コード）は格納されず、コードを管理するインスタンスを指し示すポインタが格納される。この実施形態においては、インスタンスが格納される各領域のアドレスが、インスタンスに対するポインタとして用いられる。コンテクストは、関連させたい複数個のセルのインスタンスを指定するように形成される。そして、コンテクストに格納されているポインタデータから、セルを参照することができる。
【００４７】
本発明において、リンクを図表現する際は、セル同様矩形で表し、ポインタの指し示すセルを（）で囲ってポインタ表現とする。例えば、（斎藤）は、斎藤という内容を持つセルのインスタンスを参照するポインタを表す。
【００４８】
コンテクストによって、インスタンスに格納された要素データ間の関係を表すが、データの関連性は、図２２のような設計データの静的な関連だけでなく、アプリケーションが必要とする検索方式にも依存する。従って、コンテクストは、アプリケーションにおける設計データを基にアプリケーションが必要とする検索方式を加味して構成することになる。
【００４９】
図６は、設計データとコンテクストとの関係を表す概念図である。
【００５０】
また、図７は、コンテクストを構成する処理手順を表すフローチャートである。
【００５１】
図６に表した例では、図６（ａ）の表の設計データを２種類の検索パターンで検索するアプリケーションを開発したいとする。これをデータ管理装置で実装するには、まず２種類の検索パターンを表現するデータを設計データに追加する必要がある。このデータは、後で説明するように、「ファサード」として機能することになる。このために、まず、図７にステップＳ１及びＳ２として表したように、検索パターンのそれぞれにファサード名を割り当てる。例えば、２つの検索パターンにそれぞれ”分類１”と、”分類２”という名前を付ける。さらに、図４に表したように、これら検索パターンのデータ（「分類１」と「分類２」）をレキシコンにも追加しておく。
【００５２】
次に、ステップＳ３において、元の設計データの１行のデータを取り出す。そして、ステップＳ４において、検索パターンのファサード名を各行のデータ列に追加する。この段階では、１行のデータは実体コードのデータ列である。この実体コードのデータ列を、コードを管理するインスタンスを指し示すポインタ列に置き換えるとコンテクストができあがる。これらの処理はステップＳ５により、検索パターンの数だけ繰り返し、さらにステップＳ６により、設計データの行数だけ繰り返す。
【００５３】
この例では、図６（ｂ）に表したように、設計データに対応した６種類のコンテクストができる。
【００５４】
次に、複数のコンテクストを纏めたり、それらを検索したりできるように、コンテクストの複数の要素（ポインタ）を選択して並べ替えたもの（コンテクストの要素の順列）を、「ロウ」としてその先頭の要素が参照するインスタンスのファサードに登録する。
【００５５】
なお、コンテクストもロウも、それぞれ個別にアドレスを持っており、インスタンス同様にアドレスで（ポインタとして）アクセスすることができる。そして、データ管理装置による検索などの処理結果の戻り値にこれらのアドレスを用いる。
【００５６】
ロウとその元になったコンテクストとは、ポインタで関連付けておき、ロウの各要素とコンテクストの各要素との対応関係が相互に決定できるようにする。ファサードにロウを登録する際には、先頭から何番目の要素までを連結キーとしてファサード内のロウの順序付け（ソーティング）に使用するかを指定する。
【００５７】
「連結キー」とは、優先順位付きのキー（この場合はロウ（コンテクスト）の要素）の集まりである。連結キー同士の比較においては、上位のキーが全て同一の場合に限り、下位のキーの比較順序を連結キーとしての比較順序とする。それらが一致しない場合は、一致しない上位のキー間の関係（順序）がそれらの間の比較結果として取られる。各要素がキーとして比較される場合には、それらが参照するインスタンスのセルのコードが比較される。
【００５８】
図８は、ファサードに登録されたロウの一例を表す概念図である。ポインタ（分類１）を格納した要素を先頭とするロウがインスタンス”分類１”のファサードに登録されている。
【００５９】
また、コンテクストをロウとしてファサードに登録する際には、コンテクストのすべてのデータを登録する必要はない。例えば、図８の例では”分類１”ファサードに登録したロウには、他の検索で使用する”分類２”は使う必要が無いので、”分類２”はロウには含まれていない。さらにロウの全ての要素が連結キーとして使用されるわけではなく、先頭から指定した個数だけが使用される。例えば、図８の例では、”分類１”ファサード内の５番目のロウは、このロウに対応するコンテクスト内に含まれる（１９８１）、（本社）をそれぞれ第１キー、第２キーとして用い、ロウの残りの要素はファサード内のロウのソート順には関係しない。
【００６０】
以上の説明から分かるように、ロウはコンテクストを元にしてファサードに登録されるが、その内容はロウとして登録する際に指定した順序で以下の如く並びかえられたものである。
【００６１】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類1)(1981)(本社)(佐藤)(課長)(6354)
ロウの（分類１）は登録ファサードを、(１９８１)は第１キーを、(本社)は第２キーを、それぞれ示し、(佐藤)(課長)(6354)はキーとして使用されない
以上で説明したデータ管理方式の実現方法であるが、例えばこの構造、特にファサード−ロウの部分を、スプレイ・ツリー・アルゴリズムで実装することが考えられる。なお、スプレイ・ツリー・アルゴリズムについて開示した文献としては、例えば、Robert E. Tarjan, "Data Structure and Network Algorithms", the Society for Industrial and Applied Mathematics,1983 を挙げることができる。スプレイ・ツリー・アルゴリズムは、動的に変化する２分木で、データアクセスが発生する毎にスプレイ操作を実行する。
【００６２】
図９は、スプレイ・ツリー・アルゴリズムにおけるスプレイ操作を例示する概念図である。図９において、スプレイ操作は、次のようなステップで行う。例えば、検索処理を行うとルートからノードを検索キーと比較しながら降りてきて、最終的に検索対象に到達する。そのノードを（ｘ）とすると、（ｘ）の前後のツリーの構造が図９に表した３種類のパターンのいずれかに該当するので、それを選んでツリーの構造を変える。この処理で、（ｘ）はツリーの構造を１段上がることになるが、今度は新しい位置で、再度（ｘ）の前後のツリー構造を見て図９のいずれかの構造を選び、同様に処理する。この処理を続けると、最終的にはツリーのルート（頂点）に到達する。
【００６３】
このようなスプレイ操作を通じて、偏りのあるデータアクセス適応して効率的に検索・更新を処理する２分木ができる。これをファサードにおけるロウの管理に用いることでデータを、効率的にソートして管理することができる。
【００６４】
スプレイ・ツリー・アルゴリズム以外にもソートされたデータの管理法は各種知られているが、これらのデータ管理方式を用いても同様の効果を得ることができる。本発明においては、図１乃至図８に関して前述したデータ管理構造の方式が本質的な部分であり、物理的な実装方式には依らずに上記効果を発揮することができる。
【００６５】
（具体例）
以下、具体的なデータに即して、データの登録及び検索の方法を具体的に説明する。
【００６６】
まず、本実施例における問題設定を説明する。扱いたいデータは、図２２に表した従業員データである。
【００６７】
データ項目は、「姓」、「入社年度」、「所属部門」、「役職」、「内線」の５種類であり、全部で６件のデータからなる。本実施例では、このようなデータを２種類の検索パターンで分類する。第１の検索パターンは、入社年度を第１キーに、所属部門を第２キーにするもので、第２の検索パターンは内線を第１キーにするものである。
【００６８】
以下、各データに関してコンテクストからどのようにロウが形成され、どのようにファサードに登録されるかを説明する。
【００６９】
図１０は、本実施例におけるデータ管理方法の手順を表すフローチャートである。
【００７０】
まず、最初に、ステップＳ１１において、設計データを構成するインスタンスをレキシコンに登録する。図１１は、インスタンスがレキシコンに登録された状態を表す概念図である。図示した如く、レキシコンとインスタンスのツリーができあがる。
【００７１】
次に、ステップＳ１２においてコンテクストを形成する。本実施例におけるコンテクストは、例えば、図１１の右下に表したようになる。
【００７２】
次に、ステップＳ１３において、これらのコンテクストからロウを形成し、これを所定のファサードに登録する。本実施例においては、コンテクストは、”分類１”と”分類２”のそれぞれのインスタンスのファサードに、図１２及び図１４に表された検索パターンで登録される。
【００７３】
具体的には、まず、最初に、図１２に表したように、”分類１”ファサードに、同図に表した検索パターンに従ったロウを登録する。
【００７４】
その結果、図１３に表したように、”分類１”ファサードには１件のロウが登録される。すなわち、コンテクストから、登録ファサード、第１キー、第２キー、その他の順に要素を選択して並べたロウを作成して登録する。
【００７５】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類1)(1981)(本社)(佐藤)(課長)(6354)
なお、ここで、(分類２)がこのロウには含まれないこと、及び、先頭の(分類１)がロウの登録ファサードのインスタンスを参照していることに注意されたい。この登録の結果として、”分類１”ファサードには１件のロウが登録されるが、その他のインスタンスのファサードは相変わらず空のままである。
【００７６】
次に、ステップＳ１４において上述のロウ登録操作を検索パターンの数だけ繰り返す。
【００７７】
具体的には、図１４に表したように、”分類２”ファサードにロウを登録する。この際には、同図に表したキー順位で登録する。その結果、”分類２”ファサードには１件のロウが図１５のように登録される。すなわち、コンテクストから、登録ファサード、第１キー、第２キー、その他の順に要素を選択して並べたロウを作成して登録する。
【００７８】
コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354)
↓
ロウ ：(分類2)(6354)(佐藤)(本社)(課長)
ここでも、”分類１”ファサードへの登録と同様に、(分類１)および(1981)がこのロウには含まれないこと、及び、先頭の(分類２)がロウの登録先ファサードのインスタンスを参照していることに注意されたい。この登録の結果として、”分類１”ファサードと”分類２”ファサードにはそれぞれ１件のロウが登録されるが、その他のインスタンスに付随するファサードは空のままである。
【００７９】
以下、ステップＳ１５において、上述のコンテクスト形式（ステップＳ１２）以降の処理をコンテクストの件数、すなわちデータの件数だけ繰り返す。
【００８０】
まず、２番目のコンテクストを、前と同様に”分類１”ファサードと”分類２”ファサードに登録する。図１６は、このようにしてそれぞれのファサードに２件のロウが登録された状態を表す概念図である。ロウはそれぞれのファサードで連結キー順にソートされている。
【００８１】
以下、このようにして６件すべてのデータのコンテクストを形成し、それぞれを検索するためのロウをファサードに登録する。図１７は、６件のコンテクストと１２件のロウが登録された状態を表す概念図である。これですべてのデータが登録され、検索の準備ができたことになる。
【００８２】
次に、本発明のデータ管理方法における検索手順について説明する。
【００８３】
図１８は、本検索手順を表すフローチャートである。
【００８４】
また、図１９は、本検索手順を説明するための概念図である。
【００８５】
本発明においては、検索のために、まずステップＳ２１において、検索したいパターンに対応するファサードを検索する。具体的には、まず最初に、与えられたレキシコン・セットから、アプリケーションの処理に必要となるレキシコンをその名前により検索する。例えば、本実施例の場合は、"従業員"レキシコンを検索する。
【００８６】
次に、必要とするデータをそのレキシコンにおいて検索する。最初にファサードを探してこなくてはならないが、これは上記ファサードを含むインスタンスをレキシコンから探せば良い。本実施例では、”分類１”インスタンスを、コード”分類１”をキーとしてレキシコンから検索してくる。
【００８７】
次に、ステップＳ２２において、ファサード内に登録されているロウを所望のキーで検索する。本実施例の場合は、第１キー＝”１９８１”、第２キー＝”本社”により検索して所望のロウを獲得する。
【００８８】
次に、ステップＳ２３において、ロウの中の要素から所望のインスタンスを、ポインタを参照することにより求める。すなわち、得られたロウの中からアプリケーションで必要なデータを見つけ出す。例えば、本具体例においては、検索されたデータの「姓」の項が欲しいので、ロウ内の４番目の要素であるポインタが指し示すインスタンスのセルから、所望のデータである”佐藤”を得る。
【００８９】
以上説明した具体例の場合は、ロウから直接セルを参照しているが、もっと複雑な検索の場合は、コンテクストに溯って別なデータへアクセスしたりすることも可能である。いずれにしても、基本となる検索手順はファサードからロウを確定することであり、これを中心に検索処理を組み立てればよい。
【００９０】
なお、上記説明では、”分類１”インスタンスをレキシコンから検索して得たが、”分類１”インスタンスを得る方法は、これに限られるものではない。例えば、”分類２”インスタンスのファサードからそこに登録されたエントリに対応するコンテクストを得、そのコンテクストの先頭要素を参照先として”分類１”インスタンスを得ることができる。すなわち、ファサードは通常のデータ検索の手段によって決定することができるのであり、この点が、スキーマやメタデータの管理手段が通常のデータ管理手段と別になっている従来のデータベースと根本的に異なっている。
【００９１】
次に、本発明のデータ管理方法を実行可能なデータ管理装置について説明する。
【００９２】
図２０は、上述したデータ管理方法をハードウェア上に実現したデータ管理装置の概観を例示する鳥瞰図である。
【００９３】
また、図２１は、その要部構成を例示したブロック図である。
【００９４】
このデータ管理装置８０の本体は、データ入力部８０Ａと、データ処理制御部８０Ｂと、データ記憶部８０Ｃと、データ出力部８０Ｄと、を有する。
【００９５】
データ入力部８０Ａは、管理すべきデータを外部から入力する役割を有し、その入力手段としては、例えば、フレキシブルディスク装置（フレキシブルディスクドライブ）８１、光ディスク装置（光ディスクドライブ）８２などを具備している。フレキシブルディスクドライブ８１に対してはフレキシブルディスク８３を、また光ディスクドライブ８２に対してはＣＤ−ＲＯＭあるいはＤＶＤディスクなどの光ディスク８４をその挿入口から挿入し、所定の読み出し操作を行うことにより、これらの記録媒体に格納されたデータをシステム内に入力することができる。また、所定のドライブ装置を接続することにより、例えば半導体メモリ装置としてのＲＯＭ８５や、磁気テープ装置としてのカセットテープ８６を用いることもできる。さらに、キーボード８７によりデータを入力したり、ネットワーク回線８８を介して、他のコンピュータあるいはデータ出力装置からデータを入力することもできる。
【００９６】
このようにして入力されたデータは、データ記憶部８０Ｃに格納される。この際に、図１乃至図１９に関して前述したように、レキシコン・セット、レキシコン、セル、ファサード、コンテクスト、ロウなどが適宜形成される。これら一連の処理は、データ処理制御部８０Ｂにより実行される。また、ロウのソーティングや、ファサードに格納されたデータのスプレイングも、データ処理制御部８０Ｂにより実行される。
【００９７】
このようにして管理され、ソートされたデータは、必要に応じてデータ出力部８０Ｄにより出力される。データ出力部８０Ｄは、例えば、ディスプレイ８９や、フレキシブルディスク８３などの各種の媒体、あるいはネットワーク回線８８を介して所望のデータを外部に出力する。
【００９８】
後に詳述するように、本発明においては、データを格納するデータ記憶部８０Ｃとして、ＲＡＭなどの半導体メモリを用いることができる。その結果として、高速にデータを展開、管理することが可能となり、データ管理の性能を従来よりも大幅に改善することができる。
【００９９】
なお、本発明は、図１乃至図１９に関して前述したようなデータ管理方法が実行可能なソフトウエアも包含する。このようなソフトウエアは、データ読み取り部８０Ａに関して前述したものと同様に、光ディスク８４などの記録媒体に格納して、管理装置８０のデータ処理制御部８０Ｂにダウンロードすることが可能である。または、このようなソフトウエアは、ネットワーク回線８８を介してダウンロードすることもできる。
【０１００】
以上説明した本発明のデータ処理方法及びデータ処理装置の作用および効果を、引き続き実例データに即して説明する。
【０１０１】
まず、図２２において、扱うべきデータのうち、”斉藤”について、電話番号”２４０６”が”３６９１”に加えて割り付けられることになった場合について説明する。この状況は、例えば、図２３のように示される。
【０１０２】
本発明では、このように、データによって要素の個数が異なる場合でも、全てのコンテクストの要素数を最大個数に揃えたり、一部の要素だけが異なって他は同一のコンテクストを複数作成したりしなくても良い。また、１件のデータを複数のコンテクストに分割する必要もなく、それに伴う余分な識別データを追加する必要もない。すなわち、”斉藤”のデータに対応するコンテクストは、例えば図２４のように生成すれば良い。
【０１０３】
本実施例では、ロウをコンテクストから作成してファサードに登録する場合、ロウの登録ファサードを決定するロウの先頭要素とコンテクストの要素は１対１に対応するという制約がある。つまり、１つのコンテクストから作成できるロウの数の上限はその要素数に等しく、また、登録できるファサードは各要素が参照するインスタンスのファサードに限られる。そこで、同一のファサードに複数のロウを登録したい場合には、同一のインスタンスを参照する複数の要素を含ませる必要がある。この実例の問題設定では電話番号を第１キーとしてデータが検索できなければならないから、電話番号を２つ備えたデータについては、”分類２”ファサードで２つの電話番号をそれぞれキーとするロウを登録する必要がある。すなわち、”斉藤”のデータに対応するコンテクストからは”分類２”ファサードに登録する２つのロウを作成する必要があるので、電話番号を”2406”を参照する要素だけでなく、”分類２”インスタンスを参照する要素がもう１つ追加されている。
【０１０４】
この末尾に追加された（分類２）の要素を先頭とするロウは、アプリケーションが必要とする図２５に示す検索パターンに従って、図２６に示すように作成する。この検索パターンは姓が単なる属性ではなく第２キーに指定されている点で図１４に示す検索パターンと異なっている。これは、”2406”を第１キーとするロウが既にファサード中にあるので、これとの一意な識別を可能にするために連結キーを追加したのである。これに対応して、既にファサード中に存在した”2406”を第１キーとするロウについても、上記の新たに追加するロウとの一意な識別を可能にするために、図３１に示す姓を第２キーとする検索パターンに合致するようにロウの連結キーの個数を変更する。
【０１０５】
一方、同じく”分類２”ファサードに登録するロウでも、”3691”を第１キーとするロウは、登録前のファサードに”3691”を第１キーとするロウは含まれていないので、”3691”を第１キーとし他は単なる属性とする図３０の検索パターンで生成したロウを登録すれば一意に識別できる。これらのロウを登録及び修正した結果、”分類２”でファサードは図２７に示すようになる。
【０１０６】
また、”分類１”ファサードの各ロウには、対応するコンテクストに含まれる内線番号が要素として含まれている必要があるので、（分類１）を先頭とするロウの検索パターンとしては、他のロウより要素が１つ多い図３２の検索パターンからロウを生成する。
【０１０７】
図２７には、”分類１”、”分類２”ファサード及びコンテクスト、レキシコンを含めて、実例データから本実施例のデータ管理方法で作成・登録されたデータ構造が全て示してある。これをみると、”斉藤”のデータのみ形式が異なる６件の入力データそれぞれに対応して６つのコンテクストが作成されているので、元のデータとデータベースに登録されたデータ（コンテクスト）との対応関係は、良く保たれており、分割や複製によって、対応付けに余分な手間がかかることはない。更に、データの形式を一様にするために、空値の要素を追加する必要もなく、元のデータの形式が不揃いならそれを保ったままデータベースに登録ができる。また、コンテクスト毎にアプリケーションが必要とする検索パターンを自由に設定してロウをファサードに登録することができるので、データ（コンテクスト）の形式・内容がまちまちであっても、アプリケーションに必要な内容を過不足無く検索できるようにデータベースにロウを登録できる。上記の例に即して云えば、電話番号を２つ含むデータ（コンテクスト）はそれぞれの番号をキーとして、１つのファサードから検索できるようになっている。
【０１０８】
さて、本発明においては、形式の異なるコンテクストを、ロウを登録するという操作によって、ファサード単位に組織するとともに、連結キーによる検索の対象とすることができる。ファサードは、比較可能な（比較してソートすることに意義がある）ほどに類似したデータをまとめることができるという点で、従来のＲＤＢのテーブルやビューに相当する機能を保持する。しかしながら、各ファサードにおいては、そこに登録されるロウに関して、その先頭の要素がそのファサードのインスタンスを参照するコンテクストの要素であるということ以外は、何ら制約を設けない。したがって、従来のデータベースにおいて、データをまとめる機構に付随して必要であった、まとめられるデータの形式や内容に関する制約情報（いわゆるスキーマ情報）を保存・管理する必要がない。このため、従来のデータベースでは、スキーマの変更として扱わざるを得ないような変更も、単なるデータの変更として扱うことができるので、通常のアプリケーションへのサービスを一旦停止して、データベースを再生成するという特別な操作（アプリケーション）を行う必要がない。
【０１０９】
上記の実例データに即して説明する。図２８に示すような形式のデータのみが扱えればよいという前提でデータベースを設計し、実際にデータベース（レキシコン、インスタンス、コンテクスト、及びロウ）を生成してアプリケーションの用に供した後で、図２９に示すように、内線番号が２つある別の形式のデータを扱う必要が生じた場合を考える。
【０１１０】
本発明のデータ管理方法では、この形式のデータから上記のコンテクストを生成してロウをファサードに登録する手続を新たに用意する必要はあるものの、図２８のデータから生成された既存のデータベースに、ほとんど変更を加える必要がない。もちろん、再生成の必要もない。
【０１１１】
以上説明したように、本発明のデータ管理方法は、スキーマを用いる従来のデータベースでは、困難であった不揃いな形式のデータの扱いや、データの形式・内容の動的変更にも容易に対応できるデータ管理システムを提供することができる。更に、本発明のデータ管理方法によれば、既に登録されているデータが更新されている場合も、効率良くこれを処理することができる。単にデータを追加する場合については、データ登録処理として既に述べた。ここでは、登録されているコンテクストの一要素が変更される場合について説明する。
【０１１２】
引き続き、上記の実例データに関して、コンテクスト
（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(2406)(分類2)
の（2406)が、インスタンス”2406”ではなく、インスタンス”2409”を参照するように変更された場合を考える。この結果、コンテクストは、
（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(2409)(分類2)
に変更される。これに伴って、ロウ
(分類2)(2406)(斉藤)(工場)(課長)
は、
(分類2)(2409)(斉藤)(工場)(課長)
に変更されるので、”分類２”ファサード内でソート順を維持するために、このロウを
(分類2)(2409)(小林)(研究所)(部長)
の直後に移動する。これに対して、第１キーが（2409）のロウが２つになるが、このロウの一意な識別を可能にするためには、（小林）を第２キーとするように連結キーの個数を変更するだけでよい。同じコンテクストから、作成された他の２つのロウ
(分類2)(3691)(斉藤)(1981)(工場)(課長)
(分類1)(1981)(工場)(斉藤)(課長)(3691)(2406)
は、キーに変更が及ばないので、ファサード内の順序を移動する必要がない。これらの判断及び操作は、コンテクストの各要素とそれを含むロウとの対応が管理されているので効率よく行うことができる。
【０１１３】
なお、コンテクスト（ロウ）の要素の参照先を変更するのではなく、インスタンス”2406”のセルの内容を”2406 ”から”2409”に変更した場合は、同一のインスタンスを参照していた２つのロウ
(分類2)(2406)(斉藤)(工場)(課長)
(分類2)(2406)(藤原)(研究所)(主任)
を同時に
(分類2)(2409)(斉藤)(工場)(課長)
(分類2)(2409)(藤原)(研究所)(主任)
に変更することができ、”分類２”ファサードのロウの順序はこれに応じて図３３に示すように変更される。これらのロウの（2409）の参照先インスタンスは、
(分類2)(2409)(小林)(研究所)(部長)
の（2409）の参照先インスタンスとセルの内容は同一でも依然として異なるインスタンスである。”斉藤”と”藤原”が１つの内線番号を共有している。これは、インスタンスがセルの内容ではなく、アドレスで識別されることによる効果である。
【０１１４】
このように、既に登録されたデータの変更を行う場合でもデータの部分的な修正で全て済ますことができるので、多量のデータ登録のやり直しが必要になることはない。
【０１１５】
【発明の効果】
以上説明したように、本発明のデータ管理方法によれば、種々の形式のデータを柔軟かつ動的に扱うことができ、しかも効率的な検索・更新が可能である。
【図面の簡単な説明】
【図１】本発明におけるセルの構造を表す概念図である。
【図２】本発明におけるインスタンスの構造を表す概念図である。
【図３】レキシコンにより管理されたインスタンス群を例示する概念図である。
【図４】ある従業員データを構成する個々の要素をインスタンスとし、"従業員"レキシコンに登録した状態を例示する概念図である。
【図５】コンテクストを説明するための概念図である。
【図６】設計データとコンテクストとの関係を表す概念図である。
【図７】コンテクストを構成する処理手順を表すフローチャートである。
【図８】ファサードに登録されたロウの一例を表す概念図である。
【図９】スプレイ・ツリー・アルゴリズムにおけるスプレイ操作を例示する概念図である。
【図１０】本発明の実施例におけるデータ管理方法の手順を表すフローチャートである。
【図１１】インスタンスがレキシコンに登録された状態を表す概念図である。
【図１２】”分類１”ファサードに、同図に表した構成でロウを登録する様子を表す概念図である。
【図１３】”分類１”ファサードに１件のロウが登録された様子を表す概念図である。
【図１４】”分類２”ファサードにロウを登録する様子を表す概念図である。
【図１５】”分類２”ファサードに１件のロウが登録された状態を表す概念図である。
【図１６】それぞれのファサードに２件のロウが登録された状態を表す概念図である。
【図１７】６件のコンテクストの各ロウが登録された状態を表す概念図である。
【図１８】本発明における検索手順を表すフローチャートである。
【図１９】本発明における検索手順を説明するための概念図である。
【図２０】本発明のデータ管理方法をハードウェア上に実現したデータ管理装置の概観を例示する鳥瞰図である。
【図２１】本発明のデータ管理装置の要部構成を例示したブロック図である。
【図２２】インスタンス間を関連づけたデータの例を示す図である。
【図２３】図２２のデータに新たに電話番号が割り付けた場合の例を示す図である。
【図２４】”斉藤”のデータに対応するコンテクストの例を示す図である。
【図２５】検索パターンの例を示す図である。
【図２６】”分類２”の要素を先頭とするロウの例を示す図である。
【図２７】図２６に示すロウを登録した場合の、”分類２”ファサードの例を示す図である。
【図２８】本発明の作用を説明するのに用いられる図である。
【図２９】本発明の作用を説明するのに用いられる図である。
【図３０】本発明の作用を説明するのに用いられる図である。
【図３１】本発明の作用を説明するのに用いられる図である。
【図３２】本発明の作用を説明するのに用いられる図である。
【図３３】本発明の作用を説明するのに用いられる図である。
【符号の説明】
８０ データ管理装置
８０Ａ データ入力部
８０Ｂ データ処理制御部
８０Ｃ データ記憶部
８０Ｄ データ出力部
８１ フレキシブルディスク装置（フレキシブルディスクドライブ）
８２ 光ディスク装置（光ディスクドライブ）
８３ フレキシブルディスク
８４ 光ディスク
８５ ＲＯＭ
８６ カセットテープ
８７ キーボード
８８ ネットワーク回線
８９ ディスプレイ
Claims (20)
- インスタンスの記号表現が格納されアドレスで識別される複数のセルに、前記インスタンスの間の関係を表すロウが格納されるそれぞれ別々のファサードを、データ管理装置のデータ処理制御部によって対応付けるステップと、
前記セルへのアドレス値を含むコンテクストの部分列となるロウを、含まれるアドレス値毎に、データ管理装置のデータ処理制御部によって対応付けて作成するステップと、
前記ロウの順序列の先頭要素の参照先の記憶領域のアドレス値で指示される記憶領域に対応付けられたファサードに前記ロウを、データ管理装置のデータ処理制御部によって登録するステップと、
を備えたことを特徴とするデータ管理方法。 - 前記ファサードは、前記ロウをソートして管理し、前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストの参照先のセルの内容を使用することを特徴とする請求項１記載のデータ管理方法。
- 前記ロウのソート順を決定する連結キーは、ロウ毎に指定することを特徴とする請求項２記載の管理方法。
- 前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストに含まれる他のアドレス値で指示されるセルの内容を使用することを特徴とする請求項２記載のデータ管理方法。
- 前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストに含まれる他のアドレス値そのものを使用することを特徴とする請求項２記載のデータ管理方法。
- 前記アドレス値を含むコンテクストの更新に伴って、前記ファサード中のロウの各連結キーが、更新後のファサードが整列表となるように必要に応じてロウの順序を修正することを特徴とする請求項２記載のデータ管理方法。
- 前記アドレス値の参照先のセルの内容の更新に伴って、前記ファサード中のロウの各連結キーが、更新後のファサードが整列表となるように必要に応じてロウの順序を修正することを特徴とする請求項４記載のデータ管理方法。
- 指定された連結キーでファサードを検索することを更に備えたことを特徴とする請求項２記載のデータ管理方法。
- 指定した内容を持つ前記セルを決定し、そのセルに対応付けられた前記ファサードを検索することを特徴とする請求項８記載のデータ管理方法。
- 前記ファサードを検索した結果得られたロウに対応付けたアドレス値を含むコンテクストに含まれる他のアドレス値で指示されるセルに対応付けられたファサードを更に検索することを特徴とする請求項８記載のデータ管理方法。
- データを管理するデータ管理装置のデータ処理制御部によって実行されるプログラムを格納したコンピュータ読み取りとり可能な記録媒体であって、前記プログラムは、
インスタンスの記号表現が格納されアドレスで識別される複数のセルに、前記インスタンス間の関係を表すロウが格納される、それぞれ別々のファサードを、データ管理装置のデータ処理制御部によって対応付ける手順と、
前記セルへのアドレス値を含むコンテクストの部分列となるロウを、含まれるアドレス値毎に、前記データ管理装置のデータ処理制御部によって対応付けて作成する手順と、
前記ロウの順序列の先頭要素の参照先のセルの前記アドレス値で識別されるセルに対応付けられたファサードに前記ロウを、前記データ管理層装置の前記データ処理制御部によって登録する手順と、
を備えていることを特徴とするコンピュータ読み取り可能な記録媒体。 - 前記ファサードは、前記ロウをソートして管理し、前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストの参照先のセルの内容を使用することを特徴とする請求項１１記載のコンピュータ読み取り可能な記録媒体。
- 前記ロウのソート順を決定する連結キーは、ロウ毎に指定することを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
- 前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストに含まれる他のアドレス値で指示されるセルの内容を使用することを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
- 前記ロウのソート順を決定する連結キーとして、前記ロウを対応付けたアドレス値を含むコンテクストに含まれる他のアドレスそのものを使用することを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
- 前記アドレス値を含むコンテクストの更新に伴って、前記ファサード中のロウの各連結キーが、更新後のファサードが整列表となるように必要に応じてロウの順序を修正することを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
- 前記アドレス値の参照先のセルの内容の更新に伴って、前記ファサード中のロウの各連結キーが、更新後のファサードが整列表となるように必要に応じてロウの順序を修正することを特徴とする請求項１４記載のコンピュータ読み取り可能な記録媒体。
- 指定した連結キーでファサードを検索することを更に備えたことを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
- 指定した内容を持つ前記セルを決定し、そのセルに対応付けられた前記ファサードを検索することを特徴とする請求項１８記載のコンピュータ読み取り可能な記録媒体。
- 前記ファサードを検索した結果得られたロウを対応付けたアドレス値を含むコンテクストに含まれる他のアドレス値で指示されるセルに対応付けられたファサードを更に検索することを特徴とする請求項１８記載のコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001335175A JP3980326B2 (ja) | 2000-10-31 | 2001-10-31 | データ管理方法およびコンピュータ読み取り可能な記録媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000332993 | 2000-10-31 | ||
| JP2000-332993 | 2000-10-31 | ||
| JP2001335175A JP3980326B2 (ja) | 2000-10-31 | 2001-10-31 | データ管理方法およびコンピュータ読み取り可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002202904A JP2002202904A (ja) | 2002-07-19 |
| JP3980326B2 true JP3980326B2 (ja) | 2007-09-26 |
Family
ID=26603168
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001335175A Expired - Fee Related JP3980326B2 (ja) | 2000-10-31 | 2001-10-31 | データ管理方法およびコンピュータ読み取り可能な記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3980326B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2755353A2 (en) | 2012-11-30 | 2014-07-16 | Sophia Co., Ltd. | Data exchange system and data exchange method |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6475820B2 (ja) * | 2015-03-30 | 2019-02-27 | 株式会社野村総合研究所 | データ処理システム |
-
2001
- 2001-10-31 JP JP2001335175A patent/JP3980326B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2755353A2 (en) | 2012-11-30 | 2014-07-16 | Sophia Co., Ltd. | Data exchange system and data exchange method |
| US9727525B2 (en) | 2012-11-30 | 2017-08-08 | Sophia Co., Ltd. | Data exchange system and data exchange method |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002202904A (ja) | 2002-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5404510A (en) | Database index design based upon request importance and the reuse and modification of similar existing indexes | |
| US6480857B1 (en) | Method of organizing hierarchical data in a relational database | |
| US6859808B1 (en) | Mapping logical row identifiers for primary B+tree-like structures to physical row identifiers | |
| JP4045399B2 (ja) | 構造化文書管理装置及び構造化文書管理方法 | |
| CA2388515C (en) | System for managing rdbm fragmentations | |
| US9760652B2 (en) | Hierarchical storage architecture using node ID ranges | |
| US20050033730A1 (en) | Query optimization by sub-plan memoization | |
| JP3318834B2 (ja) | データファイルシステム及びデータ検索方法 | |
| ZA200100187B (en) | Value-instance-connectivity computer-implemented database. | |
| JP2006085717A (ja) | ．ｎｅｔデータ型およびインスタンスの持続性ストレージ | |
| EP1315103B1 (en) | File search method and apparatus, and index file creation method and device | |
| JPH04124774A (ja) | 関係データベースにおける階層構造のデータ蓄積方法 | |
| US7809674B2 (en) | Supporting B+tree indexes on primary B+tree structures with large primary keys | |
| US20050021924A1 (en) | Memory management tile optimization | |
| US6826563B1 (en) | Supporting bitmap indexes on primary B+tree like structures | |
| US20060080282A1 (en) | Data management method and storage medium storing data management program | |
| JP3980326B2 (ja) | データ管理方法およびコンピュータ読み取り可能な記録媒体 | |
| JP4562749B2 (ja) | 文書の圧縮格納方法及び装置 | |
| EP1116137B1 (en) | Database, and methods of data storage and retrieval | |
| JPH09305622A (ja) | 文書検索機能を有するデータベース管理方法およびシステム | |
| US20070078888A1 (en) | Method and System for Managing An Index Arrangement for a Directory | |
| JP4825504B2 (ja) | データ登録・検索システムおよびデータ登録・検索方法 | |
| JPH0934906A (ja) | 図書管理装置 | |
| JP2001517338A (ja) | データベース内の情報をコンピュータにより動的に作成、変更、削除、保持する方法 | |
| JP2002140218A (ja) | データ処理方法、コンピュータ読み取り可能な記録媒体及びデータ処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070123 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070326 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070619 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070627 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100706 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110706 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120706 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130706 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |