162. Microsoft Fabric のセマンティックモデルを試す
はじめに
前回書いた通り、Digital Twin Builder のチュートリアルが途中で行き詰ってしまいました。現在伝手を辿って、対策を教えてもらおうと動いているところ。しかし、60日間の試用期間は、無慈悲にも進んでいくので、もう一つ気になっているセマンティックモデルを試すこととしました。
この記事が公開されたころには、問題解決しているといいなぁ。。。
セマンティックモデル
2025/11/14 にやっていた、Microsoft Japan 主催の Microsoft Fabric のオンラインセミナーを拝聴しました。AI やるにもダッシュボード作るにも、結局は、セマンティックモデルが基本なんだなと。で、Microsoft Learn の関連記事を見ると、どうも、データベース設計でいうところの ER 図で描くようなモデルっぽい図が散りばめられていました。ER図で描く対象なら、概念モデリングの概念情報モデルの作り方が役立つであろうということ。では、セマンティックモデルに関するチュートリアルをやってみようと考えた訳。
セマンティックモデル vs Digital Twin Builder のモデル
チュートリアルに散りばめられているモデル図を見ると、形式的にはどちらも同じように見えます。じゃぁ何が違うのか、Microsoft Learn の記事を見ても、今一つはっきりしない。
こんな時は、Copilot に聞いてみよう！ということで、早速聞いてみたところ、
結論：Microsoft Fabric の「セマンティックモデル」と「Digital Twin Builder のモデル」は目的と対象が大きく異なります。前者はデータ分析用の論理モデル、後者は現実世界の資産やプロセスを表現する運用モデルです。
ふーん。。。
Microsoft Fabric のセマンティックモデル
目的：
データ分析・可視化のための論理的な枠組み
特徴：
Power BI と統合され、ビジネスに分かりやすい用語やメトリックを定義できる。
通常は スター・スキーマ構造（ファクトテーブル＋ディメンションテーブル）で設計される。
DAX 計算、リレーションシップ、行レベルセキュリティなどを設定可能。
データの一貫性・再利用性を高め、分析者が「売上」「顧客」などの意味づけされたデータを扱える。
なるほど。。。
Digital Twin Builder のモデル
目的：
現実世界の資産・プロセスをデジタルで再現し、運用改善やリアルタイム分析に活用
特徴：
オントロジーモデルを採用し、資産やプロセスを「エンティティ」「リレーションシップ」「プロパティ」として表現。
IoT デバイスやセンサーからのリアルタイムデータを取り込み、物理世界とデジタル世界を橋渡しする。
ローコード／ノーコードで構築可能で、非技術者でも利用しやすい。
Power BI や Real-Time ダッシュボードと連携し、運用スタッフが直接データを探索・分析できる。
へ～。。。
それぞれの使われ方は、それぞれのコンテキストがあるので、そういうものか、で済ませます。セマンティックモデルがビジネス上の概念で意味付けられたモノを扱い、Digital Twin Builder のモデル（あーめんどくせ、以下、”ツインモデル”と呼ぶことにしますね）は、現実世界の資産・プロセスを扱うという違いがあるとのことです。しかしね、結局どちらも、分類、その分類が持つべき特徴値、分類間のリレーションシップで表現するようなので、概念モデリングの概念情報モデルと形式はおなじ。
セマンティックモデルがビジネス上の概念が対象だよということで、ツインモデルとは違って現実世界に存在するモノではないことを強調したいのかもしれないですね。しかし、新実在論からすれば、たとえ思考上にしか無いモノだとしても、それは、ある一つの意味の場上の実在であり、単に対象としている意味の場が異なっているだけだと言える。ほかに、ツインモデルの方は、IoT機器からくるデータは時系列だよねー、それビジネス系違うよねー的なフレーバーがありますが、ビジネス系の売り上げや色々な関連情報も、リアルタイムで時系列的なんじゃないかな。。。
結論としては、概念モデリング的には、セマンティクモデルもツインモデルも、概念情報モデルのモデリングスキルをそのまま使えると言って、問題ないでしょう。ただし、それぞれの意味の場の種類に紐づく環境や機能が異なるので、それに合わせた使い分けが必要ということですね。
スター・スキーマ構造って何？
セマンティクモデルの特徴で出てきた、この用語がわからなかったので、こちらも Copilot で調べてみました。RDB の設計で使われる ER図 と何がちゃうん？
スター・スキーマ構造を提唱したのは、データウェアハウス分野の第一人者である ラルフ・キンボール (Ralph Kimball) です。
データウェアハウス系のお話なんですね。。。
スター・スキーマ構造と**通常の ER 図で描くモデル（エンティティ・リレーションシップモデル）**は、同じ「データ構造」を扱うものですが、目的と設計思想が大きく異なります。整理すると以下のようになります。
ほう、目的と設計思想が大きく異なるのか。。。
スター・スキーマ構造（Star Schema）
目的：
データ分析・集計（BI、データウェアハウス）
中心構造：
ファクトテーブル（売上、取引など数値データを持つ）
ディメンションテーブル（顧客、商品、時間など分析軸を持つ）
特徴：
中心にファクトテーブルがあり、周囲にディメンションテーブルが「星型」に広がる。
正規化は最小限で、クエリ性能と分かりやすさを優先。
分析者が「売上を顧客別・商品別・日付別に集計」といった操作を簡単にできる。
ファクトとディメンション。。。
ER 図で描くモデル（Entity-Relationship Model）
目的：
業務システムのデータ設計（トランザクション処理、業務管理）
中心構造：
エンティティ（実体）（顧客、注文、商品など）
リレーションシップ（関係）（顧客が注文する、注文に商品が含まれるなど）
特徴：
正規化を重視し、データの冗長性を排除。
更新・検索の整合性を保つことが目的。
ER 図は業務データの論理構造を表現するため、分析よりも業務処理の正確さを優先。
要するに、業務システムで扱うデータをリレーショナルセオリーに従って構造化するということ。概念モデリングの用語で置き換えると
ここから先は
IoT・Digital Twins を極めよう！
2022年3月にマイクロソフトの中の人から外の人になった Embedded D. George が、現時点で持っている知識に加えて、頻繁に…
この記事が気に入ったらチップで応援してみませんか？
