データベースとは、構造と規則を持つデータの集合
データベースは、対象となる事実を定義したデータモデルに沿って保存し、検索・追加・更新・削除しながら、関係と整合性を維持できるようにしたデータの集合です。
PostgreSQL公式チュートリアルは、リレーショナルデータベースとSQLを、表の作成、行の追加、問い合わせ、結合、集計、更新、削除、外部キー、トランザクションという流れで説明しています。リレーショナル型では、顧客、商品、注文などの対象を表へ分け、各行を主キーで識別し、外部キーで関係を保ちます。データベースは保存されたデータそのものと論理構造を指し、DBMS（Database Management System）はSQL等の要求を受け、記録、検索、同時実行、権限、ログ、復旧を制御するソフトウェアです。会話では両者をまとめて「データベース」と呼ぶこともありますが、構成と責任を判断するときは分けます。
データモデルとスキーマ
どの対象を記録し、どの属性を持たせ、何を一意にし、対象同士をどう結ぶかを定義します。リレーショナル型の表、文書型の文書とコレクション、グラフ型のノードと関係など、モデルによって表現と問い合わせが変わります。
DBMSの制御
DBMSはデータの読書きだけでなく、制約、トランザクション、ロックまたは多版同時実行制御、索引、権限、ログ、複製、バックアップ連携などを担います。実際の機能と保証範囲は製品・構成・設定で異なります。
データベースに保存すれば、データが自動的に正しく・安全になるわけではない
誤った型、重複可能な識別子、欠けた外部キー、広すぎる権限、文字列連結したSQL、未検証のバックアップは不整合や漏えいにつながります。DBMSの機能を有効にし、アプリ側の入力検証、パラメータ化、権限分離、監視、復元試験と組み合わせて初めて運用品質を保てます。
注文データを、表・キー・トランザクションで表す
一人の顧客が複数の注文を行い、一つの注文が複数の商品を含む例を考えます。全情報を一つのセルやJSON文字列へ詰めるのではなく、顧客、注文、商品、注文明細の責任を分け、キーで結びます。次は概念を説明する簡略例であり、税、通貨、値引き、配送、返品、監査の実要件は別途定義します。
表と関係
orders.customer_id → customers.customer_id
customersのcustomer_idを主キーとして顧客を一意に識別し、ordersのcustomer_idを外部キーとして参照します。存在しない顧客の注文を拒否するなど、参照整合性をDBMSへ宣言できます。
注文明細の金額
line_total = quantity × unit_price
order_itemsはorder_id、product_id、quantity、unit_priceを持ちます。販売時点の単価を明細へ保存するか、商品表の現在価格を参照するかは業務ルールです。後から商品価格が変わっても過去注文額を再現するなら、販売時点の値を保持します。
例：在庫を減らして注文を確定する
- 1入力を検証する：顧客、商品、数量、価格、通貨、配送先、冪等キーを確認し、アプリからはプレースホルダーを使ったパラメータ化クエリで値を渡す。
- 2トランザクションを開始する：注文、注文明細、在庫を一つの業務操作として扱い、必要な行の同時更新を制御する。
- 3制約を確認して更新する：在庫不足、重複注文、存在しない商品、無効な状態遷移を拒否し、注文と明細を保存して在庫を減らす。
- 4すべて成功すればCOMMITし、一つでも失敗すればROLLBACKする。外部決済や配送はDBトランザクションだけに閉じないため、再試行、重複防止、補償処理を別に設計する。
トランザクションは複数の更新をall-or-nothingにまとめます。ただし外部サービスを含む業務全体が自動で一体化するわけではありません。
データモデルは、保存したい形より答えたい質問から選ぶ
データベースには複数のモデルがあり、同じ製品が複数モデルを扱う場合もあります。MongoDB公式文書は文書型で一緒に読むデータを一緒に置く考え方、Redis公式文書は文字列・ハッシュ・集合・ストリーム等のデータ型、Neo4j公式文書はノード・関係・プロパティによるグラフを説明しています。名称だけで性能や整合性を断定せず、問い合わせ、更新、運用の要件で評価します。
表は横方向にスクロールできます
| モデル | 主な構造 | 適用を検討する場面 | 設計時の確認 |
|---|---|---|---|
| リレーショナル | 表・行・列、主キー・外部キー、制約。SQLで結合・集計・更新する | 注文、会計、在庫、顧客など、関係と整合性を明示した業務データ | 正規化、制約、トランザクション境界、結合、索引、スキーマ変更を設計する |
| 文書 | JSONに近い文書とコレクション。入れ子や配列で関連データをまとめられる | 商品ごとに属性が異なるカタログ、一緒に取得する階層データ、内容構造が変化する記録 | 埋込みと参照、文書サイズ、重複、同時更新、検証規則をアクセスパターンから決める |
| キー値・データ構造 | キーから値を取得。文字列、ハッシュ、集合、ソート済み集合、ストリーム等を扱う製品もある | キャッシュ、セッション、カウンタ、ランキング、キューなど明確なアクセスパターン | 永続化、期限、メモリ、退避時の挙動、複雑な検索、正本との整合を確認する |
| グラフ | ノード、方向と種類を持つ関係、プロパティ。関係をたどって問い合わせる | 経路、依存関係、権限継承、不正ネットワーク、推薦など接続自体が主要な問い | ノードと関係の粒度、方向、制約、探索深度、更新頻度、利用クエリを定義する |
| 時系列 | 時刻付き観測値を追記し、期間、集約、保持、ダウンサンプリングで扱う | 監視メトリクス、センサー、価格、設備稼働など時間順の大量データ | 時刻精度、遅着・重複、タグ、保持期間、集約粒度、再計算を決める |
| 組込み | アプリケーションと同じ端末・プロセス近辺でファイルを管理し、別サーバーを置かない構成 | モバイル、デスクトップ、単一端末、ローカルキャッシュ、配布可能な小規模アプリ | 複数利用者の同時接続、同期、バックアップ、暗号化、端末紛失、移行を確認する |
「NoSQLならスキーマ不要」「リレーショナルなら拡張できない」は誤解
文書型でも、フィールド、型、必須値、関係、検証、移行を設計しなければアプリ側が不整合を抱えます。リレーショナル型にもJSON、パーティション、複製など多様な機能があります。モデル名から結論を出さず、代表的な読み書き、整合性、遅延、容量、運用能力を候補製品で検証します。
設計・運用を決める6つの軸
データ量だけでなく、意味、品質、問い合わせ、同時更新、復旧、責任を測ります。ピーク時の代表クエリと更新を再現し、設計上の目標値と実測値を分けて記録します。
1. 対象・関係・履歴
顧客、契約、商品、注文などの対象、識別子、属性、1対1・1対多・多対多の関係を定義します。現在値だけか、価格・住所・状態の変更履歴も必要か、削除後も監査記録を残すかを決めます。
2. 型・制約・整合性
NOT NULL、UNIQUE、CHECK、主キー、外部キー、状態遷移、金額・時刻・通貨の扱いを決めます。アプリの入力検証だけに依存せず、DBMSで継続的に守る規則と業務サービス側で守る規則を分けます。
3. 問い合わせと索引
画面、帳票、検索、API、バッチごとに条件、並び順、結合、集計、返却件数、目標応答時間を列挙します。PostgreSQL公式文書が示すように索引は特定行の取得を速めますが、保存領域と更新負荷も増やすため、実行計画と利用状況で選びます。
4. 容量・負荷・同時実行
現在と将来の行数、文書数、平均・最大サイズ、増加率、読書き比率、同時接続、ピークTPS、長時間クエリを測ります。接続プール、ロック競合、メモリ、キャッシュ、I/O、ネットワークを含むボトルネックを確認します。
5. 可用性・バックアップ・復旧
許容停止時間、RPO・RTO、複製、フェイルオーバー、バックアップ方式、保存期間、暗号化、別障害領域、ポイントインタイム復旧を決めます。スナップショットだけでなく、スキーマ、権限、設定、暗号鍵、依存サービスまで復元試験します。
6. 権限・監査・ライフサイクル
アプリ、管理者、分析者、保守担当の権限を分け、通信・保存時暗号化、秘密情報、操作ログ、個人データの目的・保持・訂正・削除を定義します。本番データを開発へ複製する場合は匿名化とアクセス制御を行います。
WordPressでは、ファイルとデータベースの両方が必要
WordPressのデータベースには投稿、コメント、ユーザー、分類、設定等が保存されますが、アップロード画像、テーマ、プラグイン、構成ファイルはファイル側にもあります。移行や復旧では、データベースだけを戻しても完全なサイトにならない場合があります。データベース名、ユーザー、ホスト、権限、文字集合・照合順序を確認し、ファイルと同じ時点へ整合させて復元します。
DBMS・SQL・表計算・ファイル・キャッシュとの違い
日常会話では「データベース」という語が、データ、製品、サーバー、検索画面をまとめて指すことがあります。構成、費用、障害責任を明確にするには、次の役割を分けます。
| 概念 | 定義・役割 | データベースとの違い |
|---|---|---|
| DBMS | データベースを作成・操作し、同時実行、制約、権限、ログ、復旧を制御するソフトウェア | データベースは管理対象となるデータ集合、DBMSはそれを管理する実行系。MySQLやPostgreSQLはDBMS製品名 |
| SQL | 表の定義、問い合わせ、追加、更新、削除、権限、トランザクション等を記述する言語 | データそのものやサーバーではない。DBMS・版ごとに方言と機能差があり、NoSQL製品でも別の問い合わせ言語を持つ |
| データベースサーバー | DBMSを実行し、クライアントからの接続と処理を受けるプロセスまたは計算環境 | 単一物理機とは限らず、複製・クラスタ・マネージドサービスの場合もある。データベース名とは別 |
| 表計算 | 人がセルを直接編集し、数式、集計、グラフで小規模な分析・帳票を行う道具 | 柔軟な対話操作に向くが、複数アプリの同時更新、参照整合性、細かな権限、API取引の正本には限界がある |
| ファイル | CSV、JSON、画像、文書など、ファイルシステムやオブジェクトストレージに置く単位 | 交換・配布・大容量バイナリに向く。複数ファイルをまたぐ制約、同時更新、索引、トランザクションは別途必要 |
| キャッシュ | 元データや計算結果の複製を近い場所へ一時保持し、応答を速くする層 | 通常は正本ではない。期限、無効化、欠損時の再取得を設計し、データベース更新との不整合を扱う |
データウェアハウスは、分析用に統合・履歴化したデータ基盤
業務トランザクションを処理するデータベースからデータを取り込み、部門横断の集計・履歴分析へ最適化します。運用DBへ重い集計を直接集中させない利点がありますが、取り込み遅延、定義差、個人データ、品質、費用を管理する必要があります。データレイク、検索エンジン、ベクトルストアも用途ごとに役割が異なります。
データベース導入・改善を5段階で進める
画面や既存Excelをそのまま表へ写すのではなく、業務事実と規則、代表クエリ、障害時の扱いを先に決めます。小さなデータで制約と操作を検証し、負荷・移行・復元を確認してから公開します。
- 1
業務用語と正本を定義する
顧客、契約、商品、注文などの用語、識別子、状態、時刻、金額、責任部署を辞書化します。同じ「顧客」が営業、請求、サポートで異なる意味なら統合ルールを決め、どのシステムが正本か明記します。
- 2
モデル・キー・制約を設計する
代表データと例外を使い、表・文書・関係、主キー、外部キー、必須、重複、削除、履歴を設計します。個人情報と秘密情報を分類し、不要な値を収集しない方針もスキーマへ反映します。
- 3
読み書きとトランザクションを検証する
主要画面、API、帳票、バッチごとに問い合わせと更新を実装し、同時実行、再試行、重複、部分失敗を試します。索引は実行計画と計測から追加し、代表データ量で応答時間と更新負荷を比較します。
- 4
移行・復旧・切替を試す
旧データを抽出、変換、検証し、件数だけでなく合計、関係、重複、欠損、文字、時刻を照合します。完全・増分バックアップとログから別環境へ復元し、RPO・RTO、アプリ接続、権限、切戻しを確認します。
- 5
監視して安全に変更する
可用性、遅延、エラー、接続、ロック、容量、複製遅延、バックアップ成否を監視します。スキーマ変更は前方・後方互換、段階展開、長時間ロック、ロールバックを設計し、所有者と定期レビュー日を決めます。
複製はバックアップの代わりではない
複製は可用性や読み取り分散に役立ちますが、誤削除、誤更新、ランサムウェア、アプリ不具合も複製され得ます。バックアップは別の保持方針と障害領域を持たせ、削除・暗号化・破損・リージョン障害を想定して復元します。取得成功ではなく復元成功を確認します。
確認した公式資料
リレーショナル構造、制約、トランザクション、索引、ACID、文書・キー値・グラフ型、WordPressのデータベース準備は次の公式資料で確認しました。製品の機能、既定値、サポート版、運用責任は変わるため、採用時には対象版の文書も確認してください。
- PostgreSQL Documentation「Tutorial」
- PostgreSQL Documentation「Constraints」
- PostgreSQL Documentation「Transactions」
- PostgreSQL Documentation「Introduction to Indexes」
- MySQL 8.4 Reference Manual「InnoDB and the ACID Model」
- MongoDB Manual「Data Modeling in MongoDB」
- Redis Docs「Redis data types」
- Neo4j Getting Started「What is a graph database」
- WordPress Advanced Administration Handbook「Creating Database for WordPress」
データベースのよくある質問
データベースとDBMSは同じですか？
厳密には異なります。データベースは構造化して管理するデータの集合、DBMSはそのデータを作成・検索・更新し、制約、同時実行、権限、ログ、復旧を制御するソフトウェアです。MySQL、PostgreSQL、MongoDB等はDBMS製品名ですが、会話では製品をデータベースと呼ぶこともあります。
Excelやスプレッドシートもデータベースですか？
表形式で情報を蓄積できるため広い意味でデータベース的に使えますが、一般的なDBMSとは機能と用途が違います。人が直接編集する小規模な台帳や分析には便利ですが、複数アプリの同時更新、参照整合性、細かな権限、トランザクション、APIの正本が必要ならDBMSを検討します。
SQLを使うデータベースはすべて同じですか？
同じではありません。共通するSQL概念はありますが、型、関数、索引、トランザクション、JSON、権限、拡張、運用機能に製品・版ごとの差があります。移行では標準SQLだけでなく、スキーマ、ストアド処理、照合順序、時刻、接続方式、バックアップを検証します。
WordPressのバックアップはデータベースだけで十分ですか？
通常は不十分です。投稿、ユーザー、コメント、設定等はデータベースにありますが、アップロード画像、テーマ、プラグイン、構成ファイルはファイル側にもあります。両方を整合する時点へ戻し、URL、権限、文字、メール、プラグイン動作まで復元試験します。
索引を増やせば検索は必ず速くなりますか？
必ずではありません。索引は適合する条件や並び順の検索を速めますが、保存領域を使い、追加・更新・削除の負荷を増やします。選択性、列順、複合条件、返却件数を考え、代表データで実行計画と応答時間を測ります。
NoSQLならスキーマ設計は不要ですか？
不要ではありません。事前に固定スキーマを宣言しない製品でも、フィールド名、型、必須値、識別子、関係、重複、変更方法をアプリと運用が共有する必要があります。柔軟性は無規則を意味せず、アクセスパターンと移行を含むデータモデルを設計します。
データを保存・配信する周辺概念を続けて確認する
データベースは、保存量ではなく守る事実と答える質問から設計する
データベースは、データを構造と規則に沿って保存し、検索・更新しながら関係と整合性を維持する集合です。DBMSは制約、トランザクション、同時実行、索引、権限、ログ、復旧を制御します。顧客、注文、商品などの業務用語と正本を決め、キーと制約、代表クエリ、更新境界、性能目標、RPO・RTO、保持・削除を定義してください。小さな実例で不整合と同時更新を試し、実データ量で計測し、別環境への復元を成功させることが、使い続けられるデータ基盤につながります。
この記事の確認体制
Finite Field 編集部
PostgreSQL、MySQL、MongoDB、Redis、Neo4j、WordPressの公式文書を照合し、データベース一般の概念と各製品の実装例を分けて編集しています。
Finite Fieldへ相談
データモデル・移行・性能・復旧を相談する
Excel台帳を業務システムへ移したい、重複や不整合を減らしたい、DBが遅い原因を特定したい、バックアップから復元できるか不安な場合は、用語一覧、代表データ、主要操作、現在件数と増加率、遅いクエリ、障害履歴、RPO・RTOを準備してください。
データ基盤を相談するデータの機密性、現行構成、要件、移行条件を確認したうえで対応可否をご案内します。無停止移行、完全なデータ品質、性能値、費用削減、障害ゼロを事前に保証するものではありません。