素人が2020年までの1ヶ月でLINE BOTに挑戦する毎日note. 【Day 18：DBスキーマの定義 part 2】

こんにちは！
12月1日から2019年残り1ヶ月でスケジュール調整BOTの開発に挑戦している"くろ"です。

わかってはいましたが、毎日続けるのが本当にきつくなってきている18日目です。

1ヶ月でBOTを作るだけだったら、追い込む日とそうでない日とか作れるんですけど、ちょっと体調悪いなとか本業とか長引いて遅くに返ってきても、それでもそこから今日がまた始まる感じなんで、あんまりこういう形態はおすすめしないです。笑

あとは、記事書くよりも作業や勉強を進めたいとかも正直あります。笑

それでも、本当に初心者の人が読んでいけば理解できるようにすることに価値はあると信じているので、引き続き頑張っていきたいと思います。

たまに、会社とかSNSとかで「見てるよ」とか言ってもらえるんですけど、あれが結構原動力になるので、もし読んでいる方いれば、直接でもSNSでもこの記事にスキやコメントでもいいので、励まして頂けると、とても嬉しいです。

本題です。

BOTの概要：Day 2の記事

BOTの仕様：機能一覧やフローチャート Day 10の記事

昨日は、heroku(+github)+node.js+expressでLINEのBOTがオウム返しをしてくれる所まで開発環境を整えました。

今日は、Day 14で記述していたDBスキーマの定義をpart 2として進めていきたいと思います。

おさらい(DBスキーマの設計とは？）

DBスキーマの定義は設計というフェーズの3つ目にやることになります。

データベースの構造をどういう風にするのか？を定義するパートです。

定義するものは以下の4つがあります。

1，Entity
2，Repository
3，Service logic
4，Controller

（復習）1，Entityとは？

サービスで利用するあらゆるデータの中で、1:1の関係に落とせないデータの単位をEntityと呼べばよさそうです。例えば、学校と学校名は1:1なので、Entity（箱）と属性（中身）の関係になるので、学校はEntity、学校名は属性となります。また、学生と学籍番号なども1:1なので、学生がEntity、学籍番号が属性になりそうです。
そして、その箱同士（＝Entity同士）は学校と学生のように1:Nの関係で結ばれることでデータベースの構造ができていくということになります。

Entityを決めていく際には、一番大きい単位だと思われるEntityから作っていき、その要素になりそうなデータたちについては、1:1なのか？1:Nなのか？N:Nなのか？を考えながら、最後1:1の関係になるまで落としていれば、全てのEntityと属性を決めることができそうです。

ちなみに、EntityはEntity クラスという形で記述していくようです。実際に構成するときは、作成したスプレッドシートを参考にこういったコードを書いていく必要があります。

class User {
    int id;
    string name;
    Datetime createdAT;
    Datetime updatedAT;

}

以上が復習になります。

ということで、

まずはGoogleのスプレッドシートを使って、スケジュール調整BOTの場合のEntityの定義をしていきたいと思います。

ざっと作ってみたのがこちらです。

手順としては、こんな感じです。

1，一番大きい概念でまずは箱を作る

今回でいうと、ユーザー(user)、日程調整(schedule)、Googleカレンダー(google_calendar)くらいの感じで出してみました。

2，その箱の中に要素を入れていく

userの中には、幹事とメンバーがいて、日程調整には、条件と回答情報があって、、、みたいな感じですね。

3，1:nの関係になるものは、別の箱に出していく

幹事やメンバーはuserに対して一意ではないですし、日程調整の条件の内、時間は一意ですが、回答情報は候補日ごとに必要なので1:nだなみたいな感じで別の箱に出していきました。

4，繰り返していきながら、矛盾やムダを解消していく

といった形で進めました。

師匠の別サービス用のサンプルを見ながら作ったので、ある程度合っていると思うのですが、FBも含めて明日解説させて頂きます。

以上になります。

今年も残りわずか、明日も頑張っていきましょう！！