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
1NFから3NF
Search
赤神青空
PRO
August 14, 2026
Video
Programming
35
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
1NFから3NF
赤神青空
PRO
August 14, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【ORM不要論の歴史】運用の問題は、いまの責務論に直結する
akagami
PRO
0
10
【ORM不要論の歴史】なぜ生まれ、20年前に何を言われたか
akagami
PRO
0
15
【高い買い物LT会】初任給で話題の国産フィジカルAIを買った話
akagami
PRO
0
84
【ORM不要論の歴史】「ORM」と呼ばれているものが3つある
akagami
PRO
0
38
【Vitest5.0大解剖】Vitest5.0で消えた記法とAPI
akagami
PRO
0
23
【Vitest5.0大解剖】Vitest5.0で増えた書き方
akagami
PRO
0
32
【Vitest5.0大解剖】Vitest5.0で静かに変わる挙動
akagami
PRO
0
24
【Vitest5.0大解剖】Vitest5.0のTrace View
akagami
PRO
0
26
【Vitest5.0大解剖】Vitest5.0は何が速くなったのか
akagami
PRO
0
28
Other Decks in Programming
See All in Programming
レビュー履歴をAIに食わせて、 Compose移行を加速するs
shihochan
0
270
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
210
AI に Inclusive UI を書かせよう — Design Rules Skill で Compose UI を作り直す
theoriatec2024
1
460
The Good Stuff, Not the Slop: Engineering High-Quality Android Apps with Modern AI Tooling
danybony
1
190
Swift愛好会と私(ウホーイ) / Swift Fan Club and Uhooi
uhooi
0
140
AWS DevOps Agentで インシデント対応をAIに任せたい
honmarkhunt
6
2.5k
異なる設計思想のフレームワークを経験して得た学び
amekuhideki
2
1.5k
XP祭りでしか伝わらないフリップネタ #xpjug
murabayashi
0
110
思考垂れ流し開発 ~音声入力 × AIエージェント × 開発ハーネスによる試行錯誤~
npostring
0
900
20260828_品質と開発生産性を両立させる、AI時代のE2Eテストの考え方
magicpod
0
160
Swift愛好会100回記念 第1回を振り返る
jollyjoester
0
120
GraphRAGのKnowledge Graphを 直接!見る/View-GraphRAG's-KnowledgeGraph-directly!
tyumugi1113
0
240
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
The Invisible Side of Design
smashingmag
301
52k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
270
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Exploring anti-patterns in Rails
aemeredith
3
490
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
230
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
660
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.1k
Making the Leap to Tech Lead
cromwellryan
135
10k
A better future with KSS
kneath
240
18k
Transcript
2026年8月 1NF第n正規形をひととおり から 3NF②まで 赤神青空
▪全4回。今回が実務で使う範囲の本体です このシリーズの地図 01 02 03 04 更新時異常とキーの言葉 注文票を4つの表に分ける BCNF・4NF・5NF 第何正規形かを答える
なぜ正規化するのか 今ココ はじめに 1NF〜3NF 3NF の先 判定演習 2/9
▪出発点は、紙の伝票をそのまま表にした形 第1正規化 — 繰り返しを行にする 第1正規化 繰り返しを⾏に展開する ⾮正規形(紙の伝票のまま) 注⽂番号 注⽂⽇ 顧客ID
顧客名 商品1 単価1 数量1 商品2 単価2 数量2 … / / C C ⾚神 りんご ⽩神 りんご みかん … … 第1正規形(1NF) ⾏に展開 注⽂番号 ★ 注⽂⽇ 顧客ID 顧客名 商品コード ★ 商品名 単価 数量 / / / C C C ⾚神 ⾚神 ⽩神 P P P りんご みかん りんご ⻩⾊い列が、横の繰り返しから縦の⾏になった。これで列の数が商品の件数に左右されない。 主キーは {注⽂番号, 商品コード} の複合キーになる。1件の注⽂が、商品の数だけ⾏に分かれる。 代わりに注⽂⽇‧顧客ID‧顧客名が⾏をまたいで重複しはじめた(⾚いところ)。 列は固定できた。代わりに赤いところが重複しはじめた 今ココ 1NF〜3NF 3/9
▪複合キーの「どこ」で決まるかで行き先が変わる 見分ける① どこで決まるかを見る 決めるもの 決まるもの 注⽂番号だけで決まる 注⽂⽇ 顧客ID 顧客名 注⽂番号
商品コードだけで決まる 商品コード 商品名 単価 両⽅そろって初めて決まる 注⽂番号 + 商品コード 数量 ⾚ = 部分関数従属。キーの⼀部だけで決まっている。ここを別表に切り出す。 緑 = 完全関数従属。複合キー全体が必要なので、明細表にそのまま残す。 赤い2組が切り出す対象。緑は明細にそのまま残る 今ココ 1NF〜3NF 4/9
▪キーの一部で決まる列が、別の表に移る 第2正規化 — どの列が、どこへ移ったか 第2正規化 部分関数従属を切り出す 1つの表 注⽂番号 ★ 注⽂⽇
顧客ID 顧客名 商品コード ★ 商品名 / / / C C C ⾚神 ⾚神 ⽩神 P P P りんご みかん りんご 単価 数量 注⽂ 切り出す 注⽂番号 ★ 注⽂⽇ 顧客ID 顧客名 商品 商品コード ★ 商品名 単価 注⽂明細 注⽂番号 ★ 商品コード ★ 数量 同じ⾊の列が、同じ表に集まる。⾊は⾏き先の印で、良し悪しではない。 ★ の2列は注⽂明細にも残る。切り出した先を指すための列として要るため。 数量だけが両⽅のキーで決まるので、動かさずに明細へ残る。 同じ色の列が同じ表に集まる。1つの表が3つに分かれた 今ココ 1NF〜3NF 5/9
▪注文表の中にまだ従属が隠れている 見分ける② 非キーを経由する連鎖を見る 推移的関数従属 注⽂番号 決める 顧客ID 決める 顧客名 結果として決まってしまう
= 推移的関数従属 主キー → ⾮キー属性 → 別の⾮キー属性 という連鎖。 真ん中で切って、顧客表を独⽴させる。これが第3正規化。 真ん中の顧客IDは、この表の主キーではない 今ココ 1NF〜3NF 6/9
▪経由している列を主キーにした表へ移す 第3正規化 — 注文表の2列が顧客表になる 第3正規化 推移的関数従属を切り出す 注⽂(2NF のとき) 注⽂番号 ★
注⽂⽇ 顧客ID 顧客名 / / C C ⾚神 ⽩神 注⽂ 切り出す 注⽂番号 ★ 注⽂⽇ 顧客ID ◆ 顧客 顧客ID ★ 顧客名 紫の2列が顧客表として独⽴した。商品と注⽂明細は、この操作では変わらない。 顧客IDは注⽂表に残る。残さないと、どの顧客の注⽂か分からなくなるため。 顧客名はどこにも重複していない。改名しても直すのは顧客表の1⾏だけ。 商品と注文明細は、この操作では変わらない 今ココ 1NF〜3NF 7/9
▪紙の伝票1枚が、ここまで分かれた できあがった4つの表 第3正規形(3NF) 紙の伝票1枚が4つの表になった 注⽂ 注⽂番号 ★ 注⽂⽇ 顧客ID ◆
/ / C C 顧客 顧客ID ★ 顧客名 C C ⾚神 ⽩神 商品 商品コード ★ 商品名 単価 P P りんご みかん 注⽂明細 注⽂番号 ★◆ 商品コード ★◆ 数量 P P P ★ = 主キー ◆ = 外部キー。◆ をたどれば、いつでも元の1枚の形に戻せる。 顧客名は顧客表だけ、単価は商品表だけにある。直す場所が1か所に決まった。 重複しているのは注⽂明細の ★ の2列だけで、これは他の表を指すために必要な重複。 実務ではここが到達点。◆ をたどれば元の形に戻せる 今ココ 1NF〜3NF 8/9
▪次回は 今回のまとめ 3NF の先にある正規形を見ます 01 3回とも「元の表 → 操作 → 結果」
紙の伝票1枚が、1NF・2NF・3NF を経て4つの表になった。 02 キーの「どこ」で決まるかを見る 一部で決まれば 2NF、非キーを経由すれば 3NF で切り出す。 03 動かないのが完全関数従属 数量は複合キー全体で決まるので明細に残る。実務での到達点は 3NF。 今ココ まとめ 9/9