Loading article…
コンピューティングにおいて、データウェアハウス（DWまたはDWH）、別名エンタープライズデータウェアハウス（EDW ）は、レポート作成とデータ分析に使用されるシステムであり、ビジネスインテリジェンスの中核コンポーネントです。[ 1 ]データウェアハウスは、さまざまなソースから統合されたデータの中央リポジトリです。データ分析、レポートの生成、統合されたデータ全体にわたる洞察の開発に最適化された方法で整理された、現在および過去のデータを保存します。[ 2 ]アナリストやマネージャーが組織の意思決定を支援するために使用することを目的としています。[ 3 ]
データウェアハウスに保存されるデータは、運用システム（マーケティングや販売など）からアップロードされます。データは運用データストアを経由する場合があり、レポート作成のためにデータウェアハウスで使用される前に、データ品質を確保するための追加処理としてデータクレンジングが必要になる場合があります。
データウェアハウスシステムを構築するための主なワークフローは、抽出、変換、ロード（ETL）と抽出、ロード、変換（ELT）の2つです。
データウェアハウスおよびデータマートの環境には、以下の要素が含まれます。
運用データベースは、データベース正規化とエンティティ関係モデルの使用により、データ整合性の維持とビジネス トランザクションの記録速度を最適化するように設計されている。[ 4 ]運用システム設計者は、一般的にデータ整合性を確保するためにデータベース正規化に従う。完全に正規化されたデータベース設計では、ビジネス トランザクションからの情報が数十から数百のテーブルに格納されることが多い。リレーショナル データベースは、これらのテーブル間の関係を効率的に管理できる。これらのテーブル内の少量のデータのみが各トランザクションの影響を受けるため、データベースの挿入/更新パフォーマンスは非常に高速である。パフォーマンスを向上させるために、古いデータは定期的に削除される。
データウェアハウスは、分析アクセスパターンに最適化されています。分析アクセスパターンでは、運用データベースで一般的なようにすべてのフィールドを選択するのではなく、特定のフィールドを選択することが一般的です。このようなアクセス方法の違いから、運用データベース（一般的にOLTP）は行指向データベース管理システム（DBMS）の利用によってメリットが得られるのに対し、分析データベース（一般的にOLAP）は列指向DBMSの利用によってメリットが得られます。運用システムはビジネスのスナップショットを維持する一方、データウェアハウスは、運用システムからデータウェアハウスへ定期的にデータを移行するETLプロセスを通じて履歴データを維持します。
オンライン分析処理(OLAP) は、トランザクションのレートが低く、集計を伴う複雑なクエリが特徴です。[ 5 ]応答時間は、OLAP システムの効果的なパフォーマンス指標です。OLAP アプリケーションは、データ マイニングに広く使用されています。OLAP データベースは、集計された履歴データを多次元スキーマ (通常はスター スキーマ) に格納します。OLAP システムのデータ遅延は通常数時間ですが、データ マートの遅延は 1 日近くになります。OLAP アプローチは、複数のソースと視点から多次元データを分析するために使用されます。OLAP の 3 つの基本操作は、ロールアップ (統合)、ドリルダウン、およびスライス & ダイシングです。
オンライン・トランザクション処理（OLTP）は、多数の短いオンライン・トランザクション（INSERT、UPDATE、DELETE）を特徴としています。OLTPシステムは、高速なクエリ処理と、マルチアクセス環境におけるデータ整合性の維持を重視します。OLTPシステムにおけるパフォーマンスは、1秒あたりのトランザクション数で表されます。OLTPデータベースには、詳細かつ最新のデータが格納されます。トランザクション・データベースを格納するために使用されるスキーマは、エンティティ・モデル（通常は第3正規形）です。正規化は、このシステムにおけるデータ・モデリング手法の標準です。
予測分析とは、複雑な数理モデルを用いてデータに潜むパターンを見つけ出し、定量化することで、製品需要など様々な将来の結果に備え、より良い意思決定を行うことです。一方、OLAPは過去のデータ分析に重点を置き、事後対応型です。予測システムは、顧客関係管理（CRM）にも利用されています。
データベースとは、電子的に保存および管理される整理されたデータの集合です。[ 6 ]データベースは、データベース管理システム（DBMS）を使用してデータを照会および操作することにより、構造化データを保存、取得、管理するように設計されています。
データマートは、単一の主題または機能領域に焦点を当てたシンプルなデータウェアハウスです。そのため、販売、財務、マーケティングなど、限られた数のソースからデータを取得します。データマートは、多くの場合、組織内の単一の部門によって構築および管理されます。ソースは、内部運用システム、中央データウェアハウス、または外部データである可能性があります。[ 8 ]
データマートの種類には、依存型、独立型、ハイブリッド型データマートがあります。
データレイクは、実行時に処理される生の形式で大量のデータを保存する集中型リポジトリです。[ 9 ] API、ファイル、データベース、センサー、Webサイトなど、複数のソースからデータを収集できます。データウェアハウスとは異なり、データレイクは構造化、半構造化、非構造化形式でデータを保存するため、機械学習やビッグデータ処理に使用できます。
典型的な抽出、変換、ロード(ETL) ベースのデータウェアハウスは、ステージング、データ統合、およびアクセスレイヤーを使用して主要な機能を保持します。ステージングレイヤーまたはステージングデータベースは、さまざまなソースデータシステムから抽出された生データを格納します。統合レイヤーは、ステージングレイヤーからのデータを変換してさまざまなデータセットを統合し、多くの場合、この変換されたデータを運用データストア(ODS) データベースに格納します。統合されたデータは、データウェアハウスデータベースと呼ばれる別のデータベースに移動され、そこでデータは、ディメンションと呼ばれる階層グループ、およびファクトと集計ファクトに整理されます。ファクトとディメンションの組み合わせは、スタースキーマと呼ばれることもあります。アクセスレイヤーは、ユーザーがデータを取得するのに役立ちます。[ 11 ]
データの主なソースは、データマイニング、オンライン分析処理、市場調査、意思決定支援のために、管理者やその他のビジネス専門家が使用できるように、クレンジング、変換、カタログ化されます。[ 12 ]ただし、データの取得と分析、データの抽出、変換、ロード、およびデータ辞書の管理の手段も、データウェアハウジングシステムの重要なコンポーネントと考えられています。データウェアハウジングに関する多くの参照では、このより広いコンテキストが使用されています。したがって、拡張されたデータウェアハウジングの定義には、ビジネスインテリジェンスツール、リポジトリへのデータの抽出、変換、ロードツール、メタデータの管理と取得ツールが含まれます。
ELTベースのデータウェアハウジングでは、データ変換のためのETLツールが不要になります。代わりに、データウェアハウス内部にステージング領域が設けられます。この方式では、データは異種混在のソースシステムから抽出され、変換処理が行われる前にデータウェアハウスに直接ロードされます。必要な変換処理はすべてデータウェアハウス内部で行われます。最後に、処理済みのデータが同じデータウェアハウス内のターゲットテーブルにロードされます。
データウェアハウスは、ソーストランザクションシステムからの情報のコピーを保持します。このアーキテクチャの複雑さにより、以下のことが可能になります。
データウェアハウスの概念は、IBM の研究者であるバリー・デブリンとポール・マーフィーが「ビジネスデータウェアハウス」を開発した1980 年代後半に遡ります[ 13 ] 。本質的に、データウェアハウスの概念は、運用システムから意思決定支援環境へのデータの流れのためのアーキテクチャ モデルを提供することを目的としていました。この概念は、この流れに関連するさまざまな問題、主にそれに伴う高コストに対処しようとしました。データウェアハウス アーキテクチャがない場合、複数の意思決定支援環境をサポートするために膨大な冗長性が必要でした。大企業では、複数の意思決定支援環境が独立して運用されるのが一般的でした。各環境は異なるユーザーにサービスを提供していましたが、多くの場合、同じ保存データを必要としていました。さまざまなソース、通常は長期にわたって存在する運用システム (通常はレガシー システムと呼ばれる) からのデータの収集、クリーニング、統合のプロセスは、通常、各環境で部分的に複製されていました。さらに、新しい意思決定支援要件が出現すると、運用システムは頻繁に再検討されました。新たな要件が発生すると、ユーザーが容易にアクセスできるように調整された「データマート」から新しいデータを収集、整理、統合する必要が生じることが多かった。
さらに、ジェームズ・M・カー著『The IRM Imperative』（Wiley & Sons、1991年）の出版により、組織のデータリソースを管理し、その価値を金銭的価値として評価し、貸借対照表に資産として計上するという考え方が広く普及しました。同書の中でカーは、トランザクション駆動型システムから得られたデータを用いて主題別データベースを構築し、要約データをさらに活用して経営幹部の意思決定に役立てることができるストレージ領域を作成する方法を解説しています。この概念は、あらゆる企業においてデータウェアハウスをいかに実用的に開発・管理できるかという議論をさらに促進するきっかけとなりました。
データウェアハウジング初期における主な発展：
事実とは、管理対象システムにおける値または測定値のことである。
生データは、報告主体によって報告されるデータです。例えば、携帯電話システムにおいて、基地局（BTS）がトラフィックチャネル割り当て要求を1,000件受信し、820件を割り当て、残りを拒否した場合、管理システムには次の3つのデータが報告される可能性があります。
tch_req_total = 1000tch_req_success = 820tch_req_fail = 180生データは、さまざまな次元でより高いレベルに集約され、サービスやビジネスにより関連性の高い情報が抽出されます。これらは集約データまたは要約データと呼ばれます。
例えば、ある都市に3つの基地局（BTS）がある場合、上記の事実をネットワーク次元で都市レベルに集約することができます。例：
tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3データウェアハウスにデータを格納するための最も重要なアプローチは、ディメンションと正規化の2つです。ディメンションアプローチは、ラルフ・キンボールが提案したスタースキーマを使用します。正規化アプローチは、第3正規形（3NF）とも呼ばれ、ビル・インモンが提案したエンティティ関係の正規化モデルです。[ 27 ]
ディメンションアプローチでは、トランザクションデータは、通常は数値トランザクションデータである「ファクト」と、ファクトにコンテキストを与える参照情報である「ディメンション」に分割されます。たとえば、販売トランザクションは、注文された製品の数や製品の合計支払額などのファクトと、注文日、顧客名、製品番号、注文の配送先と請求先、注文の受領を担当した営業担当者などのディメンションに分割できます。
この次元アプローチにより、データの理解が容易になり、データ検索が高速化されます。[ 21 ]次元構造は、構造が測定値/事実とコンテキスト/次元に分割されているため、ビジネスユーザーにとって理解しやすいです。事実は組織のビジネスプロセスと運用システムに関連し、次元はそれらに関するコンテキストです（Kimball、Ralph 2008）。もう1つの利点は、次元モデルでは毎回リレーショナルデータベースが関与しないことです。したがって、このタイプのモデリング手法は、データウェアハウスのエンドユーザークエリに非常に役立ちます。
事実と次元のモデルはデータキューブとしても理解できます[ 28 ]。ここで、次元は多次元キューブ内のカテゴリ座標であり、事実は座標に対応する値です。
次元アプローチの主な欠点は以下のとおりです。
正規化アプローチでは、データウェアハウス内のデータは、ある程度データベースの正規化ルールに従って格納されます。正規化されたリレーショナルデータベーステーブルは、主題領域（たとえば、顧客、製品、財務）ごとにグループ化されます。大規模企業で使用される場合、結果として、結合のネットワークでリンクされた数十のテーブルが生成されます（Kimball, Ralph 2008）。
このアプローチの主な利点は、データベースへの情報の追加が容易であることです。一方、欠点としては、テーブル数が多いため、異なるソースからのデータを意味のある情報に結合したり、データソースやデータウェアハウスのデータ構造を正確に理解せずに情報にアクセスしたりすることが困難になる場合があることが挙げられます。
正規化モデルと次元モデルはどちらも結合された関係テーブルを含むため、エンティティ関係図で表現できます。両者の違いは正規化の度合いです。これらのアプローチは相互に排他的ではなく、他にもアプローチがあります。次元アプローチでは、データをある程度正規化することができます（Kimball, Ralph 2008）。
『Information-Driven Business』 [ 29 ]において 、ロバート・ヒラードは、ビジネス上の問題の情報ニーズに基づいて2つのアプローチを比較しています。彼は、正規化モデルは、同じフィールドが両方のモデルで使用されている場合でも、次元の同等物よりもはるかに多くの情報を保持していますが、使いやすさを犠牲にしていると結論付けています。この手法は、情報エントロピーの観点から情報量を、スモールワールドデータ変換尺度の観点から使いやすさを測定します。[ 30 ]
ボトムアップアプローチでは、まず特定のビジネスプロセスに対するレポート作成機能と分析機能を提供するためにデータマートが作成されます。これらのデータマートは統合されて、包括的なデータウェアハウスを作成できます。データウェアハウスバスアーキテクチャは、主に「バス」の実装であり、これは確認済みのディメンションと確認済みのファクトの集合です。確認済みのディメンションとは、2 つ以上のデータマートのファクト間で (特定の方法で) 共有されるディメンションのことです。[ 31 ]
トップダウンのアプローチは、正規化されたエンタープライズデータモデルを使用して設計されています。「アトミック」データ、つまり最も詳細なレベルのデータは、データウェアハウスに格納されます。特定のビジネスプロセスまたは特定の部門に必要なデータを含むディメンションデータマートは、データウェアハウスから作成されます。[ 32 ]
データウェアハウスは、多くの場合、スポーク・ハブ型の分散パラダイムを採用しています。ウェアハウスにデータを供給するレガシーシステムには、顧客関係管理（CRM）や企業資源計画（ERP）などがあり、大量のデータを生成します。これらの多様なデータモデルを統合し、抽出・変換・ロード（ETL）プロセスを円滑に進めるため、データウェアハウスは多くの場合、運用データストアを利用し、そこから情報を解析して実際のデータウェアハウスに格納します。データの冗長性を低減するため、大規模なシステムでは、データを正規化された形式で格納することがよくあります。その後、データウェアハウス上に、特定のレポート用のデータマートを構築できます。
ハイブリッド（アンサンブルとも呼ばれる）データウェアハウスデータベースは、データの冗長性を排除するために第三正規形に維持されます。しかし、通常のリレーショナルデータベースは、ディメンションモデリングが主流となるビジネスインテリジェンスレポートには効率的ではありません。小規模なデータマートは、統合されたウェアハウスからデータを取得し、フィルタリングされた特定のデータを必要なファクトテーブルとディメンションに使用できます。データウェアハウスは、データマートが読み取ることができる単一の情報源を提供し、幅広いビジネス情報を提供します。ハイブリッドアーキテクチャでは、データウェアハウスを、運用情報（静的情報ではない）を格納できるマスターデータ管理リポジトリに置き換えることができます。
データボールトのモデリングコンポーネントは、ハブアンドスポークアーキテクチャを採用しています。このモデリングスタイルは、第三正規形とスタースキーマの両方のベストプラクティスを組み合わせたハイブリッド設計です。データボールトモデルは真の第三正規形ではなく、そのルールの一部に違反していますが、ボトムアップ設計のトップダウンアーキテクチャとなっています。データボールトモデルは、データウェアハウスとしてのみ機能するように設計されています。エンドユーザーがアクセスできるようには設計されておらず、構築後もビジネス目的でデータマートまたはスタースキーマベースのリリース領域を使用する必要があります。
データウェアハウス内のデータを定義する基本的な特徴には、主題指向性、データ統合、時系列性、非揮発性データ、データ粒度などが含まれます。
運用システムとは異なり、データウェアハウス内のデータは企業の主題を中心に構成されています。主題指向はデータベースの正規化とは異なります。主題指向は意思決定に非常に役立ちます。必要なオブジェクトを収集することを主題指向と呼びます。
データウェアハウス内のデータは統合されています。複数の運用システムから取得されるため、すべての不整合を取り除く必要があります。整合性には、命名規則、変数の測定方法、エンコーディング構造、データの物理的属性などが含まれます。
運用システムは日々の業務をサポートするため現在の値を反映する一方、データウェアハウスのデータは長期（最大10年）にわたるデータを表すため、主に履歴データを保存します。これは主にデータマイニングと予測を目的としています。（たとえば、ユーザーが特定の顧客の購買パターンを検索する場合、ユーザーは現在および過去の購入に関するデータを参照する必要があります。）[ 33 ]
データウェアハウス内のデータは読み取り専用であり、更新、作成、削除することはできません（規制上または法律上の義務がある場合を除く）。[ 34 ]
データウェアハウスのプロセスでは、データはさまざまな抽象度レベルでデータマートに集約されます。ユーザーは、まず地域全体の製品の総販売数量を確認するかもしれません。次に、その地域の州を確認します。最後に、特定の州の個々の店舗を調べるかもしれません。したがって、通常、分析はより高いレベルから始まり、より詳細なレベルへと掘り下げていきます。[ 33 ]
データ仮想化では、使用されるデータは元の場所に保持され、リアルタイムアクセスが確立されるため、複数のソースにわたる分析が可能になり、仮想データウェアハウスが作成されます。これにより、さまざまなプラットフォームからのデータを組み合わせる際の互換性の問題などの技術的な困難を解決したり、データの欠陥によるエラーのリスクを低減したり、最新のデータが使用されることを保証したりすることができます。さらに、個人情報を含む新しいデータベースの作成を避けることで、プライバシー規制への準拠が容易になります。ただし、データ仮想化では、データのローカルコピーがないため、必要なすべてのデータソースへの接続が稼働している必要があり、これがこのアプローチの主な欠点の1つです。[ 35 ]
組織が指定するデータウェアハウスを構築/編成するために使用されるさまざまな方法は数多くあります。データウェアハウスの適切な機能に特に必要なハードウェア、作成されたソフトウェア、およびデータリソースは、データウェアハウスアーキテクチャの主要な構成要素です。すべてのデータウェアハウスには、組織の要件が修正および微調整される複数のフェーズがあります。[ 36 ]
これらの用語は、データウェアハウスの高度化レベルを指します。
医療分野において、データウェアハウスは医療情報学の重要な構成要素であり、大量の臨床データ、管理データ、運用データの統合、保存、分析を可能にします。これらのシステムは、電子カルテ（EHR）、検査情報システム、画像保存通信システム（PACS）、医療請求プラットフォームなど、さまざまなソースからの情報を統合します。データを一元化することで、医療データウェアハウスは、地域医療、臨床意思決定支援、品質改善、公衆衛生監視、医学研究など、幅広い機能をサポートします。
医療データウェアハウスには、医療データの複雑さや機密性を考慮した特殊なデータモデルが組み込まれていることが多く、例えば、時間的情報（患者の長期的な病歴など）、コード化された用語（ICD-10、SNOMED CTなど）、プライバシー規制への準拠（米国のHIPAAや欧州連合のGDPRなど）といった要素が含まれる。
以下は、検査結果、薬局、年齢、人種、社会経済的地位、併存疾患、経時的変化などの変数を含む、広範な範囲（疾患や専門分野に限定されない）の主要患者データウェアハウスのリストです。
これらのデータウェアハウスは、過去の研究、比較有効性研究、予測分析をサポートすることで、データ駆動型ヘルスケアを可能にします。多くの場合、ヘルスケアに応用された人工知能が使用されます。