ここでは、企業のデータを一元的に管理するデータ管理基盤について次の観点で説明します。
データ管理基盤とは
データは、個別のシステムで生成され管理されますが、企業全体でデータを一元管理したい場合、データを一箇所に集約して分析しやすい形に変換して利活用します。
この、企業全体でデータを一元管理するための基盤をデータ管理基盤といいます。
また、個別のシステムのデータベースも含めた範囲を広義のデータ管理基盤といいます。
データアーキテクチャで設計されたデータモデルは、データ管理基盤上に実装されます。
なので、データマネジメントの管理対象には、論理的基盤であるデータアーキテクチャと、それを実装し管理する物理的基盤であるデータ管理基盤があるのです。
データ管理基盤は、様々なデータの連携を管理するデータ連携基盤と、データを中央で一元管理するデータ基盤、データ基盤のデータを分析するためのデータ分析環境（データマートやBIツール）にわけることができます。
それでは、データ管理基盤を構成する要素を一つひとつ見ていきましょう。
リレーショナルデータベース
主に下記1から5の要件を満たすために、ファイルを統合し、高度化したものをデータベースといいます。
- データの重複の排除
- 排他制御
- プログラムからの独立
- アクセスコントロール
- 障害回復管理
また、データベースを管理するソフトウェアをデータベースマネジメントシステム、略してDBMSといいます。
そして、データベースとDBMSをあわせてデータベースシステムといいます。
ただ、通常、データベースというと、DBMSも含めたデータベースシステムのことを指します。
さて、下図は、データ、実体（エンティティ）、データモデルの関係を表したものです。
この例の場合、データが表形式で管理されていますが、この表形式のデータセットを、専門用語でリレーションといいます。
リレーション、つまり、表形式でデータを管理するデータベースのことをリレーショナルデータベース（RDB）といいます。
ここで、Webアプリケーションで、アプリケーションとデータベースの関係を説明します。
Webアプリケーションは、ブラウザ上でユーザーインターフェースをコントロールするクライアントアプリケーションと、サーバー側でデータベースとのやりとりを管理するサーバーアプリケーションに分けることができます。
サーバーアプリケーションの土台となるアプリケーションサーバーにには、DBMSをコントロールするDBドライバーというソフトウェアがあり、クライアントアプリケーションから渡されるデータはDBドライバーを介してデータベースに保管されます。
【動画】リレーショナルデータベース
データウェアハウス
データウェアハウス（DWH）とは、大量のデータを収集・統合し、組織全体での分析や意思決定支援に使用するためのデータベースシステムのことで、リレーショナルDBの一種です。
データを分析するために、データベースのデータを問合せることをクエリといいますが、データウェアハウスは、意思決定の支援ができるよう、列指向のデータストアや並列処理など高速なデータの問合せ、クエリができる機能を備えています。
また、データウェアハウスは、組織全体のデータを収集して、分析できやすい型に変換して、統合します。
この統合の過程を、データの抽出（Extract）、変換（Transform）、読込（Load）を略してETLといいます。
データを変換する処理の一環として名寄や欠損データの修復などデータのクレンジングを行うこともあります。
データウェアハウスは、データのウェアハウス、つまり、データの倉庫です。
１月の売上データ、２月の売上データ、３月の売上データというように、分析しやすい形にトランスフォームされたデータが時系列で蓄積されていきくのです。
なので、過去からの履歴データを保持するデータウェアハウスは、データの適時性を高めるソリューションの一つになります。
さて、データウェアハウスには、組織全体のデータが統合されていますが、データウェアハウスのデータを特定の領域別、部門別に分割したリポジトリをデータマートといいます。
ある部門だけが見れるデータだけに限定することで、データセキュリティを担保することができます。
どのようなデータマートが必要か明確でない場合、全社レベルのセントラルデータウェアハウスを設けて、そこから必要に応じて部門別、領域別にデータ分析環境（データマート）を構築することになりますが、全体概念分析データモデルが設計されている場合、セントラルデータウェアハウスを設けずに、分析の目的（サブジェクト）別にデータ分析環境（データマート）を構築することができます。
【動画】データウェアハウス
データレイク
データレイクとは、さまざまな種類や構造を持った膨大な量のデータをインジェスト（飲み込み）し保存し評価し分析できる環境のことです。
DMBOKでは、データレイクについて次のように言及しています。
- データサイエンティストがデータをマイニングし分析するための環境となる
- データ変換が必要であっても最小限ですむような、生データの中央記憶装置となる
- 詳細な履歴データを持つデータウェアハウスの代替ストレージとなる
最近は、SNSやIoTによって大量のデータが発生しています。
いわゆるいビッグデータです。
IMBでは、ビッグデータを３Vというキーワードを使って説明しています。
大量で多様なデータを高速で処理する必要があるということです。
そこで、大量で多様なデータを高速に処理するためのデータストレージとして、データレイクというソリューションが出てきました。
データレイクには、例えば、Hadoopのような、さまざまな形式のデータを高速に処理する仕組があります。
データウェアハウスは、さきほど説明したように表形式で構造化された大量のデータを扱います。
しかし、データ全体から見ると、このように構造化されたデータは、ごく一部です。
構造化データだけではなく、画像や音声など非構造化データも扱いたい場合は、データレイクを検討する必要があります。
DMBOKでは、データレイクは、データサイエンティストがデータをマイニングし分析するための環境となると説明しています。
データレイクは、様々なデータを一旦飲み込んで、必要に応じて変換することで、AIを通して、データサイエンティストに活用されるのです。
データウェアハウスの箇所で、データは、抽出され変換されロードされる、ETLの説明をしましたが、
データレイクの場合、データは抽出された後、一旦ロードされ、必要に応じてさまざまな形に変換されます。
つまり、データレイクの場合、ETLではなく、ELTになります。
これを、DMBOKでは、
データ変換が必要であっても最小限ですむような、生データの中央記憶装置となる
と説明しています。
だた、DMBOKでは、
データレイク（湖）の危険性は、それがすぐにデータスワンプ（沼）になってしまうことである。
つまり乱雑で、汚れていて、一貫性がないものになってしまう。
データレイクに含まれているデータを台帳化するには、データがインジェストされる前にメタデータを管理すべきである。
と説明しています。
データレイク内のデータがどのように関連付けられて結合されているかを理解するために、データアーキテクトは、データモデルを記述しメタデータとして定義します。
さて、構造化されたデータを扱うデータウェアハウスに対して、データレイクは、非構造化データも扱えるので、データウェアハウスの代替になります。
ただ注意すべきは、データレイクで扱う構造化データは、データウェアハウスのように必ずしも表形式で構造化されているわけではなくCSVやJSONのようなテキスト形式として構造化されています。
さらに、データウェアハウスのように高速なクエリを実現するエンジンを持っているとは限りません。
なので、データウェアハウスとデータレイクは用途によって使い分けるのが賢明だと思います。
上図では、多次元分析のような記述的分析をする場合は、データウェアハウスを使い、さまざまなデータをAIがマイニングする必要があるデータサイエンスにはデータレイクを活用するという例を示しています。
もちろん、データウェアハウスの構造化データをAIが活用するのことも可能です。
さらに、すべてのデータを一旦データレイクにインジェストし、その中の必要なデータを統合し、データウェアハウスで活用するという構成も可能です。
【動画】データレイク
NoSQL
リレーショナルデータベースやデータウェアハウスが構造化データを扱い、データレイクがさらに非構造化データを扱うのに対してNoSQLは主に半構造化データを扱います。
半構造化データとは、表形式で構造化されたリレーショナル・データベースのテーブルのような厳密な構造を持たないが（例えば、データの値の長さや形式がバラバラ）、一定の構造や規則性があるデータの形式を指します。
NoSQLについては、記事NoSQLとは何かを参照してください。
【動画】NoSQL
マスターデータ管理
マスターデータ管理（Master Data Management、MDM）は、組織が所有するさまざまなデータのうち、特に重要で共有されるマスターデータを一元管理し、一貫性を保ちながら利用するための手法やプロセスを指します。
DMBOKでは、マスターデータの種類として以下をあげています。
- パーティマスターデータ
パーティマスターデータのパーティは、Party、人の集まりを表しています。なので、顧客データや、社員データ、取引先のデータが該当します。 - 財務マスターデータ
事業単位、コストセンター、プロフィットセンター、勘定科目、予算、財務予測、プロジェクトなど財務に関するデータのことです。 - 法令マスターデータ
契約や規則などの法的事項に関するデータが含まれています。 - 製品マスターデータ
社内の製品やサービス、業界全体（競合他社含む）の製品やサービスのデータのことです。
製品や部品の品目を表す品目マスターも製品マスターとして考えることができます。 - ロケーションマスターデータ
拠点に関するデータのことで、地理情報を追跡して共有し、それに基づいて階層関係や担当地域を生成する機能を持ちます。 - 業種マスターデータ
業界で共有できるデータのことです。例えば、米国医師会の処方医師データベースなど、外部から購入できるマスターデータがあります。
例えば、顧客データについて考えてみましょう。
顧客データが必要なシステムはたくさんあります。
これらのシステム、それぞれで顧客データを重複して管理すると、あるシステムでは最新化されているけど、他のシステムでは最新化されていない
すべての顧客データが整合しなくなる可能性があります。
古いままの顧客の住所に請求やダイレクトメールを出しても届かない可能性があります。
そこで、顧客マスターデータ管理システムによって、組織で一元管理された顧客データを、必要とするさまざまなシステムが共有するようにすることで、
顧客データのメンテナンスが一箇所になるので、コストがかからないとともに、正しいデータが一箇所に集約されることになります。
さらに、顧客データが散財していると、顧客データの漏洩リスクも、それだけ高くなりますが、一箇所で管理することでセキュリティリスクを抑えることもできます。
さて、DMBOKではマスターデータ管理の仕組（アーキテクチャ）として次の３つをあげています。
- レジストリ
マスターデータ管理システムは、さまざまなシステムのマスターデータを指すインデックス（レジストリ）になる。 - トランザクションハブ
マスターデータ管理システムは、マスターデータのハブとなる。
マスターデータは、マスターデータ管理システムのみに存在し、他のシステムには存在しない。 - 統合アプローチ
レジストリとトランザクションハブのハイブリット。
各システムにあるマスターデータが、マスターデータ管理システムで統合され、他のシステムから利用される。
一つひとつ見ていきましょう。
まず、レジストリですが、マスターデータ管理システムには、マスタデータがどこにあるのかを記録したインデックスが存在し、他のシステムは、それを見て場所を確認し、マスターデータを管理するシステムからマスターデータを取得して利用します。
次に、トランザクションハブですが、顧客マスターデータは、トランザクション管理システムである顧客管理システムにのみに存在し、他のシステムには存在しません。
他のシステムは、顧客管理システムを介して顧客マスターデータを取得します。
最後に統合アプローとですが、これはレジストリとトランザクションハブのハイブリットです。
各システムにあるマスターデータが、マスターデータ管理システムで統合され、他のシステムから利用されます。
顧客管理システムが顧客データの主管システムで、顧客データが変更されると、それが顧客マスターデータ管理システムで統合され、
顧客マスターデータ管理システムの顧客データが、他のシステムに展開されます。
顧客管理システムを顧客データのトランザクションハブとして、顧客管理システムの顧客データを共有することもできますが、顧客管理システムの顧客データは、顧客管理システムの機能に特化した構造になっています。
なので、顧客データを受け取ったシステムは、顧客管理システムの機能に特化した構造を、自分に適した構造に変換して使う必要があります。
顧客管理システムの顧客データの構造を、一旦、顧客マスターデータ管理システムで、さまざまなシステムで使える一般的な構造に変換したい場合は、統合アプローチを適用します。
なので、顧客データの構造の特殊性を鑑みた上で、どちらか選択すればよいと思います。
マスターデータ管理については、記事マスターデータ管理（MDM）も参考にしてください。
【動画】マスターデータ管理
データ統合
ここでは、データをETLを通して統合する方法について詳細にみていきたいと思います。
DMBOKでは、ETLのT、トランスフォーム、変換の例を次のようにあげています。
- フォーマットの変換
例えばEBCDICからASCIIなど技術的なフォマットを変換します。 - 構造の変換
例えば正規化データを非正規化データにするなどデータの構造を変換します。 - 意味的変換
例えばソースデータの性別コードの値0,1,2を、ターゲットデータの性別コードの値FEMAILE、MAILE、NOT PROVIDEDに変えるなど、データの値を変換します。 - 重複排除
データをユニークにする必要がある場合、重複データを排除します。 - 並べ替え
データの順序を変更します。
実際にデータを統合するときは、変換する前にデータをクレンジングしてきれいにして変換するというケースも多くあります。
続いて、統合の方法について見ていきましょう。
DMBOKでは統合の方法について次のように言及しています。
ソースシステムでデータが生成されてからターゲットシステムでデータが利用可能になるまでの時間差をレイテンシといいますが、データ統合を考える場合、レイテンシが高い場合、低い場合、非常に低い場合で、統合の方法を分ける必要があります。
通常、レイテンシが高い場合はバッチ、低い場合はイベント駆動、非常に低い場合はリアルタイムという方法を選択します。
- バッチ
- イベント駆動
- リアルタイム
バッチ
データウェアハウスやデータマート上の分析やレポート作成に必要なデータのように、レイテンシが低い場合、定期的に一定量のデータをまとめて処理するバッチ処理がとられます。
イベント駆動
ソースシステム側に起きたイベントをターゲットシステム側に通知することで、ターゲットシステム側の処理が駆動される形態です。
この場合、ソースシステム側は、ターゲットシステム側の更新を待たずに処理を続行することができます（非同期処理）。
非同期処理によって、ターゲットシステムが利用できない場合でも、ソースシステムが止まったり利用できなることはなく、システム間を疎結合にすることができます。
この例の場合、ソースシステムは、イベントが発生したタイミングで、データをQueue、待ち行列に送り、ターゲットシステムは、Queueからデータを受け取ったタイミングでデータを処理します。
Queueは、ターゲットシステムが活動しているとき、データを送ります。
イベント駆動の実装技術の例としては非同期メッセージングがあります。
非同期メッセージングは、メッセージプロバイダーというサーバー機能が持つキューなどを介してメッセージであるデータをやり取りします。
リアルタイム
例えば、システム間でトランザクション整合性を保持する必要があるなど、ソースシステムとターゲットシステムのデータ間の時間の遅れや相違が許容されない場合は、リアルタイムにデータを同期させる必要があります（同期処理）。
同期処理の場合、ソースシステムが利用できない場合、ターゲットシステムが利用できなる可能性があり、システム間を密結合にします。
この例の場合、ターゲットシステムは、必要なとき、アプリケーションプログラミングインターフェース、APIを介して、ソースシステムからデータを取得しています。
なお、相手にリクエストし、レスポンスを受け取る場合でも、相手にコールバックを渡すことで非同期処理にすることができます。
以上より、データを統合する場合、データの適時性、トランザクション整合性などリアルタイム性を求められる（レイテンシの許容度が非常に低い）場合は、APIなどによるリアルタイム統合、そうでない場合は、システム間を疎結合にするために、非同期メッセージングなどによるイベント駆動による統合を考えるようにします。
【動画】データ統合
データ連携
ここでは、データ連携基盤を通して、データを連携する方法についてみていきたいと思います。
データを連携する仕組は、ポイント・ツー・ポイントとハブ＆スポークに分けることができます。
ポイント・ツー・ポイントは、ネットワークを構成する各ノード（システム）が、他のノードと相互に連携する仕組で、ハブ＆スポークは、ネットワークの中心であるハブになるノードに他のノードが連携する仕組です。
ポイント・ツー・ポイントの場合、比較的小さなシステム群を対象にする場合は問題がありませんが、多数のシステムが同じソースから同じデータを必要とする場合、管理も複雑になるとともに、ネットワーク効率も急速に低下します。
データの共有に３つ以上のシステムが関与する場合、ハブ＆スポークを考える方が管理を簡素化できます。
それに対して、ハブ＆スポークの場合、ハブが過負荷になりやすく、大規模なネットワークの場合にはスケーラビリティの課題が生じることがありますし、ハブが攻撃されると、ネットワーク全体に影響を与える可能性があります。
DMBOKでは、ハブ＆スポークのデータ連携アーキテクチャとして次の２つを紹介しています。
- EAI（Enterprise Application Integration）
企業内における多種多様なコンピュータシステム群や各種ビジネスパッケージ群を有機的に連携する方式や技術のことです。 - ESB（Enterprise Service Bus）
企業内の異なるソフトウェアアプリケーションやサービス間での通信とデータ転送を管理・仲介するための方式や技術のことです。
EAIはハブ・アンド・スポーク型アーキテクチャによるモノリシックな構成であり、ESB ではその構成要素を機能単位に分割し、必要に応じて協調動作するよう分散配置することができます。
データ連携を考える場合、業務パッケージ（ブラックボックスでモノリシックなシステム）間の連携が多く、連携方法も多様な場合、連携機能をカプセル化するために、ESBなどのデータ連携基盤を導入することを考えます。
【動画】データ連携
