DB設計などについて①
正直どの項目よりも一番興味をひかれるのはこの項目。データベース大好き人間だからかもしれない。
普通に万物を全てDBで表現できるってすごくない？そそられる
定義
table: 定義
データベース 大量の情報を保存し、PCから効率よくアクセスできるように加工したデータの集まり
3層スキーマ DB設計においての3層構造について。3層にすることで変更に対する柔軟性(データの独立性)を保つ
外部スキーマ ユーザ側からみたDB,ビュー
概念スキーマ 開発者絡みたDB,テーブル
内部スキーマ DBManagementSystemから見たDB,データの物理的配置
エンティティ システムにおいて管理する必要があるデータのこと。テーブルの名前になる。
テーブル
共通点のあるレコードの集まりのことをテーブルという
→テーブル名は複数形・複数名詞で書く。
関連のないレコードの寄せ集めはただ二次元表である。
テーブルの構成要素
①行と列
ぱっとイメージはエクセルのあれ。
行：レコード、列：カラムと呼ぶ。
②キーについて。(超重要)
表にはなくてもよいが、テーブルになくてはならないもの。
キーとはある特定のデータを引き出すための鍵となる列のことである。
主に主キーと外部キーがある。
主キー
Primary keyとも呼ぶ。その値を指定すれば必ず一行のレコードを特定できるような列(の組み合わせ)
テーブルにおいて必ず一つ存在し、かつ一つしか存在しない。
またテーブルに重複業は存在できない。
そして複数列を組み合わせなければ主キーを作れないこともある。
外部キー
2つのテーブル間の列同士の関連性を設定する
これにより、テーブルをまたいでデータの参照を行うことができる。
https://gyazo.com/87788b5e3728204268c1f903a6147bd8
また2つテーブルに分けることであるメリットが非参照整合性制約である。
上のDB見てみると、社員テーブルの部署IDが外部キーとなっており、部署テーブルと関連してる。
このときに部署テーブルの部署IDが1,2,3のみの場合、社員テーブルの部署カラムに4を入れることはできない。
これより社員てぶるに対して制約を課している
制約について
上記の非参整合性制約のほかにNOT NULL制約がある。
NULLを禁止する制約
可能な限りNULLの入れる必要のないDB設計にする必要がある。
DB設計の流れ
1.論理設計(概念スキーマの設計)
データを管理するためのデータモデルの設計
2.物理設計(内部スキーマの設計)
DDLによる実装やストレージの構成などの設計
論理設計の流れ
①システムのコアな機能の定義・エンティティの抽出
なんのシステムのためのDBなのかを定義する。
どんなデータを管理するエンティティ(テーブル)が必要かを明確にする。
要件定義と重なるプロセス
②エンティティの定義
エンティティ(テーブル)ごとにどんな属性(カラム)が必要か明確にする。
各テーブルがどのような列を持つのかを定義するプロセス
特にキー(key)という列を決定することが重要
③正規化
テーブルを分割し、データの団長性(無駄・重複)をなくす。
システムの利用がスムーズに行えるようにエンティティを整理するプロセス
④ER図の作成
※じつはエンティティの定義・抽出ができていれば正規化するプロセスが不要になる場合がある。
正規化について
テーブルを分割し、データの団長性(無駄・重複)をなくす。
システムの利用がスムーズに行えるようにエンティティを整理するプロセス
とりあえずテーブルを正規形に整える。と覚える。
正規形 → 保持するデータの重複が排除されたデータ形式 第1正規形〜第5まである。
正規化したテーブルはJOINによる結合で正規化の前の状態に戻せる。＝無損失分解