第三正規化の求め方

八王子さん  
(No.1)
DBの第3正規化系の問題がかなり苦手です。
第1正規化が繰り返しなしにしよう…というのは理解できますが、第二第三が意味不明です。
例えば、下記の問題などは具体的にどう考え皆さんは解かれていますか?

https://www.ap-siken.com/s/kakomon/28_haru/q27.html
2023.03.11 09:11
GinSanaさん 
AP プラチナマイスター
(No.2)
>第二第三が意味不明です。

第2は、たとえば従業員IDと従業員の名前を明細とかにもってたとして、
従業員のIDがわかれば従業員の名前が確定する(※これを関数従属する、という)んじゃマスタで引けばいいだろ、というわけで
明細から従業員の名前を外して
従業員のマスタとして分離してやる、という話で

第3は、たとえば
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_db_pm1_qs.pdf
でP8の図4に周辺施設ってテーブル(※ほんとはエンティティという)があるが、
こいつは本文を読むと主キーが施設IDと駐車場IDであることがわかる。
施設IDでカテゴリコードが一意になる(こいつしかない、という意味。本文だと「施設は、いずれか1つのカテゴリに属する」)ので
施設ID→カテゴリコード
という関係になるわけだが
カテゴリ名もあるので
カテゴリコード→カテゴリ名
という関係もある
そうなると、つながっているので
施設ID→カテゴリコード→カテゴリ名
という推移的関数従属性がある、ということになるので
これらを分離してやることで
エンティティA(施設ID、駐車場ID)
エンティティB(施設ID、カテゴリコード)
エンティティC(カテゴリコード、カテゴリ名)
にすることで第3正規形になる。
※難しくいうと、エンティティBは施設ID、駐車場IDで決まる(完全関数従属する、という)ものではなく、
カテゴリコードが施設IDのみで決まる(部分関数従属する、という)ものだから、エンティティAにはいらんだろということで
分離する。
2023.03.11 12:53
GinSanaさん 
AP プラチナマイスター
(No.3)
>例えば、下記の問題などは具体的にどう考え皆さんは解かれていますか?
〔正規化する関係〕
の図を見ると、
①aからbに矢印がのびている
②bからcに矢印がのびている
③aからcに矢印がのびている
④aからdに矢印がのびている
⑤bとdからeに矢印がのびている
というわけだが、
①、③、④からいったん
aを主キーにしてa,b,c,d,eというテーブルがあるとする
②のルールがあるので、cはbから決まるならcはさっきのテーブルにはいらんな、となるので
a,b,d,e
b,c
に分離する
⑤のルールもあるので、eはbとdから決まるならeはさっきのテーブルにはいらんな、となるので
a,b,d
b,c
b,d,e
に分離する
2023.03.11 12:59
jjon-comさん 
AP プラチナマイスター
(No.4)
このサイトでは次のように解説されています。
https://www.ap-siken.com/kakomon/02_aki/q28.html

> "注文番号"と"商品番号"の両方が決まることで
> 全ての属性が一意に定まるため、
> 主キーはこの2つを組み合わせた複合キーとわかります。

> 第2正規化では、複合主キーの部分キーによって
> 一意に定まる属性を別表に移します。
> 設問のリレーションでは以下の4つがこれに該当します。
> ①注文番号→注文日
> ②注文番号→顧客番号
> ③顧客番号→顧客名
> ⑥商品番号→商品名

> 第3正規化では、主キー以外の属性によって
> 一意に定まる属性を別表に移します。
> 1つがこれに該当します。
> ⑤顧客番号→顧客名

----
今回、質問のあった次の〔正規化する関係〕の場合。
https://www.ap-siken.com/s/kakomon/28_haru/q27.html

・主キーは a です。

・これは複合主キーではないので、第2正規化作業の前提を満たしません。
  よって第2正規化を適用しても別表への分離は発生しません。
  現状の〔正規化する関係〕がすでに第2正規化後の形式だとも言えます。

・主キー → 主キー以外の属性 → 属性 という
  間接的な推移関数従属に着目すると次の2つが見つかります。
  a→b→c
  a→{b,d}→e
  これを別表へ分離するのが第3正規化であり、
  この問題では結果として次の3表に分割されます。
  「b→c」の表(主キーは b)
  「{b,d}→e」の表(主キーは b,d の複合キー)
  「a→b と a→{b,d}」の表(主キーは a)
2023.03.11 13:09
八王子さん  
(No.5)
皆様ありがとうございます。
何となく分かったよくなないような…名前に紐付けられたIDみたいな関数従属性の関係のみでできた表にしていくのが第3正規化という事なのですね。
2023.03.12 15:46
pixさん 
AP シルバーマイスター
(No.6)
DBの正規化は慣れないと理解しがたいことが多い概念です。
それならば、
「DBの正規化の方法(HOW)」よりも
「DBの正規化の理由(WHY)」を考えたほうが理解しやすいと思います。

正規化の理由は
  更新時異状の防止(データの不整合の防止)
  情報無損失分解(データの整合性の保証)
であり、
その方法が
  1事実1箇所(1 fact in 1 place)(データの冗長性の排除)
です。

まずは第二、第三正規形を理解する前に「1事実1箇所」を理解した方が
正規化についての理解が速いと思われます。
特に、日常的に利用するエクセルなどのスプレッドシートは二次元テーブルに
「1事実複数箇所」でデータが存在しているケースが多々あります。
これを「1事実1箇所」に分解するイメージができれば、それが正規化を
していることになります。
2023.03.12 16:37
GinSanaさん 
AP プラチナマイスター
(No.7)
必要に迫られないと、分離の概念がわからんというのはあるかもしれません。実際に運用する側でマスタ1つの要素を変えれば済む話が、明細にみんな散らばっててそこも変えなきゃいけない、とかめんどくさいことになればなるべく分離しときたいと思うようになるんじゃないですか。
2023.03.12 20:52

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。

その他のスレッド


Pagetop