【2021年9月 2weeksインターンシップ】初めてDataverseでデータベース設計したお話
2021-10-12
azblob://2022/11/11/eyecatch/2021-10-12-for-first-time-dataverse-by-db-designed-story-000.jpg

株式会社FIXER新卒採用担当の諸見里です。この度、9月6日~17日までの2週間で夏季インターンシップを実施いたしました。今回のインターンシップは14名にご参加いただき、最終日に参加者全員にブログを書いていただきましたので、その内容を代筆いたしました。以下内容がインターン生のブログになりますのでご覧ください。

2weeksインターンシップに参加させていただきました、後藤祥仁と申します。この記事では、チームメンバーと協力しながら開発したアプリの中で、筆者が担当したデータベース設計のお話を書こうと思います。

1. 開発アプリ概要

今回、「Health Fixer」という生活習慣病の患者を支援し、医者の負担を軽くするアプリを作成しました。このアプリは、患者が日々の食事や運動を記録し医者に送信したり、診察予約をアプリ上で行ったり、医者は普段の患者の様子をチェックしたりすることができます。

医者と患者、相互で通信を行うため、医者用のアプリ、患者用のアプリを作る必要性がありました。今回は開発時間の都合上、患者用のアプリのみの作成となりました。

私は、主にデータベース設計の取りまとめを担当しました。

2. データベース設計

データベース構成は以下の図のようになりました。

患者用のアプリを重点的に作っていったので、患者情報テーブルが少し大きくなっています。まずはそれぞれのテーブルの説明をします。

・患者情報…患者の情報があるテーブル

・患者計画…医者が作った患者向け計画があるテーブル

・予定(記録) …患者の日々の記録が載るテーブル

・医者情報…医者の情報があるテーブル

・予約…確定した診察予約が載っているテーブル

・医者さんの予約受け入れ…医者が予約を受け入れることができる日時が入っているテーブル

データベース設計をやること自体、ほぼ初めての取り組みだったので、かなり戸惑いながら作っていきました。私は不足データが後から出てくると、面倒くさいことになると考え、チームメンバーと一緒に最初は必要そうなデータをどんどん書き出しました。その後、そのデータをテーブルにそれぞれまとめて行きました。まとめていくとき、テーブル同士のつながり(リレーション)を意識しました。例えば、医者情報テーブルに載っていない医者(病院などから登録されていない医者)が患者との予約をセッティングしているとおかしいですよね。そうならないよう、医者情報テーブルの医者IDと予約テーブルの医者IDにリレーションを持たせることで、先程の例にならないようにしました。

3. Dataverse上に構築

Dataverseにテーブルを登録して行きました。最初は登録一つでも苦労しました。身に覚えのないカラムが出てきたり、登録時のオプションの付け方がわからなかったりとありました。しかし、UI上で全て完結していたので、すぐに慣れて構築を進めて行くことができました。

リレーションを持たせるときに少し苦労しました。Dataverseはテーブル同士でリレーションを持たせた瞬間にカラムも同時生成しており、そこで少し混乱しました。他にもオプションで色々設定できるみたいですが、開発時間的に間に合わないと判断し諦めました。

4. まとめ

初めてデータベース設計を行い、Dataverse上に構築しました。私が思っていた以上に褒められたので、正直嬉しかったです。とはいえ、少し設計に時間をかけすぎてしまい、アプリ開発に遅延が発生してしまいました。そのため、次回以降このような機会があったときは、早く綺麗なデータベースが作れるよう、今後もがんばります。

今回のインターンシップでは、チームメンバーやメンターの方々に助けられて完成まで持っていくことができました。特にデータベース設計時に必要なデータの案出しやテーブル設計時に不足していそうな部分を指摘してくださったメンバーには感謝しています。一人だと満足いくデータベースはできなかったと思います。他にも感謝したいこと、ここが良かったなど書いていくとキリがないです。本当に、本当にありがとうございました。

azblob://2024/04/08/eyecatch/2024-04-04-yellow-apron-000.jpg
2024/04/15
About FIXER