Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
1NFから3NF
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
赤神青空
PRO
August 14, 2026
Video
Programming
41
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 赤神青空
【AWS AIF対策】AIシステムを守る
akagami
PRO
0
13
【AIニュース】ChatGPT Space とは何か
akagami
PRO
0
20
【AWS AIF対策】透明性と説明可能性
akagami
PRO
0
16
【AIニュース】OpenAI の「dots」とは何か
akagami
PRO
0
22
【AWS AIF対策】責任あるAI
akagami
PRO
0
24
【AWS AIF対策】基盤モデルの評価
akagami
PRO
0
27
【AWS AIF対策】モデルの学習とファインチューニング
akagami
PRO
0
17
【AWS AIF対策】プロンプトエンジニアリング
akagami
PRO
0
17
【AWS AIF対策】RAGとベクトルデータベース
akagami
PRO
0
17
Other Decks in Programming
See All in Programming
スマートフォンでモールス信号を送受信する 〜スマートフォンのLEDとカメラで作る光通信の設計と実装〜
atsuki_seo
0
230
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
130
すこし踏み込む CancellationToken
htkym
2
1.6k
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
13
6.5k
ゲームコントローラやキーボードのファームウェアをSwiftで書く
kishikawakatsumi
1
270
Ghostty + Neovimで作る 透明でカッコ良い開発環境
j341nono
0
150
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
340
The Rails Doctrine Decade
koic
2
490
Security issues being discussed on Web Platforms
petamoriken
0
1.4k
App Storeの外へ──日本のiOSサイドローディング入門 for iOSDC Japan 2026
yuukiw00w
0
300
RAG の “R” を Swift で覗いてみる 〜「意味から探す」検索の仕組み〜
nao_randd
0
120
テストを司るデーモンに会いに行く 〜隔離した仮想マシンでテストを通すまで〜
h1d3mun3
1
620
Featured
See All Featured
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
1k
Embracing the Ebb and Flow
colly
88
5.2k
Typedesign – Prime Four
hannesfritz
42
3.2k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
AI: The stuff that nobody shows you
jnunemaker
PRO
10
1.1k
Believing is Seeing
oripsolob
1
240
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
570
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
470
Documentation Writing (for coders)
carmenintech
77
5.6k
Marketing to machines
jonoalderson
1
5.8k
Speed Design
sergeychernyshev
33
2.1k
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