導入
データベースの中身は、突きつめると 表（テーブル） です。横1行が「1件のデータ」、縦の列が「その項目」。ではなぜ、実際の DB は「注文も会員も1つの大きな表」にせず、あえて意味ごとに表を分けるのでしょうか。設計の出発点になる、この「分ける理由」から始めます。
説明
このショップの DB は、会員 users・商品 products・注文 orders などに分かれています。まず会員を見てください。
SELECT * FROM users;もし「注文ごとに会員名・都市まで全部」を1つの表に書いたら、佐藤さんが注文するたびに名前も都市もコピーされます。佐藤さんが引っ越したら、その全部を直さねばならず、1か所でも直し忘れれば「東京の佐藤」と「大阪の佐藤」が混在します。
flowchart LR
U["users（会員）<br/>id・name・age・city"]
O["orders（注文）<br/>id・user_id・ordered_at"]
U -->|"1人が何度も注文<br/>users.id ＝ orders.user_id"| O
そこで、会員の情報は users に一度だけ置き、orders は「誰の注文か」を番号 user_id で指すだけにします。各行を一意に識別する users.id を 主キー（primary key）、それを別の表から指す orders.user_id を 外部キー（foreign key） と呼びます。こうして「重複が出ないよう意味ごとに表を分ける設計」が 正規化（normalization） です。この章以降で、これらを実際に CREATE TABLE で作りながら深めていきます。
やってみよう
SELECT * FROM users; と SELECT * FROM orders; を順に実行し、orders の user_id が users の id を指していることを見比べましょう。「名前を何度も書かず、番号で参照する」――この分け方こそ、設計の基本形です。
演習
商品の一覧 products テーブルの中身を全部表示して、どんな列（項目）を持っているか眺めてみましょう。
ヒント1を見る
SELECT * FROM products;