Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
なぜ正規化するのか
Search
赤神青空
August 14, 2026
Programming
33
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
なぜ正規化するのか
赤神青空
August 14, 2026
More Decks by 赤神青空
See All by 赤神青空
【AWS Dogwood入門】使い分けと、採用するときの注意
akagami
0
7
【AWS Dogwood入門】認可はどこに置かれているか
akagami
0
19
【AWS Dogwood入門】実務向けの7つの型
akagami
0
13
【AWS Dogwood入門】手元で動かしてみた
akagami
0
19
【AWS Dogwood入門】一語だけ違うポリシー
akagami
0
19
【AWS Dogwood入門】イベントと演算子
akagami
0
21
【AWS Dogwood入門】Dogwoodって何?
akagami
0
16
AWSのデータの選び方
akagami
0
22
Auroraは速いRDSではない
akagami
0
69
Other Decks in Programming
See All in Programming
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
620
<title><a id="</title>君はこのHTMLをパースできるか"></a></title> #雑LT_study
pizzacat83
0
180
バグを直したら useEffect が消えた
colorful12
3
700
Japan Community Day at Kubecon + CloudNativeCon Japan 2026: Learning Container Privilege Control by Building My Own Low-Level Container Runtime
ternbusty
1
170
異なる設計思想のフレームワークを経験して得た学び
amekuhideki
1
520
まだ間に合う!今年の夏こそSchemeのマクロ展開器を完全理解!
omasanori
0
500
いまどきの Codex で開発する visionOS アプリの開発スタイルについて
karad
0
160
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
240
Loosening the Reins: Go Generics Get More Flexible
kuro_kurorrr
0
330
tsc.rip を支える技術 / Kyoto.なんか #8
susisu
0
280
jsmini JavaScript Engine を作ってみた話
yosuke_furukawa
PRO
0
350
Hono + Inertia + React で LP を構築した話
oukayuka
2
160
Featured
See All Featured
Speed Design
sergeychernyshev
33
2k
エンジニアに許された特別な時間の終わり
watany
108
250k
Site-Speed That Sticks
csswizardry
13
1.5k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
220
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
290
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.5k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
3
1.1k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
660
My Coaching Mixtape
mlcsv
0
280
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
390
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Transcript
2026年8月 なぜ正規化するのか 第n正規形をひととおり ① 赤神青空
▪全4回。今回は目的と言葉を揃える回です このシリーズの地図 01 02 03 04 更新時異常とキーの言葉 注文票を4つの表に分ける BCNF・4NF・5NF 第何正規形かを答える
なぜ正規化するのか 今ココ はじめに 1NF〜3NF 3NF の先 判定演習 2/8
▪読みやすくするためではない 正規化は更新のための整理 正規化が守っているのは「1つの事実は1か所にしか書かない」という状態であ る。 同じ事実が散る 商品名が変わると、その商品の明細を全部直す。漏れれば2 つの名前が残る。 同じ事実が1行にある 商品表の1行を直すだけ。漏れようがないので矛盾も起きな い。
正規形の段が上がるほど、この状態に近づく。 今ココ 目的 3/8
▪まとめて更新時異常と呼ばれるもの 詰め込んだ表で起きる3つの異常 01 更新異常 — 直し漏れが矛盾になる 同じ単価が何行にも書かれていると、一部だけ古い値のまま残る。 02 挿入異常 —
登録したいのにできない 注文がまだ無い新商品を、注文表しか無ければ登録する場所がない。 03 削除異常 — 消したくないものまで消える 最後の注文を削除すると、その商品の単価まで一緒に失われる。 今ココ 目的 4/8
▪主キー・複合キー・非キー属性・外部キー 先にキーの言葉を揃えます 注⽂明細 注⽂番号 ★ 商品コード ★◆ P P P
数量 外部キー 商品 商品コード ★ P P 商品名 記号の読み⽅ ★ = 主キー。⾏を1つに決める列。 主キーが2列以上のとき、複合キーと呼ぶ。この例は2列。 主キーに⼊らない列(数量‧商品名)が⾮キー属性。 ◆ = 外部キー。ほかの表の主キーを指す列。 外部キーの値は、参照先の表に必ず存在していなければならない。 外部キーだけが表をまたぐ。ほかは1つの表の中の話。 りんご みかん ★ が主キー、◆ が外部キー。この4語だけ今日は使います 今ココ 目的 5/8
▪正規形の定義はすべてこの言葉で書かれている 関数従属という言葉 「A が決まれば B が1つに決まる」を A → B と書く。
完全関数従属 … 複合キーの全体が揃って初めて決まる 部分関数従属 … キーの一部だけで決まる(2NF で外す) 推移的関数従属 … 非キーを経由して決まる(3NF で外す) この3つを見分けられれば 3NF までは機械的に進む 今ココ 目的 6/8
▪注文票を1枚に詰め込むと、決まり方の違う列が同居する 3つを1つの表で見る 注文番号・商品コード・注文日・顧客ID・顧客名・商品名・単価・数量が1つの 表にある。 完全関数従属 {注文番号, 商品コード} → 数量。両方そ ろって初めて決まる。
今ココ 目的 部分関数従属 商品コード → 商品名。キーの一部だけ で決まっている。 推移的関数従属 注文番号 → 顧客ID → 顧客名。非キーを 経由して決まる。 7/8
▪次回はこの言葉を使って表を分解します 今回のまとめ 01 目的は更新時異常の防止に尽きる 読みやすさのためではない。1つの事実を1か所に置くための整理。 02 防いでいるのは更新・挿入・削除 同じ事実が散っていることが、3つすべての原因になっている。 03 定義は全部「関数従属」で書かれる
完全・部分・推移の3つを見分けられれば 3NF までは進める。 今ココ まとめ 8/8