データベースは、整理されたデータのコレクションを保管、管理、保護するためのデジタル・リポジトリです。
データベースの種類が異なれば、データを保管する方法も異なります。例えばリレーショナル・データベースの場合、データは行と列を含む定義されたテーブルに保管されますが、非リレーショナル・データベースでは、キー・バリューペアやグラフなど、さまざまなデータ構造として保管できます。
組織はこうしたさまざまな種類のデータベースを使用して、さまざまな種類のデータを管理します。リレーショナル・データベースは、財務記録などの構造化データに適しています。非リレーショナル・データベースは、テキストファイル、音声、ビデオなどの非構造化データに最適です。ベクトル・データベースは、多くの生成AI アプリケーションで使用されるベクトル埋め込み形式でデータを保管します。
企業は、顧客との取引や製品在庫、社内プロセスや独自の調査に至るまで、あらゆるものに関する大量のデータを保有しています。そのデータは、多くの場合、ペタバイト(1兆回のビット)単位で測定されます。このデータは、ユーザーやアプリが必要なときにアクセスできるように、一貫したデータ・アーキテクチャで整理する必要があります。
データベースは、このようなデータ・アーキテクチャを構築するための基盤です。単なる情報の保管場所ではありません。むしろ、データベースによって組織はデータを集中管理し、データの整合性とセキュリティ標準を適用し、データ・アクセスを促進することができます。
適切なデータベース・システムを導入することで、組織はビジネス・インテリジェンス(BI)、人工知能(AI)、機械学習(ML)プロジェクトなどの主要なビジネス・イニシアチブに高品質のデータ・セットを使用できるようになります。
「データベース」という用語は、かなり曖昧に使われることが多く、データベースとは何であり、何ではないのかという点で混乱を招くことがあります。
データベースは、データを保管および管理するためのシステムであり、データが保管されている物理ハードウェアと、データへのアクセスを整理および制御するソフトウェアの両方で構成されています。
データベースは、Webサイト、アプリ、AmazonやGoogleなどのプラットフォームを含む、多くの最新の ITインフラストラクチャーを支えています。これらのサービス自体はデータベースではありませんが、製品在庫や検索成果などの情報を管理するためにデータベースを利用しています。
また、Microsoft Excelはデータベースではなく、スプレッドシート・アプリケーションであるということも知っておくとよいでしょう。Excelのスプレッドシートは、リレーショナル・データベースと同じようにデータを行と列に編成しますが、そのスプレッドシートは単一のファイルです。ただし、データベースは、より高度なクエリーをサポートしながら、さまざまな種類のデータをさまざまな形式で保管できる堅牢な集中管理システムです。
組織は、さまざまなタイプのデータベースを使用して、さまざまなタイプのデータを管理し、さまざまなアプリケーションをサポートします。最も一般的なデータベースの種類としては、次のようなものがあります。
ナビゲーション・データベースは、リンクされたレコードのセットにデータを保管します。ユーザーは必要なデータに到達するために、これらのレコードの間を移動する必要があるため、この名前が付けられています。
最も一般的な2種類のナビゲーション・データベースは、階層データベースとネットワーク・データベースの2つです。
階層型データベースは、親レコードと子レコードのツリー構造にデータを配置します。各子レコードは 1 つの親のみを持つことができますが、親レコードは複数の子を持つことができます。目的のレコードに到達するには、ユーザーはツリーの一番上から始めて、下に向かって作業する必要があります。
ネットワーク・データベースは階層型データベースとよく似ていますが、子レコードを複数の親レコードにリンクできる点が異なります。ユーザーは、通常、ポインターを使用して目的のデータに到達するために、リンクされたレコード内を移動する必要があります。
かつてはナビゲーション・データベースが一般的でしたが、データベースのテクノロジーの進歩、特にリレーショナル・データモデルの開発により、その人気は大きく下がりました。
リレーショナル・データベースは、行と列に分けられたされたテーブルにデータを保管します。多くのリレーショナル・データベースは、データのクエリと操作のために構造化クエリ言語(SQL)をサポートしているため、「SQLデータベース」と呼ばれることもあります。(詳細については、「データベース言語」を参照してください)。
リレーショナル・データベースのテーブルには、それぞれ1つのタイプのエンティティーに関する情報が含まれています。たとえば、ある組織には、すべての顧客に関する情報を含むテーブルと、個々の顧客の購入履歴を詳細に記載する個別のテーブルが必要です。
IBMの科学者、Edgar F. Coddは、1970年代にリレーショナル・モデルを開発しました。このモデルは、データを取得する作業を大幅に簡素化するため、ほどなくナビゲーション・モデルを上回るペースで普及しました。レコード間のパスを指定する代わりに、ユーザーはSQL ステートメントを使用して、必要なデータを指名できます。このデータベースは関連するレコードを取得するために、しばしば全テーブル検索の代わりにインデックスを使用してプロセスを高速化します。
また、リレーショナル・データベースでは、各データ・ポイントを一度保管する必要があるため、冗長性も減ります。異なるテーブルのデータを、データを複製することなく統合ビューに組み合わせることができます。
リレーショナル・データベースは、現代で最も一般的なデータベースの1つです。金融取引やユーザーの連絡先情報など、標準的な形式による構造化されたデータ・セットの管理に適しています。
「NewSQLデータベース」と呼ばれる最近のリレーショナル・データベースは、分散データベース・アーキテクチャー、つまり複数のデータベース・サーバーにデータを分散することで、リレーショナル・モデルのスケーラビリティを高めることを目的としています。
「非リレーショナル・データベース」は、基本的にはテーブルのような厳密な形式でデータを保管しないデータベースを指す包括的な用語です。これらは、一般にSQLを必要としないため、「NoSQLデータベース」と呼ばれることもあります。
非リレーショナル・データベースは、リレーショナル・テーブルにはうまく収まらない、自由形式のテキストや画像などの非構造化・半構造化データをサポートするために生まれてきました。
一般的な非リレーショナル・データベースには次のようなものがあります:
グラフ・データベース。データを「ノード」(エンティティを表す)と「エッジ」(ノード間の関係を表す)として保存します。グラフ・データベースは、ソーシャル・ネットワーキング・サイトのユーザー間のつながりなどの関係を追跡するためによく使用されます。
ドキュメント・データベースは、JSON、XML、BSON などの形式を含むドキュメントとしてデータを保管します。ドキュメントデータベースは、コンテンツ管理システムでは一般的です。
キー・バリュー・データベースは、情報をキーと値のペアとして保管します。キーは一意の識別子(デジタルショッピングカートのIDなど)で、値はデータの配列(カート内のアイテムなど)です。
ワイドカラムデータベースは、リレーショナルデータベースのように行と列を使用します。違いは、各行に他の行と異なる情報を保管する独自の列セットを設定できることです。ワイドカラムデータベースは、複数のソースからデータを抽出して一元管理する必要があるデータウェアハウスをサポートするためによく使用されます。
オブジェクト指向データベースはオブジェクト・データベースとも呼ばれ、オブジェクト指向プログラミングのようにデータをオブジェクトとして保管します。
オブジェクトは基本的に、情報とそれに関連づけられたコードのバンドルです。各オブジェクトはエンティティを表します。オブジェクトはクラスにグループ化され、その特性と動作を定義するメソッドを持っています。
たとえば、「ネコ」クラスのオブジェクトには、「色」と「体重」という属性、および「喉を鳴らす」と「狩りをする」というメソッドがある場合があります。
オブジェクト指向データベースは、1990年代にオブジェクト指向プログラミングとともに人気が高まりました。リレーショナル・データベースは、オブジェクト指向言語で構築された一部のアプリで問題を引き起こす場合があります。データベースに保管するために、データ・オブジェクトをテーブルに変換する必要があるからです。オブジェクト指向データベースを使用すると、開発者はその問題を回避できます。
ベクトル・データベースは、情報を「ベクトル」と呼ばれる数値の配列として保管し、類似性に基づいてクラスター化します。例えば天気モデルである日の最低気温、平均気温、最高気温をベクトル形式で表すと、[62、77、85]となります。
ベクトルは、単語、画像、動画、音声などの複雑なオブジェクトを表すこともできます。高次元のベクトルデータは、機械学習、自然言語処理(NLP)その他の AI タスクに不可欠です。
ベクトル・データベースは、AIとMLのユースケースで一般的です。例えば 大規模言語モデル(LLM)が外部のナレッジベースからファクトを取得できるようにする 検索拡張生成(RAG)フレームワークの多くの実装では、ベクトル・データベースが使用されます。
クラウド・データベースはクラウドでホストされるデータベースです。リレーショナル、非リレーショナル、またはその他のデータベースなど、どの種類のデータベースでもクラウド・データベースになりえます。
クラウド・データベースには、主に2つのタイプがあります。最も基本的なものである1つ目は、クラウドで実行されるセルフマネージド式のデータベース・システムです。もう1つはサービスとしてのデータベース(DBaaS)と呼ばれるものです。
DBaaSは、ユーザーがシステムを自分で管理しなくてもデータベースソフトウェアにアクセスして使用できるようにするクラウド・コンピューティングサービスです。名前が示すように、DBaaSプロバイダーは、アップグレード、バックアップ、データベース・セキュリティーなどを含むスイートのデータベースサービスを提供しています。
クラウド・データベースはオンプレミス・データベースよりもスケーラブルです。組織がより多くのストレージ容量を必要としたり、パフォーマンスが低下し始めたら、必要に応じてより多くのリソースを投入できます。
マルチモデル・データベースには、複数の種類のデータを保管できます。例えば、IBM Db2 Cloud Databasesは、1つのデータベース・インスタンスでXML、JSON、テキスト、および空間データをサポートできます。
インメモリデータベースは、デバイスのメインメモリまたはRAMに情報を保管します。アプリケーションは通常、従来のデータベースからよりも速くRAMからデータを取得できるため、インメモリー・データベースはデータをキャッシュし、リアルタイムのデータ処理に対応するためによく使用されます。 ただし、ストレージ容量ははるかに制限されており、RAMは標準のデータベースよりも揮発性であるため、データが失われやすくなっています。
データベースはデータを整理する唯一の方法ではなく、組織は各種の取り組みをサポートするためにしばしばさまざまなデータ・ストアを使用します。
データベースは主に、自動的なデータ取得、クエリとトランザクション処理の高速化を目的として構築されています。
データレイクは大量の生の構造化データと非構造化データを処理するために設計された低コストのストレージ環境です。データベースとは異なり、データレイクは通常、データのクリーニング、検証、正規化を行いません。通常はリアルタイムのパフォーマンスがそれほど重要ではないAIトレーニングやビッグデータ分析などのアクティビティをサポートするために、膨大な量のデータを格納します。
データウェアハウスは、データ分析、ビジネス・インテリジェンス、データサイエンスの取り組みをサポートするために構築されます。さまざまなデータベースからデータを集約し、クリーニングして、すぐに使用できるように準備します。
データレイクハウスは、データウェアハウスとデータレイクの機能を単一のデータ管理ソリューションに統合します。レイクハウスは、低コストのストレージと高性能のクエリー・エンジンおよびインテリジェントなメタデータ・ガバナンスを組み合わせたものです。これにより、組織は大量の構造化データと非構造化データを保管し、そのデータをAI、ML、分析の取り組みに簡単に使用できるようになります。
大枠としては、データベースシステムには2つの主要コンポーネントがあります。1つはデータを物理的または論理的に格納するデータ・ストレージ・システム、もう1つは保管されたデータセットをユーザーが操作できるようにするデータベース管理システム(DMBS)です。
データベース・システムのコンポーネントをより詳細に見ていくと、データベースの仕組みをさらに深く理解することができます。
データベースは、データを何らかのハードウェアに保管する必要があります。とはいえ、データベースに専用のマシンは必要ありません。
代わりに、ほとんどのデータベース・システムは、コンピューター、サーバー、またはその他のデバイス上で動作するデータベース・ソフトウェアで構成されています。マシンはデータベースを実行するための物理ハードウェアを提供します。ソフトウェアはデータの論理的な配置を処理します。例えばリレーショナル・データベース内のテーブルや、グラフ・データベースの内のグラフとしてのデータをフォーマットします。
データベースとそれを使用するアプリケーションは同じハードウェア上で実行できますが、現在、ほとんどのデータベース・システムは、アプリケーション・サーバーとデータベース・サーバーを分離する多層アーキテクチャを採用しています。この配置により、拡張性と信頼性が向上します。アプリケーション・サーバーとデータベース・サーバーは互いに独立して拡張できるため、ある階層で障害が発生しても他の階層に影響する必要はありません。
データ・モデルは、情報システムを視覚的に表現したものです。データ・モデルは、データベースの管理者や設計者が、追跡すべきデータの種類、データポイント間の関係、データを整理する最適な方法を理解するために使用する概念的ツールです。
データ・モデルは、適切なデータベース・モデル、つまり技術的な要件やストレージ形式を含むデータベース・システムの実用的な実装を特定するのに役立ちます。例えば先述の論理データモデルからは、次のようなリレーショナル・データベースが導かれるでしょう。
データベース・スキーマは、データベース内でデータがどのように編成されるかを技術的および論理的に定義します。別の言い方をすれば、データ・モデルをデータベースが従うための一連のルールに翻訳したものです。
たとえば、リレーショナル・データベースのスキーマでは、テーブル名、フィールド、データ・タイプ、およびその関係などを定義します。
スキーマは、図表で可視化したり、SQLステートメントまたはその他のプログラミング言語で記述したり、その他の方法で定義したりできます。この手段はスキーマのタイプと対象のデータベースシステムによって異なります。
すべてのリレーショナル・データベース・システムにはスキーマがあります。非リレーショナル・データベースでは、スキーマのあるものとないもの、そしてスキーマを設定できるものの必須ではない場合があります。
データベース管理システム(DBMS)は、データベース管理者、ユーザー、アプリがデータベース内のデータに簡単にインターフェースできるようにするソフトウェアです。
DBMS システムを使用すると、ユーザーはデータベースのフォーマット、メタデータの管理、データ セットのクエリ、データの追加、更新、削除などの主要なデータ管理タスクを実行できます。
一部のDBMSは、データベース・アクセス制御を適用したり、ユーザー・アクティビティーをロギングしたりすることで、データ・セキュリティー対策の強化に役立ちます。また、データベースの性能を追跡する場合もあります。
データベースそのものと同様、DBMSにもさまざまなモデルがあります。たとえば、リレーショナル・データベース管理システム(RDBMS)はリレーショナル・データベースのために構築されたものであり、オブジェクト指向データベース管理システム(OODBMS)はオブジェクト指向データベースを管理するためものです。
一般的なデータベース管理システムには、次のようなものがあります。
MySQLは、eコマース・サイトやその他のWebアプリでよく使用されるオープンソースのRDBMSです。
PostgreSQLは、拡張性とトランザクションの信頼性を重視することで知られています。
Microsoft SQL Serverは、Microsoftのネットワークがある組織で広く使用されています。
Oracle Databaseは、構造化データと非構造化データの両方を管理できるマルチモデルDBMSです。
IBM Db2は、リアルタイム分析とAIアプリケーションをサポートするデータベース管理、ウェアハウジング、ストレージ、およびその他の機能を含むクラウドネイティブなデータベース・システムです。
データベース言語は、データベースと対話するために使用する特殊なプログラミング言語です。これらは、データを取得、結合、更新、またはその他の方法で使用するためのクエリーを作成するための構文をユーザーに提供します。
最も一般的なデータベース言語は、ほとんどのリレーショナル・データベースで使用されている構造化クエリ言語(SQL)です。1970 年代に IBM の科学者によって開発された SQL は、データベース管理者、開発者、データ・アナリストが、データ定義、アクセス制御、データ共有、データ統合、分析クエリなどのタスクを実行するのに役立ちます。
他のデータベース言語には、オブジェクト指向データベースで動作するオブジェクト照会言語(OQL)や、XMLドキュメント・データベースで動作するXQueryなどがあります。
MongoDB用のMongoDBクエリ言語(MQL)や Apache Cassandra用のCassandraクエリ言語(CQL)など、データベース固有の言語もあります。
データベースは、リレーショナル・データベースで金融取引を追跡する銀行アプリから、ベクトル・データベースを使用して精度を向上させるAIアシスタントまで、今日人々が依存している多くのテクノロジーに欠かせません。データベースがここまで普及しているのは、下記の用途をサポートするからです。
今日、組織は大量のデータを所有していますが、人々がそのデータを活用できなければ、そのことは意味がありません。 実際、 IBM Data Differentiator の報告によると、企業データの 68% は分析されていないそうです。 多くの場合、その理由は、人々がそのアプリの存在に気づいなかったり、サイロ化によってアクセスが妨げられたりしているためです。
データベースは、組織がデータの集合をキュレートし、保管し、一元管理する方法を提供します。また、イベントやトランザクションをリアルタイムでキャプチャするなど、データ収集プロセスの多くを自動化するのにも役立ちます。
組織でデータベース・アプリケーションを選択し、設計し、実装する方法によって、重要なビジネス・イニシアティブの成否が決まることもあります。データが整理され、簡単にアクセスできる体制があれば、意思決定が促進され、ビジネス・インテリジェンスが進展し、AIやML プロジェクトを強化できます。
データベースには、エラー、冗長性、不正確さが発生しやすいスプレッドシートやその他の手動記録管理プロセスに比べ、大きな利点があります。
データベースは集中管理できるため、クレンジングやフォーマットのルールの適用、使用状況の監視、データ・リネージュの追跡が容易になります。また、データベースにより、時間の経過とともに非同期化される可能性があるデータセットの複数のコピーを循環させる必要がなくなります。代わりに、すべてのアプリケーションとユーザーが同じ共有リポジトリーで作業できます。
最終的に、データベースは、あらゆる種類のユーザー (人、アプリ、 API)をクリーンかつ信頼できるデータに接続するのに役立ちます。
場所や業界に応じて、組織は米国の医療保険の相互運用性と説明責任に関する法律(HIPAA法)や EU の 一般データ保護規則(GDPR) どのデータ保護 およびデータ・プライバシー規制に準拠する必要があります。
法的義務にとどまらず、組織が不正なデータ・アクセスを防止することにはビジネス上の利益もあります。IBM のデータ侵害のコストに関する調査によると、平均的なデータ侵害コストは、ビジネス損失、システムダウンタイム、修復作業、その他のコストを合わせて 488 万ドルです。
データベースは、ロールベースのアクセス制御(RBAC)をはじめとするデータ・セキュリティー 対策を導入し、適切なユーザーのみが適切なデータにアクセスできるようにすることで、データを保護し、コンプライアンスを維持するのに役立ちます。
CEOの75%が、最先端の生成AIの導入が今後の組織の競争優位性の決定要因になると考えています。このような高度なAIをサポートするために、組織は大量の構造化データと非構造化データを保管、管理、制御する能力が必要です。それを実現するには、適切なデータベースシステムの導入が不可欠です。
AIとMLの取り組みは、さまざまな種類のデータベースによって、さまざまな方法でサポートできます。たとえば、ベクトル・データベースは、ハルシネーションを軽減するのに役立つRAGフレームワークを実装するために広く使用されています。キー・バリュー・データベースは、データの検索と処理をスピードアップできます。インメモリ・データベースは、キャッシュとストリーミング分析をサポートできます。
具体的なイニシアチブのために組織がデータベースを選択する場合は、いくつかの要因が影響します。最も重要な要因としては次のものがあります。
データの種類:データベースの種類によって、扱うデータの種類は異なります。例えば関係のマッピングには、多くの場合、SQLデータベースよりもグラフ・データベースの方が適しています。
目的:データベースの種類によって、適している用途も異なります。たとえば、ベクトル・データベースは多くの場合、RAG フレームワークに最適な選択です。
性能の要件: アプリがリアルタイムでデータを継続的に取得する場合、組織にはクエリ速度を最適化するデータベースが必要です。ただし、データをウェアハウスに送信する前に保管する場所が必要だという場合、性能はそれほど重要ではない場合もあります。
価格:組織が保存する必要があるデータの量、そのデータの形式、およびパフォーマンス要件は、いずれもデータベースのコストに影響します。
拡張性:一部のデータベースは垂直方向にのみ拡張できます。つまり、既存のサーバーまたはマシンにリソースを追加する必要があります。また、水平方向に拡張することもできます。つまり、より多くのサーバーを追加して、分散型でデータベースをサポートすることができます。