(57)【要約】  データストレージシステム（１０２）が、複数のレコードを含む少なくとも１つのデータセットを記憶する。データストレージシステムに接続されたデータ処理システム（１０４）が、レコードにおけるデータパターンを表すコード（１１４）を生成するために、複数のレコードを処理し、処理することが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
2014511587.tif 000002
【特許請求の範囲】
【請求項１】
複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、
前記レコードにおけるデータパターンを表すコードを生成するために、前記データストレージシステムに接続されたデータ処理システムにおいて、前記複数のレコードを処理するステップと
を含む方法であって、
前記処理するステップが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けるステップを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
方法。
【請求項２】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、ポピュレートされている、又はポピュレートされていないときのフィールドの状態をそれぞれ表す、請求項１に記載の方法。
【請求項３】
ポピュレートされていない状態が、ヌル状態、非存在状態、又は空状態のうちの１つを含む、請求項２に記載の方法。
【請求項４】
ヌル状態が、所定の値を有するフィールドの状態を含む、請求項３に記載の方法。
【請求項５】
所定の値が、１又は２以上の空白文字を含む、請求項４に記載の方法。
【請求項６】
非存在状態が、レコードにおいて欠けているフィールドを含む、請求項３に記載の方法。
【請求項７】
空状態が、対応するデータ値を有さないフィールドを含む、請求項３に記載の方法。
【請求項８】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、フィールドに関連付けられたバリデーションルールに従って、有効である又は有効でない前記フィールドにおいて発生するデータ値を表す、請求項１に記載の方法。
【請求項９】
バリデーションルールが、データ値のデータタイプに少なくとも部分的に基づいて、有効値を定義する、請求項８に記載の方法。
【請求項１０】
バリデーションルールが、列挙された値のリストを参照することによって、少なくとも部分的に有効値を定義する、請求項８に記載の方法。
【請求項１１】
第１のコードの少なくとも１つの要素について、セット内の１又は２以上の要素値が、第１のフィールドにおいて発生するデータ値がターゲットデータ値と一致する度合いを表す、請求項１に記載の方法。
【請求項１２】
ターゲットデータ値が、第２のフィールドにおいて発生するデータ値である、請求項１１に記載の方法。
【請求項１３】
セット内の少なくとも３つの要素値が、第１のフィールドにおいて発生するデータ値が、不一致、完全一致、又はファジーマッチとしてそれぞれターゲットデータ値に一致する度合いを表す、請求項１１に記載の方法。
【請求項１４】
第１のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、第１のレコードのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、及び前記第１のレコードとは異なる少なくとも第２のレコードを含む１又は２以上のレコードのセットのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、計算されるデータ値を符号化する、請求項１に記載の方法。
【請求項１５】
第１のレコードが、第１のデータセット内にあり、第２のレコードが、前記第１のデータセットとは異なる第２のデータセット内にある、請求項１４に記載の方法。
【請求項１６】
少なくとも第２のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、フィールドにおいて発生する所定のデータ値を表す、請求項１に記載の方法。
【請求項１７】
第２のコードの要素についての要素値のセット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド又はフィールドの組み合わせにおいて発生するデータ値の総数に等しい、請求項１６に記載の方法。
【請求項１８】
コンピュータプログラムを記憶するコンピュータ可読ストレージ媒体であって、前記コンピュータプログラムが、コンピュータシステムに、
複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶させ、
前記レコードにおけるデータパターンを表すコードを生成するために、前記データストレージシステムに接続された、前記コンピュータシステムの少なくとも１つのプロセッサにおいて、前記複数のレコードを処理させるための命令を含み、
前記処理させることが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
コンピュータ可読ストレージ媒体。
【請求項１９】
複数のレコードを含む少なくとも１つのデータセットを記憶するように構成されたデータストレージシステムと、
前記レコードにおけるデータパターンを表すコードを生成するために、前記複数のレコードを処理するように構成された、前記データストレージシステムに接続されたデータ処理システムと
を含むシステムであって、
前記処理することが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
システム。
【請求項２０】
複数のレコードを含む少なくとも１つのデータセットを記憶するための手段と、
前記レコードにおけるデータパターンを表すコードを生成するために、前記複数のレコードを処理するための手段と
を含むシステムであって、
前記処理することが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１１年１月２８日に出願された米国特許出願第６１／４３７，３６１号明細書の優先権を主張するものである。
【０００２】
本明細書は、データパターン情報の生成に関する。
【背景技術】
【０００３】
データベースシステムでは、データを、さまざまなフォーマットのうちのいずれかで、個々にアクセス可能なユニット又は「レコード」に記憶することができる。各レコードは、クレジットカード取引などの論理的エンティティに対応し、通常、レコードを一意に識別するのに使用される、関連した主キーを有することができる。レコードは、レコードフォーマットのそれぞれのフィールドに関連付けられた多様な値を含むことができる。レコードは、１又は２以上のファイル内（例えば、フラットファイル又はＸＭＬファイルなどの構造化データファイル）に記憶することができる。圧縮データベースシステムでは、個々のレコード又はレコード内の値を、記憶時に圧縮し、アクセス時に展開して、システムのストレージ要件を削減することができる。
【発明の概要】
【課題を解決するための手段】
【０００４】
一態様では、概して、方法が、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、レコードにおけるデータパターンを表すコードを生成するために、データストレージシステムに接続されたデータ処理システムにおいて、複数のレコードを処理するステップとを含み、処理するステップが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けるステップを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【０００５】
態様は、以下の特徴のうちの１又は２以上を含むことができる。
【０００６】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、ポピュレートされている、又はポピュレートされていないときのフィールドの状態をそれぞれ表す。
【０００７】
ポピュレートされていない状態は、ヌル状態、非存在状態、又は空状態のうちの１つを含む。
【０００８】
ヌル状態は、所定の値を有するフィールドの状態を含む。
【０００９】
所定の値は、１又は２以上の空白文字を含む。
【００１０】
非存在状態は、レコードにおいて欠けているフィールドを含む。
【００１１】
空状態は、対応するデータ値を有さないフィールドを含む。
【００１２】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、フィールドに関連付けられたバリデーションルールに従って、有効である又は有効でないフィールドにおいて発生するデータ値を表す。
【００１３】
バリデーションルールは、データ値のデータタイプに少なくとも部分的に基づいて、有効値を定義する。
【００１４】
バリデーションルールは、列挙された値のリストを参照することによって、少なくとも部分的に有効値を定義する。
【００１５】
第１のコードの少なくとも１つの要素について、セット内の１又は２以上の要素値が、第１のフィールドにおいて発生するデータ値がターゲットデータ値と一致する度合いを表す。
【００１６】
ターゲットデータ値は、第２のフィールドにおいて発生するデータ値である。
【００１７】
セット内の少なくとも３つの要素値が、第１のフィールドにおいて発生するデータ値が、不一致、完全一致、又はファジーマッチとしてそれぞれターゲットデータ値に一致する度合いを表す。
【００１８】
第１のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、第１のレコードのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、及び第１のレコードとは異なる少なくとも第２のレコードを含む１又は２以上のレコードのセットのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、計算されるデータ値を符号化する。
【００１９】
第１のレコードが、第１のデータセット内にあり、第２のレコードが、第１のデータセットとは異なる第２のデータセット内にある。
【００２０】
少なくとも第２のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、フィールドにおいて発生する所定のデータ値を表す。
【００２１】
第２のコードの要素についての要素値のセット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド又はフィールドの組み合わせにおいて発生するデータ値の総数に等しい。
【００２２】
別の態様では、概して、コンピュータ可読ストレージ媒体が、コンピュータプログラムを記憶し、コンピュータプログラムは、コンピュータシステムに、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶させ、レコードにおけるデータパターンを表すコードを生成するために、データストレージシステムに接続された、コンピュータシステムの少なくとも１つのプロセッサにおいて、複数のレコードを処理させるための命令を含み、処理させることが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【００２３】
別の態様では、概して、システムが、複数のレコードを含む少なくとも１つのデータセットを記憶するように構成されたデータストレージシステムと、レコードにおけるデータパターンを表すコードを生成するために、複数のレコードを処理するように構成された、データストレージシステムに接続されたデータ処理システムとを含み、処理することが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【００２４】
別の態様では、概して、システムが、複数のレコードを含む少なくとも１つのデータセットを記憶するための手段と、レコードにおけるデータパターンを表すコードを生成するために、複数のレコードを処理するための手段とを含み、処理することが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【００２５】
別の態様では、概して、方法が、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、レコードにおけるデータパターンの表現を生成するために、データストレージシステムに接続されたデータ処理システムにおいて、複数のレコードを処理するステップとを含み、処理するステップが、複数のレコードのフィールド若しくはフィールドの組み合わせの１又は２以上の状態又はプロパティを分析するステップと、レコードにおけるデータパターンの表現として、１又は２以上のプロパティを示すためのコードを生成するステップとを含む。
【００２６】
別の態様では、概して、方法が、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、レコードにおけるデータパターンの表現を生成するために、データストレージシステムに接続されたデータ処理システムにおいて、複数のレコードを処理するステップとを含み、処理するステップが、複数のレコードにおけるレコードごとに、レコードのフィールド若しくはフィールドの組み合わせに対応する１又は２以上のデータ要素を符号化するコードを指定するステップを含み、１又は２以上のデータ要素が、対応するフィールドがポピュレートされているかどうかを表す。
【００２７】
態様は、以下の効果のうちの１又は２以上を含むことができる。
【００２８】
データセットがデータ品質について分析されるとき、フィールドが非存在である（レコードの中に存在しない）レコードはいくつあるか、フィールドが空である（文字がない）レコードはいくつあるか、フィールドがブランクである（１又は２以上の空白文字）レコードはいくつあるか、フィールドがヌルである（ＮＵＬＬに関連付けられた特定の値を収容する）レコードはいくつあるか、フィールドがポピュレートされている（存在し、空又はブランクではない）レコードはいくつあるか、或いは、バリデーションルールのセットに従って（例えば、データタイプに従って、又は列挙された値のリストを参照することによって）フィールドが有効である、又は無効であるレコードはいくつあるかを示す、フィールドごとのカウントがしばしば計算される。フィールド若しくはフィールドの組み合わせのポピュレーションの状態は、これらの条件若しくは条件の組み合わせのうちの１又は２以上から形成されてもよく、より一般的には、ポピュレーションの状態は、フィールド若しくはフィールドの組み合わせにおける値の、コードに対する何らかの関連である。レコードにおいて、選択されるフィールド又はフィールドの組み合わせのセットについてのポピュレーションの状態の集まりを、選択されるフィールド又はフィールドの組み合わせのポピュレーションの状態を集合的に集約する、データパターンコードに符号化することができる。データパターンコードを使用して、ポピュレーションの状態に加えて、又はポピュレーションの状態の代わりに、他のプロパティを示すこともまたできる。各データパターンコードを有するレコードの数を、計算することができる。得られたデータパターンコードのセットは、データセットにおけるポピュレーションの多様性を反映し、各パターンに関連付けられたカウントは、データセットにおけるそのパターンの広がりを示す。
【００２９】
データパターンコードを使用して、データセットのデータ品質を測定することができる。いくつかのデータパターンコードは、有効とみなされ（ポピュレーションのパターンが受け入れられる）、一方、他はみなされないことがある。例えば、特定のフィールドは必須であってもよく、言い換えれば、特定のフィールドは、あらゆるレコードにおいて存在してポピュレートされることを必要とされる。すべての必須フィールドがポピュレートされている場合に値１を有し、いずれかの必須フィールドがポピュレートされていない場合に０を有する、データパターンコードが計算されてもよい。データパターンコード０を有するレコードの小部分は、いくつかの必須フィールドがポピュレートされていない理由でデータ品質問題を有する、データセットにおけるレコードの小部分を示す。より改良されたデータパターンコードは、どの必須フィールドがポピュレートされていないかの識別及び定量化を可能にすることになる。
【００３０】
いくつかのデータセットにおいては、いくつかのフィールドが条件付きで必須であり、すなわち、あるフィールドが存在する、又は特定の値を有する場合には、別のフィールドが存在しなければならない。条件が既知であるときにはこれを検証し、又は条件が既知でないときには、データパターンコードの分布からそれを推測するように、データパターンコードを構築することができる。この後者は、データパターンコード内でフィールド間の相関関係を求めることによって、隠れたビジネスルールを検出することができるので、利用価値がある。例えば、取引データセットが、税が徴収された場所にあるストアについてのみポピュレートされる税フィールドを収容することがある。データにおけるフィールドの共同ポピュレーションの優越から識別される、税フィールドのポピュレーションと特定のストア＿ｉｄとの相関関係が、これを明らかにすることになる。相関関係が乱されているとき、それはデータ品質問題の証拠である。
【００３１】
データパターンコードを使用して、フィールドのポピュレーションを認めるだけでなく、異なる種類の無効性（すなわち、フィールドの中に保持されている、フィールドにとって不適切なデータ、例えば数値フィールドにおける非数値文字）を検出し、識別することもまたできる。これは、データ品質を定量化するために有用であり、アプリケーションをテストするためにもまた有用である。それぞれ実在のデータパターンコードを有するソースデータから（例えば、アプリケーションが最終的に処理することになる実際の生産データから）レコードのサンプルを抽出することによって、テストデータセットを構築することができる。有効性に基づくデータパターンコードでは、コードの多くが、無効なデータを収容するレコードを識別することができる。関連するレコードを使用して、（実際に発生する）粗悪なデータに対するアプリケーションの堅牢性をテストすることができる。これは、そうでなければ、アプリケーションが生産において展開されるまで行うことができないことがあるテストを可能にする。ソフトウェア開発ライフサイクルのより初期にそれらのレコードが検出されれば、問題の修正はより安価であることが多い。
【００３２】
データパターンコードを、（例えば、ポピュレーション又は有効性以外の）他の評価に反映することができる。例えば、フィールド又はフィールドの組み合わせの状態が、何らかの点で注目に値することがあり、この場合、その状態は、同じデータセットの他のレコードにおいて、又は他のデータセットのレコードにおいて、フィールドの値を有する所与のレコードの、フィールド若しくはフィールドの組み合わせにおける値を含む計算によって判定される。例えば、取引量フィールドの値がデータセットにおけるレコードのグループの平均値から３以上の標準偏差の場合、値は、そのグループのコンテキストにおいて注目に値するとみなされることがある。同様に、それは、データセットの外部のレコードに記憶されている、又はそこから計算される履歴平均値に対して、注目に値することがある。
【００３３】
別の例では、あいまい一致のアプリケーションにおいて、グループ又はクラスタにおける所与のレコードと他のレコードとの一致の品質を測定するスコアを計算することができる。データパターンコードの１つの要素が、帯状の範囲で一致品質のスコアに関連付けられて、レコードが、完全一致である、あいまい一致である（一致閾値を上回るスコアであるが正確ではない）、などを示すことができる。名前又はアドレスのようなレコードの要素についての一致の品質を測定する同様の要素と一緒に、この要素から構築されるデータパターンコードを使用して、レコードを、適切な取扱い又は分析のためのセット（例えば、「あいまいなレコード一致、正確な名前、あいまいなアドレス、ポストコードなし」）に分類することができる。
【００３４】
データパターンコードを使用して、構築中のアプリケーションの出力を分析することもまたできる。予想される有効性ルール及びフィールド間の相関関係を、データパターンコードを用いてプログラムでチェックすることができる。アプリケーションの出力に関連付けられたデータパターンコードごとのレコードのサンプル抽出を検査することにより、予想しないバグを明らかにすることができる。データパターンコードが、アプリケーションの異なるステージからのポピュレーション情報及び有効性情報を記録する場合、良好な結果と粗悪な結果からのデータパターンコードを比較することによって、粗悪な結果を分析し、その起源に遡ることができる。
【００３５】
サンプル抽出はまた、連続動作のための新しい入力を構築するための基礎として使用することができる、テストケースを提供する。この使用は、テストの一部として反復実行が必要とされるアプリケーションにおいて、潜在的に重要である。反復実行が使用される１つの例は、所望の結果を達成するためにパラメータを調整するときである。例えば、名前及びアドレスが類似性について比較される、あいまい一致のアプリケーションでは、それを下回ると一対の名前及びアドレス間の一致の度合いを特徴付けるスコアが一致と考慮されない閾値が、しばしば存在する。一致すべきケースが一致するように、一致決定を制御するさまざまなパラメータが調整されるので、アプリケーションを何度も動作させる必要があることがある。ポピュレーションの異なるパターン（例えば、ミドルネームなし、最初のイニシャルのみ、家屋番号なし、など）は、一致決定プロセスに関与するビジネスルールに影響する。異なるスコアリングフィールド（「正確な名前」「あいまいなアドレス」など）についての一致の品質を反映するコードと、ポピュレーションのパターンとを組み合わせることによって構築されるデータパターンコードを使用して、異なるケースを反映するテストケースを切り離すことができ、これは、調整するプロセスをはかどらせるのに極めて貴重であることがある。
【００３６】
いくつかのアプリケーションインターフェースは、ダウンストリーム処理のために、異質なソースからのデータを、共通のレコードフォーマットに標準化する。通常、すべてのフィールドが、あらゆるソースによってポピュレートされるわけではない。データパターンコードは、ソースデータにおいてフィールドのどの組み合わせが発生するかを識別することができる。これを使用して、いくつかのケースでは、データの起源が既知でないときに、起源を推測することができる。データパターンコードにおけるフィールド間の相関関係を識別することによって、例えば、あるフィールドが別のフィールドを条件にして必須であることなどの、隠れたビジネスルールを推測することができる。例えば、いくつかの欧州の国々からのデータが単一のデータセットの中に組み合わされている場合、ある種のフィールドは、データがドイツソースから来た場合しかポピュレートされないことがあり得る。これは、データパターンコードに照らして、基礎になるデータの分析から推測され、後にビジネスによって確認することができる。他の国々からのレコードにおけるそれらのフィールドのデータの非存在は、それによって説明され、非存在は、データ品質問題ではない。
【００３７】
いくつかの状況では、共通のレコードフォーマットを解除して、それを、ポピュレートされたフィールドのみ（又はそのほとんど）からなる条件付き形式に戻すことが役に立つことがある。均一のフォーマットで届いたデータにもかかわらず、ソース固有の処理が要求される場合には、これが必要となることがある。データパターンコードは、ソースデータに存在するレコードのクラス［すなわち、（ほとんど）常に一緒にポピュレートされるフィールドのセット］を識別し、条件付きレコードフォーマットにおける条件としての役割を果たし、次いでソースデータセットを縮小されたレコードフォーマットに分解するのを促進するよう支援することができる。
【００３８】
均一化レコードフォーマットがアプリケーションのためのデータソースを記述する場合、アプリケーションが取り扱うことができなければならない入力ケースが多岐にわたるテストケースの表現セットを取得する、又は構築することは、困難であることがある。アプリケーションが最終的に扱うことになる実際の（生産）ソースデータへのアクセスが与えられれば、データパターンコードをソースレコードごとに構築することができ、各パターンを表すレコードの（小さな）セットを抽出することができる。これらのレコードを、必要であれば、テスト環境で使用するために分かりにくくすることができるが、レコードは、その時間点においては、生産データのテストケースの包括的なセットを構成している（ケースは、経時的に常に変化し得る）。次いでこのレコードのセットを、アプリケーションのコード網羅率分析、及びエッジケースストレステスト（すなわち、ほとんど見られないデータの組み合わせのもとでの挙動のためのテスト）のために使用することができる。
【００３９】
多くのレガシーメインフレームデータセットは、ＣＯＢＯＬによって記述され、ＣＯＢＯＬ  ＲＥＤＥＦＩＮＥを収容する。ＲＥＤＥＦＩＮＥステートメントは、バイト位置の同じセットを再使用することによって空白を省いて、同じデータセット内の（通常、サブレコードのための）異なるレコードフォーマットでデータを保持するために、使用される。例えば、あるレコード内で、バイトは、人名及び顧客識別子のような顧客情報を収容してもよく、一方、別のレコード内で、バイトは、購入した品物についての数量及び価格情報を収容するインボイスデータを収容してもよい。時に、レコードにおける別のフィールドが、ＲＥＤＥＦＩＮＥのどのインスタンスが所与のレコードを対象にしているかを識別するが、これがどのフィールドであるかの認識は、失われている、又は入手可能でない（例えば、アプリケーションコードに収容されている）ことがある。時に、レコードフォーマットの外部の何か（例えば、ファイル名、処理するアプリケーションへのコマンドライン引数、又はアプリケーションコードがアクセスできる外部の何か他のもの）が、全体のデータセットのために使用するのはどのＲＥＤＥＦＩＮＥかを識別する。時に、バイトの内容は、どのＲＥＤＥＦＩＮＥが対象にされているかを判定するために点検されなければならない。これらのケースは、例示的であって、網羅的ではない。その予想される内容（例えば、十進数はアルファベット文字を収容できない、文字列データは任意のバイナリ文字を収容しないことになる、国コードは特定の参照テーブルの中になければならない、など）に基づいて、フィールドの有効性をとりわけ考慮する、共に得られるＲＥＤＥＦＩＮＥフィールドのすべての内容から構築されるデータパターンコードを使用して、所与のレコードのためにどのＲＥＤＥＦＩＮＥが適正であるか（これらは２以上存在することもある）を推測することができる。このデータパターンコードをレコードに追加して、非ＣＯＢＯＬアプリケーションによる処理により適した条件付きレコードフォーマットに変換するために使用することができる。同様の検討は、他の言語における共用体データ構造及び他の「可変レコード」に当てはまる。
【００４０】
ＸＭＬドキュメントは、任意の特定のドキュメント（又は原本）に存在するフィールドのスーパーセットをしばしば収容する、関連するＸＭＬスキーマによって記述される。これは、さまざまなレガシーフォーマットを包含するように設計された、金融取引のためのＩＳＯ２００２２のような業界標準において、とりわけ当てはまる。これらの業界標準スキーマは、しばしば大型で複雑であり、考え得る要素（フィールド）のわずかな小部分のみが、所与のドキュメントにおいてポピュレートされる。そのようなスキーマにおけるドキュメントの集まりで作業するとき、どの要素が使用中で、何の要素の分布がドキュメントの集まりにわたっているか知ることは有益である。これは、ドキュメントについてのデータパターンコード（又はおそらくはデータパターンコードのセット）を構築することによって、答えることができる。ビジネスルールは、ソースデータには現れないそのような要素について標準で書かれる必要がないので、これは新しいアプリケーションを設計するときに特に有益であり、それにより、多くの時間とリソースを節約する。
【００４１】
いくつかの組織は、組織のレガシーデータを、ＩＳＯ２００２２のような業界標準フォーマットに記憶するように提案しており、なぜならＩＳＯ２００２２は、おそらくカスタマイズされた、又は拡張された異なるレガシーフォーマットからのデータを、共通のデータ構造に置くからである。共通フォーマットでのデータで作業するときの課題は、すべてのソースが、スキーマ内でフィールドの同じ集まりをポピュレートしていることにはならないことである。原本ドキュメントの集まりからデータパターンコードを構築することは、どのフィールドが使用中であり、どのフィールドがダウンストリームの取扱いのためのドキュメントの分類に使用できるかを示すことになる。いくつかのケースにおいて、アップストリームレガシーソースの性質を、稀なポピュレートされるフィールドから推測することができ、これは、それらのフィールドを取り扱うためのビジネスルールの開発を支援することができる。
【００４２】
ＸＭＬドキュメントの別の特徴は、データを、他の要素を収容してもよい要素の中に編成することである。これらの要素のいくつかは必須になり、すなわち、それらの要素は、いかなるドキュメントにも存在しなければならず、一方、他の要素はオプションになる。さらに他の要素は、条件付きで必須であり、ある要素が存在する場合、別の要素もまた存在しなければならない。スキーマは、しばしばこの情報を収容しているが、他のアプリケーションによる使用に常に適しているわけではない形式においてである。要素のどの組み合わせが存在しなければならず、どの組み合わせが存在しなくてもよいかをおそらく識別することによって、有効なデータパターンコードを識別するテーブルを、スキーマから構築することができる。原本ドキュメントから構築されたデータパターンコードを、有効なデータパターンコードのこのテーブルと比較することによって、ＸＭＬドキュメントをＸＭＬスキーマとの適合のために有効化することができる。
【００４３】
いくつかのＸＭＬ要素は、異なる目的を有する情報を分離することが意図されている。例えば、名前及びアドレスによって債権者を識別するデータについてのタグ、並びに金融取引の詳細についての別のタグが存在してもよい。これらの異なる要素は、別個に処理するように決められていてもよい。あらゆるドキュメントが、存在するあらゆる要素を有するわけではないので、データパターンコードを使用して、所与のドキュメントの中にどの要素が存在するかを識別することができ、これを、ひいては、ドキュメントを分解し、ドキュメントの異なる要素を適切な処理へと送るために使用することができる。
【００４４】
本発明の他の特徴及び効果は、以下の説明から、及び特許請求の範囲から、明らかになるであろう。
【図面の簡単な説明】
【００４５】
【図１】データパターン分析を実施するためのシステムのブロック図である。
【図２】例示的なデータパターン分析手順の流れ図である。
【図３】フィールド及びレコードの対応するコードを示す概略図である。
【図４−５】データパターンコードを表示するための例示的なユーザインターフェースの概略図である。
【発明を実施するための形態】
【００４６】
図１は、データパターン分析技法を使用することができる、例示的なデータ処理システム１００を示す。システム１００は、データソース１０２を含み、データソース１０２は、ストレージデバイス又はオンラインデータストリームへの接続などの、データの１又は２以上のソースを含むことができ、そのそれぞれが、さまざまなストレージフォーマットのいずれか（例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイル、又はメインフレームによって使用されるネイティブフォーマット）で、データを記憶することができる。実行環境１０４は、前処理モジュール１０６と、実行モジュール１１２とを含む。いくつかの実装形態において、前処理モジュール１０６は、データソース１０２から１又は２以上のデータセットを受信し、データセットにおけるデータにデータ完全性チェックを実施する。例えば、前処理モジュール１０６は、範囲外の値、不可能な値などを収容するレコードについて、データセットを選別することができる。実行モジュール１１２は、診断及び他の高レベルなデータ処理のためのパターン情報を使用することを含んで、パターンについてデータセットを分析する。実行環境１０４は、ＵＮＩＸオペレーティングシステムなどの好適なオペレーティングシステムの制御下において、１又は２以上の汎用コンピュータ上でホストされてもよい。例えば、実行環境１０４は、複数ノードの並列コンピューティング環境を含むことができ、この環境は、ローカルな（例えば、ＳＭＰコンピュータなどのマルチプロセッサシステム）若しくはローカルに分散された（例えば、クラスタ若しくはＭＰＰとして連結された複数のプロセッサ）いずれか、又は、リモートの若しくはリモートに分散された（例えば、ローカルエリアネットワーク（ＬＡＮ）及び／又はワイドエリアネットワーク（ＷＡＮ）を介して連結された複数のプロセッサ）いずれか、又は、それらの任意の組み合わせの、複数の中央処理ユニット（ＣＰＵ）使用するコンピュータシステムの構成を含む。
【００４７】
データソース１０２を提供するストレージデバイスは、例えば、実行環境１０４を動作させるコンピュータに接続されたストレージ媒体（例えば、ハードドライブ１０８）に記憶されて、実行環境１０４にローカルであってもよく、又は、例えば、リモート接続上で実行環境１０４を動作させるコンピュータと通信しているリモートシステム（例えば、メインフレーム１１０）上でホストされて、実行環境１０４にリモートであってもよい。
【００４８】
実行モジュール１１２は、データソース１０２からのデータセットを処理し、任意で前処理モジュール１０６からの結果を使用して、例えば、１又は２以上のコード１１４に符号化され、実行環境１０４にアクセス可能なデータストレージシステム１１６に記憶される、データセットにおけるパターンの表現を生成する。コード１１４は、データソース１０２内のデータセットに、又は別の場所に、データと共に記憶されてもよい。データストレージシステム１１６はまた、開発環境１１８にアクセス可能であり、開発環境１１８では、開発者１２０が、データパターン分析のパフォーマンスを見て、管理することができる。
【００４９】
開発環境１１８は、いくつかの実装形態において、データフローグラフとして、アプリケーションを開発するためのシステムであり、データフローグラフは、頂点（コンポーネント又はデータセットを表す）間の有向リンク（作業要素のフローを表す）によって接続された頂点を含む。例えば、そのような環境は、「Managing Parameters for Graph-Based Applications」と題された米国特許出願公開第２００７／００１１６６８号明細書により詳細に説明されており、これを参照により本明細書に組み込む。そのようなグラフベースの計算を実行するためのシステムは、米国特許第５，５６６，０７２号明細書「EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS」に説明されており、これを参照により本明細書に組み込む。このシステムに従って作成されたデータフローグラフは、情報を、グラフコンポーネントが表す個々のプロセスに入れて、そこから取り出すための方法、プロセス間で情報を移動させるための方法、及びプロセスのための動作順序を定義するための方法を提供する。このシステムは、プロセス間の通信方法（例えば、グラフのリンクに従った通信路がＴＣＰ／ＩＰ若しくはＵＮＩＸドメインソケットを使用することができる、又はプロセス間でデータを渡すための共有メモリを使用する）を選ぶアルゴリズムを含む。
【００５０】
前処理モジュール１０６は、異なる形式のデータベースシステムを含むさまざまなタイプのシステムから、「データセット」の形式で、データを受信することができる。データセットは、場合によりＮＵＬＬ値を含む、それぞれのフィールド（「属性」又は「列」とも呼ばれる）についての値を有するレコードとして編成されていてもよい。データソースから最初にデータを読み取るとき、前処理モジュール１０６は、通常、そのデータソース内のレコードについての何らかの初期フォーマット情報から開始する。いくつかの状況において、データソースのレコード構造は、最初から既知でなくてもよく、代わりに、データソースの分析後に決定されてもよい。レコードについての初期情報は、別個の値を表すビットの数、レコード内のフィールドの順序、及びビットによって表される値のタイプ（例えば、文字列、符号付き整数／符号なし整数）を含むことができる。続いて、前処理モジュール１０６は、例えば、フィールドに対応する値が予想の範囲内であり、予想のデータタイプであることを保証するために、レコードにデータ完全性分析を実施することができる。
【００５１】
前処理ステップが完了すると、実行モジュール１１２は、データパターン分析を実施する。より一般的には、データレコードは、レコードについての１又は２以上のフィールド及び／若しくはフィールドの組み合わせ（例えば、レコードに潜在的に存在するものとして、レコードフォーマット又はスキーマによって定義されるフィールド）に関係した、多様なプロパティを有することができる。プロパティは、レコードについてのそれぞれのフィールド又はフィールドの組み合わせに対応することができ、データ値タイプ、データ値の長さ、及び／又はデータ値を含むことができる。いくつかの実装形態において、データレコードにおいてフィールドに対応する値を、集合的にレコードのポピュレーションと呼ぶことができる。概して、レコードについてのフィールドは、必ずしもすべてポピュレートされるわけではない。例えば、データレコードは、個々のレコードに存在するフィールドのすべてに対応する値を有していても、有さなくてもよい。加えて、そのレコードに関連付けられていることが既知である、又は宣言されているいくつかのフィールドは、存在しなくてもよく、非存在のフィールドと呼ばれることがある。したがって、あるフィールドが「ポピュレートされていない」と示されるさまざまな理由が存在し得る。いくつかのフィールドは、特定のレコードに非存在であることがあり、いくつかのフィールドは、存在し得るものの、空であることもあり、又は「ＮＵＬＬ」値（１又は２以上の空白文字の文字列などの、フィールドがポピュレートされていないことを示すためにあらかじめ決められた値）を収容していることもある。存在し、非ＮＵＬＬ値を含むフィールドは、「ポピュレートされている」。いくつかの実装形態において、レコードの、フィールドの非存在、又はフィールドに対応する値の非存在は、何らかの点でレコードが不完全であることを示すことがあり、それは、データ品質問題であり得る。いくつかの実装形態において、フィールド又は値の欠如は、所与のレコードについての特定のフィールドに無関係であると単に合図していることがある。
【００５２】
レコードのポピュレーションのパターンは、レコードのフィールドを分析することによって確認することができる。レコードにおけるデータパターンの表現は、例えば、要素の値が、レコードの対応するフィールド若しくはフィールドの組み合わせの１又は２以上の状態又はプロパティに対応する、データ要素を有するデータパターンコードを定式化することを含むことができる。要素値は、要素値の所定のセットから選択されてもよい。セット内の要素値の数は、データセットにおけるレコードにわたって対応するフィールドに発生するデータ値の総数よりも少なくてもよい。例えば、データパターンは、その中で要素がレコードにおけるフィールドの状態又はプロパティを表すビットである、ビットマップであってもよい。例えば、データパターンコードの定式化は、以下のようなフィールドの状態又はプロパティを示すために１又は２以上のビットが設定されたビットマップを含むことができる。０が、「空」又は「非存在」のフィールドの状態に対応し、１が、「空でない」及び「非存在でない」フィールドの状態に対応する。代替的なビットマップは以下のようであってもよい。０が、「空」（例えば、値なし）又は「ＮＵＬＬ」（例えば、フィールドが、１又は２以上の空白文字などの所定の「ＮＵＬＬ」値を有する）のフィールドの状態に対応し、１が、「非存在」（例えば、レコードにフィールドが存在しない）のフィールドの状態又はプロパティに対応し、及び２が、「ポピュレートされた」（例えば、フィールドが非ＮＵＬＬ値を有する）フィールドの状態に対応することができる。
【００５３】
複数のレコードの１又は２以上のフィールド若しくはフィールドの組み合わせは、フィールドのさまざまな状態又はプロパティの中でのパターンを確認するために分析される。例えば、分析が、フィールドがポピュレートされているか否かを判定する場合、特定のレコードについての考え得るパターン情報は、その特定のレコードにおいて、フィールドがポピュレートされているか否かを表す情報の配列を含むことができる。このようにして、データパターンコードは、レコードに対応するデータパターンを示すように、レコードに関連付けられる。
【００５４】
いくつかの実装形態において、ユーザが、フィールドについての特定の値を有するレコードの小部分を知りたいと思うことがある。例として、レコードは、ユニット番号又はアパート番号を予想することができるアドレスボディの断片を指す、フィールド「apt_num」を有することがある。レコードのどの小部分がアパートを有するものとして識別されるかを知ることに興味のあるユーザは、パターン情報のクイックビューによって、この情報を見つけ出すことができる。パターン情報はまた、レコードのフィールド間の考え得る相関関係への見通しを提供することができる。例えば、アパート番号又はユニット番号を有さないものとして示されるアドレスを有するレコードはまた、レコードが住宅所有者である個人に属すことを示している「Ｙｅｓ」に設定された、その住宅所有者フィールドを有することがある。
【００５５】
いくつかの実装形態において、必須フィールドにおける値が欠けている場合に、レコードは不完全であると考えられてもよい。例えば、銀行顧客のレコードにおいて、顧客の名字が必須フィールドであることがある。したがって、顧客レコードの名字フィールドに名字の値が存在しない場合、そのレコードは不完全であるとみなされるべきである。反対に、顧客レコードのミドルネームの値が存在しない場合、ミドルネームはオプションの値とみなすことができるので、そのレコードは不完全でなくてもよい。そのような状況において、銀行顧客のレコードのパターンが決定され、データパターンコードがレコードに割り当てられてもよい。実行モジュール１１２が特定のレコードについてのデータパターンコードを決定すると、データソース１０２から読み取られるさらなるデータを、コードに照らして分析することができる。これらの線に沿って、名字フィールドにおいて名字の値が欠けているデータレコードをフラグするために、１又は２以上のルールをエラー訂正のために書くことができる。したがって、データパターンコードの定式化が、必須フィールドがポピュレートされていることを保証し、また、オプションフィールドのポピュレーションを定量化するための、診断メカニズムとして使用されてもよい。
【００５６】
いくつかの実装形態において、データ処理システム１００がデータ発見モードにあるとき、データパターンコードの定式化を使用して、オプションフィールドから必須フィールドを区別することができる。時に、どのフィールドが必須であり、どのフィールドがオプションであるかを提供するオリジナルのポピュレーションルールが、失われている、又は入手可能でないことがある。例えば、名字フィールドが必須フィールドであり、一方、ミドルネームフィールドがオプションフィールドであることを提供するオリジナルのルールを、システム１００が利用可能でないことがある。実行モジュール１１２は、データソース１０２におけるデータセットを分析して、データセット内でポピュレーションのパターンを確立することができる。この状況において、所与のデータセットにおける実質的にすべてのレコードが、空でない値によってポピュレートされたその名字フィールドを有し、データセットにおけるレコードの特定の小部分のみがポピュレートされたそのミドルネームフィールドを有する場合、システム１００は、名字フィールドが必須フィールドであり、ミドルネームフィールドがオプションフィールドであることを推量することができる。
【００５７】
例として、次に図３を参照しながら、多国籍小売組織のエンタープライズデータウェアハウスにおける「取引」データセット３００を考えてみる。ウェアハウスは、いくつかの国々のストアで行われた取引を記録することができる。したがって、ある国の取引に対応する取引レコード３０４は、取引＿ｉｄフィールド（例えば、特定の取引を識別する代理キー）、顧客＿ｉｄフィールド（例えば、顧客のマスターリストからなる別のデータセットにリンクする代理キー）、購入された品物を識別する製品＿ｉｄフィールド（例えば、製品のマスターリストからなる別のデータセットにリンクする代理キー）、ストア＿ｉｄフィールド（例えば、ストア及びその場所のリストからなるデータセットにリンクする代理キー）、数量フィールド、及び価格フィールドを含むことができる。これらのフィールドはすべて、必須フィールド３０８（例えば、フィールドが空であることが許可され得ない）とみなすことができる。したがって、これらの必須フィールド３０８のうちのいずれかがポピュレートされていない場合、データの品質に問題があるとみなすことができる。データセットはまた、国＿ｃｄフィールド（例えば、そのストアが位置する国を識別する代理キー）、通貨＿ｃｄフィールド（例えば、取引の通貨を識別する代理キー）、及び購入に含まれる税の金額を示す税フィールドなどの、追加フィールド３１２を含むことができる。いくつかの実装形態において、追加フィールド３１２は、ポピュレートされていても、されていなくてもよく、そのようなフィールドにおけるデータの非存在は、データ品質問題を提示しなくてもよい。
【００５８】
上のシナリオにおいて、データパターンコード３１６を各レコード３０４に割り当てることによって、取引データセット３００のデータ品質を分析することができる。例えば、データパターンコード３１６は、取引レコード３０４の、どのフィールド３２０がポピュレートされていて、どのフィールドがポピュレートされていないかを反映することができる。ビットマップコードの定式化を仮定すると、ビットマップコードのビットは、以下のように、取引レコードの対応するフィールドに割り当てられてもよい。取引＿ｉｄ（ビット０）、顧客＿ｉｄ（ビット１）、製品＿ｉｄ（ビット２）、ストア＿ｉｄ（ビット３）、数量（ビット４）、価格（ビット５）、国＿ｃｄ（ビット６）、通貨＿ｃｄ（ビット７）、及び税（ビット８）。取引レコードのフィールドがポピュレートされると、対応するビットが１に設定され、そうでない場合、ビットは０に設定される。一般に、１０進表記法では、例えば、ビット「ｋ」が１に設定されると、２ｋの値がビットマップコードに加えられる。例えば、取引＿ｉｄ、顧客＿ｉｄ、製品＿ｉｄ、価格及び税がポピュレートされたとすると、データパターンコードは、１５１であることになる（設定されたビット０、１、２、５及び８が１＋２＋４＋３２＋２５６＝２９５に対応する）。
【００５９】
いくつかの実装形態において、必須フィールド３０８及び追加フィールド３１２に対応するマスクコード３２４を実装することができる。マスクコード３２４は、レコード３０４のフィールド若しくはフィールド値を、選択的に含める、又は除くことができるフィルタとしての役割を果たす。上で説明したように、例示的な取引レコードの最初の６つのフィールドは、必須フィールド３０８であり、次の３つのフィールドは、追加フィールド３１２である。したがって、マスクコード３２４を、必須フィールド３０８及び追加フィールド３１２を示すために、［０００１１１１１１］のように定式化することができる（１０進表記法において、マスクコードは６３である）。ビット単位のＡＮＤ演算を、ビットマップコード３２０とマスクコードとの間で計算することができる。ビット単位のＡＮＤの結果が６３以外の何らかである場合は、必須フィールド３０８のうちの１つがポピュレートされていない。例えば、（６３＆２９５）＝３９であり、これはビット０、１、２、及び５が設定されたことを示しており、したがって、ストア＿ｉｄフィールド及び数量フィールドがポピュレートされていない。したがって、この状況をデータ品質問題としてフラグすることができる。
【００６０】
いくつかのシナリオにおいて、異種のデータセット（例えば、レコードが、異なるデータレコードフォーマットにおいて値を受け入れることができるデータセット）が、レコードタイプを識別するための別個のフィールドを含むレコードを有することができる。したがって、レコードのためのポピュレーションのデータフォーマットが、レコードタイプを条件にして作成されてもよい。しかしながら、条件付きの必須フィールド（すなわち、特定のデータ条件が満たされたときのみに必須であるフィールド）を有する特定の他のデータセットでは、レコードタイプについての情報を保持する明示的なフィールドを持たない暗黙の異種性が存在してもよい。そのような状況では、データパターンコードの定式化を使用して、レコードフォーマットの基礎になる集まりを決定し、条件付きの必須フィールドを有するデータセットの完全性を検証することができる。開発者又は分析者は、データパターンコードの定式化を使用して、そのような条件付きの必須レコードをカテゴライズすることができる。このような状況において、代理レコードタイプとしてのデータパターンコードの定式化の使用は、自然キーの代わりに使用されてもよい代理キー（すなわち、ビジネス／実世界の意味を有さないシステム生成されたキー）に類似していてもよい。
【００６１】
例として、上で説明した取引データセット３００（図３）のコンテキストでは、データを、各ストア内で別々にキャプチャし、国ごとに単一のデータセットに組み合わせ、次いでエンタープライズデータウェアハウスの取引データセット３００の中にロードすることができる。米国における取引データセットが国フィールド又は通貨フィールド（すなわち、ビット番号６及び７）を有さない、例示的なシナリオを考えてみる。ＵＳ取引レコードフォーマットを、２つの新しいフィールドを含むように拡張することができ、一方で、レガシーアプリケーションとの一致を維持するために、ＵＳ取引についての国フィールド及び通貨フィールドはポピュレートされていない。これらのフィールドは、非ＵＳ取引レコードについては必須とみなすことができる。したがって、これらのデータ値がこれらのフィールドに存在しないいかなる状況も、データ品質問題としてフラグすることができる。この点において、フィールドは、レコードが非ＵＳ取引レコードであるという条件に従って必須とみなされる。同様に、税フィールド（ビット８）は、取引中に地域で税が徴収された場合に、必須とみなすことができる。やはり、税は徴収されたが税フィールドがポピュレートされていない状況は、データ品質問題としてフラグすることができ、したがって、税フィールドは、レコードが、税が徴収された地域にあるという条件に従って必須とみなすことができる。
【００６２】
条件付きデータパターンを、必須データパターンに類似したやり方で分析することができる。現在のシナリオでは、ＵＳ取引レコードは、ポピュレートされていない国＿ｃｄ及び通貨＿ｃｄ（ビット６及び７）のフィールドを有することが予想され、一方、これらのフィールドは、非ＵＳ取引レコードについてはポピュレートされることが予想される。ストアの場所（これは、いくつかの状況では、Ｓｔｏｒｅデータセットにアクセスすることを必要とすることがある）を明示的にチェックすることなく、ビット６及び７の両方が１に設定されるか、又は両方が０に設定されるかのどちらかをチェックすることによって、国＿ｃｄフィールド及び通貨＿ｃｄフィールドのパターンの相関関係を検証することができる。
【００６３】
いくつかの実装形態において、そのような相関関係の存在を、データパターンコードの分布から推測することができる。各コードを有するレコードの数をカウントすることを可能にするように、取引データセット３００をデータパターンコードまでロールアップすることができる。このようにして、ビット６及び７の両方が設定された、又はされていないレコードの数を決定することができる。いくつかの実装形態において、パターンについての説明を探す目的のために、データパターンコードを有するレコードのサンプルを抽出することが有益であることがある。このシナリオでは、レコードの好適なサンプルの検査後に、国＿ｃｄフィールドからのＵＳ国コードの非存在、並びに通貨＿ｃｄフィールドからのＵＳドル通貨コードの対応する非存在が目立つことになると思われる。したがって、通貨＿ｃｄフィールドのポピュレーションは、国＿ｃｄフィールドのポピュレーションを条件にして必須であるとみなすことができる。このようにして、データパターンコードの定式化の使用により、「隠れた」ルールを探すプロセスを単純化することができる。
【００６４】
いくつかのデータ処理アプリケーションにおいて、特殊なレコードフォーマットを使用して、共通フレームワークを通した処理前の異質なソースからのデータを、標準化する、又は均一にすることができる。そのようなアプリケーションでは、情報の紛失を避けるために、「均一化」レコードフォーマットが、異なるソースからのフィールドのスーパーセットを含む。均一化レコードフォーマットは、いくつかの異なるソースからのデータパターンを分析することによって、生成されてもよい。例えば、いくつかの実装形態において、第１のフィールドのセットが、多くのソースに共通したデータを保持することができ、一方、第２の異なるフィールドのセットが、特定のソース又はソースのサブセットに一意に関連付けられてもよい。例として、第１のソースからのレコードにおける日付フィールドは、「ＤＤ／ＭＭ／ＹＹＹＹ」フォーマットであってもよく、第２のソースからの第２の異なるレコードにおけるデータフィールドは、「ＤＤ、月、年」のフォーマットであってもよい。いくつかのソースでは、日及び月のみが利用可能であってもよく、他のソースでは、日、月、及び年の値が、別個のフィールドであってもよい。均一化レコードフォーマットは、このようにさまざまなソースからのレコードタイプの組み合わせから導き出されてもよい。続いて、均一化レコードは、異なるソースに属するレコードからのデータによって、ポピュレートされてもよい。
【００６５】
いくつかの実装形態において、均一化レコードが適切にポピュレートされたかどうかを判定するために、必須及び条件付きのポピュレーションを指定する１又は２以上のビジネスルールを使用して、予想されるデータパターンをテストシナリオの出力に関連付けることができる。次いで、バリデーションのために、これらの予想される結果を、実際の結果と比較することができる。例えば、実行モジュール１１２が均一化レコードフォーマットを生成すると、均一化レコードをポピュレートするために、さまざまなデータソースを使用することができる。次いで、必須及び条件付きのポピュレーションを指定するビジネスルールを使用して、フィールドが適正にポピュレートされたかどうかを判定することができる。
【００６６】
異なるソースからのデータが共通のフォーマットに組み合わされるとき、例えば、異なる国々の異なる会社からのレガシーデータが企業合併後に組み合わされるとき、異なるレコード構造が、データウェアハウジングアプリケーションに必要とされる可能性がある。これらの線に沿って、取引データセット３００（図３）において、国固有である追加フィールドが存在してもよい。例えば、いくつかの国では、品物が（例えば、飲料の「６パック」セットと同じような）マルチパックの一部として購入されたときを示すために使用される、パッケージ＿ｉｄフィールドが存在してもよく、一方、他の国々では、サイズ（例えば、１６オンス又は４００ｇ）を示すためのボリュームフィールド、及びいくつかのユニットを示すためのユニットフィールドが存在してもよい。データパターンコード３２０は、特定のフィールドのみが相関したポピュレーションを有することを示すことができる。すなわち、パッケージ＿ｉｄフィールドがポピュレートされるか、ボリュームフィールド及びユニットフィールドが両方ポピュレートされるかのいずれかであり、どちらも特定の互いに素である国＿ｃｄフィールド値についてのみ発生する。
【００６７】
いくつかの実装形態において、そのそれぞれがポピュレートされたフィールドのみからなるレコードフォーマットのセットに関してデータセットを記述する、条件付きレコードフォーマットを構築することができる。例えば、１つの縮小されたレコードフォーマットが、単にパッケージ＿ｉｄを特別なフィールドとして有してもよく、別の縮小されたレコードフォーマットは、ボリューム及びユニットを有することになり、一方、さらに別の縮小されたレコードフォーマットは、追加フィールドを有さなくてもよい。そのような縮小は、多くのソースからのデータを組み合わせる複雑なレコードフォーマットで作業するときに、有益であることがある。いくつかの実装形態において、異なる縮小されたフォーマットのそれぞれにおけるレコードのサンプルを調査することは、ソースを示すことができる、又は、縮小されたレコードフォーマットの背後にあるビジネス根拠を、これが最初の時点では既知でなかった場合でも提供することができる。
【００６８】
いくつかの例において、データパターンコードの定式化を、ＣＯＢＯＬ  ＲＥＤＥＦＩＮＥと共に使用することができる。一般に、ＲＥＤＥＦＩＮＥ節は、空白を省くために、同じメモリ領域が異なるデータアイテムによって記述されることを許容する。したがって、ＣＯＢＯＬ  ＲＥＤＥＦＩＮＥは、バイトの同じセットの２以上の構文解析を、異なるフィールドの中に指定することができる。Ｃプログラミング言語（又は同様のプログラミング言語）においては、そのような構文を共用体データ構造と呼ぶことができ、同様の問題が発生し得る。２以上のＲＥＤＥＦＩＮＥのうちのどれが所与のレコードにおいて使用されることになるかは、時に、そのレコードにおける別のフィールドによって決定されるが、これがどのフィールドであるかの認識は、失われている、又は入手可能でない（例えば、アプリケーションコードに埋め込まれている）ことがある。或いは、レコードにおいて、どのＲＥＤＥＦＩＮＥを使用するかを示すフィールドが存在しないことがある。時に、この情報は、レコードフォーマットの外部（例えば、ファイル名の中、若しくは処理アプリケーションに利用可能などこか）に保持される、又は、時に、ＲＥＤＥＦＩＮＥの内容は、どれが適正なものかを判定するために点検が必要になることがある。これらの例は、網羅的ではなく、例示的であることを意図している。これらの状況のすべては、そのオリジナルコンテキストの外部のデータセットを読み取るための潜在的な難しさを呈している。
【００６９】
ＲＥＤＥＦＩＮＥのすべてのフィールドを使用して計算されたデータパターンコードは、適切な構文解析を推測することができる。例示的なシナリオにおいて、ＲＥＤＥＦＩＮＥデータ構造は、似ていないデータからなることができる。例えば、ＲＥＤＥＦＩＮＥの１つのブランチがアルファベットのテキストフィールドのみを収容し、一方、同じバイトについての別のＲＥＤＥＦＩＮＥが１０進数フィールドを収容する場合、１０進数フィールドが数字及び単一の小数点以外の何かを収容するときに、１０進数フィールドは無効とマークされることになる。この状況は、ＣＯＢＯＬ  ＲＥＤＥＦＩＮＥが使用されるレガシーメインフレームデータにおいて発生し得る。（単純なポピュレーションではなく）フィールドにおけるデータの有効性に基づいたデータパターンコードの定式化を使用して、適正な構文解析を検出することができる。いくつかの実装形態において、結果としてのデータパターンコードを使用して、データ構造を、各代替ＲＥＤＥＦＩＮＥフォーマットが関連するデータパターンコードについてのみ発生する条件付きレコードフォーマットに変換することができる。
【００７０】
レガシーデータの場合、どのフィールドが多くのソースに共通であるか、どのフィールドが固有であるか、又は、ソースを越えて持続できる若しくは持続できないフィールド間で相関関係が存在するかどうかに関する問題に、データをポピュレートするのに使用されたビジネスルールを調べることによって答えることができる。いくつかのシナリオにおいて、これらのルールは、失われている、又は入手可能でないことがある。例えば、ルールがなお現行で使用されていても、いずれの書面のドキュメンテーションも期限切れである、又は紛失していることがある。そのようなシナリオでは、データパターンコードの定式化を使用して、フィールド間の相関関係を判定し、フィールドとレコードのソースとの関連もまた判定することができる。
【００７１】
いくつかの実装形態において、データパターンコードを構築した後にアグリゲーションを実施することによって、レコードにおけるフィールド間の相関関係を推定することができる。例えば、取引データセット３００（図３）において、データセットがストア＿ｉｄフィールドまでロールアップされる場合、税フィールドがポピュレートされたレコードはいくつあるかのカウントを使用して、地域におけるどのストアが売上又はＶＡＴ税を有するかを判定することができる。どの地域が税を徴収したかの判定は、上で詳細に説明したように、データ単独の統計値から推測することができる。
【００７２】
いくつかの実装形態において、データは、ＸＭＬなどの業界標準レコードフォーマット、及び金融取引のためのＩＳＯ２００２２に存在することができる。例えば、ある人は、既存のシステムを再設計する必要なしに、自分たちのレガシーデータを共通フォーマットの中にポピュレートできるという理由で、ＩＳＯ２００２２を内部標準として使用する選択をすることがある。また、異なるレガシーソース（カスタマイズされた、又は拡張されたレガシーフォーマットを含む）が、他のソースと共通であるフィールド、及びレガシーソースに一意のいくつかのフィールドをポピュレートすることができる。この点において、開発者は、業界標準で保持されたデータで動くアプリケーションを書く必要があることがある。業界標準によって記述された完全なレコードフォーマットは、複雑で、任意の１つのレガシータイプの観点から異質なデータを収容することがあるので、開発者は、ポピュレートされないフィールドを破棄する選択をすることがある。具体的には、ＸＭＬスキーマが、ポピュレートされてもよいフィールドの考え得るセットを定義することができる。したがって、ＸＭＬレコード（例えば、ＸＭＬに従ってフォーマットされたデータを含むドキュメント）は、そのレコードについてポピュレートされるフィールドのみを収容することがある。
【００７３】
多様なレガシーソースからのデータが一緒に保持されるデータウェアハウジングの状況では、ＸＭＬレコード内に存在するデータはさまざまであってよい。データパターンコードがＸＭＬレコードごとに計算される場合、コードは、フィールドの異なる組み合わせを使用するレコードを独立した処理のために簡単に引き離すのを可能にすることができる。一緒にポピュレートされるフィールドの種類が、質的に異なるデータの種類（例えば、ＢＩＣコードのような機関識別情報は、名前及びアドレス情報とは異なる）を表すことができ、したがって、それらは別個に処理するように決められている。多様なデータパターンコードのマスキング又は作成が、データのこれらのセグメントを簡単に区別するのを可能にすることができる。
【００７４】
さらに、いくつかの実装形態において、いくつかのＸＭＬタグは必須であってもよく、一方、他のＸＭＬタグは必須でなくてもよい。上で説明したように、データパターンコードの定式化は、ドキュメンテーションへの参照に頼ることなく、フィールドの分析を手助けすることができる。
【００７５】
いくつかの実装形態において、データパターンコードの定式化を使用して、ダウンストリームアプリケーションのためのテストケースを用意することができる。アプリケーションへの入力データが多くのソースから組み立てられるとき、アプリケーションが受信する可能性のあるさまざまな入力を適切に扱うことができるかどうかについての懸念があり得る。実社会の状況では、アプリケーションへの入力データ量が、意味のあるテストを可能にするには大きすぎることがある。この状況に対処するために、いくつかの実装形態において、データパターンコードを、生産データ、すなわち、アプリケーションへの入力データについて定式化することができる。テストレコードのデータセットをデータパターンコードに基づいて作成し、アプリケーションに適用することができる。例えば、少数のレコード（例えば、単一のレコード又は別の所定の数のレコード）を、別個のデータパターンコードごとに選択することができる。全生産データから得られると、このデータセットは、適正に扱うようにアプリケーションを構成することができる、テストケースの包括的なセットを表すようにみなすことができる。
【００７６】
図２は、例示的なデータパターン分析手順２００のための流れ図を示す。手順は、データストレージシステムにデータセットを記憶するステップ（２０２）を含む。データセットは、多様なフィールドに対応する値を有する複数のレコードを含むことができる。レコードは、データストレージシステムに接続されたデータ処理システムにおいて分析されて（２０４）、レコードにおけるデータパターンの表現を生成する。レコードにおけるデータパターンの表現は、例えば、レコードにおけるフィールドのプロパティを表すビットを有するビットマップなどの、データパターンコードの定式化を含むことができる。レコードの処理は、レコードごとに、複数のレコードの１又は２以上のフィールド若しくはフィールドの組み合わせを分析するステップ（２０６）を含むことができる。分析は、データセットにおけるレコードごとに、そのデータセット内の、又は１若しくは２以上の他のデータセット内の、１又は２以上の他のレコードに関する計算を含むことができる。例えば、数値フィールドの平均値をデータセットにおけるレコードのセットについて計算し、他のデータセットの集まりから得られたレコードのセットの平均値（「履歴平均値」）と比較して、何らかの閾値量によって、現在の平均値が履歴平均値よりも大きいかどうかを判定することができる。分析は、複数のレコードにおけるフィールドの中で１又は２以上のパターンを発見するステップを含むことができる。例えば、関連した状態又はプロパティが、フィールドがポピュレートされているか否かを含む場合、パターンは、フィールドがポピュレートされているか否かを表す情報の配列であってもよい。このようにして、データパターンコードを定式化して（２０８）、レコードに対応するデータパターンを示すことができる。レコードが処理された後、結果としてのコードを、レコード及びその対応するデータパターンを識別するやり方で記憶することができる（２１０）。追加のレコードが分析されるとき、手順２００が繰り返されて、追加のレコードを処理することができる。
【００７７】
いくつかの実装形態において、サブルーティンをより大きなプログラムで使用して、フィールド名のベクトルを収容するレコードを引数として受信し、データパターンコードを生成することができる。例えば、サブルーティンは、引数として、レコード、及び「ブランク」、「ブランク＿ｏｒ＿ＮＵＬＬ」、その他などの値を有するルール＿ｔｙｐｅを取ることができる。サブルーティンは、フィールド名ごとに値を計算することができ、選んだルール＿ｔｙｐｅに適切なビットマップを構築する。「ブランク」ルール＿ｔｙｐｅは、フィールドがブランクであるか、又はポピュレートされているかを示すデータパターンコードを提供する。したがって、結果としてのビットマップは、フィールドがポピュレートされている場合にはビットセットを有するバイナリであり、フィールドがポピュレートされていない場合には０を有するバイナリである。「ブランク＿ｏｒ＿ＮＵＬＬ」ルール＿ｔｙｐｅは、このケースではコードごとに２つのビットを使用して、フィールドが、ブランクであるか（０）、ポピュレートされているか（１）、又はＮＵＬＬであるか（２）を示すデータパターンコードを提供する。「有効性」ルール＿ｔｙｐｅは、所与のフィールドが無効であるか（０）、又は有効であるか（１）を示すデータパターンコードを提供することができる。無効なフィールドは、関連したデータタイプについて許可されていないバイト又は値を収容するフィールドであってもよい。例えば、「３１−ＪＵＮ−１９６０」は、日付フィールドとして無効であり、一方、「１２３ａ」は、１０進数フィールドとして無効である。
【００７８】
「表現」ルール＿ｔｙｐｅは、表現がフィールドごとに供給され、その結果をビット（又はビット値のセット）に関連付けるのを可能にすることができる。例えば、いくつかのヌル非許容なフィールドを、「ブランク」ルールを用いて分析することでき、一方、他のヌル許容なフィールドを「ブランク＿ｏｒ＿ヌル」ルールを用いて分析することができる。列挙された値の小さなセットのみを収容する他のフィールドは、ビット値にマップされたその特定の値を有することができる。例えば、性別の「Ｍ」又は「Ｆ」は、０又は１にマップされてもよく、一方、取引＿ｔｙｐｅフィールドの「Ａ」、「Ｃ」、又は「Ｐ」は、０、１、又は２にマップされてもよい。
【００７９】
いくつかの実装形態において、フィールドの１又は２以上の組み合わせもまた符号化することができる。例えば、類似性（「あいまい一致」）についてフィールドを比較しているアプリケーションにおいて、一致コードのセットを（通常、２つの別個のレコードにおける、場合により別個のデータセットにおける）２つのフィールドの比較に指定することができる。例えば、比較されている２つの会社名が与えられたとすると、結果（例えば、一致の度合いを定量化するスコア）は、「不一致」（０）、すなわち、会社名は、何らかの所定の基準に従って類似していない、「完全一致」（１）、「ファジーマッチ」（２）、すなわち、会社名は何らかの所定の基準に従って類似しているが同一ではない、「ポピュレートされていない０」、すなわち、会社名１はポピュレートされているが、会社名０はポピュレートされていない、「ポピュレートされていない１」、すなわち、会社名０はポピュレートされていないが、会社名１はポピュレートされていない、及び、「ポピュレートされていない０１」、すなわち、どちらの会社名もポピュレートされていない、としてマークされてもよい。あいまい一致のための技法の例、及びあいまい一致に基づいたクラスタリングは、「MANAGING AN ARCHIVE FOR APPROXIMATE STRING MATCHING」と題された米国特許出願公開第２００９／０１８２７２８号Ａ１明細書、及び「FUZZY DATA OPERATIONS」と題された米国特許出願公開第２０１０／０１０６７２４号Ａ１明細書に説明されており、これらのそれぞれを参照により本明細書に組み込む。
【００８０】
いくつかの実装形態において、ユーザに提示されるユーザインターフェース内のグラフィカル表示を通して、パターン情報をユーザに提示することができる。このようにして、ユーザは、ポピュレートされている、レコードにおけるフィールドのパーセンテージを素早く確認することができる。図４は、フィールド４００のリスト、ビットラベル４０１、及びマスク４０２を設定するためのボタンを含む例示的なユーザインターフェースを示す。フィールドごとに考え得るコードの設定が、凡例４０４に提供されている。（選択はフィールドごとに異なってもよく、いくつかの実装形態において、ユーザインターフェースは、フィールドごとに異なる選択を表示する。）ダイアグラム４０６は、（別個のデータパターンコードに対応する）それぞれの別個のパターンにおいて、選択されたフィールドごとにどの要素が設定されるかを示す。マスク４０２において選択されるボタンごとに（ラベル４０１で上段にわたって識別される対応するフィールドを有する）列があり、別個のパターンごとに行がある。所与のパターンを有するレコードの小部分が、ここではグレイスケール表示４０８で示され、より濃い色調が、ポピュレーションのより大きな小部分を示し、またパーセンテージ４１０として数値的に示す。
【００８１】
図５は、マスクが選択的に設定され、フィールドごとに３以上のデータパターンコードがあるときの、例示的なユーザインターフェースを示す。フィールド５００が列挙され、それぞれのフィールドにラベル５０１が割り当てられている。マスク５０２は、ボタンを選択することによって設定される。凡例５０４は、表示されるデータパターンコードを列挙する。ここでは、濃度レベルを使用してデータパターンコードを区別しているが、単に数値的なデータパターンコードを表示することを含む、他の考え得る表示表現も可能である。パターンのセットがグリッド５０６として表示され、各列は、マスクにおいて選択されたフィールドに対応し、各行は、ポピュレーションのパターンを示すデータパターンコードに対応している。（マスク及び選択されたデータパターンコードのセットに関連付けられた）各パターンを有するレコードの小部分を反映するポピュレーションの小部分が、グレイスケール５０８で、及びパーセンテージ５１０として数値的に表示されている。
【００８２】
上で説明したデータパターン分析アプローチは、コンピュータ上で実行するためのソフトウェアを使用して実装されてもよい。例えば、ソフトウェアは、１又は２以上のプログラムされた、若しくはプログラム可能なコンピュータシステム（システムは、分散型、クライアント／サーバ、又はグリッドなどのさまざまなアーキテクチャであってもよい）上で実行される１又は２以上のコンピュータプログラムで手順を形成し、コンピュータシステムのそれぞれは、少なくとも１つのプロセッサ、少なくとも１つのデータストレージシステム（揮発性及び非揮発性メモリ並びに／又はストレージ要素を含む）、少なくとも１つの入力デバイス又はポート、及び少なくとも１つの出力デバイス又はポートを含む。ソフトウェアは、より大きなプログラムの１又は２以上のモジュールを形成することができ、モジュールは、例えば、データフローグラフの設計及び構成に関連した他のサービスを提供する。グラフのノードと要素は、コンピュータ可読媒体に記憶されるデータ構造として、又はデータリポジトリに記憶されるデータモデルに適合する他の編成されたデータとして、実装されてもよい。
【００８３】
ソフトウェアは、ＣＤ−ＲＯＭなどのストレージ媒体上で提供されても、汎用コンピュータ若しくは特殊目的プログラム可能なコンピュータによって可読であっても、又は、実行されるときに（伝搬信号において符号化されて）ネットワークの通信媒体上でコンピュータに配信されてもよい。機能のすべては、特殊目的コンピュータ上で、又はコプロセッサなどの特殊目的ハードウェアを使用して、実施されてもよい。ソフトウェアは、ソフトウェアによって指定された計算の異なる部分が異なるコンピュータによって実施される、分散型方式において実装されてもよい。ストレージ媒体若しくはストレージデバイスがコンピュータシステムによって読み込まれて、上で説明した手順を実施するときに、コンピュータを構成し、動作させるために、それぞれのそのようなコンピュータプログラムは、好ましくは、汎用コンピュータ又は特殊目的プログラム可能なコンピュータによって可読な、ストレージ媒体若しくはストレージデバイス（例えば、ソリッドステートメモリ若しくはソリッドステート媒体、又は磁気媒体若しくは光学媒体）に記憶される、又はダウンロードされる。本発明のシステムはまた、コンピュータプログラムによって構成されたコンピュータ可読ストレージ媒体として実装するように考えられてもよく、そこでは、そのように構成されたストレージ媒体が、コンピュータシステムを、固有の、及びあらかじめ定義されたやり方で動作させて、本明細書で説明した機能を実施する。
【００８４】
本発明のいくつかの実施形態を説明してきた。それでもやはり、本発明の趣旨及び範囲から逸脱せずに、さまざまな修正形態を行うことができることが理解されるだろう。例えば、上で説明したステップのうちのいくつかは、順序に無関係であってもよく、したがって、説明した順序とは異なる順序で実施されてもよい。
【００８５】
上述した説明は、添付の特許請求の範囲によって定義される本発明を例証することを意図しており、本発明の範囲を限定することを意図していないことが理解されるべきである。例えば、上で説明した機能ステップのうちのいくつかは、全体的な処理に実質的に影響することなく、異なる順序で実施されてもよい。他の実施形態は、以下の特許請求の範囲内である。
【図１】
2014511587.tif 000003
【図２】
2014511587.tif 000004
【図３】
2014511587.tif 000005
【図４】
2014511587.tif 000006
【図５】
2014511587.tif 000007
【手続補正書】
【提出日】平成25年10月9日(2013.10.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、
前記レコードにおけるデータパターンを表すコードを生成するために、前記データストレージシステムに接続されたデータ処理システムにおいて、前記複数のレコードを処理するステップであって、前記データパターンが、前記レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、処理するステップと
を含む方法であって、
前記処理するステップが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けるステップを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
方法。
【請求項２】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、ポピュレートされている、又はポピュレートされていないときのフィールドの状態をそれぞれ表す、請求項１に記載の方法。
【請求項３】
ポピュレートされていない状態が、ヌル状態、非存在状態、又は空状態のうちの１つを含む、請求項２に記載の方法。
【請求項４】
ヌル状態が、所定の値を有するフィールドの状態を含む、請求項３に記載の方法。
【請求項５】
所定の値が、１又は２以上の空白文字を含む、請求項４に記載の方法。
【請求項６】
非存在状態が、レコードにおいて欠けているフィールドを含む、請求項３〜５のいずれかに記載の方法。
【請求項７】
空状態が、対応するデータ値を有さないフィールドを含む、請求項３〜６のいずれかに記載の方法。
【請求項８】
第１のコードの少なくとも１つの要素について、セット内の少なくとも２つの要素値が、フィールドに関連付けられたバリデーションルールに従って、有効である又は有効でない前記フィールドにおいて発生するデータ値を表す、請求項１〜７のいずれかに記載の方法。
【請求項９】
バリデーションルールが、データ値のデータタイプに少なくとも部分的に基づいて、有効値を定義する、請求項８に記載の方法。
【請求項１０】
バリデーションルールが、列挙された値のリストを参照することによって、少なくとも部分的に有効値を定義する、請求項８に記載の方法。
【請求項１１】
第１のコードの少なくとも１つの要素について、セット内の１又は２以上の要素値が、第１のフィールドにおいて発生するデータ値がターゲットデータ値と一致する度合いを表す、請求項１〜１０のいずれかに記載の方法。
【請求項１２】
ターゲットデータ値が、第２のフィールドにおいて発生するデータ値である、請求項１１に記載の方法。
【請求項１３】
セット内の少なくとも３つの要素値が、第１のフィールドにおいて発生するデータ値が、不一致、完全一致、又はファジーマッチとしてそれぞれターゲットデータ値に一致する度合いを表す、請求項１〜１２のいずれかに記載の方法。
【請求項１４】
第１のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、第１のレコードのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、及び前記第１のレコードとは異なる少なくとも第２のレコードを含む１又は２以上のレコードのセットのフィールド若しくはフィールドの組み合わせにおいて発生する１又は２以上の値から、計算されるデータ値を符号化する、請求項１〜１３のいずれかに記載の方法。
【請求項１５】
第１のレコードが、第１のデータセット内にあり、第２のレコードが、前記第１のデータセットとは異なる第２のデータセット内にある、請求項１４に記載の方法。
【請求項１６】
少なくとも第２のコードの少なくとも１つの要素について、セット内の少なくとも１つの要素値が、フィールドにおいて発生する所定のデータ値を表す、請求項１〜１５のいずれかに記載の方法。
【請求項１７】
第２のコードの要素についての要素値のセット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド又はフィールドの組み合わせにおいて発生するデータ値の総数に等しい、請求項１６に記載の方法。
【請求項１８】
コンピュータプログラムを記憶するコンピュータ可読ストレージ媒体であって、前記コンピュータプログラムが、コンピュータシステムに、
複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶させ、
前記レコードにおけるデータパターンを表すコードを生成するために、前記データストレージシステムに接続された、前記コンピュータシステムの少なくとも１つのプロセッサにおいて、前記複数のレコードを処理させるための命令を含み、前記データパターンが、前記レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表し、
前記処理させることが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
コンピュータ可読ストレージ媒体。
【請求項１９】
複数のレコードを含む少なくとも１つのデータセットを記憶するように構成されたデータストレージシステムと、
前記レコードにおけるデータパターンを表すコードを生成するために、前記複数のレコードを処理するように構成された、前記データストレージシステムに接続されたデータ処理システムであって、前記データパターンが、前記レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、システムと
を含むシステムであって、
前記処理することが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
システム。
【請求項２０】
複数のレコードを含む少なくとも１つのデータセットを記憶するための手段と、
前記レコードにおけるデータパターンを表すコードを生成するために、前記複数のレコードを処理するための手段であって、前記データパターンが、前記レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、手段と
を含むシステムであって、
前記処理することが、前記複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードを前記レコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、前記セット内の要素値の数が、前記データセットにおける前記複数のレコードのすべてにわたって前記対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない、
システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００４
【補正方法】変更
【補正の内容】
【０００４】
一態様では、概して、方法が、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶するステップと、レコードにおけるデータパターンを表すコードを生成するために、データストレージシステムに接続されたデータ処理システムにおいて、複数のレコードを処理するステップであって、データパターンが、レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、処理するステップとを含み、処理するステップが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けるステップを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】変更
【補正の内容】
【００２２】
別の態様では、概して、コンピュータ可読ストレージ媒体が、コンピュータプログラムを記憶し、コンピュータプログラムは、コンピュータシステムに、複数のレコードを含む少なくとも１つのデータセットをデータストレージシステムに記憶させ、レコードにおけるデータパターンを表すコードを生成するために、データストレージシステムに接続された、コンピュータシステムの少なくとも１つのプロセッサにおいて、複数のレコードを処理させるための命令を含み、データパターンが、レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表し、処理させることが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】変更
【補正の内容】
【００２３】
別の態様では、概して、システムが、複数のレコードを含む少なくとも１つのデータセットを記憶するように構成されたデータストレージシステムと、レコードにおけるデータパターンを表すコードを生成するために、複数のレコードを処理するように構成された、データストレージシステムに接続されたデータ処理システムであって、データパターンが、レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、システムとを含み、処理することが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
別の態様では、概して、システムが、複数のレコードを含む少なくとも１つのデータセットを記憶するための手段と、レコードにおけるデータパターンを表すコードを生成するために、複数のレコードを処理するための手段であって、データパターンが、レコードのそれぞれに含まれる１又は２以上のフィールドにおける、データのポピュレーション又はデータの有効性のうちの少なくとも１つを表す、手段とを含み、処理することが、複数のレコードにおける多様なレコードのそれぞれについて、１又は２以上の要素を符号化するコードをレコードに関連付けることを含み、それぞれの要素が、要素値のセットの１つとして、対応するフィールド若しくはフィールドの組み合わせの状態又はプロパティを表し、少なくとも第１のコードの少なくとも１つの要素について、セット内の要素値の数が、データセットにおける複数のレコードのすべてにわたって対応するフィールド若しくはフィールドの組み合わせにおいて発生するデータ値の総数よりも少ない。
【国際調査報告】
2014511587.tif 000008
2014511587.tif 000009
2014511587.tif 000010