データベースについて(リレーション、正規化、テーブル設計)
データベース入門
データベースとは
サイトの顧客情報や商品情報などのデータを管理する場所
DBの種類
RDB
-
MySQL
無料で使えて、実際の仕事現場でもよく使われている
PostgreSQL
Oracle
どれを使っても基本的な役割は一緒
テーブル/カラム/レコード
-
テーブル
エクセルで言うところのシート
データの種類でテーブルごとに管理をする
-
カラム
エクセルで言うところの列
-
レコード
エクセルで言うところの行
SQLとは
データベースはコマンドで操作する
このデータベースを操作するコマンド(言語)をSQLという
追加、変更、削除など
例:select * from users limit 2 ;
usersのテーブルから2件のデータを表示する
DBの設計#1
DBのリレーション
-
1:n(1:多)
会社情報 : 社員情報
一つの会社に複数の社員が入ることができる
-
n:n(多:多)
社員情報 : サークル
社員一人につき複数のサークルに所属できる
サークルは複数の社員をかかえることができる
-
1:1
社員情報 : 個人情報
社員一人につき一つの個人情報
ER図
IE記法
1:n(1:多)
会社情報 : 社員情報
一つの会社に複数の社員が入ることができる
n:n(多:多)
社員情報 : サークル
社員一人につき複数のサークルに所属できる
サークルは複数の社員をかかえることができる
1:1
社員情報 : 個人情報
社員一人につき一つの個人情報
テーブル同士のリレーション(関係)を表現する
【○】・・・0
【|】・・・1
【鳥の足】・・・n
リレーション関係で親と子の関係がある場合角を丸く表現する
中間テーブル
- n:nのリレーション設計する場合に中間に置くテーブル
- 中間テーブルには余計なカラムを持たせない
- リレーションの橋渡し役
SQLアンチパターン
やってはいけない設計パターンを解説した書籍
【Amazon】https://www.amazon.co.jp/gp/product/4...
ツール
- Cacoo
- MySQL Workbench
DBの設計#2
正規化
データの繰り返しをなくして整理すること
手順は2つ
- 横方向の繰り返しをなくす
- 縦方向の繰り返しをなくす
例:青いカラムのデータが横方向に重複しているデータ
このデータを縦方向に伸びるよう並べ替えて横方向の繰り返しをなくす
項目がグレーのカラムは縦に繰り返しが発生している
この縦方向の繰り返しをなくすために、青いカラムのデータを別テーブルに切り出す
注文番号に紐付けて管理するようにテーブルを分けている
上記のように縦方向の繰り返しをなくすには1:nの関係のテーブルに切り出す
その他の縦の繰り返しをそれぞれ切り出す
DBの設計#3
テーブル設計の手順
-
システム要件を把握
-
システムの要件と機能を明確にすること
要件例:AmazonのようなECサイト
機能例
- フロント画面
- 商品検索
- 商品詳細ページ
- マイページ
- 管理者画面
- ログイン
- 商品管理
- 商品カテゴリー一覧
-
テーブルの概要設計(ラフスケッチ)
- テーブルの一覧と主要なカラムを書き出す
-
闇雲に出さず,機能一覧をみながらシナリオを思い浮かべながら洗い出す
テーブル例
- 店舗テーブル
- 店舗名
- メールアドレス
- パスワード
- 商品カテゴリーテーブル
- カテゴリ名
- 商品テーブル
- 商品名
- 価格
- 在庫
- ユーザーテーブル
- 名前
- 住所
- メールアドレス
- 購入履歴テーブル
- 購入日
- 合計金額
-
テーブルの詳細設計(最終調整)
- 日本語(論理名)を英語名(物理名)に変換(命名規則参照)
-
カラムに型を付ける
-
varcharという型を使う場合、桁数が2の累乗数となる
例:2,4,8,16,32,64,128,256,512...
※256は255にする(256以上だとインデクスが貼れないから)
-
全てのテーブルに( id, created_at, updated_at )というカラムを3点セットで追加する
id
- **プライマリーキー**
- int型 AutoIncrement
- shop_idのような名前にしない
**created_at / uptated_at**
- datetime型
- _date*ではなく*_atと命名
-
ER図を書きながら正規化
-
1:nの関係のn側に外部キーを追加
例:shops |—————○Items
この場合Itemsテーブルにshop_idカラムを追加
外部キー命名規則:相手テーブル名の(単数形_id)
-
ER図を書きながら正規化していく
例:購入履歴テーブル|——○購入履歴明細テーブル|———|商 品テーブル(正規化で購入履歴テーブルから切り出す)
-
n:nの関係のテーブルの間に中間テーブルを持たせる
この場合外部キーは中間テーブルに持たせる
-
インデクスや制約条件をつける
インデクス(検索を早くするためのもの)
- 検索のキーになるカラムに付ける
- プライマリーキーや外部キーにはつけない→自動でつく
**制約**
- 全てのカラムに可能な限りつける
命名規則
- 半角アルファベット、半角数字、アンダーバー
- テーブル名は複数形、カラム名は単数形
- text1,text2のような雑な名前にしない
予約後
- If
- Null
- Limit
- Date など
システム要件を把握
-
システムの要件と機能を明確にすること
要件例:AmazonのようなECサイト
機能例
- フロント画面
- 商品検索
- 商品詳細ページ
- マイページ
- 管理者画面
- ログイン
- 商品管理
- 商品カテゴリー一覧
テーブルの概要設計(ラフスケッチ)
- テーブルの一覧と主要なカラムを書き出す
-
闇雲に出さず,機能一覧をみながらシナリオを思い浮かべながら洗い出す
テーブル例
- 店舗テーブル
- 店舗名
- メールアドレス
- パスワード
- 商品カテゴリーテーブル
- カテゴリ名
- 商品テーブル
- 商品名
- 価格
- 在庫
- ユーザーテーブル
- 名前
- 住所
- メールアドレス
- 購入履歴テーブル
- 購入日
- 合計金額
テーブルの詳細設計(最終調整)
- 日本語(論理名)を英語名(物理名)に変換(命名規則参照)
-
カラムに型を付ける
-
varcharという型を使う場合、桁数が2の累乗数となる
例:2,4,8,16,32,64,128,256,512...
※256は255にする(256以上だとインデクスが貼れないから)
-
全てのテーブルに( id, created_at, updated_at )というカラムを3点セットで追加する
id
- **プライマリーキー** - int型 AutoIncrement - shop_idのような名前にしない **created_at / uptated_at** - datetime型 - _date*ではなく*_atと命名
-
ER図を書きながら正規化
-
1:nの関係のn側に外部キーを追加
例:shops |—————○Items
この場合Itemsテーブルにshop_idカラムを追加
外部キー命名規則:相手テーブル名の(単数形_id)
-
ER図を書きながら正規化していく
例:購入履歴テーブル|——○購入履歴明細テーブル|———|商 品テーブル(正規化で購入履歴テーブルから切り出す)
-
n:nの関係のテーブルの間に中間テーブルを持たせる
この場合外部キーは中間テーブルに持たせる
-
-
インデクスや制約条件をつける
インデクス(検索を早くするためのもの)
- 検索のキーになるカラムに付ける - プライマリーキーや外部キーにはつけない→自動でつく **制約** - 全てのカラムに可能な限りつける
-
予約後はテーブル名やカラム名には使わない
このほかたくさんあるので、一覧を見ておくとよい
制約
-
NOT NULL制約
入力必須になる場合の制約
-
ユニークキー制約
値の重複を防ぐ制約
-
外部キー制約
リレーション先にレコードがあることを保証する制約
Author And Source
この問題について(データベースについて(リレーション、正規化、テーブル設計)), 我々は、より多くの情報をここで見つけました https://qiita.com/dende-h/items/325585289f04d7b05a72著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .