特表 2024-514501 論理モデルの不整合の自律的テスト

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-04-02

(54)【発明の名称】論理モデルの不整合の自律的テスト

(51)【国際特許分類】

   G06F 16/33 20190101AFI20240326BHJP

【ＦＩ】

G06F16/33

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023560421

(86)(22)【出願日】2022-02-15

(85)【翻訳文提出日】2023-11-21

(86)【国際出願番号】 US2022016435

(87)【国際公開番号】W WO2022220916

(87)【国際公開日】2022-10-20

(31)【優先権主張番号】17/230,167

(32)【優先日】2021-04-14

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】サッシン，マイケル

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175DA10

5B175GB03

(57)【要約】

実施の形態は、論理モデルの不整合を自律的にテストする。たとえば、論理モデルを記述したメタデータが受信され得る。ここで、論理モデルは、データベーススキーマを抽象化したものを含み、データベーススキーマは、データベースにおいて実装され、データベーススキーマは、ファクトテーブルと、ディメンションテーブルとを含む。取得したメタデータに基づいて、第１論理クエリと第２論理クエリとを少なくとも含む複数の論理クエリが自動的に生成され得る。ここで、第１論理クエリおよび第２論理クエリは、論理モデルの論理オブジェクトを対象とする。論理モデルをホストするサーバに、第１論理クエリと第２論理クエリが少なくとも発行され得る。ここで、サーバにおいて、第１論理クエリおよび第２論理クエリは、第１のデータベースクエリおよび第２のデータベースクエリに変換され、第１のデータベースクエリおよび第２のデータベースクエリは、データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする。第１のデータベースクエリおよび第２のデータベースクエリを実行した結果受信したクエリ結果が比較され得る。クエリ結果の比較が基準を満たさない場合、不整合が特定され得る。

【特許請求の範囲】

【請求項1】

論理モデルの不整合を自律的にテストするための方法であって、
論理モデルを記述したメタデータを取得することを含み、前記論理モデルは、データベーススキーマを抽象化したものを含み、前記データベーススキーマは、データベースにおいて実装され、前記データベーススキーマは、ファクトテーブルと、１つ以上のディメンションテーブルとを含み、前記方法は、さらに、
取得した前記メタデータに基づいて、第１論理クエリと第２論理クエリとを少なくとも含む複数の論理クエリを自動的に生成することを含み、前記第１論理クエリおよび前記第２論理クエリは、前記論理モデルの論理オブジェクトを対象とし、前記方法は、さらに、
前記論理モデルをホストするサーバに、前記第１論理クエリと前記第２論理クエリを少なくとも発行することを含み、前記サーバにおいて、前記第１論理クエリは、第１のデータベースクエリに変換され、前記第２論理クエリは、第２のデータベースクエリに変換され、前記第１のデータベースクエリおよび前記第２のデータベースクエリは、前記データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とし、前記方法は、さらに、
前記第１のデータベースクエリおよび前記第２のデータベースクエリを実行した結果受信したクエリ結果を比較することと、
前記第１のデータベースクエリおよび前記第２のデータベースクエリの前記クエリ結果の前記比較が基準を満たさない場合、１つ以上の不整合を特定することとを含み、前記１つ以上の不整合は、前記メタデータによって定義される前記論理モデルとの不整合、または前記データベースにおける不整合を含む、方法。

【請求項2】

前記第１のデータベースクエリおよび前記第２のデータベースクエリは、対象とされる前記論理オブジェクトに関連する集約関数を用いて前記論理モデルをテストするように構成された対のデータベースクエリを含む、請求項１に記載の方法。

【請求項3】

前記第１論理クエリおよび前記第２論理クエリは、対象とされる前記論理オブジェクトに対応付けられたメタデータに基づいて生成され、前記第１のデータベースクエリおよび前記第２のデータベースクエリは、前記第１論理クエリおよび第２論理クエリを変換するために使われる対象とされる前記論理オブジェクトのマッピングに基づいて、前記データベーススキーマの前記ファクトテーブルおよび前記ディメンションテーブルを対象とする、請求項２に記載の方法。

【請求項4】

前記第１のデータベースクエリは、前記メタデータにおいて定義される前記メジャーデータの集約関数の定義に基づいて、１つ以上のディメンションに沿ったメジャーデータ値を集約し、前記第２のデータベースクエリは、前記メジャーデータ値のうち複数のメジャーデータ値を、１つ以上のディメンション属性別にグループ化する、請求項３に記載の方法。

【請求項5】

前記第１のデータベースクエリは、前記メジャーのディメンション定義、および前記メタデータにおいて定義される前記メジャーデータの集約関数の定義に基づいて、前記メジャーのすべてのディメンションに沿ったメジャーデータ値を集約する、請求項４に記載の方法。

【請求項6】

前記対のデータベースクエリのクエリ結果を比較することは、集約された前記メジャーデータ値を、グループ化された前記メジャーデータ値の集計と比較することを含む、請求項４に記載の方法。

【請求項7】

集約された前記メジャーデータ値とグループ化された前記メジャーデータ値の前記集計との差がしきい値よりも大きい場合、前記少なくとも１つの不整合が特定される、請求項６に記載の方法。

【請求項8】

対象とされる前記論理オブジェクトと前記メタデータにおいて定義される対象とされる前記ファクトテーブルおよび前記ディメンションテーブルとの関係、前記データベースにある対象とされる前記ファクトテーブルおよび前記ディメンションテーブルにロードされたデータ、および前記メタデータにある対象とされる前記ファクトテーブルおよび前記ディメンションテーブルについて定義されるカラム構成メタデータ、のうち１つ以上について前記少なくとも１つの不整合が特定される、請求項７に記載の方法。

【請求項9】

複数のデータベースクエリを自動的に生成することは、複数の対のデータベースクエリを自動的に生成することを含み、各対のデータベースクエリのうち第１は、１つ以上のディメンションの所与のメジャーデータ値の集約を含み、各対のデータベースクエリのうち第２は、前記所与のメジャーデータ値のうち複数を１つ以上のディメンション属性別にグループ化する、請求項３に記載の方法。

【請求項10】

前記論理モデルをホストする前記サーバに前記複数の対の論理クエリを発行することをさらに含み、前記サーバにおいて、各対の論理クエリは、前記データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする対のデータベースクエリに変換され、前記方法は、さらに、
前記複数の対のデータベースクエリを実行した結果受信したクエリ結果を比較することと、
各対のデータベースクエリの前記クエリ結果の前記比較が基準を満たさない場合、１つ以上の不整合を特定することとを含み、前記１つ以上の不整合は、前記メタデータによって定義される前記論理モデルとの不整合、または前記データベースにおける不整合を含む、請求項９に記載の方法。

【請求項11】

自動的に生成された前記複数の対のデータベースクエリは、各対が対象としている少なくとも１つの論理オブジェクトに関連する集約関数を用いて前記論理モデルをテストするように構成される、請求項１０に記載の方法。

【請求項12】

発行された前記複数の対の論理クエリの場合、所与の対の前記論理クエリは、前記所与の対が対象としている前記少なくとも１つの論理オブジェクトに対応付けられたメタデータに基づいて生成され、前記所与の対の論理クエリに基づいて変換される所与の対のデータベースクエリは、前記所与の対の論理クエリを変換するために使われる対象とされる前記所与の論理オブジェクトのためのマッピングに基づいて前記データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする、請求項１１に記載の方法。

【請求項13】

自動的に生成された前記複数の対のデータベースクエリは、前記論理モデルの複数の論理オブジェクトをテストし、変換された前記複数の対のデータベースクエリは、前記データベースの複数のファクトテーブルおよびディメンションテーブルをテストする、請求項１２に記載の方法。

【請求項14】

論理モデルの不整合を自律的にテストするためのシステムであって、
プロセッサと、
前記プロセッサによって実行される命令を記憶したメモリとを備え、前記命令は、前記プロセッサを、
論理モデルを記述したメタデータを取得するように構成し、前記論理モデルは、データベーススキーマを抽象化したものを含み、前記データベーススキーマは、データベースにおいて実装され、前記データベーススキーマは、ファクトテーブルと、１つ以上のディメンションテーブルとを含み、前記命令は、さらに、前記プロセッサを、
取得した前記メタデータに基づいて、第１論理クエリと第２論理クエリとを少なくとも含む複数の論理クエリを自動的に生成するように構成し、前記第１論理クエリおよび前記第２論理クエリは、前記論理モデルの論理オブジェクトを対象とし、前記命令は、さらに、前記プロセッサを、
前記論理モデルをホストするサーバに、前記第１論理クエリと前記第２論理クエリを少なくとも発行するように構成し、前記サーバにおいて、前記第１論理クエリは、第１のデータベースクエリに変換され、前記第２論理クエリは、第２のデータベースクエリに変換され、前記第１のデータベースクエリおよび前記第２のデータベースクエリは、前記データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とし、前記命令は、さらに、前記プロセッサを、
前記第１のデータベースクエリおよび前記第２のデータベースクエリを実行した結果受信したクエリ結果を比較し、
前記第１のデータベースクエリおよび前記第２のデータベースクエリの前記クエリ結果の前記比較が基準を満たさない場合、１つ以上の不整合を特定するように構成し、前記１つ以上の不整合は、前記メタデータによって定義される前記論理モデルとの不整合、または前記データベースにおける不整合を含む、システム。

【請求項15】

前記第１のデータベースクエリおよび前記第２のデータベースクエリは、対象とされる前記論理オブジェクトに関連する集約関数を用いて前記論理モデルをテストするように構成された対のデータベースクエリを含む、請求項１４に記載のシステム。

【請求項16】

前記第１論理クエリおよび前記第２論理クエリは、対象とされる前記論理オブジェクトに対応付けられたメタデータに基づいて生成され、前記第１のデータベースクエリおよび前記第２のデータベースクエリは、前記第１論理クエリおよび第２論理クエリを変換するために使われる対象とされる前記論理オブジェクトのマッピングに基づいて、前記データベーススキーマの前記ファクトテーブルおよび前記ディメンションテーブルを対象とする、請求項１５に記載のシステム。

【請求項17】

前記第１のデータベースクエリは、前記メタデータにおいて定義される前記メジャーデータの集約関数の定義に基づいて、１つ以上のディメンションに沿ったメジャーデータ値を集約し、前記第２のデータベースクエリは、前記メジャーデータ値のうち複数のメジャーデータ値を、１つ以上のディメンション属性別にグループ化する、請求項１６に記載のシステム。

【請求項18】

前記第１のデータベースクエリは、前記メジャーのディメンション定義、および前記メタデータにおいて定義される前記メジャーデータの集約関数の定義に基づいて、前記メジャーのすべてのディメンションに沿ったメジャーデータ値を集約する、請求項１７に記載のシステム。

【請求項19】

前記対のデータベースクエリのクエリ結果を比較することは、集約された前記メジャーデータ値を、グループ化された前記メジャーデータ値の集計と比較することを含む、請求項１７に記載のシステム。

【請求項20】

命令を記憶した非一時的なコンピュータ読み取り可能な媒体であって、前記命令は、プロセッサによって実行されると、前記プロセッサに、論理モデルの不整合を自律的にテストさせ、実行されると、前記命令は、前記プロセッサに、
論理モデルを記述したメタデータを取得させ、前記論理モデルは、データベーススキーマを抽象化したものを含み、前記データベーススキーマは、データベースにおいて実装され、前記データベーススキーマは、ファクトテーブルと、１つ以上のディメンションテーブルとを含み、前記プロセッサに、さらに、
取得した前記メタデータに基づいて、第１論理クエリと第２論理クエリとを少なくとも含む複数の論理クエリを自動的に生成させ、前記第１論理クエリおよび前記第２論理クエリは、前記論理モデルの論理オブジェクトを対象とし、前記プロセッサに、さらに、
前記論理モデルをホストするサーバに、前記第１論理クエリと前記第２論理クエリを少なくとも発行させ、前記サーバにおいて、前記第１論理クエリは、第１のデータベースクエリに変換され、前記第２論理クエリは、第２のデータベースクエリに変換され、前記第１のデータベースクエリおよび前記第２のデータベースクエリは、前記データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とし、前記プロセッサに、さらに、
前記第１のデータベースクエリおよび前記第２のデータベースクエリを実行した結果受信したクエリ結果を比較させ、
前記第１のデータベースクエリおよび前記第２のデータベースクエリの前記クエリ結果の前記比較が基準を満たさない場合、１つ以上の不整合を特定させ、前記１つ以上の不整合は、前記メタデータによって定義される前記論理モデルとの不整合、または前記データベースにおける不整合を含む、非一時的なコンピュータ読み取り可能な媒体。

【発明の詳細な説明】

【技術分野】

【0001】

分野
本開示の実施の形態は、概して、論理モデルの不整合を自律的にテストすることに関する。

【背景技術】

【0002】

背景
コンピューティングデバイスおよびコネクテッドデバイスの急増により、管理を必要とするデータが膨大な量になった。データ管理およびデータアクセスの側面では、複雑なデータスキーマの効率的なクエリ検索などの課題が残っている。いくつかの近年のデータベース実装は、たとえば、より簡素化された形式で論理クエリをサポートするために、複雑なデータスキーマを論理モデルに抽象化する層を含む。これに加えて、複雑なスキーマを実装するデータベースにデータを入力するために、抽出、変換、ロード（「ＥＴＬ」または「ＥＬＴ」）フローが利用され得る。これらの構成要素の複雑度およびそれらの相互作用に基づいて生じ得る数多くの様々な課題のために、従来技術を活用した場合、データ管理およびデータアクセスの側面が面倒になる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

概要
本開示の実施の形態は、概して、関連技術を実質的に改善できる、論理モデルの不整合を自律的にテストするためのシステムおよび方法を対象とする。

【0004】

論理モデルを記述したメタデータが受信され得る。ここで、論理モデルは、データベーススキーマを抽象化したものを含み、データベーススキーマは、データベースにおいて実装され、データベーススキーマは、ファクトテーブルと、１つ以上のディメンションテーブルとを含む。取得したメタデータに基づいて、第１論理クエリと第２論理クエリとを少なくとも含む複数の論理クエリが自動的に生成され得る。ここで、第１論理クエリおよび第２論理クエリは、論理モデルの論理オブジェクトを対象とする。論理モデルをホストするサーバに、第１論理クエリと第２論理クエリが少なくとも発行され得る。ここで、サーバにおいて、第１論理クエリは、第１のデータベースクエリに変換され、第２論理クエリは、第２のデータベースクエリに変換され、第１のデータベースクエリおよび第２のデータベースクエリは、データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする。第１のデータベースクエリおよび第２のデータベースクエリを実行した結果受信したクエリ結果が比較され得る。クエリ結果の比較が基準を満たさない場合、不整合が特定され得る。ここで、１つ以上の不整合は、メタデータによって定義される論理モデルとの不整合、またはデータベースにおける不整合を含む。

【0005】

実施の形態の特徴および利点は、以下の説明に記載される、または、当該説明から明らかになるであろう。あるいは、本開示を実施することによって分かるであろう。

【0006】

その他の実施の形態、詳細、利点、および変形例は、添付の図面と共に、以下の好ましい実施の形態についての詳細な説明から明らかになるであろう。

【図面の簡単な説明】

【0007】

【図1】例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするためのシステムを示す図である。

【図2】例示的な実施の形態に係る、自律テスト部に動作可能に連結されたコンピューティングデバイスのブロック図である。

【図3】例示的な実施の形態に係る、サンプルスターデータスキーマを示す図である。

【図4A】例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするためのシステムの実施態様を示す図である。

【図4B】例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするためのシステムの実施態様を示す図である。

【図5】例示的な実施の形態に係る、対のデータベースクエリとその結果を示す図である。

【図6】例示的な実施の形態に係る、対のデータベースクエリとその結果を示す図である。

【図7】例示的な実施の形態に係る、別の対のデータベースクエリとその結果を示す図である。

【図8】例示的な実施の形態に係る、別の対のデータベースクエリとその結果を示す図である。

【図9】例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするための例示的なフロー図である。

【発明を実施するための形態】

【0008】

詳細な説明
実施の形態は、論理モデルの不整合を自律的にテストすることを実現する。たとえば、データスキーマは、時として、結合およびその他の高度なクエリ構造を用いて非常に多くのテーブル／フィールドの関連性のあるデータを対象とする複雑なクエリを必要とし得る。このクエリの負担を軽減するために、いくつかのデータベース実装およびレポート作成ツールは、論理モデルを含む、または、基礎となる複雑なデータスキーマをより簡素化された論理モデルにマッピングする層を含む。たとえば、論理モデルは、その後、さらに過度に単純化した論理クエリを用いてクエリ検索され得る。これらの論理クエリは、基礎となるデータスキーマを対象とするクエリに変換される（たとえば、基礎となるデータスキーマのデータにアクセス／取得可能な複雑なクエリに変換される）。

【0009】

論理モデルのいくつかの実施の形態は、様々な集約機能、ドリルダウン機能、結合動作などを含む、複雑さの複数の層を含み得る。たとえば、複雑な論理モデルをデプロイするために使用できるメタデータを定義するなどによって当該モデルを素早く開発するために１つ以上のツールを用いることができる。いくつかの実施の形態では、ユーザーインタフェースを通して概念データモデルを定義するためにツールを用いることができ、このようなツールの出力は、論理データモデルを構成する構成要素の概念的関係を記憶したメタデータであり得る。

【0010】

いくつかの実施の形態では、これらのツールは、複雑なデータベースをデプロイすることを効率化できるが、デプロイには、下位レベルの不整合および／または不具合が含まれている場合がある。たとえば、論理モデルにおいて定義される集約機能が、基礎となるデータスキーマと一致しない場合があり、１つ以上のテーブルが正しくロードされなかったり、データフィールド（たとえば、Ｎｕｌｌであってはならない）の構成が正しく設定されなかったりなどする。これらの不整合および／または不具合は、従来、デバッグするために綿密な手作業を必要とする。

【0011】

実施の形態は、基礎となるデータスキーマとともに実装した場合の不整合および／または不具合を自律的にテストする論理モデルのメタデータに基づいて、クエリを生成する。たとえば、論理モデルのメタデータを取得および解析して、当該モデルの構成要素間の概念的関係を判断できる。いくつかの実施の形態では、解析したメタデータから判断して、論理モデルの想定される挙動およびデータスキーマに基づいてクエリを生成できる。たとえば、（たとえば、データスキーマの１つ以上のディメンション間の）想定される集約機能をテストする対のクエリを生成できる。

【0012】

実施の形態は、クエリの結果を解析する。たとえば、論理データモデルがデータの関係をデータスキーマに正確に反映している場合は同様の結果セット（たとえば、同じデータ値）を返すように２つ以上のクエリを設計できる。これらの２つ以上のクエリの返ってきた結果セットが類似していない場合は、論理モデルとの不整合があることを示し得る。その他の例では、データの間違ったロード、データベースのテーブルまたはカラムがないこと、間違った埋込みＳＱＬ表現、および／またはデータフィールドの間違った構成を理由にクエリエラーが返されてもよい。いくつかの実施の形態では、想定される結果から逸脱したこれらの結果を用いて、これらの不整合のうち１つ以上を特定できる。

【0013】

ここで、本開示の実施の形態について詳細に説明する。実施の形態の例は、添付の図面に示している。以下の詳細な説明では、本開示を十分に理解してもらうため、いくつかの具体的な詳細を説明する。しかしながら、これらの具体的な詳細がなくても本開示を実施することができることは、当業者であれば分かるであろう。その他の場合、周知の方法、プロシージャ、構成要素、論理積回路については、実施の形態の態様を不必要に曖昧にしないために、詳細を説明しない。可能な限り、同一の要素には同一の参照番号を付している。

【0014】

図１は、実施の形態に係る、論理モデルの不整合を自律的にテストするためのシステムを示す図である。システム１００は、メタデータ取得１０２、メタデータ解析１０４、クエリ生成１０６、クエリ実行１０８、結果比較１１０、および発見された不整合１１２を含む。メタデータ取得１０２は、論理モデルの構成要素間の概念的関係（たとえば、データのテーブル、カラム、キー、結合など）を定義するメタデータなど、論理データモデルのメタデータの取得を含み得る。メタデータ解析１０４は、取得したメタデータを解析して、これらの概念的関係を特定できる。クエリ生成１０６は、解析したメタデータから判断して、論理モデルの想定される挙動およびデータスキーマに基づいて、対のクエリなどのクエリ、一連の関連クエリなどを生成できる。たとえば、（たとえば、論理モデルの１つ以上のディメンション間の）想定される集約機能をテストするための対のクエリを生成でき、その他の適したクエリも生成できる。

【0015】

クエリ実行１０８は、論理モデルを実装するサーバを用いて、データスキーマを実装するデータベースにおいてクエリを実行できる。たとえば、クエリ実行は、生成されたクエリ（たとえば、論理クエリ）を変換クエリ（たとえば、データスキーマのクエリ）にサーバが変換することを含み得、データスキーマ（たとえば、データベース）の実装からデータを取得するために変換クエリを使用できるようになる。いくつかの実施の形態では、データベースにおいて変換クエリを実行した結果の結果セットを返すことができる。結果比較１１０は、クエリの結果を比較して、（たとえば、整合性が想定されている場合の）不整合または、その他の想定外の挙動を特定できる。

【0016】

たとえば、論理データモデルがデータの関係をデータスキーマに正確に反映した場合などでは同様の結果（たとえば、最大でしきい値差を有する１つ以上の値を有する結果セット）を返すよう、生成された対（またはセット）のクエリを設計できる。類似した結果を出すように設計された２つ以上のクエリが実際には類似しない結果セットを返したと結果比較１１０が判断した場合、不整合を特定できる。これに加えて、いくつかのクエリは、データの間違ったロードや、データフィールドの間違った構成を理由にエラーを返してもよい。いくつかの実施の形態では、想定される結果から逸脱したこれらの結果を用いて不整合（たとえば、データモデルと実装されたデータスキーマとの間で、誤ってロードされたデータに基づく不整合など）を特定できる。

【0017】

いくつかの実施の形態では、（たとえば、データベースにおいて実装される）基礎となるデータスキーマは、リレーショナルデータテーブルのセット、多次元データスキーマ、第３正規形（「３ＮＦ」）スキーマなどの一連の規則または規格に従って構成されたリレーショナルテーブルのセット、およびその他の適したスキーマなど、データを記憶するための任意の適切なスキーマであってもよい。一般に、スキーマは、１つ以上のデータのカラムを有するデータテーブルを含む。スキーマは、テーブルおよびテーブルが記憶しているデータだけでなく、テーブル間の関係によっても定義される。たとえば、第１テーブルと第２テーブルとの関係は、これらのテーブルのそれぞれに記憶されたデータ同士をリンクする外部キーによって定義できる。いくつかの実施の形態では、２つのテーブルは、複数の関係を共有してもよい（たとえば、テーブル間の関係を定義する複数の外部キーを有してもよい）。テーブル間の様々な種類の関係については、本明細書においてさらに開示する。

【0018】

データスキーマおよび論理モデルの設計は、設計者によって異なる場合が多い。たとえば、所与のセットの関係を有する所与のセットのデータを、設計および／または論理モデルが異なる複数のデータスキーマによって正常に表すことができる。一部の設計は、特定のセットのデータを取得するためにテーブル結合を必要としてもよいが、その他の設計はそれを必要としない。したがって、テスト中のデータスキーマおよび論理モデルは、任意の適切な設計事項を含み得、クエリ生成１０６によって生成されてクエリ実行１０８によって実行されるクエリは、様々な異なるデータスキーマおよび論理モデルの不整合および／または不具合をテストするように設計され得る。

【0019】

図２は、実施の形態に係る、コンピュータサーバ／システム２１０のブロック図である。図２に示すように、システム２１０は、プロセッサ２２２およびメモリ２１４など、システム２１０の様々な構成要素間で情報を伝達するように構成されたバスデバイス２１２および／またはその他の通信機構（複数可）を備えてもよい。これに加えて、プロセッサ２２２からその他のデバイスにネットワーク（図示せず）で送信されるデータを符号化し、当該ネットワークでその他のシステムから受信したプロセッサ２２２宛てのデータを復号化することによって、通信装置２２０は、プロセッサ２２２とその他のデバイスとの間の接続性を可能にしてもよい。

【0020】

たとえば、通信装置２２０は、ワイヤレスネットワーク通信を提供するように構成されたネットワークインターフェースカードを備えてもよい。赤外線、無線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ、および／またはセルラー通信を含む様々なワイヤレス通信技術が用いられてもよい。あるいは、通信装置２２０は、Ｅｔｈｅｒｎｅｔ（登録商標）接続など、有線ネットワーク接続（複数可）を提供するように構成されてもよい。

【0021】

プロセッサ２２２は、システム２１０の計算機能および制御機能を実行するための１つ以上の汎用プロセッサまたは特定用途向けプロセッサを備えてもよい。プロセッサ２２２は、マイクロ処理装置など、１つの集積回路を備えてもよく、連携して動作してプロセッサ２２２の機能を実現する複数の集積回路デバイスおよび／または複数の配線基板を備えてもよい。これに加えて、プロセッサ２２２は、オペレーティングシステム２１５、自律テスト部２１６、およびその他のアプリケーション２１８など、メモリ２１４内に記憶されたコンピュータプログラムを実行してもよい。

【0022】

システム２１０は、情報およびプロセッサ２２２によって実行される命令を記憶するためのメモリ２１４を備えてもよい。メモリ２１４は、データを取得、提示、修正、および記憶するための様々な構成要素を備えてもよい。たとえば、メモリ２１４は、プロセッサ２２２によって実行されると機能を提供するソフトウェアモジュールを記憶してもよい。これらのモジュールは、システム２１０のオペレーティングシステム機能を提供するオペレーティングシステム２１５を含んでもよい。モジュールは、オペレーティングシステム２１５と、自律テスト部２１６と、その他のアプリケーションモジュール２１８とを含んでもよい。オペレーティングシステム２１５は、システム２１０のオペレーティングシステム機能を提供する。自律テスト部２１６は、データスキーマの不整合を自律的にテストするためのシステム機能を提供してもよく、本開示のその他の機能をさらに提供してもよい。場合によっては、自律テスト部２１６をインメモリ構成として実装してもよい。

【0023】

非一時的なメモリ２１４は、プロセッサ２２２がアクセスできる様々なコンピュータ読み取り可能な媒体を含んでもよい。たとえば、メモリ２１４は、ランダムアクセスメモリ（「ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）」）、ダイナミックＲＡＭ（「ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）」）、スタティックＲＡＭ（「ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）」）、読み取り専用メモリ（「ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）」）、フラッシュメモリ、キャッシュメモリ、および／またはその他の種類の非一時的なコンピュータ読み取り可能な媒体の任意の組合せを含んでもよい。

【0024】

プロセッサ２２２は、さらに、液晶ディスプレイ（「ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）」）などのディスプレイ２２４にバス２１２を介して連結される。通信装置２１２には、キーボード２２６、およびコンピュータマウスなどのカーソルコントローラ装置２２８がさらに連結されて、ユーザをシステム２１０にインタフェース接続することを可能にする。

【0025】

いくつかの実施の形態では、システム２１０は、大規模システムの一部であってもよい。そのため、システム２１０は、追加機能を備えるために１つ以上の追加の機能モジュール２１８を備えることができる。その他のアプリケーションモジュール２１８が、Ｏｒａｃｌｅ（登録商標）Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ（「ＢＩ」）、Ｏｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ、Ｏｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｓｅｒｖｅｒ、およびその他の適した構成要素など、運用システムおよびデータウェアハウスターゲットを備えるデータウェアハウスの様々な構成要素を含んでもよい。バス２１２にはデータベース２１７が連結されて、モジュール２１６および２１８のための集中ストレージを提供し、たとえば、ワイヤレスデバイスのアクティビティ、いくつかの実施の形態では、ユーザプロファイル、トランザクション履歴などを記憶する。データベース２１７は、論理的に関連したレコードまたはファイルからなる統合コレクションにデータを記憶することができる。データベース２１７は、運用データベースであってもよく、アナリティカルデータベースであってもよく、データウェアハウスであってもよく、分散データベースであってもよく、エンドユーザデータベースであってもよく、外部データベースであってもよく、ナビゲーショナルデータベースであってもよく、インメモリデータベースであってもよく、ドキュメント指向データベースであってもよく、リアルタイムデータベースであってもよく、リレーショナルデータベースであってもよく、オブジェクト指向データベースであってもよく、Ｈａｄｏｏｐ（登録商標）分散型ファイルシステム（「ＨＦＤＳ（Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ）」）であってもよく、は当技術分野で周知のその他のデータベースであってもよい。

【0026】

１つのシステムとして図示しているが、システム２１０の機能は分散システムとして実装されてもよい。たとえば、まとめてシステム２１０を表す複数の異なるコンピュータ間でメモリ２１４およびプロセッサ２２２を分散してもよい。一実施の形態において、システム２１０は、デバイス（たとえば、スマートフォン、タブレット端末、コンピュータなど）の一部であってもよい。実施の形態では、システム２１０は、当該デバイスとは別個であってもよく、記載の機能を遠隔でデバイスに提供してもよい。さらには、システム２１０の１つ以上の構成要素を省略してもよい。たとえば、ユーザデバイスまたは消費者向けデバイスとしての機能の場合、システム２１０は、プロセッサと、メモリと、ディスプレイとを備え、図２に示すその他の構成要素のうちの１つ以上を備えず、図２に示されていない追加コンポーネントを備えるスマートフォンまたはその他のワイヤレスデバイスであってもよい。

【0027】

図１に戻ると、実施の形態は、論理モデルのメタデータを用いて対象にされるクエリを使用して、当該論理モデルの不整合を自律的にテストする。たとえば、リポジトリファイル（たとえば、ＲＰＤファイル）を定義するツールなど、論理モデルを定義するメタデータを生成するために１つ以上のツールを用いることができる。リポジトリファイルは、データ構造（たとえば、リレーショナルテーブルおよび／または論理オブジェクト）、データフィールド（たとえば、カラム）、データ構造間の関係（たとえば、外部キー、結合など）、データの機能（たとえば、集約機能、ドリルキーなど）、およびその他の論理モデルに関連する情報を定義できる。

【0028】

論理モデルの実施の形態は、基礎となるデータスキーマ論理を抽象化したものである。図３は、例示的な実施の形態に係る、サンプルスターデータスキーマを示す図である。データスキーマ３００は、ファクトテーブル３０２と、ｄｉｍｅｎｓｉｏｎ＿１テーブル３０４と、ｄｉｍｅｎｓｉｏｎ＿２テーブル３０６と、ｄｉｍｅｎｓｉｏｎ＿３テーブル３０８とを含む。一般に、スタースキーマでは、ファクトテーブルがドメインについてのファクトを保持し、ディメンションテーブルがこれらのファクトの属性を保持する。その結果、ファクトテーブル３０２は、ｄｉｍｅｎｓｉｏｎ＿１テーブル３０４と、ｄｉｍｅｎｓｉｏｎ＿２テーブル３０６と、ｄｉｍｅｎｓｉｏｎ＿３テーブル３０８との様々な外部キー関係を有する。すなわち、ファクトテーブルの一部のロウは、外部キー（「ＦＫ」）である。外部キーは、ディメンションテーブルへのリンクであり得る。ディメンションテーブルは、１つ以上のファクトテーブルによって参照されるイベントに対応付けられたコンテキストを記憶するテーブルであり得る。

【0029】

スターデータスキーマは、スノーフレークデータスキーマと同様であるが、いくつかの違いがある。たとえば、スノーフレークデータスキーマは、複数の関連テーブルに正規化されるディメンションを含むが、スタースキーマは、各ディメンションが１つのテーブルによって表される非正規化されたディメンションを有する。これらのスキーマのそれぞれから、データ冗長性、クエリ設計の単純化などに関連する異なる利点がもたらされる。たとえば、正規化によるストレージ効率という利点は、正規化されたデータスキーマのクエリ検索の効率を犠牲にしてしまう可能性がある。テスト中のデータスキーマの実施の形態は、ディメンションテーブルとのつながりを有するファクトテーブル、スタースキーマとして編成されたテーブル、スノーフレークスキーマとして編成されたテーブル、およびその他の適したデータスキーマ構造を含み得る。

【0030】

基礎となるデータスキーマを抽象化するために論理モデルの実施の形態を用いることができ、クライアント（たとえば、エンドユーザ）が（たとえば、論理モデルのメタデータを用いて）変換される論理クエリを発行できるようになる。たとえば、データベース（たとえば、データが入力されているデータスキーマの実装）に対してクエリ検索を行って、結果セットを取得するために変換クエリを用いることができる。論理モデルの実施の形態は、メタデータを用いて定義され、関連するビジネスインテリジェンス機能は、メタデータに基づいて生成できる。たとえば、ビジネスインテリジェンス機能は、物理層、ビジネスモデル／マッピング層、およびプレゼンテーション層のうち１つ以上の層など、複数の層を含み得る。

【0031】

例示的な物理層は、（たとえば、論理クエリを変換するために用いられる）物理的なデータソースのそれぞれに対してネイティブクエリを書き込むために用いられるオブジェクトおよび関係を定義できる。たとえば、データソースからテーブル、キューブ、およびフラットファイルをインポートすることによって物理層を作成できる。物理モデルから論理的挙動を切り離すことによって、複数の物理ソースを同じ論理オブジェクトに連合させる機能がもたらされ、集約ナビゲーションおよびパーティション分割、ならびにディメンションの適合、および物理ソースの変化からの隔離を可能にする。

【0032】

例示的なビジネスモデル／マッピング層は、データのビジネスモデルまたは論理モデルを定義し、論理モデルと物理スキーマとのマッピングを指定できる。たとえば、この層は、クライアント／エンドユーザが見ることのできる解析挙動を決定でき、クライアント／エンドユーザが利用できるオブジェクトおよび関係のスーパーセットを定義できる。いくつかの実施の形態では、ビジネスモデルの各カラムは、物理層にある１つ以上のカラムにマッピングできる。ランタイム時、論理ＳＱＬの要求をビジネスモデルに照らして評価でき、このマッピングは、関連性のある物理クエリを生成するための一式の物理テーブル、ファイル、およびキューブを決定するために用いることができる。マッピングは、計算および変換を含み得、いくつかの実施態様では、複数の物理的なテーブルを組み合わせてもよい。

【0033】

例示的なプレゼンテーション層は、カスタマイズされたセキュアな役割ベースのビジネスモデルのビューをユーザに提示するためのメカニズムを提供する。たとえば、プレゼンテーション層は、ビジネスモデルおよびマッピング層に抽象化のレベルを追加し、要求を構築しているユーザによって見られるデータのビューを提供できる。いくつかの実施の形態では、１つのビジネスモデルにマッピングする複数の対象領域をプレゼンテーション層によって作成することができ、このビジネスモデルを効果的に複数の管理可能な部分に分割する。

【0034】

クエリ変換について例をあげて説明するために、論理モデルをホストするサーバにおいて受信され得る下記のサンプル論理クエリについて考える。

【0035】

【表1】

【0036】

いくつかの実施の形態では、サーバは、このような論理クエリを、１つ以上の変換クエリ、または基礎となるデータスキーマ／データベース向けに設計された１つ以上のクエリに変換し得る。受信した論理クエリに基づいてサーバによって変換された下記のサンプルクエリについて考える。

【0037】

【表2】

【0038】

この変換によって実証されるように、論理モデルにある論理オブジェクトを対象とする簡略化された論理クエリを、データスキーマの特定のコンポーネントを対象とするデータベースクエリに変換する。特に、データスキーマの特定の要素を、論理クエリ内の論理コンポーネント（たとえば、論理オブジェクト）として抽象化し、これらの抽象化を、変換クエリ内のそれらの基礎となる物理コンポーネントにマッピングする。この例は、クエリ変換の問題または論理モデルのその他のコンポーネントの問題が不具合のある結果または誤った結果を生じせると論理モデルにおける定義がデータスキーマを実装するデータベースのクエリ検索に影響を与えてしまう理由について説明している。

【0039】

従来の論理モデルについての機能テストは、多くの場合、メタデータが（たとえば、ＲＰＤモデルに）正しく変換されていることを検証するためのパターンに依拠する。このようなテストは、ＲＰＤモデルが指定された通り機能することを検証できる一方で、作成された解が基礎となるデータスキーマとともに機能する（たとえば、想定される結果を生成する）ことを保証してくれない。たとえば、生成されたモデルを完全検証するには、複雑なモデルのサイズを理由にかなりの手作業を必要とするであろう。

【0040】

従来の生成器を用いて作成された論理モデルは、多くの場合、モデル不全、およびパフォーマンスの問題につながり、たとえば、その他の開発活動の副次的効果として検出される。これらの知見は、従来のモデルでは検出されない整合性の問題があることを示している。たとえば、誤った挙動を生じさせる可能性のある潜在的エラーの例示的なクラスは、以下を含む。

【0041】

●ＲＰＤモデルは、一部の予期しないケースには適さない場合があり、モデル不全を生じさせてしまう。

【0042】

●ディメンションを要求されたとおりにメタデータに記述できるが、基礎となるデータが、データがオプションであり、ＮＵＬＬになり得ることを示している（たとえば、誤って定義されたファクトＦＫカラムのメタデータによって引き起こされる可能性が高い）。

【0043】

●テーブルが正しく／完全にロードされない。これは、カレンダーディメンションと時間ディメンションで共通の問題であり得、間違ってロードされた集約テーブルの問題であり得る。

【0044】

●クエリに属性を追加したときに一部のクエリのパフォーマンスが想定外に低下する場合がある（たとえば、説明カラムが正しくモデル化または実装されていないことによって生じ得る）。

【0045】

実施の形態は、系統的かつ自動的に論理データモデル（たとえば、ＲＰＤ）のテストを実行して、モデルの品質および／または論理モデルとデータスキーマとの一致を向上させることができることを実証している。たとえば、監査ツールの実施の形態は、１つまたは複数の予め定義されたテスト戦略に基づいてデータまたは論理モデルの不整合を自律的に検出できる。いくつかの実施の形態では、１つ以上のメタデータサービスを利用して、対象領域、テーブル、およびカラムを含む、論理モデルを記述するメタデータ（たとえば、ウェブサービスを介して）を取得できる。実施の形態によって論理モデルのメタデータを用いて、（たとえば、ウェブサービスを利用するサーバに対して）発行される一連の論理クエリを生成できる。たとえば、論理層は、論理クエリを（たとえば、基礎となるデータスキーマをクエリ検索するように設計された）変換クエリに変換し得る。変換クエリは、最終的には、データベースをクエリ検索するために使用される。クエリ結果は、取り込んで整合性を比較することができ、整合性のない結果を有するクエリには、フラグを立てることができる。

【0046】

図４Ａおよび図４Ｂは、例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするためのシステムの実施態様を示す図である。たとえば、図４Ａのシステムは、テスト戦略４０２、自律的ディメンションテスト部（「Ａｕｄｉｔ」）４０４、サーバ４０６、ウェブサービス４０８、意味的モデル４１０、およびデータベース４１２を示す。テスト戦略４０２は、データスキーマを定義するメタデータに基づいてテストクエリを生成するために使われるソフトウェア機能を含み得る。たとえば、データ構造、および取得したメタデータが示す構造間の関係に基づいて、テスト戦略４０２は、監査クエリを生成するためのソフトウェア機能を実装できる。

【0047】

Ａｕｄｉｔ４０４は、監査クエリを生成し、実行するクエリを発行し、監査クエリの結果を受信し、結果を解析して意味的モデル４１０における不整合および／または不具合を検出するためのテスト戦略４０２を実装できる。いくつかの実施の形態では、クライアントデバイス、サーバ、任意のクラウドコンピューティングデバイス、またはその他の適したコンピューティングデバイスにおいてテスト戦略４０２およびＡｕｄｉｔ４０４を実装できる。

【0048】

サーバ４０６は、ウェブサービス４０８をホストする、意味的モデル４１０を記憶する、および／またはデータベース４１２を実装する１つ以上のサーバ（たとえば、ウェブサーバ、クラウドサーバ、仮想マシンなど）であり得る。たとえば、サーバ４０６は、ビジネスインテリジェンス製品（たとえば、Ｏｒａｃｌｅ（登録商標）Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ）、解析製品（たとえば、Ｏｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｓｅｒｖｅｒおよび／またはＯｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ）、データウェアハウス（たとえば、Ｏｒａｃｌｅ（登録商標）データウェアハウス）などのコンポーネントを含み得る。いくつかの実施の形態では、サーバ４０６は、論理クエリを基礎となるデータベース／データスキーマ向けに設計されたクエリに変換するためのクエリ変換技術を実装する。

【0049】

たとえば、サーバ４０６／意味的モデル４１０は、図４Ｂによって示されているような関連するビジネスインテリジェンス機能を備え得る。図４Ｂは、論理クエリ４２０、プレゼンテーション層４２２、ビジネスモデル／マッピング層４２４、物理層４２６、およびデータソース４２８を示す。いくつかの実施の形態では、Ａｕｄｉｔ４０４は、（取得したメタデータに基づいた）論理クエリ４２０をサーバ４０６に発行し得る。サーバ４０６は、次に、プレゼンテーション層４２２、ビジネスモデル／マッピング層４２４、および物理層４２６を介して論理クエリを変換し、最終的にデータソース４２８に対して変換クエリを発行する（たとえば、図４Ａのデータベース４１２）。次に、変換クエリを使用するクエリのデータソース４２８からの結果セットがＡｕｄｉｔ４０４に返され得る。

【0050】

いくつかの実施の形態では、たとえば、Ａｕｄｉｔ４０４からのアプリケーションプログラミングインタフェース（「ＡＰＩ」）呼び出しに応答して意味的モデル４１０についてのメタデータをＡｕｄｉｔ４０４に提供するようにウェブサービス４０８を構成できる。たとえば、Ａｕｄｉｔ４０４は、サーバ４０６に対するウェブサービス呼び出しを抽象化するウェブサービスＡＰＩ抽象化を含み得る。いくつかの実施の形態では、この抽象化により、実装拡張性を提供できるようになり、代替物（たとえば、ＲＥＳＴベースのＡＰＩ）が使えるようになる。

【0051】

いくつかの実施の形態では、ウェブサービス４０８は、テーブル（たとえば、ファクト、ディメンション、時間ディメンション）およびディメンションの詳細（たとえば、説明カラム、ビンおよびビン分割されたカラム、階層およびレベルなどの詳細、ドリルキー、記述キーなど）を記述したリッチ化されたデータ構造を用いて対象領域を記述するメタデータサービスを含む。たとえば、ウェブサービス４０８は、Ｏｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ（「ＯＡＣ」）のウェブサービス、および／またはＯｒａｃｌｅ（登録商標）Ａｎａｌｙｔｉｃｓ Ｓｅｒｖｅｒ（「ＯＡＳ」）のウェブサービスを含み得る。

【0052】

いくつかの実施の形態では、ＯＡＣが提供するウェブサービスには、（たとえば、オーバーヘッドを減らすために）Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（「ＳＯＡＰ」）クライアントを通じてアクセスすることができる。たとえば、Ａｕｄｉｔ４０４にあるＳＯＡＰクライアントＡＰＩをクラスにカプセル化して、特定のＳＯＡＰクライアント実装に対するその他の論理の依存状態を最小限に抑えることができる。いくつかの実施の形態では、ウェブサービス４０８は、ウェブサービスにログインおよびログオフするための技術、それぞれ異なるオブジェクトの意味的モデル４１０のメタデータ（たとえば、ＲＰＤメタデータ）を取得するための技術、および論理ＳＱＬクエリを発行するための技術を提供できる。いくつかの実施の形態では、ウェブサービス４０８は、ＡＰＩの実装の詳細の一部を非表示にするオブジェクトを返すことができる。たとえば、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（「ＸＭＬ」）文書を、リストまたは文字列、辞書、または、その他のオブジェクトなどのオブジェクト表現に変換できる。

【0053】

いくつかの実施の形態では、ウェブサービス４０８は、下記のウェブサービスをサポートできる。

【0054】

●ウェブサービスにログインして使用後にログオフするためのＳＡＷＳｅｓｓｉｏｎＳｅｒｖｉｃｅ
●対象領域の名称および対象領域、テーブル、ならびカラムの説明（非表示である場合、および説明カラムの場合、カラムタイプを示す）を取得するためのＭｅｔａｄａｔａ Ｓｅｒｖｉｃｅ
●論理ＳＱＬクエリを発行して結果セットを取得するためのＸＭＬＶｉｅｗＳｅｒｖｉｃｅ
●ＸＵＤＭＬの断片としてメタデータを取得するためのＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓ。いくつかの実施の形態では、取得したＸＭＬを構文解析して関連性のある詳細を抽出する。

【0055】

いくつかの実施の形態では、対象領域の名称、プレゼンテーションテーブルの詳細、およびそれらのカラムなどのベースメタデータは、ＯＡＣメタデータサービスを用いて取得できる。いくつかの実施の形態では、ディメンションおよびカラムについての詳細な情報は、ＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓのウェブサービスを用いて取得できる。情報のタイプ毎にＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓのウェブサービスによって返されるＸＵＤＭＬの分散は、いくつかの実施態様において存在しており、この場合、Ａｕｄｉｔ４０４は、それぞれ異なるオブジェクトタイプのメタデータを取得するように構成される１つ以上の特定のＡＰＩを備え得る。

【0056】

いくつかの実施の形態では、ウェブサービス４０８は、（たとえば、ＯＡＣメタデータサービスを用いて取得される）モデルの基本情報を充実させる単純なモデルによって対象領域、プレゼンテーションテーブル、およびプレゼンテーションカラムを表すことができる。

【0057】

●テーブルは、ファクトテーブルまたはディメンションテーブルとして分類できる。
●ディメンションテーブルモデルは、関連する階層、レベル、ドリルキー、および関連するカラムの表現を提供できる。

【0058】

●ディメンションおよびファクトの属性カラムを、カラムが説明であるかビンカラムであるか、算出されるか、主キー（「ＰＫ」）カラムであるかなどを示すフラグを含むように拡張できる。

【0059】

●ファクトメジャーは、カラムが算出される場合、高度な集約規則（たとえば、半加算的なメジャー）についてのさらなる詳細を提供でき、レベルベースのメジャーについての特定の詳細を提供できる。

【0060】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、メジャー（たとえば、集約機能を有するカラム）の存在に基づいてファクトテーブルを特定するためのソフトウェアを含み得る。また、ウェブサービス４０８は、ＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓサービスを含み得る。ＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓサービスは、プレゼンテーション、論理、および／または物理ＲＰＤモデルを記述したＸＵＤＭＬの断片を返すことができる。

【0061】

いくつかの実施の形態では、ウェブサービス４０８のＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓサービスの支援を受けて、Ａｕｄｉｔ４０４からのメタデータクエリをアドレス指定できる。たとえば、ＮＱＳＱｕｅｒｙＭｅｔａｄａｔａＯｂｊｅｃｔｓサービスは、以下を返すことができる。

【0062】

●ＰＫカラムおよびドリルキー、
●レベルおよび階層（レベルの順序を含む）、
●レベルに対応付けられた属性、
●算出されるＩＤカラム（Ｐｒｅ－ＡｇｇｒｅｇａｔｉｏｎまたはＰｏｓｔ－Ａｇｇｒｅｇａｔｉｏｎ）の特定、
●レベルベースのメジャー、および、
●ディメンションベースの集約規則を有するメジャー。

【0063】

いくつかの実施の形態では、詳細なテーブルおよびカラムの特徴を取得するために、アルゴリズムは、参照または親にある完全修飾名を用いて、プレゼンテーションオブジェクトを関連する論理（さらには物理）オブジェクトにトレースできる。いくつかの実施の形態では、論理テーブルの名称は、一致するプレゼンテーションオブジェクトの英語名称を定義するために「Ｄｉｍ－」、「Ｆａｃｔ」、および「Ｈｉｅｒ－」という接頭辞を除去するための処理など、処理すべき特定の命名規則を含む。いくつかの実施の形態では、トレードオフは、ＸＵＤＭＬの断片を取得するためのラウンドトリップが減ることであるため、テストの処理能力が向上する。

【0064】

Ａｕｄｉｔ４０４およびウェブサービス４０８の実施の形態は、下記の技術のうち１つ以上を用いて機能とパフォーマンスのバランスをとることを目的とする。

【0065】

【表3】

【0066】

いくつかの実施の形態では、これらのカラムをプレゼンテーションカラム（たとえば、以前取得した情報）と照合してどのプレゼンテーションカラムがテーブルのドリルキーであるか、ＰＫであるかを判断できる。いくつかの実施の形態では、論理キーの取得は、一括操作（Ｂｕｌｋ Ｏｐｅｒａｔｉｏｎ）を含む。なぜならば、たとえば、論理ディメンション（たとえば、階層オブジェクト）は、そのドリルキーを通して関連付けられるためである。たとえば、時々、（ドリル）キーの数は、カラムの数と比較すると少ないので、ドリルキーに基づく一括操作によってパフォーマンスを改善することができる。これに加えて、パフォーマンスの問題は、結果をキャッシュ保存してその他のディメンションテーブルを解析するときに追加のラウンドトリップをなくすことによって軽減できる。いくつかの実施の形態では、この手法の代替となる手法は、プレゼンテーションディメンションテーブルから参照される論理ディメンションオブジェクトを特定することである。これにより、論理レベルの取得が可能になるであろう。しかしながら、これには、いくつかの実施態様において、プレゼンテーションテーブル毎に２つのサービス呼び出しを伴う。

【0067】

同様に、実施の形態は、メタデータを取得するためにその他の適した技術を実装できる。たとえば、メタデータを取得するために１つ以上のその他のＡＰＩ（または、その他のインタフェース／取得の抽象化）を用いてもよく、メタデータがその他の態様（たとえば、対象領域以外）に基づいて取得されてもよく、および／またはその他の適した技術を実装することもできる。

【0068】

【表4】

【0069】

いくつかの実施の形態では、ウェブサービス４０８を用いて（たとえば、サーバ４０６から）取得したメタデータは、対象領域にあるテーブルがディメンションであるかファクトテーブルであるかを示さない。しかしながら、テーブルカラムは、カラムの名称、説明、データ型、および集約規則を示し得る。いくつかの実施の形態では、定義済みの集約型を有する少なくとも１つのカラムを含んだテーブルは、ファクトテーブルとみなすことができ、定義済みの集約規則を有するファクトテーブルのカラムは、メジャーとみなすことができる。

【0070】

いくつかの実施の形態では、カレンダーディメンションテーブルの名称は、「Ｄａｔｅ」で終わり得、時間ディメンションテーブルの名称は、「Ｔｉｍｅ」で終わり得る。また、実施態様は、「Ｍｏｎｔｈ」、「Ｑｕａｒｔｅｒ」、「Ｙｅａｒ」、「Ｐｅｒｉｏｄ」、「Ｆｉｓｃａｌ Ｑｕａｒｔｅｒ」、または「Ｆｉｓｃａｌ Ｙｅａｒ」で終わり得る縮めたカレンダーディメンションを含み得る。

【0071】

【表5】

【0072】

【表6-1】

【0073】

【表6-2】

【0074】

【表6-3】

【0075】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、テストケース（たとえば、Ｐｙｔｈｏｎのテストケース）を動的に生成して、テストケースを適したツール（たとえば、ＪＵｎｉｔ－ｓｔｙｌｅＸＭＬ形式でテスト結果を作成するＸＭＬＲｕｎｎｅｒ）で実行できる。実施の形態は、別個のテストケースを生成することによって特定の便利なインフラストラクチャを活用できる。テストは、ウェブサービス４０８からモデルのメタデータが取得されてから初めて分かる意味的モデル４１０の構造（たとえば、ＲＰＤ）によって決まるので、実施の形態は、取得したメタデータに基づいてクラスおよびクラスメソッド（たとえば、Ｐｙｔｈｏｎのクラスおよびメソッド）を動的に作成できる。たとえば、対象領域毎にｕｎｉｔｔｅｓｔ．ＴｅｓｔＣａｓｅのサブクラスを作成でき、テストケース毎に１つ以上のテストメソッドを対象領域内で定義できる。

【0076】

いくつかの実施の形態では、対象領域毎に別個のテストケースクラスを作成でき、複数の単体テストケースを作成および追加できる（たとえば、「ｔｅｓｔ」という名称から始まる関数によって表される）。たとえば、この編成は、対象領域に関連する複数のテスト結果を１つのリポートにグループ化し得る。下記の例示的機能は、サンプルクラス／メソッドを動的に生成するこの技術を説明している。

【0077】

【表7-1】

【0078】

【表7-2】

【0079】

上記例示的機能は、対象領域毎に１つのクラスを生成し、２つの動的に生成されたクラスメソッドで実装された単体テスト毎に２つのテストを実行する。テストケースは、説明／パラメータとして定義でき、各テストケースを実行する関数が生成され得る。実施の形態は、この編成を実現できる。なぜならば、メジャーがグループ化される対象領域、メジャー、および属性（複数可）別に監査テストが定義されるためである。実施の形態は、標準のＰｙｔｈｏｎの単体テストフレームワークをｕｎｉｔｔｅｓｔ．ｍａｉｎ（）というコマンドで実行できる。ｕｎｉｔｔｅｓｔ．ｍａｉｎ（）は、テストクラスおよびテストメソッドを自動的に発見でき、続いてこれらを実行できる。

【0080】

いくつかの実施の形態では、テストケースの実行およびテスト結果を、ＨＴＭＬに変換可能なＪｕｎｉｔＸＭＬ形式で取り込むことができる。テストケースを、１つまたは複数のテスト戦略によって作成されるテストスイートの説明として指定できる。いくつかの実施の形態では、ランタイムコンポーネントが指定のテストケースを作成して単体テストフレームワークでこれらを実行できる。たとえば、Ａｕｄｉｔ４０４の機能をＪｅｎｋｉｎｓのビルド処理を用いて実装できる。

【0081】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、論理モデルを記述したメタデータを取得し、メタデータを解析して論理モデルを構成するデータ構造間の関係を判断し、論理モデルの不整合をテストするための論理クエリを生成する。たとえば、クエリ戦略の中でも特に、集約機能における不整合をテストするための１つ以上の対のクエリ（たとえば、基準クエリおよびテストクエリ）を生成でき、データスキーマの結合を列挙するためのクエリを生成でき、スキーマの不具合を示すパフォーマンスの問題を検出するための、複雑度が大きいクエリを生成できる。

【0082】

実施の形態は、下記のアルゴリズムを用いて１つ以上の論理クエリを生成できる。１つ以上のメジャーを選択するために、取得および解析されたメタデータを用いることができる。たとえば、実装されたテスト戦略（たとえば、所与のテスト戦略のソフトウェア機能）は、解析したメタデータに基づいてメジャーを選択できる。いくつかの実施の形態では、その後、実装されたテスト戦略は、メジャーをグループ化できる属性のグループを定義できる。たとえば、テスト戦略は、選択したメジャーに関連性のあるメタデータの解析に基づいて、グループ化するための属性を決定できる。いくつかの実施の形態では、テスト戦略は、基準（たとえば、ＰＫカラム）に基づいてディメンション当たり１つの属性を選択できる、テストされるドリルキーまたは説明カラムを１つのグループ化基準として列挙できる、または、グループ化のための属性を決定するためのその他の適した技術を実装できる。

【0083】

いくつかの実施の形態では、テスト戦略は、選択したメジャー、および決定した属性別のグループに基づいて、データ構造のリストを生成できる。たとえば、各データ構造は、メジャーおよび属性別のグループを定義できる（たとえば、対のテストに関連性のある属性、または基準クエリおよびテストクエリ）。いくつかの実施の形態では、クエリ生成器は、クエリを発行するためにデータ構造を用いることができる。たとえば、基準クエリは、メジャー（たとえば、関連性のあるメジャーのすべて）をその集約規則（たとえば、メタデータにおいて定義されるＳＵＭ、ＭＩＮ、ＭＡＸなど）に従って集計できる。基準クエリの結果を比較するために取り込むことができる。また、メジャーに対して同じ動作を実行し、かつ、支給された１つ以上の属性からなるリストに基づいてこれらのメジャーをグループ化する第２のテストクエリを生成できる。このテストクエリの結果も、その後、比較するために取り込むことができる。

【0084】

Ａｕｄｉｔ４０４は、ＲＰＤモデルの整合性が合っていない（たとえば、物理データスキーマのデータと一致していない、または、そうでない場合、不整合である）場合に整合性のない結果をもたらす基準クエリとテストクエリを生成とを発行できる。たとえば、メジャーおよび属性のリスト（たとえば、生成されたデータ構造）から判断して、Ａｕｄｉｔ４０４は、（たとえば別個のＡＰＩを用いて）実行できる対の論理ＳＱＬクエリを作成できる。いくつかの実施の形態では、基準クエリは、提供されたメジャーごとに合計を作成する（たとえば、すべてのメジャーをすべてのディメンションの総計（Ｇｒａｎｄ Ｔｏｔａｌ）にロールする）ことができる。いくつかの実施の形態では、テストクエリは、同じメジャーについて報告し、当該メジャーを１つまたは複数の属性別にグループ化できる。結果として得られるレコードを集約して１つのレコードに戻し、基準クエリの結果と比較することができる。いくつかの実施の形態では、基準クエリは、ファクトテーブルの１つ、一部、またはすべてのメジャーに対してクエリ検索を行って１つのレコードを基準として取り込むことができ、テストクエリは、同じメジャーを集約して当該メジャーを１つまたは複数の属性別にグループ化することができる。

【0085】

いくつかの実施態様では、テストクエリが返したレコードに含まれるメジャーの集計が基準クエリの結果と同じでない場合、意味的モデル４１０（たとえば、ＲＰＤモデル）が基礎となるデータ（たとえば、データスキーマを実装するデータベース４１２）と不整合であることを示す。いくつかの実施の形態では、クエリのうち一方または両方がｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ（「ＳＱＬ」）エラーで失敗した場合、モデルには不具合がある。

【0086】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、１つのメジャーまたは、（たとえば、スタースキーマのスターの）複数のディメンションの総計に集約されるメジャーのアレイを返す１つの論理クエリを対象領域単位で生成できる。たとえば、結果ロウを用いてこの対象領域にあるテストケースの結果セットを互いに比較することができる。いくつかの実施の形態では、クエリは、加算的な（レベルベースではない）ファクトメジャーを含み得る。その他の実施の形態では、クエリは、任意の適切なファクトメジャーを含み得る。

【0087】

いくつかの実施の形態では、基礎となるデータスキーマは、スタースキーマであってもよい。スタースキーマは、構造化クエリの型を単純なデータ構造によって表すことができるよう、クエリの詳細を規定できる。たとえば、クエリの複雑度（ファクトおよびディメンションがどのように結合されるか、および正規化されたディメンションがどのように構築されるか）の多くを、（たとえば、スキーマ関係を表すメタデータに基づいて）論理モデルに含めることができる。テスト戦略機能の実施の形態は、どのテスト戦略を施行するかについてのオプションを提供できる。いくつかの実施の形態では、テストケースの数と、数百または数千に限定できる。理論上、一部のデータスキーマ／論理モデルと現実的な要件を超えるランタイムとの関係から判断して、何百万もテストケースを生成することが可能である。テスト戦略機能の実施の形態は、現実的なリソースの制約を用いてテストするクエリを効果的に構築する。

【0088】

図５および図６は、例示的な実施の形態に係る、対のデータベースクエリとその結果を示す図である。いくつかの実施の形態では、１つまたは複数のディメンション属性に基づいて同じメジャーをグループ化し、結果として得られる結果ロウに対するモデルの集約規則を用いてメジャーを集約するクエリを生成できる。図５および図６に示した実施の形態では、クエリ５０２は、「Ａｓｓｅｔ－Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｙ」という対象領域において「Ｃｏｕｎｔ ｏｆ Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｉｅｓ」というメジャーに対して発行される基準クエリである。クエリ５０２のＳＱＬは、メジャーがグループ化なしで集計されることを示す。結果５０４は、クエリ５０２の結果を示しており、この結果は３５０２というデータ値を有する。

【0089】

図示した実施の形態では、クエリ６０２は、「Ａｓｓｅｔ－Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｙ」という同じ対象領域において「Ｃｏｕｎｔ ｏｆ Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｉｅｓ」という同じメジャーに対して発行されるテストクエリである。クエリ６０２は、クエリ５０２とは異なる。なぜならば、クエリ６０２のＳＱＬは、メジャーが「Ｐｅｒｍｉｔ ＩＤ」（参照された論理「Ｐｅｒｍｉｓｓｉｏｎ」ディメンション）という属性別にグループ化されることを示すためである。結果６０４は、クエリ６０２の結果を示しており、「Ｃｏｕｎｔ ｏｆ Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｉｅｓ」というメジャーデータ値を、「Ｐｅｒｍｉｓｓｉｏｎ」というディメンションの「Ｐｅｒｍｉｔ ＩＤ」という属性別にグループ化する１６個のロウを有する。

【0090】

図示した実施の形態では、「Ｃｏｕｎｔ ｏｆ Ｓｅｒｖｉｃｅ Ｈｉｓｔｏｒｉｅｓ」というメジャーデータ値の結果６０４の１６個のロウの集計は、３５０２である。これは、クエリ５０２に対して結果５０４で返された、グループ化なしで集計されたメジャーデータ値に等しい。これらの値が等しいので、クエリ結果５０４および６０４は、論理モデルに不整合があることを示していない。

【0091】

図７および図８は、例示的な実施の形態に係る、別の対のデータベースクエリとその結果を示す図である。図７および図８に示した実施の形態では、クエリ７０２は、「Ａｓｓｅｔ－Ｔｉｍｅｓｈｅｅｔ Ｄｅｔａｉｌ」という対象領域において「Ｔｉｍｅｓｈｅｅｔ Ｄｅｔａｉｌ Ｃｏｕｎｔ」というメジャーおよび「Ｔｏｔａｌ Ｃｏｓｔ」というメジャーに対して発行される基準クエリである。クエリ７０２のＳＱＬは、メジャーがグループ化なしで集計されることを示す。結果７０４は、クエリ７０２の結果を示しており、「Ｔｉｍｅｓｈｅｅｔ Ｄｅｔａｉｌ Ｃｏｕｎｔ」というメジャーについては１６６２というデータ値を有し、「Ｔｏｔａｌ Ｃｏｓｔ」というメジャーについては５１１３６９．４５というデータ値を有する。

【0092】

図７および図８に示した実施の形態では、クエリ８０２のＳＱＬ、テストクエリは、加算的なメジャーを、（参照されるＴｉｍｅｓｈｅｅｔディメンションの）「Ｔｉｍｅｓｈｅｅｔ ＩＤ」というＰＫカラム別にグループ化する。結果８０４は、クエリ８０２の結果を示しており、メジャー毎に集約された（なぜならば、クエリ８０２がＳＵＭ集約規則を使用するためである）複数の結果を含む。いくつかの実施の形態では、メジャーを集約するために論理ＳＱＬを使用して、ビジネスロジックにおける論理を減らす、切り上げエラーを最小限に抑える、およびクエリのパフォーマンスを向上させる。たとえば、これは、サポートされる集約機能でメジャーを集約することによって実現できる。クエリ８０２は、集約されたメジャーを属性別のグループごと（たとえば、「Ｔｉｍｅｓｈｅｅｔ Ｄｅｔａｉｌ Ｃｏｕｎｔ」および「Ｔｏｔａｌ Ｃｏｓｔ」）に繰り返すため、（たとえば、図４のデータベース４１２によって）１番目のロウが返される。いくつかの実施の形態では、１番目のディメンション属性上でＲＡＮＫ（）を規定すること、およびクエリ８０２のＷＨＥＲＥ句にＣ１＝１という条件を付けてロウを１番目のロウに限定することによって、結果８０４を１つのロウまで減らす。

【0093】

図示した実施の形態では、結果８０４にある関連性のあるメジャーの集計は、結果７０４にある集権とは等しくない。これらの値が等しくないため、クエリ結果７０４および８０４は、不整合を示している。たとえば、図示した不整合は、未定義のキー、つまり、ファクトビューがＴｉｍｅｓｈｅｅｔディメンションにある未定義のキーを参照すること（たとえば、データ不整合）によって生じ得る。

【0094】

いくつかの実施の形態では、基準クエリおよび／または生成された論理モデルのテストクエリ、のうち１つ以上のクエリ内で集約機能が使われる。下記の集約関数は、指定された集約役割でグループ化した後にメジャーを集約するときに使われ得る。

【0095】

【表8】

【0096】

いくつかの実施態様では、下記のうち１つ以上によって不整合や不具合が引き起こされる可能性がある。

【0097】

●下記の問題の場合、報告される基準クエリのメジャー値は、集計されたテストクエリのメジャー値よりも大きい。

【0098】

○ファクトテーブルまたはディメンションテーブル間の結合は、内部結合を使用するが、外部結合でなければならない。これは、ファクトテーブルのＦＫカラムにあるメタデータが誤りであるために起こるケースである可能性が高い。

【0099】

○ファクトテーブルが、対象とされているディメンションに一致するＰＫを有さないＦＫ値でディメンションを参照する。これは、誤ったデータロード操作の結果である可能性がある。

【0100】

○ファクトテーブルまたはディメンションテーブルが、誤った結合で説明カラムルックアップを参照する。これは、ファクトテーブルのフラグカラムにあるメタデータが誤りであるために起こるケースである可能性が高い。

【0101】

○ビン分割されたカラムを用いて結果がグループ化された場合、結果は、誤りであろう。これは、バケット定義が不完全であり、あり得るビン分割されたカラムの値を範囲に含んでいないことを暗に示している可能性が高い。また、選択されたバケット型が誤りであることも暗に示している可能性がある。

【0102】

●下記の問題の場合、報告される基準クエリのメジャー値は、集計されたテストクエリのメジャー値よりも小さい。

【0103】

○誤って定義された算出されたメジャー、または誤って定義されたクロスドリルが、この状況の根本原因である可能性がある。

【0104】

いくつかの実施の形態では、Ａｕｄｉｔ４０４が発行したクエリは、ＳＱＬエラーなどのエラーに遭遇し得る。たとえば、ＳＱＬエラーは、下記の問題を示し得る。

【0105】

●データベース（たとえば、Ｏｒａｃｌｅ（登録商標）ＤＢ）にある物理的なファクトビューまたはディメンションビューが正しく定義されておらず、ＳＱＬ例外をトリガする。

【0106】

●（たとえば、Ｏｒａｃｌｅ（登録商標）Ｕｔｉｌｉｔｉｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ（「ＯＵＡＦ」）のメタデータの問題により）物理テーブルまたは物理カラムは存在しない
●ＲＰＤがＳＱＬ例外（たとえば、ファクトラッパー、Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓテーブルマッピング、ビニングテーブル）を生じさせる不備を有する仮想テーブルを作成した
●サーバ４０６との接続問題。これは、ネットワークの問題であり得、再ログインしてクエリの発行を再試行することによって回復を試みることができる。

【0107】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、リソースの効率化および不整合の発見を向上させるために１つ以上のクエリ戦略を実装できる。たとえば、発行されたクエリの数に効率よく到達するために、基準クエリおよびテストクエリは、検証／テスト中に（たとえば、ＳＵＭ、ＭＩＮ、およびＭＡＸ集約関数を用いて）集約できるファクトテーブルのすべてのメジャーを含み得る。いくつかの実施の形態では、カラムのメタデータにおいて定義される集約規則は、テストクエリによって作成されたデータレコードの各メジャーカラムをどのように集約するかについて定義することができる。

【0108】

いくつかの実施の形態では、時間ディメンションに対するクエリを限定することは、テスト戦略のランタイムを高速化することができ、返される結果セットを最小限に抑えることに役立てることができる。たとえば、最高レベル（たとえば、ＡＭ／ＰＭドリルキー）時間ディメンションをグループ化できる、または、時間ディメンション属性に対するグループ化をスキップできる。たとえば、時間ディメンションが適切にロードされたと最初のテストが認めた後は、時間ディメンションに対するグループ化をスキップできる。これに加えて、カレンダーディメンションと時間ディメンションの不整合に相関関係が存在する場合があるので（たとえば、なぜならば、どちらも同じメタデータに基づいているため）、時間ディメンションを個々にテストすることは、冗長であろう。ＰＫの正規表現が時間ディメンションのＰＫを除外した場合、ドリルキーの正規表現が時間ディメンションのドリルキーを除外する、という考えから、実施の形態は、時間ディメンションを除外できる。

【0109】

いくつかの実施の形態では、Ａｕｄｉｔ４０４は、取得したメタデータが示す結合を列挙するためのクエリを生成できる。たとえば、対象領域に関連するプレゼンテーションディメンションのＰＫ、ドリルキー、ビン分割されたカラム、および説明カラム、のうち１つ以上を特定できる。監査クエリは、ＰＫ、ドリルキー、ビン分割されたカラム、および説明カラム、のうち１つ以上に基づいてグループ化を行うことができる（たとえば、親テーブルおよび親の親テーブルが含まれることを保証するために）。また、監査クエリは、ファクトテーブル上のビン分割されたカラム、および説明カラムに基づいてグループ化を行うことができる。いくつかの実施の形態では、縮めたディメンションを参照している集約テーブル間の結合がテストされることを保証するために、カレンダーディメンションのドリルキーを対象とすることができる。いくつかの実施の形態では、論理ディメンションに組み込まれる子テーブルの属性カラムを、結合を列挙するために生成したクエリの対象とすることができる。いくつかの実施の形態では、結合を列挙するために生成されたクエリは、問い合わせに指定のタイムアウトよりも長い時間がかかった場合、テストクエリに対してエラーを返す。たとえば、タイムアウトは、固定期間とすることができ（たとえば、２分、５分など）または、通常の問い合わせ時間よりもＸ倍長いタイムアウト（たとえば、クエリ当たり１分というデフォルトの問い合わせ時間しきい値の５倍以上）として構成されてもよい。

【0110】

いくつかの実施の形態では、結合を列挙するために生成された１つ以上のクエリは、以下の利用可能な特徴のサブセットにグループ化されるカラムを限定するように構成されてもよい。

【0111】

●ＰＫ、
●ディメンション上のドリルキー（ＰＫ無し）、
●テーブル説明カラム、
●コード説明カラム、
●ディメンション上のビン分割されたカラム、
●ファクト上のコード説明、
●ファクト上のビン分割されたカラム、および
●子テーブル属性（今後のバージョンでこの特徴は利用できるようになる）。

【0112】

いくつかの実施の形態では、テストクエリの複雑度が大きくなる一連のクエリをＡｕｄｉｔ４０４によって生成できる。たとえば、グループ化基準として以下を順次追加する一連のクエリを追加できる。

【0113】

●ＰＫ、
●ディメンション上のドリルキー（ＰＫ無し）、
●テーブル説明カラム、
●コード説明カラム、または、
●ディメンション上のビン分割されたカラム,
●ファクト上のドリルキー、
●ファクト上のビン分割されたカラム、および、
●ディメンション上の子テーブル属性。

【0114】

いくつかの実施の形態では、問い合わせ期間が指定のタイムアウトよりも長かった場合、整合性のない結果であった場合、または一連のクエリのうち現在のクエリと以前のクエリとの時間差が設定可能なしきい値よりも大きい場合、これらの発行された監査クエリのうち１つ以上のクエリに対する結果に基づいて不具合を検出することができる。複雑度をテストするクエリを生成するためのいくつかの実施の形態は、ファクトテーブル上の説明カラムとビン分割されたカラム、ならびに、このような機能の数が最も多いファクトのＮ個のディメンションが利用できる（たとえば、上にリストアップした）その他のディメンション機能を対象とすることができ。デフォルトでは、Ｎは、任意のデフォルトの数字（たとえば、３）であってもよく、値は、構成オプションによって変更できる。いくつかの実施の形態では、カレンダーディメンションおよび時間ディメンションは、複雑度が低いので考慮されない。２つのディメンションが同じ数の特徴を有し、既にＮ－１個のディメンションが処理済みである場合、いくつかの実施の形態では、英数字の並び替えに基づいた１番目のディメンションが選択され得る。

【0115】

実施の形態は、複数のテストケースを同時に実行できる。いくつかの実施の形態では、Ａｕｄｉｔ４０４は、以下をサポートするソフトウェアツールを備える。

【0116】

【表9】

【0117】

実施の形態は、実装された論理モデルおよび／またはデータベースの品質を、過剰な手作業によるテストなしで改善することができる。たとえば、実施の形態によって次を特定することができる：データベーススキーマと、そのサンプルデータと、ＲＰＤモデルとの不整合；ＮＵＬＬになり得ないと宣言された＋ＲＰＤモデルにおいて必要であるが、ＮＵＬＬまたはスペース付きの文字列を含んだＦＫ（これは、通常、ファクトビューの問題である）；完全にロードまたは更新されていないテーブル；モデル化の問題またはビューの定義の問題を示す予想外のパフォーマンス低下があるクエリ。

【0118】

図９は、例示的な実施の形態に係る、論理モデルの不整合を自律的にテストするための例示的なフロー図である。一実施の形態では、図９の機能は、メモリまたはその他のコンピュータ読み取り可能もしくは有形の媒体に記憶され、プロセッサによって実行されるソフトウェアによって実現される。その他の実施の形態では、各機能は、（たとえば、特定用途向け集積回路（「ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）」）、プログラマブルゲートアレイ（「ＰＧＡ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）」）などの利用によって）ハードウェアによって実行されてもよく、ハードウェアとソフトウェアとの任意の組合せによって実行されてもよい。

【0119】

９０２では、論理モデルを記述したメタデータを取得し得る。ここで、論理モデルは、データベーススキーマを抽象化したものであり、このデータベーススキーマは、データベースにおいて実装されており、ファクトテーブルと、１つ以上のディメンションテーブルとを含む。たとえば、この論理モデルを実装するサーバから、論理モデルの一部（たとえば、対象領域）のメタデータを取得できる。いくつかの実施の形態では、メタデータは、ウェブサービスＡＰＩを利用して取得される。

【0120】

いくつかの実施の形態では、メタデータは、論理スキーマを記述している。論理スキーマに対しては、論理クエリを発行できる。たとえば、メタデータを管理するおよび／または論理モデルを実装するサーバは、論理モデルに対して発行された論理クエリを、基礎となるデータベースに対して発行されるデータベースクエリに変換できる。いくつかの実施の形態では、メタデータをＲＰＤ形式で管理できる。

【0121】

９０４では、第１論理クエリと第２論理クエリとを少なくとも含んだ複数の論理クエリを取得したメタデータに基づいて自動的に生成し得る。ここで、第１論理クエリおよび第２論理クエリは、論理モデルの論理オブジェクトを対象とする。たとえば、ＲＰＤメタデータによって定義された論理モデルに対して発行するための論理クエリは、取得したメタデータに基づいて生成できる。

【0122】

９０６では、論理モデルをホストするサーバに、少なくとも第１論理クエリおよび第２論理クエリを発行し得る。ここで、サーバにおいて、第１論理クエリは、第１のデータベースクエリに変換され、第２論理クエリは、第２のデータベースクエリに変換され、第１のデータベースクエリおよび第２のデータベースクエリは、データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする。いくつかの実施の形態では、第１論理クエリおよび第２論理クエリは、対象とされる論理オブジェクトに対応付けられたメタデータに基づいて生成され得、第１のデータベースクエリおよび第２のデータベースクエリは、第１論理クエリおよび第２論理クエリを変換するために使われる対象とされる論理オブジェクトのマッピングに基づいて、データベーススキーマのファクトテーブルおよびディメンションテーブルを対象とし得る。

【0123】

いくつかの実施の形態では、第１のデータベースクエリと第２のデータベースクエリは、論理オブジェクトに対応付けられた集約関数を用いて論理モデルをテストするように構成された対のデータベースクエリである。いくつかの実施の形態では、第１のデータベースクエリは、メタデータにおいて定義されたメジャーデータの集約関数の定義に基づいて１つ以上のディメンションに沿ったメジャーデータ値を集約し、第２のデータベースクエリは、メジャーデータ値のうち複数を、１つ以上のディメンション属性別にグループ化する。いくつかの実施の形態では、第１のデータベースクエリは、メジャーのディメンション定義、およびメタデータにおいて定義されるメジャーデータの集約関数の定義に基づいてメジャーのすべてのディメンションに沿ったメジャーデータ値を集約する。

【0124】

９０８では、第１のデータベースクエリおよび第２のデータベースクエリを実行した結果受信したクエリ結果を比較し得る。たとえば、対のデータベースクエリのクエリ結果を比較することは、（たとえば、第１のデータベースクエリによって返された）集約されたメジャーデータ値を、（たとえば、第２のデータベースクエリによって返された）グループ化されたメジャーデータ値の集計と比較することを含み得る。

【0125】

９１０では、第１のデータベースクエリと第２のデータベースクエリのクエリ結果の比較が基準を満たさない場合、１つ以上の不整合が特定され得る。ここで、１つ以上の不整合は、メタデータによって定義される論理モデルとの不整合、または、データベースにおける不整合であり得る。いくつかの実施の形態では、集約されたメジャーデータ値とグループ化されたメジャーデータ値の集計との差がしきい値よりも大きい場合、少なくとも１つの不整合が特定される。対象とされる論理オブジェクトとメタデータにおいて定義される対象とされるファクトテーブルおよびディメンションテーブルとの関係、データベースにある対象とされるファクトテーブルおよびディメンションテーブルにロードされたデータ、およびメタデータにある対象とされるファクトテーブルおよびディメンションテーブルについて定義されるカラム構成メタデータ、のうち１つ以上について少なくとも１つの不整合を特定できる。

【0126】

いくつかの実施の形態では、複数のデータベースクエリを自動的に生成することは、複数の対のデータベースクエリを自動的に生成することを含み、各対のデータベースクエリのうち第１は、１つ以上のディメンションの所与のメジャーデータ値の集約を含み、各対のデータベースクエリのうち第２は、所与のメジャーデータ値のうち複数を１つ以上のディメンション属性別にグループ化する。たとえば、論理モデルをホストするサーバに複数の対の論理クエリを発行できる。ここで、サーバにおいて、各対の論理クエリは、データベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とする対のデータベースクエリに変換され得る。いくつかの実施の形態では、対のデータベースクエリを実行した結果受信したクエリ結果を比較し得、各対のデータベースクエリのクエリ結果の比較が基準を満たさない場合、１つ以上の不整合を特定し得る。ここで、１つ以上の不整合は、メタデータによって定義された論理モデルとの不整合、またはデータベースにおける不整合を含む。

【0127】

いくつかの実施の形態では、自動的に生成された複数の対のデータベースクエリは、各対が対象としている少なくとも１つの論理オブジェクトに関連する集約関数を用いて論理モデルをテストするように構成される。たとえば、発行された複数の対の論理クエリの場合、所与の対の論理クエリは、当該所与の対が対象としている少なくとも１つの論理オブジェクトに対応付けられたメタデータに基づいて生成され得、当該所与の対の論理クエリに基づいて変換される所与の対のデータベースクエリは、所与の対の論理クエリを変換するために使われる対象とされる当該所与の論理オブジェクトのためのマッピングに基づいてデータベーススキーマのファクトテーブルおよびディメンションテーブルを少なくとも対象とし得る。いくつかの実施の形態では、自動的に生成された複数の対のデータベースクエリは、論理モデルの複数の論理オブジェクトをテストし、変換された複数の対のデータベースクエリは、データベースの複数のファクトテーブルおよびディメンションテーブルをテストする。

【0128】

実施の形態は、論理モデルの不整合を自律的にテストすることを実現する。たとえば、データスキーマは、時として、結合およびその他の高度なクエリ構造を用いて非常に多くのテーブル／フィールドの関連性のあるデータを対象とする複雑なクエリを必要とし得る。このクエリの負担を軽減するために、いくつかのデータベース実装およびレポート作成ツールは、論理モデルを含む、または、基礎となる複雑なデータスキーマをより簡素化された論理モデルにマッピングする層を含む。たとえば、論理モデルは、その後、さらに過度に単純化した論理クエリを用いてクエリ検索され得る。これらの論理クエリは、基礎となるデータスキーマを対象とするクエリに変換される（たとえば、基礎となるデータスキーマのデータにアクセス／取得可能な複雑なクエリに変換される）。

【0129】

論理モデルのいくつかの実施の形態は、様々な集約機能、ドリルダウン機能、結合動作などを含む、複雑さの複数の層を含み得る。たとえば、複雑な論理モデルをデプロイするために使用できるメタデータを定義するなどによって当該モデルを素早く開発するために１つ以上のツールを用いることができる。いくつかの実施の形態では、ユーザーインタフェースを通して概念データモデルを定義するためにツールを用いることができ、このようなツールの出力は、論理データモデルを構成する構成要素の概念的関係を記憶したメタデータであり得る。

【0130】

いくつかの実施の形態では、これらのツールは、複雑なデータベースをデプロイすることを効率化できるが、デプロイには、下位レベルの不整合および／または不具合が含まれている場合がある。たとえば、論理モデルにおいて定義される集約機能が、基礎となるデータスキーマと一致しない場合があり、１つ以上のテーブルが正しくロードされなかったり、データフィールド（たとえば、Ｎｕｌｌであってはならない）の構成が正しく設定されなかったりなどする。これらの不整合および／または不具合は、従来、デバッグするために綿密な手作業を必要とする。

【0131】

実施の形態は、基礎となるデータスキーマとともに実装した場合の不整合および／または不具合を自律的にテストする論理モデルのメタデータに基づいて、クエリを生成する。たとえば、論理モデルのメタデータを取得および解析して、当該モデルの構成要素間の概念的関係を判断できる。いくつかの実施の形態では、解析したメタデータから判断して、論理モデルの想定される挙動およびデータスキーマに基づいてクエリを生成できる。たとえば、（たとえば、データスキーマの１つ以上のディメンション間の）想定される集約機能をテストする対のクエリを生成できる。

【0132】

実施の形態は、クエリの結果を解析する。たとえば、論理データモデルがデータの関係をデータスキーマに正確に反映している場合は同様の結果セット（たとえば、同じデータ値）を返すように２つ以上のクエリを設計できる。これらの２つ以上のクエリの返ってきた結果セットが類似していない場合は、論理モデルとの不整合があることを示し得る。その他の例では、データの間違ったロード、データベースのテーブルまたはカラムがないこと、間違った埋込みＳＱＬ表現、および／またはデータフィールドの間違った構成によるクエリエラーが返されてもよい。いくつかの実施の形態では、想定される結果から逸脱したこれらの結果を用いて、これらの不整合のうち１つ以上を特定できる。

【0133】

本明細書を通して説明した本開示の特徴、構造、または特性を任意の適切な方法で組み合わせて１つ以上の実施の形態にしてもよい。たとえば、本明細書を通した「一実施の形態」、「いくつかの実施の形態」、「特定の実施の形態」、「複数の特定の実施の形態」、またはその他の同様の文言の使用は、実施の形態に関して説明した特定の特徴、構造、または特性が本開示の少なくとも１つの実施の形態に含まれてもよいことを指している。よって、本明細書を通した「一実施の形態」、「いくつかの実施の形態」、「特定の実施の形態」、「複数の特定の実施の形態」いうフレーズ、またはその他の同様の文言の出現は、必ずしもすべてが同じグループの実施の形態を指しているわけではなく、記載の特徴、構造、または特性を任意の適切な方法で組み合わせて１つ以上の実施の形態としてもよい。

【0134】

上述した実施の形態を異なる順序のステップで実施してもよいこと、および／または開示の構成とは異なる構成の要素を用いて実施してもよいことは、当業者であれば容易に理解できるであろう。そのため、本開示は、概要を説明した実施の形態を考慮しているが、本開示の趣旨および範囲から逸脱しないで特定の変更例、変形例、および別の構成も明らかになることは、当業者に明らかになるであろう。そのため、本開示の範囲を特定するために添付の特許請求の範囲を参照されたい。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】