# アプリケーションの設計
# 設計を行う理由
Web アプリケーション開発において、いきなり開発に着手することはありません。まず、どのようなアプリケーションを作るのか、どういった機能が必要かの洗い出しをしていきます。
このセクションでは、想定するユーザ、画面構成、機能の洗い出し(要求要件の整理)、DB (データベース) 設計の順で設計をしていきます。
# 作成するアプリケーションのデモ
# 想定するユーザ
Web アプリケーションには、当然ですが使う人が存在します。本教材で実装する「掲示板アプリ」では、投稿者と閲覧者がいます。
投稿者はひとことを投稿することができます。閲覧者は投稿されたひとことを一覧で見ることができます。
# 画面構成
本教材で実装する掲示板アプリに必要なページは、ひとこと投稿を一覧表示しているメイン画面のみです。
具体的には、上部が入力フォーム、下部が投稿内容表示部となっています。
# 要求要件の整理
- 投稿者がフォームに入力したデータの投稿
- 投稿内容の表示
- 投稿内容の削除
# 投稿者がフォームに入力したデータの投稿
掲示板画面の上部には、ひとことを投稿するフォームがあります。フォームに値を入力した状態で「投稿する」ボタンをクリックすると データベース に値が保存されます。フォームに入力される内容は「投稿者ニックニーム」と「投稿内容」のみで、どちらも必須とし、空の状態でボタンがクリックされると「〇〇を入力してください」のエラーメッセージが表示されます。
【通常時】
【エラー表示時】
# 投稿内容の表示
掲示板画面の下部には、投稿された内容を一覧表示するエリアがあります。表示する内容は投稿者ニックネーム、内容、投稿した時刻の 3 つです。「削除」の文字がクリックされると投稿が削除されます。
# 投稿内容の削除
削除の文字がクリックされると対象の投稿が表示されなくなります。同時に データベース に保存されている投稿内容のデータも削除されます。
# DB 設計
データベースはシステムの土台であり、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。データベース設計に正解はありませんが、より安定したサービスを作るためには、初期の設計段階から様々な点を考慮する必要があります。
# ER 図
DB(データベース) 設計には、ER 図を使います。ER 図とは、Entity Relationship Diagram といい、物(Entity)同士の関係(Relationship)を図にしたものです。
ここでは、簡易的な ER 図を用いて、これから使うデータベースのイメージを膨らませます。
ER 図の作成ツールは様々ありますが、今回は https://app.diagrams.net/ (opens new window) を使用します。
(GoogleDrive (opens new window) が利用できる前提)
本教材で実装する掲示板アプリでは、ユーザの投稿内容が入っているデータを データベース に保存する必要があるため、投稿を意味する posts テーブルを用意し、投稿者名、投稿内容、投稿日時を保存する設計とします。
テーブル名は任意ですが、読んで意味の分かる名前であること、単語の連結には_(アンダースコア)を使う等の命名規則を設けることが一般的です。
掲示板アプリの ER 図の見た目はかなりシンプルですが、大規模なアプリケーションではかなり複雑な図になります。
データの詳細
- id: データごとに割り振る id。(オートインクリメントにすることで、データが新規で作成される度に、 1 を追加した数値を自動で格納できる。)
int型として整数値を保持する。 - author_name: 投稿者の名前。
varchar型として文字列を保持する。 - message: 投稿内容。
text型として別の場所に保存された文字列のポインターを保持する。 - created_at: 投稿日時。
timestamp型として日付と時刻を保持する。
MySQL では varchar 型の文字列はデータベースに直接保存されます。 しかし、 text 型の文字列は、データベースとは別に保存され、データベースにはその保存領域のアドレスを指すポインターのみ保存されます。 そのため、短い文字列であれば varchar を使った方が、効率良く処理できます。今回は、投稿者の名前は短い文字列、投稿内容は長くなることを想定した文字列として型を使い分けています。
データ型 【data type】とは
プログラミング言語などが扱うデータをいくつかの種類に分類し、それぞれについて名称や特性、範囲、扱い方、表記法、メモリ上での記録方式などの規約を定めたもの。