データベースとは？

データ定義はシステム内のデータの形状と構造を制御する

データベース内でデータが取る構造を作成および制御することは、データベース管理の重要な部分です。これにより、システムに取り込む前にデータの形状（または構造）を制御できます。また、データが特定のパラメータに準拠していることを確認するための制約を設定することもできます。

リレーショナルデータベースのように、非常に規則的なデータを扱うデータベースでは、これらの定義はしばしばデータベースのスキーマとして知られています。データベーススキーマは、特定のデータベースによってデータが受け入れられるために、データがどのようにフォーマットされる必要があるかの厳密な概要です。これには、個々のレコードに存在する必要がある特定のフィールド、およびデータ型、フィールド長、最小値または最大値などの値の要件が含まれます。データベーススキーマは、データベース所有者がシステムに保存されるデータに影響を与え、制御するための最も重要なツールの1つです。

規則性よりも柔軟性を重視するデータベース管理システムは、しばしばスキーマレスデータベースと呼ばれます。これはこれらのデータベースに保存されるデータに構造がないことを意味するように思われますが、通常はそうではありません。代わりに、データベースの構造はデータ自体と、データに対するアプリケーションの知識と関係によって決定されます。データベースは通常、依然として構造に準拠していますが、データベース管理システムは制約の強制に関与することが少なくなります。これは状況に応じて利点と欠点がある設計上の選択です。

システムからデータを取り込み、変更し、削除するためのデータ更新

データ更新には、以下のいずれかの操作が含まれます。

• システムに新しいデータを入力する
• 既存のエントリを変更する
• データベースからエントリを削除する

これらの機能はあらゆるデータベースにとって不可欠であり、多くの場合、データベースシステムが処理するアクションの大部分を構成します。これらのタイプの活動（システム内のデータを変更する操作）は、総称して書き込み操作として知られています。

書き込みアクションは、時間の経過とともに変化するデータソースにとって重要です。破壊的なアクションであるデータの削除でさえ、システム内のデータを変更するため、書き込み操作と見なされます。

書き込み操作はデータを変更する可能性があるため、これらのアクションは潜在的に危険です。ほとんどのデータベース管理者は、偶発的または悪意のあるデータ改ざんの可能性を最小限に抑えるために、特定のアプリケーションプロセスに書き込み操作を制限するようにシステムを構成します。例えば、ウェブサイトのパフォーマンスや訪問者の行動に関する質問に答えるために既存のデータを使用するデータ分析は、読み取り権限のみを必要とします。一方、ユーザーの注文を記録するアプリケーションの部分は、データベースに新しいデータを書き込むことができる必要があります。

情報を抽出したり特定の質問に答えたりするためのデータ取得

データを保存しても、必要なときに取得する方法がなければあまり役に立ちません。データを返すことは、現在データベースに保存されている情報には影響しないため、これらのアクションは読み取り操作と呼ばれます。読み取り操作は、データベースにすでに保存されているデータを収集する主要な方法です。

データベース管理システムは、主キーと呼ばれる一意の識別子によってデータにアクセスする簡単な方法をほぼ常に持っています。これにより、キーを提供することで任意のエントリにアクセスできます。

多くのシステムは、特定の基準に一致するデータセットを返したり、エントリに関する部分的な情報を返したりするための、洗練されたデータベースクエリ方法も持っています。このタイプのクエリの柔軟性により、データベース管理システムは、基本的なデータストレージ機能に加えて、データプロセッサとしても機能します。特定のクエリを開発することで、ユーザーはデータベースシステムに必要な情報だけを返すように促すことができます。この機能は、そのプロパティによって特定のレコードを見つけて変更するために、書き込み操作と組み合わせてよく使用されます。

すべてをスムーズに実行するためのデータベースシステムの管理

データベースがよくサポートする最後のアクションのカテゴリは、管理機能です。これは、データ自体に直接影響を与えることなく、データベース環境をサポートするのに役立つ、広範で一般的なアクションのクラスです。このグループに当てはまる項目には、次のようなものがあります。

• ユーザー、権限、認証、および承認の管理
• バックアップの設定と維持
• ストレージのバックアップ媒体の構成
• レプリケーションおよびその他のスケーリングに関する考慮事項の管理
• オンラインおよびオフラインの復旧オプションの提供

このアクションのセットは、最新のアプリケーションに共通する基本的な管理上の懸念と一致しています。

管理操作はコアデータ管理機能の中心ではないかもしれませんが、これらの機能はしばしば類似のデータベース管理システムを区別します。データのバックアップと復元が容易であること、既存のシステムに連携するユーザー管理を実装できること、または需要に応じてデータベースをスケーリングできることは、すべて本番環境で運用するために不可欠な機能です。これらの領域に注意を払わないデータベースは、実際の環境での採用に苦労することがよくあります。

忠実な記録と再構築によるデータ整合性の保護

データ整合性は、その目的や設計に関わらず、データベースシステムの基本的な要件です。データベースにロードされたデータは、予期しない変更、操作、または消去なしに、信頼性高く取得できる必要があります。これには、データを物理メディアに保存するために、必要に応じてデータのロードと取得、およびシリアル化と逆シリアル化の信頼できる方法が必要です。

データベースはしばしば、チェックサムなどの書き込みまたは取得時のデータ検証機能、またはライトアヘッドログなどの予期しないシャットダウンによる問題から保護するための技術に依存します。データストアが分散されるほど、データ整合性の確保はより困難になります。システムの各部分が各データ項目の現在の望ましい状態を反映する必要があるためです。これはしばしば、システムでデータが変更されるたびに、より堅牢な要件と複数のメンバーからの応答によって達成されます。

デプロイ環境の要件を満たすパフォーマンスの提供

データベースは有用であるためには適切に機能する必要があります。必要なパフォーマンス特性は、アプリケーションの特定の要件に大きく依存します。すべての環境には読み取りと書き込み要求の独自のバランスがあり、これら両方のカテゴリで許容できるパフォーマンスが何を意味するかを決定する必要があります。

データベースは一般に、特定の種類の操作を実行する方が得意です。運用パフォーマンス特性は、使用されるデータベースの種類、データスキーマまたは構造、および操作自体を反映していることがよくあります。場合によっては、インデックス作成のような機能（一般的にアクセスされるデータのパフォーマンス最適化された代替ストアを作成する）が、これらのアイテムのより高速な取得を提供できます。他の場合では、データベースが要求されているアクセスパターンにうまく適合しない場合があります。これは、必要なデータベースの種類を決定する際に考慮すべき事項です。

安全な同時アクセスを可能にするプロセスの設定

これは厳密な要件ではありませんが、実用的に言えば、データベースは同時アクセスを許可する必要があります。これは、複数の関係者が同時にデータベースを操作できる必要があることを意味します。レコードは、任意の数のユーザーが同時に読み取ることができ、別のユーザーによってロックされていない場合は書き込み可能である必要があります。

同時アクセスは通常、データベースがユーザーアカウント、権限システム、認証および認可メカニズムなどの他の基本的な機能を実装する必要があることを意味します。また、複数のユーザーが同じデータを同時に操作しようとするのを防ぐための戦略も開発する必要があります。レコードロックとトランザクションは、これらの懸念に対処するためにしばしば実装されます。

データを個別に、または集計して取得する

データベースの基本的な責任の1つは、要求に応じてデータを取得する機能です。要求は単一のレコードに関連付けられた個々のデータである場合もあれば、多くの異なるレコードに見つかるデータを取得することを含む場合もあります。これらの両方のケースが、ほとんどのシステムで可能である必要があります。

ほとんどのデータベースでは、データの取得中にデータベース自体によってある程度のデータ処理が提供されます。これらには、以下の種類の操作が含まれます。

• 条件による検索
• フィルタリングと制約の遵守
• 特定のフィールドの抽出
• 平均、ソートなど

これらのオプションは、必要なデータと最も有用な形式を明確にするのに役立ちます。

ローカルメモリまたは一時ファイルシステム

アプリケーションが生成するデータの中には、役に立たないものや、アプリケーションの寿命の間だけ関連性があるものもあります。そのような場合、アプリケーションが終了すると必要なくなるため、そのデータをメモリに保持するか、一時ファイルシステムにオフロードすることを検討するかもしれません。データがまったく役に立たない場合は、出力を完全に無効にするか、/dev/nullにログを記録することを検討するかもしれません。

アプリケーションデータを直接ローカルファイルシステムにシリアル化する

データベースが必要とされないもう一つのケースは、少量のデータを直接シリアル化および逆シリアル化できる場合です。これは、同時実行をほとんど、またはまったく含まない予測可能な使用パターンを持つ少量のデータにのみ実用的です。これはスケーリングには適していませんが、ローカルログ情報の出力など、特定のケースでは役立ちます。

ファイルのようなオブジェクトを直接ディスクまたはオブジェクトストレージに保存する

アプリケーションのデータは、データベースに保存する代わりに、直接ディスクや別のストレージに書き込むこともできます。たとえば、データが画像や音声ファイルのようにファイル指向の形式ですでに整理されており、追加のメタデータが必要ない場合は、直接ディスクまたは専用のオブジェクトストアに保存するのが最も簡単な場合があります。

サイトデータの保存と処理

データベースの主要な用途の1つは、サイト関連データの保存と処理です。これらの項目は、サイト上の情報の整理方法に影響を与え、多くの場合、サイトの「コンテンツ」の大部分を構成します。

上記の例のアプリケーションでは、データベースがサイトのほとんどのコンテンツ（製品情報、在庫詳細、ユーザープロファイル情報など）を生成します。これは、製品リスト、製品詳細ページ、またはユーザープロファイルを表示する必要があるたびに、データベースまたは何らかの中間キャッシュが参照されることを意味します。

データベースはまた、現在および過去の注文を表示したり、配送料を計算したり、割引コードをチェックしたり、頻繁な顧客の報酬を計算したりして割引を適用したりする際にも関与します。当社の例のサイトでは、データベースシステムを使用して、製品情報、在庫、ユーザー情報を組み合わせて注文を正確に作成します。注文に記録される複合情報は、注文処理を追跡したり、返品を許可したり、注文をキャンセルまたは変更したり、より良い顧客サポートを可能にしたりするために、再びデータベースに保存されます。

より良い意思決定を支援するための情報分析

前回のカテゴリのアクションは、ウェブサイトの基本的な機能に関連していました。これらはアプリケーション層のデータ要件を処理するために非常に重要ですが、全体像を表しているわけではありません。

ウェブアプリケーションがユーザーの登録と注文の処理を開始すると、さまざまな製品がどのように売れているか、最も利益を上げているユーザーは誰か、そして何が売上に影響を与えるかについて詳細な質問に答えることができるようになるでしょう。これらは、組織の傾向とパフォーマンスに関する最新の情報を収集するためにいつでも実行できる分析的な質問です。

これらの種類の操作は、しばしばビジネスインテリジェンスまたはアナリティクスと呼ばれます。これらはまとめて、組織が過去に何が起こったかを理解し、情報に基づいた変更を行うのに役立ちます。データベースシステムは、これらのプロセス中に使用されるデータのほとんどを保存し、それに関する質問に答えるための適切なツールまたはクエリ機能を提供する必要があります。

当社の例のアプリケーションでは、データベースにクエリを実行して、製品の傾向、ユーザー登録数、最も出荷量の多い州、または最も忠実なユーザーは誰かといった質問に答えることができます。これらの比較的基本的なクエリを使用して、より複雑な質問を構成し、製品パフォーマンスに影響を与える要因をよりよく理解し、制御することができます。

ソフトウェア構成の管理

一部の種類のデータベースは、ネットワーク上の他のソフトウェアの設定値のリポジトリとして使用されます。これらは、ネットワーク上の設定値に対する中央の信頼できる情報源として機能します。新しいサービスが起動されると、設定データベースのネットワークアドレスで特定のキーの値をチェックするように構成されます。これにより、サービスのブートストラップに必要なすべての情報を1つの場所に保存できます。

ブートストラップ後、アプリケーションは設定に関連するキーの変更を監視するように構成できます。変更が検出された場合、アプリケーションは新しい設定を使用するように自身を再構成できます。このプロセスは、古いサービスを停止し、新しいサービスを起動することで、時間の経過とともに新しい値を展開する管理プロセスによって調整されることがあり、可用性を維持するために時間の経過とともにアクティブな設定を切り替えます。

当社のアプリケーションは、このタイプのデータベースを使用して、アプリケーション環境全体の永続的な構成データを保存できます。アプリケーションサーバー、ウェブサーバー、ロードバランサー、メッセージングキューなどは、構成データベースを参照して本番設定を取得するように構成できます。アプリケーション開発者は、中央の場所で構成値を調整することで、環境の動作を変更できます。

ログ、イベント、その他の出力の収集

アクティブにリクエストを処理しているアプリケーションは、多くの出力を生成する可能性があります。これには、ログファイル、イベント、その他の出力が含まれます。これらはディスクまたはその他の管理されていない場所に書き込まれる可能性がありますが、その有用性は制限されます。このタイプのデータをデータベースに収集すると、作業が容易になり、パターンを特定し、予期しない事態が発生した場合や過去のパフォーマンスについて詳しく知る必要がある場合にイベントを分析しやすくなります。

当社の例のアプリケーションは、より簡単に分析できるように、各システムからのログを1つのデータベースに収集するかもしれません。これは、問題の原因を分析しようとするときや、環境全体の健全性を理解しようとするときに、イベント間の相関関係を見つけるのに役立ちます。

また、インフラストラクチャやコードによって生成されるメトリクスを、時間を追って値を追跡するために特別に設計されたデータベースである時系列データベースに収集することもあります。このデータベースは、リアルタイムの監視および可視化ツールを強化するために使用され、アプリケーションの開発チームと運用チームにパフォーマンス、エラー率などに関する情報を提供します。

データアーキテクト

データアーキテクトは、データベースシステムの全体的なマクロ構造、アプリケーションや開発チームに公開するインターフェース、および組織のデータニーズを満たすために必要な基盤となるテクノロジーとインフラストラクチャを担当します。

この役割の担当者は通常、異なるアプリケーションに使用される適切なデータベースモデルと実装を決定します。彼らは、オプションを調査し、テクノロジーを決定し、既存のシステムと統合し、組織全体の包括的なデータ戦略を開発することで、データベースの決定を実装する責任を負います。彼らはデータシステム全体を包括的に扱い、さまざまなプロジェクトのデータモデルの決定と実装に関与します。

DBA（データベース管理者）

データベース管理者、またはDBAは、データシステムをスムーズに稼働させる責任を負う個人です。彼らは、新しいデータシステムの計画、ソフトウェアのインストールと構成、他の当事者のためのデータベースシステムの設定、およびパフォーマンス管理を担当します。また、データベースのセキュリティ確保、問題の監視、使用パターンに合わせてシステムを最適化するための調整も担当することがよくあります。

データベース管理者は、個々のデータベースシステムと、それらを基盤となるオペレーティングシステムやハードウェアと適切に統合してパフォーマンスを最大化する方法の両方の専門家です。彼らはデータベースを使用するチームと密接に連携し、容量とパフォーマンスの管理を支援し、データベースシステムの問題をトラブルシューティングするのを支援します。

アプリケーション開発者

アプリケーション開発者は、さまざまな方法でデータベースと対話します。彼らはデータベースと対話するアプリケーションの多くを開発します。これらのアプリケーションは、個々のユーザーや顧客がデータベースシステムによって管理されるデータとどのように対話するかを制御する唯一のアプリケーションであることがほとんどであるため、これは非常に重要です。パフォーマンス、正確性、信頼性は、アプリケーション開発者にとって信じられないほど重要です。

開発者は、アプリケーションに関連するデータ構造を管理し、データをディスクに永続化させます。彼らは、プログラミングデータをデータベースシステムにマッピングできるメカニズムを作成または使用し、コンポーネントが調和して機能するようにする必要があります。アプリケーションが変更されるにつれて、データベースシステム内のデータとデータ構造を同期させる必要があります。開発者がデータベースとどのように連携するかについては、記事の後半で詳しく説明します。

SRE（サイト信頼性エンジニア）および運用プロフェッショナル

SRE（サイト信頼性エンジニア）および運用プロフェッショナルは、インフラストラクチャおよびアプリケーション構成の観点からデータベースシステムと連携します。彼らは、追加の容量のプロビジョニング、データベースシステムの立ち上げ、データベース構成が組織のガイドラインに一致することの確認、稼働時間の監視、およびバックアップの管理を担当する場合があります。

多くの点で、これらの個人はDBAと重複する責任を負いますが、データベースだけに焦点を当てているわけではありません。運用スタッフは、データベースシステムを含む、組織の残りの部分が依存するシステムの信頼性の高い機能と最小限のダウンタイムを確保します。

ビジネスインテリジェンスとデータアナリスト

ビジネスインテリジェンス部門とデータアナリストは、主にデータベースシステム内にすでに収集され利用可能なデータに関心があります。彼らはデータ内の傾向とパターンに基づいて洞察を開発し、将来のパフォーマンスを予測したり、潜在的な変更について組織に助言したり、マーケティングや営業などの他の部門のためにデータに関する質問に答えたりします。

データアナリストは通常、データシステムへの読み取り専用アクセスのみで作業できます。彼らが実行するクエリは、プライマリアプリケーションが使用するクエリとは劇的に異なるパフォーマンス特性を持つことがよくあります。このため、彼らはしばしばデータベースレプリカ（コピー）と連携して、プライマリデータベースシステムのリソース使用量に影響を与える可能性のある、長時間実行されパフォーマンス集約的な集計クエリを実行できるようにします。

アプリケーションとデータベース間のデータ変換

データベースと通信するための既存のインターフェースを作成するか、使用する必要があります。通常のネットワーク関数、シンプルなライブラリ、またはより高レベルのプログラミングライブラリ（例：クエリビルダーやORM）を使用してデータベースに直接接続できます。

ORM、またはオブジェクトリレーショナルマッパーは、リレーショナルデータベースにあるテーブルをオブジェクト指向プログラミング言語で使用されるクラスに変換し、その逆も行うマッピング層です。この変換はしばしば有用ですが、決して完璧ではありません。オブジェクトリレーショナルインピーダンスミスマッチは、リレーショナルデータベースとオブジェクト指向プログラムがデータを構造化する方法の違いによって生じる摩擦を説明するために使用される用語です。

リレーショナルデータベースとオブジェクト指向プログラミングは2つの特定の設計選択を記述しますが、アプリケーションとデータベース層の間で変換する問題は、データベースの種類やプログラミングパラダイムに関係なく存在する一般的な問題です。データベース抽象化層は、これら2つのコンテキスト間を変換する責任を持つソフトウェアのより一般的な用語です。

データベースとの構造的変更の同期

アプリケーションを開発する上で発見する重要な事実の1つは、データベースがコードベースの外に存在するため、データ構造の変更に対応するために特別な注意が必要であるということです。この問題は、他のデータベース設計よりも一部のデータベース設計でより顕著です。

アプリケーションのデータ構造とデータベースを同期させる最も一般的なアプローチは、データベースマイグレーションまたはスキーママイグレーション（どちらも口語的には単にマイグレーションとして知られています）と呼ばれるプロセスです。マイグレーションには、アプリケーションのデータモデルの進化に合わせてデータベースの構造を更新することが含まれます。これらは通常、各進化に対応する一連のファイルとして存在し、データベースを新しい形式に変換するために必要なステートメントが含まれています。

データへのアクセス保護と入力のサニタイズ

開発者としてデータベースを扱う際の重要な責任の一つは、アプリケーションがデータへの不正アクセスを許さないようにすることです。データセキュリティは、多くの利害関係者を巻き込む、広範で多層的な問題です。最終的に、セキュリティに関する考慮事項の一部はあなたの責任で対応する必要があります。

あなたのアプリケーションは、日常的なタスクを実行するためにデータベースへの特権アクセスを必要とします。安全のために、データベースの承認フレームワークは、アプリケーションが実行できる操作の種類を制限するのに役立ちます。ただし、アプリケーションがそれらの操作を適切に制限していることを確認する必要があります。例えば、アプリケーションがユーザープロファイルデータを管理している場合、ユーザーがそのアクセスを悪用して他のユーザーの情報を表示または編集するのを防ぐ必要があります。

具体的な課題の1つは、ユーザー入力のサニタイズです。入力のサニタイズとは、ユーザーが提供するあらゆるデータを操作する際に特別な予防措置を講じることを意味します。悪意のあるアクターが通常のユーザー入力メカニズムを使用してアプリケーションを騙し、機密データを漏洩させるという長い歴史があります。これらのシナリオから保護するためにアプリケーションを設計することは重要なスキルです。