(57)【要約】      （修正有）【課題】異なるストレージ技術で構築された複数のデータベースを、統一インタフェースでアクセスする技術を提供する。【解決手段】データエンティティモデルの定義を受信する４０２と、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関係付け４０４、データベーススキーマに変換する４０６。データストレージに格納されたデータへのアクセスを受信する４０８と、データベーススキーマに従ってストレージシステムに固有のデータアクセス動作に変換してデータにアクセスする４１０。【選択図】図４
2015062109.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータストレージシステムに格納されたデータエンティティへのユーザアクセスを提供するためにコンピュータで実施される方法であって、
コンポーネント要素を含むデータエンティティモデルの定義を受信する工程と、
前記定義されたデータエンティティモデルの前記コンポーネント要素のうちの少なくとも１つを、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関連付ける仕様を受信する工程と、
前記受信した仕様に基づいて、前記データエンティティモデルの前記受信した定義を、前記データエンティティモデルを前記複数のデータストレージシステムに格納された前記データにリンクするデータベーススキーマに変換する工程と、
前記複数のデータストレージシステムのうちの１つに格納されたデータの一部へアクセスするリクエストを受信する工程と、
前記リクエストを受信したことに応じるとともに前記変換されたスキーマに基づいて、前記リクエストを、前記データストレージシステムに固有のデータアクセス動作に構成する工程とを有することを特徴とする方法。
【請求項２】
前記データストレージシステムに固有の前記データアクセス動作が当該データストレージシステムで実行されるようにする工程を更に有することを特徴とする請求項１に記載の方法。
【請求項３】
前記データの一部へアクセスするリクエストを受信する工程は、前記少なくとも１つのデータエンティティの一部にアクセスするデータアクセスリクエストを受信することを含み、前記データアクセスリクエストは前記データストレージシステムに固有でない統一フォーマットで指定されることを特徴とする請求項２に記載の方法。
【請求項４】
前記データアクセス動作を前記データストレージシステムで実行した結果を受信する工程を更に有することを特徴とする請求項２に記載の方法。
【請求項５】
前記データエンティティモデルの定義を受信する工程は、前記データエンティティモデルに記述された少なくとも１つのコンポーネント要素についての有効性定義を受信することを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記有効性定義に従ってアクセスされる前記少なくとも１つのデータエンティティの前記一部を検証する工程を更に有することを特徴とする請求項５に記載の方法。
【請求項７】
前記データエンティティモデルの前記受信した定義を変換する工程は、前記データエンティティモデルの前記受信した定義を、データエンティティを行で格納する少なくとも１つのデータストレージシステムと、データエンティティを列で格納する少なくとも１つの他のデータストレージシステムとについてのデータベーススキーマに変換することを含むことを特徴とする請求項１に記載の方法。
【請求項８】
データエンティティを行で格納する前記少なくとも１つのデータストレージシステムは、構造化クエリ言語（ＳＱＬ）データベース管理システムを含むことを特徴とする請求項７に記載の方法。
【請求項９】
データエンティティを列で格納する前記少なくとも１つの他のデータストレージシステムは、ＮｏＳＱＬデータベース管理システムを含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記データエンティティモデルの前記定義と前記仕様とを拡張可能データフォーマットで受信する工程を更に有することを特徴とする請求項１に記載の方法。
【請求項１１】
前記データエンティティモデルの前記定義と前記仕様とを拡張可能マークアップ言語（ＸＭＬ）で受信する工程を更に有することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記データエンティティモデルの前記定義と前記仕様とをＪａｖａスクリプトオブジェクト表記法（ＪＳＯＮ）で受信する工程を更に有することを特徴とする請求項１１に記載の方法。
【請求項１３】
前記データエンティティモデルの前記定義と前記仕様とを少なくとも１つのパース可能オブジェクトに変形する工程を更に有することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記複数のデータストレージシステムのそれぞれについて前記データベーススキーマを生成するために前記少なくとも１つのパース可能オブジェクトをパースする工程を更に有することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記データエンティティモデルに関連した表示レイアウトを指定する命令を受信する工程を更に有することを特徴とする請求項４に記載の方法。
【請求項１６】
前記データエンティティモデルの少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする工程を更に有することを特徴とする請求項１５に記載の方法。
【請求項１７】
報告ツールとのインタフェースを構成する工程と、
前記インタフェースを介して、前記データアクセス動作を実行した結果を前記報告ツールへ送信する工程と、
前記少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする工程とを更に有することを特徴とする請求項１５に記載の方法。
【請求項１８】
複数のデータストレージシステムとやり取りできるサーバであって、動作群を実行するように構成された少なくとも１つのプロセッサを備え、前記動作群は、
コンポーネント要素を含むデータエンティティモデルの定義を受信する動作と、
前記定義されたデータエンティティモデルの前記コンポーネント要素のうちの少なくとも１つを、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関連付ける仕様を受信する動作と、
前記受信した仕様に基づいて、前記データエンティティモデルの前記受信した定義を、前記データエンティティモデルを前記複数のデータストレージシステムに格納された前記データにリンクするデータベーススキーマに変換する動作と、
前記複数のデータストレージシステムのうちの１つに格納されたデータの一部へアクセスするリクエストを受信する動作と、
前記リクエストを受信したことに応じるとともに前記変換されたスキーマに基づいて、前記リクエストを、前記データストレージシステムに固有のデータアクセス動作に構成する動作とを有することを特徴とするサーバ。
【請求項１９】
前記動作群は、前記データストレージシステムに固有の前記データアクセス動作が当該データストレージシステムで実行されるようにする動作を更に有することを特徴とする請求項１８に記載のサーバ。
【請求項２０】
前記データの一部へアクセスするリクエストを受信する動作は、前記少なくとも１つのデータエンティティの一部にアクセスするデータアクセスリクエストを受信することを含み、前記データアクセスリクエストは前記データストレージシステムに固有でない統一フォーマットで指定されることを特徴とする請求項１９に記載のサーバ。
【請求項２１】
前記動作群は、前記データアクセス動作を前記データストレージシステムで実行した結果を受信する動作を更に有することを特徴とする請求項１９に記載のサーバ。
【請求項２２】
前記データエンティティモデルの定義を受信する動作は、前記データエンティティモデルに記述された少なくとも１つのコンポーネント要素についての有効性定義を受信することを含むことを特徴とする請求項１８に記載のサーバ。
【請求項２３】
前記動作群は、前記有効性定義に従ってアクセスされる前記少なくとも１つのデータエンティティの前記一部を検証する動作を更に有することを特徴とする請求項２２に記載のサーバ。
【請求項２４】
前記データエンティティモデルの前記受信した定義を変換する動作は、前記データエンティティモデルの前記受信した定義を、データエンティティを行で格納する少なくとも１つのデータストレージシステムと、データエンティティを列で格納する少なくとも１つの他のデータストレージシステムとについてのデータベーススキーマに変換することを含むことを特徴とする請求項１８に記載のサーバ。
【請求項２５】
データエンティティを行で格納する前記少なくとも１つのデータストレージシステムは、構造化クエリ言語（ＳＱＬ）データベース管理システムを含むことを特徴とする請求項２４に記載のサーバ。
【請求項２６】
データエンティティを列で格納する前記少なくとも１つの他のデータストレージシステムは、ＮｏＳＱＬデータベース管理システムを含むことを特徴とする請求項２５に記載のサーバ。
【請求項２７】
前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能データフォーマットで受信する動作を更に有することを特徴とする請求項１８に記載のサーバ。
【請求項２８】
前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能マークアップ言語（ＸＭＬ）で受信する動作を更に有することを特徴とする請求項２７に記載のサーバ。
【請求項２９】
前記動作群は、前記データエンティティモデルの前記定義と前記仕様とをＪａｖａスクリプトオブジェクト表記法（ＪＳＯＮ）で受信する動作を更に有することを特徴とする請求項２８に記載のサーバ。
【請求項３０】
前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを少なくとも１つのパース可能オブジェクトに変形する動作を更に有することを特徴とする請求項２９に記載のサーバ。
【請求項３１】
前記動作群は、前記複数のデータストレージシステムのそれぞれについて前記データベーススキーマを生成するために前記少なくとも１つのパース可能オブジェクトをパースする動作を更に有することを特徴とする請求項３０に記載のサーバ。
【請求項３２】
前記動作群は、前記データエンティティモデルに関連した表示レイアウトを指定する命令を受信する動作を更に有することを特徴とする請求項２１に記載のサーバ。
【請求項３３】
前記動作群は、前記データエンティティモデルの少なくとも１つのコンポーネント要素を前記指定された表示レイアウトに従って表示する動作を更に有することを特徴とする請求項３２に記載のサーバ。
【請求項３４】
前記動作群は、
報告ツールとのインタフェースを構成する動作と、
前記インタフェースを介して、前記データアクセス動作を実行した結果を前記報告ツールへ送信する動作と、
前記少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする動作とを更に有することを特徴とする請求項３２に記載のサーバ。
【請求項３５】
ソフトウェア命令を有するコンピュータ可読記憶媒体であって、前記ソフトウェア命令はコンピュータの１つ以上のプロセッサによって実行された場合に前記コンピュータに動作群を実行させ、前記動作群は、
コンポーネント要素を含むデータエンティティモデルの定義を受信する動作と、
前記定義されたデータエンティティモデルの前記コンポーネント要素のうちの少なくとも１つを、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関連付ける仕様を受信する動作と、
前記受信した仕様に基づいて、前記データエンティティモデルの前記受信した定義を、前記データエンティティモデルを前記複数のデータストレージシステムに格納された前記データにリンクするデータベーススキーマに変換する動作と、
前記複数のデータストレージシステムのうちの１つに格納されたデータの一部へアクセスするリクエストを受信する動作と、
前記リクエストを受信したことに応じるとともに前記変換されたスキーマに基づいて、前記リクエストを、前記データストレージシステムに固有のデータアクセス動作に構成する動作とを有することを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
ヘルスケアデータは多様なストレージシステムに電子フォーマットで格納されうる。
【発明の概要】
【０００２】
１つの側面では、実施形態は、多数のデータストレージシステムに格納されたデータエンティティへのユーザアクセスを提供するためにコンピュータで実施される方法であって、コンポーネント要素を含むデータエンティティモデルの定義を受信する工程と、前記定義されたデータエンティティモデルの前記コンポーネント要素のうちの少なくとも１つを、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関連付ける仕様を受信する工程と、前記受信した仕様に基づいて、前記データエンティティモデルの前記受信した定義を、前記データエンティティモデルを前記複数のデータストレージシステムに格納された前記データにリンクするデータベーススキーマに変換する工程と、前記複数のデータストレージシステムのうちの１つに格納されたデータの一部へアクセスするリクエストを受信する工程と、前記リクエストを受信したことに応じるとともに前記変換されたスキーマに基づいて、前記リクエストを、前記データストレージシステムに固有のデータアクセス動作に構成する工程とを有することを特徴とする方法を提供する。
【０００３】
実施形態は以下の特徴のうちの1つ以上を含んでもよい。１つの構成では、前記方法は、前記データストレージシステムに固有の前記データアクセス動作が当該データストレージシステムで実行されるようにする工程を更に有してもよい。前記データの一部へアクセスするリクエストを受信する工程は、前記少なくとも１つのデータエンティティの一部にアクセスするデータアクセスリクエストを受信することを含んでもよく、前記データアクセスリクエストは前記データストレージシステムに固有でない統一フォーマットで指定されてもよい。前記方法は、前記データアクセス動作を前記データストレージシステムで実行した結果を受信する工程を更に有してもよい。
【０００４】
別の構成では、前記データエンティティモデルの定義を受信する工程は、前記データエンティティモデルに記述された少なくとも１つのコンポーネント要素についての有効性定義を受信することを含んでもよい。前記方法は、前記有効性定義に従ってアクセスされる前記少なくとも１つのデータエンティティの前記一部を検証する工程を更に有してもよい。
【０００５】
さらに別の構成では、前記データエンティティモデルの前記受信した定義を変換する工程は、前記データエンティティモデルの前記受信した定義を、データエンティティを行で格納する少なくとも１つのデータストレージシステムと、データエンティティを列で格納する少なくとも１つの他のデータストレージシステムとについてのデータベーススキーマに変換することを含んでもよい。データエンティティを行で格納する前記少なくとも１つのデータストレージシステムは、構造化クエリ言語（ＳＱＬ）データベース管理システムを含んでもよい。データエンティティを列で格納する前記少なくとも１つの他のデータストレージシステムは、ＮｏＳＱＬデータベース管理システムを含んでもよい。
【０００６】
なおも別の構成では、前記方法は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能データフォーマットで受信する工程を更に有してもよい。前記方法は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能マークアップ言語（ＸＭＬ）で受信する工程を更に有してもよい。前記方法は、前記データエンティティモデルの前記定義と前記仕様とをＪａｖａスクリプトオブジェクト表記法（ＪＳＯＮ）で受信する工程を付加的に有してもよい。前記方法は、前記データエンティティモデルの前記定義と前記仕様とを少なくとも１つのパース可能オブジェクトに変形する工程を付加的に有してもよい。前記方法は、前記複数のデータストレージシステムのそれぞれについて前記データベーススキーマを生成するために前記少なくとも１つのパース可能オブジェクトをパースする工程を更に有してもよい。
【０００７】
さらになおも別の構成では、前記方法は、前記データストレージシステムで前記データアクセス動作を実行した結果と、前記データエンティティモデルに関連した表示レイアウトを指定する命令を受信する工程とを更に有してもよい。これに応答して、前記方法は、前記データエンティティモデルの少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする工程を更に有してもよい。これに応答して、前記方法は、報告ツールとのインタフェースを構成する工程と、前記インタフェースを介して、前記データアクセス動作を実行した結果を前記報告ツールへ送信する工程と、前記少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする工程とを更に有してもよい。
【０００８】
別の側面では、一部の実施形態は、多数のデータストレージシステムとやり取りできるサーバであって、動作群を実行するように構成された少なくとも１つのプロセッサを備え、前記動作群は、コンポーネント要素を含むデータエンティティモデルの定義を受信する動作と、前記定義されたデータエンティティモデルの前記コンポーネント要素のうちの少なくとも１つを、複数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関連付ける仕様を受信する動作と、前記受信した仕様に基づいて、前記データエンティティモデルの前記受信した定義を、前記データエンティティモデルを前記複数のデータストレージシステムに格納された前記データにリンクするデータベーススキーマに変換する動作と、前記複数のデータストレージシステムのうちの１つに格納されたデータの一部へアクセスするリクエストを受信する動作と、前記リクエストを受信したことに応じるとともに前記変換されたスキーマに基づいて、前記リクエストを、前記データストレージシステムに固有のデータアクセス動作に構成する動作とを有することを特徴とするサーバを含んでもよい。
【０００９】
実施形態は、以下の特徴のうちの1つ以上を含んでもよい。１つの構成では、前記動作群は、前記データストレージシステムに固有の前記データアクセス動作が当該データストレージシステムで実行されるようにする動作を更に有してもよい。前記データの一部へアクセスするリクエストを受信する動作は、前記少なくとも１つのデータエンティティの一部にアクセスするデータアクセスリクエストを受信することを含んでもよく、前記データアクセスリクエストは前記データストレージシステムに固有でない統一フォーマットで指定されてもよい。前記動作群は、前記データアクセス動作を前記データストレージシステムで実行した結果を受信する動作を更に有してもよい。
【００１０】
別の構成では、前記データエンティティモデルの定義を受信する動作は、前記データエンティティモデルに記述された少なくとも１つのコンポーネント要素についての有効性定義を受信することを含んでもよい。前記動作群は、前記有効性定義に従ってアクセスされる前記少なくとも１つのデータエンティティの前記一部を検証する動作を更に有してもよい。
【００１１】
さらに別の構成では、前記データエンティティモデルの前記受信した定義を変換する動作は、前記データエンティティモデルの前記受信した定義を、データエンティティを行で格納する少なくとも１つのデータストレージシステムと、データエンティティを列で格納する少なくとも１つの他のデータストレージシステムとについてのデータベーススキーマに変換することを含む。データエンティティを行で格納する前記少なくとも１つのデータストレージシステムは、構造化クエリ言語（ＳＱＬ）データベース管理システムを含んでもよい。データエンティティを列で格納する前記少なくとも１つの他のデータストレージシステムは、ＮｏＳＱＬデータベース管理システムを含んでもよい。
【００１２】
なおも別の構成では、前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能データフォーマットで受信する動作を更に有してもよい。前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを拡張可能マークアップ言語（ＸＭＬ）で受信する動作を更に有してもよい。前記動作群は、前記データエンティティモデルの前記定義と前記仕様とをＪａｖａスクリプトオブジェクト表記法（ＪＳＯＮ）で受信する動作を付加的に更に有してもよい。前記動作群は、前記データエンティティモデルの前記定義と前記仕様とを少なくとも１つのパース可能オブジェクトに変形する動作を付加的に有してもよい。前記動作群は、前記複数のデータストレージシステムのそれぞれについて前記データベーススキーマを生成するために前記少なくとも１つのパース可能オブジェクトをパースする動作を更に有してもよい。
【００１３】
なおもさらに別の構成では、前記動作群は、前記データストレージシステムで前記データアクセス動作を実行した結果と、前記データエンティティモデルに関連した表示レイアウトを指定する命令を受信する動作とを更に有してもよい。これに応答して、前記動作群は、前記データエンティティモデルの少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする動作を更に有してもよい。これに応答して、前記動作群は、報告ツールとのインタフェースを構成する動作と、前記インタフェースを介して、前記データアクセス動作を実行した結果を前記報告ツールへ送信する動作と、前記少なくとも１つのコンポーネント要素が前記指定された表示レイアウトに従って表示されるようにする動作とを更に有してもよい。
【００１４】
上記の技術の実施形態は、方法、コンピュータプログラム製品及びシステムを含む。コンピュータプログラム製品は、永続性機械可読媒体に適切に組み込まれ、１つ以上のプロセッサによって実行可能な命令を含む。命令は、1つ以上のプロセッサに、上述の動作を実行させるように構成される。
【００１５】
システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行可能な永続的機械可読媒体に組み込まれた命令とを含む。命令は、実行された場合に、上述の動作を１つ以上のプロセッサに実行させるように構成される。デフォルトの位置は外部データベースを用いることではなく、システムは必要ならばデータベースチェックを実行するように構成されうる。
【００１６】
本明細書に記載された主題の１つ以上の側面の詳細は添付の図面及び以下の詳細な説明で説明される。主題の他の特徴、側面及び利点は詳細な説明、図面及び特許請求の範囲から明らかになるだろう。
【図面の簡単な説明】
【００１７】
【図１】一部の実施形態に従う多数のデータストレージシステムに結合されたウェブサーバを示す図である。
【００１８】
【図２Ａ】一部の実施形態に従うデータアクセスリクエストをハンドリングする例示のワークフローを示す図である。
【００１９】
【図２Ｂ】一部の実施形態に従うシステム管理者がデータモデルを構成するための例示のユーザインタフェースを示すスクリーンショットである。
【００２０】
【図３】一部の実施形態に従う例示のデータストレージ構成を説明する図である。
【００２１】
【図４】一部の実施形態に従うデータアクセスリクエストを処理するフローチャートを示す図である。
【００２２】
【図５Ａ】一部の実施形態に従う表示出力を構成するフローチャートを示す図である。
【００２３】
【図５Ｂ】一部の実施形態に従う表示結果を生成するフローチャートを示す図である。
【発明を実施するための形態】
【００２４】
本開示は一般に、ソフトウェア設計者と、多様な検索技術を有する多数のヘテロジニアスなデータストレージシステムとの間のインタフェースを記載する。本明細書に開示される実施形態は、動的データモデルとストレージ構成フレームワークとを組み込み、これらを通じてシステム管理者は、サーバ上で、モデリングされるデータエンティティと、各データエンティティの関連属性と、これらのデータエンティティの関係とだけでなく、表示レイアウト及びデザインを指定できる。フレームワークにより、アプリケーションソフトウェア開発者は、汎用定義言語を用いて、複数の基底（underlying）ストレージ技術に格納されたデータにアクセスするためのアプリケーションコードを記述することが可能になる。これらのフレームワークを用いて、アプリケーションソフトウェアプログラマは、基底ストレージ技術の詳細を知る必要がなくてもよい。アプリケーションソフトウェアプログラマは基底ストレージ技術又は検索技術の詳細ではなくアプリケーションのデータモデルに集中できるので、本明細書に開示される実施形態に基づいて、アプリケーションプログラムコードは多数の基底データストレージ技術とシームレスにやり取りできる。さらに、実施形態は、新たな又は未開発のストレージ技術に適応するためのアダプタを組み込みうる。よって、本明細書に開示される実施形態は拡張可能でありうる。
【００２５】
ヘルスケアデータベースは、患者のケア、投薬、研究及び教育を含む、ヘルスケアにおける中心的な役割を果たしてもよい。ヘルスケアデータは総括的に、例えばかかりつけ医、病院、クリニック、薬局などを含む多数の機関によって生成された患者のヘルスケアレコードを指してもよい。これらの機関は、国中に又は世界中にさえも広がっていてもよい。このようなヘルスケアデータはますます一層電子的になってきている。例として、画像保管通信システム（ＰＡＣＳ：picture archiving and communication system）は、病院の放射線科又は心臓科で取得された患者の画像データを管理してもよい。一般に、診断テスト結果、治療薬の摂取履歴、手術履歴、又は家族履歴及び遺伝性素因でさえもすべて、患者のヘルスケアデータの一部になりうる。電子形式のこのようなヘルスケアデータは、患者及び治療する医師に、関連するヘルスケアデータへの容易なアクセスを提供してもよい。別の例として、保険取引が電子的に実施されてもよい。実際に、迅速なサービス及び容易なアクセスを提供するために、多くの保険会社が保険金請求を電子的に処理し、ファンドを電子的に支払うようになってきている。
【００２６】
サービス品質を提供するために、ヘルスケアデータベースは、様々な機関及び技術の境界を越えて機能することが期待される。これらの電子データベースは、国内のいたるところ又は国をまたいだ様々な機関によってホスティングされうる。これらの電子データベースは、多様なデータストレージシステムを利用しうる。ヘルスケアデータベースで用いられるデータストレージ技術の例は、ＳＱＬ（構造化クエリ言語）データサーバ、非ＳＱＬデータサーバ、ネットワーク・アッタッチト・ストレージ（ＮＡＳ）サーバ、ダイレクト・アタッチト・ストレージ（ＤＡＳ）デバイス、ストレージ・エリア・ネットワーク（ＳＡＮ）ストレージなどを含みうるが、これらに限定されない。例示のデータストレージ技術はまた、サードパーティによって管理される仮想化されたストレージプールに電子ヘルスケアデータが格納されうるクラウドストレージを含みうる。
【００２７】
この文脈で、電子形式のヘルスケアデータは、大容量ストレージデバイスの速度及び容量に関するハードウェア面での向上だけでなく、プロセッサ及びネットワーク速度の同様の進歩によって促進されて、サイズが大きくなってきている。ヘルスケアデータベースは、多様なストレージ技術を有する別々のデータベースサーバのクラスタをまたがる大きなテーブルに分割されうる。例えば、高速ローカルエリアネットワーク及びファイバチャネル技術で結合されたネットワーク・アタッチト・ストレージ（ＮＡＳ）及びストレージ・エリア・ネットワーク（ＳＡＮ）は、更に大きく、疎結合されたデータベース及び分散計算能力の構成を可能にする。分散データベースストレージの例示の実施形態は、Ｘ／Ｏｐｅｎ  ＸＡ標準及びオラクルＲＡＣリライを含んでもよく、これらの両方はデータストレージサーバ間の高速ネットワーク接続を採用する。データストレージ技術を記載する文脈で、サーバと、システムと、デバイスとは置換可能に用いられうる。
【００２８】
図１は、一部の実施形態に従って多数のデータストレージシステム１０８〜１０２に結合されたサーバ１０２を示す図である。サーバ１０２は、本明細書の記載に整合する任意のコンピュータ又はコンピューティング装置でありうる。サーバ１０２は、データアクセスリクエスト１０４、１０６をハンドリングように構成されうる。データアクセスリクエスト１０４、１０６は、患者、かかりつけ医、処置医、理学療法士又は保険提供者によって投入されうる。データアクセスリクエスト１０４、１０６は、データストレージシステム１０８〜１１２によって実施されるような、多数のストレージ技術にまたがって格納されたデータにアクセスすることを試みてもよい。
【００２９】
上記で概説された多数のストレージ技術とやり取りする１つのソリューションは、サーバ１０２で動作するデータベースアプリケーションプログラムに条件付きロジックの大きなブロックを記述することであろう。制御ブロックによって、アプリケーションプログラムは、特定の基底データストレージ技術に整合する方法で、多数の基底データストレージ技術のそれぞれとやり取りすることが可能になりうる。このアプローチは、特定の基底データストレージ技術のそれぞれとのインタフェースを扱うための「ハードワイヤリング」アプローチを表す。一般に、各基底データストレージ技術に固有のデータ構造の明示的な知識が必要となりうる。このような知識の必要性は、特定の基底データストレージ技術の単独のインタフェースの実装においてさえも撤回されないかもしれない。従って、このソリューションを実施するために、基底データストレージ技術に固有のオブジェクト及びオブジェクト関係を記述するデータ構造は、サーバ１０２で動作するデータベースアプリケーションプログラムにハードワイヤリングされる。結果として、このようなソリューションは、データ構造の複雑な仕様を必要とするかもしれず、バグの発生頻度の増加及び保守の適合性の低下を伴う脆弱な実装につながる。
【００３０】
オブジェクトリレーショナルモデリング（ＯＲＭ）技術は、オブジェクト指向プログラミング言語で他の方法では互換性のないタイプのシステム間でデータを変換してもよい。変換は、実質的に、プログラミング言語内から使用されうる「仮想オブジェクトデータベース」を作成する。この文脈で、オブジェクト指向（ＯＯ）プログラミングのデータ管理タスクは典型的に、ほとんど常に非スカラー値であるオブジェクトを操作することによって実装される。例として、住所、自宅の電話番号、かかりつけ医の名前及び保険ポリシー情報のエントリを有する患者のアドレス帳は、１つのオブジェクトとして実装されてもよい。実装されたオブジェクトは、各データエントリ項目を保持するための属性／フィールドを含む。実装されたオブジェクトはまた、例えば電話番号を検索したり、保険ポリシー番号を更新したりなどするような、データエントリ項目にアクセスするための様々なメソッドを含んでもよい。しかし、構造化クエリ言語（ＳＱＬ）のデータベース管理システム（ＤＢＭＳ）のような多くの人気のあるデータベース製品は、テーブル内に編成された整数及び文字列のようなスカラー値を格納・操作できるだけである。ＯＲＭ技術はオブジェクト値を、データベースに格納するための単純な値のグループに変換する（、そして検索の際にこれらを変換して戻す）ことを試みる。
【００３１】
ＯＲＭ技術を用いる商用パッケージ及びオープンソースパッケージが利用可能である。例えば、ＮｉｂｅｒｎａｔｅやＮＮｉｂｅｒｎａｔｅのようなパッケージは、オブジェクトリレーショナルマッピングを実行できる。しかし、これらの既存のパッケージは、ソフトウェアアプリケーションプログラムと対象のＤＢＭＳとの間のレイヤでの変換に対処できるだけである。高位のレベル、すなわちアプリケーションレベルでこの問題に対処するのは難しいかもしれない。さらに、ＮｉｂｅｒｎａｔｅやＮＮｉｂｅｒｎａｔｅのような既存のソフトウェアパッケージは、新たなＮｏＳＱＬ技術とやり取りすることができない。
【００３２】
この文脈で、ＮｏＳＱＬデータベースは、従来の関係データベースではなく、緩い一貫性モデルを用いる、データの記憶及び検索のための仕組みを提供する。このＮｏＳＱＬアプローチへの動機は、設計の単純化、水平スケーリング、及び可用性に関する細かな制御を含む。ＮｏＳＱＬデータベースはしばしば、単純な検索・付加動作に最適化されたキー‐値ストアを含み、その結果としてレイテンシ及びスループットの観点で著しい性能上の利点が得られうる。ＮｏＳＱＬデータベースは、ビッグデータ及びリアルタイムウェブアプリケーションにおける著しく成長している産業の用途で見られる。ＳＱＬのような従来のトランザクション式データベースシステムと比べて、ＮｏＳＱＬデータベースは必ずしも完全な原子性、一貫性、独立性及び耐久性（ＡＣＩＤ）の保証を与えられるわけではない。その代わりに、ＮｏＳＱＬデータベースの実装は通常、最終的な一貫性を与えるだけでありうるか、ＮｏＳＱＬデータベースの実装は、トランザクションを単一のデータ項目に制限しうる。この対照的な特徴は、十分に長い期間に追加の変更がないことが保証されることを前提として、最終的に全ての更新がシステムを通じて伝播することが期待されうる。ＮｏＳＱＬシステムの実装のほとんどは、単一文書上のトランザクションをハンドリングできるが、ｅＸｔｒｅｍｅ  Ｓｃａｌｅ、ＦｏｕｎｄａｔｉｏｎＤＢ，ＯｒｉｅｎｔＤＢ、ＷａｋａｎｄａＤＢ及びｄｊｏｎｄｂのような一部のＮｏＳＱＬシステムは、ＲＤＢＭＳシステムが複数行でトランザクションをサポートするのと同様に、複数の文書上でトランザクションを実行してもよい。ＮｏＳＱＬデータベースは典型的に、水平に拡張し、これは多くの低コストコモディティシステムが、データクエリへ高速に応答する能力を含む、集約された計算能力を向上できることを意味する。結果として、ＮｏＳＱＬデータベースはしばしば、性能及びリアルタイム性が一貫性よりも重要な場合に（多数の文書のインデックス付け、高トラフィックなウェブサイトのページのサービス提供、及びストリーミングメディアの配信のような場合に）、大量のデータを管理しうる。
【００３３】
データストレージソリューションの提供において、一部の会社及び調査者は、リレーショナルデータベース管理システムの制限を議論するかもしれない。例えば、ＧｉｇａＳｐａｃｅｓのような一部のベンダーは、最高の性能及び拡張性を実現するために、主流のリレーショナルデータベースモデルとは異なるスペースベースのアーキテクチャを支持するかもしれない。ＢａｓｅＯｎｅのようなその他のものは、拡張性をさらに向上するために主流のリレーショナルデータベース技術を信じる。さらに、グーグルのビッグテーブルのようなＮｏＳＱＬアーキテクチャは、特定用途に対して拡張性を更に向上することを実証してきた。さらなる発展として、ビッグテーブルの後継として位置付けられるグーグルの大規模分散スパナー技術は、汎用データベーストランザクションをサポートし、多くの従来のＳＱＬベースのクエリ言語を提供する。よって、様々な、時として偏った実装思想で様々なベンダーから多種多様なデータストレージ技術が利用可能である。
【００３４】
大量のヘテロジニアスなデータセットの管理において、ソフトウェア産業は、例えばＳＱＬストレージシステム及びＮｏＳＱＬストレージシステムを含む多種多様なデータストレージソリューションとやり取りすることの問題に対処することに懸命に取り組んでいる。すなわち、ソフトウェア設計者が多様な基底データストレージシステムに格納されたデータにアクセスするためのアプリケーションレイヤにおける統一したインタフェースを提供することは困難である。
【００３５】
アプリケーションレイヤにおいて複数のストレージ技術をサポートすることは困難でありうるが、このような統一インタフェースは、アプリケーションソフトウェアプログラマがコードを効率的に開発することを可能にする。
【００３６】
第一に、アプリケーションプログラムコードは、基底ストレージシステムの特異性によって影響を受けないように特定のアプリケーションプログラムで用いられるデータモデルを変更又は更新してもよい。そのかわりに、基底ストレージシステムは、変更されたデータモデルに従って動作してもよい。よって、アプリケーションコードは、基底データストレージの実装に関して保守可能及び柔軟でありうる。
【００３７】
第二に、アプリケーションソフトウェアプログラマは、アプリケーションプログラムによって参照されるデータをホスティングする特定の各データストレージシステムに対する固有のアプリケーションコードを記述する必要はない。言い換えると、ソフトウェアプログラマは、基底ストレージ技術がどのように実装されたかに関する詳細な知識の負担から解放されうる。よって、アプリケーションソフトウェアプログラマは保守可能なコードの記述に注力でき、それによって、ビッグデータアプリケーションのためのソフトウェアプログラムを実装及び変更する開発時間を低減できる。
【００３８】
図２は、一部の実施形態に従う動的データモデル及びストレージ構成の例示のアーキテクチャを示す図である。構成データ１は総括的に、オブジェクトリレーショナルモデルにおけるエンティティ及びこれらの関係を構成することを意図されたデータを指す。一部の実施形態では、構成データ１の汎用ブロックは、とりわけ、エンティティ構造２、エンティティ関係３、エンティティ表示ガイド４、及びエンティティ振る舞い５を表してもよい。一部の実施形態では、構成データ１を表すために拡張可能マークアップ言語（ＸＭＬ）が選ばれてもよい。他の実施形態では、表現スキーマのためにＪＳＯＮのような他の拡張可能プログラム言語が用いられてもよい。
【００３９】
エンティティ構造２は総括的に、オブジェクトリレーショナルモデルにおけるエンティティのレイアウトを指定する構成情報を指してもよく、構成属性と、各属性に対する適用可能な属性データタイプとを含む。構成属性と、対応する適用可能な属性データタイプとは総括的にコンポーネント要素と呼ばれてもよい。
【００４０】
以下のＸＭＬコードの抜粋は、エンティティ構造２の例示のＲｅｌａｘＮＧコンパクト（ＲＮＣ）スキーマ定義を示す。
entitymodel =
element entitymodel {
entitymodelcontent
}
entitymodelcontent =
attribute id { xsd:NMTOKEN },
attribute table { text }?,
attribute scope { "public" | "private" },
( (field | fieldref)* & indexes? & relations? )
field =
element field {
attribute id { xsd:NMTOKEN },
attribute name { text }?,
attribute type { "string" | "double" | "int" | "uint" | "bool" | "datetime" | "date" | "currency" | "enum" | "long" | "ulong" | "entityName" },
attribute column { text }?,
(attribute primarykey { "true" | "false" } | attribute not-null { "true" | "false" })?,
# デフォルトは "sequence"
attribute keygen { "sequence" | "assigned" | "native" }?,
attribute length { xsd:unsignedInt }?,
attribute db-type { text }?,
attribute default { text }?,
attribute indexed { "true" | "false" }?,
attribute values { text }?,
element description { text }?  }
fieldref =
element fieldref {
attribute id { xsd:NMTOKEN }
}
# 関係は以下で定義されるエンティティ結合のオプションの上書きとして用いられる
# アカウントごとのまさしく明示の上書き状況が必要な場合
relations =
element relations {
anyrelation*
}
indexes =
element indexes {
index*
}
index =
element index {
attribute id { xsd:NMTOKEN },
attribute fields { text },
attribute constraint { "none" | "unique" }?
}
anyrelation =
element rel:* {
attribute * { text }*,
anyrelation*
}
【００４１】
エンティティ関係３は、キーの観点で複数のエンティティが互いにどのように関係しているか及び関係濃度（relationship cardinality）（例えば、１：１、１：ｍ、ｍ：ｍ）を指定する構成情報を指してもよい。この文脈で、別のデータテーブルに関する１つのデータテーブルの濃度は、データテーブル間の関係に対応し、すなわち各テーブルがどのように別のテーブルにリンクするかを説明する。リレーショナルデータベースモデルでは、テーブルは、多対多と、１対多と、１対１とのうちの何れかとして関係しうる。このマッピングは、所与のテーブルの、別のテーブルに関する濃度とであるといえる。例えば、病院レコードを管理するように設計されたデータベースを検討する。このようなデータベースは、医師の情報に満ちた医師テーブルと、患者情報を有する患者テーブルと、病院の各診療科に対するエントリを有する診療科テーブルとのような多くのテーブルを有しうる。この仮説モデルでは、医師テーブルのレコードと患者テーブルのレコードとの間に多対多の関係が存在し（医師は多くの患者を有し、患者は何人かの医師を有しうる）、診療科テーブルと医師テーブルとの間に１対多の関係が存在する（各医師は１つの診療科で働くが、１つの診療科は多くの医師を有しうる）。この仮想モデルでは、例えば、医師の個人情報と管理情報とを分けるために医師テーブルが２つに分離されるならば、１対１の関係が存在しうる。データモデリングにおいて、データ要素のコレクションはデータテーブルにグループ分けされる。データテーブルは、（データベース属性としても知られる）データフィールド名のグループを含む。データテーブルは、キーフィールドによってリンクされる。プライマリキーは当該フィールドの特別な順序をテーブルに割り当てる。この仮想モードでは、医師テーブルに対するプライマリキーは、医師ＩＤの属性でありうる。テーブルはまた、当該フィールドが別のテーブルのプライマリキーにリンクされていることを示す外部キーを有しうる。複雑なデータモデルは、数百の関連するテーブルを伴い、これらは様々な機関及び様々なストレージシステムにわたって格納されうる。
【００４２】
以下のＸＭＬコードの抜粋は、エンティティ関係３の例示のＲｅｌａｘＮＧコンパクト（ＲＮＣ）スキーマ定義を示す。
entityjoins =
element entityjoins {
attribute id { xsd:NMTOKEN },
join*,
joincontext*,
joindefault?
}
join =
element join {
attribute to { text },
(attribute via { text } |
(attribute property { text }?,
attribute alias { text }?))?,
joincondition*
}
joincondition =
(element eq {
attribute property { text },
attribute value { text },
attribute type { text },
empty
})*
joincontext =
element context {
attribute name { text },
join*
}
joindefault =
element default {
attribute via { text }
}
【００４３】
エンティティ表示ガイド４は、人間可視化及び検査のためのユーザインタフェースにエンティティがどのように表示されるべきかを指定する構成情報を指してもよい。エンティティ表示ガイド４は、ユーザインタフェース（ＵＩ）要素であってもよい。表現の多数の変形が存在する。ＵＩ表現は、制御のための命令を提供してもよいが、実際のパイパーテキストマークアップ言語（ＨＴＭＬ）レンダリングコードを提供しなくてもよい。以下は、エンティティ表示ガイド４の例示の定義である。
dataform =
element dataform {
(attribute id { xsd:NMTOKEN }
& attribute editable { "true" | "false" }
& dataform.attlist),
dataformitem*,
actions?
}
dataformitem =
## input fields
element field {
attribute id { xsd:NMTOKEN },
attribute type { "text" | "textarea" | "checkbox" | "date" | "dropdown" | "password" }?,
attribute required { "true" | "false" }?,
attribute readonly { "true" | "false" }?,
attribute helptext { text }?,
attribute style { text }?,
## type=checkbox
attribute iconify { "true" | "false" }?,
attribute truestring { text }?,
attribute falsestring { text }?,
attribute trueiconurl { text }?,
attribute falseiconurl { text }?,
## type=text|textarea|password
attribute maxlength { xsd:unsignedInt }?,
attribute columns { xsd:unsignedInt }?,
## type=textarea
attribute rows { xsd:unsignedInt }?, 
## type=dropdown
attribute constrain { "true" | "false" }?,
attribute optionsnamedprojection { text }?,
attribute optionsstringid { text }?,
staticdatafieldoptions?,
element validators {
element validator {
attribute id { xsd:NMTOKEN }+
}
}?
} |
## non-input (display) fields
element empty { empty } |
element separator { empty } |
element search {
attribute id { xsd:NMTOKEN },
attribute label { text },
attribute lazy { "true" | "false" }?,
attribute helptext { text }?
}
【００４４】
上記のコーディング例に従って追加の構成データの要素タイプが実装されてもよい。これらの追加の要素タイプは、列形式（例えば２〜４列）でエンティティをモデリングするデータフォームと、エンティティが検索インタフェースに現れるものとしてエンティティをモデリングするサーチと、エンティティがリストフォーマットに現れるものとしてエンティティをモデリングするリストと、計算されたメトリックを有する報告ビューにエンティティをモデリングするダッシュボードと、外部の報告／可視化ツール（例えば、Ｔａｂｌｅａｕ、ＭｉｃｒｏＳｔｒａｔｅｇｙなど）に現れるものとしてエンティティをモデリングするバブリッシュド・ビューとを含んでもよい。
【００４５】
エンティティ振る舞い５は、エンティティタイプのレコードが作成され、更新され、検証され、削除された場合に所与のエンティティがどのように振舞うべきかだけでなく、エンティティの変更で何の後続の動作が行われるべきかを指定する構成情報を指してもよい。例えば、エンティティ振る舞い５は、検証ルール（例えば、通貨フィールドはアメリカでは‘＄’文字を有するべきである）を含んでもよい。以下のコーディングの抜粋は、エンティティ振る舞い５の例示の実施形態として正規化ルールのＲｅｌａｘＮＧコンパクト（ＲＮＣ）定義を含む。
normalizationrules =
element normalizationrules {
attribute id { text },
attribute enabled { "true" | "false" }?,
(staticnormalizerule | regexnormalizerule | element uppercase { empty } | element titlecase { empty } | element lowercase { empty })*
}*
mailingaddress =
element mailingaddress {
attribute id { text },
attribute enabled { "true" | "false" }?,
element address { text }?,
element secondary { text }?,
element city { text }?,
element state { text }?,
element zip { text }?
}
staticnormalizerule =
element static {
attribute match { text },
attribute replace { text },
attribute ignorecase { "true" | "false" }?,
empty
}
regexnormalizerule =
element regex {
attribute pattern { text },
attribute options { text }?,
attribute replace { text },
empty
}
【００４６】
さらに別の説明で、以下のコードの抜粋は、上記で概説された構成スキーマに従って定義された、「規約」エンティティのための例示の構成データ１を示す。「規約」エンティティは付加的に、例えば冗長なエントリを排除するための正規化セクションを含む。
＜!-- core entity model definition example(i.e. 2) --＞
＜entitymodel id="Contact" table="contacts" scope="public"＞
＜field id="Id" type="uint" column="contactId" primarykey="true" /＞
＜field id="AccountId" type="uint" column="accountId" /＞
＜field id="AsSalesRepId" type="uint" column="salesRepId" not-null="true" default="0"/＞
＜field id="ContactType" type="string" column="contactType" values="Contact,Lead,SalesRep" default="Contact" /＞
＜field id="ExternalContactId" type="string" length="200" column="extContactId" indexed="true" /＞
＜field id="Salutation" type="string" length="50" column="salutation" /＞
＜field id="Designation" type="string" length="50" column="designation" /＞
＜fieldref id="FirstName" /＞
＜fieldref id="MiddleName" /＞
＜fieldref id="LastName" /＞
＜field id="GenerationalSuffix" type="string" length="100" column="generationalSuffix" /＞
＜fieldref id="Created" /＞
＜fieldref id="Updated" /＞
＜fieldref id="Email" /＞
＜fieldref id="Phone" /＞
＜fieldref id="MobilePhone" /＞
＜fieldref id="Fax" /＞
＜fieldref id="Address1" /＞
＜fieldref id="Address2" /＞
＜fieldref id="City" /＞
＜fieldref id="State" /＞
＜fieldref id="Zip" /＞
＜fieldref id="Country" /＞
＜field id="ExternalAddressId" type="string" column="extAddressId" length="30" /＞
＜field id="Title" type="string" length="250" column="title" /＞
＜field id="Company" type="string" length="150" column="company" /＞
＜fieldref id="EmailVerified" /＞      ＜fieldref id="SalesOwner" /＞
＜fieldref id="SalesTeam" /＞
＜field id="LeadSource" type="string" length="200" column="leadSource"＞
＜description＞This is where the contact's data came from.＜/description＞
＜/field＞
＜field id="LeadStatus" type="string" column="leadStatus" values="Unqualified,Qualified,Trash" default="Unqualified" /＞
＜fieldref id="Notes" /＞
＜field id="BirthDate" type="datetime" column="birthdate" /＞
＜field id="Department" type="string" length="200" column="department" /＞
＜field id="Division" type="string" length="200" column="division" /＞
＜fieldref id="CreatedBy" /＞
＜fieldref id="ModifiedBy" /＞
＜fieldref id="TimeZone" /＞
＜fieldref id="WebAddress" /＞
＜fieldref id="WebSource" /＞
＜fieldref id="WebReferrer" /＞
＜field id="Role" type="string" length="200" column="role" /＞
＜field id="ExtSourceSystem" type="string" length="100" column="extSourceSystem" /＞
＜field id="PrimaryDevice" type="string" length="100" column="primaryDevice" /＞
＜field id="PrimaryDeviceDate" type="datetime" column="primaryDeviceDate" /＞
＜field id="NpiId" type="uint" column="npiId" not-null="false" /＞
＜fieldref id="EmailOptIn" /＞
＜fieldref id="EmailOkUpdated" /＞
＜fieldref id="MailOptIn" /＞
＜fieldref id="MailOkUpdated" /＞
＜fieldref id="CallOptIn" /＞
＜fieldref id="CallOkUpdated" /＞
＜fieldref id="FaxOptIn" /＞
＜fieldref id="FaxOkUpdated" /＞
＜fieldref id="SmsOptIn" /＞
＜fieldref id="SmsOkUpdated" /＞
＜field id="WebsiteVisitorId" type="ulong" column="websiteVisitorId" /＞
＜indexes＞
＜index id="ix_excontactId" fields="ExternalContactId" constraint="unique" /＞
＜/indexes＞
＜/entitymodel＞
＜!-- relationships between the "Contact" and other entities (i.e. (3)) --＞
＜entityjoins id="Contact"＞
＜!-- entityjoins are intelligently compiled so that you only need to define new overriding joins that differ from the default for each individual account --＞
＜join to="Account" /＞
＜join to="OpportunityContact" property="OpportunityContacts" alias="OpportunityContact" /＞
＜join to="Opportunity" via="OpportunityContact" /＞
＜join to="Activity" property="Activities" alias="Activity" /＞
＜join to="ContactFacility" property="ContactFacilities" alias="ContactFacility" /＞
＜join to="Facility" via="ContactFacility" /＞
＜join to="ContactTerritory" property="ContactTerritories" alias="ContactTerritory" /＞
＜join to="Territory" via="ContactTerritory" /＞
＜join to="SalesRepTerritory" via="Territory" /＞
＜join to="SalesRep" via="SalesRepTerritory" /＞
＜join to="NpiIndividual" /＞
＜join to="ExternalContactIdMapping" property="ExternalIds" alias="ExternalContactIdMapping" /＞
＜join to="Topic" via="OptIn" /＞
＜join to="OptIn" property="OptIns" alias="OptIn" /＞
＜join to="OptInActivity" property="OptInActivities" alias="OptInActivity" /＞
＜join to="DeduplicationRecord" property="DeduplicationRecords" alias="DeduplicationRecord" /＞
＜join to="DeduplicationRun" via="DeduplicationRecord" /＞
＜join to="MailingTarget2" property="MailingTargets" alias="MailingTarget2" /＞
＜join to="Mailing" via="MailingTarget2" /＞
＜join to="AnalyticsIdMapping" property="AnalyticsIds" alias="AnalyticsIdMapping" /＞
＜join to="AnalyticsSite" via="AnalyticsIdMapping" /＞
＜join to="AnalyticsVisit" via="AnalyticsIdMapping" /＞
＜join to="AnalyticsReferrer" via="AnalyticsIdMapping" /＞
＜join to="AnalyticsKeyword" via="AnalyticsIdMapping" /＞
＜join to="AnalyticsPath" via="AnalyticsIdMapping" /＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" /＞
＜join to="CampaignElement" via="ContactResponse" /＞
＜join to="Campaign" via="CampaignElement" /＞
＜join to="CampaignWave" via="ContactResponse" /＞
＜join to="SurveyResponse" property="SurveyQuestionResponses" alias="SurveyResponse"/＞
＜join to="SurveyTaker" via="SurveyResponse"/＞
＜join to="SurveyCompletion" via="SurveyResponse"/＞
＜join to="Survey" via="ContactResponse" /＞
＜join to="Email" via="MailingTarget2" /＞
＜join to="EmailClickThrough" via="MailingTarget2" /＞
＜join to="EmailLink" via="MailingTarget2" /＞
＜join to="EmailTest" via="Email" /＞
＜join to="EmailTestSpamResult" via="EmailTest" /＞
＜join to="EmailTestPreviewResult" via="EmailTest" /＞
＜join to="SmsTarget" property="SmsTargets" alias="SmsTarget" /＞
＜join to="SmsToken" via="SmsTarget" /＞
＜join to="SmsLink" via="SmsToken" /＞
＜join to="Sms" via="SmsTarget" /＞
＜join to="SmsDelivery" via="SmsTarget" /＞
＜join to="Traveler" property="Travelers" alias="Traveler" /＞
＜join to="TravelerHistory" via="Traveler" /＞
＜join to="JourneyNodeData" via="Traveler" /＞
＜join to="Journey" via="JourneyNodeData" /＞
＜!-- temporary default to enable suppression search in ui.-＞
＜join to="Blacklisting" property="EmailBlacklist"＞
＜eq property="Channel" value="1" type="Appature.Common.Types.CommunicationChannel, common" /＞
＜/join＞
＜context name="EmailBlacklisting"＞
＜join to="Blacklisting" property="EmailBlacklist" /＞
＜/context＞
＜context name="FaxBlacklisting"＞
＜join to="Blacklisting" property="FaxBlacklist" /＞
＜/context＞
＜context name="CallBlacklisting"＞
＜join to="Blacklisting" property="CallBlacklist" /＞
＜/context＞
＜context name="AnsweredQuestion"＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="6" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Email" via="ContactResponse" /＞
＜join to="Sms" via="ContactResponse" /＞
＜join to="Survey" via="SurveyQuestion" /＞
＜join to="SurveyQuestion" via="SurveyResponse" /＞
＜join to="SurveyResponse" property="SurveyQuestionResponses" alias="SurveyResponse" /＞
＜/context＞
＜context name="SmsRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs"＞
＜eq property="ParentType" value="88" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Sms" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜join to="SmsDelivery" via="Sms" /＞
＜/context＞
＜context name="EmailRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs"＞
＜eq property="ParentType" value="23" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Email" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜join to="Mailing" via="MailingTarget2" /＞
＜join to="MailingTarget2" property="MailingTargets" alias="MailingTarget2" /＞
＜join to="SentMailing" via="SentMailingTarget2" /＞
＜join to="SentMailingTarget2" property="SentMailingTargets" alias="SentMailingTarget2" /＞
＜/context＞
＜context name="ContactImportRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="ParentType" value="39" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactImport" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜/context＞
＜context name="SurveyRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="6" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Survey" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜/context＞
＜context name="CampaignElementRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="14" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="CampaignElement" via="ContactResponseLog" /＞
＜join to="Campaign" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜/context＞
＜context name="JourneyNodeDataRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="101" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="JourneyNodeData" via="ContactResponseLog" /＞
＜join to="Journey" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜/context＞
＜context name="LifeCycleActionRespondedByLog"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="20" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="LifeCycleAction" via="ContactResponseLog" /＞
＜join to="LifeCycle" via="ContactResponseLog" /＞
＜join to="ContactResponse" via="ContactResponseLog" /＞
＜join to="TargetGroup" via="ContactResponseLog" /＞
＜/context＞
＜context name="SurveyResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="6" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="6" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Survey" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="CampaignElementResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="14" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="14" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="CampaignElement" via="ContactResponse" /＞
＜join to="Campaign" via="CampaignElement" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="JourneyNodeDataResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="GrandparentType" value="101" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="101" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="JourneyNodeData" via="ContactResponse" /＞
＜join to="Journey" via="JourneyNodeData" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="CampaignWaveResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="ParentType" value="96" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="96" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="CampaignWave" via="ContactResponse" /＞
＜join to="CampaignElement" via="CampaignWave" /＞
＜join to="Campaign" via="CampaignElement" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="EmailResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs"＞
＜eq property="ParentType" value="23" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="23" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Email" via="ContactResponse" /＞
＜join to="Mailing" via="MailingTarget2" /＞
＜join to="MailingTarget2" property="MailingTargets" alias="MailingTarget2" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜join to="SentMailing" via="SentMailingTarget2" /＞
＜join to="SentMailingTarget2" property="SentMailingTargets" alias="SentMailingTarget2" /＞
＜/context＞
＜context name="EmailSent"＞
＜!-- LEGACY! See Bug #7715 and FindTestFixture.TestEmailSentTime() --＞
＜join to="SentMailingTarget2" property="SentMailingTargets" alias="SentMailingTarget2" /＞
＜join to="SentMailing" via="SentMailingTarget2" /＞
＜/context＞
＜context name="SmsResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs"＞
＜eq property="ParentType" value="88" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="88" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="Sms" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="ContactImportResponded"＞
＜join to="ContactResponseLog" property="ContactResponseLogs" ＞
＜eq property="ParentType" value="39" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" ＞
＜eq property="Type" value="39" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜join to="ContactImport" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="EmailClickedThrough"＞
＜join to="Email" via="MailingTarget2" /＞
＜join to="Survey" via="MailingTarget2" /＞
＜join to="CampaignElement" via="MailingTarget2" /＞
＜join to="MailingTarget2" property="MailingTargets" /＞
＜join to="TargetGroup" via="MailingTarget2" /＞
＜/context＞
＜context name="EmailActivityResponded"＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" /＞
＜join to="Email" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="SmsActivityResponded"＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" /＞
＜join to="Sms" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜context name="SurveyOptInEvent"＞
＜join to="Survey" via="OptInActivity" /＞
＜join to="OptInActivity" property="OptInActivities" alias="OptInActivity"＞
＜eq property="LinkedSourceType" value="6" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜/context＞
＜context name="CampaignElementOptInEvent"＞
＜join to="CampaignElement" via="OptInActivity" /＞
＜join to="OptInActivity" property="OptInActivities" alias="OptInActivity"＞
＜eq property="LinkedSourceType" value="14" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜/context＞
＜context name="EmailOptInEvent"＞
＜join to="Email" via="OptInActivity" /＞
＜join to="OptInActivity" property="OptInActivities" alias="OptInActivity"＞
＜eq property="LinkedSourceType" value="23" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜/context＞
＜context name="LifeCycleOptInEvent"＞
＜join to="LifeCycle" via="OptInActivity" /＞
＜join to="OptInActivity" property="OptInActivities" alias="OptInActivity"＞
＜eq property="LinkedSourceType" value="29" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜/context＞
＜context name="ContactDeduplicationRecord"＞
＜join to="DeduplicationRun" via="DeduplicationRecord" /＞
＜join to="DeduplicationRecord" property="DeduplicationRecords" alias="DeduplicationRecord"＞
＜eq property="ResolvedEntityIdentifier.EntityType" value="0" type="Appature.Common.Types.EntityType, common" /＞
＜/join＞
＜/context＞
＜context name="OptInTopic"＞
＜join to="ContactResponse" property="Responses" alias="ContactResponse" /＞
＜join to="Email" via="ContactResponse" /＞
＜join to="TargetGroup" via="ContactResponse" /＞
＜/context＞
＜/entityjoins＞
＜!-- defining how the entity should be displayed in a "form" format (i.e. (4)) --＞
＜dataform id="contact" editable="true"＞
＜field id="Salutation" /＞
＜field id="Designation" /＞
＜field id="FirstName" /＞
＜field id="LastName" /＞
＜separator /＞
＜field id="Created" /＞
＜field id="Updated" /＞
＜field id="SalesOwner" /＞
＜field id="LeadSource" /＞
＜field id="SalesTeam" /＞
＜field id="WebReferrer" /＞
＜field id="Division" /＞
＜field id="WebSource" /＞
＜separator /＞
＜field id="Title" /＞
＜field id="Company" /＞
＜field id="Department" /＞
＜field id="Role" /＞
＜separator /＞
＜field id="Phone" /＞
＜field id="Email" /＞
＜field id="MobilePhone" /＞
＜field id="Fax" /＞
＜field id="TimeZone" /＞
＜separator /＞
＜field id="Address1" /＞
＜field id="Address2" /＞
＜field id="City" /＞
＜field id="State" /＞
＜field id="Zip" /＞
＜field id="Country" /＞
＜field id="Notes" /＞
＜actions＞
＜action id="Delete" /＞
＜action id="Export" /＞
＜action id="Dedupe" restrictto="Super" /＞
＜/actions＞
＜/dataform＞
＜!- normalization rules defining behaviors for the "Contact" entity 
(i.e. (5) --＞
＜normalizationrules id="Contact.Email"＞
＜regex pattern="^(?:.*?)([^ ()\[\]<>]+)@([^ ()\[\]<>]+).*?$" replace="$1@$2" /＞
＜/normalizationrules＞
＜!-- reusable field concepts for any entity's model definition --＞
＜field id="Email" type="string" length="150" column="email" /＞
＜field id="EmailVerified" type="bool" column="emailVerified" /＞
＜field id="Name" type="string" length="200" column="name" /＞
＜field id="FirstName" type="string" length="100" column="firstName"＞
＜description＞The first name of the person represented by this record.＜/description＞
＜/field＞
＜field id="MiddleName" type="string" length="100" column="middleName"＞
＜description＞The middle name of the person represented by this record.＜/description＞
＜/field＞
＜field id="LastName" type="string" length="100" column="lastName"＞
＜description＞The last name of the person represented by this record.＜/description＞
＜/field＞
＜field id="Created" type="datetime" column="created" not-null="true"＞
＜description＞The date and time when this record was created in Appature Nexus.＜/description＞
＜/field＞
＜field id="Updated" type="datetime" column="updated" not-null="true"＞
＜description＞The date and time when this record was most recently updated within Appature Nexus.＜/description＞
＜/field＞
＜field id="Phone" type="string" length="30" column="phone"＞
＜description＞The primary phone number used to reach the person or business represented.＜/description＞
＜/field＞
＜field id="MobilePhone" type="string" length="30" column="mobilePhone"＞
＜description＞The mobile phone number used to reach the person or business represented.＜/description＞
＜/field＞
＜field id="Fax" type="string" length="30" column="fax"＞
＜description＞The fax number used to reach the person or business represented.＜/description＞
＜/field＞
＜field id="Address1" type="string" length="100" column="address1"＞
＜description＞The first line of the person or business's address.＜/description＞
＜/field＞
＜field id="Address2" type="string" length="100" column="address2"＞
＜description＞The second line of the person or business's address.＜/description＞
＜/field＞
＜field id="City" type="string" length="100" column="city"＞
＜description＞The city of the person or business's address.＜/description＞
＜/field＞
＜field id="State" type="string" length="100" column="state"＞
＜description＞The state of the person or business's address.＜/description＞
＜/field＞
＜field id="Zip" type="string" length="40" column="zip"＞
＜description＞The zip or postal code of the person or business's address.＜/description＞
＜/field＞
＜field id="Country" type="string" length="100" column="country"＞
＜description＞The country of the person or business's address.＜/description＞
＜/field＞
＜field id="Notes" type="string" length="5000" column="notes"＞
＜description＞Generic notes about the person or business.＜/description＞
＜/field＞
＜field id="CreatedBy" type="string" length="200" column="CreatedBy" /＞
＜field id="ModifiedBy" type="string" length="200" column="ModifiedBy" /＞
＜field id="TimeZone" type="string" length="200" column="TimeZone"＞
＜description＞The timezone the person or business is in.＜/description＞
＜/field＞
＜field id="EmailOptIn" type="bool" column="emailOk"＞
＜description＞Whether or not the recipient has opted into receiving emails.＜/description＞
＜/field＞
＜field id="EmailOkUpdated" type="datetime" column="emailOkUpdated"＞
＜description＞The most recent timestamp of when the person or business's Email opt-in status was verified.＜/description＞
＜/field＞
＜field id="MailOptIn" type="bool" column="mailOk"＞
＜description＞Whether or not the recipient has opted into receiving direct mailings.＜/description＞
＜/field＞
＜field id="MailOkUpdated" type="datetime" column="mailOkUpdated"＞
＜description＞The most recent timestamp of when the person or business's Direct Mail opt-in status was verified.＜/description＞
＜/field＞
＜field id="CallOptIn" type="bool" column="callOk"＞
＜description＞Whether or not the recipient has opted into receiving phone calls.＜/description＞
＜/field＞
＜field id="CallOkUpdated" type="datetime" column="callOkUpdated"＞
＜description＞The most recent timestamp of when the person or business's Phone Call opt-in status was verified.＜/description＞
＜/field＞
＜field id="FaxOptIn" type="bool" column="faxOk"＞
＜description＞Whether or not the recipient has opted into receiving faxes.＜/description＞
＜/field＞
＜field id="FaxOkUpdated" type="datetime" column="faxOkUpdated"＞
＜description＞The most recent timestamp of when the person or business's Fax opt-in status was verified.＜/description＞
＜/field＞
＜field id="SmsOptIn" type="bool" column="smsOk"＞
＜description＞Whether or not the recipient has opted into receiving SMS communication or text messages.＜/description＞
＜/field＞
＜field id="SmsOkUpdated" type="datetime" column="smsOkUpdated"＞
＜description＞The most recent timestamp of when the person or business's SMS opt-in status was verified.＜/description＞
＜/field＞
＜field id="SalesOwner" type="string" length="200" column="salesOwner" /＞
＜field id="SalesTeam" type="string" length="200" column="salesTeam" /＞
＜field id="WebAddress" type="string" column="webAddress" /＞
＜field id="WebSource" type="string" column="webSource" /＞
＜field id="WebReferrer" type="string" column="webReferrer" /＞
【００４７】
図２Ｂを参照して、一部の実施形態に従ってシステム管理者がデータモデルを構成するための例示のグラフィカルユーザインタフェース（ＧＵＩ）のスクリーンショットが示される。ＧＵＩは、エンティティのリストが右側パネルにモデリングされることを示す。データエンティティのリストは、上述の規約エンティティモデルを含む。ＧＵＩは、システム管理者がデータエンティティを変更することを可能にする。システム管理者は、左側パネルでデータエンティティを選んでもよく、右側パネルで、選んだデータエンティティに関連する任意のフィールドを変更してもよい。システム管理者が何れかのフィールド変更で「セーブ」ボタン（不図示）を叩くか、「新しいフィールドを追加」ボタンを叩いた場合に、本明細書に記載されるサーバは、基底ストレージ技術と自動的に通信し、必要ならばどこにあってもストレージデバイスの物理モデルを更新する。同様のやり方で、システム管理者は例示のユーザインタフェースを通じて、例えば特徴構成、認証及びアカウント情報を含むオブジェクトリレーショナルモデリングの他の側面を更新してもよい。
【００４８】
図２Ａを参照して、構成コントローラ（ＣＣ）６は、格納された構成データセットから構成データ１を読み出す。一部の実施形態では、格納されたデータセットは、ＸＭＬを用いて表されうる。他の実施形態では、格納されたデータセットはＪＳＯＮで表されてもよいし、他の任意の拡張可能データフォーマットで表されてもよい。構成コントローラ６は、未加工の（raw）構成表現をとり、未加工の構成表現を、アプリケーションレイヤの他のソフトウェアプログラムアップストリームによってパースされうるオブジェクトに変形する。
【００４９】
データモデルコントローラ（ＤＭＣ）７は、構成データ１を受け取り、構成コントローラ６を通じて読み出し、構成データ１を、関連プラグインデータが格納する特定のスキーマ定義に変換するように構成される。ＤＭＣ７は、データエンティティモデルの適用と、データエンティティモデルへの変更と、対象ストレージ・検索技術との一貫性についてのデータエンティティモデルの検証とを管理する。言い換えると、ＤＭＣ７は、構成コントローラ（ＣＣ）６とともに、特定のデータエンティティモデルを、対象データストレージシステムに固有のデータ構造管理ステートメントに変換してもよい。
【００５０】
図２Ａに説明されるように、例示の対象データストレージシステムは、ＳＱＬデータベース８と、キャッシングストレージ９と、ＮｏＳＱＬデータベースのための列ストア１０と、ＮｏＳＱＬデータベースのための列ストア１１とを含んでもよい。ＤＭＣ７は、スキーマ定義とスキーマを変更するためのメソッドとをサポートするに任意のストレージシステムに適合されうる。ＤＭＣ７に適合されうるすべてのストレージシステムの網羅的な列挙は本明細書の開示では非現実的でありえるが、ＤＭＣ７の例示の実装が以下のコーディングの抜粋に記載される。
interface IDataStoreAdapter {
public void CreateEntityType(string entityTypeId, Field[] fields);
public void RemoveEntityType(string entityTypeId);
public void ModifyEntityType(string entityTypeId, Field[] fields);
public Field[] GetEntityFields(string entitytypeId);
public Relation[] GetEntityRelations(string entityTypeId);
public IEntityBehavior[] GetEntityBehaviors(string entityTypeId);
public void StoreRecord(string entityTypeId, Field[] fields);
public Field[] LoadRecord(string entityTypeId);
public List＜Field[]＞ QueryRecords(string xmlQuery);
};
【００５１】
上記の例示のコーディングの抜粋では、フィールドオブジェクト及び関係オブジェクトは、本開示でのスペースを省略するために詳細には書き出されていない。しかし、上記のコーディング例に記載されるように、フィールド名、データタイプ及び結合パスを関連付けるようにフィールドオブジェクト及び関係オブジェクトが含まれることを当業者は容易に理解するだろう。
【００５２】
基底ストレージ技術に対するデータオブジェクトの適合において、データストアアダプタがＤＭＣ７に実装されてもよい。一部の実施形態では、特定のデータストアアダプタは、例示のＩデータストアアダプタ（IDataStoreAdapter）インタフェースによって必須となる作成・変更・問い合わせの動作を実行するために、基底ストレージ技術に対する関連シンタックスを生成する。例えば、ＤＭＣ７は、入力構成データの状態に依存して、Ｉデータストアアダプタインタフェースでアダプタを呼び出してもよい。ＤＭＣ７はまた、ストレージシステム内のデータが指定された構成に一致するか否かを判定するためにＩデータストアアダプタインタフェースに問い合わせる際に、様々な基底データベースストレージシステムによって実行される差分計算をハンドリングしてもよい。一致が識別されると、ＤＭＣ７は対象ストレージシステムにおけるデータへの任意の要求された変更を適用するために作成メソッド、削除メソッド又は変更メソッドを呼び出してもよい。
【００５３】
アダプタの実装に焦点を当てるため、ＭｙＳＱＬのためのアダプタ及びＭｏｎｇｏＤＢのためのアダプタが実装されうるように従来のリレーショナルデータベース及び近年のＮｏＳＱＬデータベースを伴う例を検討する。図３に説明されるように、ＭｙＳＱＬデータストアアダプタ３０４とＭｏｎｇｏＤＢデータストアアダプタ３０６との両方がＩデータストアアダプタ３０２から派生する。
【００５４】
以下の構成定義は、ＭｙＳＱＬデータベース又はＭｏｎｇｏＤＢデータベースのデータエントリに適したデータエンティティについて用いられてもよい。
＜entitymodel id=”Example”＞
＜field id=”Id” type=”uint” primarykey=”true” /＞
＜field id=”Field0” type=”string” length=”50” /＞
＜field id=”Field1” type=”uint” /＞
＜/entitymodel＞
【００５５】
１つの説明では、Ｉデータストアアダプタから派生するＭｙＳＱＬデータストアアダプタは、ジェネレータのＣｒｅａｔｅＥｎｔｉｔｙＴｙｐｅ（）メソッドが呼び出されると、以下のＭｙＳＱＬコードを生成し、実行してもよい。
create table Example (
Id integer unsigned primary key auto_increment,
Field0 varchar(50),
Field1 integer unsigned
);
【００５６】
しかし、Ｉデータストアアダプタから派生するＭｏｎｇｏＤＢデータストアアダプタのＣｒｅａｔｅＥｎｔｉｔｙＴｙｐｅ（）への同じメソッドコールは、以下のＭｏｎｇｏＤＢステートメントを生成し、実行してもよい。
db.createCollection(“Example”)
【００５７】
ＭｏｎｇｏＤＢはレコード構造を厳密に行使しなくてもよいので、ＭｏｎｇｏＤＢデータストアアダプタによって名前によるコレクション作成だけが実装されてもよい。しかし、ＤＭＣ７は、ＤＭＣ７がＳｔｏｒｅＲｅｃｏｒｄ（）を介してレコードを格納するように命令された場合に、データエンティティのフィールドを管理してもよい。例えば、ＳｔｏｒｅＲｅｃｏｒｄ(“Example”, “Id: 5, Field0: ‘test’, Field1: 42”)の呼び出しは、どの基底データストレージが呼び出されるかに依存して、以下のＳＱＬステートメント又はＭｏｎｇｏＤＢステートメントをそれぞれ生成しうる。
MySQL   : insert into Example values (5, ‘test’, 42);
MongoDB : db.Example.insert({ Id: 5, Field0: ‘test’, Field1: 42});
【００５８】
よって、Ｉデータストアアダプタを用いて、ソフトウェアプログラマは、データテーブル内の新たなレコードを作成するためにＳｔｏｒｅＲｅｃｏｒｄメソッドによって規定された統一のフォーマットを用いてもよい。示されるように、統一のフォーマットは、基底データストレージシステムから独立している。
【００５９】
別の説明では、ＩデータストアアダプタのＱｕｅｒｙＲｅｃｏｒｄｓ（）メソッドは、ＤＭＣレベルクエリ記述を特定の基底ストレージ技術のクエリ言語に変換してもよい。ＤＭＣレベルクエリは、例えば、結合条件から独立して、フェッチするエンティティのタイプ及びクエリするフィールドのコレクションを列挙する拡張可能マークアップ言語（ＸＭＬ）シンタックスを用いて構築されてもよい。
【００６０】
結合動作に関して、「エンティティ結合」構成セクションは、適切な結合をコンパイルするようにプログラムされてもよい。この文脈で、データベース管理における結合動作は、２つ以上のテーブルからのデータエンティティを統合する。例示の結合は、両方のテーブルからの行を連結することによって、第１テーブルからの各行を第２テーブルからの各行に組み合わせるクロス結合と、例えば両方のテーブル内の行からのフィールドが共通の値を有する場合に結合述部に基づいて第１テーブルからの行を第２テーブルからの行に組み合わせるインナー結合と、２つの結合されるテーブル内の各レコードが一致値を有する必要がないアウター結合とを含んでもよい。例えば、米国規格協会（ＡＮＳＩ）標準又は特定のベンダによって他の結合が定義されてもよい。「エンティティ結合」構成は、特定の基底データストレージシステムによってサポートされる結合動作を指定してもよい。しかし、アプリケーションプログラマは、開発されるアプリケーションプログラムコードにおいて結合動作を実装する必要がなくてもよい。
【００６１】
以下のように、上記の例示の「Example」を参照する「JoinExample」の第２エンティティを想定する。
＜entitymodel id=”JoinExample”＞
＜field id=”Id” type=”uint” primarykey=”true” /＞
＜field id=”ExampleId” type=”uint” not-null=”true” /＞
＜field id=”JoinField” type=”string” length=”50” /＞
＜/entitymodel＞
【００６２】
ＩデータストアアダプタのＱｕｅｒｙＲｅｃｏｒｄｓ（）メソッドは、ＤＭＣレベルでこのクエリを用いて呼び出されてもよい。
＜find fetch=”Example”＞
＜equals id=”JoinField” value=”Hello” /＞
＜/find＞
【００６３】
これに応答して、ＭｙＳＱＬ及びＭｏｎｇｏＤＢのための個別のＩデータストアアダプタオブジェクトによって以下のステートメントが生成されてもよい。
MySQL: select * from Example inner join JoinExample on 
Example.Id=JoinExample.ExampleId where JoinField=”Hello”
MongoDB: db.Example.Find({ JoinField=”Hello"})
【００６４】
ＭｏｎｇｏＤＢでは、エンティティモデル及びエンティティ結合定義に基づいてオブジェクトマップ全体が格納されるだろう。エンティティ結合定義は、ファインドステートメントの結合動作の上記の記述と同様であってもよい。オブジェクトマップ全体は、個別のオブジェクトのコレクションに追加して結合ステートメントのオブジェクトのコレクション全体をストレージに保存することによって格納されてもよい。よって、これらの２つの個別のエンティティが定義され、結合ステートメントも定義されるならば、結合フィールドレコードを挿入する際に生成されるＭｏｎｇｏＤＢコードは以下であってもよい。
db.Example_JoinExample.insert({ type: “Example”, Id: 5, Field0: ‘test’, Field1: 42}, { type: “JoinExample”, Id: 16, ExampleId: 5, JoinField: “Hello” });
【００６５】
よって、本明細書に記載される一部の実施形態に従って、アダプタは、ストレージ技術に依存してデータエンティティへの相異なる動作を実行するように構成されてもよい。データエンティティへの動作はデータストレージ側でありうる。データエンティティへの動作はまた、データ検索側でありうる。しかし、アプリケーションソフトウェアプログラマは、様々な基底データストレージ技術のなかの上記の差異の詳細に関して考える必要はない。実際に、ソフトウェアプログラマは、１つの統一されたハイレベル言語において、エンティティスキーマを変更し、レコードを格納し、ロードし、クエリするためにＤＭＣ７を呼び出すだけでよい。よって、アプリケーションソフトウェアプログラマは、任意の特定の基底データストレージ技術に個別に適応するようにデータエンティティを変換するためのアップストリームコード全体を書き換える必要なく、所与の文脈的状況における特定の問題を解決するために個別調整された相異なるストレージ技術の属性（速度、トランザクション、一貫性など）の性能面の利点を得られる。アップストリームコードは、開発されるコードを呼び出すハイレベルアプリケーションプログラムコードを指してもよい。アプリケーションプログラマが基底データストレージ技術に個別に適応するようにデータエンティティを変換するためのコードを記述しなければならないならば、アプリケーションプログラマは基底データストレージ技術の不愉快な詳細に精通している必要があるだろう。基底データストレージ技術への精通は一般に、各基底データストレージ技術の特性を学習し習得するために人間に余計な時間がかかることを意味する。基底データストレージシステムへのコード依存性はまた、基底データストレージ技術が例えばムーアの法則の結果として発達するならば変換コードがアプリケーションプログラマによって書き直される必要があり、よって変換コードをドラフトする望ましくない複雑性を悪化させることを意味する。対照的に、本明細書に開示されるアダプタアーキテクチャは、「ビッグデータ」システムの実装者に対して、管理・開発・保守のコストを著しく節減することにつながりうる。節減は、システム実装者がこのような技術が特定のアプリケーションに利用可能になる際に新たな「そのクラスで最高の」データストレージ技術を統合し始める場合に一層顕著である。
【００６６】
図４は、一部の実施形態に従うデータアクセスリクエストを処理するフローチャートを示す図である。まず、例えばサーバにおいて、データエンティティモデルの定義が受信される（４０２）。サーバは、本明細書の記載に整合する任意のコンピュータ又はコンピューティング装置でありうる。データエンティティモデルは、図２Ａの構成データ１のエンティティ構造２によって説明されたような、データエンティティに対するテンプレートを定義してもよい。データエンティティモデルは、コンポーネント要素を含んでもよい。コンポーネント要素は、例えば、データベーステーブル内の定義されたフィールドを含んでもよい。次に、データエンティティモデルの少なくとも１つのコンポーネント要素を、多数のデータストレージシステムに格納された少なくとも１つのデータエンティティを表すデータに関係付ける仕様が受信されてもよい（４０４）。例示の仕様は、図２Ａの構成データ１のエンティティ関係３を含んでもよい。一部の実施形態では、構成コントローラ６は、図２Ａで説明されたような、定義及び仕様を受信するように構成されてもよい。他の実施形態では、データエンティティモデルの定義と、データエンティティモデルを多数のデータストレージシステムに格納された１つ以上のデータエンティティに関係付ける仕様とは、例えば図２Ｂで説明されたようなウェブポータルでグラフィカルユーザインタフェース（ＧＵＩ）を通じてシステム管理者によって構成されてもよい。
【００６７】
その後、サーバは、データエンティティモデルの定義を、データエンティティモデルを少なくとも１つのデータエンティティにリンクするデータベーススキーマに変換してもよい（４０６）。一部の実施形態では、データモデルコントローラ（ＤＭＣ）７は、図２Ａで説明されたように、変形を実行するように構成されてもよい。１つの例では、図３で説明されたように、Ｉデータストアアダプタ３０２は、入力データエンティティモデルをＭｙＳＱＬデータストレージ及びＭｏｎｇｏＤＢデータベースストレージにリンクする変換を実行するためにＭｙＳＱＬデータストアアダプタ３０４及びＭｏｎｇｏＤＢデータストアアダプタ３０６のような派生インタフェースを呼び出すように構成されてもよい。
【００６８】
サーバが様々な基底データストレージ技術への変換を実行するように構成されると、サーバは多数の基底データストレージシステムの１つに格納されたデータの一部にアクセスするリクエストを受信してもよい（４０８）。これに応答して、サーバは、データベーススキーマに従って基底データストレージシステムに固有のデータアクセス動作にデータアクセスリクエストを構成してもよい（４１０）。一部の実施形態では、データへアクセスするこのようなリクエストは、図１で説明されたように、アプリケーションソフトウェアプログラマによって記述されたアプリケーションプログラムによって発行されてもよい。アプリケーションプログラムに対するソフトウェアコードを作る際に、アプリケーションプログラマは、基底データストレージシステムの細目に関係のない統一したフォーマットでデータアクセスリクエストをプログラムしてもよい。図３の例で説明されるように、アプリケーションプログラマは、アダプタインタフェースとして、Ｉデータストアアダプタ３０２を用いてもよい。要求されたデータのストレージアドレスに依存して、Ｉデータストアアダプタ３０２は、上述のように、ＭｙＳＱＬデータストアアダプタ３０４又はＭｏｎｇｏデータストア３０６のいずれかを呼び出してもよい。よって、アプリケーションプログラマは基底データストレージシステムに精通している必要がなくてもよく、基底データストレージシステムが更新されたとしても、アプリケーションコードは殆ど保守される必要がなくてもよい。
【００６９】
続いて、サーバは、データベーススキーマに従って、データアクセス動作が特定のデータストレージシステムで実行されるようにしてもよい。図１で説明されたように、サーバは、データアクセス動作を対象データストレージシステム１０８〜１１２へルーティングしてもよい。
【００７０】
データアクセス動作の実行の結果は、アプリケーションプログラムからデータアクセスリクエストを投入したユーザに向けて表示されてもよい。一部の実施形態では、図５Ａで説明されたように、サーバは、対象データストレージシステムでデータアクセス動作、例えばデータベースクエリコマンドを実行した結果を受信してもよい（５０２）。サーバはまた、データエンティティモデルに関連した表示レイアウトを指定する命令を受信してもよい（５０４）。表示レイアウトを指定する例示の命令は、図２Ａの構成データ１のエンティティ表示ガイド４を含んでもよい。その後に、サーバは、指定された表示レイアウトに従って、対象データストレージシステムでデータアクセス動作を実行した結果を表示してもよい（５０６）。
【００７１】
他の実施形態では、図５Ｂで説明されるように、表示結果は外部の、すなわちサードパーティの報告ツールを通じてユーザに提示されてもよい。例示の外部の、すなわちサードパーティの報告ツールは、Ｔａｂｌｅａｕ又はＭｉｃｒｏＳｔｒａｔｅｇｙのツールを含んでもよい。データストレージシステムでデータアクセス動作を実行した結果（５０２）と、データエンティティモデルに関連した表示レイアウトを指定する命令（５０４）とを受信した後に、サーバは、データアクセス動作を実行した結果を外部の報告ツールにエクスポートしてもよい（５０６）。サーバはその後、指定された表示レイアウトに従って、データアクセス動作を実行した結果が報告ツールに表示されるようにしてもよい（５０８）。
【００７２】
本明細書で記載された主題及び機能動作の実施形態は、本明細書で開示された構造及びこれらの構造的均等物を含む、デジタル電子回路と、有形に実装されたコンピュータソフトウェア又はファームウェアと、これらのうちの１つ以上の組合せとの何れで実施されてもよい。本明細書に記載された主題の実施形態は、１つ以上のコンピュータプログラム、すわなちデータ処理装置によって実行されるかデータ処理装置の動作を制御するための有体永続的プログラム媒体に符号化されたコンピュータプログラム命令の１つ以上のモジュールとして実施されてもよい。コンピュータストレージ媒体は、機械可読ストレージデバイス、機械可読ストレージ基板、ランダム又はシリアルアクセスメモリデバイス、又はこれらのうちの１つ以上の組合せでありうる。
【００７３】
「データ処理装置」という用語はデータ処理ハードウェアを指し、例としてプログラマブルプロセッサ、コンピュータ又は複数のプロセッサ又はコンピュータを含む、データを処理するためのすべての種類の装置、コンピュータ及び機械を包含する。装置はまた、特定用途ロジック回路、例えば中央処理ユニット（ＣＰＵ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）であってもよいし、これらをさらに含んでもよい。一部の実施形態では、データ処理装置及び／又は特定用途ロジック回路は、ハードウェアベースであってもよいし、ソフトウェアベースであってもよい。装置はオプションとして、コンピュータプログラムのための実行環境を作成するコード、例えばプロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、又はこれらのうちの１つ以上の組合せを構築するコードを含みうる。本開示は、例えばＬｉｎｕｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃ  ＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）又は他の任意の適切な従来のオペレーティングシステムである従来のオペレーティングシステムを有するか、有していないデータ処理装置の使用を意図する。
【００７４】
プログラム、ソフトウェア、ソフトウェアアプリケーション、モジュール、ソフトウェアモジュール、スクリプト又はコードとも呼ばれうるコンピュータプログラムは、翻訳型言語若しくは解釈実行型言語又は宣言型言語又は手続き型言語を含む任意の形式のプログラム言語で記述されてもよく、スタンドアロンプログラム又はモジュール、コンポーネント、サブルーチン若しくは計算環境で用いるのに適した他のユニットを含む任意の形式でデプロイされてもよい。コンピュータプログラムはファイルシステム内のファイルに対応してもよいが、必須ではない。プログラムは、他のプログラム又はデータ、例えばマークアップ言語文書に格納された１つ以上のスクリプトを保持するファイルの一部に格納されてもよいし、対象のプログラムに専用の単一ファイルに格納されてもよいし、複数の連携ファイル、例えば１つ以上のモジュール、サブプログラム又はコードの複数部分を格納するファイルに格納されてもよい。コンピュータプログラムは、１つのコンピュータで実行されるようにデプロイされてもよいし、１箇所に位置するか複数の場所に分散されて通信ネットワークで相互接続された複数のコンピュータで実行されるようにデプロイされてもよい。様々な図面で説明されたプログラムの部分は様々なオブジェクト、メソッド又は他のプロセスを通じて様々な特徴及び機能を実施する個別のモジュールとして示されたが、その代わりに、プログラムは、複数のサブモジュール、サードパーティサービス、コンポーネント、ライブラリ及びこのような適切なものを含んでもよい。反対に、様々なコンポーネントの特徴及び機能は適切な単一コンポーネントに組み合わされてもよい。
【００７５】
本明細書に記載されたプロセス及びロジックフローは、入力データで動作し、出力を生成することによって機能を実行するための１つ以上のコンピュータプログラムを１つ以上のプログラマブルコンピュータが実行することによって実行されうる。プロセス及びロジックフローはまた、例えば中央処理ユニット（ＣＰＵ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）のような特定用途ロジック回路によって実行されてもよいし、装置はまた、このような特定用途ロジック回路として実施されてもよい。
【００７６】
コンピュータプログラムの実行に適したコンピュータは、例として、汎用マイクロプロセッサ若しくは専用マイクロプロセッサ若しくはこの両方又は他の任意の種類の中央処理ユニットを含む。一般に、中央処理ユニットは、リードオンリメモリ若しくはランダムアクセスメモリ又はこの両方から命令及びデータを受信する。コンピュータに必須の要素は、命令を実行するための中央処理ユニットと、命令及びデータを記憶するための１つ以上のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための１つ以上の大容量ストレージデバイス、例えば磁気ディスク、光磁気ディスク又は光ディスクを含むか、大容量ストレージデバイスからデータを受信し若しくはこれへデータを送信し又はこの両方を行うために動作可能に結合される。さらに、コンピュータは、別のデバイス、例えば、モバイル電話、携帯情報端末（ＰＤＡ）、モバイルオーディオ／ビデオプレーヤ、ゲーム機、全地球測位システム（ＧＰＳ）受信機、又は携帯ストレージデバイス、例えば少しだけ名前を挙げるとユニバーサルシリアルバス（ＵＳＢ（登録商標））フラッシュドライブに組み込まれうる。
【００７７】
コンピュータプログラム命令及びデータを記憶するのに適した（必要に応じて一時的な又は永続的な）コンピュータ可読媒体は、例として、半導体メモリデバイス、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリと、磁気ディスク、例えば内部ハードディスク又は取り外し可能ディスクと、光磁気ディスクと、ＣＤ−ＲＯＭディスク及びＤＶＤ−ＲＯＭディスクとを含む、すべての形式の不揮発性メモリを含む。メモリは、キャッシュ、クラス、フレームワーク、アプリケーション、バックアップデータ、ジョブ、ウェブページ、ウェブページテンプレート、データベーステーブル、ビジネス及び／又は動的情報を記憶するレポジトリ、及び任意のパラメータ、変数、アルゴリズム、命令、規則、制約又はこれらへの参照を含む他の任意の適切な情報を含む、様々なオブジェクト又はデータを記憶してもよい。さらに、メモリは、ログ、ポリシー、セキュリティ又はアクセスデータ、報告ファイルだけでなく他のもののような他の任意の適切なデータを含んでもよい。プロセッサ及びメモリは特定用途ロジック回路によって補完されてもよいし、これに組み込まれてもよい。
【００７８】
ユーザとのやり取りを提供するために、本明細書に記載される主題の実施形態は、ユーザに向けて情報を表示するためのディスプレイデバイス、例えばＣＲＴ（ブラウン管）、ＬＣＤ（液晶ディスプレイ）又はプラズマモニタと、ユーザがコンピュータへ入力を与えるためのキーボード及びポインティングデバイス、例えばマウス又はトラックボールとを有するコンピュータに実装されうる。ユーザとのやり取りを与えるために他の種類のデバイスが用いられうる。例えば、ユーザへ与えられるフィードバックは、任意の形式の知覚フィードバック、例えば視覚フィードバック、聴覚フィードバック又は触覚フィードバックであってもよく、ユーザからの入力は、音響、音又は触覚入力を含む任意の形式で受信されてもよい。さらに、コンピュータは、ユーザによって使用されるデバイスへ文書を送信し、このデバイスから文書を受信することによって、例えば、ユーザのクライアントデバイスのウェブブラウザから受信したリクエストに応答してウェブブラウザへウェブページを送信することによって、ユーザとやり取りできる。
【００７９】
「グラフィカルユーザインタフェース」すなわちＧＵＩという用語は、１つ以上のグラフィカルユーザインタフェースと、特定のグラフィカルユーザインタフェースの表示のそれぞれとを記載するために単数形又は複数形で用いられうる。従って、ＧＵＩは、情報を処理し、情報の結果をユーザに効率的に提示する、ウェブブラウザ、タッチスクリーン又はコマンドラインインタフェース（ＣＬＩ）を含むがこれらに限定されない任意のグラフィカルユーザインタフェースを表しうる。一般に、ＧＵＩは、ビジネススートユーザによって操作可能なインタラクティブフィールド、プルダウンリスト及びボタンのような一部又は全部がウェブブラウザに関連する複数のユーザインタフェース（ＵＩ）要素を含んでもよい。これらの及びその他のＵＩ要素は、ウェブブラウザの機能に関連してもよく、この機能を表してもよい。
【００８０】
本明細書に記載される主題の実施形態は、例えばデータサーバとしてバックエンドコンポーネントを含むコンピュータシステムで実施されてもよいし、例えばアプリケーションサーバとしてミドルウェアコンポーネントを含むコンピュータシステムで実施されてもよいし、フロントエンドコンポーネント、例えばユーザが本明細書に記載された主題の実施形態とやり取りできるグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータを含むコンピュータシステムで実施されてもよいし、このようなバックエンド、ミドルウェア又はフロントエンドコンポーネントの１つ以上の任意の組合せで実施されてもよい。システムのコンポーネントとは、デジタルデータ通信の任意の形式の媒体、例えば通信ネットワークで相互接続されうる。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、例えばインターネット、及び無線ローカルエリアネットワーク（ＷＬＡＮ）を含む。
【００８１】
コンピューティングシステムは、クライアント及びサーバを含みうる。クライアント及びサーバは一般に、互いに離れており、典型的に通信ネットワークを通じてやり取りする。クライアントとサーバとの関係は、個別のコンピュータで動作し、互いにクライアント・サーバ関係を有するコンピュータプログラムのおかげで生じる。
【００８２】
本明細書は多くの個別の実施形態の詳細を含むが、これらは任意の発明の範囲又は特許請求の範囲に係る発明の範囲の限定として解釈されるべきではなく、特定の発明の特定の実施形態に固有でありうる特徴の説明として解釈されるべきである。個別の実施形態の文脈で本明細書に記載された所定の特徴はまた、単一の実施形態において組み合わせて実施されうる。反対に、単一の実施形態の文脈で記載された様々な特徴はまた、複数の実施形態で別々に実施されてもよく、任意の適切な部分的な組合せで実施されてもよい。さらに、特徴は所定の組合せで動作するものとして上述され、そのように最初の請求項に記載されるかもしれないが、請求された組合せからの１つ以上の特徴は一部の場合に組合せから抽出されてもよく、請求された組合せはサブコンビネーション又はサブコンビネーションの変形を対象としてもよい。
【００８３】
同様に、動作は図面において特定の順序で記載されたが、このような動作が示された特定の順序又は順次に実行され、又は所望の結果を実現するために説明された全ての動作が実行されることが必要であると理解されるべきではない。所定の環境では、マルチタスク及び並列処理が有用でありうる。さらに、上述の実施形態の様々なシステムモジュール及びコンポーネントの分離は、このような分離がすべての実施形態で必要であると解釈されるべきではなく、記載されたプログラムコンポーネント及びシステムは一般に単一のソフトウェア製品に統合されてもよく、複数のソフトウェア製品にパッケージされてもよいことが理解されるべきである。
【００８４】
主題の特定の実施形態が記載されてきた。当業者に明らかなように、他の実施形態、変形及び記載された実施形態の置換が以下の特許請求の範囲に含まれる。例えば、請求項に記載された動作は、異なる順序で実行されてもよく、なおも所望の結果を実現する。
【００８５】
従って、例示の実施形態の上記の説明は本開示を定義又は制限しない。他の変更、代替又は変形も、本開示の精神及び範囲から逸脱せずに可能である。
【図１】
2015062109.tif 000003
【図２Ａ】
2015062109.tif 000004
【図２Ｂ】
2015062109.tif 000005
【図３】
2015062109.tif 000006
【図４】
2015062109.tif 000007
【図５Ａ】
2015062109.tif 000008
【図５Ｂ】
2015062109.tif 000009
【外国語明細書】
2015062109000001.pdf