(57)【特許請求の範囲】
【請求項１】
データを記憶しているインメモリデータベースシステムによって前記データを出力するコンピュータ実施方法であって、
前記インメモリデータベースシステムによって、データウェアハウスシステムによって記憶されている第1のデータにアクセスすることに対応する第1のデータモデルを記憶するステップと、
前記インメモリデータベースシステムによって、第2のデータを記憶するステップであって、前記データウェアハウスシステムは非インメモリシステムであって、前記第１のデータモデルはデータキューブと特性を含み、前記インメモリデータベースシステムは前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、ステップと、
前記インメモリデータベースシステムによって、前記第1のデータモデルを、前記第2のデータにアクセスすることに対応する第2のデータモデルに変換するステップであって、前記第２のデータは、前記第１のデータに対応し、前記第1のデータモデルを前記第2のデータモデルに変換するステップは、前記データキューブをAnalytic Viewに変換するステップと、前記特性を共用属性ビューに変換するステップと、を含み、
前記インメモリデータベースシステムによって、前記第2のデータモデルに従い前記第2のデータを出力するステップであって、前記第２のデータモデルはインメモリデータ構造に関する、ステップと、
を含む方法。
【請求項２】
前記第1のデータモデルは、行指向フォーマットで記憶されている前記第1のデータに対応する、請求項1に記載の方法。
【請求項３】
前記第2のデータモデルは、列指向フォーマットで記憶されている前記第2のデータに対応する、請求項1に記載の方法。
【請求項４】
前記第2のデータモデルは、行指向フォーマットおよび列指向フォーマットの両方で記憶されている前記第2のデータに対応する、請求項1に記載の方法。
【請求項５】
前記第2のデータが行指向フォーマットとは異なる列指向フォーマットで記憶されているという理由により、前記インメモリデータベースシステムは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項1に記載の方法。
【請求項６】
前記第2のデータが行指向フォーマットと、前記行指向フォーマットとは異なる列指向フォーマットとの両方で記憶されているという理由により、前記インメモリデータベースシステムは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項1に記載の方法。
【請求項７】
前記インメモリデータベースシステムは、前記第2のデータが行指向フォーマットのみで記憶されていないという理由により、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項1に記載の方法。
【請求項８】
データを出力するためのシステムであって、
データウェアハウスシステムによって記憶されている第1のデータにアクセスすることに対応する第1のデータモデルを記憶するように構成され、第2のデータを記憶するように構成されたインメモリデータベースコンポーネントであって、前記データウェアハウスシステムは非インメモリシステムであって、前記第１のデータモデルはデータキューブと特性を含み、前記第２のデータは前記第１のデータに対応し、前記インメモリデータベースコンポーネントは前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、インメモリデータベースコンポーネントと、
前記第2のデータにアクセスすることに対応する第2のデータモデルに前記第1のデータモデルを変換するように構成された処理コンポーネントであって、前記第1のデータモデルを前記第2のデータモデルに変換することは、前記データキューブをAnalytic Viewに変換することと、前記特性を共用属性ビューに変換することと、を含み、前記第２のデータモデルはインメモリデータ構造に関する、処理コンポーネントと、
前記第2のデータモデルに従い前記第2のデータを出力するように構成された出力コンポーネントと
を備えるシステム。
【請求項９】
前記第1のデータモデルは、行指向フォーマットで記憶されている前記第1のデータに対応する、請求項8に記載のシステム。
【請求項１０】
前記第2のデータモデルは、列指向フォーマットで記憶されている前記第2のデータに対応する、請求項8に記載のシステム。
【請求項１１】
前記第2のデータが行指向フォーマットとは異なる列指向フォーマットで記憶されているという理由により、前記インメモリデータベースコンポーネントは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項8に記載のシステム。
【請求項１２】
前記第2のデータが行指向フォーマットと、前記行指向フォーマットとは異なる列指向フォーマットとの両方で記憶されているという理由により、前記インメモリデータベースコンポーネントは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項8に記載のシステム。
【請求項１３】
データを出力するようにコンピュータシステムを制御するための命令を記憶する非一時的コンピュータ可読媒体であって、
データウェアハウスシステムによって記憶されている第1のデータにアクセスすることに対応する第1のデータモデルを記憶するように前記コンピュータシステムを制御するように構成され、第2のデータを記憶するように構成されたインメモリデータベースコンポーネントであって、前記データウェアハウスシステムは非インメモリシステムであって、前記第１のデータモデルはデータキューブと特性を含み、前記第２のデータは前記第１のデータに対応し、前記インメモリデータベースコンポーネントは前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、インメモリデータベースコンポーネントと、
前記第2のデータにアクセスすることに対応する第2のデータモデルに前記第1のデータモデルを変換するように前記コンピュータシステムを制御するように構成された処理コンポーネントであって、前記第1のデータモデルを前記第2のデータモデルに変換することは、前記データキューブをAnalytic Viewに変換することと、前記特性を共用属性ビューに変換することと、を含み、前記第２のデータモデルは非インメモリデータ構造に関する、処理コンポーネントと、
前記第2のデータモデルに従い前記第2のデータを出力するように前記コンピュータシステムを制御するように構成された出力コンポーネントと
を備える非一時的コンピュータ可読媒体。
【請求項１４】
前記第1のデータモデルは、行指向フォーマットで記憶されている前記第1のデータに対応する、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項１５】
前記第2のデータモデルは、列指向フォーマットで記憶されている前記第2のデータに対応する、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項１６】
前記第2のデータが行指向フォーマットとは異なる列指向フォーマットで記憶されているという理由により、前記インメモリデータベースコンポーネントは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項１７】
前記第2のデータが行指向フォーマットと、前記行指向フォーマットとは異なる列指向フォーマットとの両方で記憶されているという理由により、前記インメモリデータベースコンポーネントは、前記第1のデータモデルを使用して前記第2のデータにアクセスすることができない、請求項13に記載の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
【０００２】
本開示は、データ処理に関し、詳細には、分析データ処理に関する。
【背景技術】
【０００３】
本明細書で別途明示されない限り、本節に記載の手法は、本出願における特許請求の範囲に対する従来技術ではなく、本節に含まれることによって従来技術であると認められるものでもない。
【０００４】
データ処理は、多様な分野である。データ処理の2つのタイプは、トランザクションデータ処理および分析データ処理である。トランザクションデータ処理は、トランザクションデータ処理システムが管理する個々のトランザクションを表すトランザクションデータに関し、例として、注文処理、インボイス処理などが挙げられる。トランザクションデータ処理は、(行指向のデータベースシステムではない、非従来型のデータベース管理システム(DBMS)と区別するために)「従来の」DBMSと呼ばれることが多いDBMS、より詳細には、行指向のデータベースシステムを使用して実行されることが多い。トランザクションデータ処理は、略語OLTP(online  transaction  processing:オンライントランザクション処理)で示される場合もある。
【０００５】
分析データ処理は、トランザクションデータの集まりを表す分析データに関し、例として、ある時間帯の総販売高、受取勘定の平均一日残高などが挙げられる。分析データ処理は、データが抽出(extraction)、変換(translation)およびローディング(loading)(ETL)と呼ばれるプロセスにおいて、トランザクションデータ処理システムから周期的に(しばしば要約データとして)ロードされる従来のDBMSを使用して実行され得る。しばしば、ETLプロセスは、1日に1つ、例えば、トランザクション処理システムが軽くロードされる夜間に実行される。分析データ処理システムは、データウェアハウス(DW)、ビジネスウェアハウス(BW、例えば、「データ」がそこでは暗示的または暗黙的である)、ビジネスインテリジェンス(BI)システム、データマート(DM)などと呼ばれることがある。分析データ処理は、略語OLAP(online  analytical  processing:オンライン分析処理)で示される場合もある。
【０００６】
データ処理が2つのシステムに分割される1つの理由は、分析データ処理のために使用される分析クエリは、しばしば、それらが運用しているすべてのデータをそのデータが中間クエリに変わることを防止するために「ロックする」ことであるが、そのようなロックは、追加のトランザクションを実行するためのシステムの動作をスローダウンさせる可能性がある。データ処理を2つのシステムに分割する1つの不利な面は、ETLプロセスの周期的な性質のために分析データが古くなることである。
【０００７】
分析データ処理システムでは、中核分析概念は、分析キューブ(「多次元キューブ」または「ハイパーキューブ」とも呼ばれる)である。分析キューブは次元によって分類されるメジャーと呼ばれる数値ファクトからなる。キューブメタデータは、通常、リレーショナルデータベース内の表の星型スキーマまたは雪片型スキーマから作成される。メジャーは、ファクト表内のレコードから得られ、次元は次元表から得られる。各メジャーは、ラベルのセットまたはそれに関連付けられたメタデータを有するとみなすことができる。次元は、これらのラベルを記述するものであり、メジャーに関する情報を提供する。
【０００８】
分析キューブは、データモデル(単に「モデル」とも呼ばれる)を作成するために使用されるいくつかのデータ構造のうちの1つである。モデルは、一般に、データを見る方法、データを選択する方法などを含めて、データを分析するために使用される。一般に、いくつかのモデルは、特定の分析データ処理システムにおいて作成され、これらのモデルは、分析データ処理システムによって記憶されている特定のデータに対して頻繁に実行されるデータ分析動作に対応する。例えば、X社によって使用されるモデルは、Y社によって使用されるモデルとは異なるはずであり、それは、両社の基本的データの構造に相違があるからである。
【０００９】
最近のインメモリ技術の開発は、従来のDBMSの代わりに分析データ処理システムにインメモリデータベースを実装してきた。インメモリデータ処理システムの例は、SAP社からのHANA(登録商標)である。インメモリデータ処理システムは、(非インメモリデータベースシステムのディスクストレージとは対照的に)データをメモリに記憶することによって利用可能なスピードにより、トランザクションデータ処理および分析データ処理の両方を実行することができる。
【００１０】
基本データが別々のOLAPシステムおよびOLTPシステムからインメモリデータ処理システムに統合されたとは言え、ユーザは、分析データにアクセスする方法を依然として必要としている。OLAPシステムとインメモリデータ処理システムとでは構造が異なるため、ユーザの既存のモデルは、機能しないことになる。例えば、OLAPシステムは、しばしば、(データを行構造で記憶する)従来のRDBMSであるが、インメモリシステムは、データを列構造で記憶する。この問題に対処する1つの方法は、モデルを書き換えることである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記の議論を前提として、モデルを書き換えるのではなく、変換する必要性が存在する。一実施形態は、モデルを非インメモリデータ処理システムからインメモリデータ処理システムに変換することを対象とする。
【課題を解決するための手段】
【００１２】
一実施形態は、データを記憶するインメモリデータベースシステムによってデータを出力する方法である。本方法は、データウェアハウスシステムによって記憶されている第1のデータにアクセスすることに対応する第1のデータモデルを、インメモリデータベースシステムによって記憶するステップを含む。本方法は、インメモリデータベースシステムによって第2のデータを記憶するステップをさらに含む。本方法は、第2のデータにアクセスすることに対応する第1のデータモデルを、インメモリデータベースシステムによって第2のデータモデルに変換するステップをさらに含む。本方法は、インメモリデータベースシステムによって、第2のデータモデルに従い第2のデータを出力するステップをさらに含む。
【００１３】
コンピュータシステムは、前述の方法を実施するように動作することができる。このコンピュータシステムは、コンピュータシステムを前述の方法を実施するように制御する1つまたは複数のコンピュータプログラムを記憶する、実行する、またはそうでなければこの1つまたは複数のコンピュータプログラムによって制御され得る。
【００１４】
非一時的コンピュータ可読媒体は、コンピュータシステムを前述の方法を実施するように制御するための命令を記憶することができる。これらの命令は、インメモリデータベースコンポーネント、処理コンポーネント、および出力コンポーネントを含み得る。
【００１５】
以下の詳細な説明および添付の図面は、本開示の本質および利点のより良い理解を提供する。
【図面の簡単な説明】
【００１６】
【図１】データを記憶しているインメモリデータベースシステムによってデータを出力する方法の流れ図である。
【図２】本開示の諸実施形態を実施するための例示的コンピュータシステムおよびネットワークのブロック図である。
【発明を実施するための形態】
【００１７】
本明細書では、インメモリデータベースからデータを出力するための技法が説明される。以下の説明では、本開示の徹底的な理解を提供するために、多数の例および具体的な詳細が説明の目的で述べられる。しかし、特許請求の範囲によって定義される本開示は、これらの例における特徴の一部分またはすべてを単独でまたは以下に記載されている他の特徴と組み合わせて含んでもよく、本明細書に記載の特徴および概念の修正形態ならびに均等形態をさらに含み得ることは、当業者には明らかであろう。
【００１８】
本明細書では、様々な方法、プロセスおよび手順が詳述される。特定のステップが、ある一定の順序で記述されるが、そのような順序は、主に便宜上のためおよび明瞭にするためのものである。特定のステップは、何度も繰り返されてもよく、他のステップの前または後に(たとえそれらのステップが別の順序で別途記述されていても)実行されてもよく、他のステップと並行して実行されてもよい。第2のステップは、第2のステップが始まる前に第1のステップが完了しなければならない場合にのみ、第1のステップに続くことを必要とされる。そのような状況は、文脈から明らかでない場合は、具体的に指摘されることになる。特定のステップが省略されてもよい。特定のステップは、その省略が別のステップに実質的に影響を与えると思われる場合にのみ必要とされる。
【００１９】
本明細書では、用語「および」、「または」、および「および/または」が使用される。そのような用語は、同じ意味を有する、すなわち、包括的であると解釈されるものとする。例えば、「AおよびB」は、少なくとも以下のこと、すなわち「AとBの両方」、「Aのみ」、「Bのみ」、「少なくともAとBの両方」を意味してもよい。他の例として、「AまたはB」は、少なくとも以下のこと、すなわち「Aのみ」、「Bのみ」、「AとBの両方」、「少なくともAとBの両方」を意味してもよい。排他的論理和が意図される場合は、そのことが特筆される(例えば、「AまたはBのいずれか」、「多くてもAおよびBのうちの1つ」)。
【００２０】
本明細書では、様々なコンピュータ実施方法、プロセスおよび手順が説明される。様々な動作(受信すること、記憶すること、送信すること、通信すること、表示することなど)は、たとえ動作がユーザによって認可、初期設定またはトリガされることがあっても、またはハードウェアデバイスがコンピュータプログラム、ソフトウェア、ファームウェアなどによって制御されていても、ハードウェアデバイスによって実行されることを理解されたい。さらに、たとえデータが概念または現実世界の対象物を表すことがあっても、したがって、「データ」自体としての明白なラベリングは省略されても、ハードウェアデバイスはデータを運用していることを理解されたい。例えば、ハードウェアデバイスが「レコードを記憶している」と記載されている場合は、ハードウェアデバイスはレコードを表すデータを記憶していることを理解されたい。
【００２１】
本明細書では、特定の例が、SAP  BIシステムまたはDWシステム(非インメモリシステム)およびSAP  HANAシステム(インメモリシステム)などのSAPシステムの文脈で論じられる。非インメモリシステムのSAP特有の構造(例えば、InfoCube)上で実行される動作はまた、モデルをインメモリシステムでの使用のために変換するために、非SAP構造(例えば、分析キューブ、多次元キューブ、ハイパーキューブなど)上で実行されてもよいことを理解されたい。さらに、本明細書に記載のシステムは、ローカルエリアネットワークまたはインターネットなどの通信リンクを介して接続され得る1つまたは複数のコンピュータを含んでもよい。
【００２２】
前述のように、SAP  BWの非常に強い(10000より多い)インストールベース、および自分のウェアハウスおよびデータマートをモデル化するのにすでに巨額の資金を投資した多数の顧客が存在する。次に、顧客は、HANAシナリオ上でBW(BWのためのデータベースとして使用されるHANA)にアップグレードする場合は、エクスプローラなどのSAPビジネスオブジェクトツールを使用するために、再び巨額の資金を投資してHANA分析モデルを作成しなければならない。さらに、顧客は、BWデータを消費することを必要とする自分のニーズに基づいて、任意のUI技術を使用して、何度も自分のカスタムアプリケーションを構築しなければならない、または構築したいと思う。顧客は、直接HANAからデータを得ることができるが、HANAの分析機能を使用するために、顧客は、BWスキーマ表の上でモデルを手動で作成する必要があり、その結果、これらの顧客にとって多大な努力と費用がかかることになる可能性がある。
【００２３】
以下でさらに詳述されるように、自動プロセスは、BWデータを記憶しているHANA(データベース)内にあるBWスキーマ表の上でHANA分析モデルを作成する。(HANAモデルは、BWモデルとは異なり、したがって、1対1で変換されることは不可能である。)アプリケーションのインテリジェンスは、BWモデルのセマンティクスをインタープリットし、HANAモデルのための対応するセマンティクスを作成する。
【００２４】
例えば、Attribute  View(属性ビュー)をBW内のInfoObject(インフォオブジェクト)ごとにHANAにおいて作成することができる。Analytic  View(分析ビュー)をInfoCube/Operational  Datastore  Object(オペレーショナルデータストアオブジェクト)のために作成することができる。BW  MultiProvider(マルチプロバイダ)およびInfoSet(インフォセット)では、HANAにおいて、集合(union)シナリオおよび結合(join)シナリオの両方を引き受けるCalculation  View(計算ビュー)を作成することができる。分析認可では、HANA  Analytic  Privilege(分析権限)を作成することができる。
【００２５】
概括的な使用事例は、Business  Object(ビジネスオブジェクト)レポーティングツールである。エクスプローラなどのBusiness  Objectレポーティングツールは、HANAモデルの上に直接レポートすることができる。したがって、BW  InfoProvider(インフォプロバイダ)をHANAモデルに変換することにより、システムは、ユーザフレンドリなレポートを生成することができるエクスプローラにそれらを露出する。
【００２６】
いくつかの実施形態の1つの注目に値する特徴は、別々のモデル化を必要としないことである。変換は、BWモデルの分析セッティングをインテリジェントに識別し、次いで、対応する分析セッティングを適用可能な場合はどの場合にもHANAモデルに適用する。HANAモデルおよびそれらのセマンティクスは、BWモデルとは異なるが、変換は、BWモデルセマンティクスをインタープリットすることを引き受け、次いで、適切にHANAモデルのセマンティクスを作成する。これは、顧客にとってかなりのモデル化努力と費用を低減する。
【００２７】
いくつかの実施形態の他の注目に値する特徴は、BWからのデータレプリケーションを必要としないことである。変換ユーティリティは、BWモデルのメタデータから基本的データベーススキーマを識別し、BWモデルの上にHANAビューを作成する。したがって、HANAにおける特別のスキーマ作成の必要がなく、これらのHANAモデルのための別々のデータローディングは必要がない。
【００２８】
いくつかの実施形態の他の注目に値する特徴は、顧客専用レポートである。HANAモデルは、デプロイされた場合、MDX(多次元式)準拠のランタイムオブジェクトを作成する。これらのビューには、JDBC(Java(登録商標)データベース接続)を使用してアクセスすることができる。したがって、BWレポートが中断されずに依然として動作している場合は、顧客はまた、HTML5(ハイパーテキストマークアップ言語バージョン5)または任意の他のユーザインターフェース技術を使用して自分のニーズに基づいて自分のカスタムレポートまたはダッシュボードを作成する選択肢を有し、JDBCを使用してHANAモデル上で自分の多次元クエリを実行する。このようにして、顧客は、スライシング、ダイシング、アグリゲーションなどすべての所望の分析機能を用いてBWデータに直接アクセスすることができる。これらの分析動作は、HANAにおいて実行され、したがって、顧客は自分の高速レポーティングニーズを満たすことができるようになる。
【００２９】
例示的実施形態
【００３０】
以下でさらに詳述されるように、諸実施形態は、HANAをBWシステムのためのデータベースとして使用するSAP  BW顧客が、InfoObject、InfoCube、Operational  Datastore  Object(DSO)、Infoset、MultiProviderなどのBWモデルから自動的に、Attribute  View、Analytic  View、Calculation  View、Analytic  PrivilegeなどのHANA情報モデルを作成することができる場合に使用され得る。これらのそれぞれの詳細は、以下で論じられる。
【００３１】
InfoObject処理における特性
【００３２】
BW内の固有のInfoObjectでは、システムは、HANAにおいて共用Attribute  Viewを作成する。この特性が多くのInfoProviderにまたがって共用されない場合は、この特性が使用される(InfoCubeまたはDSOなどのようなInfoProviderに対応する)特定のAnalitic/Calculation  Viewにおいて、プライベート属性としてこの特性を作成することができる。
【００３３】
システムは、データファンデーション(data  foundation)の一部分として固有のSID(システム識別子)表、マスタデータ、テキスト表などを生成することができる。システムは、標準BWロジック、例えば、SID表およびマスタデータを使用して、結合を得ることができ、テキスト表は、CHAVL(固有の値)フィールド上の関係結合を使用して結合されることが可能であり、テキスト表内のLANGU(言語)は、テキスト結合内の言語属性として選択することができる。
【００３４】
Currency(カレンシ)特性およびUnit特性では、システムは、標準カレンシ、カレンシテキスト、ユニット、およびユニットテキスト表を共用Attribute  Viewのデータファンデーションに追加することができることに留意されたい。
【００３５】
InfoObject処理におけるキー数値
【００３６】
HANAには共用メジャーがない。したがって、システムは、InfoProvider自体の文脈でBWキー数値を処理する。システムは、HANA情報モデルにおいてプライベートメジャーを作成することによりBWキー数値を変換する。
【００３７】
InfoCube処理
【００３８】
システムは、従来のBW拡張星型スキーマに比較して非常に簡略化されたスキーマを有するために、InfoCube上の新しい拡張であるHANA  Optimized  InfoCube(最適化インフォキューブ)のためのHANAモデルを作成することができる。
【００３９】
BW  InfoCubeでは、システムは、HANAにおいてAnalytic  Viewを作成する。データファンデーションは、InfoCube  Fファクト表を包含する。
【００４０】
プライベート属性を作成する必要がある場合は、システムは、データファンデーションの一部分としてSID表および他の表を生成する。システムは、標準BWロジック通りの関係結合を作成する、すなわち、SID表内のSIDフィールドは、ファクト表内のSID_<CharacteristicName>フィールドと結合される。
【００４１】
InfoCubeにおいて使用される特性が共用Attribute  ViewとしてHANAにおいてすでに作成されている場合は、システムは、Attribute  ViewをAnalytic  ViewのLogical  Viewに追加する。再度、システムは、特性のSIDを使用してLogical  Viewにおいてデータファンデーションとこの特性との間に結合を作成する。
【００４２】
InfoCubeにおけるキー数値では、システムは、Analytic  Viewにおいてプライベートメジャーを作成する。これは、キー数値と同じ説明を必要とする。「アグリゲーションタイプ」、「メジャーのユニット」、「カレンシ」など他の分析特性もしかるべくセットされる。
【００４３】
制限されたキー数値/計算されたキー数値
【００４４】
InfoCubeレベルで定義された制限されたキー数値および計算されたキー数値がある場合は、システムは、Analytic  Viewにおける同様の制限および式を用いてHANAにおいて制限されたメジャーまたは計算されたメジャーを作成する。InfoCube上にナビゲーション属性がある場合は、それらは他の特性と同じやり方でAnalytic  Viewにおけるプライベート属性として作成される。これのデータファンデーションは、親特性の属性表および属性特性のテキスト表から成ることになる。
【００４５】
Operational  Datastore  Object(DSO)処理
【００４６】
システムは、特にHANAシステムのために設計されたDSOの拡張版であるIMO  DSO(InMemory  Optimized  DSO)のためのHANAモデルを作成することができる。IMO  DSOは、全データを包含するアクティブデータ表を有する。この表はデータファンデーションの一部分でもよい。残余の変換ステップは、上記のInfoCubeの節で提供されたものと同様である。
【００４７】
MultiProvider処理
【００４８】
BW  MultiProviderでは、システムはHANAにおいてCalculation  Viewを作成する。パートプロバイダは、InfoObject、InfoCube、DSO、InfoSetなど任意のBW  InfoProviderでもよい。システムは、(上記のそれぞれの節において詳述されているように)MultiProvider内のパートプロバイダごとに対応するタイプのモデルを作成する。システムは、Calculation  Viewにこれらのモデルを「データソース」(ノード)として含み、次いで、「Union」ノードを使用してそれらを結合する。属性マッピングは、MultiProviderにおけるマッピングに基づいてソースとターゲットデータソースとの間で行われる。
【００４９】
InfoSet処理
【００５０】
BW  InfoSetでは、システムはHANAにおいてCalculation  Viewを作成する。これは、MultiProviderと非常に同様に処理される(上記参照)。システムは、基本的パートプロバイダをHANAにおけるそれぞれのモデルとして作成する。パートプロバイダは、データソースとしてCalculation  Viewに含まれ、Joinを使用して結合される。システムは、InfoSetのメタデータに基づいて結合における適切な属性を選択する。
【００５１】
さらなる詳細
【００５２】
以下の節は、非インメモリシステムからインメモリシステムへのモデルの変換に関する追加の詳細を提供する。概括的な使用事例は以下のとおりである。第1に、モデラー(ユーザ)は、非インメモリシステムによって記憶されているInfoProviderをブラウズするために、インメモリシステム(例えば、HANA)を使用して非インメモリシステム(例えば、BW)に接続する。インメモリシステムは、JCO(SAP  Java(登録商標)コネクタ)を使用してこの接続を実施することができる。第2に、モデラーは、InfoProviderを選択する。第3に、インメモリシステムは、(非インメモリシステムにおける)選択されたInfoProviderに対応するインメモリシステムにおいて情報モデルを生成する。インメモリシステムは、InfoProviderスキーマをデータファンデーションに含めることによりこれらの情報モデルを生成し、その結果、データレプリケーションの必要がない。インメモリシステムは、InfoProviderメタデータから情報モデル特性をセットすることができる。インメモリシステムは、既存のRFC(リモート機能コール)およびBWによって実装されたBAPI(ビジネスアプリケーションプログラミングインターフェース)を使用してメタデータを読み取ることができる。
【００５３】
インメモリシステムは、BWから情報を取得するために、以下のBAPIを使用することができる。BAPI_CUBE_GETLIST(InfoCubeのリストを得るため)、BAPI_CUBE_GETDETAIL(InfoCube詳細を得るため)、およびBAPI_IOBJ_GETDETAIL(InfoObject詳細を得るため)。インメモリシステムはまた、変換を実行するためにBWの以下の11のAPIのうちの1つまたは複数のものと相互に作用することができる。
1.  BWは、BWシステムにおける既存のInfoAreaおよびInfoProviderをブラウズするためのインターフェースを実施するBrowse  APIを実施することができる。このAPIは、所与のInfoAreaの下にオブジェクトを提供することができる。この出力は、その下にInfoAreaを含んでもよい。インポートパラメータとして、Browse  APIは、InfoArea名およびタイプ(AREA、CUBE、ODSO、MPROなど)の表を受信することができる。エクスポートパラメータとして、Browse  APIは、オブジェクトヘッダ(名称、ロングテキスト、タイプなど)の表を送信することができる。
2.  BAPI_CUBE_GETLISTは、FLAT  InfoCube(それらのすべてではない)のみを返すことができ、同様に、BAPI_ODSO_GETLISTは、FLAT  InMemory  Optimized  DSOのみを返すことができる。
3.  BWは、複数のInfoObjectの完全なメタデータを得るためにAPIを実施することができる。インポートパラメータとして、APIは、InfoObject名の表を受信することができる。エクスポートパラメータとして、APIは、InfoObjectメタデータの表を送信することができる。
4.  BWは、複数のInfoCubeの完全なメタデータを得るためにAPIを実施することができる。これは、InfoCubeメタデータに関する#2と同様のAPIである。
5.  BWは、複数のデータストアオブジェクトの完全なメタデータを得るためにAPIを実施することができる。DSOメタデータに関する#2と同様のAPIである。
6.  BWは、パートプロバイダを含む複数のプロバイダの完全なメタデータを得るためにAPIを実施することができる。
7.  BWは、クエリのためのリストAPIを実施することができる。
8.  BWは、InfoProvider上の制限されたキー数値のためのリストAPIを実施することができる。
9.  BWは、制限されたキー数値(まとめて複数)の詳細を得るためにAPIを実施することができる。
10.  BWは、計算されたキー数値のためのリストAPIを実施することができる。
11.  BWは、計算されたキー数値(複数)の詳細を得るためにAPIを実施することができる。
【００５４】
変換詳細/詳細なワークフロー
【００５５】
インメモリシステムは、以下の概括的な手順によってモデルを変換する。第1に、システムは、キューブファクト表(AVファクト表と呼ばれる)を用いて、キューブをAnalytic  View(AV)に変える。SID表およびX/Y表は、AVデータファンデーションに関連付けることができる。第2に、システムは、ターゲットパッケージを選択するユーザ入力を受信する。例えば、ユーザは、ローカルにターゲットパッケージを生成したいと思うこともあり、ターゲットパッケージなどをトランスポートしたいと思うこともある。第3に、システムは、他のキューブによって生成された共用次元を見つける。これを行う1つの方法は、ログオンデータと共にパッケージを中心構成として有することである。
【００５６】
第4に、システムは、特性(時間およびユニットも)を共用属性ビューに変える。データファンデーション(DF)は、P表およびT表(時間依存性がサポートされている場合はQ表も、下記参照)を含有する。システムは、Compound(複合物)をKey  Attribute(キー属性)に変換する。ナビゲーション属性では、システムは特性「Navigation  enabled」を満たす。
【００５７】
第5に、システムは、date(日付)(および$$date$$制約)を使用してテキストのための時間依存性ならびに属性を変える。これを行うための1つの方法は、dateTo  columnのための固定制約を指定することである。
【００５８】
最後に、システムは、オリジナルモデルであったものを見つけ出すために十分なデータでオリジンを満たす。
【００５９】
システムは、変換を実行することの一部分としてユーザにウィザードを提示することができる。ウィザードは、(例えば、キューブがBWにおいて変更された後に)キューブを作り直したい場合に再スタート可能であるべきである。このために、顧客は変換されたモデルを拡張する(少なくとも、マージ(merge)の間、顧客が作成した階層を保持する)ことを許可されるので、最小マージがサポートされることが可能である。
【００６０】
ウィザードによって実行されるステップは、以下のとおりである(例えば、システムは、選択肢を提示し、ユーザは、システムが変換を実行するための選択肢のうちの1つを選択する)。
1.  InfoCubeを選択する(探索/オプション  ‐  nfoArea階層を表示する)。
2.  (サブ)パッケージを選択する(オプション  ‐  そのシステムのために中央に維持されるパッケージから開始する)。
3.  再利用のためにすでに存在する属性ビューを提案/選択する可能性を有する共用属性ビューに変換されるべき特性を選択する。再利用は、とりわけ時間次元に適している。既存の探索にまだ含まれていないすでに生成された属性ビューを探索するためにオリジンを使用することができる。
4.  キー数値(オプション  ‐  デフォルト、すべてのキー数値)を選択する。
5.  認可を選択する(オプション)。
【００６１】
ウィザードは、他の選択肢を含んでもよい。1つの他の選択肢は、DFを生成するのみの選択肢を提供し、次いで、ユーザが論理モデルを実行することを許可することである。もう1つの他の選択肢は、生成されたものを記憶し、この情報をより良いマージのために再利用することである。リポジトリオブジェクトがこの記憶のために使用されてもよい。
【００６２】
図1は、データを記憶しているインメモリデータベースシステムによってデータを出力する方法100の流れ図である。本方法は、インメモリデータベースシステムの動作を制御するコンピュータプログラムとして実施され得る。
【００６３】
102において、インメモリデータベースシステムは、データウェアハウスシステムによって記憶されている第1のデータにアクセスすることに対応する第1のデータモデルを記憶する。上記で論じられたように、第1のデータモデルは、BWシステムのための既存のモデルに対応する。BWシステムは、インメモリシステムとは異なり(例えば、BWシステムは、行指向ストレージを実施し、インメモリシステムは列指向ストレージを実施する)、したがって、第1のデータモデルは、インメモリシステムからデータを適切に抽出しないことになる。インメモリデータベースシステムは、BWシステムから、例えば上記で論じられたAPIを介して第1のデータモデルを取得した後に、第1のデータモデルを記憶することができる。
【００６４】
104において、インメモリデータベースシステムは、第2のデータを記憶する。概して、インメモリシステムはこの機構のOLAPタスクを実行するためにBWシステムに取って代わるので、(インメモリシステムによって記憶されている)第2のデータは、(BWシステムによって記憶されている)第1のデータに対応する。
【００６５】
106において、インメモリデータベースシステムは、第1のデータモデルを第2のデータにアクセスすることに対応する第2のデータモデルに変換する。変換プロセスの詳細は、上記で論じられたとおりである。変換なしでは、第1のデータモデルは第2のデータにアクセスするように適切に動作しないことになることに留意されたい。
【００６６】
108において、インメモリデータベースシステムは、第2のデータモデルに従い第2のデータを出力する。この出力は、変換されたデータモデルに従ったインメモリシステムの所望のOLAP機能に従うビュー、レポートなどの形態であってもよい。
【００６７】
図2は、本開示の諸実施形態を実施するための例示的コンピュータシステムおよびネットワーク2400のブロック図である。コンピュータシステム2410は、情報を伝達するためのバス2405または他の通信機構、および情報を処理するためのバス2405に結合されたプロセッサ2401を含む。コンピュータシステム2410はまた、前述の技法を実行するための情報および命令を含めて、プロセッサ2401によって実行されるべき情報および命令を記憶するためのバス2405に結合されたメモリ2402を含む。このメモリはまた、プロセッサ2401によって実行されるべき命令の実行中に一時変数または他の中間情報を記憶するために使用されてもよい。このメモリの可能な実施形態は、ランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)(一時変数または他の中間情報を記憶しない場合)、または両方でもよいが、それらに限定されない。ストレージデバイス2403も、情報および命令を記憶するために提供される。ストレージデバイスの概括的な形態は、例えば、ハードドライブ、磁気ディスク、光ディスク、CD-ROM、DVD、フラッシュメモリ、USBメモリカード、ソリッドステートドライブ、またはコンピュータがそこから読み出すことができる任意の他の媒体を含む。ストレージデバイス2403は、例えば、上記の技法を実行し上記の構造を実施するためのソースコード、バイナリコード、またはソフトウェアファイルを記憶することができる。
【００６８】
コンピュータシステム2410は、情報をコンピュータユーザに表示するために、バス2405を介して陰極線管(CRT)または液晶ディスプレイ(LCD)などのディスプレイ2412に結合されていてもよい。キーボードおよび/またはマウスなどの入力デバイス2411は、情報およびコマンド選択をユーザからプロセッサ2401に伝達するために、バス2405に結合される。これらのコンポーネントの組合せによって、ユーザはシステムと通信することができるようになる。システムによっては、バス2405は、複数の専用バスに分割されてもよい。
【００６９】
コンピュータシステム2410はまた、バス2405に結合されたネットワークインターフェース2404を含む。ネットワークインターフェース2404は、コンピュータシステム2410とローカルネットワーク2420との間の双方向通信を提供することができる。ネットワークインターフェース2404は、例えば、電話回線を介してデータ通信接続を提供するためのデジタル加入者回線(DSL)またはモデムでもよい。ネットワークインターフェースの他の例は、データ通信接続を互換LANに提供するためのローカルエリアネットワーク(LAN)カードである。無線リンクももう1つの例である。任意のそのような実施形態では、ネットワークインターフェース2404は、様々なタイプの情報を表すデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送受信する。
【００７０】
コンピュータシステム2410は、ネットワークインターフェース2404を介してイントラネットまたはインターネット2430に、メッセージまたは他のインターフェース動作を含めて、情報を送受信することができる。インターネットの例では、ソフトウェアコンポーネントまたはサービスは、ネットワーク全体にわたって、複数の様々なコンピュータシステム2410、またはサーバ2431、2432、2433、2434および2435に常駐していてもよい。サーバ2431は、1つのコンポーネントから、インターネット2430、ローカルネットワーク2420、およびネットワークインターフェース2404を介して、コンピュータシステム2410上のコンポーネントに動作またはメッセージを送信することができる。
【００７１】
コンピュータシステムおよびネットワーク2400は、クライアントサーバのように構成されてもよい。例えば、コンピュータシステム2410は、サーバを実装することができる。クライアント2415は、コンピュータシステム2410のものと同様のコンポーネントを含んでもよい。
【００７２】
より具体的には、前述のように、コンピュータシステム2410は、インメモリデータベースシステムを実施することができる。コンピュータシステム2410は、前述のモデル変換プロセスを実施することができる。代替として、サーバ2431は、モデル変換プロセスを実施することができ、変換されたモデルをコンピュータシステム2410に提示することができ、この場合、サーバ2431はインメモリデータベースシステムのコンポーネントとみなすことができる。サーバ2432は、BWシステムを実施することができる。
【００７３】
上記説明は、本発明の諸態様がどのように実施され得るかを示す諸例と共に様々な実施形態を例示している。上記諸例および諸実施形態は、単なる実施形態に過ぎないとみなすべきではなく、添付の特許請求の範囲によって定義された本開示の柔軟性および利点を例示するために提示されるものである。上記の開示および添付の特許請求の範囲に基づいて、他の構成、実施形態、実装形態および均等形態が当業者には明らかになり、特許請求の範囲によって定義される本開示の趣旨および範囲から逸脱することなく利用することが可能である。
【符号の説明】
【００７４】
100  データを記憶しているインメモリデータベースシステムによってデータを出力する方法
102  第1のデータにアクセスすることに対応する第1のデータモデルを記憶する
104  第2のデータを記憶する
106  第1のデータモデルを第2のデータにアクセスすることに対応する第2のデータモデルに変換する
108  第2のデータモデルに従い第2のデータを出力する
2400  例示的コンピュータシステムおよびネットワーク
2401  プロセッサ
2402  メモリ
2403  ストレージデバイス
2404  ネットワークインターフェース
2405  バス
2410  コンピュータシステム
2411  入力デバイス
2412  ディスプレイ
2415  クライアント
2420  ローカルネットワーク
2430  インターネット
2431  サーバ
2432  サーバ
2433  サーバ
2434  サーバ
2435  サーバ
【図１】
0006391217.tif 000002
【図２】
0006391217.tif 000003