前回の続き——分けた表の中身を開ける
前回のL-02では、リレーショナルデータベースを「複数の表に分け、キーで関係づける方式」と学びました。今回は、その一枚の表を開けて、いったい何が保存の単位なのかを正確にします。テーブル・行・列・型という基本語をそろえておくことが、この先で扱うキーやSQL、JOINをすべて支えます。まずは言葉の解剖から始めましょう。
このスライドのポイント
- L-02: リレーショナルデータベース＝複数の表に分け、キーで関係づける方式
- 今回はその「一枚の表」を開けて、保存の単位を正確にする
- テーブル・行・列・型の4語が、この先のキー（L-04）・SQL（L-06）・JOIN（L-07）を支える土台になる
テーブル・行・列・型の定義
テーブルとは、1種類の対象を保存する表のことです。経費を保存する表なら、それがexpensesテーブルです。行とは、その表の1件のデータを指します。経費1件が1行で、これはE-09で学んだオブジェクト1個に対応します。列とは、すべての行が共通して持つ属性のことで、金額を表すamountや日付を表すexpense_dateがそれにあたり、E-09のプロパティに対応します。そして列の型とは、その列が受け入れる値の種類のことで、数値・文字列・日付・真偽といった、E-02で学んだ型がデータベースの上に現れたものです。
このスライドのポイント
- テーブル: 1種類の対象を保存する表（経費ならexpensesテーブル）
- 行: 表の1件のデータ（経費1件＝E-09のオブジェクト1個に対応）
- 列: すべての行が共通して持つ属性（amount・expense_date＝E-09のプロパティに対応）
- 列の型: その列が受け入れる値の種類（数値・文字列・日付・真偽＝E-02の型がデータベース上に現れたもの）
なぜ必要か——型は防衛線の最終段
この4つの言葉を持たないと、たとえば金額を入れる列に文字列が混ざった設計を見抜けません。金額のはずの列に「未定」や「約1万」といった文字が入ると、合計も並べ替えも一気に信用できなくなります。E-02で学んだ型は、F-10やJ-06と、アプリの各段階でデータを守る防衛線として続いてきました。列の型は、その防衛線のいちばん奥、保存される直前の最終段にあたります。ここが緩いと、手前でどれだけ確認しても最後に崩れます。
このスライドのポイント
- 4つの言葉がないと「金額の列に文字列が混ざる」設計を見抜けない
- 金額列に「未定」「約1万」などの文字が入ると、合計も並べ替えも信用できなくなる
- E-02の型 → F-10 → J-06 と続いた防衛線の、保存直前の最終段が「列の型」
- ここが緩いと、手前でどれだけ確認しても最後に崩れる
構造——テーブルの解剖図
構造を図で見てみましょう。expensesテーブルは、横方向が列、縦方向が行の格子として描けます。各列の見出しには、amountは数値、expense_dateは日付、というように型のラベルが付きます。1行が経費1件で、下に足していくほどデータが増えます。E-08やE-09で扱った「オブジェクトの配列」を思い出すと、配列全体がテーブル、配列の要素1個が行、要素の中のプロパティが列、ときれいに対応します。
このスライドのポイント
- expensesテーブル＝横方向が列・縦方向が行の格子
- 各列の見出しに型のラベル（amount=数値、expense_date=日付）
- 1行＝経費1件。下に足すほどデータが増える
- 「オブジェクトの配列（E-08/E-09）」との対応: 配列全体＝テーブル／要素1個＝行／要素内のプロパティ＝列
処理の流れ——型が最後の砦になる
型が最後の砦になる様子を具体的に見ます。amount列を数値型で定義しておくと、そこに「abc」という文字列を入れようとしても、データベースが保存自体を拒否します。誤った値がそもそも記録に残らないので、後の集計が守られます。逆に、この列をうっかり文字列型にしてしまうと、その瞬間から集計も大小の比較も信用できなくなります。「9」と「10」が文字として並ぶと、10より9が大きいと判定されることすらあります。だからこそ、金額や日付の列には正しい型を選ぶことが、品質の第一歩になります。
このスライドのポイント
- amount列を数値型で定義 → 「abc」は保存自体が拒否される（データベースが最後の砦）
- 誤った値が記録に残らないので、後の集計が守られる
- 逆に文字列型にすると、その瞬間から集計も大小比較も信用できない
- 例: 文字として並ぶと「9」が「10」より大きいと判定されることすらある
技術サンプル——CREATE TABLE を読む
実際のテーブル定義を見てみましょう。次のCREATE TABLE文は、経費を保存するexpensesテーブルを作る宣言です。各行は「列の名前」と「その型」の組で書かれています。idは連番、user_idは社員を指す番号、amountは金額の数値、expense_dateは日付、approvedは承認済みかどうかの真偽、memoは自由記述の文字列です。読み取るときは、列名の右にある型が、その列の品質を守っている、という点に注目してください。
混同しやすい——行を増やす vs 列を増やす
混同しやすいのが、行と列の違いです。行は1件のデータそのもので、増やせばデータが増えます。列はすべての行が共通して持つ属性で、増やすことは表の設計そのものを変えることを意味します。経費が1件増えるのは行の追加ですが、「備考」という新しい列を足すのは設計変更で、これはL-10で扱うマイグレーションという別の手続きが必要になります。日常では同じ「増やす」でも、意味がまったく違う点を押さえてください。
バイブコーディングでの確認点
バイブコーディングでは、AIが作ったテーブル設計を必ず型の観点で点検します。特に、金額・日付・真偽の列が文字列型になっていないかを確認してください。AIは指定がないと、無難に何でも入る文字列型を選びがちで、それが後の集計崩れの原因になります。質問例としては「このテーブルの各列の型と、その型を選んだ理由を表にしてください」と聞くとよいでしょう。理由まで答えさせることで、型の選択が妥当かどうかを人間が判断できます。
このスライドのポイント
- AIが作ったテーブル設計は、必ず型の観点で点検する
- 特に「金額・日付・真偽の列が文字列型になっていないか」を確認（AIは無難に文字列を選びがち）
- 文字列型のままだと、後の集計崩れの原因になる
- AIへの質問例: 「このテーブルの各列の型と、その型を選んだ理由を表にしてください」——理由まで答えさせて人間が妥当性を判断する
まとめと次回
最後に一問一答です。「経費1件は、テーブルの行と列のどちらでしょうか」。……答えは行です。列は金額や日付といった属性を表します。30秒まとめとして、テーブルは1種類の対象を保存する表、行は1件のデータ、列は属性、そして列の型はデータ品質の第一防衛線でした。次回のL-04では、その行を一意に特定し、表と表をつなぐキーへ進みます。関連資料は「DB設計チェックリスト50」と「DB設計プロンプト50」です。
このスライドのポイント
- 一問一答: 経費1件は、テーブルの行と列のどちら？ → 答: 行（列は金額・日付などの属性）
- 30秒まとめ: テーブル＝1種類の対象を保存する表／行＝1件のデータ／列＝属性／列の型＝データ品質の第一防衛線
- 次回L-04: 行を一意に特定し、表と表をつなぐ「キー」へ
- 関連資料: 「DB設計チェックリスト50」「DB設計プロンプト50」
