PowerApps

【PowerApps入門】キャンバスアプリの作成方法#2~アプリ設計(後半)~ データ型とデータベース設計

ミムチ
ミムチ
今日はPowerAppsアプリ設計の後半、データベース設計についてでしたな!

パワ実
パワ実
その通り!

最初にPower Appsで使えるデータベースの比較や、データ型についても解説した後、今回作る家事管理アプリのデータベース設計について解説するよ。

この記事では、Power Appsのアプリ設計について、以下の解説をしていきます。

この記事でわかること

  1. Power Appsで使えるデータソースの比較
  2. データ型とは何か?
  3. データベース設計の方法

Power Appsのアプリ設計の前半は、以下の記事を参考にしてください。

【PowerApps入門】キャンバスアプリの作成方法#1~アプリ設計(前半)~ 本日はPower Appsのアプリ設計について、以下の解説をしていきます。 YouTube動画で見たいかたは、こち...

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を使うことを検討するのがいいかもね。

Dataverseへアップグレードすると、ストレージはライセンスによって増やせるし、データソースへの柔軟なアクセス制御もできるよ!

ミムチ
ミムチ
ちゃんとしたデータソースが使いたければ、有料のDataverseを買うべし…ということですかな。

世知辛い世の中ですぞ…

これらのデータソースの比較をもとに、今回作る家事管理アプリでは、どのデータソースを使うべきか検討してみました。

今回作るアプリの要件

  • データ件数が1年で最大1,800~1,900件程度
  • レシピの画像ファイル等も多く登録する

以上の要件を踏まえ、今回はデータソースとしてSharePointリストを使うことに決めました。

Office365ライセンスの範囲で、とりあえず無料で使ってみるデータソースとしては、SharePointリストか、Dataverse for teamsがよいと思います。

両者の使いどころは、こんな感じだと思います。

SharePointリストとDataverse for teamsの使い分け

  1. SharePointリスト
    • データ(レコード)数が2,000件以下
    • シンプルなデータベース
    • 画像を多く登録する
    • 社内で広く使いたい
  2. Dataverse for teams
    • レコード数が2,000件以上
    • リレーショナルデータベースを使う
    • 画像をあまり登録しない
    • Teamsのチームで使う

パワ実
パワ実
今回はSharePointリストを使うことにしたけど、Dataverse for teamsについても、もう少し勉強してからまたまとめるよ!

データ型とは?

パワ実
パワ実
次に、アプリ設計に必要な、データ型について説明するよ!

ミムチ
ミムチ
データ型とは何ですかな?

パワ実
パワ実
データの型は、その値が整数なのか?テキストなのか?等、どのような種類のデータかを示すものだよ。

主なデータ型としては、以下の表に示したような数値型、テキスト型、日付/時刻型、True/False型等があります。

数値型

数値型のデータの中身は、1,2,3や、1.1、1.2等の数値データで、データの値を合計したり、平均をとったり等、値の計算、集計をすることができます。

テキスト型

一方で、テキスト型のデータの中身は、あいう、やABC,あるいは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つの機能を持ち、テーブルもこの6つを作ります。

  1. 買い物管理
  2. 店名管理
  3. レシピ管理
  4. 献立管理
  5. カテゴリー管理
  6. 材料管理

Power Appsでアプリ開発するとき、データベース設計では、最低限以下のことを決めておけばよいす。

データベース設計で書いておくこと

  • 列名(日本語、英語)
  • データ型
  • テーブル間のリレーションシップ(関係性)

ミムチ
ミムチ
列名は何で、日本語と英語が必要なのですかな?

パワ実
パワ実
今回使うSharePointリストは、列を作成するとき、最初につけた名前がアプリの実装でも使う内部名になって、これは変更できないんだよ。

このとき内部名を日本語で付けると、エンコードされたよく分からない名前になるから、最初英語で列名を設定するんだ。

ミムチ
ミムチ
SharePointリストだと、日本語の列名を作れないということですかな?

パワ実
パワ実
日本語の列名を作成したい場合は、最初に英語の列名を作成し、その後で日本語に変える手順をふめばOKだよ!

買い物管理テーブルと、店名管理テーブル

まずは買い物管理と、店名管理のテーブル設計を以下のように作りました。

左から、列名、英語の列名(内部名)、データ型です。

買い物管理テーブルは、日付列、買う物、店ID、完了フラグ列、削除フラグ列を作ります。

店名管理テーブルは、店ID列、店名列を作ります。

ミムチ
ミムチ
完了フラグ列と、削除フラグ列とは何ですかな?

パワ実
パワ実
完了フラグ列は、買い物が完了したかどうかの判定に使うよ。

削除フラグ列は買い物が終わった時、削除フラグ列をTrueにして、画面に表示しないようにするために使うんだ。

ミムチ
ミムチ
買い物が終わったら、データベースから削除してよいのではないですかな?

パワ実
パワ実
買い物が終わったものも、あとでPower BIレポートを使った分析をしたいから、データベースには残しておくんだ。

他のアプリでも間違ってデータを削除してしまうことを考慮して、データ削除の実装でも実際には削除しないで、データベースに残しておく場合も多いよ。

次に買い物管理と店名管理のテーブル間のリレーションシップを考えます。

買い物管理テーブルでは、買うものと一緒に、どの店で買うか店名も登録します。

データベースのメンテナンス性を考えて、店名ではなく、店IDを登録するため、買い物管理と店名管理のテーブル間は、店IDで一対多のリレーションシップをします。

ミムチ
ミムチ
ちょっと待ってくだされ!

一対多のリレーションシップとは、どういうことですかな?

パワ実
パワ実
買い物管理テーブルと、店名管理テーブルの関係性を示すものだよ。

まず2つのテーブルは店ID列で紐づくよね。

店名管理テーブルでは登録する店が重複することはない(一意の値を持つ)から、店ID列が主キー(1)になるんだ。

一方、買い物管理テーブルでは、同じ店で複数の買う物がある(重複のある)から、店ID列が外部キー(多)になるんだよ。

リレーションシップについて、もう少し詳しく知りたいかたは、PowerBIのリレーションシップを解説した以下の動画も参考にしてください。

材料管理テーブル、レシピ管理テーブル、カテゴリー管理テーブル、献立管理のテーブル

材料管理テーブル、レシピ管理テーブル、カテゴリー管理テーブル、献立管理のテーブルは、以下のように設計しました。

ポイントとなるのはレシピ管理テーブルと、材料管理テーブル間が、多対多のリレーションシップとなる点です。

ミムチ
ミムチ
多対多のリレーションシップとは何ですかな?

パワ実
パワ実
レシピ管理テーブルでは、例えばカレーのレシピには材料として、玉ねぎ、にんじん、ジャガイモなど複数の材料が登録されるよね。

材料テーブルからみたときも、玉ねぎは、カレー、シチュー等複数のレシピで使うよね。

こういう関係が、多対多のリレーションシップになるんだよ。

多対多のリレーションシップの場合、中間テーブルを作るやり方が一般的によく使われる方法です。

しかしリレーショナルデータベースに対応していないSharePointリストでは、アプリの実装側が大変になってしまうため、今回はレシピ管理テーブルで参照列を使い、材料管理テーブルから材料名列を参照することにしました。

※SharePointリストでは、1レコードに複数データを登録するということができるため、参照列を使い、1つのレシピに複数の材料を登録することも可能になります。

その他レシピ管理テーブルと献立管理テーブルは、レシピIDで一対多のリレーションシップ、レシピ管理テーブルとカテゴリー管理テーブルがカテゴリーIDで一対多のリレーションシップで紐づきます。

Power Appsのデータベース設計をChatGPTに考えてもらう方法については、以下の記事を参考にしてください。

【ChatGPT活用】Power Appsのデータベース設計をAIに考えてもらう! ChatGPTとは? この記事では、ChatGPT(AI)を使ってPower Appsアプリのデータベース設計を考えてもら...

最後に

この記事では、Power Appsで使えるデータベースの比較、データ型についての説明と合わせて、今回作るアプリのデータベース設計方法を解説しました。

このような感じでデータベースの設計をしておけば、データベースを作成する際、この設計を元にそのまま作成するだけなので簡単です。

ミムチ
ミムチ
データ型に、リレーションシップ…

今回は色々と難しい内容でしたぞ…

パワ実
パワ実
今回の説明で、データベースを完全に理解できていなくても大丈夫だよ!

今後データベースを作成したり、アプリで実際にデータベース操作をしていく中で、段々とデータベースの理解が深まっていくと思うから。

ビジネスアプリのデータベース設計はアプリ作りの肝になるので、アプリ開発前にきちんと設計しておくことをおススメします。

今回のデータベース設計をもとに、実際にSharePointリストでデータベースを作成する方法については、以下の記事を参考にしてください!

【PowerApps入門】キャンバスアプリの作成方法#3~データベース作成~ SharePointリストの作成方法 この記事では、SharePointリストでデータベースを作成する方法を解説します。 YouTube動画で見たいかたは、...
ABOUT ME
パワ実
DX推進担当(IT部門) 2021年からPower Platform(Power BI、Power Apps、Power Automate)を勉強中。 Power Platformを使っていく中で、知りえた情報を発信している。 Youtube、Twitterでの情報発信もしています!

Power Platformのご依頼・ご相談について

Power Platformについてのご相談、お仕事のご依頼については、
こちらのお問い合わせページをご確認ください。