2022年5月3日「開発前に知っておきたいデータベースのあれこれ」というイベントを開催しましたが、もっともっと「基本的なところから設計の基礎知識」までを丁寧にお伝えできればなぁ…と思い記事にしました。
「自分のアプリのDBってこれでいいのかな？」って思っている方もおられるようなので、少しでもお役に立てたら幸いです(*^^*)
前回の記事でデータベースのイメージはできたでしょうか？
ここではデータベース設計について…ですが、
「こんな感じかな？エイヤーッ！」てやるものではないので(^^;)
まずは逸る気持ちをいったん落ち着けて、システム開発の流れから確認・・・(^^)/
システム開発
システム開発の流れ
要件定義
どんなシステムを作るのか（仕様）を決める工程です。
クライアントの持つ課題や要望などをヒアリングして、システムでどのように解決できるのかを考えます。（誰が、どのような目的で使うのかを整理する）
設計
要件定義をもとに、それを実現するために段階を分けて具体的な内容を決めていきます。
基本設計／外部設計
どのような機能を持つのか、を決めていきます。
詳細設計／プログラム設計
入出力や印刷の内容、デザイン、必要なデータなど、より具体的に決めていきます。
データベースのテーブルやカラム、制約などもここで決めます。
ここで決まった内容をもとに、開発の工程に入ります。
開発
詳細設計をもとにソフトウエアやデータベースを作ります。
作ったソフトウエアのテストをして、正しく動作するかの確認もします。
運用
作成したソフトウエアを導入・公開します。
またバックアップを取ったり、常に正常に動作するように保つ必要があります（保守）。
それぞれのフェーズとデータベース
要件定義の中のデータベース
- システムの規模からデータ種類（テキスト、画像、動画など）やアクセス量・データ量の増加を見据えて、ストレージ・レスポンスタイムに無理がないように考える。
- 何のデータが必要かを洗い出す。
※ストレージ：HDDやSSDなどデータを保存する場所のこと
レスポンスタイム：ユーザーのアクションに対しシステムが返すまでの時間（入力から出力まで、画面遷移）
設計の中のデータベース（詳細設計）
ソフトウエアの設計と同時にデータベースの設計もここでします。
- どの情報の何の項目が必要なのかを考える。
- 必要なテーブルやそれぞれのテーブルに持たせるデータを網羅して設計に生かす。
- 保存すべきデータに漏れがないか確認する。
- テーブルや項目同士の結びつきを考える。
- それぞれの属性や制限を決める。
開発の中のデータベース
- 詳細設計に基づいてデータベースを実装する
- ダミーデータで動作を検証する
データベースを運用する
- 正しく稼働させる
・仕様で決められたとおりに動いている
・データが壊れていない
・データにアクセスできる→レスポンスタイムが遅くならない - 安全に稼働させる
・物理的脅威：自然災害、盗難、破壊など
・人為的脅威：情報漏洩、データの破損・紛失など
・技術的脅威：マルウェア、セキュリティホール、DoS攻撃など
「正しく、安全に稼働させる」ためには、
- 監視：不具合がないか
- 復旧：バックアップを取っておく
- 維持：アップデートやシステム改修
が必要です。
データベース設計
ここまででシステムの中のデータベース、というのがボンヤリ見えてきたでしょうか？
「では具体的に何をしたらいいのか…」ですよね。
では実際にどうしたらいいのか、何から始めたらいいのか、順番に見ていきましょう(◎_◎)
何が必要なのか？を考える
必要なもの
・変更の可能性があるデータ
・保存する必要のあるデータ
・ログインや管理で必要なユーザー情報
不要なもの
・タイトルや項目名、ロゴや背景などを装飾する画像
「誰が、どういう目的で使うのか」ってとこは大事！ここ忘れないで！！
※データ同士の関係（リレーションシップ）を考えておくと、何が必要か把握しやすいですよ^ ^
参考）リレーションシップの種類
- 1対1
あるデータと結びつくデータは1つだけ、の関係。
この関係は一つのテーブルにまとめられるので、特殊なケースでのみ使われる。
例）ユーザーアカウントとメール設定。 - 1対多
1つのデータに対して複数のデータが関係している場合。
例）SNSユーザーと投稿、作者と制作物。 - 多対多
1つのデータに複数のデータが関連づけられ、また相手側もこちら側の複数のデータが結び付けられている関係。
例）ある授業を受講する学生が複数いる、また学生ひとりひとりが複数の授業を受講する。という関係。
必要なものを洗い出せたら → それぞれのテーブルや属性を考える
必要な項目の整理と分類をする → ER図に書き出して整理する
例）ユーザーテーブル：ユーザーID、ユーザー名、電話番号、メールアドレス・・・
商品テーブル：商品ID、商品名、サイズ、入数、価格・・・
データベースを正規化する
正規化とは・・・データを管理しやすい形（構造）に整えること・データの重複や繰り返しを避けること
- メンテナンスが楽！
- データの容量が減らせる！
- データが汎用的に使える！
↑ これだとデータの修正漏れが発生する可能性も(+o+)
そこで、こうする ↓
第一正規化 → 項目を重複させない
横方向（カラム）は固定されているので、同じ項目が複数回出てくるとカラムが足らなくなります。
データベースにデータを登録するときは、縦方向（レコード）に追加していきます。
第二正規化 → 従属関係のカラムは別のテーブルに分ける
※従属関係：A→B。Aの値が決まると、Bの値も決まる。
下の学生テーブルでいうなら、学生ID1番→平井さん、てこと!(^^)!
こうやって分けておくと、まだ受講する科目が決まっていない学生を前もって登録することもできるし、科目を担当する先生を変更したいときは講師テーブルの一つのレコードだけを変更したらいいですよね(^^)v
第三正規化 → 従属関係にある項目をさらに分ける
ここでは第二正規化で分けたテーブルで、さらに従属関係になっているカラムを別テーブルにします。
従属関係をなくすことで、同じデータが複数のレコードに登録されるのを防ぐことができます。
ということは、ある情報を編集するときには一つの値を変えるだけで、それに紐づくデータ全てに反映されることになります。
※正規化は、必ず行わないといけないというものではありません。
第五正規化までありますが、通常は第三正規化までです。
「データベースで扱いやすい形にする」のが目的なので、場合によってはしないこともあります(=_=)
カラムの型や制約を決める
- 型：数値型、テキスト型、日付型など
- データの長さ
- 制約：初期値を入れるか入れないか、初期値の値、空白を許可するかしないか、値の重複は？など
※データの型は後から変更できないので、よく検討してから決めましょう(?_?)
カラムの型
文字列を扱う型
・「文字」も「数字」も扱えますが、数字も「文字」として扱われるので計算には使えません。
・「固定長」「可変長」があります。
数値を扱う型
・数値を扱う型には種類があります。
・データベース管理システム(RDBMS)によって多少の差があり、大まかには整数を扱う型と小数点を扱う型になります。
・四則演算ができます。
日付や時間を扱う型
・存在しない日付や時間は入力できません。
２種類の値のみを扱う型
・ONかOFFかといった状態を表すときに用いられます。
カラムの型のまとめ
制約
- NULL
「NULL（ヌル）」とは、何も設定されていない状態です。
「空白」でも「0（ゼロ）」でもありません。
「NOT NULL」は、必ず何らかの値が入っていないといけません。 - 一意制(UNIQUE)
同じカラム内に重複する値は許さない、という制約です。
他のレコードと同じ値は格納できません。 - 初期値(DEFAULT)
このカラムに値を設定しなかったら、あらかじめ指定されているデフォルト値が格納されます。 - 参照制約(FOREIGN_KEY)
参照しているテーブルにない値は入れられない、という制約です。 - 連番(AUTO_INCREMENT)
自動で連番を入れます。
最後まで読んでいただいてありがとうございました( ^^) _旦~~
かなり長くなりましたが、データベースを設計するために必要な知識として基本的なことは書いたつもりです。
データベース超初心者の方々の参考にでもしていただけたら(*^^*)
sowaka
大阪市出身。 PEとして20年弱の経験。猫13匹と同居。2022年2月より大分県に移住。
田舎暮らしを満喫中も畑の管理に頭を悩ませ、犬・山羊・鶏を飼いたいと画策中。
Bubble、Softr、Airtable、Studio、Canvaでいろいろやってます。
