- テーブルは表のように表示されるが、”表”ではない。
関係(リレーショナル)したモデルであり、それに一番適した形として表で表現されている
- 主キー
そのテーブルの中でユニークになる値を持つ列。
複数の列を組み合わせて主キーとする”複合主キー”もあります。（主キーが複数あるわけではありません） 外部キー(FKとか記入されていることこも=foreign key)
外部キーで引くことができる値。
それによって外部キーのテーブル（親）で持っていない値を入力できなくする（制約をかける）正規化
テーブルの関係性について
カージナリティ
関係性の数のことです。多対多?
どういうパターンでしょう？
たとえば「学生」と「授業」を関連づけることきに
学生は複数の授業をとることができ、
授業は複数の学生に教えるものです
しかしこの関係のまま設計するのは好ましくありません。
両者が共通するキーを持っていないからです。
学生コードは主キーですが、複数の授業を受けている場合、授業テーブルに複数の同一学生コードがあることになります。
逆もしかり。
そんなときは
関連実態で間にワンクッション挟みます
これを関連実態といいます。
だから関連実態は本当に実態というよりも「表」って感じになるね。紐付け表。
こっから先には物理層(DB内部)
パフォーマンスについて 正規化の副作用
- SQLの中でもJOINは高コストです。多用するとSQLの速度が悪化します。
- SQLの実行方法はDBMSが自動的にきめます。クライアントが指定するのはなにを取って欲しいだけでです。
手続きの方法までは指定しません（非手続き型言語）
パフォーマンスで重要な要素が
– インデックス
と
– 統計情報
です！
インデックス
- B-treeインデックスが平均点高い優等生だよ！
https://en.wikipedia.org/wiki/B-tree
統計情報
これをもとにオプティマイザが最適な手続きを作り、実際にDBとやりとりします。
リレーショナルデータベースの弱点
苦手なデータ構造がある->ノード型のやつ。
NoSqlなどはこれに強い。(制約とのトレードオフ)
最近のコメント