JP2001517338A

JP2001517338A - データベース内の情報をコンピュータにより動的に作成、変更、削除、保持する方法

Info

Publication number: JP2001517338A
Application number: JP53898198A
Authority: JP
Inventors: オリバー，ブライアン・キース
Original assignee: マインドトレイル・プロプライエタリー・リミテッド
Priority date: 1997-03-12
Filing date: 1998-03-12
Publication date: 2001-10-02
Also published as: EP0966714A1; CN1253643A; WO1998040829A1

Abstract

(57)【要約】コンピュータ、データベース内に、読み出し可能な形で、それぞれ関連づけられ、表題を付された情報の集合体を記録する方法。この方法には、以下を含む。それぞれの表題は、従来のデータベースに従来のレコードとして記録する。これにより、従来のレコードと同様、効率的に追加、移動、削除ができる。さらに、従来のデータベースを提供することにより、集合体に属する表題を付された個々の情報が、このデータベースの従来のレコードとして記録可能になる。さらに、表題を付された個々の情報を集合体とその表題とに関連づけることにより、これら集合体を記録、削除、変更、検索できるようにする。

Description

【発明の詳細な説明】データベース内の情報をコンピュータにより動的に作成、変更、削除、保持する方法本発明は、データベース内の情報をコンピュータにより動的に作成、変更、削除、保持する方法に関する。特に、本発明は、従来型データベース内に同一形式で構成された情報の、組織、保存、表示、読み出し、索引作成および検索に関する。これ以外にも、本発明は、同一ではない形式で構成された情報の保存および取り扱いにも利用できる。発明の背景人や組織が職場で行うことの多くは、報告書、評価書その他の書類に含まれる情報や、専門知識、事実、戦略、その他の情報といった、既存の知識の利用、再利用、拡張に密接に関わることが多い。コンピュータ技術はこれらの知識の捕捉、管理、構成、保守および分配を可能にした。しかし、現在のシステムは、しばしば、費用がかかり、専門技師を必要とし、非効率的で、多大な労力を消費し、時間のかかるものである。以下に説明する従来の技術と本発明を容易に理解し、現実的な適用を可能にするために、添付する各図面を参照されたい。図面の簡単な説明は以下の通りである。図１はコンピュータの概要；図２はデータベース内に表示された従業員情報；図３は図２に示す従業員情報の、従来型データベース表における従来方式の構築方法；図４は情報集合体の概念図；図５は図２に示す従業員情報の、従来型データベース表における、本発明を利用した構築方法；図６は従来型の情報処理において、図３に示すデータベース表の情報に列を１つ追加する場合；図７は本発明を利用して構成されたデータベースに列を１つ追加する場合のアルゴリズム；図８は図５に示すデータベースに列を１つ追加する場合；図９は本発明を利用して構成されたデータベースから列を１つ削除する場合のアルゴリズム；図１０は図５から「給与」の列を削除した後の数値列定義表およびセル値保存表；図１１は図５の列を改名する場合；図１２はデータベースに従来の方法で構築されている情報において、セル値が不完全または定義されていない場合、そのセルに割り当てられた保存容量が無駄になることを示す；図１３は本発明により構成されるデータベースにおいては、セル値が不完全または定義されていなくても、保存容量が無駄にならないことを示す；図１４は本発明を利用して構成されたデータベースに行を１つ追加する場合のアルゴリズム；図１５は図５に示す、本発明により構築されているデータベースに行を１つ追加した結果；図１６は本発明を利用して構成されたデータベースの行を１つ読み出す場合のアルゴリズム；図１７は本発明を利用して構成されたデータベースの行を１つアップデートする場合のアルゴリズム；図１８は図５に示す、本発明により構築されているデータベースにおいて、図１６に示すアルゴリズムを用いて第３行をアップデートした結果；図１９は本発明を利用して構成されたデータベースから行を１つ削除する場合のアルゴリズム；図２０は図５に示す、本発明により構築されているデータベースにおいて、図１９に示すアルゴリズムを用いて第２行を削除した結果；図２１は従来型および本発明を利用したデータベースのそれぞれにおける、ＳＱＬクエリーの例；図２２は本発明の「リンク付リスト」方式を利用して従来型データベース内の図２の従業員情報をリンク付けする例；図２３は西暦２０００年対応作業で、セル値保存表中「年」のセルのみを更新することにより、作業の単純化が得られる例；図２４はセル値保存表と列定義表に新規の列を加えることにより、列を追加する例；図２５は列ごとに独立した索引を作成するために、図２の情報のそれぞれの列について、別々の索引を作成する例。コンピューターの説明本明細書において、コンピュータとは、図１に一般的に示すような機械を指す。標準的なコンピュータは、キーボード入力装置、ポインタ装置、複数の表示装置、大容量記憶手段、印刷手段、ネットワーク通信手段、入出力管理機能、メインメモリ、キャッシュメモリを装着していることもある複数の中央演算素子等が、通信機構あるいは何らかのバスなどで接続された形をとることが多い。従来型データベースシステム従来型データベースシステムは、情報を組織し、保存し、処理し、索引を作成し、検索し報告書を作成することを目的としている。通常、情報をデータベースに保存する前に、保存する情報の値と種類に関して、「ノーマリゼーション」という、形式的な機械処理手続を経ることが一般的である。（データベースシステム関連の文献引用）もっとも、最初から標準化されている情報であれば、このノーマリゼーション手続が不要な場合もある。一般的に、ノーマリゼーション手続を行う大きな理由の１つは、データベース内の情報を保管と読み出しが効率的に行えるような構造にしておくことにある。より厳密にいえば、ノーマリゼーション手続の過程で、情報（一般的にセル値の形で表わされている）は、図２に示すように、データベース表の上に行列として構成されている。これにより、従来型データベースシステムにおいて、情報の効率的な保存、読み出し、検索、報告書作成が可能になる。一般的に言って、ノーマリゼーションの度合は非常に重要である。なぜなら、ノーマリゼーションの度合いはデータベース内に保管されている情報の処理速度に影響するばかりでなく、どれほど効率的に情報を保存できるかにも影響してくるからである。また、情報をデータベース内に保存する前にノーマリゼーションを行うことの重要性は、次からも明らかである。すなわち、大学や類似の機関で開講されているデータベースの基礎コースで強調されていること、データベースの教科書やデータベースシステム付属書類の中でノーマリゼーションに多くの頁数が割かれていること、また、ＳＱＬ（Structured Query Language）など、データベースのクエリー言語を利用した処理を実行する際、それをいかに効率的に行えるかはデータベースのノーマリゼーションの度合に大きく依存すると考えられていること。ノーマリゼーションに先立って、情報はしばしば行列で構成され、行は同種のセル値を含み、列は互いに関連する、もしくは関係のあるセル値を含む。たとえば、図２において、それぞれのセル値は、種類（名前、年齢、住所など）ごとに行に構成されている。それぞれの列には、特定の客体（抽象概念、対象物、物）に関する情報が並べられている。図２では、それぞれの列は、ある組織の一従業員に関する情報（セル値）を表わしている。ノーマリゼーション後の情報は、セル値、行、列はデータベースレコード値、レコード、フィールド、表の形で表わされることが多い。もっとも、上記と同様、データベースに格納しようとする情報がすでにそのままで効率的な情報である場合は、ノーマリゼーション手続が不要な場合があることにも留意する必要がある。たいていの場合、いったんノーマリゼーション手続が完了すれば、セル、行、列などの形で認識される情報と、それらが従来型データベースシステムにおいてそれぞれフィールド値、フィールド、レコードとして格納されていた在り方との間には、一対一の対応が成り立つ。例えば、図３には、図２の形で表された情報が、従来型データベース表ではどのように表わされるかの例が示されている。従来型データベースの説明従来のコンピュータデータベースの用語では、データベースとは、表、フィールド、レコードで成り立っており、データベースは１つ以上の表を有し、表は零以上のレコードを有し、表中のレコードの構成は一以上のフィールドによって定義され、フィールドは、一単位のデータ（例えば、５０文字の文字を有する「名前」フィールドとか、数字を有する「年齢」フィールド等）を表わすために必要な定義としての名、種類、その他の保存要件を示す。多くのデータベースでは、フィールドは列の定義を保存するのに使われる。レコードは、フィールド数値の集合であって、その構成はフィールドによって定義され、値はデータベースの実際の情報セル内容となる。多くの場合、レコードは情報行を表わすのに使われる。フィールド値は、データベースに保存される情報の最小単位である。多くの場合、フィールド値は単一のセル情報を表わす。データベースに保存されるべき情報の在り方と、コンピュータデータベース内の情報の在り方との間には、しばしば一対一の対応が成り立つので、情報の構成を表現する用語（たとえば、セル、行、列）が、そのままコンピュータデータベースの定義用語（たとえば、上記括弧内のそれぞれに対応して、フィールド値、レコード、フィールド等）と同義に使われることが多い。例として、図２に示すデータベース内に記載されている情報の定義と、図３に示すデータベース内に実際に表わされている情報との対応関係を考察せよ。従来型データベースの問題点従来型データベース表においては、データベース表の構成を決定づけるフィールドの数と種類は、表を作成したときに決まってしまうことが多かった。つまり、新規にデータベース表のフィールドを追加したり、既存のデータベース表のフィールドを並べ替えたり削除しようとする場合、既存のレコードを再構築するか、そのために特別のソフトウェアを作る以外に方法が無かった。例えば、図３に示した、従来型のデータベースとして表わされる従業員表に、ある情報列（仮に「身長」とする）を追加しようとすると、既存のデータベース表に記載されていた情報の全部と、新規フィールド（上の例では「身長」フィールド）を含む、まったく新しいデータベース表を作成する必要があった。さらに、こうして作成された新しい従業員表に、元の従業員表の各レコードをコピーする必要があった。これは普通でも非常に手間と時間を要する作業であるが、コピーすべき既存のレコード数が多い場合には特に膨大になる。この作業手続を図６に例示した。このほかにも、従来型データベース表においては、フィールドの削除、名称変更、移動などの際にも同様の新規作成作業が必要になることが多い。もっとも、多くの場合、従来型データベースにおいて、情報表を作成、名称変更、削除するに当たっては、その適時性には制限が無いことが多い。データベース内に行として記載された情報に、列を追加することで新たに情報を加える必要が出てきた場合に備えて、新規にレコードを再作成する手間を省くためにとられる手段の一つは、新規作成時点で、様々な種類の空の（情報を持たない）列をあらかじめ備えておくことである。これが、将来の情報に備えてスペースを空けておく方式である。この方式の問題点は、将来のためにとってあるセルは、行の中で使われないまま無駄になることである。また、その分の記憶容量は、必要ないにもかかわらず無駄に管理されることになる。このため、データベースの容量が、非常に大きくなることもなりかねない。そのうえ、もし予備の列が全部使われてしまえば、予備の列を追加するためにはまたデータベース表全体の新規作成が必要になってくる。このように、簡単かつ効率的にフィールドを追加、構成、削除することができないにもかかわらず、これまで、従来型データベースの限界は（主に予備フィールド手法のおかげで）それほど強く認識されてこなかった。しかし、今日のように、情報をとりまく環境が流動的で、収集、処理、報告すべき情報の内容と構成が常に変化する状況では、すぐこの限界に達してしまうことになる。この結果、データベースシステムの維持に要するコストは、個人にとっても、データベースを利用する組織にとっても、増加してきている。特に、すでに膨大な既存のレコードが存在している場合や、当該維持作業を実行するためにソフトウェアを維持したり、開発したりする場合にそれが顕著である。本発明の目的本発明は、上記に挙げた問題点の少なくとも１つを緩和し、データベース内において情報列を作成、構成、改名、移動する際に効率的かつ信頼性の高い方法を提供することにより、これら作業を効率的に遂行できるようにすることを目的とする。本出願人等は、１９９７年３月１２日及び１３日付でオーストラリア国に提出している仮明細書（番号ＰＯ５６０１及びＰＯ５６３８）のなかで、「従来型」データベースと「アルファ」データベースに言及している。アルファデータベースとは、従来型のデータベース内にアルファフィールド定義とアルファフィールドデータが保存されたものを言う。しかし、本発明においては、「アルファ」は、単なる名称ではなく、特別の意味を持つと解されなければならない。したがって、本明細書では、「アルファ」という呼称を使用しない。本明細書においては、「集合体」を「アルファ・レコード」、「関連表題情報」を「アルファ・レコード」の構成要素たる「アルファ・フィールド」に代わる呼称として用いることとする。「アルファ・データベース」は、本明細書では「関連表題情報の集合体」と呼ばれる。発明の要点上記の目的を念頭において、本発明は、大まかに言えば、コンピュータ内に互いに関連する表題を持つ情報を含むコンピュータデータベースの集合体を読み出し可能な形で保管する方法に関するものである。この方法には以下が含まれる。それぞれの表題を従来型データベースに従来型レコードとして保管することにより、表題を効率的に追加、移動、削除できるようにする。さらに、これら表題を、独自の表題を付された集合体として、別の従来型データベースに従来型レコードとして保存しうる新たなデータベース手法を提供する。独自の表題を付された情報を、その表題及び集合体に関連づけ、それぞれの集合体の保存、削除、アップデート、検索を可能にする。それぞれが関連表題情報を含む集合体は、例えば図４に示すようになる。本発明においては、情報はいつでも、データベース内の既存の情報を再構築することなく追加、移動、削除することができる。本発明は、マイクロソフト社のAccessやFoxPro、ポーランド社のParadoxやDba se、オラクル社のDatabase Systems等のシステムを利用することができる。他にも、本発明の実施適用に当たっては、リレーショナル、階層構造、フェデラル構造、オブジェクト指向データベースなどさまざまなデータベースを利用することができる。必要に応じて、上記必要情報を保存するために、特別仕様のデータベースを新規開発してもよい。また、更なる態様としては、本発明は、大まかに言って、従来型データベースに情報を保存する方法に関するものである。この方法には以下が含まれる。各々の列定義を、従来型のデータベース内に従来型レコードとして保存し、列定義の追加、移動、削除が従来型レコードとして効率的に行えるようにする。１つのレコード内のセル値を別個のレコードとして保存することを可能にする新たなデータベース手法を提供する。各々のセル値をその列と関連づける。好ましくは、各々のセル値と列との関連づけは、各々のセル値の他に列定義への言及を追加して保存することで行う。あるいは、各々のセル値と列との関連づけは、従来型データベースの外字キーで行う。この方法を利用することにより、既存のセル値の一貫性を損なうことなく、列定義の追加、削除、構成変更ができるようになる。また、そのような操作に伴うデータベースの既存のレコードの再構築も不要になる。本発明の更なる態様を好ましく実施するために、情報の構築には以下が含まれることもある。従来型データベース表を作成する（以下、「セル値保存表」とする）。この表は、セル値の列を１つ持ち、関連するセル値の数は比較的少なく、同一種類のセル値の列を１つ以上持つこともある。さらにもう１つの従来型データベース表を作成する（以下、「数値列定義表」とする）。ここに、列を特定する諸情報（たとえば、列の名称など）を保存する。セル値保存表内のそれぞれのセルと、それらが属する列に関する数値列定義表内の情報を関連づける手段を構築する。上記により明らかである通り、本発明は、従来型データベースのように、意味的に関連するセル（たとえば、図３に示すような表において行を構成する、図２の従業員情報）を従来の表における１つのレコードとして扱うのではなく、列を構成するセル値は図５に示すようなセル値保存表に保存する。これにより、列を新たに追加／削除したり、既存の列を並べ替えたりすることが簡単にできるようになる。それぞれの列の定義および関連情報は、列定義表に、列の種類ごとに別々のレコードとして保存される（図５．３および５．４に示す列定義表参照）。たとえば、図３のように、従業員表を従来型レコード内にセル値として保存するかわりに、数値情報を持つセルの情報は全て単一のセル値保存表に保存される（図５．１参照）。同様に、図３の従業員表における行を構成していた文字情報を持つセルの情報は、図５．２に示すように、別の文字情報セル値保存表に保存される。さらに、従業員表のそれぞれの列の定義情報は、図５．３および５．４に示すように、それぞれの列定義表に保存される。同じ種類のセル値は全て同一のセル値保存表に保存されるので、同一のセル値保存表の内部で違う種類の列に属するセル値同士を区別する手段が必要になる。それにより、特定の列に属するセル値に関して、特定の行について作成、検出、維持、削除が可能になる。セル値保存表の個々のセル値が属する列を特定するためには、第二の従来型データベース表（すなわち、「列定義表」）に保存する列定義に、追加情報を保存することが望ましい。具体的には、上記は列定義表保存の個々の列定義に、その列に固有の番号を付し、セル値保存表に保存する個々のセル値に、この列番号を併記することで実現できる。列定義表に保存される列定義は、これに加えて、列の名称とその他の情報、すなわち、容量、範囲、検索能力などを含む（図５．３、５．４参照）。さらに、セル値保存表に保存する個々のセル値には、その属する行番号と列番号を併記する。その結果、従来の方式で構成されたレコードについて、フィールドとレコードが検出、アップデート、検索、索引作成、維持できたのと同様に、特定の列に属するセル値に関して、特定の行について検出、アップデート、検索、構築、維持が可能になる。従来型データベースの用語で言えば、セル値保存表に記載される行番号と固有の列番号は、特定の行、特定の列に属する特定のセル値の検出を可能にする「外字キー」に相当する。したがって、どのセル値保存表にも少なくとも１つの列定義表が割り当てられなければならず、また、どの列定義表にも少なくとも１つのセル値保存表が割り当てられる。列定義表の例として、図５．３には数値情報の列定義表を、また、図５．４には文字情報の列定義表を揚げた。この２つの表は、図２に示す従業員情報の１つ１つの列のうちから、それぞれの種類の列を、列の名称ならびに適当なその他のパラメータを併せて示している。ここでのそれぞれの列に固有の列番号が、セル値保存表（図５．１および５．２を参照）において、外字キーとして用いられ、特定のセル値がどの列に属するかを示す働きをする。たとえば、図５．１において、＜２，１，６４７１＞と記載されてあるレコードは、図２に示す従業員情報の、行２、数値列１（この列は、数値列定義表を参照すれば、「従業員番号」の列であることが明らかである）のセルの内容を示している。同様に、図５．２において、＜４，２，ケアンズ＞と記載されてあるレコードは、図２に示す従業員情報の、行４、文字列２（この列は、文字列定義表を参照すれば、「都市」の列であることが明らかである）のセルの内容を示している。本発明の上記以外の特長としては、以下に示すデータベース構成が揚げられる。「列定義表」と称する従来型のデータベース表を作成し、そこに列を定義する情報、すなわち列の名称およびその他の情報を保存する。上記に加えて、「セル値保存表」と称する従来型のデータベース表を作成し、その一列はセル値を保存し、他の一列は対応する行値を保存する。セル値保存表に保存されている個々のセル値を、列定義表に保存されているそれぞれに対応する行および列値と関連づける、関連手段を有する。典型的な実施の形態この発明の典型的な実施の形態は、「クレバーＸ」と称するデータベース内の情報の構築に見られる。クレバーＸに関する詳細な説明は、添付のユーザーマニュアルに譲る。クレバーＸは、この発明の一態様を応用し、柔軟かつ高度な情報収集処理を従来型データベースによって実現するものである。クレバーＸ用語を以下に揚げる。クレバーＸワークシートとは、本発明にしたがって構成した情報を含むデータベースを指す。クレバーＸパレット部品は、クレバーＸワークシート、クレバーＸセクションズ、クレバーＸレスポンス、クレバーＸテキストボックスなどの、本発明にしたがって構成する様々な種類の「空欄」列の総称である。本発明は、データベースにおいて情報列の効率的な追加、変更および削除を可能にするものであるが、同様に、クレバーＸも、クレバーＸワークシート、クレバーＸセクションズ、クレバーＸレスポンス、クレバーＸテキストボックスの追加、変更、削除を効率的に行うことができるようになっている。これら部品は、それぞれがクレバーＸのユーザーが決定した情報をクレバーＸ内に記載する役割を担っている。さらに、本発明にしたがって記載された情報においては、ある情報が不完全あるいは未定義でも構わないが、クレバーＸも同様に、ユーザーがクレバーＸ部品の値を部分的に未定義もしくは空欄のままにしておいても構わないようになっている。さらに、クレバーＸは、ユーザーが条件定義の際、ユーザー情報がデータベースに記載されない条件を設定することも許容している。この場合、クレバーＸのユーザーが入力した情報のうち、条件に合致する情報は、データベース内の定形外の行に保存される。新たな情報列を追加する場合すでに説明したように、従来型データベースシステムの問題点は、既存の表に新たにフィールドを追加したいと思えば、新たなフィールドを含む表を新規に作成し、既存の表から全レコードを新たな表にコピーし、場合によっては索引を作成しなおさなければならないことにあった（図６参照）。この問題点は、既存のレコード数の少ない小規模の従来型データベース表もしくはめったに変更されない情報を記載するデータベース表については顕著ではないが、レコード数の多いデータベース表や、頻繁に変更を要する表においては大きな問題となる。既存の表を再構築するのは、開発コストや、プロセッサ稼動時間（一般的にデータベース内のレコード数に比例する）の面でコストがかかる。最近のデータベースの中には、このような原始的な新規作成もしくは既存レコードのコピーといった作業に依らずともデータベース表に情報列を追加することができるものも出ているが、それらは既存レコード数の割に非常な時間を要するものであったり、既存のデータベースフィールドの改名、移動、削除ができなかったりする問題点がある。情報を、本発明を応用した構成にして保存することにより、データベース表への新たな情報列の追加は、既存のレコード数に関わりなく比較的短時間でできるようになる。また、レコードの再構築や索引の再作成は不要になる。何故なら、新たな列の追加は、列定義表にレコードを追加するだけで行えるからである。レコードを追加する際のアルゴリズムは図７に示してある。たとえば、従業員の身長の列を追加するために、従来のデータベースシステムであれば、図６に示すような手段をとるのが普通である。他方、本発明に従えば、身長フィールドを追加するためには図８に示す手段がとられる。セル値はレコードごとに行として並べられていないため、新たに列を加えるためにあらかじめレコードごとに予備の保存用量を確保しておく必要はない。新たに加えられた列に入れるセル値は、既存のレコードとは別個に既存の表や新規の表に保存される。既存の情報列を削除する場合従来のデータベースシステムにおいては、上記のほか、既存の情報列を削除する場合にも、新たな情報列の追加と全く同様に、既存のレコードの再構築が必要になる問題があった。しかし、本発明の方式を利用して情報の構成を行えば、情報列の削除は、以下の手続のみで行うことができる：特定の列を列定義表から解除する、および当該列に関連するセルを関連のセル値保存表から削除する。上記のために使用するアルゴリズムを、図９に示す。レコードの再構築が不要である理由は、列の削除が列定義表からの列の削除と、関連するセルの関連のセル値保存表からの削除のみで行うことができるためである。個々のセル値は別個のデータベース表に保存されている。たとえば、図３に示す、従来型で構築された従業員表から給与の列を削除するためには、給与列を持たない従業員表を新たに作成し、その上で、既存の従業員表から、給与列の値のみを除く全てのレコード値をこの新表にコピーする必要があった。本発明によれば、データベースからの給与の列の削除は、以下の手続きで行うことができる。図５．３の数値列定義表から、給与の列定義を削除する。その結果、図１０．１に示す表が得られる。さらに、図５．１の数値セル値保存表から、従来型の構造クエリー言語で記述する下記のような命令を使って給与のセル値を削除する。その結果、図１０．２に示す表が得られる。「数値セル値保存表より、数値列番号が３であるレコードを削除せよ。」既存の列定義を改名もしくは移動する場合従来の方式で構築したデータベースにおいては、既存の列を改名したり移動したりすることはあまり行われないが、それは、通常そのような作業のためには、列定義の追加や削除と同様に、既存の表のレコードを再構築する必要があるためである。本発明により構成されたデータベースにおいては、このような作業は列定義表の列定義を変更するだけで簡単に行える。セル値保存表に保存されたセル値にアクセスする必要はなく、したがって、既存のレコードの再構築も不要である。たとえば、図２の従業員表の「年齢」の列を、「誕生からの年数」と改名したいとすれば、本発明により構成されたデータベースにおいては、数値列定義表中の対応する列定義に変更を加えるだけで済む（図１１参照）。構造的変更の融通性本発明により構築された情報のもう１つの特長は、上記の各作業、すなわち、データベース内の情報列の作成、変更、定義変更などが任意に行えることである。しかも、これら作業はデータベースに新規のセル値を追加したり、既存のセル値をアップデートしたりするのと同時に行うことができる。これは、セル値をセル値保存表に保存する作業は列定義を列定義表に保存する作業とは別個だからである。さらに、列の名称その他の列定義情報は、セル値とは別個に保存されるので、データベース内の情報処理作業と同時に変更可能である。このことは従来のデータベースの情報構築方法に比べて大きな利点である。なぜなら、通常の場合、データベースの列の構造、定義、構成を改変しようとする場合には、他のデータベース処理は中止されなければならないのに引き換え、本発明では、データベースの構造的なアップデートを行う際に、ネットワークを通じて利用しているユーザーを切断しなくても良くなるからである。レコードの完全性および定形外の行情報本発明により構築された情報のもう１つの特長は、セル値が定義されていなかったり、不完全だったり、不明だったりする場合でも、従来方式で構築されたデータベースシステムのように、その分の記憶容量が無駄になってしまわないことである。たとえば、図１２に示すように、従業員表にパートナーの欄が設けられている場合、従来型のデータベースでは、全レコードについて、フィールドが実際に使用されているか否かに関わらず全フィールド値のための容量を確保をするため、パートナーのいない従業員についてはパートナーを保存するための容量が無駄になってしまう。一方、本発明により情報を構築すると、未定義、不完全あるいは不明な値を持つセルは、保存されない。たとえば、図１３おいて、メアリーとデイブに関しては、パートナーのセルは保存されない。このように、本発明によって情報を保存するデータベースにおいては、使用されていないセル値のための容量が無駄になることはない。この特長のため、従来方式で保存される行とは違い、不定形の情報行も許容される［ＯＵＴ（米国特許番号５６８２５２４参照）］本発明の方式で情報を構成すれば、新たにデータベースソフトウェアのクエリー手段を開発する必要もないし、従来型のデータベースクエリー言語（例えばＳＱＬ）が稼動できるように単一のフィールドを利用したハイブリッド型もしくは異形のバイナリーフォーマット（たとえばＢＬＯＢ＝バイナリー・ラージ・オブジェクト）を使用して行を構築する必要もないし、使用するデータベースツールを限定して情報へのアクセス方途を狭めることもないのであるが、他の多くの標準的データベース開発ツールは新たにソフトウェアを開発せずにはＢＬＯＢフィールドを直接参照できないので、上記のような制約が起こるのである。データベースに新たな情報行を追加する場合個々の情報行が１つのレコードとしてデータベース表に保存されているわけではないので、従来の方式で構成されたデータベースのように、新たな行を完全な形で追加する方式はとることができない。そのかわり、適当なセル値保存表に一つ一つのセル値を別個のレコードとして追加することになる（図１４のアルゴリズム参照）。図１５は図１４のアルゴリズムを実行した例である。｛（従業員番号１２３４）、（氏名ケビン）、（年齢３１）、（都市メルボルン）、（給与５２０００）｝という内容を持つ第５行を図１４のアルゴリズムにしたがって追加した結果を示す。データベースから既存の情報行を検出する場合同様に、個々の情報行が１つのレコードとしてデータベース表に保存されているわけではないので、従来の方式で構成されたデータベースのように、１つの行を完全な形で検出する方式はとることができない。そのかわり、適当なセル値保存表から別個のセル値として検出することになる（図１６のアルゴリズム参照）。図１６のアルゴリズムを実施すると、たとえば、図５の情報に対して第２行を要求することにより、｛（氏名メアリー）、（年齢２６）、（都市ブリスベーン）、（給与４２０００）｝という結果が得られる。データベースの既存の情報行をアップデートする場合同様に、個々の情報行が１つのレコードとしてデータベース表に保存されているわけではないので、従来の方式で構成されたデータベースのように、１つの行を完全な形でアップデートする方式はとることができない。そのかわり、適当なセル値保存表から別個のセル値としてアップデートすることになる（図１７のアルゴリズム参照）。図１８は、図５の情報の第３行を、｛（給与４１０００）｝と改めた結果を示す。従来型のデータベースで行をアップデートする場合と異なり、本発明によるデータベースで行をアップデートする場合には、当該行に属するセルが全て新しくなるわけではない。データベースから既存の情報行を削除する場合削除の場合は、適当なセル値保存表から、それぞれのセル値を削除することになる。図１９にそのアルゴリズムを示す。図２０は、図１９のアルゴリズムに従い、図５のデータベースから第２行を削除する例である。データベースに保存された情報についてクエリーを実行する場合本発明の特長は、情報の保存に際して従来のデータベース技術を踏襲していることである。このため、従来型データベースで可能な処理は本発明により保存されている情報についても適用できる。したがって、構造的クエリー言語（たとえばＳＱＬ）、索引作成システム、レポート作成ツールなどは本発明にしたがって情報を保存しているデータベースについても使用可能である。図２１に、従来型のＳＱＬクエリーを従来型および本発明により保存されている情報の双方について行う例を示してある。データベース内の情報の索引作成従来の方式に従って保存されている情報について索引を作成し、維持する作業は、本発明により保存されている情報についても適用できる。たとえば、図３の従業員情報の氏名フィールドについて索引を作成するのと同様の処理を、図５の文字情報セル値保存表についても行うことができる。もっとも、図５の文字情報セル値保存表には、その他の文字情報も保存されているので、この表について索引作成処理を行えば、その他の文字情報も標識付けられてしまうという副作用には留意が必要である。すなわち、図５の文字情報セル値保存表に索引作成処理を行えば、氏名のみならず、「都市」列のセル値も同時に標識付けされるのである。この副作用は、場合によっては不必要であるかもしれないが、そのときは新たな氏名セル値保存表を作成し、そこには氏名文字情報のみを保存することにすれば解決する。図２５にその例を示す。好ましい情報構成方法本発明は、情報列の効率的な管理を目的とするものであるが、その結果として、従来型データベースのように１つのレコードをセル値の１行として保存する方式に比べ、セル値の１行全体を検出する場合の処理効率が劣る問題が生じる。しかしこの問題は、従来からセル値を保存するのに用いられてきた、リンク付リスト方式を採用することで回避できる。この方式は、それぞれのセル値に、行においてそのセルの次に来るセルが何であるかを示す情報を追加する。図２２に図５の情報にこの方式を適用した場合の例を示す。もっとも、リンク付リストの特長として、セル情報列が削除された場合は既存のリンクの再構築が必要になる場合がある。そのためのアルゴリズムは、すでに説明した列アップデートのためのアルゴリズムと同じである。情報行全体の追加、アップデート、検出、削除のためのアルゴリズムは、標準的なリンク付リスト用のアルゴリズムと同じである。レコードの保護この発明のもう１つの特長は、多数のユーザーのいるデータベース環境において、アップデートの際特定のセル値を保護することができるようになることである。そのため、複数のユーザーが同じレコードに属する別々のセルの値を同時にアップデートすることができるようになる。たとえば、ある会社に属するユーザーが図３の従業員表の第１行氏名列のセル値を変更しようとするとき、もう一人のユーザー（同じ会社の別の部署に属する人など）が、同じ従業員表の第１行給与列のセル値を変更しようとしていたとすれば、この２つの処理は同時に実行可能である。上記を、従来型データベースシステムのほとんどにおいて、特定のレコードについて一時に変更処理を行えるのは１ユーザーに限られるのと比較せよ。データベース内のセル値の再構築本発明のもう１つの特長は、列情報と、それに対応するセル値保存表内のセル値を、その他の行のセル値に影響を与えずに変更することができることである。これにより、セル情報列保存の必要状況の変化にともない、列定義の変更と、それに対応するセル値の再構築が、他のセル値に影響を与えずに可能になる。この特長の好例が、西暦２０００年対応手続である。この危機に対応するために、年を示す値を保存するセルが二桁になっている従来型データベースを全体として再構築する代りに、本発明によって構成された情報においては、セル値保存表の年号セルの値のみを変更すればよい。新たな種類の列を追加する場合本発明のもう１つの特長は、情報列を追加するのと全く同様に、新たな種類の列を追加することもできる点である。たとえば、本発明では、図７に示したように既存のデータベースに、すでにあった列と同じ種類の列を新たに追加できるほかに、新たな種類の列定義およびセル値保存表を追加することで、情報行に新たな種類の列を付け加えることができる。図２４はその例として、日付列定義と、日付セル値保存表を追加することで、従業員情報の各行に、新たに日付セルを付け加える場合を示している。本発明の効果本発明は、データベース作成時点で収集、保存、構築、処理、報告すべき情報の内容と構造が完全に知られていない業種で特に有効である。例えば、評価や測量を行う業種、メモを多用する業種、判断を要したり、見積りや予測が必要になる業種がそれである。また、情報の内容や構造が変動しやすい業種も本発明を利用するシステムを導入することで効果を得られる。たとえば、教員、医師、弁護士、銀行、保険、マーケティングなどを営む個人や会社にあっては、収集した情報の構造や組み立てが変動しやすい。特に、時間の経過に伴いそれが顕著になる。データベースシステムへの影響を最小限にしつつ、これらの情報を組み替えることで効率化を図れる。上記は本発明の一例を挙げたに過ぎないことは当然認識されなければならない。上記についてこの分野に精通した人なら当然加えうるような改訂や変更は、添付書類に定義される本発明の範囲内であり、広くその中に含まれるものと解さなければならない。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号ＰＯ８６３６ (32)優先日平成９年８月15日(1997．8．15) (33)優先権主張国オーストラリア（ＡＵ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims

【特許請求の範囲】１．コンピュータ内に互いに関連する表題を持つ情報を含むコンピュータデータベースの集合体を読み出し可能な形で保管する方法において、各表題を効率的に追加、移動、削除できるように、それぞれの表題を従来型データベースに従来型レコードとして保管し、これら表題を、独自の表題を付された集合体として、別の従来型データベースに従来型レコードとして保存しうる新たなデータベース手法を提供し、それぞれの集合体の保存、削除、アップデート、検索を可能にするように、独自の表題を付された情報を、その表題及び集合体に関連づけるようにした方法。２．請求項１に記載の方法であって、集合体は概念的に集合体の行を構成し、従来型のデータベース（その中で上記従来型のレコードは行に構成され、それぞれの列は同種のセル値の列をなす）と同様、題名付き同種の情報列をなすようにした方法。３．請求項２に記載の方法であって、その各列に関する情報は、列の名称およびその他の列の性格を定義する情報を含むようにした方法。４．請求項１から請求項３のいずれかに記載の方法であって、当該列定義情報が少なくとも２つ以上別個のデータベースに保存されているようにした方法。５．請求項４に記載の方法であって、当該フィールド定義の関連づけはリンクによって行われるようにした方法。６．請求項４に記載の方法であって、セル値の処理上の関連づけは、セル値に、そのセル値の行情報に加えて、該当する列番号への言及を保存することにより行われるようにした方法。７．請求項４に記載の方法であって、それぞれのセル値とその列との処理上の関連づけは、従来型データベースの外字キーを利用することで得られるようにした方法。８．請求項１から請求項７のいずれかに記載の方法であって、上記従来型データベース表は、列定義表として作成され、１つの列には列の名称を、またその他の列にはそれ以外の性格付けに関わる情報を含む列定義情報が保存され、上記別個の従来型データベース表は、セル値保存表として作成され、セル値を保存する１つの列と、関連する行番号を保存する１つの列を有し、個々の情報集合体における名称と含有される情報相互間の関連づけは、セル値保存表に保存されるセル値と、列定義表内のそのセルに固有の行および列情報を関連づけることによって得られるようにした方法。９．請求項８に記載の方法であって、上記セル値保存表は、比較的少数の相互に関連するセル値、もしくは同一の種類の列に属するセルの値のみを保存するようにした方法。１０．従来型データベースに情報を保存する方法であって、列定義を効率的に追加、移動または削除することができるように、列定義情報を従来型レコードとして従来型データベースに保存し、行を構成するセル値を別のレコードとして保存できるようなデータベース手段を用意し、それぞれのセル値をその属する行と列に関連づけるようにした方法。１１．情報を行列の形で従来型データベースに保存する方法であって、列定義を効率的に追加、移動または削除することができるように、列定義情報を従来型レコードとして従来型データベースに保存し、行を構成するセル値を別のレコードとして保存できるようなデータベース手段を用意し、それぞれのセル値をその属する行に関連づけるようにした方法。１２．データベース構造であって、列定義表として作成され、１つの列には列の名称を、またその他の列には、それ以外の列の性格付けに関わる情報を含む列定義情報を保存する従来型データベース表と、セル値保存表として作成され、セル値を保存する１つの列と、関連する行番号を保存する１つの列を有する他の従来型データベース表と、セル値保存表に保存されるセル値と、列定義表内のそのセルに固有の行および列情報を関連づけるための手段とを備えるようにしたデータベース構造。