問題は、データ量の増加に伴い、情報の分析がますます困難になっていることです。 主な問題は生産性が低いことと、多くの場合、ERPシステムに特別な分析ツールがないことです。 したがって、ERPシステムの現在のアーキテクチャにとどまり、許容可能な時間内にデータ分析を実行することはできなくなりました。 すべてがゆっくりと動作するか、一定の速度で減速します。 ERPシステムサーバーの計算能力の向上でさえ、短期的にしか節約できない場合があります。
そのため、約30年前、ソフトウェアアーキテクトは新しいクラスのシステム、つまりデータウェアハウスを作成することを考えていました。 データウェアハウジング（HD）を実装するための目標は、通常次のとおりです。
- 分析に最適な構造でのデータの蓄積と保存。
- 複数のシステムからのデータの統合。
- ERPシステムの計算負荷の軽減-データプロバイダー。
- ユーザーに機能を提供する：
- 便利なツールを使用して、独自のデータに関するレポートを作成します。
- これまで使用されたことのないデータマイニング、OLAP分析機能を使用します。
問題はすぐにリポジトリ内のデータを適切に整理する方法になりました。そのため、「分析に最適な構造」の要件を満たすだけでなく、開発と保守のためのリソースのコストを管理し、維持することも可能になります。 試行錯誤を通じて、データウェアハウスアーキテクトは、層状パイアーキテクチャ、 LSA-Layered Scalable Architectureを思いつきました。 さらに、その名前が示すように、階層化だけでなく、スケーラブルでもあります。
図では、LSAは緑色のブロックです。 その上には、Excel、インターネットブラウザー、またはCDからデータをアップロードするための単なるファイル形式に基づいてレポートデータを視覚化するためのツールがあります。 緑色のLSAブロックの下には、データプロバイダーシステムのタイプがあります。
実装の観点から言うと、LSAはCDのデータ（DBMSテーブルに関して）を持つ構造を論理的に分割して、それぞれが特定の機能を実行するいくつかのレベルにあると言えます。 データはレベルごとにコピーされ、コピー中に変換され、分析に最適な構造になります（ストレージ展開の目標を参照）。 各レベルは1つのオブジェクトではなく、1つの構造とテーブルでもありません。 同じレベルの99％のケースでは、さまざまな構造の多くのオブジェクトがあります。
前述のように、データはサプライヤシステムからCDにコピーする必要があります。これにより、分析計算中の負荷がCDにかかるようになります。 ダウンロード形式でデータを一時的に保存するためのLSAアーキテクチャは、特別な「ダウンロードレベル」を提供します。 このレベルにロードする場合、データ変換は行われません。 型チェックのみが実行されます。 たとえば、数字フィールドに文字が書き込まれないように、「8月32日」などはありません。
このレベルのデータが保存された後、t.z。 CDのそれ以降の処理は、データがファイル、ERPシステム、または異なるタイプのソースから来た場合、すでに「すべて同じ」です。 t.zを使用したブートレベルのストレージ。 LSAは一時的なものと見なされます。 したがって、通常、次のダウンロードが正常に実行された直後に、データは「より高く」コピーされ、次のレベルへの途中で変換されます。 通常、負荷レベルでは、データを5〜10日以内に保存してから削除することをお勧めします。 データをより長期間保存すること、このレベルで大量のデータを蓄積することは、パフォーマンス上の理由から合理的ではありません。 実際、読み取り時に、このレベルのテーブルのインデックス化されていないフィールドによるフィルタリングは、長い遅延で実行できます。
ただし、「ダウンロード」形式のデータが5〜10日よりはるかに遅れてCDで必要になる場合があります。 このような場合、HDは、写真に表示されていないレベルの「企業メモリ」を提供します。 フィールドの構造と構成により、各コーポレートメモリオブジェクトは対応する負荷レベルオブジェクトと同一です。 ただし、企業メモリのデータはすぐには削除されません。 ただし、「無限」ボリュームを条件付きで蓄積しないために、このレベルのデータを定期的にアーカイブし、その後オンデマンドで迅速に回復できるようにする必要があります。
「データウェアハウスレベル」と呼ばれる次のレベルでは、消費者（ユーザーレポート、他のシステム）に必要となる可能性のある最も詳細な構造のデータがあります。 重要なお知らせ：プロジェクトで定められた要件に応じた消費者のみ！ これは常にそうではありませんが。 経験豊富なCDアーキテクトは、調査および設計時に不明な要件を予測し、モデルに含めるようにしてください。 クライアントがそれらをアナウンスするとき、それらはデータモデルによって既に提供されているか、モデルの修正に時間がかかりません。
ストレージレベルにロードする場合、次の操作を実行できます（リストは不完全です）。
- 意味は同種ですが、参照コードコードは異なります。 たとえば、性別FとFは同じ値に減らす必要があります。
- 可能な限り最も詳細なデータを必要とする計算（たとえば、ドキュメントアイテムからの為替レートでの通貨の変換）。
- アナリスト値の妥当性をチェックします（チェック制約）。
- フィルタリング。
このレベルのオブジェクトにロードを設定するときは、「分離」を観察することを強くお勧めします。 ストレージレベルの1つのオブジェクトをロードするときの変換ロジックは、同じレベルの別のオブジェクトのデータに依存するべきではありません。 それ以外の場合は、ロードの順序を観察する必要があり、変換のロジックが複雑な場合、ダウンロードの終わりの「相互期待」の状況に陥るのは簡単です。
データが「真実の単一バージョン」を表すのは、ウェアハウスレベルです。 消費者から質問がある場合は、データの品質をストレージレベルに対応させ、そこで確認する必要があります。 これがこのように機能するためには、タイムリーで技術的に正しいデータをこのレベルまでロードし、すべてのチェックなどのパフォーマンスを行うプロセスが非常に重要になります。
これがすべて完了し、データウェアハウスレベルで真実の単一バージョンがあるとします。 ただし、ここでの情報は最も詳細な構造で保存されます。これは通常、大量のデータを意味します。 さらに、このレベルでは、すべての必須指標と分析が計算されて保存されるわけではありません。 実際、不必要な計算が多数あるため、最大のデータ粒度ですべての必要な指標をレベルで計算することは不合理かもしれません。 計算には、データの予備的な集計だけでなく、同じレベルの他のオブジェクトのデータも必要になる場合があります。 また、たとえば、他のオブジェクトには異なる更新規則があります...
したがって、ユーザーグループおよび/またはレポートグループのニーズに合わせたデータのサブセットを格納する次の、既に下から3番目のデータレベルが必要です。 このレベルは「 データストアフロントレベル 」と呼ばれます 。
このレベルでは、単純な集約（たとえば、商品グループへの圧縮と1か月の出荷）とともに、データウェアハウスレベルの複数のオブジェクトからのデータもマージされます。 このレベルのオブジェクトでは、インジケーターとアナリストの計算結果が保存されます。
最後のレベルは、 仮想データプロバイダーとレポートです。 独自のレベルと「データマート」レベルの両方のさまざまなオブジェクトからのデータを（仮想、つまりストレージなしで）結合することを目的としています。 最後に、ユーザーレポートがここで定義されます。これには通常、インジケーターを計算するためのロジックも含まれます。
図のxDBMSシリンダーは、3つの下位レベルに影響します。 DBMSテーブルに対応するレベルのデータを保存することを意味します。 スキームから次のように、最高の「仮想」レベルのデータは、DBMSテーブルに保存されず、そこから読み取られます。
そして、もちろん、図のナポレオンケーキは、レイヤー化の優れたメタファーです。 ナポレオンの場合のように、層の数が標準で設定されていない場合、LSAもドグマではありません。 LSAの概念は、レベルの基本セットに焦点を合わせるためのHDデータモデルの設計のみを提供します。 そして、残りは
SAPは1998年にデータウェアハウスクラスの製品を発売しました。 これは、SAPの世界で広く知られているSAP NetWeaver BW（ビジネスウェアハウスまたはSAP BW）です。 それ以来、SAP BWは常に改善され、新しいバージョンが定期的にリリースされています。 SAP BWは、すぐに使用できるデータウェアハウスではなく、データウェアハウスを作成するためのツールです。 SAP BWでデータウェアハウスが構築されるオブジェクトタイプのセットは、LSAレベルに完全に適合します。各レベルには、推奨されるオブジェクトタイプのセットがあります。
- 負荷レベルの場合、これらはPSAテーブル（永続ステージ領域）を持つデータソースです。
- データウェアハウスレベルの場合、これらは標準のDSO（データストアオブジェクト）です。
- 企業のメモリ層の場合、これは書き込み最適化DSOです
- 「データマート」レベルの場合-インフォキューブ。
- 最後に、「仮想プロバイダーとレポート」の最終レベル-マルチプロバイダー、情報セット、仮想情報キューブ、およびBex Query Designerツールで作成されたレポート自体。
これらすべてのレベルのすべてのこれらのオブジェクト（レポートとデータソースを除く）は、SAP BWに組み込まれたいわゆる「データモデル」を形成します。 情報オブジェクト-標識（他の名前：特性、分析）およびインジケーター。 BWの情報オブジェクトは、家を建てるときのレンガのようなものです。 これは、技術的な観点から、および機能的な観点から、SAP BWデータモデルでは、info-objects-signsが参照情報を実装します。
SAP BWでは、「変換」や「データ転送プロセス」などのオブジェクトを使用して、変換の実装でレベル間でデータをコピーします。 データモデルを抽出、変換、およびロードする一連のアクションを定期的に実行するために、「プロセスチェーン」のコンストラクタが提供されます。
SAP BWのすべてのバージョンは、主要ベンダーであるOracle、Microsoft、IBM、SAP / Sybaseの主要なリレーショナルDBMSとして使用できます。 ここでの「基本」とは、すべてのビジネスデータ、メタデータ、およびシステム情報がDBMSテーブルに格納されることを意味します。
どのDBMSを選択した場合でも、SAP BWで効果的なデータモデルを設計するには、統一されたLSAルールをお勧めします。
2012年から、SAP BWは上記のものに加えて 、メインおよびDBMSとしてSAP HANAをサポートしています 。 SAP HANA DBMSの新しい機能と同じ名前のプラットフォームにより、LSAを大幅に再考することが可能になり、HANA上のBWのいくつかの重要なアプローチが事実上変更されました。これは新しいLSA ++名に反映されます。 次の出版物のいずれかで、変更について詳しく説明します。