(57)【要約】【課題】ＤＢ管理システム及びアクセス方法を提供する。【解決手段】ＤＢ管理システムは、複数装置のカウンターデータエントリーを保存し、各カウンターデータエントリーに保存アドレスを割り当てる第一データ保存構造；カウンターデータエントリーの保存アドレスを示し且つヌル又は空白であるカウンターデータエントリーを含まないアドレスデータと、カウンターデータエントリーに対応するタイムスタンプと、各装置がどのカウンターデータエントリーに対応するかを示す装置IDとを保存し、三者間のマッピングを行う第二データ保存構造；及び、特定期間及び少なくとも一つの装置に関するデータへのリクエストの受信に応じて、該装置に対して、第二データ保存構造により、特定期間にあり且つヌル又は空白でない、時間的に最初及び最後のカウンターデータエントリーの保存アドレスを識別するデータアクセス手段を含む。【選択図】図４
2013191211.tif 000002
【特許請求の範囲】
【請求項１】
データベース管理システムであって、
複数の装置の各々の、タイムスタンプを有するカウンターデータエントリーを非順序の方式で保存し、各カウンターデータエントリーに、一意的に識別可能な保存アドレスを割り当てる第一データ保存構造と、
前記カウンターデータエントリーの保存アドレスを示し且つヌル又は空白であるカウンターデータエントリーを含まないアドレスデータと、前記カウンターデータエントリーに対応するタイムスタンプと、前記複数の装置の各々がどのカウンターデータエントリーに対応するかを示す装置IDとを保存し、且つこの三者間のマッピングを行う第二データ保存構造と、
特定の期間及び前記複数の装置のうちの少なくとも一つに関するデータへのリクエストを受信することに応じて、該装置に対して、前記第二データ保存構造を用いて、前記特定の期間にあり且つヌル又は空白でない、時間的に最初及び最後のカウンターデータエントリーの保存アドレスを識別するデータアクセス手段と、を含む、データベース管理システム。
【請求項２】
前記データ保存構造は、前記アドレスデータと、前記タイムスタンプと、前記装置IDと、複数の装置の各々の複数のロケーションのうちの一つを示すロケーションデータとを保存し、且つこの四者間のマッピングを行い、
前記リクエストは、さらに、前記複数のロケーションのうちの少なくとも一つを特定し、
前記データアクセス手段は、特定された前記複数のロケーションの各々のカウンターデータエントリーの保存アドレスを識別する、
請求項１に記載のデータベース管理システム。
【請求項３】
前記複数のロケーションは、論理的な階層を定義する、
請求項２に記載のデータベース管理システム。
【請求項４】
前記データベース管理システムは、関係型データベース管理システムを含み、前記関係型データベース管理システムにおける前記第一データ保存構造は、関係型データ保存構造を含む、
請求項１ないし３の何れか１項に記載のデータベース管理システム。
【請求項５】
前記第二データ保存構造は、インデックスオブジェクトを含む、
請求項１ないし４の何れか１項に記載のデータベース管理システム。
【請求項６】
前記第二データ保存構造は、前記第一データ保存構造のビューを含む、
請求項１ないし３の何れか１項に記載のデータベース管理システム。
【請求項７】
前記第二データ保存構造は、前記第一データ保存構造のマテリアライズドビューを含む、
請求項１ないし３の何れか１項に記載のデータベース管理システム。
【請求項８】
前記リクエストは、SQLクエリーを含む、
請求項１ないし７の何れか１項に記載のデータベース管理システム。
【請求項９】
前記データベース管理システムは、ネットワークインターフェースを経由して、ネットワーク上の前記複数の装置からカウンターデータを受信するように作動する、
請求項１ないし８の何れか１項に記載のデータベース管理システム。
【請求項１０】
前記カウンターデータを取得するために、前記複数の装置をポーリングする、
請求項９に記載のデータベース管理システム。
【請求項１１】
前記複数の装置は、多機能印刷装置を含む、
請求項１ないし１０の何れか１項に記載のデータベース管理システム。
【請求項１２】
データ管理システムにおけるデータをアクセス方法であって、
第一データ保存構造で、複数の装置の各々の、タイムスタンプを有するカウンターデータエントリーを非順序の方式で保存し、各カウンターデータエントリーに、一意的に識別可能な保存アドレスを割り当てるステップと、
第二データ保存構造で、前記カウンターデータエントリーの保存アドレスを示し且つヌル又は空白であるカウンターデータエントリーを含まないアドレスデータと、前記カウンターデータエントリーに対応するタイムスタンプと、前記複数の装置の各々がどのカウンターデータエントリーに対応するかを示す装置IDとを保存し、且つこの三者間のマッピングを行うステップと、
特定の期間及び前記複数の装置のうちの少なくとも一つに関するデータへのリクエストを受信することに応じて、該装置に対して、前記第二データ保存構造を用いて、前記特定の期間にあり且つヌル又は空白でない、時間的に最初及び最後のカウンターデータエントリーの保存アドレスを識別するステップと、を含む、アクセス方法。
【請求項１３】
カウンターデータを取得するために、前記複数の装置をポーリングするステップをさらに含む、
請求項１２に記載のアクセス方法。
【請求項１４】
コンピュータに、請求項１２又は１３に記載のアクセス方法を実行させるためのプログラムを記録している、コンピュータ読み取り可能な記録媒体。
【請求項１５】
コンピュータを、請求項１ないし１１の何れか１項に記載のデータベース管理システムとして構成するためのプログラムを記録している、コンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施例は、データの保存及び取得に関し、特に、ネットワーク化されたオフィス装置におけるデータの保存及び取得に関する。
【背景技術】
【０００２】
プリンター、コピー機、スキャナー、及び多機能機器のような多くの電子装置は、デバイスの使用及び他のデータを生成することができる。多くの場合、これらのような装置は、データを後続の解析のためにデータベースに定期的に伝送することができるようにネットワークにより接続される。装置の数及びデータに関連するデバイスパラメータの数が多くなるにつれて、経時的に集められたデータの量も膨大になる。
【０００３】
今のところ、幅広く使われている多くの従来のシステム、例えば、関係型データベース管理システムは、経時的に集められた大量のデータ（即ち、時間依存性データ）を保存することができるが、関係型データベースにおけるトランザクションを管理するためのルールは、データを解析し得る十分なビルトインサポートを提供していない。言い換えると、関係型データベースでは、過去のデータへのクエリーが難しい。この問題を解決するために、単独の解析用構造がよく用いられる。このようにして、データは、関係型データベースに保存され得る一方で、解析は、密に接続される解析用構造により行われる。しかし、既存の実施手段、特に、企業向け印刷システムのための実施手段は、ベンダー独自のクエリー及び／又は複雑なクエリーを用い、このようなクエリーは、コンピュータリソースを、システムのパフォーマンスを著しく低下させる程度まで消費することができる。
【０００４】
よって、データを管理及び解析するために、改良されたシステム及び方法を提供することが望ましい。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、データを保存及び取得する方法及びシステムを提供することにある。
【課題を解決するための手段】
【０００６】
本発明の一側面によれば、データベース管理システムが提供される。このデータベース管理システムは、複数の装置の各々の、タイムスタンプを有するカウンターデータエントリーを非順序の方式で保存し、各カウンターデータエントリーに、一意的に識別可能な保存アドレスを割り当てる第一データ保存構造；前記カウンターデータエントリーの保存アドレスを示し且つヌル又は空白であるカウンターデータエントリーを含まないアドレスデータと、前記カウンターデータエントリーに対応するタイムスタンプと、前記複数の装置の各々がどのカウンターデータエントリーに対応するかを示す装置IDと、を保存し、且つこの三者間のマッピングを行う第二データ保存構造；及び、特定の期間及び前記複数の装置のうちの少なくとも一つに関するデータへのリクエストを受信することに応じて、該装置に対して、前記第二データ保存構造を用いて、前記特定の期間にあり且つヌル又は空白でない、時間的に最初及び最後のカウンターデータエントリーの保存アドレスを識別するデータアクセス手段を含む。
【０００７】
本発明の他の側面によれば、データ管理システムにおけるデータをアクセス方法が提供される。このアクセス方法は、第一データ保存構造で、複数の装置の各々の、タイムスタンプを有するカウンターデータエントリーを非順序の方式で保存し、各カウンターデータエントリーに、一意的に識別可能な保存アドレスを割り当てるステップ；第二データ保存構造で、前記カウンターデータエントリーの保存アドレスを示し且つヌル又は空白であるカウンターデータエントリーを含まないアドレスデータと、前記カウンターデータエントリーに対応するタイムスタンプと、前記複数の装置の各々がどのカウンターデータエントリーに対応するかを示す装置IDと、を保存し、且つこの三者間のマッピングを行うステップ；及び、特定の期間及び前記複数の装置のうちの少なくとも一つに関するデータへのリクエストを受信することに応じて、該装置に対して、前記第二データ保存構造を用いて、前記特定の期間にあり且つヌル又は空白でない、時間的に最初及び最後のカウンターデータエントリーの保存アドレスを識別するステップを含む。
【０００８】
本発明によれば、データベース管理システムは、第二データ保存構造を用いることにより、ヌル又は空白でないカウンターデータ値を含み、非順序の方式で保存され、自然的な順番を有するカウンターデータエントリーの保存ロケーションを迅速に特定することができる。これにより、カウンターデータエントリー毎に検索を行う必要がなく、検索時の計算コストを大幅に削減することができる。
【図面の簡単な説明】
【０００９】
【図１Ａ】異なるタイプのデータ不連続を示す図である（その一）。
【図１Ｂ】異なるタイプのデータ不連続を示す図である（その二）。
【図１Ｃ】異なるタイプのデータ不連続を示す図である（その三）。
【図１Ｄ】異なるタイプのデータ不連続を示す図である（その四）。
【図２Ａ】図１Ａに示すデータ不連続に対しての検索処理を示す図である。
【図２Ｂ】図１Ｂに示すデータ不連続に対しての検索処理を示す図である。
【図２Ｃ】図１Ｃに示すデータ不連続に対しての検索処理を示す図である。
【図２Ｄ】図１Ｄに示すデータ不連続に対しての検索処理を示す図である。
【図３】組織階層を示す図である。
【図４】一実施例によるデータベース管理システムを示す図である。
【図５】一実施例によるデータ保存構造を示す図である。
【図６】一実施例によるデータ保存処理のフローチャートである。
【図７】一実施例によるデータアクセス処理のフローチャートである。
【発明を実施するための形態】
【００１０】
以下、添付した図面を参照しながら、本発明の好適な実施形態を詳細に説明する。
【００１１】
なお、以下に述べた実施例は、ハードウェア、ソフトウェア、又はそれらの組み合わせにより実施され得る。よって、ここで定義の「手段（means）」、「コンポーネント（component）」、及び「部（part）」は、コンピュータに異なる組み合わせのコードモジュールとして実行され得る。また、実施例は、記憶媒体及び一時的媒体又は信号を含む運び可能な媒体におけるコンピュータプログラムプロダクトとして提供されるコンピュータプログラムを含む。コンピュータプログラムは、固体メモリ、光ディスク、磁気ディスク、又はデープ装置のような記憶媒体に保存され得る。コンピュータプログラムは、一時的媒体、或いは、光学信号、音響信号、磁気信号、無線周波数信号、又は電気信号、例えば、インターネットでコードを運び得るTCP/IP信号により提供され得る。コンピュータプログラムプロダクトは、一つ以上の実施例の実行をそのまま構成し得る完全なコンピュータ実行可能な命令、或いは、コンピュータに既存の実行可能なソフトウェアコンポーネントを確保して所望の方式でそのコンピュータを構成させる命令として、実施例の実施に関与することができる。また、コンピュータプログラムプロダクトは、直接実行されてもよく、或いは、実行可能な条件を満たす前に、ローカル処理、例えば、復号、解凍、又はコンパイルを必要としてもよい。
【００１２】
一般的には、印刷装置は、その内部においてデジタル制御される、「カウンター（Counter）」の別名でも知られる複数の「ゲージ（gauge）」を有する。このようなカウンターは、例えば、印刷されているコピー部数を示すことができ、製造仕様の一つである。カウンターデータを取得するために、通常、スケジューリングメカニズムを用いることにより、ポーリングを定期的に行ってもよい。
【００１３】
ここで、特に関心があるのは、「絶対カウンター（absolute  counter）値」である。これは、その値が一定時点におけるトータルカウント値を示すことを意味する。よって、与えられた時間内（以下、「レポート期間」という）における印刷装置のカウンター値を取得するために、この期間の終了時に対応するカウンター値からこの期間の開始時に対応するカウンター値を引くことが行われてもよい。
【００１４】
しかし、関心がある任意のレポート期間において、全ての装置及び全ての時点のカウンターデータを取得することは、通常、不可能である。例えば、印刷装置は、カウンターの特定のポーリング時間に、物理的に使用不可になることがあり、例えば、オフラインモードにある可能性があり、或いは、ネットワーク通信エラーが発生してしまう可能性もある。これは、装置におけるカウンターデータに「ギャップ」（データ不連続）をもたらす。
【００１５】
一般的に言えば、３種類の印刷装置のデータ不連続が存在する。即ち、（１）レポート期間の開始時に発生するもの、（２）レポート期間の終了時に発生するもの、及び（３）レポート期間の開始時及び終了時に発生するものである。また、全レポート期間にカウンターデータがないという特例も存在する。
【００１６】
図１Ｂないし図１Ｄは、１つの印刷装置のレポート期間１０２における上述の３種類のデータ不連続を示す。この具体例では、レポート期間は、連続１４日間に対応し、各日は、序数（即ち、１から１４までの整数）として表されている。なお、実際には、他のレポート期間も可能であり、例えば、日付以外の時間間隔が用いられてもよく、或いは、序数の代わりにタイムスタンプが用いられてもよい。これらの図面では、斜線付きセルは、データが保存された日を示し、空白セルは、データがない日を示す。よって、図１Ａでは、レポート期間１０２にデータのギャップがない。図１Ｂでは、レポート期間１０２の開始時にデータのギャップ１０４が存在する。図１Ｃでは、レポート期間１０２の終了時にデータのギャップが存在する。図１Ｄでは、レポート期間１０２の開始時及び終了時にデータのギャップ１０４及び１０６が存在する。
【００１７】
上述のように、与えられた時間内における印刷装置の絶対的なカウンター値を確定するために、最初及び最後のタイムスタンプに対応するカウンター値を確定し、それから、両者の差を計算することが行われてもよい。一般的には、これは、欠測データをスキップするリニアサーチ（線形検索）処理を要する。その理由は、多くのデータ構造、例えば、関係表（HEAPテーブルの別名でも知られる）が非順序の方式でデータを保存することにある。これは、データが特定の順序に保存されていない（即ち、例えば、「昼間」に従って管理されていない）ことを意味する。なお、上述の図面に示すデータは、有効データの一部のみを構成してもよい。そのため、レポート期間における最初及び最後のタイムスタンプに対応するカウンターデータ値の検索は、結局、これらのカウンターデータ値を見つける前に、そのレポート期間における全てのデータを読むことになる。よって、図２Ａないし図２Ｄに示すように、データが全レポート期間に存在する場合（図２Ａ）、欠測データをスキップする検索を行う必要がないが、レポート期間の開始時にカウンターデータがない（図２Ｂ）場合、レポート期間における最初のタイムスタンプに対応するカウンターデータ値２０４を識別するための検索２０２を行われなければならない。同様に、図２Ｃに示すように、レポート期間の終了時にカウンターデータがない場合、レポート期間における最後のタイムスタンプに対応するカウンターデータ値２０８を識別するための検索２０６を行われなければならない。また、レポート期間の開始時及び終了時にデータがない場合、レポート期間における最初及び最後のタイムスタンプにそれぞれ対応するカウンターデータ値２１４、２１６を識別するための２つの検索２１０、２１２を行う必要がある。
【００１８】
実際には、エンドユーザ（例えば、組織）が単一の印刷装置のみにほとんど興味がない。比較的大きい印刷インフラストラクチャーの中では、Ｎ個の印刷装置が並列に用いられているものであると見なされてもよく、ここで、Ｎは、数十、数百又は数千であってもよい。一つ以上の上述のタイプのデータ不連続は、かなりの割合の印刷装置に見られ得る。しかし、積み重ねられた莫大な量のデータは、高効率のデータ取得への課題（チャレンジ）を提示する。特に、不可能ではないにしても、データのギャップの分布に対しての価値のある予測を行うことが難しい。Ｎ個の印刷装置の場合、検索処理を行うのは、Ｎ個の検索の実行を要し、こうして、Ｎ倍の検索時間を要し、計算上多大な時間を必要とする。
【００１９】
また、エンドユーザは、通常、Ｎ個の印刷装置のうちの一部（サブセット）、例えば、組織の中の特定の物理（又は論理）的なロケーション（位置）にあるものに興味を持つ。一般的なルールとして、インストールされている各印刷装置が既存のインフラストラクチャーの中の一部であると見なされ得る。よって、エンドユーザは、通常、その内部階層を反映する組織的なインフラストラクチャーを有する。図３は、全組織を示す最上位（又はルート）ノード３０２、及び、この例では異なるロケーション３０４、施設３６０、部門３０８、ユニット３１０、及びネットワーク３１２を示すブランチを含む樹状構造３００として表される組織階層を示す図である。よって、一実施例では、階層がルートに対応するロケーションであり、ルートノード３０２が階層３００の中の全ての他のロケーションを含む。同様に、階層の下位に現れる１つ以上のノード（例えば、ノード３０８、３１０、及び３１２）に接続されるノード（例えば、ノード３０２）は、その下の全てのノードを含む。それで、異なるブランチの間には重複が存在することができ、即ち、一つのノードは２つ以上のブランチの一部であってもよい。一般的には、データベース管理システムは、エンドユーザが取引先のインフラストラクチャーにある異なるロケーションをアクセスすることを絶対に許さない。
【００２０】
図４は、データベース管理システム４００を示す。一般的に言えば、データベース管理システム４００は、インフラストラクチャー４２２にある印刷装置４２０からデータを集めて保存し、また、保存されたデータをエンドユーザ４１８によりアクセスする方法を提供する役割を果たす。データベース管理システム４００は、データベースサーバ４０２及びデータ保存システム４０４を含むが、これらは、図示のように、必ずしも単独のサブシステムではない。また、物理的に分離する必要がなく、即ち、それらは、一体化されてもよい。
【００２１】
データベース４０２は、ネットワークプロトコール４０６、クエリーエンジン４０８、及び報告アプリケーション４０９を含む。ネットワークプロトコール４０６は、接続処理、認証、セキュリティー、及びネットワーク４１６上の他の処理などの機能を提供する。ネットワーク４１６は、インターネットのような広域ネットワークであってもよい。クエリーエンジン４０８は、クエリーの最適化及び実行を行うために用いられる。そのコンポーネントは、構文解析ツール（パーサー）、クエリー最適化ツール、及びクエリー実行ツール（図示せず）を含んでもよい。簡単に説明すれば、構文解析ツールは、主としてクエリーの構文をチェックする役割を果たす。クエリー最適化ツールは、どのようにしてデータをできるだけ早く且つ効率よく取得するかを確定するためのものである。それは、例えば、クエリーを実行するための複数の方法から一つを選択して、クエリー実行ツールにより認識され得る実行プランを生成することができる。それから、クエリー実行ツールは、実行プランを解釈し、また、受信した情報に基づいて、システムの他のコンポーネント、例えば、データ保存システム４０４の保存エンジン４１０へのリクエストを行い、データを取得する。データが取得されたら、それは、エンドユーザに見せるために、報告アプリケーション４０９に渡される。
【００２２】
データ保存システム４０４は、保存エンジン４１０を含み、それは、第一及び第二データ保存構造４１２、４１４にデータを効率よく保存及びアクセスするために用いられる。データサーバ４２０は、保存エンジンのアプリケーション・プログラミング・インタフェース（ＡＰＩ）（図示せず）を介して、保存エンジン４１０と通信する。
【００２３】
実施例では、データベース管理システム４００は、印刷装置４２０を定期的にポーリングすることができるので、ポーリング処理を管理するためのポーリングアップリケーションを有してもよい。なお、それは、明確である理由で、図示されていない。
【００２４】
報告を生成するために、エンドユーザ４１８は、クエリーを作成してデータベースサーバ４０２に送る。実施例では、データベース管理システム４００は、ＳＱＬ（Structural  Query  Language）を用いる。ＳＱＬでは、クエリーとは、クローズ（clause）と称される、広く利用可能なＳＱＬコマンドのセットを指す。各クロース（コマンド）は、データベースに対して、ある種の機能を行う。クエリーは、いくつかの基準を指定し、データベースサーバは、その基準に従って、データベースシステムに含まれている全てのデータからデータを選択することができる。一実施例では、クエリーは、「SQL  SELECT」クロースを含む。データベースサーバは、このクエリーを受信して実行を行う。クエリーを実行するプロセスでは、データベースサーバは、結果セットを形成し、そして、結果セットをエンドユーザに見せるために報告アプリケーション４０９に送る。結果セットは、データベースシステムにおける全てのデータから選択されたサブセットである（これについては、以下詳述する）。結果セットは、クエリーに指定された基準を満たすデータのみより構成される。
【００２５】
データベース管理システムは、少なくとも一つのプロセッサを有するデータ処理システムとして実装されてよい。一実施例では、少なくとも一つのプロセッサは、従来の処理デバイス、例えば、汎用マイクロプロセッサであってもよい。データ処理システムは、さらに、メモリを含み、このメモリは、上述の特徴、例えば、クエリーエンジン４０８及びストーリッジエンジン４１０を実現するためのプログラム命令又は機能的なユニットを含んでも良い。
【００２６】
図5は、一実施例による第一及び第二データ保存構造４１２、４１４を示す。
【００２７】
一実施例では、第一（又はプライマリー）データ保存構造４１２は、関係型データ構造である。論理的データ構造では、データが関係表に保存される。図5に示すように、表５１２は、装置、装置中のイベントの発生、及びイベントが発生した時間に関するデータを保存する。これらは、表５１２のコラム（列）により定義され、それぞれ、印刷装置ID、カウンター値、及びタイムスタンプと称される。そのため、一実施例では、各行が装置ID、カウンターデータ入力、及びタイムスタンプを保存する三つのフィールドを含むレコードである。これらのデータは、一般的に、表５１２に示すように、時間的に並べられていない。タイムスタンプは、時点を示し、このような時点では、カウンターデータが取得されており、又は、取得予定されている（即ち、データベース管理システム４００に受信されており、又は、印刷装置４２０によりサンプリングされている）。なお、図５に示すタイムスタンプは、順序のある値（1、2、3、…、N）であるが、これは、説明を明確にするためだけのものである。そのうち、カウンターデータは無くてもよく、カウンターデータ入力は「null（ヌル）」又は空白（何も無い）であってもよい。「null」は何れのデータ領域に属しないので、厳密に言えば、「value（値）」ではなく、むしろ、「値無し」を示すためのマーカー（又は、プレースホルダー）である。
【００２８】
一実施例では、カウンターデータ値は、絶対カウンター値であり、カウントされているイベントの発生の総数、例えば、印刷されているページ数を示すという意味がある。そのため、カウンターデータは、数値データを含み、このような数値データは、時間に基づいて測定され、又は、時間に制限されるものである。なお、カウントされているイベントの発生は、アドレス「An03」及び「An04」に保存されているカウンターデータのように、経時的に変化する必要がなくてもよい。しかし、各々は、依然として、関連したタイムスタンプを有する。一実施例では、カウンターデータは、一定の時間周期で、経時的に繰り返して集められる。時間周期の頻度又は“粒度（granularity）”は、「秒」、「分」、「時間」、「日」、「週」、「月」、又は「年」であってもよい。一実施例では、頻度は、一日n回（規則又は不規則な時間間隔）であり、例えば、ネットワークインフラに応じて、nは、2〜8である。なぜなら、ポーリングは、多くの場合、ネットワーク帯域幅にかなりの負荷を与え、酷い場合、一時的なネットワーク“storm（ストーム）”又は“collapse（コラプス）”を引き起こしてしまうからである。
【００２９】
一実施例では、第二（又は、オグジリアリ）データ保存構造４１４は、多次元データ保存構造５１４（数学用語で、ハイパーキューブ）である。しかし、ここでは、便宜のために、それが二次元の表として示される。一実施例では、データ保存構造５１４は、データを直接（vs.順次）にアクセスすることを許す物理データ構造であるインデックスオブジェクトを含む。データ保存構造５１４に保存されるデータは、表５１２に保存されるデータに基づくものである。実施例では、データ保存構造５１４は、印刷装置ID、タイムスタンプ、及び、対応するカウンターデータの利用可能な保存場所を示すアドレスデータを保存し、また、それらの間のマッピングをも行う。一実施例では、データ保存構造５１４は、図３に基づいて説明したように、エンドユーザの組織構成における装置の場所に対応する階層IDを含む。例えば、階層ID「1」は、組織全体に対応してもよい。図５による実施例では、データ保存構造５１４は、エントリー（入力）毎に階層IDを保存する。
【００３０】
次に、図６及び図７を参照しながら、上述のデータ保存構造の使用について説明する。
【００３１】
ステップＳ６０２では、データベース管理システム４００から分離するがそれに通信可能に接続されるポーリングアップリケーションが、印刷装置４２０にポーリングメッセージを送信する。これに応じて、「アクティブ」な印刷装置は、カウンターデータ値を含むレスポンスメッセージを送信する（Ｓ６０４）。次に、ポーリングアプリケーションは、受信したレスポンスメッセージを装置ＩＤにマッピングする。メッセージは、位置ＩＤをも含んでもよく、この位置ＩＤは、ユーザからの入力に基づいて最後に決定されてもよい。ステップＳ６０６では、データが、データ保存構造（例えば、表５１２）に保存される。ステップＳ６０８では、第二データ保存構造（例えば、表５１４）が更新される。
【００３２】
次に、データベースサーバ４０２は、ネットワーク４１６及びネットワークプロトコール４０６を経由してエンドユーザ４１８から、データへのリクエスト（例えば、ＳＱＬクエリーの形）を受信する場合（ステップＳ７０２）、ＳＱＬクエリーは、クエリーエンジン４０８に渡され、クエリーエンジンにより、構文解析、最適化、及び実行が為される（ステップＳ７０４）。リクエストされたデータは、データ保存システム４０４の保存エンジン４１０により読み出され、その結果は、報告アプリケーション４０９に返され、エンドユーザ４１８に見せるために準備される。
【００３３】
上述のように、関係型データ構造は、保存されているデータが時間依存性データコレクションの一部であることを「把握」することができない。これは、カウンターデータ値の無い特定の時点を指定するクエリーは、この特定の時点にカウンターデータ値が無いため、「ヌル」を返すことを意味する。また、データ不連続の場合、データベース管理システム４００は、まず、報告期間の最初及び／又は最後に対応するカウンターデータを見つけなければならない。これは、Ｎ個の印刷装置の場合、Ｎ回の検索を要する。しかし、第二データ保存構造を用いる場合、このような検索を使う必要がなくなる。その理由の一つは、データベース管理システムが、所定の時点にカウンターデータ値が存在するかどうかを「知っており」、もう一つは、アドレス情報を用いて、第一データ保存構造においてそれをアクセスすることができる。
【００３４】
よって、図５を参照するに、例えば、タイムスタンプ「１」ないし「４」をカバーする報告期間では、印刷装置２及びタイムスタンプ「１」、「２」について、カウンターデータが存在しない。それに応じて、表５１４は、この装置のこれらのタイムスタンプについて、アドレスデータを保存しない。その代わりに、カウンターデータ値が存在するタイムスタンプ「３」及び「４」のみについては、アドレスデータが保存される。これは、この報告期間について、データベース管理システム４００が直ちにタイムスタンプ「３」のところに行ってアドレスデータ値「Ａ２０７」を見つけ、このアドレスにあるカウンターデータ値（値「１０」）をアクセスすることを意味する。
【００３５】
言い換えると、カウンターデータ値が存在するアドレスデータ及びタイムスタンプを保存し、両者間のマッピングを行うことにより、第二データ保存構造は、保存エンジンがどこに行くべきかを示す指示を提供することができる。
【００３６】
上述の実施例では、各装置のためのカウンターデータが第一データ保存構造においてコラム（列）に保存されるが、他の実施例では、各装置のためのデータが、専用の表、共用の表の複数の行、又は、共用の表の一つの行として保存され得る。
【００３７】
上述の実施例では、第二データ保存構造がインデックスオブジェクトを含むが、他の実施例では、（例えば、Oracleのような）「view（ビュー）」又は「materialized  view（マテリアライズドビュー）」を含んでもよい。「view（ビュー）」は、クエリーの構文解析後のバイナリ言語の実装のようなものであると考えられてもよく、実行される時に、その参照するデータ保存構造（この場合、第一データ保存構造）からデータを抽出又は取得することができる。「view（ビュー）」（即ち、クエリー）は、保存されているので、同じクエリーを何度も書き直す必要がなく、繰り返して実行され得る。また、「view（ビュー）」は、第一データ保存構造に基づくものであるため、データ・ディクショナリ（データ辞書）において、ビュー（即ち、クエリー）の定義のためのストレージ以外のストレージを占めない。一方、「materialized  view（マテリアライズドビュー）」は、クエリーが実行される時に生成された結果セットにより定義される物理データ構造である。言い換えると、「materialized  view（マテリアライズドビュー）」は、事前計算されたクエリー結果を含み、この事前計算されたクエリー結果は、後で迅速にアクセスされ得るために、持続的な（persistent）方式で保存されてもよい。これは、追加のレコードロギングメカニズム（record  logging  mechanism）とともに、即ち、カウンターデータをも保存して、上述の第二データ保存構造の形で実現される。「materialized  view（マテリアライズドビュー）」は、そのデータ構造のソース、即ち、第一データ構造と同期する。そうでなければ、「materialized  view（マテリアライズドビュー）」は、「stale（古いもの）」にされ、データベースのQEP実行プログラム（query  execution  plan  executor）により用いられない。
【００３８】
上述の実施例では、データベースシステムが、プリンター、コピー機、及びファクシミリ機（又は、それらの組み合わせを含む装置）のようなネットワーク接続されるオフィス機器の環境で実装されるが、データベースシステムは、他の種類の装置にも関連してもよい。大まかに言えば、これらのような装置は、マシン読み取り可能なデジタルフォーマットの異なる情報、及び、デジタル化され得る情報内容を処理するためのデジタル機能を持つデバイスを提供し、むしろ含む。例えば、これらのような装置は、測定及び評価が可能で、また、マシン読み取り可能な電子フォーマットに変換することができる光学的、機械的、及び他のデータを含む。
【００３９】
上述の実施例では、第二データ保存構造が、エントリー毎に階層IDを保存するが、他の実施例では、第二データ保存構造５１４が、各エントリーについて、複数の階層IDを保存してもよい。また、「drill  down（ドリルダウン）」機能、例えば、階層IDを階層に対応する「tree（木）」構造にマッピングする機能を提供する追加の構造を提供することもできる。
【００４０】
上述の実施例では、データが定期的に装置から送られるが、他の実施例では、データが不定期的に、又は、定期と不定期との組み合わせの形で、装置から送られてもよい。一方、定期的なデータは、予測可能な所定の期間に送られ、不定期的なデータは、繰り返しパターンにより特徴を付けることができない不特定の時点又はタイムスタンプに送られる。
【００４１】
上述の実施例では、タイムスタンプが時点（即ち、データタイプの精度に基づく、時間上の特定の瞬間）に関連するが、他の実施例では、タイムスタンプが期間に関連してもよい。
【００４２】
上述の実施例では、SQLクエリーが特定の情報を検索するために用いられるが、他の実施例では、クエリーが他のクエリー言語により構成されてもよい。
【００４３】
なお、保存位置アドレスは、物理的な位置を指すのではなくてもよい。その代わりに、保存位置アドレスは、コントローラから情報をリクエストする手段として用いられてもよい。コントローラは、そのリクエストを論理的なアドレスから、記憶装置における実際の物理的な位置からデータを取得することができる物理的アドレスに変換する。
【００４４】
以上、本発明の好ましい実施形態を説明したが、本発明はこの実施形態に限定されず、本発明の趣旨を離脱しない限り、本発明に対するあらゆる変更は本発明の技術的範囲に属する。
【図１Ａ】
2013191211.tif 000003
【図１Ｂ】
2013191211.tif 000004
【図１Ｃ】
2013191211.tif 000005
【図１Ｄ】
2013191211.tif 000006
【図２Ａ】
2013191211.tif 000007
【図２Ｂ】
2013191211.tif 000008
【図２Ｃ】
2013191211.tif 000009
【図２Ｄ】
2013191211.tif 000010
【図３】
2013191211.tif 000011
【図４】
2013191211.tif 000012
【図５】
2013191211.tif 000013
【図６】
2013191211.tif 000014
【図７】
2013191211.tif 000015