JP3628030B2 - データベース装置 - Google Patents
データベース装置 Download PDFInfo
- Publication number
- JP3628030B2 JP3628030B2 JP29358792A JP29358792A JP3628030B2 JP 3628030 B2 JP3628030 B2 JP 3628030B2 JP 29358792 A JP29358792 A JP 29358792A JP 29358792 A JP29358792 A JP 29358792A JP 3628030 B2 JP3628030 B2 JP 3628030B2
- Authority
- JP
- Japan
- Prior art keywords
- line
- word
- tables
- event
- registered
- 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
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、データベース装置に関する。
【０００２】
【従来の技術】
データベース（ＤＢ）技術の目的は、データの内部構造を、それを利用する応用プログラムから独立させることである。
【０００３】
従来のＤＢシステムの概念上の枠組みには、階層、ネットワーク、リレーショナルなどの代表的なものがある。それらのうち、リレーショナル・データベース（ＲＤＢ） が最も理論的に整理されており、現在では標準的な技術となっている。このＲＤＢの基礎概念は、「関係」である。この点について、以下に説明する。
【０００４】
例えば、ｎ個の集合Ｓ１ ，…，Ｓｎ の直積集合Ｒを次のように定義する。
【０００５】
【数１】
このとき、Ｒの任意の部分集合をＳ１ ，…，Ｓｎ の間のｎ項関係（または単に関係、ないしはリレーション） と呼ぶ。たとえば、２個の集合Ｓ１ ，Ｓ２ を次の式（２）に示すように定義する。
【０００６】
【数２】
このとき、２個の集合Ｓ１ ，Ｓ２ の直積集合Ｓ１ ×Ｓ２ は、次の式（３）のように表される。
【０００７】
【数３】
このうち、次の式（４）に示すような部分集合Ｒが、都県−市リレーションである。
【０００８】
【数４】
ＲＤＢは、このようなリレーションの集合をデータとするＤＢである。要するに、リレーションは図５２、図５３に示すような表である。一般的に、表を横に見て１つの行をタプル（組、 ｔｕｐｌｅ、レコード） 、縦にみて１つの列を属性（ａｔｔｒｉｂｕｔｅ ）と呼ぶ。図５２の表で各属性に付けられた名前を属性名（ａｔｔｒｉｂｕｔｅ ｎａｍｅ ）といい、各属性の値を属性値（ａｔｔｒｉｂｕｔｅ ｖａｌｕｅ、フィールド値）という。また、表の名前をリレーション名（関係名、ｒｅｌａｔｉｏｎ ｎａｍｅ）という。
【０００９】
このように、ＲＤＢにおいては、リレーションという表を概念的な仲立ちとして、データレコードを計算機に収容する。もちろん、計算機の内部では複雑なデータ構造やアクセス手続きをとっている可能性が高い。しかし、ユーザからはその複雑な実装が見えない。実装に関する情報は隠蔽されている。単なる表、すなわちデータの容器があって、ユーザはその容器にレコードを入れるという利用法である。
【００１０】
ＲＤＢは、次のような４つの処理機能を持つ。：
「１．レコードを収容する表を設定する。」
「２．表にレコードを登録する。」
「３．表からレコードを削除する。」
「４．表の中のレコードを検索する。」
そして、ＲＤＢの実装は、属性と属性値を指定すれば、レコードの登録処理、削除処理、および検索処理が能率良くできるようになっている。
【００１１】
ＲＤＢの特徴の１つは、表とレコードとの独立性が高いことである。ユーザは、まず表を設定し、しかる後にその表にレコードを登録する。あるレコードをある表に登録しておくか否かはユーザの任意である。検索したレコードのある属性値を変更する場合でも、レコードと表との対応関係に変化はない。ユーザがレコードと表との対応を変更するためには、上記のようなレコード登録、削除の操作が必要である。複数の表を指定してそれらに登録されているレコード間で演算を行って生じたレコードを、指定した新たな表に登録する場合でも、新たに生成されたレコードをどの表に登録するかは、ユーザが管理する。すなわち、ＲＤＢにおいて、表とレコードの対応関係は、ユーザが任意の表に任意のレコードを登録するという行為を通してのみ与えられる。
【００１２】
先に説明したように、関係は１つの集合である。一般に、集合の定義には、外延的な方法と内包的な方法がある。外延的な方法では、要素を全て列挙することによって集合を定義する。たとえば、０以上９以下の整数全体の集合Ｓを、次の式（５）に示すように定義するのが外延的な定義である。
【００１３】
【数５】
…式（５）これに対して、その集合に属する要素が満たすべき性質を規定するのが内包的な定義である。たとえば、上の集合Ｓを、次の式（６）のように定義するのが内包的な定義である。ここで、Ｚは整数の集合である。
【００１４】
【数６】
これに対して、表にレコードを登録する行為は、「このレコードはこのリレーション（表）に属し、このレコードが登録されない他のリレーション（表）には属さない。」ということを、属性と属性値を列挙することによって定義している。これを全てのレコードについて行うのであるから、リレーションは外延的に定義されている。
【００１５】
この結果、ＲＤＢは次のような特徴を持つ。まず、リレーションに従って行う処理は、概念的に単純であり、能率良く行える。すなわちプログラムは簡単ですみ、計算量も少ない。たとえば図５３において、
「（Ａ）生年が‘６３年の者を検索する。」
という処理は、リレーションに従う処理であり、能率良く行うことができる。
【００１６】
【発明が解決しようとする課題】
これに対して、ＲＤＢにおいて、リレーションに従わない処理は、もともと想定されていなかった処理であるから、能率が悪い。たとえば、図５３において、
「（Ｂ）生年が若い順に３番めの者を検索する。」
という処理は、リレーションに従わない処理である。この処理は、仮に図５３の表中に「生年の順番」という属性がもともとありさえすれば、容易に実行できるものである。それにもかかわらず、図５３の表中においては、「生年の順番」という属性が、予め考えられてはいないので、（Ｂ）の処理を行うためには、登録されたレコードのうち生年を有するレコードを全て調べた上で、これらのレコードの順番を定めなければならない。このような検索を実行する場合には、プログラムが長くなり、計算量も多くなる。
【００１７】
さらに言及すれば、この場合、（Ｂ）の処理で用いる属性「生年の順番」は、（Ａ）の処理で用いる属性「生年」から自然に定まるものである。すなわち、属性「生年の順番」は、属性「生年」を有するレコードの関係の部分集合を規定する内包的な性質として、自然に存在するものである。それにも関わらず、属性「生年の順番」は、このＲＤＢには存在しない属性であるために、この属性を利用した（Ｂ）の処理は、容易に実行することができないのである。
【００１８】
以上のことから、ＲＤＢは、その設計時に想定された使い方には適合している反面、想定から少し外れた使い方をしようとすると、能率が悪いことがわかる。ここで、設計時に想定された使い方とは、外延的な定義に用いた属性と、その値とでレコードを扱うことである。また、想定から少し外れた使い方とは、前述の（Ｂ）の処理のように、ＲＤＢに存在する属性とその値から導かれる性質によって内包的に規定されるレコードを扱うことである。
【００１９】
一般的に、ＤＢを設計してから時間がたつと、使い方が設計時の想定から外れて来ることは避けられない。なぜなら、ＤＢの方が、それを利用する応用プログラムよりも寿命が長いからである。つまり、ほとんどの場合、ＤＢは既に存在しており、プログラムは、ＤＢに存在する情報をなんとか利用しようという意図をもって書かれるのである。このようにＤＢの使い方が設計時の想定から外れる場合として、図５３の表に対する前述の処理に関連付けるならば、ＤＢの設計時には、「生年」という属性を検索できるようにしておけば十分だと考えられていたにも関わらず、実際には年齢順の方が使いやすいことが後で判明したりする場合などが挙げられる。このような場合、ＲＤＢでは、新たに「年齢順」という属性を設けることになる。これは表の作り直しに当り、レコード数が多いときは大変な作業である。
【００２０】
このことは、従来のデータベースにおける、表とレコードの対応関係（登録操作）が任意であるという本質的な特徴に起因する。すなわち、ユーザはデータベースの構築、利用にあたって、
「Ａ．レコードの作成、変更」
「Ｂ．レコードの表への登録、削除」
という２つの操作を関連付けて実行する必要がある。なぜなら、データを保存する際には、データベース中にあるレコードが存在している場合、このレコードの存在だけでなく、そのレコードがどの表に登録されており、どの表に登録されていないかということが重要だからである。したがって、１つのレコードが複数の表に登録されるべき内容を表している場合には、ユーザは、それを判断して、そのレコードを対応する複数の表に対して個別に登録しなければならない。
【００２１】
例えば、イベントスケジュール管理のデータベースにおいて、将来のイベントを管理している表（表名：ＦＵＴＵＲＥ ＥＶＥＮＴ）には、「時刻 イベント」のレコードが、イベントとその発生時刻を表すために登録される。ここで、各イベントには、不定人数の参加者が予定されているとする。これに対して、この予定される参加者に関する表（表名：ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ ）を作成し、この表に、「参加者 イベント」のレコードを登録する。そして、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」に登録されている「時刻 イベント」のレコードは、イベントが生起すると削除され、すでに生起したイベントを管理している表（表名：ＰＡＳＴ ＥＶＥＮＴ）に登録される。
【００２２】
この場合、それぞれの表は、その目的に適した形式のレコードのみを効率的に登録しているが、１つのイベントに関してどのような情報が登録されているかという検索は、３つの表（ＦＵＴＵＲＥ ＥＶＥＮＴ、ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ 、ＰＡＳＴ ＥＶＥＮＴ）を個別に調べなければ実行できない。例えば、あるイベントに関する「時刻 イベント」のレコードは、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」か表「ＰＡＳＴ ＥＶＥＮＴ」かどちらか一方に必ず含まれているはずであるが、これを確認するためには、両方の表を同時に調べなければならない。また、イベント生起時には、一方の表からそのイベントに関するレコードを削除し、かつ、他方の表にそのイベントに関するレコードを登録するという２つの処理を、ユーザの責任において同時に行わなければならない。ここに誤りが生じる可能性があり、かつ、誤りの検出にも手間がかかる。
【００２３】
このような問題を回避する一つの方法として、「ＦＵＴＵＲＥ ＥＶＥＮＴ」と「ＰＡＳＴ ＥＶＥＮＴ」という２つの表の別をやめて、例えば、１つの表（表名：ＥＶＥＮＴ ）を作成し、この表「ＥＶＥＮＴ 」に、「ＦＵＴＵＲＥ／ＰＡＳＴ 時刻 イベント」というレコードとして、イベントのスケジュールを登録することが考えられる。ここで、フィールド「ＦＵＴＵＲＥ／ＰＡＳＴ」は、ＦＵＴＵＲＥ ｏｒ ＰＡＳＴを意味する。この方法を採用した場合、イベント生起時には、前述の方法のように、異なる表に対する２つの処理（削除と登録）を行う必要なく、「ＦＵＴＵＲＥ／ＰＡＳＴ 」のフィールド値の変更という１つの処理を行うだけでよいため、誤りが発生する可能性が極めて少なくなり、かつ、誤りの検出も比較的容易になる。
【００２４】
その反面、この方法での処理を進めるためには、結局、関連性のあるレコードを登録する表をすべて融合して１つの表とすることになるため、有効に使われない多くのフィールドを含む長尺なレコードを登録することになる。このような無駄の多い長尺なレコードを多数登録することは、レコードを収納する表を設定することによるデータベースの効率的運用を放棄することに他ならない。
【００２５】
以上のように、表を設定し、その表に対してレコードを任意に登録、削除することでデータを効率的に蓄積利用しようとする従来のデータベースシステムにおいては、表とレコードの対応関係の意図的な管理に多くの労力を要し、その分だけ多くのコストが費やされている。また、従来のデータベースにおいては、レコードの内容すなわちフィールド値に関して、あるフィールド値を持つレコードの指定した表への（正しいレコードとしての） 登録の可否を制限することはあっても、そのレコードがどの表に登録されるべきであるかを指示する機能、あるいは、実際に自動的に登録を行う機能は、設けられていない。
【００２６】
したがって、従来のデータベースにおいて、特定のフィールド値に関して、どのようなレコードがそのフィールド値を有し、また、そのフィールド値を有するレコードがどのような表に登録されているかを検索することは困難である。すなわち、フィールド値は、文字列や数値であり、それが各レコード（の各フィールド） でどのような意味に用いられるかはユーザの任意である。そのため、異なる表の異なるレコード間で、同一のフィールド値が全く異なる意味で用いられることは十分ありうる。このような同一のフィールド値の異なる意味での使用は、データベース中におけるデータ処理の混乱を来し、極めて不都合である。したがって、ユーザがレコードを作成する際には、それぞれのフィールド値が、そのときすでにデータベース中に使用されているフィールド値とどういう関連を持つかを把握することが不可欠である。そして、このように、特定のフィールド値の情報をデータベース全体にわたって完全に把握するためには、従来のデータベースにおいて、関連する（レコードを含む） 可能性のある表のレコードをすべて調べて結論を出さなければならない。しかしながら、このような検索の実行には、大変な手間がかかり、また、個々のフィールド値ごとに可能性のある表やフィールドの情報をユーザが維持管理すること自体が困難である。
【００２７】
本発明は上記のような従来技術の課題を解決するために提案されたものであり、その目的は、新たに登録するデータまたは内容を変更するデータとすでに登録されているデータとの関連を容易に把握可能であり、表とデータの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することである。
【００２８】
【課題を解決するための手段】
本発明によるデータベース装置は、文字列、整数、および浮動小数点数の中から選ばれた単一種類または複数種類の値を示すワードを、序列をもって複数個並べることにより構成されたラインが、複数の表に登録されたデータベース装置において、管理手段、表指定手段、ソート手段、検索手段、を備えたことを特徴とするものである。ここで、管理手段は、個々の表について、入力されるラインにおける複数の序列位置の中から選択された判定用の位置のワードとして特定値を持つラインを登録するというワードの条件と、複数の序列位置の中から判定用の位置とは別に選択されたソート用の位置のワードの値でソートするというソート規則とを含む表情報により定義される複数の表の登録条件を管理する手段である。また、表指定手段は、表の登録条件に基づき、入力されたラインを登録する複数の表を指定する手段である。また、ソート手段は、表に登録されたラインを、各表に設定されたソート規則によって特定される序列位置のワードの値に基づいて各表の上でソートする手段である。さらに、検索手段は、表指定手段によって指定された各表の上で、ソート手段によってソートされた順序に基づき、ラインをそれぞれ検索する手段である。
【００２９】
【作用】
以上のような構成を有する本発明の作用は次の通りである。まず、ラインにおける複数の序列位置について、判定用の位置におけるワードの値に応じて当該ラインの登録を判定するためのワードの条件と、ソート用の位置におけるワードの値でソートするためのソート規則とを含む表情報により登録条件を定義しているため、この登録条件により、１つのラインと、このラインを登録すべき複数の表との対応関係を明確に示すことができる。その結果、ラインを登録する際には、表指定手段により、ラインと表の対応関係を示す登録条件に基づき、ラインを構成する複数のワードの値に応じて、収納すべき複数の表を自動的に指定できるため、１つのラインを異なるソート規則を持つ複数の表に容易に登録できる。したがって、設計時に想定されなかった使い方に柔軟に対処可能であり、操作性および能率を向上できる。
【００３０】
一方、本発明では、表指定手段により、１つのワードが収納されている表を自動的に特定可能であり、また、表指定手段に加えて検索手段を使用することにより、１つのワードによるラインの検索を容易に行うことができる。したがって、１つのワードの情報をデータベース全体にわたって容易に把握でき、データベースにすでに登録されたラインと新しく登録されるラインとの関連を容易に把握することができる。加えて、ソート手段を利用していることから、ソート順によるラインの検索や、検索されたラインの位置の決定なども自動的に簡単に行えるため、検索処理や、検索の必要な削除処理、変更処理などの能率を向上できる。
【００３１】
【実施例】
［装置構成］
以下には、本発明によるデータベース装置の構成について、図１を参照して説明する。ここで、図１は、本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図である。この図１に示す装置は、入力手段１、格納手段２、表指定手段３、管理手段４、登録手段５、ソート手段６、検索手段７、削除手段８、出力手段９を備えており、複数のワードの順序列をラインとして、複数のラインを複数の条件に合致する複数の表に対して個別・選択的に登録・削除するとともに、ワードの内容に基づいてラインを検索するように構成されている。
【００３２】
入力手段１は、複数のワードの順序列をラインとして入力する機能と、すでに登録済みのラインを、ワードの内容またはラインの位置によって指定し、検索指令、削除指令、または変更指令を入力する機能を有する。格納手段２は、各表に設定されたソート規則と各表に登録されたライン情報およびそのソート順情報を含む複数の表情報を格納する機能を有する。
【００３３】
表指定手段３は、ラインと表の対応関係を示す予め設定された一定の登録条件を有し、入力手段１によるラインの入力に応答して、入力されたラインのワードの内容と登録条件に基づき、そのラインを登録する複数の表を指定する機能と、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、指定されたラインのワードの内容と登録条件に基づき、そのラインが登録された複数の表を指定する機能を有する。
【００３４】
管理手段４は、格納手段２に格納された複数の表情報を管理し、表指定手段３によって指定された複数の表情報を提供する機能と、登録手段５およびソート手段６による登録情報と、削除手段８による削除情報によって管理情報を更新する機能と、検索手段７による検索情報を管理する機能を有する。
【００３５】
登録手段５は、入力手段１によるラインの入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表に、入力手段１によって入力されたラインをそれぞれ登録する機能を有する。ソート手段６は、登録手段５によって複数の表に登録されたラインを、各表に設定されたソート規則によって特定される位置のワードの内容に基づいて表の上にソートする機能を有する。
【００３６】
検索手段７は、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表の上で、ソート手段６によってソートされた順序に基づき、入力手段１によって指定された登録済みのラインをそれぞれ検索する機能を有する。削除手段８は、入力手段１による登録済みのラインの削除指令または変更指令の入力に応答して、検索手段７によって検索された複数の表情報を受け取り、各表の上で検索されたラインを削除する機能を有する。出力手段９は、管理手段４による管理情報を出力する機能を有する。
【００３７】
また、一般的には、管理手段４は表作成手段１０を有している。この表作成手段１０は、表指定手段３によって指定された表が格納手段内に存在していない場合に、指定された表に合致する新たな表を作成する機能を有する。一方、ラインを構成するワードとしては、例えば、２つの文字列の順序対、文字列と整数の順序対、２つの整数の順序対、または、１つの浮動小数点数の４種類のいずれかを使用することが可能である。より一般的には、文字列、整数、浮動小数点数、およびそれらの任意個数の順序組を使用することが可能である。さらに、本発明においては、表上のラインをソートするソート手段６として、例えば、二分探索木を使用することが可能であるが、二分探索木と同様に、ラインのソート、検索、登録、および削除が可能であれば、別のソート手段を使用することも可能である。
【００３８】
次に、本発明において、表指定手段３に予め設定される登録条件、すなわち、ラインと表の対応関係を示す一定の登録条件について説明する。まず、１つのラインは、ｎワード（ｗ１ ，…，ｗｎ ）の順序列で構成される。そして、１つのラインを登録するｋ種類の表は、Ｈ１ ，…，Ｈｋ と表される。なお、本発明においては、１つのラインが、必ずｋ種類の表に登録されるわけではなく、ラインの内容によって登録される表の数が異なる場合もある。
【００３９】
ここで、ｘ＝ワード ｏｒ ライン、 Ｎ＝１〜ｎの数、 Ｓ＝ソート規則として、各表を（ｘ，Ｎ，Ｓ）で表すことを考える。この場合、ｘがワードであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがワードｘであるようなラインからなり、ソート規則がＳである表を表す。また、ｘがラインであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがラインｘのＮ番目のワードであるようなラインからなり、ソート規則がＳである表を表す。さらに、ｉ＝１，…，ｋとした場合、ｉ番目の表Ｈｉは（ｘ，Ｎｉ，Ｓｉ）と表される。
【００４０】
［処理手順の概要］
図２〜図５は、図１に示すデータベース装置の一般的な処理手順の例を示すフローチャートであり、図２は登録処理、図３は検索処理、図４は削除処理、図５は変更処理をそれぞれ示している。以下には、各処理手順の概要について順次説明する。
【００４１】
まず、ラインを登録する場合には、図２に示すように、ステップ１において、入力手段１により、ラインを構成するｎ個のワード（ｗ１ ，…，ｗｎ ）が作成され、ステップ２において、ｎ個のワード（ｗ１ ，…，ｗｎ ）の順序列であるラインＬが作成され、入力される。ステップ３において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、そのラインＬを登録するｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ４において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ１ ，…，Ｈｋ のうちで存在しない表がある場合には、ステップ５において、表作成手段１０により、必要な表が作成される。ステップ６において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が登録手段５に提供され、登録手段５により、各表にラインＬが登録される。ステップ７において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、登録処理を終了する。
【００４２】
次に、ラインを検索する場合には、図３に示すように、ステップ１１において、入力手段１により、検索するラインＬが指定され、ステップ１２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ１３において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索され、検索処理を終了する。
【００４３】
また、ラインを削除する場合には、図４に示すように、ステップ２１において、入力手段１により、削除するラインＬが指定され、ステップ２２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ２３において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索される。ステップ２４において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表からラインＬが削除され、削除処理を終了する。
【００４４】
一方、ラインを変更する場合には、図５に示すように、ステップ３１において、入力手段１により、変更するラインＬが指定され、ステップ３２およびステップ３３において、変更後のｎ個のワードとその順序列である変更後のラインＬ´が作成され、入力される。ステップ３４において、表指定手段３により、変更前のラインＬのワードの内容と予め設定された登録条件に基づき、変更前のラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ３５において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、指定されたラインＬが各表においてソート順に検索される。ステップ３６において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表から変更前のラインＬが削除される。ステップ３７において、表指定手段３により、変更後のラインＬ´のワードの内容と予め設定された登録条件に基づき、そのラインＬ´を登録するｋ種類の表Ｈ１ ´，…，Ｈｋ ´が自動的に指定される。ステップ３８において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ１ ´，…，Ｈｋ ´のうちで存在しない表がある場合には、ステップ３９において、表作成手段１０により、必要な表が作成される。ステップ４０において、指定されたｋ種類の表Ｈ１ ´，…，Ｈｋ ´の情報が登録手段５に提供され、登録手段５により、各表に変更後のラインＬ´が登録される。ステップ４１において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、変更処理を終了する。
【００４５】
本発明の代表的な実施例においては、１つのラインは３つのワードによって構成されている。そこにおいて、ワードは、文字列 文字列、文字列 整数、整数整数順序対のいずれかであるか、または浮動小数点数である。１つのラインを登録するときには、このラインは、ラインを構成する３つのワードとソートキーの違いによって同時に４つの表に自動的に登録される。この４つの表は、登録する１つのラインの３つのワードが左から順にａ，ｂ，ｃである場合に、（ｂ，Ｈ）、（ｂ，Ｍ）、（ａ，ｈ）、（ｃ，ｍ）、と表される。ここで、（ｂ，Ｈ）は、中央のワードがｂであるラインの集まりで、左のワードがソートキーである表を表す。（ｂ，Ｍ）は、中央のワードがｂであるラインの集まりで、右のワードがソートキーである表を表す。（ａ，ｈ）は、左のワードがａであるラインの集まりで、中央のワードがソートキーである表を表す。（ｃ，ｍ）は、右のワードがｃであるラインの集まりで、中央のワードがソートキーである表を表す。後述するように、例えば、１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＥＣＥ ８００ −１ 」をデータベースに登録する場合には、このラインは、４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）にそれぞれ登録される。また、１つのラインを削除する場合には、そのラインが登録されている４つの表すべてから自動的にそのラインが削除される。さらに、１つのラインの内容を変更する場合には、ラインを一旦４つの表から削除し、そのラインを変更し、変更した新たなラインを登録し直す。つまり、１つのラインを新たに登録すると最大４つの表が新たに作られる。
【００４６】
［具体的な実施例の内容］
以下には、本発明による具体的な実施例として、図１に示す構成を有するデータベース装置によって離散事象シミュレーションを行う例を説明する。なお、図１のデータベース装置を構成する手段（機能）とその作用は、前述した通りであるため、以下には、本実施例の特徴のみを説明する。
【００４７】
実施例を説明する前提として、離散事象シミュレーションについて説明する。離散事象シミュレーションにおいては、シミュレートするモデルの初期状態をデータベースに記述する。そして、データベースにある将来生起する事象リストのうち最も早く生起する事象の時刻に時間を進め、その事象を行う。ここで、事象を行うとは、その事象が起きることによってもたらされるモデルの変化を、モデルを記述しているデータベースに反映させることである。つまり、図６に示すように、シミュレーションの実行は、事象によってデータベースを書き換えることによって行われる。
【００４８】
本実施例では、以上のような離散事象シミュレーションを、図７に示すようなシミュレーションモデルに対して実行する。図７においては、窓口が１つしかない銀行のモデルを想定しており、客が窓口に来た順にサービスを受けてサービスが終了すると去っていく場合の、ある時点の状態を示している。この場合、複数の客は、異なる時間に順次到着し、前の客がサービス中ならば、前の客のサービスが終わるまで列に並んでおり、その客自身に対する窓口のサービスが終了した時点で退去するものとする。このモデルでは、客が５人いる。
【００４９】
図８は、図７のモデルの状態を表す全てのラインを示す表であり、これらのラインを、後述するような条件に従って登録すると、図９〜１２に示すような多数の表からなるデータベースが作成される。言い換えれば、図９〜１２は、図７のモデルの状態を表すデータベース全体を示している。このデータベースを構成する１つの表を図１３に例示する。図１３に示すように、表は、ある条件で集めた１つまたはそれ以上のライン集合からなる。図１３のライン集合を構成する１つのラインを図１４に例示する。図１４に示すように、１つのラインは３つのワードからなる。
【００５０】
本実施例においては、図１５の表に示すような４つの型のワードが、使用可能なワードとして設定されている。図１６は、図１５の４つの型のワードの例をそれぞれ示している。すなわち、型１のワードは２つの文字列の対で、型２は文字列、整数の対で、型３は２つの整数の対である。また、型４のワードは対ではなく、浮動小数点数１個でワードをなす。
【００５１】
ワード間の整列の順序は次のように決定されている。すなわち、基本的に、小さい方から大きい方に向かって上から下に並べるものとする。そして、型１、２、３は、型４より小さいものとする。また、型１、２、３の間の比較は、まず、ワードの対の左の要素を比較して決める。左の要素が同じ場合は、右の要素の比較によって決める。整数、浮動小数点数の間の比較は、それらの数の大小関係をそのまま使う。さらに、文字列と整数の間の比較は、文字列の方が小さいものとし、そして、これらの比較結果に従って、小さい方が上で、大きい方が下となるように並べる。一方、文字列間については、その文字列がデータベース内で使われた順序に従って、上から下に並べるものとする。
【００５２】
本実施例において、ラインは、単なる３つのワードの集まりではなく、その順序が極めて重要である。本実施例では、図示された表において、図中左のワードから右に向かって、それぞれ、左のワード、中央のワード、右のワードと称する。本実施例においては、１つのラインがデータベースに登録されるとき、ラインの内容、整列の基準となるワードを、左、中央、右のどのワードにしているかによって、自動的に同時に４つの表に登録される。登録すべき表が存在しなければ、表を新たに作成し登録する。
【００５３】
このような１つのラインを登録する４つの表を表すとき、ｘを任意のワードとして、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）というような記法を使用する。この場合、（ｘ，Ｈ）は、中央のワードがｘであるライン集合からなり、左のワードによってラインを整列した表である。（ｘ，Ｍ）は、中央のワードがｘであるライン集合からなり、右のワードによってラインを整列した表である。（ｘ，ｈ）は、左のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。（ｘ，ｍ）は、右のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。たとえば、図１４に示す１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」を登録する４つの表は、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）である。それぞれの表を、図１７〜２０に示す。
【００５４】
本実施例のデータベースは、このように、１つのラインに対して４つの表が用意されるので、図９〜１２に示すように、多数の表が集まって構成される。また、本実施例において、モデルの状態の記述は、主に以下の４種類のラインからなる。
【００５５】
第１に、事象の状態を表すラインがある。将来生起する事象リストである。これを表すラインの右のワードが、事象の種類を表す。本実施例では、事象は２つあり、到着事象と退去事象である。以下には、これらの事象をそれぞれ、「ＡＲ」と「ＬＶ」で表す。すなわち、到着事象「ＡＲ」は、客が銀行に到着することを実行し、退去事象「ＬＶ」は客が銀行から去ることを実行する。また、中央のワードは、既に実行が終った事象か将来起こる事象かを表すワードであり、「ＰＡＳＴ ＥＶＥＮＴ」または「ＦＵＴＵＲＥ ＥＶＥＮＴ」である。左のワードは、事象生起時刻を表している。たとえば、ライン「 ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０ 」は、これから起こる事象であり、生起時刻は１０００ｓｅｃ で、起こる事象は到着事象「ＡＲ」であることを示す。
【００５６】
第２に、このモデルにいる５人の客の状態と客のサービス時間を表すラインがある。このラインの左のワードは、客のＩＤ番号であり、中央のワードは客の状態を表し、右のワードでサービス時間を表す。サービス時間とは、客が窓口に入ったときサービスを終えるのに必要な時間のことである。客の状態は４種類あり、それを図２１に表す。この図２１に示すように、客がまだ銀行に来ていない状態（未到着状態）を「 ＣＯＭＩＮＧ ＩＮ」と表す。客が銀行に到着しているが、窓口でサービスを受けられず、列に並んでいる状態を「 ＩＮ ＬＩＮＥ」と表す。客がまさに窓口でサービスを受けている状態を「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」と表す。客がサービスを終了し銀行を去った状態を「 ＧＯＮＥ ＡＷＡＹ」と表す。たとえば、ライン「 ＣＵＳＴＯＭＥＲ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、ＩＤ番号１の客（客１と呼ぶ。）の状態が、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」（サービスを受けている）状態であり、客１が必要なサービス時間は、４００ ｓｅｃ であることを示す。
【００５７】
第３に、客の追跡情報を格納するラインがある。このラインには、左に客のＩＤ番号を表すワードがあり、中央にこのラインが客の追跡情報であることを表すワード「 ＴＲＡＣＥ ＴＲＡＣＥ」がある。右のワードの左の要素は、その客が銀行に到着した時刻を表す。右のワードの右の要素は、その客がサービスを終了し銀行を去った時刻を表す。これらの要素には、初期状態では負の数「−１」を入力する。
【００５８】
第４に、銀行でサービスを終えて去っていった客の、銀行に滞在していた平均時間を示すラインがある。このラインは、中央に、「 ＭＥＡＮ ＲＥＳＰＯＮＳＥ」というワードを持っている。左のワードの左の要素は、去った客の合計滞在時間を表し、左のワードの右の要素は、去った客の数を表す。また、右のワードは平均滞在時間（浮動小数点数）を表す。
【００５９】
本実施例においては、ラインの３つのワードのいずれかを変更すると、自動的に登録すべき４つの表に登録され整列される。たとえば、図１４に示すライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」の右のワードを「 ８００ １２００ 」に変更した場合を想定する。この場合、変更前のライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」は、前記の４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）からすべて消去される。そして、新しいライン「ｃｕｓｔｏｍｅｒ１ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００ 」が、新たに４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ １２００，ｍ）に登録される。この場合、登録される４つの表のうち、先の３つの表は変更前と変わらないが、表の中でのラインの位置が変わり得る。
【００６０】
また、本実施例において、表の検索をする場合には、（ｘ，Ａ）の表と指定することによって、表を検索することができる。ここで、ｘはワード、ＡはＨ，Ｍ，ｈ，ｍのいずれかである。図１３は、（ｃｕｓｔｏｍｅｒ １，ｈ）の表である。また、表（ｃｕｓｔｏｍｅｒ １，ｈ）の何番目のラインと指定して、ラインを検索することもできる。さらに、ラインの内容によってラインを検索することもできる。そしてまた、表（ｃｕｓｔｏｍｅｒ １，ｈ）のうち、右のワードが「ｓｅｃ ３５０ 」のラインを検索することができる。加えて、検索したラインが、その表の中でどの位置にあるを決定することができる。
【００６１】
以下には、本実施例における具体的なシミュレーション操作について説明する。
【００６２】
まず、図９〜１２に示すデータベースを用いて、次に生起する事象を検索する。この場合、次に起きる事象は、図９に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」に記述されている。このラインは、時刻１０００ ｓｅｃに到着事象「ＡＲ」が起こることを表している。そして、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」が生起した場合には、この到着事象「ＡＲ」により、図９〜１２に示されるデータが次のようにして書き換えられる。
【００６３】
到着事象「ＡＲ」は、未到着である客のうち、ＩＤ番号の最も小さい客を探して、銀行に到着させる。未到着である客についてのラインは、表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）に登録されており、この表は、客のＩＤ番号を表す左のワードをソートキーとして整列されている。この未到着の客をＩＤ番号順に表す表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を図２２に示す。この表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）の一番上のラインを検索すると、その左のワードから、客４が得られる。したがって、客４を到着させ、列に並ばせる。すなわち、客４の状態を、「 ＣＯＭＩＮＧ ＩＮ」から「 ＩＮ ＬＩＮＥ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」を、ライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」が、対応する４つの表に登録される。図２３の表（ ＩＮ ＬＩＮＥ，Ｈ）は、到着事象「ＡＲ」実行後における待ち行列中の客をＩＤ番号順に表している。客４が加わって客２、３、４の順に並んでいることがわかる。
【００６４】
次に、客４の追跡情報に関するラインを検索し、銀行到着時刻を記録する。この場合、追跡情報は、表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）に示される。この表の中で、左のワードが「 ｃｕｓｔｏｍｅｒ ４ 」であるラインを検索すると、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」が得られる。このライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」の右のワードの左の要素を、初期値「−１」からこの到着事象「ＡＲ」の時刻値「１０００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」をライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」が、客の追跡情報を表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。
【００６５】
続いて、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」を表している前記のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」は、将来生起する事象を客のＩＤ番号順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）と将来生起する事象を事象の種類順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「ｓｅｃ １０００ ＰＡＳＴ ＥＶＥＮＴ ＡＲ ０」が、過去に生起した事象を表す表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。
【００６６】
図２４は、以上のような時刻１０００ ｓｅｃにおける到着事象「ＡＲ」実行後のモデルの状態を表している。図２５は、図２４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図２６〜２９に示すような多数の表からなるデータベースが作成される。この図２６〜２９に示すデータベースにおいて、次に生起する事象は、図２６に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」に記述されている。このラインは、時刻１２００ ｓｅｃに退去事象「ＬＶ」が起こることを表している。そして、この時刻１２００ ｓｅｃにおける退去事象「ＬＶ」が生起した場合には、この退去事象「ＬＶ」により、図２６〜２９に示されるデータが次のようにして書き換えられる。
【００６７】
退去事象「ＬＶ」は、まず、現在窓口にいる客を、表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）から検索する。この窓口にいる客をサービス時間順に表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）には、図２７に示されるように、１つのライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」のみが登録されている。このラインから、現在窓口にいる客が、客１であることがわかる。したがって、客１を銀行から退去させる。すなわち、このライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」において、客の状態を示す中央のワードを、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」から「 ＧＯＮＥ ＡＷＡＹ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」が、対応する４つの表に登録される。
【００６８】
次に、列の先頭で待っている客を窓口に入れる。待ち行列中の客をＩＤ番号順に表す表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインを検索する。この表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインは、図２６に示されるように、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」である。このラインから、次に窓口に入る客が、客２であることがわかる。したがって、客２を窓口に入れる。すなわち、このライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」において、客の状態を示す中央のワードを「ＩＮ ＬＩＮＥ 」から「ＢＥＩＮＧ ＳＥＲＶＥＤ」に書き換え、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」を、ライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」が、対応する４つの表に登録される。
【００６９】
以上のような操作の結果、現在窓口にいる客を表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）と、待ち行列中の客を表す表（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｍ）の内容が変更される。また、退去した客に関するラインを、前述のように変えた結果、新たに、退去した客を示す表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ ＧＯＮＥ ＡＷＡＹ，Ｍ）が作成される。図３０は、このような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行前の客の状態を表す３つの表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示しており、図３１は、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後の客の状態を表す４つの表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示している。
【００７０】
本実施例において、上述のように、新たに窓口に客２が入ると、その客２が窓口を去る退去時刻は、「現時刻＋サービス時間」によって決定される。すなわち、次の退去事象「ＬＶ」が生起する時刻である。この例において、客２の退去時刻は、「１２００＋３００」から、１５００ ｓｅｃになる。次の退去事象「ＬＶ」が１５００ ｓｅｃに生起するので、この事象に関するラインを新たに登録する。すなわち、ライン「 ｓｅｃ １５００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０ 」を、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録する。また、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」を表している前記のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」は、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｓｅｃ １２００ ＰＡＳＴ ＥＶＥＮＴ ＬＶ ０」が、過去に生起した事象の表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の内容は、図３２のようになる。
【００７１】
さらに、客１の追跡情報に関するラインを検索し、銀行退去時刻を記録する。すなわち、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の中で、客１に関するライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」の右のワードの右の要素を、初期値「−１」からこの退去事象「ＬＶ」の時刻値「１２００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」が、客の追跡情報の表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の内容は、図３３のようになる。
【００７２】
図３４は、以上のような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後のモデルの状態を表している。図３５は、図３４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図３６〜３９に示すような多数の表からなるデータベースが作成される。
【００７３】
なお、本発明は、前記実施例に限定されるものではなく、例えば、１つのラインを構成するワードの数は３つに限らず、４つ以上のワードによって１つのラインを構成することも可能であり、逆に、２つのみのワードによって１つのラインを構成することも可能である。また、表のソート規則およびそれに関連する一定の登録条件の設定内容についても自由に設定可能である。例えば、ある位置のワードでソートするだけの単純なソート規則、あるいは逆に、複数のワードをソートキーにするソート規則などを使用することが可能であり、このようなソート規則に応じて、登録条件の内容を適宜設定することができる。
【００７４】
より具体的に、前記実施例の変形例として、３つのワードで構成される１つのラインを登録する表として、前記実施例における４つの表に加え、さらに、左のワードが同じであるライン集合からなり、右のワードをソートキーとする第５の表を対応させるように構成する実施例などが考えられる。また、１つのラインを５つのワードで構成し、１つのラインを登録する表として、第１のワードが同じであるライン集合からなり、第２のワードをソートキーとする第１の表と、第２のワードが同じであるライン集合からなり、第３のワードを第１ソートキー、第４のワードを第２ソートキーとする第２の表、およびその他の数種類の表を対応させるように構成する実施例なども考えられる。
【００７５】
ところで、本発明において、ラインをソートするソート手段としては、各種の手段を使用可能であるが、例えば、ソート、検索、登録、および削除可能な二分探索木を使用することが可能である。以下には、この二分探索木について簡単に解説する。
【００７６】
まず、二分木といくつかの言葉を定義する。図４０のように、二分木はノード（○印）とノードの間の親子関係を示す枝（／ ＼）からなり、どのノードも、子ノードを最大２つしか持たず、かつ、ある１つのノード以外のどのノードも、親ノードをただ１つだけ持つ。左下の子ノードを左子ノード、右下の子ノードを右子ノードと呼ぶ。親ノードを持たない唯一のノードを根ノードと呼ぶ。図４０において、ノード（１）はノード（２）の親ノードであり、ノード（２）はノード（１）の右子ノードである。ノード（３）は二分木の根ノードである。ノードの左（右）の子ノードの下の構造全体を左（右）部分木と言う。図４０において、部分木（４）はノード（１）の右部分木である。
【００７７】
本発明において利用する二分木は、ソート規則の定められた対象があり、二分木のノードがその対象（前記実施例においては、データベースのライン）を指示していて、二分木の任意のノードが指示している対象が、そのノードの左（右）部分木のどのノードが指す対象と比して大きい（小さい）ような二分木である。等しい場合を左に含めるか右に含めるかは二分探索木を使う事情による。ただし、小さい方が表の上にあり、大きい方が表の下にある。
【００７８】
たとえば、図４１は、整数をソートしている二分探索木である。なお、この図４１では、図面の簡略化の目的で、ノードが指示している対象である整数を直接ノードに書き込んでいる。この図４１において、ノード（１）が指す整数「５４」は、その右部分木（２）のどのノードの指示する整数「６０」、「５８」、「７１」、「５６」よりも小さい。
【００７９】
図４２は、このような二分探索木での検索方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木で整数「９」を検索する場合には、次のような手順の処理を行うことになる。この処理について、図４１を参照して説明する。なお、以下の説明において、Ｎは現在のノードを意味する。まず、図４１の根ノード（３）をＮとする。この場合、検索する整数「９」はＮが指示する整数「４６」より小さい。したがって、Ｎの左子ノード（４）を新たにＮにする。この場合、検索する整数「９」はＮが指示する整数「１３」より小さい。したがって、Ｎの左子ノード（５）を新たにＮとする。この場合、Ｎが指示する整数は「９」であり、このノードが、検索目的のノードである。
【００８０】
図４３は、二分探索木での登録方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木に対して、整数「４８」を指示するノードを登録する場合には、次のような手順の処理を行うことになる。この処理について、図４４を参照して説明する。まず、図４４の根ノード（１）をＮにする。この場合、登録する整数「４８」は、Ｎが指示する整数「４６」より大きい。よって、Ｎの右子ノード（２）を新たにＮとする。この場合、登録する整数「４８」はＮが指示する整数「５４」より小さい。したがって、Ｎの左子ノード（３）を新たにＮにする。この場合、登録する整数「４８」はＮが指示する整数「４９」より小さいが、現在のノードＮの左には子ノードがないので、Ｎを親ノードとして、整数「４８」を指示する左子ノード（４）を作成する。
【００８１】
図４５は、二分探索木での削除方法の一例を示すフローチャートである。このフローチャートによって、次のような処理を行うことができる。すなわち、まず、ノードＡを削除する場合、そのノードＡが子ノードを全く持たない場合には、図４６に示すように、そのままノードＡを削除する。また、ノードＡが左（右）子ノードだけしか持たない場合には、図４７に示すように、このノードＡを消して、左（右）部分木をノードＡの位置に付け替える。一方、ノードＡが左右の両子ノードを持つ場合には、図４８に示すように、ソート順においてノードＡの１つ前のノード（これはノードＡの左部分木の中で最も右にあるノードである。）をＮとして（図４８の左の状態）、ノードＡとノードＮを入れ替える（図４８の操作▲１▼：左→中央の状態）。このように入れ替えた際に、ノードＡが左部分木を持たない場合には、単にノードＡを消す。ノードＡが左部分木を持つならば、その左部分木をノードＡの位置に付け替える（図４８の操作▲２▼：中央→右の状態）。
【００８２】
なお、ラインをソートするソート手段として、このような二分探索木を用いることは有効であるが、前述の通り、ラインのソート、検索、登録、および削除である限り、他のソート手段を使用することも同様に可能である。
【００８３】
続いて、本発明におけるデータベースへの機能の実装例を、図４９によって説明する。この例では、図４９の中央部分に６つのラインｘｕｗ、ｖｘｚ、ｗｘｙ、ｘｘｘ、ｙｘｘ、ｙｗｘが示されている。ここで、ｕ，ｖ，ｗ，ｘ，ｙ，ｚは、それぞれ異なるワードを表す。ラインの検索に際しては、各ワードに対応する４つの異なる表を使用できる。たとえば、ワードをｘとすると、４つの表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）で表される。これらの表は、図４９中において、二分探索木：木（１）〜（４）として表現されている。この場合、木の各ノードは、ラインとそのラインのソートキーになっているワードを指示している。たとえば、木（１）の根のノードはラインｗｘｙを指示し、さらにソートキーであるワードｗを指示している。逆にラインも対応するノードを指示している。ある木のノードが指示しているラインは、その木が表現する表に含まれることを意味する。たとえば表（ｘ，Ｈ）に対応する木（１）には、ラインｘｘｘを指示するノードがあるので、ラインｘｘｘは、表（ｘ，Ｈ）に含まれている。
【００８４】
表（ｘ，Ｈ）は左のワードがソートキーなので、この表を表現する二分探索木の各ノードは、対応するラインと左のワードを指示している。すなわち、各表の各ワードは、対応するラインを指示するとともに、（ｘ，Ｍ）なら右、（ｘ，ｈ）、（ｘ，ｍ）なら中央のワードも指示している。たとえば、図４９のラインｘｘｘは、４つの表を表現する４つの二分探索木のノードによって指示されている。また逆に、ラインｘｘｘは、このラインｘｘｘを指示するノードを指示している。つまり、このラインｘｘｘを指定することにより、このラインｘｘｘを含む４つの表を表現している４つの二分探索木を見つけられる。
【００８５】
以上のような構造を有する図４９のデータベースにおいて、ラインを削除する方法を説明する。データベース上からラインｘｘｘを削除する場合には、このラインｘｘｘを含む４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）からラインｘｘｘを削除する。この場合、図４９上の木（１）〜（４）のラインｘｘｘを指示しているノードを削除しなければならない。ノードの削除は、二分探索木に関して前述した手順に従う。その結果、図５０に示すような、ラインｘｘｘのないデータベースが得られる。
【００８６】
逆に、図５０に示すようなデータベースに対して、ラインｘｘｘを登録するときは、４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）にそれぞれラインｘｘｘを登録しなければならない。この場合、これらの４つの表に対応する木（１）〜（４）にラインｘｘｘを指示するノードを登録する。ノードの登録の手順は、二分探索木に関して前述した手順に従う。
【００８７】
さらに、図４９のデータベースにおける任意のラインの検索は、図５１のようにして行うことができる。この図５１は、一例として、左と中央にワードｘを持つラインｘｘ？を１つ検索し、右のワードを検索する場合の手順を示している。このラインｘｘ？を含む可能性のある表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）である。中央のワードがｘで、左のワードをソートキーとする表（ｘ，Ｈ）を使用することにより、目的のラインを探索できる。この図５１上で、まず、ワードｘを起点とする矢印（１）をたどると、矢印（１）は表（ｘ，Ｈ）を指示している。この表のラインは、整列順を保持するため、二分探索木のノードに格納されている。表（ｘ，Ｈ）から矢印（２）をたどると、その二分探索木：木（３）の根を指示している。木の根を指示することは、木自体を指示することに等しい。また逆に、表（ｘ，Ｈ）のラインは、木（３）の各ノードから指示されている。
【００８８】
続いて、木（３）の根から矢印（４）をたどると、根のノードが指示しているラインはｗｘｙである。この場合、ラインｗｘｙと検索するラインｘｘ？の大小を比較するとｘｘ？の方が大きい（つまり表の下、木のノードの右にある）。そこで、木（３）の根の右の枝（５）を下がり、その先のノードが矢印（６）によって指示するラインｙｘｘと比較する。この場合、ｘｘ？の方が小さいので、左の枝（７）を下がる。その枝（７）の先のノードが矢印（８）によって指示するラインはｘｘｘであり、検索しているラインに該当する。したがって、左と中央にワードｘを持つラインｘｘ？の右のワードはｘであることがわかる。
【００８９】
【発明の効果】
以上説明したように、本発明においては、ラインと表との対応関係を示す一定の登録条件を予め設定しておくことにより、この登録条件に基づいて、１つのラインを登録する複数の表を自動的に指定することができるため、新たに登録するラインまたは内容を変更するラインとすでに登録されているラインとの関連を容易に把握可能であり、表とラインの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することができる。
【図面の簡単な説明】
【図１】本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図。
【図２】本発明によるデータベース装置の一般的な登録処理手順の一例を示すフローチャート。
【図３】本発明によるデータベース装置の一般的な検索処理手順の一例を示すフローチャート。
【図４】本発明によるデータベース装置の一般的な削除処理手順の一例を示すフローチャート。
【図５】本発明によるデータベース装置の一般的な変更処理手順の一例を示すフローチャート。
【図６】離散事象シミュレーションの手順を示す説明図。
【図７】本発明のデータベース装置によって離散事象シミュレーションを行う一実施例において、シミュレートするモデルの１つの状態を示す模式図。
【図８】図７のモデルの状態を表す全てのラインを示す表。
【図９】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１０】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１１】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１２】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１３】図９〜１２のデータベースを構成する１つの表を示す図。
【図１４】図１３のライン集合を構成する１つのラインを示す図。
【図１５】本発明において使用可能なワードの４つの型を示す表。
【図１６】図１５のワードの例を示す表。
【図１７】図１４のラインを登録する１つの表を示す図。
【図１８】図１４のラインを登録する１つの表を示す図。
【図１９】図１４のラインを登録する１つの表を示す図。
【図２０】図１４のラインを登録する１つの表を示す図。
【図２１】図７のモデルにいる客の４種類の状態を示す表。
【図２２】図９〜１２のデータベースを構成する表のうち、未到着の客をＩＤ番号順に表す表。
【図２３】図９〜１２のデータベースを用いた離散事象シミュレーションによる到着事象実行後の待ち行列中の客をＩＤ番号順に表す表。
【図２４】図７のモデルの、離散事象シミュレーションによる到着事象実行後における状態を示す模式図。
【図２５】図２４のモデルの状態を表す全てのラインを示す表。
【図２６】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２７】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２８】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２９】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３０】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行前の客の状態を表す３つの表を示す図。
【図３１】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の客の状態を表す４つの表を示す図。
【図３２】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、将来生起する事象を時刻順に表す表の内容を示す図。
【図３３】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、客の追跡情報を客のＩＤ番号順に表す表の内容を示す図。
【図３４】図２４のモデルの、離散事象シミュレーションによる退去事象実行後における状態を示す図。
【図３５】図３４のモデルの状態を表す全てのラインを示す表。
【図３６】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３７】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３８】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３９】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図４０】本発明によるデータベース装置においてソート手段として使用可能な二分探索木の一例を示す図。
【図４１】整数をソートしている二分探索木の一例を示す図。
【図４２】二分探索木での検索方法の一例を示すフローチャート。
【図４３】二分探索木での登録方法の一例を示すフローチャート。
【図４４】図４１の二分探索木に対して、新しいノードを登録する手順とそれを登録した二分探索木を示す図。
【図４５】二分探索木での削除方法の一例を示すフローチャート。
【図４６】図４５の方法による削除操作の一例を示す説明図。
【図４７】図４５の方法による削除操作の一例を示す説明図。
【図４８】図４５の方法による削除操作の一例を示す説明図。
【図４９】本発明に従って機能を実装したデータベースの一例を示す説明図。
【図５０】図４９のデータベースから１つのラインを削除して得られたデータベースを示す説明図。
【図５１】図４９のデータベースにおける任意のラインの検索手順を示す説明図。
【図５２】データベースに登録されるリレーションの一例を示す表。
【図５３】データベースに登録されるリレーションの一例を示す表。
【符号の説明】
１…入力手段
２…格納手段
３…表指定手段
４…管理手段
５…登録手段
６…ソート手段
７…検索手段
８…削除手段
９…出力手段
１０…表作成手段
【産業上の利用分野】
本発明は、データベース装置に関する。
【０００２】
【従来の技術】
データベース（ＤＢ）技術の目的は、データの内部構造を、それを利用する応用プログラムから独立させることである。
【０００３】
従来のＤＢシステムの概念上の枠組みには、階層、ネットワーク、リレーショナルなどの代表的なものがある。それらのうち、リレーショナル・データベース（ＲＤＢ） が最も理論的に整理されており、現在では標準的な技術となっている。このＲＤＢの基礎概念は、「関係」である。この点について、以下に説明する。
【０００４】
例えば、ｎ個の集合Ｓ１ ，…，Ｓｎ の直積集合Ｒを次のように定義する。
【０００５】
【数１】
【０００６】
【数２】
【０００７】
【数３】
【０００８】
【数４】
【０００９】
このように、ＲＤＢにおいては、リレーションという表を概念的な仲立ちとして、データレコードを計算機に収容する。もちろん、計算機の内部では複雑なデータ構造やアクセス手続きをとっている可能性が高い。しかし、ユーザからはその複雑な実装が見えない。実装に関する情報は隠蔽されている。単なる表、すなわちデータの容器があって、ユーザはその容器にレコードを入れるという利用法である。
【００１０】
ＲＤＢは、次のような４つの処理機能を持つ。：
「１．レコードを収容する表を設定する。」
「２．表にレコードを登録する。」
「３．表からレコードを削除する。」
「４．表の中のレコードを検索する。」
そして、ＲＤＢの実装は、属性と属性値を指定すれば、レコードの登録処理、削除処理、および検索処理が能率良くできるようになっている。
【００１１】
ＲＤＢの特徴の１つは、表とレコードとの独立性が高いことである。ユーザは、まず表を設定し、しかる後にその表にレコードを登録する。あるレコードをある表に登録しておくか否かはユーザの任意である。検索したレコードのある属性値を変更する場合でも、レコードと表との対応関係に変化はない。ユーザがレコードと表との対応を変更するためには、上記のようなレコード登録、削除の操作が必要である。複数の表を指定してそれらに登録されているレコード間で演算を行って生じたレコードを、指定した新たな表に登録する場合でも、新たに生成されたレコードをどの表に登録するかは、ユーザが管理する。すなわち、ＲＤＢにおいて、表とレコードの対応関係は、ユーザが任意の表に任意のレコードを登録するという行為を通してのみ与えられる。
【００１２】
先に説明したように、関係は１つの集合である。一般に、集合の定義には、外延的な方法と内包的な方法がある。外延的な方法では、要素を全て列挙することによって集合を定義する。たとえば、０以上９以下の整数全体の集合Ｓを、次の式（５）に示すように定義するのが外延的な定義である。
【００１３】
【数５】
【００１４】
【数６】
【００１５】
この結果、ＲＤＢは次のような特徴を持つ。まず、リレーションに従って行う処理は、概念的に単純であり、能率良く行える。すなわちプログラムは簡単ですみ、計算量も少ない。たとえば図５３において、
「（Ａ）生年が‘６３年の者を検索する。」
という処理は、リレーションに従う処理であり、能率良く行うことができる。
【００１６】
【発明が解決しようとする課題】
これに対して、ＲＤＢにおいて、リレーションに従わない処理は、もともと想定されていなかった処理であるから、能率が悪い。たとえば、図５３において、
「（Ｂ）生年が若い順に３番めの者を検索する。」
という処理は、リレーションに従わない処理である。この処理は、仮に図５３の表中に「生年の順番」という属性がもともとありさえすれば、容易に実行できるものである。それにもかかわらず、図５３の表中においては、「生年の順番」という属性が、予め考えられてはいないので、（Ｂ）の処理を行うためには、登録されたレコードのうち生年を有するレコードを全て調べた上で、これらのレコードの順番を定めなければならない。このような検索を実行する場合には、プログラムが長くなり、計算量も多くなる。
【００１７】
さらに言及すれば、この場合、（Ｂ）の処理で用いる属性「生年の順番」は、（Ａ）の処理で用いる属性「生年」から自然に定まるものである。すなわち、属性「生年の順番」は、属性「生年」を有するレコードの関係の部分集合を規定する内包的な性質として、自然に存在するものである。それにも関わらず、属性「生年の順番」は、このＲＤＢには存在しない属性であるために、この属性を利用した（Ｂ）の処理は、容易に実行することができないのである。
【００１８】
以上のことから、ＲＤＢは、その設計時に想定された使い方には適合している反面、想定から少し外れた使い方をしようとすると、能率が悪いことがわかる。ここで、設計時に想定された使い方とは、外延的な定義に用いた属性と、その値とでレコードを扱うことである。また、想定から少し外れた使い方とは、前述の（Ｂ）の処理のように、ＲＤＢに存在する属性とその値から導かれる性質によって内包的に規定されるレコードを扱うことである。
【００１９】
一般的に、ＤＢを設計してから時間がたつと、使い方が設計時の想定から外れて来ることは避けられない。なぜなら、ＤＢの方が、それを利用する応用プログラムよりも寿命が長いからである。つまり、ほとんどの場合、ＤＢは既に存在しており、プログラムは、ＤＢに存在する情報をなんとか利用しようという意図をもって書かれるのである。このようにＤＢの使い方が設計時の想定から外れる場合として、図５３の表に対する前述の処理に関連付けるならば、ＤＢの設計時には、「生年」という属性を検索できるようにしておけば十分だと考えられていたにも関わらず、実際には年齢順の方が使いやすいことが後で判明したりする場合などが挙げられる。このような場合、ＲＤＢでは、新たに「年齢順」という属性を設けることになる。これは表の作り直しに当り、レコード数が多いときは大変な作業である。
【００２０】
このことは、従来のデータベースにおける、表とレコードの対応関係（登録操作）が任意であるという本質的な特徴に起因する。すなわち、ユーザはデータベースの構築、利用にあたって、
「Ａ．レコードの作成、変更」
「Ｂ．レコードの表への登録、削除」
という２つの操作を関連付けて実行する必要がある。なぜなら、データを保存する際には、データベース中にあるレコードが存在している場合、このレコードの存在だけでなく、そのレコードがどの表に登録されており、どの表に登録されていないかということが重要だからである。したがって、１つのレコードが複数の表に登録されるべき内容を表している場合には、ユーザは、それを判断して、そのレコードを対応する複数の表に対して個別に登録しなければならない。
【００２１】
例えば、イベントスケジュール管理のデータベースにおいて、将来のイベントを管理している表（表名：ＦＵＴＵＲＥ ＥＶＥＮＴ）には、「時刻 イベント」のレコードが、イベントとその発生時刻を表すために登録される。ここで、各イベントには、不定人数の参加者が予定されているとする。これに対して、この予定される参加者に関する表（表名：ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ ）を作成し、この表に、「参加者 イベント」のレコードを登録する。そして、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」に登録されている「時刻 イベント」のレコードは、イベントが生起すると削除され、すでに生起したイベントを管理している表（表名：ＰＡＳＴ ＥＶＥＮＴ）に登録される。
【００２２】
この場合、それぞれの表は、その目的に適した形式のレコードのみを効率的に登録しているが、１つのイベントに関してどのような情報が登録されているかという検索は、３つの表（ＦＵＴＵＲＥ ＥＶＥＮＴ、ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ 、ＰＡＳＴ ＥＶＥＮＴ）を個別に調べなければ実行できない。例えば、あるイベントに関する「時刻 イベント」のレコードは、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」か表「ＰＡＳＴ ＥＶＥＮＴ」かどちらか一方に必ず含まれているはずであるが、これを確認するためには、両方の表を同時に調べなければならない。また、イベント生起時には、一方の表からそのイベントに関するレコードを削除し、かつ、他方の表にそのイベントに関するレコードを登録するという２つの処理を、ユーザの責任において同時に行わなければならない。ここに誤りが生じる可能性があり、かつ、誤りの検出にも手間がかかる。
【００２３】
このような問題を回避する一つの方法として、「ＦＵＴＵＲＥ ＥＶＥＮＴ」と「ＰＡＳＴ ＥＶＥＮＴ」という２つの表の別をやめて、例えば、１つの表（表名：ＥＶＥＮＴ ）を作成し、この表「ＥＶＥＮＴ 」に、「ＦＵＴＵＲＥ／ＰＡＳＴ 時刻 イベント」というレコードとして、イベントのスケジュールを登録することが考えられる。ここで、フィールド「ＦＵＴＵＲＥ／ＰＡＳＴ」は、ＦＵＴＵＲＥ ｏｒ ＰＡＳＴを意味する。この方法を採用した場合、イベント生起時には、前述の方法のように、異なる表に対する２つの処理（削除と登録）を行う必要なく、「ＦＵＴＵＲＥ／ＰＡＳＴ 」のフィールド値の変更という１つの処理を行うだけでよいため、誤りが発生する可能性が極めて少なくなり、かつ、誤りの検出も比較的容易になる。
【００２４】
その反面、この方法での処理を進めるためには、結局、関連性のあるレコードを登録する表をすべて融合して１つの表とすることになるため、有効に使われない多くのフィールドを含む長尺なレコードを登録することになる。このような無駄の多い長尺なレコードを多数登録することは、レコードを収納する表を設定することによるデータベースの効率的運用を放棄することに他ならない。
【００２５】
以上のように、表を設定し、その表に対してレコードを任意に登録、削除することでデータを効率的に蓄積利用しようとする従来のデータベースシステムにおいては、表とレコードの対応関係の意図的な管理に多くの労力を要し、その分だけ多くのコストが費やされている。また、従来のデータベースにおいては、レコードの内容すなわちフィールド値に関して、あるフィールド値を持つレコードの指定した表への（正しいレコードとしての） 登録の可否を制限することはあっても、そのレコードがどの表に登録されるべきであるかを指示する機能、あるいは、実際に自動的に登録を行う機能は、設けられていない。
【００２６】
したがって、従来のデータベースにおいて、特定のフィールド値に関して、どのようなレコードがそのフィールド値を有し、また、そのフィールド値を有するレコードがどのような表に登録されているかを検索することは困難である。すなわち、フィールド値は、文字列や数値であり、それが各レコード（の各フィールド） でどのような意味に用いられるかはユーザの任意である。そのため、異なる表の異なるレコード間で、同一のフィールド値が全く異なる意味で用いられることは十分ありうる。このような同一のフィールド値の異なる意味での使用は、データベース中におけるデータ処理の混乱を来し、極めて不都合である。したがって、ユーザがレコードを作成する際には、それぞれのフィールド値が、そのときすでにデータベース中に使用されているフィールド値とどういう関連を持つかを把握することが不可欠である。そして、このように、特定のフィールド値の情報をデータベース全体にわたって完全に把握するためには、従来のデータベースにおいて、関連する（レコードを含む） 可能性のある表のレコードをすべて調べて結論を出さなければならない。しかしながら、このような検索の実行には、大変な手間がかかり、また、個々のフィールド値ごとに可能性のある表やフィールドの情報をユーザが維持管理すること自体が困難である。
【００２７】
本発明は上記のような従来技術の課題を解決するために提案されたものであり、その目的は、新たに登録するデータまたは内容を変更するデータとすでに登録されているデータとの関連を容易に把握可能であり、表とデータの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することである。
【００２８】
【課題を解決するための手段】
本発明によるデータベース装置は、文字列、整数、および浮動小数点数の中から選ばれた単一種類または複数種類の値を示すワードを、序列をもって複数個並べることにより構成されたラインが、複数の表に登録されたデータベース装置において、管理手段、表指定手段、ソート手段、検索手段、を備えたことを特徴とするものである。ここで、管理手段は、個々の表について、入力されるラインにおける複数の序列位置の中から選択された判定用の位置のワードとして特定値を持つラインを登録するというワードの条件と、複数の序列位置の中から判定用の位置とは別に選択されたソート用の位置のワードの値でソートするというソート規則とを含む表情報により定義される複数の表の登録条件を管理する手段である。また、表指定手段は、表の登録条件に基づき、入力されたラインを登録する複数の表を指定する手段である。また、ソート手段は、表に登録されたラインを、各表に設定されたソート規則によって特定される序列位置のワードの値に基づいて各表の上でソートする手段である。さらに、検索手段は、表指定手段によって指定された各表の上で、ソート手段によってソートされた順序に基づき、ラインをそれぞれ検索する手段である。
【００２９】
【作用】
以上のような構成を有する本発明の作用は次の通りである。まず、ラインにおける複数の序列位置について、判定用の位置におけるワードの値に応じて当該ラインの登録を判定するためのワードの条件と、ソート用の位置におけるワードの値でソートするためのソート規則とを含む表情報により登録条件を定義しているため、この登録条件により、１つのラインと、このラインを登録すべき複数の表との対応関係を明確に示すことができる。その結果、ラインを登録する際には、表指定手段により、ラインと表の対応関係を示す登録条件に基づき、ラインを構成する複数のワードの値に応じて、収納すべき複数の表を自動的に指定できるため、１つのラインを異なるソート規則を持つ複数の表に容易に登録できる。したがって、設計時に想定されなかった使い方に柔軟に対処可能であり、操作性および能率を向上できる。
【００３０】
一方、本発明では、表指定手段により、１つのワードが収納されている表を自動的に特定可能であり、また、表指定手段に加えて検索手段を使用することにより、１つのワードによるラインの検索を容易に行うことができる。したがって、１つのワードの情報をデータベース全体にわたって容易に把握でき、データベースにすでに登録されたラインと新しく登録されるラインとの関連を容易に把握することができる。加えて、ソート手段を利用していることから、ソート順によるラインの検索や、検索されたラインの位置の決定なども自動的に簡単に行えるため、検索処理や、検索の必要な削除処理、変更処理などの能率を向上できる。
【００３１】
【実施例】
［装置構成］
以下には、本発明によるデータベース装置の構成について、図１を参照して説明する。ここで、図１は、本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図である。この図１に示す装置は、入力手段１、格納手段２、表指定手段３、管理手段４、登録手段５、ソート手段６、検索手段７、削除手段８、出力手段９を備えており、複数のワードの順序列をラインとして、複数のラインを複数の条件に合致する複数の表に対して個別・選択的に登録・削除するとともに、ワードの内容に基づいてラインを検索するように構成されている。
【００３２】
入力手段１は、複数のワードの順序列をラインとして入力する機能と、すでに登録済みのラインを、ワードの内容またはラインの位置によって指定し、検索指令、削除指令、または変更指令を入力する機能を有する。格納手段２は、各表に設定されたソート規則と各表に登録されたライン情報およびそのソート順情報を含む複数の表情報を格納する機能を有する。
【００３３】
表指定手段３は、ラインと表の対応関係を示す予め設定された一定の登録条件を有し、入力手段１によるラインの入力に応答して、入力されたラインのワードの内容と登録条件に基づき、そのラインを登録する複数の表を指定する機能と、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、指定されたラインのワードの内容と登録条件に基づき、そのラインが登録された複数の表を指定する機能を有する。
【００３４】
管理手段４は、格納手段２に格納された複数の表情報を管理し、表指定手段３によって指定された複数の表情報を提供する機能と、登録手段５およびソート手段６による登録情報と、削除手段８による削除情報によって管理情報を更新する機能と、検索手段７による検索情報を管理する機能を有する。
【００３５】
登録手段５は、入力手段１によるラインの入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表に、入力手段１によって入力されたラインをそれぞれ登録する機能を有する。ソート手段６は、登録手段５によって複数の表に登録されたラインを、各表に設定されたソート規則によって特定される位置のワードの内容に基づいて表の上にソートする機能を有する。
【００３６】
検索手段７は、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表の上で、ソート手段６によってソートされた順序に基づき、入力手段１によって指定された登録済みのラインをそれぞれ検索する機能を有する。削除手段８は、入力手段１による登録済みのラインの削除指令または変更指令の入力に応答して、検索手段７によって検索された複数の表情報を受け取り、各表の上で検索されたラインを削除する機能を有する。出力手段９は、管理手段４による管理情報を出力する機能を有する。
【００３７】
また、一般的には、管理手段４は表作成手段１０を有している。この表作成手段１０は、表指定手段３によって指定された表が格納手段内に存在していない場合に、指定された表に合致する新たな表を作成する機能を有する。一方、ラインを構成するワードとしては、例えば、２つの文字列の順序対、文字列と整数の順序対、２つの整数の順序対、または、１つの浮動小数点数の４種類のいずれかを使用することが可能である。より一般的には、文字列、整数、浮動小数点数、およびそれらの任意個数の順序組を使用することが可能である。さらに、本発明においては、表上のラインをソートするソート手段６として、例えば、二分探索木を使用することが可能であるが、二分探索木と同様に、ラインのソート、検索、登録、および削除が可能であれば、別のソート手段を使用することも可能である。
【００３８】
次に、本発明において、表指定手段３に予め設定される登録条件、すなわち、ラインと表の対応関係を示す一定の登録条件について説明する。まず、１つのラインは、ｎワード（ｗ１ ，…，ｗｎ ）の順序列で構成される。そして、１つのラインを登録するｋ種類の表は、Ｈ１ ，…，Ｈｋ と表される。なお、本発明においては、１つのラインが、必ずｋ種類の表に登録されるわけではなく、ラインの内容によって登録される表の数が異なる場合もある。
【００３９】
ここで、ｘ＝ワード ｏｒ ライン、 Ｎ＝１〜ｎの数、 Ｓ＝ソート規則として、各表を（ｘ，Ｎ，Ｓ）で表すことを考える。この場合、ｘがワードであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがワードｘであるようなラインからなり、ソート規則がＳである表を表す。また、ｘがラインであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがラインｘのＮ番目のワードであるようなラインからなり、ソート規則がＳである表を表す。さらに、ｉ＝１，…，ｋとした場合、ｉ番目の表Ｈｉは（ｘ，Ｎｉ，Ｓｉ）と表される。
【００４０】
［処理手順の概要］
図２〜図５は、図１に示すデータベース装置の一般的な処理手順の例を示すフローチャートであり、図２は登録処理、図３は検索処理、図４は削除処理、図５は変更処理をそれぞれ示している。以下には、各処理手順の概要について順次説明する。
【００４１】
まず、ラインを登録する場合には、図２に示すように、ステップ１において、入力手段１により、ラインを構成するｎ個のワード（ｗ１ ，…，ｗｎ ）が作成され、ステップ２において、ｎ個のワード（ｗ１ ，…，ｗｎ ）の順序列であるラインＬが作成され、入力される。ステップ３において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、そのラインＬを登録するｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ４において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ１ ，…，Ｈｋ のうちで存在しない表がある場合には、ステップ５において、表作成手段１０により、必要な表が作成される。ステップ６において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が登録手段５に提供され、登録手段５により、各表にラインＬが登録される。ステップ７において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、登録処理を終了する。
【００４２】
次に、ラインを検索する場合には、図３に示すように、ステップ１１において、入力手段１により、検索するラインＬが指定され、ステップ１２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ１３において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索され、検索処理を終了する。
【００４３】
また、ラインを削除する場合には、図４に示すように、ステップ２１において、入力手段１により、削除するラインＬが指定され、ステップ２２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ２３において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索される。ステップ２４において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表からラインＬが削除され、削除処理を終了する。
【００４４】
一方、ラインを変更する場合には、図５に示すように、ステップ３１において、入力手段１により、変更するラインＬが指定され、ステップ３２およびステップ３３において、変更後のｎ個のワードとその順序列である変更後のラインＬ´が作成され、入力される。ステップ３４において、表指定手段３により、変更前のラインＬのワードの内容と予め設定された登録条件に基づき、変更前のラインＬが登録されたｋ種類の表Ｈ１ ，…，Ｈｋ が自動的に指定される。ステップ３５において、指定されたｋ種類の表Ｈ１ ，…，Ｈｋ の情報が検索手段７に提供され、指定されたラインＬが各表においてソート順に検索される。ステップ３６において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表から変更前のラインＬが削除される。ステップ３７において、表指定手段３により、変更後のラインＬ´のワードの内容と予め設定された登録条件に基づき、そのラインＬ´を登録するｋ種類の表Ｈ１ ´，…，Ｈｋ ´が自動的に指定される。ステップ３８において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ１ ´，…，Ｈｋ ´のうちで存在しない表がある場合には、ステップ３９において、表作成手段１０により、必要な表が作成される。ステップ４０において、指定されたｋ種類の表Ｈ１ ´，…，Ｈｋ ´の情報が登録手段５に提供され、登録手段５により、各表に変更後のラインＬ´が登録される。ステップ４１において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、変更処理を終了する。
【００４５】
本発明の代表的な実施例においては、１つのラインは３つのワードによって構成されている。そこにおいて、ワードは、文字列 文字列、文字列 整数、整数整数順序対のいずれかであるか、または浮動小数点数である。１つのラインを登録するときには、このラインは、ラインを構成する３つのワードとソートキーの違いによって同時に４つの表に自動的に登録される。この４つの表は、登録する１つのラインの３つのワードが左から順にａ，ｂ，ｃである場合に、（ｂ，Ｈ）、（ｂ，Ｍ）、（ａ，ｈ）、（ｃ，ｍ）、と表される。ここで、（ｂ，Ｈ）は、中央のワードがｂであるラインの集まりで、左のワードがソートキーである表を表す。（ｂ，Ｍ）は、中央のワードがｂであるラインの集まりで、右のワードがソートキーである表を表す。（ａ，ｈ）は、左のワードがａであるラインの集まりで、中央のワードがソートキーである表を表す。（ｃ，ｍ）は、右のワードがｃであるラインの集まりで、中央のワードがソートキーである表を表す。後述するように、例えば、１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＥＣＥ ８００ −１ 」をデータベースに登録する場合には、このラインは、４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）にそれぞれ登録される。また、１つのラインを削除する場合には、そのラインが登録されている４つの表すべてから自動的にそのラインが削除される。さらに、１つのラインの内容を変更する場合には、ラインを一旦４つの表から削除し、そのラインを変更し、変更した新たなラインを登録し直す。つまり、１つのラインを新たに登録すると最大４つの表が新たに作られる。
【００４６】
［具体的な実施例の内容］
以下には、本発明による具体的な実施例として、図１に示す構成を有するデータベース装置によって離散事象シミュレーションを行う例を説明する。なお、図１のデータベース装置を構成する手段（機能）とその作用は、前述した通りであるため、以下には、本実施例の特徴のみを説明する。
【００４７】
実施例を説明する前提として、離散事象シミュレーションについて説明する。離散事象シミュレーションにおいては、シミュレートするモデルの初期状態をデータベースに記述する。そして、データベースにある将来生起する事象リストのうち最も早く生起する事象の時刻に時間を進め、その事象を行う。ここで、事象を行うとは、その事象が起きることによってもたらされるモデルの変化を、モデルを記述しているデータベースに反映させることである。つまり、図６に示すように、シミュレーションの実行は、事象によってデータベースを書き換えることによって行われる。
【００４８】
本実施例では、以上のような離散事象シミュレーションを、図７に示すようなシミュレーションモデルに対して実行する。図７においては、窓口が１つしかない銀行のモデルを想定しており、客が窓口に来た順にサービスを受けてサービスが終了すると去っていく場合の、ある時点の状態を示している。この場合、複数の客は、異なる時間に順次到着し、前の客がサービス中ならば、前の客のサービスが終わるまで列に並んでおり、その客自身に対する窓口のサービスが終了した時点で退去するものとする。このモデルでは、客が５人いる。
【００４９】
図８は、図７のモデルの状態を表す全てのラインを示す表であり、これらのラインを、後述するような条件に従って登録すると、図９〜１２に示すような多数の表からなるデータベースが作成される。言い換えれば、図９〜１２は、図７のモデルの状態を表すデータベース全体を示している。このデータベースを構成する１つの表を図１３に例示する。図１３に示すように、表は、ある条件で集めた１つまたはそれ以上のライン集合からなる。図１３のライン集合を構成する１つのラインを図１４に例示する。図１４に示すように、１つのラインは３つのワードからなる。
【００５０】
本実施例においては、図１５の表に示すような４つの型のワードが、使用可能なワードとして設定されている。図１６は、図１５の４つの型のワードの例をそれぞれ示している。すなわち、型１のワードは２つの文字列の対で、型２は文字列、整数の対で、型３は２つの整数の対である。また、型４のワードは対ではなく、浮動小数点数１個でワードをなす。
【００５１】
ワード間の整列の順序は次のように決定されている。すなわち、基本的に、小さい方から大きい方に向かって上から下に並べるものとする。そして、型１、２、３は、型４より小さいものとする。また、型１、２、３の間の比較は、まず、ワードの対の左の要素を比較して決める。左の要素が同じ場合は、右の要素の比較によって決める。整数、浮動小数点数の間の比較は、それらの数の大小関係をそのまま使う。さらに、文字列と整数の間の比較は、文字列の方が小さいものとし、そして、これらの比較結果に従って、小さい方が上で、大きい方が下となるように並べる。一方、文字列間については、その文字列がデータベース内で使われた順序に従って、上から下に並べるものとする。
【００５２】
本実施例において、ラインは、単なる３つのワードの集まりではなく、その順序が極めて重要である。本実施例では、図示された表において、図中左のワードから右に向かって、それぞれ、左のワード、中央のワード、右のワードと称する。本実施例においては、１つのラインがデータベースに登録されるとき、ラインの内容、整列の基準となるワードを、左、中央、右のどのワードにしているかによって、自動的に同時に４つの表に登録される。登録すべき表が存在しなければ、表を新たに作成し登録する。
【００５３】
このような１つのラインを登録する４つの表を表すとき、ｘを任意のワードとして、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）というような記法を使用する。この場合、（ｘ，Ｈ）は、中央のワードがｘであるライン集合からなり、左のワードによってラインを整列した表である。（ｘ，Ｍ）は、中央のワードがｘであるライン集合からなり、右のワードによってラインを整列した表である。（ｘ，ｈ）は、左のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。（ｘ，ｍ）は、右のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。たとえば、図１４に示す１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」を登録する４つの表は、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）である。それぞれの表を、図１７〜２０に示す。
【００５４】
本実施例のデータベースは、このように、１つのラインに対して４つの表が用意されるので、図９〜１２に示すように、多数の表が集まって構成される。また、本実施例において、モデルの状態の記述は、主に以下の４種類のラインからなる。
【００５５】
第１に、事象の状態を表すラインがある。将来生起する事象リストである。これを表すラインの右のワードが、事象の種類を表す。本実施例では、事象は２つあり、到着事象と退去事象である。以下には、これらの事象をそれぞれ、「ＡＲ」と「ＬＶ」で表す。すなわち、到着事象「ＡＲ」は、客が銀行に到着することを実行し、退去事象「ＬＶ」は客が銀行から去ることを実行する。また、中央のワードは、既に実行が終った事象か将来起こる事象かを表すワードであり、「ＰＡＳＴ ＥＶＥＮＴ」または「ＦＵＴＵＲＥ ＥＶＥＮＴ」である。左のワードは、事象生起時刻を表している。たとえば、ライン「 ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０ 」は、これから起こる事象であり、生起時刻は１０００ｓｅｃ で、起こる事象は到着事象「ＡＲ」であることを示す。
【００５６】
第２に、このモデルにいる５人の客の状態と客のサービス時間を表すラインがある。このラインの左のワードは、客のＩＤ番号であり、中央のワードは客の状態を表し、右のワードでサービス時間を表す。サービス時間とは、客が窓口に入ったときサービスを終えるのに必要な時間のことである。客の状態は４種類あり、それを図２１に表す。この図２１に示すように、客がまだ銀行に来ていない状態（未到着状態）を「 ＣＯＭＩＮＧ ＩＮ」と表す。客が銀行に到着しているが、窓口でサービスを受けられず、列に並んでいる状態を「 ＩＮ ＬＩＮＥ」と表す。客がまさに窓口でサービスを受けている状態を「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」と表す。客がサービスを終了し銀行を去った状態を「 ＧＯＮＥ ＡＷＡＹ」と表す。たとえば、ライン「 ＣＵＳＴＯＭＥＲ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、ＩＤ番号１の客（客１と呼ぶ。）の状態が、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」（サービスを受けている）状態であり、客１が必要なサービス時間は、４００ ｓｅｃ であることを示す。
【００５７】
第３に、客の追跡情報を格納するラインがある。このラインには、左に客のＩＤ番号を表すワードがあり、中央にこのラインが客の追跡情報であることを表すワード「 ＴＲＡＣＥ ＴＲＡＣＥ」がある。右のワードの左の要素は、その客が銀行に到着した時刻を表す。右のワードの右の要素は、その客がサービスを終了し銀行を去った時刻を表す。これらの要素には、初期状態では負の数「−１」を入力する。
【００５８】
第４に、銀行でサービスを終えて去っていった客の、銀行に滞在していた平均時間を示すラインがある。このラインは、中央に、「 ＭＥＡＮ ＲＥＳＰＯＮＳＥ」というワードを持っている。左のワードの左の要素は、去った客の合計滞在時間を表し、左のワードの右の要素は、去った客の数を表す。また、右のワードは平均滞在時間（浮動小数点数）を表す。
【００５９】
本実施例においては、ラインの３つのワードのいずれかを変更すると、自動的に登録すべき４つの表に登録され整列される。たとえば、図１４に示すライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」の右のワードを「 ８００ １２００ 」に変更した場合を想定する。この場合、変更前のライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」は、前記の４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）からすべて消去される。そして、新しいライン「ｃｕｓｔｏｍｅｒ１ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００ 」が、新たに４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ １２００，ｍ）に登録される。この場合、登録される４つの表のうち、先の３つの表は変更前と変わらないが、表の中でのラインの位置が変わり得る。
【００６０】
また、本実施例において、表の検索をする場合には、（ｘ，Ａ）の表と指定することによって、表を検索することができる。ここで、ｘはワード、ＡはＨ，Ｍ，ｈ，ｍのいずれかである。図１３は、（ｃｕｓｔｏｍｅｒ １，ｈ）の表である。また、表（ｃｕｓｔｏｍｅｒ １，ｈ）の何番目のラインと指定して、ラインを検索することもできる。さらに、ラインの内容によってラインを検索することもできる。そしてまた、表（ｃｕｓｔｏｍｅｒ １，ｈ）のうち、右のワードが「ｓｅｃ ３５０ 」のラインを検索することができる。加えて、検索したラインが、その表の中でどの位置にあるを決定することができる。
【００６１】
以下には、本実施例における具体的なシミュレーション操作について説明する。
【００６２】
まず、図９〜１２に示すデータベースを用いて、次に生起する事象を検索する。この場合、次に起きる事象は、図９に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」に記述されている。このラインは、時刻１０００ ｓｅｃに到着事象「ＡＲ」が起こることを表している。そして、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」が生起した場合には、この到着事象「ＡＲ」により、図９〜１２に示されるデータが次のようにして書き換えられる。
【００６３】
到着事象「ＡＲ」は、未到着である客のうち、ＩＤ番号の最も小さい客を探して、銀行に到着させる。未到着である客についてのラインは、表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）に登録されており、この表は、客のＩＤ番号を表す左のワードをソートキーとして整列されている。この未到着の客をＩＤ番号順に表す表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を図２２に示す。この表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）の一番上のラインを検索すると、その左のワードから、客４が得られる。したがって、客４を到着させ、列に並ばせる。すなわち、客４の状態を、「 ＣＯＭＩＮＧ ＩＮ」から「 ＩＮ ＬＩＮＥ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」を、ライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」が、対応する４つの表に登録される。図２３の表（ ＩＮ ＬＩＮＥ，Ｈ）は、到着事象「ＡＲ」実行後における待ち行列中の客をＩＤ番号順に表している。客４が加わって客２、３、４の順に並んでいることがわかる。
【００６４】
次に、客４の追跡情報に関するラインを検索し、銀行到着時刻を記録する。この場合、追跡情報は、表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）に示される。この表の中で、左のワードが「 ｃｕｓｔｏｍｅｒ ４ 」であるラインを検索すると、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」が得られる。このライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」の右のワードの左の要素を、初期値「−１」からこの到着事象「ＡＲ」の時刻値「１０００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」をライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」が、客の追跡情報を表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。
【００６５】
続いて、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」を表している前記のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」は、将来生起する事象を客のＩＤ番号順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）と将来生起する事象を事象の種類順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「ｓｅｃ １０００ ＰＡＳＴ ＥＶＥＮＴ ＡＲ ０」が、過去に生起した事象を表す表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。
【００６６】
図２４は、以上のような時刻１０００ ｓｅｃにおける到着事象「ＡＲ」実行後のモデルの状態を表している。図２５は、図２４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図２６〜２９に示すような多数の表からなるデータベースが作成される。この図２６〜２９に示すデータベースにおいて、次に生起する事象は、図２６に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」に記述されている。このラインは、時刻１２００ ｓｅｃに退去事象「ＬＶ」が起こることを表している。そして、この時刻１２００ ｓｅｃにおける退去事象「ＬＶ」が生起した場合には、この退去事象「ＬＶ」により、図２６〜２９に示されるデータが次のようにして書き換えられる。
【００６７】
退去事象「ＬＶ」は、まず、現在窓口にいる客を、表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）から検索する。この窓口にいる客をサービス時間順に表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）には、図２７に示されるように、１つのライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」のみが登録されている。このラインから、現在窓口にいる客が、客１であることがわかる。したがって、客１を銀行から退去させる。すなわち、このライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」において、客の状態を示す中央のワードを、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」から「 ＧＯＮＥ ＡＷＡＹ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」が、対応する４つの表に登録される。
【００６８】
次に、列の先頭で待っている客を窓口に入れる。待ち行列中の客をＩＤ番号順に表す表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインを検索する。この表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインは、図２６に示されるように、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」である。このラインから、次に窓口に入る客が、客２であることがわかる。したがって、客２を窓口に入れる。すなわち、このライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」において、客の状態を示す中央のワードを「ＩＮ ＬＩＮＥ 」から「ＢＥＩＮＧ ＳＥＲＶＥＤ」に書き換え、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」を、ライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」が、対応する４つの表に登録される。
【００６９】
以上のような操作の結果、現在窓口にいる客を表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）と、待ち行列中の客を表す表（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｍ）の内容が変更される。また、退去した客に関するラインを、前述のように変えた結果、新たに、退去した客を示す表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ ＧＯＮＥ ＡＷＡＹ，Ｍ）が作成される。図３０は、このような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行前の客の状態を表す３つの表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示しており、図３１は、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後の客の状態を表す４つの表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示している。
【００７０】
本実施例において、上述のように、新たに窓口に客２が入ると、その客２が窓口を去る退去時刻は、「現時刻＋サービス時間」によって決定される。すなわち、次の退去事象「ＬＶ」が生起する時刻である。この例において、客２の退去時刻は、「１２００＋３００」から、１５００ ｓｅｃになる。次の退去事象「ＬＶ」が１５００ ｓｅｃに生起するので、この事象に関するラインを新たに登録する。すなわち、ライン「 ｓｅｃ １５００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０ 」を、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録する。また、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」を表している前記のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」は、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｓｅｃ １２００ ＰＡＳＴ ＥＶＥＮＴ ＬＶ ０」が、過去に生起した事象の表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の内容は、図３２のようになる。
【００７１】
さらに、客１の追跡情報に関するラインを検索し、銀行退去時刻を記録する。すなわち、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の中で、客１に関するライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」の右のワードの右の要素を、初期値「−１」からこの退去事象「ＬＶ」の時刻値「１２００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」が、客の追跡情報の表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の内容は、図３３のようになる。
【００７２】
図３４は、以上のような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後のモデルの状態を表している。図３５は、図３４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図３６〜３９に示すような多数の表からなるデータベースが作成される。
【００７３】
なお、本発明は、前記実施例に限定されるものではなく、例えば、１つのラインを構成するワードの数は３つに限らず、４つ以上のワードによって１つのラインを構成することも可能であり、逆に、２つのみのワードによって１つのラインを構成することも可能である。また、表のソート規則およびそれに関連する一定の登録条件の設定内容についても自由に設定可能である。例えば、ある位置のワードでソートするだけの単純なソート規則、あるいは逆に、複数のワードをソートキーにするソート規則などを使用することが可能であり、このようなソート規則に応じて、登録条件の内容を適宜設定することができる。
【００７４】
より具体的に、前記実施例の変形例として、３つのワードで構成される１つのラインを登録する表として、前記実施例における４つの表に加え、さらに、左のワードが同じであるライン集合からなり、右のワードをソートキーとする第５の表を対応させるように構成する実施例などが考えられる。また、１つのラインを５つのワードで構成し、１つのラインを登録する表として、第１のワードが同じであるライン集合からなり、第２のワードをソートキーとする第１の表と、第２のワードが同じであるライン集合からなり、第３のワードを第１ソートキー、第４のワードを第２ソートキーとする第２の表、およびその他の数種類の表を対応させるように構成する実施例なども考えられる。
【００７５】
ところで、本発明において、ラインをソートするソート手段としては、各種の手段を使用可能であるが、例えば、ソート、検索、登録、および削除可能な二分探索木を使用することが可能である。以下には、この二分探索木について簡単に解説する。
【００７６】
まず、二分木といくつかの言葉を定義する。図４０のように、二分木はノード（○印）とノードの間の親子関係を示す枝（／ ＼）からなり、どのノードも、子ノードを最大２つしか持たず、かつ、ある１つのノード以外のどのノードも、親ノードをただ１つだけ持つ。左下の子ノードを左子ノード、右下の子ノードを右子ノードと呼ぶ。親ノードを持たない唯一のノードを根ノードと呼ぶ。図４０において、ノード（１）はノード（２）の親ノードであり、ノード（２）はノード（１）の右子ノードである。ノード（３）は二分木の根ノードである。ノードの左（右）の子ノードの下の構造全体を左（右）部分木と言う。図４０において、部分木（４）はノード（１）の右部分木である。
【００７７】
本発明において利用する二分木は、ソート規則の定められた対象があり、二分木のノードがその対象（前記実施例においては、データベースのライン）を指示していて、二分木の任意のノードが指示している対象が、そのノードの左（右）部分木のどのノードが指す対象と比して大きい（小さい）ような二分木である。等しい場合を左に含めるか右に含めるかは二分探索木を使う事情による。ただし、小さい方が表の上にあり、大きい方が表の下にある。
【００７８】
たとえば、図４１は、整数をソートしている二分探索木である。なお、この図４１では、図面の簡略化の目的で、ノードが指示している対象である整数を直接ノードに書き込んでいる。この図４１において、ノード（１）が指す整数「５４」は、その右部分木（２）のどのノードの指示する整数「６０」、「５８」、「７１」、「５６」よりも小さい。
【００７９】
図４２は、このような二分探索木での検索方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木で整数「９」を検索する場合には、次のような手順の処理を行うことになる。この処理について、図４１を参照して説明する。なお、以下の説明において、Ｎは現在のノードを意味する。まず、図４１の根ノード（３）をＮとする。この場合、検索する整数「９」はＮが指示する整数「４６」より小さい。したがって、Ｎの左子ノード（４）を新たにＮにする。この場合、検索する整数「９」はＮが指示する整数「１３」より小さい。したがって、Ｎの左子ノード（５）を新たにＮとする。この場合、Ｎが指示する整数は「９」であり、このノードが、検索目的のノードである。
【００８０】
図４３は、二分探索木での登録方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木に対して、整数「４８」を指示するノードを登録する場合には、次のような手順の処理を行うことになる。この処理について、図４４を参照して説明する。まず、図４４の根ノード（１）をＮにする。この場合、登録する整数「４８」は、Ｎが指示する整数「４６」より大きい。よって、Ｎの右子ノード（２）を新たにＮとする。この場合、登録する整数「４８」はＮが指示する整数「５４」より小さい。したがって、Ｎの左子ノード（３）を新たにＮにする。この場合、登録する整数「４８」はＮが指示する整数「４９」より小さいが、現在のノードＮの左には子ノードがないので、Ｎを親ノードとして、整数「４８」を指示する左子ノード（４）を作成する。
【００８１】
図４５は、二分探索木での削除方法の一例を示すフローチャートである。このフローチャートによって、次のような処理を行うことができる。すなわち、まず、ノードＡを削除する場合、そのノードＡが子ノードを全く持たない場合には、図４６に示すように、そのままノードＡを削除する。また、ノードＡが左（右）子ノードだけしか持たない場合には、図４７に示すように、このノードＡを消して、左（右）部分木をノードＡの位置に付け替える。一方、ノードＡが左右の両子ノードを持つ場合には、図４８に示すように、ソート順においてノードＡの１つ前のノード（これはノードＡの左部分木の中で最も右にあるノードである。）をＮとして（図４８の左の状態）、ノードＡとノードＮを入れ替える（図４８の操作▲１▼：左→中央の状態）。このように入れ替えた際に、ノードＡが左部分木を持たない場合には、単にノードＡを消す。ノードＡが左部分木を持つならば、その左部分木をノードＡの位置に付け替える（図４８の操作▲２▼：中央→右の状態）。
【００８２】
なお、ラインをソートするソート手段として、このような二分探索木を用いることは有効であるが、前述の通り、ラインのソート、検索、登録、および削除である限り、他のソート手段を使用することも同様に可能である。
【００８３】
続いて、本発明におけるデータベースへの機能の実装例を、図４９によって説明する。この例では、図４９の中央部分に６つのラインｘｕｗ、ｖｘｚ、ｗｘｙ、ｘｘｘ、ｙｘｘ、ｙｗｘが示されている。ここで、ｕ，ｖ，ｗ，ｘ，ｙ，ｚは、それぞれ異なるワードを表す。ラインの検索に際しては、各ワードに対応する４つの異なる表を使用できる。たとえば、ワードをｘとすると、４つの表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）で表される。これらの表は、図４９中において、二分探索木：木（１）〜（４）として表現されている。この場合、木の各ノードは、ラインとそのラインのソートキーになっているワードを指示している。たとえば、木（１）の根のノードはラインｗｘｙを指示し、さらにソートキーであるワードｗを指示している。逆にラインも対応するノードを指示している。ある木のノードが指示しているラインは、その木が表現する表に含まれることを意味する。たとえば表（ｘ，Ｈ）に対応する木（１）には、ラインｘｘｘを指示するノードがあるので、ラインｘｘｘは、表（ｘ，Ｈ）に含まれている。
【００８４】
表（ｘ，Ｈ）は左のワードがソートキーなので、この表を表現する二分探索木の各ノードは、対応するラインと左のワードを指示している。すなわち、各表の各ワードは、対応するラインを指示するとともに、（ｘ，Ｍ）なら右、（ｘ，ｈ）、（ｘ，ｍ）なら中央のワードも指示している。たとえば、図４９のラインｘｘｘは、４つの表を表現する４つの二分探索木のノードによって指示されている。また逆に、ラインｘｘｘは、このラインｘｘｘを指示するノードを指示している。つまり、このラインｘｘｘを指定することにより、このラインｘｘｘを含む４つの表を表現している４つの二分探索木を見つけられる。
【００８５】
以上のような構造を有する図４９のデータベースにおいて、ラインを削除する方法を説明する。データベース上からラインｘｘｘを削除する場合には、このラインｘｘｘを含む４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）からラインｘｘｘを削除する。この場合、図４９上の木（１）〜（４）のラインｘｘｘを指示しているノードを削除しなければならない。ノードの削除は、二分探索木に関して前述した手順に従う。その結果、図５０に示すような、ラインｘｘｘのないデータベースが得られる。
【００８６】
逆に、図５０に示すようなデータベースに対して、ラインｘｘｘを登録するときは、４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）にそれぞれラインｘｘｘを登録しなければならない。この場合、これらの４つの表に対応する木（１）〜（４）にラインｘｘｘを指示するノードを登録する。ノードの登録の手順は、二分探索木に関して前述した手順に従う。
【００８７】
さらに、図４９のデータベースにおける任意のラインの検索は、図５１のようにして行うことができる。この図５１は、一例として、左と中央にワードｘを持つラインｘｘ？を１つ検索し、右のワードを検索する場合の手順を示している。このラインｘｘ？を含む可能性のある表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）である。中央のワードがｘで、左のワードをソートキーとする表（ｘ，Ｈ）を使用することにより、目的のラインを探索できる。この図５１上で、まず、ワードｘを起点とする矢印（１）をたどると、矢印（１）は表（ｘ，Ｈ）を指示している。この表のラインは、整列順を保持するため、二分探索木のノードに格納されている。表（ｘ，Ｈ）から矢印（２）をたどると、その二分探索木：木（３）の根を指示している。木の根を指示することは、木自体を指示することに等しい。また逆に、表（ｘ，Ｈ）のラインは、木（３）の各ノードから指示されている。
【００８８】
続いて、木（３）の根から矢印（４）をたどると、根のノードが指示しているラインはｗｘｙである。この場合、ラインｗｘｙと検索するラインｘｘ？の大小を比較するとｘｘ？の方が大きい（つまり表の下、木のノードの右にある）。そこで、木（３）の根の右の枝（５）を下がり、その先のノードが矢印（６）によって指示するラインｙｘｘと比較する。この場合、ｘｘ？の方が小さいので、左の枝（７）を下がる。その枝（７）の先のノードが矢印（８）によって指示するラインはｘｘｘであり、検索しているラインに該当する。したがって、左と中央にワードｘを持つラインｘｘ？の右のワードはｘであることがわかる。
【００８９】
【発明の効果】
以上説明したように、本発明においては、ラインと表との対応関係を示す一定の登録条件を予め設定しておくことにより、この登録条件に基づいて、１つのラインを登録する複数の表を自動的に指定することができるため、新たに登録するラインまたは内容を変更するラインとすでに登録されているラインとの関連を容易に把握可能であり、表とラインの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することができる。
【図面の簡単な説明】
【図１】本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図。
【図２】本発明によるデータベース装置の一般的な登録処理手順の一例を示すフローチャート。
【図３】本発明によるデータベース装置の一般的な検索処理手順の一例を示すフローチャート。
【図４】本発明によるデータベース装置の一般的な削除処理手順の一例を示すフローチャート。
【図５】本発明によるデータベース装置の一般的な変更処理手順の一例を示すフローチャート。
【図６】離散事象シミュレーションの手順を示す説明図。
【図７】本発明のデータベース装置によって離散事象シミュレーションを行う一実施例において、シミュレートするモデルの１つの状態を示す模式図。
【図８】図７のモデルの状態を表す全てのラインを示す表。
【図９】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１０】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１１】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１２】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１３】図９〜１２のデータベースを構成する１つの表を示す図。
【図１４】図１３のライン集合を構成する１つのラインを示す図。
【図１５】本発明において使用可能なワードの４つの型を示す表。
【図１６】図１５のワードの例を示す表。
【図１７】図１４のラインを登録する１つの表を示す図。
【図１８】図１４のラインを登録する１つの表を示す図。
【図１９】図１４のラインを登録する１つの表を示す図。
【図２０】図１４のラインを登録する１つの表を示す図。
【図２１】図７のモデルにいる客の４種類の状態を示す表。
【図２２】図９〜１２のデータベースを構成する表のうち、未到着の客をＩＤ番号順に表す表。
【図２３】図９〜１２のデータベースを用いた離散事象シミュレーションによる到着事象実行後の待ち行列中の客をＩＤ番号順に表す表。
【図２４】図７のモデルの、離散事象シミュレーションによる到着事象実行後における状態を示す模式図。
【図２５】図２４のモデルの状態を表す全てのラインを示す表。
【図２６】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２７】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２８】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２９】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３０】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行前の客の状態を表す３つの表を示す図。
【図３１】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の客の状態を表す４つの表を示す図。
【図３２】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、将来生起する事象を時刻順に表す表の内容を示す図。
【図３３】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、客の追跡情報を客のＩＤ番号順に表す表の内容を示す図。
【図３４】図２４のモデルの、離散事象シミュレーションによる退去事象実行後における状態を示す図。
【図３５】図３４のモデルの状態を表す全てのラインを示す表。
【図３６】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３７】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３８】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３９】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図４０】本発明によるデータベース装置においてソート手段として使用可能な二分探索木の一例を示す図。
【図４１】整数をソートしている二分探索木の一例を示す図。
【図４２】二分探索木での検索方法の一例を示すフローチャート。
【図４３】二分探索木での登録方法の一例を示すフローチャート。
【図４４】図４１の二分探索木に対して、新しいノードを登録する手順とそれを登録した二分探索木を示す図。
【図４５】二分探索木での削除方法の一例を示すフローチャート。
【図４６】図４５の方法による削除操作の一例を示す説明図。
【図４７】図４５の方法による削除操作の一例を示す説明図。
【図４８】図４５の方法による削除操作の一例を示す説明図。
【図４９】本発明に従って機能を実装したデータベースの一例を示す説明図。
【図５０】図４９のデータベースから１つのラインを削除して得られたデータベースを示す説明図。
【図５１】図４９のデータベースにおける任意のラインの検索手順を示す説明図。
【図５２】データベースに登録されるリレーションの一例を示す表。
【図５３】データベースに登録されるリレーションの一例を示す表。
【符号の説明】
１…入力手段
２…格納手段
３…表指定手段
４…管理手段
５…登録手段
６…ソート手段
７…検索手段
８…削除手段
９…出力手段
１０…表作成手段
Claims (2)
- 文字列、整数、および浮動小数点数の中から選ばれた単一種類または複数種類の値を示すワードを、序列をもって複数個並べることにより構成されたラインが、複数の表に登録されたデータベース装置において、
個々の表について、入力されるラインにおける複数の序列位置の中から選択された判定用の位置のワードとして特定値を持つラインを登録するというワードの条件と、前記複数の序列位置の中から前記判定用の位置とは別に選択されたソート用の位置のワードの値でソートするというソート規則とを含む表情報により定義される複数の表の登録条件を管理する管理手段と、
前記表の登録条件に基づき、入力されたラインを登録する複数の表を指定する表指定手段と、
前記表に登録されたラインを、各表に設定されたソート規則によって特定される序列位置のワードの値に基づいて各表の上でソートするソート手段と、
前記表指定手段によって指定された各表の上で、前記ソート手段によってソートされた順序に基づき、ラインをそれぞれ検索する検索手段、
を備えたことを特徴とするデータベース装置。 - ３つのワードから構成されるラインを登録するための前記表の登録条件は、
前記ラインを構成する３つのワードの３つの序列位置に対して、この３つの序列位置の中から選択された１つの位置を第１の位置と定義し、残りの２つの位置を第２、第３の位置と定義した場合に、
前記３つのワードから構成される１つのラインを、
前記第１の位置が前記判定用の位置であって、この位置のワードの値が当該ラインの対応する位置のワードと同じ値を持ち、かつ、前記第２の位置が前記ソート用の位置である第１の表と、
前記第１の位置が前記判定用の位置であって、この位置のワードの値が当該ラインの対応する位置のワードと同じ値を持ち、かつ、前記第３の位置が前記ソート用の位置である第２の表と、
前記第２の位置が前記判定用の位置であって、この位置のワードの値が当該ラインの対応する位置のワードと同じ値を持ち、かつ、前記第１の位置が前記ソート用の位置である第３の表と、
前記第３の位置が前記判定用の位置であって、この位置のワードの値が当該ラインの対応する位置のワードと同じ値を持ち、かつ、前記第１の位置が前記ソート用の位置である第４の表、
という４つの表にそれぞれ登録することを規定する、
ことを特徴とする請求項１に記載のデータベース装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29358792A JP3628030B2 (ja) | 1992-10-30 | 1992-10-30 | データベース装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29358792A JP3628030B2 (ja) | 1992-10-30 | 1992-10-30 | データベース装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06149634A JPH06149634A (ja) | 1994-05-31 |
| JP3628030B2 true JP3628030B2 (ja) | 2005-03-09 |
Family
ID=17796659
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP29358792A Expired - Lifetime JP3628030B2 (ja) | 1992-10-30 | 1992-10-30 | データベース装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3628030B2 (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 |
|---|---|---|---|---|
| JP2002140218A (ja) | 2000-10-31 | 2002-05-17 | Toshiba Corp | データ処理方法、コンピュータ読み取り可能な記録媒体及びデータ処理装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2718836B2 (ja) * | 1990-12-20 | 1998-02-25 | 株式会社ピーエフユー | データベースシステム |
-
1992
- 1992-10-30 JP JP29358792A patent/JP3628030B2/ja not_active Expired - Lifetime
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 |
|---|---|
| JPH06149634A (ja) | 1994-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US4933848A (en) | Method for enforcing referential constraints in a database management system | |
| US5717924A (en) | Method and apparatus for modifying existing relational database schemas to reflect changes made in a corresponding object model | |
| US20020194196A1 (en) | Method and apparatus for transforming data | |
| CN106716416A (zh) | 数据检索装置、程序及记录介质 | |
| CN106874411B (zh) | 一种表格的搜索方法及搜索平台 | |
| US20040015486A1 (en) | System and method for storing and retrieving data | |
| US20030074419A1 (en) | System and method for non-programmers to dynamically manage multiple sets of XML document data | |
| JPH06176081A (ja) | 階層構造ブラウジング方法およびその装置 | |
| JP4425377B2 (ja) | データ処理装置、および、データ処理方法 | |
| JPH07244605A (ja) | データベースシステム及びその更新方法 | |
| JP2001014329A (ja) | データベース処理方法及び実施装置並びにその処理プログラムを記憶した媒体 | |
| CN108664509A (zh) | 一种即席查询的方法、装置及服务器 | |
| RU2433467C1 (ru) | Способ формирования структуры агрегированных данных и способ поиска данных посредством структуры агрегированных данных в системе управления базами данных | |
| JP3628030B2 (ja) | データベース装置 | |
| JPH08305724A (ja) | 設計支援情報文書管理装置 | |
| JP3552339B2 (ja) | データベースシステム | |
| JPH06251064A (ja) | 情報検索装置 | |
| Shentu et al. | Mechanism design of data management system for nuclear power | |
| JPH0934906A (ja) | 図書管理装置 | |
| KR100873807B1 (ko) | 기업 데이터 시스템들에 대한 객체 지향형 메타 데이터저장소 구축 방법 | |
| CN113220945B (zh) | 一种用于数据血缘的字段检索和路径展示的方法及*** | |
| JP7411489B2 (ja) | 生産知識管理システム、生産知識管理方法及び生産知識管理プログラム | |
| JPH09305611A (ja) | データベースの検索装置 | |
| JPH117402A (ja) | データ処理方法 | |
| JPS63254523A (ja) | キ−ワ−ド検索方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20041130 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041207 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071217 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081217 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121217 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |