RDBについて【正規化、論理学】
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
- 作者: 奥野幹也
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (20件) を見る
この本を読み終わったので、忘れないうちにまとめます。
断定して書いているが、間違っていることもあると思う。
「'---」が付いている行は個人的に感じたこと。
リレーショナルモデルとは、現実世界のデータを「リレーション」と呼ばれる概念を用いて表現するデータモデルのこと。
→データをリレーショナルモデルという考え方を使ってデータを表現する。
'---オブジェクト指向もプログラミングの考え方の1つというイメージだった。
'---RDBはデータの捉え方とそのデータをまとめる方法。
このRDBで最も重要な概念が、リレーション。
SQLにおいてリレーションに相当するものは、テーブル。
リレーショナルモデルでは見出し(Heading)と本体(Body)のペアで構成されている。
この見出しは属性の集合で、本体は属性値の集合である組、タプル(tuple)の集合である。
→属性というのは、名前とデータ型のこと
リレーショナルモデルは集合論に基づいたものであり、論理学に基づいたデータモデルでもある。
論理学は命題(真か偽かを問うもの)を扱う学問。
ある命題の真偽が判明している時、もっと複雑な命題の真偽はどうなのか?がテーマ。
→論理学を何故理解する必要があるのかというと、リレーションは真の命題の集合であると言えるから。
'---JOINが古いクエリではWHEREを使って使用しているのは、これが関係しているのだとわかった。
'---CASEなどの分岐も、命題の結合子(∧とか)と同じ。真のものを抽出したい。
'---量化という言葉を初めて知った。
'---量化は、集団を対象にした真偽値を問うもの。
正規化について
→正規化は、リレーション(テーブル)を扱いやすくするための理論。
正規化理論自体は、リレーショナルモデルそのものの一部ではない。
→理論:ある物事に関して、原理、法則を拠り所として筋道を立てて考えた認識の行動体系。
また、「実践を伴わない理論は役に立たない」のように、実践に対応する純粋な論理的な知識の意でもある。
論理:思考などを進めていく筋道そのもの。また、道理、事柄間の法則的なつながりをいうこともある。
'---理論、論理という言葉は参考書の中でよく出てくる。
'--- ≒ 考え方 という感じで理解していたけども、「筋道の立てられている考え方」と改める。
ここからより本を理解するため、架空のテーブルを作成する。
・これは架空の人格を持つ生き物のの人生をまとめた集合
・連動するアプリケーションがあり、そこで追加、更新、削除ができる
①基本情報テーブル
種別(人間かそうでないか)
性別(男、女、その他)
出身地
居住地
生年月日
候:名前
②エピソードテーブル
名前 →2NFで候補キー追加
西暦 →2NFで候補キー追加
エピソードタイトル
出来事(その年にこの人物の身に起こったこと)
BCNFで変更
②-1
候:名前
候:西暦
候:エピソードタイトル
4NFでさらに変更
②-1_A
候:名前
候:西暦
②-1_B
候:名前
候:エピソードタイトル
②-2
候:エピソードタイトル
出来事(その年にこの人物の身に起こったこと)
③関係性テーブル
名前
所属組織番号
④組織マスタテーブル
候:所属組織番号
候:所属組織名
思いついたのはこのくらい
このテーブル構造で良いのか考える
第1正規形(1NF)
各テーブルに重複が出てこないか?
→同一名の生物が出てこないので、重複はでてこない(と思う)
ちなみにリレーショナルモデルには主キーという概念がない。
候補キー(単にキー)という概念はある。候補キーは、テーブルに含まれる組の値を一位に決められる属性の集合。
また候補キーは、複数の種類を持つこともある。
候補キーは主キーと意味的・機能的には違いはない。候補キーを主キーと呼ぶかは主観の問題。
'---①基本情報テーブルの候補キーはスーパーキー?
各カラムはさらに分解できないか(値のアトミック性)
→名前は名と姓に分解できるが、名前という集合で意味を成せるのでOK
NULLはでないか?
→所属組織番号を持っていない生物がいるかもしれないが、その生物関係性テーブルには登録しない。
また所属組織番号が複数持つ生物が出てくる場合、関係性テーブルは複数登録を可能とする。
第2正規形(2NF)
2NFは候補キーの真部分集合から非キー属性(Non-prime Attribute)への関数従属性を取り除く作業。
→関数従属性とは、Aの値がわかれば、Bの値が求められるということ。
→真部分集合は、部分集合のうちもとの集合自身以外のものを指す。
'---タプル全体としてみれば重複していなくても、一部で重複していて異常が生じそうなものを複数のテーブルへ分解する。
'---真部分集合が解りづらい。候補キー全体としてではなく、ある候補キーから求められる非キー属性の値に異常が出てきそうと言った意味合いかな。{x,y}
②エピソードテーブルが怪しいのではないかと思ったので、考える。
第3正規形(3NF)
推移関数従属性(Transitive Dependency)を取り除く作業。
'---非キー(候補キーでないもの)同士で関数従属性が発生しているものを考える作業。
架空のテーブル群にはなさそうだけども、以下の状態だったとき分解した方がいい。
③関係性テーブル
名前
所属組織番号
所属組織名
'---所属組織番号がわかれば、所属組織名は求めることができるので分解できる。
ボイスコッド正規形(BCNF)
非キー属性から候補キーの真部分集合への関数従属性で分解した方が良いものが無いか考える。
非キーが候補キーになり得てしまわないか?
②エピソードテーブルのエピソードタイトルが候補キーになり得そう。
②エピソードテーブル
名前 →2NFで候補キー追加
西暦 →2NFで候補キー追加
エピソードタイトル
出来事(その年にこの人物の身に起こったこと)
②-1
名前 →2NFで候補キー追加
西暦 →2NFで候補キー追加
エピソードタイトル →BCNFで候補キー追加
②-2
候:エピソードタイトル
出来事(その年にこの人物の身に起こったこと)
第4正規形、第5正規形は結合従属性を取り除く作業。
→結合従属性は、リレーションを分割して再度結合しても値が失われないもの。
第4正規形(4NF)、第5正規形(5NF)
多値従属性(MultiValued Dependency)による正規化とだが、本によるとMVDは特殊なパターンとのこと。
MVDは、テーブルRの項目A、B、Cが次の結合従属性を満たす場合かつその場合に限り、B及びCはAに多値移植するという。
{AB,AC}
'---テーブルに候補キーが3つあった場合、1つの項目によって他2つが求められる場合のことかな
4NFで取り除かれるのは上記のもので、第5正規形(5NF)で取り除かれるものは
{AB,BC,CA}
このようなもの。
'---4NFではAによってのみBとCが求められたが、5NFではA以外でも結合従属性がある時どうするかを考えるものみたい
'---本文を見ると、リレーションの条件はどうであったか、分解したリレーションがこれで良いのかも見ていた。
4NFについて見ると、②-1のテーブルがさらに分解できそう。
②-1_A
候:名前
候:西暦
②-1_B
候:名前
候:エピソードタイトル
'---5NFで分解できそうなものは、架空のテーブルには存在しなかった。
第6正規形(6NF)
可能な限り無損失分解できるか考えるのが6NF。
6NFまで分解したリレーションは無駄な結合が多くなってしまうので、6NFを目指してリレーションの正規化を行うことはない。
'---①基本情報テーブルは6NFを使うと5つに分解できる。けれども確かにそこまでする必要はないかなと思う。
'---考えるとしたら、項目の多すぎるリレーションがあった場合、2つに分解するとか。
以上で正規化を終えた。
①基本情報テーブル
種別(人間かそうでないか)
性別(男、女、その他)
出身地
居住地
生年月日
候:名前
②-1_A
候:名前
候:西暦
②-1_B
候:名前
候:エピソードタイトル
②-2
候:エピソードタイトル
出来事(その年にこの人物の身に起こったこと)
③関係性テーブル
名前
所属組織番号
④組織マスタテーブル
候:所属組織番号
候:所属組織名
以下、個人的な感想
本では他にも重複やNULLを排除する方法、リファクタリング等、DB設計において考える必要な要素について説明がなされている。
どれも重要な内容だが、中でも第二章と第十章が面白かった。
第十章で出てくるグラフ理論というのが、初めて知ったのでこれをさらに勉強したい。
本の中で、とても好きな文章があった(P129)のでそれだけ抜粋して終わりとする。
ところで、ナチュラルキーという言葉は自然という名前からすると、いかにも、この宇宙に最初から存在しているような印象を受けます。
しかし、それは誤解です。
自然界に最初から宇宙の摂理として存在する、ラベルなどというものは存在しません。
物や概念の名称や番号などのラベルは、すべて人間が勝手につけたものです。歴史的経緯に差はあれど、全て人工物であるということは、認識しておいたほうがよいでしょう。
そういう観点で見れば、ナチュラルキーもサロゲートキーも本質的な違いはありません。
過去に他の誰かが割り当てたIDを用いるか、自分でIDを割り当てるかというだけの違いなのです。