前回はデータベースの基本知識についてご説明しましたが、Webアプリケーションを構築するには、データベースが欠かせません。
また、データベースを運用するためには、はじめにデータベース設計が必要です。
そこでここでは、データベース設計の考え方について説明します。
このページの内容をマスターすると、『データベースの論理設計、物理設計の基本的なことを理解している』ということになります。
データベースの論理設計
データベース設計だけに限らず、システム設計全般においては、抽象的・概念的な条件を整理してから、論理的な設計を行い、最後に物理的な設計を行います。
今回は、データベースの論理設計からはじめます。
必要なテーブルを考える
データベースの論理設計のはじめに、必要なテーブルを考えます。
当実習のテーマは、『簡易ブログの構築』です。
そこで必要なテーブルを考えてみると、まずは記事が保存されているテーブルがあればよさそうです。
ここでの結論として、『記事』というテーブルがあればいいとしておきましょう。
テーブル内部の設計
記事テーブルの中には、記事を構成する様々なデータが格納されることになります。
最低限必要なフィールドは、『記事タイトル』『記事本文』あたりでしょうか。
なお、データベース設計においては、管理上の理由から、『（レコードの）通し番号』『（レコードの）更新日時』『（レコードの）作成日時』を全て設けるようにします。（会社ごとにルールが変わってくると思いますが、これはおよそ一般的なルールです）
リストアップすると、以下のようなものになります。
- 通しID
- 記事タイトル
- 記事本文
- 更新日時
- 作成日時
上記で論理設計は終わったものとしましょう。
データベースの物理設計
論理設計が終わったら、システム上に登録するため、物理設計を行います。
ここでは、各情報の物理名と型を決めていきます。
テーブルの物理名決定
今回は記事テーブルだけです。
『posts』ということにしておきましょう。
フィールドの物理設計
前述の論理設計に対し、物理名と型を検討しましょう。
| 論理名 | 物理名 | 型 | サイズ |
|---|---|---|---|
| 通しID | post_id | int | |
| 記事タイトル | post_title | varchar | 100文字 |
| 記事本文 | post_content | text | |
| 更新日時 | post_updated | timestamp | |
| 作成日時 | post_created | timestamp |
その他の考慮事項
データベースの利用に関しては、上記以外にも考慮すべき事項があります。
以下では主要なものについて説明します。
実際の設定については、今後の記事での説明となります。
プライマリーキー（主キー）
上記のテーブル設計においては、通し番号が重複するとシステム的に破綻が生じます。
そこで、あるレコードを一意性（ユニーク性）を示す唯一のフィールドとして、主キーを指定することができます。
基本的に、全てのテーブルについて主キーを設定する必要があります。
通常は『Auto increment』の設定と合わせて使うため、int型またはbigint型になります。
Auto increment
レコードに通しIDを割り当てる際に、毎回SQLを発行して最後のIDを取得するのは面倒な話です。
そこでMySQL（MariaDB）では、特定のフィールドにAuto incrementを指定することで、自動的にIDを割り振っていくことができます。
ユニークキー
主キー以外にも、商品コードや記事コードや会員ログインIDのように、テーブル内でユニークにしたい項目が発生することがあります。
主キーは1テーブルでひとつしか設定できませんので、変わりにユニークキーを設定することになります。
ユニークキーの制約に違反するinsertなどを行うと、処理がエラーとなります。
インデックス
データベースエンジンの運用に当たっては、データ量増加による速度の低下などが課題になります。
そこで、インデックスを作成することで検索性能を早めることができます。
