歴史
古代の記録からAI時代のベクトルデータベースまで
データベース技術の進化史：古代の記録からAI時代のベクトルデータベースまで
序文
個人の記録帳の管理といった身近な課題から、人類社会全体の情報を体系化する試みまで、データを効率的に管理したいという欲求は、時代や規模を問わず存在する普遍的な課題です。紙に記録するだけでは、過去のデータの検索や月別の集計といった単純な作業でさえ、膨大な手間を要します。この根源的な課題を解決するために、古代メソポタミアの粘土版による記録管理から、現代の生成AIを支える最新のベクトルデータベースに至るまで、データベース技術が辿ってきた壮大な進化の歴史を体系的に解説します。各時代における社会や技術の要請が、いかにして新たなデータベースの形態を生み出し、それがどのようなイノベーションによって解決されてきたのかを明らかにすることで、現代社会の根幹を成すこの技術の重要性と未来への展望を考察することを目的とします。
——————————————————————————–
データベース前史：電子計算機以前のデータ管理
電子計算機、すなわちコンピュータが誕生する遥か以前から、人類は増え続ける情報を体系的に管理し、再利用するための方法を模索してきました。これらの初期の試みは、現代のデータベース技術とは比較にならないほど原始的でしたが、データを構造化し、機械的に処理するという思想の基盤を形成した点で極めて重要です。このセクションでは、後のデータベース概念の萌芽となった歴史的なデータ管理技術を概観します。
古代の記録媒体：粘土版
人類最古のデータベースと見なせるかもしれない記録媒体は、古代メソポタミアで用いられていた粘土版です。当時、人々は楔形文字を用いて取引記録などを粘土版に刻みつけていました。紙媒体と比較した場合、粘土版は「焼くことで半永久的に保存できる」という顕著な優位性を持っていました。これは、体系的な形で**データ永続性（Data Persistence）という根源的な課題を初めて解決した試みであり、現代のデータベース理論における永続性（Durability）に通じる概念です。そのおかげで、数千年の時を経た現代においても、当時の取引記録が解読され、古代社会の研究に貢献しています。
パンチカードシステムの登場
19世紀後半になると、データ処理の機械化に向けた画期的な発明が登場します。それがパンチカードシステムです。
1890年のアメリカ国勢調査において、膨大なデータを効率的に集計するため、ハーマン・ホレリスがこのシステムを開発しました。紙のカードに穴を開け、その穴の有無や位置によって「男性/女性」といった情報を表現するこの仕組みは、後のコンピュータにおける2進法（0と1）の基礎となる概念を内包していました。これは、情報を機械が解釈できる形式に変換するという、データ処理における大きな一歩でした。ホレリスが設立した会社は、後に巨大IT企業であるIBMへと発展しました。パンチカード自体も非常に息の長い技術となり、1970年代までデータ処理の現場で現役として利用され続けました。粘土版による記録の構造化と、パンチカードによる処理の機械化。これらの前史的技術は、データを体系的に扱い、そこから価値を引き出すというデータベースの基本概念の萌芽であり、やがて来る電子計算機の時代への扉を開く重要な布石となったのです。
——————————————————————————–
初期データベースの黎明期：1950年代～1960年代
1950年代に電子計算機が登場すると、データ管理の世界は大きな変革期を迎えました。しかし、初期のコンピュータがもたらした革新は、同時に新たな課題も浮き彫りにしました。特に、データを記録媒体の先頭から順番にしか読み取れないという逐次的なアクセス方法の限界は、初期コンピューティングの潜在能力を著しく阻害するものでした。この非効率性は、より高度で体系的なデータ管理システム、すなわちデータベース管理システム（DBMS）の登場を促す強い圧力となりました。
磁気テープとシーケンシャルアクセスの限界
初期のコンピュータにおける主要なデータ記録媒体は磁気テープでした。この媒体へのアクセス方法は「シーケンシャルアクセス」と呼ばれ、特定のデータを探すためには、テープの先頭から順番にデータを読み込んでいく必要がありました。例えば、1万件のデータの中から特定の1件を探し出すのに、最悪の場合1万件すべてのデータをチェックしなければならないという非効率性を抱えていました。これは、紙の記録を1枚ずつめくって探すのと本質的に変わらず、コンピュータの計算能力を十分に活かせない大きなボトルネックでした。
階層型データベース
この課題を解決するため、1960年代に最初の本格的なデータベース管理システム（DBMS）である階層型データベースが登場しました。1966年にIBMが開発した「IMS (Information Management System)」がその代表格です。データを木構造（ツリー構造）で管理する方式で、その構造は家系図に例えることができます。例えば、神社の組織図であれば、頂点に神社があり、その下に「拝殿」「賽銭箱」「お守り売り場」といった子要素が連なります。このモデルの根本的な問題点は、「一つのデータ（子）が複数の親を持てない」という厳格な制約でした。例えば、ある「お守り」が”個”である「拝殿」からも”組織”である「お守り売り場」からも販売されるという関係性を表現しようとしても、どちらか一方にしか所属させることができませんでした。これは現実世界の複雑な関係性を表現する上で、重大な制約となりました。
ネットワーク型データベース
階層型の構造的制約を克服するために登場したのがネットワーク型データベースです。このモデルでは、一つのデータが複数の親を持つことが許容されたため、網の目のようなより複雑なデータ関係を表現することが可能になりました。 しかし、その柔軟性は構造の複雑化という代償を伴いました。データを取り出すには、データの物理的な格納場所を示す「ポインタ」を迷路のように辿っていく必要があり、プログラミングは極めて困難になりました。当時のプログラマーたちは、この複雑に絡み合った構造を「スパゲッティコード」と呼び、その扱いに大変苦労したと伝えられています。階層型とネットワーク型の両モデルに共通していたのは、「一度設計したデータ構造の変更が非常に困難」という柔軟性の欠如でした。新しい関係性を追加しようとすると、システム全体の大幅な再設計とプログラムの書き直しが必要となり、変化に対応することが難しかったのです。これらの初期データベースモデルが抱えていた硬直性と複雑性は、開発者たちに大きな負担を強いました。この状況が、より柔軟で、直感的で、使いやすい新たなデータベースモデルの登場を必然とし、次の革命への道筋をつけたのです。
——————————————————————————–
関係モデルの革命：リレーショナルデータベースの時代
1970年、IBMの研究者であったエドガー・F・コッドが発表した論文は、データベースの歴史における真のパラダイムシフトを引き起こしました。彼が提唱した「関係モデル（リレーショナルモデル）」は、データの物理的な格納方法（どう保存されているか）と論理的な構造（どう見えるか）を完全に分離するという画期的な概念を導入しました。これにより、開発者は複雑なデータ構造を意識することなく、必要なデータそのものに集中できるようになり、生産性は飛躍的に向上しました。
関係モデルの誕生とSQL
リレーショナルデータベース（RDBMS）の核心は、そのシンプルさと数学的な厳密性にあります。
基本構造: 全てのデータを数学の「関係（Relation）」理論に基づき、「表（テーブル）」形式で管理します。これは、多くの人が使い慣れているExcelのシートのように、行と列で構成された単純明快な構造です。例えば、賽銭記録であれば「日付」「金額」「参拝者名」といった列（カラム）を持つ表として定義され、一行一行が一件の賽銭記録を表します。
言語の革新: RDBMSの最大の功績の一つが、SQL (Structured Query Language) という問い合わせ言語の登場です。それ以前のモデルでは、データを取り出すために「どうやって（How）」アクセスするかの手順を細かく記述する必要がありました。しかしSQLでは、開発者は**「何が欲しいか（What）」だけを宣言的に記述すればよく**、データベースシステムが最適な方法を自動的に判断してくれます。例えば、「3月の賽銭の合計金額を知りたい」場合、SQLでは以下のように記述するだけで済みます。
SELECT SUM(金額) FROM 賽銭記録 WHERE 月 = 3
これは、手続き的なコーディングを必要とした階層型やネットワーク型とは比較にならないほどの簡潔さと分かりやすさでした。
主要なRDBMSの登場と市場形成
コッドの論文発表後、その理論を実装した商用RDBMSが次々と登場し、巨大な市場を形成していきました。1977年に設立されたRelational Software, Inc.（後のOracle社）が、1979年に世界初の商用RDBMSである『Oracle』をリリース。1982年IBMが「SQL/DS」を発表。1984年Sybase社が製品をリリース。
ACID特性による信頼性の確立
リレーショナルデータベースが金融システムのような高い信頼性が求められる分野で標準となったのは、そのトランザクション処理が「ACID特性」と呼ばれる厳格な原則に基づいているためです。
原子性 (Atomicity): トランザクション（一連の処理）は、「すべて成功」するか「すべて失敗」するかのどちらかであることが保証されます。例えば、100円の賽銭をある賽銭箱から別の箱へ移すという複数ステップの操作は、単一の不可分な単位として扱われます。「元の箱から100円減らす」処理と「新しい箱へ100円加える」処理の片方だけが実行され、お金が消滅したり複製されたりすることはありません。
一貫性 (Consistency): データベースに設定されたルール（制約）が常に守られることを保証します。例えば、「賽銭の金額は0円以上である」というルールが設定されていれば、データベースはマイナス金額をもたらすようなトランザクションを決して許可しません。これは、ソースがユーモラスに指摘するように、神社が参拝者にお金を支払うという矛盾した状態を防ぎます。
独立性 (Isolation): 複数のユーザーが同時にデータベースにアクセスしても、互いの処理が干渉しないことを保証します。これにより、複数の処理が同時に行われても、データが矛盾した状態になることを防ぎます。
永続性 (Durability): 一度正常に完了（コミット）したトランザクションの結果は、システムに障害が発生しても失われないことが保証されます。
このACID特性によって、RDBMSはデータ管理における「信頼性のゴールドスタンダード」としての地位を確立しました。しかし、その厳格さと一貫性を維持するための仕組みは、次の時代、すなわちインターネットの爆発的な普及によってもたらされる超大規模なデータとアクセスを捌く上で、新たな課題に直面することになります。
——————————————————————————–
インターネットの波とNoSQLの台頭
2000年代に入り、インターネットが世界中に爆発的に普及すると、データの世界は新たな局面を迎えます。特に、GoogleやAmazon、Facebookといった、日々膨大な量のデータを生成し、世界中から無数のアクセスを受け付ける巨大ウェブサービスの登場は、従来のリレーショナルデータベースが前提としていたスケーラビリティ（規模の拡張性）の限界を露呈させました。この課題に対応するため、RDBMSの厳格なACID特性をあえて緩和し、分散環境での速度と可用性（いつでも利用できること）を優先する「NoSQL」という新しいデータベースの潮流が生まれました。NoSQLの基本概念とBASE特性
NoSQLは「Not Only SQL」の略であり、特定の一技術を指すのではなく、関係モデル以外のデータベース全般を指す総称です。その多くは、RDBMSのACID特性とは対照的な「BASE特性」と呼ばれる、より緩やかな一貫性モデルを採用しています。
Basically Available (基本的に利用可能): システムの一部に障害が発生しても、システム全体が停止することなく、利用可能な状態を維持します。
Soft State (厳密でない状態): システムの状態は、外部からの入力がなくても時間と共に変化する可能性があり、常に厳密に一貫している必要はないという考え方です。
Eventual Consistency (結果的に一貫性が取れる): データの更新後、すぐにはシステム全体で一貫性が取れていなくても、最終的（Eventually）には一貫した状態に収束するというモデルです
このBASE特性をソーシャルメディアのアナロジーで説明すると、ある投稿が世界中で拡散された際、各地域のユーザーに見える「いいね」の数は数秒間、わずかに異なるかもしれません。システムは速度と可用性を優先し、全てのカウンターが最終的に正しい合計値に収束することを許容するのです。このモデルは銀行の勘定システムには不向きですが、高速な処理が求められる用途には非常に適しています。
主要なNoSQLデータベースの分類と特徴
NoSQLには多種多様なモデルが存在しますが、主に以下の4つのタイプに分類されます。
キーバリュー型:
仕組み: 「キー（鍵）」と「値（バリュー）」という非常にシンプルなペアでデータを保存します。
特徴: 構造が単純なため極めて高速に動作しますが、キーに基づかない複雑な検索は不得意です。
製品例: Redis, Amazon DynamoDB
ドキュメント型:
仕組み: JSONやXMLのような、構造化された文書（ドキュメント）をそのままの形で保存します。
特徴: 人間が読んでも理解しやすい柔軟なデータ構造を持ち、スキーマ（構造定義）を事前に厳密に決める必要がありません。
製品例: MongoDB, CouchDB
カラム指向型:
仕組み: 一般的なデータベースが行単位でデータを保存するのに対し、列（カラム）単位でデータを保存します。
特徴: 「全ユーザーの平均年齢を計算する」といった、特定の列だけを対象とする集計処理を非常に高速に実行できます。
製品例: Cassandra, HBase
グラフ型:
仕組み: データそのものよりも、データ間の「関係性」を表現することに特化しています。
特徴: SNSの友人関係や鉄道の路線図のような、複雑なネットワーク構造を持つデータの扱いに絶大な強みを発揮します。
製品例: Neo4j
巨大テック企業が与えた影響
NoSQL技術の普及において、インターネットを牽引する巨大テック企業の役割は絶大でした。2006年、Googleが自社の分散データベースシステム「Bigtable」に関する論文を、Amazonが同様に「Dynamo」に関する論文を発表すると、業界に大きな衝撃が走りました。さらに2008年には、Facebookが社内で開発したカラム指向型データベース「Cassandra」をオープンソースとして公開。これにより、世界中の多くの企業が最先端の分散データベース技術を無料で利用できるようになり、NoSQLの普及が一気に加速しました。NoSQLの登場は、RDBMSを完全に置き換えるものではありません。むしろ、システムの要件に応じて最適なデータベースを選択するという「適材適所」の考え方をデータベース界にもたらしたという点で、非常に重要な変革でした。この思想は、次のクラウドとNewSQLの時代へと繋がっていきます。
——————————————————————————–
クラウド時代と次世代データベース
2010年代以降、ITインフラの利用形態は、自社で物理的なサーバーを保有・管理するオンプレミス型から、インターネット経由で必要なリソースを利用するクラウドコンピューティングへと大きくシフトしました。このクラウド化の波はデータベースの世界にも及び、世界中にデータを地理的に分散配置する超大規模データベースの実現を技術的・経済的に可能にしました。この新しい環境が、従来のデータベースの常識を覆す新たなアーキテクチャの創出を強力に後押ししました。NewSQL：スケーラビリティと一貫性の両立
クラウド時代がもたらした一つの答えが、「NewSQL」と呼ばれる新しいカテゴリのデータベースです。NewSQLは、NoSQLが持つ水平的なスケーラビリティ（サーバーを増やすことで性能を向上させる能力）と、RDBMSが保証する厳格なACID特性を両立させることを目指しています。その代表格が、2012年にGoogleが発表した「Spanner」です。Spannerは以下の革新的な特徴を備えています。
グローバル分散: 世界中に点在するデータセンターにデータを分散して配置することが可能です。これにより、特定の地域で大規模な災害が発生しても、他の地域のデータセンターでサービスを継続できる、極めて高い災害耐性を実現します。
厳密な一貫性の維持: 地理的に遠く離れた場所にデータが分散していながら、RDBMSと同等の厳密なACID特性を保証します。これは、NoSQLの多くが採用した結果整合性とは一線を画す点です。時刻同期技術: 分散システムにおける最重要課題の一つが、各拠点の時刻を正確に同期させることです。Spannerは「GPSと原子時計」を組み合わせることで、世界中のサーバーの時刻をナノ秒単位で完璧に同期させます。この技術的ブレークスルーにより、地球の裏側にあるデータとの間でも矛盾なく、かつ高速にトランザクションを処理することを可能にしました。
AIとの融合：自己チューニングデータベース
2017年頃からは、データベースとAI（人工知知能）が融合した「自己チューニングデータベース」が登場し始めました。Oracle社のAutonomous Databaseなどがその代表例です。これらのデータベースでは、AIが自律的に次の役割を担います。パフォーマンスの自動最適化、セキュリティパッチの自動適、障害の予測と事前対策。これにより、従来は専門のデータベース管理者が行っていた高度な運用・管理タスクが自動化され、人間はより創造的な業務に集中できるようになります。
ベクトルデータベースとAI検索
そして2020年代、生成AIの急速な発展とともに「ベクトルデータベース」が大きな注目を集めています。画像、文章、音声といった、従来のデータベースでは扱いにくかった非構造化データを、「ベクトル」と呼ばれる高次元の数値の配列に変換して保存します。ベクトル間の距離を計算することで、「この画像に似ている画像を探す」「この文章と関連性の高い文章を見つける」といった、従来のキーワード検索では不可能だった曖昧な類似性検索を極めて高速に実行できます。この能力は、「特定のキャラクターに似た巫女の画像を探す」といった、明示的なタグではなく抽象的な視覚的類似性に基づいた、直感的で強力なクエリを可能にします。高度な生成AIサービスの裏側では、ユーザーの質問や文脈に関連する情報を膨大な知識ベースから瞬時に探し出すために、このベクトルデータベース技術が活用されています。AI時代において、もはや不可欠な技術基盤と言えるでしょう。代表的な製品には、PineconeやMilvusなどがあります。データベースは、もはや単なるデータの格納庫ではありません。クラウドの力を借りて世界中に広がり、AIと融合することで自律的に動作する、インテリジェントな情報基盤システムへと進化を遂げているのです。
——————————————————————————–
データベースとは
データベースの基本的な考え方
「本棚」＝ データベース
資料がぎっしりと詰まった大きな「本棚」がある。この本棚そのものが「データベース」にあたります。データベースとは、たくさんの情報を整理して保管しておくための、大きな入れ物なのです。
「ファイル」＝ テーブル
情報が内容や目的ごとに綺麗に仕分けられ、文房具の「ファイル」に綴じられて並んでいます。この一つひとつの「ファイル」が、データベースでいう「テーブル」です。テーブル（ファイル）は、特定の種類の情報をまとめておくための入れ物だと考えてください。
・顧客情報
・従業員情報
・売上情報
・予約情報
このように、テーブルは「顧客の情報」「売上の情報」といったように、決まったテーマのデータだけを集める場所です。このように情報をテーマごとにきっちり分けることが、後から目的のデータを素早く見つけ出すための第一歩になるのです。
「一枚の書類」＝ レコード
ファイルの中には、情報が書き込まれた紙の書類が、一枚一枚綴じられています。この「一枚の書類」が、データベースにおける「レコード」という単位になります。一つのレコード（一枚の書類）には、一つの完結したデータが記録されています。
例１：「顧客情報」のファイルなら、次のように情報が整理されています。
一 枚 の 紙 に 対し て 1人 の お 客 さん の 情報 が 書か れ て い ます
ファイルに500枚の紙が綴じてあれば、それは500人分のお客様の情報（500レコード）が保管されている、ということになります。
「書類の項目」＝ カラム（列）
「一枚の書類（レコード）」には、書くべき場所が決まっています。例えば、名前を書く欄、住所を書く欄、電話番号を書く欄などです。この「縦の項目」を「カラム」と呼びます。
カラム（列）： データの「種類」を定義します（例：氏名、年齢、入会日）。
レコード（行）： 具体的な「1人分」のデータの集まりです。
「インデックス」＝ 本棚の索引
本棚に500枚どころか、100万枚の書類がある場合、端からめくって探すのは大変です。そこで、データベースには「索引（インデックス）」を作ります。「五十音順のラベル」をファイルに貼っておくことで、コンピューターは一瞬で目的のレコードを見つけ出すことができるのです。
正規化
「顧客情報」と「売上情報」を別のファイルに分ける、これを「正規化」と呼びます。
| なぜ分けるのか？ | 理由 |
| 重複を防ぐ | 同じお客さんが10回買い物をしても、住所を10回書く必要はありません。 |
| 正確性を保つ | お客さんが引っ越した時、1箇所の住所を書き換えるだけで全ての売上データに反映されます。 |
| 容量の節約 | 無駄な書き込みを減らし、ハードウェアのストレージを効率よく使います。 |
RDB（リレーショナルデータベース）
RDBとは「別々のファイル（テーブル）同士を、共通の『鍵』で関連付けて（リレーション）、一つの巨大な情報源として扱う仕組み」のことです。
例えば、あなたがネットショップを運営していると想像してください。
一つの巨大なファイルに「誰が、いつ、何を、いくらで買ったか」をすべて書き込むと、同じ人が買い物をするたびに、その人の住所や電話番号を何度も書かなければなりません。これは書く手間もかかりますし、住所が変わった時の修正も大変です。そこで、ファイルを役割ごとに分けます。
・「顧客テーブル」（顧客ID、名前、住所、電話番号）
・「商品テーブル」（商品ID、商品名、価格）
・「注文テーブル」（注文ID、注文日、顧客ID、商品ID）
「鍵（キー）」
RDBで最も重要なのが、テーブル同士を紐付ける「ID（識別番号）」です。これを主キー（プライマリキー）と呼びます。
・顧客ID「101」は「田中さん」
・商品ID「A-5」は「ノートパソコン」
注文テーブルに「101がA-5を買った」とだけメモしておけば、コンピューターは瞬時に「田中さんがノートパソコンを買ったんだな」と、別々のファイルから情報を引き出して合体させることができます。この「合体させる力」こそが、リレーショナルデータベースの最大の強みです。
SQL
このバラバラのファイルを「合体させて、必要なデータだけ持ってきて！」とコンピューターに命令する時に使う共通言語が SQL（エスキューエル） です。SQLは非常に論理的な言語で、世界中の基幹システム（銀行、予約サイト、SNSなど）のほとんどが、このSQLとRDBの組み合わせで動いています。
Excelで見るデーターベース
データベースについて
Excelのシートがデータベースの「テーブル」というものに相当します(Excelの機能で”テーブル”があり、そちらの方がより相応ですが、今回は広い意味で示しています）。
Excelの行が、データベースのレコード（1件分のデータ）。列が、データベースのカラム（データの項目）。
データベースは「テーブルの分割と結合」にある
データベースでは「情報を正規化（せいきか）する」要は「役割ごとにテーブルを分ける」だけです。例として「顧客名簿兼注文履歴」の 注文日/ 顧客名/ 住所 /電話番号 /商品名 /金額 を一括りにまとめるのではなく、テーブルを分ける。
顧客テーブル
顧客ID /顧客名 /住所 /電話番号
注文テーブル
注文ID /注文日 /顧客ID /商品名 /金額
このようにテーブルを分けることで、この2つのテーブルを「顧客ID」という共通のキーで結びつける（これをJOINと言います）ことで、「○○さんの注文履歴」をいつでも取り出すことができるのです。
JOINが、ExcelでいうところのVLOOKUPやXLOOKUP関数に相当する
データベースとの対話には「SQL」という言語を使う
Excelでは、データを集計するのにピボットテーブルを使ったり、関数をセルに打ち込みます。
データベースでは、SQL（エスキューエル）という専用の言語を使って、データの取り出しや追加、更新を行います。例として「○○さんの注文履歴が知りたい」と思ったら、データベースにこう命令します。
SELECT * FROM 注文テーブル WHERE 顧客ID = ‘×△□×’;
”意訳：注文テーブルから、顧客IDの×△□×のレコードを全部持ってきて”
DatabaseとMaster Dataの違い
データベース：データを格納する「入れ物（システム全体）」のこと。
データを電子的に保存・管理するための仕組みそのものを指し、ソフトウェア（PostgreSQL, MySQLなど）と、データが実際に保存されているファイル群を合わせた全体を「データベース」と呼びます。 Excelのブック（.xlsxファイル）そのものや、そのブックが保存されている共有フォルダやサーバー、と考えると分かりやすいでしょう。
役割としてあらゆる種類のデータ（後述するマスタデータやトランザクションデータなど）をすべて格納し、安全かつ効率的に管理する場所。
データマスタ：その入れ物に入っている「データの種類の一つ（特に重要な基本情報）」のこと。
「マスタ」とも呼ばれます。これは、業務を行う上での基礎となる、中心的な情報のことです。システムの中で「正本」や「台帳」のような役割を果たします。
役割：
・様々な業務データから参照される、基準となるデータ。
・一元管理され、情報の正確性や一貫性を保つためのもの。
特徴：
・あまり頻繁には変更されない。（例：商品が発売されたら登録するが、商品名が毎日変わることはない）
・単体で意味を持つ情報が多い。（例：顧客情報、商品情報、社員情報など）
ExcelでのVLOOKUPやXLOOKUP関数を使う時、検索の参照元にする「一覧表」シートです。
データマスタの役割をよりはっきりさせるために、それと対になるTransaction Data。
トランザクションデータ ：
日々の業務活動によって発生する「出来事」のデータで、一般的に「実績データ」や「履歴データ」と呼ばれます。
役割: 「いつ、誰が、何を、どうした」という活動を記録する。
特徴:
・時間と共にどんどん増え続ける。（例：売上データは毎日追加されていく）
・一度発生したら、基本的には変更・削除されない。（例：過去の売上記録を消したりはしない）
・マスタデータを参照して作られる。
Excelでは日々の売上を入力していく「売上明細」シートがトランザクションデータです。
このシートには、「商品コード」や「顧客ID」を入力しますが、商品名や顧客名は入力しません。VLOOKUPでマスタシートから引っ張ってくる、これが「マスタデータを参照する」ということです。
このように、「データベース」という大きな器の中に、「データマスタ」という基準情報と、「トランザクションデータ」という活動記録が、互いに関連付けられながら格納されているのです。
データベース（データマスタ、←参照するトランザクションデータ）
テーブルの作り方
テーブル作成には、大きく分けて2つの側面があります。
それを実現するための「具体的なSQL構文」（実装）と、どういう構造にするかという「考え方・注意点」（設計思想）です。
テーブル作成時の注意点（設計思想）
① 【最重要】1つのテーブルには、1種類の情報だけを入れる
「顧客の情報」と「注文の情報」は別のテーブルに分けるべき、という考え方です。これを正規化（せいきか）と呼びます。Excelで言うと: 「顧客マスタ」シートと「注文履歴」シートをきっちり分けるのと同じ感覚です。これ データの重複を防ぎ、修正を容易にするためです。
② 各行をユニークに識別できる「主キー」を必ず用意する
テーブル内の各行（レコード）は、人間でいう「個人」のようなものです。同姓同名の人がいるように、データも偶然同じ内容になることがあります。そこで、各行を絶対に重複しない値で識別するための「背番号」が必要になります。これが主キー（Primary Key）です。具体的には customer_idやproduct_idのように、「テーブル名_id」という名前の列を作り、自動で1, 2, 3…と連番が振られるように設定するのが一般的です。
③ 列（カラム）の「データ型」を正しく決める
Excelのセルにも「セルの書式設定」で「数値」「文字列」「日付」などを設定しますよね。データベースでは、これをテーブル作成時に必須で、かつ厳格に決めます。
データの整合性: 「電話番号」の列に「あいうえお」のような文字が入るのを防ぎます。
効率性: 「年齢」を文字列で保存するより数値で保存したほうが、データサイズが小さくなり、計算も速くなります。
代表的なデータ型:
・INTEGER (または INT): 整数（年齢、個数など）
・VARCHAR(n): n文字以内の可変長の文字列（氏名、住所など）
・TEXT: 長い文章
・DATE: 日付（年月日）
・TIMESTAMP: 日時（年月日と時分秒）
・BOOLEAN: 真偽値（True/False）
④ 「NULL（ヌル）を許容するか」を慎重に決める
NULLとは、「データが存在しない」状態を表す特殊な値です。「0（ゼロ）」や「空の文字列（”）」とは全くの別物です。Excelで言うと: 「データの入力規則」で「空白を無視する」のチェックを外す設定に似ています。例えば「会員登録フォーム」で、メールアドレスは必須項目だけど、誕生日は任意入力だとします。この場合、メールアドレスの列は、NULLを許容しない（NOT NULL制約を付ける）。誕生日の列は、NULLを許容する（未入力でもOK）
と設定します。これにより、システムのデータ品質を保ちます。
⑤ テーブル同士を繋ぐための「外部キー」を設定する
「注文テーブル」には「どの顧客からの注文か」を記録するために「顧客ID」の列を設けます。このとき、「顧客テーブル」に存在しない顧客IDが間違って入力を防ぐために、「注文テーブルの顧客ID列は、必ず顧客テーブルの顧客ID列に存在する値しか受け付けません」というルールを設定します。この時の「注文テーブルの顧客ID列」を外部キー（Foreign Key）と呼びます。Excelで言うとVLOOKUPで参照先のリストにない値を検索すると#N/Aエラーが出ますよね。外部キーは、そもそもエラーになるような値を入力段階でブロックする強力な仕組みだと考えてください。これは関連するデータ同士の矛盾を防ぎ、データの整合性を保証するためです。
テーブル作成のSQL構文（実装）
思想が先、構文は後。 まず「どんな情報を」「どう分けて」「どう関連付けるか」を考える。
基本形は CREATE TABLE です
CREATE TABLE テーブル名 (
カラム名1 データ型 制約,
カラム名2 データ型 制約,
…
PRIMARY KEY (主キーにするカラム名),
FOREIGN KEY (外部キーにするカラム名) REFERENCES 参照先テーブル名(参照先カラム名)
);
顧客テーブルと注文テーブルを作ってみる
❶顧客テーブル (customers)
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY, [注意点②] SERIALで連番の主キーを作成
customer_name VARCHAR(100) NOT NULL, [注意点③,④] 100文字以内の文字列、NULLはダメ
email VARCHAR(255) NOT NULL,
address TEXT, 住所は長い可能性があるのでTEXT型。任意なのでNOT NULLは付けない
registered_date DATE NOT NULL DEFAULT CURRENT_DATE [注意点③,④] 登録日。デフォルトで今日の日付が入る
);
SERIAL: PostgreSQLで使われる、自動で連番を生成してくれる便利な型です。(MySQLでは INT AUTO_INCREMENT)
PRIMARY KEY: この列が主キーであることを宣言します。
NOT NULL: この列はNULLを許容しない（必須入力）という制約です。
DEFAULT CURRENT_DATE: 値が指定されなかった場合、自動的にその日の日付が入力されます。
❷ 注文テーブル (orders)
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY, [注意点②] 注文テーブルの主キー
order_date TIMESTAMP NOT NULL, [注意点③,④] 注文日時
customer_id INTEGER NOT NULL, [注意点⑤] 顧客を参照するための外部キー
amount INTEGER NOT NULL, [注意点③,④] 金額
— ここからが外部キー制約の定義
FOREIGN KEY (customer_id) REFERENCES customers(customer_id) [注意点⑤
);
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
このテーブルの customer_id 列は外部キーです。
そして、それは customers テーブルの customer_id 列を参照しています。
これにより、customersテーブルに存在しないcustomer_idをordersテーブルに登録しようとすると、データベースがエラーを出し てブロックしてくれます。