データウェアハウジング-概要

「データウェアハウス」という用語は、1990年にビル・インモンによって最初に造られました。 Inmonによると、データウェアハウスは、主題指向の統合された時変の不揮発性データコレクションです。このデータは、アナリストが組織内で情報に基づいた意思決定を行うのに役立ちます。

運用データベースは、発生するトランザクションのために、毎日頻繁に変更されます。経営幹部が製品、サプライヤ、消費者データなどのデータに関する以前のフィードバックを分析したい場合、幹部はトランザクションのために以前のデータが更新されているため、分析できるデータはありません。

データウェアハウスは、多次元ビューで一般化および統合されたデータを提供します。データの一般化され統合されたビューに加えて、データウェアハウスはオンライン分析処理（OLAP）ツールも提供します。これらのツールは、多次元空間のデータのインタラクティブで効果的な分析に役立ちます。この分析により、データの一般化とデータマイニングが行われます。

関連付け、クラスタリング、分類、予測などのデータマイニング機能をOLAP操作と統合して、複数レベルの抽象化で対話型の知識マイニングを強化できます。これが、データウェアハウスがデータ分析とオンライン分析処理の重要なプラットフォームになった理由です。

データウェアハウスについて

データウェアハウスはデータベースであり、組織の運用データベースとは別に保管されます。
データウェアハウスで頻繁に行われる更新はありません。
組織がビジネスを分析するのに役立つ、統合された履歴データを所有しています。
データウェアハウスは、経営幹部がデータを整理、理解、使用して戦略的な意思決定を行えるようにします。
データウェアハウスシステムは、多様なアプリケーションシステムの統合を支援します。
データウェアハウスシステムは、統合された履歴データ分析に役立ちます。

データウェアハウスが運用データベースから分離されている理由

データウェアハウスは、次の理由により、運用データベースとは別に保管されます-

運用データベースは、特定のレコードの検索、インデックス作成など、よく知られているタスクとワークロード用に構築されます契約では、データウェアハウスクエリはしばしば複雑であり、一般的な形式のデータを提示します。
オペレーションデータベースは、複数のトランザクションの同時処理をサポートします。データベースの堅牢性と一貫性を確保するために、運用データベースには同時実行制御と回復メカニズムが必要です。
操作可能なデータベースクエリでは、操作の読み取りと変更が可能ですが、OLAPクエリでは、保存されたデータの*読み取り専用*アクセスのみが必要です。
運用データベースは、現在のデータを維持します。一方、データウェアハウスは履歴データを保持します。

データウェアハウスの機能

データウェアハウスの主要な機能は以下で説明されています-

サブジェクト指向-データウェアハウスは、組織の継続的な運用ではなく、サブジェクトに関する情報を提供するため、サブジェクト指向です。これらのサブジェクトには、製品、顧客、サプライヤー、売上、収益などがあります。データウェアハウスは、進行中の運用に焦点を当てるのではなく、意思決定のためのデータのモデリングと分析に焦点を合わせます。
統合-データウェアハウスは、リレーショナルデータベース、フラットファイルなどの異種ソースからのデータを統合することにより構築されます。この統合により、データの効果的な分析が強化されます。
Time Variant -データウェアハウスで収集されたデータは、特定の期間で識別されます。データウェアハウスのデータは、履歴の観点から情報を提供します。
不揮発性-不揮発性とは、新しいデータが追加されても以前のデータが消去されないことを意味します。データウェアハウスは運用データベースとは別に保管されるため、運用データベースの頻繁な変更はデータウェアハウスに反映されません。

注意-データウェアハウスは、物理的に保存され、運用データベースから分離されているため、トランザクション処理、リカバリ、および同時実行性の制御は必要ありません。

データウェアハウスアプリケーション

前に説明したように、データウェアハウスは、経営幹部が意思決定のためにデータを整理、分析、使用するのに役立ちます。データウェアハウスは、企業経営のための計画実行評価「クローズドループ」フィードバックシステムの唯一の部分として機能します。データウェアハウスは、次の分野で広く使用されています-

金融業務
銀行サービス
消費財
小売部門
制御された製造

データウェアハウスの種類

情報処理、分析処理、およびデータマイニングは、以下で説明する3種類のデータウェアハウスアプリケーションです。

情報処理-データウェアハウスでは、そこに保存されているデータを処理できます。データは、クエリ、基本的な統計分析、クロスタブ、テーブル、チャート、またはグラフを使用したレポートによって処理できます。
分析処理-データウェアハウスは、格納されている情報の分析処理をサポートします。データは、スライスアンドダイス、ドリルダウン、ドリルアップ、ピボットなどの基本的なOLAP操作によって分析できます。
データマイニング-データマイニングは、隠れたパターンと関連性を見つけ、分析モデルを構築し、分類と予測を実行することにより、知識発見をサポートします。これらのマイニング結果は、視覚化ツールを使用して表示できます。

Sr.No.	Data Warehouse (OLAP)	Operational Database(OLTP)
1	It involves historical processing of information.	It involves day-to-day processing.
2	OLAP systems are used by knowledge workers such as executives, managers, and analysts.	OLTP systems are used by clerks, DBAs, or database professionals.
3	It is used to analyze the business.	It is used to run the business.
4	It focuses on Information out.	It focuses on Data in.
5	It is based on Star Schema, Snowflake Schema, and Fact Constellation Schema.	It is based on Entity Relationship Model.
6	It focuses on Information out.	It is application oriented.
7	It contains historical data.	It contains current data.
8	It provides summarized and consolidated data.	It provides primitive and highly detailed data.
9	It provides summarized and multidimensional view of data.	It provides detailed and flat relational view of data.
10	The number of users is in hundreds.	The number of users is in thousands.
11	The number of records accessed is in millions.	The number of records accessed is in tens.
12	The database size is from 100GB to 100 TB.	The database size is from 100 MB to 100 GB.
13	These are highly flexible.	It provides high performance.

データウェアハウジング-概念

データウェアハウジングとは何ですか？

データウェアハウジングは、データウェアハウスを構築して使用するプロセスです。データウェアハウスは、分析レポート、構造化および/またはアドホッククエリ、意思決定をサポートする複数の異種ソースからのデータを統合することで構築されます。データウェアハウジングには、データクリーニング、データ統合、およびデータ統合が含まれます。

データウェアハウス情報の使用

データウェアハウスで利用可能なデータの利用を支援する意思決定支援技術があります。これらのテクノロジーは、幹部が倉庫を迅速かつ効果的に使用するのに役立ちます。データを収集して分析し、ウェアハウスに存在する情報に基づいて決定を下すことができます。倉庫で収集された情報は、次のドメインのいずれかで使用することができます-

生産戦略の調整-製品の戦略は、四半期ごとまたは年ごとの売上を比較して製品の位置を変更し、製品ポートフォリオを管理することにより、適切に調整できます。
顧客分析-顧客分析は、顧客の購入の好み、購入時間、予算サイクルなどを分析することによって行われます。
運用分析-データウェアハウジングは、顧客関係管理や環境修正にも役立ちます。また、この情報により、ビジネスオペレーションを分析できます。

異種データベースの統合

異種データベースを統合するには、2つのアプローチがあります-

クエリ駆動型アプローチ
更新主導のアプローチ

クエリ駆動型アプローチ

これは、異種データベースを統合する従来のアプローチです。このアプローチは、複数の異種データベースの上にラッパーとインテグレーターを構築するために使用されました。これらのインテグレーターは、メディエーターとも呼ばれます。

クエリ駆動型アプローチのプロセス

クエリがクライアント側に発行されると、メタデータディクショナリは、クエリを、関係する個々の異種サイトに適した形式に変換します。
現在、これらのクエリはマップされ、ローカルクエリプロセッサに送信されます。
異種サイトからの結果は、グローバルな回答セットに統合されます。

デメリット

クエリ駆動型アプローチには、複雑な統合プロセスとフィルタリングプロセスが必要です。
このアプローチは非常に非効率的です。
頻繁なクエリでは非常に高価です。
このアプローチは、集計が必要なクエリにとっても非常に高価です。

更新主導のアプローチ

これは、従来のアプローチの代替手段です。今日のデータウェアハウスシステムは、前述の従来のアプローチではなく、更新主導のアプローチを採用しています。更新主導のアプローチでは、複数の異種ソースからの情報が事前に統合され、ウェアハウスに保存されます。この情報は、直接のクエリと分析に利用できます。

利点

このアプローチには、次の利点があります-

このアプローチは、高いパフォーマンスを提供します。
データは、セマンティックデータストアで事前にコピー、処理、統合、注釈付け、要約、および再構築されます。
クエリ処理では、ローカルソースでデータを処理するためのインターフェイスは必要ありません。

データウェアハウスのツールとユーティリティの機能

以下は、データウェアハウスのツールとユーティリティの機能です-

データ抽出-複数の異種ソースからデータを収集します。
データクリーニング-データのエラーを見つけて修正します。
データ変換-データをレガシー形式からウェアハウス形式に変換します。
データのロード-整合性の確認、インデックスおよびパーティションの構築、要約、統合、チェックを含みます。
更新-データソースからウェアハウスへの更新を伴います。

注-データのクリーニングとデータ変換は、データの品質とデータマイニングの結果を改善するための重要な手順です。

データウェアハウジング-用語

この章では、データウェアハウジングで最もよく使用される用語について説明します。

メタデータ

メタデータは、単にデータに関するデータとして定義されます。他のデータを表すために使用されるデータは、メタデータと呼ばれます。たとえば、本のインデックスは本の内容のメタデータとして機能します。つまり、メタデータは、詳細データにつながる要約データであると言えます。

データウェアハウスの観点から、メタデータを次のように定義できます-

メタデータは、データウェアハウスへのロードマップです。
データウェアハウスのメタデータは、ウェアハウスオブジェクトを定義します。
メタデータはディレクトリとして機能します。このディレクトリは、意思決定支援システムがデータウェアハウスのコンテンツを見つけるのに役立ちます。

メタデータリポジトリ

メタデータリポジトリは、データウェアハウスシステムの不可欠な部分です。次のメタデータが含まれています-

ビジネスメタデータ-データ所有権情報、ビジネス定義、および変更ポリシーが含まれています。
運用メタデータ-データの通貨とデータ系統が含まれます。データの通貨とは、アクティブ、アーカイブ、またはパージされるデータを指します。データの系統とは、移行されたデータの履歴とそれに適用される変換を意味します。
運用環境からデータウェアハウスにマッピングするためのデータ-メタデータには、ソースデータベースとそのコンテンツ、データ抽出、データパーティション、クリーニング、変換ルール、データ更新、パージルールが含まれます。
要約のアルゴリズム-ディメンションアルゴリズム、粒度、集計、要約などのデータが含まれます。

データキューブ

データキューブは、複数のディメンションでデータを表すのに役立ちます。ディメンションとファクトによって定義されます。ディメンションは、企業がレコードを保持する対象となるエンティティです。

データキューブの図

ある会社が、販売データウェアハウスの助けを借りて、時間、アイテム、支店、場所に関して販売記録を追跡したいとします。これらのディメンションにより、毎月の売上とアイテムが販売された支店を追跡できます。各ディメンションに関連付けられたテーブルがあります。このテーブルは、ディメンションテーブルと呼ばれます。たとえば、「item」ディメンションテーブルには、item_name、item_type、item_brandなどの属性があります。

次の表は、時間、アイテム、および場所のディメンションに関する会社の販売データの2Dビューを表しています。

データキューブ2D

しかし、この2Dテーブルには、時間とアイテムのみに関するレコードがあります。ニューデリーの売上高は、時間、および販売されたアイテムのタイプに応じたアイテムのディメンションに関して表示されます。もう1つのディメンション（ロケーションディメンションなど）を使用して販売データを表示する場合は、3Dビューが役立ちます。時間、アイテム、場所に関する販売データの3-Dビューは、以下の表に示されています-

data cube 3D

上記の3-Dテーブルは、次の図に示すように3-Dデータキューブとして表すことができます-

data cube 3D

データ市場

データマートには、組織内の特定の人々のグループにとって有益な組織全体のデータのサブセットが含まれています。つまり、データマートには、特定のグループに固有のデータのみが含まれます。たとえば、マーケティングデータマートには、アイテム、顧客、および販売に関連するデータのみが含まれる場合があります。データマートは対象に限定されます。

データマートに関する注意点

WindowsベースまたはUnix/Linuxベースのサーバーは、データマートを実装するために使用されます。これらは低コストのサーバーに実装されています。
データマートの実装サイクルは、短期間、つまり数か月または数年ではなく数週間で測定されます。
データマートのライフサイクルは、計画と設計が組織全体に当てはまらない場合、長期的には複雑になる可能性があります。
データマートのサイズは小さいです。
データマートは部門ごとにカスタマイズされます。
データマートのソースは、部門ごとに構造化されたデータウェアハウスです。
データマートは柔軟です。

次の図は、データマートのグラフィカルな表現を示しています。

データマート

仮想倉庫

運用データウェアハウスのビューは、仮想ウェアハウスと呼ばれます。仮想倉庫の構築は簡単です。仮想倉庫を構築するには、稼働中のデータベースサーバーに過剰な容量が必要です。

データウェアハウジング-配信プロセス

データウェアハウスは決して静的ではありません。ビジネスが拡大するにつれて進化します。ビジネスが進化するにつれて、その要件は変化し続けるため、これらの変化に対応するようにデータウェアハウスを設計する必要があります。したがって、データウェアハウスシステムには柔軟性が必要です。

理想的には、データウェアハウスを配信する配信プロセスが必要です。ただし、データウェアハウスプロジェクトは通常、さまざまな問題に悩まされており、ウォーターフォール法で要求される厳密かつ秩序立った方法でタスクと成果物を完了することが困難です。ほとんどの場合、要件は完全には理解されていません。アーキテクチャ、設計、およびビルドコンポーネントは、すべての要件を収集して調査した後にのみ完成できます。

配送方法

配信方法は、データウェアハウスの配信に採用された共同アプリケーション開発アプローチの変形です。リスクを最小限に抑えるために、データウェアハウスの配信プロセスを準備しました。ここで説明するアプローチは、全体的な配信時間スケールを短縮するものではありませんが、開発プロセスを通じてビジネス上のメリットが徐々に提供されることを保証します。

注-プロジェクトと配信のリスクを軽減するために、配信プロセスはフェーズに分割されています。

次の図は、配信プロセスの段階を説明しています-

配信方法

IT戦略

データウェアハウスは、利益を生み出すためにビジネスプロセスを必要とする戦略的投資です。プロジェクトの資金を調達して維持するには、IT戦略が必要です。

ビジネスケース

ビジネスケースの目的は、データウェアハウスの使用から得られるビジネス上の利点を見積もることです。これらの利点は定量化できない場合がありますが、予測される利点を明確に述べる必要があります。データウェアハウスに明確なビジネスケースがない場合、ビジネスは配信プロセスのある段階で信頼性の問題に悩まされる傾向があります。したがって、データウェアハウスプロジェクトでは、投資のビジネスケースを理解する必要があります。

教育とプロトタイピング

組織は、データ分析の概念を実験し、ソリューションに落ち着く前にデータウェアハウスを持つことの価値について教育します。これはプロトタイピングによって対処されます。データウェアハウスの実現可能性と利点を理解するのに役立ちます。小規模のプロトタイピング活動は、以下の限り教育プロセスを促進できます-

プロトタイプは、定義された技術目標に対応しています。
プロトタイプは、実現可能性の概念が示された後に廃棄することができます。
このアクティビティは、データウェアハウスの最終的なデータコンテンツの小さなサブセットに対応します。
アクティビティのタイムスケールは重要ではありません。

早期のリリースを作成し、ビジネス上のメリットをもたらすには、次の点に留意する必要があります。

進化できるアーキテクチャを特定します。
ビジネス要件と技術設計図フェーズに焦点を当てます。
最初のビルドフェーズの範囲を、ビジネス上のメリットをもたらす最小限に制限します。
データウェアハウスの短期および中期の要件を理解します。

ビジネス要件

質の高い成果物を提供するには、全体的な要件を確実に理解する必要があります。短期および中期の両方のビジネス要件を理解していれば、短期要件を満たすソリューションを設計できます。その後、短期的なソリューションを完全なソリューションに成長させることができます。

次の側面は、この段階で決定されます-

データに適用されるビジネスルール。
データウェアハウス内の情報の論理モデル。
当面の要件のクエリプロファイル。
このデータを提供するソースシステム。

技術的な青写真

このフェーズでは、長期的な要件を満たすアーキテクチャ全体を提供する必要があります。このフェーズでは、ビジネス上のメリットを得るために短期的に実装する必要があるコンポーネントも提供します。設計図では、以下を識別する必要があります。

全体的なシステムアーキテクチャ。
データ保持ポリシー。
バックアップと復元の戦略。
サーバーおよびデータマートのアーキテクチャ。
ハードウェアとインフラストラクチャの容量計画。
データベース設計のコンポーネント。

バージョンの構築

この段階では、最初の生産成果物が生産されます。この製品は、データウェアハウスの最小コンポーネントです。この最小のコンポーネントはビジネス上の利点を追加します。

履歴ロード

これは、必要な履歴の残りがデータウェアハウスにロードされるフェーズです。この段階では、新しいエンティティは追加しませんが、追加の物理テーブルを作成して、増加したデータボリュームを格納する可能性があります。

例を挙げましょう。ビルドバージョンフェーズが2か月分の履歴を持つ小売販売分析データウェアハウスを提供したとします。この情報により、ユーザーは最近の傾向のみを分析し、短期的な問題に対処できます。この場合、ユーザーは年次および季節的な傾向を特定できません。そのために、過去2年間の販売履歴をアーカイブから読み込むことができます。これで、40GBのデータが400GBに拡張されました。

注意-バックアップとリカバリの手順は複雑になる可能性があるため、別のフェーズでこのアクティビティを実行することをお勧めします。

アドホッククエリ

このフェーズでは、データウェアハウスの運用に使用されるアドホッククエリツールを構成します。これらのツールは、データベースクエリを生成できます。

注意-データベースが大幅に変更されている場合、これらのアクセスツールを使用しないことをお勧めします。

オートメーション

このフェーズでは、運用管理プロセスが完全に自動化されています。これらは含まれます-

データを分析に適した形式に変換します。
クエリプロファイルを監視し、システムパフォーマンスを維持するための適切な集計を決定します。
異なるソースシステムからのデータの抽出とロード。
データウェアハウス内の事前定義された定義から集計を生成します。
データのバックアップ、復元、およびアーカイブ。

スコープの拡大

このフェーズでは、データウェアハウスが拡張され、ビジネス要件の新しいセットに対応します。スコープは2つの方法で拡張することができます-

追加のデータをデータウェアハウスにロードする。
既存の情報を使用して新しいデータマートを導入する。

注-このフェーズはかなりの労力と複雑さを伴うため、個別に実行する必要があります。

要件の進化

配信プロセスの観点から、要件は常に変更可能です。それらは静的ではありません。配信プロセスはこれをサポートし、これらの変更がシステム内に反映されるようにする必要があります。

この問題は、既存のクエリのデータ要件とは対照的に、ビジネスプロセス内のデータの使用に関するデータウェアハウスを設計することで対処されています。

アーキテクチャは、ビジネスニーズに合わせて変更および成長するように設計されており、プロセスは疑似アプリケーション開発プロセスとして動作します。このプロセスでは、新しい要件が開発アクティビティに継続的に供給され、部分的な成果物が生成されます。これらの部分的な成果物はユーザーにフィードバックされた後、ビジネスニーズに合わせてシステム全体が継続的に更新されるように修正されます。

データウェアハウジング-システムプロセス

運用データベースに適用される操作の数は固定されており、正規化されたデータを使用、*テーブルを小さく保持*などの明確に定義された手法があります。これらの手法は、ソリューションの提供に適しています。しかし、意思決定支援システムの場合、今後実行する必要があるクエリと操作はわかりません。したがって、運用データベースに適用される手法は、データウェアハウスには適していません。

この章では、Unixやリレーショナルデータベースなどのトップオープンシステムテクノロジーでデータウェアハウジングソリューションを構築する方法について説明します。

データウェアハウスのプロセスフロー

データウェアハウスに寄与する4つの主要なプロセスがあります-

データを抽出してロードします。
データのクリーニングと変換。
データをバックアップおよびアーカイブします。
クエリを管理し、それらを適切なデータソースに転送します。

プロセスフロー

抽出およびロードプロセス

データ抽出は、ソースシステムからデータを取得します。データロードは、抽出されたデータを取得してデータウェアハウスにロードします。

注意-データウェアハウスにデータをロードする前に、外部ソースから抽出した情報を再構築する必要があります。

プロセスの制御

プロセスの制御には、データ抽出の開始時期の決定とデータの整合性チェックが含まれます。プロセスを制御することにより、ツール、ロジックモジュール、およびプログラムが正しい順序で正しいタイミングで実行されるようになります。

抽出を開始するタイミング

データは、抽出時に一貫した状態である必要があります。つまり、データウェアハウスは、ユーザーに対して単一の一貫したバージョンの情報を表す必要があります。

たとえば、電気通信部門の顧客プロファイリングデータウェアハウスでは、水曜日の午後8時に顧客データベースから顧客のリストを、火曜日の午後8時までの顧客サブスクリプションイベントとマージすることは非論理的です。これは、関連するサブスクリプションがない顧客を見つけることを意味します。

データの読み込み

データを抽出した後、一時データストアにロードされ、そこでクリーンアップされて一貫性が保たれます。

注-整合性チェックは、すべてのデータソースが一時データストアにロードされた場合にのみ実行されます。

クリーンおよび変換プロセス

データが抽出され、一時データストアにロードされたら、クリーニングと変換を実行します。ここにクリーニングと変換に関与するステップのリストがあります-

ロードされたデータをクリーンにし、構造に変換します
データを分割する
集約

ロードされたデータをクリーンにし、構造に変換します

ロードされたデータのクリーニングと変換は、クエリの高速化に役立ちます。データを一貫性のあるものにすることで実現できます-

それ自体の中。
同じデータソース内の他のデータと。
他のソースシステムのデータを使用します。
ウェアハウスに存在する既存のデータを使用します。

変換では、ソースデータを構造に変換します。データを構造化すると、クエリのパフォーマンスが向上し、運用コストが削減されます。データウェアハウスに含まれるデータは、パフォーマンス要件をサポートし、継続的な運用コストを制御するために変換する必要があります。

データを分割する

ハードウェアのパフォーマンスを最適化し、データウェアハウスの管理を簡素化します。ここでは、各ファクトテーブルを複数の個別のパーティションに分割します。

集約

一般的なクエリを高速化するには、集計が必要です。集約は、最も一般的なクエリが詳細データのサブセットまたは集約を分析するという事実に依存しています。

データのバックアップとアーカイブ

データの損失、ソフトウェアの障害、またはハードウェアの障害が発生した場合にデータを回復するには、定期的なバックアップを維持する必要があります。アーカイブには、必要なときにすぐに復元できる形式でシステムから古いデータを削除することが含まれます。

たとえば、小売販売分析データウェアハウスでは、最新の6か月のデータをオンラインで保持しながら、3年間データを保持する必要がある場合があります。このようなシナリオでは、多くの場合、今年と昨年の月ごとの比較を実行できる必要があります。この場合、一部のデータをアーカイブから復元する必要があります。

クエリ管理プロセス

このプロセスは、次の機能を実行します-

クエリを管理します。
querisの実行時間を短縮するのに役立ちます。
クエリを最も効果的なデータソースに誘導します。
すべてのシステムソースが最も効果的な方法で使用されるようにします。
実際のクエリプロファイルを監視します。

このプロセスで生成された情報は、生成する集計を決定するために倉庫管理プロセスによって使用されます。通常、このプロセスは、データウェアハウスへの情報の定期的なロード中には機能しません。

データウェアハウジング-アーキテクチャ

この章では、データウェアハウスの設計とアーキテクチャのデータウェアハウスのビジネス分析フレームワークについて説明します。

ビジネス分析フレームワーク

ビジネスアナリストは、データウェアハウスから情報を取得してパフォーマンスを測定し、市場の他のビジネスホルダーに勝つために重要な調整を行います。データウェアハウスを持つことには、次の利点があります-

データウェアハウスは情報を迅速かつ効率的に収集できるため、ビジネスの生産性を向上させることができます。
データウェアハウスは、顧客とアイテムの一貫したビューを提供するため、顧客関係の管理に役立ちます。
データウェアハウスは、傾向、長期にわたるパターンを一貫した信頼性の高い方法で追跡することにより、コストの削減にも役立ちます。

効果的で効率的なデータウェアハウスを設計するには、ビジネスニーズを理解して分析し、*ビジネス分析フレームワーク*を構築する必要があります。データウェアハウスの設計に関しては、各人が異なる見解を持っています。これらのビューは次のとおりです-

トップダウンビュー-このビューでは、データウェアハウスに必要な関連情報を選択できます。
データソースビュー-このビューには、運用システムによってキャプチャ、保存、および管理されている情報が表示されます。
データウェアハウスビュー-このビューには、ファクトテーブルとディメンションテーブルが含まれます。データウェアハウス内に格納されている情報を表します。
ビジネスクエリビュー-エンドユーザーの視点からのデータのビューです。

3層データウェアハウスアーキテクチャ

通常、データウェアハウスは3層アーキテクチャを採用しています。以下は、データウェアハウスアーキテクチャの3つの層です。

*最下層-アーキテクチャの最下層は、データウェアハウスデータベースサーバーです。これはリレーショナルデータベースシステムです。バックエンドのツールとユーティリティを使用して、データを最下層に送ります。これらのバックエンドツールとユーティリティは、抽出、クリーン、ロード、およびリフレッシュ機能を実行します。
中間層-中間層には、次のいずれかの方法で実装できるOLAPサーバーがあります。
拡張リレーショナルデータベース管理システムであるリレーショナルOLAP（ROLAP）による。 ROLAPは、多次元データの操作を標準のリレーショナル操作にマップします。
多次元OLAP（MOLAP）モデル。多次元データと操作を直接実装します。
最上層-この層はフロントエンドクライアント層です。このレイヤーには、クエリツールとレポートツール、分析ツール、データマイニングツールが含まれています。

次の図は、データウェアハウスの3層アーキテクチャを示しています-

データウェアハウジングアーキテクチャ

データウェアハウスモデル

データウェアハウスアーキテクチャの観点から、次のデータウェアハウスモデルがあります-

仮想倉庫
データ市場
エンタープライズウェアハウス

仮想倉庫

運用データウェアハウスのビューは、仮想ウェアハウスと呼ばれます。仮想倉庫の構築は簡単です。仮想倉庫を構築するには、稼働中のデータベースサーバーに過剰な容量が必要です。

データ市場

データマートには、組織全体のデータのサブセットが含まれます。このデータのサブセットは、組織の特定のグループにとって貴重です。

つまり、データマートには特定のグループに固有のデータが含まれていると主張できます。たとえば、マーケティングデータマートには、アイテム、顧客、および販売に関連するデータが含まれる場合があります。データマートは対象に限定されます。

データマートについて覚えておくべき点-

ウィンドウベースまたはUnix/Linuxベースのサーバーは、データマートを実装するために使用されます。これらは低コストのサーバーに実装されています。
実装データマートサイクルは短期間、つまり数か月または数年ではなく数週間で測定されます。
データマートのライフサイクルは、計画と設計が組織全体に及ばない場合、長期的には複雑になる場合があります。
データマートのサイズは小さいです。
データマートは部門ごとにカスタマイズされます。
データマートのソースは、部門ごとに構造化されたデータウェアハウスです。
データマートは柔軟です。

エンタープライズウェアハウス

エンタープライズウェアハウスは、組織全体にわたるすべての情報とサブジェクトを収集します
企業全体のデータ統合を提供します。
データは、運用システムと外部の情報プロバイダーから統合されます。
この情報は、数ギガバイトから数百ギガバイト、テラバイト以上までさまざまです。

ロードマネージャー

このコンポーネントは、プロセスの抽出とロードに必要な操作を実行します。

ロードマネージャーのサイズと複雑さは、データウェアハウスごとのソリューションによって異なります。

ロードマネージャーのアーキテクチャ

ロードマネージャは、次の機能を実行します-

ソースシステムからデータを抽出します。
抽出したデータを一時データストアに高速でロードします。
データウェアハウスの構造に類似した構造への簡単な変換を実行します。

ロードマネージャー

ソースからデータを抽出する

データは、運用データベースまたは外部情報プロバイダーから抽出されます。ゲートウェイは、データの抽出に使用されるアプリケーションプログラムです。基礎となるDBMSによってサポートされ、クライアントプログラムがサーバーで実行されるSQLを生成できるようにします。 Open Database Connection（ODBC）、Java Database Connection（JDBC）はゲートウェイの例です。

高速負荷

総負荷ウィンドウを最小限に抑えるために、データを可能な限り高速でウェアハウスにロードする必要があります。
変換は、データ処理の速度に影響します。
変換とチェックを適用する前に、データをリレーショナルデータベースにロードする方がより効果的です。
ゲートウェイテクノロジーは、大量のデータが含まれる場合にパフォーマンスが低下する傾向があるため、適切でないことが判明しています。

単純な変換

ロード中に、単純な変換を実行するために必要になる場合があります。これが完了すると、複雑なチェックを行うことができます。次のチェックを実行する必要があるEPOS販売トランザクションをロードするとします。

ウェアハウス内で不要なすべての列を取り除きます。
すべての値を必要なデータ型に変換します。

倉庫マネージャー

倉庫管理者は倉庫管理プロセスを担当します。サードパーティのシステムソフトウェア、Cプログラム、およびシェルスクリプトで構成されています。

倉庫管理者の規模と複雑さは、特定のソリューションによって異なります。

Warehouse Managerのアーキテクチャ

倉庫管理者には以下が含まれます-

制御プロセス
ストアドプロシージャまたはC with SQL
バックアップ/リカバリツール
SQLスクリプト

倉庫マネージャー

Warehouse Managerによって実行される操作

ウェアハウス管理者は、データを分析して一貫性および参照整合性チェックを実行します。
基本データに対してインデックス、ビジネスビュー、パーティションビューを作成します。
新しい集計を生成し、既存の集計を更新します。正規化を生成します。
ソースデータを変換し、公開されたデータウェアハウスにマージします。
データウェアハウスのデータをバックアップします。
キャプチャされた寿命の終わりに達したデータをアーカイブします。

注-ウェアハウスマネージャーは、クエリプロファイルを分析して、インデックスと集計が適切かどうかを判断します。

クエリマネージャー

クエリマネージャーは、適切なテーブルにクエリを送信する責任があります。
クエリを適切なテーブルに転送することにより、クエリと応答生成の速度を上げることができます。
クエリマネージャは、ユーザーが提示したクエリの実行をスケジュールする役割を果たします。

Query Managerのアーキテクチャ

次のスクリーンショットは、クエリマネージャーのアーキテクチャを示しています。次のものが含まれます。

CツールまたはRDBMSを介したクエリリダイレクト
ストアドプロシージャ
クエリ管理ツール
CツールまたはRDBMSを介したクエリスケジューリング
サードパーティソフトウェアを介したクエリスケジューリング

クエリマネージャー

詳細な情報

詳細情報はオンラインで保持されるのではなく、次の詳細レベルに集約されてからテープにアーカイブされます。データウェアハウスの詳細情報部分は、スターフレークスキーマに詳細情報を保持します。集約データを補足するために、詳細情報がデータウェアハウスにロードされます。

次の図は、詳細な情報が保存されている場所とその使用方法を視覚的に示しています。

詳細情報

注-ディスクストレージを最小限に抑えるために詳細情報をオフラインで保持する場合は、アーカイブする前にデータが抽出され、クリーンアップされ、スターフレークスキーマに変換されていることを確認する必要があります。

要約情報

概要情報は、事前定義された集計を格納するデータウェアハウスの一部です。これらの集計は、ウェアハウスマネージャーによって生成されます。要約情報は一時的なものとして扱う必要があります。変化するクエリプロファイルに対応するために、外出先で変更します。

概要情報に関する注意点は次のとおりです-

要約情報は、一般的なクエリのパフォーマンスを高速化します。
運用コストが増加します。
新しいデータがデータウェアハウスに読み込まれるたびに更新する必要があります。
詳細情報から新たに生成できるため、バックアップされていない可能性があります。

データウェアハウジング-OLAP

オンライン分析処理サーバー（OLAP）は、多次元データモデルに基づいています。これにより、マネージャーやアナリストは、情報への高速で一貫した対話型のアクセスを通じて情報の洞察を得ることができます。この章では、OLAPの種類、OLAPの操作、OLAPの違い、および統計データベースとOLTPについて説明します。

OLAPサーバーの種類

4種類のOLAPサーバーがあります-

リレーショナルOLAP（ROLAP）
多次元OLAP（MOLAP）
ハイブリッドOLAP（HOLAP）
専用のSQLサーバー

リレーショナルOLAP

ROLAPサーバーは、リレーショナルバックエンドサーバーとクライアントフロントエンドツールの間に配置されます。ウェアハウスデータを保存および管理するために、ROLAPはリレーショナルまたは拡張リレーショナルDBMSを使用します。

ROLAPには次のものが含まれます-

集約ナビゲーションロジックの実装。
各DBMSバックエンドの最適化。
追加のツールとサービス。

多次元OLAP

MOLAPは、データの多次元ビューに配列ベースの多次元ストレージエンジンを使用します。多次元データストアでは、データセットがまばらな場合、ストレージの使用率が低くなる可能性があります。したがって、多くのMOLAPサーバーは、2つのレベルのデータストレージ表現を使用して、密なデータセットと疎なデータセットを処理します。

ハイブリッドOLAP

ハイブリッドOLAPは、ROLAPとMOLAPの両方の組み合わせです。 ROLAPの高いスケーラビリティとMOLAPの高速計算を提供します。 HOLAPサーバーでは、大量の詳細データを保存できます。集計は、MOLAPストアに個別に保存されます。

専用のSQLサーバー

専用SQLサーバーは、読み取り専用環境でスタースキーマとスノーフレークスキーマを介したSQLクエリの高度なクエリ言語とクエリ処理をサポートします。

OLAP操作

OLAPサーバーはデータの多次元ビューに基づいているため、多次元データでのOLAP操作について説明します。

ここにOLAP操作のリストがあります-

巻き上げる
ドリルダウン
スライスとサイコロ
ピボット（回転）

巻き上げる

ロールアップは、次のいずれかの方法でデータキューブの集計を実行します-

ディメンションの概念階層を登ることにより
次元削減により

次の図は、ロールアップの仕組みを示しています。

ロールアップ

ロールアップは、ディメンションの場所の概念階層を登ることにより実行されます。
当初、コンセプト階層は「通り<都市<州<国」でした。
ロールアップ時に、データは、都市のレベルから国のレベルまでロケーション階層を昇順で集約します。
データは国ではなく都市にグループ化されます。
ロールアップが実行されると、データキューブから1つ以上のディメンションが削除されます。

ドリルダウン

ドリルダウンは、ロールアップの逆の操作です。次のいずれかの方法で実行されます-

ディメンションの概念階層をステップダウンすることにより
新しい次元を導入することにより。

次の図は、ドリルダウンの仕組みを示しています-

ドリルダウン

ドリルダウンは、ディメンション時間の概念階層をステップダウンして実行されます。
当初、概念階層は「日<月<四半期＆lt年」でした。
ドリルダウンすると、時間ディメンションは四半期のレベルから月のレベルに下降します。
ドリルダウンが実行されると、データキューブから1つ以上のディメンションが追加されます。
データを詳細度の低いデータから詳細度の高いデータにナビゲートします。

スライス

スライス操作は、特定のキューブから特定の1つのディメンションを選択し、新しいサブキューブを提供します。スライスの仕組みを示す次の図を検討してください。

スライス

ここでは、基準time = "Q1"を使用して、ディメンション "time"に対してスライスが実行されます。
1つ以上のディメンションを選択することにより、新しいサブキューブを形成します。

Dice

Diceは、指定されたキューブから2つ以上のディメンションを選択し、新しいサブキューブを提供します。サイコロの動作を示す次の図を検討してください。

サイコロ

次の選択基準に基づくキューブのサイコロ操作には、3つのディメンションが含まれます。

（場所=「トロント」または「バンクーバー」）
（時間= "Q1"または "Q2"）
（item = "Mobile"または "Modem"）

ピボット

ピボット操作は回転とも呼ばれます。データの代替表示を提供するために、ビューでデータ軸を回転させます。ピボット操作を示す次の図を検討してください。

ピボット

OLAP vs OLTP

Sr.No.	Data Warehouse (OLAP)	Operational Database (OLTP)
1	Involves historical processing of information.	Involves day-to-day processing.
2	OLAP systems are used by knowledge workers such as executives, managers and analysts.	OLTP systems are used by clerks, DBAs, or database professionals.
3	Useful in analyzing the business.	Useful in running the business.
4	It focuses on Information out.	It focuses on Data in.
5	Based on Star Schema, Snowflake, Schema and Fact Constellation Schema.	Based on Entity Relationship Model.
6	Contains historical data.	Contains current data.
7	Provides summarized and consolidated data.	Provides primitive and highly detailed data.
8	Provides summarized and multidimensional view of data.	Provides detailed and flat relational view of data.
9	Number or users is in hundreds.	Number of users is in thousands.
10	Number of records accessed is in millions.	Number of records accessed is in tens.
11	Database size is from 100 GB to 1 TB	Database size is from 100 MB to 1 GB.
12	Highly flexible.	Provides high performance.

データウェアハウジング-リレーショナルOLAP

リレーショナルOLAPサーバーは、リレーショナルバックエンドサーバーとクライアントフロントエンドツールの間に配置されます。ウェアハウスデータを保存および管理するために、リレーショナルOLAPはリレーショナルまたは拡張リレーショナルDBMSを使用します。

ROLAPには次のものが含まれます-

集約ナビゲーションロジックの実装
各DBMSバックエンドの最適化
追加のツールとサービス

覚えておくべきポイント

ROLAPサーバーは非常にスケーラブルです。
ROLAPツールは、複数のディメンションにわたって大量のデータを分析します。
ROLAPツールは、非常に揮発性で変更可能なデータを保存および分析します。

リレーショナルOLAPアーキテクチャ

ROLAPには次のコンポーネントが含まれています-

データベースサーバー
ROLAPサーバー
フロントエンドツール。

Rolap Architecture

利点

ROLAPサーバーは、既存のRDBMSで簡単に使用できます。
ゼロファクトを保存できないため、データを効率的に保存できます。
ROLAPツールは、事前に計算されたデータキューブを使用しません。
マイクロ戦略のDSSサーバーはROLAPアプローチを採用しています。

デメリット

クエリのパフォーマンスが悪い。
使用されるテクノロジーアーキテクチャに依存するスケーラビリティの制限。

データウェアハウジング-多次元OLAP

多次元OLAP（MOLAP）は、データの多次元ビューに配列ベースの多次元ストレージエンジンを使用します。多次元データストアでは、データセットがまばらな場合、ストレージの使用率が低くなる可能性があります。そのため、多くのMOLAPサーバーは2つのレベルのデータストレージ表現を使用して、密なデータセットと疎なデータセットを処理します。

覚えておくべきポイント-

MOLAPツールは、選択された要約または計算のレベルに関係なく、一貫した応答時間で情報を処理します。
MOLAPツールは、分析用のデータを保存するリレーショナルデータベースの作成の複雑さの多くを回避する必要があります。
MOLAPツールには、可能な限り高速のパフォーマンスが必要です。
MOLAPサーバーは、2つのレベルのストレージ表現を採用して、密なデータセットと疎なデータセットを処理します。
高密度のサブキューブは、配列構造として識別および保存されます。
スパースサブキューブは圧縮技術を採用しています。

MOLAPアーキテクチャ

MOLAPには次のコンポーネントが含まれています-

データベースサーバー。
MOLAPサーバー。
フロントエンドツール。

Molap Architecture

利点

MOLAPは、事前に計算された要約データへの最速のインデックス付けを可能にします。
ネットワークに接続しているユーザーが、大規模で未定義のデータを分析する必要がある場合に役立ちます。
使いやすいため、MOLAPは経験の浅いユーザーに適しています。

デメリット

MOLAPは詳細データを含むことができません。
データセットがまばらな場合、ストレージの使用率が低くなる可能性があります。

MOLAP対ROLAP

Sr.No.	MOLAP	ROLAP
1	Information retrieval is fast.	Information retrieval is comparatively slow.
2	Uses sparse array to store data-sets.	Uses relational table.
3	MOLAP is best suited for inexperienced users, since it is very easy to use.	ROLAP is best suited for experienced users.
4	Maintains a separate database for data cubes.	It may not require space other than available in the Data warehouse.
5	DBMS facility is weak.	DBMS facility is strong.

データウェアハウジング-スキーマ

スキーマは、データベース全体の論理的な説明です。関連するすべてのデータ項目と集計を含む、すべてのレコードタイプのレコードの名前と説明が含まれます。データベースと同様に、データウェアハウスもスキーマを維持する必要があります。データベースはリレーショナルモデルを使用し、データウェアハウスはStar、Snowflake、およびFact Constellationスキーマを使用します。この章では、データウェアハウスで使用されるスキーマについて説明します。

スタースキーマ

スタースキーマの各ディメンションは、1次元のテーブルのみで表されます。
このディメンションテーブルには、属性のセットが含まれています。
次の図は、時間、品目、支店、場所の4つのディメンションに関する会社の販売データを示しています。

スキーマの開始

中央にファクトテーブルがあります。これには、4つの各次元へのキーが含まれています。
ファクトテーブルには、属性（販売ドルと販売単位）も含まれています。

注-各ディメンションには1つのディメンションテーブルのみがあり、各テーブルには属性のセットが保持されます。たとえば、ロケーションディメンションテーブルには、属性セット\ {location_key、street、city、Province_or_state、country}が含まれます。この制約により、データの冗長性が生じる場合があります。たとえば、「バンクーバー」と「ビクトリア」はどちらもカナダのブリティッシュコロンビア州にあります。そのような都市のエントリは、provision_or_stateおよびcountry属性に沿ってデータの冗長性を引き起こす可能性があります。

スノーフレークスキーマ

Snowflakeスキーマの一部のディメンションテーブルは正規化されています。
正規化は、データを追加のテーブルに分割します。
スタースキーマとは異なり、スノーフレークスキーマのディメンションテーブルは正規化されます。たとえば、スタースキーマのアイテムディメンションテーブルは正規化され、2つのディメンションテーブル、つまりアイテムテーブルとサプライヤテーブルに分割されます。

スノーフレークスキーマ

これで、アイテムディメンションテーブルには、item_key、item_name、type、brand、supplier-keyの属性が含まれます。
サプライヤキーは、サプライヤディメンションテーブルにリンクされています。サプライヤディメンションテーブルには、属性supplier_keyおよびsupplier_typeが含まれています。

注-Snowflakeスキーマの正規化により、冗長性が低下するため、保守が容易になり、ストレージスペースを節約できます。

ファクトコンステレーションスキーマ

ファクトコンステレーションには複数のファクトテーブルがあります。これはgalaxyスキーマとも呼ばれます。
次の図は、販売と出荷という2つのファクトテーブルを示しています。

ファクトコンステレーションスキーマ

売上ファクトテーブルは、スタースキーマのテーブルと同じです。
出荷ファクトテーブルには、item_key、time_key、shipper_key、from_location、to_locationの5つのディメンションがあります。
出荷ファクトテーブルには、2つのメジャー、つまり販売ドルと販売単位も含まれています。
ファクトテーブル間でディメンションテーブルを共有することもできます。たとえば、時間、アイテム、および場所のディメンションテーブルは、販売ファクトテーブルと出荷ファクトテーブルの間で共有されます。

スキーマ定義

多次元スキーマは、データマイニングクエリ言語（DMQL）を使用して定義されます。データウェアハウスとデータマートの定義には、キューブ定義とディメンション定義の2つのプリミティブを使用できます。

キューブ定義の構文

define cube < cube_name > [ < dimension-list > }: < measure_list >

ディメンション定義の構文

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

スタースキーマ定義

我々が議論したスタースキーマは、次のようにデータマイニングクエリ言語（DMQL）を使用して定義することができます-

define cube sales star [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state, country)

スノーフレークスキーマ定義

スノーフレークスキーマは、次のようにDMQLを使用して定義できます-

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

ファクトコンステレーションスキーマの定義

事実星座スキーマは、次のようにDMQLを使用して定義することができます-

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

データウェアハウジング-パーティショニング戦略

パーティション化は、パフォーマンスを向上させ、データの管理を容易にするために行われます。パーティショニングは、システムのさまざまな要件のバランスを取るのにも役立ちます。各ファクトテーブルを複数の個別のパーティションに分割することにより、ハードウェアのパフォーマンスを最適化し、データウェアハウスの管理を簡素化します。この章では、さまざまなパーティション戦略について説明します。

分割する必要があるのはなぜですか？

パーティションは次の理由で重要です-

管理を容易にするために、
バックアップ/リカバリを支援するために、
パフォーマンスを向上させるため。

簡単な管理のために

データウェアハウスのファクトテーブルは、サイズが数百ギガバイトまで拡大する可能性があります。この巨大なファクトテーブルは、単一のエンティティとして管理するのが非常に困難です。したがって、パーティション化が必要です。

バックアップ/リカバリを支援するには

ファクトテーブルをパーティション分割しない場合、すべてのデータを含む完全なファクトテーブルをロードする必要があります。パーティショニングにより、定期的に必要なデータだけをロードできます。ロード時間を短縮し、システムのパフォーマンスも向上します。

注-バックアップサイズを削減するために、現在のパーティション以外のすべてのパーティションを読み取り専用としてマークできます。その後、これらのパーティションを変更できない状態にすることができます。その後、それらをバックアップできます。これは、現在のパーティションのみがバックアップされることを意味します。

パフォーマンスを向上させる

ファクトテーブルをデータセットに分割することにより、クエリプロシージャを強化できます。クエリが関連するパーティションのみをスキャンするようになったため、クエリのパフォーマンスが向上しました。データ全体をスキャンする必要はありません。

水平分割

ファクトテーブルをパーティション分割するには、さまざまな方法があります。水平分割では、データウェアハウスの管理性の要件を考慮する必要があります。

時間による等しいセグメントへの分割

このパーティション分割戦略では、期間に基づいてファクトテーブルがパーティション分割されます。ここで、各期間は、ビジネス内の重要な保持期間を表しています。たとえば、ユーザーが*月間のデータ*を照会する場合、データを月単位のセグメントに分割するのが適切です。パーティションテーブル内のデータを削除することで、パーティションテーブルを再利用できます。

時間ごとに異なるサイズのセグメントに分割

この種のパーティションは、古くなったデータにアクセスする頻度が低い場所で行われます。比較的最新のデータには小さなパーティションのセットとして、非アクティブなデータには大きなパーティションのセットとして実装されます。

時間による異なるサイズのセグメントへの分割

注意点

詳細情報は引き続きオンラインで入手できます。
物理テーブルの数は比較的少なく抑えられ、運用コストが削減されます。
この手法は、最近の履歴に浸るデータと履歴全体のデータマイニングの組み合わせが必要な場合に適しています。
再パーティション化はデータウェアハウスの運用コストを増加させるため、この手法はパーティション化プロファイルが定期的に変更される場合には役立ちません。

異なる次元のパーティション

ファクトテーブルは、製品グループ、地域、サプライヤー、またはその他のディメンションなど、時間以外のディメンションに基づいてパーティション化することもできます。例を見てみましょう。

市場機能が、*州ごと*のように、別個の地域部門に構成されているとします。各地域がその地域内でキャプチャされた情報を照会する場合、ファクトテーブルを地域パーティションに分割するとより効果的であることがわかります。これにより、関係のない情報をスキャンする必要がないため、クエリの速度が向上します。

注意点

クエリは、クエリプロセスを高速化する無関係なデータをスキャンする必要はありません。
この手法は、将来ディメンションが変更される可能性が低い場合には適切ではありません。したがって、ディメンションが将来変更されないことを判断する価値があります。
ディメンションが変更された場合、ファクトテーブル全体を再パーティション化する必要があります。

注-推奨されるディメンショングループがデータウェアハウスの有効期間内に変更されないことが確実でない限り、時間ディメンションに基づいてのみパーティションを実行することをお勧めします。

テーブルのサイズによるパーティション

ディメンションでファクトテーブルをパーティション分割する明確な根拠がない場合は、*サイズに基づいてファクトテーブルをパーティション分割する必要があります。*所定のサイズをクリティカルポイントとして設定できます。テーブルが所定のサイズを超えると、新しいテーブルパーティションが作成されます。

注意点

このパーティショニングは管理が複雑です。
各パーティションに保存されているデータを識別するためのメタデータが必要です。

分割寸法

ディメンションに多数のエントリが含まれる場合、ディメンションをパーティション化する必要があります。ここでは、ディメンションのサイズを確認する必要があります。

時間の経過とともに変化する大規模な設計を検討してください。比較を適用するためにすべてのバリエーションを保存する必要がある場合、そのディメンションは非常に大きくなる可能性があります。これは間違いなく応答時間に影響します。

ラウンドロビンパーティション

ラウンドロビン手法では、新しいパーティションが必要になると、古いパーティションがアーカイブされます。メタデータを使用して、ユーザーアクセスツールが正しいテーブルパーティションを参照できるようにします。

この手法により、データウェアハウス内のテーブル管理機能を簡単に自動化できます。

垂直パーティション

垂直分割、データを垂直に分割します。次の図は、垂直分割がどのように行われるかを示しています。

垂直分割

垂直分割は、次の2つの方法で実行できます-

正規化
行分割

正規化

正規化は、データベース編成の標準的なリレーショナル方式です。この方法では、行が単一の行に縮小されるため、スペースが削減されます。正規化の実行方法を示す次の表をご覧ください。

正規化前の表

Product_id	Qty	Value	sales_date	Store_id	Store_name	Location	Region
30	5	3.67	3-Aug-13	16	sunny	Bangalore	S
35	4	5.33	3-Sep-13	16	sunny	Bangalore	S
40	5	2.50	3-Sep-13	64	san	Mumbai	W
45	7	5.66	3-Sep-13	16	sunny	Bangalore	S

正規化後の表

Store_id	Store_name	Location	Region
16	sunny	Bangalore	W
64	san	Mumbai	S

Product_id	Quantity	Value	sales_date	Store_id
30	5	3.67	3-Aug-13	16
35	4	5.33	3-Sep-13	16
40	5	2.50	3-Sep-13	64
45	7	5.66	3-Sep-13	16

行分割

行分割は、パーティション間で1対1のマップを残す傾向があります。行分割の動機は、サイズを小さくすることで大きなテーブルへのアクセスを高速化することです。

注意-垂直分割を使用しているときは、2つのパーティション間で主要な結合操作を実行する必要がないことを確認してください。

パーティションのキーを特定する

適切なパーティションキーを選択することは非常に重要です。間違ったパーティションキーを選択すると、ファクトテーブルが再編成されます。例を見てみましょう。次のテーブルをパーティション分割するとします。

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

任意のキーでパーティションを選択できます。 2つの可能なキーは

領域
transaction_date

ビジネスが30の地理的地域で構成されており、各地域の支店数が異なるとします。これにより、30個のパーティションが得られますが、これは妥当です。要件のキャプチャにより、クエリの大部分がユーザー自身のビジネス地域に制限されていることが示されているため、このパーティションは十分に優れています。

リージョンではなくtransaction_dateでパーティション化すると、すべてのリージョンからの最新のトランザクションが1つのパーティションになります。これで、自分の地域内のデータを確認したいユーザーは、複数のパーティションをクエリする必要があります。

したがって、適切なパーティション化キーを決定する価値があります。

データウェアハウジング-メタデータの概念

メタデータとは何ですか？

メタデータは、単にデータに関するデータとして定義されます。他のデータを表すために使用されるデータは、メタデータと呼ばれます。たとえば、本のインデックスは本の内容のメタデータとして機能します。言い換えれば、メタデータは、詳細なデータにつながる要約データであると言えます。データウェアハウスに関しては、次のようにメタデータを定義できます。

メタデータは、データウェアハウスへのロードマップです。
データウェアハウスのメタデータは、ウェアハウスオブジェクトを定義します。
メタデータはディレクトリとして機能します。このディレクトリは、意思決定支援システムがデータウェアハウスのコンテンツを見つけるのに役立ちます。

注-データウェアハウスでは、特定のデータウェアハウスのデータ名と定義のメタデータを作成します。このメタデータとともに、抽出データのソースである抽出データにタイムスタンプを付けるための追加のメタデータも作成されます。

メタデータのカテゴリ

メタデータは大きく3つのカテゴリに分類できます-

ビジネスメタデータ-データ所有権情報、ビジネス定義、および変更ポリシーがあります。
テクニカルメタデータ-データベースシステム名、テーブルと列の名前とサイズ、データ型、および許可された値が含まれます。技術メタデータには、主キーおよび外部キーの属性とインデックスなどの構造情報も含まれます。
運用メタデータ-データの通貨とデータ系統が含まれます。データの通貨とは、データがアクティブ、アーカイブ、またはパージされているかどうかを意味します。データの系統とは、移行されたデータとそれに適用された変換の履歴を意味します。

メタデータのカテゴリ

メタデータの役割

メタデータは、データウェアハウスで非常に重要な役割を果たします。ウェアハウスでのメタデータの役割はウェアハウスのデータとは異なりますが、重要な役割を果たしています。メタデータのさまざまな役割を以下に説明します。

メタデータはディレクトリとして機能します。
このディレクトリは、意思決定支援システムがデータウェアハウスのコンテンツを見つけるのに役立ちます。
メタデータは、データが運用環境からデータウェアハウス環境に変換されるときに、データをマッピングするための意思決定支援システムに役立ちます。
メタデータは、現在の詳細データと高度に要約されたデータの要約に役立ちます。
メタデータは、わずかに詳細なデータと高度に要約されたデータ間の要約にも役立ちます。
メタデータはクエリツールに使用されます。
メタデータは、抽出およびクレンジングツールで使用されます。
メタデータはレポートツールで使用されます。
メタデータは変換ツールで使用されます。
メタデータは、関数の読み込みに重要な役割を果たします。

次の図は、メタデータの役割を示しています。

メタデータの役割

メタデータリポジトリ

メタデータリポジトリは、データウェアハウスシステムの不可欠な部分です。次のメタデータがあります-

データウェアハウスの定義-データウェアハウスの構造の説明が含まれています。説明は、スキーマ、ビュー、階層、派生データ定義、およびデータマートの場所と内容によって定義されます。
ビジネスメタデータ-データ所有権情報、ビジネス定義、および変更ポリシーが含まれています。
運用メタデータ-データの通貨とデータ系統が含まれます。データの通貨とは、データがアクティブ、アーカイブ、またはパージされているかどうかを意味します。データの系統とは、移行されたデータとそれに適用された変換の履歴を意味します。
運用環境からデータウェアハウスにマッピングするためのデータ-ソースデータベースとそのコンテンツ、データ抽出、データパーティションクリーニング、変換ルール、データ更新およびパージルール。
要約のアルゴリズム-次元アルゴリズム、粒度、集計、要約などのデータが含まれます。

メタデータ管理の課題

メタデータの重要性を誇張することはできません。メタデータは、レポートの精度を高め、データ変換を検証し、計算の精度を確保するのに役立ちます。また、メタデータはビジネス用語の定義をビジネスエンドユーザーに強制します。これらすべてのメタデータの使用には、課題もあります。いくつかの課題を以下で説明します。

大きな組織のメタデータは、組織全体に散在しています。このメタデータは、スプレッドシート、データベース、およびアプリケーションに広がります。
メタデータは、テキストファイルまたはマルチメディアファイルに存在する可能性があります。このデータを情報管理ソリューションに使用するには、データを正しく定義する必要があります。
業界全体で受け入れられている標準はありません。データ管理ソリューションベンダーの焦点は狭い。
メタデータを渡す簡単で受け入れられた方法はありません。

データウェアハウジング-データマーティング

データマートが必要な理由

以下は、データマートを作成する理由です。

*アクセス制御戦略*を課すためにデータを分割する
スキャンするデータの量を減らして、クエリを高速化します。
データを異なるハードウェアプラットフォームにセグメント化する。
ユーザーアクセスツールに適した形式でデータを構造化します。

注-データマーティングの運用コストが非常に高くなる可能性があるため、他の理由でデータマートを使用しないでください。データマーティングの前に、データマーティング戦略が特定のソリューションに適していることを確認してください。

費用対効果の高いデータマーティング

以下の手順に従って、データマーティングの費用対効果を高めます-

機能分割を特定する
ユーザーアクセスツールの要件を特定する
アクセス制御の問題を特定する

機能分割を特定する

このステップでは、組織に自然な機能分割があるかどうかを判断します。部門の分割を探し、部門が情報を使用する方法が組織の他の部分から隔離される傾向があるかどうかを判断します。例を見てみましょう。

各小売商が製品グループの売上を最大化する責任を負う小売組織を考えてみましょう。このため、以下は貴重な情報です-

毎日の販売取引
毎週の売上予測
毎日の在庫ポジション
毎日の在庫移動

マーチャントが扱っていない製品に関心がないため、データマーティングは、関心のある製品グループが扱うデータのサブセットです。次の図は、さまざまなユーザーのデータマーティングを示しています。

データマーティング

機能的な分割を決定する際に考慮すべき問題を以下に示します-

部門の構造は変更される場合があります。
製品は、ある部門から別の部門に切り替える場合があります。
商人は、他の製品の販売傾向を照会して、何が起こっているかを分析できます販売に。

注-データマートを使用するビジネス上の利点と技術的な実現可能性を判断する必要があります。

ユーザーアクセスツールの要件を特定する

内部データ構造を必要とする*ユーザーアクセスツール*をサポートするには、データマートが必要です。このような構造のデータは、データウェアハウスの制御外ですが、定期的にデータを取り込み、更新する必要があります。

ソースシステムから直接入力するツールもありますが、そうでないツールもあります。したがって、ツールの範囲外の追加要件を将来的に特定する必要があります。

注-すべてのアクセスツールでデータの一貫性を確保するために、データウェアハウスからデータを直接入力するのではなく、各ツールに独自のデータマートが必要です。

アクセス制御の問題を特定する

許可されたユーザーのみがデータにアクセスできるようにするには、プライバシールールが必要です。たとえば、リテールバンキング機関のデータウェアハウスでは、すべてのアカウントが同じ法人に属していることが保証されます。プライバシー法により、特定の銀行が所有していない情報へのアクセスを完全に禁止することができます。

データマートを使用すると、データウェアハウス内でデータセグメントを物理的に分離することにより、完全な壁を構築できます。起こりうるプライバシーの問題を回避するために、詳細データをデータウェアハウスから削除できます。各法人のデータマートを作成し、詳細なアカウントデータとともにデータウェアハウス経由でロードできます。

データマートの設計

データマートは、データウェアハウス内のスターフレークスキーマの小さいバージョンとして設計し、データウェアハウスのデータベース設計と一致させる必要があります。データベースインスタンスの制御を維持するのに役立ちます。

データマートの設計

サマリーは、データウェアハウス内で設計されたのと同じ方法でマーティングされたデータです。サマリーテーブルは、スターフレークスキーマのすべてのディメンションデータを利用するのに役立ちます。

データマーティングのコスト

データマーティングのコスト指標は次のとおりです-

ハードウェアとソフトウェアのコスト
ネットワークアクセス
時間枠の制約

ハードウェアとソフトウェアのコスト

データマートは同じハードウェア上に作成されますが、追加のハードウェアとソフトウェアが必要です。ユーザークエリを処理するには、追加の処理能力とディスクストレージが必要です。詳細データとデータマートがデータウェアハウス内に存在する場合、複製されたデータを保存および管理するための追加コストが発生します。

注-データマーティングは集約よりも高価なので、代替戦略としてではなく、追加戦略として使用する必要があります。

ネットワークアクセス

データマートはデータウェアハウスとは異なる場所にある可能性があるため、LANまたはWANが*データマートロードプロセス内で転送されるデータボリュームを処理する能力を持っていることを確認する必要があります。

時間枠の制約

データマートのロードプロセスが使用可能な時間枠に食い込む程度は、変換の複雑さと出荷されるデータボリュームによって異なります。可能なデータマートの数の決定は、次の要素に依存します-

ネットワーク容量。
利用可能な時間枠
転送されるデータの量
データをデータマートに挿入するために使用されるメカニズム

データウェアハウジング-システムマネージャー

データウェアハウスを正常に実装するには、システム管理が必須です。最も重要なシステム管理者は-

システム構成マネージャー
システムスケジューリングマネージャー
システムイベントマネージャー
システムデータベースマネージャー
システムバックアップリカバリマネージャー

システム構成マネージャー

システム構成マネージャーは、データウェアハウスのセットアップと構成の管理を担当します。
構成マネージャーの構造は、オペレーティングシステムごとに異なります。
Unixの構成構造では、マネージャーはベンダーによって異なります。
構成マネージャーには、単一のユーザーインターフェイスがあります。
構成マネージャーのインターフェースにより、システムのすべての側面を制御できます。

注-最も重要な構成ツールはI/Oマネージャーです。

システムスケジューリングマネージャー

System Scheduling Managerは、データウェアハウスの実装を成功させる責任があります。その目的は、アドホッククエリをスケジュールすることです。すべてのオペレーティングシステムには、何らかの形式のバッチ制御メカニズムを備えた独自のスケジューラがあります。システムスケジューリングマネージャが持つ必要がある機能のリストは次のとおりです-

クラスターまたはMPPの境界を越えて作業する
国際的な時差に対処する
ジョブの失敗を処理する
複数のクエリを処理する
ジョブの優先順位をサポート
失敗したジョブを再起動または再キューイングする
ジョブの完了時にユーザーまたはプロセスに通知する
システム停止全体でジョブスケジュールを維持する
ジョブを他のキューに再キューイングする
キューの停止と開始をサポート
キューに入れられたジョブのログ
キュー間処理に対処する

注-上記のリストは、優れたスケジューラーの評価の評価パラメーターとして使用できます。

スケジューラが処理できる必要があるいくつかの重要なジョブは次のとおりです-

毎日およびアドホッククエリスケジューリング
定期的なレポート要件の実行
データロード
情報処理
インデックス作成
バックアップ
集計の作成
データ変換

注-データウェアハウスがクラスターまたはMPPアーキテクチャで実行されている場合、システムスケジューリングマネージャーはアーキテクチャ全体で実行できる必要があります。

システムイベントマネージャー

イベントマネージャは一種のソフトウェアです。イベントマネージャは、データウェアハウスシステムで定義されているイベントを管理します。データウェアハウスの構造は非常に複雑であるため、データウェアハウスを手動で管理することはできません。したがって、ユーザーの介入なしにすべてのイベントを自動的に処理するツールが必要です。

注-イベントマネージャはイベントの発生を監視し、それらを処理します。イベントマネージャは、この複雑なデータウェアハウスシステムで問題が発生する可能性のある無数のことも追跡します。

イベント

イベントは、ユーザーまたはシステム自体によって生成されるアクションです。イベントは、定義されたアクションの測定可能で観測可能な発生であることに注意してください。

以下に、追跡する必要がある一般的なイベントのリストを示します。

ハードウェア障害
特定のキーディスクのスペースが不足している
死にかけているプロセス
エラーを返すプロセス
805のしきい値を超えるCPU使用率
データベースのシリアル化ポイントでの内部競合
バッファキャッシュヒット率がしきい値を超えているか、しきい値を下回っています
最大サイズに達するテーブル
過剰なメモリスワッピング
スペース不足のために拡張できないテーブル
I/Oボトルネックを示すディスク
特定のしきい値に達した一時領域またはソート領域の使用
その他のデータベース共有メモリ使用量

イベントについて最も重要なことは、イベントが自分で実行できる必要があるということです。イベントパッケージは、事前定義されたイベントの手順を定義します。各イベントに関連付けられたコードは、イベントハンドラーと呼ばれます。このコードは、イベントが発生するたびに実行されます。

システムおよびデータベースマネージャー

システムマネージャとデータベースマネージャは、2つの別個のソフトウェアである場合がありますが、同じ仕事をします。これらのツールの目的は、特定のプロセスを自動化し、他のプロセスの実行を簡素化することです。システムとデータベースマネージャを選択するための基準は次のとおりです-

ユーザーの割り当てを増やします。
ユーザーへの役割の割り当てと割り当て解除
ユーザーへのプロファイルの割り当てと割り当て解除
データベーススペース管理を実行する
スペース使用量の監視とレポート
断片化された未使用のスペースを片付ける
スペースを追加および拡張する
ユーザーの追加と削除
ユーザーパスワードを管理する
サマリーまたは一時テーブルを管理する
ユーザーとの一時スペースの割り当てまたは割り当て解除
古いまたは古い一時テーブルからスペースを再利用する
エラーおよびトレースログを管理する
ログおよびトレースファイルを参照するには
エラーまたはトレース情報のリダイレクト
エラーおよびトレースロギングのオンとオフを切り替える
システムスペース管理を実行する
スペース使用量の監視とレポート
古いファイルディレクトリと未使用のファイルディレクトリをクリーンアップする
スペースを追加または拡張します。

システムバックアップリカバリマネージャー

バックアップおよび復元ツールにより、運用および管理スタッフがデータを簡単にバックアップできます。システムバックアップマネージャーは、使用するスケジュールマネージャーソフトウェアと統合する必要があることに注意してください。バックアップの管理に必要な重要な機能は次のとおりです-

スケジューリング
バックアップデータの追跡
データベース認識

バックアップは、データの損失を防ぐためにのみ行われます。以下は覚えておくべき重要なポイントです-

バックアップソフトウェアは、データがいつどこでバックアップされたかの何らかの形のデータベースを保持します。
バックアップリカバリマネージャには、そのデータベースへの適切なフロントエンドが必要です。
バックアップ回復ソフトウェアはデータベースに対応している必要があります。
データベースを認識することで、ソフトウェアはデータベースの用語で対処でき、実行不可能なバックアップは実行されません。

データウェアハウジング-プロセスマネージャー

プロセスマネージャは、データウェアハウスの内外へのデータの流れを維持する責任があります。プロセスマネージャには3つの異なるタイプがあります-

ロードマネージャー
倉庫マネージャー
クエリマネージャー

データウェアハウスロードマネージャー

ロードマネージャは、データを抽出してデータベースにロードするために必要な操作を実行します。ロードマネージャーのサイズと複雑さは、データウェアハウスごとに特定のソリューションによって異なります。

ロードマネージャーのアーキテクチャ

ロードマネージャは、次の機能を実行します-

ソースシステムからデータを抽出します。
抽出したデータを一時データストアに高速でロードします。
データウェアハウスの構造に類似した構造への簡単な変換を実行します。

ロードマネージャー

ソースからデータを抽出する

データは、運用データベースまたは外部情報プロバイダーから抽出されます。ゲートウェイは、データの抽出に使用されるアプリケーションプログラムです。基礎となるDBMSによってサポートされ、クライアントプログラムがサーバーで実行されるSQLを生成できるようにします。 Open Database Connection（ODBC）およびJava Database Connection（JDBC）はゲートウェイの例です。

高速負荷

総ロード時間枠を最小限に抑えるために、データを可能な限り迅速にウェアハウスにロードする必要があります。
変換はデータ処理の速度に影響します。
変換とチェックを適用する前に、データをリレーショナルデータベースにロードする方がより効果的です。
ゲートウェイテクノロジーは、大量のデータが含まれる場合には効率が悪いため、適していません。

単純な変換

ロード中に、単純な変換を実行する必要がある場合があります。単純な変換を完了した後、複雑なチェックを行うことができます。 EPOS販売トランザクションをロードしていると仮定すると、次のチェックを実行する必要があります-

ウェアハウス内で不要なすべての列を取り除きます。
すべての値を必要なデータ型に変換します。

倉庫マネージャー

倉庫管理者は倉庫管理プロセスを担当します。サードパーティのシステムソフトウェア、Cプログラム、およびシェルスクリプトで構成されています。ウェアハウスマネージャーのサイズと複雑さは、特定のソリューションによって異なります。

Warehouse Managerのアーキテクチャ

倉庫管理者には以下が含まれます-

制御プロセス
ストアドプロシージャまたはC with SQL
バックアップ/リカバリツール
SQLスクリプト

倉庫マネージャー

倉庫マネージャーの機能

倉庫マネージャーは、次の機能を実行します-

データを分析して、整合性および参照整合性チェックを実行します。
基本データに対してインデックス、ビジネスビュー、パーティションビューを作成します。
新しい集計を生成し、既存の集計を更新します。
正規化を生成します。
一時ストアのソースデータを変換して、公開されたデータウェアハウスにマージします。
データウェアハウスのデータをバックアップします。
キャプチャされた寿命の終わりに達したデータをアーカイブします。

注-ウェアハウスマネージャーはクエリプロファイルを分析して、インデックスと集計が適切かどうかを判断します。

クエリマネージャー

クエリマネージャは、クエリを適切なテーブルに送信する責任があります。クエリを適切なテーブルに送信することにより、クエリの要求と応答のプロセスを高速化します。さらに、クエリマネージャーは、ユーザーによってポストされたクエリの実行をスケジュールする責任があります。

Query Managerのアーキテクチャ

クエリマネージャには、次のコンポーネントが含まれています-

CツールまたはRDBMSを介したクエリリダイレクト
ストアドプロシージャ
クエリ管理ツール
CツールまたはRDBMSを介したクエリスケジューリング
サードパーティソフトウェアを介したクエリスケジューリング

クエリマネージャー

Queryマネージャーの機能

ユーザーに理解できる形式でデータを提示します。
エンドユーザーによってポストされたクエリの実行をスケジュールします。
クエリプロファイルを格納して、ウェアハウスマネージャーが適切なインデックスと集計を決定できるようにします。

データウェアハウジング-セキュリティ

データウェアハウスの目的は、ユーザーが大量のデータに簡単にアクセスできるようにすることです。したがって、ユーザーはビジネス全体に関する情報を抽出できます。しかし、情報にアクセスするための障害となる可能性のあるデータにセキュリティ制限が適用される可能性があることを知っています。アナリストがデータの制限されたビューを持っている場合、ビジネス内のトレンドの全体像を把握することは不可能です。

各アナリストからのデータを要約し、さまざまな要約を集計できる経営陣に渡すことができます。集計の集計は集計全体の集計と同じにはできないため、誰かがデータ全体を分析しない限り、データの一部の情報トレンドを見逃す可能性があります。

セキュリティ要件

セキュリティ機能を追加すると、データウェアハウスのパフォーマンスに影響するため、セキュリティ要件をできるだけ早く決定することが重要です。データウェアハウスが稼働した後、セキュリティ機能を追加することは困難です。

データウェアハウスの設計段階では、後で追加できるデータソースと、それらのデータソースを追加した場合の影響に留意する必要があります。設計段階では、次の可能性を考慮する必要があります。

新しいデータソースに新しいセキュリティや監査の制限を実装する必要があるかどうか。
すでに一般的に利用可能なデータへのアクセスを制限している新しいユーザーが追加されたかどうか？

この状況は、将来のユーザーとデータソースがよくわからない場合に発生します。このような状況では、ビジネスの知識とデータウェアハウスの目的を使用して、考えられる要件を知る必要があります。

次の活動は、セキュリティ対策の影響を受けます-

ユーザーアクセス
データロード
データ移動
クエリ生成

ユーザーアクセス

最初にデータを分類し、次にアクセスできるデータに基づいてユーザーを分類する必要があります。つまり、ユーザーは、アクセスできるデータに従って分類されます。

データ分類

次の2つのアプローチは、データを分類するために使用することができます-

データはその感度に従って分類できます。機密性の高いデータは高度に制限されていると分類され、機密性の低いデータは制限が少ないと分類されます。
データは、職務に応じて分類することもできます。この制限により、特定のユーザーのみが特定のデータを表示できます。ここでは、ユーザーが関心を持ち、責任を負うデータの部分のみを表示するように制限します。

2番目のアプローチにはいくつかの問題があります。理解するために、例を挙げましょう。銀行のデータウェアハウスを構築しているとします。データウェアハウスに保存されているデータは、すべてのアカウントのトランザクションデータであると考えてください。ここでの質問は、誰がトランザクションデータを表示できるかです。ソリューションは、機能に従ってデータを分類することにあります。

ユーザー分類

次のアプローチは、ユーザーを分類するために使用することができます-

ユーザーは、組織内のユーザーの階層に従って分類できます。つまり、ユーザーは部門、セクション、グループなどで分類できます。
ユーザーは、役割に基づいて分類することもできます。ユーザーは、役割に基づいて部門間でグループ化されます。

部門ごとの分類

ユーザーが販売およびマーケティング部門から来ているデータウェアハウスの例を見てみましょう。トップダウンの企業ビューによりセキュリティを確保でき、さまざまな部門を中心にアクセスできます。ただし、さまざまなレベルのユーザーにいくつかの制限がある可能性があります。この構造を次の図に示します。

ユーザーアクセス階層

ただし、各部門が異なるデータにアクセスする場合は、各部門のセキュリティアクセスを個別に設計する必要があります。これは、部門のデータマートによって実現できます。これらのデータマートはデータウェアハウスから分離されているため、各データマートに個別のセキュリティ制限を適用できます。このアプローチを次の図に示します。

データマートを使用してデータへのアクセスに制限を適用する

役割に基づく分類

データが一般的にすべての部門で利用できる場合、ロールアクセス階層に従うことは有用です。つまり、データがすべての部門から一般的にアクセスされる場合、ユーザーの役割に従ってセキュリティ制限を適用します。ロールアクセス階層を次の図に示します。

ロールアクセス階層

監査要件

監査はセキュリティのサブセットであり、費用のかかるアクティビティです。監査は、システムに大きなオーバーヘッドを引き起こす可能性があります。監査を時間内に完了するには、より多くのハードウェアが必要になるため、可能な限り監査をオフにすることをお勧めします。監査要件は次のように分類することができます-

つながり
切断
データアクセス
データ変更

注-上記の各カテゴリについて、成功、失敗、またはその両方を監査する必要があります。セキュリティ上の理由から、障害の監査は非常に重要です。失敗の監査は、不正または不正なアクセスを強調できるため重要です。

ネットワーク要件

ネットワークセキュリティは、他のセキュリティと同様に重要です。ネットワークセキュリティ要件を無視することはできません。私たちは次の問題を考慮する必要があります-

データをデータウェアハウスに転送する前に暗号化する必要がありますか？
データが使用できるネットワークルートに制限はありますか？

これらの制限は慎重に検討する必要があります。覚えておくべきポイントは次のとおりです-

暗号化および復号化のプロセスにより、オーバーヘッドが増加します。より多くの処理能力と処理時間が必要になります。
暗号化はソースシステムによって行われるため、システムが既にロードされたシステムである場合、暗号化のコストが高くなる可能性があります。

データ移動

データの移動中に潜在的なセキュリティの影響が存在します。ロードするフラットファイルとして制限されたデータを転送する必要があるとします。データがデータウェアハウスにロードされると、次の質問が提起されます-

フラットファイルはどこに保存されますか？
誰がそのディスクスペースにアクセスできますか？

これらのフラットファイルのバックアップについて話すと、次の質問が発生します-

暗号化または復号化されたバージョンをバックアップしますか？
これらのバックアップは、個別に保存されている特別なテープに作成する必要がありますか？
誰がこれらのテープにアクセスできますか？

クエリ結果セットのような他の形式のデータ移動も考慮する必要があります。一時テーブルの作成中に発生した質問は次のとおりです-

その一時テーブルはどこに保持されますか？
このようなテーブルをどのように表示しますか？

セキュリティ制限の偶発的な軽outを避ける必要があります。制限されたデータにアクセスできるユーザーがアクセス可能な一時テーブルを生成できる場合、データは許可されていないユーザーに表示される可能性があります。この問題は、制限されたデータにアクセスできるユーザー用に一時的な領域を別に用意することで解決できます。

ドキュメンテーション

監査およびセキュリティ要件を適切に文書化する必要があります。これは正当化の一部として扱われます。このドキュメントには、から収集されたすべての情報を含めることができます-

データ分類
ユーザー分類
ネットワーク要件
データの移動とストレージの要件
すべての監査可能なアクション

設計に対するセキュリティの影響

セキュリティは、アプリケーションコードと開発タイムスケールに影響します。セキュリティは次の領域に影響します-

アプリケーション開発
データベース設計
テスト

アプリケーション開発

セキュリティは、アプリケーション開発全体に影響し、ロードマネージャー、ウェアハウスマネージャー、クエリマネージャーなどのデータウェアハウスの重要なコンポーネントの設計にも影響します。ロードマネージャーは、コードをチェックしてレコードをフィルタリングし、それらを異なる場所に配置する必要がある場合があります。特定のデータを非表示にするには、より多くの変換ルールも必要になる場合があります。また、追加のオブジェクトを処理するために追加のメタデータが必要になる場合があります。

追加のビューを作成および維持するために、倉庫管理者はセキュリティを強化するために追加のコードを要求する場合があります。データウェアハウスに余分なチェックをコーディングして、データが利用できないはずの場所にデータを移動させてしまうのを防ぐ必要があります。 Query Managerでは、アクセス制限を処理するために変更が必要です。クエリマネージャーは、すべての追加のビューと集計を認識する必要があります。

データベース設計

セキュリティ対策が実装されると、ビューとテーブルの数が増加するため、データベースレイアウトも影響を受けます。セキュリティを追加すると、データベースのサイズが大きくなるため、データベースの設計と管理の複雑さが増します。また、バックアップ管理と復旧計画が複雑になります。

テスト

データウェアハウスのテストは、複雑で時間がかかるプロセスです。データウェアハウスにセキュリティを追加すると、テスト時間の複雑さに影響します。次の2つの方法でテストに影響します-

統合とシステムのテストに必要な時間が長くなります。
テストする機能が追加され、テストスイートのサイズが大きくなります。

データウェアハウジング-バックアップ

データウェアハウスは複雑なシステムであり、膨大な量のデータが含まれています。そのため、すべてのデータをバックアップして、将来の要件に従ってリカバリできるようにすることが重要です。この章では、バックアップ戦略の設計における問題について説明します。

バックアップ用語

さらに進む前に、以下で説明するバックアップ用語のいくつかを知っておく必要があります。

完全バックアップ-データベース全体を同時にバックアップします。このバックアップには、すべてのデータベースファイル、制御ファイル、およびジャーナルファイルが含まれます。
部分バックアップ-名前が示すように、データベースの完全なバックアップは作成されません。部分バックアップは、データベースのさまざまな部分を日常的にラウンドロビン方式でバックアップする戦略を可能にし、データベース全体が週に1回効果的にバックアップされるため、大規模なデータベースでは非常に便利です。
コールドバックアップ-データベースが完全にシャットダウンされている間にコールドバックアップが取られます。マルチインスタンス環境では、すべてのインスタンスをシャットダウンする必要があります。
ホットバックアップ-ホットバックアップは、データベースエンジンが稼働しているときに行われます。ホットバックアップの要件は、RDBMSごとに異なります。
オンラインバックアップ-ホットバックアップと非常によく似ています。

ハードウェアバックアップ

バックアップに使用するハードウェアを決定することが重要です。バックアップと復元の処理速度は、使用されているハードウェア、ハードウェアの接続方法、ネットワークの帯域幅、バックアップソフトウェア、およびサーバーのI/Oシステムの速度によって異なります。ここでは、利用可能なハードウェアの選択肢とその長所と短所について説明します。これらの選択肢は次のとおりです-

テープ技術
ディスクバックアップ

テープ技術

テープの選択は次のように分類することができます-

テープメディア
スタンドアロンのテープドライブ
テープスタッカー
テープサイロ

テープメディア

テープメディアにはいくつかの種類があります。いくつかのテープメディア標準は、以下の表にリストされています-

Tape Media	Capacity	I/O rates
DLT	40 GB	3 MB/s
3490e	1.6 GB	3 MB/s
8 mm	14 GB	1 MB/s

考慮する必要がある他の要因は次のとおりです-

テープ媒体の信頼性
ユニットあたりのテープ媒体のコスト
スケーラビリティ
テープシステムへのアップグレードのコスト
ユニットあたりのテープ媒体のコスト
テープ媒体の貯蔵寿命

スタンドアロンテープドライブ

テープドライブは次の方法で接続できます-

サーバーに直接
ネットワーク利用可能なデバイスとして
他のマシンにリモートで

テープドライブをデータウェアハウスに接続する際に問題が発生する可能性があります。

サーバーが48node MPPマシンであると考えてください。テープドライブを接続するノードがわからず、サーバーの中断や内部I/Oの遅延を最小限に抑えて最適なパフォーマンスを得るために、それらをサーバーノードに分散する方法もわかりません。
ネットワーク利用可能なデバイスとしてテープドライブを接続するには、ネットワークが膨大なデータ転送速度の仕事に対応している必要があります。必要な時間に十分な帯域幅が利用可能であることを確認してください。
テープドライブをリモートで接続するには、高帯域幅も必要です。

テープスタッカー

複数のテープを単一のテープドライブにロードする方法は、テープスタッカーと呼ばれます。スタッカーは、現在のテープの処理が終了するとマウントを解除し、次のテープをロードします。したがって、アクセスできるテープは一度に1つだけです。価格と機能は異なる場合がありますが、一般的な機能は無人バックアップを実行できることです。

テープサイロ

テープサイロは、大容量の店舗を提供します。テープサイロは、数千のテープを保存および管理できます。複数のテープドライブを統合できます。彼らは、保存するテープにラベルを付けて保存するソフトウェアとハードウェアを持っています。サイロがネットワークまたは専用リンクを介してリモートで接続されることは非常に一般的です。接続の帯域幅が仕事に合っていることを確認する必要があります。

ディスクバックアップ

ディスクバックアップの方法は次のとおりです-

ディスクからディスクへのバックアップ
鏡面破壊

これらのメソッドはOLTPシステムで使用されます。これらの方法は、データベースのダウンタイムを最小化し、可用性を最大化します。

ディスク間バックアップ

ここでは、テープではなくディスクでバックアップが行われます。ディスクからディスクへのバックアップは、次の理由で行われます-

初期バックアップの速度
復元の速度

ディスクからディスクへのデータのバックアップは、テープよりもはるかに高速です。ただし、これはバックアップの中間ステップです。その後、データはテープにバックアップされます。ディスクツーディスクバックアップのもう1つの利点は、最新のバックアップのオンラインコピーが提供されることです。

ミラーブレイク

アイデアは、稼働中に復元力のためにディスクをミラーリングすることです。バックアップが必要な場合、ミラーセットの1つを分割できます。この手法は、ディスク間バックアップの一種です。

注意-バックアップの一貫性を保証するために、データベースをシャットダウンする必要がある場合があります。

光学ジュークボックス

光ジュークボックスを使用すると、データを回線の近くに保存できます。この手法により、テープスタッカーまたはテープサイロと同じ方法で多数の光ディスクを管理できます。この手法の欠点は、ディスクよりも書き込み速度が遅いことです。しかし、光メディアは長寿命で信頼性が高いため、アーカイブに適したメディアの選択肢になります。

ソフトウェアのバックアップ

バックアッププロセスを支援するソフトウェアツールが利用可能です。これらのソフトウェアツールはパッケージとして提供されます。これらのツールはバックアップを取るだけでなく、バックアップ戦略を効果的に管理および制御できます。市場には多くのソフトウェアパッケージがあります。それらのいくつかは、次の表に記載されています-

Package Name	Vendor
Networker	Legato
ADSM	IBM
Epoch	Epoch Systems
Omniback II	HP
Alexandria	Sequent

ソフトウェアパッケージの選択基準

最適なソフトウェアパッケージを選択するための基準は以下のとおりです-

テープドライブの追加に伴う製品の拡張性はどの程度ですか？
パッケージにはクライアントサーバーオプションがありますか、またはデータベースサーバー自体で実行する必要がありますか？
クラスターおよびMPP環境で動作しますか？
どの程度の並列性が必要ですか？
パッケージでサポートされているプラットフォームは何ですか？
パッケージはテープの内容に関する情報への簡単なアクセスをサポートしていますか？
パッケージデータベースは認識していますか？
パッケージでサポートされているテープドライブとテープメディアは何ですか？

データウェアハウジング-チューニング

データウェアハウスは進化し続けており、ユーザーが今後どのクエリを投稿するかは予測できません。そのため、データウェアハウスシステムの調整が難しくなります。この章では、パフォーマンス、データロード、クエリなど、データウェアハウスのさまざまな側面を調整する方法について説明します。

データウェアハウスチューニングの難しさ

データウェアハウスのチューニングは、次の理由により難しい手順です-

データウェアハウスは動的です。一定のままになることはありません。
ユーザーが今後どのクエリを投稿するかを予測することは非常に困難です。
ビジネス要件は時間とともに変化します。
ユーザーとそのプロファイルは変化し続けます。
ユーザーは、あるグループから別のグループに切り替えることができます。
ウェアハウスのデータ負荷も時間とともに変化します。

注-データウェアハウスの完全な知識を持つことが非常に重要です。

性能評価

ここにパフォーマンスの客観的尺度のリストがあります-

平均クエリ応答時間
スキャン率
1日あたりのクエリ時間
プロセスごとのメモリ使用量
I/Oスループットレート

覚えておくべきポイントは次のとおりです。

サービスレベル契約（SLA）で対策を指定する必要があります。
応答時間が既に必要なものより優れている場合、応答時間を調整しようとしても意味がありません。
パフォーマンスを評価する際には、現実的な期待をすることが不可欠です。
ユーザーが実行可能な期待を持っていることも重要です。
システムの複雑さをユーザーから隠すには、集計とビューを使用する必要があります。
また、ユーザーが調整していないクエリを作成できる可能性もあります。

データロードチューニング

データロードは夜間処理の重要な部分です。データのロードが完了するまで、他に何も実行できません。これは、システムへのエントリポイントです。

注意-データの転送、またはデータの到着に遅延がある場合、システム全体が悪影響を受けます。したがって、最初にデータロードを調整することが非常に重要です。

以下で説明するデータロードのチューニングにはさまざまなアプローチがあります-

非常に一般的なアプローチは、* SQLレイヤー*を使用してデータを挿入することです。このアプローチでは、通常のチェックと制約を実行する必要があります。データがテーブルに挿入されると、コードを実行して、データを挿入するのに十分なスペースがあるかどうかを確認します。十分なスペースが利用できない場合、これらのテーブルにより多くのスペースを割り当てる必要があります。これらのチェックは実行に時間がかかり、CPUに負荷がかかります。
2番目のアプローチは、これらすべてのチェックと制約をバイパスし、データを事前にフォーマットされたブロックに直接配置することです。これらのブロックは、後でデータベースに書き込まれます。最初のアプローチよりも高速ですが、データのブロック全体でのみ機能します。これは、スペースの浪費につながる可能性があります。
3番目のアプローチは、すでにテーブルを含んでいるテーブルにデータをロードするときに、インデックスを維持できることです。
4番目のアプローチでは、すでにデータを含んでいるテーブルにデータをロードするには、データのロードが完了したら*インデックスを削除して再作成*します。 3番目と4番目のアプローチの選択は、すでにロードされているデータの量と、再構築する必要があるインデックスの数によって異なります。

整合性チェック

整合性チェックは、負荷のパフォーマンスに大きな影響を与えます。覚えておくべきポイントは次のとおりです-

整合性チェックは大きな処理能力を必要とするため、制限する必要があります。
データ負荷のパフォーマンス低下を回避するために、ソースシステムに整合性チェックを適用する必要があります。

チューニングクエリ

データウェアハウスには2種類のクエリがあります-

固定クエリ
アドホッククエリ

固定クエリ

固定クエリは明確に定義されています。以下は、固定クエリの例です-

定期報告
定型クエリ
一般的な集約

データウェアハウスでの固定クエリのチューニングは、リレーショナルデータベースシステムと同じです。唯一の違いは、照会するデータの量が異なる場合があることです。固定クエリのテスト中に最も成功した実行計画を保存しておくと便利です。これらの実行計画を保存すると、実行計画が変更されるため、変化するデータサイズとデータスキューを見つけることができます。

注-ファクトテーブルでこれ以上行うことはできませんが、ディメンションテーブルまたは集計の処理中に、SQL調整、ストレージメカニズム、およびアクセスメソッドの通常のコレクションを使用して、これらのクエリを調整できます。

アドホッククエリ

アドホッククエリを理解するには、データウェアハウスのアドホックユーザーを知ることが重要です。各ユーザーまたはユーザーのグループについては、次のことを知る必要があります-

グループ内のユーザー数
定期的にアドホッククエリを使用するかどうか
アドホッククエリを頻繁に使用するかどうか
不明な間隔で時々アドホッククエリを使用するかどうか。
実行する傾向があるクエリの最大サイズ
実行する傾向があるクエリの平均サイズ
基本データへのドリルダウンアクセスが必要かどうか
1日あたりの経過ログイン時間
毎日の使用のピーク時間
ピーク時間ごとに実行されるクエリの数

注意事項

ユーザーのプロファイルを追跡し、定期的に実行されるクエリを識別することが重要です。
また、実行されるチューニングがパフォーマンスに影響を与えないことも重要です。
頻繁に実行される同様のアドホッククエリを特定します。
これらのクエリが識別されると、データベースが変更され、それらのクエリに新しいインデックスを追加できます。
これらのクエリが識別された場合、効率的な実行につながるクエリ専用に新しい集計を作成できます。

データウェアハウジング-テスト

テストは、データウェアハウスシステムが正しく効率的に機能するために非常に重要です。データウェアハウスで実行されるテストには3つの基本レベルがあります-

単体テスト
統合テスト
システムテスト

単体テスト

単体テストでは、各コンポーネントが個別にテストされます。
各モジュール、つまりプロシージャ、プログラム、SQLスクリプト、Unixシェルがテストされます。
このテストは開発者によって実行されます。

統合テスト

統合テストでは、アプリケーションのさまざまなモジュールがまとめられ、入力数に対してテストされます。
さまざまなコンポーネントが統合後にうまく機能するかどうかをテストするために実行されます。

システムテスト

システムテストでは、データウェアハウスアプリケーション全体が一緒にテストされます。
システムテストの目的は、システム全体が正常に機能するかどうかを確認することです。
システムテストは、テストチームによって実行されます。
データウェアハウス全体のサイズは非常に大きいため、通常、テスト計画を実施する前に最小限のシステムテストを実行することができます。

テストスケジュール

まず、テスト計画を作成する過程でテストスケジュールが作成されます。このスケジュールでは、データウェアハウスシステム全体のテストに必要な推定時間を予測します。

テストスケジュールを作成するために利用できるさまざまな方法論がありますが、データウェアハウスは非常に複雑で大規模であるため、いずれも完璧ではありません。また、データウェアハウスシステムは本質的に進化しています。テストスケジュールの作成中に次の問題に直面する可能性があります-

単純な問題には、完了するまでに1日以上かかる大きなサイズのクエリが含まれる場合があります。つまり、クエリは希望する時間スケールで完了しません。
ディスクの紛失などのハードウェア障害や、誤ってテーブルを削除したり、大きなテーブルを上書きしたりする人為的なエラーが発生する場合があります。

注意-上記の問題のため、通常はテストに許可する時間を常に2倍にすることをお勧めします。

バックアップリカバリのテスト

バックアップ回復戦略のテストは非常に重要です。このテストが必要なシナリオのリストはここにあります-

メディア障害
表スペースまたはデータファイルの損失または損傷
REDOログファイルの損失または損傷
制御ファイルの紛失または損傷
インスタンス障害
アーカイブファイルの紛失または破損
テーブルの紛失または損傷
データ障害中の障害

運用環境のテスト

テストする必要のある多くの側面があります。これらの側面を以下にリストします。

セキュリティ-セキュリティテストには個別のセキュリティドキュメントが必要です。このドキュメントには、許可されていない操作とそれぞれのテストの考案のリストが含まれています。
Scheduler -データウェアハウスの日常業務を制御するには、スケジューリングソフトウェアが必要です。システムのテスト中にテストする必要があります。スケジューリングソフトウェアには、データウェアハウスとのインターフェイスが必要です。データウェアハウスには、夜間の処理と集計の管理を制御するスケジューラが必要です。
ディスク構成-I/Oボトルネックを識別するために、ディスク構成もテストする必要があります。テストは、異なる設定で複数回実行する必要があります。
管理ツール-システムのテスト中にすべての管理ツールをテストする必要があります。テストする必要があるツールのリストを次に示します。
イベントマネージャ
システム管理者
データベースマネージャー
構成マネージャー
バックアップリカバリマネージャー

データベースのテスト

データベースは、次の3つの方法でテストされます-

データベースマネージャーと監視ツールのテスト-データベースマネージャーと監視ツールをテストするには、テストデータベースの作成、実行、管理に使用する必要があります。
データベース機能のテスト-ここにテストする必要がある機能のリストがあります-
並列クエリ
並行してインデックスを作成する
並行してデータをロード
データベースパフォーマンスのテスト-クエリの実行は、データウェアハウスのパフォーマンス測定において非常に重要な役割を果たします。定期的に実行する必要がある固定クエリのセットがあり、テストする必要があります。アドホッククエリをテストするには、ユーザー要件ドキュメントを確認し、ビジネスを完全に理解する必要があります。さまざまなインデックスおよび集計戦略に対して、ビジネスで要求される可能性が高い最も厄介なクエリをテストするために時間をかけてください。

アプリケーションのテスト

すべてのマネージャーを正しく統合し、エンドツーエンドのロード、インデックス、集計、クエリが期待どおりに機能するように機能する必要があります。
各マネージャーの各機能は正しく動作するはずです
また、一定期間にわたってアプリケーションをテストする必要があります。
週末と月末のタスクもテストする必要があります。

テストのロジスティック

システムテストの目的は、次のすべての領域をテストすることです-

スケジューリングソフトウェア
日々の運用手順
バックアップ復旧戦略
管理およびスケジューリングツール
一晩処理
クエリのパフォーマンス

注-最も重要な点は、スケーラビリティをテストすることです。そうしないと、システムの成長時に機能しないシステム設計が残ります。

データウェアハウジング-将来の側面

以下は、データウェアハウジングの将来の側面です。

過去数年間でオープンデータベースのサイズがその規模の約2倍になったことを見てきたように、そこに含まれる重要な価値を示しています。
データベースのサイズが大きくなると、非常に大きなデータベースを構成するものの推定値が大きくなり続けます。
現在利用可能なハードウェアとソフトウェアでは、大量のデータをオンラインで保持することはできません。たとえば、電話会社の通話記録では、10 TBのデータをオンラインで保持する必要がありますが、これはわずか1か月分の記録です。売上、マーケティング顧客、従業員などの記録を保持する必要がある場合、サイズは100 TBを超えます。
レコードには、テキスト情報といくつかのマルチメディアデータが含まれています。マルチメディアデータをテキストデータとして簡単に操作することはできません。マルチメディアデータの検索は簡単な作業ではありませんが、テキスト情報は現在入手可能なリレーショナルソフトウェアで取得できます。
サイズ計画とは別に、サイズが増え続けるデータウェアハウスシステムの構築と実行は複雑です。ユーザー数が増加すると、データウェアハウスのサイズも増加します。これらのユーザーもシステムにアクセスする必要があります。
インターネットの成長に伴い、ユーザーはオンラインでデータにアクセスする必要があります。

したがって、データウェアハウスの将来の形状は、現在作成されているものとは大きく異なります。 Dwh-interview-questions

Dwh-quick-guide

データウェアハウジング-概要

データウェアハウスについて

データウェアハウスが運用データベースから分離されている理由

データウェアハウスの機能

データウェアハウスアプリケーション

データウェアハウスの種類

データウェアハウジング-概念

データウェアハウジングとは何ですか？

データウェアハウス情報の使用

異種データベースの統合

クエリ駆動型アプローチ

クエリ駆動型アプローチのプロセス

デメリット

更新主導のアプローチ

利点

データウェアハウスのツールとユーティリティの機能

データウェアハウジング-用語

メタデータ

メタデータリポジトリ

データキューブ

データキューブの図

データ市場

データマートに関する注意点

仮想倉庫

データウェアハウジング-配信プロセス

配送方法

IT戦略

ビジネスケース

教育とプロトタイピング

ビジネス要件

技術的な青写真

バージョンの構築

履歴ロード

アドホッククエリ

オートメーション

スコープの拡大

要件の進化

データウェアハウジング-システムプロセス

データウェアハウスのプロセスフロー

抽出およびロードプロセス

プロセスの制御

抽出を開始するタイミング

データの読み込み

クリーンおよび変換プロセス

ロードされたデータをクリーンにし、構造に変換します

データを分割する

集約

データのバックアップとアーカイブ

クエリ管理プロセス

データウェアハウジング-アーキテクチャ

ビジネス分析フレームワーク

3層データウェアハウスアーキテクチャ

データウェアハウスモデル

仮想倉庫

データ市場

エンタープライズウェアハウス

ロードマネージャー

ロードマネージャーのアーキテクチャ

ソースからデータを抽出する

高速負荷

単純な変換

倉庫マネージャー

Warehouse Managerのアーキテクチャ

Warehouse Managerによって実行される操作

クエリマネージャー

Query Managerのアーキテクチャ

詳細な情報

要約情報

データウェアハウジング-OLAP

OLAPサーバーの種類

リレーショナルOLAP

多次元OLAP

ハイブリッドOLAP

専用のSQLサーバー

OLAP操作

巻き上げる

ドリルダウン

スライス

Dice