目次
前回の記事では、ある架空のクリニックで使う診療記録アプリを作成することを考えました。このアプリは非常にシンプルなもので、日々の一つ一つの診療に対して、日付、患者名、症状・状態、処置、備考、担当スタッフを記録していきます。そしてそれらの診療の情報の登録、閲覧、修正、削除、検索などが行えるようにしたいと考えていました。また診療記録アプリで使うデータの構造を考え、そのデータを格納するデータベースとして Google スプレッドシートを利用することにしました。
今回はこのスプレッドシートを AppSheet に読み込んで連携することにします。その際、データベースに関する基礎的な知識、例えば型、制約という概念が必要になるということを説明します。
AppSheet と スプレッドシートを連携する
業務アプリで使うデータベースがスプレッドシートで準備できると、実は直ちに AppSheet で自動的に業務アプリを作成することができます。
スプレッドシートの画面上部にメニューが並べられていますが、その中に「拡張機能」という項目があると思います。これをクリックし、「AppSheet > アプリを作成」と進みます。
そうすると 「Google にログイン」するように求められるので自分のアカウントでログインします。すると次に 「Google AppSheet にログイン」するように求められるので「次へ」をクリックします。するとさらに「Google AppSheet が Google アカウントへのアクセスを求めています」と表示されるので「続行」をクリックします。すると AppSheet が自動的に「診療記録アプリ」を作成し始めます。
しばらくすると、次のような画面が現れ、アプリが作成されます。
このようにして自動的に作成されたアプリはパソコンで使ったりスマホにインストールして使うことができます。そのためにはまだいくつかの作業が必要になりますが、ここで問題となるのは、実はこのアプリはまだまだ問題があり目的を果たさないということです。前回の記事で診療記録のデータを格納するために用意したスプレッドシートは「患者」、「スタッフ」、「診療」、「診療-スタッフ」という４枚でした。しかしこの自動的に生成されたアプリには「患者」というシートだけが連携され、残りの３枚のシートはまだ連携されていないのです。おそらくAppSheetでは、最初のシートだけを使ってアプリを自動作成するようです。
残りの３枚のシートを連携するには、まず「Your 診療記録 app is ready!」と書かれている横にある「×」をクリックし、アプリ作成やカスタマイズをするための画面を表示します。次のような画面が見えるようになるはずです。
この画面の左側には縦にアイコン表示でメニューが並んでいます。まだ連携されていないスプレッドシートのシートと連携させるためには 次のように Data アイコンをクリックします。
すると次のようなデータを扱う画面 「Data」が開きます。この画面に表示されているボタンを操作していくことによりまだ連携していないシートを読み込んで連携することができます。
シートを追加するはまず次のように「+」ボタンをクリックします。
次のように、AppSheet が提案するシートの候補からの追加、様々なサービスからのデータ追加、Google Drive からのデータ追加ができるようになっています。
では、次のように、AppSheet が提案する中からシート「診療」を追加してみましょう。
読み込み対象として選択したシートに対して、いくつかの設定ができるようになっていますが、ここではそのまま「Add to app」ボタンを押して追加します。
ポップアップしていたダイアログが消え、次のようにシート「診療」が追加されたことがわかります。
これでシート「診療」をAppSheet に連携できました。これ以外の残りのシートについても同様に読み込んで連携することができます。
AppSheet では、読み込まれたシートは テーブル（table）と呼ばれることになります。また、シートの列に対応するものは列またはカラム（column）と呼ばれ、、シートで一つひとつの行が表しているデータは行またはロー（row）と呼ばれます。
データが従う規則の設定
さて、すべてのシートを AppSheet に連携させても、まだまだ設定しなければならないことがあります。
そもそも業務アプリで扱うデータは、業務の目的に沿ったものが集められ、業務の目的を果たすように何らかの規則に沿って設計されるべきです。例えば、ここで考えている診療記録アプリでは、シート「患者」の列「患者名」は文字列であるという規則に従うべきです。このような規則は、型と呼ばれます。またシート「患者」において、患者ひとりひとりにつけられる「id」は「それぞれの患者に必らず一つつけられ、他の患者と重複してはならない」という規則に従うべきです。このような規則は、制約と呼ばれます。
型と制約
シート「診療」を読み込んだ、先程の画面をもう一度見てみましょう。
「Table：診療」と書かれている所では、その下に、AppSheet によって自動的に設定された項目及びその内容が表示されています。設定項目として NAME、 TYPE、 KEY?、 LABEL?、… のようなものが並んでいるのがわかります。さらに、画面を横スクロールするともっと右にも設定項目があることがわかります。
型
データーベースに限らず、コンピュータが扱うデータはいくつかの種類に分けて考えることができます。そして、それら種類のことを「データ型」とか単に「型」と呼びます。例えば、大まかには「文字列型」、「整数型」、「小数型」、「日付型」などに分けることができまです。また、日常生活では馴染みがありませんが「ブール型（真偽値型）」というものもあります。どのデータがどの型に属しているのかということをコンピュータに教えておくことにより、コンピュータは効率よくデータを処理することができるようになります。
設定項目にある NAME はシート「診療」の列の名前に対応するものです。そこには、「_RowNumber」、「id」、「患者」、「日付」、「症状・状態」、「処置」、「備考」というものが縦に並んでいますが、「_RowNumber」以外はもともとのシート「診療」の列の名前です。またもとのシートには「_RowNumber」という列はありませんでしたが、AppSheet は自動的に「_RowNumber」を付け加えるということをします。
NAME の右隣の TYPE はデータ型をあらわしています。
例えば、「症状・処置」の TYPE を見てみると、Text となっていて、これは「症状・処置」に入力されるデータは Text、つまり文字列型でなければならないということを意味しています。またこれは、 読み込みに使ったスプレッドシートをもとに、AppSheet が自動的に「症状・処置」は文字列型であるべきだと判断して設定したものです。
また、例えば、「_RowNumber」のTYPE を見てみると、Number、つまり数となっているのがわかります。つまり「_RowNumber」に入力されるデータは数でなければならないということです。そしてこれも AppSheet が自動的に設定したものです。
以上見たように、シートを読み込んで連携する際、Appsheet は自動的に各列のデータ型を設定してくれます。しかし、時には自分の意図したものとは違う型を設定してしまうこともあります。そのような場合は手動で設定し直すことが必要です。
制約
データベースでは、それぞれの列に対する値の入力に関して何らかの制約を与えておくことが望ましい場合があります。
例えば、それぞれの列に対し「何も入力されていない状態（つまり空）は許されない」とか、「他の行の値と重複することは許されない」とか、「自動的にある決まりに従って初期値を設定する」などという制約を課すことが良く行われます。
ここでは、KEY?、FORMULA、EDITABLE?、 REQUIRE?、 INITIAL VALUE という設定項目について説明しておきます。
KEY?
ある列の値を見ればその他の列の値を見なくてもデータを一意的に特定できるような列のことを主キーといいます。そのような列では KEY? にチェックを入れます。テーブル「診療」では列「id」が主キーとなっています。チェックを入れ主キーとして扱うことにした列の値は、他のデータと重複することはなく、空であることも許されなくなります。
FORMULA
ある列の値を定数にする、自動的に計算される値にするという場合はここで定数や数式などを設定します。
EDITABLE?
これにチェックを入れると、その列は値の入力など編集可能になります。
REQUIRE?
これにチェックを入れると、その列は空であることは許されず、必ずなにか入力されていなくてはならないという制約をかけることができます。
INITIAL VALUE
データを新たに追加登録する際、様々な決まりに従ってその列に自動的に初期値が設定されるようにできます。ここでは例えば、「id」の INITIAL VALUE では「=UNIQUEID()」という関数が設定されています。この関数を設定することにより列「id」では値が必ず設定され、同じ id の値を持つデータは必ず一つだけになることが保証されます。
データベース言語として広く用いられている SQL では AppSheet とは様々な点で違う流儀で制約を設定します。
完成予定アプリのデータ操作画面に関する設定
これまで説明した他にも、LABEL?、SHOW?、DISPLAY NAME などの設定項目があります。これらは完成予定アプリのデータ操作画面でそれぞれの列をどのように表示するのかということを設定する項目です。
LABEL?
これにチェックを入れると、このテーブルに対応している画面ではタイトルのような役割を持つものとして表示されるようになります。また、このテーブルを参照しているテーブルに対応している画面でこの列が表示されるとき、この列の値は KEY として指定された列の値の代わりに表示されるようになります。
SHOW
これにチェックを入れると、その列はデータ操作画面に表示されるようになります。
DISPLAY NAME
ここに何かしらの文字列を設定しておくと、データ操作画面ではもともとの列名ではなく設定した文字列で列名が表示されるようになります。
テーブル間の参照とRef 型
あるテーブルの中のある列が別のテーブルのある列を参照するようにしたい場合、まず参照される側のテーブルはどれであるのかを指定する必要があります。
AppSheet では、まず参照する側で参照に使う列の TYPE を Ref 型（参照型）に指定し、さらに参照される側のテーブルがどれなのかを指定すると、自動的に参照される側で KEY に設定してある列の値を使い参照をしようとします。参照される側のテーブルでは、もちろんその KEY の値を持つデータ（つまり行）は必ず一つだけ存在します。その結果、参照する側で参照に使う列の値を持つデータ（つまり行）が参照される側で必ず一つ見つかり、そのデータが持つ様々な列の値も参照する側で自由に使えるようになります。
例えば、テーブル「診療」にあらわれている列「患者id」がテーブル「患者」の列「id」を参照するようにしたければ、まず、テーブル「診療」を選択し、テーブル「診療」の列「患者id」の TYPE を Ref にします。
列「患者id 」の鉛筆アイコンをクリックすると、列「患者id」に対して様々な設定を行うダイアログがポップアップします。
Type が Refになっていることを確認し、参照するテーブルとして、ここでは「患者」を選択します。
Done ボタンをクリックして列「患者id」に対する設定を完了します。
ポップアップしていたダイアログが閉じ、Data に関する設定画面に戻るので、SAVE ボタンを押してこれまでの設定をアプリに反映させます。
このように設定をすると、参照される側のテーブルには「Relatad 参照元の列名s」という名前で仮想的な列（Virtual Column）が自動的に作成されます。この仮想的な列には、参照される側のこのデータ（つまり行）を参照している参照元のすべてデータ（行）がリストとして格納されます。仮想的な列（Virtual Column）は読み込んだもともとのシートには存在していないものですが、AppSheet で作成する業務アプリではこの仮想的な列（Virtual Column）の値を用いた様々な表示をすることができます。
実際、テーブル「患者」の設定を確認してみると、次のように、「Related 診療s」という列が自動的に作られているのがわかります。鉛筆アイコンが青くなっているのは、この列が仮想的な列、つまり Virtual Column であることを示しています。
複数のシートを AppSheet に読み込むと、AppSheet は自動的に読み込むシート間の関連を判断し、テーブル間の参照を設定することがあります。もちろん、この自動的な設定が意図しているものと違う場合は、手動で列の型を設定し直す必要があります。
Ref は 参照型とでも呼ぶべきもので、別のテーブル（つまりシート）から引っ張ってきて作られているデータであることを意味しています。
データベース言語として広く用いられている SQL では、参照は型ではなく制約として扱われます。
ここでは詳しく述べませんが、リレーショナルデータベースでは外部キーという概念を使って参照する仕組みを説明します。外部キーについては次の記事を参考にしてください。
まとめ
今回もコードを全く書くことなく作業を進めることができました。
しかし、データベースに関する基礎知識、例えば、型や制約、参照といった知識が必要になるということが分かると思います。
