データベース設計をやってみた

前書き

前回はこんな感じでUI設計・機能設計を簡単にやっていきました。
melheaven.hatenadiary.jp

今回はデータ設計に取り掛かろうと思います。

データ設計

データ設計では、以下の3つを決定する必要があるみたいです。

• データの具体的な中身
• データベース設計
• データの流れ

上記に倣って、データ設計に取り組んでいこうと思います。
qiita.com

データの具体的な中身

以下の4種類に大別できることは明白です。

• Webのフォームに打ち込むデータ
• データベースから取得するデータ
• Web画面に表示するデータ
• データベースに格納するデータ

では大まかに必要なデータとは何か・・・。

【ユーザー情報】

• ユーザーID（一意）
• ユーザー名前
• パスワード（Twitter or Google認証を適用したいので不要かも）
• TwitterID
• GithubID
• GoogleID
• ブログURL

今回は1ユーザーにつきページは1つです。よって1対1の関係性です。
でもユーザーIDとページIDは1対1の関係ですが、別にしておいた方が良いかと考えました。
理由は「将来的に1ユーザーにつき複数のページを持つシステムにしたい時に楽だと思った」からです。

あとログイン認証はGoogle or Twitter認証で実装しようと思います。そちらの方が便利でしょう？

【ページ情報】

• ページID（一意）
• 管理ユーザー（ID）
• 現時点で保存されている記事内容（HTML?）
• 公開 or 非公開?
• 更新日時

イマイチ理解しきれていないのは、記事内容をどういう形でDBに保存すれば良いのかです。
理想としては、QiitaやブログのようなHTML・画像・リンクを繋げて一つのWebページにしてくれる機能です。調査しているとCMSがヒットしてきました。次の詳細設計にてこの点は追求しようと思います。

【タグ情報】

• タグID
• タグ名前

【タグとページを結びつける情報】

• タグ=ページID
• タグID
• ページID

タグ検索する時に1回のクエリで全てのページを獲得したい！となった場合に便利なテーブルです。
タグ=ページに一意IDを設定させました。

【いいね！情報】

• いいね！ID
• いいね！するユーザーID
• いいね！されるページID

同様に「いいね！」情報を結びつけるテーブルも準備します。
ひとまずはこんなところでしょうか。

データベース設計

ER図で表現してみました。

ER図

使用アプリはLucid Chartです。
www.lucidchart.com

データの流れ

上記の変更点やデータベース設計から以下のデータフローを作成できました。

UI設計+機能設計+データ設計

ひとまずこんなところでデータベース設計を完了しようと思います。

次回

次回以降は詳細設計に着手しようと思います。