データベースのテーブルとは何か

データベースのテーブルとは？

英語ではtable。

データベース（データを整理してためておく仕組み）の多くは、この形でデータをしまっておく。

行は1件、列は項目

紙の日報を思い浮かべると、、

日付、担当者、作業区分、時間と、列で並んでいる。

日付	担当者	作業区分	時間

1件を1行に書き、次の1件はその下へ足していく。これがそのままテーブルの形になる。

番号	日付	担当者	作業区分	時間
1	11月4日	佐藤	検査	3.5
2	11月4日	鈴木	梱包	2.0
3	11月5日	佐藤	梱包	4.0

行はレコードとも呼ばれる。

列はカラムとも呼ばれる。

Excelの表と違うところ

Excelのセルには、ふつう何でも書ける。時間の欄に「だいたい3時間」と書いても、誰にも止められない。

テーブルは違う。列ごとに、入れてよいものを先に決めておく（PostgreSQL公式ドキュメント）。

• 数値の列には、数値しか入らない。
• 日付の列には、日付として読めるものしか入らない。
• 空欄を許さない列は、空のままでは登録できない。

決まりに合わないデータは、入口で断られる。

テーブルの値打ちは、この入れるときの厳しさにある。

1行を指さすための番号、主キー

佐藤さんが2人いたら、名前だけではどちらの行か分からない。

そこで、行ごとにほかと重ならない番号を持たせる。この列を主キーと呼ぶ。

社員番号や注文番号が、ちょうどこの役目をしている。

主キーには、重なる値も空欄も入れられない。

重ならないことを一意という。

主キーがあるから、「この1行」と指させる。

表を分けて、番号でつなぐ

日報の1行ごとに、担当者の部署まで書いたとする。

担当者のみならず、同じ部署名を、何百回も書くことになる。

日報の表 (部署まで書いてしまった形)
1  11月4日  佐藤  検査課  3.5
2  11月4日  鈴木  出荷課  2.0
3  11月5日  佐藤  検査課  4.0
...

異動があれば、その全部を直さなければならない。1か所でも直し忘れると、表の中で食い違う。

そこで担当者の情報は、別のテーブルへ分ける。日報の側には担当者の番号だけを残す。

こちらが担当者の表。

担当者番号	名前	部署
101	佐藤	検査課
102	鈴木	出荷課

こちらが日報の表。担当者の欄は番号になった。

番号	日付	担当者番号	時間
1	11月4日	101	3.5
2	11月4日	102	2.0
3	11月5日	101	4.0

番号をたどれば、2つの表を合わせて見られる。「1番の作業をしたのは検査課の佐藤」と分かる。

別の表の番号を指す列は、外部キーと呼ばれる。表にない番号は入れられない（PostgreSQL公式ドキュメント）。

異動があっても、直すのは担当者の表の1行だけで済む。

担当者の表 (ここの1行だけ直す)
101  佐藤  検査課
 |
 v
101  佐藤  出荷課  <-- ここが変わる

日報の表 (直さなくてよい)
1  11月4日  101  3.5
3  11月5日  101  4.0

まとめ・私見

使う際に、入れてよいものが決まっているせいで、最初は断られるのを窮屈に感じるはず。

けど。このテーブルもデータを取るための専用言語SQLがあり、それさえ覚えてしまえば、「うわっ、早いっ」となる。

便利さに感動すること間違いなし。

SQLについては、またいずれ。。

豆知識

• リレーショナルデータベース: データをテーブルで持ち、テーブル同士を値でつなぐ形のデータベース。
• SQL: テーブルのデータを出し入れするための言語。
• PostgreSQL: 無料で使える、リレーショナルデータベースのソフト。
• SQLite: アプリの中に組み込んで使う、小さなリレーショナルデータベース。
• UUID: 別々の場所で作っても重ならないように作られた、長い番号。

歴史

はじまり：置き場所を知らないと取り出せなかった

1960年代、コンピューターが扱うデータの量は急に増えていった（IBM「The relational database」）。

1968年には、アポロ計画の部品を管理するために作られた仕組みが、IBMのIMSとして売り出される（IBM「Information Management Systems」）。

ただ、当時のデータベースは、データの親子関係や保存場所の道順に縛られていた。

欲しいデータを1つ取り出すために、専門家がプログラムを丸ごと書くこともあった（IBM「The relational database」）。

壁と転換点：表にすれば、置き場所を知らなくていい

1970年、IBMの研究者エドガー・コッドが、データを関係づけられる表で持つ考えを論文にした（Codd「A Relational Model of Data for Large Shared Data Banks」）。

データ同士のつながりを、保存場所ではなく、中に入っている値で表す。これが新しかった。

置き場所ではなく、中身の値でつなぐ。

理屈だけでは疑う人が多く、IBMは1973年からSystem Rで実用になるかを試す（IBM「The relational database」）。

表のデータを出し入れする言語のSQLも、このとき育った。1983年には、製品のDB2が出荷される（IBM「The relational database」）。

いま進んでいる開発

• 2025年9月、PostgreSQL 18が公開された。行ごとの番号に使うUUIDを、検索しやすい形で作る機能が入った（PostgreSQL（2025年9月25日））。
• AIが扱う数値の列（ベクトル）を、ほかのデータと同じ表へしまう拡張機能のpgvectorが開発されている（pgvector）。

この先

表で持つデータベースはいま、スマートフォンやブラウザの中でも動いている（SQLite「Most Widely Deployed」）。

1970年の考えが、いまも土台に残っている。次の50年も表のままかは、まだ分からない。