【Dataverse】テーブル設計ガイドラインを作ってみた
こんにちは。システムソリューション営業本部の吾妻です。
以前の「【Power Platform】オリジナルのコーディング標準を作ろう」シリーズでは、Power Platform製品群を対象とした自社独自のコーディング標準を用意する際に、抑えておくべきポイントについてご紹介しました。
今回は、コーディング標準の分冊として テーブル設計ガイドライン を整備した際に検討した内容について、ご紹介していきたいと思います。
テーブル設計ガイドラインの目的
Power Appsの、特にモデル駆動型アプリでは、データソースとなるDataverseテーブルをいかに設計するかによって、アプリの使いやすさや保守しやすさが大きく変わってきます。
モデル駆動型アプリでDataverseテーブルをもとに実現できる機能については、別の連載でご紹介しています。
Dataverseには、通常のリレーショナルデータベース製品とは異なり、テーブル定義を自由に変更しやすい特徴があります。そのため、「雑な設計」をもとにテーブルを実装しても、後から修正して改善させることはできます。
ただし、当然最初から一定のルールに従って設計・実装した方がスムーズなので、この「一定のルール」を明文化しておき、開発者に読んでもらうことで、テーブルや、それを参照するアプリ実装の属人化を防ぎ、可読性を向上させるというのが、テーブル設計ガイドラインの目的です。
大まかな構成
テーブル設計ガイドラインの構成例として、作成したガイドライン資料から主要な見出しを抜粋してみます。
- 用語定義
- 開発環境
- 命名規約
- テーブル設計の手順
- マスタ設計
- コード設計
- 正規化
- よくあるテーブル構成
それぞれの項目にどのような事柄を記載しているか、具体例を交えつつご紹介していきます。
用語定義、開発環境、命名規約
テーブル設計ガイドラインの中で登場する用語や開発環境、命名規約に関しては、コーディング標準と同様に記載します。
ただし、命名規約については同一の内容で済ますことはできず、アプリ設計で採用する語句の範囲よりもテーブル設計で採用する語句の範囲の方が狭くなるという違いがあります。
例えば、テーブルやカラムで取り扱う情報は静的(static)な状態を表現することが多いので、動詞の単語は使用せず、名詞（句）を使用して定義していきます。
テーブル設計の手順
データベースに格納する対象とするデータ（目的）を定めるところから、エンティティ抽出、正規化、Dataverseテーブルへの反映、…といった設計から実装までの大まかな手順を記載します。
マスタ設計、コード設計
マスタデータとは、複数のサービスから参照されるシステムの基幹情報を指します。
Dataverseテーブルの場合でも、複数のアプリやクラウドフローから参照され、マスタデータを軸に様々な業務情報が管理されることになるので、一元性と一貫性、管理者によるメンテナンスの容易さ、機構改革などの外的要因に対する長期的な安定性といった観点から、慎重に定義する必要があります。
特に、複数の既存システムからマスタデータを抽出・統合すると、同じ単語を違う意味で使っていたり、違う単語を同じ意味で使っていたりするせいでデータの一元管理ができないことがあります。
その場合、 IMI共通語彙基盤 のような標準に従って、語句を整理しておく必要があります（同音異義語／異音同義語）。
また、マスタデータと同様に、コードについても事前の設計が重要となります。コードとは、個々の情報の管理を容易にするために（一般的には）英数文字で設定した別名のことを指します。コードは、システム連携や外部データとの結合を考慮して、既に標準化されているコード（性別、国、都道府県など）や、広く世の中で利用されているコード（郵便番号、法人番号など）になるべく準拠するように設定します。
コードを自分で定義する場合には、コードを人が見てすぐに内容を理解できる有意コードとするのか、UUIDなどの無意コードとするのか、桁数や文字種をどのように設定するかといった事項を検討する必要があります。
また、コードを手入力する作業がある場合や、システム間連携を行う際にユーザーがデータ編集を行うことが想定される場合には、以下の対応も検討します。
- チェックディジットを付加
- 「0」が欠けるのを防ぐために、先頭桁へ必ず0以外の文字を配置（特にユーザーがExcelによって編集し得る場合）
このような対策によって、予期せずデータが欠損したり変更されたりするリスク（欠損したり変更されたりしたことに気が付かないリスク）を減らすことができます。
正規化
テーブルを正規化するための手順を標準化します。サンプルのテーブルを用意しておいて、正規化の途中経過を示しながら解説すると分かりやすいかと思います。
 |
→ |  |
| 非正規形のテーブルの例 | 正規化後のテーブルの例 |
Dataverseの場合もリレーショナルデータベースと同様の手順で正規化します。なので、ここでは具体的な正規化手順は省きます。
ただ、プライマリ名の列（Dataverse）とプライマリキー（リレーショナルデータベース）のように似ているものの考え方が異なる機能や、一対一のリレーションの有無といった差異があるので、整理した上で記載しておく必要があります。
また、一般的なリレーショナルデータベース製品の場合は、テーブルを第3正規形まで正規化した状態で定義することが多いですが、Dataverseテーブルの場合は、データソースに指定するテーブルが1つであればキャンバスアプリを簡単に作成できること（「データで開始する」機能）や、キャンバスアプリやクラウドフローの中でJOIN処理を行うコストが高いことから、あえてテーブルを分割せず（正規化せず）に実装することもあります。
ちなみに、Salesforceなどの他社製品とは異なり、テーブル（オブジェクト）の個数で課金額が変動するライセンス体系ではないので、ライセンス費用を節約するために無理矢理非正規形に崩すようなことをする必要はありません。
よくあるテーブル構成
そのままPower Appsアプリに組み込めるようなテーブルを例示します。
台帳管理、問合せ管理、予定管理といったテーマに分割して用意しておくと良いでしょう。
例えば、備品管理のためのアプリと蔵書管理のためのアプリを作る場合には、備品管理では備品のシリアルナンバーを格納する列が必要で、蔵書管理ではISBNコードを格納する列が必要という差異はありますが、登場人物やテーブル間のリレーションシップ、キー情報（管理通番やGUID）はだいたい同じと考えられるので、「台帳管理」をテーマとしたサンプルテーブルを用意しておけば、どちらにも応用することができます。
サンプルテーブルを増やしすぎると保守するのも大変になるので、登場人物、テーブル間のリレーションシップ、キー情報が大きく異なるものを別のテーマとして切り出します。
例えばリレーションシップに関して、
- 単一テーブルで構成する場合
- 一対多のリレーションシップを含む場合
- 多対多のリレーションシップを含む場合
- 自己参照を含む場合
の4つに区分すると良いかと思います。
 |
| 自己参照（階層的な）テーブルの例 |
まとめ
今回は、テーブル設計ガイドラインを作成する際に、どのような内容を定義し、記載すべきかを具体例を交えてご紹介しました。これからPower Platformを導入しようとしている組織や、既にPower Platformを導入していて今後より市民開発を広げたい組織において、ガイドライン資料やコーディング標準を活用することで、業務改善に繋げていただければ幸いです。
弊社の Power Platform サポート＆アプリカタログサービス では、アプリの提供・開発だけではなく、今回ご紹介したようなガイドラインの策定や、市民開発者コミュニティの運営、ガバナンス管理に対するサポートも積極的に行っています。
市民開発を支える体制を構築したり、運用・監査マニュアル類を一から整備したりするのはなかなか困難ですので、本サービスをご活用いただき、迅速な立ち上げに繋げていただければと考えています。
まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。その他の商標はそれぞれの権利者に帰属します。
