JP2018500680A - レポートの構築 - Google Patents

Abstract

レポートを構築するために、コンピュータ記憶媒体上に符号化されたコンピュータプログラムを含む、方法、システム、および装置。方法のうちの１つは、関係構造化データに基づいてモデルを作成することを含み、構造化データはデータ構造を含み、各データ構造はデータ要素を有し、各データ要素はフィールドを有し、各フィールドは名前を有する。方法は、モデル内にオブジェクトの階層を生成することを含み、階層は、オブジェクト上の関係フィールドに従い、開始オブジェクトに関してオブジェクトを編成する。方法は、階層内のオブジェクトのうちの１つまたは複数についての要素を含むユーザインターフェースを生成することを含み、ユーザインターフェースは、ユーザがレポートを作成し、新しい名前を使用してレポートをフィルタリングできるようにするものである。方法は、要素からの要素のユーザ選択を受信することを含む。方法は、レポートを生成することも含む。

Description

本明細書は、レポートの構築に関する。

データベースは大量の情報を記憶することができる。情報が記憶される様式は、必ずしも直観的ではない。代わりに、データベースの構造は、参照整合性の維持、アクセスの速度、および冗長性の最小化などの要因に基づいて決定される。論理的にまとめてグループ化することができるデータを、別々のエンティティに記憶することが可能である。複雑な関係は、物理的な対応先を持たない追加のエンティティを追加することによって解決可能である。

一般に、本明細書で説明する本主題の態様１は、構造化データに基づいてモデルを作成するアクションを含む方法において具体化可能であり、構造化データはデータ構造を含み、各データ構造はデータ要素を有し、各データ要素はフィールドを有し、各フィールドは名前を有する。モデルを作成することは、構造化データ内のデータ構造に基づいてモデル内にオブジェクトを作成すること、データ構造内のフィールドの名前を自然言語名に変換すること、新しい名前を有するオブジェクト上にフィールドを作成すること、および、構造化データ内のデータ構造間の関係に基づいてオブジェクト上に関係フィールドを作成することを含む。方法は、モデル内にオブジェクトの階層を生成することを含み、階層は、オブジェクト上の関係フィールドに従い、開始オブジェクトに関してオブジェクトを編成する。本態様は、階層内の１つまたは複数のオブジェクトについての要素を含むユーザインターフェースを生成することを含み、ユーザインターフェースは、ユーザがレポートを作成し、新しい名前を使用してレポートをフィルタリングできるようにするものである。方法は、要素からの要素のユーザ選択を受信することを含む。方法は、要素に対応するデータ構造を識別することを含むレポートを生成すること、データソース内で識別されたデータ構造内の少なくとも１つのフィールドからデータを取得すること、および、データをユーザに提示することを含む。

態様２は態様１に従い、名前を変換することは、ルックアップテーブルを使用して名前を変換することを含み得る。

態様３は態様１または２のいずれかに従い、関係フィールドは、データ構造内の１データ要素と第２のデータ構造内の第２の１データ要素との間の関係を表す参照フィールドとすることができる。

態様４は態様１、２、または３のいずれかに従い、関係フィールドは、データ構造内の１データ要素と第２のデータ構造内の第２のデータ要素との間の関係を表す集合フィールドとすることができる。

態様５は態様１、２、３、または４のいずれかに従い、ユーザインターフェースは、集合フィールド上で使用可能な集約関数を含むことができる。

態様６は態様１、２、３、４、または５のいずれかに従い、関係フィールドは、データ構造内の１データ要素とデータ構造内の第２のデータ要素との間の関係を表す親子フィールドとすることができる。

態様７は態様１、２、３、４、５、または６のいずれかに従い、構造化データは構造化データベースとすることができ、データ構造は構造化データベース内のテーブルである。

態様８は態様１、２、３、４、５、６、または７のいずれかに従い、構造化データは１つまたは複数のファイルとすることができる。

態様９は態様１、２、３、４、５、６、７、または８のいずれかに従い、レポートを生成することは、ユーザ選択の受信に応答して生じ得る。

態様１０は態様１、２、３、４、５、６、７、８、または９のいずれかに従い、ユーザインターフェースは、見たままが得られる（what-you-see-is-what-you-get）インターフェースを使用したレポートのインタラクティブな作成を可能にし、ユーザインターフェースは、データ値を含むレポートの視覚フィードバックを、レポートのファイナライズ前にほぼリアルタイムで提供することができる。

態様１１は態様１、２、３、４、５、６、７、８、９、または１０のいずれかに従い、ユーザインターフェースを生成することは、開始オブジェクトの選択をユーザから受信することをさらに含むことができる。

態様１２は態様１、２、３、４、５、６、７、８、９、１０、または１１のいずれかに従い、自然言語名は、構造化データに関する限定文字のセット内の少なくとも１つの文字を含むことができる。

態様１３は態様１、２、３、４、５、６、７、８、９、１０、１１、または１２のいずれかに従い、構造化データ内のデータ構造間の関係に基づいてオブジェクト上に関係フィールドを作成することは、構造化データ内の主キー対外部キーの関係を表すために関係オブジェクトを作成することを含むことができる。

本態様の他の実施形態は、対応するコンピュータシステム、装置、および、１つまたは複数のコンピュータ記憶デバイス上に記憶されたコンピュータプログラムを含み、各々が方法のアクションを実行するように構成される。１つまたは複数のコンピュータのシステムは、動作中、システムにアクションを実行させる、システム上にインストールされたソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを有することによって、特定のアクションを実行するように構成可能である。１つまたは複数のコンピュータプログラムは、データ処理装置によって実行された場合、装置にアクションを実行させる命令を含むことによって、特定のアクションを実行するように構成可能である。

態様は、以下の利点のうちの１つまたは複数を含むことができる。レポートはリアルタイムで更新可能であり、ユーザはレポートの反響を即時に見ることができる。レポートは迅速に作成可能である。

本発明の他の特徴および利点は、以下の説明から、および特許請求の範囲から、明らかとなるであろう。

レポートを構築するための環境の例を示す図である。 リレーショナルデータベースをメタモデルにマッピングする例を示す図である。 レポートを構築するためのユーザインターフェースの例を示す図である。 レポートを構築するためのユーザインターフェースの例を示す図である。 レポートを構築するためのユーザインターフェースの例を示す図である。 レポートを構築するためのユーザインターフェースの例を示す図である。 レポートを構築するための例示的プロセスを示すフローチャートである。 レポートを構築するための例示的プロセスを示すフローチャートである。

レポーティングツールとは、データベース、ＸＭＬストリーム、またはスプレッドシートなどのソースからデータを取り、これを使用して特定の人間の読者を満足させる形式で文書を生成することを目的とする、コンピュータプログラムである。従来のレポーティングツールにおいて、熟練したユーザは、特定のレポートまたはレポートのセットのためのデータにアクセスできるビューをセットアップする。通常、ビューは、基礎となるデータ（たとえば、データベースの関係モデル）の構造を理解する技術系ユーザによってセットアップされる。ビューは、レポートを生成するために従来のレポートビルダによって使用および操作される。しかしながら、ビューのセットアップは手動プロセスであるため、ビューは典型的には基礎となるデータ方式の小部分を反映するか、または特定のビジネス上の問題に特有であり得る。

加えて、これらのビューは、通常、ユーザフレンドリなデータの表現を示さない。ビューは、通常、レポーティングツールのエンドユーザにとって直観的でない可能性のある関係モデル内に表される通りに、フィールドを提示する。

これに対してここで提示される手法は、レポートの作成プロセスを、エンドユーザにとってかなり直観的、インタラクティブ、および効率的にする、２つの新規な要素を含む。

その第１は、関係データをビジネスフレンドリな用語で記述するメタモデルの作成概念である。関係は、直観的な階層メタモデルを作成するようにモデル化される。

第２に、レポートビルダアプリケーションを使用して、ユーザが特別な公式レポートを迅速かつ容易に作成できるようにするために、非常にインタラクティブなユーザインターフェース（UI）内にメタモデルが提示される。レポートビルダＵＩは、ユーザがレポートを作成する際に、インスタントフィードバックを提供する。ドラッグアンドドロップインターフェースを介してレポートに列を追加することが可能であり、単純で容易な様式でフィルタを適用することが可能である。これらの機能により、ユーザは特別な調査活動を迅速に実行し、幅広いユーザのセットによる実行のためにより公式なレポートを作成することができる。

メタモデルは、基礎となるデータソースから直接、または基礎となるデータを記述する仕様から、生成することができる。メタモデルは、オブジェクト、オブジェクトのフィールド、オブジェクト間の関係、およびメタモデル内のオブジェクトと基礎となるデータとの間のマッピングを識別する。

これらの関係は対称的であり、いずれかの方向にナビゲート可能である。たとえば、ある関係が顧客に基づいたオーダーの識別を可能にする場合、対応する関係はオーダーに基づいた顧客の識別を可能にする。

図１は、レポートを構築するための環境１００の例を示す。データソース１０２は、たとえばリレーショナルデータベース、オブジェクトデータベース、構造化データファイル（SGMLまたはXMLファイルなど）、階層型データベース、データ倉庫、または任意の他のデータ記憶システムとすることができる。一般に、データソース１０２は、内部でデータ記録が識別可能であり、そのデータ記録が個々のフィールドに関連付けられた値を含む、任意のデータストアとすることができる。

レポートの生成に先立ち、モデル生成器１０４は、以下でさらに説明するように、データソース１０２またはデータソースを記述する仕様を読み取り、メタモデルを生成することができる。メタモデルが生成されると、ユーザインターフェースによって後に使用するために保存される。通常、メタモデルはユーザインターフェースがデータソースのビジネスフレンドリフォームを提示することを可能にする。たとえば、メタモデルは、技術的理由で確立された制約および関係を消去または簡略化する一方で、ビジネス概念に対応するデータソース内に確立された制約および関係を反映することができる。

メタモデル内のオブジェクトは、異なる種類のフィールドを含むことができる。通常のフィールドは、名前、誕生日、量、および説明などのデータを、レポートに提供する単純なフィールドである。参照フィールドは、メタモデル内の他のオブジェクトを指し示すフィールドである。参照フィールドは、基礎となるデータソース内の外部キーから導出可能である。メタモデルは、集合フィールドを含むことも可能である。集合フィールドは、別のオブジェクトに関連付けられたオブジェクトの集合の論理的表現である。集合内のオブジェクトに対するオブジェクトの関係は１対多数である。通常、オブジェクトがターゲットオブジェクトのうちの最大で１つに関連付けられた場合、参照フィールドが使用され、オブジェクトがターゲットオブジェクトのうちの多くに関連付けられ得る場合、集合フィールドが使用される。

ユーザインターフェースモジュール１０６は、モデル生成器１０４によって生成されたメタモデルを読み取り、ユーザ１１２への提示のためにユーザインターフェース１１０を生成する。ユーザインターフェースモジュール１０６は、たとえば、クライアントデバイス上で実行されるウェブブラウザ上でユーザ１１２に提示されるウェブページまたはアプリケーションを生成することができる。

ユーザ１１２は、レポートを生成するためにユーザインターフェース１１０と対話する。たとえばユーザインターフェース１１０は、ユーザ選択レポート情報をユーザインターフェースモデル１０６に提供することができる。ユーザインターフェースモジュール１０６は、レポート情報をレポートモジュール１０８に提供することができる。レポートモジュール１０８は、データソース１０２に対してレポートを実行する。いくつかの実装において、レポートモジュール１０６は、レポート情報およびモデル生成器１０４からの情報（たとえば、メタモデル）を使用して、レポートを生成することができる。レポートモジュール１０８の出力は、ユーザ１１２への提示のために、ユーザインターフェースモジュール１１６を介してユーザインターフェース１１０に戻すことができる。これにより、ほぼリアルタイムな（たとえば、５秒未満のレイテンシでの）結果がユーザ１１２に提供される。このワークフローは、ユーザ１１２が、レポートが構築されているときにレポートに対して行われている変更の影響を見ることができる。

図２は、リレーショナルデータベースに基づくメタモデルの生成の例を示す。この例では、データソース１０２の構造がエンティティ関係モデル２００内に反映されている。一般に、テーブル内のデータの行間の関係は、第２のテーブル内のデータの行内の主キーを参照する１つのテーブルのデータの行内に外部キーを含めることによって確立することができる。通常、外部キーは、外部キーが外部キーのないテーブル内の単一行に関連付けられた、テーブル内の複数の行を可能にする関係の側に記憶される。データベースは、１つのテーブルが別のテーブルとどのように関係しているかを記述することができる。データベース内の関係は、一般に関係の濃度と呼ばれる、２つのオブジェクト間の関係におけるいくつかの要素を記述することができる。「１対１」は、テーブルＡ内の１つの行がテーブルＢ内の１つの行に関係することを示す。「１対多数」は、テーブルＡ内の１つの行がテーブルＢ内の多数の行に関係することを示す。「多数対多数」は、テーブルＡ内の多数の行がテーブルＢ内の多数の行に関係することを示す。

この例において、顧客テーブル２０２内の行はオーダーテーブル２１０内の多くの行に関係付けることが可能であり、オーダーテーブル２１０内の各行は顧客テーブル２０２内の１行のみに関係付けることが可能である。前述のように、この関係は、顧客テーブル２０２内の行を識別する、オーダーテーブル内の外部キーの導入によって作成される。同様に、オーダーテーブル２１０内の行はラインアイテムテーブル２１２内の多くの行に関係付けることが可能であり、ラインアイテムテーブル２１２内の行はオーダーテーブル２１０内の１行のみに関係付けることが可能である。製品テーブル２１４内の行はラインアイテムテーブル２１２内の多くの行に関係付けることが可能であり、ラインアイテムテーブル２１２内の行は製品テーブル内の１行のみに関係付けることが可能である。

顧客テーブル２０２内の行は顧客アドレステーブル２０４内の多数の行に関係付けることが可能であり、顧客アドレステーブル２０４内の行は顧客テーブル２０２内の１行に関係付けることが可能である。顧客アドレステーブル２０４内の行はアドレステーブル２０６内の１行に関係付けることが可能であり、アドレステーブル２０６内の行は顧客アドレステーブル２０４内の多数の行に関係付けることが可能である。アドレステーブル２０６内の行は国テーブル２０８内の１行に関係付けることが可能であり、国テーブル２０８内の行はアドレステーブル２０６内の多数の行に関係付けることが可能である。

物理データベースの作成は、データベーステーブルの導入と、データベースの管理および維持を簡略化するためにのみ存在する関係とを含むことができる。たとえば、データベースの正規化は、冗長性を最小化するためにリレーショナルデータベースのフィールドおよびテーブルを編成するプロセスである。正規化は、通常、大きなテーブルを小さなテーブルに分割すること、およびそれらの間の関係を定義することを含む。正規化されたデータベースは、フィールドの追加、削除、および修正が１テーブル内でのみ実行された後、定義された関係を使用して残りのデータベース全体に伝搬できるように、データを分離する。データベースの正規化は、ビジネスユーザによって容易に理解される概念に必ずしも対応していないテーブルを導入することができる。たとえば、正規化されたデータベースは、通常、多数対多数の関係を解決するためのテーブルを導入する。たとえば、ある顧客は多数のアドレスを有し得、多くの顧客は同じアドレスに常駐することが可能であって、顧客テーブル２０２とアドレステーブル２０６との間のこの多数対多数の関係は、顧客アドレステーブル２０４の導入を介して解決される。他のテーブル間の多数対多数の関係を解決するためにのみ働くこれらのテーブルは、リンクテーブルと呼ぶことができる。一般に、リンクテーブルはビジネスユーザにとってほとんど意味がない可能性がある。

メタモデル生成器は、メタモデル２１６を生成する。一般に、メタモデル２１６は、ビジネスにより密接に関係し、データセットの物理的実装にはそれほど関係しないような、データ要素間の関係を記述する。メタモデル内の関係は双方向である。たとえば顧客２１８は１つまたは複数のアドレス２２０を有し、アドレス２２０は１人または複数の顧客２１８を有する。同様に、顧客２１８は１つまたは複数のオーダー２２６を有し、オーダー２２６は１人の顧客２１８を有する。

メタモデル内の関係は、参照関係として特徴付けることが可能であり、ここでオブジェクトは１つの他のオブジェクトのみに関連付けられる（たとえば、オーダーオブジェクト２２６と顧客２１８との間の関係）。代替として、メタモデル内の関係は、集合関係として特徴付けることが可能である（たとえば、顧客２１８とオーダー２２６との間の関係）。

モデル生成器は、初期に、リレーショナルデータベース内のテーブルについてオブジェクトを生成する。モデル生成器は、基礎となるテーブル内のフィールドに対応するオブジェクト上のフィールドを作成することができる。モデル生成器は、基礎となるデータ構造を分析することによって、メタモデル内のオブジェクト間の関係を識別することも可能であり、たとえばモデル生成器は、顧客テーブルとオーダーテーブルとの間の主キー対外部キー関係を識別することができる。オーダーテーブル内の顧客テーブルに対する外部キーの存在に基づいて、モデル生成器は、オーダーオブジェクトと顧客オブジェクトの間の参照関係、および顧客オブジェクトとオーダーオブジェクトの間の集合関係を作成する。

名前は、所定の命名規則に基づいて決定することができる。たとえば、データベース内のフィールドは、単語を分けるためにキャメルケースを用いてラベル付けすることができる（たとえば、「FirstName」）か、または、データベース内のフィールドは、下線を用いて命名することができる（たとえば、「first_name」）。モデル生成器は、規則をユーザフレンドリな名前に変換することに基づいて、メタモデルについてのフィールド「Ｆｉｒｓｔ Ｎａｍｅ」を作成することができる。変換は、ヒューリスティックス、正規表現、または明示的変換ルーチンを使用して実行可能である。いくつかの実装において、メタモデル内で使用される名前は自然言語名とすることができる。自然言語または日常言語は、人の脳内に自然発生的に生じる任意の言語である。したがって典型的には、これらは、人が会話、歌、触れ合い、または書くことによって、互いにコミュニケーションを取るために使用する言語である。これらは、コンピュータのプログラミングまたは論理の研究のために使用されるような、構造化言語および形式言語とは区別される。これらの名前は、予約文字を含む無制限文字セットから作成可能である。予約文字とは、別の場所でデータベースまたはオペレーティングシステムによって利用されているために、使用することができない文字または記号である。たとえば、多くのオペレーティングシステムは、文字「＼、／、：、^＊、？、”、＜、＞、および｜」を予約し、これらの文字が使用されるのを許可しない。いくつかのデータベースは空白文字の使用を制限する。いくつかの実装において、制限文字のセットは、基礎となるデータベースまたはデータストアに依存することができる。

いくつかの実装において、モデルは、オブジェクトがレポートに含まれる場合、デフォルトフィールドとして働くデータの１つまたは複数のフィールドを識別することができる。たとえば顧客オブジェクトは、２つのデフォルトフィールドとして「ｆｉｒｓｔ ｎａｍｅ」および「ｌａｓｔ ｎａｍｅ」を有することができる。いくつかの実装において、デフォルトフィールドは１つまたは複数のフィールドに適用される公式とすることが可能であり、たとえば顧客オブジェクトのデフォルトフィールドは、名前と名字の連結とすることができる。オーダーオブジェクト２２６のデフォルトフィールドは、オーダー番号とすることができる。製品オブジェクト２２８のデフォルトフィールドは、製品名とすることができる。モデル内の他のオブジェクトも各々、それらに関連付けられたデフォルトフィールドを有することができる。

メタモデル２１８は、データタイプを含むフィールドに関する情報およびフィールド上に配置された任意の制約を含むこともできる。たとえば顧客オブジェクト２１８は、文字列である名前フィールドと、日付である誕生日フィールドとを含むことができる。

ユーザは、メタモデルに濃縮を加えることができる。たとえば図２において点線で表されるように、ユーザは顧客オブジェクト２１８と製品オブジェクト２３０との間にリンクを作成することができる。モデル生成器は、選択されたオブジェクト間のナビゲーション経路に基づく関係の濃度を決定することができる。この例では、顧客オブジェクト２１０からオーダーオブジェクト２２６、ラインアイテムオブジェクト２２８、製品オブジェクト２３０までである。これらのオブジェクト間の関係に基づいて、モデル生成器は、２つの選択されたオブジェクト間の関係が１対１、１対多数、多数対１、または多数対多数の関係であるかどうかを判定することができる。

図３は、レポートを構築するためのユーザインターフェースの例を示す。この例において、ユーザインターフェースの左側３０２では、選択されたオブジェクトの要素が階層に編成されている。ユーザは、開始オブジェクトをレポートの主題オブジェクト（この例では、図２の顧客オブジェクト２１８）として選択する。主題オブジェクトは、ユーザインターフェースが表示される前に選択可能であるか、または、ユーザインターフェース上に表示されるユーザインターフェース要素（図示せず）を使用して選択することができる。

ユーザインターフェースは、主題オブジェクトを開始ポイントとして使用して、オブジェクトの階層を示す。

顧客要素３０４の下に、アドレス（複数）要素３０６およびオーダー（複数）要素３１０がある。アドレス（複数）要素の下に国要素３０７がある。オーダー（複数）要素の下にラインアイテム（複数）要素がある。ラインアイテム（複数）要素３１２の下に製品要素３１４がある。前述のように、メタモデルにおいて、各関係は、メタモデル内の関係を２方向に（たとえば、顧客オブジェクト２１８からオーダーオブジェクト２２６へ、およびオーダーオブジェクト２２６から顧客オブジェクト２１８へ）ナビゲートすることが可能な、対応する逆関係を有する。いくつかの実装において、ユーザインターフェースは逆関係を表示しない。たとえば、顧客要素３０４はネストされたアドレス（複数）要素３０６を有するが、顧客要素３０４は階層内でアドレス（複数）要素３０６の直前にあるため、ユーザインターフェースは顧客要素をアドレス（複数）要素３０６の下には表示しない。言い換えれば、ユーザインターフェースによって、ユーザが顧客からアドレスへとナビゲートし、再度顧客に戻ることはできない。ユーザインターフェースは、顧客からアドレスへとメタモデルをナビゲートすることに基づいてアドレス要素を表示するため、ユーザインターフェースは関係をアドレスから顧客へはナビゲートしないことになる。いくつかの実装において、ユーザインターフェースは、円形参照の提示を防ぐ論理を含む。

階層内のユーザインターフェースにおけるアイコンは、メタモデル内の２つのオブジェクト間の関係の濃度を示すことができる。たとえば図２を参照すると、モデル２１６は、１つの顧客オブジェクト２１８を多数のオーダー２２６に関係付けることができることを示し、すなわち、顧客オブジェクト２１８とオーダーオブジェクト２２６との間の関係の濃度は１対多数である。同様に、各オーダーオブジェクト２２６が１つの顧客オブジェクト２１８に関連付けられるため、オーダーオブジェクト２２６と顧客オブジェクト２１８との間の関係の濃度は多数対１である。再度図３を参照すると、顧客データ要素３０４の下にネストされたオーダーデータ要素３１０は、複数形（たとえば、「オーダー」に対して「オーダー（複数）」）で提示される。オブジェクト名を複数形で提示することで、顧客（より高位のデータ要素）が多数のオーダーに関係付けられていることを反映する。さらに、アイコンを使用して、視覚的な指示を提供することが可能であり、たとえばオーダー（複数）要素３１０の隣に存在するアイコンは複数のフォルダを表示し、顧客が複数のオーダーを有し得ることを示す。対照的に、製品要素３１４は単数名詞を使用して記述され、単一フォルダを表示するアイコンを含む。これは、各ラインアイテムが１製品のみを有し得ることを示す。

ユーザインターフェースは、モデル内の濃縮関係に基づいてオブジェクトを表示することも可能である。たとえば、製品（複数）３１５要素は顧客要素３０４の下にネストされる。

オブジェクトに加えて、ユーザインターフェースはオブジェクトのフィールド（たとえば、誕生日フィールド３０８）を表示することも可能である。フィールド名によって、ユーザはオブジェクトの追加フィールドをレポートに加えることができる。

いくつかの実装において、ユーザインターフェースはメタモデル全体をメモリ内にロードすることができる。メタモデルをメモリ内にロードすることはより効率的であり、他のレポートビルダには存在しない様式で階層をナビゲートすることができる。たとえばユーザインターフェース３００は、図２のメタモデル２１６をメモリ内に保持することができる。ユーザが顧客要素３０４を展開する場合、ユーザインターフェース３００は、階層をどのようにポピュレートするかを決定するためにメタモデル２１６を参照する。この例では、図２を参照すると、顧客オブジェクト２１８はオーダーオブジェクト２２６およびアドレスオブジェクト２２０に関係付けられる。したがって、再度図３を参照すると、ユーザインターフェースは、顧客要素の下にネストされた階層にオーダー要素３０６およびアドレス（複数）要素３０６を追加する。同様に、ユーザがオーダー（複数）要素３０６を展開する場合、ユーザインターフェース３００は図２のメタモデル２１６を参照することができる。この例では、図２を参照すると、オーダーオブジェクト２２６はラインアイテムオブジェクト２２８に関係付けられる。したがって、再度図３を参照すると、ユーザインターフェースは、オーダー要素３１０の下にネストされた階層にラインアイテム（複数）要素３１２を追加する。

ユーザインターフェースは、以下でさらに考察するように、ユーザがレポートを作成できる右側を含むこともできる。図４を参照すると、ユーザはユーザインターフェースの左側３０２から要素を選択し、これを、ユーザインターフェースの右側にドラッグするか、さもなければユーザインターフェースの右側に要素を配置することができる。ユーザインターフェース３００の右側３３８に要素を追加することで、追加された要素に基づいてレポート内に列を生成する。列は、ヘッダおよび基礎となるデータからのデータを含むことができる。たとえば、顧客要素３０４をユーザインターフェース３００の右側３３８にドラッグすることで、顧客の名前を表示するレポートのための列３４０を生成する。同様に、オーダー（複数）要素３１０をユーザインターフェース３００の右側３３８にドラッグすることで、オーダー番号列３４２がレポートに追加される。

たとえば、ユーザが顧客要素３０４をユーザインターフェース３００の右側のキャンバス３２２上にドラッグした場合、レポートには基礎となるモデル内の顧客オブジェクトからデフォルトフィールドがポピュレートされる。この例では、デフォルトフィールドは顧客名である。レポートには、リアルタイムまたはほぼリアルタイムで、基礎となるデータソース（たとえば、図１のデータソース１０２）内の顧客テーブル内の行からの顧客名デフォルトフィールドに対応するフィールドまたはフィールド（複数）からの値をポピュレートすることができる。この例では、レポートには顧客名「Ｊｏｈｎ Ｓｍｉｔｈ」および「Ｓｔｅｖｅ Ｍｉｌｌｅｒ」がポピュレートされる。

いくつかの実装では、そのレポート主題に基づいて初期フィールドをレポートに追加することができる。

たとえば、一実装において、顧客要素３０４をキャンバス３２２上にドラッグすることで、以下のＳＱＬステートメントを生成および実行することができる。
ＳＥＬＥＣＴ ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥ．ＣＵＳＴＯＭＥＲ＿ＮＡＭＥ ＦＲＯＭ ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥ；

ユーザがオーダー（複数）要素３０６をキャンバス３２２上にドラッグすると、レポートにはオーダーオブジェクトからのデフォルトフィールドがポピュレートされ、この例では、オーダーオブジェクトのデフォルトフィールドはオーダー番号３２６である。前述のように、オーダー要素がキャンバスに追加されるとすぐに、データベースのために対応する関係およびクエリを生成および取得することができる。一般に、オブジェクトおよびフィールドは、レポート内のいずれの位置に配置することも可能である。たとえばユーザは、新規オブジェクトを既存の列の前、後ろ、または間に配置することができる。ユーザインターフェースによって、ユーザは列を並べ替えることもできる。

レポートをポピュレートするために使用される値は、レポート内に既に存在する顧客に関係する、基礎となるデータソース内のオーダーテーブルの行から取られる。この場合、Ｊｏｈｎ Ｓｍｉｔｈに関する顧客テーブル内のデータの行は、オーダー＃１２３４５およびオーダー＃５４３２１の２つのオーダーに関係する。たとえば、オーダー＃１２３４５を伴うオーダーテーブル内の行は、Ｊｏｈｎ Ｓｍｉｔｈに関する顧客テーブル内の行に関連付けられた主キーを参照する外部キーであるフィールドを有する。Ｓｔｅｖｅ Ｍｉｌｌｅｒに関する顧客テーブル内のデータの行は、オーダー＃８４０５３およびオーダー＃１２３３１のオーダーテーブル内の２つの行に関連付けられる。

たとえば、一実装において、顧客要素３０４の後のオーダー要素３０６をキャンバス３２２上にドラッグすることで、以下のＳＱＬステートメントを生成および実行することができる。
ＳＥＬＥＣＴ ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥ．ＣＵＳＴＯＭＥＲ＿ＮＡＭＥ， ＯＲＤＥＲ＿ＴＡＢＬＥ．ＯＲＤＥＲ＿ＮＵＭＢＥＲ ＦＲＯＭ ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥ， ＯＲＤＥＲ＿ＴＡＢＬＥ
ＷＨＥＲＥ ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥ．ＣＵＳＴＯＭＥＲ＿ＩＤ＝ＯＲＤＥＲ＿ＴＡＢＬＥ．ＣＵＳＴＯＭＥＲ＿ＩＤ；

この例では、ＷＨＥＲＥ節内に記述された関係は、階層関係に基づいて、顧客要素３０４とオーダー要素３０６との間に含められる。

同様に、ユーザが製品要素３０８をキャンバス３２２上にドラッグした場合、製品データオブジェクトに関するデフォルトフィールド（この場合、製品名３２８）を表示するように、レポートを更新することができる。この場合、レポートは、階層的にオーダー要素３０６の下に配置された製品要素３０８の選択に基づく、製品テーブルとオーダーテーブルとの間の関係を含む。

この例では、オーダー＃１２３４５はゴルフボールおよびアイアンセットの２つの製品を含む。オーダー＃５４３２１はゴルフバッグ製品を含む。オーダー＃８４０５３は、ゴルフボールおよびゴルフティーの２つの製品を含む。オーダー＃１２３３１は、ドライバおよびウッドセット製品を含む。

ユーザインターフェースは、レポートに追加されることになる集約関数を提供する。集約関数は、フィールドの値に関する演算を自動的に実行する。集約関数の例はＣＯＵＮＴを含み、（指定する属性に応じて）フィールド内の行の総数を表示する。具体的に言えば、ＣＯＵＮＴはフィールド内の非ＮＵＬＬ値の数を戻し、ＣＯＵＮＴＤＩＳＴＩＮＣＴはフィールド内の固有値の数を表示し、ＭＩＮはフィールド内の最小値を表示する。ＭＡＸはフィールド内の最大値を表示する。ＳＵＭはフィールドの値の合計を提供する。ＡＶＧはフィールドの平均値（算術平均）を表示し、これはフィールド内の値を合計し、その合計を値の総数で割るものであり、ＥＸＩＳＴＳは、フィールド内にいずれかの非ＮＵＬＬ値が存在するかどうかを示すブール値（真または偽）を表示する。

いくつかの集約関数は、異なるタイプのフィールドについてのみ使用可能である。たとえば、ＭＩＮおよびＭＡＸは、日付フィールドおよび数値フィールドの両方で使用可能である。ＡＶＧおよびＳＵＭは、数値フィールドでのみ使用可能である。

一般に、集約関数は集合フィールドに対して演算を実行する。集合フィールドは、集約関数が演算できる値のセットからなる。ユーザインターフェースは、フィールドが集約関数として有効な場合、集約関数を集合フィールドに対して使用可能にする。

ユーザインターフェースは、フィールドおよびタイプに適切な集約関数のみを表示することができる。たとえばユーザインターフェースは、文字列フィールド上にＡＶＧ集約を表示しない。集約関数が適切であるかどうかを決定することは、フィールド名、タイプ、および濃度についてメタモデルを分析することを含むことができる。たとえばユーザインターフェースは、集約を適切にするために、所与のオブジェクト（たとえば、顧客）と集約されているオブジェクトおよびフィールド（たとえば、オーダー、ラインアイテム）との間に１対多数の関係が存在しなければならないことを、決定することができる。

ユーザインターフェース３００は、集約関数セクション３１６を含む。集約セクションは、レポートの選択されたレポート主題に基づいてポピュレートすることができる。この例では、集約関数３１６はオーダー集約関数３１８を含む。オーダー集約関数３１８の下に、オーダー（複数）のカウント関数３２０およびオーダー（複数の）個別カウント関数３２２（すなわち、固有値の数を提示する集約関数）がある。

メタモデルのさらなるナビゲーションに基づいて、追加の集約関数を表示することができる。たとえば、オーダー（複数）集約関数３１８の下に、ラインアイテム集約関数３２４がある。ラインアイテム集約関数は、ラインアイテム（複数）についてのカウント３２６および個別カウント３２８を含む。

ユーザインターフェースは、ユーザが列をまとめてグループ化すること、およびグループ化された列をまたぐ名前を追加することも可能にする。

ユーザインターフェースは、ユーザが（たとえば、ユーザインターフェース上の保存アイコン３３０を選択することによって）レポートを保存することも可能にし得る。保存機能は、選択された要素、フィルタ（以下でさらに考察）、および／または選択されたフィールドを、永続データストア（たとえば、フラットファイルシステム）内に記憶することができる。レポートを保存することは、保存されたレポートを識別するために使用可能な名前または参照を提供することを含むことができる。

ユーザインターフェースは、ユーザが（たとえば、ユーザインターフェース上のロードアイコン３３２を選択することによって）保存されたレポートをロードすることも可能にし得る。ユーザインターフェースは、ユーザが（たとえば、リフレッシュアイコン３３４を選択することによって）レポートをリフレッシュまたは再実行することも可能にし得る。これらの特徴の各々はアイコンに関して述べているが、リボン上の領域、ボタン、メニュー選択項目などを含むが限定されない、他の視覚的表現を使用することができる。

図５は、例示的レポートの作成を示す。ユーザインターフェース３００は、単純フィールド、参照フィールド、または集合に関する追加の情報を表示することができる。たとえば、国要素３０７の上でホバリングすることで、ポップアップボックス５０２を表示させることができる。ポップアップボックスは、基礎となるデータセットの名前、基礎となるデータセット内の対応するフィールドの名前、およびフィールドのデータタイプを含む、国要素３０７に関する追加の情報を表示することができる。

ユーザインターフェース３００は、ユーザが、レポート内のフィールドまたはレポートに含まれるオブジェクトに関するフィールドにフィルタを適用することを可能にすることもできる。たとえば、ユーザは顧客要素３０４のフィルタリングを選択することができる。システムは、フィルタユーザインターフェース領域５０４を提示することができる。フィルタユーザインターフェースは、その上でレポートのフィルタリングが可能な、異なるフィールドおよびオブジェクトの階層を含むことができる。たとえば、フィルタインターフェース領域５０４は、アドレス（複数）集合５０６、名前フィールド５０８、およびオーダー（複数）集合を含む。ユーザが、たとえばオーダー（複数）集合を選択した場合、オーダー（複数）集合は、前述のように、単純フィールド、参照フィールド、および、オーダーオブジェクトに関連付けられた集合フィールドを提示するために、展開することができる。

ユーザは、レポート内に含めるフィールドを選択するのと同様に、要素（たとえば、名前要素５０８）を選択し、この要素をユーザインターフェース３００の右側３２２上にドラッグすることができる。ユーザインターフェースはフィルタ情報を表示することが可能であり、これはたとえば、レポートがフィルタリングされることになるフィールドの名前、ユーザがフィルタのタイプを選択できる選択ボックス５１４、およびユーザがテキスト情報をフィルタ内に提供できるようにする値フィールド５１６を含むことができる。フィルタのタイプは、フィールドが値で開始されるか、値で終了するか、値を含むか、正確な値であるか、および値でないかを決定することを含むが、これらに限定されない。データタイプに基づいていくつかのフィルタが使用可能であり、たとえば数値フィールドは、フィールドが値より大きいかまたは値より小さいかどうかを決定することなどのフィルタを含むことができる。

この例では、ユーザは名前フィールド５０８、「含む」フィルタ５１４を選択し、値として「Ｓｔｅｖｅ Ｍｉｌｌｅｒ」を入力した。フィールド、フィルタ動作、および値の選択に応答して、レポートはフィルタを反映するように更新された。たとえばキャンバス３２２上のレポートは、Ｊｏｈｎ Ｓｍｉｔｈによって行われたかまたはＪｏｈｎ Ｓｍｉｔｈに関連付けられたオーダーのみを提示する。いくつかの実装において、フィルタリングは、フィールドおよび値が選択されるとすぐに実行可能である。他の実装において、フィルタリングは、ユーザによるさらなるアクションを必要とする場合がある。たとえばユーザは、ユーザインターフェース上に提示されたフィルタアイコン（図示せず）を選択することが必要な場合がある。

異なるトップレベル要素を選択することで、結果として異なるレポートを提示および作成することができる。たとえば図６を参照すると、レポートを構築するためのユーザインターフェース６００である。上記の例と同様に、ユーザインターフェースの左側６０２には、階層状に編成された選択されたオブジェクトの要素が示されている。この例では、ユーザは製品オブジェクトをレポートの主題オブジェクトとして選択している。

製品要素６０４の下に、ラインアイテム要素６０６および顧客（複数）要素がある。ラインアイテム要素６０６の下に、オーダー（複数）要素６０７がある。オーダー要素６０７の下に、顧客要素６０８がある。顧客要素６０８の下にアドレス（複数）要素６１０がある。顧客要素６１２の下にアドレス（複数）要素６１４がある。

ユーザは、ユーザインターフェースの左側６０２から要素を選択し、これをユーザインターフェースの右側にドラッグするか、あるいは右側に要素を配置することができる。ユーザインターフェース６００の右側６３８に要素を追加することで、追加された要素に基づいてレポート内に列が生成される。列は、ヘッダと基礎となるデータからのデータを含むことができる。たとえば、ユーザインターフェース６００の右側６６８に製品要素６０４をドラッグすることで、製品の名前を表示するレポートのための列６４０が生成される。同様に、顧客（複数）要素６１２をユーザインターフェース６００の右側６３８にドラッグすることで、顧客列６４２がレポートに追加される。代替として、顧客要素６０８をユーザインターフェース６００の右側６６８上にドラッグすることで、顧客（複数）要素６１２を右側にドラッグするのと同じ効果を得ることができる。

アドレス（複数）要素６１４をユーザインターフェースの右側６６８にドラッグすることで、アドレス列６４６がレポートに追加される。図７は、レポートを構築するための例示的プロセス７００のフローチャートである。プロセス７００は、プロセスを実行するコンピュータシステムによって実行可能である。

モデルが取得される（７０２）。モデルは、データソース内のデータ構造を表すオブジェクト、および、データ構造間の関係を表すオブジェクト間のリンクを含むことが可能であり、モデル内の各オブジェクトは対応するデータ構造内の少なくとも１つのデフォルトフィールドを識別する。データソースは、たとえばリレーショナルデータベースとすることができる。モデルは、データソース内のデータ構造から生成可能である。たとえば一実装において、モデルは、テーブル、およびリレーショナルデータベース内のテーブル間の関係に基づいて、生成可能である。

モデル内の各オブジェクトについて、モデルはオブジェクトに関連付けられたデフォルトフィールドを定義することも可能である。たとえば顧客オブジェクトは、デフォルトフィールドとして「顧客名」を有し得る。デフォルトフィールドは、データソースのデータ構造内の１つまたは複数のフィールドに対応し得る。いくつかの実装において、デフォルトフィールドは、データ構造に記憶されたデータの変換あるいは修正バージョンとすることができる。たとえば、デフォルトフィールドは２つまたはそれ以上の他のフィールドの連結であり得るか、あるいはデフォルトフィールドは異なるフォーマットに変換されたデータを含み得る。

ユーザインターフェースが生成される（７０４）。ユーザインターフェースは、階層状に編成された要素を含む。各要素はモデル内のオブジェクトに対応可能である。ユーザインターフェースは、カスタムスタンドアロンアプリケーション、またはクライアントデバイスに送信されたウェブページとすることができる。

要素のユーザ選択が受信される（７０６）。ユーザは、たとえば要素のクリック、ダブルクリック、階層からキャンバス上への要素のドラッグ、タッチベースユーザインターフェースのタッピング、または任意の他の選択機構を介して、要素を選択することができる。

レポートが生成される（７０８）。レポートを生成するために、プロセスは要素に対応するモデルのオブジェクトを識別することができる。たとえば、ユーザが「顧客」とラベル表示された要素を選択する場合、プロセスは、顧客オブジェクトを要求されたオブジェクトとして識別することができる。プロセスは、オブジェクトに対応するデータ構造を識別することができる。たとえばプロセスは、ＣＵＳＴＯＭＥＲ＿ＴＡＢＬＥがモデル内の顧客オブジェクトに関連付けられている旨を識別することができる。プロセスは、データソース内で識別されたデータ構造内の少なくとも１つのデフォルトフィールドから、データを取得することができる。たとえば、顧客名が顧客オブジェクトに関連付けられたデフォルトフィールドである場合、プロセスは、データソース内の顧客データ構造から顧客名データを取得することができる。

データはユーザに提示される。データは、クライアントからの後続または介在アクションを必要とせずに提示可能である。データは、表レポートとして提示するか、あるいは他の方法で変換または修正することができる。たとえばデータは、集約する、解析する、作図する、バケットに入れる、あるいは他の方法で提示される前に修正することができる。

図８は、レポートを構築するための例示的なプロセス８００のフローチャートである。プロセス８００は、プロセスを実行するコンピュータシステムによって実行可能である。

モデルが作成される（８０２）。モデルは、構造化データ（たとえば、リレーショナルデータベースのデータベーススキーマ）に基づいて作成可能である。構造化データは、データ要素（たとえば、テーブル）を有するデータ構造を含むことができる。各データ要素は名前付きフィールドを有することができる。

モデルを作成することは、構造化データ内のデータ構造のうちの１つに基づいてモデル内にオブジェクトを作成することを含むことができる。構造内のフィールドの名前を自然言語名に変換する。フィールドの名前の変換は、ルックアップテーブル、ヒューリスティックス、変換関数を使用して、または任意の他の変換機構を介して実行可能である。

自然言語名を有するオブジェクト上に、フィールドが作成される。

モデルを作成することは、構造化データ内の２つのデータ構造間の関係を表す関係フィールドを作成することも含む。たとえば、関係フィールドは、リレーショナルデータベース内の主キー対外部キーの関係に基づいて作成可能である。関係フィールドは、いくつかの関係において複数のオブジェクトを単一オブジェクトに関連付け得る旨を表す集合とすることができる。

モデル内にオブジェクトの階層が生成される（８０４）。階層は、開始オブジェクトに関してオブジェクトを編成することによって生成可能である。いくつかのシナリオでは、開始オブジェクトはユーザインターフェースと対話するユーザによって選択可能である。

階層内のオブジェクトのうちの１つまたは複数についての要素を含むユーザインターフェースが生成される（８０６）。ユーザインターフェースは、モデル内のオブジェクトを表すユーザインターフェース要素を含むことができる。ユーザインターフェース要素は、階層に従って編成される。ユーザインターフェースは、ユーザがレポートを作成すること、および自然言語名を使用してレポートをフィルタリングすることを可能にし得る。ユーザインターフェースは、集約関数およびフィルタリング関数も含むことができる。集約関数は、ユーザがフィールドに関する情報を集約できるようにする。フィルタ関数は、ユーザがレポート内に提示される値を制限できるようにする。

ユーザから１つまたは複数の要素の選択を受信することができる（８０８）。ユーザは、たとえばスクリーンの一部からスクリーンの別の部分への要素のドラッグアンドドロップによって、要素を選択することができる。

レポートが生成される（８０８）。レポートを生成するために、システムは、選択された要素に対応するデータ構造を識別することができる。識別されたデータ構造内の少なくとも１つのフィールドから、データを取得する。さらに、データをユーザに提示する。レポートは、ＷＹＳＩＷＹＧインターフェースを使用して生成することができる。たとえば、ユーザはレポートにフィールドを追加することができ、レポートはデータソースからの値をリフレッシュおよび表示することができる。これによってユーザは、レポートの品質に関するフィードバックを即時に取得できるため、迅速な反復が可能になる。

前述のレポート構築手法は、好適なソフトウェアを実行するコンピューティングシステムを使用して実装可能である。たとえばソフトウェアは、
各々が、少なくとも１つのプロセッサ、少なくとも１つのデータ記憶システム（揮発性および／または不揮発性のメモリ、ならびに／あるいは記憶要素を含む）、および（少なくとも１つの入力デバイスまたはポートを使用して入力を受信するため、および、少なくとも１つの出力デバイスまたはポートを使用して出力を提供するための）少なくとも１つのユーザインターフェースを含む、１つまたは複数のプログラムされたまたはプログラム可能なコンピューティングシステム（分散型、クライアント／サーバ、またはグリッドなどの、様々なアーキテクチャであり得る）上で実行する、１つまたは複数のコンピュータプログラム内の手順を含むことが可能である。ソフトウェアは、たとえば、データフローグラフの設計、構成、および実行に関するサービスを提供する、より大きなプログラムの１つまたは複数のモジュールを含むことができる。プログラムのモジュール（たとえば、データフローグラフの要素）は、データリポジトリに記憶されたデータモデルに準拠するデータ構造または他の編成データとして実装可能である。

ソフトウェアは、ＣＤ−ＲＯＭまたは他のコンピュータ可読媒体（たとえば、汎用または特定用途向けのコンピューティングシステムまたはデバイスによって読み取り可能）などの、有形の非一時的媒体上に提供すること、あるいは、ネットワークの通信媒体を介して、実行されているコンピューティングシステムの有形の非一時的媒体に送達する（たとえば、伝搬信号内に符号化する）ことができる。処理の一部またはすべては、特定用途向けコンピュータ上で、あるいは、特定用途向けハードウェア（コプロセッサまたはフィールドプログラマブルゲートアレイ（FPGA）あるいは専用の特定用途向け集積回路（ASIC）など）を使用して、実行可能である。処理は、ソフトウェアによって指定された計算の異なる部分が異なるコンピューティング要素によって実行される、分散様式で実装可能である。こうしたコンピュータプログラムは、各々、本明細書で説明する処理を実行するために記憶デバイス媒体がコンピュータによって読み取られるときに、コンピュータを構成および動作させるために、好ましくは、汎用または特定用途向けプログラム可能コンピュータによるアクセスが可能な記憶デバイスの、コンピュータ可読記憶媒体（たとえば、ソリッドステートメモリまたは媒体、あるいは磁気または光媒体）に記憶するか、またはダウンロードされる。本発明のシステムは、コンピュータプログラムと共に構成された有形の非一時的媒体として実装されるものと見なすことも可能であり、媒体は、本明細書で説明する処理ステップのうちの１つまたは複数を実行するために、特定かつ事前定義された様式でコンピュータを実行させるように構成される。

以上、本発明のいくつかの実施形態について説明してきた。しかしながら、上記の説明は例示的なものであり、以下の特許請求の範囲によって定義される本発明の範囲を限定することは意図されていないことを理解されたい。したがって、他の実施形態も以下の特許請求の範囲内である。たとえば、本発明の範囲を逸脱することなく様々な修正を行うことができる。加えて、上述のステップのいくつかは順序に依存しない可能性があるため、説明した順序とは異なる順序で実行可能である。

Claims (39)

1. コンピュータ実装方法であって、
   構造化データに基づいてモデルを作成することであって、前記構造化データはデータ構造を含み、各データ構造はデータ要素を有し、各データ要素はフィールドを有し、各フィールドは名前を有し、前記モデルを作成することは、
   前記構造化データ内のデータ構造に基づいて前記モデル内にオブジェクトを作成すること、
   前記データ構造内のフィールドの名前を自然言語名に変換すること、
   前記自然言語名を有する前記オブジェクト上にフィールドを作成すること、および、
   前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成すること、
   を含む、作成することと、
   モデル内にオブジェクトの階層を生成することであって、前記階層は、前記オブジェクト上の関係フィールドに従い、開始オブジェクトに関して前記オブジェクトを編成する、生成することと、
   前記階層内の前記オブジェクトのうちの１つまたは複数についての要素を含むユーザインターフェースを生成することであって、前記ユーザインターフェースは、ユーザがレポートを作成し、前記自然言語名を使用して前記レポートをフィルタリングできるようにする、生成することと、
   前記要素からの要素のユーザ選択を受信することと、
   レポートを生成することであって、
   前記要素に対応するデータ構造を識別すること、
   前記データソース内で前記識別されたデータ構造内の少なくとも１つのフィールドからデータを取得すること、および、
   前記データを前記ユーザに提示すること、
   を含む、生成することと、
   を含む、方法。
2. 名前を変換することは、ルックアップテーブルを使用して前記名前を変換することを含む、請求項１に記載の方法。
3. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２の１データ要素との間の関係を表す参照フィールドである、請求項１に記載の方法。
4. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２のデータ要素との間の関係を表す集合フィールドである、請求項１に記載の方法。
5. 前記ユーザインターフェースは、前記集合フィールド上で使用可能な集約関数を含む、請求項４に記載の方法。
6. 前記関係フィールドは、前記データ構造内の１データ要素と前記データ構造内の第２のデータ要素との間の関係を表す親子フィールドである、請求項１に記載の方法。
7. 前記構造化データは構造化データベースであり、前記データ構造は前記構造化データベース内のテーブルである、請求項１に記載の方法。
8. 前記構造化データは１つまたは複数のファイルである、請求項１に記載の方法。
9. 前記レポートを生成することは、前記ユーザ選択の受信に応答して生じる、請求項１に記載の方法。
10. 前記ユーザインターフェースは、見たままが得られるインターフェースを使用したレポートのインタラクティブな作成を可能にし、前記ユーザインターフェースは、データ値を含む前記レポートの視覚フィードバックを、前記レポートのファイナライズ前にほぼリアルタイムで提供する、請求項１に記載の方法。
11. ユーザインターフェースを生成することは、前記開始オブジェクトの選択をユーザから受信することをさらに含む、請求項１に記載の方法。
12. 前記自然言語名は、前記構造化データに関する限定文字のセット内の少なくとも１つの文字を含む、請求項１に記載の方法。
13. 前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成することは、前記構造化データ内の主キー対外部キーの関係を表すために関係オブジェクトを作成することを含む、請求項１に記載の方法。
14. コンピュータプログラム命令を用いて符号化された非一時的コンピュータ記憶媒体であって、前記コンピュータプログラム命令は、１つまたは複数のコンピュータによって実行された場合、
    構造化データに基づいてモデルを作成することであって、前記構造化データはデータ構造を含み、各データ構造はデータ要素を有し、各データ要素はフィールドを有し、各フィールドは名前を有し、前記モデルを作成することは、
    前記構造化データ内のデータ構造に基づいて前記モデル内にオブジェクトを作成すること、
    前記データ構造内のフィールドの名前を自然言語名に変換すること、
    前記自然言語名を有する前記オブジェクト上にフィールドを作成すること、および、
    前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成すること、
    を含む、作成することと、
    モデル内にオブジェクトの階層を生成することであって、前記階層は、前記オブジェクト上の関係フィールドに従い、開始オブジェクトに関して前記オブジェクトを編成する、生成することと、
    前記階層内の前記オブジェクトのうちの１つまたは複数についての要素を含むユーザインターフェースを生成することであって、前記ユーザインターフェースは、ユーザがレポートを作成し、前記自然言語名を使用して前記レポートをフィルタリングできるようにする、生成することと、
    前記要素からの要素のユーザ選択を受信することと、
    レポートを生成することであって、
    前記要素に対応するデータ構造を識別すること、
    前記データソース内で前記識別されたデータ構造内の少なくとも１つのフィールドからデータを取得すること、および、
    前記データを前記ユーザに提示すること、
    を含む、生成することと、
    を含む動作を、前記１つまたは複数のコンピュータに実行させる、非一時的コンピュータ記憶媒体。
15. 名前を変換することは、ルックアップテーブルを使用して前記名前を変換することを含む、請求項１４に記載の非一時的コンピュータ可読媒体。
16. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２の１データ要素との間の関係を表す参照フィールドである、請求項１４に記載の非一時的コンピュータ可読媒体。
17. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２のデータ要素との間の関係を表す集合フィールドである、請求項１４に記載の非一時的コンピュータ可読媒体。
18. 前記ユーザインターフェースは、前記集合フィールド上で使用可能な集約関数を含む、請求項１７に記載の非一時的コンピュータ可読媒体。
19. 前記関係フィールドは、前記データ構造内の１データ要素と前記データ構造内の第２のデータ要素との間の関係を表す親子フィールドである、請求項１４に記載の非一時的コンピュータ可読媒体。
20. 前記構造化データは構造化データベースであり、前記データ構造は前記構造化データベース内のテーブルである、請求項１４に記載の非一時的コンピュータ可読媒体。
21. 前記構造化データは１つまたは複数のファイルである、請求項１４に記載の非一時的コンピュータ可読媒体。
22. 前記レポートを生成することは、前記ユーザ選択の受信に応答して生じる、請求項１４に記載の非一時的コンピュータ可読媒体。
23. 前記ユーザインターフェースは、見たままが得られるインターフェースを使用したレポートのインタラクティブな作成を可能にし、前記ユーザインターフェースは、データ値を含む前記レポートの視覚フィードバックを、前記レポートのファイナライズ前にほぼリアルタイムで提供する、請求項１４に記載の非一時的コンピュータ可読媒体。
24. ユーザインターフェースを生成することは、前記開始オブジェクトの選択をユーザから受信することをさらに含む、請求項１４に記載の非一時的コンピュータ可読媒体。
25. 前記自然言語名は、前記構造化データに関する限定文字のセット内の少なくとも１つの文字を含む、請求項１４に記載の非一時的コンピュータ可読媒体。
26. 前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成することは、前記構造化データ内の主キー対外部キーの関係を表すために関係オブジェクトを作成することを含む、請求項１４に記載の非一時的コンピュータ可読媒体。
27. １つまたは複数のコンピュータと、命令を記憶する１つまたは複数の記憶デバイスとを備える、システムであって、
    前記命令は、前記１つまたは複数のコンピュータによって実行された場合、
    構造化データに基づいてモデルを作成することであって、前記構造化データはデータ構造を含み、各データ構造はデータ要素を有し、各データ要素はフィールドを有し、各フィールドは名前を有し、前記モデルを作成することは、
    前記構造化データ内のデータ構造に基づいて前記モデル内にオブジェクトを作成すること、
    前記データ構造内のフィールドの名前を自然言語名に変換すること、
    前記自然言語名を有する前記オブジェクト上にフィールドを作成すること、および、
    前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成すること、
    を含む、作成することと、
    モデル内にオブジェクトの階層を生成することであって、前記階層は、前記オブジェクト上の関係フィールドに従い、開始オブジェクトに関して前記オブジェクトを編成する、生成することと、
    前記階層内の前記オブジェクトのうちの１つまたは複数についての要素を含むユーザインターフェースを生成することであって、前記ユーザインターフェースは、ユーザがレポートを作成し、前記自然言語名を使用して前記レポートをフィルタリングできるようにする、生成することと、
    前記要素からの要素のユーザ選択を受信することと、
    レポートを生成することであって、
    前記要素に対応するデータ構造を識別すること、
    前記データソース内で前記識別されたデータ構造内の少なくとも１つのフィールドからデータを取得すること、および、
    前記データを前記ユーザに提示すること、
    を含む、生成することと、
    を含む動作を、前記１つまたは複数のコンピュータに実行させるように動作可能である、システム。
28. 名前を変換することは、ルックアップテーブルを使用して前記名前を変換することを含む、請求項２７に記載のシステム。
29. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２の１データ要素との間の関係を表す参照フィールドである、請求項２７に記載のシステム。
30. 前記関係フィールドは、前記データ構造内の１データ要素と第２のデータ構造内の第２のデータ要素との間の関係を表す集合フィールドである、請求項２７に記載のシステム。
31. 前記ユーザインターフェースは、前記集合フィールド上で使用可能な集約関数を含む、請求項３０に記載のシステム。
32. 前記関係フィールドは、前記データ構造内の１データ要素と前記データ構造内の第２のデータ要素との間の関係を表す親子フィールドである、請求項２７に記載のシステム。
33. 前記構造化データは構造化データベースであり、前記データ構造は前記構造化データベース内のテーブルである、請求項２７に記載のシステム。
34. 前記構造化データは１つまたは複数のファイルである、請求項２７に記載のシステム。
35. 前記レポートを生成することは、前記ユーザ選択の受信に応答して生じる、請求項２７に記載のシステム。
36. 前記ユーザインターフェースは、見たままが得られるインターフェースを使用したレポートのインタラクティブな作成を可能にし、前記ユーザインターフェースは、データ値を含む前記レポートの視覚フィードバックを、前記レポートのファイナライズ前にほぼリアルタイムで提供する、請求項２７に記載のシステム。
37. ユーザインターフェースを生成することは、前記開始オブジェクトの選択をユーザから受信することをさらに含む、請求項２７に記載のシステム。
38. 前記自然言語名は、前記構造化データに関する限定文字のセット内の少なくとも１つの文字を含む、請求項２７に記載のシステム。
39. 前記構造化データ内のデータ構造間の関係に基づいて前記オブジェクト上に関係フィールドを作成することは、前記構造化データ内の主キー対外部キーの関係を表すために関係オブジェクトを作成することを含む、請求項２７に記載のシステム。

Images