概要
アプリケーションに必要なER図を起こしました。
現状は、非常にシンプルな構造となっています。
今回制作するアプリケーションはマッチングアプリなので、「フォロー/アンフォロー」や「いいね機能」が追加予定です。その都度最新のER図を掲載していきます。
どんなアプリケーションか？
簡単にいうと生産者と料理人のマッチングサービスです。
以下の記事に制作に至った経緯が書いてあるので気になったかはご覧ください！
https://pontyblog.com/364/
エンティティの絞り方
エンティティを絞り込む場合は、データが登録される場面に着目して絞っていきます。
第三正規化をおこない、情報するエンティティを分離する必要があります。正規化や第一、第二正規化では、「重複するデータ」が存在したり、本来分離されるべきエンティティが混同してしまうからです。
例えばSNSのように、1つの投稿に対して多数のコメントがされる場合を正規化で考えてみます。
postsテーブル【正規化】
| user_name | tweet_text | comment_text |
|---|---|---|
| masuda | 虫が少ないキャンプ場 | 行ってみたい！/どこのキャンプ場？/景色も良さそう！ |
| tanita | 今日は犬と戯れています〜 | ハスキー飼いたい！ |
一見問題なさそうですが、commentのところを見ると、コメントが複数存在しています。これは、アプリケーションのパフォーマンスを落とす原因になります。そして特定の情報を取得する際、情報整理できていないので、効率の悪いものになってしまいます。
第三正規化をおこなう
第三正規化は、情報の混在するエンティティを分離することです。実際にやってみます。
usersテーブル
| id | name |
|---|---|
| 1 | masuda |
| 2 | tanita |
tweetsテーブル
| id | tweet_text | user_id |
|---|---|---|
| 1 | 虫が少ないキャンプ場 | 1 |
| 2 | 今日は犬と戯れています〜 | 2 |
commentsテーブル
| id | comment_text | tweet_id |
|---|---|---|
| 1 | 行ってみたい！ | 1 |
| 1 | どこのキャンプ場？ | 1 |
| 1 | 景色も良さそう！ | 1 |
| 2 | ハスキー飼いたい！ | 2 |
このように第三正規化をおこなうことで、データの重複を回避することができます。同時にエンティティも分離されているのでデータ管理も容易になります。