はじめに

私見を述べます。

既定のセマンティックモデルとカスタムセマンティックモデル

現在、Power BI にはセマンティックモデルの機能がありますが、Fabric の登場により既定のセマンティックモデル（デフォルトセマンティックモデルとも呼ばれます）が登場しました。

Power BI Service のころから存在する セマンティックモデル
（以下、区別のため カスタムセマンティックモデル と表記します）

Fabric で登場した 既定のセマンティックモデル

それぞれの機能的な違い

既定のセマンティックモデルの機能は限定的です。データモデルをカスタマイズし、BI レポートのためのモデルを作成する場合は、カスタムセマンティックモデルを選択すべきでしょう。

機能	カスタムセマンティックモデル	既定のセマンティックモデル
開発ツール	Power BI Desktop, Tabular Editor など	Fabric Portal 画面のみ
モデル上のテーブルの基になるもの	Power Query のクエリ	ウェアハウスと SQL 分析エンドポイントのテーブル、View
ストレージモード	Import / DirectQuery / Direct Lake*	Direct Lake*
データソースへの認証	クラウド接続で定義（参考）	シングルサインオンのみ
表示名の設定	可能	不可
セマンティックモデルの RLS	可能	不可
計算列および計算テーブル	可能**	不可（Direct Lake の制限に準拠）

* Direct Lake のソースが View である場合や、データ量制限を超える場合などは Direct Query にフォールバックされます。
** Direct Lake モードの場合、現時点では不可

どう付き合っていくべきか？

まず、セマンティックモデルとは何かを考えます。

Microsoft Fabric では、Power BI セマンティックモデルは、分析ドメインの論理的記述であり、メトリック、ビジネスにわかりやすい用語、および表現によって、より深い分析を可能にします。
引用：https://learn.microsoft.com/ja-jp/fabric/data-warehouse/semantic-models

このように、セマンティックモデルはデータ利用者に物理的なテーブルデータだけでなく、ドメイン知識やロジックが付与された情報を提供する役割を持ちます。

Power BI はこれまで、カスタムセマンティックモデルにより、多言語や馴染みのある論理名でのメジャーや集計軸を提供することで、利用者がデータベースの物理的な前提情報なしに自身のドメイン知識を基にした分析を行い、セルフサービスからエンタープライズ領域までをカバーするコラボレーティブな BI を実現してきました。

引用：https://www.microsoft.com/ja-jp/power-platform/products/power-bi?msockid=26e65972aa38684b2b8a4d9aab1a694e#tabs-pill-bar-ocb9d418_tab1

Fabric が登場し、レイクハウスとウェアハウスと呼ばれる分析データストアが、既定のセマンティックモデルとともに提供されるようになりました。

レイクハウスとウェアハウスは OneLake 上のデータを構造化し、SQL分析 やノートブックによる データレイク分析 を提供します。

OneLake 内のレイクハウス/ウェアハウスフォルダに保管されたデータを SQL 分析のためのアーキテクチャ

引用：https://blog.fabric.microsoft.com/en-US/blog/lakehouse-vs-data-warehouse-deep-dive-into-use-cases-differences-and-architecture-designs/

通常、DWH / データレイクなどの分析データストアを使った分析は物理名を使って行われますが、提供されたデータストア上で分析者がテーブルを組み合わせ、活用するためにはリレーションシップの情報が必要不可欠です。

既定のセマンティックモデルが提供する主な機能は、カスタムセマンティックモデルと比べると最低限ですが、ビジネスロジックの記述とリレーションシップの設定が可能なので、分析データストアの意味を理解するために十分な役割を果たします。

つまり、既定のセマンティックモデルはレイクハウスやウェアハウスなど、構造化されたテーブル群（データセット）を説明するためのドキュメントとして活用できます。

既定のセマンティックモデルの利点

レイクハウス（SQL分析エンドポイント）とウェアハウスに対して、グラフィカルな ER 図を提供

リレーショナルモデルが視覚化されます。

また、テーブルに T-SQL で外部キー制約を設定すると、自動的にリレーションシップが有効になります。

sql


CREATE TABLE ForeignKeyReferenceTable (c1 INT NOT NULL);

ALTER TABLE ForeignKeyReferenceTable ADD CONSTRAINT PK_ForeignKeyReferenceTable PRIMARY KEY NONCLUSTERED (c1) NOT ENFORCED;

CREATE TABLE ForeignKeyTable (c1 INT NOT NULL, c2 INT);

ALTER TABLE ForeignKeyTable ADD CONSTRAINT FK_ForeignKeyTablec1 FOREIGN KEY (c1) REFERENCES ForeignKeyReferenceTable (c1) NOT ENFORCED;

自動的に Direct Lake テーブルを追加可能

既定のセマンティックモデルは Direct Lake で構成されるため、最新のレイクハウス、ウェアハウスのテーブルを探索できます。モデルの同期設定をすることで、レイクハウスとウェアハウスのテーブルが自動的に可視化可能な状態になります。

データフロー Gen2 にリレーションシップが継承される

既定のセマンティックモデルで設定したリレーションシップが、データフロー Gen2 のクエリでマージによって表現され、クエリのステップを簡略化できます。

まとめ

既定のセマンティックモデルは、ウェアハウスやレイクハウスのテーブルを準備するだけではなく、ビジネスユーザーにとって直感的に使いやすい分析環境を提供します。これにより、データの理解が進み、効果的な意思決定が可能になります。

余談：Synapse Analytics の Lake データベース - データベースデザイナー

Fabric の登場以前の Microsoft 純正の分析ソリューションといえば Azure Synapse Analytics でした。

その機能の一つに Lake データベースがあります。

引用：https://www.slideshare.net/slideshow/synapse-lakedatabase/251249646#7

Azure Synapse Analytics の Lake データベースを使用すると、データベースのデザイン、格納されているデータに関するメタ情報、データを格納する方法と場所を記述できる可能性をまとめることができます。
レイクデータベースでは、データがどのように構造化されているかを理解するのが難しいという今日のデータレイクの課題に対処しています。

引用：https://learn.microsoft.com/ja-jp/azure/synapse-analytics/database-designer/concepts-lake-database

他の Synapse 機能が Delta Lake に対応している一方で、レイクデータベースは csv, parquet 限定などの制約があり、レイクハウス型ではなく、ピュアなデータレイクのための機能という位置づけにありましたが、テンプレートによる業界向けデータモデルの提供や、データベースデザイナーによる ER 表現の設定機能など、先進的なものでした。

このころから、レイクセントリックな分析環境を活用する上でのドメイン知識とデータストアの構成の連動が重視されていたように思います。