最初にPower Appsで使えるデータベースの比較や、データ型についても解説した後、今回作る家事管理アプリのデータベース設計について解説するよ。
この記事では、Power Appsのアプリ設計について、以下の解説をしていきます。
- Power Appsで使えるデータソースの比較
- データ型とは何か？
- データベース設計の方法
Power Appsのアプリ設計の前半は、以下の記事を参考にしてください。
YouTube動画で見たいかたは、こちらからどうぞ！
PowerAppsで使えるデータベースの種類
PowerAppsで使える主なデータソースを比較してみます。
- Excel Online、SharePointリスト、Dataverse for teamsはOffice365ライセンスを持っていれば無料で使える
- Dataverseは追加のライセンス購入が必要
Excel Online
多くの人が馴染みあるツールとして、Excelをデータベースとして使うことができます。
しかしExcelの場合、委任処理がほとんどできないという、大きな問題があります。
委任処理は、アプリで実装したデータベースの絞り込み等をする関数の実行を、データベース側で行うことです。
例えばPower AppsでSearchやFilter等の関数を使って、絞り込んだデータを表示したいときがあります。
このとき全てのデータ処理をPower Apps側で行うと、アプリ側の負荷が大きく、動作も遅くなってしまいます。
委任処理を使うと、データベース側で関数の実行による絞り込み処理をしてもらい、絞り込んだ結果をPower Appsに渡すことができます。
Excelではこの委任処理が一切できないため、全てPower Apps側でデータの処理をすることになります。
Power Appsで一度に扱えるデータ数の上限は2,000件のため、Excelではデータソースとして実質2,000件までしか扱えません。
※アプリ側での関数処理の結果、2,000レコード以内になる場合も、データソースからは2,000レコードまでしかデータが渡されない
委任処理がほとんどできないと、正直データソースとしては貧弱で、Excelはあまり利用候補にはならないと思います。
Excel Onlineは委任処理がほとんどできないため、データソースとして利用するには少し貧弱である
SharePointリスト
そこで次にデータソースの候補にあがるのが、SharePointリストです。
SharePointリストは3,000万行のデータが登録でき、一部の関数は委任処理も行えます。
一応、参照列を使うことで、リレーションシップを作成することはできます。
リレーションシップとは、テーブル間をキー列を使って、一対多等で関連づけること
しかし参照列は使いすぎるとアプリのパフォーマンスが落ちるため、複雑なデータモデルの場合、SharePointリストは適さないです。
またSharePointリストでも、一部の関数は委任処理できないため、2,000件を超える場合は、委任処理ができる関数を使う等、実装の工夫が必要になります。
- シンプルなデータモデルの場合、SharePointリストは使用するデータソースの候補になる
- レコード数が2,000件を超える場合、Power Apps側の実装で工夫が必要になる
Dataverse for teams
Dataverse for teamsは有料のライセンスが必要なDataverseの簡易版で、Teamsで使うことができます。
Dataverse for teamsの場合、SharePointリストよりも委任できる関数が多く、リレーションシップの定義もできるため、複雑なデータモデルにも使えます。
レコード数も100万件まで登録できるので、非常に有力なデータソース候補となると思います。
問題点としては、以下のようなものがあります。
- ストレージ（容量）の制限が、1つのデータベースにつき2GBまでなので、写真等、画像ファイルを多く保存するには向かない
- 基本的にチーム内で使うデータベースで、Teams外のメンバーの追加は、AzureADに登録した1つのセキュリティグループに限られる
-
データベースへのアクセス制御は基本的にチームの所有者、メンバー、ゲスト等の権限ごとにアクセス権が割り振られ、個人ごとに権限を変えることもできない
Dataverseへアップグレードすると、ストレージはライセンスによって増やせるし、データソースへの柔軟なアクセス制御もできるよ！
世知辛い世の中ですぞ…
これらのデータソースの比較をもとに、今回作る家事管理アプリでは、どのデータソースを使うべきか検討してみました。
- データ件数が1年で最大1,800~1,900件程度
- レシピの画像ファイル等も多く登録する
以上の要件を踏まえ、今回はデータソースとしてSharePointリストを使うことに決めました。
Office365ライセンスの範囲で、とりあえず無料で使ってみるデータソースとしては、SharePointリストか、Dataverse for teamsがよいと思います。
両者の使いどころは、こんな感じだと思います。
- SharePointリスト
- データ（レコード）数が2,000件以下
- シンプルなデータベース
- 画像を多く登録する
- 社内で広く使いたい
- Dataverse for teams
- レコード数が2,000件以上
- リレーショナルデータベースを使う
- 画像をあまり登録しない
- Teamsのチームで使う
データ型とは？
主なデータ型としては、以下の表に示したような数値型、テキスト型、日付/時刻型、True/False型等があります。
数値型
数値型のデータの中身は、1,2,3や、1.1、1.2等の数値データで、データの値を合計したり、平均をとったり等、値の計算、集計をすることができます。
テキスト型
一方で、テキスト型のデータの中身は、あいう、やＡＢＣ，あるいは1,2,3というデータが入っていることもあります。
ただし、テキスト型のデータに1,2,3というデータが入っていても、数値型のように値の計算、集計をすることはできません。
- 数値型のデータは、値を集計することができる
- テキスト型のデータは、1,2,3のような数値データでも、値を集計できない
日付型
日付/時刻型のデータは、2021年1月1日 9:00のようなデータを扱えます。
例えば、日付から年や時間を分離したり、データに入っている日付の値～現在の日付までの期間を計算したりできます。
True/False型
True/False型は、YESかNOのどちらかを表す値です。
プログラミングでいうところの、Boolean型ですね。
例えばアンケート項目に、「あなたは会社員ですか？」という質問があった場合、回答としては「はい、か、いいえ」を選択します。
この、「はい、か、いいえ」どちらかが入るデータが、True/False型のデータになります。
自分が扱っているデータのデータ型が、何のデータ型になるのか意識することが大事です。
例えば以下の、スーパーの売上一覧のテーブルで、それぞれの列は何のデータ型になるでしょうか？
日付はもちろん日付型です。
商品コード、商品名はテキスト型、原価、売上は数値型になります。
商品コードは、一見、数値型のようにもみえますが、合計したり、平均したり集計する必要のないデータのため、テキスト型になります。
PowerAppsでサポートしている主なデータ型
PowerAppsでサポートしている主なデータ型は以下になります。
先ほど説明したデータ型以外にも、ハイパーリンク、イメージ、選択肢、レコード、テーブル等があります。
選択肢は、あらかじめ用意した選択肢を、ドロップダウンなどで選んで登録することができます。
例えば、年代を登録する列で、10代、20代、30代・・・などの選択肢で登録する等でができます。
レコード型とテーブル型もアプリの中でよく使うデータ型です。
レコード型は、1行のデータのことです。例えば、年代が20代、性別が女性、職種が事務職、等のデータです。
テーブル型は、複数行のデータのセットで、レコード型が複数集まったものと考えてください。
アプリ開発の中で、データ型が異なるためにエラーが出ることがよくあります。
たとえば以下のPowerAppsの開発画面をみると、型に互換性がないという警告が出ています。
CategoryID = ThisItem.CategoryIDと書いていますが、CategoryIDは数値型、ThisItem.CategoryIDはテキスト型のため、警告が出ています。
Power Appsの実装では基本的に同じデータ型で、比較をする必要があるため、データ型を意識することは非常に重要です。
データベース設計方法
それでは、いよいよ今回作るアプリのデータベース設計です。
今回作る家事管理アプリは、以下６つの機能を持ち、テーブルもこの6つを作ります。
- 買い物管理
- 店名管理
- レシピ管理
- 献立管理
- カテゴリー管理
- 材料管理
Power Appsでアプリ開発するとき、データベース設計では、最低限以下のことを決めておけばよいです。
- 列名（日本語、英語）
- データ型
- テーブル間のリレーションシップ（関係性）
このとき内部名を日本語で付けると、エンコードされたよく分からない名前になるから、最初英語で列名を設定するんだ。
買い物管理テーブルと、店名管理テーブル
まずは買い物管理と、店名管理のテーブル設計を以下のように作りました。
左から、列名、英語の列名（内部名）、データ型です。
買い物管理テーブルは、日付列、買う物、店ID、完了フラグ列、削除フラグ列を作ります。
店名管理テーブルは、店ID列、店名列を作ります。
削除フラグ列は買い物が終わった時、削除フラグ列をTrueにして、画面に表示しないようにするために使うんだ。
他のアプリでも間違ってデータを削除してしまうことを考慮して、データ削除の実装でも実際には削除しないで、データベースに残しておく場合も多いよ。
次に買い物管理と店名管理のテーブル間のリレーションシップを考えます。
買い物管理テーブルでは、買うものと一緒に、どの店で買うか店名も登録します。
データベースのメンテナンス性を考えて、店名ではなく、店IDを登録するため、買い物管理と店名管理のテーブル間は、店IDで一対多のリレーションシップをします。
一対多のリレーションシップとは、どういうことですかな？
まず2つのテーブルは店ID列で紐づくよね。
店名管理テーブルでは登録する店が重複することはない（一意の値を持つ）から、店ID列が主キー（１）になるんだ。
一方、買い物管理テーブルでは、同じ店で複数の買う物がある（重複のある）から、店ID列が外部キー（多）になるんだよ。
リレーションシップについて、もう少し詳しく知りたいかたは、PowerBIのリレーションシップを解説した以下の動画も参考にしてください。
材料管理テーブル、レシピ管理テーブル、カテゴリー管理テーブル、献立管理のテーブル
材料管理テーブル、レシピ管理テーブル、カテゴリー管理テーブル、献立管理のテーブルは、以下のように設計しました。
ポイントとなるのはレシピ管理テーブルと、材料管理テーブル間が、多対多のリレーションシップとなる点です。
材料テーブルからみたときも、玉ねぎは、カレー、シチュー等複数のレシピで使うよね。
こういう関係が、多対多のリレーションシップになるんだよ。
多対多のリレーションシップの場合、中間テーブルを作るやり方が一般的によく使われる方法です。
しかしリレーショナルデータベースに対応していないSharePointリストでは、アプリの実装側が大変になってしまうため、今回はレシピ管理テーブルで参照列を使い、材料管理テーブルから材料名列を参照することにしました。
※SharePointリストでは、1レコードに複数データを登録するということができるため、参照列を使い、1つのレシピに複数の材料を登録することも可能になります。
その他レシピ管理テーブルと献立管理テーブルは、レシピIDで一対多のリレーションシップ、レシピ管理テーブルとカテゴリー管理テーブルがカテゴリーIDで一対多のリレーションシップで紐づきます。
Power Appsのデータベース設計をChatGPTに考えてもらう方法については、以下の記事を参考にしてください。
最後に
この記事では、Power Appsで使えるデータベースの比較、データ型についての説明と合わせて、今回作るアプリのデータベース設計方法を解説しました。
このような感じでデータベースの設計をしておけば、データベースを作成する際、この設計を元にそのまま作成するだけなので簡単です。
今回は色々と難しい内容でしたぞ…
今後データベースを作成したり、アプリで実際にデータベース操作をしていく中で、段々とデータベースの理解が深まっていくと思うから。
ビジネスアプリのデータベース設計はアプリ作りの肝になるので、アプリ開発前にきちんと設計しておくことをおススメします。
今回のデータベース設計をもとに、実際にSharePointリストでデータベースを作成する方法については、以下の記事を参考にしてください！
