たくさんのデータを表の形でキレイに整理して、ダブりなく取り出せるようにする仕組みが「データベース」。試験で問われる関係データベース・キー・ER図・正規化・NoSQLを、身近なたとえと一緒に整理していくわよ。
星見 めい
データベースって、要はExcelの巨大版ってこと?
紫垣 こはる 先生
イメージとしては近いわね。
いま主流の関係データベースは、Excelみたいな表でデータを管理するの。
英語の頭文字でRDBとも呼ぶわ。
蜂谷 まこと
用語を整理しますね。
1枚の表がテーブル、横1行がレコード、縦の列がフィールドです。
テーブル=表、レコード=行、フィールド=列、と覚えると混乱しません。
小夜川 ほのか
んー、行と列ってどっちがどっちか毎回わからなくなるんですぅ…
星見 めい
あー、それあたしもなる!
横長の『行』は漢字も横に広いし、縦の『列』は『リッ』って縦に立ってる感じ、で覚えてるよ。
紫垣 こはる 先生
ふふ、いい覚え方ね。
さて、表が1枚だけならいいけれど、たくさんのデータを扱うと『この行はどれのこと?』と区別したくなるわ。
そこで登場するのがキーよ。
蜂谷 まこと
レコードを1つに特定するための列が主キーです。
学生表なら学籍番号のように、絶対に重複しない列を選びます。
小夜川 ほのか
名前を主キーにしちゃダメなんですかぁ?
蜂谷 まこと
同姓同名がいると区別できなくなるのでダメですね。
だから番号のような確実に重複しない値を使います。
補足すると、主キーには空っぽ(NULL)を入れることも禁止されています。
紫垣 こはる 先生
もう一つ大事なのが外部キー。
たとえば『成績表』に学籍番号を持たせて『学生表』とつなぐ、橋渡しの役よ。
主キー=自分の身分証、外部キー=相手の身分証を控えておく欄、という対比で覚えるといいわ。
星見 めい
なるほど、キーで表どうしを線でつなぐんだ。
その『どの表とどの表がつながってるか』の設計図ってあるの?
紫垣 こはる 先生
鋭いわね。
それがER図よ。
エンティティを箱で、リレーションシップを線で描くの。
蜂谷 まこと
線の両端には『1対1』『1対多』『多対多』といったカーディナリティを書きます。
たとえば『1人の顧客が複数の注文を持つ』なら顧客と注文は1対多ですね。
小夜川 ほのか
箱と線でお絵かきするみたいで、ちょっと楽しそうですぅ。
紫垣 こはる 先生
そうやって整理する一方で、同じデータが何度も書かれる『重複』は厄介なの。
それを取り除く設計が正規化。
第1→第2→第3正規形と段階的に進めるのよ。
星見 めい
重複ってそんなにマズいの?
ちょっとくらいダブってても良くない?
蜂谷 まこと
それが危ないんです。
たとえば顧客の住所が複数行に重複していると、引っ越し時に1か所だけ直し忘れて、表の中で住所が食い違う『更新の矛盾』が起きます。
正規化すれば住所は1か所にまとまるので、直すのも1回で済みます。
小夜川 ほのか
うぅ〜ん…第1とか第2とか、何が違うのか覚えられる気がしないですぅ…
蜂谷 まこと
ざっくりで大丈夫ですよ。
第1正規形は『繰り返し項目をなくす』、第2正規形は『主キーの一部だけで決まる項目を別表に出す(部分関数従属の排除)』、第3正規形は『主キー以外の項目で決まる項目を別表に出す(推移的関数従属の排除)』です。
星見 めい
正規化って、つまり『1つのことは1か所にだけ書く』っていう片付けの考え方なんだね。
紫垣 こはる 先生
まさにそう。
ただし分けすぎると、データを使うとき表どうしを結合する回数が増えて遅くなることも。
そこで性能優先であえて重複を戻す非正規化もあるわ。
星見 めい
へえ、理論どおりが常に正解ってわけじゃないんだ。
理論と実務のバランスってやつだね!
蜂谷 まこと
はい。
最後に、表に当てはめにくい大量データ向けにNoSQLも広がっています。
キーバリュー型・ドキュメント型・グラフ型などがあり、RedisやMongoDBが代表例です。
紫垣 こはる 先生
整理するわね。
データは表で持ち、主キーで1件を特定し、外部キーで表をつなぐ。
ER図で全体を設計し、正規化で重複を消す。
試験ではこの流れと、第1〜第3正規形の違いがよく問われるわよ。
確認クイズ
関係データベースで、別のテーブルの主キーを参照することでテーブルどうしを関連づける列を何と呼ぶか。
- 主キー
- 外部キー
- 候補キー
- インデックス
こたえを見る
正解: 2. 外部キー
正解は外部キー(FK)。別テーブルの主キーを参照し、表どうしを結びつける列です。主キーは自テーブルのレコードを一意に識別する列で、参照する側ではなくされる側。候補キーは主キーになり得る列の候補、インデックスは検索を高速化する索引であり、いずれも表どうしの関連づけを担う列ではありません。