PowerAppsにはCommon Data Serviceというサービスがありますが、ほとんどの人に単なるデータベースだと思われがちで、SharePointのカスタムリストやSQLデータベースを選ばれてしまうことがあります。今回はなぜCommon Data Serviceを利用した方が良いかをIT担当者の目線で取り上げてみました。

※2020年11月より、Common Data Service の名前が Microsoft Dataverse になりました。変更内容についてはこちらからご覧ください。

1. ただのデータベースではない

Common Data Serviceで真っ先に思われている誤解が、これはデータベースだと思われていることです。実際にはCommon Data Serviceは、Azure SQL、Blog Storage、Cosmos DBで構成されています。それらが1つのサービスとして提供されており、コンテンツの内容に応じて、自動で振り分けられています。リレーショナルデータベース（RDB）の部分はSQLで動いていますが、添付ファイル等はBLOBストレージに保管されており、データ構成がテーブル（エンティティ）単位で違う監査ログはCosmos DB上に保管されています。つまり、適材適所なのです。

2. SQLを知らなくても使える

Common Data Service上でエンティティ（テーブル）を設計するには従来のようにSQL言語を一切知る必要がありません。テーブル間のリレーションもクリック操作で実装できるため、わざわざ「キー列は・・・」などと考えることもありません。そのため、エンドユーザーでもテーブルを構築することができます。もちろんそうするべきだとお伝えしているわけではなく、ガバナンスは必要ですが、より気軽にエンドユーザーでも簡単なシステムであれば、自部署内で構築してもらうということも可能で、より複雑なことをIT側は集中することができます。

3. パフォーマンスチューニングやインデックス・インフラのセキュリティ等を考える必要がない

Common Data ServiceはPaaSでもIaaSでもなく、SaaS型のサービスです。パフォーマンスチューニングやスケーリング、インデックスなどはすべてマイクロソフトが「いい感じに」してくれるので、IT側での管理は必要ありません。実際に数万・数十万のユーザーが利用しても、Common Data Serviceは何も構成を変更することなく、耐えられます。

4. SQLにすらない、高度なセキュリティ機能を搭載している

Common Data Serviceには、ユーザー・チーム・部署・セキュリティロールとアクセスレベルというセキュリティ機能があります。

データはレコード単位（つまりSQL的には行単位／SharePoint的にはアイテム単位）で「所有者」という概念があります。データの作成者のことです。各ユーザーは部署やチームへ所属することができ、その同じ部署やチームへ所属するユーザーはデータアクセスできるようにする、というような設定も可能です。

部署に関してはさらに特別で、「所有者と同じ部署に所属、またはその部署の配下のすべての部署はアクセス可能」というような高度な設定にも対応しています。

レコードのアクセスレベルは非常に細かく分かれており、以下のレベルが用意されています。

  • 作成：新規でレコードを作る権限
  • 読み取り：レコードを読み取る権限
  • 書き込み：
  • 削除：

ここまでは一般的ですが、ここから4つはCommon Data Serviceにしかない、より便利なセキュリティ機能です。

  • 追加：ほかの関連するエンティティのデータを操作中のデータに関連付けするための権限（親から子へ）
  • 追加先：操作中のデータを他の関連するエンティティのデータへ関連付ける権限（子から親へ）
  • 割り当て：データの所有権を他の人に割り当てる権限
  • 共有：通常アクセスできないユーザーなどに対して例外的に共有できる権限

このアクセスレベルがさらに、以下のくくり設定できるようになっています。

  • 組織全体：ユーザーや部署・チームなどに関係なく、
  • 部署配下：データを所有しているユーザーと同じ部署のユーザー、同じ部署の配下のすべての部署がアクセスできます
  • 部署：データを所有しているユーザーと同じ部署のユーザーがアクセスできます
  • ユーザー：データを所有しているユーザーのみがアクセスできます
  • なし：アクセスできません

上記のように、非常に細かな制御ができるので、例えば人事評価のアプリを作りたいとき、「自己評価の投稿はできても、投稿内容はアクセスできないようにし、同じ部署の上長は閲覧のみにして、フィードバック用のテーブルに書き込めるようにする」といった複雑なシナリオでも対応することができるのです。

5. フォームやビュー、ビジネスルールも設定可能

Common Data Serviceで作成したテーブルには、フォームやビュー・ビジネスルールを関連付けられるようになっています。そのため、エンティティの作成と合わせてこれらのパーツさえ用意してしまえば、PowerAppsの視点で考えると、同じエンティティを利用することになった場合に統一された入力画面や閲覧画面、業務ルールが設定できます。なので、例えば営業部と生産部で同じ「製品マスタ」画面を利用するとなった場合に、それぞれのアプリで作ることなく、共通の画面が利用できるため、さらなる開発コストの削減にもなるわけです。

6. Azureの強力なインフラ基盤で構築されている

Common Data Serviceは「リージョン」を指定するだけで、その裏のインフラはすべて自動で展開されます。実際のインフラアーキテクチャを絵にすると、以下のような図となり、例えば日本リージョンを選べば、東京・埼玉にある東日本リージョンと、大阪にある西日本リージョンでペアリングされ、もちろんそれぞれでバックアップも冗長化も行われます。

7. ソリューション管理が行える

Common Data Serviceにはソリューション管理機能があるため、作成したエンティティ（テーブル）定義はもちろんのこと、その関連するビュー、フォーム、PowerAppsのアプリ、Microsoft Flowをすべて1つのソリューションへとまとめ、エクスポートしたりすることができます。そのため、テスト環境と本番環境にわけて運用したりするときは、そのソリューションさえインポートしてしまえば、そのまま移行することができます。

8. Web APIや、高度な開発にも対応

Common Data Serviceには標準でWeb APIがあり、作成したエンティティはWeb API経由ですぐにアクセスできます。そのため、別途SQLの時のように専用のウェブサーバを立てたりする必要はなく、SDKを利用すれば、高度なカスタマイズもすぐに行えます。

9. ETLのようなデータ統合機能が搭載されている

Common Data Serviceへ他のシステムから連携するのがデータ統合機能です。基幹系の業務システムへ直接参照するのはリスクが大きかったりするので、この機能を利用し、安全に他のシステムのデータを見て、PowerAppsのアプリで2次利用したりすることも可能になります。データ統合機能は「アップサート」という考えがあり、自動で新規データか、更新データかを確認し、差分管理もしてくれます。この機能を利用することで、複数のシステムにバラバラに散らばっていたデータを1つのCommon Data Serviceへ格納し、マスターデータ管理ツールとしても利用できます。

この機能についてはこちらの記事でさらに詳細に記載してます。

10. PowerApps、Microsoft Flow、Power BIへは秒殺で連携

Common Data ServiceはPower Platformのために生まれてきたサービスと言っても過言ではありません。PowerAppsのアプリのデータ保管場所としても、Microsoft Flowでの承認ワークフローの結果の保管場所としても、Power BIのための分析データの保管先としても、すべてノンコーディングで利用できます。

まとめ

Common Data Serviceはまさに、IT担当でもエンドユーザーでも利活用できる、スーパーデータサービスです。

今までのようにサイジング、インストール、デプロイ、構成、最適化、稼働監視、パッチ、アップデート、スケール、可用性、災害対策、バックアップ／リストア、セキュリティ、アクティビティ監査ログ、暗号化、コンプライアンス…と面倒なことは全て任せてしまい、データモデルに集中して、より付加価値の高い業務に時間を割くことができるようになるサービスです！