データベースは、顧客、商品、注文などのデータを、後から探し、追加し、変更できるように管理する仕組みです。図書館が本を分類し、目録で探せるようにするのと似ています。ただし、データベースを導入するだけで、内容が正しくなったり、必ず速くなったりするわけではありません。
このガイドでは、顧客と注文の小さな架空例から、表・行・列、データ同士の関係、検索、同時更新、運用までをつなげます。製品名を先に選ぶより、「何を保存し、どの操作を正しく行いたいか」を説明できることを目指します。
30秒で要点
- データベースは、データの保存だけでなく、検索・更新や、決めたルールを守るために使う。現実の情報の真偽は人や業務の確認も必要。
- 表形式で扱うRDB、文書形式などで扱うNoSQLには、それぞれ設計と運用の条件がある。「NoSQLなら速い」とは決められない。
- Excelも条件を満たせば共同編集できる。人数や件数だけでデータベースへの移行を決めず、重複・同時更新・権限・他システムとの連携を見る。
- バックアップ、復元、アクセス権、更新の責任者までが運用の範囲。クラウドや製品の標準機能に任せる部分も、契約と設定を確認する。
図書館の目録と、業務データの違い
本の題名、著者、分類、貸出状況が整理されていれば、「ある著者の本を探す」「貸出中の本を確認する」といった問いに答えやすくなります。業務では、それに当たるものが顧客名、商品番号、注文日、数量などです。
データベースを操作・管理するソフトウェアをDBMSと呼びます。日常会話では保存したデータと管理ソフトをまとめて「データベース」と呼ぶこともあります。まずは、データそのもの、管理するソフト、それを使うアプリを区別すると理解しやすくなります。
表が収まらない場合は、横にスクロールできます
| 身近な用途 | 保存するもの | 答えたい問い |
|---|---|---|
| 電話帳・顧客管理 | 名前、連絡先、顧客ID | この顧客の連絡先はどれか |
| ECの注文 | 注文、商品、数量、受付状態 | 何を何個、誰から受け付けたか |
| 在庫管理 | 商品、入出庫、保管場所 | どこに何個あり、なぜ増減したか |
| 予約 | 日時、枠、予約者、状態 | 同じ枠を重複して受け付けていないか |
| 社内システム | 担当、進行状態、操作履歴 | 誰が何を変更したか |
同じデータでも、必要な問いが違えば設計は変わります。検索しやすさだけでなく、何を一緒に更新すべきか、誰が閲覧・変更できるかも考えます。
顧客・商品・注文を三つの表で考える
RDB（リレーショナルデータベース）では、行と列から成る表を使ってデータを扱います。表をテーブル、行をレコード、列をカラムと呼ぶことがあります。
以下は架空の教材です。簡単にするため、注文一件につき商品一種類だけを記録します。実際のECでは、注文と複数の注文明細、配送、税、返金などを別途設計することが多く、この三表だけで実運用を完成させる例ではありません。
表が収まらない場合は、横にスクロールできます
| 顧客ID | 顧客名 |
|---|---|
| C01 | サンプル商店 |
| C02 | サンプル工房 |
表が収まらない場合は、横にスクロールできます
| 商品ID | 商品名 | 現在の単価 |
|---|---|---|
| P01 | ノートセット | 1,200円 |
| P02 | カードセット | 800円 |
表が収まらない場合は、横にスクロールできます
| 注文ID | 顧客ID | 商品ID | 数量 | 注文時単価 | 小計 |
|---|---|---|---|---|---|
| O01 | C01 | P01 | 2 | 1,200円 | 2,400円 |
| O02 | C02 | P02 | 3 | 800円 | 2,400円 |
注文時単価を記録するのは、商品表の現在の単価が後から変わっても、過去の注文の計算を追えるようにするためです。ここでは税・送料・値引きを含めず、合計は2,400円＋2,400円＝4,800円です。
IDとルールを決める
顧客名は同じものがあったり、後から変わったりします。そこで、一件を識別するIDを使います。主キーは行を一意に識別するためのもので、PostgreSQLでは主キーに一意性とNULLを許さない条件が伴います。
注文に存在しない顧客IDを入れないようにするには、外部キーなどの制約を設計します。数量が正であること、必須項目を空にしないことも、適切な制約で表せます。ただし、「住所が現実に正しい」「注文者に購入意思がある」といったことまでは、こうした形式のルールだけでは分かりません。PostgreSQLの制約の公式説明
また、「重複を防ぐ」と言っても、何を重複とするかを決める必要があります。同じ顧客の二回の注文は、通常、同じデータの重複とは限りません。顧客ID、注文ID、外部システムの受付番号など、それぞれの意味を整理します。
検索・追加・更新・削除を区別する
データに対する基本操作を、Create・Read・Update・Deleteの頭文字でCRUDと呼びます。このときのCreateは、新しい行などのデータを追加することです。入れ物となるテーブルの作成とは区別します。
表が収まらない場合は、横にスクロールできます
| 操作 | 顧客・注文の例 | SQLで使う代表的な語 |
|---|---|---|
| Create：追加 | 新しい注文を一件登録する | INSERT |
| Read：参照 | 顧客C01の注文を探す | SELECT |
| Update：更新 | 注文の受付状態を変更する | UPDATE |
| Delete：削除 | 保存方針に従い不要なデータを削除する | DELETE |
| 構造の定義・変更 | 注文テーブルや列を用意する | CREATE TABLE、ALTER TABLE |
SQLは、RDBに対してデータを問い合わせたり、操作したりするための言語です。上の語は役割の説明で、コピーして実行するSQLプログラムではありません。実際に更新・削除する際は、対象条件と権限、影響する件数を確かめる必要があります。基本操作はPostgreSQLの行の追加、検索、更新、削除の教材で確認できます。
アプリでは、画面の「登録」ボタンの裏でこうした操作が行われます。画面からDBへ直接何でも送ってよいという意味ではなく、サーバー側などの処理で入力や操作権限を確認する設計が必要です。
検索を助ける索引と、その代償
図書館の目録のように、特定の条件でデータを探しやすくする仕組みがインデックス（索引）です。たとえば顧客IDで注文を探す処理に役立つ場合があります。
ただし、索引を増やせば必ず速くなるわけではありません。どれだけの行を取得するか、検索条件、データの分布などによって、データベースは索引を使うか、表を順に読むかを選びます。索引自体の容量と、データ更新時に索引を維持する負担もあります。索引の使われ方、索引の利点と負担
「100万件でも高速」という件数だけの説明では、必要な性能を判断できません。「どの条件で、何件返し、同時に何回処理し、どの程度の時間で終える必要があるか」を決め、実際に近いデータと負荷で確認します。
同時に使うときは、更新のまとまりを考える
複数人が使える仕組みであっても、更新が競合しないとは限りません。残り一つの商品を、二人が同時に注文するような場合を考えます。画面の表示だけを見て別々に処理すると、在庫の扱いが矛盾する可能性があります。
関連する処理をひとまとまりとして扱うのがトランザクションです。PostgreSQLの教材では、複数の操作を全部完了するか、途中の結果を残さず取り消すかという考え方を説明しています。トランザクションの公式教材
もっとも、トランザクションを使うだけで、あらゆる同時処理の問題が解決するわけではありません。どの更新をまとめ、競合をどう検出し、再試行や二重受付をどう扱うかは設計が必要です。既に送ったメールや外部決済まで、DBの取り消し操作で自動的に戻るとは考えないでください。
Excelとデータベースは、人数だけで選ばない
表計算は、人が見ながら集計や試算を行うのに便利です。Excelも、対応するアプリや保存先などの条件を満たせば共同編集ができます。「一人でしか編集できないからDBへ移る」という説明は正確ではありません。MicrosoftのExcel共同編集の条件
表が収まらない場合は、横にスクロールできます
| 見る点 | 表計算を続けやすい場面 | DBや業務アプリを検討する場面 |
|---|---|---|
| 作業の性質 | 人が見て柔軟に試算・整理する | 決まった登録・検索を繰り返す |
| ルール | 少人数で確認手順を保てる | 必須・参照・重複ルールを一貫させたい |
| 同時更新 | 共同編集の条件内で運用できる | 同時受付や関連更新の整合性が重要 |
| 連携 | 手動の受け渡しでも支障が少ない | Webや他の業務から継続して更新する |
| 権限・履歴 | ファイル単位などで足りる | 操作やデータ範囲ごとの管理が必要 |
| 継続運用 | 担当交代時にも確認方法が伝わる | システムとして保守・復旧を整えたい |
この表も選択の観点であり、製品の絶対的な優劣ではありません。1万件や10人という境界だけで切り替えず、実際に起きている重複、作業時間、誤更新、連携の手間を記録します。
RDB・NoSQL・組み込みDBの違い
RDBの製品例にはPostgreSQL、MySQL、Oracle Database、SQL Serverがあります。製品名だけで要件が満たされるとは判断せず、必要な機能、契約、管理体制を個別に確認します。
NoSQLは一つの共通製品ではなく、文書、キーと値など、さまざまなモデルを扱う分類です。たとえばMongoDBは文書モデルを使い、異なる項目を持つ文書を扱えますが、検索・更新の仕方に合うデータ設計は必要です。柔軟な形式だから設計不要、RDBより常に高速という意味ではありません。MongoDBのデータモデリング
また、DBが必ず独立したサーバーで動くわけでもありません。SQLiteのように、アプリに組み込んで使う方式があります。SQLiteは一つのDBファイルへの書き込みを同時に一つにするなどの条件を持ち、複数の端末がネットワーク越しに同じファイルへ直接アクセスする用途には注意が必要です。小さいデータなら必ずSQLite、大きいなら必ず別製品、という区切りではありません。SQLiteの適した用途と制約
クラウドで管理機能を提供するDBを使う場合も、データモデルや権限、費用、取り出しや復元の条件を確認します。提供者が担う運用と、自社が決めるルールを分けてください。
保存した後の責任を決める
データベースは、故障や誤操作に備える運用も必要です。PostgreSQLの公式資料も、価値あるデータのバックアップと、方式ごとの前提の理解を求めています。取得したファイルがあることと、必要な時間・範囲で復元できることは、別の確認です。バックアップと復元の導入
表が収まらない場合は、横にスクロールできます
| 責任 | 決めておくこと |
|---|---|
| データの定義 | 各項目、ID、必須条件、保存する目的 |
| アクセス | 誰が読み、誰が変更し、誰が権限を見直すか |
| 変更 | 構造やアプリを変えるときの確認と戻し方 |
| 復旧 | バックアップの対象、保管、復元を試す担当 |
| 終了・移行 | データを取り出せる形式と、他環境で再現する範囲 |
個人情報などを扱う場合は、そもそも保存が必要か、保存期間や利用権限をどう決めるかを業務側で確認します。便利だから集め続ける、という運用にはしません。
最初の確認は、小さな架空データで行う
導入前には、次の紙上確認から始められます。実際のDBを起動しなくても、設計の曖昧さを見つける助けになります。
- 顧客、商品、注文などを数件書き、一件を識別するIDを付ける。
- 「この顧客の注文」「この商品の数量」など、必要な問いを三つ書く。
- 存在しない顧客ID、重複する注文ID、数量0や負数を入れたらどうするか決める。
- 名前や単価を変更したとき、過去の記録がどう見えるべきか確かめる。
- 同時受付や復元の確認は、別の検証項目として担当者に渡す。
今回の表なら、O01の小計は2×1,200円、O02は3×800円です。一つの注文IDが二行に増えた場合を黙って合計せず、意図した明細構造なのか、誤った重複なのかを先に判断します。こうした問いを説明できると、製品選定や開発の相談が具体的になります。
サーバー・API・運用とのつながり
保存場所と役割はサーバーの基礎、外部とのデータのやり取りはAPIの基礎、運用の分担はクラウドの基礎で整理できます。アプリの更新とデータの変更を分ける考え方はデプロイの基礎につながります。