前回の記事で、SNSを作るときの変数について取り上げてみました。
その中で、Firebaseというクラウド上のデータベースとつないだ「Cloud Variable」という変数についてとりあてました。
今回は、クラウド上のデータベースにどのように保存しておくとSNSをつくれるのかについて説明していきます。
現在、Firebaseには認証用の「Authentication」テーブルと、ユーザー管理用の「Users」テーブルの２つのテーブルがあります。
「Authentication」テーブルは、Firebaseで「FireBaseプロジェクト」を構成してサインインの方法を指定すると自動的に作成されるテーブルで次のような形をしています。
少し専門的な表記となりますがER図という形で上のテーブルを表記してみると次のようになります。
PKは「プライマリキー」または「主キー」と呼ぶものになります。
PKはそのテーブルで行を特定するものになります。
「Users」テーブルはThunkableアプリの「Cloud Variable Users」と対になるテーブルになります。そのテーブルの形はThunkableで定義します。
こちらもER図で表記してみましょう。
「Users」テーブルでPKは「ID」としています。「Users」テーブルにおけるPKとは「だれが」と言い換えることができます。
それでは、なぜ「メールアドレス」ではなく「ID」を使って「だれが」としているのでしょうか。
それは、あとからメールアドレスを変更できるようにするためです。
もし、メールアドレスを使って「だれが」を特定できるようにしてしまうと、あとからメールアドレスを変えるたびに「だれが」という値をそこらじゅうのテーブルから探して書き換えないといけなくなります。
そのため、人の目に触れないIDという項目を作って、メールアドレスとは別に管理しているのです。
それでは、このIDというのはどこで入力するのでしょうか。
実は、「Users」テーブルのIDは人が入力するものではなく、Firebaseが自動的に作った値を採用しています。
そのあたりの関係をER図では「Authentication」テーブルと「Users」テーブルの間のRelation（リレーション）という線で表現できます。
例えば、ER図の次の表記は、「Authentication」テーブルの「ユーザーUID」と「Users」テーブルの「ID」は同じ値を入れることで「１対１」であること、つまり「Authentication」テーブルの１行と「Users」テーブルの１行がペアになっているということを表しています。
それでは、なぜ、「Authentication」テーブルの他に「Users」テーブルが必要なのでしょうか。
なぜ、「Users」テーブルが必要かといえば、「Authentication」テーブルはFirebaseが自動的に作成するテーブルのため、アプリを利用する人の「姓」「名」などを保存する項目を追加できないためです。そのため、アプリが必要とする利用者１人１人の情報は「Users」テーブルを作ってあげて、そちらに保存する必要があるからです。
つぎにSNSへ投稿した内容を保存するテーブルを考えてみましょう。
投稿内容に必要なのは「内容」「投稿日時」「投稿した人」などが最低限必要です。
「Tweets」テーブルに「内容」「投稿日時」「投稿した人」をいれてみましょう。
「ID」が「だれが」つまり「投稿した人」なので「Users」テーブルと関係づけてみましょう。
１人の人が投稿できるのは１つではないので、「Users」テーブルと「Tweets」テーブルは「１対N」の関係になります。
ER図では「１対N」の関係は次のように表します。
ここで「FK」という新しい表記がでてきましたが、FKとは「外部キー」と呼ぶもので、今回の場合「ID」は「Tweets」テーブル以外（つまり外部の）「Users」テーブルのキーであることを表しています。
さて、それでは投稿に「いいね」がつけられるようしてみましょう。「いいね」は画面では「いいねの数」のように数字で表示されていますが、実際は「だれが」いいねしたかが保存されていて、ある投稿に何人「いいね」したかを「いいねの数」として表示します。
そのため、「いいね」を保存するテーブルに必要なのは「どの投稿」「だれが」「いつ」という３つの要素になります。
それでは、「Users」テーブル「Tweets」テーブル「Favs」テーブルの３つの関係を表してみましょう。
１つの投稿に１人の人がつけられる「いいね」は１つだけなので、「１対１」の関係が３つのテーブルの間で成り立たないといけないので、ER図のRelationは次のようになります。
これで、使う人が好きな投稿に対して「いいね」を付けたり消したりすることができるようになりました。
それでは、テーブル編はひとまずここまでにして、次回はER図をみながらThunkableアプリのブロックを書いていくことにしましょう。
