JP3628030B2 - Database device - Google Patents

Description

このとき、Ｒの任意の部分集合をＳ_１ ，…，Ｓ_ｎ の間のｎ項関係（または単に関係、ないしはリレーション） と呼ぶ。たとえば、２個の集合Ｓ_１ ，Ｓ_２ を次の式（２）に示すように定義する。
【０００６】
【数２】

このとき、２個の集合Ｓ_１ ，Ｓ_２ の直積集合Ｓ_１ ×Ｓ_２ は、次の式（３）のように表される。
【０００７】
【数３】

このうち、次の式（４）に示すような部分集合Ｒが、都県−市リレーションである。
【０００８】
【数４】

ＲＤＢは、このようなリレーションの集合をデータとするＤＢである。要するに、リレーションは図５２、図５３に示すような表である。一般的に、表を横に見て１つの行をタプル（組、 ｔｕｐｌｅ、レコード） 、縦にみて１つの列を属性（ａｔｔｒｉｂｕｔｅ ）と呼ぶ。図５２の表で各属性に付けられた名前を属性名（ａｔｔｒｉｂｕｔｅ ｎａｍｅ ）といい、各属性の値を属性値（ａｔｔｒｉｂｕｔｅ ｖａｌｕｅ、フィールド値）という。また、表の名前をリレーション名（関係名、ｒｅｌａｔｉｏｎ ｎａｍｅ）という。
【０００９】
このように、ＲＤＢにおいては、リレーションという表を概念的な仲立ちとして、データレコードを計算機に収容する。もちろん、計算機の内部では複雑なデータ構造やアクセス手続きをとっている可能性が高い。しかし、ユーザからはその複雑な実装が見えない。実装に関する情報は隠蔽されている。単なる表、すなわちデータの容器があって、ユーザはその容器にレコードを入れるという利用法である。
【００１０】
ＲＤＢは、次のような４つの処理機能を持つ。：
「１．レコードを収容する表を設定する。」
「２．表にレコードを登録する。」
「３．表からレコードを削除する。」
「４．表の中のレコードを検索する。」
そして、ＲＤＢの実装は、属性と属性値を指定すれば、レコードの登録処理、削除処理、および検索処理が能率良くできるようになっている。
【００１１】
ＲＤＢの特徴の１つは、表とレコードとの独立性が高いことである。ユーザは、まず表を設定し、しかる後にその表にレコードを登録する。あるレコードをある表に登録しておくか否かはユーザの任意である。検索したレコードのある属性値を変更する場合でも、レコードと表との対応関係に変化はない。ユーザがレコードと表との対応を変更するためには、上記のようなレコード登録、削除の操作が必要である。複数の表を指定してそれらに登録されているレコード間で演算を行って生じたレコードを、指定した新たな表に登録する場合でも、新たに生成されたレコードをどの表に登録するかは、ユーザが管理する。すなわち、ＲＤＢにおいて、表とレコードの対応関係は、ユーザが任意の表に任意のレコードを登録するという行為を通してのみ与えられる。
【００１２】
先に説明したように、関係は１つの集合である。一般に、集合の定義には、外延的な方法と内包的な方法がある。外延的な方法では、要素を全て列挙することによって集合を定義する。たとえば、０以上９以下の整数全体の集合Ｓを、次の式（５）に示すように定義するのが外延的な定義である。
【００１３】
【数５】

…式（５）これに対して、その集合に属する要素が満たすべき性質を規定するのが内包的な定義である。たとえば、上の集合Ｓを、次の式（６）のように定義するのが内包的な定義である。ここで、Ｚは整数の集合である。
【００１４】
【数６】

これに対して、表にレコードを登録する行為は、「このレコードはこのリレーション（表）に属し、このレコードが登録されない他のリレーション（表）には属さない。」ということを、属性と属性値を列挙することによって定義している。これを全てのレコードについて行うのであるから、リレーションは外延的に定義されている。
【００１５】
この結果、ＲＤＢは次のような特徴を持つ。まず、リレーションに従って行う処理は、概念的に単純であり、能率良く行える。すなわちプログラムは簡単ですみ、計算量も少ない。たとえば図５３において、
「（Ａ）生年が‘６３年の者を検索する。」
という処理は、リレーションに従う処理であり、能率良く行うことができる。
【００１６】
【発明が解決しようとする課題】
これに対して、ＲＤＢにおいて、リレーションに従わない処理は、もともと想定されていなかった処理であるから、能率が悪い。たとえば、図５３において、
「（Ｂ）生年が若い順に３番めの者を検索する。」
という処理は、リレーションに従わない処理である。この処理は、仮に図５３の表中に「生年の順番」という属性がもともとありさえすれば、容易に実行できるものである。それにもかかわらず、図５３の表中においては、「生年の順番」という属性が、予め考えられてはいないので、（Ｂ）の処理を行うためには、登録されたレコードのうち生年を有するレコードを全て調べた上で、これらのレコードの順番を定めなければならない。このような検索を実行する場合には、プログラムが長くなり、計算量も多くなる。
【００１７】
さらに言及すれば、この場合、（Ｂ）の処理で用いる属性「生年の順番」は、（Ａ）の処理で用いる属性「生年」から自然に定まるものである。すなわち、属性「生年の順番」は、属性「生年」を有するレコードの関係の部分集合を規定する内包的な性質として、自然に存在するものである。それにも関わらず、属性「生年の順番」は、このＲＤＢには存在しない属性であるために、この属性を利用した（Ｂ）の処理は、容易に実行することができないのである。
【００１８】
以上のことから、ＲＤＢは、その設計時に想定された使い方には適合している反面、想定から少し外れた使い方をしようとすると、能率が悪いことがわかる。ここで、設計時に想定された使い方とは、外延的な定義に用いた属性と、その値とでレコードを扱うことである。また、想定から少し外れた使い方とは、前述の（Ｂ）の処理のように、ＲＤＢに存在する属性とその値から導かれる性質によって内包的に規定されるレコードを扱うことである。
【００１９】
一般的に、ＤＢを設計してから時間がたつと、使い方が設計時の想定から外れて来ることは避けられない。なぜなら、ＤＢの方が、それを利用する応用プログラムよりも寿命が長いからである。つまり、ほとんどの場合、ＤＢは既に存在しており、プログラムは、ＤＢに存在する情報をなんとか利用しようという意図をもって書かれるのである。このようにＤＢの使い方が設計時の想定から外れる場合として、図５３の表に対する前述の処理に関連付けるならば、ＤＢの設計時には、「生年」という属性を検索できるようにしておけば十分だと考えられていたにも関わらず、実際には年齢順の方が使いやすいことが後で判明したりする場合などが挙げられる。このような場合、ＲＤＢでは、新たに「年齢順」という属性を設けることになる。これは表の作り直しに当り、レコード数が多いときは大変な作業である。
【００２０】
このことは、従来のデータベースにおける、表とレコードの対応関係（登録操作）が任意であるという本質的な特徴に起因する。すなわち、ユーザはデータベースの構築、利用にあたって、
「Ａ．レコードの作成、変更」
「Ｂ．レコードの表への登録、削除」
という２つの操作を関連付けて実行する必要がある。なぜなら、データを保存する際には、データベース中にあるレコードが存在している場合、このレコードの存在だけでなく、そのレコードがどの表に登録されており、どの表に登録されていないかということが重要だからである。したがって、１つのレコードが複数の表に登録されるべき内容を表している場合には、ユーザは、それを判断して、そのレコードを対応する複数の表に対して個別に登録しなければならない。
【００２１】
例えば、イベントスケジュール管理のデータベースにおいて、将来のイベントを管理している表（表名：ＦＵＴＵＲＥ ＥＶＥＮＴ）には、「時刻 イベント」のレコードが、イベントとその発生時刻を表すために登録される。ここで、各イベントには、不定人数の参加者が予定されているとする。これに対して、この予定される参加者に関する表（表名：ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ ）を作成し、この表に、「参加者 イベント」のレコードを登録する。そして、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」に登録されている「時刻 イベント」のレコードは、イベントが生起すると削除され、すでに生起したイベントを管理している表（表名：ＰＡＳＴ ＥＶＥＮＴ）に登録される。
【００２２】
この場合、それぞれの表は、その目的に適した形式のレコードのみを効率的に登録しているが、１つのイベントに関してどのような情報が登録されているかという検索は、３つの表（ＦＵＴＵＲＥ ＥＶＥＮＴ、ＡＴＴＥＮＤＡＮＴ ＥＶＥＮＴ 、ＰＡＳＴ ＥＶＥＮＴ）を個別に調べなければ実行できない。例えば、あるイベントに関する「時刻 イベント」のレコードは、表「ＦＵＴＵＲＥ ＥＶＥＮＴ」か表「ＰＡＳＴ ＥＶＥＮＴ」かどちらか一方に必ず含まれているはずであるが、これを確認するためには、両方の表を同時に調べなければならない。また、イベント生起時には、一方の表からそのイベントに関するレコードを削除し、かつ、他方の表にそのイベントに関するレコードを登録するという２つの処理を、ユーザの責任において同時に行わなければならない。ここに誤りが生じる可能性があり、かつ、誤りの検出にも手間がかかる。
【００２３】
このような問題を回避する一つの方法として、「ＦＵＴＵＲＥ ＥＶＥＮＴ」と「ＰＡＳＴ ＥＶＥＮＴ」という２つの表の別をやめて、例えば、１つの表（表名：ＥＶＥＮＴ ）を作成し、この表「ＥＶＥＮＴ 」に、「ＦＵＴＵＲＥ／ＰＡＳＴ 時刻 イベント」というレコードとして、イベントのスケジュールを登録することが考えられる。ここで、フィールド「ＦＵＴＵＲＥ／ＰＡＳＴ」は、ＦＵＴＵＲＥ ｏｒ ＰＡＳＴを意味する。この方法を採用した場合、イベント生起時には、前述の方法のように、異なる表に対する２つの処理（削除と登録）を行う必要なく、「ＦＵＴＵＲＥ／ＰＡＳＴ 」のフィールド値の変更という１つの処理を行うだけでよいため、誤りが発生する可能性が極めて少なくなり、かつ、誤りの検出も比較的容易になる。
【００２４】
その反面、この方法での処理を進めるためには、結局、関連性のあるレコードを登録する表をすべて融合して１つの表とすることになるため、有効に使われない多くのフィールドを含む長尺なレコードを登録することになる。このような無駄の多い長尺なレコードを多数登録することは、レコードを収納する表を設定することによるデータベースの効率的運用を放棄することに他ならない。
【００２５】
以上のように、表を設定し、その表に対してレコードを任意に登録、削除することでデータを効率的に蓄積利用しようとする従来のデータベースシステムにおいては、表とレコードの対応関係の意図的な管理に多くの労力を要し、その分だけ多くのコストが費やされている。また、従来のデータベースにおいては、レコードの内容すなわちフィールド値に関して、あるフィールド値を持つレコードの指定した表への（正しいレコードとしての） 登録の可否を制限することはあっても、そのレコードがどの表に登録されるべきであるかを指示する機能、あるいは、実際に自動的に登録を行う機能は、設けられていない。
【００２６】
したがって、従来のデータベースにおいて、特定のフィールド値に関して、どのようなレコードがそのフィールド値を有し、また、そのフィールド値を有するレコードがどのような表に登録されているかを検索することは困難である。すなわち、フィールド値は、文字列や数値であり、それが各レコード（の各フィールド） でどのような意味に用いられるかはユーザの任意である。そのため、異なる表の異なるレコード間で、同一のフィールド値が全く異なる意味で用いられることは十分ありうる。このような同一のフィールド値の異なる意味での使用は、データベース中におけるデータ処理の混乱を来し、極めて不都合である。したがって、ユーザがレコードを作成する際には、それぞれのフィールド値が、そのときすでにデータベース中に使用されているフィールド値とどういう関連を持つかを把握することが不可欠である。そして、このように、特定のフィールド値の情報をデータベース全体にわたって完全に把握するためには、従来のデータベースにおいて、関連する（レコードを含む） 可能性のある表のレコードをすべて調べて結論を出さなければならない。しかしながら、このような検索の実行には、大変な手間がかかり、また、個々のフィールド値ごとに可能性のある表やフィールドの情報をユーザが維持管理すること自体が困難である。
【００２７】
本発明は上記のような従来技術の課題を解決するために提案されたものであり、その目的は、新たに登録するデータまたは内容を変更するデータとすでに登録されているデータとの関連を容易に把握可能であり、表とデータの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することである。
【００２８】
【課題を解決するための手段】
本発明によるデータベース装置は、文字列、整数、および浮動小数点数の中から選ばれた単一種類または複数種類の値を示すワードを、序列をもって複数個並べることにより構成されたラインが、複数の表に登録されたデータベース装置において、管理手段、表指定手段、ソート手段、検索手段、を備えたことを特徴とするものである。ここで、管理手段は、個々の表について、入力されるラインにおける複数の序列位置の中から選択された判定用の位置のワードとして特定値を持つラインを登録するというワードの条件と、複数の序列位置の中から判定用の位置とは別に選択されたソート用の位置のワードの値でソートするというソート規則とを含む表情報により定義される複数の表の登録条件を管理する手段である。また、表指定手段は、表の登録条件に基づき、入力されたラインを登録する複数の表を指定する手段である。また、ソート手段は、表に登録されたラインを、各表に設定されたソート規則によって特定される序列位置のワードの値に基づいて各表の上でソートする手段である。さらに、検索手段は、表指定手段によって指定された各表の上で、ソート手段によってソートされた順序に基づき、ラインをそれぞれ検索する手段である。
【００２９】
【作用】
以上のような構成を有する本発明の作用は次の通りである。まず、ラインにおける複数の序列位置について、判定用の位置におけるワードの値に応じて当該ラインの登録を判定するためのワードの条件と、ソート用の位置におけるワードの値でソートするためのソート規則とを含む表情報により登録条件を定義しているため、この登録条件により、１つのラインと、このラインを登録すべき複数の表との対応関係を明確に示すことができる。その結果、ラインを登録する際には、表指定手段により、ラインと表の対応関係を示す登録条件に基づき、ラインを構成する複数のワードの値に応じて、収納すべき複数の表を自動的に指定できるため、１つのラインを異なるソート規則を持つ複数の表に容易に登録できる。したがって、設計時に想定されなかった使い方に柔軟に対処可能であり、操作性および能率を向上できる。
【００３０】
一方、本発明では、表指定手段により、１つのワードが収納されている表を自動的に特定可能であり、また、表指定手段に加えて検索手段を使用することにより、１つのワードによるラインの検索を容易に行うことができる。したがって、１つのワードの情報をデータベース全体にわたって容易に把握でき、データベースにすでに登録されたラインと新しく登録されるラインとの関連を容易に把握することができる。加えて、ソート手段を利用していることから、ソート順によるラインの検索や、検索されたラインの位置の決定なども自動的に簡単に行えるため、検索処理や、検索の必要な削除処理、変更処理などの能率を向上できる。
【００３１】
【実施例】
［装置構成］
以下には、本発明によるデータベース装置の構成について、図１を参照して説明する。ここで、図１は、本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図である。この図１に示す装置は、入力手段１、格納手段２、表指定手段３、管理手段４、登録手段５、ソート手段６、検索手段７、削除手段８、出力手段９を備えており、複数のワードの順序列をラインとして、複数のラインを複数の条件に合致する複数の表に対して個別・選択的に登録・削除するとともに、ワードの内容に基づいてラインを検索するように構成されている。
【００３２】
入力手段１は、複数のワードの順序列をラインとして入力する機能と、すでに登録済みのラインを、ワードの内容またはラインの位置によって指定し、検索指令、削除指令、または変更指令を入力する機能を有する。格納手段２は、各表に設定されたソート規則と各表に登録されたライン情報およびそのソート順情報を含む複数の表情報を格納する機能を有する。
【００３３】
表指定手段３は、ラインと表の対応関係を示す予め設定された一定の登録条件を有し、入力手段１によるラインの入力に応答して、入力されたラインのワードの内容と登録条件に基づき、そのラインを登録する複数の表を指定する機能と、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、指定されたラインのワードの内容と登録条件に基づき、そのラインが登録された複数の表を指定する機能を有する。
【００３４】
管理手段４は、格納手段２に格納された複数の表情報を管理し、表指定手段３によって指定された複数の表情報を提供する機能と、登録手段５およびソート手段６による登録情報と、削除手段８による削除情報によって管理情報を更新する機能と、検索手段７による検索情報を管理する機能を有する。
【００３５】
登録手段５は、入力手段１によるラインの入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表に、入力手段１によって入力されたラインをそれぞれ登録する機能を有する。ソート手段６は、登録手段５によって複数の表に登録されたラインを、各表に設定されたソート規則によって特定される位置のワードの内容に基づいて表の上にソートする機能を有する。
【００３６】
検索手段７は、入力手段１による登録済みのラインの検索指令、削除指令、または変更指令の入力に応答して、表指定手段３によって指定された複数の表情報を管理手段４から受け取り、各表の上で、ソート手段６によってソートされた順序に基づき、入力手段１によって指定された登録済みのラインをそれぞれ検索する機能を有する。削除手段８は、入力手段１による登録済みのラインの削除指令または変更指令の入力に応答して、検索手段７によって検索された複数の表情報を受け取り、各表の上で検索されたラインを削除する機能を有する。出力手段９は、管理手段４による管理情報を出力する機能を有する。
【００３７】
また、一般的には、管理手段４は表作成手段１０を有している。この表作成手段１０は、表指定手段３によって指定された表が格納手段内に存在していない場合に、指定された表に合致する新たな表を作成する機能を有する。一方、ラインを構成するワードとしては、例えば、２つの文字列の順序対、文字列と整数の順序対、２つの整数の順序対、または、１つの浮動小数点数の４種類のいずれかを使用することが可能である。より一般的には、文字列、整数、浮動小数点数、およびそれらの任意個数の順序組を使用することが可能である。さらに、本発明においては、表上のラインをソートするソート手段６として、例えば、二分探索木を使用することが可能であるが、二分探索木と同様に、ラインのソート、検索、登録、および削除が可能であれば、別のソート手段を使用することも可能である。
【００３８】
次に、本発明において、表指定手段３に予め設定される登録条件、すなわち、ラインと表の対応関係を示す一定の登録条件について説明する。まず、１つのラインは、ｎワード（ｗ_１ ，…，ｗ_ｎ ）の順序列で構成される。そして、１つのラインを登録するｋ種類の表は、Ｈ_１ ，…，Ｈ_ｋ と表される。なお、本発明においては、１つのラインが、必ずｋ種類の表に登録されるわけではなく、ラインの内容によって登録される表の数が異なる場合もある。
【００３９】
ここで、ｘ＝ワード ｏｒ ライン、 Ｎ＝１〜ｎの数、 Ｓ＝ソート規則として、各表を（ｘ，Ｎ，Ｓ）で表すことを考える。この場合、ｘがワードであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがワードｘであるようなラインからなり、ソート規則がＳである表を表す。また、ｘがラインであれば、（ｘ，Ｎ，Ｓ）は、左からＮ番目のワードがラインｘのＮ番目のワードであるようなラインからなり、ソート規則がＳである表を表す。さらに、ｉ＝１，…，ｋとした場合、ｉ番目の表Ｈｉは（ｘ，Ｎｉ，Ｓｉ）と表される。
【００４０】
［処理手順の概要］
図２〜図５は、図１に示すデータベース装置の一般的な処理手順の例を示すフローチャートであり、図２は登録処理、図３は検索処理、図４は削除処理、図５は変更処理をそれぞれ示している。以下には、各処理手順の概要について順次説明する。
【００４１】
まず、ラインを登録する場合には、図２に示すように、ステップ１において、入力手段１により、ラインを構成するｎ個のワード（ｗ_１ ，…，ｗ_ｎ ）が作成され、ステップ２において、ｎ個のワード（ｗ_１ ，…，ｗ_ｎ ）の順序列であるラインＬが作成され、入力される。ステップ３において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、そのラインＬを登録するｋ種類の表Ｈ_１ ，…，Ｈ_ｋ が自動的に指定される。ステップ４において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ_１ ，…，Ｈ_ｋ のうちで存在しない表がある場合には、ステップ５において、表作成手段１０により、必要な表が作成される。ステップ６において、指定されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ の情報が登録手段５に提供され、登録手段５により、各表にラインＬが登録される。ステップ７において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、登録処理を終了する。
【００４２】
次に、ラインを検索する場合には、図３に示すように、ステップ１１において、入力手段１により、検索するラインＬが指定され、ステップ１２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ が自動的に指定される。ステップ１３において、指定されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索され、検索処理を終了する。
【００４３】
また、ラインを削除する場合には、図４に示すように、ステップ２１において、入力手段１により、削除するラインＬが指定され、ステップ２２において、表指定手段３により、ラインＬのワードの内容と予め設定された登録条件に基づき、ラインＬが登録されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ が自動的に指定される。ステップ２３において、指定されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ の情報が検索手段７に提供され、この検索手段７により、指定されたラインＬが各表においてソート順に検索される。ステップ２４において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表からラインＬが削除され、削除処理を終了する。
【００４４】
一方、ラインを変更する場合には、図５に示すように、ステップ３１において、入力手段１により、変更するラインＬが指定され、ステップ３２およびステップ３３において、変更後のｎ個のワードとその順序列である変更後のラインＬ´が作成され、入力される。ステップ３４において、表指定手段３により、変更前のラインＬのワードの内容と予め設定された登録条件に基づき、変更前のラインＬが登録されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ が自動的に指定される。ステップ３５において、指定されたｋ種類の表Ｈ_１ ，…，Ｈ_ｋ の情報が検索手段７に提供され、指定されたラインＬが各表においてソート順に検索される。ステップ３６において、指定された各表と各表における検索されたライン位置の情報が削除手段８に提供され、削除手段８により、各表から変更前のラインＬが削除される。ステップ３７において、表指定手段３により、変更後のラインＬ´のワードの内容と予め設定された登録条件に基づき、そのラインＬ´を登録するｋ種類の表Ｈ_１ ´，…，Ｈ_ｋ ´が自動的に指定される。ステップ３８において、管理手段４により、指定された複数の表が格納手段２内に存在するか否かが判断され、指定された表Ｈ_１ ´，…，Ｈ_ｋ ´のうちで存在しない表がある場合には、ステップ３９において、表作成手段１０により、必要な表が作成される。ステップ４０において、指定されたｋ種類の表Ｈ_１ ´，…，Ｈ_ｋ ´の情報が登録手段５に提供され、登録手段５により、各表に変更後のラインＬ´が登録される。ステップ４１において、ソート手段６により、各表に設定されたソート規則Ｓに基づいて各表がソートされ、変更処理を終了する。
【００４５】
本発明の代表的な実施例においては、１つのラインは３つのワードによって構成されている。そこにおいて、ワードは、文字列 文字列、文字列 整数、整数整数順序対のいずれかであるか、または浮動小数点数である。１つのラインを登録するときには、このラインは、ラインを構成する３つのワードとソートキーの違いによって同時に４つの表に自動的に登録される。この４つの表は、登録する１つのラインの３つのワードが左から順にａ，ｂ，ｃである場合に、（ｂ，Ｈ）、（ｂ，Ｍ）、（ａ，ｈ）、（ｃ，ｍ）、と表される。ここで、（ｂ，Ｈ）は、中央のワードがｂであるラインの集まりで、左のワードがソートキーである表を表す。（ｂ，Ｍ）は、中央のワードがｂであるラインの集まりで、右のワードがソートキーである表を表す。（ａ，ｈ）は、左のワードがａであるラインの集まりで、中央のワードがソートキーである表を表す。（ｃ，ｍ）は、右のワードがｃであるラインの集まりで、中央のワードがソートキーである表を表す。後述するように、例えば、１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＥＣＥ ８００ −１ 」をデータベースに登録する場合には、このラインは、４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）にそれぞれ登録される。また、１つのラインを削除する場合には、そのラインが登録されている４つの表すべてから自動的にそのラインが削除される。さらに、１つのラインの内容を変更する場合には、ラインを一旦４つの表から削除し、そのラインを変更し、変更した新たなラインを登録し直す。つまり、１つのラインを新たに登録すると最大４つの表が新たに作られる。
【００４６】
［具体的な実施例の内容］
以下には、本発明による具体的な実施例として、図１に示す構成を有するデータベース装置によって離散事象シミュレーションを行う例を説明する。なお、図１のデータベース装置を構成する手段（機能）とその作用は、前述した通りであるため、以下には、本実施例の特徴のみを説明する。
【００４７】
実施例を説明する前提として、離散事象シミュレーションについて説明する。離散事象シミュレーションにおいては、シミュレートするモデルの初期状態をデータベースに記述する。そして、データベースにある将来生起する事象リストのうち最も早く生起する事象の時刻に時間を進め、その事象を行う。ここで、事象を行うとは、その事象が起きることによってもたらされるモデルの変化を、モデルを記述しているデータベースに反映させることである。つまり、図６に示すように、シミュレーションの実行は、事象によってデータベースを書き換えることによって行われる。
【００４８】
本実施例では、以上のような離散事象シミュレーションを、図７に示すようなシミュレーションモデルに対して実行する。図７においては、窓口が１つしかない銀行のモデルを想定しており、客が窓口に来た順にサービスを受けてサービスが終了すると去っていく場合の、ある時点の状態を示している。この場合、複数の客は、異なる時間に順次到着し、前の客がサービス中ならば、前の客のサービスが終わるまで列に並んでおり、その客自身に対する窓口のサービスが終了した時点で退去するものとする。このモデルでは、客が５人いる。
【００４９】
図８は、図７のモデルの状態を表す全てのラインを示す表であり、これらのラインを、後述するような条件に従って登録すると、図９〜１２に示すような多数の表からなるデータベースが作成される。言い換えれば、図９〜１２は、図７のモデルの状態を表すデータベース全体を示している。このデータベースを構成する１つの表を図１３に例示する。図１３に示すように、表は、ある条件で集めた１つまたはそれ以上のライン集合からなる。図１３のライン集合を構成する１つのラインを図１４に例示する。図１４に示すように、１つのラインは３つのワードからなる。
【００５０】
本実施例においては、図１５の表に示すような４つの型のワードが、使用可能なワードとして設定されている。図１６は、図１５の４つの型のワードの例をそれぞれ示している。すなわち、型１のワードは２つの文字列の対で、型２は文字列、整数の対で、型３は２つの整数の対である。また、型４のワードは対ではなく、浮動小数点数１個でワードをなす。
【００５１】
ワード間の整列の順序は次のように決定されている。すなわち、基本的に、小さい方から大きい方に向かって上から下に並べるものとする。そして、型１、２、３は、型４より小さいものとする。また、型１、２、３の間の比較は、まず、ワードの対の左の要素を比較して決める。左の要素が同じ場合は、右の要素の比較によって決める。整数、浮動小数点数の間の比較は、それらの数の大小関係をそのまま使う。さらに、文字列と整数の間の比較は、文字列の方が小さいものとし、そして、これらの比較結果に従って、小さい方が上で、大きい方が下となるように並べる。一方、文字列間については、その文字列がデータベース内で使われた順序に従って、上から下に並べるものとする。
【００５２】
本実施例において、ラインは、単なる３つのワードの集まりではなく、その順序が極めて重要である。本実施例では、図示された表において、図中左のワードから右に向かって、それぞれ、左のワード、中央のワード、右のワードと称する。本実施例においては、１つのラインがデータベースに登録されるとき、ラインの内容、整列の基準となるワードを、左、中央、右のどのワードにしているかによって、自動的に同時に４つの表に登録される。登録すべき表が存在しなければ、表を新たに作成し登録する。
【００５３】
このような１つのラインを登録する４つの表を表すとき、ｘを任意のワードとして、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）というような記法を使用する。この場合、（ｘ，Ｈ）は、中央のワードがｘであるライン集合からなり、左のワードによってラインを整列した表である。（ｘ，Ｍ）は、中央のワードがｘであるライン集合からなり、右のワードによってラインを整列した表である。（ｘ，ｈ）は、左のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。（ｘ，ｍ）は、右のワードがｘであるライン集合からなり、中央のワードによってラインを整列した表である。たとえば、図１４に示す１つのライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」を登録する４つの表は、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）である。それぞれの表を、図１７〜２０に示す。
【００５４】
本実施例のデータベースは、このように、１つのラインに対して４つの表が用意されるので、図９〜１２に示すように、多数の表が集まって構成される。また、本実施例において、モデルの状態の記述は、主に以下の４種類のラインからなる。
【００５５】
第１に、事象の状態を表すラインがある。将来生起する事象リストである。これを表すラインの右のワードが、事象の種類を表す。本実施例では、事象は２つあり、到着事象と退去事象である。以下には、これらの事象をそれぞれ、「ＡＲ」と「ＬＶ」で表す。すなわち、到着事象「ＡＲ」は、客が銀行に到着することを実行し、退去事象「ＬＶ」は客が銀行から去ることを実行する。また、中央のワードは、既に実行が終った事象か将来起こる事象かを表すワードであり、「ＰＡＳＴ ＥＶＥＮＴ」または「ＦＵＴＵＲＥ ＥＶＥＮＴ」である。左のワードは、事象生起時刻を表している。たとえば、ライン「 ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０ 」は、これから起こる事象であり、生起時刻は１０００ｓｅｃ で、起こる事象は到着事象「ＡＲ」であることを示す。
【００５６】
第２に、このモデルにいる５人の客の状態と客のサービス時間を表すラインがある。このラインの左のワードは、客のＩＤ番号であり、中央のワードは客の状態を表し、右のワードでサービス時間を表す。サービス時間とは、客が窓口に入ったときサービスを終えるのに必要な時間のことである。客の状態は４種類あり、それを図２１に表す。この図２１に示すように、客がまだ銀行に来ていない状態（未到着状態）を「 ＣＯＭＩＮＧ ＩＮ」と表す。客が銀行に到着しているが、窓口でサービスを受けられず、列に並んでいる状態を「 ＩＮ ＬＩＮＥ」と表す。客がまさに窓口でサービスを受けている状態を「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」と表す。客がサービスを終了し銀行を去った状態を「 ＧＯＮＥ ＡＷＡＹ」と表す。たとえば、ライン「 ＣＵＳＴＯＭＥＲ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、ＩＤ番号１の客（客１と呼ぶ。）の状態が、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」（サービスを受けている）状態であり、客１が必要なサービス時間は、４００ ｓｅｃ であることを示す。
【００５７】
第３に、客の追跡情報を格納するラインがある。このラインには、左に客のＩＤ番号を表すワードがあり、中央にこのラインが客の追跡情報であることを表すワード「 ＴＲＡＣＥ ＴＲＡＣＥ」がある。右のワードの左の要素は、その客が銀行に到着した時刻を表す。右のワードの右の要素は、その客がサービスを終了し銀行を去った時刻を表す。これらの要素には、初期状態では負の数「−１」を入力する。
【００５８】
第４に、銀行でサービスを終えて去っていった客の、銀行に滞在していた平均時間を示すラインがある。このラインは、中央に、「 ＭＥＡＮ ＲＥＳＰＯＮＳＥ」というワードを持っている。左のワードの左の要素は、去った客の合計滞在時間を表し、左のワードの右の要素は、去った客の数を表す。また、右のワードは平均滞在時間（浮動小数点数）を表す。
【００５９】
本実施例においては、ラインの３つのワードのいずれかを変更すると、自動的に登録すべき４つの表に登録され整列される。たとえば、図１４に示すライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」の右のワードを「 ８００ １２００ 」に変更した場合を想定する。この場合、変更前のライン「ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１ 」は、前記の４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ −１，ｍ）からすべて消去される。そして、新しいライン「ｃｕｓｔｏｍｅｒ１ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００ 」が、新たに４つの表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ ）、（ｃｕｓｔｏｍｅｒ １，ｈ）、（８００ １２００，ｍ）に登録される。この場合、登録される４つの表のうち、先の３つの表は変更前と変わらないが、表の中でのラインの位置が変わり得る。
【００６０】
また、本実施例において、表の検索をする場合には、（ｘ，Ａ）の表と指定することによって、表を検索することができる。ここで、ｘはワード、ＡはＨ，Ｍ，ｈ，ｍのいずれかである。図１３は、（ｃｕｓｔｏｍｅｒ １，ｈ）の表である。また、表（ｃｕｓｔｏｍｅｒ １，ｈ）の何番目のラインと指定して、ラインを検索することもできる。さらに、ラインの内容によってラインを検索することもできる。そしてまた、表（ｃｕｓｔｏｍｅｒ １，ｈ）のうち、右のワードが「ｓｅｃ ３５０ 」のラインを検索することができる。加えて、検索したラインが、その表の中でどの位置にあるを決定することができる。
【００６１】
以下には、本実施例における具体的なシミュレーション操作について説明する。
【００６２】
まず、図９〜１２に示すデータベースを用いて、次に生起する事象を検索する。この場合、次に起きる事象は、図９に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」に記述されている。このラインは、時刻１０００ ｓｅｃに到着事象「ＡＲ」が起こることを表している。そして、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」が生起した場合には、この到着事象「ＡＲ」により、図９〜１２に示されるデータが次のようにして書き換えられる。
【００６３】
到着事象「ＡＲ」は、未到着である客のうち、ＩＤ番号の最も小さい客を探して、銀行に到着させる。未到着である客についてのラインは、表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）に登録されており、この表は、客のＩＤ番号を表す左のワードをソートキーとして整列されている。この未到着の客をＩＤ番号順に表す表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を図２２に示す。この表（ ＣＯＭＩＮＧ ＩＮ，Ｈ）の一番上のラインを検索すると、その左のワードから、客４が得られる。したがって、客４を到着させ、列に並ばせる。すなわち、客４の状態を、「 ＣＯＭＩＮＧ ＩＮ」から「 ＩＮ ＬＩＮＥ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」を、ライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＣＯＭＩＮＧ ＩＮ ｓｅｃ ３００ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＩＮ ＬＩＮＥ ｓｅｃ ３００ 」が、対応する４つの表に登録される。図２３の表（ ＩＮ ＬＩＮＥ，Ｈ）は、到着事象「ＡＲ」実行後における待ち行列中の客をＩＤ番号順に表している。客４が加わって客２、３、４の順に並んでいることがわかる。
【００６４】
次に、客４の追跡情報に関するラインを検索し、銀行到着時刻を記録する。この場合、追跡情報は、表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）に示される。この表の中で、左のワードが「 ｃｕｓｔｏｍｅｒ ４ 」であるラインを検索すると、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」が得られる。このライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」の右のワードの左の要素を、初期値「−１」からこの到着事象「ＡＲ」の時刻値「１０００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」をライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ −１ −１ 」は、到着事象「ＡＲ」実行前にそれが登録されていた４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「 ｃｕｓｔｏｍｅｒ ４ ＴＲＡＣＥ ＴＲＡＣＥ １０００ −１ 」が、客の追跡情報を表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。
【００６５】
続いて、この時刻１０００ ｓｅｃにおける到着事象「ＡＲ」を表している前記のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、到着事象「ＡＲ」実行前のライン「ｓｅｃ １０００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＡＲ ０」は、将来生起する事象を客のＩＤ番号順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）と将来生起する事象を事象の種類順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、到着事象「ＡＲ」実行後のライン「ｓｅｃ １０００ ＰＡＳＴ ＥＶＥＮＴ ＡＲ ０」が、過去に生起した事象を表す表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。
【００６６】
図２４は、以上のような時刻１０００ ｓｅｃにおける到着事象「ＡＲ」実行後のモデルの状態を表している。図２５は、図２４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図２６〜２９に示すような多数の表からなるデータベースが作成される。この図２６〜２９に示すデータベースにおいて、次に生起する事象は、図２６に示す表のうち、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の一番上のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」に記述されている。このラインは、時刻１２００ ｓｅｃに退去事象「ＬＶ」が起こることを表している。そして、この時刻１２００ ｓｅｃにおける退去事象「ＬＶ」が生起した場合には、この退去事象「ＬＶ」により、図２６〜２９に示されるデータが次のようにして書き換えられる。
【００６７】
退去事象「ＬＶ」は、まず、現在窓口にいる客を、表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）から検索する。この窓口にいる客をサービス時間順に表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）には、図２７に示されるように、１つのライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」のみが登録されている。このラインから、現在窓口にいる客が、客１であることがわかる。したがって、客１を銀行から退去させる。すなわち、このライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」において、客の状態を示す中央のワードを、「 ＢＥＩＮＧ ＳＥＲＶＥＤ 」から「 ＧＯＮＥ ＡＷＡＹ」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ４００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＧＯＮＥ ＡＷＡＹ ｓｅｃ ４００ 」が、対応する４つの表に登録される。
【００６８】
次に、列の先頭で待っている客を窓口に入れる。待ち行列中の客をＩＤ番号順に表す表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインを検索する。この表（ ＩＮ ＬＩＮＥ，Ｈ）の一番上のラインは、図２６に示されるように、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」である。このラインから、次に窓口に入る客が、客２であることがわかる。したがって、客２を窓口に入れる。すなわち、このライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」において、客の状態を示す中央のワードを「ＩＮ ＬＩＮＥ 」から「ＢＥＩＮＧ ＳＥＲＶＥＤ」に書き換え、ライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」を、ライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｃｕｓｔｏｍｅｒ ２ ＩＮ ＬＩＮＥ ｓｅｃ ３００」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｃｕｓｔｏｍｅｒ ２ ＢＥＩＮＧ ＳＥＲＶＥＤ ｓｅｃ ３００ 」が、対応する４つの表に登録される。
【００６９】
以上のような操作の結果、現在窓口にいる客を表す表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｍ）と、待ち行列中の客を表す表（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｍ）の内容が変更される。また、退去した客に関するラインを、前述のように変えた結果、新たに、退去した客を示す表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ ＧＯＮＥ ＡＷＡＹ，Ｍ）が作成される。図３０は、このような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行前の客の状態を表す３つの表（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示しており、図３１は、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後の客の状態を表す４つの表（ ＧＯＮＥ ＡＷＡＹ，Ｈ）、（ＢＥＩＮＧ ＳＥＲＶＥＤ，Ｈ）、（ ＩＮ ＬＩＮＥ，Ｈ）、（ ＣＯＭＩＮＧ ＩＮ，Ｈ）を示している。
【００７０】
本実施例において、上述のように、新たに窓口に客２が入ると、その客２が窓口を去る退去時刻は、「現時刻＋サービス時間」によって決定される。すなわち、次の退去事象「ＬＶ」が生起する時刻である。この例において、客２の退去時刻は、「１２００＋３００」から、１５００ ｓｅｃになる。次の退去事象「ＬＶ」が１５００ ｓｅｃに生起するので、この事象に関するラインを新たに登録する。すなわち、ライン「 ｓｅｃ １５００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０ 」を、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録する。また、時刻１２００ ｓｅｃにおける退去事象「ＬＶ」を表している前記のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」の中央のワードを、「 ＦＵＴＵＲＥ ＥＶＥＮＴ 」から「 ＰＡＳＴ ＥＶＥＮＴ 」に変更する。この結果、退去事象「ＬＶ」実行前のライン「ｓｅｃ １２００ ＦＵＴＵＲＥ ＥＶＥＮＴ ＬＶ ０」は、将来生起する事象の表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）、（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｍ）を含む４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「ｓｅｃ １２００ ＰＡＳＴ ＥＶＥＮＴ ＬＶ ０」が、過去に生起した事象の表（ＰＡＳＴ ＥＶＥＮＴ，Ｈ）、（ＰＡＳＴ ＥＶＥＮＴ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、将来生起する事象を時刻順に表す表（ＦＵＴＵＲＥ ＥＶＥＮＴ，Ｈ）の内容は、図３２のようになる。
【００７１】
さらに、客１の追跡情報に関するラインを検索し、銀行退去時刻を記録する。すなわち、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の中で、客１に関するライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」の右のワードの右の要素を、初期値「−１」からこの退去事象「ＬＶ」の時刻値「１２００」に書き換え、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」を、ライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」に変更する。この結果、退去事象「ＬＶ」実行前のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ −１」は、退去事象「ＬＶ」実行前にそれが登録されていた４つの表から削除され、新たに、退去事象「ＬＶ」実行後のライン「 ｃｕｓｔｏｍｅｒ １ ＴＲＡＣＥ ＴＲＡＣＥ ８００ １２００」が、客の追跡情報の表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）、（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｍ）を含む４つの表に登録される。そして、以上のような操作の結果、客の追跡情報を客のＩＤ番号順に表す表（ ＴＲＡＣＥ ＴＲＡＣＥ，Ｈ）の内容は、図３３のようになる。
【００７２】
図３４は、以上のような時刻１２００ ｓｅｃにおける退去事象「ＬＶ」実行後のモデルの状態を表している。図３５は、図３４のモデルの状態を表す全てのラインを示す表であり、各ラインをそれぞれ対応する４つの表に登録することにより、図３６〜３９に示すような多数の表からなるデータベースが作成される。
【００７３】
なお、本発明は、前記実施例に限定されるものではなく、例えば、１つのラインを構成するワードの数は３つに限らず、４つ以上のワードによって１つのラインを構成することも可能であり、逆に、２つのみのワードによって１つのラインを構成することも可能である。また、表のソート規則およびそれに関連する一定の登録条件の設定内容についても自由に設定可能である。例えば、ある位置のワードでソートするだけの単純なソート規則、あるいは逆に、複数のワードをソートキーにするソート規則などを使用することが可能であり、このようなソート規則に応じて、登録条件の内容を適宜設定することができる。
【００７４】
より具体的に、前記実施例の変形例として、３つのワードで構成される１つのラインを登録する表として、前記実施例における４つの表に加え、さらに、左のワードが同じであるライン集合からなり、右のワードをソートキーとする第５の表を対応させるように構成する実施例などが考えられる。また、１つのラインを５つのワードで構成し、１つのラインを登録する表として、第１のワードが同じであるライン集合からなり、第２のワードをソートキーとする第１の表と、第２のワードが同じであるライン集合からなり、第３のワードを第１ソートキー、第４のワードを第２ソートキーとする第２の表、およびその他の数種類の表を対応させるように構成する実施例なども考えられる。
【００７５】
ところで、本発明において、ラインをソートするソート手段としては、各種の手段を使用可能であるが、例えば、ソート、検索、登録、および削除可能な二分探索木を使用することが可能である。以下には、この二分探索木について簡単に解説する。
【００７６】
まず、二分木といくつかの言葉を定義する。図４０のように、二分木はノード（○印）とノードの間の親子関係を示す枝（／ ＼）からなり、どのノードも、子ノードを最大２つしか持たず、かつ、ある１つのノード以外のどのノードも、親ノードをただ１つだけ持つ。左下の子ノードを左子ノード、右下の子ノードを右子ノードと呼ぶ。親ノードを持たない唯一のノードを根ノードと呼ぶ。図４０において、ノード（１）はノード（２）の親ノードであり、ノード（２）はノード（１）の右子ノードである。ノード（３）は二分木の根ノードである。ノードの左（右）の子ノードの下の構造全体を左（右）部分木と言う。図４０において、部分木（４）はノード（１）の右部分木である。
【００７７】
本発明において利用する二分木は、ソート規則の定められた対象があり、二分木のノードがその対象（前記実施例においては、データベースのライン）を指示していて、二分木の任意のノードが指示している対象が、そのノードの左（右）部分木のどのノードが指す対象と比して大きい（小さい）ような二分木である。等しい場合を左に含めるか右に含めるかは二分探索木を使う事情による。ただし、小さい方が表の上にあり、大きい方が表の下にある。
【００７８】
たとえば、図４１は、整数をソートしている二分探索木である。なお、この図４１では、図面の簡略化の目的で、ノードが指示している対象である整数を直接ノードに書き込んでいる。この図４１において、ノード（１）が指す整数「５４」は、その右部分木（２）のどのノードの指示する整数「６０」、「５８」、「７１」、「５６」よりも小さい。
【００７９】
図４２は、このような二分探索木での検索方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木で整数「９」を検索する場合には、次のような手順の処理を行うことになる。この処理について、図４１を参照して説明する。なお、以下の説明において、Ｎは現在のノードを意味する。まず、図４１の根ノード（３）をＮとする。この場合、検索する整数「９」はＮが指示する整数「４６」より小さい。したがって、Ｎの左子ノード（４）を新たにＮにする。この場合、検索する整数「９」はＮが指示する整数「１３」より小さい。したがって、Ｎの左子ノード（５）を新たにＮとする。この場合、Ｎが指示する整数は「９」であり、このノードが、検索目的のノードである。
【００８０】
図４３は、二分探索木での登録方法の一例を示すフローチャートである。このフローチャートによって、たとえば、図４１の二分探索木に対して、整数「４８」を指示するノードを登録する場合には、次のような手順の処理を行うことになる。この処理について、図４４を参照して説明する。まず、図４４の根ノード（１）をＮにする。この場合、登録する整数「４８」は、Ｎが指示する整数「４６」より大きい。よって、Ｎの右子ノード（２）を新たにＮとする。この場合、登録する整数「４８」はＮが指示する整数「５４」より小さい。したがって、Ｎの左子ノード（３）を新たにＮにする。この場合、登録する整数「４８」はＮが指示する整数「４９」より小さいが、現在のノードＮの左には子ノードがないので、Ｎを親ノードとして、整数「４８」を指示する左子ノード（４）を作成する。
【００８１】
図４５は、二分探索木での削除方法の一例を示すフローチャートである。このフローチャートによって、次のような処理を行うことができる。すなわち、まず、ノードＡを削除する場合、そのノードＡが子ノードを全く持たない場合には、図４６に示すように、そのままノードＡを削除する。また、ノードＡが左（右）子ノードだけしか持たない場合には、図４７に示すように、このノードＡを消して、左（右）部分木をノードＡの位置に付け替える。一方、ノードＡが左右の両子ノードを持つ場合には、図４８に示すように、ソート順においてノードＡの１つ前のノード（これはノードＡの左部分木の中で最も右にあるノードである。）をＮとして（図４８の左の状態）、ノードＡとノードＮを入れ替える（図４８の操作▲１▼：左→中央の状態）。このように入れ替えた際に、ノードＡが左部分木を持たない場合には、単にノードＡを消す。ノードＡが左部分木を持つならば、その左部分木をノードＡの位置に付け替える（図４８の操作▲２▼：中央→右の状態）。
【００８２】
なお、ラインをソートするソート手段として、このような二分探索木を用いることは有効であるが、前述の通り、ラインのソート、検索、登録、および削除である限り、他のソート手段を使用することも同様に可能である。
【００８３】
続いて、本発明におけるデータベースへの機能の実装例を、図４９によって説明する。この例では、図４９の中央部分に６つのラインｘｕｗ、ｖｘｚ、ｗｘｙ、ｘｘｘ、ｙｘｘ、ｙｗｘが示されている。ここで、ｕ，ｖ，ｗ，ｘ，ｙ，ｚは、それぞれ異なるワードを表す。ラインの検索に際しては、各ワードに対応する４つの異なる表を使用できる。たとえば、ワードをｘとすると、４つの表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）で表される。これらの表は、図４９中において、二分探索木：木（１）〜（４）として表現されている。この場合、木の各ノードは、ラインとそのラインのソートキーになっているワードを指示している。たとえば、木（１）の根のノードはラインｗｘｙを指示し、さらにソートキーであるワードｗを指示している。逆にラインも対応するノードを指示している。ある木のノードが指示しているラインは、その木が表現する表に含まれることを意味する。たとえば表（ｘ，Ｈ）に対応する木（１）には、ラインｘｘｘを指示するノードがあるので、ラインｘｘｘは、表（ｘ，Ｈ）に含まれている。
【００８４】
表（ｘ，Ｈ）は左のワードがソートキーなので、この表を表現する二分探索木の各ノードは、対応するラインと左のワードを指示している。すなわち、各表の各ワードは、対応するラインを指示するとともに、（ｘ，Ｍ）なら右、（ｘ，ｈ）、（ｘ，ｍ）なら中央のワードも指示している。たとえば、図４９のラインｘｘｘは、４つの表を表現する４つの二分探索木のノードによって指示されている。また逆に、ラインｘｘｘは、このラインｘｘｘを指示するノードを指示している。つまり、このラインｘｘｘを指定することにより、このラインｘｘｘを含む４つの表を表現している４つの二分探索木を見つけられる。
【００８５】
以上のような構造を有する図４９のデータベースにおいて、ラインを削除する方法を説明する。データベース上からラインｘｘｘを削除する場合には、このラインｘｘｘを含む４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）からラインｘｘｘを削除する。この場合、図４９上の木（１）〜（４）のラインｘｘｘを指示しているノードを削除しなければならない。ノードの削除は、二分探索木に関して前述した手順に従う。その結果、図５０に示すような、ラインｘｘｘのないデータベースが得られる。
【００８６】
逆に、図５０に示すようなデータベースに対して、ラインｘｘｘを登録するときは、４つの表（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）にそれぞれラインｘｘｘを登録しなければならない。この場合、これらの４つの表に対応する木（１）〜（４）にラインｘｘｘを指示するノードを登録する。ノードの登録の手順は、二分探索木に関して前述した手順に従う。
【００８７】
さらに、図４９のデータベースにおける任意のラインの検索は、図５１のようにして行うことができる。この図５１は、一例として、左と中央にワードｘを持つラインｘｘ？を１つ検索し、右のワードを検索する場合の手順を示している。このラインｘｘ？を含む可能性のある表は、（ｘ，Ｈ）、（ｘ，Ｍ）、（ｘ，ｈ）、（ｘ，ｍ）である。中央のワードがｘで、左のワードをソートキーとする表（ｘ，Ｈ）を使用することにより、目的のラインを探索できる。この図５１上で、まず、ワードｘを起点とする矢印（１）をたどると、矢印（１）は表（ｘ，Ｈ）を指示している。この表のラインは、整列順を保持するため、二分探索木のノードに格納されている。表（ｘ，Ｈ）から矢印（２）をたどると、その二分探索木：木（３）の根を指示している。木の根を指示することは、木自体を指示することに等しい。また逆に、表（ｘ，Ｈ）のラインは、木（３）の各ノードから指示されている。
【００８８】
続いて、木（３）の根から矢印（４）をたどると、根のノードが指示しているラインはｗｘｙである。この場合、ラインｗｘｙと検索するラインｘｘ？の大小を比較するとｘｘ？の方が大きい（つまり表の下、木のノードの右にある）。そこで、木（３）の根の右の枝（５）を下がり、その先のノードが矢印（６）によって指示するラインｙｘｘと比較する。この場合、ｘｘ？の方が小さいので、左の枝（７）を下がる。その枝（７）の先のノードが矢印（８）によって指示するラインはｘｘｘであり、検索しているラインに該当する。したがって、左と中央にワードｘを持つラインｘｘ？の右のワードはｘであることがわかる。
【００８９】
【発明の効果】
以上説明したように、本発明においては、ラインと表との対応関係を示す一定の登録条件を予め設定しておくことにより、この登録条件に基づいて、１つのラインを登録する複数の表を自動的に指定することができるため、新たに登録するラインまたは内容を変更するラインとすでに登録されているラインとの関連を容易に把握可能であり、表とラインの管理が簡略で、設計時に想定されなかった使い方に対しても柔軟に対処でき、操作性および能率に優れたデータベース装置を提供することができる。
【図面の簡単な説明】
【図１】本発明によるデータベース装置の基本的な機能構成の一例を示す機能ブロック図。
【図２】本発明によるデータベース装置の一般的な登録処理手順の一例を示すフローチャート。
【図３】本発明によるデータベース装置の一般的な検索処理手順の一例を示すフローチャート。
【図４】本発明によるデータベース装置の一般的な削除処理手順の一例を示すフローチャート。
【図５】本発明によるデータベース装置の一般的な変更処理手順の一例を示すフローチャート。
【図６】離散事象シミュレーションの手順を示す説明図。
【図７】本発明のデータベース装置によって離散事象シミュレーションを行う一実施例において、シミュレートするモデルの１つの状態を示す模式図。
【図８】図７のモデルの状態を表す全てのラインを示す表。
【図９】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１０】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１１】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１２】図８のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図１３】図９〜１２のデータベースを構成する１つの表を示す図。
【図１４】図１３のライン集合を構成する１つのラインを示す図。
【図１５】本発明において使用可能なワードの４つの型を示す表。
【図１６】図１５のワードの例を示す表。
【図１７】図１４のラインを登録する１つの表を示す図。
【図１８】図１４のラインを登録する１つの表を示す図。
【図１９】図１４のラインを登録する１つの表を示す図。
【図２０】図１４のラインを登録する１つの表を示す図。
【図２１】図７のモデルにいる客の４種類の状態を示す表。
【図２２】図９〜１２のデータベースを構成する表のうち、未到着の客をＩＤ番号順に表す表。
【図２３】図９〜１２のデータベースを用いた離散事象シミュレーションによる到着事象実行後の待ち行列中の客をＩＤ番号順に表す表。
【図２４】図７のモデルの、離散事象シミュレーションによる到着事象実行後における状態を示す模式図。
【図２５】図２４のモデルの状態を表す全てのラインを示す表。
【図２６】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２７】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２８】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図２９】図２５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３０】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行前の客の状態を表す３つの表を示す図。
【図３１】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の客の状態を表す４つの表を示す図。
【図３２】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、将来生起する事象を時刻順に表す表の内容を示す図。
【図３３】図２６〜２９のデータベースを用いた離散事象シミュレーションによる退去事象実行後の時点での、客の追跡情報を客のＩＤ番号順に表す表の内容を示す図。
【図３４】図２４のモデルの、離散事象シミュレーションによる退去事象実行後における状態を示す図。
【図３５】図３４のモデルの状態を表す全てのラインを示す表。
【図３６】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３７】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３８】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図３９】図３５のラインから作成されるデータベースの一部を構成する複数の表を示す図。
【図４０】本発明によるデータベース装置においてソート手段として使用可能な二分探索木の一例を示す図。
【図４１】整数をソートしている二分探索木の一例を示す図。
【図４２】二分探索木での検索方法の一例を示すフローチャート。
【図４３】二分探索木での登録方法の一例を示すフローチャート。
【図４４】図４１の二分探索木に対して、新しいノードを登録する手順とそれを登録した二分探索木を示す図。
【図４５】二分探索木での削除方法の一例を示すフローチャート。
【図４６】図４５の方法による削除操作の一例を示す説明図。
【図４７】図４５の方法による削除操作の一例を示す説明図。
【図４８】図４５の方法による削除操作の一例を示す説明図。
【図４９】本発明に従って機能を実装したデータベースの一例を示す説明図。
【図５０】図４９のデータベースから１つのラインを削除して得られたデータベースを示す説明図。
【図５１】図４９のデータベースにおける任意のラインの検索手順を示す説明図。
【図５２】データベースに登録されるリレーションの一例を示す表。
【図５３】データベースに登録されるリレーションの一例を示す表。
【符号の説明】
１…入力手段
２…格納手段
３…表指定手段
４…管理手段
５…登録手段
６…ソート手段
７…検索手段
８…削除手段
９…出力手段
１０…表作成手段[0001]
[Industrial application fields]
The present invention relates to a database apparatus.
[0002]
[Prior art]
The purpose of database (DB) technology is to make the internal structure of data independent of application programs that use it.
[0003]
The conceptual framework of the conventional DB system includes representative ones such as hierarchy, network, relational, and the like. Of these, the relational database (RDB) is the most theoretically organized and is now a standard technology. The basic concept of this RDB is “relationship”. This point will be described below.
[0004]
For example, n sets S₁, ..., S_nThe Cartesian product set R of is defined as follows.
[0005]
[Expression 1]

In this case, an arbitrary subset of R is defined as S₁, ..., S_nCalled an n-term relationship (or simply a relationship or a relation). For example, two sets S₁, S₂Is defined as shown in the following equation (2).
[0006]
[Expression 2]

At this time, two sets S₁, S₂Cartesian product set S₁× S₂Is expressed as the following equation (3).
[0007]
[Equation 3]

Among these, the subset R as shown in the following formula (4) is a prefecture-city relation.
[0008]
[Expression 4]

The RDB is a DB that uses such a set of relations as data. In short, the relation is a table as shown in FIGS. Generally, one row is called a tuple (tuple, tuple, record) when the table is viewed horizontally, and one column is called an attribute when viewed vertically. The name given to each attribute in the table of FIG. 52 is referred to as an attribute name, and the value of each attribute is referred to as an attribute value (field value). The name of the table is referred to as a relation name (relation name).
[0009]
Thus, in RDB, a data record is accommodated in a computer using a table called a relation as a conceptual intermediate. Of course, there is a high possibility that a complicated data structure or access procedure is taken inside the computer. However, users cannot see the complicated implementation. Information about the implementation is hidden. It's a usage where there is just a table, a container for data, and the user puts a record in that container.
[0010]
The RDB has the following four processing functions. :
“1. Set up a table to accommodate records.”
“2. Register a record in the table.”
“3. Delete the record from the table.”
“4. Search for records in the table.”
The RDB implementation can efficiently perform record registration processing, deletion processing, and search processing by specifying attributes and attribute values.
[0011]
One of the features of RDB is that the table and the record are highly independent. The user first sets a table, and then registers a record in the table. It is up to the user to register a record in a table. Even when an attribute value of a retrieved record is changed, the correspondence between the record and the table does not change. In order for the user to change the correspondence between records and tables, record registration and deletion operations as described above are required. Even when multiple records are specified and records created by performing operations between records registered in those tables are registered in the specified new table, which table the newly generated record is registered in Managed by the user. That is, in RDB, the correspondence between a table and a record is given only through the act of a user registering an arbitrary record in an arbitrary table.
[0012]
As explained earlier, a relationship is a set. In general, there are a deferred method and an inclusive method for defining a set. In the exaggerated method, a set is defined by enumerating all elements. For example, it is an exaggerated definition to define a set S of whole integers of 0 or more and 9 or less as shown in the following equation (5).
[0013]
[Equation 5]

(5) On the other hand, it is an inclusive definition that defines the properties to be satisfied by the elements belonging to the set. For example, defining the above set S as in the following equation (6) is an inclusive definition. Here, Z is a set of integers.
[0014]
[Formula 6]

On the other hand, the act of registering a record in a table is that this record belongs to this relation (table) and does not belong to another relation (table) in which this record is not registered. It is defined by enumerating values. Since this is performed for all records, the relation is defined in an extended manner.
[0015]
As a result, RDB has the following characteristics. First, the process performed according to the relation is conceptually simple and can be performed efficiently. That is, the program is simple and the amount of calculation is small. For example, in FIG.
"(A) Search for people whose birth year is '63."
This process is based on the relation and can be performed efficiently.
[0016]
[Problems to be solved by the invention]
On the other hand, in RDB, a process that does not follow the relation is a process that was not originally assumed, and thus the efficiency is poor. For example, in FIG.
“(B) Search for the third person in order of age.”
Is a process that does not follow the relation. This process can be easily executed as long as the attribute of “order of birth” originally exists in the table of FIG. Nevertheless, in the table of FIG. 53, since the attribute “order of birth” is not considered in advance, in order to perform the process (B), it has the birth year among the registered records. After examining all the records, the order of these records must be determined. When such a search is executed, the program becomes longer and the calculation amount increases.
[0017]
Further, in this case, the attribute “order of birth” used in the process (B) is naturally determined from the attribute “birth year” used in the process (A). In other words, the attribute “order of birth” naturally exists as an inclusive property that defines a subset of the relationship of records having the attribute “birth year”. Nevertheless, since the attribute “order of birth year” is an attribute that does not exist in this RDB, the process (B) using this attribute cannot be easily executed.
[0018]
From the above, it can be seen that the RDB conforms to the usage assumed at the time of designing, but is inefficient when trying to use it slightly different from the assumption. Here, the usage assumed at the time of design is to handle the record with the attribute and the value used for the extension definition. Further, the usage slightly deviating from the assumption is to handle a record that is inherently defined by an attribute existing in the RDB and a property derived from its value, as in the process (B) described above.
[0019]
In general, if time passes after designing a DB, it is inevitable that usage will deviate from the design assumptions. This is because DB has a longer lifetime than application programs that use it. That is, in most cases, the DB already exists, and the program is written with the intention of managing the information existing in the DB. As described above, if the usage of the DB deviates from the assumption at the time of design, if it is associated with the above-described processing for the table in FIG. 53, it is sufficient to be able to search for the attribute “birth year” at the time of DB design. In spite of the fact that it was considered, there are cases where it becomes clear later that it is actually easier to use in order of age. In such a case, in the RDB, an attribute “order by age” is newly provided. This is a rework of the table, and it is a difficult task when the number of records is large.
[0020]
This is due to the essential feature that the correspondence between tables and records (registration operation) in a conventional database is arbitrary. In other words, when building and using a database,
“A. Creating and changing records”
"B. Registration and deletion of records to the table"
These two operations need to be executed in association with each other. Because, when saving data, if there is a record in the database, not only the existence of this record, but in which table the record is registered and in which table it is not registered Because it is important. Therefore, when one record represents the contents to be registered in a plurality of tables, the user must judge it and register the record individually for the corresponding plurality of tables. .
[0021]
For example, in the event schedule management database, in a table (table name: FUTURE EVENT) that manages future events, a record of “time event” is registered to represent the event and its occurrence time. Here, it is assumed that an indefinite number of participants are scheduled for each event. In response to this, a table (table name: ATTENDANT EVENT) relating to the planned participant is created, and a record of “participant event” is registered in this table. Then, the record of “time event” registered in the table “FUTURE EVENT” is deleted when the event occurs, and is registered in the table (table name: PAST EVENT) that manages the event that has already occurred.
[0022]
In this case, each table efficiently registers only records of a format suitable for the purpose, but a search for what information is registered for one event is performed using three tables (FUTURE EVENT). , ATTENDANT EVENT, PAST EVENT) cannot be executed unless they are individually examined. For example, a “time event” record for an event should always be included in either the table “FUTURE EVENT” or the table “PAST EVENT”. Must be examined at the same time. In addition, when an event occurs, two processes of deleting a record related to the event from one table and registering a record related to the event to the other table must be performed simultaneously at the user's responsibility. An error may occur here, and it takes time to detect the error.
[0023]
As one method for avoiding such a problem, for example, one table (table name: EVENT) is created by separating the two tables “FUTURE EVENT” and “PAST EVENT”, and this table “EVENT” is created. In addition, it is conceivable to register an event schedule as a record “FUTURE / PAST time event”. Here, the field “FUTURE / PAST” means FUTURE or PAST. When this method is adopted, when an event occurs, one process of changing the field value of “FUTURE / PAST” is performed without performing two processes (deletion and registration) for different tables as in the above-described method. Therefore, the possibility of an error is extremely reduced, and the detection of the error is relatively easy.
[0024]
On the other hand, in order to proceed with this method, all the tables for registering related records are merged into one table, so many fields that are not used effectively are included. A long record will be registered. Registering a large number of such long and wasteful records is nothing other than abandoning the efficient operation of the database by setting a table for storing the records.
[0025]
As described above, in a conventional database system that attempts to efficiently store and use data by setting a table and arbitrarily registering and deleting records in the table, the intention of the correspondence relationship between the table and the record A lot of labor is required for efficient management, and much of that cost is spent. In addition, in the conventional database, regarding the contents of a record, that is, the field value, whether or not the record having a certain field value can be registered in the specified table (as a correct record) is restricted. There is no function for instructing whether or not to be registered in the table, or for automatically automatically registering.
[0026]
Therefore, in a conventional database, it is difficult to search for a specific field value what record has the field value and in which table the record having the field value is registered. is there. That is, the field value is a character string or a numerical value, and the meaning of the field value used in each record (each field) is arbitrary by the user. Therefore, it is possible that the same field value is used in a completely different meaning between different records in different tables. Such use of the same field value in a different meaning causes confusion in data processing in the database and is extremely inconvenient. Therefore, when a user creates a record, it is essential to know how each field value is related to the field value already used in the database. In this way, in order to fully understand the information of a specific field value throughout the database, all the records in the related table (including records) in the conventional database are examined and a conclusion is drawn. There must be. However, execution of such a search requires a lot of labor, and it is difficult for the user to maintain and manage information on tables and fields that are possible for each field value.
[0027]
The present invention has been proposed to solve the above-described problems of the prior art, and its purpose is to facilitate the association between newly registered data or data whose contents are to be changed and already registered data. It is possible to provide a database device that is easy to grasp, can easily manage tables and data, can flexibly cope with usage that was not assumed at the time of design, and has excellent operability and efficiency.
[0028]
[Means for Solving the Problems]
The database device according to the present invention comprises:A database device in which lines formed by arranging a plurality of words indicating a single type or a plurality of types of values selected from character strings, integers, and floating-point numbers in an order are registered in a plurality of tables. And a management means, a table specifying means, a sorting means, and a search means. Here, the management means, for each table, a word condition of registering a line having a specific value as a word of a determination position selected from a plurality of rank positions in the input line, a plurality of conditions A means for managing registration conditions of a plurality of tables defined by table information including a sorting rule of sorting by a word value at a sorting position selected separately from a position for determination from among rank positions. . The table designating means is a means for designating a plurality of tables for registering input lines based on the table registration conditions. The sorting means is means for sorting the lines registered in the table on each table based on the value of the word at the rank position specified by the sorting rule set in each table. Further, the search means is a means for searching for each line based on the order sorted by the sort means on each table designated by the table designation means.
[0029]
[Action]
The operation of the present invention having the above-described configuration is as follows.First, for a plurality of sequential positions in a line, a sorting rule for sorting by the word condition for determining registration of the line according to the value of the word at the position for determination and the value of the word at the position for sorting Since the registration condition is defined by the table information including “”, it is possible to clearly show the correspondence between one line and a plurality of tables to which this line should be registered. As a result, when registering a line, a table designating unit automatically selects a plurality of tables to be stored according to the values of a plurality of words constituting the line based on a registration condition indicating a correspondence relationship between the line and the table. Therefore, one line can be easily registered in a plurality of tables having different sort rules.Therefore, it is possible to flexibly deal with usage that was not assumed at the time of design, and operability and efficiency can be improved.
[0030]
On the other hand, in the present invention, a table storing one word can be automatically specified by the table specifying means, and a line by one word can be obtained by using a search means in addition to the table specifying means. Can be easily searched. Therefore, the information of one word can be easily grasped throughout the entire database, and the relationship between the line already registered in the database and the newly registered line can be easily grasped. In addition, since the sorting method is used, it is easy to automatically search for lines by sort order and determine the position of the searched line. The efficiency of change processing can be improved.
[0031]
【Example】
[Device configuration]
The following is a description of a database device according to the present invention.ConstitutionWill be described with reference to FIG. Here, FIG. 1 shows a database apparatus according to the present invention.Functional block diagram showing an example of basic functional configurationIt is.The apparatus shown in FIG. 1 includes an input unit 1, a storage unit 2, a table designation unit 3, a management unit 4, a registration unit 5, a sort unit 6, a search unit 7, a deletion unit 8, and an output unit 9. It is configured to search for lines based on the contents of words while registering / deleting multiple lines individually / selectively for multiple tables that meet multiple conditions, using the word sequence as a line. ing.
[0032]
The input unit 1 has a function of inputting an ordered sequence of a plurality of words as a line, and a function of designating an already registered line by word content or line position and inputting a search command, a deletion command, or a change command. Have The storage means 2 has a function of storing a plurality of table information including a sorting rule set for each table, line information registered in each table, and sort order information thereof.
[0033]
The table designating means 3 has a predetermined registration condition indicating the correspondence relationship between the line and the table, and in response to the line input by the input means 1, the contents of the word of the inputted line and the registration condition are set. Based on the function of designating a plurality of tables for registering the line, and the word contents of the designated line in response to the input of the search command, the delete command or the change command of the registered line by the input means 1 Based on the registration conditions, it has a function of designating a plurality of tables in which the line is registered.
[0034]
The management means 4 manages a plurality of table information stored in the storage means 2 and provides a plurality of table information designated by the table designation means 3, registration information by the registration means 5 and the sorting means 6, It has a function of updating management information with deletion information by the deletion means 8 and a function of managing search information by the search means 7.
[0035]
The registration means 5 receives a plurality of table information designated by the table designation means 3 from the management means 4 in response to the line input by the input means 1, and each line inputted by the input means 1 is received in each table. Has the function to register. The sorting unit 6 has a function of sorting the lines registered in the plurality of tables by the registering unit 5 on the table based on the content of the word at the position specified by the sorting rule set in each table.
[0036]
The retrieval means 7 receives a plurality of table information designated by the table designation means 3 from the management means 4 in response to an input of a search command, a deletion command, or a change command for registered lines by the input means 1. It has a function of searching each registered line designated by the input means 1 based on the order sorted by the sort means 6 on the table. The deletion unit 8 receives a plurality of table information searched by the search unit 7 in response to the input of the registered line deletion command or change command by the input unit 1, and selects the lines searched on each table. Has a function to delete. The output unit 9 has a function of outputting management information from the management unit 4.
[0037]
In general, the management unit 4 includes a table creation unit 10. The table creation means 10 has a function of creating a new table that matches the designated table when the table designated by the table designation means 3 does not exist in the storage means. On the other hand, as a word constituting a line, for example, one of four types of order pairs of two character strings, an order pair of character strings and integers, an order pair of two integers, or one floating point number is used. Is possible. More generally, it is possible to use strings, integers, floating point numbers, and any number of ordinal sets. Furthermore, in the present invention, for example, a binary search tree can be used as the sorting means 6 for sorting the lines on the table. Similar to the binary search tree, line sorting, search, registration, and If the deletion is possible, another sort means can be used.
[0038]
Next, registration conditions preset in the table designating means 3 in the present invention, that is, certain registration conditions indicating the correspondence between lines and tables will be described. First, one line consists of n words (w₁, ..., w_n). And k types of tables for registering one line are H₁, ..., H_kIt is expressed. In the present invention, one line is not necessarily registered in k types of tables, and the number of registered tables may differ depending on the contents of the lines.
[0039]
Here, it is assumed that each table is represented by (x, N, S) as x = word or line, N = 1 to n, and S = sort rule. In this case, if x is a word, (x, N, S) represents a table composed of lines in which the Nth word from the left is the word x and the sorting rule is S. If x is a line, (x, N, S) represents a table in which the N-th word from the left is the N-th word of the line x and the sorting rule is S. Further, when i = 1,..., K, the i-th table Hi is expressed as (x, Ni, Si).
[0040]
[Outline of processing procedure]
2 to 5 areAs shown in FIG.FIG. 2 is a flowchart showing an example of a general processing procedure of the database apparatus, FIG. 2 shows a registration process, FIG. 3 shows a search process, FIG. 4 shows a deletion process, and FIG.Below, the outline | summary of each process procedure is demonstrated sequentially.
[0041]
First, when registering a line, as shown in FIG. 2, in step 1, n words (w₁, ..., w_n) And n words (w₁, ..., w_n) Is created and input. In step 3, the table designating means 3 registers the line L based on the word contents of the line L and preset registration conditions.₁, ..., H_kIs automatically specified. In step 4, the management means 4 determines whether or not a plurality of designated tables exist in the storage means 2, and the designated table H₁, ..., H_kIf there is a table that does not exist, a necessary table is created by the table creating means 10 in step 5. In step 6, the designated k types of tables H₁, ..., H_kIs provided to the registration means 5, and the registration means 5 registers the line L in each table. In step 7, each table is sorted by the sorting means 6 based on the sorting rule S set for each table, and the registration process is terminated.
[0042]
Next, when searching for a line, as shown in FIG. 3, the line L to be searched is designated by the input means 1 in step 11, and the word of the line L is designated by the table designating means 3 in step 12. Based on the contents and preset registration conditions, k types of tables H in which the line L is registered₁, ..., H_kIs automatically specified. In step 13, the designated k types of tables H₁, ..., H_kIs provided to the search means 7, and the search means 7 searches for the designated line L in each table in the sort order, and ends the search processing.
[0043]
When deleting a line, as shown in FIG. 4, the line L to be deleted is designated by the input means 1 in step 21, and the word contents of the line L are designated by the table designation means 3 in step 22. And k types of tables H in which lines L are registered based on preset registration conditions.₁, ..., H_kIs automatically specified. In step 23, the designated k types of tables H₁, ..., H_kIs provided to the search means 7, and the search means 7 searches the specified line L in each table in the sort order. In step 24, each specified table and the information of the searched line position in each table are provided to the deletion unit 8, and the deletion unit 8 deletes the line L from each table, and the deletion process is terminated.
[0044]
On the other hand, when changing the line, as shown in FIG. 5, the line L to be changed is designated by the input means 1 in step 31, and the changed n words and their words are changed in step 32 and step 33. The changed line L ′, which is an order sequence, is created and input. In step 34, the table designating means 3 performs k types of tables H in which the line L before change is registered based on the word contents of the line L before change and preset registration conditions.₁, ..., H_kIs automatically specified. In step 35, the designated k types of tables H₁, ..., H_kIs provided to the search means 7, and the designated line L is searched in the sort order in each table. In step 36, each specified table and information on the searched line position in each table are provided to the deleting unit 8, and the deleting unit 8 deletes the line L before the change from each table. In step 37, the table designating means 3 registers the line L 'based on the contents of the word of the changed line L' and preset registration conditions.₁', ..., H_k'Is automatically specified. In step 38, the management means 4 determines whether or not the specified plurality of tables exist in the storage means 2, and the specified table H₁', ..., H_kIf there is a non-existing table among the ′, a necessary table is created by the table creating means 10 in step 39. In step 40, the designated k types of tables H₁', ..., H_k'Is provided to the registration means 5, and the registration means 5 registers the changed line L' in each table. In step 41, the sorting means 6 sorts each table based on the sorting rule S set for each table, and ends the change process.
[0045]
In the exemplary embodiment of the present invention, one line is composed of three words. There, the word is either a string string, a string integer, an integer-integer ordered pair, or a floating point number. When registering one line, this line is automatically registered in four tables at the same time according to the difference between the three words constituting the line and the sort key. These four tables show (b, H), (b, M), (a, h), (c, c) when the three words of one line to be registered are a, b, c in order from the left. m). Here, (b, H) represents a table in which the central word is b and the left word is the sort key. (B, M) is a collection of lines whose central word is b, and represents a table in which the right word is the sort key. (A, h) is a collection of lines in which the left word is a, and represents a table in which the central word is the sort key. (C, m) is a collection of lines whose right word is c, and represents a table in which the central word is the sort key. As will be described later, for example, when one line “customer 1 TRACE TRACE 800 −1” is registered in the database, this line includes four tables (TRACE TRACE, H), (TRACE TRACE, M), ( customer 1, h), (800-1, m). Further, when deleting one line, the line is automatically deleted from all four tables in which the line is registered. Further, when changing the contents of one line, the line is once deleted from the four tables, the line is changed, and the changed new line is registered again. That is, when one line is newly registered, a maximum of four tables are newly created.
[0046]
[Details of specific examples]
In the following, according to the present inventionconcreteAs an example, an example in which a discrete event simulation is performed by a database apparatus having the configuration shown in FIG. 1 will be described. Since the means (function) and the operation of the database apparatus of FIG. 1 are as described above, only the features of this embodiment will be described below.
[0047]
As a premise for explaining the embodiment, a discrete event simulation will be explained. In discrete event simulation, the initial state of a model to be simulated is described in a database. Then, the time is advanced to the time of the event that occurs first in the event list that occurs in the database in the future, and the event is performed. Here, performing an event means reflecting a change in the model caused by the occurrence of the event in the database describing the model. That is, as shown in FIG. 6, the simulation is performed by rewriting the database according to the event.
[0048]
In this embodiment, the discrete event simulation as described above is executed for a simulation model as shown in FIG. FIG. 7 assumes a bank model having only one window, and shows a state at a certain point in time when a customer receives a service in the order in which he / she came to the window and leaves when the service ends. In this case, multiple customers arrive at different times in sequence, and if the previous customer is in service, they are lined up until the previous customer's service is completed, and when the service at the window for that customer is completed Suppose to leave. In this model, there are five customers.
[0049]
FIG. 8 is a table showing all the lines representing the state of the model of FIG. 7. When these lines are registered according to the conditions described later, a database consisting of a large number of tables as shown in FIGS. Created. In other words, FIGS. 9 to 12 show the entire database representing the state of the model of FIG. One table constituting this database is exemplified in FIG. As shown in FIG. 13, the table consists of one or more sets of lines collected under certain conditions. One line constituting the line set of FIG. 13 is illustrated in FIG. As shown in FIG. 14, one line consists of three words.
[0050]
In this embodiment, four types of words as shown in the table of FIG. 15 are set as usable words. FIG. 16 shows examples of the four types of words in FIG. That is, a word of type 1 is a pair of two character strings, type 2 is a pair of character strings and integers, and type 3 is a pair of two integers. In addition, type 4 words are not pairs, but are formed by a single floating point number.
[0051]
The order of alignment between words is determined as follows. That is, it is basically arranged from top to bottom from the smallest to the largest. The molds 1, 2, and 3 are assumed to be smaller than the mold 4. Also, the comparison between types 1, 2, and 3 is determined by comparing the left elements of the word pairs. If the left element is the same, determine by comparing the right element. Comparisons between integers and floating-point numbers use the magnitude relationship of those numbers as they are. Further, in the comparison between the character string and the integer, the character string is assumed to be smaller, and the smaller one is arranged on the upper side and the larger one is arranged on the lower side in accordance with these comparison results. On the other hand, between character strings, the character strings are arranged from top to bottom according to the order in which the character strings are used in the database.
[0052]
In this embodiment, the line is not just a collection of three words, the order of which is very important. In the present embodiment, in the illustrated table, the left word, the center word, and the right word are referred to from the left word to the right in the drawing, respectively. In this embodiment, when one line is registered in the database, the contents of the line and the word used as the alignment reference are automatically set to four tables at the same time depending on whether the word is left, center, or right. be registered. If there is no table to be registered, a new table is created and registered.
[0053]
When expressing four tables for registering one line, the notation such as (x, H), (x, M), (x, h), (x, m) where x is an arbitrary word Is used. In this case, (x, H) is a table composed of a set of lines whose central word is x, and the lines are aligned by the left word. (X, M) is a table that consists of a set of lines whose central word is x, and lines are aligned by the right word. (X, h) is a table that is composed of a set of lines whose left word is x and in which the lines are aligned by the central word. (X, m) is a table in which the right word is a set of lines whose x is x, and the lines are aligned by the center word. For example, four tables for registering one line “customer 1 TRACE TRACE 800 −1” shown in FIG. 14 are (TRACE TRACE, H), (TRACE TRACE, M), (customer 1, h), (800 − 1, m). Each table is shown in FIGS.
[0054]
In this way, the database of this embodiment is prepared with a large number of tables as shown in FIGS. 9 to 12 because four tables are prepared for one line. In the present embodiment, the description of the model state mainly consists of the following four types of lines.
[0055]
First, there is a line that represents the state of the event. A list of events that will occur in the future. The word to the right of this line represents the type of event. In this embodiment, there are two events, an arrival event and a leaving event. In the following, these events are represented by “AR” and “LV”, respectively. That is, the arrival event “AR” executes that the customer arrives at the bank, and the leaving event “LV” executes that the customer leaves the bank. The center word is a word indicating whether the event has already been executed or will occur in the future, and is “PAST EVENT” or “FUTURE EVENT”. The left word represents the event occurrence time. For example, the line “sec 1000 FUTURE EVENT AR 0” is an event that will occur, the occurrence time is 1000 sec, and the event that occurs is the arrival event “AR”.
[0056]
Second, there are lines representing the status of the five customers and customer service time in this model. The left word of this line is the customer ID number, the middle word represents the customer's status, and the right word represents the service time. The service time is the time required to finish the service when the customer enters the window. There are four types of customer states, which are shown in FIG. As shown in FIG. 21, a state where the customer has not yet come to the bank (non-arrival state) is represented as “COMING IN”. A state in which the customer has arrived at the bank but cannot receive the service at the counter and is in line is represented as “IN LINE”. The state in which the customer is receiving service at the window is represented as “BEING SERVED”. A state in which the customer ends the service and leaves the bank is expressed as “GONE AWAY”. For example, in the line “CUSTOMER 1 BEING SERVED sec 400”, the customer of ID number 1 (referred to as customer 1) is in the state of “BEING SERVED” (receiving service), and the service that customer 1 requires is required. The time indicates 400 sec.
[0057]
Third, there is a line for storing customer tracking information. In this line, there is a word representing the customer ID number on the left, and a word “TRACE TRACE” representing that this line is tracking information of the customer in the center. The left element of the right word represents the time when the customer arrived at the bank. The right element of the right word represents the time when the customer finished the service and left the bank. For these elements, a negative number “−1” is input in the initial state.
[0058]
Fourth, there is a line indicating the average time spent at the bank of customers who have left the service at the bank. This line has the word “MEAN RESPONSE” in the center. The left element of the left word represents the total staying time of the left customers, and the right element of the left word represents the number of left customers. The word on the right represents the average stay time (floating point number).
[0059]
In the present embodiment, when any of the three words in the line is changed, it is automatically registered and aligned in the four tables to be registered. For example, it is assumed that the right word of the line “customer 1 TRACE TRACE 800 −1” illustrated in FIG. 14 is changed to “800 1200”. In this case, the line “customer 1 TRACE TRACE 800 −1” before the change is the above four tables (TRACE TRACE, H), (TRACE TRACE, M), (customer 1, h), (800 −1 m ) Are all deleted. Then, a new line “customer1 TRACE TRACE 800 1200” is newly registered in the four tables (TRACE TRACE, H), (TRACE TRACE, M), (customer 1, h), and (800 1200, m). In this case, among the four registered tables, the previous three tables are the same as before the change, but the position of the line in the table can be changed.
[0060]
In this embodiment, when searching for a table, the table can be searched by designating it as a table of (x, A). Here, x is a word, and A is any one of H, M, h, and m. FIG. 13 is a table of (customer 1, h). It is also possible to search for a line by designating what line in the table (customer 1, h). Furthermore, a line can be searched according to the content of the line. In the table (customer 1, h), a line whose right word is “sec 350” can be searched. In addition, it is possible to determine where the retrieved line is in the table.
[0061]
Hereinafter, a specific simulation operation in this embodiment will be described.
[0062]
First, the event that occurs next is searched using the databases shown in FIGS. In this case, the next event is described in the top line “sec 1000 FUTURE EVENT AR 0” of the table (FUTURE EVENT, H) representing the events occurring in the future in the time chart in the table shown in FIG. Yes. This line indicates that an arrival event “AR” occurs at time 1000 sec. When the arrival event “AR” occurs at the time 1000 sec, the data shown in FIGS. 9 to 12 is rewritten as follows by this arrival event “AR”.
[0063]
In the arrival event “AR”, the customer having the smallest ID number is searched for among the customers who have not arrived, and the customer arrives at the bank. Lines for customers who have not arrived are registered in a table (COMING IN, H), which is arranged with the left word representing the customer ID number as the sort key. FIG. 22 shows a table (COMING IN, H) representing the unarrived customers in the order of ID numbers. When the top line of this table (COMING IN, H) is searched, the customer 4 is obtained from the left word. Therefore, the customer 4 arrives and is lined up. That is, the state of the customer 4 is rewritten from “COMING IN” to “IN LINE”, and the line “customer 4 COMING IN sec 300” is changed to the line “customer 4 IN LINE sec 300”. As a result, the line “customer 4 COMING IN sec 300” before execution of the arrival event “AR” is deleted from the four tables in which the arrival event “AR” was registered before the arrival event “AR” is executed. "The line" customer 4 IN LINE sec 300 "after execution is registered in the corresponding four tables. The table (IN LINE, H) of FIG. 23 represents customers in the queue in the order of ID numbers after the arrival event “AR” is executed. It can be seen that the customer 4 is added and the customers 2, 3, 4 are arranged in this order.
[0064]
Next, a line related to the tracking information of the customer 4 is searched, and the bank arrival time is recorded. In this case, the tracking information is shown in a table (TRACE TRACE, H). In this table, a line “customer 4 TRACE TRACE −1 −1” is obtained by searching for a line whose left word is “customer 4”. The left element of the right word of this line “customer 4 TRACE TRACE −1 −1” is rewritten from the initial value “−1” to the time value “1000” of this arrival event “AR”, and the line “customer 4 TRACE TRACE” −1 −1 ”is changed to the line“ customer 4 TRACE TRACE 1000 −1 ”. As a result, the line “customer 4 TRACE TRACE −1 −1” before execution of the arrival event “AR” is deleted from the four tables in which the arrival event “AR” was registered before the arrival event “AR” is executed. The line “customer 4 TRACE TRACE 1000 −1” after execution of “AR” is registered in four tables including a table (TRACE TRACE, H) and (TRACE TRACE, M) representing customer tracking information.
[0065]
Subsequently, the central word of the line “sec 1000 FUTURE EVENT AR 0” representing the arrival event “AR” at this time 1000 sec is changed from “FUTURE EVENT” to “PAST EVENT”. As a result, the line “sec 1000 FUTURE EVENT AR 0” before the arrival event “AR” is executed is a table (FUTURE EVENT, H) indicating the events occurring in the future in the order of the customer ID numbers and the events occurring in the future in the order of the event types. The table “FAST EVENT, M” is deleted from the four tables, and the line “sec 1000 PAST EVENT AR 0” after the execution of the arrival event “AR” is newly added to the table (PAST EVENT EVENT) that has occurred in the past. , H), (PAST EVENT, M).
[0066]
FIG. 24 shows the state of the model after execution of the arrival event “AR” at time 1000 sec as described above. FIG. 25 is a table showing all the lines representing the state of the model of FIG. 24. By registering each line in the corresponding four tables, a database consisting of a large number of tables as shown in FIGS. Is created. In the database shown in FIGS. 26 to 29, the event that occurs next is “sec 1200 FUTURE” in the top line of the table (FUTURE EVENT, H) that represents the events occurring in the future in the table shown in FIG. EVENT LV 0 ". This line represents that a retirement event “LV” occurs at time 1200 sec. Then, when the withdrawal event “LV” occurs at the time of 1200 sec, the data shown in FIGS. 26 to 29 is rewritten as follows by this withdrawal event “LV”.
[0067]
In the leaving event “LV”, first, a customer at the window is searched from the table (BEING SERVED, M). In the table (BEING SERVED, M) representing the customers at this window in order of service time, only one line “customer 1 BEING SERVED sec 400” is registered as shown in FIG. From this line, it can be seen that the customer currently at the window is customer 1. Therefore, customer 1 is removed from the bank. That is, in this line “customer 1 BEING SERVED sec 400”, the central word indicating the customer's state is rewritten from “BEING SERVED” to “GONE AWAY”, and the line “customer 1 BEING SERVED sec 400” is changed to line “customer BEING SERVED sec 400”. 1 GONE AWAY sec 400 ". As a result, the line “customer 1 BEING SERVED sec 400” before execution of the leaving event “LV” is deleted from the four tables in which it was registered before the leaving event “LV” is executed, and a new leaving event “LV” is newly created. "The line" customer 1 GONE AWAY sec 400 "after execution is registered in the corresponding four tables.
[0068]
Next, the customer waiting at the head of the line is put into the window. The top line of the table (IN LINE, H) representing the customers in the queue in order of ID number is searched. The top line of this table (IN LINE, H) is a line “customer 2 IN LINE sec 300” as shown in FIG. From this line, it can be seen that the customer who enters the window next is customer 2. Therefore, customer 2 enters the window. That is, in this line “customer 2 IN LINE sec 300”, the central word indicating the customer state is rewritten from “IN LINE” to “BEING SERVED”, and the line “customer 2 IN LINE sec 300” is changed to the line “customer 2 Change to "BEING SERVED sec 300". As a result, the line “customer 2 IN LINE sec 300” before execution of the leaving event “LV” is deleted from the four tables in which it was registered before the leaving event “LV” is executed, and a new leaving event “LV” is newly created. The line “customer 2 BEING SERVED sec 300” after execution is registered in the corresponding four tables.
[0069]
As a result of the operations described above, tables (BEING SERVED, H) and (BEING SERVED, M) representing customers currently at the window, and tables (IN LINE, H) and (IN LINE, H) representing customers in the queue. The contents of M) are changed. Further, as a result of changing the line relating to the customers who have moved out as described above, new tables (GONE AWAY, H) and (GONE AWAY, M) indicating the customers who have moved out are created. FIG. 30 shows three tables (BEING SERVED, H), (IN LINE, H), and (COMING IN, H) representing the state of the customer before the execution of the leaving event “LV” at time 1200 sec. FIG. 31 shows four tables (GONE AWAY, H), (BEING SERVED, H), (IN LINE, H), and (COMING IN) that represent customer states after execution of the leaving event “LV” at time 1200 sec. , H).
[0070]
In the present embodiment, as described above, when the customer 2 newly enters the window, the leaving time when the customer 2 leaves the window is determined by “current time + service time”. That is, it is the time when the next leaving event “LV” occurs. In this example, the leaving time of the customer 2 is changed from “1200 + 300” to 1500 seconds. Since the next retirement event “LV” occurs at 1500 seconds, a new line relating to this event is registered. That is, the line “sec 1500 FUTURE EVENT LV 0” is registered in four tables including a table (FUTURE EVENT, H) and (FUTURE EVENT, M) of events occurring in the future. In addition, the central word of the line “sec 1200 FUTURE EVENT LV 0” representing the leaving event “LV” at time 1200 sec is changed from “FUTURE EVENT” to “PAST EVENT”. As a result, the line “sec 1200 FUTURE EVENT LV 0” before execution of the leaving event “LV” is deleted from the four tables including the table of events (FUTURE EVENT, H) and (FUTURE EVENT, M) that occur in the future, The line “sec 1200 PAST EVENT LV 0” after execution of the leaving event “LV” is newly registered in four tables including a table of events that occurred in the past (PAST EVENT, H) and (PAST EVENT, M). The Then, as a result of the operation as described above, the contents of a table (FUTURE EVENT, H) representing events that occur in the future in time order are as shown in FIG.
[0071]
Further, a line related to the tracking information of the customer 1 is searched and the bank leaving time is recorded. That is, in the table representing the customer tracking information in the order of the customer ID numbers (TRACE TRACE, H), the right element of the right word of the line “customer 1 TRACE TRACE 800 −1” relating to customer 1 is set to the initial value “ -1 ”is rewritten to the time value“ 1200 ”of the leaving event“ LV ”, and the line“ customer 1 TRACE TRACE 800 −1 ”is changed to the line“ customer 1 TRACE TRACE 800 1200 ”. As a result, the line “customer 1 TRACE TRACE 800 −1” before execution of the leaving event “LV” is deleted from the four tables in which it was registered before the leaving event “LV” is executed. The line “customer 1 TRACE TRACE 800 1200” after the execution of “LV” is registered in four tables including a customer tracking information table (TRACE TRACE, H) and (TRACE TRACE, M). As a result of the above operation, the contents of the table (TRACE TRACE, H) representing the customer tracking information in the order of the customer ID numbers are as shown in FIG.
[0072]
FIG. 34 shows the state of the model after execution of the leaving event “LV” at time 1200 sec as described above. FIG. 35 is a table showing all the lines representing the state of the model of FIG. 34. By registering each line in the corresponding four tables, a database comprising a large number of tables as shown in FIGS. Is created.
[0073]
The present invention is not limited to the above embodiment. For example, the number of words constituting one line is not limited to three, and one line can be constituted by four or more words. Conversely, it is also possible to form one line with only two words. Further, the setting contents of the table sorting rule and certain registration conditions related thereto can be freely set. For example, it is possible to use a simple sorting rule that only sorts by a word at a certain position, or conversely, a sorting rule that uses multiple words as sort keys. The contents of can be set as appropriate.
[0074]
More specifically, as a modification of the embodiment, as a table for registering one line composed of three words, in addition to the four tables in the embodiment, a line set in which the left word is the same An embodiment in which the fifth table with the right word as the sort key is made to correspond can be considered. In addition, as a table for registering one line with five words and registering one line, the first table includes a set of lines having the same first word and the second word as a sort key; An implementation that consists of a set of lines in which two words are the same, the second table having the third word as the first sort key, the fourth word as the second sort key, and several other types of tables. Examples are also possible.
[0075]
In the present invention, various means can be used as the sorting means for sorting the lines. For example, a binary search tree that can be sorted, searched, registered, and deleted can be used. Below, this binary search tree is briefly explained.
[0076]
First, define a binary tree and some words. As shown in FIG. 40, the binary tree is composed of nodes (circles) and branches (/ \) indicating the parent-child relationship between the nodes. Each node has a maximum of two child nodes, and a certain one Every node other than a node has only one parent node. The lower left child node is called the left child node, and the lower right child node is called the right child node. The only node that does not have a parent node is called the root node. In FIG. 40, node (1) is a parent node of node (2), and node (2) is a right child node of node (1). Node (3) is the root node of the binary tree. The entire structure under the left (right) child node of a node is called a left (right) subtree. In FIG. 40, subtree (4) is the right subtree of node (1).
[0077]
The binary tree used in the present invention has a target for which a sorting rule is defined, and a node of the binary tree indicates the target (in the above embodiment, a database line), and an arbitrary node of the binary tree is The target object is a binary tree that is larger (smaller) than the target pointed to by any node in the left (right) subtree of the node. Whether to include equal cases on the left or on the right depends on the circumstances in which the binary search tree is used. However, the smaller one is above the table and the larger one is below the table.
[0078]
For example, FIG. 41 is a binary search tree in which integers are sorted. In FIG. 41, for the purpose of simplifying the drawing, an integer that is a target indicated by the node is directly written into the node. In FIG. 41, the integer “54” pointed to by the node (1) is smaller than the integers “60”, “58”, “71”, and “56” indicated by which node of the right subtree (2).
[0079]
FIG. 42 is a flowchart showing an example of a search method using such a binary search tree. For example, when searching for the integer “9” using the binary search tree in FIG. 41 according to this flowchart, the following procedure is performed. This process will be described with reference to FIG. In the following description, N means the current node. First, the root node (3) in FIG. In this case, the integer “9” to be searched is smaller than the integer “46” indicated by N. Therefore, the left child node (4) of N is newly set to N. In this case, the integer “9” to be searched is smaller than the integer “13” indicated by N. Therefore, N left child node (5) is newly set as N. In this case, the integer indicated by N is “9”, and this node is the node for search purposes.
[0080]
FIG. 43 is a flowchart illustrating an example of a registration method using a binary search tree. According to this flowchart, for example, when a node indicating an integer “48” is registered in the binary search tree of FIG. 41, the following procedure is performed. This process will be described with reference to FIG. First, the root node (1) in FIG. In this case, the integer “48” to be registered is larger than the integer “46” indicated by N. Therefore, the right child node (2) of N is newly set as N. In this case, the integer “48” to be registered is smaller than the integer “54” indicated by N. Therefore, the left child node (3) of N is newly set to N. In this case, the integer “48” to be registered is smaller than the integer “49” indicated by N, but since there is no child node to the left of the current node N, the left indicating the integer “48” with N as the parent node A child node (4) is created.
[0081]
FIG. 45 is a flowchart illustrating an example of a deletion method in a binary search tree. With this flowchart, the following processing can be performed. That is, first, when deleting node A, if node A has no child nodes, node A is deleted as it is as shown in FIG. If the node A has only the left (right) child node, the node A is deleted and the left (right) subtree is replaced with the position of the node A as shown in FIG. On the other hand, if node A has both left and right child nodes, as shown in FIG. 48, the node immediately preceding node A in the sort order (this is the rightmost node in the left subtree of node A). ) Is set to N (left state in FIG. 48), node A and node N are switched (operation {circle around (1)} in FIG. 48: left to center state). When the node A does not have a left subtree when switched in this way, the node A is simply deleted. If node A has a left subtree, the left subtree is replaced with the position of node A (operation {circle over (2)} in FIG. 48: center → right).
[0082]
Although it is effective to use such a binary search tree as a sorting means for sorting lines, as described above, as long as sorting, searching, registering, and deleting lines, other sorting means are used. It is possible as well.
[0083]
Subsequently, an implementation example of the function in the database according to the present invention will be described with reference to FIG. In this example, six lines xuw, vxz, wxy, xxx, yxx, ywx are shown in the central portion of FIG. Here, u, v, w, x, y, and z represent different words, respectively. When searching for a line, four different tables corresponding to each word can be used. For example, if the word is x, the four tables are represented by (x, H), (x, M), (x, h), (x, m). These tables are expressed as binary search trees: trees (1) to (4) in FIG. In this case, each node of the tree points to a line and the word that is the sort key for that line. For example, the root node of the tree (1) indicates the line wxy, and further indicates the word w that is the sort key. Conversely, the line also indicates the corresponding node. A line indicated by a node of a tree means that the line is included in a table represented by the tree. For example, in the tree (1) corresponding to the table (x, H), since there is a node indicating the line xxx, the line xxx is included in the table (x, H).
[0084]
In the table (x, H), since the left word is the sort key, each node of the binary search tree representing this table indicates the corresponding line and the left word. That is, each word of each table indicates the corresponding line, and also indicates the right word if (x, M) and the center word if (x, m). For example, the line xxx in FIG. 49 is indicated by four binary search tree nodes representing four tables. Conversely, the line xxx indicates a node indicating the line xxx. That is, by specifying the line xxx, four binary search trees expressing four tables including the line xxx can be found.
[0085]
A method for deleting a line in the database of FIG. 49 having the above structure will be described. When deleting the line xxx from the database, the line xxx is deleted from the four tables (x, H), (x, M), (x, h), and (x, m) including the line xxx. In this case, the node indicating the line xxx of the trees (1) to (4) in FIG. 49 must be deleted. Node deletion follows the procedure described above for the binary search tree. As a result, a database having no line xxx as shown in FIG. 50 is obtained.
[0086]
Conversely, when a line xxx is registered in the database as shown in FIG. 50, each of the four tables (x, H), (x, M), (x, h), and (x, m) is registered. Line xxx must be registered. In this case, a node indicating the line xxx is registered in the trees (1) to (4) corresponding to these four tables. The node registration procedure follows the procedure described above for the binary search tree.
[0087]
Furthermore, a search for an arbitrary line in the database of FIG. 49 can be performed as shown in FIG. FIG. 51 shows an example of a line xx having a word x at the left and center. The procedure for searching one word and searching for the right word is shown. This line xx? Tables that may contain are (x, H), (x, M), (x, h), (x, m). By using a table (x, H) in which the central word is x and the left word is the sort key, the target line can be searched. In FIG. 51, first, when the arrow (1) starting from the word x is traced, the arrow (1) indicates the table (x, H). The lines in this table are stored in the nodes of the binary search tree in order to maintain the sort order. When the arrow (2) is traced from the table (x, H), the root of the binary search tree: tree (3) is indicated. Pointing to the root of a tree is equivalent to pointing to the tree itself. Conversely, the lines in the table (x, H) are instructed from each node of the tree (3).
[0088]
Subsequently, when the arrow (4) is traced from the root of the tree (3), the line indicated by the root node is wxy. In this case, the line wxy and the line xx to be searched? Xx? Is larger (ie below the table, to the right of the tree node). Therefore, the right branch (5) of the root of the tree (3) is lowered and compared with the line yxx indicated by the arrow ahead (6). In this case, xx? Since is smaller, go down the left branch (7). The line indicated by the arrow (8) by the node ahead of the branch (7) is xxx, which corresponds to the line being searched. Thus, a line xx with the word x on the left and center? It can be seen that the word to the right of is x.
[0089]
【The invention's effect】
As described above, in the present invention, by setting a predetermined registration condition indicating the correspondence between a line and a table in advance, a plurality of tables for registering one line based on the registration condition are obtained. Since it can be automatically specified, it is easy to grasp the relationship between a newly registered line or a line whose contents are to be changed and an already registered line. It is possible to provide a database apparatus that can flexibly cope with unexpected usage and is excellent in operability and efficiency.
[Brief description of the drawings]
FIG. 1 shows a database apparatus according to the present invention.Functional block diagram showing an example of basic functional configuration.
FIG. 2 is a flowchart showing an example of a general registration processing procedure of the database apparatus according to the present invention.
FIG. 3 is a flowchart showing an example of a general search processing procedure of the database apparatus according to the present invention.
FIG. 4 is a flowchart showing an example of a general deletion processing procedure of the database apparatus according to the present invention.
FIG. 5 is a flowchart showing an example of a general change processing procedure of the database apparatus according to the present invention.
FIG. 6 is an explanatory diagram showing a procedure of discrete event simulation.
FIG. 7 is a schematic diagram showing one state of a model to be simulated in an embodiment in which a discrete event simulation is performed by the database apparatus of the present invention.
8 is a table showing all lines representing the state of the model in FIG. 7;
9 is a view showing a plurality of tables constituting a part of a database created from the lines in FIG. 8;
FIG. 10 is a view showing a plurality of tables constituting a part of a database created from the lines of FIG. 8;
11 is a view showing a plurality of tables constituting a part of a database created from the lines of FIG. 8;
12 is a view showing a plurality of tables constituting a part of a database created from the lines in FIG. 8;
13 is a view showing one table constituting the database of FIGS. 9 to 12; FIG.
14 is a diagram showing one line constituting the line set of FIG. 13;
FIG. 15 is a table showing four types of words that can be used in the present invention.
16 is a table showing an example of the word in FIG.
17 is a diagram showing one table for registering the lines in FIG. 14;
FIG. 18 is a view showing one table for registering the lines in FIG. 14;
FIG. 19 is a diagram showing one table for registering the lines in FIG. 14;
FIG. 20 is a diagram showing one table for registering the lines in FIG. 14;
21 is a table showing four types of states of customers in the model of FIG.
22 is a table representing unarrived customers in the order of ID numbers among the tables constituting the databases of FIGS.
FIG. 23 is a table showing customers in a queue in the order of ID numbers after arrival event execution by discrete event simulation using the database of FIGS.
24 is a schematic diagram showing a state of the model of FIG. 7 after execution of an arrival event by a discrete event simulation.
FIG. 25 is a table showing all lines representing the state of the model in FIG. 24;
26 is a view showing a plurality of tables constituting a part of a database created from the lines in FIG. 25. FIG.
FIG. 27 is a view showing a plurality of tables constituting a part of a database created from the lines of FIG. 25;
FIG. 28 is a view showing a plurality of tables constituting a part of a database created from the lines of FIG. 25;
FIG. 29 is a view showing a plurality of tables constituting a part of a database created from the lines of FIG. 25;
FIG. 30 is a diagram showing three tables representing customer states before execution of an exit event by a discrete event simulation using the database of FIGS.
FIG. 31 is a diagram showing four tables representing customer states after execution of a leaving event by a discrete event simulation using the databases of FIGS.
FIG. 32 is a view showing the contents of a table representing events occurring in the future in time order after execution of a leaving event by discrete event simulation using the database of FIGS. 26 to 29;
FIG. 33 is a diagram showing the contents of a table representing customer tracking information in the order of customer ID numbers at the time after execution of an exit event by a discrete event simulation using the databases of FIGS. 26 to 29;
FIG. 34 is a diagram showing a state of the model of FIG. 24 after execution of a leaving event by a discrete event simulation.
35 is a table showing all lines representing the state of the model in FIG. 34;
FIG. 36 is a diagram showing a plurality of tables that constitute a part of a database created from the lines in FIG. 35;
FIG. 37 is a view showing a plurality of tables constituting a part of a database created from the lines in FIG. 35;
38 is a view showing a plurality of tables constituting a part of a database created from the lines in FIG. 35. FIG.
FIG. 39 is a diagram showing a plurality of tables that constitute a part of a database created from the lines in FIG. 35;
FIG. 40 is a diagram showing an example of a binary search tree that can be used as sorting means in the database apparatus according to the present invention.
FIG. 41 is a diagram showing an example of a binary search tree in which integers are sorted.
FIG. 42 is a flowchart illustrating an example of a search method using a binary search tree.
FIG. 43 is a flowchart showing an example of a registration method in a binary search tree.
44 is a diagram showing a procedure for registering a new node and a binary search tree in which a new node is registered with respect to the binary search tree in FIG. 41;
FIG. 45 is a flowchart showing an example of a deletion method in a binary search tree.
46 is an explanatory diagram showing an example of a deletion operation by the method of FIG. 45. FIG.
47 is an explanatory diagram showing an example of a deletion operation by the method of FIG. 45. FIG.
48 is an explanatory diagram showing an example of a deletion operation by the method of FIG. 45. FIG.
FIG. 49 is an explanatory diagram showing an example of a database in which functions are implemented according to the present invention.
50 is an explanatory diagram showing a database obtained by deleting one line from the database of FIG. 49. FIG.
51 is an explanatory diagram showing a search procedure for an arbitrary line in the database shown in FIG. 49;
FIG. 52 is a table showing an example of relations registered in the database.
FIG. 53 is a table showing an example of relations registered in the database.
[Explanation of symbols]
1 ... Input means
2. Storage means
3 ... Table designation means
4 ... Management means
5. Registration means
6 ... Sort means
7 ... Search means
8 ... Deletion means
9. Output means
10 ... Table creation means

Claims (2)

A database device in which lines configured by arranging a plurality of words indicating a single type or a plurality of types of values selected from character strings, integers, and floating-point numbers in order are registered in a plurality of tables. In
  For each table, a word condition of registering a line having a specific value as a word for a determination position selected from a plurality of rank positions in an input line, and the above-mentioned among the plurality of rank positions A management means for managing registration conditions of a plurality of tables defined by table information including a sorting rule of sorting by a word value at a sorting position selected separately from the position for determination;
  A table designating unit for designating a plurality of tables for registering the input lines based on the registration conditions of the table;
  Sort means for sorting the lines registered in the table on each table based on the value of the word at the rank position specified by the sorting rule set in each table;
  Retrieval means for retrieving lines on each table designated by the table designation means based on the order sorted by the sorting means,
A database apparatus comprising: The registration condition of the table for registering a line composed of three words is:
  For the three rank positions of the three words constituting the line, one position selected from the three rank positions is defined as the first position, and the remaining two positions are the second and second positions. If defined as position 3
  One line composed of the three words is
  The first position is the position for determination, the value of the word at this position has the same value as the word at the corresponding position of the line, and the second position is the position for sorting. A first table,
  The first position is the position for determination, the value of the word at this position has the same value as the word at the corresponding position of the line, and the third position is the position for sorting. A second table,
  The second position is the position for determination, the value of the word at this position has the same value as the word at the corresponding position on the line, and the first position is the position for sorting. A third table,
  The third position is the position for determination, the value of the word at this position has the same value as the word at the corresponding position of the line, and the first position is the position for sorting. A fourth table,
Stipulate that each of the four tables is registered.
The database apparatus according to claim 1.

Images