@@ -404,7 +404,7 @@ flowchart TD
404404 - 組織内に既にカタログデータが存在している場合は、その利活用を試みる（カタログデータ収集）
405405- 利活用促進
406406 - 共有データを利用するデータコンシューマは、データカタログに登録されている共有データから用途に適合するものを探索し、利用する共有データを特定する（カタログ検索、利用データ特定）
407- - データコンシューマは、特定した共有データのデータオーナーとの間で利用契約を結ぶ 。利用契約が承認された後、データオーナーはデータコンシューマに対して共有データに対するアクセス権限を付与し、データコンシューマは利用を開始する（共有データ利用手続き）
407+ - データコンシューマは、特定した共有データのデータオーナーに対して利用申請をおこない、承認を得る 。利用契約が承認された後、データオーナーはデータコンシューマに対して共有データに対するアクセス権限を付与し、データコンシューマは利用を開始する（共有データ利用手続き）
408408 - 統合したメタデータを外部システムに連携する（メタデータ配信）
409409- ガバナンス強化
410410 - データガバナンス担当者は、データカタログに登録されている共有データを対象に、例えばアクセス権の付与状況、利用契約締結状況、データ品質の観点から分析し、その管理・統制を図る（共有データ監査）
@@ -462,7 +462,7 @@ flowchart TD
462462| データ一貫性 | ✅️データベース構造が分離されるため、システムが疎結合である | ❌️参照するためであるため、メタデータソースの独自仕様の影響を受ける | ⚠️集中型の欠点と分散型の利点を併せ持つ | ✅️集中型の利点を持つ |
463463| 独自メタデータ保有 | ❌️個別メタデータソースから収集のみ。メタデータの品質は関係するソースシステムのみに依存する | ❌️参照するだけであるため、メタデータの品質は関係するソースシステムのみに依存する | ✅️中央側で独自のメタデータ項目を保有可能 | ✅️中央で編集されたメタデータを個別メタデータソースに戻すことが可能 |
464464| 可用性 | ✅️メタデータソースから独立しているため、信頼性が高い | ❌️メタデータソースの信頼性に直接影響を受ける | ⚠️集中型の欠点と分散型の利点を併せ持つ | ✅️集中型と同等の利点を持つ |
465- | メタデータ連携コスト | ❌️ソースメタデータの変更をリポジトリに迅速に反映するために複雑な処理が必要る | ✅️自動化されたメタデータクエリ処理の開発がより簡単になり、手動介入を最小限に抑えることができる | ⚠️集中型の欠点と分散型の利点を併せ持つ | ❌️集中型と同等の欠点を持つ |
465+ | メタデータ連携コスト | ❌️ソースメタデータの変更をリポジトリに迅速に反映するために複雑な処理が必要 | ✅️自動化されたメタデータクエリ処理の開発がより簡単になり、手動介入を最小限に抑えることができる | ⚠️集中型の欠点と分散型の利点を併せ持つ | ❌️集中型と同等の欠点を持つ |
466466| 導入コスト | ❌️拡張部分の保守運用で、負担が増大する懸念。抽出部分が特別対応が必要な可能性 | ✅️独自システムからのメタデータ要求はクエリのみであるため、実装コストは最小限 | ⚠️集中型の欠点と分散型の利点を併せ持つ | ❌️集中型と同等の欠点を持つ |
467467| 維持コスト | ❌️集中型リポジトリの保守運用コストが掛かる | ✅️メタデータのレプリケーションや同期処理が不要でバッチ処理が削減される | ⚠️集中型の欠点と分散型の利点を併せ持つ | ❌️集中型と同等の欠点を持つ |
468468
@@ -590,7 +590,7 @@ flowchart TD
590590- データ基盤には原則、3層のデータモデルを採用する
591591- 原則、データマート層は、ユースケースと1:1で作成する
592592 - リネージを用いた影響度調査を把握しやすくするため、オーナーを明確にするため
593- - データウェアハウス層から直接、BIの接続はNG
593+ - データウェアハウス層から直接、BIの接続は原則、禁止する
594594 - 最低でも、マート層にビューを作成する
595595 - データサイエンティストなど、限られたユーザーのみがアクセスする
596596- もし、スピード最優先とする場合は、レイク層から直接データマート層を作成する
@@ -603,7 +603,7 @@ flowchart TD
603603
604604## ETLとELTの違い
605605
606- ETLとELTは、データウェアハウスやデータレイクにデータを統合するためのプロセスだが、その処理順序やそれぞれメリット/デメリットがある 。
606+ ETLとELTは、データウェアハウスやデータレイクにデータを統合するための主要なプロセスである。しかし、理順序が異なりそれぞれにメリット・デメリットが存在する 。
607607
608608下記表にETLとELTの主な特徴を記載する。
609609
@@ -617,7 +617,7 @@ ETLとELTは、データウェアハウスやデータレイクにデータを
617617| 性能 (分析時) | ✅️ 格納時にデータが最適化済みであるため分析性能を向上させやすい | ⚠️ 変換を伴う分析の場合、処理性能は格納先のエンジン性能に依存する |
618618| 性能 (格納時) | ⚠️ 変換処理を伴うためロードに時間を要する | ✅️ 変換を後回しにするためロード時間を短縮可能 |
619619| 柔軟性 (分析ニーズ) | ❌️ 事前に定義した変換に縛られ、多様な分析への即時対応は困難 | ✅️ 未加工データを保持するため、後から多様な分析要件に柔軟に対応可能 |
620- | 柔軟性 (ソース追加) | ❌️ 新規データソースごとに変換ロジックの設計・開発が必要 | ✅️ とりあえずデータをロードできるため 、比較的迅速な対応が可能 |
620+ | 柔軟性 (ソース追加) | ❌️ 新規データソースごとに変換ロジックの設計・開発が必要 | ✅️ 変換処理を経ずにデータをロードできるため 、比較的迅速な対応が可能 |
621621| 保守性 | ⚠️ 変換ロジックの開発・変更に専門知識と工数を要する | ⚠️ 開発は後回しにできるが、変換ロジック開発にはETLと同等の作業が発生 |
622622| インフラ (処理リソース) | ❌️ DWH/データレイク外に専用のETL処理サーバが必要となることが多い | ✅️ 格納先(DWH/データレイク)のコンピューティングリソースを活用できる |
623623| インフラ (ストレージ) | ✅️ 必要なデータのみ格納するため、ストレージ効率が良い | ❌️ 未加工の生データをそのまま格納するため、大容量のストレージが必要となる |
@@ -642,16 +642,16 @@ ETLとELTは、データウェアハウスやデータレイクにデータを
642642- 柔軟性と適応性
643643 - 変化するビジネス要件やデータソースに柔軟に対応できる、俊敏性の高いデータ統合を実現する
644644- データソースとデータウェアハウスの直接的な統合
645- - Change Data Capture（ CDC)という技術を用いることで、データソースで変更があったデータを、リアルタイムに近い形でデータウェアハウス等に転送し統合する
645+ - Change Data Capture( CDC) という技術を用いることで、データソースで変更があったデータを、リアルタイムに近い形でデータウェアハウス等に転送し統合する
646646
647647ゼロETLの利点は以下の通り。
648648
649649- 開発・メンテナンスの簡素化
650- - ETLパイプラインの構築・管理にかかる時間とコストを削減しやすい
650+ - ETLパイプラインの構築・管理にかかる時間とコストの削減が期待できる
651651- リアルタイム分析の実現
652- - 最新のデータを迅速に分析に利用でき、ビジネス上の意思決定を加速しやすい
652+ - 最新データを迅速に分析利用することで、ビジネス上の意思決定を加速できる可能性がある
653653- データ活用の促進
654- - データ統合の障壁を下げることで、より多くのユーザーがデータにアクセスし、活用できるようしやすい
654+ - データ統合の障壁を下げることで、より多くのユーザーによるデータアクセスと活用を促進する
655655
656656ゼロETLの適用が難しいケースは以下の通り。
657657
@@ -744,7 +744,7 @@ MDMシステムの実装手段にも「スクラッチ型」 「SaaS型」 「
744744推奨は以下の通り。
745745
746746- SaaS型の導入することを推奨する
747- - MDMシステムは組織のデータ特性やIT戦略、予算などを加味して選定することになるが、ビジネスのコアではないことから 、導入期間と導入コスト・運用コストの観点を重視する
747+ - MDMシステムは組織のデータ特性やIT戦略、予算などを加味して選定することになるが、バックオフィスシステムと同様に、効率性やコストが重視される傾向があるため 、導入期間と導入コスト・運用コストの観点を重視する
748748- SaaS型導入後、MDMシステムに対する要件の変化に応じて、ハイブリッド型に移行を検討する
749749
750750## マスタデータ管理プロセス
@@ -754,34 +754,34 @@ MDMシステム導入後のマスタデータを管理するプロセスの全
754754![ ] ( images/mdm_process.drawio.png )
755755
7567561 . データモデル管理
757- - 組織内で統一されたマスタの粒度・属性を定義する
757+ 1 . 組織内で統一されたマスタの粒度・属性を定義する
7587582 . データ取得
759- - マスタの管理者を定める
760- - マスタ値の取得元を定める
761- - マスタ値を入力する
759+ 1 . マスタの管理者を定める
760+ 2 . マスタ値の取得元を定める
761+ 3 . マスタ値を入力する
7627623 . データ検証
763- - 入力されたデータの品質を確認して保証する
764- - サービス性向上のための属性を追加する
763+ 1 . 入力されたデータの品質を確認して保証する
764+ 2 . サービス性向上のための属性を追加する
7657654 . エンティティ解決（名寄せ）
766- - エンティティを解決する
767- - エンティティのID体系を確立する
766+ 1 . エンティティを解決する
767+ 2 . エンティティのID体系を確立する
7687685 . データ共有
769- - マスタデータの共有を開始する
769+ 1 . マスタデータの共有を開始する
7707706 . データ運用
771- - マスタデータの変更を管理する
772- - マスタデータの移動を監視する
771+ 1 . マスタデータの変更を管理する
772+ 2 . マスタデータの移動を監視する
773773
774- 「4.a. エンティティを解決する」では、「名前は同じだがメールアドレスが異なる」 「メールアドレスは同じだがクレジットカード番号が異なる」など、実世界に存在する実体に対して複数の参照があった際、それらを別のレコード（エンティティ）として管理するのか、同じレコード（エンティティ）として管理するのかを解決する意思決定を行う。
774+ 「4.1 エンティティを解決する」では、「名前は同じだがメールアドレスが異なる」 「メールアドレスは同じだがクレジットカード番号が異なる」など、実世界に存在する実体に対して複数の参照があった際、それらを別のレコード（エンティティ）として管理するのか、同じレコード（エンティティ）として管理するのかを解決する意思決定を行う。
775775
776776以下、プロセスごとに考慮しておいたほうがよいであろうポイントを列記する。
777777
778- - 1.a. 組織内で統一されたマスタの粒度・属性を定義する
778+ - 1.1 組織内で統一されたマスタの粒度・属性を定義する
779779 - ここで定義する粒度・属性は組織全体で意味をなす必要があるため、個別の用途に引きずられないよう注意を払う
780- - 3.a. 入力されたデータの品質を確認して保証する
780+ - 3.1 入力されたデータの品質を確認して保証する
781781 - データに一貫性を持たせるために、データの欠落、フォーマットの誤りなどがあれば、この段階で検証・修正し、データの品質を保証する
782- - 6.a. マスタデータの変更を管理する
782+ - 6.1 マスタデータの変更を管理する
783783 - 参照されるマスタデータは共有リソースであるため、共有を開始する前に、変更時のルールを定める
784- - 6.a. マスタデータの移動を監視する
784+ - 6.2 マスタデータの移動を監視する
785785 - マスタデータに誤りがあった場合に備え、組織内でマスタデータがどのように利用されているのか（リネージ）を把握する
786786
787787なお、マスタデータ管理においてもガバナンスの取り組みは不可欠で、これがなければ単にMDMシステムを導入するだけに終わってしまうこと（利用・用途が広がらない）について、留意する必要がある。
@@ -820,7 +820,7 @@ ISO/IEC・DMBOK版のどちらの評価基準を採用するかという話で
820820 - エンタープライズデータモデリングによる組織全体の論理名、物理名の統一や、データが理解、分析しやすいように区分値の説明やデータカタログで補足説明があるかという点
821821 - データアーキテクチャ（レイク層からDWH層へ連携時の正規化）や、データカタログの章と重複
822822
823- また、以下の項目については、本ガイドラインの議論の対象外とする 。
823+ また、以下の観点については、本ガイドラインの主なスコープ外とし、基本的には連携元システムで品質が担保されていることを前提として議論を進める。ただし、実際のデータ基盤構築・運用においては、連携元のデータ品質についても評価・確認が必要となる場合があることに留意すべきである 。
824824
825825- 正確性
826826 - 「顧客の年齢が実際の年齢と一致しているか」 「測定機器で計測された数値が実際の物理量を正確に表している」といった入力精度のもっともらしさについては、連携元システムで考慮、担保されているとする
@@ -837,7 +837,7 @@ ISO/IEC・DMBOK版のどちらの評価基準を採用するかという話で
837837 - 連携元システムで考慮、担保されているとする
838838- 標準適合性
839839 - 「月日が西暦ではなく和暦で表記されている」などの観点
840- - 連携元システムで考慮、担保されているとする。もしシステム間で統制が取れていない場合は、DWH層への登録時に正規化する
840+ - 連携元システムで考慮、担保されているとする。もしシステム間で統制が取れていない場合は、データ基盤側（DWH層）での正規化対応が必要となる可能性があるが、その具体的な変換ロジックは本章の主たる議論の対象外とする
841841- 効率性
842842 - 「データに全角と半角が混在するなど、データとデータを結び付ける際に正規化が必要となる」などの観点
843843 - 連携元システムで考慮、担保されているとする
0 commit comments