データベースの基礎（表・レコード・キー）｜情報Ⅰ 最強120講義 第90講

こんにちは、数強塾代表の藤原進之介です。この記事は参考書『藤原進之介の最強120講義』の第90講「データベースの基礎（表・レコード・キー）」のWeb版です。共通テスト「情報Ⅰ」での重要度はA（頻出。得点差がつく）、情報Ⅱでの接続先は(3)情報とデータサイエンスです。

データベースの単元は、用語の暗記で終わらせてしまう人が本当に多い分野です。テーブル、レコード、フィールド、主キー、外部キー。言葉だけ覚えても、実際の問題は解けるようになりません。この講ではなぜ表をわざわざ複数に分けるのかを、分けなかったときに何が壊れるかから説明します。 そして、それが情報Ⅱの「正規化」と「SQL」にそのまま化けることまでお見せします。

1. この講の問い

なぜデータベースは、1枚の大きな表にまとめず、わざわざ複数の表に分けて持つのか。

2. 結論

3. なぜそうなるのか

3-1. 情報Ⅰのデータベースは「情報システム」の話として置かれている

まず、国がこの内容をどこに置いているかを見ておきます。高等学校学習指導要領（平成30年告示）解説 情報編で、データベースは情報Ⅰの(4)「情報通信ネットワークとデータの活用」のア(イ)にあります。しかもその直前は家庭内LANの構築の話です。

つまり情報Ⅰのデータベースは「データ分析の道具」としてではなく、ネットワークの上で複数のシステムがデータを共有するための仕組みとして導入されています。第68講のTCP/IPと階層構造の続きにデータベースが置かれている、と読むと配置の意図が見えてきます。

文部科学省が公開している授業用コンテンツ「身近にあるデータベースを学ぼう！」のスライドも、データベースを「データを1つにまとめて、複数のシステムで共有できるようにしたもの」と定義し、コンビニのPOSシステムを題材にしています。この「共有できるようにしたもの」という定義が、そのままこの講の主戦場に直結します。共有するとは、同じ事実を全員が同じ1か所から読むということだからです。

3-2. 表・レコード・フィールドという3語

定義は文部科学省の「情報Ⅰ」教員研修用教材（第4章）のものがいちばん簡潔です。

情報Ⅱの教員研修用教材では、同じものを「行のことをレコード（タプル）、列のことを属性（カラム）という」と書いています。呼び方が2系統あるだけで中身は同じです。

3-3. なぜ1枚の大きな表ではいけないのか

ここが本講の中心です。文房具店の注文記録を、1枚の表にまとめたとします。

一見すると何の問題もありません。むしろ1枚で全部見えるぶん便利に思えます。ところがこの表は、3通りの壊れ方をします。

3つとも原因は同じです。この表には「注文という出来事」と「商品というモノ」という、寿命の違う2種類の事実が混ざっている。 注文は起きたり取り消されたりしますが、商品は注文と無関係に存在します。寿命の違うものを同じ行に載せると、片方を触ったときに必ずもう片方が巻き添えになるのです。

3-4. 表を分けて外部キーでつなぐ

やることは単純です。混ざっている2種類を2枚の表に分け、片方からもう片方を指す。

• 主キー…その表の中で1行を一意に決める列。商品表なら商品ID
• 外部キー…他の表の主キーを指す列。注文表の商品IDは、商品表の商品IDを指している

これで3つの不整合が同時に消えます。

• 値上げは商品表の1行を直すだけ。単価が書いてある場所が世界に1か所しかないので、直し漏れが定義上あり得ない
• 定規は注文が0件でも商品表に登録できる。商品の存在が注文に依存しなくなった
• 注文ID=2を消しても、ノートは商品表に残る

文部科学省の「情報Ⅰ」教員研修用教材も、同じことを蔵書目録の例で書いています。

「正規化」という語は、実は情報Ⅰの教材の段階ですでに出てきます。 ただし情報Ⅰ側にあるのは「表を分けると変更漏れが生じない」という理由だけで、第一正規形から第三正規形へという手順はありません。手順が出てくるのは情報Ⅱと専門教科です。この差については第6章で書きます。

3-5. 主キーが満たすべき3条件と、氏名を主キーにしてはいけない理由

主キーは「行を見分けるための列」ですが、見分けられれば何でもよいわけではありません。

なぜこの3つなのか。主キーは外部キーから指される先だからです。指される側の値が重複していたら、外部キーがどの行を指しているのか決まりません。指される側の値が途中で変わったら、指していた外部キーが行方不明になります。指される側が空欄なら、そもそも指せません。3条件は「指す・指される」という関係を成立させるための最低条件であって、暗記事項ではないのです。

だから氏名を主キーにしてはいけません。 氏名は3条件を全部落とします。

• 一意でない…同姓同名は実在します。仮に山田太郎さんが2人入会したら、片方を登録できなくなる
• 不変でない…改姓する人がいます。氏名を主キーにしていると、改姓のたびに、その氏名を外部キーとして持つ全部の表を直して回ることになる
• NULL不可を保証できない…登録時点で氏名が未確定という場面は現場にあります

会員番号・学籍番号・商品コードのように、その存在を識別するためだけに作った、意味を持たない番号を主キーにする。これが原則です。文部科学省の授業用コンテンツのワークシート（解答編）も、キーという語を使わずに同じことを書いています。

3-6. 表計算ソフトとデータベースは何が決定的に違うのか

「表計算ソフトでも表は作れる。何が違うのか」という質問は、毎年出ます。同じワークシートが短く答えています。

「大規模になると難しい」の中身を具体化すると、3つになります。

トランザクション管理の4つの性質と「同時実行制御及びロック」は、学習指導要領解説 情報編の専門教科情報科「データベース」の項に明記されています。またIPAのITパスポート試験シラバスは、データベース管理システムを「データを構造的に蓄積し，それらの一貫性を保ち，効率的に取り出すための機能を備えたもの」と定義しています。DBMSの本体は「速く探せること」ではなく「一貫性を保つこと」なのです。

4. 手で確かめる

以下はすべて SQLite 3.51.0 で実際に実行し、出力を確認したものです。表名・列名に日本語を使っているのは、情報Ⅰの教員研修用教材のSQL例（SELECT * FROM 書籍 WHERE 作者ID=1001;）に合わせたためです。

4-1. わざと1枚にまとめた表で、3つの不整合を起こす

CREATE TABLE 注文表(注文ID INTEGER, 注文日 TEXT, 商品名 TEXT, 単価 INTEGER, 個数 INTEGER);
INSERT INTO 注文表 VALUES
  (1,'2026-08-01','消しゴム',120,2),
  (2,'2026-08-01','ノート',180,1),
  (3,'2026-08-02','消しゴム',120,3);

更新不整合。値上げのつもりで、注文ID=1の行だけ直してしまいます。

UPDATE 注文表 SET 単価=130 WHERE 注文ID=1;
SELECT DISTINCT 商品名,単価 FROM 注文表 WHERE 商品名='消しゴム';

出力：

商品名|単価
消しゴム|130
消しゴム|120

消しゴムの単価が2つあります。 データベースはこの矛盾に気づきません。この表の構造には、矛盾を禁止する場所がないからです。

削除不整合。ノートの注文を取り消します。

DELETE FROM 注文表 WHERE 注文ID=2;
SELECT DISTINCT 商品名,単価 FROM 注文表;

出力：

商品名|単価
消しゴム|130
消しゴム|120

ノートが消えました。 消したのは注文1件ですが、ノートという商品の情報も一緒に消えています。挿入不整合のほうは、まだ売れていない定規を登録しようとすると、注文IDも注文日も個数も無い行を作るしかない、という形で現れます。「注文の表」に注文でない行が混ざるわけです。

4-2. 表を分けて外部キーでつなぎ直す

PRAGMA foreign_keys = ON;
CREATE TABLE 商品(
  商品ID INTEGER PRIMARY KEY,
  商品名 TEXT    NOT NULL,
  単価   INTEGER NOT NULL
);
CREATE TABLE 注文(
  注文ID INTEGER PRIMARY KEY,
  注文日 TEXT    NOT NULL,
  商品ID INTEGER NOT NULL REFERENCES 商品(商品ID),
  個数   INTEGER NOT NULL
);
INSERT INTO 商品 VALUES(101,'消しゴム',120),(102,'ノート',180);
INSERT INTO 注文 VALUES(1,'2026-08-01',101,2),(2,'2026-08-01',102,1),(3,'2026-08-02',101,3);

PRAGMA foreign_keys = ON; は必須です。SQLiteは外部キー制約が既定でオフで、書き忘れると制約が一切効きません。「制約を書いたから安心」と思い込んだまま壊れたデータが入る、という事故が起きやすいところです。

更新不整合が消える。

UPDATE 商品 SET 単価=130 WHERE 商品ID=101;
SELECT * FROM 商品;
-- 商品ID|商品名|単価
-- 101|消しゴム|130
-- 102|ノート|180

直したのは1行だけ。単価が書いてある場所が1か所しかないので、直し漏れが起こりようがありません。

挿入不整合が消える。注文0件の定規を登録できます。

INSERT INTO 商品 VALUES(103,'定規',250);
SELECT * FROM 商品;
-- 商品ID|商品名|単価
-- 101|消しゴム|130
-- 102|ノート|180
-- 103|定規|250

削除不整合が消える。ノートの注文を消しても商品は残ります。

DELETE FROM 注文 WHERE 注文ID=2;
SELECT * FROM 商品;
-- 商品ID|商品名|単価
-- 101|消しゴム|130
-- 102|ノート|180
-- 103|定規|250

4-3. データベースが「拒否する」ところを見る

構造を整えるだけでなく、DBMSが実際に壊れた書き込みを止めることを確認します。以下はすべてエラーで拒否されました（末尾の数字はSQLiteのエラーコードです）。

INSERT INTO 商品 VALUES(101,'消しゴム(黒)',120);
-- Runtime error: UNIQUE constraint failed: 商品.商品ID (19)
INSERT INTO 注文 VALUES(4,'2026-08-03',999,1);
-- Runtime error: FOREIGN KEY constraint failed (19)
DELETE FROM 商品 WHERE 商品ID=101;
-- Runtime error: FOREIGN KEY constraint failed (19)
INSERT INTO 商品 VALUES(104,NULL,300);
-- Runtime error: NOT NULL constraint failed: 商品.商品名 (19)

上から順に、主キーの重複／存在しない商品IDへの注文／注文から参照されている商品の削除／NOT NULL違反です。型の制約も見ておきます（SQLiteでは STRICT を付けた表で厳密に効きます）。

CREATE TABLE 商品S(商品ID INTEGER PRIMARY KEY, 商品名 TEXT NOT NULL, 単価 INTEGER NOT NULL) STRICT;
INSERT INTO 商品S VALUES(102,'ノート','180円');
-- Runtime error: cannot store TEXT value in INTEGER column 商品S.単価 (19)

表計算ソフトなら「180円」も何事もなく入ります。データベースは入る前に止める。3-6で書いた3つの違いが、そのままエラーメッセージとして出てきました。

4-4. 氏名を主キーにするとどうなるか

CREATE TABLE 会員(氏名 TEXT PRIMARY KEY, 学年 INTEGER);
INSERT INTO 会員 VALUES('山田太郎',1);
INSERT INTO 会員 VALUES('山田太郎',2);
-- Runtime error: UNIQUE constraint failed: 会員.氏名 (19)

同姓同名の別人を登録できません。現実に存在する人を、システムが存在しないことにしてしまう。 主キーの一意性は「現実がそうなっているから満たされる」のではなく、「満たす列を選ばなければならない」制約なのだ、と分かっていただけると思います。

5. 共通テストではこう出る（重要度A）

データベースは、共通テスト情報Ⅰでは単独の大問というより、表を読ませてから何かをさせる型で出ます。データの分析の問題の前提として顔を出すことが多い分野です。出題の型は3つに整理できます（当塾では共通テストの問題文・選択肢・図表は転載していません）。

落とし穴

• レコード（行）とフィールド（列）を逆に覚えている。 ここだけは絶対に固めること
• 「主キーは1列でなければならない」と思い込む。 複数列の組み合わせが主キーになる場合があります
• 「今たまたま重複していない列＝主キー」と判断する。 将来重複しうるか、を考えるのが主キーの選び方です
• 外部キーの向きを逆に覚える。 外部キーは「相手の表に存在する値」しか取れません。逆ではありません
• NULLは「0」でも「空文字」でもない。 値が無いという状態そのものです

練習用の自作問題（本記事オリジナル）

表から取り出した数値をどう要約するかは第83講 代表値（平均値・中央値・最頻値）、2つの列の関係を見る方法は第86講 相関係数で扱っています。

6. 情報Ⅱではこうなる

情報Ⅰと情報Ⅱの差は、この単元でいちばんはっきり出ます。情報Ⅰは「表はこういう構造でできている」を知る。情報Ⅱは「その構造を自分で設計し、言語で操作する」。

6-1. 学習指導要領解説が名指ししているもの

情報Ⅱ(3)「情報とデータサイエンス」のア(ア)の解説に、次の一文があります。

情報Ⅰ側には無い語が2つ入っています。「関係演算」と「データベースの管理や操作を行うプログラミング言語」です。後者が指しているのがSQLで、文部科学省「情報Ⅱ」教員研修用教材 第3章の学習11「データと関係データベース」は「RDBを操作するためにはSQL（Structured Query Language）を使う」と明記しています。前者（選択・射影・結合）は次の講の担当なので、本講では踏み込みません。

6-2. 「表を分ける」が「正規化という手順」になる

情報Ⅰ側にも「テーブルの正規化」という語はありました（3-4）。しかしそこにあるのは理由だけで、手順はありません。手順が出てくるのは専門教科情報科の科目「データベース」で、学習指導要領解説はこう書いています。

同じ節では、データの分析とモデル化としてE-R図、データベース管理システムの働きとして整合性管理・トランザクション管理（原子性・一貫性・独立性・耐久性）・同時実行制御及びロックが挙げられています。情報Ⅰで「1か所にまとめると直し漏れる」と体で理解したことが、名前と手順を与えられて技法になる。 順番が逆ではないことに注意してください。理由を先に理解した人だけが、第一正規形・第二正規形・第三正規形という手順を、意味のあるものとして受け取れます。

6-3. 「主キー」は学習指導要領解説には一度も出てこない

私が今回の調べもので驚いたのはここです。「主キー」「外部キー」という語は、学習指導要領解説 情報編の全文に一度も出てきません。 共通教科（情報Ⅰ・情報Ⅱ）の解説にも、専門教科の記述にもありません。「一意」「参照整合性」も同様に0件でした（PDFを全文検索して確認）。

では受験生が覚えている主キー・外部キーはどこから来ているのか。用語として明示的に規定しているのは、たとえばIPAのITパスポート試験シラバス Ver.6.5（令和8年1月改訂）です。「データベース設計／データの設計」の用語例に、E-R図、コード設計、フィールド（項目）、レコード、ファイル、テーブル（表）、主キー、外部キー、インデックスが並びます。しかも同シラバスは正規化について「データの正規化の必要性（ただし，正規化の詳細な内容は問わない）」と書いており、高校情報Ⅰとまったく同じ深さで止めています。

国の設計として、高校情報Ⅰで求められているのは「なぜ分けるか」までであって、正規形の手順ではない。 だからこの講で時間をかけるべきなのは、第一正規形の定義を暗記することではなく、3-3で見た3つの壊れ方を自分の言葉で言えるようにすることです。

6-4. 表計算の延長線ではなくなる

情報Ⅱ教員研修用教材の学習12「大量のデータの収集と整理，整形」では、Pythonのpandasが登場し、「リレーショナルデータベースのように二つのデータを結合したり，重複データを取り除いたりすることができる」と書かれています。情報Ⅰで手作業だった「表を分ける・つなぐ」が、情報Ⅱではコードになる。 さらに学習11のデータ型の例には Object（blob）＝「図，音声などのデータ」があり、画像や音声も表の1つのフィールドに収まる対象として扱われます。表から行を絞り込むときのAND・OR・NOTについては第43講 論理演算と検索の絞り込みで詳しく書きました。あわせて読むと、構造（本講）と操作（第43講）がつながります。

まとめ

• データベースは「データを1つにまとめて、複数のシステムで共有できるようにしたもの」（文部科学省 授業用コンテンツの定義）
• テーブル＝表、レコード＝行（1件分のデータ）、フィールド＝列（項目・属性）
• 1枚の表に詰め込むと更新不整合・挿入不整合・削除不整合の3つが起きる。原因は「寿命の違う事実が同じ行に混ざっている」こと
• 表を分け、主キーと外部キーでつなぐと3つとも消える。事実が書いてある場所が1か所になるから
• 主キーの条件は一意・不変・NULL不可。氏名は3つとも落とすので主キーにできない
• 表計算との決定的な差は、型の制約・同時アクセスの制御・整合性の保証をシステムが強制するかどうか
• 情報Ⅱでは「関係演算」と「操作言語（SQL）」が名指しされ、専門教科では第一〜第三正規形とE-R図まで進む

出典（すべて2026年8月3日に取得）

• 文部科学省「高等学校学習指導要領（平成30年告示）解説 情報編」平成30年7月
• 文部科学省「高等学校情報科『情報Ⅰ』教員研修用教材」第4章 情報通信ネットワークとデータの活用（令和2年）
• 文部科学省「高等学校情報科『情報Ⅱ』教員研修用教材」第3章 情報とデータサイエンス 前半（令和2年7月）
• 文部科学省「授業・研修用コンテンツ」【情報Ⅰ】学習動画「身近にあるデータベースを学ぼう！」スライド・ワークシート（2023年2月）
• 情報処理推進機構（IPA）「ITパスポート試験 シラバス Ver.6.5」令和8年1月
• SQLの実行環境：SQLite 3.51.0（本記事のSQLはすべて実行して出力を確認しています）

本シリーズの全体像は『藤原進之介の最強120講義』ハブページ、公開済みの各講はシリーズ一覧からご覧いただけます。制度の話は2026年8月時点の情報です。