データベースの「テーブル」とオブジェクト指向の「クラス」が
「個別でデータを管理する」
という性質を持っているので、親和性が高いと言う話。
名前や型、データ構造を一緒にしておけば、とても便利に使えます。
1️⃣ 共通点の背景
- どちらも「現実世界のモノや概念」をプログラムやデータとして扱うための道具です。
- クラスはオブジェクト（実体）を作る「設計図」であり、
属性（データ）と振る舞い（メソッド）を持ちます。 - テーブルは行（レコード）として実体データを持ち、
列（カラム）がその属性を定義します。
つまり、現実のものごとを分かりやすく整理して扱いたいという目的は共通していて、
その設計思想が似ているのです。
2️⃣ 意図的な設計か？
答え：かなり意図的です。
- **オブジェクト指向設計（OOP:object-oriented programming,）**は、
ソフトウェアで複雑な現実のモデルを扱いやすくするために生まれました。 - 一方、**リレーショナルデータベース（RDB:Relational Database）**も、
現実世界の情報を整理して格納しやすくするために発展してきました。 - どちらも「データのまとまり（エンティティ）」を単位として設計されており、
自然と「1つの型（テーブル／クラス）ごとにデータを管理する」という形になります。
さらに、**O/Rマッピング（ORM）**という技術があることからも、
クラスとテーブルが似た構造であることが意図的だとわかります。
ORMはまさに、クラスとテーブルの対応関係を自動的に変換・橋渡しする技術です。
3️⃣ 補足：違いもある
似ているけれど、違いもあります。
| クラス（OOP） | テーブル（RDB） |
|---|---|
| データ＋振る舞い（メソッド）を持つ | データのみを持つ |
| メモリ上で扱う | 永続化（ディスク）される |
| インスタンス（オブジェクト）が生きている間だけ存在 | データは永続的に保持される |
ORMとは？
**ORM（Object-Relational Mapping）**は、
オブジェクト指向プログラミングとリレーショナルデータベースという2つの異なる世界
をMapping（対応付けること）するために発展してきました。
背景や発展の流れを順に整理してみます。
1️⃣ そもそもなぜ必要？
OOPとRDBは「思想」が違うから
| オブジェクト指向プログラミング (OOP) | リレーショナルデータベース (RDB) |
|---|---|
| クラス → オブジェクト → メモリ上のデータ | テーブル → レコード → 永続的なデータ |
| データと振る舞い（メソッド）が一体 | データ（値）のみ管理 |
| 階層的・ネストした構造を好む | フラットなテーブル設計が基本 |
| 参照をポインタ（オブジェクト同士の参照）で管理 | 主キー・外部キーでリレーションを管理 |
→ 開発者はプログラム内では「オブジェクト」で考えるのに、
DBには「テーブルとレコード」として保存しなければならない。
この 「意識のギャップ」 が非常に大きい。
2️⃣ ORM の基本的な考え方
そこで ORM は
「クラスとテーブル、オブジェクトとレコードの対応を自動でやろう」
という発想で登場します。
✅ 対応関係：下記の対応で名前を共通化する。
- クラス ↔ テーブル
- インスタンス（オブジェクト） ↔ レコード（行）
- 属性（フィールド） ↔ カラム
✅ 基本機能：クラスにはメソッドもあるので、SQL文はメソッドで対応
- オブジェクトをDBに保存 → INSERT文を自動生成
- DBからデータ取得 → SELECT文＋オブジェクト生成
- オブジェクトの変更 → UPDATE文生成
- オブジェクト削除 → DELETE文生成
3️⃣ 発展の経緯
1980〜90年代：初期の状況
- プログラム言語はOOPが台頭（Smalltalk → C++ → Java）
- DBはRDBが主流（Oracle, Informix, PostgreSQL など）
- しかし「手書きSQL」が主流で、プログラマはSQLとOOPの
両方を意識する必要があった
1990年代後半〜2000年代初頭：ORMの登場
- Java や .NET の普及に伴い OOP が主流化
- Hibernate（Java, 2001年頃） や Entity Framework（Microsoft）
などのORMライブラリが登場 - 「OOP だけでプログラムしたい」という開発者の願望が反映
- デザインパターン「DAO（Data Access Object）」と連携
2000年代半ば〜：
- Ruby on Rails の ActiveRecord（2004年〜）が爆発的な影響
→ ORM がWebアプリケーションの基本ツールに
→ Convention over Configuration（設定より慣習）
2010年代〜現在：
- Django（Python）など、ほぼ全ての主要WebフレームワークがORM内蔵
- マイグレーション機能（スキーマ変更も管理）
- クエリビルダー、Eager/Lazyロードなど高機能化
- GraphQL や NoSQL との併用など、新たな方向性も
4️⃣ まとめ：なぜ今も重要？
- 開発者は ビジネスロジックに集中できる
→ SQLの細かい記述やデータ整合性の管理をORMが肩代わり - クリーンで保守性の高いコードが書ける
- 逆に、ORMの限界（パフォーマンス・複雑クエリ）
を理解してうまく使い分けることが大事
