アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
機能拡張サービス
X-SP Feature
デザイン拡張サービス
X-SP Design
モダン化から運用管理までサポート
構築支援サービス
前回は「商品」テーブルに「列」を追加しながら、列ごとに適したデータ型や選択肢について解説しました。
第3回となる今回は、Dataverseで最も魅力的な機能の一つ、「リレーションシップ（テーブル間の関連付け）」についての解説となります。
例えばExcelでデータを管理していると、「商品一覧」と「注文一覧」が別々のシートにあって、それをVLOOKUP関数で繋げたりすることも多いのではないでしょうか？
Dataverseではこれを、「リレーションシップ」という機能を使うことで、より簡単に、より堅牢に実現することができます！
今回は、前回作成した「商品」テーブルを使って、「注文」や「顧客」などのデータを紐付けるハンズオンを行っていきます！
弊社はPower Platform（Power Apps・Power Automate）に関するアプリ開発や、
皆様が内製化を行う際の支援サービスを提供しておりますので、
Power
Platformに関する内容でお悩みがある場合は、以下からぜひお問い合わせください。
そもそも「リレーション」とは？
Dataverseや一般的なデータベースでは、すべての情報を1つのテーブル（表）にまとめるのではなく、「情報の種類ごとに別々のテーブルに分けて」管理し、それらを「関連付け（リレーション）」して使うのが基本となります。
一見すると「なるべく多くの情報を1つのテーブルにまとめた方が、パッと見やすくていいのでは？」と思うかもしれません。
例として、「注文管理」を考えてみましょう。
1つの表で管理する方法（Excel的なアプローチ）
すべての情報を1つの表にベタ打ちした場合です。
| 注文日 | 顧客名 | 顧客住所 | 商品名 | 単価 | 数量 |
|---|---|---|---|---|---|
| 4/1 | 山田 太郎 | 東京都港区… | ノートPC | 100,000 | 1 |
| 4/2 | 鈴木 次郎 | 大阪府大阪市… | マウス | 2,000 | 2 |
| 4/3 | 山田 太郎 | 東京都港区… | マウス | 2,000 | 1 |
この方法にはいくつか問題があります。
- 入力が面倒・ミスが増える: 同じマウスが注文されるたびに、毎回同じ「商品名」や「単価」を入力しなおす必要があります。入力者によって「商品名」の表記ゆれが起きるかもしれないですし、「単価」の入力ミスは一大事になってしまいます。
- 変更が大変: もし商品名を変更した場合、 過去の注文データの「商品名」をすべて書き換える必要があります。
テーブルを分けてリレーションする方法（データベース的なアプローチ）
Dataverseや一般的なデータベースではこれらの問題を、「商品」、「注文」、「顧客」といった別々のテーブルに分けることで解決します。
A. 商品テーブル（商品情報を一元管理）
| ID | 商品名 | 単価 |
|---|---|---|
| 001 | ノートPC | 100,000 |
| 002 | マウス | 2,000 |
B. 顧客テーブル（顧客情報を一元管理）
| ID | 顧客名 | 顧客住所 |
|---|---|---|
| 001 | 山田 太郎 | 東京都港区… |
| 002 | 鈴木 次郎 | 大阪府大阪市… |
C. 注文テーブル（商品や顧客はIDで指名するだけ）
| 注文日 | 顧客（ここで紐付け！） | 商品（ここで紐付け！） | 数量 |
|---|---|---|---|
| 4/1 | 001（山田さん） | 001（ノートPC） | 1 |
| 4/2 | 002（鈴木さん） | 002（マウス） | 2 |
| 4/3 | 001（山田さん） | 002（マウス） | 1 |
「注文テーブル」には「山田さん（ID: 001）」や「マウス（ID:002）」という情報だけが記録されている構成となります。
こういった構成にすると、もし商品名が変更されても「商品テーブル」の商品名を1か所直すだけで、注文テーブルのすべてのデータに変更後の商品名を反映することができます。
この「テーブルとテーブルをIDで繋ぐ仕組み」こそがリレーションシップであり、Dataverseを活用するうえで一番重要な機能の一つとなります。
適切にリレーションを作成してあげることで、システム内の各データの矛盾や重複を自動的に防ぎつつ、システム全体のパフォーマンスも最適化することが可能になります！
データベースの基本となる非常に重要な機能ですが、Dataverseでは簡単な操作でリレーションを作成することができます！
さっそく試してみましょう！
ハンズオン：1対多（1:N）を作成しよう
まずはリレーションの基本となる「1対多（1:N）」のリレーションシップを作成してみましょう！
1対多のイメージとしては、
「1人の顧客（1）」が「複数の注文をする（多）」というケースは一般的だと思いますが、
「1つの注文（1）」に「複数の顧客が紐づいている（多）」というケースは通常ないかと思われます。
そのため「顧客（1）」、「注文（多）」としてリレーションを設定していくことになります。
図として整理すると以下のようなイメージですね！
Tips：画像のように、システム内のテーブルとリレーション関係をまとめたものをER図と呼びます。
まずは紐付け先となる「顧客」テーブルと「注文」テーブルが必要ですね。
テーブルの作り方や列の追加については、それぞれ第1回と第2回にて解説していますので、詳細はそちらを参考にしていただきながら作ってみてください。
1. 「顧客（Customer）」テーブルの作成
-
表示名: 顧客
-
複数形: 顧客
-
プライマリ列: 顧客名
-
スキーマ名: Customer
-
所有権: ユーザーまたはチーム（各営業担当が顧客情報を管理する想定です）
今回のハンズオンでは、列はプライマリ列（顧客名）だけで進めていきます。
2. 「注文（Order）」テーブルの作成
-
表示名: 注文
-
複数形: 注文
-
プライマリ列: 注文番号
-
スキーマ名: Order
-
所有権: ユーザーまたはチーム
また、注文テーブルには「注文日」を格納する日付列を追加しましょう。
-
表示名: 注文日
-
データの種類: 日付と時刻
-
必須: 必須
-
タイムゾーンの調整: ユーザーローカル
-
スキーマ名: OrderDate
3. 注文テーブルに「顧客」への検索列を追加する
ここからがリレーションの設定手順になります！
今回は「1対多」という関係性のリレーションを作っていきます。
「注文」テーブルに、「どの顧客からの注文なのか」を記録するための列を追加します。
これには「検索（Lookup）」というデータ型を使用します。
「注文」テーブルの列の追加画面で、以下のように設定してください。
-
表示名: 顧客
-
データの種類: 検索
-
関連テーブル: 顧客（先ほど作成した顧客テーブルを選択）
-
-
スキーマ名: CustomerId
-
リレーションシップ名: order_CustomerId（自動生成されますが、簡潔で分かりやすい名前を付けておきましょう）
上記のように設定して保存するだけで、「注文（多）対 顧客（1）」のリレーションシップが完成しました！
ポイント：リレーションの方向
「1対多」を作る時は、「多」の方のテーブルに「1」の方への検索列を追加すると覚えるとスムーズです！
（今回であれば、「注文（多）」テーブルに、「顧客（1）」への検索列を追加したことになります。）
ハンズオン：多対多（N:N）を理解しよう
次はもう少し複雑なケースになります！
次は注文と商品のリレーションを作成するために、先ほどと同じようにテーブル間の関係を整理してみましょう。
すると、
「1つの注文（1）」に「複数の商品が含まれている（多）」というケースは考えられますし、
「1つの商品（1）」が「複数の注文に紐づいている（多）」というケースも当然あり得ると思います。
このように、どちらのテーブルも多の側になりえる関係を、「多対多（N:N）」の関係と呼びます。
実は、Dataverseにも標準で「多対多」のリレーションを作る機能もあるのですが、
実際のシステムでは2つのテーブルの間に「中間テーブル」を設けて、双方のテーブルに1対多のリレーションを作成することで疑似的に「多対多」のリレーションを実現する設計が推奨されています。
そこで今回は「注文明細（Order Detail）」という中間テーブルを作成して、多対多のリレーションを実現していきます！
ER図にすると以下の通りです！
Tips
標準の多対多リレーションが推奨されない理由はいくつかあるのですが、代表的なのは「紐づけに対する付加情報」を持たせられない点でしょうか。
例えば標準の多対多のリレーションでは「注文と商品」を紐づけることはできるものの、「この注文でその商品を何個注文した」といった「数量」などの情報は持つことができなくなってしまいます。
その他にも、多対多のリレーションには保守性やパフォーマンスの面などでも難点があり、標準の多対多リレーションは利用しないことが推奨されています。
1. 「注文明細」テーブルの作成
注文と商品を繋ぐための専用テーブルです。
-
表示名: 注文明細
-
プライマリ列: 明細番号
-
スキーマ名: OrderDetail
2. 2つの検索列を追加する
このテーブルに、2つの検索列を追加します。
① 注文へのリンク
-
表示名: 注文
-
データの種類: 検索
-
関連するテーブル: 注文
-
-
スキーマ名: OrderId
② 商品へのリンク
-
表示名: 商品
-
データの種類: 検索
-
関連するテーブル: 商品
-
-
スキーマ名: ProductId
3. 数量列を追加する
最後に、何個買ったかを記録する列を追加します。
-
表示名: 数量
-
データの種類: 整数
-
スキーマ名: Quantity
以上で完成です！
一度、これまでに作成したテーブルとリレーションの関係をER図に整理してみると、以下のようになりますね！
このように1つのテーブルではなく、複数のテーブルに分割してリレーションを設定することで、
「山田さんという顧客からの注文Aには、商品Xが2個、商品Yが1個含まれる」といった柔軟なデータ管理が可能になります！
リレーションの動作設定について
リレーションシップの作成は以上の手順で完了なのですが、システムに組み込むときに重要な設定として「動作」という項目があります。
これは例えば、商品テーブルのような親（1側）のレコードが削除されたり割り当て変更されたりした時に、注文明細テーブルのような子（多側）のレコードはどうするのか、という設定です。
まずはテーブルの設定画面より、「スキーマ」→「リレーションシップ」をクリックします。
すると、テーブルに含まれるリレーションシップの一覧が表示されます。
その中から「動作」を設定したいリレーションシップ、今回は「商品テーブル」をクリックしてみましょう。
画面右側に設定メニューが開かれるのですが、その中の「詳細オプション」→「関連付け動作」から動作の設定が可能です！
設定には「動作の種類」や「削除」などの項目があり、各設定の詳細な挙動については公式ドキュメントを参照いただければと思いますが、
基本的には以下の3つから選択していただければ問題ないと思われます！
参照：リンクの削除
親となるレコードが削除された場合も子レコードは削除されず、リンクが切れた状態となります。
例として、取り扱いが終了した商品を商品テーブルから削除することは想定されると思いますが、
併せて注文明細テーブルから関連する過去のレコードまで削除されてしまうと、売り上げの計算などが合わなくなる、といった影響が考えられます。
そういった場合は「参照：リンクの削除」を設定することで、商品データの削除は許可しつつ、注文データへの影響を少なくすることが可能となります。
参照：制限
子レコードが存在する限り、親レコードも削除することができない制限がかかります。
例えば、顧客テーブルと注文テーブル間のリレーションに「参照：制限」を設定することで、一度でも注文をしたことのある顧客は削除することができなくなります。
どうしても顧客レコードの削除が必要な場合は、事前に注文テーブルから関連するレコードをすべて削除しないといけない、といったステップが必要になるので、手順は煩雑になりますが、ミスによる削除を強く防ぐことができます。
今回の顧客テーブルのような、操作ミスや判断ミスなどで削除されると取り返しのつかない、重要性の高いテーブルのリレーションに適した設定となります。
親子
親レコードが削除されたとき、子レコードも自動的に削除されます。
この設定のユースケースとしては、注文テーブルと注文明細テーブルのリレーションが想定されるでしょう。
もし注文のキャンセルなどで注文テーブルからレコードが削除されたとき、関連する注文明細のレコードだけが残っていても意味がありません。
むしろ、注文明細テーブルに意味のないレコードが残ってしまうことから、検索速度などのパフォーマンスに悪い影響を与えてしまう可能性も考えられます。
このようなリレーションに対しては「親子」の動作を設定することで、
注文テーブルの削除に応じて注文明細テーブルでも自動的に関連レコードが削除され、効率的にパフォーマンスを最適化することができます。
先ほどのER図に合わせてみると、以下のようになりますね。
このように、「リレーションの動作」をテーブルやリレーションごとの要件に合わせて設定してあげることで、意図しないデータの削除を防ぎつつ、効率的なデータの管理を実現することが可能になります！
ちなみに、SharePointの参照列における動作については、過去に以下のブログでご紹介していますので、 こちらもご参考ください！
SharePoint運用Tips：選択肢・参照列の一覧を更新・削除したらどうなる？ 参照列編
今回を機に、SharePointの設定を改めて見直してみるのも良いのではないでしょうか！
おわり
今回はDataverseにおけるリレーションシップについての解説でした。
改めておさらいすると、以下の通りです！
-
リレーション
-
1対多
→「多」のテーブルに検索列を追加する。 -
多対多
→「中間テーブル」を作って、2つの1対多で表現する。
-
-
動作
-
参照：リンクの削除
→親レコードの削除は許可するが、子レコードは残す。 -
参照：制限
→子レコードが存在する限り、親レコードの削除は許可しない。 -
親子
→親レコードが削除されたら、子レコードも一緒に削除する。
-
これで、商品、顧客、注文、注文明細というテーブルの作成と、
各テーブル間のリレーションが設定され、業務アプリとして利用できるようなデータ構造が出来上がってきました！
次回は、テーブル内のデータの整合性を保つための重要な機能「キー設定（代替キー）」について解説します。
「同じ商品コードを登録できないようにしたい！」といった要望に応える機能ですので、ぜひ続けてご覧ください。
それでは！
【こちらも合わせて読みたい】
こんにちは。アーティサン株式会社の伊礼（いれい）です。