163. Microsoft Fabric のセマンティックモデルを試す ～ その2.

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

今回は、まず、セマンティックモデルを実際に使う、

レイクハウスのエンドツーエンド シナリオ: 概要とアーキテクチャ - Microsoft Fabric | Microsoft Learn

というチュートリアルの内容を確認することにします。

チュートリアルの内容

まずはどんなシナリオなのかを確認します。

シナリオ

なるほど。個人的には、日本でどのぐらい、この”従来”の状況になっている企業が存在するのか興味のあるところ。
ちなみに、以前どこかで書いたように、組織ごとにデータ管理をすれば、原理的にサイロ化するのは当たり前だし、サイロ化＝ある意味の場に特化したデータモデル、という意味合いでは、そうでなければ、その組織にとって使い物にはならない、実質的には組織の誰も使っていないデータであろうということ。なのでサイロ化の問題とは、そのデータの質、内容ではなく、データ管理システムが、組織外のシステムと簡単に接続・参照ができない、というのが本質のはずで、それを Microsoft Fabric の機能で何とかしようということだろうね。

また、組織が違うというのは、担当している意味の場が異なる（生産、開発、営業、財務、総務、人事など）か、意味の場は同じだが、圏I を分割しているかのどちらかを意味することになる。

意味の場が異なれば、たとえ同じモノ（機器とビジネスエンティティの両方）が同じでも、意味・意義が異なる（モノの間の意味的つながりはそれぞれの意味の場で異なる）ので、それぞれの組織が管理・保持しているデータの対象が同一であっても、それは当たり前のこと。データ統合をする際には、同一の対象を指すデータ項目を、（セマンティックモデル？の）テーブル等を新たに作成して、対応関係を記述すればよい。データ重複で問題になりそうなのは、本来はそれぞれの意味の場で記述するべきモノの特徴値が、別の意味の場のモデルに混入してしまう状況でしょう。Shlaer-Mellor 法では、このような状況を”Domain Pollution（ドメイン汚染）”と言っていました。汚染があると、本来はどちらか一方の意味の場がデータソース（担当組織の業務活動からその特徴値の値が決まること）で、そちら側だけで更新をすれば済むものを、別の意味の場のデータ側も更新しなければならないという二重性が生じてしまう。こんな時は、対応付けは、モノのアイデンティティ間の関係を保持するだけで、必要な時に、その対応性を辿って参照すれば、データ重複の問題は解決する。
組織間で同じ意味の場の圏Iのモデルを分割している場合は、素直に、同じ意味の場を分割・共有している組織間で、データ管理システムを共有化するのが、解決策なのではないだろうか。
この手のケースで、各組織に（ある意味）有能でぶっ飛んだ社員がいると、それぞれ勝手に、素敵なシステムを構築しちゃったりする場合もあるんだけど、それも、サイロ化、データ重複の原因でしょうね。

Microsoft Fabric を使う・使わないにかかわらず、データウェアハウスの構築・改修を行う場合には、ここに書いた話を参考にしてもらえればありがたい。

さて、チュートリアルでは、Microsoft Fabric の柔軟性を利用して、

をやるとのこと。
ちなみに、”メダリオン アーキテクチャ”という用語が出てきますが、こちらも Microsoft Learn に説明があったので紹介しておきます。

それぞれのレイヤーは、

とのこと。概念モデリング的には、それぞれのレイヤーは、それぞれ”意味の場”だと考えます。
6. ドメインとITシステム構築｜Knowledge & Experience
では、ドメインについて簡単に解説を行っていますが、具体的な種類や分類については言及していないので、とっても参考になります。
前回の記事で言及した観点からすると、