(57)【要約】【課題】コンタクト・センタが任意の国際時間帯で報告するための日付および時刻ディメンションを提供すること。【解決手段】一実施形態では、選択された時間的起点に関して選択された時点を識別する日付キーと、複数の可能な時間帯の内の１つを識別する時間帯キーと、選択された日付および時間帯キーのペアについての時間情報を記述する少なくとも１つの属性と、を備える、日付時間帯ディメンション表を含むコンピュータ読み取り可能媒体が提供される。【選択図】図６
2007228590.tif 000002
【特許請求の範囲】
【請求項１】
選択された時間的起点に関して選択された時点を識別する日付キーと、
複数の可能な時間帯の内の１つを識別する時間帯キーと、
選択された日付および時間帯キーのペアについての時間情報を記述する少なくとも１つの属性と、
を備える日付時間帯ディメンション構造を備える、コンピュータ読み取り可能媒体。
【請求項２】
前記日付キーは、１秒、１分、１５分、３０分、および６０分の間隔の内の少なくとも１つの粒度で、前記選択された時間的起点からの経過時間を定義し、前記少なくとも１つの属性は、対応する日付キー値について、１年から少なくとも前記日付キーの前記粒度まで細分された全日付を識別する、請求項１に記載の媒体。
【請求項３】
前記選択された時間的起点は１９７０−０１−０１  ００：００：００  ＵＴであり、前記日付キーは時間帯キーと共に１次キーを備え、前記時間帯キーは外部キーであり、
１次キーとしての前記時間帯キーと、選択された時刻キー値に対応する時間帯を記述する少なくとも１つの属性と、を備える時間帯ディメンション表をさらに備え、
前記少なくとも１つの属性は、複数の夏時間インジケータと、選択された世界時システムに関するオフセット文字列と、前記選択された日付および時間帯キー・ペアに対応する年と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算月と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算週と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１月の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の曜日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の相対順序曜日と、前記選択された日付および時間帯キー・ペアに対応する１日の内の時間と、前記選択された日付および時間帯キー・ペアに対応する１時間の内の分と、前記選択された日付および時間帯キー・ペアに対応する会計年度と、前記選択された日付および時間帯キー・ペアに対応する会計半年度と、前記選択された日付および時間帯キー・ペアに対応する会計四半年度と、前記選択された日付および時間帯キー・ペアに対応する特定用途向け時間間隔と、を備える、請求項１に記載の媒体。
【請求項４】
選択された日付キーおよび時間帯キーの値は前記構造内の行を定義し、
前記行は、他の時点に関連付けられた日付キー値のセットを備え、前記日付時間帯ディメンション構造から生成された複数の日付ディメンション表をさらに備え、前記日付ディメンション表のそれぞれは前記時間帯キーの単一の値および前記日付キーの複数の値に対応し、
前記選択された時点について、前記日付キーは複数の値を有し、それぞれの値は異なる時間帯キー値に対応し、
前記日付キーおよび時間帯キーの論理的機能は１つの物理キーに組み合わせられる、
請求項１に記載の媒体。
【請求項５】
前記日付キーは特定の時間帯とは無関係のタイミング規則の時間単位で表され、
前記日付キー値のセットは、複数の今週、今日、この６０分間隔、この３０分間隔、この１５分間隔、昨年、昨月、昨週、昨日、前の６０分間隔、前の３０分間隔、前の１５分間隔、来年、来週、来月、明日、次の６０分間隔、次の３０分間隔、次の１５分間隔、この会計年度、この会計半年度、この会計四半年度、この特定用途向け時間間隔、前の会計年度、前の会計半年度、前の会計四半年度、前の特定用途向け時間間隔、次の会計年度、次の会計半年度、次の会計四半年度、および次の特定用途向け時間間隔に関連付けられる、
請求項１に記載の媒体。
【請求項６】
顧客のコンタクトを受け取り、前記コンタクトを複数のサービス・エージェントに分配するように動作可能なサーバと、
データベースと、
を備えるコンタクト・センタであって、前記データベースは、
選択された時間的起点に関して選択された時点を識別する日付キーと、
複数の可能な時間帯の内の１つを識別する時間帯キーと、
選択された日付および時間帯キーのペアについての時間情報を記述する少なくとも１つの属性と、
を備える日付時間帯ディメンション表を備える、コンタクト・センタ。
【請求項７】
前記日付キーは、１秒、１分、１５分、３０分、および６０分の間隔の内の少なくとも１つの粒度で、前記選択された時間的起点からの経過時間を定義し、
前記日付キーは時間帯キーと共に１次キーを備え、前記時間帯キーは外部キーであり、
１次キーとしての前記時間帯キーと、選択された時刻キー値に対応する時間帯を記述する少なくとも１つの属性と、を備える時間帯ディメンション表をさらに備え、
前記少なくとも１つの属性は、対応する日付キー値について、１年から少なくとも前記日付キーの前記粒度まで細分された全日付を識別する、請求項６に記載のコンタクト・センタ。
【請求項８】
前記選択された時間的起点は１９７０−０１−０１  ００：００：００  ＵＴＣであり、
前記少なくとも１つの属性は、複数の夏時間インジケータと、選択された世界時システムに関するオフセット文字列と、前記選択された日付および時間帯キー・ペアに対応する年と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算月と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算週と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１月の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の曜日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の相対順序曜日と、前記選択された日付および時間帯キー・ペアに対応する１日の内の時間と、前記選択された日付および時間帯キー・ペアに対応する１時間の内の分と、前記選択された日付および時間帯キー・ペアに対応する会計年度と、前記選択された日付および時間帯キー・ペアに対応する会計半年度と、前記選択された日付および時間帯キー・ペアに対応する会計四半年度と、前記選択された日付および時間帯キー・ペアに対応する特定用途向け時間間隔と、を備える、請求項７に記載のコンタクト・センタ。
【請求項９】
前記データベースは、前記日付時間帯ディメンション表から生成された複数の日付ディメンション表をさらに備え、前記日付ディメンション表のそれぞれは前記時間帯キーの単一の値および前記日付キーの複数の値に対応し、
前記選択された時点について、前記日付キーは複数の値を有し、それぞれの値は異なる時間帯キー値に対応し、
前記日付キーは特定の時間帯とは無関係のタイミング規則の時間単位で表され、
前記選択された日付キーおよび時間帯キーの値は前記構造内の行を定義し、
前記行は、他の時点に関連付けられた日付キー値のセットを備える、請求項７に記載のコンタクト・センタ。
【請求項１０】
前記日付キーおよび時間帯キーの論理的機能は１つの物理キーに組み合わせられ、
前記日付キー値のセットは、複数の今週、今日、この６０分間隔、この３０分間隔、この１５分間隔、昨年、昨月、昨週、昨日、前の６０分間隔、前の３０分間隔、前の１５分間隔、来年、来週、来月、明日、次の６０分間隔、次の３０分間隔、次の１５分間隔、この会計年度、この会計半年度、この会計四半年度、この特定用途向け時間間隔、前の会計年度、前の会計半年度、前の会計四半年度、前の特定用途向け時間間隔、次の会計年度、次の会計半年度、次の会計四半年度、および次の特定用途向け時間間隔に関連付けられる、請求項６に記載のコンタクト・センタ。
【請求項１１】
（ａ）第１の時間帯および期間の選択をユーザから受け取ること、
（ｂ）前記第１の時間帯に対応する第１の時間帯キーを選択すること、および
（ｃ）複数の日付ディメンション表の中から、前記選択された第１の時間帯キー用の第１の日付ディメンション表を選択すること、
を備える、方法であって、
前記第１の日付ディメンション表は前記選択された期間を備え、前記複数の日付ディメンション表のそれぞれは、時間帯キーの単一の値および日付キーの複数の値に対応し、
前記日付キーは、選択された時間的起点に関して選択された時点を識別し、前記時間帯キーは複数の可能な時間帯の内の１つを識別する、方法。
【請求項１２】
前記日付キーは、１秒、１分、１５分、３０分、および６０分の間隔の内の少なくとも１つで、前記選択された時間的起点からの経過時間を定義し、
前記日付キーは特定の時間帯とは無関係のタイミング規則の時間単位で表され、
少なくとも１つの属性は前記時間帯キーおよび日付キーに対応し、
前記少なくとも１つの属性は、複数の夏時間インジケータと、選択された世界時システムに関するオフセット文字列と、前記選択された日付および時間帯キー・ペアに対応する年と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算月と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算週と、前記選択された日付および時間帯キー・ペアに対応する１年の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１月の内の通算日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の曜日と、前記選択された日付および時間帯キー・ペアに対応する１週の内の相対順序曜日と、前記選択された日付および時間帯キー・ペアに対応する１日の内の時間と、前記選択された日付および時間帯キー・ペアに対応する１時間の内の分と、前記選択された日付および時間帯キー・ペアに対応する会計年度と、前記選択された日付および時間帯キー・ペアに対応する会計半年度と、前記選択された日付および時間帯キー・ペアに対応する会計四半年度と、前記選択された日付および時間に対応する特定用途向け時間間隔と、を備える、請求項１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にデータ・ウェアハウジングに関し、具体的には、コンタクト・センタでのデータ・ウェアハウジングに関する。
【背景技術】
【０００２】
多くの企業では、自動着信分配すなわちＡＣＤシステムなどのコンタクト・センタを利用して顧客とのコンタクトを処理している。典型的なコンタクト・センタは、着信するパケット交換済みおよび／または回路交換済みのコンタクトを受信およびルーティングするためのスイッチおよび／またはサーバと、着信するコンタクトを処理するための、人間のエージェントおよび自動化リソース（たとえば音声自動応答（ＩＶＲ）ユニット）などの１つまたは複数のリソースとを含む。コンタクト・センタは、インバウンドまたはアウトバウンドにかかわらず、事前に定義された基準に従って任意の好適なリソースに対する処理を行うためにコンタクトを分配する。一般に現在のＡＣＤでは、エージェントがコンタクトを処理できるようになったことをＡＣＤシステムの制御装置が検出した場合、制御装置はエージェントのすべての事前に定義されたコンタクト処理スキルを（通常は何らかの優先順位で）識別し、エージェントの最高優先順位スキルに合致する最高優先順位の最も古いコンタクトを、エージェントに送達する。
【０００３】
着信分配アルゴリズムを含むコンタクト・センタ管理の主な目的は、コンタクト・センタの性能および収益性を最終的に最大にすることである。コンタクト・センタ管理における現行の課題は、コンタクト・センタ・リソースの使用を最適化するため、およびエージェントの性能および収益性を最大にするために、エージェントの挙動を監視することである。Ａｖａｙａ  Ｉｎｃ．，によるＣａｌｌ  Ｍａｎａｇｅｍｅｎｔ  ＳｙｓｔｅｍすなわちＣＭＳ（商標）およびＡｖａｙａ  Ｉｎｃ．，によるＯｐｅｒａｔｉｏｎａｌ  ＡｎａｌｙｓｔすなわちＯＡ（商標）などの、コンタクト・センタの性能を監視および報告するための現在の製品は、複数のソースからデータを抽出し、そのデータを標準化形式に変換し、そのデータをデータ・ウェアハウス・データベースにロードする、データ・ウェアハウスとして構成される。バッチ・ロード後に、追加の計算および報告を実行することができる。理解されるように、日付および時刻を正確に追跡することは、コンタクト・センタ監視にとって不可欠である。基本的な測定結果は、エージェントが時間をどのように使っているか、およびコンタクト・センタが経時的にいかに効果をあげているか、に関するものである。
【０００４】
コンタクト・センタにおいて基本的な性能測定を行うことは、決して単純なタスクではない。コンタクト・センタ・データの時間スケールは非常に大きい。発生した時刻に従って単にイベントにラベル付けすること（たとえば、２００５−１０−０１  ０１：００：００）に加えて、コンタクト・センタ・クロックは、（たとえば前の例において、ある時間帯では秋の夏時間移行日であるため、クロック時間が、同日の第２時間および第３時間の両方の開始であることを知るために）時間を均等に分割できるように、イベントを含む様々なサイズの間隔でイベントにタグ付けもしなければならない。詳細スケールのデータは、少なくとも１秒（好ましくは１ミリ秒）の精度で記録しなければならず、１秒に約１０００行の速さで着信する、すなわちスケールは約０．００１秒である。広域スケールのデータは、通常、３年間またはそれ以上、すなわち、１億秒間維持される。したがって、広域スケール・データは詳細スケール・データの１０００億倍である。
【０００５】
地球規模のたとえ単一のコンタクト・センタ報告センタであっても、日付および時刻を処理するにはさらなる柔軟性が必要である。ローカル監視プログラムがエージェントを管理しているローカル時間帯、および、企業管理がコンタクト・センタ全体を管理している企業またはクライアント特有の時間帯では、同じデータを等しく提示可能でなければならない。たとえば、企業（たとえば地域的または地球的な）レベルでは、ローカル・センタ間でのトラフィック・ロードのバランシングを分析するため、および契約上のサービス目標が満たされていることをクライアントに実証するために、異なる共通時間帯にある同じ性能データが結び付けられる。特定の報告システムに必要な時間帯セットは、通常、サポートされている様々なセンタの場所に依存するため、システム構成によって変化する。
【０００６】
地球時間帯は、一般に理解されているよりも多様である。世界中にはグリニッジを基準にして時差が３０分単位の領域にある時間帯が１６あり、その中でもコンタクト・センタにとって重要な市場はインドである。さらに、１５分単位の領域にある時間帯も２つある（その１つはネパール）。分単位の時間帯があることによって、地球時間帯の単純な数は２４から４２まで増加している。しかしながら、地球時間帯を圧倒的に複雑にしているのは夏時間である。時間帯は、夏時間を導入しているかどうかによってだけでなく、いつ夏時間を実行するかによって区別される。秋および春の移行時期は、年間通算日によって異なり（たとえば、ヨーロッパは３月の最終日曜日に入るが、米国では現在、４月の第１日曜日に入る）、また時刻によっても異なる（たとえば、午前３時、午前２時、午前１時、および午後１１時４５分）。夏時間の影響により、地球時間帯は５００を超える（Ｊａｖａ（登録商標）  ｖ．５では５６１と認識している）数にのぼっている。
【０００７】
夏時間規則は異なるだけでなく、変化する。米国では、夏時間の期間が２００７年から春に３週間、秋に１週間延長されることになる。２００６年、インディアナ州では、この地方特有の慣習であった３つの時間帯を打ち切っている。夏時間規則は非常に複雑であるため、Ｇｏｏｇｌｅ（商標）でこの規則を検索した場合、アルゴリズムではなく当年度の予測が見つかることになるであろう。さらに悪いことに、Ｊａｖａ（登録商標）の時間帯の知識では、規則の変動履歴を表示しようとはせず、現在の規則のみが表示される。
【０００８】
既存のコンタクト・センタ報告システムは、すべてのデータを単一の世界時間帯（ＵＴＣ、別名はＧＭＴ）で格納し、すべての時間帯変換の責務を特別な報告専売権付きソフトウェアに譲る。報告コードは、３０分粒度の範囲の要約データを報告ユーザの時間帯に再マッピングすることができたが、毎日、毎週、および毎月粒度の要約はＯＡではＡｒｃｈｉｖｅ  Ｔｉｍｅ  Ｚｏｎｅ（ＡＴＺ）と呼ばれる好ましい時間帯に制約される。選択はユーザによるものではなく、データ内に凍結されたものであるため、この時間帯は、データを要約する前に選択しなければならなかった。国際時間帯および夏時間規則の独自性により、報告におけるすべての時間帯変換を処理する手法は、報告ソフトウェアを第三者のＯｎＬｉｎｅ  Ａｎａｌｙｔｉｃａｌ  Ｐｒｏｃｅｓｓｉｎｇ（ＯＬＡＰ）ツールにとってかなり複雑なものにした。その結果、こうしたツールは、結果をデータの世界時間帯でのみ表示しなければならなくなり、多くの場合、作業日のグラフをＵＴＣの午前零時をはさんで２つに分けることになる。
【０００９】
データ・ウェアハウス技法を使用してデータを編成しているコンタクト・センタ報告システムは、ますます増えてきている。ディメンション・モデリングまたはデータ・ウェアハウジングにおいて、数値性能メジャー（通常は加算されるもの）は、「ディメンション表」内に維持される記述属性（名前および識別子など）とは別に、特別な「ファクト表」で維持される。ファクト表内の外部キーは、メジャーと、メジャーが記述する個々のディメンション行とをリンクする。通常、メジャーは異なるディメンションからのエンティティの組合せに関する（たとえば、キュー・ディメンションの特定のキュー内の呼び出しに応答するエージェント・ディメンションからの特定のエージェントに関する）ものとすることができるため、ファクト表には複数の外部キーがある。
【００１０】
データ・ウェアハウスは、データおよび時刻を単一のディメンションとして処理するものと示唆されてきたが、この手法は、結果として生じるディメンション表が法外なサイズになるため、従来技術では却下される。１年は３１００万秒を超えるため、１０年分のデータを１秒分解能（ｒｅｓｏｌｕｔｉｏｎ）で維持するには、そのディメンション表内に３億１０００万行以上が必要となる。代わりに、標準的な技法は、データおよび時刻を劇的に小さなサイズ（１０年分のデータ・ディメンションでは３，６５０行、および、１分または１秒のいずれかの分解能のための時刻ディメンションではそれぞれ１，４４０または８６，４００行）の別々のディメンションに分割するものである。近年、この標準技法は、日付および時刻ディメンションを指す外部キーに加えて、ファクト表内に別々のメジャーとして完全な日付時刻のタイム・スタンプを含むように改善されてきた。他の変形形態では、時刻ディメンションをまったく省いている。すべてのケースにおいて、複数の時間帯は、ファクト表内に複数の外部キー／タイム・スタンプのセットを必要とする。
【００１１】
時間帯の処理は、従来のディメンション・データ・モデルにとっての弱点である。これらのモデルは、たとえ単一の時間帯であっても夏時間移行日の時間分割に失敗する（たとえば、夏時間からの移行日における第２および第３の時間からのデータを一括にしてしまい、２３時間および２５時間の日の認識がない）。データベース空間における（結果としてアクセス速度における）時間帯に費やすコストによって、報告に必要な時間帯のサポートが十分にできない（時間帯を４つしか備えていない典型的なウェアハウスは、すでにそのスペースのほとんどをタイム・スタンプのみに使用している）。また、タイム・スタンプは最も大きなデータベース表に凍結されているため、データ・ウェアハウスの存続期間中に（１週間にわたるデータ・マイグレーションのためにコンタクト・センタをシャットダウンすることなく）サポートされている時間帯の選択を変更することができない。日付および時刻ディメンションで複数の時間帯を記述するために複数のタイム・スタンプを使用しようとすると（異なる時間帯から見て同じ瞬間に対する同義ラベルなど）、時間帯が異なる場合は日付および時刻が一致しない時間があるために失敗する。この障害を理解する他の方法は、日付ディメンションにおいて特定の日付を選択することは、その日付の選択に一致する時間帯のみを支持することに等しいと理解することである。複数の時間帯情報をファクト表に入れると、データベースのサイズが著しく大きくなり、結果としてデータベースの性能は低下する（速度が遅くなる）。大規模なファクト表の場合、すべてのファクト表の行を完全に書き換えること、および（さらに多くの時間帯を含めるためには）スキーマの変更をも必要とするため、どの時間帯をサポートするべきかを変更できないことを意味する。ファクト表におけるこうした大量の変更については、データ・マイグレーションに１週間またはそれ以上のダウン・タイムを必要とする経験から知られている。
【特許文献１】米国特許第６１９２１２２号
【特許文献２】米国特許第６１７３０５３号
【特許文献３】米国特許第６１６３６０７号
【特許文献４】米国特許第５９８２８７３号
【特許文献５】米国特許第５９０５７９３号
【特許文献６】米国特許第５８２８７４７号
【特許文献７】米国特許第５２０６９０３号
【非特許文献１】ＤＥＦＩＮＩＴＹ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ  Ｇｅｎｅｒｉｃ３  Ｃａｌｌ  Ｖｅｃｔｏｒｉｎｇ／Ｅｘｐｅｒｔ  Ａｇｅｎｔ  Ｓｅｌｅｃｔｉｏｎ（ＥＡＳ）Ｇｕｉｄｅ、ＡＴ＆Ｔ  ｐｕｂｌｉｃａｔｉｏｎ  ｎｏ．５５５−２３０−５２０（１９９３年１１月第３版）
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の様々な実施形態および構成は、これらおよび他のニーズに対処する。
【課題を解決するための手段】
【００１３】
本発明は一般に、複数の国際時間帯を横切ってイベントを報告するのに好適なデータ・ウェアハウス・クロックを対象とする。クロックは、データベースの表内でのデータの配置構成によって実行される。この配置構成は、データ・ウェアハウスのディメンション・データ・モデルにおけるファクト表とディメンション表との間の関係を含む。データ・ウェアハウス・クロックは任意のデータ・ウェアハウス・アプリケーションで有用であり、特に、データ・ウェアハウス技術をコンタクト・センタの報告に適用する際に適用可能である。新しい構造は、ファクト表のサイズを、従来技術の日付および時刻ディメンション表に比べてかなり縮小させることができる。
【００１４】
本発明の一実施形態では、日付ディメンションは少なくとも時間まで細分された時刻情報を含む。時間帯に依存する典型的な時刻ディメンションにおける任意の情報（たとえば時刻）が、日付ディメンションに移動される。時間帯の中にはオフセットまたは４５分単位の移行時間を有するものがわずかにあるため、Ｊａｖａ（登録商標）によって認識される５６１の世界時間帯のほとんどを処理するために、好ましくは、日付ディメンションは少なくとも１５分単位まで細分される。サポートされる時間帯のリストがさらに制限されるアプリケーションでは、日付ディメンションを、３０分単位（インドおよび１５の他の３０分オフセット時間帯を処理するため）または１時間単位粒度（５４３の時間帯を完全な時間オフセットで処理する）までのみ細分することが可能であり、日付ディメンションにおける行数がその分だけ節約される（たとえば、１時間粒度の日付ディメンション表は、１５分粒度の４分の１、１分粒度の６０分の１まで短くなる）。日付キー（日付ディメンション表の基本キーの一部である）は、物理的に連続した時間間隔を設計された粒度での（たとえば連続する１５分間隔）、システムの存続期間にわたる（たとえば１０年）列挙を表す。他の実施形態では、日付ディメンションは、１分などの非常に詳細な粒度まで細分することが可能である。
【００１５】
従来技術における日付および時刻ディメンションの分割は、データ・ウェアハウスが有する時間帯に伴う諸問題の根本原因であると考えられる。夏時間とは、クロック時間がその日の間隔をマッピングする方法において、何日か（移行日）が他の日と異なることを意味する。しかしながら、時刻は日付とは別のディメンションにあるため、特定の日付であるにもかかわらず時刻は同じ方法で扱われなければならず、移行日の実際の挙動は決して正確には表されない。日付と時刻の分離も、ファクト表において複数の時間帯が外部キーの複数のコピーを必要とするという理由からである。
【００１６】
一構成では、日付ディメンションは複数の時間帯での表現を含む。日付ディメンションにおける情報は時間帯に依存する（物理的に同じ実時間の１５分間隔に関して、異なる時間帯は異なるカレンダおよびクロックの値を有する）ため、日付ディメンションは、システムが構成されてきたいくつかの時間帯に関するこの情報の複数のバージョンを含む。データベースに関して、これは、複数列の情報を同じ行に含めることによって、またはより一般的には、同じ１５分間隔を記述する複数の行を含めることによって、実施可能である。後者の場合、追加の行は時間帯を識別する追加の列によって区別される（その後、この列は、日付ディメンション表用の２構成要素の基本キーを形成するために日付キーと共に含められる）。
【００１７】
一構成では、時刻ディメンションは時間帯に依存しない。時刻ディメンションの残りのデータは、日付ディメンションによって記述される１５分または１時間粒度内で、秒単位（またはさらにミリ秒単位）まで細分された時刻を記述する。日付ディメンションが１５分単位まで細分された場合、典型的な時刻ディメンションは、１５分中にある９００の個別の秒に対応した、少なくとも９００の行を有することになる。分解能がミリ秒の場合、極端な時刻ディメンションは、９００，０００行を有することになる。いずれの場合も、情報コンテンツは、時間帯とは関係のない日付時刻の細粒化された部分を表す。
【００１８】
一構成では、ファクト表は、時間帯とは関係のない日付キーおよび時刻キーによって、時間内のある時点を参照する。現在日付ディメンションに含まれるすべての時間帯の依存性により、ファクト表はもはや、複数の時間帯をサポートするために複数の外部キーを維持する必要がない。これらの大規模なファクト表は、ある時間の同義表現への複数の参照ではなく、その時間の物理的時点への単一の参照をすることができる。
【００１９】
一構成では、使用される特定の時間帯がビューワによって選択される。ファクト表内で維持される日付キーは、新しい日付ディメンションに必要な基本キーの一部に過ぎないため、基本キーの他の部分（時間帯キー）は外部的に供給される。通常、この情報は、報告が実行された場合に供給されるパラメータから得られる。報告ユーザのコンピュータのロケール環境、ユーザによって明示的に指示された選択、または報告ツールによって供給されたデフォルト値から推論される。
【００２０】
本実施形態は、従来技術の諸問題を克服することができる。
第１に、夏時間移行をすべての時間帯で正確に記述することができる。日付キーは、特定のクロック時間ではなく物理的に連続する１５分を記述するため、アプリケーションは、それらの間隔の公称の日付時刻が同じ（たとえば午前１時）である場合、たとえ秋の夏時間移行日であっても、たとえば第２の時刻と第３の時刻とを区別することができる。同様に、春の移行日に、何らかの移行帯にある）クロックが進められる場合、物理的間隔が「欠落」することはない。
【００２１】
第２に、複数の時間帯をサポートすることが、必ずしも大幅なスペース／時間のペナルティを負うことはない。ここでファクト表は時間帯と無関係であるため、データベース全体のサイズが大幅に減少する。理解されるように、データ・ウェアファイルをサイズ変更する場合、常にファクト表の方がディメンション表よりも圧倒的であるため、ファクト表の節約は日付ディメンションの拡張に桁違いに影響する。
【００２２】
第３に、時間帯の追加または変更はいつでも実行可能である。すべての時間帯同義語は、ファクト表に比べて小規模かつ静的なディメンション表に格納されるため、個々の時間帯に関するサポートの追加、修正、または除去は、比較的重要でないデータベース操作である。こうした変更は、コンタクト・センタ操作のビジー時間中であっても実行可能である。本発明を使用しない場合、時間帯追加に必要な等価のデータ・マイグレーションを実行するためには、大規模なコンタクト・センタであれば１週間またはそれ以上のクローズを必要とする可能性がある。
【００２３】
第４に、時間帯の規則を正確かつ独立に処理することができる。時間帯が単に時間オフセットによって特徴付けられるという単純な想定とは異なり、本発明は、好ましくは、各時間帯に対して異なる規則セットを使用することにより、世界の５６１の時間帯すべてを正確かつ独立に取り扱う。規則セットは、各時間帯における移行日、オフセット（あれば）、および時刻を精密に記述する。たとえば、緊急時における地方または国の条例（たとえば、米国では戦時中に夏時間を一年中維持し、最近ではガソリン不足の際に、燃料を節約するために夏時間を早期に開始した）による、特定の時間帯における何らかの変更は、規定の規則セットを変更すること、および日付ディメンションのその部分を再生成することによって、すなわち、任意の他の時間帯または前の期間に影響を与えることなく、特定の期間中の特定の時間帯について、処理可能である。さらに一般には、すべての時間帯が、同じ日付または時刻で夏時間からまたは夏時間へ移行するとは想定されない。最終的に、本発明は、好ましくは異なる時間帯を横切る異なるバージョンの日付ディメンションを使用することによって、異なる時間帯は単に同じディメンションへの異なる追加オフセットに対応するという、一般的に誤った考え方を回避する。前述のように、夏時間の影響を考慮すると、任意の時間帯の有効なＧＭＴオフセットは一定ではなく、それ自体が時間帯に依存するように時刻および日付と共に変化する。
【００２４】
これらおよび他の利点は、本明細書に含まれる本発明の開示から明らかとなろう。
本明細書で使用される場合、「少なくとも１つ」、「１つまたは複数」、および「および／または」は、動作が接続的および離接的の両方である、制約のない表現である。たとえば、「Ａ、Ｂ、およびＣの内の少なくとも１つ」、「Ａ、Ｂ、またはＣの内の少なくとも１つ」、「Ａ、Ｂ、およびＣの内の１つまたは複数」、「Ａ、Ｂ、またはＣの内の１つまたは複数」、および「Ａ、Ｂ、および／またはＣ」の各表現は、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ共に、ＡおよびＣ共に、ＢおよびＣ共に、または、Ａ、Ｂ、およびＣ共に、を意味する。
【００２５】
前述の諸実施形態および諸構成は、いずれも完璧または網羅的ではない。理解されるように、本発明の他の諸実施形態は、前述の、または以下で詳細に説明する特徴の内の１つまたは複数を、単独で、または組み合わせて使用することが可能である。
【発明を実施するための最良の形態】
【００２６】
本発明について、例示的通信システムに関して以下で説明する。本発明は、たとえばＡＣＤまたは他の同様のコンタクト処理スイッチを有するシステムで使用するのに好適であるが、いかなる特定タイプの通信システム・スイッチまたはシステム要素の構成での使用にも限定されるものではない。当業者であれば、開示された技法が、改良されたイベント（たとえばコンタクト）処理を提供することが望ましい任意の通信アプリケーションで使用可能であることを理解されよう。
【００２７】
図１は、本発明の例示的実施形態を示す。コンタクト・センタ１００は、中央サーバ１１０と、コンタクトまたは顧客関連情報、エージェント情報、ならびに、コンタクト・センタの操作の値および効率を拡張することが可能な他のコンタクト・センタ情報を含む、データ・ストアまたはデータベースのセット１１４と、複数のサーバ、すなわち音声メール・サーバ１１８と、音声自動応答ユニットすなわちＩＶＲ  １２２と、他のサーバ１２６（予測ダイヤラなど）、スイッチ１３０と、複数の作業エージェント操作パケット交換（第１の）通信デバイス１３４−１からＮ（コンピュータ・ワークステーションまたはパーソナル・コンピュータ）と、および／または回路交換（第２の）通信デバイス１３８−１からＭとを備え、すべてがローカル・エリア・ネットワークＬＡＮ（またはワイド・エリア・ネットワークＷＡＮ）１４２によって相互接続される。サーバはオプションの通信回線１４６を介してスイッチ１３０に接続することができる。理解されるように、他のサーバ１２６はスキャナ（通常はスイッチ１３０またはウェブ・サーバに接続されない）、ＶｏＩＰソフトウェア、ビデオ通話ソフトウェア、音声メッセージング・ソフトウェア、ＩＰ音声サーバ、ファックス・サーバ、ウェブ・サーバ、および電子メール・サーバ、その他を含むこともできる。スイッチ１３０は複数のトランク１５０を介して公衆交換通信網すなわちＰＳＴＮ  １５４へ、およびリンク１５２を介して第２の通信デバイス１３８−１からＭへと接続される。ゲートウェイ１５８は、サーバ１１０とパケット交換網１６２との間を通る通信を処理するために、サーバ１１０と網１６２との間に配置される。
【００２８】
本明細書で使用される「スイッチ」または「サーバ」という用語は、ＰＢＸ、ＡＣＤ、エンタープライズ・スイッチ、または他のタイプの通信システム・スイッチもしくはサーバ、および、メディア・サーバ、コンピュータ、付属品などの他のタイプのプロセッサ・ベースの通信制御デバイスを含むものと理解されたい。
【００２９】
スイッチ１３０および／またはサーバ１１０は、コンタクトを１つまたは複数の通信デバイスに向けて送るための任意のアーキテクチャとすることができる。例示的に、スイッチおよび／またはサーバは、参照によりすべてが本明細書に組み込まれた米国特許第６１９２１２２号、第６１７３０５３号、第６１６３６０７号、第５９８２８７３号、第５９０５７９３号、第５８２８７４７号、および第５２０６９０３号に開示された加入者構内機器の修正された形、Ａｖａｙａ  Ｉｎｃ．のＤｅｆｉｎｉｔｙ（商標）構内交換機（ＰＢＸ）ベースのＡＣＤシステム、ＭｕｌｔｉＶａｎｔａｇｅ（商標）ＰＢＸ、ＣＲＭ  Ｃｅｎｔｒａｌ  ２０００  Ｓｅｒｖｅｒ（商標）、通信マネージャ（商標）、Ｓ８３００（商標）メディア・サーバ、ならびに／またはＡｖａｙａ  Ｉｎｔｅｒａｃｔｉｏｎ  Ｃｅｎｔｅｒ（商標）、とすることが可能である。通常、スイッチ／サーバは、従来は、外部通信リンク、通信スイッチング・ファブリック、サービス回路（たとえばトーン・ジェネレータ、告知回路など）、制御プログラムおよびデータを格納するためのメモリ、ならびに、インターフェースとファブリックとを制御するため、および自動コンタクト分配機能を提供するために、内蔵制御プログラムを実行するための、プロセッサ（すなわちコンピュータ）への、インターフェースを含む、プログラム内蔵制御システムである。スイッチおよび／またはサーバは、通常、サービス受取側通信デバイスにサービスを提供するための、ネットワーク・インターフェース・カード（図示せず）を含む。当技術分野では他のタイプの既知のスイッチおよびサーバがよく知られているため、本明細書では詳細に説明しない。
【００３０】
ゲートウェイ１５８は、Ａｖａｙａ  Ｉｎｃ．のＧ７００  Ｍｅｄｉａ  Ｇａｔｅｗａｙ（商標）などのプロトコルを変換するための任意の好適なデバイスとすることが可能であり、付属のプロセッサ（図示の通り）を介するなどのハードウェアとして、またはサーバ内のチップとして、実施することが可能である。
【００３１】
第１の通信デバイス１３４−１、．．．１３４−Ｎはパケット交換型であり、たとえばＡｖａｙａ  Ｉｎｃ．の４６００  Ｓｅｒｉｅｓ  ＩＰ  Ｐｈｏｎｅｓ（商標）などのＩＰハードフォン、Ａｖａｙａ  Ｉｎｃ．のＩＰ  Ｓｏｆｔｐｈｏｎｅ（商標）などのＩＰソフトフォン、携帯情報端末すなわちＰＤＡ、パーソナル・コンピュータすなわちＰＣ、ラップトップ、パケット・ベースのＨ．３２０テレビ電話および会議ユニット、パケット・ベースの音声メッセージングおよび応答ユニット、パケット・ベースの従来型コンピュータ電話付属品、ならびに任意の他の通信デバイスを含むことができる。
【００３２】
第２の通信デバイス１３８−１、．．．１３８−Ｍは回路交換型であり、たとえば有線および無線電話、ＰＤＡ、Ｈ．３２０テレビ電話および会議ユニット、音声メッセージングおよび応答ユニット、従来型コンピュータ電話付属品、ならびに任意の他の通信デバイスを含むことができる。
【００３３】
本発明は、スイッチまたはサーバと第１および第２の通信デバイスとの間に任意の特定タイプの情報移送媒体を必要としない、すなわち、本発明は任意の所望のタイプの移送媒体、および異なるタイプの移送チャネルの組合せで実施できることに留意されたい。
【００３４】
パケット交換網１６２は、任意のデータ、および／またはインターネットなどの分散処理ネットワークとすることができる。
パケット交換網１６２は、ゲートウェイ１７８を介して外部の第１の通信デバイス１７４と通信し、回路交換網１５４は外部の第２の通信デバイス１８０と通信する。
【００３５】
図１に示されたようなスイッチ、サーバ、ユーザ通信デバイス、および他の要素の構成は例示のためのみのものであり、本発明を任意の特定の要素配置構成に限定するものとして解釈すべきでないことを重視されたい。
【００３６】
図２を参照すると、サーバ１１０の１つの可能な構成が示されている。サーバ１１０は複数の顧客通信回線２００ａ−ｙ（１本または複数のトランク、電話回線などとすることができる）およびエージェント通信回線２０４（ＬＡＮ  １４２などの音声およびデータ伝送回線ならびに／または回路交換音声回線１４０）と通信する。サーバ１１０は、コンタクト・センタ報告を生成する際に使用するための呼び出し記録およびコンタクト・センタ統計を収集する、Ｂａｓｉｃ  Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（商標）すなわちＢＣＭＳ、Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（商標）、および／またはＡｖａｙａ，Ｉｎｃ．によるＯｐｅｒａｔｉｏｎａｌ  Ａｎａｌｙｓｔ（商標）の修正済みの形などの、イベント処理モジュール２２８を含むことができる。
【００３７】
サーバ１１０に格納されるデータの中には、コンタクト・キューのセット２０８ａ〜ｎおよび別のエージェント・キューのセット２１２ａ〜ｎが含まれる。各コンタクト・キュー２０８ａ〜ｎは、各エージェント・キュー２１２ａ〜ｎと同様に、異なるエージェント・スキル・セットに対応する。従来から、コンタクトは優先順位付けされ、いずれも個々のコンタクト・キュー２０８ａ〜ｎ内に優先順にエンキューされるか、または異なる優先順位に対応する複数のコンタクト・キューの内の異なるキューにエンキューされる。同様に、各エージェントのスキルはそのスキルの専門知識についての自分のレベルに従って優先順位付けされ、いずれのエージェントもその専門知識レベルの順に個々のエージェント・キュー２１２ａ〜ｎ内にエンキューされるか、またはスキルに対応する複数のエージェント・キュー２１２ａ〜ｎの内の異なるキューおよび異なる専門知識レベルに対応するそれぞれのキューにエンキューされる。サーバ１１０内の制御プログラムの中には、コンタクト・ベクトル２１６が含まれる。コンタクト・センタに着信するコンタクトは、顧客の識別、顧客のニーズ、コンタクト・センタのニーズ、現在のコンタクト・センタ・キュー長さ、顧客値、およびコンタクトの正しい処理に必要なエージェント・スキルを含む、いくつかの所定の基準に基づいて、コンタクト・ベクトル２１６によって異なるコンタクト・キュー２０８ａ〜ｎに割り当てられる。コンタクトを処理するために使用可能なエージェントは、それらが所有するスキルに基づいてエージェント・キュー２１２ａ〜ｎに割り当てられる。エージェントは複数のスキルを有することが可能であるため、複数のエージェント・キュー２１２ａ〜ｎに同時に割り当てることができる。さらにエージェントは、異なるレベルのスキル専門知識（たとえば、１つの構成におけるスキル・レベル１〜Ｎ、または他の構成における単なる１次スキルおよび２次スキル）を有することができるため、異なる専門知識レベルで異なるエージェント・キュー２１２ａ〜ｎに割り当てることができる。呼び出しのベクトル化については、ＤＥＦＩＮＩＴＹ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ  Ｇｅｎｅｒｉｃ３  Ｃａｌｌ  Ｖｅｃｔｏｒｉｎｇ／Ｅｘｐｅｒｔ  Ａｇｅｎｔ  Ｓｅｌｅｃｔｉｏｎ（ＥＡＳ）Ｇｕｉｄｅ、ＡＴ＆Ｔ  ｐｕｂｌｉｃａｔｉｏｎ  ｎｏ．５５５−２３０−５２０（１９９３年１１月第３版）に記載されている。スキル・ベースのＡＣＤについては、米国特許第６１７３０５３号および第５２０６９０３号に詳細に記載されている。
【００３８】
コンタクト管理システム２２８は、好ましくはＡｖａｙａ（商標）Ｃｕｓｔｏｍｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ（商標）製品（たとえば、Ｂａｓｉｃ  Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  ＳｙｓｔｅｍすなわちＢＣＭＳ（商標）、Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  ＳｙｓｔｅｍすなわちＣＭＳ（商標）、およびＯｐｅｒａｔｉｏｎａｌ  Ａｎａｌｙｓｔ（商標））の修正済みの形であり、コンタクト・センタ内で着信および／または送信するコンタクトに関する詳細な情報を収集する。コンタクト管理システム２２８は、主メモリまたは周辺メモリ（たとえばディスク、ＣＤ  ＲＯＭなど）、あるいはセンタ１００の何らかの他のコンピュータ読み取り可能媒体のいずれかに格納される。
【００３９】
コンタクト管理システム２２８は、時間帯の影響を考慮するためにファクト表およびディメンション表などのデータ構造を更新するための時間帯報告サブシステム２５０を含む。報告サブシステム２５０は、日付および時刻を単一のディメンションに組み合わせる。一構成では、日付ディメンションは、選択された開始日付および時刻規則（たとえば１９７０年以降のＵＴＣ）に関して、選択された粒度（たとえば分）まで時刻を識別する日付キーと、複数の選択された時間帯に対応する複数の値を有する時間帯キーとを含む、組み合わせられた日付／時間帯ディメンション内に拡張される。この組合せによって、複数の時間帯について同じ日付キーで複数の解釈が存在することになる。ファクト表は、（好ましくはＵＴＣベースの）キー・セット、すなわち日付キー（好ましくは１９７０年以降のＵＴＣ分）、時刻キー（たとえば０から５９秒）、および好ましくはＵＴＣベースの日付時刻キー（共通データベース日付時刻データ型）を、１つしか使用しない。ディメンションは、指定された時間帯に変換される。この構成により、ユーザは、所望の報告を生成するために使用する時間帯を選択することができる。
【００４０】
図４は、報告サブシステム２５０が使用するデータ・モデルを示す。
ＴｉｍｅＺｏｎｅＤｉｍすなわち時間帯ディメンション４００は、ＴｉｍｅＺｏｎｅＫｅｙすなわち時間帯１次キー、ならびにＴｉｍｅＺｏｎｅＮａｍｅすなわち時間帯名およびＴｉｍｅＺｏｎｅＰｒｏｍｐｔすなわち時間帯プロンプトなどの属性を備える。時間帯名とは、Ｊａｖａ（登録商標）時間帯ＩＤ命名規則を使用して、Ｊａｖａ（登録商標）プログラミング言語によって認識された数百の時間帯の中から１つを識別する、時間帯の名前であり、時間帯プロンプトとは、報告仕様で時間帯を選択するようにプロンプトが出される場合、報告ユーザに示される時間帯の名前である。この表は、システムが報告をサポートするように構成された時間帯を記述する。グリニッジ・オフセット、夏時間オフセット、および夏時間移行時間が、選択された粒度（たとえば１分）に対応するいかなる時間帯も、この表の候補である。時間帯は、表ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍとの関係が維持される限り、システムの実行中に追加または除去することができる。時間帯キーは、複数の異なる時間帯に対応する複数の可能な値を有する。表は、報告仕様に使用可能な時間帯のリストを作成するために使用される。
【００４１】
ＣｕｒｒｅｎｔＤａｔｅＫｅｙすなわち現在日付キー表４０４は、現在の日付および時刻に対応するＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ内の特定の行を識別する１行を含む。
ＰｅｒｉｏｄＣｈｏｉｃｅすなわち期間選択表４０８は、ＰｅｒｉｏｄＣｈｏｉｃｅＫｅｙすなわち期間選択キーおよびＰｅｒｉｏｄＣｈｏｉｃｅＮａｍｅすなわち期間選択名を備え、報告プロンプトを作成するための報告期間仕様の選択肢をリスト表示する。期間選択キーとは、ある報告に関する報告期間の選択を定義するパラメータであり、期間選択名とは、たとえば「今日」または「年初来」などの期間選択文字列である。
【００４２】
ＧｒａｉｎＣｈｏｉｃｅすなわち粒度選択表４１２は、報告プロンプトを作成するための報告粒度仕様の選択肢をリスト表示する。これは、ＧｒａｉｎＣｈｏｉｃｅＫｅｙすなわち粒度選択キーまたはある報告に関する報告粒度の選択を定義するパラメータと、ＧｒａｉｎＣｈｏｉｃｅＮａｍｅすなわち粒度選択名、あるいはたとえば「曜日」または「毎月の傾向」などの粒度選択文字列とを含む。
【００４３】
ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍすなわち日付／時間帯ディメンション４１６は、システム内の日付および時刻の複数の同義表現を、報告に必要なすべての時間帯について、選択された粒度（たとえば１分）まで提供する。一実施形態では、この表内には、システムの履歴における分ごと、および報告が構成された時間帯ごとに、１行（すなわち、表ＴｉｍｅＺｏｎｅ内で構成された各時間帯について、１年３６５日では５２５，６００行）が存在する。これにより、たとえ移行日中であっても、また夏時間規則が歴史的に変更される場合であっても、グリニッジを基準とする様々なオフセットの影響のみならず、ローカルな夏時間規則の特異性をも処理する１つのディメンションに、すべての時間帯の影響を捕捉することができる。このディメンション表における各行は、この行が属するより大きな時間の単位（たとえば週および月）を記述するために、かつそれらのより大きな時間の単位に従ったナビゲーションおよびグループ化を容易にするために、同じディメンション表および他のディメンション表内の関係する行を指すことになる。
【００４４】
日付／時間帯ディメンション４１６は、以下にリスト表示するような多くの変数を含むことができる。
ＤａｔｅＫｅｙすなわち日付キーは、分単位まで細分されたエポック内の特定の時点を識別する整数である。これは、１９７０年以降のＵＴＣ分の整数に等しい。
ＴｉｍｅＺｏｎｅＫｅｙ、すなわち外部キーについては、以前に確認した。
【００４５】
ＦｕｌｌＤａｔｅＴｉｍｅすなわち全日付時刻属性は、日付時刻データ型として格納された選択された時間帯におけるこの時点に関する、年単位から、たとえば秒またはミリ秒単位などのデータベースの分解能までの、全日付である。これは、日付時刻範囲の比較で、かつ、月名および曜日を含む日付および時刻のロケールに依存した表現に対して、使用される。
【００４６】
ＤａｙｌｉｇｈｔＳａｖｉｎｇＩｎｄすなわち夏時間インジケータは、選択された時間帯におけるこの時点が、夏時間がアクティブな期間中であることを示すフラグである。これを時間帯キーと共に使用して、時間帯に関する代替の略語を選択することができる。
【００４７】
ＵＴＣＯｆｆｓｅｔＳｔｒｉｎｇすなわちＵＴＣオフセット文字列は、選択された時間帯におけるこの時点に関する、ＵＴＣを基準とする現在のオフセットである。
Ｙｅａｒは、選択された時間帯におけるこの時点に関する、数字で表された年である。
【００４８】
ＭｏｎｔｈＯｆＹｅａｒすなわち年間通算月は、選択された時間帯におけるこの時点に関する、数字で表された１年の内の通算月である。
ＷｅｅｋＯｆＹｅａｒすなわち年間通算週は、選択された時間帯におけるこの時点に関する、数字で表された１年の内の通算週である。
ＭｏｎｔｈＤａｙＯｆＹｅａｒは、選択された時間帯におけるこの時点に関する、単一の数字で表された１年の内の通算月および日である。
【００４９】
ＤａｙＯｆＹｅａｒすなわち年間通算日は、選択された時間帯におけるこの時点に関する、数字で表された１年の内の通算日である。
ＤａｙＯｆＭｏｎｔｈすなわち月間通算日は、選択された時間帯におけるこの時点に関する、数字で表された１月の内の通算日である。
ＤａｙＯｆＷｅｅｋすなわち曜日は、選択された時間帯におけるこの時点に関する、数字で表された１週の内の曜日である。
【００５０】
ＲｅｌａｔｉｖｅＤａｙＯｆＷｅｅｋすなわち相対曜日は、選択された時間帯におけるこの時点に関する、数字で表された１週の内の相対（順序）曜日である。
ＨｏｕｒＯｆＤａｙすなわち時は、選択された時間帯におけるこの時点に関する、数字で表された１日の内のクロック時である。
ＨａｌｆＨｏｕｒＯｆＤａｙは、選択された時間帯におけるこの時点に関する、数字で表された１日の内のクロック３０分である。
【００５１】
ＱｕａｒｔｅｒＨｏｕｒＯｆＤａｙは、選択された時間帯におけるこの時点に関する、数字で表された１日の内のクロック１５分である。
ＭｉｎｕｔｅＯｆＨｏｕｒは、選択された時間帯におけるこの時点に関する、数字で表された１時間の内のクロック分である
ＴｈｉｓＹｅａｒＫｅｙは、選択された時間帯におけるこの時点を含む年の開始に関するＤａｔｅＫｅｙである。
【００５２】
ＴｈｉｓＭｏｎｔｈＫｅｙは、選択された時間帯におけるこの時点を含む月の開始に関するＤａｔｅＫｅｙである。
ＴｈｉｓＷｅｅｋＫｅｙは、選択された時間帯におけるこの時点を含む週の開始に関するＤａｔｅＫｅｙである。
ＴｈｉｓＤａｙＫｅｙは、今日に関する、すなわち選択された時間帯におけるこの時点を含む日の開始に関するＤａｔｅＫｅｙである。
【００５３】
ＴｈｉｓＭｉｎ６０ＩｎｔｅｒｖａｌＫｅｙは、現在の１時間に関する、すなわち選択された時間帯におけるこの時点を含む６０分間隔の開始に関するＤａｔｅＫｅｙである。
ＴｈｉｓＭｉｎ３０ＩｎｔｅｒｖａｌＫｅｙは、現在の３０分に関する、すなわち選択された時間帯におけるこの時点を含む３０分間隔の開始に関するＤａｔｅＫｅｙである。
ＴｈｉｓＭｉｎ１５ＩｎｔｅｒｖａｌＫｅｙは、現在の１５分に関する、すなわち選択された時間帯におけるこの時点を含む１５分間隔の開始に関するＤａｔｅＫｅｙである。
【００５４】
ＰｒｅｖＹｅａｒＫｅｙは、選択された時間帯におけるこの時点を含むその年の前の年の開始に関するＤａｔｅＫｅｙである。
ＰｒｅｖＭｏｎｔｈＫｅｙは、選択された時間帯におけるこの時点を含むその月の前の月の開始に関するＤａｔｅＫｅｙである。
ＰｒｅｖＷｅｅｋＫｅｙは、選択された時間帯におけるこの時点を含むその週の前の週の開始に関するＤａｔｅＫｅｙである。
【００５５】
ＰｒｅｖＤａｙＫｅｙは、昨日に関する、すなわち選択された時間帯におけるこの時点を含むその日の前の日の開始に関するＤａｔｅＫｅｙである。
Ｐｒｅｖ６０ＩｎｔｅｒｖａｌＫｅｙすなわち前の６０分間隔キーは、前の１時間に関する、すなわち選択された時間帯におけるこの時点を含む６０分間隔の前の６０分間隔の開始に関する、ＤａｔｅＫｅｙである。
Ｐｒｅｖ３０ＩｎｔｅｒｖａｌＫｅｙすなわち前の３０分間隔キーは、前の３０分に関する、すなわち選択された時間帯におけるこの時点を含む３０分間隔の前の３０分間隔の開始に関するＤａｔｅＫｅｙである。
Ｐｒｅｖ１５ＩｎｔｅｒｖａｌＫｅｙすなわち前の１５分間隔キーは、前の１５分に関する、すなわち選択された時間帯におけるこの時点を含む１５分間隔の前の１５分間隔の開始に関するＤａｔｅＫｅｙである。
【００５６】
ＮｅｘｔＹｅａｒＫｅｙは、選択された時間帯におけるこの時点を含む年の次の年の開始に関するＤａｔｅＫｅｙである。
ＮｅｘｔＭｏｎｔｈＫｅｙは、選択された時間帯におけるこの時点を含む月の次の月の開始に関するＤａｔｅＫｅｙである。
ＮｅｘｔＷｅｅｋＫｅｙは、選択された時間帯におけるこの時点を含む週の次の週の開始に関するＤａｔｅＫｅｙである。
ＮｅｘｔＤａｙＫｅｙは、翌日に関する、すなわち選択された時間帯におけるこの時点を含む日の次の日の開始に関するＤａｔｅＫｅｙである。
【００５７】
ＮｅｘｔＭｉｎ６０ＩｎｔｅｒｖａｌＫｅｙは、次の１時間に関する、すなわち選択された時間帯におけるこの時点を含む６０分間隔の次の６０分間隔の開始に関するＤａｔｅＫｅｙである。
ＮｅｘｔＭｉｎ３０ＩｎｔｅｒｖａｌＫｅｙは、次の３０分に関する、すなわち選択された時間帯におけるこの時点を含む３０分間隔の次の３０分間隔の開始に関するＤａｔｅＫｅｙである。
ＮｅｘｔＭｉｎ１５ＩｎｔｅｒｖａｌＫｅｙは、次の１５分に関する、すなわち選択された時間帯におけるこの時点を含む１５分間隔の次の１５分間隔の開始に関するＤａｔｅＫｅｙである。
Ｃｏｕｎｔｅｒは、１に設定されたカウンタである。この行が存在するファクトの処理で使用される。
【００５８】
前述のデータ構造セットは、日付キー値で表された選択された時点にユーザ・クエリをマッピングするため、および、選択された時間帯内で関連する選択された時点へとナビゲートするための、計算上効率的かつ有効な方法を提供することができる。前述のマッピング機能に関して、Ｙｅａｒ、ＭｏｎｔｈＯｆＹｅａｒ、ＷｅｅｋＯｆＹｅａｒ、ＭｏｎｔｈＤａｙＯｆＹｅａｒ、ＤａｙＯｆＹｅａｒ、ＤａｙＯｆＭｏｎｔｈ、ＤａｙＯｆＷｅｅｋ、ＲｅｌａｔｉｖｅＤａｙＯｆＷｅｅｋ、ＨｏｕｒＯｆＤａｙ、ＱｕａｒｔｅｒＨｏｕｒＯｆＤａｙ、およびＭｉｎｕｔｅＯｆＨｏｕｒの属性は、ユーザの時刻表現に容易にマッピングされる数字で表される。たとえば、２００５年４月１日午後１時は、値４を有するＭｏｎｔｈＯｆＹｅａｒ属性、値１を有するＤａｙＯｆＷｅｅｋ属性、および値１３を有するＨｏｕｒＯｆＤａｙ属性にマッピングすることができる。このマッピングにより、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表内の対応する行の位置を特定することができる。行の位置が特定されると、ＤａｔｅＫｅｙ値として表されるいくつかのポインタが提供される。ポインタは、対応するＤａｔｅＫｅｙ値を有する表内の他の行を参照する。これらのポインタには、ＴｈｉｓＹｅａｒＫｅｙ、ＴｈｉｓＭｏｎｔｈＫｅｙ、ＴｈｉｓＷｅｅｋＫｅｙ、ＴｈｉｓＤａｙＫｅｙ、ＴｈｉｓＭｉｎ６０ＩｎｔｅｒｖａｌＫｅｙ、ＴｈｉｓＭｉｎ３０ＩｎｔｅｒｖａｌＫｅｙ、ＴｈｉｓＭｉｎ１５ＩｎｔｅｒｖａｌＫｅｙ、ＰｒｅｖＹｅａｒＫｅｙ、ＰｒｅｖＭｏｎｔｈＫｅｙ、ＰｒｅｖＷｅｅｋＫｅｙ、ＰｒｅｖＤａｙＫｅｙ、Ｐｒｅｖ６０ＩｎｔｅｒｖａｌＫｅｙ、Ｐｒｅｖ３０ＩｎｔｅｒｖａｌＫｅｙ、Ｐｒｅｖ１５ＩｎｔｅｒｖａｌＫｅｙ、ＮｅｘｔＹｅａｒＫｅｙ、ＮｅｘｔＭｏｎｔｈＫｅｙ、ＮｅｘｔＷｅｅｋＫｅｙ、ＮｅｘｔＤａｙＫｅｙ、ＮｅｘｔＭｉｎ６０ＩｎｔｅｒｖａｌＫｅｙ、ＮｅｘｔＭｉｎ３０ＩｎｔｅｒｖａｌＫｅｙ、およびＮｅｘｔＭｉｎ１５ＩｎｔｅｒｖａｌＫｅｙが含まれる。これら日付キーのデータ構造により、報告サブシステム２５０は、低い処理オーバヘッドで、選択された時間帯内を時間的に前後に移動することが可能である。
【００５９】
時間報告サブシステム２５０は、図４のデータ構造を生成するための様々な計算モジュールを備えることができる。一実施形態では、ＬｏａｄＤａｔｅＫｅｙと知られている計算モジュールが、１分ごとの現在のＤａｔｅＫｅｙを使用してＣｕｒｒｅｎｔＤａｔｅＫｅｙ表を更新する。現在のＤａｔｅＫｅｙ値は、１９７０年１月１日００：００：００  ＧＭＴ以降の現在の分数である。ＬｏａｄＤＴＺと知られている他のモジュールは、日付時間帯情報をＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表にロードする。このモジュールは、あらゆる指定された時間帯にある指定された日付時刻範囲内の１分ごとの日付時刻情報を生成し、これをＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表にロードする。コンタクト・センタが構成されると、ユーザは時間帯およびそれらの開始曜日を指定することができる。ＬｏａｄＤＴＺは、それらの仕様を使用して、事前に生成するべき報告日付範囲に関する正しい日付時刻情報を生成し、それらをＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表にロードすることになる。ユーザは、先読み日付範囲をカスタマイズ値に指定するか、または、現在の日付時刻から９０日のデフォルトの値を取ることができる。最後に、最小報告日付時刻（現在の日付時刻のＤａｔｅＫｅｙ値）、最大報告日付時刻（報告日付範囲内の最大ＤａｔｅＫｅｙ値のＤａｔｅＫｅｙ値）、ならびに、毎週の開始曜日および時間帯名を、構成表（図示せず）内の報告日付時刻情報の構成データとして記録することになる。それと同時に、時間帯情報をＴｉｍｅＺｏｎｅＤｉｍ表に挿入することになる。
【００６０】
従来のデータ・モデル図での描写を容易にするために、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表は、単一の報告クエリ・サブジェクトでＴｉｍｅＺｏｎｅ表に論理的に組み合わせて、ユーザが選択した報告パラメータによって指定されることになる時間帯に対応する擬似日付ディメンション（ＤａｔｅＰｓｅｕｄｏＤｉｍ）を提供することができる。データ構造は、報告によって指定されたＴｉｍｅＺｏｎｅＫｅｙの値を使用して、物理表ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍおよびＴｉｍｅＺｏｎｅＤｉｍを接合するクエリ・サブジェクトとして、報告層内で実現される。ＤａｔｅＰｓｅｕｄｏＤｉｍは、時間を非表示にすることにより、日付のみのクエリ項目をユーザに提供することもできる。ＤａｔｅＰｓｅｕｄｏＤｉｍは、データベース内の物理表ではない。その代わりに、構造が、実際の基礎となる物理表の論理的挙動を表す。
ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍを表す図表の便宜を考えたＤａｔｅＰｓｅｕｄｏＤｉｍの概念上の基準が、図５に示される。
【００６１】
図５を参照すると、この様々なディメンション表は、コンタクト・センタ報告システムで使用されるディメンション表に特有のものである。ＤａｔｅＰｓｅｕｄｏＤｉｍディメンション表５００は、ユーザによって選択された時間帯キー値に関するＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表４１６のスライスに対応することに留意されたい。これは、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍディメンション表４１６を参照しながら上記で論じた１次キーおよび属性としてのＤａｔｅＫｅｙを含む。図５の表は、エージェント作業セッションの開始および終了（エージェントがシステムにログインする期間）を記録するために、ＤａｔｅＰｓｅｕｄｏＤｉｍを参照する例示的なデータ構造を示す。ＤａｔｅＰｓｅｕｄｏＤｉｍは時間帯キーを含まないため、これを使用して、時間帯とは無関係なＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表５１２にリスト表示された開始日および終了日を例示することができる。エージェントは、ルーティング構造によって指示されたコンタクトを受け取るように割り当てられているものと認識される。
【００６２】
ＤａｔｅＰｓｅｕｄｏＤｉｍディメンション表５００に関連付けられた他の表には、ＡｇｅｎｔＤｉｍディメンション表５０４、ＴｉｍｅＤｉｍディメンション表５０８、およびＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表５１２が含まれる。
【００６３】
ＡｇｅｎｔＤｉｍディメンション表５０４は、コンタクト・センタ・エージェントの様々な属性を示し、１次キーとしてＡｇｅｎｔＫｅｙすなわちエージェント・キーを含む。このキーは、システム生成のエージェントを識別する固有キーである。表５０４内の属性には、以下のものが含まれる。
【００６４】
ＦｉｒｓｔＮａｍｅは、識別されたエージェントのファースト・ネームである。
ＭｉｄｄｌｅＮａｍｅは、識別されたエージェントのミドル・ネームである。
ＬａｓｔＮａｍｅは、識別されたエージェントのラスト・ネームである。
ＦｕｌｌＮａｍｅすなわちフル・ネームは、識別されたエージェントの完全な名前を言い表す。
【００６５】
ＴｉｍｅＤｉｍ表５０８は、コンタクト・センタ・エージェントの様々な属性を示し、１次キーとしてＴｉｍｅＫｅｙを含む。このキーは、１５分以内の秒単位での時刻に関するシステム生成の固有キーである。表５０８内の属性には、以下のものが含まれる。
ＳｅｃｏｎｄＯｆＱｔｒＨｒは、１５分の開始からの秒数である。
ＭｉｎｕｔｅＯｆＱｔｒＨｒは、この秒が存在する分数である。
ＳｅｃｏｎｄＯｆＭｉｎｕｔｅは、１５分の開始からの６０を法とする秒数である。
【００６６】
ＭＭＳＳＦｏｒ００は、００：００で始まる１５分に関する（すなわち、第１の１５分間の）、ＭＭ−ＳＳ形式での対応する時ベースの時刻である。
ＭＭＳＳＦｏｒ１５は、１５：００で始まる１５分に関する（すなわち、第２の１５分間の）、ＭＭ−ＳＳ形式での対応する時ベースの時刻である。
ＭＭＳＳＦｏｒ３０は、３０：００で始まる１５分に関する（すなわち、第３の１５分間の）、ＭＭ−ＳＳ形式での対応する時ベースの時刻である。
ＭＭＳＳＦｏｒ４５は、４５：００で始まる１５分に関する（すなわち、第４の１５分間の）、ＭＭ−ＳＳ形式での対応する時ベースの時刻である。
【００６７】
表５１２は、コンタクト・センタ・エージェントの様々な属性を示し、１次キーとしてＡｇｅｎｔＳｅｓｓｉｏｎＫｅｙを含む。このキーは、時間間隔中のセッション・イベントへのエージェントの割り当てに関する、システム生成の固有キーである。表５１２内の属性には、以下のものが含まれる。
【００６８】
ＡｇｅｎｔＫｅｙは、特定のエージェントを識別する外部キーである。
ＳｔａｒｔＤａｔｅＫｅｙ（外部キー）は、各エポック内の特定の１５分間隔を識別する整数である。
ＳｔａｒｔＴｉｍｅＫｅｙ（外部キー）は、１５分内の秒単位の時刻に関するシステム生成の固有キーである。
ＥｎｄＤａｔｅＫｅｙ（外部キー）は、各エポック内の特定の１５分間隔を識別する整数である。
ＥｎｄＴｉｍｅＫｅｙ（外部キー）は、１５分内の秒単位の時刻に関するシステム生成の固有キーである。
【００６９】
いくつかの論理的関係は、表をよく見れば明らかである。表５０４の１次キーであるＡｇｅｎｔＫｅｙと、表５０８の１次キーであるＴｉｍｅＫｅｙは、表５１２の外部キーとして使用される。表５１２のＳｔａｒｔＴｉｍｅＫｅｙおよびＥｎｄＴｉｍｅＫｅｙは、表５００の１次キーであるＤａｔｅＫｅｙの２つのインスタンスである。
【００７０】
一例を使用して、従来技術のコンタクト・センタのディメンション・モデルと本発明のディメンション・モデルとの相違点を例示する。あるエージェント・セッション・ファクト表が、エージェントが１つまたは複数のアカウントを介してシステムにログインする期間を記述すると想定する。個々のセッションは、エージェントが任意のアカウント（ｌｏｇｉｄ）を介してシステムにログインすると開始し、エージェントがすべてのアカウントをログアウトすると終了する。さらに、あるセッションに関するこれらのファクトが、３つの時間帯、すなわちＴｉｍｅＺｏｎｅ  Ａ、Ｂ、およびＣに関して記述され、ユーザが自身の裁量で３つの内の１つを選択できるようにするものと想定する。
【００７１】
図３を参照すると、従来技術のデータ構造が示される。従来技術のファクト表３０４は、関連するエージェント（エージェント・ディメンション３２４への参照による）、セッションの開始および終了（それぞれ、従来技術の日付ディメンション３１２および時刻ディメンション３０８への複数の参照による）を示す、各セッションに関する行を含む。３つの時間帯、たとえばＡ、Ｂ、およびＣをサポートするには、従来技術では、開始日付（３２６ａ、３２６ｂ、および３２６ｃ）、開始時刻（３２８ａ、３２８ｂ、および３２８ｃ）、終了日付（３３０ａ、３３０ｂ、および３３０ｃ）、および終了時刻（３３６ａ、３３６ｂ、および３３６ｃ）についてそれぞれ３つの、１２の別々の列に加えて、ファクト表内の３つの別々の日付時刻列が必要である。各追加の時間帯は、従来技術のファクト表に４つの追加の列を加える必要があり、時間帯の内の任意の１つを変更するには、従来技術のファクト表のすべての行を書き換える必要があることを理解されよう。この従来技術の構成では、日付時刻記述は２つのディメンション、すなわち１０９５行（３年間のｙｙｙｙ−ｍｍ−ｄｄ）の日付および８６，４００行（２４時間のｈｈ−ｍｍ−ｓｓ）の時刻に分割される。
【００７２】
図６は、本発明のデータ構造を使用している同じイベントを示す。日付擬似ディメンション５００は、時間帯の特定の選択に関するＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ４１６とＴｉｍｅＺｏｎｅＤｉｍ４００との組合せを示す。ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ内では複数の時間帯が構成され、前述のようにＴｉｍｅＺｏｎｅＫｅｙの様々な値によって区別される。したがって、ＤａｔｅＫｅｙによって識別された各時点は、複数の時間帯で同義的に記述される。したがってすべての時間帯に依存する日付時刻情報は日付擬似ディメンションに集中し、時間帯に依存しないより詳細な粒度の時間コンポーネントは時刻ディメンション６０８に含められる。一実施形態では、日付擬似ディメンションは分単位まで細分化されるため、時刻ディメンションは各１分内に６０秒しか含まない。他の実施形態では、日付擬似ディメンションは１５分単位までしか細分化されず、時刻ディメンションは各１５分内に９００秒を記述することができる。制約付きの時間帯セットに好適な他の実施形態では、日付擬似ディメンションと時刻ディメンションとの間の情報分割は時単位であり、時刻ディメンションは各１時間内に３６００秒を記述することができる。
【００７３】
これで、日付時刻値ペアのすべての時間帯に依存するコンポーネントが１つの表に含まれるため、本発明でのファクト表の実現は、サポートしている時間帯の数とは無関係である。図６では、ファクト表６０４は各日付時刻データについて１つのみの参照、すなわち、開始日付参照６１２、開始時刻参照６１４、終了日付参照６１６、および終了時刻参照６１８のみを含む。したがって、構成済みの時間帯の追加または修正には、いかなるファクト表の拡張または書き換えも不要であることを理解されよう。
【００７４】
以下に特定の例を示し、様々な表にどのようにデータを生成するか、およびそのデータをどのように使用して時間帯に中立のファクト表から時間帯に特有の報告を作成するかについて、実証する。このデータは、当該の間隔が１つの時間帯における春の夏時間移行イベントに渡っているが、他の時間帯では渡っておらず、すべての時間帯が互いに統一された時間領域上にあるわけではないという、複雑なケースを示す。また、日付ディメンションの粒度が、たとえばインドおよびカトマンズに対処するために１５分に選択されている、実施形態も示す。
【００７５】
表１は、それらのＴｉｍｅＺｏｎｅＫｅｙ値（１、２、および３）によって固有に識別され、報告ではそれらのＴｉｍｅＺｏｎｅＰｒｏｍｐｔ値（ＵＴＣ、デンバー、およびプーナ）によってラベル付けされた、３つの時間帯を構成するために、ＴｉｍｅＺｏｎｅＤｉｍ表４００がどのように生成されるかを示す。ＵＴＣは本来、グリニッジ標準時と同じである。デンバーは夏時間の影響を示し（ＧＭＴ−０７００およびＧＭＴ−０６００のオフセット）、プーナは統一されていない時間範囲の影響を示すことになる（ＧＭＴ＋５３０のオフセット）。
【表１】
2007228590.tif 000003
【００７６】
表２は、３つの時間帯それぞれ（すでに前述のＴｉｍｅＺｏｎｅＤｉｍで構成された行に対応するＴｉｍｅＺｏｎｅＫｅｙの値によって識別される）からわかるように、４つの別々の時点（それらのＤａｔｅＫｅｙによって識別される）を記述するために、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表４１６をどのように生成することができるかを示す。この結果、日付時間帯ディメンションには４×３＝１２のデータ行が生じる。１５分の粒度を示すこの実施形態では、以下で説明するような報告内での典型的な時刻フォーマットの構築を容易にするために、ＴｉｍｅＰｒｅｆｉｘおよびＴｉｍｅＳｕｆｆｉｘという２つの追加の列が含められる。
【表２】
2007228590.tif 000004
【００７７】
表３は、日付粒度が１５分の場合、ＴｉｍＤｉｍ表５０８をどのように生成することができるかを示す。このケースでは、任意の１５分間隔内の９００秒に対応し、０から８９９までのＴｉｍｅＫｅｙの値によって固有に識別された、９００の行がある。簡略化するために、表３にはこうした行の内４行のみが含められている。この実施形態では、ＴｉｍｅＤｉｍの各行は、任意の１５分間隔内の特定の秒を記述する。１時間には４つの可能な１５分間隔が存在するため、各行は、典型的にフォーマット化されたタイム・スタンプ（ＨＨ：ＭＭ：ＳＳ）で、分の場所に４つの異なる値を効果的に記述する。したがって、この実施形態はタイム・スタンプのＭＭ：ＳＳ部分の４つの記述を提供し、上記表２に示されたＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表からＴｉｍｅＰｒｅｆｉｘ列およびＴｉｍｅＳｕｆｆｉｘ列によって接頭部ＨＨ：および接尾部ＡＭ／ＰＭが供給される。
【表３】
2007228590.tif 000005
【００７８】
表４は、同じエージェント（ＡｇｅｎｔＫｅｙによって固有に識別される）によって実行される、２つの別個のセッション（ＡｇｅｎｔＳｅｓｓｉｏｎＫｅｙのそれらの値によって識別される）を記録するために、ＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表５１２がどのように生成するかを示す。セッション番号１は、特定の１５分間隔（番号１８５４１９６５）の最後の秒（番号８９９）で／最後の秒中に、開始し、続く１５分間隔（番号１８５４１９８０＝１８５４１９６５＋１５）の２番目の秒（番号１、０からカウント）で／２番目の秒中に、終了する。したがって、セッション番号１の長さは正確に２秒であり、１５分領域にわたる。デンバー時間帯では、この特定の領域は夏時間が午前２時から午前３時へと「前に進む」時点でもあるが、プーナ時間帯では、この領域は午後２時３０分という半端な３０分にある。セッション番号２はほぼ９時間の長さであり、デンバーでは典型的な同日作業期間を表す。しかしながらプーナでは、この同じセッションは開始日と終了日が異なって表現される。こうした複雑さはすべて日付および時刻ディメンションによって処理され、結果として、このファクト表には単純かつ効率的に時間が記述される。
【表４】
2007228590.tif 000006
【００７９】
以下の表５、６、および７は、ユーザが３つの時間帯の内の１つを指定する単一の報告定義によって、前述のＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のセッションがどのように記述されるかを示す。報告の各行は、ＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表の特定の行によって記述されるセッションを表す。ＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔおよび日付時刻ディメンションのデータベース表列へのレポート列の再マッピングは、次の通りである。報告の中に示されるＳｅｓｓｉｏｎの値は、ＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のＡｇｅｎｔＳｅｓｓｉｏｎＫｅｙの値である。報告の中の開始日付の値は、ＤａｔｅＫｅｙがＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のＳｔａｒｔＤａｔｅＫｅｙの値に等しく、ＴｉｍｅＺｏｎｅＫｅｙは報告ユーザが選択したＴｉｍｅＺｏｎｅＤｉｍ表内のＴｉｍｅＺｏｎｅＰｒｏｍｐｔの値に対応する、行に対応する、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表からのＦｕｌｌＤａｔｅＴｉｍｅ列の日付部分である。報告の中の開始時刻の値は、ＴｉｍｅＫｅｙがＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のＳｔａｒｔＴｉｍｅＫｅｙの値に等しい、ＴｉｍｅＤｉｍ表内の行からの、４つの列、ＭＭＳＳＦｏｒ００、ＭＭＳＳＦｏｒ１５、ＭＭＳＳＦｏｒ３０、またはＭＭＳＳＦｏｒ４５の内の１つから構成される。４つのＭＭＳＳＦｏｒＸＸ列間での選択は、ＤａｔｅＫｅｙがＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のＳｔａｒｔＤａｔｅＫｅｙの値に等しく、ＴｉｍｅＺｏｎｅＫｅｙは報告ユーザが選択したＴｉｍｅＺｏｎｅＤｉｍ表内のＴｉｍｅＺｏｎｅＰｒｏｍｐｔの値に対応する、行に関する、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表内のＭｉｎｕｔｅＯｆＨｏｕｒ列の値によって指示される。次に、示されたＭＭＳＳＦｏｒＸＸ列の値には、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表の同じ行から、すなわち、ＤａｔｅＫｅｙがＡｇｅｎｔＳｅｓｓｉｏｎＦａｃｔ表内のＳｔａｒｔＤａｔｅＫｅｙの値に等しく、ＴｉｍｅＺｏｎｅＫｅｙは報告ユーザが選択したＴｉｍｅＺｏｎｅＤｉｍ表内のＴｉｍｅＺｏｎｅＰｒｏｍｐｔの値に対応する行から、接頭部としてＴｉｍｅＰｒｅｆｉｘの値が付けられ、接尾部としてＴｉｍｅＳｕｆｆｉｘの値が付けられる。報告の中の終了日付および終了時刻の値は、類似して（前述のマッピングにおける語「開始」を「終了」に置き換えて）決定される。１５分実施形態に関するこれらのマッピングは、言葉で表すと複雑に聞こえるが、市販のデータベースによって一般に認識される構造化照会言語（ＳＱＬ）の機能の範囲に十分おさまる。
【００８０】
報告ユーザがＵＴＣ時間帯を選択した場合、表５の値が示される。これは、午前９時の前後１秒間続くセッション番号１と、深夜零時の直前であるが同日の４月４日に開始および終了するセッション番号２とを示す。
【表５】
2007228590.tif 000007
【００８１】
報告ユーザがデンバー時間帯を選択した場合、表６の値が示される。セッション番号１は、デンバーの春の夏時間移行にまたがるため、このセッションは午前２時（標準時）の直前に開始し、午前３時（夏時間）の直後に終了するが、それでもなお２秒間のみの長さである。デンバーの立場からすると、セッション番号２は同日の４月４日に開始および終了する典型的な作業日に見える。
【表６】
2007228590.tif 000008
【００８２】
報告ユーザがインドのプーナ時間帯を選択した場合、表７の値が示される。ここでセッション番号１は午後２時３０分で３０分マークをまたがり、セッション番号２は異なる日（４月４日および４月５日）に開始および終了する。
【表７】
2007228590.tif 000009
【００８３】
この例を再検討すると、ＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表の粒度が、選択された時間帯に対応するために必要に応じて変更可能であることを理解することが重要である。言い換えれば、表の各行は１分、１５分、３０分、１時間などに対応可能である。時間帯の中には、グリニッジを基準にして１５分または３０分単位で開始するものもあることに留意されたい。ほとんどの時間帯はグリニッジを基準にして１時間単位で開始する。前述の例は、グリニッジを基準にして１５分または３０分の領域を有する時間帯にも対処可能である。
【００８４】
さらに１次表、すなわちＤａｔｅＴｉｍｅＺｏｎｅＤｉｍ表内の粒度が、補助のＴｉｍｅＤｉｍ表内の粒度に影響を与えることを理解されよう。したがって、１次表内の粒度が１時間の場合、その時間内のすべての秒が補助表に表示される。前述の例では、１次表内の粒度が１５分であるため、補助表内の粒度は各１５分内の秒である。ユーザが１７分を表したい場合、最初の１５分間隔は１次表によって識別されるが、その間隔内の２分地点は補助表によって識別される。この例では、補助表は各時刻キーについて、すでに４つの可能性を各１５分領域に追加しており、すなわち、キー１について、潜在的な対応時刻値は００：０１、１５：０１、３０：０１、および４５：０１である。
【００８５】
１５分以外の他の粒度を選択することで、前述の例で示された複雑さが軽減される実施形態も可能であることも理解されるであろう。具体的には、１分粒度または１時間粒度を選択すると、分コンポーネントの知識は、例のように１次および２次の両方の表にまたがって分散されるのではなく、それぞれ１次表内または２次表内のいずれかにすべて収められる。たとえば表のサイズおよびアルゴリズム的複雑さなど、粒度の選択に影響を与える可能性のある様々な他の技術的な兼ね合いがあるが、本発明の中心となる寄与は、システムが設計される際に対象とする時間帯セットについて、２次表に依存する時間帯なしに、すべての時間帯依存が１次表に集中するような粒度とすることである。本発明のいくつかの変形形態および修正形態が使用可能である。他の特徴を提供することなく、本発明のいくつかの特徴を提供することが可能である。
【００８６】
たとえば、サーバおよび／またはスイッチは、処理ユニット（ＣＰＵ）、マイクロプロセッサ、あるいは、ソフトウェアを実行する他のタイプのデジタル・データ・プロセッサまたは特定用途向け集積回路（ＡＳＩＣ）、ならびにこうした要素の様々な部分または組合せを含む、ソフトウェア制御システムとすることができる。メモリは、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、またはこれらおよび他のタイプの電子メモリ・デバイスの組合せとすることができる。
【００８７】
他の代替実施形態では、より長い間隔の日付時刻値が、日付キーおよび全日付時刻属性に使用される。たとえば、より長い間隔とは、１分間隔ではなく、１５、３０、または６０分とすることができる。
【００８８】
他の代替実施形態では、より短い間隔の日付時刻値（粒度）が、日付キーおよび全日付時刻属性に使用される。たとえば、より短い間隔とは、１秒とすることができる。
他の実施形態では、前述の諸実施形態のすべてに関する変形として、時刻ディメンションを０．０１秒または０．００１秒などのより詳細な粒度まで拡張することができる。
【００８９】
様々な実施形態において、本発明は、様々な実施形態、サブコンビネーション、およびそれらのサブセットを含む、ほぼ本明細書で図示および説明したようなコンポーネント、方法、プロセス、システム、および／または装置を含む。当業者であれば、本開示を理解した後に、本発明の作成および使用方法を理解されよう。本発明は、様々な実施形態において、たとえば性能の向上、容易さの達成、および／または実施コストの削減のために、前述のデバイスまたはプロセスで使用されたようなアイテムがない場合を含め、本明細書またはその様々な実施形態に図示および／または説明されていないアイテムなしで、デバイスおよびプロセスを提供することを含む。
【００９０】
本発明の前述の内容は、例示および説明のために提示したものである。前述の内容は、本発明を本明細書で開示された形に限定することを意図するものではない。たとえば前述の発明を実施するための最良の形態では、本開示を簡略化するために、本発明の様々な特徴が１つまたは複数の実施形態にまとめられている。この開示の方法は、本発明が、各請求項に明示的に示された特徴よりも多くの特徴を必要とするという意図を反映するものと解釈すべきではない。むしろ、添付の特許請求の範囲が反映するように、発明の諸態様は、前述の単一の開示された実施形態のすべての特徴よりも少ない特徴にある。したがって、添付の特許請求の範囲は、この発明を実施するための最良の形態に組み込まれており、各請求項は本発明の別の好ましい実施形態として独立している。さらに、本発明の説明には１つまたは複数の実施形態ならびに一定の変形形態および修正形態の説明が含まれているが、他の変形形態および修正形態も、たとえば本開示を理解した後の当業者の技術および知識の範囲内とすることができるように、本発明の範囲内にある。特許請求された内容と代替の、交換可能な、および／または等価の構造、機能、範囲、または工程を含み、こうした代替の、交換可能な、および／または等価の構造、機能、範囲、または工程が本明細書に開示されているか否かにかかわらず、ならびに、任意の特許可能な対象を公用する意図なしに、許可される範囲までの代替実施形態を含める権利を取得することが意図される。
【図面の簡単な説明】
【００９１】
【図１】本発明の実施形態に従ったコンタクト・センタを示すブロック図である。
【図２】本発明の実施形態に従ったサーバを示すブロック図である。
【図３】従来技術に従ったデータ・モデルを示す図である。
【図４】本発明の実施形態に従ったデータ構造セットを含むデータ・モデルを示す図である。
【図５】本発明の実施形態に従ったデータ構造セットを含むデータ・モデルを示す図である。
【図６】本発明に従ったファクト・イベントを示す図である。
【図１】
2007228590.tif 000010
【図２】
2007228590.tif 000011
【図３】
2007228590.tif 000012
【図４】
2007228590.tif 000013
【図５】
2007228590.tif 000014
【図６】
2007228590.tif 000015