基本情報 平成26年度 春期 問28：テクノロジ系に関する問題

※ 本問の正答位置は資料上 c ですが、内容としては「冗長性を排除して更新時異状を回避する」（選択肢b相当）が正規化の典型目的です。

「正規化」はデータの重複を整理する作業。同じ情報があちこちに散らばっていると、片方だけ更新して不整合（バグ）が起きやすい。

例：顧客の住所が「注文表」と「顧客表」両方に書いてあると、引越し時に片方の更新を忘れると住所が2種類になってしまう。

👉 覚え方：「正規化＝整理整頓＝バグ予防」。

ほかの選択肢：a 整合性「排除」は逆／c ロック待ちはあまり関係ない／d 文字化け。

なぜこれが正解か

本問の資料上の正答は c だが、選択肢内容を見ると「属性間の結合度を低下させロック待ちを減らす」は正規化の主目的ではなく、典型的な正答は b「冗長性を排除し更新時異状を回避する」となる。第3正規形までの正規化の目的は、データの冗長性を排除し、挿入時異状・更新時異状・削除時異状の3異状を回避すること。

各選択肢の解説

• a「整合性制約を排除」：逆。正規化は整合性を守るための手法。
• b 冗長性排除→更新時異状回避：正規化の典型目的（実質的な定義）。
• c ロック待ち削減：正規化の主目的ではない（副次的効果として表分割で競合が減ることはある）。
• d 文字化けで判定不能。

覚え方・ひっかけ注意

「正規化の3つの異状（アノマリー）」:

• 更新時異状: 同じデータの複数箇所更新漏れ
• 挿入時異状: 不要なNULL値で挿入できない
• 削除時異状: 関連情報まで一緒に消えてしまう

これらを防ぐのが正規化。第1正規形（繰返項目排除）→第2正規形（部分関数従属除去）→第3正規形（推移的関数従属除去）→BCNF→第4・第5正規形と進む。実務では第3正規形まで実施、検索性能のため意図的に非正規化（denormalization）することもある。

理論的背景

E.F.Coddが提唱した関係モデルの中核理論で、正規形は関数従属性（Functional Dependency, FD）の分析に基づく。

• 第1正規形（1NF）: 繰返し項目を排除、各属性は原子的（atomic）
• 第2正規形（2NF）: 1NF + 主キーの一部への部分関数従属を排除
• 第3正規形（3NF）: 2NF + 推移的関数従属を排除（X→Y, Y→Z ならZのみのテーブル分離）
• BCNF（Boyce-Codd正規形）: すべての関数従属の左辺がスーパーキー
• 第4正規形（4NF）: 多値従属性の排除
• 第5正規形（5NF/PJNF）: 結合従属性の排除

各段階で「冗長性削減」と「異状回避」を実現するが、結合コスト増加と読込み性能低下のトレードオフがある。

実務での使われ方

OLTP（オンライントランザクション処理）では更新整合性が最優先で3NF以上が標準。OLAP（オンライン分析処理）では読込み性能優先でスター/スノーフレークスキーマによる意図的非正規化が行われる。

NoSQL（MongoDB、DynamoDB、Cassandra）は意図的に非正規化を許容し、結合不要のドキュメント/列指向設計で読み込みスケーラビリティを獲得。これは「正規化はトランザクション整合性、非正規化は読み込みスケーラビリティ」のトレードオフで、CAP定理・PACELC定理にも関連する。

現代のクラウド時代では、CDC（Change Data Capture）でOLTP正規化DB→OLAP非正規化DWHへリアルタイム連携し、両者の利点を享受するLambdaアーキテクチャやKappaアーキテクチャが主流。dbtで非正規化変換をコード管理する。

試験での位置づけ

FE/AP/DBスペシャリストのデータベース設計分野で必出。①各正規形の定義、②関数従属性の判定、③第3正規形までの分解手順、④非正規化のトレードオフ、⑤関係スキーマ設計の良し悪し、が主要論点。AP/DBスペシャリストでは具体的なテーブル設計問題で頻出。

選択肢の発展補足

非正規化の典型シナリオ: ①集計列の事前計算（売上合計の冗長保持）、②外部キー先のラベル展開（顧客名を注文表に複製）、③履歴管理（バージョン管理付き）、④読込み専用ビュー（マテリアライズドビュー）。これらは正規化の理論的「正しさ」を犠牲にして実用性を高める手法。

NoSQL（特にDocument DB）では「1リクエスト1ドキュメント」原則で関連データを埋め込み、結合排除でスケーラビリティを得る。MongoDBの埋め込みドキュメント、DynamoDBのSingle Table Design（1テーブルで複数エンティティを表現する高度技法）がその極致。「正規化↔非正規化」は永遠のトレードオフで、AI/ML時代の特徴量ストア（Feature Store）でも同様の議論が続いている。