業務改善と標準化を同時に実現:MS 365業務システム開発

PowerAppsでのデータベースの構成の3つのパターンでDBの作成が楽になる。【Split関数の活用法】

  
PowerAppsでのデータベースの構成の3つのパターンでDBの作成が楽になる。【Split関数の活用法】
\ この記事を共有 /
PowerAppsでのデータベースの構成の3つのパターンでDBの作成が楽...

データベースの構成の3つのパターンとそれらをPowerAppsのギャラリーでどう表現しているかをお見せします。それらを知るとアプリ作成が楽になります。

(動画時間:

データベースの構成のパターンを覚えるとアプリ作成が楽になる。

こんにちは、リーンシグマブラックベルトのマイク根上です。
業務改善コンサルをしています。
今日はこのご質問からです。

「作業時間記録アプリについての詳細が知りたいです。
データベースはどのような構成なのか、
どこに保存されているか等を教えて頂けないでしょうか。」

その「作業時間記録アプリ」は以前の動画でご紹介しました。
⇒「【PowerApps 事例】自分の作業時間を記録する携帯アプリを作る:作業時間記録アプリ」

そのデータベースの構成は最も簡単なパターンで、
今日はそれを含めて三つのパターンをご紹介しますので、
それらを使いこなす事で今後のアプリ作成を楽にできます。

DBの構成パターン1:詳細テーブルに区分データの列を含むやり方

作業時間記録アプリ画面1 記録開始

上図が作業時間記録アプリで、
最初の画面が手持ちのプロジェクトの一覧で、
各プロジェクトでの作業時間を簡単に記録できるものでした。
そしてプロジェクトの右の矢印をくりっくすると
次の画面でこれまで記録した作業時間の詳細の閲覧と編集ができます。

作業時間記録アプリ画面1 記録完了

そしてそのアプリのデータベースとしてSharePointリストを使っていて、
下図がそのSPリストで「作業記録テーブル(Tbl_Task_Records)」としています。

それには「プロジェクト名(Project_Name)」、
作業の「開始時間(Start_Time)」、「終了時間(End_Time)」、
そして掛かった「作業時間(Duration)」、「メモ欄(Memo)」の列を入れています。

この一枚のテーブルだけであれだけのアプリが作れてしまうのです。
このテーブルの構成をパターン1と呼びましょう。

このパターン1では作業毎に一つのレコードが作成されます。
ですのでこのテーブルの単位は「一作業」という事になります。
そしてその詳細データの中に区分データである「プロジェクト名」列があり、
この列にどんどん同じプロジェクト名がたまっていきます。

そこでPowerAppsの開発画面を見ると、
最初のプロジェクト名の一覧を表示する画面のギャラリーの「Items」属性には
Distinct関数を使って重複を削除して表示しています。

プロジェクト一覧画面内のギャラリーの「Items」属性
=Search(
  Distinct(
    Tbl_Task_Records,
    Project_Name
  ),
  TextSearchBox1.Text,
  ”Value”
)

DBの構成パターン2:区分データと詳細データを分けた複数のテーブルを使うやり方

前述のパターン1は一番シンプルな構成で、
今回は各プロジェクトに関するデータが作業時間だけでしたので
このパターンで良かったのですが、
もし、他にプロジェクトの開始日やプロジェクトリーダーとかの情報も
記録したい場合はどうでしょうか?

パターン1では単位が「一作業」なので、
それらの情報を保存する場所がありません。
そこでパターン1のテーブルをプロジェクト名を重複無しで記録する
プロジェクトテーブルと作業時間テーブルに分ける必要があります。

それがパターン2で、実際の業務システムの開発では
このパータンがほとんどです。

この記事では便宜上、プロジェクトテーブルを「区分テーブル」、
作業時間テーブルを「詳細テーブル」と呼ぶ事にします。

上図のアプリがその改良版です。
各プロジェクトのリーダー名を追加しています。

上図がその区分テーブルの構造です。
この「ProjectCol」テーブルではプロジェクトが一単位で
それに付随する色んな情報を記録できるのです。

このテーブルはすでにプロジェクト名が重複無しなので、
ギャラリーの「Items」属性内ではそのまま使えるのです。

SharePointリストでプロジェクトテーブルを作った時、
既定で重複無しの連番が自動で作成される「ID」列があります。
それをプロジェクトIDとして使えるのです。

そして作業時間をさっきの作業記録テーブルで記録し、
各レコードにプロジェクト名ではなく、
プロジェクトIDを割り振ります。

プロジェクトIDを使う利点は将来
プロジェクトテーブルのプロジェクト名を変更しても
プロジェクトIDは変更しなくて済むので、問題が起こりません。

一方、パターン1ではプロジェクト名を各レコードに入れてますので、
プロジェクト名を変えたい時は
過去の全てのそのプロジェクト名を変更する必要があるのです。

パターン1は作るのは簡単で良いのですが、
メンテナンスが難しくなるので
実務で使う業務アプリではパターン2を使うと良いでしょう。

区分テーブルは複数の詳細テーブルと連結できる

次に各プロジェクトに参加するプロジェクトメンバーも
記録したいとしましょう。
メンバーは複数いるのでプロジェクトテーブルの
一つのレコードに入りません。

そこでパターン2ではもう一つ「チームメンバー」テーブルを作り、
そのテーブルにプロジェクトID列を入れる事で
全3つのテーブルを連結する事ができるのです。

上図の画面がまたその改良版です。
ギャラリー内に「メンバー」ボタンを追加しています。
それをクリックすると次の画面で
そのプロジェクトに参加しているメンバー名が
ギャラリーで表示されます。

そのギャラリーの「Items」属性の数式と
その中のメンバーデータが入っている「MemberCol」の中身が下図です。
選択されたプロジェクトのIDでFilter関数を使って絞り込みをしています。

メンバー名と彼らが参加しているプロジェクトのIDが含まれています。
このテーブルの単位はメンバーなので
他に各メンバーの情報、例えば社員番号や役職名なども
このテーブルで管理ができます。

DBの構成パターン3:区分テーブルに少数の詳細データを保存するやり方

このパターン2は汎用性が高いのでメインで使いますが、
例えばこのメンバー名だけを管理したいという時に
これだけの少ない情報なのにSharePointリストを単独で作るのも手間ですね。
そこで手軽にできるパターン3をご紹介します。

その場合のアプリの見かけと機能性はさっきと全く同じになります。

このパターン3では区分テーブルのプロジェクトテーブルに
「Member」列を追加して、その中に「;(半角セミコロン)」を区切文字にして
メンバー名を入れています。(下図参照)

そしてメンバー一覧のギャラリーの「Items」属性には
その選択されたプロジェクトの「Member」列の値を表示しています。

メンバー一覧画面のギャラリーの「Items」属性
=Split( BrowseGallery3.Selected.Member,”;”)

上図がその式ですが、「Member」列はテキスト型ですので、
それだけではエラーになってしまいます。
そこでSplit関数を使ってそのテキストを第二引数で
セミコロンを区切文字として各メンバー名を一列のテーブルに変換して、
正しくメンバーの一覧表示ができるのです。

ちなみにSplit関数と真逆の変換ができるのがConcat関数で、
今日はやりませんが、このデータを保存したい時にこの関数を使います。

Concat関数の使用例
=Concat(Gallery3.AllItems,Value,”;”)

上記の数式の結果:
メンバー D;メンバー E;メンバー F;メンバー G;メンバー H

テーブル構成の3パターンの比較と使い分け方

ここで今回ご紹介したテーブルの構成の
3つのパターンをまとめてみます。

パターン1では「詳細テーブルに区分データの列を含む」やり方でした。
これはテーブルが一つでアプリ作成時はとても楽にできます。
短所としては区分データに付随するデータを記録できない事と
区分データの変更を管理するのが難しい事です。

パターン2は「区分データと詳細データを分けた複数のテーブルを使う」やり方で、
これは汎用性が高く、通常このパターンを使います。

しかしテーブル数が増えるのでDBの作成と
ユーザーのアクセスの管理もしないといけないのでメンテで手間が増えます。

そこで少数の詳細データなら
個別のSharePointリストを作成せずにすむパターン3を使います。
それは「区分データのテーブルに列を追加して、
少数の詳細データを区切文字と一緒に保存する」やり方です。

その詳細データのテーブルを作らないので
作成とメンテが楽になりますが、
ちゃんと複数の詳細データのテーブルとして扱えます。

短所は、時間と共にデータが増えていく詳細データには適さない事です。
少数の数値データにもこのパターンは使えますが、
その数値データを使って後で集計をしたい時にはこの方法は使えません。

それらのデータを使った集計がしたいのであればパターン2を使いましょう。

僕は個人利用以外のアプリではパターン2をメインで使いますが、
適切な場合であればパターン3もたまに使います。
使用するSharePointリストの数を減らせるのが魅力だからです。

皆さんもこの3つのパターンの違いをご理解されて、
時と場合によって使い分けてみて下さい。

「こちらの記事も読まれてます。」