[{"data":1,"prerenderedAt":112},["ShallowReactive",2],{"unit:shindanshi\u002Fjoho\u002Fkaihatsu\u002Fer-seikika":3},{"unit":4,"drills":90,"related":95,"topicUnits":100},{"id":5,"exam":6,"subject":7,"subjectName":8,"topic":9,"title":10,"tier":11,"hindo":12,"kijunbi":13,"readingMinutes":14,"sources":15,"factcheck":20,"blocks":24,"pairs":38,"drills":50,"links":87},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fer-seikika","shindanshi","joho","経営情報システム","データベースと開発","正規化 — 引っ越し1件で2行直すはめになる前に",1,"A","2026-05-01",5,[16],{"kind":17,"label":18,"url":19},"kokai","日本中小企業診断士協会連合会「令和8年度第1次試験案内」（ER図・正規化はデータベース設計の標準知識。URLは試験科目・制度の確認用）","https:\u002F\u002Fwww.jf-cmca.jp\u002Fattach\u002Ftest\u002Fr08\u002Fr08_1ji_annai.pdf",{"status":21,"date":22,"scope":23},"passed","2026-07-16","独立監査（opus・2026-07-16）: 最重要検証点＝C2（条件網羅）の定義を素材の「すべての条件の真偽の組み合わせ」から標準定義（個々の条件式の真偽をそれぞれ1回以上。全組み合わせは複数条件網羅=MCC）へ修正した当否——権威ソースで「素材が誤り・修正は正当」と確認（素材誤りの上方修正11例目）。Chen記法・正規化3段階・SQL4分類（TRUNCATE=DDL含む）・WHERE\u002FHAVING・ACID・分離レベル両端・スクラム3役と5行事・テスト4段階（UAT=発注側）・境界値分析の例（100と101）・FP法5対象（IFPUG=EI\u002FEO\u002FEQ\u002FILF\u002FEIFと一致）・COCOMO（Boehm1981・3モード）を全数照合し全点正確。ドリル20\u002F20正確・比喩の承認継承忠実・請負\u002F準委任の対応はIPA「モデル取引・契約書」の通説と一致・文字混入ゼロ（483字全て標準日本語漢字）・リンク10件全実在・hindo全一致。S\u002FA\u002FB級ゼロ・C級3点（C0⊂C1⊂C2の簡略化／TCL独立の4分類系／M:Nの層——いずれも試験深度で無害・修正不要と判定）。合格可能性約88%。PASS。",{"hook":25,"question":26,"intuition":27,"rigor":30,"pitfall":33,"jitsumu":36,"payoff":37},"\n        \u003Cp>売上をExcelの1枚の表で管理していると、同じ顧客の住所が注文の数だけ何行も並びます。その顧客が引っ越したら？——\u003Cb>全部の行を直して回る\u003C\u002Fb>ことになり、1行でも直し漏れると「どっちの住所が本当？」という事故（更新異常）が起きます。\u003C\u002Fp>\n        \u003Cp>原因は\u003Cb>同じ情報の重複\u003C\u002Fb>。表を適切に分けて重複をなくす手続きが\u003Cb>正規化\u003C\u002Fb>です。\u003C\u002Fp>","更新異常はなぜ起き、第1〜第3正規形は何を順に排除していくのでしょうか。",{"heading":28,"html":29},"「1つの事実は1か所に」——表を分けるだけで事故が消えます","\n        \u003Cp>解決は単純です——顧客の情報は\u003Cb>顧客テーブル\u003C\u002Fb>に1行だけ持ち、売上テーブルには顧客番号だけ書く。引っ越しは\u003Cb>1か所直せば全部に効く\u003C\u002Fb>ようになります。この「1つの事実は1か所に」を段階的に徹底するのが正規化で、設計図の道具が\u003Cb>ER図\u003C\u002Fb>——\u003Cb>エンティティ\u003C\u002Fb>（実体・長方形）、\u003Cb>リレーションシップ\u003C\u002Fb>（関係・ひし形）、\u003Cb>アトリビュート\u003C\u002Fb>（属性・楕円）で業務の構造を描きます。関係の多重度（カーディナリティ）は1:1・1:N・M:Nで、\u003Cb>M:Nは間に関連テーブルを挟んで\u003C\u002Fb>表現します。\u003C\u002Fp>\n        \u003Cdiv class=\"chorus\">\u003Cspan class=\"chorus-k\">正規化の合言葉\u003C\u002Fspan>\u003Cspan class=\"chorus-t\">\u003Cb>1NF＝繰り返し排除→2NF＝部分関数従属排除→3NF＝推移的関数従属排除\u003C\u002Fb>——順番ごと固定\u003C\u002Fspan>\u003C\u002Fdiv>",{"heading":31,"html":32},"2NFと3NFの違い——「主キーの一部」か「非キーの間」かです","\n        \u003Cp>3段階の中身です。\u003Cb>第1正規形\u003C\u002Fb>＝セルの中の\u003Cb>繰り返しグループを排除\u003C\u002Fb>し、1マス1値にする。\u003Cb>第2正規形\u003C\u002Fb>＝複合主キー（例：注文番号＋商品番号）の\u003Cb>一部だけで決まる列\u003C\u002Fb>（商品番号だけで決まる商品名など）を別表へ——\u003Cb>部分関数従属の排除\u003C\u002Fb>。\u003Cb>第3正規形\u003C\u002Fb>＝主キー以外の列から決まる列（顧客番号→顧客住所のように、非キー経由で芋づる式に決まる列）を別表へ——\u003Cb>推移的関数従属の排除\u003C\u002Fb>です。\u003C\u002Fp>\n        \u003Cp>従属の「出発点」で区別します——\u003Cb>主キーの一部\u003C\u002Fb>から決まってしまうのが部分関数従属（2NFで排除）、\u003Cb>非キーの列\u003C\u002Fb>を経由して決まるのが推移的関数従属（3NFで排除）。\u003C\u002Fp>",{"heading":34,"html":35},"2NFと3NFの「何を排除するか」の入れ替えが最頻出です","\n        \u003Cp>定番の誤り肢は\u003Cb>排除対象の入れ替え\u003C\u002Fb>——「第2正規形では推移的関数従属を排除する」（正しくは\u003Cb>部分関数従属\u003C\u002Fb>。推移的の排除は第3正規形）。順序を崩した「第3正規形にしてから第2正規形にする」も誤り——\u003Cb>1NF→2NF→3NFの順\u003C\u002Fb>は一方通行です。\u003C\u002Fp>\n        \u003Cp>ER図では\u003Cb>記号の帰属\u003C\u002Fb>（ひし形＝リレーションシップ、楕円＝アトリビュート）と、\u003Cb>「M:Nはそのまま実装できる」という誤り\u003C\u002Fb>（関連テーブルが必要）が的になります。\u003C\u002Fp>","\n        \u003Cp>顧問先の「Excel台帳がぐちゃぐちゃ問題」は、正規化の考え方だけで大半が診断できます——顧客の連絡先が請求台帳にも納品台帳にも書いてあるなら、それは更新異常の予備軍。「マスタ（顧客・商品）と明細（取引）を分けましょう」という一言が、ITツール選定より先に効く処方箋です。販売管理システムの導入相談でも、この分離ができているデータは移行がスムーズに進みます。\u003C\u002Fp>","\n        冒頭の問いに答えます。更新異常は同じ事実の重複から起き、第1正規形で繰り返しを、第2正規形で部分関数従属（主キーの一部から決まる列）を、第3正規形で推移的関数従属（非キー経由で決まる列）を順に排除して「1つの事実は1か所に」を実現します（ER図＝長方形・ひし形・楕円、M:Nは関連テーブル）。次は、その整えた表に話しかける言葉——SQLとACIDへ。",[39],{"label":40,"left":41,"right":45,"hinge":49},"第2正規形と第3正規形",{"badge":42,"name":43,"note":44},"2NF","部分関数従属を排除","複合主キーの一部だけで決まる列を別表へ",{"badge":46,"name":47,"note":48},"3NF","推移的関数従属を排除","非キーの列を経由して決まる列を別表へ","従属の出発点が「主キーの一部」か「非キーの列」か。排除対象の入れ替えが最頻出の的です。",[51,62,75,82],{"type":52,"id":53,"prompt":54,"options":55,"correct":60,"explanation":61},"quiz","joho-er-q1","データベースの正規化に関する記述として、最も適切なものはどれか。",[56,57,58,59],"第2正規形では、複合主キーの一部にのみ関数従属する列を分離する（部分関数従属の排除）。","第2正規形では、非キー属性を経由して決まる列を分離する（推移的関数従属の排除）。","第1正規形の目的は、非キー属性間の関数従属をなくすことである。","正規化は第3正規形から始め、第1正規形へ向かって段階的に進める。",0,"\u003Cstrong>正解：ア\u003C\u002Fstrong>　2NF＝部分関数従属の排除です。\u003Cbr>イ＝推移的関数従属の排除は第3正規形の仕事、ウ＝1NFは繰り返しグループの排除、エ＝順序は1NF→2NF→3NFの一方通行。「何を排除するか」の入れ替えが手口です。",{"type":63,"id":64,"prompt":65,"ask":66,"choices":67,"correctKey":72,"explanation":74},"judge","joho-er-j1","「注文番号と商品番号を複合主キーとする明細表で、商品番号だけで決まる商品名を別テーブルに分離した。これは第3正規形への変換にあたる」との記述がある。","この記述は適切か。",[68,71],{"key":69,"label":70},"ok","適切",{"key":72,"label":73},"ng","不適切","\u003Cb>不適切\u003C\u002Fb>です。主キーの\u003Cb>一部\u003C\u002Fb>（商品番号）だけで決まる列の分離は\u003Cb>部分関数従属の排除＝第2正規形\u003C\u002Fb>の仕事です。第3正規形が排除するのは非キー経由の推移的関数従属——出発点で切り分けてください。",{"type":63,"id":76,"prompt":77,"ask":66,"choices":78,"correctKey":69,"explanation":81},"joho-er-j2","「多対多（M:N）のリレーションシップは、リレーショナルデータベースでは間に関連テーブルを設けて2つの1:Nに分解して実装する」との記述がある。",[79,80],{"key":69,"label":70},{"key":72,"label":73},"\u003Cb>適切\u003C\u002Fb>です。学生と講義のようなM:Nは、間に「受講」という関連テーブルを挟んで1:NとN:1に分解します。「M:Nはそのまま実装できる」という肢が定番の誤りです。",{"type":83,"id":84,"prompt":85,"answer":86},"blank","joho-er-b1","ER図の構成要素——エンティティは長方形、アトリビュート（属性）は楕円、〔?〕はひし形で表す。","リレーションシップ（関係。多重度は1:1・1:N・M:N）",[88,89],"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fsql-acid","shindanshi\u002Fjoho\u002Fdodai\u002Fsystem-dx",[91,92,93,94],{"unitId":5,"unitTitle":10,"topic":9,"item":51},{"unitId":5,"unitTitle":10,"topic":9,"item":62},{"unitId":5,"unitTitle":10,"topic":9,"item":75},{"unitId":5,"unitTitle":10,"topic":9,"item":82},[96,98],{"id":88,"title":97},"SQLとACID — 絞ってから集めるか、集めてから絞るか",{"id":89,"title":99},"ERPとDX — 台帳をつなぐ話と、商売を変える話は別物です",[101,102,103,106,109],{"id":5,"title":10},{"id":88,"title":97},{"id":104,"title":105},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmodel","開発モデル — 家を建てるか、試食を重ねるか",{"id":107,"title":108},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Ftest","テスト — 分解して見るか、ハンドルを回して見るか",{"id":110,"title":111},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmitsumori","見積り3法 — 機能で測る、行数で測る、過去に聞く",1784210666928]