Day1 前半 データベースのイメージを「ちゃんと」つくる
プログラミング初心者が最初にやるべきことは、文法を覚えることではなく、「そもそもデータベースって何者なのか」を正しくイメージすることです。ここがあいまいなままSQLに進むと、「なんとなく動くけど、よく分からない」という状態から抜け出せません。今日はまず、頭の中に“正しい模型”を組み立てるつもりで読んでください。
データベースとは何か
情報をきれいに、長期間、安全にしまうための仕組み
データベースは、一言でいうと「大量の情報を、後から取り出しやすい形で整理して保存する仕組み」です。
Excelも表で情報を扱えますが、データベースはもっとシビアな世界を想定しています。
現実のシステムでは、次のような情報がデータベースに入っています。
ネットショップなら、商品情報、在庫数、注文履歴、顧客情報。
SNSなら、ユーザー情報、投稿、コメント、いいね。
会社の業務システムなら、社員情報、勤怠、給与、顧客との取引履歴。
これらは、数千件ではなく、数十万件、数百万件という単位で増えていきます。しかも、同時に多くの人がアクセスし、間違って消えてはいけないし、外部に漏れてもいけない。
この「大量」「同時」「長期間」「安全」という条件を満たすために、データベースという専用の仕組みが必要になります。
SQLとSQLiteの位置づけ
会話の言語と、その相手
ここで登場人物を整理しておきます。
SQLとは何か
SQLは、データベースに対して「こうしてほしい」と命令するための言語です。
人間がデータベースに向かって、次のようなことを指示します。
この条件に合うデータを取り出してほしい。
新しいデータを追加してほしい。
既存のデータを更新してほしい。
不要になったデータを削除してほしい。
これらをすべて、SQLという共通言語で表現します。
「データベースとの会話の言語」と思っておくとイメージしやすいです。
SQLiteとは何か
SQLiteは、「データベースそのものの種類（製品名）」です。
世の中には、MySQL、PostgreSQL、SQL Server、Oracle、SQLite など、さまざまなデータベース製品がありますが、その一つがSQLiteです。
SQLiteの特徴は、インストールが軽く、ファイル一つで完結し、学習や小規模アプリにとても向いていることです。
30日でSQLを身につけるという目的には、かなり相性の良い相棒だといえます。
テーブル・行・列とは何か
ここが分かれば、SQLの半分は怖くなくなる
Day1で一番大事なのは、「テーブル」「行」「列」のイメージを、曖昧さゼロにすることです。
この3つがふわっとしたままだと、どんなSQLを見ても「なんとなく」しか分からなくなります。
テーブルとは
「1種類の情報を入れるための表」
データベースの中には、複数のテーブルが入っています。
テーブルとは、「ある種類の情報だけを集めた表」です。
たとえば、会員情報を管理する users テーブルを考えてみます。
users テーブル
id | name | age | email
---+------------+-----+----------------------
1 | 山田太郎 | 25 | taro@example.com
2 | 佐藤花子 | 19 | hanako@example.com
3 | 鈴木一郎 | 30 | ichiro@example.com
この表全体が users テーブルです。
ここには「会員の情報だけ」を入れます。商品情報や注文情報は、別のテーブルに分けます。
現実のシステムでは、たとえば次のようにテーブルを分けます。
users … 会員の基本情報products … 商品情報orders … 注文情報
このように「1種類の情報につき1テーブル」という考え方が、データベース設計の基本です。
行とは
「1件分のまとまった情報」
行（row、レコード）は、「1件分の情報のまとまり」です。
先ほどの users テーブルでいうと、
1行目は「山田太郎さんの情報」。
2行目は「佐藤花子さんの情報」。
3行目は「鈴木一郎さんの情報」。
現実世界でいうと、「名簿の1行」「顧客カード1枚」「伝票1枚」に相当します。
SQLでは、「この行を追加する」「この行を削除する」といった単位でデータを扱います。
列とは
「そのテーブルで管理したい項目」
列（column、カラム）は、そのテーブルで管理したい「項目」です。
users テーブルには、次の列があります。
id … 会員を識別するための番号
name … 名前
age … 年齢
email … メールアドレス
列は、「このテーブルでは、こういう情報を管理します」というルールを決めているイメージです。
列ごとに「数値だけ」「文字だけ」「日付だけ」といった“型”を決めることもできますが、それはもう少し後のステップで扱います。
行と列が交差する「1マス」が、具体的な値
行と列が交差する1マスには、実際の値が入ります。
2行目 × name列 → 佐藤花子
3行目 × age列 → 30
1行目 × email列 → taro@example.com
SQLでデータを扱うときは、
どのテーブルの、どの列の、どの行の値を触りたいのか、を言葉で正確に指定していきます。
SQLiteで実際にテーブルを作ってみる
テーブルを定義するSQL
ここで、SQLiteで users テーブルを作るSQLを見てみましょう。
CREATE TABLE users (
id INTEGER,
name TEXT,
age INTEGER,
email TEXT
);
この1文で、「users という名前のテーブルを作る」「中には id, name, age, email という4つの列を持つ」という“器”ができます。
行（データ）を追加するSQL
次に、実際のデータを1件追加してみます。
INSERT INTO users (id, name, age, email)
VALUES (1, '山田太郎', 25, 'taro@example.com');
さらにもう1件追加します。
INSERT INTO users (id, name, age, email)
VALUES (2, '佐藤花子', 19, 'hanako@example.com');
中身を確認するSQL
今、テーブルにどんな行が入っているかを確認するには、次のように書きます。
SELECT * FROM users;
実行結果は、次のようなイメージになります。
id | name | age | email
---+------------+-----+----------------------
1 | 山田太郎 | 25 | taro@example.com
2 | 佐藤花子 | 19 | hanako@example.com
ここまでで、
テーブル＝表全体。
行＝1件分の情報。
列＝項目。
1マス＝具体的な値。
という構造が、かなりはっきりしてきたはずです。
セキュリティの視点から見た「テーブルを分ける意味」
なぜ「全部1つの表に入れない」のか
情報セキュリティの観点からも、「テーブルを分ける」というのは非常に重要です。
たとえば、次のような情報を考えてみてください。
会員の基本情報（名前、年齢、メールアドレス）。
ログイン用のパスワードハッシュ。
クレジットカードのトークン情報。
購入履歴。
これらを1つのテーブルに全部詰め込むと、次のような問題が起きます。
アクセス権限を細かく分けられない（本当はカード情報には限られた人だけアクセスさせたい）。
誤ってテーブル全体をダウンロードされたときの被害が最大になる。
バックアップやログの扱いが重くなり、管理が難しくなる。
そのため、現実のシステムでは、
users … 会員の基本情報auth … 認証情報（パスワードハッシュなど）payments … 支払い関連情報orders … 注文情報
のようにテーブルを分けて設計します。
Day1の段階では、「テーブル＝1種類の情報を入れる表」という意識だけ持っていれば十分ですが、その裏にはセキュリティや運用の理由がある、ということも覚えておくと、ワンランク上のエンジニアになれます。
前半のまとめ
データベースは、大量の情報を長期間、安全に扱うための仕組み。
SQLは、そのデータベースに命令するための共通言語。
SQLiteは、学習や小規模システムに向いた軽量なデータベース製品。
テーブルは「1種類の情報を入れる表」。
行は「1件分の情報」。
列は「項目」であり、そのテーブルで何を管理するかを決めるルール。
ここまでが Day1 の「前半」です。
後半では、いよいよ「Excelとの違い」と「集合操作」というSQLの本質を、具体的な例題を使ってじっくり解説します。
