データベースとは｜ビジネスサイドのための IT 用語集

 データベースとはデータベースは、業務データを整理して保存し、複数の人と複数のシステムが同じデータを矛盾なく扱うための仕組みです。通常はデータベース管理システムと呼ぶソフトウェアが制御し、略称はDBMS（Database Management System）です。
例えば営業部門が共有の表計算ファイルで管理してきた受注一覧を、受注管理システムの裏側のデータベースに移すと、複数の担当者と他のシステムが同じ受注データを同時に登録し、参照できます。共有ファイルは全員が1冊のノートを同時に書き換える状態で、データベースは書き込みの競合を係が調整する書庫に近い仕組みです。この調整を同時実行制御と呼びます。
表計算ソフトにはもともと1人の利用者を想定して設計されたものが多く、同時利用の管理が前提のデータベースとは設計が異なる場合があります。
 ファイル管理の限界とリレーショナルデータベースが備えるデータの整合性と耐久性共有ファイルでの管理は、少人数で複雑な操作をしない用途に向いており、データベースは大量のデータを複数の利用者が同時に検索する用途のために設計されています。受注の件数が増え、販売管理や会計など他のシステムが同じデータを使い始めると、次の困りごとが出ます。
行数の上限: Excelの1シートは1,048,576行まで
転記の手間: システムごとに別ファイルを持つと、同じ受注を何度も入力し直し、数字がずれる
変更の衝突: 複数人が同じファイルを別々に開いて保存すると、後から保存した内容で上書きされることがある
リレーショナルデータベースの多くは、これらを防ぐ仕組みとしてトランザクションを備えます。トランザクションは複数の更新を、すべて成功するか、まったく反映されないかのどちらかにまとめる単位です。例えば受注の登録と在庫の引当を1つにまとめれば、在庫だけが減って受注が残らない状態を避けられます。リレーショナルデータベースの多くは、確定した更新を障害後も保持する仕組みを備え、設定にもよりますが、処理の途中の状態は通常は他の処理から見えません。
 表計算ファイルのままでよい場面とデータベースへの移行の目安移行するかどうかは、同時に更新する人、データを利用するシステム、行数の3点で判断します。以下は、受注管理のような業務データを1つの部署から数部署で扱う小規模な利用を想定した目安で、製品や業務によって前後します。
同時に更新する人が数人以内で、利用が1つの部署のみ、行数が数万行までなら、表計算ファイルのままで足りる。移行の作業と運用の負担のほうが大きくなる
同時に更新する人が数人を超える、または複数のシステムが同じデータを参照・更新するなら、データベースへの移行対象
行数が10万行を超えたら、上限の約104万行に達する前でも移行対象
迷うのは、まだ小さい利用のうちに、将来の増加を見越して早めに導入するかどうかです。導入は、他のシステムとの連携や公開サービスなど、データの利用側が増えることが決まった時点で検討すれば足りる場合が多いです。表計算ファイルで足りている間は移行を急がず、必要になったときはリレーショナルのマネージドサービスも選択肢になります。
 データベースの種類と選び方業務で最初に迷う区分は、データの扱い方の傾向による区分です。リレーショナルデータベースは、データを行と列の表に整理して扱います。NoSQLデータベースは、表にきれいに収まらないデータ向けに、特定のデータモデルで柔軟な構造で保存します。
受注、顧客、会計のように項目が決まり、表同士を結びつけて集計する業務データ: リレーショナル
アクセスログやセンサーの記録のように、大量で形が揃わず、決まった検索の仕方で高速に読み書きするデータ: NoSQL
この区分は製品の分類ではなく目安です。MongoDBなどのドキュメントデータベースには、複数のドキュメントにまたがるトランザクションに対応する機能があり、PostgreSQLにはJSONデータ型があって、リレーショナルでも柔軟な構造のデータを扱えます。近年は両者の違いが曖昧になっており、対応する機能は製品ごとに違います。選ぶときは区分の名前ではなく、トランザクション、検索の仕方、スキーマの扱いを製品ごとに確認します。
業務システムで迷ったら、まずリレーショナルを選びます。表同士を結びつけて集計する処理が業務システムの中心になり、扱える人材や情報も多いためです。NoSQLは、扱うデータの形とアクセスの仕方が先に決まっていて、リレーショナルでは性能や構造が合わないと分かった部分に限って追加します。
 導入後の運用とコストデータベースは導入して終わりではなく、稼働させ続けるための作業が続きます。
バックアップの取得と、復元できることの確認
ソフトウェアの更新。攻撃に悪用されうる欠陥である脆弱性への対応を含む
障害時の切り替え
処理が遅くなったときの、データベースへの問合せであるクエリの調整
利用者ごとの権限の管理
データ量の増加に合わせた容量の拡張
運用の担当者がいなければ、運用作業の一部を事業者が担う提供形態のマネージドサービスが現実的です。Amazon RDS（Relational Database Service）の例では、バックアップ、更新、障害の検出と復旧をサービス側が管理し、クエリの調整は利用者の責任とされています。容量の拡張や権限の管理は利用者の作業です。サーバーを自社で持つ場合は、OSやハードウェアの管理もすべて自社の負担です。
単一の小規模なデータベースをマネージドサービスで動かす想定の目安は、利用料が月数千円から数万円、運用工数が月数時間から十数時間です。製品、データ量、構成で大きく変わるため、見積もりでは利用料に加えて、設計とクエリの調整に必要な人材の時間も見込みます。
 よくある誤解 データベースは大きな表計算ファイルである実際は、表計算ファイルと違い、同時利用の整合性、権限、障害時の復元を前提にして作られています。ただし、検索に合わせた設計をしていなければ遅くなり、同じ項目を複数の表に重複して持てば数字がずれます。
 表の構造は後からいつでも気軽に変えられる実際は、列の追加や制約の変更が、製品と操作によっては既存の行すべての検証や書き換えを伴います。MySQLにもテーブルのコピーを作ってデータを移す変更方法があります。運用を始めた後の変更は、所要時間や影響を見積もってから行います。
 データベースがあれば分析も楽になる実際は、業務を処理するデータベースで全期間を集計すると、業務の画面が遅くなる場合があります。分析の用途には、データベースのうち分析の集計を主な用途とするデータウェアハウスを、業務用とは別に用意して集計します。
 マネージドサービスなら運用は不要実際は、設計、クエリの調整、権限の管理、拡張が利用者に残ります。
 NoSQLのほうが新しくて優れている実際は、新旧や優劣ではなく、扱うデータとアクセスの仕方で選びます。NoSQLにもトランザクションに対応する製品があり、リレーショナルもJSON型で柔軟な構造を扱えるため、違いは曖昧になっています。業務データの多くはリレーショナルで足ります。