(57)【要約】【目的】本件発明は、リレーショナル・データベースの構造を解析して、ＳＱＬ式で参照するテーブル群の結合に必要な参照整合性制約を自動的に確保すること、ならびに集合と位相の論理によって、データ・ディクショナリーに保持する情報のみで、利用目的の位相特性を解釈して、利用目的に応じたＳＱＬ構文を構成し、利用目的性制約を確保したＳＱＬ式を自動的に作成する方法を提供することが目的である。【効果】従来の技術が、参照整合性制約と利用目的性制約を確保するために、クラス・オブジェクトの管理、保守、保持に多大の労力とコンピュータ資源を要し、リレーショナル・データベースが保持する管理情報と、二元的に管理することの問題点解決し、これらの工程に要する人的資源をはじめとして、ハードウェア資源、ソフトウェア資源を大幅に削減する効果がある。【選択図】  図３
2004355416.tif 000002
【特許請求の範囲】
【請求項１】
本発明は、ＳＱＬリレーショナル・データベース管理システム・プログラムと、ＲＤＢＭＳの応用プログラムとの中間に位置する、本発明の「解釈処理プログラム」において、応用プログラムが発行する利用目的の位相特性を表象した非手順型の命令を、「解釈処理プログラム」が集合と位相と記号論理により、利用目的の位相特性を解釈して、ＳＱＬリレーショナル・データベース管理システム・プログラムに対して、その利用目的の位相特性に応じたＳＱＬ指令を、実行時に自動的に発行する方法で、
（１）  ＳＱＬリレーショナル・データベース管理システムが管理保持するデータ・ディクショナリー情報を取得し、リレーショナル・データベースの構造を解析する、リレーショナル・データベース構造解析工程と、
（２）  リレーショナル・データベースの参照整合性を確保する制約条件を構成する、参照整合性制約構成工程と、
（３）  利用目的に応じた項目を組み合わせたデータ検索結果行列に、前記の参照整合性制約を自動的に付与する、参照整合データ行列構成工程と、
（４）  集合と位相における集合の計量空間を「位相空間オブジェクト」と呼ぶ対象とし、利用目的の位相特性に応じて複数個の位相空間オブジェクトを生成登録する、位相空間オブジェクト生成登録工程と、
（５）  複数個の位相空間オブジェクトの中から、利用目的の位相特性に応じた位相空間オブジェクトを選択する、位相空間オブジェクト選択工程と、
（６）  選択した位相空間オブジェクトにおいて、利用目的の検索標識の条件を満足する集合の量を「位相集合オブジェクト」と呼ぶ対象とし、位相空間オブジェクトの下に生成登録する位相集合オブジェクト生成登録工程と、
（７）  位相空間オブジェクト、位相集合オブジェクトを生成登録する処理目的の、利用目的の検索標識の条件式を「検索標識条件オブジェクト」と呼ぶ対象として生成登録する工程と、ＳＱＬ集計関数やＲＤＢＭＳが提供する関数機能を用いた函数を「ＳＱＬ函数オブジェクト」と呼ぶ対象として生成登録する工程と、ならびに参照整合データ行列構成工程により構成したデータ検索結果行列の構成を「データ行列オブジェクト」と呼ぶ対象として生成登録する工程の、位相特性クラス・オブジェクト生成登録工程と、
（８）  位相空間オブジェクト条件式、位相集合オブジェクト条件式、データ行列オブジェクト式および、それらのオブジェクトに用いた検索標識条件オブジェクト式、ＳＱＬ函数オブジェクト式が参照するテーブル群の結合関係を解析して、それらの式に最適な結合順路を探索する、位相特性ＳＱＬ結合順路探索工程と、
（９）  参照テーブル群に最適な結合順路から利用目的の位相特性に応じたＳＱＬ構文を構成する、位相特性ＳＱＬ構文構成工程と、
（１０）  参照テーブル群の結合に必要な参照整合性制約と、利用目的の位相特性に応じたＳＱＬ構文構成から、ＳＱＬリレーショナル・データベース管理システムに発行するＳＱＬ指令を記号論理により自動生成する、位相特性ＳＱＬ指令自動生成工程と、を備えたリレーショナル・データベース検索処理方法に関する。
【請求項２】
本件発明者の特許第３３１８８４４号の請求項１の（ｂ）に記載がある、集合描画工程により描画された集合の図式を視認することによって、利用目的の位相特性に応じた結果の集合であることを確認し、その集合に応じた結果の検索結果行列をもたらすことにより、利用目的の位相特性がリレーショナル・データベース構造設計時の利用目的の位相特性と矛盾しないことを検証する過程がある、利用時点における利用目的の位相特性を検証することが可能である概念を有することを特徴とする、本件発明の請求項１記載のリレーショナル・データベース検索処理方法に関する。
【請求項３】
リレーショナル・データベース構造設計時の利用目的の位相特性と、応用処理時の利用目的の位相特性との一貫性を保証する概念を有することを特徴とする、本件発明の請求項２記載のリレーショナル・データベース検索処理方法に関する。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
利用形態は、ＳＱＬリレーショナル・データベース管理システム・プログラム（以下、”ＲＤＢＭＳ”と記す）の動作するデータベース・サーバー・システムと、ＲＤＢＭＳの応用プログラム（以下、”ＡＰ”と記す）の動作するクライアント・システムで構成する、クライアント・サーバー型システム構成で、またはＲＤＢＭＳとＡＰが単一のコンピュータ・システム上で動作するスタンドアロン型システム構成での利用が可能で、データベース・システムの構成形態は問わない。
本件発明の「解釈処理プログラム」（以下、”ＩＮＴＥＲＰＲＥＴＥＲ”と記す）は、データベース・サーバー・システムに置くことも、クライアント・システムに置くことも可能である。
グラフィック・ユーザ・インタフェースを介した会話型データベース検索処理は、グラフィック・ディスプレイ装置、キーボード装置、マウスなどの指示装置を具備したパーソナル・コンピュータ・システム、またはワークステーション・コンピュータ・システムを用い、本件発明者の特許第３３１８８４４号に記載する「集合の図式化によるデータベース検索処理方法」のユーザ・インタフェース（以下、「集合グラフ・インタフェース」と記す）を実装する、【図１】に示す構成のシステムで用いる。
利用分野は、ＲＤＢＭＳを用いるあらゆる産業の会話型データベース検索処理に適用可能である。
【０００２】
【従来の技術】
本件請求の解説では、Ｃ．  Ｊ．  Ｄａｔｅ著、”Ａｎ  Ｉｎｔｒｏｄｕｃｔｉｏｎ  ｔｏ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍｓ  −  Ｔｈｉｒｄ  Ｅｄｉｔｉｏｎ”に記載がある、以下に記すリレーショナル・データベースの定義とデータを引用する。
2004355416.tif 000003
2004355416.tif 000004
【０００３】
次に解決しなければならない課題を考察する。
参照整合性制約の課題；（Ｒｅｆｅｒｅｎｔｉａｌ  ｉｎｔｅｇｒｉｔｙ  ｃｏｎｓｔｒａｉｎｔ）
参照整合性制約は、リレーショナル論理代数（Ｒｅｌａｔｉｏｎａｌ  Ａｌｇｅｂｒａ）において、リレーション（ＳＱＬ：  ＴＡＢＬＥ  以下、”ＴＡＢＬＥ”と記す）と、リレーションのアトリビュート（ＳＱＬ：  ＣＯＬＵＭＮ  以下、”ＣＯＬＵＭＮ”と記す）を組み合わせてタプル（ＳＱＬ：  ＲＯＷ  以下、”ＲＯＷ”と記す）を構成する工程において、ＴＡＢＬＥ    ”Ａ”のＣＯＬＵＭＮ  ”ａ”と、ＴＡＢＬＥ  ”Ｂ”のＣＯＬＵＭＮ  ”ｂ”に存在する値が同値である制約条件とするＲＯＷの領域に限定する制約である。ＴＡＢＬＥ  ”Ａ”のＣＯＬＵＭＮ  ”ａ”の値とＴＡＢＬＥ  ”Ｂ”のＣＯＬＵＭＮ  ”ｂ”  の値との関係は、”Ａ”の１個の値が”Ｂ”のｍ個の値とが同値である場合、または”Ａ”のｎの値が”Ｂ”のｍ個の値と同値である場合の対応関係がある。このときに、ＴＡＢＬＥ  ”Ａ”を主とし、ＴＡＢＬＥ  ”Ｂ”を従とする結合関係（ＳＱＬ：  ＪＯＩＮ  以下、”ＪＯＩＮ”と記す）が存在するとし、ＴＡＢＬＥ  ”Ａ”のＣＯＬＵＭＮ  ”ａ”をＰｒｉｍａｒｙ  ｋｅｙ（以下、”ＰＫ”と記す）と呼称し、ＴＡＢＬＥ  ”Ｂ”のＣＯＬＵＭＮ  ”ｂ”をＦｏｒｅｉｇｎ  Ｋｅｙ（以下、”ＦＫ”と記す）と呼称する結合属性（以下、”ＪＯＩＮ”と記す）が定義される。
引用するデータベースでは、ＴＡＢＬＥ  ”Ｓ”のＣＯＬＵＭＮ  ”Ｓ．Ｓ＃”，  ”Ｓ．ＳＮＡＭＥ”とＴＡＢＬＥ    ”Ｐ”のＣＯＬＵＭＮ  ”Ｐ．Ｐ＃”，  ”Ｐ．ＰＮＡＭＥ”のＲＯＷを読むＳＱＬ式を記述するときに、ＴＡＢＬＥ  ”Ｓ”とＴＡＢＬＥ  ”Ｐ”は、ＴＡＢＬＥ  ”ＳＰ”のＣＯＬＵＭＮ  ”Ｓ．Ｓ＃”と”Ｐ．Ｐ＃”の対応表で参照性を有した関係を、ＷＨＥＲＥ句に”Ｓ．Ｓ＃  ＝  ＳＰ．Ｓ＃  ＡＮＤ  Ｐ．Ｐ＃  ＝  ＳＰ．Ｐ＃”と同値条件を記述をして参照整合性制約を確保したＲＯＷを読むために、以下に記す【ＳＱＬ式１】を記述する課題である。
【ＳＱＬ式１】
2004355416.tif 000005
【ＳＱＬ式１】の実行結果のＲＯＷ；
2004355416.tif 000006
これに対して、ＷＨＥＲＥ句に参照整合性を制約する同値条件を記述しない
【ＳＱＬ式２】は、ＴＡＢＬＥ  ”Ｓ”のすべての値と、ＴＡＢＬＥ  ”Ｐ”のすべての値との組み合わせ順列のＲＯＷが出現する直積（Ｃａｒｔｅｓｉａｎ  ｐｒｏｄｕｃｔ）が生じ、現実に存在しないデータを含むＲＯＷを読む結果となる。
【ＳＱＬ式２】
2004355416.tif 000007
【ＳＱＬ式２】の実行結果のＲＯＷ；
2004355416.tif 000008
2004355416.tif 000009
【０００４】
ユーザが目的とする検索標識条件（Ｓｅａｒｃｈ  ｃｒｉｔｅｒｉａ）を与えて、条件を満足するＲＯＷを読む処理を実行するときに、２つの条件を与えなければならない。
第１の条件は検索標識条件で、目的のＣＯＬＵＭＮに存在する値を評価する、ＣＯＬＵＭＮと関係演算子と値とで構成する条件式である。第２の条件は参照整合性制約条件で、目的のＲＯＷを構成するための参照整合性を確保するための制約条件式である。リレーショナル・データベースの論理代数概念においては、ＴＡＢＬＥ  ”Ｓ”のＣＯＬＵＭＮ  ”Ｓ．Ｓ＃”とＴＡＢＬＥ    ”Ｐ”のＣＯＬＵＭＮ  ”Ｐ．Ｐ＃”がＴＡＢＬＥ  ”ＳＰ”のＣＯＬＵＭＮ  ”Ｓ．Ｓ＃”と”Ｐ．Ｐ＃”の対応表によって合致したＲＯＷが存在することを評価して、その結果のＲＯＷに対して、検索標識条件を評価する。
ＡＰの処理ロジックを作成過程のプログラム開発者の思考、またはターミナルの操作過程のターミナル・ユーザ（以下、”ＴＵ”と記す）の思考において、検索標識条件は明示的であるが、参照整合性制約条件は暗示的であり、これらのデータベース・ユーザにとって、参照整合性制約条件は演繹的な課題であるので、「ＳＱＬは難しい」、「わかり難い」とされる。
参照整合性制約を確保することは、ＲＤＢＭＳの応用プログラムによって解決しなければならない課題である。
【０００５】
利用整合性制約の課題；（Ｕｓｅｒ−ｄｅｆｉｎｅｄ  ｉｎｔｅｇｒｉｔｙ  ｃｏｎｓｔｒａｉｎｔ）
利用整合性制約は、ＴＵのアクション、ＡＰまたは時刻（ｄａｔｅ−ｔｉｍｅ）の到来をタイミングとしてテストする条件などである。
タイミングは、ＴＡＢＬＥ  ”Ｓ”のＣＯＬＵＭＮ  ”Ｓ．ＳＮＡＭＥ”の値を追加しようとするタイミングには、予めＣＯＬＵＭＮ  ”Ｓ．Ｓ＃”の値が存在しなければならない、とする「時点制約」（以下、”ＴＣ”と記す）と、ＴＡＢＬＥ  ”Ｓ”の”Ｓ．ＳＮＡＭＥ”、”Ｓ．ＳＴＡＴＵＳ”、”Ｓ．ＣＩＴＹ”の値を一括して追加しなければならない、とする「トランザクション制約」（以下、”ＴＴ”と記す）である。
ＴＣとＴＴの制約は、データベース設計者またはデータベース管理者（以下、”ＤＢＡ”と記す）が、予めＴＡＢＬＥに対してＳＱＬ指令のＣＨＥＣＫ、ＣＡＳＣＡＤＥなどの制約記述文（Ｃｏｎｓｔｒａｉｎｔｓ  Ｓｔａｔｅｍｅｎｔ）により設定することが可能である。これらの予め設定された利用整合性制約に違反する処理に対しては、異常を通知することが可能であり、応用プログラム処理のＲＤＢＭＳ処理に対する実行時の利用整合性制約と言う。
利用整合性制約を確保することは、ＲＤＢＭＳの管理と運用によって解決することが可能な課題である。
【０００６】
利用目的性制約の課題；（Ｓｃｏｐｅ；  Ｂｕｓｉｎｅｓｓ−ｒｕｌｅ  ｉｎｔｅｇｒｉｔｙ  ｃｏｎｓｔｒａｉｎｔ）
特定の利用目的における、データの読込、追加、更新、削除の領域（Ｓｃｏｐｅ）に対する意味論上の制約が必要である。
いわゆる「ビジネス・ルール」と言われる利用目的の位相特性で、ＡＰの処理ロジックまたはＴＵの操作意図によって、同じＣＯＬＵＭＮの組み合わせから構成されるＲＯＷに対して、同じ検索標識条件を与えた場合でも、ＳＱＬ指令の構文が異なり、あるべきデータがあり、あるべからざるデータがない、利用目的の位相特性に応じた適切なＲＯＷを得るための制約を言う。
利用目的の検索標識条件（Ｓｅａｒｃｈ  ｃｒｉｔｅｒｉａ）を評価する方法に２種類のＳＱＬ構文がある。
ＴＡＢＬＥ  ”Ｓ”に対して、”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”と条件を与えて、重複のない（Ｄｉｓｔｉｎｃｔ）”Ｓ．Ｓ＃，  Ｓ．ＳＮＡＭＥ，  Ｓ．ＳＴＡＴＵＳ，  Ｐ．Ｐ＃，  Ｐ．ＰＮＡＭＥ，  Ｐ．ＣＯＬＯＲ”のＲＯＷを読むＳＱＬ式は、以下の【ＳＱＬ式３】に記す、検索標識条件式と参照整合性制約条件式をＡＮＤで連結したものである。
【ＳＱＬ式３】
2004355416.tif 000010
”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”を満足したＳ．Ｓ＃はＳ１，  Ｓ４  である。ＳＰの対応表で、Ｓ１はＰ１からＰ６に、Ｓ４はＰ２，  Ｐ４，  Ｐ５に対応する。この結果、以下に示すＲＯＷを読む。
【ＳＱＬ式３】の実行結果のＲＯＷ；
2004355416.tif 000011
これに対して、ＴＡＢＬＥ  ”Ｐ”に対して、”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”と条件を与えて、重複のない”Ｓ．Ｓ＃，  Ｓ．ＳＮＡＭＥ，  Ｓ．ＳＴＡＴＵＳ，  Ｐ．Ｐ＃，  Ｐ．ＰＮＡＭＥ，  Ｐ．ＣＯＬＯＲ”のＲＯＷを読むＳＱＬ式は、
以下の【ＳＱＬ式４】に記す、検索標識条件と、その検索標識条件の参照整合性制約条件をＡＮＤで連結したＳｕｂＱｕｅｒｙを実行してＰ．Ｐ＃を求め、その結果のＰ．Ｐ＃の値に該当（ＩＮ）するＲＯＷを読むための参照整合性制約条件とＳｕｂＱｕｅｒｙ  をＡＮＤで連結したものである。
【ＳＱＬ式４】
2004355416.tif 000012
”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”を満足したＳ．Ｓ＃はＳ１，  Ｓ４  である。ＳＰの対応表で、Ｓ１はＰ１からＰ６に、Ｓ４はＰ２，  Ｐ４，  Ｐ５に対応する。ＳＰの対応表で、Ｐ１はＳ２に、Ｐ２はＳ２，  Ｓ３，  Ｓ４に対応するので、ＳｕｂＱｕｅｒｙの結果はＰ１からＰ６である。この結果、主Ｑｕｅｒｙは以下に示すＲＯＷを得る。
【ＳＱＬ式４】の実行結果のＲＯＷ；
2004355416.tif 000013
【０００７】
【ＳＱＬ式３】は、”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”の製品のＳｕｐｐｌｉｅｒの観点で、製品のビジネス・ルールに着目し、部品一覧ＲＯＷを読む利用目的の位相特性を反映したものである。
【ＳＱＬ式４】は、”Ｓ．ＳＴＡＴＵＳ  ＝  ２０”の製品に使用される部品のＳｕｐｐｌｉｅｒの観点で、製品のビジネス・ルールに着目し、部品一覧ＲＯＷを読む利用目的の位相特性を反映したものである。
ＡＰとＴＵの利用目的の特性は、ＲＤＢＭＳがＡＰの処理ロジックまたはＴＵの意図を察知することが不可能で、ＡＰとＴＵが自ら制約を、事前に付与しなければならないので、ＲＤＢＭＳ処理における応用プログラム処理の事前の利用目的性制約と言うことができる。
【０００８】
一貫性制約の課題；（Ｃｏｎｓｉｓｔｅｎｃｙ  ｃｏｎｓｔｒａｉｎｔ）
リレーショナル・データベースの概念における正規化は、さまざまなの状況、時点における利用目的の位相特性を高度に抽象化、統合化することから、リレーション（ＴＡＢＬＥ）が細分化される。
この結果、個々の応用処理における利用目的の位相特性においては、リレーション間の結合に複雑な参照整合性制約必要となるために、一般のエンド・ユーザは言うに及ばず、プログラマーなどの開発者にとっても、その構造が複雑で理解しがたいものとなる。
従って、リレーショナル・データベースの設計においては、正規化の概念を忠実に履行することと、応用処理における利用性を考慮してある程度非正規のリレーションを許容しなければならないこと、との矛盾の中で、妥協による解決を図らなければならず、データベースの一貫性を損なう可能性があることが課題である。
【０００９】
次に、参照整合性制約と利用目的性制約の解決を図る、従来の技術を要約する。
ＳＱＬリレーショナル・データベース管理システムの制約モデル；
ＲＤＢＭＳのビュー（ＳＱＬ：  ＶＩＥＷ  以下、”ＶＩＥＷ”と記す）は、複数のＴＡＢＬＥのＣＯＬＵＭＮから構成するＲＯＷの参照整合性制約を保持したＳＱＬ式で、利用目的に応じて作成して事前にＲＤＢＭＳの定義としてＲＤＢＭＳのデータ・ディクショナリー（以下、”ＲＤＢ／ＤＤ”と記す）に登録することで、参照整合性制約を解決した、仮想のＴＡＢＬＥを規定する。
ＶＩＥＷのＳＱＬ式は、ＲＯＷの範囲を限定する検索標識条件を設定することが可能であり、ある程度、利用目的性制約機能を果たすと考えられるが、利用目的に応じたＶＩＥＷを個別に設定して登録する必要があるとともに、ＶＩＥＷに対する更新処理において、実用のＲＤＢＭＳで未解決な問題があるために、利用目的性制約を解決する機能を完全に果たし得ない。
【００１０】
クラス・オブジェクトによる制約モデル；
ＲＤＢＭＳに対してＡＰが発行するＳＱＬ指令の参照整合性制約と利用目的性制約を記述したクラス・オブジェクトを事前に登録し（ＲＤＢＭＳの定義ではない）、ＡＰは、このクラス・オブジェクトを用いて応用処理する方法がある。
以下にその方法を要約して述べる。
【００１１】
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ；
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓは、フランスの企業Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ  Ｓ．Ａ  が考案し、米国特許を取得した方法（Ｕ．Ｓ．  Ｐｔｅｎｔ  Ｎｕｍｂｅｒ  ５，５５５，４０３  ａｎｄ  ６，２４７，００８）で、各々の利用目的の位相特性に対応して、処理ロジックのある個別のＳＱＬ式を保持したクラスを作成し、オブジェクトとして登録保持する、と特許請求した方法である。
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ  Ｕｎｉｖｅｒｓｅｓ；
ユニヴァース（Ｕｎｉｖｅｒｓｅ）と呼ぶ、ユーザやグループの特定の利用目的の位相特性に応じて作成するオブジェクトを定義する。ユニヴァースは、論理的なクラス・オブジェクトの集まりで、Ｃｌａｓｓｅｓ−ユーザが理解可能に命名されたユニヴァース固有の変数名の検索結果ＲＯＷと、Ｊｏｉｎｓ−ユニヴァース（全部）の参照整合性制約と、Ｃｏｎｔｅｘｔｓ−管理者が設定した各々の参照整合性制約記述とを保持する。ユニヴァースは、ＲＤＢＭＳとは別の、Ｕｎｉｖｅｒｓｅｓ  Ｄｉｃｔｉｏｎａｒｙと呼ぶ外部記憶域に保存される。クラス・オブジェクト（Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ）の作成登録は、事前の処理で、グラフィック・ユーザ・インタフェースを用いて実施する。
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ  Ｑｕｅｒｙ  Ｅｎｇｉｎｅ；
検索エンジン（Ｑｕｅｒｙ  Ｅｎｇｉｎｅ）は、ユニヴァースに対応して、検索結果のＲＯＷと検索標識条件（Ｓｅａｒｃｈ  ｃｒｉｔｅｒｉａ）とＳｏｒｔ条件、Ｇｒｏｕｐ条件との組み合わせに対応したＳＱＬ式を自動生成する。
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓエンド・ユーザの利用方法；
エンド・ユーザは、検索結果のＲＯＷを、ＣＯＬＵＭＮ一覧表から任意のＣＯＬＵＭＮをドラッグして結果表示域のウィンドウにドロップする方法で構成する。検索標識条件は、条件式を設定するダイアログ・ウィンドウで、ＣＯＬＵＭＮ、関係演算子、条件値を入力して作成する。また、ＳＯＲＴやＧＲＯＵＰのオプションを指定する。
この結果、Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ  Ｑｕｅｒｙ  Ｅｎｇｉｎｅは、ＳＥＬＥＣＴ、ＷＨＥＲＥ、ＳＯＲＴ、ＧＲＯＵＰ句の構成要素であるＣＯＬＵＭＮを認識し、ＣＯＬＵＭＮを含むＴＥＢＬＥ群を確定して、予めユニヴァースに登録された参照整合性制約記述（Ｃｏｎｔｅｘｔ）を組み合わせて、ＳＱＬ式を自動生成することが可能である。ＳＱＬ式に記述する参照整合性制約は、ＰＫとＦＫの同値条件とし、複数の参照整合性制約条件はすべてＡＮＤで結合してＷＨＥＲＥ句に記述するか、もしくは、利用処理に記述されたＣＯＬＵＭＮの内容によらず、グローバル・リストと呼ぶＪＯＩＮのクラス・オブジェクトを用いて、参照整合性制約条件をＷＨＥＲＥ句に記述する。
Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓは、処理目的に対応した個別のクラス・オブジェクトを作成保持し、処理目的の位相特性に対応した検索結果ＲＯＷを得ることができ、ＡＰの処理ロジックまたはＴＵの意図は、このビジネス・クラス・オブジェクトを使用することで規定され、エンド・ユーザが、ＳＱＬ式を作成する困難がなく、直接データベースと会話型検索処理を行うことが可能である、と特許請求するものである。
【００１２】
ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔならびにその派生方式；
ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔは、利用目的の処理に対応した個別のクラス・オブジェクトと、ＳＱＬとのインタフェースを規定したクラス・オブジェクトを分離して保持し、利用のパターンからそれらのクラス・オブジェクトを組み合わせるために共有管理する方式である。
ＣｌａｓｓＭａｐ；
ＣｌａｓｓＭａｐは、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）がＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）に規定したもので、ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔのビジネス・ルールを規定したクラス・オブジェクトのみを用い、リレーショナル・データベースの参照整合性制約や利用整合性制約を記述したＲｅｌａｔｉｏｎａｌＤａｔａｂａｓｅクラス・オブジェクトとの対応付けを記述したクラス・オブジェクトである。
Ｂｒｏｋｅｒ；
Ｂｒｏｋｅｒは、ＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）の規定したクラス・オブジェクトで、検索標識条件を保持するＣｒｉｔｅｒｉａクラス・オブジェクトと協調して、参照整合性制約や利用整合性制約を保有するメタ・データ・ディクショナリーの役割を果たす。
ＣｌａｓｓＭａｐクラス・オブジェクトとＲｅｌａｔｉｏｎａｌＤａｔａｂａｓｅクラス・オブジェクトは、Ｂｒｏｋｅｒクラス・オブジェクトによって協調することが可能となる。
【００１３】
これらのＢｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔｓ、ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔならびにその派生方式のクラス・オブジェクトによる、従来の参照性合成制約、利用目的性制約モデルは、いずれも事前に、処理目的に応じたクラス・オブジェクトを作成して登録保持することを必要とするものである。
【００１４】
【発明が解決しようとする課題】
ＳＱＬリレーショナル・データベース管理システムの参照整合性制約と利用目的性制約モデルは、ＲＤＢＭＳ処理における応用プログラム処理の事前の利用目的性制約を完全に規定することができないので、利用目的に応じたクラス・オブジェクトを規定する利用目的性制約モデルが出現したと考えられる。
クラス・オブジェクトによる参照整合性制約と利用目的性制約モデルは、完全を期することは可能であるが、クラス・オブジェクトの管理、保守、保持に多大の労力とコンピュータ資源を要し、リレーショナル・データベースが保持する管理情報と、二元的に管理することの問題点が指摘されている。
管理における二元性の問題のみならず、リレーショナル・データベースの構造によって規定された利用の目的、意味論と、個別に規定され、作成されるクラス・オブジェクトの目的、意味論との間に差異が生じる可能性がある。
規定の数が複数あり、それぞれの規定を定義する機会が増加するに従って、その規定自体に瑕疵を内包する可能性が増加し、規定相互間の矛盾を内包する可能性が増加する。
瑕疵も矛盾もない完全なクラス・オブジェクトを作成し保持することも、それを完全に利用し運用することも、いずれも人的な能力と管理に依存するものであるので、不完全性を内包するものである。
【００１５】
従って、本件発明が解決しようとする第１の課題は、参照整合性制約と利用目的性制約のために、クラス・オブジェクトの管理、保守、保持に多大の労力とコンピュータ資源を要し、リレーショナル・データベースが保持する管理情報と、二元的に管理することの問題点の課題と、完全なクラス・オブジェクトを作成し保持することも、それを完全に利用し運用することも、いずれも人的な能力と管理に依存するものであるので、不完全性を内包することの課題を解決し、利用目的の位相特性の一貫性を保証することが可能な方法を実現し、リレーショナル・データベースの参照性合成制約と利用目的性制約を効果的に確保することである。第２の課題は、リレーショナル・データベースの設計において、正規化の概念を忠実に履行するために、個々の利用目的の応用処理において、リレーション間の結合に必要な参照整合性制約の課題を自動的に解決し、プログラマーなどの開発者のみならず、一般ユーザにとっても、複雑な構造を意識することなく、どのように情報を取り出すかを思い煩うことなく、どの情報を読むかに集中することが可能な方法を実現し、リレーショナル・データベース構造設計時の利用目的の位相特性と、応用処理時の利用目的の位相特性との一貫性を保証することである。
【００１６】
【課題を解決するための手段】
整合性の前提；
リレーショナル・データベースは、正規化されているものとする。正規化されたリレーショナル・データベースの構造は、利用目的性制約を表象する、とする。応用プログラム処理のＲＤＢＭＳ処理に対する実行時の利用整合性制約、ＴＣとＴＴの制約は、ＤＢＡが予めＣＨＥＣＫ、ＣＡＳＣＡＤＥなどのＳＱＬ制約記述文（Ｃｏｎｓｔｒａｉｎｔｓ  Ｓｔａｔｅｍｅｎｔ）により設定し、上記の利用目的性制約の一貫性を保証する、とする。
これらのリレーショナル・データベースの利用整合性制約機能は、とかく複雑であるとか、理解が困難などの理由から敬遠され、プログラムの処理ロジックやクラス・オブジェクトに規定することで解決する方法が選択された。複雑さや理解が困難という課題に対しては、簡便で矛盾のない制約記述を与えるためのユーザ・インタフェースを具備したツールを提供することで、利用整合性制約の課題を解決する。
【００１７】
正規化されたリレーショナル・データベース；
本件発明は、リレーショナル・データベースが正規化されており、応用プログラム処理のＲＤＢＭＳ処理に対する利用整合性制約規定が厳格に定義されたＳＱＬリレーショナル・データベースで、その構造が利用目的性制約を表象していることを前提とする。
【００１８】
参照整合性制約の課題を解決するための方法；
整合性の前提が成立する場合に、リレーショナル・データベースに対する検索を記述するＳＱＬ式を自動的に作成する方法で、ＳＱＬ式が参照するＴＡＢＬＥの参照整合性制約（Ｒｅｆｅｒｅｎｔｉａｌ  ｉｎｔｅｇｒｉｔｙ  ｃｏｎｓｔｒａｉｎｔ）を、事前にクラス・オブジェクトを登録保持することなく、実行時（ｏｎ−ｔｈｅ−ｆｌｙ）に自動的に作成することが可能である。
リレーショナル・データベースの利用目的において、関連付けて参照しなければならないＴＡＢＬＥ群のＴＡＢＬＥ間には、必然的にＰＫとＦＫのＪＯＩＮが定義される。直接的に結合関係がない場合でも、中間に共通の結合関係のあるＴＡＢＬＥを経由して関係付けられる。
従って、ＲＤＢＭＳのデータ・ディクショナリーが保持する主ＴＡＢＬＥのＰＫと従ＴＡＢＬＥのＦＫによるＪＯＩＮ定義を解析することによって、それらの結合関係を認識し、実行時にＷＨＥＲＥ句に同値条件式を付与するか、もしくは以下に記す、ＩＳＯ／ＩＥＣ  ９０７５：１９９２に規定された、参照整合性制約指令をＦＲＯＭ句に付与する工程により、ＳＱＬ式を自動的に生成することが可能である。
ＩＳＯ／ＩＥＣ  ９０７５：１９９２参照整合性制約指令；
１．  ＣＲＯＳＳ＿ＪＯＩＮ
２．  ＥＸＣＥＰＴ＿ＪＯＩＮ
３．  ＦＵＬＬ＿ＯＵＴＥＲ＿ＪＯＩＮ
４．  ＩＮＮＥＲ＿ＪＯＩＮ
５．  ＩＮＴＥＲＳＥＣＴ＿ＪＯＩＮ
６．  ＬＥＦＴ＿ＯＵＴＥＲ＿ＪＯＩＮ
７．  ＮＡＴＵＲＡＬ＿ＪＯＩＮ
８．  ＲＩＧＨＴ＿ＯＵＴＥＲ＿ＪＯＩＮ
９．  ＵＮＩＯＮ＿ＪＯＩＮ
【００１９】
利用目的性制約の課題を解決するための方法；
正規化されたＳＱＬリレーショナル・データベースの構造は、利用目的の意味を表象し、各々のＴＡＢＬＥは利用目的の特性に応じた位相を表象している。
ＡＰまたはＴＵが、検索標識条件式を与えるとき、まず条件式のＣＯＬＵＭＮが存在するＴＡＢＬＥに注目する、その後にそのＴＡＢＬＥと利用目的の意味に対応するＴＡＢＬＥとの参照整合性を確立する制約条件式を考慮する。この考慮の過程が、利用目的の意味に対する考慮を希薄にする。
ＡＰまたはＴＵは、そのような参照整合性制約に捉われることなく、単に利用目的の意味のみを考慮して、適切な利用目的の位相特性領域（以下、”ＳＣＯＰＥ”と記す）に対して、利用目的の検索標識条件式を与えればよい。
利用目的の検索標識条件に対して、直接的に条件式を記述するＱｕｅｒｙ構文（【ＳＱＬ式３】）を用いるか、間接的に条件式を記述するＳｕｂＱｕｅｒｙ構文（【ＳＱＬ式４】）を用いるべきかは、ＡＰの処理ロジックまたはＴＵの意図が、利用目的の位相特性に対応したＴＡＢＬＥを選択することで定まる。利用目的の位相特性に対応したＴＡＢＬＥを選択し、そのＳＣＯＰＥを選択している間、ＳＣＯＰＥが活性化されている状態（以下、”ＡＣＴＩＶＥ”と記す）である。
ＡＰまたはＴＵが発行する命令は、ＡＣＴＩＶＥなＳＣＯＰＥにおいて、集合と位相に基づいて解釈し、記号論理により言い換えると共に変換する工程により、利用目的の位相特性に応じた、ＳＱＬ式を自動的に生成することが可能である。
【００２０】
【作用】
参照整合性制約を確保する同値条件式、参照制約指令を自動生成する作用；ＲＤＢＭＳに接続（ＬＯＧＩＮ）した時点に、データディクショナリーからＴＡＢＬＥ、ＰＫ、ＦＫ、ＣＯＬＵＭＮ群の属性情報を取得し、  （１）  リレーショナル・データベース構造解析工程により、ＴＡＢＬＥに規定されたＰＫとＦＫの関係からデータベース構造を解析する。
次に、  （２）  参照整合性制約構成工程により、参照整合性制約を確保するためのＷＨＥＲＥ句に記述する同値条件式を予め自動生成して、内部記憶域に保持する。ＲＤＢＭＳがＩＳＯ／ＩＥＣ  ９０７５：１９９２規約に準拠し、参照制約指令をサポートする場合には、参照制約指令をＳＱＬ式のＦＲＯＭ句に記述する。
ＦＲＯＭ句に記述する参照制約指令は、ＴＡＢＬＥの結合順路に依存するため、実際のＳＱＬ式生成時点に構成を決定する。ＲＤＢＭＳが該当規約に準拠しない場合は、ＳＱＬ式のＷＨＥＲＥ句に同値条件式を記述する。
【００２１】
利用目的に応じた項目を組み合わせた検索結果行列を構成する作用；
内部記憶域に保持したＴＡＢＬＥ、ＣＯＬＵＭＮ群の属性をブラウザーに表示し、利用目的に応じた項目（ＣＯＬＵＭＮ）をドラッグし、データ行列表示領域にドロップするなどの方法で、検索結果行列（ＲＯＷ）のＣＯＬＵＭＮ配列を構成する。
ＣＯＬＵＭＮ群の構成から参照するＴＡＢＬＥ群が定まるので、  （３）  参照整合データ行列構成工程により、参照するＴＡＢＬＥ群を一筆書きで辿ることができる適切な順路を選定する。
適切な順路は、グラフ理論などのアルゴリズムを用いて求めることができ、ＳＱＬ参照整合性制約指令を構成することが可能である。
データ行列オブジェクトを生成登録するＣプログラム関数；
ｃｒｅａｔｅＲｏｗ（ｎａｍｅ，  ｉｔｅｍ＿ｌｉｓｔ）；
ｎａｍｅ−データ行列オブジェクト名文字列を指定する。
ｉｔｅｍ＿ｌｉｓｔ−項目名リストの文字列を指定する。
2004355416.tif 000014
【００２２】
利用目的に応じた位相空間オブジェクト領域を設定する作用；
特許第３３１８８４４号の「集合グラフ・インタフェース」を介して処理操作を行うとき、集合グラフ・インタフェースのプログラムは、グラフィック・ディスプレイ装置の表示画面上に「空間オブジェクト」と呼ぶ矩形の領域を描画する。
特許第３３１８８４４号の空間オブジェクトの属性に対して、本件発明では、利用目的の位相特性を保持した「位相空間オブジェクト」である。
位相空間オブジェクトは、集合論における閉集合の計量空間で、ＳＣＯＰＥと、計量単位（以下、”ＭＥＴＲＩＣ”と記す）と、その空間の全体集合の計量値を保持するオブジェクトで、内部記憶域に保持する。ＭＥＴＲＩＣは、ＲＯＷ件数や特定の数値ＣＯＬＵＭＮの集計値（ＳＵＭ）など、利用目的に応じた計量単位を設定し、利用目的の位相特性に応じた解釈をするために、閉集合と開集合を評価する機能を有する。
利用目的の特性に応じて、（４）  位相空間オブジェクト生成登録工程により、位相空間オブジェクトを設定する。複数のＳＣＯＰＥが必要な場合は、複数の位相空間オブジェクトを生成登録し、表示画面上に複数の矩形の領域を描画して、複数の位相空間オブジェクトを配列する。
位相空間オブジェクトを生成登録するＣプログラム関数；
ｃｒｅａｔｅＳｐａｃｅ（ｎａｍｅ，  ｔａｂｌｅ，  ｃｏｎｄｉｔｉｏｎ，  ｍｅｔｒｉｃ）；
ｎａｍｅ−位相空間オブジェクト名文字列を指定する。
ｔａｂｌｅ−位相空間オブジェクトの基底とするＴＡＢＬＥ名文字列を指定する。
ｃｏｎｄｉｔｉｏｎ−位相空間オブジェクトの領域を限定する条件式文字列を指定する。
指定がない場合は、ＴＡＢＬＥ全体とする。
ｍｅｔｒｉｃ−集合を計量する単位の項目名文字列を指定する。
指定がない場合は、ＲＯＷ件数とする。
例：
ｃｒｅａｔｅＳｐａｃｅ（”Ｏｒｄｅｒｓ”，  ”Ｏｒｄｅｒｓ”，  ””，  ””）；
【００２３】
利用目的に応じた位相空間オブジェクト領域を選択する作用；
ＴＵは、マウスなどの指示装置で、位相空間オブジェクトの画像領域をクリックすることで、複数の位相空間オブジェクトの中から利用目的に応じた位相空間オブジェクトを選択することから、  （５）  位相空間オブジェクト選択工程により、ＳＣＯＰＥをＡＣＴＩＶＥにする。
位相空間オブジェクトを選択するＣプログラム関数；
ｓｅｌｅｃｔＳｐａｃｅ（ｎａｍｅ）；
ｎａｍｅ−位相空間オブジェクト名文字列を指定する。
例：
ｓｅｌｅｃｔＳｐａｃｅ（”Ｏｒｄｅｒｓ”）；
【００２４】
位相空間オブジェクト領域に対して利用目的の検索標識条件を与える作用；ＴＵは、利用目的の検索標識条件式を、位相空間オブジェクトに対して与える。検索標識条件式を与える方法は、条件式を記述するためのダイアログなどを用いて行う。
ＩＮＴＥＲＰＲＥＴＥＲは、検索標識条件式のＣＯＬＵＭＮのＴＡＢＬＥと、ＳＣＯＰＥのＴＡＢＬＥとの参照整合性を確保するために必要な制約条件を付与したＳＱＬ指令を自動的に生成してＲＤＢＭＳに発行する。
検索標識条件式のＣＯＬＵＭＮが存在するＴＡＢＬＥを起点とし、位相空間オブジェクトが保持するＴＡＢＬＥを終点とする結合順路を、（８）  位相特性ＳＱＬ結合順路探索工程により、探索し選定する。結合順路がすべて、ＰＫからＦＫに向けての順接合のときは、Ｑｕｅｒｙ構文を用い、結合順路中にＦＫからＰＫに向かう逆接合が存在するとき、ＳｕｂＱｕｅｒｙ構文を用いる、（９）  位相特性ＳＱＬ構文構成工程により、適切なＳＱＬ構文を構成する。
以上の結果に基づき、（１０）  位相特性ＳＱＬ指令自動生成工程により、参照テーブル群の結合に必要な参照整合性制約と、利用目的の位相特性に応じたＳＱＬ構文から、ＳＱＬリレーショナル・データベース管理システムに発行するＳＱＬ式を自動的に生成する。
検索標識条件式を満足する集合の結果は、（ＡＣＴＩＶＥな）位相空間オブジェクトに規定されたＭＥＴＲＩＣによって得られ、その位相空間オブジェクトにおいて固有の識別子で登録され、検索標識条件式とＭＥＴＲＩＣ値を保持したオブジェクトとして、内部記憶域に保持する。
このオブジェクトは、特許第３３１８８４４号の請求項１の（ａ）に記載がある、集合生成工程が生成する「集合オブジェクト」に対して、本件発明では、利用目的の位相特性を保持する「位相集合オブジェクト」である。
位相集合オブジェクトは、位相空間オブジェクトに対して、閉集合であるか、または開集合であるかが判定されたオブジェクトである。
位相集合オブジェクトを生成登録するＣプログラム関数；
ｃｒｅａｔｅＳｅｔ（ｎａｍｅ，  ｃｏｎｄｉｔｉｏｎ）；
ｎａｍｅ−位相集合オブジェクト名文字列を指定する。
オブジェクト名が、ピリオドで区切られた名称であるときは、
前部を位相空間オブジェクト名、後部を位相集合オブジェクト名とする。
ｃｏｎｄｉｔｉｏｎ−位相集合オブジェクトの条件式文字列を指定する。
例：
ｃｒｅａｔｅＳｅｔ（”Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
【００２５】
集合グラフによって利用目的に対する適合性を判定する作用；
集合グラフ・インタフェースのプログラムは、位相集合オブジェクトの計量値を、位相空間オブジェクトの計量値の面積の矩形領域と、相対的な面積を有する矩形領域に写像して描画する。
複数の標識条件の論理積（ｉｎｔｅｒｓｅｃｔ）、論理和（ｕｎｉｏｎ）、または論理差（ｄｉｆｅｒｅｎｃｅ）の標識条件が必要であれば、各々の標識条件に対応した個別の位相集合オブジェクトを作成し、集合グラフ上において、それらを最大３個まで組み合わせて描画し、評価する。
集合グラフ・インタフェースのプログラムは、組み合わせた位相集合オブジェクトの持つ条件式をＡＮＤで結合して論理積集合のＭＥＴＲＩＣを得て、  特許第３３１８８４４号の請求項１の（ｂ）に記載がある、集合描画工程により、集合グラフを描画する。
この集合グラフによって、ＴＵは、検索標識の条件を満足する集合の存在、論理集合の存在を視覚して評価する。
また、与えた標識条件式が妥当か、選択したＳＣＯＰＥが、利用目的の意味に対して適当であるかを判定する。
利用目的の意味に対して、適当でないＳＣＯＰＥを選択したのであれば、別の位相空間オブジェクトを選択して、同様の手順を繰り返して判定する。
このような操作方法の概念が、本件発明の請求項２に記載するところの、利用時点における利用目的の位相特性を検証することが可能である概念を形成するものである。
集合グラフを描画するＣプログラム関数；
ｄｒａｗＳｅｔ（ｓｐａｃｅ，  ｓｅｔ＿１，  ｓｅｔ＿２，  ｓｅｔ＿３）；
ｓｐａｃｅ−位相集合オブジェクト名文字列を指定する。
ｓｅｔ＿１−第１の位相集合オブジェクト名文字列を指定する。
ｓｅｔ＿２−第２の位相集合オブジェクト名文字列を指定する。
ｓｅｔ＿３−第３の位相集合オブジェクト名文字列を指定する。
例：
ｄｒａｗＳｅｔ（”Ｏｒｄｅｒｓ”，  ”Ａ”，  ”Ｂ”，  ”Ｃ”）；
【００２６】
利用目的に応じた集合グラフの領域を選択する作用；
ＴＵは、集合グラフ上の利用目的に応じた領域をマウスでクリックして選択する。複数の標識条件の論理積、論理和、または論理差の標識条件は、複数の領域を組み合わせた論理的な集合を構成して、特許第３３１８８４４号の請求項１の（ｃ）に記載がある、集合選択工程により、選択する。
選択した論理集合は、記号論理に基づく「集合論理式」で表記される。
集合グラフの論理集合を選択するＣプログラム関数；
ｓｅｌｅｃｔＳｅｔ（ｓｅｔ＿ｆｏｒｍｕｌａ）；
ｓｅｔ＿ｆｏｒｍｕｌａ−集合論理式文字列を指定する。
例：
ｓｅｌｅｃｔＳｅｔ（”＆ｌｔ＋＆ｇｔ  Ａ  ＆ｌｔ−＆ｇｔ  （（Ａ  ＊  Ｂ）  ＋  （Ａ  ＊  Ｃ）”）；
【００２７】
利用目的に応じたオブジェクトを登録して再利用可能とする作用；
ＳＱＬ集計関数やＲＤＢＭＳが提供する関数機能を用いた函数式を標識条件に記述することが可能である。このために、（７）  位相特性クラス・オブジェクト生成登録工程により、標識条件式やＳＱＬ函数式をオブジェクトとして生成登録し、内部記憶域に保持する。
標識条件オブジェクトを生成登録するＣプログラム関数；
ｃｒｅａｔｅＣｏｎｄｉｔｉｏｎ（ｎａｍｅ，  ｃｏｎｄｉｔｉｏｎ）；
ｎａｍｅ−標識条件オブジェクト名文字列を指定する。
ｃｏｎｄｉｔｉｏｎ−標識条件式文字列を指定する。
例：
ｃｒｅａｔｅＣｏｎｄｉｔｉｏｎ（”Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
ＳＱＬ函数オブジェクトを生成登録するＣプログラム関数；
ｃｒｅａｔｅＳｃａｌａｒ（ｎａｍｅ，  ｓｃａｌａｒ）；
ｎａｍｅ−標識条件オブジェクト名文字列を指定する。
ｓｃａｌａｒ−ＳＱＬ函数式文字列を指定する。
例：
ｃｒｅａｔｅＳｃａｌａｒ（”ＳｕｍＯｒｄｅｒｓ”，  ”ＳＵＭ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ）”）；
また、これらの位相空間オブジェクト、位相集合オブジェクト、データ行列オブジェクト、標識条件オブジェクト、ＳＱＬ函数オブジェクトは、簡便に操作することや共用する目的で、外部記憶域に保存管理し、再利用することが可能である。
【００２８】
利用目的に応じた集合グラフの利用目的に応じた検索結果行列に適用する作用；
利用目的に応じて選択した集合グラフの論理集合を、利用目的に応じた検索結果のデータ行列に適用する。
集合グラフの論理集合が保持するＴＡＢＬＥ群と、データ行列のＣＯＬＵＭＮが存在するＴＡＢＬＥ群とから、利用目的性を考慮したＳＱＬ構文構成を決定した後、参照整合性を確保する。
データ行列のＣＯＬＵＭＮが参照するＴＡＢＬＥ群のうちで最上位に位置するＴＡＢＬＥを起点とした結合順路を、（８）  位相特性ＳＱＬ結合順路探索工程により、探索し選定する。結合順路がすべて、ＰＫからＦＫに向けての順結合のときは、Ｑｕｅｒｙ構文を用い、結合順路中にＦＫからＰＫに向かう逆接合が存在するとき、ＳｕｂＱｕｅｒｙ構文を用いる、（９）  位相特性ＳＱＬ構文構成工程により、適切なＳＱＬ構文を構成する。
以上の結果に基づき、（１０）  位相特性ＳＱＬ指令自動生成工程により、参照テーブル群の結合に必要な参照整合性制約と、利用目的の位相特性に応じたＳＱＬ構文から、ＳＱＬリレーショナル・データベース管理システムに発行するＳＱＬ式を自動的に生成する。
【００２９】
このように利用の目的に応じて、適切なデータ行列結果を求めるために、異なるＳＱＬ構文を自動的に生成することが可能で、利用目的の位相特性を自動的に解釈することが可能であるので、リレーショナル・データベースに発行するＳＱＬ式を自動的に作成する方法で、参照整合性制約と同時に、利用目的性制約を自動的に解決することが可能である。
従って、利用目的に応じたクラス・オブジェクトを事前に作成し、保持して運用する必要がなく、位相空間を表象した図形を選択することによって、利用目的を選択し、その位相特性に対応した制約のＳＱＬ式を自動的に生成することによって、第１の課題とした、リレーショナル・データベースの参照性合成制約と利用目的性制約を効果的に確保することが可能である。
【００３０】
第１の課題を効果的に解決することによって、リレーショナル・データベースの設計においては、正規化の概念を忠実に履行した上で、複雑な構造を意識することなく、どのように情報を取り出すかを思い煩うことなく、どの情報を読むかに集中することができるため、第２の課題とした、本件発明の請求項３に記載するところの、リレーショナル・データベース構造設計時の利用目的の位相特性と、応用処理時の利用目的の位相特性との一貫性を保証することが可能である。
【００３１】
【実施例】
実施例においては、次に記すＴＡＢＬＥ群とＪＯＩＮ群を定義した
【図２】に示す、正規化された構造のリレーショナル・データベースを用いた例を示す。
本件発明は、特許第３３１８８４４号「集合の図式化によるデータベース検索処理方法」を実装したＳＱＬｃｒａｆｔと呼ぶプログラムにおいて実施する。
ＳＱＬｃｒａｆｔの操作画面イメージを
【図３】に示す。操作画面には、以下の５個の区画がある。
Ａ．  集合グラフ表示区画
Ｂ．  オブジェクト・ギャラリー階層木表示区画
Ｃ．  オブジェクト・ギャラリー一覧表示区画
Ｄ．  データベース・オブジェクト表示区画
Ｅ．  データ行列表示区画
【００３２】
実施例の参照整合性制約を確保する同値条件式、ＳＱＬ参照整合性制約指令を自動生成する作用において、（１）  リレーショナル・データベース構造解析工程、（２）  参照整合性制約構成工程により作成したＴＡＢＬＥ一覧表、結合関係の判定表、同値条件式の一覧を以下に示す。
ＲＤＢＭＳのデータディクショナリーから取得したＴＡＢＬＥ一覧表；
１．  Ｃａｔｅｇｏｒｉｅｓ
２．  Ｃｕｓｔｏｍｅｒｓ
３．  Ｅｍｐｌｏｙｅｅｓ
４．  ＯｒｄｅｒＩｔｅｍｓ
５．  Ｏｒｄｅｒｓ
６．  Ｐｒｏｄｕｃｔｓ
７．  Ｓｈｉｐｐｅｒｓ
８．  Ｓｕｐｐｌｉｅｒｓ
リレーショナル・データベース構造解析工程により作成した結合関係の判定表；
１２３４５６７８
１  ：＊−−−−Ｃ−−：  Ｃａｔｅｇｏｒｉｅｓ
２  ：−＊−−Ｃ−−−：  Ｃｕｓｔｏｍｅｒｓ
３  ：−−＊−Ｃ−−−：  Ｅｍｐｌｏｙｅｅｓ
４  ：−−−−ＰＰ−−：  ＯｒｄｅｒＩｔｅｍｓ
５  ：−ＰＰＣ＊−Ｐ−：  Ｏｒｄｅｒｓ
６  ：Ｐ−−Ｃ−＊−Ｐ：  Ｐｒｏｄｕｃｔｓ
７  ：−−−−Ｃ−＊−：  Ｓｈｉｐｐｅｒｓ
８  ：−−−−−Ｃ−＊：  Ｓｕｐｐｌｉｅｒｓ
＊  −  主ＴＡＢＬＥ属性。このマークがないテーブルは主ＴＡＢＬＥ属性がない。
Ｐ  −  列番号のＴＡＢＬＥを主ＴＡＢＬＥとする属性。
Ｃ  −  列番号のＴＡＢＬＥを従ＴＡＢＬＥとする属性。
また、結合関係の判定表よりＴＡＢＬＥの結合性を樹上図と呼ぶ階層木形式で、データベース・オブジェクト表示区画に表示した例を
【図４】に示す。
参照整合性制約を確保するためのＷＨＥＲＥ句に記述する同値条件式の一覧；
１．  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ
２．  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ
３．  Ｅｍｐｌｏｙｅｅｓ．ＥｍｐｌｏｙｅｅＩＤ  ＝  Ｏｒｄｅｒｓ．ＥｍｐｌｏｙｅｅＩＤ
４．  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ
５．  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ
６．  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ
７．  Ｓｕｐｐｌｉｅｒｓ．ＳｕｐｐｌｉｅｒＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＳｕｐｐｌｉｅｒＩＤ
【００３３】
実施例の利用目的に応じた項目を組み合わせた検索結果行列を構成する作用において、ＴＵが、データベース・オブジェクト表示区画のＣＯＬＵＭＮをドラッグして、データ行列表示区画上にドロップする操作により、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに、以下に記す、Ｃ関数命令を発行した。
ｃｒｅａｔｅＲｏｗ（”ＳａｌｅｓＢｙＥｍｐｌｏｙｅｅ”，  ”Ｅｍｐｌｏｙｅｅｓ．ＬａｓｔＮａｍｅ，Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ，ＳＵＭ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ），ＡＶＧ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ）”）；
解釈処理プログラムは、位相特性ＳＱＬ結合順路探索工程により、それらの項目の参照整合性を確保するために必要な結合順路を探索し、参照整合データ行列構成工程により、以下に記す、
【ＳＱＬ式５】を生成した。
【ＳＱＬ式５】
ＳＥＬＥＣＴ  Ｅｍｐｌｏｙｅｅｓ．ＬａｓｔＮａｍｅ，  Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ，  ＳＵＭ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ），  ＡＶＧ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ）  ＦＲＯＭ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｅｍｐｌｏｙｅｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｅｍｐｌｏｙｅｅｓ．ＥｍｐｌｏｙｅｅＩＤ  ＝  Ｏｒｄｅｒｓ．ＥｍｐｌｏｙｅｅＩＤ）  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ  ＧＲＯＵＰ  ＢＹ  Ｅｍｐｌｏｙｅｅｓ．ＬａｓｔＮａｍｅ，  Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ；
【ＳＱＬ式５】に記述された、ＳＱＬ集計関数の項目は、
【図５】に示す、標識条件オブジェクト、ＳＱＬ函数オブジェクトを作成登録するダイアログで、事前に登録した。
【００３４】
実施例の利用目的に応じた位相空間オブジェクト領域を設定する作用において、ＴＵの操作により、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに、以下に記す、Ｃ関数命令を発行した。
ｃｒｅａｔｅＳｐａｃｅ（”Ｏｒｄｅｒｓ”，  ”Ｏｒｄｅｒｓ”）；
位相空間オブジェクト生成登録工程が、位相空間オブジェクトの基底の集合計量値を取得するために、以下に記す
【ＳＱＬ式６】を生成した。
【ＳＱＬ式６】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ）  ＦＲＯＭ  Ｏｒｄｅｒｓ；
表示画面上に複数の矩形の領域を描画して、複数の位相空間オブジェクトを配列する。
【図３】に示す、ＳＱＬｃｒａｆｔ操作画面の集合グラフ描画区画に、４個の位相空間オブジェクトが並列して描画した。
実施例の利用目的に応じた位相空間オブジェクト領域を選択する作用により選択された、活性化されている位相空間オブジェクトの領域は赤線の枠が表示される。
【００３５】
実施例の位相空間オブジェクト領域に対して利用目的の検索標識条件を与える作用において、ＴＵの操作により、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに発行するＣ関数命令と、位相特性ＳＱＬ結合順路探索工程、位相特性ＳＱＬ構文構成工程、  位相特性ＳＱＬ指令自動生成工程がＳＱＬ式を自動的に生成する過程を以下に記す。
位相空間オブジェクトＯｒｄｅｒｓに対して、”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｓｐｅｅｄｙ  Ｅｘｐｒｅｓｓ’”の標識条件を与えて位相集合オブジェクトを生成登録する操作を行った結果、以下に記す、Ｃ関数命令が発生した。
ｃｒｅａｔｅＳｅｔ（”Ｏｒｄｅｒｓ．’Ｓｐｅｅｄｙ  Ｅｘｐｒｅｓｓ’”，  ”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｓｐｅｅｄｙ  Ｅｘｐｒｅｓｓ’”）；
位相特性ＳＱＬ結合順路探索工程は、標識条件式のＴＡＢＬＥ  ”Ｓｈｉｐｐｅｒｓ”を起点として、位相空間オブジェクトのＴＡＢＬＥ  ”Ｏｒｄｅｒｓ”を終点とする結合順路を探索し、Ｓｈｉｐｐｅｒｓ  →  Ｏｒｄｅｒｓの結合順路を求めた。この結合順路は順接合（”→”）であるので、位相特性ＳＱＬ構文構成工程は、単純なＱｕｅｒｙ構文を使用する式を構成した。
以上の結果、位相特性ＳＱＬ指令自動生成工程は、以下に記す
【ＳＱＬ式７】を生成した。
【ＳＱＬ式７】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ）  ＦＲＯＭ  Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｓｐｅｅｄｙ  Ｅｘｐｒｅｓｓ’；
次に、位相空間オブジェクトＯｒｄｅｒｓに対して、”  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＮａｍｅ  ＝  ’Ｃｈｏｃｏｌａｄｅ’”の標識条件を与えて位相集合オブジェクトを生成登録する操作を行った結果、以下に記す、Ｃ関数命令が発生した。
ｃｒｅａｔｅＳｅｔ（”Ｏｒｄｅｒｓ．Ｃｈｏｃｏｌａｄｅ”，  ”Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＮａｍｅ  ＝  ’Ｃｈｏｃｏｌａｄｅ’”）；
位相特性ＳＱＬ結合順路探索工程は、標識条件式のＴＡＢＬＥ”  Ｐｒｏｄｕｃｔｓ”を起点として、位相空間オブジェクトのＴＡＢＬＥ  ”Ｏｒｄｅｒｓ”を終点とする結合順路を探索し、Ｐｒｏｄｕｃｔｓ  →  ＯｒｄｅｒＩｔｅｍｓ  ←  Ｏｒｄｅｒｓ結合順路を求めた。この結合順路には逆接合（”←”）を含むので、位相特性ＳＱＬ構文構成工程は、ＳｕｂＱｕｅｒｙ構文を構成した。
以上の結果、位相特性ＳＱＬ指令自動生成工程は、以下に記す
【ＳＱＬ式８】を生成した。
【ＳＱＬ式８】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ）  ＦＲＯＭ  Ｏｒｄｅｒｓ  ＷＨＥＲＥ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ  ＦＲＯＭ  Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｏｒｄｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ  ＷＨＥＲＥ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＮａｍｅ  ＝  ’Ｃｈｏｃｏｌａｄｅ’）；
【００３６】
実施例の集合グラフによって利用目的に対する適合性を判定する操作概念を以下に記す。
以下に記す、２個の標識条件を、ＯｒｄｅｒＩｔｅｍｓ、Ｏｒｄｅｒｓ、Ｃｕｓｔｏｍｅｒｓ、Ｐｒｏｄｕｃｔｓの各位相空間オブジェクトおいて評価するものとする。
Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’
Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’（ａ）  位相空間オブジェクト”ＯｒｄｅｒＩｔｅｍｓ”の例；
位相空間オブジェクト”ＯｒｄｅｒＩｔｅｍｓ”で、ＴＵが位相集合オブジェクトを生成登録する操作を行った結果、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに対して、以下に記す、Ｃ関数命令を発行した。
ｃｒｅａｔｅＳｅｔ（”ＯｒｄｅｒＩｔｅｍｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
ｃｒｅａｔｅＳｅｔ（”ＯｒｄｅｒＩｔｅｍｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”，  ”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
次に、上記の位相集合オブジェクトを指定して、集合グラフを描画する操作を行った結果、以下に記す、Ｃ関数命令を発行した。
ｄｒａｗＳｅｔ（”ＯｒｄｅｒＩｔｅｍｓ”，  ”ＯｒｄｅｒＩｔｅｍｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｏｒｄｅｒｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
上記の集合グラフを描画するために、論理積集合オブジェクトを生成登録する工程で、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに対して、以下に記すＣ関数命令を発行した。
ｃｒｅａｔｅＳｕｂｓｅｔ（”ＯｒｄｅｒＩｔｅｍｓ．［Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’］”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’  ＡＮＤ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
上記の論理積集合オブジェクトを生成登録するＣ関数命令で、解釈処理プログラムは、位相特性ＳＱＬ結合順路探索工程によって、２個の標識条件の参照するＴＡＢＬＥの結合順路を探索した結果、Ｃａｔｅｇｏｒｉｅｓは、Ｃａｔｅｇｏｒｉｅｓ  →  Ｐｒｏｄｕｃｔｓ  →  ＯｒｄｅｒＩｔｅｍｓの結合順路、Ｓｈｉｐｐｅｒｓは、Ｓｈｉｐｐｅｒｓ  →  Ｏｒｄｅｒｓ  →  ＯｒｄｅｒＩｔｅｍｓの結合順路であった。
位相特性ＳＱＬ構文構成工程は、すべての結合が順接合であるので、Ｑｕｅｒｙ構文を構成し、位相特性ＳＱＬ指令自動生成工程は、以下に記す
【ＳＱＬ式９】を生成した。
【ＳＱＬ式９】
ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ，ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｏｒｄｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’  ＡＮＤ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’；
【００３７】
（ｂ）  位相空間オブジェクト”Ｏｒｄｅｒｓ”の例；
同様の操作手順で、”Ｏｒｄｅｒｓ”の領域で実施した結果、以下に記す、Ｃ関数命令が発生した。
ｃｒｅａｔｅＳｅｔ（”Ｏｒｄｅｒｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
ｃｒｅａｔｅＳｅｔ（”Ｏｒｄｅｒｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”，  ”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｄｒａｗＳｅｔ（”Ｏｒｄｅｒｓ”，  ”Ｏｒｄｅｒｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｏｒｄｅｒｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｃｒｅａｔｅＳｕｂｓｅｔ（”Ｏｒｄｅｒｓ．［Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’］”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’  ＡＮＤ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
上記の論理積集合オブジェクトを生成登録するＣ関数命令で、各々の標識条件の参照するＴＡＢＬＥのＣａｔｅｇｏｒｉｅｓは、Ｃａｔｅｇｏｒｉｅｓ  →  Ｐｒｏｄｕｃｔｓ  →  ＯｒｄｅｒＩｔｅｍｓ  ←  Ｏｒｄｅｒｓの結合順路、Ｓｈｉｐｐｅｒｓは、Ｓｈｉｐｐｅｒｓ  →  Ｏｒｄｅｒｓの結合順路であった。
Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’については、順接合であるのでＱｕｅｒｙ構文を用い、Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’については、順接合と逆接合が混在するので、ＳｕｂＱｕｅｒｙ構文を用いた、以下に記す
【ＳＱＬ式１０】を生成した。
【ＳＱＬ式１０】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ）  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （（Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’  ＡＮＤ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｏｒｄｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’）；
【００３８】
（ｃ）  位相空間オブジェクト”Ｃｕｓｔｏｍｅｒｓ”の例；
同様の操作手順で、”  Ｃｕｓｔｏｍｅｒｓ”の領域で実施した結果、以下に記す、Ｃ関数命令が発生した。
ｃｒｅａｔｅＳｅｔ（”Ｃｕｓｔｏｍｅｒｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
ｃｒｅａｔｅＳｅｔ（”Ｃｕｓｔｏｍｅｒｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”，  ”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｄｒａｗＳｅｔ（”Ｃｕｓｔｏｍｅｒｓ”，  ”Ｃｕｓｔｏｍｅｒｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｃｕｓｔｏｍｅｒｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｃｒｅａｔｅＳｕｂｓｅｔ（”Ｃｕｓｔｏｍｅｒｓ．［Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’］”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’  ＡＮＤ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
上記の論理積集合オブジェクトを生成登録するＣ関数命令で、各々の標識条件の参照するＴＡＢＬＥのＣａｔｅｇｏｒｉｅｓは、Ｃａｔｅｇｏｒｉｅｓ  →  Ｐｒｏｄｕｃｔｓ  →  ＯｒｄｅｒＩｔｅｍｓ  ←  Ｏｒｄｅｒｓ  ←  Ｃｕｓｔｏｍｅｒｓの結合順路、Ｓｈｉｐｐｅｒｓは、Ｓｈｉｐｐｅｒｓ  →  Ｏｒｄｅｒｓ  ←  Ｃｕｓｔｏｍｅｒｓの結合順路であった。
いずれも順接合と逆接合が混在するので、ＳｕｂＱｕｅｒｙ構文を用いた、以下に記す
【ＳＱＬ式１１】を生成した。
【ＳＱＬ式１１】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （（Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＦＲＯＭ  Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’）  ＡＮＤ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （（Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’）；
【００３９】
（ｄ）  位相空間オブジェクト”Ｐｒｏｄｕｃｔｓ”の例；
同様の操作手順で、”  Ｃｕｓｔｏｍｅｒｓ”の領域で実施した結果、以下に記す、Ｃ関数命令が発生した。
ｃｒｅａｔｅＳｅｔ（”Ｐｒｏｄｕｃｔｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’”）；
ｃｒｅａｔｅＳｅｔ（”Ｐｒｏｄｕｃｔｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”，  ”Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｄｒａｗＳｅｔ（”Ｐｒｏｄｕｃｔｓ”，  ”Ｐｒｏｄｕｃｔｓ．Ｂｅｖｅｒａｇｅｓ”，  ”Ｐｒｏｄｕｃｔｓ．’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
ｃｒｅａｔｅＳｕｂｓｅｔ（”Ｐｒｏｄｕｃｔｓ．［Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’］”，  ”Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’  ＡＮＤ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’”）；
上記の論理積集合オブジェクトを生成登録するＣ関数命令で、各々の標識条件の参照するＴＡＢＬＥのＣａｔｅｇｏｒｉｅｓは、Ｃａｔｅｇｏｒｉｅｓ  →  Ｐｒｏｄｕｃｔｓの結合順路、Ｓｈｉｐｐｅｒｓは、Ｓｈｉｐｐｅｒｓ  →  Ｏｒｄｅｒｓ  →  ＯｒｄｅｒＩｔｅｍｓ  →  Ｐｒｏｄｕｃｔｓの結合順路であった。
Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’については、順接合であるのでＱｕｅｒｙ構文を用い、Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’については、順接合と逆接合が混在するので、ＳｕｂＱｕｅｒｙ構文を用いた、以下に記す
【ＳＱＬ式１２】を生成した。
【ＳＱＬ式１２】
ＳＥＬＥＣＴ  ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ）  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｏｒｄｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ  ＦＲＯＭ  Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｏｒｄｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’）  ＡＮＤ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’；
【００４０】
以上のＳＱＬ指令をＲＤＢＭＳに発行して取得したＭＥＴＲＩＣにより、各々の位相空間の描画領域に集合グラフを描画した例を
【図６】に示す。
【図６】に示すように、全く同一の標識条件を与えた場合でも、位相空間によって、異なる集合が生じる。この集合グラフを評価することから、本件発明の請求項２に記載するところの、利用時点における利用目的の位相特性を検証することが可能である概念を形成するものである。
【００４１】
実施例の利用目的に応じた集合グラフの利用目的に応じた検索結果行列に適用する作用において、ＴＵの操作により発生する命令と、（８）  位相特性ＳＱＬ結合順路探索工程、（９）  位相特性ＳＱＬ構文構成工程、（１０）  位相特性ＳＱＬ指令自動生成工程が、ＳＱＬ式を自動的に生成する工程を以下に記す。
位相空間オブジェクト”Ｃｕｓｔｏｍｅｒｓ”の集合グラフで【図７】に示す論理集合の領域、”＆ｌｔ＋＆ｇｔ  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’  ＆ｌｔ−＆ｇｔ  （Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’）”を選択して、４件の”Ｃｕｓｔｏｍｅｒｓ”の集合を、前記のデータ行列オブジェクト”ＳａｌｅｓＢｙＥｍｐｌｏｙｅｅ”のＲＯＷを読む例を以下に記す。
ＴＵが、”Ｃｕｓｔｏｍｅｒｓ”の集合グラフの領域を選択した操作の結果、集合グラフ・インタフェースのプログラムは、以下の命令を発行した。
ｓｅｌｅｃｔＳｅｔ（＆ｌｔ＋＆ｇｔ  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’  ＆ｌｔ−＆ｇｔ  （Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’））；
ＴＵは、選択した集合グラフのマウス・ボタンを押し下げた状態でずらすドラッグ操作をして、マウスをデータ行列表示区画に移動して、ボタンを開放するドロップ操作をして、集合グラフで選択した論理集合の条件をデータ行列を読む条件とする。
このドラッグ・アンド・ドロップ操作の結果、集合グラフ・インタフェースのプログラムが、解釈処理プログラムに以下に記すＣ関数命令を発行した。
ｒｅａｄＳｅｔ（”ＳａｌｅｓＢｙＥｍｐｌｏｙｅｅ”，  ”＆ｌｔ＋＆ｇｔ  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’  ＆ｌｔ−＆ｇｔ  （Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’）”）；
上記の命令によって、論理集合の集合論理式は、記号論理により、位相集合オブジェクトが保持する標識条件式に置換される。
この結果、解釈処理プログラムは、先に記述したように、（８）  位相特性ＳＱＬ結合順路探索工程、（９）  位相特性ＳＱＬ構文構成工程、（１０）  位相特性ＳＱＬ指令自動生成
工程により、以下に記す
【ＳＱＬ式１３】を生成した。
【ＳＱＬ式１３】
ＳＥＬＥＣＴ  Ｅｍｐｌｏｙｅｅｓ．ＬａｓｔＮａｍｅ，  Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ，  ＳＵＭ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ），  ＡＶＧ（ＯｒｄｅｒＩｔｅｍｓ．ＵｎｉｔＰｒｉｃｅ  ＊  ＯｒｄｅｒＩｔｅｍｓ．Ｑｕａｎｔｉｔｙ）  ＦＲＯＭ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｅｍｐｌｏｙｅｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｅｍｐｌｏｙｅｅｓ．ＥｍｐｌｏｙｅｅＩＤ  ＝  Ｏｒｄｅｒｓ．ＥｍｐｌｏｙｅｅＩＤ）  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ  ＷＨＥＲＥ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＦＲＯＭ  Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’）  ＡＮＤ  ＮＯＴ  （Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＦＲＯＭ  Ｓｈｉｐｐｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＯＮ  Ｓｈｉｐｐｅｒｓ．ＳｈｉｐｐｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＳｈｉｐＶｉａ  ＷＨＥＲＥ  Ｓｈｉｐｐｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ  ＝  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｎｇ’）  ＡＮＤ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＩＮ  （ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＦＲＯＭ  Ｃａｔｅｇｏｒｉｅｓ  ＩＮＮＥＲ  ＪＯＩＮ  （Ｐｒｏｄｕｃｔｓ  ＩＮＮＥＲ  ＪＯＩＮ  （（Ｃｕｓｔｏｍｅｒｓ  ＩＮＮＥＲ  ＪＯＩＮ  Ｏｒｄｅｒｓ  ＯＮ  Ｃｕｓｔｏｍｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ  ＝  Ｏｒｄｅｒｓ．ＣｕｓｔｏｍｅｒＩＤ）  ＩＮＮＥＲ  ＪＯＩＮ  ＯｒｄｅｒＩｔｅｍｓ  ＯＮ  Ｏｒｄｅｒｓ．ＯｒｄｅｒＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＯｒｄｅｒＩＤ）  ＯＮ  Ｐｒｏｄｕｃｔｓ．ＰｒｏｄｕｃｔＩＤ  ＝  ＯｒｄｅｒＩｔｅｍｓ．ＰｒｏｄｕｃｔＩＤ）  ＯＮ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＩＤ  ＝  Ｐｒｏｄｕｃｔｓ．ＣａｔｅｇｏｒｙＩＤ  ＷＨＥＲＥ  Ｃａｔｅｇｏｒｉｅｓ．ＣａｔｅｇｏｒｙＮａｍｅ  ＝  ’Ｂｅｖｅｒａｇｅｓ’））  ＧＲＯＵＰ  ＢＹ  Ｅｍｐｌｏｙｅｅｓ．ＬａｓｔＮａｍｅ，  Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅ；
上記の
【ＳＱＬ式１３】を実行した結果、以下のＲＯＷを得た。
2004355416.tif 000015
上記のＲＯＷは１１行あるが、Ｃｕｓｔｏｍｅｒｓ．ＣｏｍｐａｎｙＮａｍｅは４件で、位相空間オブジェクト”Ｃｕｓｔｏｍｅｒｓ”の集合グラフで選択した論理集合の件数に合致しており、応用処理の利用目的の位相特性を確保するための制約条件が正しく適用された結果であることが検証された。
【００４２】
【発明の効果】
本件発明は、リレーショナル・データベースの応用プログラムの開発プログラマーの開発工程、ならびにグラフィック・ユーザ・インタフェースを介したエンド・ユーザの検索処理の操作工程において、検索結果のデータ行列を読む処理、ならびにデータの追加、更新、削除処理において記述するＳＱＬ式に、リレーショナル論理代数の概念に基づく、参照整合性を確保するための制約と、応用処理の利用目的の位相特性を確保するための制約を、リレーショナル・データベース自体のデータ・ディクショナリーが保持する情報によってのみ解決することが可能である。
従って、従来の技術が、参照整合性制約と利用目的性制約のために、クラス・オブジェクトの管理、保守、保持に多大の労力とコンピュータ資源を要し、リレーショナル・データベースが保持する管理情報と、二元的に管理することの問題点の課題と、完全なクラス・オブジェクトを作成し保持することも、それを完全に利用し運用することも、いずれも人的な能力と管理に依存するものであるので、不完全性を内包することの課題を解決した。
さらに、リレーショナル・データベースの設計において、正規化の概念を忠実に履行するために、個々の利用目的の応用処理において、リレーション間の結合に必要な参照整合性制約の課題を自動的に解決し、プログラマーなどの開発者のみならず、一般ユーザにとっても、複雑な構造を意識することなく、どのように情報を取り出すかを思い煩うことなく、どの情報を読むかに集中することが可能な方法を提供することにより、リレーショナル・データベース構造設計時の利用目的の位相特性と、応用処理時の利用目的の位相特性との一貫性を保証することが可能となった。
よって、リレーショナル・データベースの、より一層の効果的な利用を図ることが可能である。
【００４３】
【図面の簡単な説明】
【図１】本件発明のシステム構成を示す図である。
【図２】実施例に用いた、正規化された構造のリレーショナル・データベースの構造図である。
【図３】実施例に用いた、特許第３３１８８４４号「集合の図式化によるデータベース検索処理方法」を実装したＳＱＬｃｒａｆｔの操作画面である。
【図４】データベース・テーブルの結合を一筆書きで辿る樹上図を表示した、ＳＱＬｃｒａｆｔの操作画面データベース・オブジェクト表示区画の図である。
【図５】標識条件オブジェクト、ＳＱＬ函数オブジェクトを作成登録するダイアログ操作画面である。
【図６】利用時点における利用目的特性を検証することが可能である概念を示す図である。
【図７】位相空間オブジェクト”Ｃｕｓｔｏｍｅｒｓ”の集合グラフで、４件の”Ｃｕｓｔｏｍｅｒｓ”の論理集合領域、”＆ｌｔ＋＆ｇｔ  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’  ＆ｌｔ−＆ｇｔ  （Ｂｅｖｅｒａｇｅｓ  ＊  ’Ｆｅｄｅｒａｌ  Ｓｈｉｐｐｉｇ’）”を選択した図である。
【図１】
2004355416.tif 000016
【図２】
2004355416.tif 000017
【図３】
2004355416.tif 000018
【図４】
2004355416.tif 000019
【図５】
2004355416.tif 000020
【図６】
2004355416.tif 000021
【図７】
2004355416.tif 000022