JP2005513674A - データ管理システムにおける図形クエリを提示、管理、および、開発するための方法およびデバイス - Google Patents

Abstract

【課題】 オブジェクト、オブジェクト間のリレーションシップ、および、オブジェクトのタイプ間の特殊化リレーションシップに基づいて、グラフベースのクエリを明示するために、クエリの図形表示を与えることができる手段および方法を提供すること。
【解決手段】 本発明は、データ管理システムにおける図形クエリを提示、管理、開発するための方法およびデバイスに関するものである。その方法において、データ管理システムにおけるクエリを、簡潔な手法で図形に扱って、オブジェクトと、それらのリレーションシップとを組み込み、そして、オブジェクトのタイプ間の特殊化リレーションシップを含むクエリフォーマリズムを形成することができる。その方法は、データベース内のデータ構造を定めるセマンティックモデルを、図形フォーマットに定めるステップと、当該セマンティックモデルを用いて、データベースクエリを定めるステップと、を有する方法であって、前記セマンティックモデルが、オブジェクトのタイプ、および、タイプを相互にリンクして、当該タイプ間のリレーションシップを定めるアトリビュートおよび特殊化を有するタイプグラフを有することを特徴とする方法である。考察したアプリケーションには、フォームベースのアプリケーションと、テキスト形式のレポートとが、含まれる。

Description

本発明は、データ管理システムにおける図形クエリ（照会、問い合わせ）を提示、管理、開発するための方法およびデバイスに関するものである。

特に、本発明は、オブジェクトと、それらのリレーションシップとを組み込み、そして、オブジェクトのタイプ間の特殊化リレーションシップ（特殊化関係、特化関係）を具えたクエリフォーマリズムを形成するために、データ管理システムにおけるクエリを、簡単に、図形に提示、管理、開発することのできる方法に関するものである。本明細書において、データ管理システムには、周知のデータベース管理システムが含まれ、さらに、例えば、ウェブ上でデータを管理するためのシステムも含まれる。

現在利用可能な、いくつかのデータベース管理システムは、それらの内部に、クエリを図形に描く可能性を具えている。そのような図形クエリは、サーチの目的の絵入りの描写を与え、ユーザが、SQLのような特別のクエリ言語についてのユーザ知識の必要性を回避しながら、クエリを構築することを容易にする。

Microsoft社からのAccessデータベースシステムは、リレーショナルモデルに基づいているけれども、情報モデラが、リレーショナルモデルを用いて、十分にセマンティックスを表現することができないことは、長い間認識されてきた。特に、オブジェクトと特殊化リレーションシップとが、現われない。さらに、オブジェクトと特殊化リレーションシップの存在する状態で、図形クエリを編成するための明確な原理に到達するのが、1つの課題である。

Accessの図形ユーザインターフェイスは、対話型の、フォームベースのデータに基づいたアプリケーションの形式で、更新可能なビューを開発するために利用することができる。しかしながら、多くの場合、ネストされた（入れ子状にされた）サブフォームでフォームを構築するときに、多数の図形クエリを開発して、供給する必要がある。同様の見解が、Accessのユーザインターフェイスによるテキスト形式のレポートの構築にも当てはまる。

Accessシステムの他の顕著な特徴は、クエリユーザインターフェイスが、データベースのテーブル間に存在するであろう、あらかじめ定められたリレーションシップの完全な使用を行わないということである。したがって、通常、クエリを図形に構築するときには、そのようなあらかじめ定められた情報の仕様を、頻繁に反復する必要がある。

本発明の実施例の1つの目的は、オブジェクト、オブジェクト間のリレーションシップ、および、オブジェクトのタイプ間の特殊化リレーションシップに基づいて、グラフベースのクエリを明示するために、クエリの図形表示を与えることができる手段を提供することである。

他の1つの目的は、可能な限り複雑なフォームベースの対話型のデータベースアプリケーションでも、図形クエリを用いて開発することができる手段を提供することである。

他の1つの目的は、可能な限り複雑なテキスト形式のレポートでも、図形クエリを用いて開発することができる手段を提供することである。

本発明の実施例のさらなる1つの目的は、図形クエリの構築が促進される手段を提供することである。

本発明の1つの態様によれば、データ管理システムのための図形ユーザインターフェイスであって、
データベース内のデータ構造を定めるセマンティックモデルを、図形フォーマットに定める手段と、当該セマンティックモデルを用いて、データベースクエリを定める手段と、を有する図形ユーザインターフェイスにおいて、前記セマンティックモデルが、オブジェクトのタイプ、および、タイプを相互にリンクして、当該タイプ間のリレーションシップを定めるアトリビュートおよび特殊化を有するタイプグラフを有することを特徴とする図形ユーザインターフェイスが、提供される。

本発明の別の1つの態様によれば、データベース内のデータ構造を定めるセマンティックモデルを、図形フォーマットに定めるステップと、当該セマンティックモデルを用いて、データベースクエリを定めるステップと、を有する、データ管理システムにおける図形クエリを提示、管理するための方法であって、前記セマンティックモデルが、オブジェクトのタイプ、および、タイプを相互にリンクして、当該タイプ間のリレーションシップを定めるアトリビュートおよび特殊化を有するタイプグラフを有することを特徴とする方法が、提供される。

当該タイプグラフは、特定の仕方で表わされ、そして、タイプ名と結び付けられるタイプ、および、タイプを相互にリンクさせるように表わされるアトリビュートおよび特殊化を有してもよい、あらかじめ定められた図形表記法にしたがって表わされるのが好ましい。

当該セマンティックモデルを用いるステップが、当該タイプグラフを用いて、クエリグラフを定めるステップを有してもよい。

当該クエリグラフが、当該タイプグラフのタイプ、アトリビュート、および、特殊化から、それぞれ、導出されるクエリタイプ、クエリアトリビュート、および、クエリ特殊化を有することが好ましい。

クエリタイプが、選択および／または否定と関連付け可能であることが好ましい。

クエリグラフが、タイプグラフに実行されるコピー・アンド・ペースト操作によって構築可能であることが好ましい。

クエリグラフが、さらに、1つ以上の他のクエリへの参照を有してもよい。

可能な限りサブフォームを含んでもよい、対話型のフォームベースのアプリケーションを、クエリグラフの構築によって実現してもよい。

データの変更を、前記フォームベースのアプリケーションを利用して達成してもよい。

ネストされた、種々の相異なる規則構造のサブレポートを含んでもよいテキスト形式のレポートを、クエリグラフの構築によって実現してもよい。

本発明のよりよい理解のために、また、本発明の実施例が、どのように実行に移されるかを示すために、一例として、添付のダイアグラマティックな図面を参照する。

本発明は、よく知られており、広く用いられているリレーショナルモデル [Codd 1970年][Codd 1982年]のいくつかの強みを保存し、また、その限界のいくつかを取り去るデータモデリングおよび検索フォーマリズムを明示することができる手段を提供する。リレーショナルモデルの限界には、セマンティックス（オブジェクト）、ユーザインターフェイス、および、更新可能なビューのような基本的な問題が含まれる。保存したいリレーショナルモデルの強みには、データ独立性、ビュー独立性、フォーマリティ(形式遵奉)、および、単純性が含まれる。

データ独立性は、情報モデラが、物理的表現の詳細に関して考える必要のないことを保証する。用語 ビュー独立性は、データを、ビューから独立に定めることができ、また、ビューを、簡単に、非手続き的に得ることができるという基本的な達成を表現している。いくつかの現在行われているリレーショナル構成では、図形ユーザインターフェイスが、ビュー（クエリ）の作成を、SQLのようなクエリ言語を用いるものよりも、簡単にしている。データ独立性とビュー独立性とは、共同して、標準の3つのレベルのデータベースアーキテクチャ[TsichritzisおよびKlug 1978年]を実現する。さらに、リレーショナルモデルのフォーマリティも重要である。それは、明瞭で正確な数学的基礎を提供して、コンセプトに明瞭な意味を与え、ソフトウェア開発のための土台を提供する。リレーショナルモデルの単純性は、そのベーシックプリミティブ：いくつかのドメイン内に値を持ち、テーブルまたはリレーションと呼ばれるセットを形成するタプル、によって与えられる。

記憶されて、検索されるデータのセマンティックスに関しては、リレーショナルモデルは、限界を持つ。リレーショナルテーブルは、いくつかのアトリビュート間のリレーションシップを記述し、一方、異なるテーブル間のリレーションシップは、制約（コンストレイント：依存性）を用いて、個別に考察される。オブジェクトや、オブジェクトのタイプ間の特殊化リレーションシップが、組み込まれない。情報モデラが、リレーショナルモデルを用いるよりも、より多くのセマンティックスを表すことを可能にする、広く用いられている、数学的に裏付けられたデータモデリングフォーマリズムは存在しない。しかしながら、オブジェクト指向のアプローチには、多くの利益が存在している。明示的なオブジェクトの使用によって呈示される重要な視点は、データセマンティックスに対する、より強力なサポートである。

現在利用可能な図形クエリユーザインターフェイスは、現在のところ、ユーザが、SQLについての知識を持つ必要なしに、SQLのような言語にインタープリトされるクエリを構築することができる手段として、単に提供されているだけである。したがって、現在利用可能な図形ユーザインターフェイスは、それ以前のテキスト形式のインターフェイスまたはフォーマリズムで、内部的にインタープリトされるグラフィックインターフェイスを提供している。オブジェクトと特殊化リレーションシップの存在する状態で、図形クエリを編成するための明確な原理に到達するのが、1つの課題である。

更新可能なビューに関しては、何らかの代わりのビュー内の情報を提示する対話型のフォームベースのアプリケーションを介して、情報の更新可能性の包括的でグローバルな処理を持つことが望ましい。リレーショナルなコンテキストでは、この種の更新が可能であるか否かは、一般に、スキーマの一部として様式化されていないテーブル間のリレーションシップに依存するから、そのような処理を開発するのは、難しい。

本発明のコンセプトの適切な理解のために、その説明において用いられるいくつかのモデリングコンセプトを理解する必要がある。以下の記述において、しばしばスキーマと呼ばれているものに対して、用語 セマンティックモデルを用いる。以下のサブセクションにおいて、セマンティックモデル、および、それらのインスタンスが記述され、セマンティックモデルのための便利な図形表記法が検討され、そして、例が挙げられる。その後、クエリ、更新可能なビュー（フォームベースのアプリケーション）、および、テキスト形式のレポートが、例とともに検討される。

セマンティックモデル、オブジェクト指向インスタンス
セマンティックモデルの重要な1つの特性は、それらが、ただ1つのタイプコンセプトを用いて定められるということである。セマンティックモデルのインスタンスは、オブジェクトを含んでいる。タイプは、1つのタイプから別のタイプへの接続であるアトリビュートおよび特殊化（特化）を用いて関係づけられる。このようにして、セマンティックモデルのタイプグラフが、形成される。アトリビュートと特殊化のいずれでも、矢と呼ぶのが便利である。1つのタイプの矢は、そのタイプの外向きの矢である。

特殊化は、タイプ間の特殊化リレーションシップを示し、データ構造の多様性をモデル化するために用いられる。例えば、eが、タイプvからタイプwへの特殊化であれば、vは、wの直接特殊化である。この場合、vの各インスタンスは、wの1つのインスタンスでもあり、また、逆に、wの各インスタンスは、vの1つのインスタンスであってもよい。このように、セマンティックモデルの1つのインスタンスの各オブジェクトは、そのモデルの1つ以上のタイプの1つのインスタンスである。1つのタイプの特殊化のペアは、互いに素である（即ち、インスタンスを共有しない）と明示することができる。

オブジェクト間のリレーションシップは全て、本質的には、n:1リレーションシップ（即ち、相関関係、即ち、1:nリレーションシップの逆）であるアトリビュートで定められる。eが、タイプvからタイプwへのアトリビュートであれば、vの各インスタンスは、アトリビュートeに関するwの1つのユニークなインスタンスに関連付けられる（参照する、と言う）。逆に、wの各インスタンスは、vのいくつか（すなわち0, 1, 2, …の1つ）のインスタンスと関連する。このように、タイプの外向きのアトリビュートは、単一の値を持っていると見ることができ、内向きのアトリビュートは、セットの値を持っていると見ることができる。

セマンティックモデルのスカラタイプは、（外向きの）矢を持たないタイプ、即ち、スカラタイプの直接特殊化である。直接特殊化は、（外向きの）アトリビュートを持たない。各スカラタイプbに対して、値のドメインを定める必要があリ、bの各インスタンスは、このドメインからの値を持つ。スカラタイプvからスカラタイプwへの特殊化があれば、そして、オブジェクトxが、vおよびwのインスタンスであれば、xの値は、vとwとに対して同じでなければならない。スカラアトリビュートは、スカラタイプを指すアトリビュートである。タイプがスカラでなければ、それは、コンポジットと呼ばれる。スカラタイプは、整数および記号列のような単純なタイプから、グラフィックスまたはマルチメディアにかかわる複雑なタイプにまで及ぶことができることに注意されたい。スカラタイプは、特有である必要がなく、スカラタイプ「0と100との間の値を持つ整数」のように、特定の制約を表現するために用いてもよい。

タイプvが、同一のタイプwの（即ち、を指す）2つ以上のアトリビュートを持っている場合、これらのアトリビュートを、役割（ロール）を用いて区別しなければならない。例えば、タイプ「人」は、役割「自宅」に属する1つ、役割「職場」に属する1つの、タイプ「電話番号」の2つのアトリビュートを持つ。このように、役割は、アトリビュートの意味を区別するために必要とされる。異なるタイプに、異なる定義（即ち、アトリビュートおよび役割）を持つことを要求するコンバーティビリティと呼ばれる制約を、セマンティックモデルに課することは理にかなったことである。タイプのインスタンスの見地からアサーションを行って、モデルのとりうるインスタンスを制限して、セマンティックモデルに静的な制約を加えてもよい。

上に与えたばかりのセマンティックモデルおよびオブジェクト指向インスタンスの定義は、セット、相関関係、および、グラフに基づいて、数学的に様式化することができる。インヘリタンス（継承）が、タイプグラフの構造に制限を課すことなく得られることに注意されたい。しかしながら、一般性を失うことなく、タイプグラフの特殊化を組み合わせて、循環パスを形成することはできないと仮定してもよい。

図形表記法
本発明は、セマンティックモデルおよび図形クエリを表わすために用いられる図形表記法の精確な詳細に依存しない。しかしながら、何らかの種類の表記法を、図形ユーザインターフェイスに用いる必要がある。本ドキュメントにおいては、セマンティックモデルのグローバルな態様についての理解を促進するのに便利な図形表記法を用いる。この表記法は、Ter Bekkeによって考案された表記法[Ter Bekke 1992年]に基づく。この表記法では、タイプは、それらの名前を内包する長方形として表現される。セマンティックモデルのグローバルな理解にとって必須でないスカラタイプは、描かれない。この表記法では、矢（即ち、アトリビュートまたは特殊化）を、矢じりをつけて描く必要はない。タイプvからwへの矢は、vの下辺から、wの上辺への接続として描かれる。図1に例示されているように、アトリビュートは、中央−中央接続として、特殊化は、角−角接続として描かれる。適切にタイプの位置を決めることによって、可能な限り多くの矢が、下向きの接続として描かれる。1つのタイプについての互いに素な特殊化は、重なり合った長方形を用いて描かれる。下向き方向にセマンティックモデルの描写を観察すると、インスタンスレベルで確定的なアサーションを読み取ることができる。下向きの中央−中央接続は、「1つのユニークな…に関連する」と読み取ることができ、下向きの角−角接続は、「1つの…である」と読み取ることができる。上向きの方向では、不確定のアサーションを読み取ることができる。上向きの中央−中央接続は，「いくつかの…に関連する」と読み取ることができ、上向きの角−角接続は、「1つの…であるかもしれない」と読み取ることができる。このように、描写ルールが、多くの透明性（わかりやすさ）に導く。

例えば、図1(a)を参照すると、この表記法は、タイプu ₁の各インスタンスが、タイプv ₁の1つのユニークなインスタンスと関連し、v ₁の各インスタンスが、u ₁の任意の数のインスタンスと関連していることを示している。図1(a)は、中央−中央接続であるから、アトリビュートに関するものである。

図1(b)においては、矢が、角−角接続であるから、このリレーションシップは、特殊化リレーションシップとして例示されている。それは、タイプu ₂の各インスタンスが、タイプv ₂の1つのインスタンスでもあり、v ₂の各インスタンスが、u ₂の1つのインスタンスでもあるかもしれないと、読み取ることができる。

この表記法を単純に拡張して、よく知られ、広く用いられているUML表記法[Booch等 1999年]の形式で、それと等価なものを得ることが可能である。それが、図2の例で例示されている。図2(a)は、2つのタイプuおよびvを持ち、そして、uからvへの2つの矢、即ち、アトリビュートと特殊化とを持つ、セマンティックモデルを表現している。アトリビュートをカーディナリティ情報で拡張することによって、また、特殊化の終端点として白三角を具えることによって、UML表記法を得る（図2(b)を参照）。このように、本明細書で用いられる図形表記法は、UMLの小さなサブセット（の単純化）と見ることができ、便利なレイアウト慣例を用いて、タイプグラフの透明で、グローバルな全体像を供給する。

図3は、セマンティックモデルのいくつかの具体的な例を挙げている。図3(a)は、部品供給業者(S)と部品(P)とに対するセマンティックモデルを提示している。第3のタイプ(SP)が、タイプSおよびPの両方を指すアトリビュートとともに用いられている。SPの各インスタンスは、部品と、この部品を供給する部品供給業者との組み合せを表わす。さらに、図3(a)には示されていない、部品供給業者と部品との両方に対して用いられるスカラタイプ「名前」がある。図3(a)を読むことによって、各インスタンスSPが、1つのユニークな供給業者および1つのユニークな部品と関連していることに気づく。さらに、各部品供給業者が、いくつかの組合せSPと関連し、また、各部品が、いくつかの組合せSPと関連していることに気づく。これは、m:nリレーションシップの一例を与える。Sの各インスタンスは、タイプSPを介して、Pの複数のインスタンスと関連することができ、また、Pの各インスタンスは、Sの複数のインスタンスと関連することができる。

図3(b)は、飛行機便に対するセマンティックモデルを提示している。各便は、2つの都市、即ち、出発地および到着地によって記述される。そのため、各便は、1つのユニークな出発地都市と関連し、また、1つのユニークな到着地都市と関連する。各都市は、いくつかの便と関連してもよい。タイプ 便からタイプ 都市への2つのアトリビュートの役割「出発地」および「到着地」は、図に表示されていない。

図3(c)は、単一の組織に対するセマンティックモデルを提示している。このモデルにおいて、従業員がおり、その大部分は、平社員でもある。タイプ 平社員からタイプ 従業員への2つの矢：各平社員が、一人の従業員であることを指示する特殊化、および、平社員の直接の上司である従業員を指示するアトリビュート、がある。

特殊化を用いる別の例示として、人々が、いくつかのタイプの品物（例えば、機械、乗り物など）の所有権を所有しており、そして、共有しているかもしれない状況を考える。リレーショナルな実装では、通常、各種類の所有権に対して、m:nリレーションシップが、導入されるであろう。しかしながら、ただ2つのもの：1つの「所有権」タイプと組み合わせて、前のタイプ（機械および乗り物）が特殊化となる、1つの追加のタイプ「所有物」、を導入するほうが、より魅力的である（図4を参照）。図4から、所有権が、一人のユニークな人間と関連していることを、見て取ることができる。所有権は、一つのユニークな所有物とも関連している。機械は所有物であり、乗り物は所有物である、等。各所有物は、いくつかの所有権と関連してもよい。

図5の例では、ソフトウェアプロセスに関する情報に対するセマンティックモデルが、示されており、2つの互いに素な特殊化「マスタ」および「スレーブ」を持つ1つのタイプ プロセスがある。1つのアトリビュートを用いて、各スレーブプロセスが、ある1つのマスタプロセスに対するセカンダリであるように割り当てられている。

ヌル値、および、m:nリレーションシップ
リレーショナルモデルのコンテキストでは、アトリビュートが、「任意選択（随意）」であることを可能にすること、即ち、アトリビュートが、ヌル値を持つことを可能にすることが、しばしば慣習になっている。セマンティックモデルおよびオブジェクト指向インスタンスのコンテキストでは、これは、特殊化によって実現できることに注意されたい。例えば、4つの任意選択のアトリビュートを持つタイプは、与えられたタイプの直接特殊化である、4つの追加のタイプを加えることによって記述できる。これらの特殊化タイプは、希望するアトリビュートを与えられる。もしかしたら用いられるかもしれない特殊化タイプの各組み合わせのために、特別のタイプを定める必要はない。インスタンスを共有する各タイプペアのために、「インターセクションタイプ」があるという仮定は、行わない。このように特殊化を系統だって用いることによって、ヌル値（オブジェクトから他のオブジェクトへの参照の）を受け入れる必要はない。

eが、タイプvからタイプwへのアトリビュートであれば、そして、オブジェクトxが、vの1つのインスタンスであれば、xは、アトリビュートeに関して、wの、あるn個のインスタンスに関連している。上述においては、nは、常に、1であると仮定した。しかしながら、図形クエリ、ユーザインターフェイス、フォームベースのアプリケーション、および、テキスト形式のレポートに関する本発明の成果は、n=1の仮定に頼るものではない。（しかしながら、）前のパラグラフにおいて、特殊化を、ヌル値の代わりに用いることができるから、n=0を受け入れる必要がないことを理解した。さらに、n>1が可能であることを受け入れる必要もない。2つのタイプuとvとの間のm:nリレーションシップは、追加のタイプwを、1つはwからuへの、1つはwからvへの2つのアトリビュート（n:1リレーションシップ）と組み合わせて、用いることによって実現することができる（図3の例と比較のこと）。追加のプリミティブとして、任意選択のアトリビュート（ヌル値）、および、m:nリレーションシップを導入することが可能である。任意選択のアトリビュートは、1つのタイプから別のタイプへの有向性の接続であり、m:nリレーションシップは、2つのタイプ間の無向性の接続である。これらの構成は、つい直前に記述したように、1つの特殊化と2つのアトリビュートとを、それぞれ、用いて、元のプリミティブで実現することができる。このように、追加のプリミティブとして、m:nリレーションシップを実現すれば、前に言及したばかりのタイプwの1つのインスタンスである、正確に1つの「接続のためのオブジェクト」が、uの1つのインスタンスである1つのオブジェクトと、vの1つのインスタンスである1つのオブジェクトとから成る、それに対応して関連する各ペアに対して存在する状況を維持することは理にかなったことである。セマンティックモデルの図形表記法は、任意選択のアトリビュートを、ダッシュを打つように描き、また、m:nリレーションシップを、垂直辺間の中央−中央接続として描くことによって、拡張することもできるであろう。

セマンティックモデルおよびオブジェクト指向インスタンスのリレーショナルリアライゼーション
上述のようなセマンティックモデルおよびオブジェクト指向インスタンスを実現する2つの仕方を記述する。最初に、リレーショナルモデルに基づくリアライゼーション、次に、XML形式のウェブデータの見地からのリアライゼーションを提示する。

リレーショナルリアライゼーションにおいては、1つのテーブルが、与えられたセマンティックモデルの各タイプに対して導入される。このテーブルは、タイプの1つのインスタンスである各オブジェクトに対して、1つのユニークなタプルを具えている（だけである）。主な考え方は、タイプvからタイプwへのセマンティックモデルにおける矢を、wのテーブルに対する外部キーである、vのテーブルのリレーショナルアトリビュートを用いて実装することができるということである。「グローバルオブジェクト識別子」を用いれば、全ての矢に対して、これをすることは必要ではなく、全てのセマンティックアトリビュートに対して、これをすれば十分である。（このセクションでは、セマンティックモデルのアトリビュートを、リレーショナルアトリビュートと区別するために、明瞭にするために、セマンティックアトリビュートと呼ぶ。）

要約すると、以下のリレーショナルアトリビュートでセマンティックモデルの各タイプvに対して1つのテーブルTvを定めるリレーショナルスキーマを用いて、セマンティックモデルを実現することができる。

− vのインスタンスであるオブジェクトをユニークに識別し、その結果、T _v 中のタプルのセットを、タイプvのインスタンスであるオブジェクトのセットと結びつけることができるようにするためのキーアトリビュートk _v 。
− vがスカラタイプである場合には、各オブジェクトの値を記述するアトリビュート（このアトリビュートのドメインは、スカラタイプのドメインである）。
− vから、あるタイプwへの、vの各セマンティックアトリビュートに対して、vのインスタンスであるオブジェクトxを記述するT _v 中のタプルにおいて、その値が、xによって参照されるオブジェクトの、テーブルT _w 中の、キー値であるアトリビュート。

キーアトリビュート値が、グローバルオブジェクト識別子として選ばれたときには,即ち、セマンティックモデルの各タイプペアv, wに対して、また、vとwとの両方のインスタンスである各オブジェクトxに対して、

であるとき、および、異なるオブジェクトx, yの各ペアにおいて、xがvのインスタンスであるような各タイプvに対して、また、yがwのインスタンスであるような各タイプwに対して、

であるときには、これらのアトリビュートで、十分である。キーアトリビュート値が、グローバルオブジェクト識別子に選ばれなかったときには、テーブルT _v に、以下のアトリビュートを加えるだけで、十分である。
− vからタイプwへの各特殊化において、vのインスタンスである各オブジェクトxに対して、値k _w (x)を持つアトリビュート。

タイプvからタイプwへの各セマンティックアトリビュートに対して、T _v に含まれるリレーショナルアトリビュートが、テーブルT _w に対する外部キーであることは明らかである。言い換えれば、1:n参照整合性制約が、テーブルT _v とT _w との間に定められる。キーアトリビュート値が、グローバルオブジェクト識別子として用いられない場合には、特殊化に用いられるリレーショナルアトリビュートに、より強い制約が存在する。タイプvからタイプwへの特殊化を実装する各リレーショナルアトリビュートに対して、また、テーブルT _w 中の各タプルに対して、T _v 中には、高々1つの関連するタプルしか存在してはならない。このより強い制約は、例えば、Accessシステムを用いたときに実現することができる。相異なるテーブルに対して、キーアトリビュート値を独立に導入することによって（即ち、グローバルオブジェクト識別子を用いずに）、タイプvからタイプwへの特殊化は、テーブルT _v からテーブルT _w への1:1参照整合性制約を用いて実施することができる。

セマンティックモデルおよびオブジェクト指向インスタンスの定義が、いくつかのさらなる静的な制約を、前に記述したばかりのリレーショナルスキーマに加えるべきであることを含意していることは明らかである。代替の１つのリレーショナルリアライゼーションにおいて、1つのタイプを、そのタイプのいくつかの特殊化とともに、それらの特殊化のセマンティックアトリビュートにヌル値を受け入れることによって、1つのリレーショナルテーブルに組み入れてもよい。

前に検討したばかりのセマンティックモデルおよびオブジェクト指向インスタンスのリレーショナルリアライゼーションは、セマンティックモデルの概念を、参照整合性制約のためのファシリティを組み込んでいるリレーショナルデータベース管理システムに適用することができることを明白にしている。このインタープリテーションにおいては、タイプは、リレーショナルテーブルとして見るべきであり、アトリビュートは、1:n参照整合性制約として見るべきであり、そして、特殊化は、1:1参照整合性制約として見るべきである。したがって、リレーショナルスキーマを、参照整合性制約とともに、セマンティックモデルの見地からインタープリトすることができる。インスタンスに関しては、オブジェクトは、このインタープリテーションにおいて、リレーショナルデータベーステーブル中のタプルによって記述されるエンティティとして見るべきである。このように、本発明のいくつかの成果は、本明細書で考察されるようなオブジェクト指向のフレームワークにおいて適切であるだけではなく、リレーショナルデータベース管理システムに適している。これには、特に、図形クエリ、ユーザインターフェイス、フォームベースのアプリケーション、および、テキスト形式のレポートに関連する成果が含まれる。以下に与えられる記述は、オブジェクトおよびリレーションシップ（参照）で表現されるが、本リレーショナルリアライゼーションを用いてリレーショナルコンテキストで表現し直すことができる。

XMLリアライゼーション
XML言語は、ワールドワイドウェブ上のデータ交換のための標準として出現した。ここで、一般的なセマンティックモデルおよびオブジェクト指向インスタンスのXMLリアライゼーションについて記述する。このXMLリアライゼーションは、前のセクションのリレーショナルリアライゼーションと類似している。前のセクションにおけると全く同様に、セマンティックモデルのアトリビュートを、セマンティックアトリビュートと呼ぶ。XMLにおけるアトリビュートは、XMLアトリビュートと呼ばれる。

1つのセマンティックモデルを与えられたとして、目的は、このモデルのインスタンスを、ある構造のXML文書の形式で表現することである。セマンティックモデルの各タイプに対して、XMLエレメントタイプを導入する。セマンティックモデルの各タイプvに対して、XMLエレメント木のルート（根）は、vのインスタンスである各オブジェクト毎に1つのユニークエレメントを含んでいる。オブジェクトxが、2つ以上のタイプのインスタンスであれば、いくつかのエレメントが、xに対して、このように導入される。インスタンスの各XMLリアライゼーションは、必然的に、意義をもたない順序付け情報を伴う。例えば、オブジェクトを記述するエレメントが現われる順序は、任意である。タイプのセット、および、それらのタイプに対するエレメントタイプも、v ₁,…,v _nと数え上げると、ルートエレメントのコンテントタイプは、XMLにおいて、例えば、

、
または、

と定義することができる。

グローバルオブジェクト識別子を用いたリアライゼーションでは、タイプvに対するエレメントタイプ宣言には、以下のXMLアトリビュートが、含まれる。
− オブジェクトをユニークに特徴づけるためのオブジェクト識別アトリビュート。
− vがスカラタイプである場合には、スカラ値アトリビュート。
− vからタイプwへの各セマンティックアトリビュートに対して、参照されるオブジェクトの該当するオブジェクト識別アトリビュートである値を持つ参照アトリビュート。

XMLは、ID値が、そのID値を帯びているエレメントをユニークに識別することを必要とするから、グローバルオブジェクト識別子を用いた、このXMLリアライゼーションでは、XMLのIDアトリビュートを使用することは不可能である。しかしながら、セマンティックモデルのタイプvに対するエレメントタイプのアトリビュートの、グローバルオブジェクト識別子を用いない、代替バージョンでは、IDアトリビュートおよびIDREFアトリビュートを用いることができる（これは、既に記述したグローバルオブジェクト識別子を用いないリレーショナルリアライゼーションと類似である）。

グラフベースのクエリ
上に説明したセマンティックモデルについて理解が得られれば、例えば、Microsoft社のAccessによって提示される、タイプの図形ユーザインターフェイスにおける使用に適合できるグラフベースのクエリのフォーマレーションに取り掛かることが可能である。

ベーシッククエリが、クエリタイプおよびクエリ矢から成るクエリグラフで定められる。各クエリタイプまたはクエリ矢は、それぞれ、セマンティックモデルのタイプグラフの、あるタイプまたは矢のコピーである。eが、タイプuからタイプvへの矢であれば、そして、e'が、クエリタイプu'からクエリタイプv'へのクエリ矢であれば、そして、e'が、eのコピーであれば、u'がuのコピーであり、そして、v'がvのコピーであることが必要とされる。この意味で、各タイプまたは矢の、それぞれ、元のタイプまたは矢への各コピーをマッピングする相関関係は、クエリグラフからタイプグラフへのホモモルフィズム（準同形）と呼ばれる。クエリ矢は、それが、アトリビュートまたは特殊化のコピーである場合には、それぞれ、クエリアトリビュートまたはクエリ特殊化である。クエリグラフは、タイプグラフと同じように描くことができる。選択および／または否定を，如何なるクエリタイプにも関連付けることができる。例えば、ある一定値が、スカラタイプのあるコピーのために必要であることを明示するために、選択を用いることができる。これを、定数選択と呼ぶ。選択の別の1つの例は、考察しているタイプの如何なるオブジェクトでも選択するワイルドカード選択である。スカラタイプ（否定の付いていない）のいくつかのコピーは、結果タイプであると定めることができる。以下に見られるように、これらの結果タイプは、射影によってクエリの結果を得るために用いられる。必然的にテキスト形式で、かつ、1列に並ぶSQLクエリと比較して、本明細書において考察されるようなグラフベースのクエリは、シンタクティックなノイズが、より少ないクエリの記述を与える。

クエリの結果を考察する前に、そのアプローチを、3つの例で例示することは有益なことである。ここで、図6を参照する。図6(a)は、図3(a)に現われて、前に説明されたタイプグラフである。図6(b)は、クエリ：部品P ₁を供給する部品供給業者に対する部品供給業者名を得る、に対するクエリグラフを示している。部品の選択P ₁が、クエリタイプPの下に指示されている。クエリタイプSの名前についての射影は、示されていない。図6(c)は、クエリ：部品供給業者S2によって供給されない、少なくとも1つの部品を供給する部品供給業者に対する部品供給業者名を得る、に対するクエリグラフを示している。このクエリグラフは、タイプPに対する1つのタイプコピー、および、タイプSPおよびSの各々に対する2つのタイプコピーを含んでいる。部品供給業者の選択S ₂が、クエリタイプS'の下に示されている。クエリタイプSP'の右上手角の記号は、否定を示している。

図7を参照すると、このクエリは、飛行機でない全ての乗り物を求めていることがわかる。

クエリの結果は、「オブジェクトのタプル」から成る中間結果の見地から定められる。各オブジェクトのタプルは、否定の付いていない各クエリタイプv'に対して、v'がコピーであるタイプvのインスタンスであるオブジェクトを含んでいる。u'およびv'が、否定の付いていないクエリタイプであるとする。そうすると、クエリタイプuからクエリタイプvへのアトリビュートeのコピーである、クエリタイプu'からクエリタイプv'へのクエリアトリビュートは、各オブジェクトのタプルが、uとvとの間のアトリビュートeに従って、u'およびv'に対するオブジェクトを含むことを示す。両方とも否定の付いていない、2つのクエリタイプu'とv'との間のクエリ特殊化は、各オブジェクトのタプルが、u'およびv'に対して同じオブジェクトを含まなければならないことを示す。各オブジェクトのタプルは、クエリの選択によって表される条件を満たすことを要求される。クエリ矢は、それらが、元のセマンティックモデルから導出される（即ち、コピーされる）ものであるから、本明細書において、内部ジョインとも呼ばれる。（古典的なリレーショナルな仕方で表されるようなクエリのジョインのほとんどは、クエリ矢になる。）クエリタイプv'が、否定（と、選択）を付けて現われた場合には、各オブジェクトのタプルに対して、v'がコピーであるタイプvのインスタンスであるオブジェクトxが、存在せず（選択を満たしながら）、したがって、xが、v'に接続されたクエリ矢に従って、そのタプルのオブジェクトと関連するということが要求される。選択、否定、および、射影に加えて、クエリグラフも、外部ジョイン、即ち、セマンティックモデルから導出されないジョインで拡張することができる。2つのクエリタイプu'とv'との間の外部ジョインについては、それぞれ、u'とv'とがコピーであるタイプuとvとが、タイプグラフ中の特殊化によって、恐らく間接的に、接続可能でなければならないことが必要とされる。さらに、中間結果における各オブジェクトのタプルが、u'とv'とに対して、同じオブジェクトを含まなくてはならないことが必要とされる。クエリの結果については、射影が、次のようになされる。中間結果における各オブジェクトのタプルに対して、結果タイプの値しか保存されない。このように、ベーシッククエリの結果は、元のセマンティックモデルのドメイン内の値から成るタプルのセットとして定められる。

図形クエリのいくつかの応用においては、ユーザが、結果の順序付けを可能にすることが重要になる。ベーシッククエリの結果セットは、そのクエリの1つ以上の結果タイプに対する順序（例えば、数字順またはアルファベット順）を定め、そして、それらの順序をレキシコ図形に結合して、ある順序にすることによって、順序付けることができる。以下で、クエリの応用について考察し、フォームベースのアプリケーション、および、テキスト形式のレポートを生成する。そのような応用においては、クエリの中間結果を順序付けることも、重要なことである。そのような順序付けは、否定の付いていないスカラタイプのいくつかのコピーに対する順序付けを、レキシコ図形に結合することによって、ユーザが、同様に定めることができる。

ベーシッククエリを普通に結合して、ユニオンクエリ、および、コンポジットクエリを形成することによって、豊富なクエリフォーマリズムが、得られる。クエリ構成に関する詳細を一般的に与える前に、一例を挙げる。

ここで、図8を参照して、リレーショナルな完璧さともいうべきものが得られることを例示する。全部品を供給する部品供給業者の名前を提示するコンポジットクエリが、提示される。図8(a)は、再度、図3(a)に現われ、そして、前に説明されたタイプグラフである。中間結果として、否定の付いたベーシッククエリが、部品供給業者と、この部品供給業者によって供給されない部品から成るペアを決定している（図8(b)）。このベーシッククエリは、Qで指示される。その結果には、全く部品を供給しない部品供給業者の名前が、含まれている。コンポジットクエリ、図8(c)において、クエリQは、スカラタイプ名を持つクエリタイプとして用いられている。コンポジットクエリの結果は、Qの結果に現われない部品供給業者のセットである。コンポジットクエリは、また、SのタイプコピーS''を用いている。S''とQとの間で名前を等しくするために、垂直辺間の中央-中央接続によって描かれた外部ジョインがある。

コンポジットクエリ
クエリ構成を定めるためには、最初に、ユニオンクエリを定めなければならない。セマンティックモデルMを与えられれば、Mに関するベーシックユニオンクエリは、等セットの結果タイプを持つMに関するベーシッククエリの有限のセットである。さらに、これらの結果タイプのいずれもが、ベーシックユニオンクエリに含まれる各クエリに対して、与えられたセマンティックモデル中の同じスカラタイプの1つのコピーであると仮定する。ベーシックユニオンクエリの結果は、含まれているクエリの結果のユニオンであると単純に定められる。

クエリ構成を定めるためには、さらに、結果モデル、および、結果インスタンスを定める必要がある。セマンティックモデルMに関するベーシッククエリの結果モデルは、そのベーシッククエリの各結果タイプに対する値を記述するスカラアトリビュートを持つ、1つのコンポジットタイプから成る、別のセマンティックモデルである。この結果モデルの各スカラタイプのドメインは、与えられたセマンティックモデルMの元のスカラタイプのドメインである。ベーシッククエリの結果モデルが、本質的に、リレーショナルテーブルであること、および、ベーシッククエリの結果が、結果モデルのインスタンス（結果インスタンスと呼ぶ）を定めることは明らかである。Mに関するベーシックユニオンクエリの結果モデルは、ベーシックユニオンクエリに含まれている任意のクエリの結果モデルである。ベーシックユニオンクエリの結果インスタンスは、ベーシックユニオンクエリに含まれているクエリの結果インスタンスが、オブジェクトを共有しないと仮定すると、それらの結果インスタンスの組み合わせである。この仮定は、以下のように、その正当性を示すことができる。即ち、セマンティックモデルのインスタンスのオブジェクトを、常に、そのときまでにまだ、そのインスタンス内にない、別のオブジェクトで置き換えることができることは、その置き換えられるオブジェクトの値および参照が、新しいオブジェクトに与えられる場合には、そして、その置き換えられるオブジェクトへの参照が、新しいオブジェクトへの参照によって置き換えられる場合には、明らかである。

ここで、再帰的に、クエリ構成を定めることができる。セマンティックモデルM、および、Mに関する有限数のクエリ

（例えば、ベーシッククエリ、または、ベーシックユニオンクエリ）を与えられると、元のセマンティックモデルMと、クエリ

の結果モデルとを含む、新しいセマンティックモデルM'を定めることができる。セマンティックモデルM'において、相異なるモデルからくるコンポジットタイプは、はっきり区別できる別々のタイプになり、また、M内の同じスカラタイプから生じるスカラタイプは、M'において互いに識別されるようになる。Mのインスタンスと、

の結果インスタンスとは、オブジェクトを共有しないと仮定すると（この仮定の正当性は、既に示されている）、これらのインスタンスを組み合わせて、M'のインスタンスを形成することができる。Mに関するクエリは、M'に関するベーシッククエリ、または、ベーシックユニオンクエリであると定義される。この回帰的定義では、クエリ依存性（クエリは、他のクエリに基づいて定められる）の有向グラフが、有限で、サイクルを持っていない（即ち、依存性のサイクリックな鎖は存在しない）、と仮定している。Mに関するベーシッククエリではない、Mに関するクエリを、Mに関するコンポジットクエリと言う。Mに関する各クエリに対して、結果モデル、および、結果インスタンスが、定められることは明らかである。クエリ構成のこの定義において、Mの同じスカラタイプvから生じる相異なるタイプは、十分な意味を持って外部ジョインを用いることができるように、M'の同じタイプv内に組み合わされる。

上述より明らかなように、図形クエリを、オブジェクトのコンテキスト、オブジェクトのタイプ、オブジェクト間のリレーションシップ、オブジェクトのタイプ間の特殊化リレーションシップで構成することができる便利な手段が、記述された。リレーショナルスキーマ、および、クエリを、そのフレームワークに変換すると、リレーショナルに完全なアプローチが得られることを理解できる。比較的複雑なクエリの構造を、直接的で、使い易い手法で、これまでの慣例にしたがって達成することができる。

クエリユーザインターフェイス
前のセクションから、有向グラフを用いて、したがって、ダイレクトマニピュレーションを用いて、セマンティックモデル、および、クエリを定めることができることは明らかである。セマンティックモデルに対する図形表記法は、実装のためにAccessのような図形リレーショナルツールを用いるときに適用することができ、そして、特に、より複雑なセマンティックモデルおよびクエリにおいて、タイプおよび矢を追跡するのに便利である。インヘリタンスは、特殊化によって扱われるので、便利で、十分に統合された仕方で扱うことができる。実際、特殊化を持たないセマンティックモデルに対してさえ、クエリの仕様を容易にするための一層の改良を提案することができる。既に指摘したように、古典的なリレーショナル形式のクエリのジョインのほとんどは、クエリのホモモルフィズムを介してタイプグラフに接続される内部ジョイン、即ち、クエリグラフのアトリビュートになる。したがって、クエリの構造に対するユーザインターフェイスは、ユーザが、クエリグラフの自動再描写のために、タイプグラフのいくつかのサブグラフを選択することを可能にすることができる。言い換えれば、ユーザは、タイプグラフから開始するコピー・アンド・ペースト操作によってクエリグラフを構築することができる。その後、ユーザは、外部ジョインのための接続を率直に描けば良いだけである。クエリの開発において、このように、タイプ間のあらかじめ定められたリレーションシップを洞察し、そして、それを用いることは、魅力的なことである。したがって、クエリのフォーマレーションにおいて、リレーションシップについてのこの情報の仕様を、何度も反復する必要はない。

更新可能なビュー、リトラクション
ここで、データ管理システムにおける図形クエリの開発に取り掛かる。与えられたセマンティックモデルに対する更新可能なビューは、ビューモデルと呼ばれる別のセマンティックモデルで実現することができ、そのタイプおよび矢は、前のセクションにおいて記述したクエリグラフの場合と同じように、元のセマンティックモデルのタイプおよび矢のコピーである。元のセマンティックモデルのインスタンスを、ビューモデルのインスタンスを定めるために用いることができる。後者のインスタンスを、リトラクションと呼ぶ。元のデータへの変更は、ビューモデルのリトラクトされたインスタンスを介して行うことができる。これは、視点を替えて情報の検査および変更を可能にする、フォームベースのアプリケーションを定めるために用いることができる。これらのアプリケーションは、図形に容易に明示することができる情報に基づいて、自動的に生成することができる。

ワールドワイドウェブに関連して、この手続きに関して関心を引くアプリケーションがある。XMLまたはHTMLを用いて、固定的で、直列的に（テキスト形式で）、ウェブ上に情報を提示することは、慣習的なことである。しかしながら、多くの場合に、セマンティックモデルを用いて、図形に表示される、ある情報の構造の概観を提示し、そして、ユーザが、図形クエリを用いて、特に望むビューを定めて、その結果を、特別に生成されたXMLを用いて提示することを可能にすることもできる。このように、ユーザは、情報の検査のために、さらには、その変更のためにさえ、自分自身のフォームベースのアプリケーションを定めることができる。

データの検査および変更のために提案する手続きを、一般的に記述する前に、ここで、図9を参照して、簡単に図形に明示される情報が与えられると、対話型のアプリケーションが、音楽に関係のある情報の検査および変更のために自動的に供給される一例を挙げる。そのセマンティックモデルの目的は、あらかじめ定めておくことのできるジャンル情報に基づいて、音楽演奏および演奏者に関する情報を記録することである。セマンティックモデルの主なタイプについては、以下のように説明することができる。音楽の各「作品」は、「作曲家」および「ジャンル」を用いて記述される。作品を演奏するためには、ピアノ協奏曲におけるピアニスト、オーケストラ、および、指揮者のような、いくつかの「役割」が必要である。あるジャンルの作品に用いられるデフォルト役割は、タイプ「役割−ジャンル」によって記述することができる。これらのデフォルト役割が、あるジャンルの作品に適していない場合には、この作品に用いられる役割は、代わって、タイプ「役割−作品」で記述しなければならない。これらのタイプ 役割−ジャンルと役割−作品とは、タイプ 役割のアトリビュートを持つタイプ「役割−使用」の互いに素な特殊化である。このように、タイプ 役割−ジャンルは、本質的に、タイプ 役割とジャンルとの間のm:nリレーションシップと見ることができ、それに対する例外は、タイプ 役割−作品を用いて明示することができる。具体的な例を挙げると、2台のピアノによるピアノ協奏曲は、ピアノ協奏曲ジャンルの3つの役割−ジャンルオブジェクトではなくて取り入れられた、4つの役割−作品オブジェクト（オーケストラ、指揮者、ピアニスト、ピアニスト）を持つ作品として記述することができる。1つの作品に対して、いくつかの演奏があってもよい。各演奏は、あるレコードしている「レーベル（レコード会社）」に属する。演奏の「関与」は、作品を演奏するために用いられる役割を実現する「演奏者」を記述する。静的な制約は、1つの作品（または、そのジャンル）の各役割−使用オブジェクトにおいて、その作品の各演奏に対して、高高1つの関与しかないということである。

ピアノ協奏曲の演奏に関する情報の検査および変更のための対話型のフォームベースのアプリケーションを作成することを望んでいるとする。図10に示されているように、ピアノ協奏曲の演奏について記述するフォームは、作曲家、作品、および、レコーディングの場所、時期、レーベルをリストしている。ピアニスト（単数または複数の）に対して、サブフォームがある。指揮者およびオーケストラに対して、サブフォームがあリ、それらのどちらも、1つのオブジェクトしか含まないと予想される。

このアプリケーションは、例えば、Microsoft社のAccessを用いることによって、図形に構築することができる。Accessを利用すれば、4つの別々の（図形に明示された）クエリに基づいて、4つのフォームを作って、それらを統合することができる。ここで、ただ1つのグラフベースのクエリに基づいて、そのような対話型のアプリケーションを開発するための、より簡単なユーザインターフェイスを記述する。このクエリが、図11に示されている。

指揮者、ピアニスト、および、オーケストラを選択するために、クエリグラフは、タイプ 関与、役割−使用、役割、および、演奏者の各々の3つのコピーを含んでいる。選択 ピアニスト、指揮者、オーケストラ、および、ピアノ協奏曲が、該当するクエリタイプの直下に表示されている。フォームベースのアプリケーションを自動的に生成するためには、このグラフベースのクエリを、特別に選択されたクエリタイプとしてジャンルを割り当てることによって、また、フォームタイプ（図11で、* によって指示されている）としてクエリタイプ 演奏を割当てることによって、また、サブフォームタイプ(図11で、記号 ~ によって指示されている）として以下のクエリタイプ：作曲家、作品、レーベル、演奏者 1、演奏者 2、演奏者 3を指示することによって、拡張することしか必要ではない。サブフォームタイプ 場所および時期は、図11に表示されていない。

図11は、既に言及したビューモデルの一例であるセマンティックモデル、即ち、クエリモデルを明示している。図9の元のセマンティックモデルのインスタンスは、リトラクションと呼ばれるクエリモデルのインスタンスを定めるものとして見ることができる。1つのオブジェクトが1つのインスタンスであるタイプが、クエリグラフにおいて、いくつかの相異なるコピーを持てば、リトラクションは、このオブジェクトのいくつかの相異なるコピー（各タイプコピーに対して1つのオブジェクトコピー）を含む。オブジェクト間のリレーションシップ、および、オブジェクトの値は、オブジェクトコピーによって、自然に引き継がれる。リトラクションに代えて、クエリの選択を考慮にいれると、そのクエリによって生成される、リトラクトされたサブインスタンスと呼ばれる、クエリモデルの、より小さなインスタンスが得られる。このリトラクトされたサブインスタンスでも、同一のオブジェクトについて、いくつかの相異なるコピーを含むことができる。例えば、図9のセマンティックモデルのインスタンスに、アシュケナージによって演奏され、かつ、指揮されたモーツァルトのピアノ協奏曲の演奏が含まれている場合には、リトラクトされたサブインスタンスには、役割 ピアニストに対して1つ、役割 指揮者に対して1つの、2つのアシュケナージオブジェクトが含まれる。

このように、図形クエリを用いて定められるビューモデル、および、そのリトラクトされたサブインスタンスは、対話型のフォームベースのアプリケーションを定めるのに有用である。ビューモデル、および、そのリトラクトされたサブインスタンスは、例えばXMLを用いて表わされる、テキスト形式のレポートを生成するために用いることもできることに注意されたい。フォームベースのアプリケーション、および、テキスト形式のレポートの自動生成のために、ユーザが、情報項目の順序付けを指定できることが好ましい。これをする理にかなった仕方は、既述のように、クエリの中間結果において、オブジェクトのタプルのセットに順序を定めることによるものである。

ベーシック更新操作
ここで、更新可能なビューの、より一般的な記述に取り掛かる。この目的のために、最初に、考察しなければならないインスタンスの変更の種類について考察する。セマンティックモデルのインスタンスの定義の結果として、インスタンスの変更は、以下のように定められる6つのベーシック更新操作に基づいて定めることができることは明らかである。

− 値割り当て：オブジェクトが、与えられたセマンティックモデルにおいて、特殊化を介して接続可能な1つ以上のスカラタイプに対して、新しい値を得る。それらのスカラタイプの各々に対して、そのオブジェクトは、同じ新しい値を得る。

− 参照割り当て：タイプvからタイプwへのアトリビュートe、および、vのインスタンスであるオブジェクトxに対して、wのインスタンスであるオブジェクトへのxの参照が、変えられる。

− オブジェクト作成：新しい1つのオブジェクトが、それが加えられるべきインスタンスが、インスタンスとなっている各スカラタイプに対して1つの値、および、それが加えられるべきインスタンスが、インスタンスとなっている各コンポジットタイプの各アトリビュートに対して1つの参照を持って、そのインスタンスに加えられる。

− オブジェクト削除：1つのオブジェクトが、それがインスタンスであるスカラタイプに対するその値、および、他のオブジェクトへのその参照とともに、そのインスタンスから削除される。これは、削除しようとする、そのオブジェクトへの参照が存在しない場合にしか、行うことができない。

− オブジェクトタイプ拡張：1つのオブジェクトが、それがまだインスタンスでなかったタイプのインスタンスになり、そのタイプがスカラであれば、新しい値を得て、また、そのタイプがアトリビュートを持っていれば、新しい参照を得る。

− オブジェクトタイプ縮小：1つのオブジェクトが、1つのタイプの1つのインスタンスであることを停止し、そのタイプがスカラであれば、そのタイプに対するその値を失い、そのタイプがコンポジットであれば、そのタイプのアトリビュートに対するその参照を失う。これは、そのオブジェクトが省略されるタイプを指すアトリビュートに関して、そのオブジェクトへの参照が存在しない場合にしか、行うことができない。

リトラクションを介する情報の更新
ここで、図形クエリを用いて定められるビューモデルが、情報の更新を可能にする仕方に関する詳細について記述する。1つのセマンティックモデルが、このセマンティックモデルのインスタンス、および、このセマンティックモデルに関するベーシッククエリとともに与えられたとする。ベーシッククエリが、そのクエリグラフから、そのセマンティックモデルのタイプグラフへのホモモルフィズムを定め、それは、クエリグラフの各タイプコピーまたは矢コピーを、それぞれ、タイプグラフの元のタイプまたは矢にマッピングする相関関係であることを、思い出されたい。そのベーシッククエリが、ビューモデルと呼ばれる別のセマンティックモデルを定める。ビューモデルの各スカラタイプが、元のセマンティックモデルのスカラタイプのコピーであると仮定する。ビューモデルのスカラタイプのドメインは、それがコピーであるタイプのドメインであるように選ばれる。

与えられたセマンティックモデル、インスタンス、および、ベーシッククエリが、共同して、次のように、リトラクションと呼ばれる、ビューモデルのインスタンスを定める。リトラクションの各オブジェクトは、元のインスタンスのオブジェクトのコピーである。xが、元のインスタンスの1つのオブジェクトであり、xが、与えられたセマンティックモデル中のタイプのセットVの1つのインスタンスであり、また、V'が、V中のタイプのコピーである、ビューモデル中のタイプのセットであるとする。W'が、V'のサブセットであり、W'の各タイプペアが、恐らくは間接的に、ビューモデル内の特殊化を介して接続することができ、また、W'が、そのプロパティを失わずに、V'中の他のタイプを含めるように拡張することはできないとする。そうすると、x'が、正確にW'中のタイプのインスタンスになるように、そのリトラクションに、xのオブジェクトコピーx'が、含まれる。リトラクションには、このようにして得られる、相異なるセットW'に対して相異なるオブジェクトが含まれ、これらは、リトラクション中のオブジェクトの全てである。v'が、ビューモデルのスカラタイプであり、v'が、vのコピーであり、xが、vのインスタンスであり、x'が、xのコピーであり、x'が、v'のインスタンスであれば、v'におけるx'の値は、vにおけるxの値に選ばれる。vが、元のセマンティックモデルのコンポジットタイプであり、eが、vのアトリビュートであリ、v'が、vのコピーであり、e'が、eのコピーであって、v'のアトリビュートであり、xが、vのインスタンスであり、x'が、xのコピーであって、v'のインスタンスであれば、e'に従ってx'によって参照されるオブジェクトは、eに従ってxによって参照されるオブジェクトのコピーであることを要求される。この最後の要求を、正確に一通りに実現することができることを理解するのは難しいことではない。

これは、リトラクションの定義を完成する。さらに、リトラクションのいくつかのサブインスタンスについて考察する必要がある。セマンティックモデルのインスタンスのサブインスタンスは、第1のインスタンスのオブジェクトのサブセットから成る、それらのオブジェクトの元の値および参照を持つ、第2のインスタンスである。ベーシッククエリによって生成される、リトラクトされたサブインスタンスは、既に検討したピアノ協奏曲の例におけるように、まず第1に、特別に選択されるように割り当てられたクエリタイプの選択を満たすオブジェクトを含むように定められる。さらに、リトラクトされたサブインスタンスには、他のオブジェクトも含まれる。リトラクションのオブジェクトxは、それが、既に言及した特別のクエリタイプの選択の1つを満たすオブジェクトを、恐らくは間接的に（即ち、恐らく、2つ以上のアトリビュートを介して）、参照していれば、そして、xが、クエリの選択を満たさないオブジェクトを、恐らくは間接的に、参照していなければ、リトラクトされたサブインスタンスの一部である。リトラクトされたサブインスタンスは、含まれている各オブジェクトの参照を組み込むために必要とされる、それらのオブジェクトも含めることにより完全に定められる。

リトラクションおよびリトラクトされたサブインスタンスについての、この検討を与えられると、グラフベースのクエリを介したインスタンスの変更についての記述が、残っている。リトラクション上に、または、リトラクトされたサブインスタンス上に認められ、実行されたベーシック更新操作の各々に関して、元のインスタンスへの、また、リトラクション（の残り）への一貫した組み込みに到達する必要がある。リトラクション中のオブジェクトx'を伴う変化は、常に、それがコピーであるオブジェクトxに、また、xの他のオブジェクトコピーにも、反映されるということに注意することは、重要なことである。リトラクションの定義は、ベーシック更新操作の各々において、インスタンスの変更を、リトラクションに組み込むことができるということ、および、その逆、を示す。要点は、インスタンスを与えられると、リトラクション中の値および参照が、常に、ユニークに定まるということである。例えば、x'が、アトリビュートe'においてy'への参照を持つ、オブジェクトxのコピーであり、一方、y'は、yのコピーであり、e'は、eのコピーである、とする。z'が、オブジェクトzのコピーであり、また、y'へのx'の参照（e'における）が、z'への参照に変わる、とする。そうすると、xの参照（eにおける）は、zへの参照に変わり、そして、次には、対応するxの他のコピーの各参照も、リトラクションのプロパティを維持するようにユニークに変わる。リトラクトされたサブインスタンスの変更の組み込みのために、ベーシック更新操作のうちの3つ、すなわち参照割り当て、オブジェクト作成、および、オブジェクトタイプ拡張に対して、さらなる仮定をなさなければならない。例えば、リトラクトされたサブインスタンスへの参照割り当てについては、リトラクションに結果として生じる参照更新が、リトラクトされたサブインスタンスへの仮定に違反しない、即ち、クエリの選択に従うと仮定される。オブジェクト作成およびオブジェクトタイプ拡張も、類似の仮定に従う。

フォームベースのアプリケーション
図9-11の例は、データの検査および変更を可能にする、可能な限り複雑なフォームベースのアプリケーションでも、セマンティックモデルを基にした、ただ1つのベーシッククエリで定めることができることを例示している。更新に関する、前のセクションにおける素材を用いて、ここで、この手続きを一般的に記述することができる。セマンティックモデル、および、このモデルを基にしたベーシッククエリが与えられ、そして、そのベーシッククエリの各スカラタイプが、セマンティックモデルのスカラタイプのコピーである、とする。そのベーシッククエリが、否定を含まず、そして、各選択が、定数選択、または、ワイルドカード選択である、とする。さらに、あるクエリタイプが、フォームタイプに選ばれ、また、いくつかの他のクエリタイプが、サブフォームタイプに選ばれ、また、選択の付いた、いくつかのクエリタイプが、特別に選択されたクエリタイプに選ばれる、とする。これらのタイプ間のリレーションシップを、より正確に記述するためには、クエリグラフ中のいくつかのパスを考慮しなければならない。一般に、タイプv'からタイプw'への、クエリグラフ中のパスは、正方向または逆方向の矢（即ち、アトリビュートまたは特殊化）を含む。クエリグラフ中に、正方向のアトリビュート、および、正方向の特殊化だけから成る、フォームタイプから、特別に選択されたクエリタイプへのパスがあると仮定する。3種類のサブフォームタイプを考える。フォームタイプをv'で、サブフォームタイプをw'で表して、クエリグラフに、正方向のアトリビュートと、正方向または逆方向の特殊化とを用いた、v'からw'へのパスがあるか、w'からv'へのアトリビュートがあるか、タイプu'と、u'からw'へのアトリビュートと、u'からv'へのアトリビュートとがある、と仮定する。図11のクエリグラフが、これらの条件を満たすことは明らかである。さらに、フォームタイプv'のインスタンスであるオブジェクトを表示することができるフォームを、その第1のオブジェクトと関係するオブジェクトを表示する、サブフォームタイプw'に対するサブフォームとともに、自動的に生成することができることは明らかである。より正確には、フォームとサブフォームとのシステムは、クエリのリトラクトされたサブインスタンス中のオブジェクトのタプルを表示する。フォームに表示された各オブジェクトにおいて、高々1つのオブジェクトしか、第1のタイプのサブフォームに表示されず、また、如何なる数のオブジェクトでも、第2および第3のタイプのサブフォームに表示できることは明らかである。フォーム、または、サブフォームは、それぞれ、フォームタイプ、または、サブフォームタイプのスカラタイプに対する値を表示する。フォームまたはサブフォームに表示されたオブジェクトが、それぞれ、対応するフォームタイプまたはサブフォームタイプの特殊化のインスタンスでもある場合には、それらの特殊化のスカラアトリビュートに対する値を、表示することもできる。データに対する変更は、前のセクションにおいて記述した手続きを用いて、そのようなフォームベースのアプリケーションで行うことができる。第3の種類のサブフォームタイプw'に対するオブジェクトの作成は、既述の、フォームタイプv'にw'を接続するタイプu'の追加オブジェクトの作成を必要とすることに注意されたい。この場合、v'の1つのインスタンスである1つのオブジェクトと、w'の1つのインスタンスである1つのオブジェクトとから成る各ペアに対して、u'の1つのインスタンスである、正確に1つのそのような「接続のためのオブジェクト」が存在する状況を維持することは、理にかなったことである。

このように記述されたセットアップの一般化が、サブフォームタイプに対して、さらに、サブサブフォームタイプを割り当てることができることに注目することによって得られる。そのようなサブサブフォームタイプは、サブフォームタイプとフォームタイプとの間のリレーションシップについて上に仮定したと同等の、サブフォームタイプに対する関係をとると仮定する。これは、サブフォームを含み、そのサブフォームが、さらに、サブフォームを含むことができるような、メインフォームから成るフォームベースのアプリケーションの構造を可能にする。これは、ただ1つのベーシッククエリを用いて、サブフォームの任意の深さのネスティング（入れ子）を持ち、そして、セマンティックモデルのインスタンスに関する特別のビューを提示し、また、管理するフォームベースのアプリケーションを構築するように、さらに拡張することができる。

フォームベースのアプリケーションを通じてデータの検査しか望まれず、変更がないときには、ベーシッククエリが、否定を含んでいないという仮定を行う必要がないということに注意されたい。しかしながら、この場合には、フォームタイプおよびサブフォームタイプが、否定の付いていないクエリタイプであることを、仮定しなければならない。

さらに、フォームベースのアプリケーションに関するこれらの考察において、フォームおよびサブフォームの項目の精確なレイアウトに関する論点を組み込んでいないということに注意されたい。本発明は、容易に明示可能な図形情報に基づく、フォームベースのアプリケーションの構造および機能の自動生成に関するものである。そのようなフォームベースのアプリケーションに対する特定のレイアウトを設計することは、必要なままにしておく。フォームベースのアプリケーションの構造および機能を与えられれば、このことは、例えば、Accessシステムによって利用可能になるような、使いやすいファシリティを用いて行うことができる。同様の言及が、次のセクションで検討されるテキスト形式のレポートにも当てはまる。

テキスト形式のレポート
ビューモデル（グラフベースのクエリを用いて構築された）を、テキスト形式のレポートを自動的に生成するために用いることもできることは、既述した。これは、前のセクションで検討したフォームベースのアプリケーションの自動生成と類似に進めることができる。1つのセマンティックモデルに対するベーシッククエリが与えられ、そして、そのクエリの各スカラタイプが、そのセマンティックモデルのスカラタイプのコピーである、とする。さらに、否定の付いていない、あるクエリタイプが、レポートタイプに割り当てられていると仮定し、また、否定の付いていない、いくつかの他のクエリタイプを、サブレポートタイプに割り当ててもよい。フォームベースのアプリケーションにおけるとまさに同様に、選択の付いている、いくつかのクエリタイプを、特別に選択されたクエリタイプに割り当てることが可能である。レポートタイプおよびサブレポートタイプは、フォームタイプおよびサブフォームタイプに対して前のセクションで仮定したのと同等のリレーションシップを満たすと仮定する。テキスト形式のレポートの仕様は、いくつかの順序付けを明示することによって、より完全にすることができる。例えば、ある順序付けを、サブレポートタイプに明示することができる。レポートタイプにおいて、および、各サブレポートタイプにおいて、ある順序付けを、そのスカラクエリタイプに明示することができる。さらに、ある順序付けを、ベーシッククエリによって定められるビューモデルのリトラクトされたサブインスタンス中のオブジェクトのタプルに明示することができる。これは、好ましくも、否定の付いていないスカラタイプに関して行うことができる。これらの仕様を、ベーシッククエリによって定められたビューモデルのリトラクトされたサブインスタンスを提示するテキスト形式のレポートを自動的に生成するために用いることができる。レポートタイプのインスタンスである各オブジェクトについて、レポートは、そのレポートタイプの全てのスカラクエリタイプに対する値を提示し、また、全てのサブレポートタイプに対するサブレポートを提示する。各サブレポートは、そのサブレポートタイプの全てのスカラアトリビュートに対する値を提示する。フォームベースのアプリケーションにおけるとまさに同様に、レポートまたはサブレポートに表示されたオブジェクトが、対応するレポートタイプまたはサブレポートタイプの特殊化のインスタンスでもあるときには、それらの特殊化のスカラアトリビュートに対する値を表示することもできる。そのようなネストされた（入れ子状にされた）テキスト形式のレポートは、標準のウェブ言語XMLを用いて実現することもできるであろう。フォームベースのアプリケーションにおけるとまさに同様に、それと類似の方法で、サブレポートの、より深いネスティングを実現することができることに注意されたい。このように、ただ1つの図形クエリに基づいて、可能な限り複雑なテキスト形式のレポートを構築することができる。

本明細書において、テキスト形式のレポートと呼んでいるものは、決して、テキストの提示に制限されるものではないことに注意されたい。既述のように、スカラタイプには、複雑な図形オブジェクトまたはマルチメディアオブジェクトを、含めてもよい。より標準的な用語 テキスト形式のレポートの代わりに、用語「情報シリアライゼーション（情報直列化）」が、意図する意味を、よりよく記述するかもしれない。

セマンティックモデル：表現度
本明細書で考察されるグラフベースのクエリ、および、それらのアプリケーションは、セマンティックモデル、および、それらのインスタンスの定義に基づいている。本発明の構成においては、モデリングプリミティブの数は、最小限にされるが、それにもかかわらず、セマンティックモデルのフォーマリズムは、大きな表現能力を持っている。多くのデータモデリング構成体を、セマンティックモデルの見地から様式化することができる。例えば、リレーショナルスキーマは、各矢が、スカラアトリビュートであるセマンティックモデルとして見ることができる。一般的なオブジェクト指向インスタンスを、コンポジットタイプの、そのコンポジットタイプの各スカラアトリビュートに対して同じ値を持つ、2つのオブジェクトを含まない「値ベースのインスタンス」に制限すると、標準のインスタンスが得られる。セマンティックモデルという用語で、そのリレーショナルモデルが、アトリビュートの1「レベル」をサポートしていると判断されるかもしれない。周知のエンティティ−リレーションシップモデルによるスキーマは、アトリビュートの2「レベル」を持つセマンティックモデルとして表現することができる。エンティティは、タイプで記述することができ、そのアトリビュートの各々は、スカラであり、また、リレーションシップは、そのような「エンティティタイプ」を指すアトリビュートを持つタイプとして見ることができる。次に、1:nリレーションシップを、追加のアトリビュートで置き換えることができることは明らかである。isaリレーションシップは、特殊化を用いて扱うことができる。

前の文において、ユーザが、フレンドリにデータにインターフェイスすることを可能にするように、セマンティックモデリングを実施することができる方法が、記述された。セマンティックモデル、および、オブジェクト指向インスタンスに基づいた、このデータモデリングフォーマリズムは、リレーショナルモデルの拡張として見ることができ、リレーショナルモデルと、いくつかの重要な強み：データ独立性、ビュー独立性、ベーシックプリミティブの単純性、を共有する。これは、セット、相関関係、および、グラフの見地から、数学的に様式化することができる。リレーショナルモデルで実現されない、いくつかの目的が、達成される。即ち、情報モデラは、オブジェクト、タイプ、オブジェクト間のリレーションシップ、および、特殊化で、データのセマンティックスを表現することができる（ベーシックプリミティブは、可能な限り単純に、これを達成するように選ばれた）。図形クエリユーザインターフェイスを、グラフベースのクエリを用いて、これらのオブジェクト指向プリミティブで直接的に考察することができる。これらのグラフベースのクエリを、対話型データベースアプリケーションの形式の更新可能なビューを構築する、または、可能な限り複雑なテキスト形式のレポートでも構築する、使い易い仕方を実現するために用いることができる。

インヘリタンスが、タイプグラフの構造を限定する仮定を置くことなしに実現される。一般的なセマンティックモデル、および、オブジェクト指向インスタンスを、リレーショナルモデルで、または、ウェブデータ(XML)の形式で、比較的容易に実施することができる。セマンティックモデルに基づいて、クエリの簡潔な抽象記述が得られた。セマンティックモデルは、タイプグラフを用いて表現され、クエリは、クエリグラフからタイプグラフへのホモモルフィズムを持つ、そのクエリグラフを用いて表現される。リレーショナルモデルに限定すると、本明細書において定義されたグラフベースのクエリが、リレーショナルに完全なクエリフォーマリズムを形成する。図形ユーザインターフェイスによる、平易な非手続き型のアクセスを、一般的なセマンティックモデル、および、オブジェクト指向インスタンスに拡張することができる。クエリをセットアップするためのユーザインターフェイスは、外部ジョイン（即ち、タイプグラフから導出されないジョイン）を描写するファシリティと組み合わせて、クエリグラフへの組み込みのためのタイプグラフのサブグラフのマーキングをサポートすることによって、単純化できる。対話型データベースアプリケーションの相当のクラスを、クエリグラフで定められる、更新可能なビューとして、平易に、図形に開発することができる。種々の相異なる規則構造のサブフォーム（または、サブレポート）の可能な限り複雑なネスティングを持つ、それぞれ、フォームベースのアプリケーション、または、テキスト形式のレポートを、ただ1つの図形クエリを用いて構築することができる。

上述において、Microsoft社のAccessシステムが参照されているが、本発明の教示が、そのようなシステムに限定されるものではないこと、また、記述した原理が、一般的に、データベースアプリケーションに、さらには、また、必ずしもデータベースに表示されていない情報、例えば、ワールドワイドウェブ上の情報の管理にも、直接適用可能であることは、当然のこととして認識されるところである。

[Booch等 1999年]
Booch, G., Rumbaugh, J., Jacobson, I.、1999年、The Unified Modeling Language User Guide（統一モデリング言語ユーザガイド）、Addison-Wesley (Reading, Mass.)
[Codd 1970年]
Codd, E.F.、1970年、A relational model of data for large shared data banks（大規模共有データバンクのためのデータのリレーショナルモデル）、Comm. ACM 13, 6, 377-387頁
[Codd 1982年]
Codd, E.F.、1982年、Relational databases: a practical foundation for productivity（リレーショナルデータベース：生産性のための実践的な基礎）、Comm. ACM 25, 2, 102-117頁
[Ter Bekke 1992年]
Ter Bekke, J.H.、1992年、Semantic Data Modelling（セマンティックデータモデリング）、Prentice-Hall (New York)
[Tsichritzis, Klug 1978年]
Tsichritzis, D.C., Klug, A.、1978年版、The ANSI/X3/SPARC DBMS Framework: Report of the Study Group on Data Base Management Systems（データベース管理システムに関するスタディグループ報告）、Information Systems 3, 173-191頁

セマンティックモデルのための図形表記法を例示する。 図1に等価なUML表記法を示す。 セマンティックモデルの3つの例を示す。 種々のタイプの品物の所有権が存在する状況を例示する線図的なモデルである。 ソフトウェアプロセスに関する情報のセマンティックモデルを例示する。 グラフベースのクエリが、いかにして、セマンティックモデルタイプグラフに基づいて構築できるかを例示する。 飛行機に関するクエリのフォーマットを例示する。 セマンティックモデルタイプグラフに基づいたコンポジットクエリの構造を例示する。 音楽の演奏および演奏者に関する、より複雑なセマンティックモデルの一例である。 図9を用いて、対話型の情報の検査および変更を、いかにして達成できるかを示すフォームベースのアプリケーションの一例である。 図9を用いて、対話型の情報の検査および変更を、いかにして達成できるかを示す複雑なグラフベースのクエリを例示する。

Claims (26)

1. データ管理システムのための図形ユーザインターフェイスであって、
   データベース内のデータ構造を定めるセマンティックモデルを、図形フォーマットに定める手段と、
   当該セマンティックモデルを用いて、データベースクエリを定める手段と、を有する図形ユーザインターフェイスにおいて、
   前記セマンティックモデルが、オブジェクトのタイプ、および、タイプを相互にリンクして、当該タイプ間のリレーションシップを定めるアトリビュートおよび特殊化を有するタイプグラフを有することを特徴とする図形ユーザインターフェイス。
2. 当該タイプグラフは、タイプが、特定の仕方で表わされ、そして、タイプ名と結び付けられる、また、アトリビュートおよび特殊化が、タイプを、相互にリンクさせるように表わされる、あらかじめ定められた図形表記法にしたがって表わされる、請求項1に記載の図形ユーザインターフェイス。
3. 当該セマンティックモデルを用いる当該手段が、当該タイプグラフを用いて、クエリグラフを定めるステップを有する、請求項1に記載の図形ユーザインターフェイス。
4. 当該クエリグラフが、当該タイプグラフのタイプ、アトリビュート、および、特殊化から、それぞれ、導出されるクエリタイプ、クエリアトリビュート、および、クエリ特殊化を有する、請求項3に記載の図形ユーザインターフェイス。
5. クエリタイプが、選択および／または否定と関連付け可能である、請求項4に記載の図形ユーザインターフェイス。
6. クエリグラフが、タイプグラフに実行されるコピー・アンド・ペースト操作によって構築可能である、請求項4に記載の図形ユーザインターフェイス。
7. クエリグラフが、さらに、少なくとも1つの他のクエリグラフへの参照を有する、請求項4に記載の図形ユーザインターフェイス。
8. 対話型のフォームベースのアプリケーションが、クエリグラフの構築によって実現可能である、請求項4に記載の図形ユーザインターフェイス。
9. 前記フォームベースのアプリケーションが、ネストされたサブフォームを持つフォームを有する、請求項8に記載の図形ユーザインターフェイス。
10. データの変更が、前記フォームベースのアプリケーションを用いて達成可能である、請求項8に記載の図形ユーザインターフェイス。
11. テキスト形式のレポートが、クエリグラフの構築によって実現可能である、請求項4に記載の図形ユーザインターフェイス。
12. 前記テキスト形式のレポートが、ネストされた、種々の相異なる規則構造のサブレポートを含む、請求項11に記載の図形ユーザインターフェイス。
13. データベース内のデータ構造を定めるセマンティックモデルを、図形フォーマットに定めるステップと、
    当該セマンティックモデルを用いて、データベースクエリを定めるステップと、を有する、データ管理システムにおける図形クエリを提示、管理するための方法であって、
    前記セマンティックモデルが、オブジェクトのタイプ、および、タイプを相互にリンクして、当該タイプ間のリレーションシップを定めるアトリビュートおよび特殊化を有するタイプグラフを有することを特徴とする方法。
14. 当該タイプグラフが、あらかじめ定められた図形表記法にしたがって表わされ、また、特定の仕方で表わされ、そして、タイプ名と結び付けられるタイプと、タイプを相互にリンクさせるように表わされるアトリビュートおよび特殊化と、を有する請求項13に記載の方法。
15. 当該セマンティックモデルを用いるステップが、当該タイプグラフを用いて、クエリグラフを定めるステップを有する、請求項13に記載の方法。
16. 当該クエリグラフが、当該タイプグラフのタイプ、アトリビュート、および、特殊化から、それぞれ、導出されるクエリタイプ、クエリアトリビュート、および、クエリ特殊化を有する、請求項15に記載の方法。
17. クエリタイプが、選択および/または否定と関連付け可能である、請求項16に記載の方法。
18. クエリグラフが、タイプグラフに実行されるコピー・アンド・ペースト操作によって構築可能である、請求項16に記載の方法。
19. クエリグラフが、さらに、1つ以上の他のクエリグラフへの参照を有する、請求項16に記載の方法。
20. 対話型のフォームベースのアプリケーションが、クエリグラフの構築によって実現可能である、請求項16に記載の方法。
21. 前記フォームベースのアプリケーションが、ネストされたサブフォームを持つフォームを有する、請求項20に記載の方法。
22. データの変更が、前記フォームベースのアプリケーションを用いて達成可能である、請求項20に記載の方法。
23. テキスト形式のレポートが、クエリグラフの構築によって実現可能である、請求項16に記載の方法。
24. 前記テキスト形式のレポートが、ネストされた、種々の相異なる規則構造のサブレポートを含む、請求項23に記載の方法。
25. 請求項1から12のいずれか1つに記載の図形ユーザインターフェイスを有するデータ管理システム。
26. コンピュータプログラム製品であって、請求項25に記載のデータ管理システムとして機能するように、当該コンピュータプログラム製品を実行するときに、プログラム可能なデバイスをイネーブルにするコンピュータプログラム製品。

Images