リレーショナル・データベースとは

IBMのDon ChamberlinとRay Boyceによって発明された構造化照会言語（SQL）は、リレーショナル・データベース管理システムと対話するための標準プログラミング言語であり、データベース管理者がデータの行を簡単に追加、更新、削除できるようになります。 元々はSEQUELとして知られていましたが、商標の問題によりSQLに簡略化されました。 SQLクエリを使用すると、ユーザーはわずか数行のコードを使用してデータベースからデータを取得することもできます。 この関係を考慮すると、リレーショナル・データベースが「SQL データベース」とも呼ばれる理由が簡単にわかります。

上記の例を使用すると、次のコードを使用して、特定の年の企業ごとの上位10件のトランザクションを検索するクエリを作成できます。

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

この方法でデータを結合できるため、データ・システム内の冗長性が軽減され、データチームが顧客用に1つのマスターテーブルを維持できるようになり、将来に別のトランザクションが発生した場合に、この情報を複製することができます。さらに詳しく知りたい方は、Donがこちらの論文（ibm.com外部へのリンク）でSQLの歴史について詳しく説明しています。

リレーショナル・データベースが登場する以前、企業はデータ・テーブルにツリー状の構造を備えた階層データベース・システムを使用していました。これらの初期のデータベース管理システム（DBMS）により、ユーザーは大量のデータを管理できるようになりました。ただし、それらは複雑で、多くの場合、特定のアプリケーションに固有のものであり、データ内で発見できる方法は限られていました。これらの制限により、最終的にIBMの研究者、Edgar F. Coddは、1970年にリレーショナル・データベースモデルを理論化した「大規模共有データ・バンクのためのデータのリレーショナル・モデル」という論文（Ibm.com外部へのリンク）を発表しました。この提案されたモデルでは、コンピュータの専門知識がなくても情報を取得できます。彼は、タプル、つまり属性と値のペアとして意味のある関係に基づいてデータを配置することを提案しました。タプルのセットはリレーションと呼ばれ、最終的にテーブル間のデータのマージが可能になりました。

1973 年、サンノゼ研究所（現アルマデン研究センター）は、このリレーショナル理論を「業界に耐えうる強力な実装」と呼ばれるもので証明するために、システムR（リレーショナルのR）と呼ばれるプログラムを始動しました。 最終的にはSQLの実験場にもなり、短期間でより広く採用されるようになりました。 ただし、OracleがSQLを採用しても、データベース管理者の間での人気は損なわれませんでした。

1983年までに、IBMはリレーショナル・データベースのDB2ファミリを導入しました。DB2ファミリは、IBMの2番目のデータベース管理ソフトウェア・ファミリであるため、この名前が付けられました。 現在、これはIBMの最も成功した製品の1つであり、クラウド・インフラストラクチャ上で毎日数十億のトランザクションを処理し続け、機械学習アプリケーションの基盤を構築しています。

リレーショナル・データベースはデータを表形式に構造化しますが、非リレーショナル・データベースにはデータベース・スキーマほど厳密ではありません。 実際、非リレーショナル・データベースは、データベースの種類に基づいてデータを異なる方法で管理します。 非リレーショナル・データベースの種類に関係なく、これらはすべて、テキスト、ビデオ、画像などの非構造化データ形式には理想的ではないリレーショナル・モデルに固有の柔軟性と拡張性の問題を解決することを目的としています。 これらのタイプのデータベースには、次のものが含まれます。

• キー・バリュー・ストア：このスキーマのないデータモデルは、キーと値のペアの辞書で構成され、各項目はキーと値を持ちます。キーは、ショッピングカートIDなど、SQLデータベースにあるものに似ていますが、値はユーザーのショッピングカート内の個々の商品などのデータの配列です。 これは、ショッピングカートなどのユーザー・セッション情報のキャッシュと保存によく使用されます。 ただし、一度に複数のレコードを取得する必要がある場合には理想的ではありません。 RedisとMemcachedは、このデータ・モデルを備えたオープンソース・データベースの例です。

• ドキュメント・ストア：名前から想像できるように、ドキュメント・データベースは、データをドキュメントとして保存します。半構造化データの管理に役立ち、データは通常JSON、XML、BSON形式で保存されます。これにより、アプリケーションでデータを使用する際、データをまとめておくことができ、データを使用するために必要な翻訳の量を減らすことができる。 また、データ・スキーマがドキュメント間で一致する必要がないため、開発者はより柔軟性を得ることができます（例：nameとfirst_name）。しかし、これは複雑なトランザクションでは問題となり、データの破損につながる可能性があります。 ドキュメント・データベースの一般的なユースケースとしては、コンテンツ管理システムやユーザー・プロファイルなどがあります。ドキュメント指向データベースの例としては、MEANスタックのデータベース・コンポーネントである「MongoDB」があります。

• ワイドコラム・ストア：これらのデータベースは列に情報を格納するため、ユーザーは無関係なデータに追加のメモリを割り当てることなく、必要な特定の列にのみアクセスできます。 このデータベースは、キー・バリュー・ストアとドキュメント・ストアの欠点を解決しようとしますが、管理がより複雑なシステムになる可能性があるため、新しいチームやプロジェクトでの使用はお勧めしません。 Apache HBaseとApache Cassandraは、オープンソースのワイドカラム・データベースの例です。 Apache HBaseは、多くのビッグデータの応用で一般的に使用されているスパース・データ・セットを格納する方法を提供するHadoop分散ファイル・システム上に構築されています。 一方、Apache Cassandraは、複数のサーバーと複数のデータセンターにまたがるクラスタリングにまたがる大量のデータを管理するように設計されています。 ソーシャルネット・ワーキングWebサイトやリアルタイムでのデータ分析など、さまざまなユースケースで使用されています。

• グラフ・ストア：このタイプのデータベースは通常、ナレッジ・グラフのデータを格納します。データ要素はノード、エッジ、プロパティとして保存されます。 あらゆるオブジェクト、場所、人物がノードになることができます。 エッジはノード間の関係を定義します。 グラフ・データベースは、グラフ内の要素間の接続ネットワークを保存および管理するために使用されます。 Neo4j（IBM外部へのリンク）は、Javaベースのグラフベースのデータベース・サービスで、ユーザーはオンライン・バックアップと高可用性拡張機能のライセンス、またはバックアップと拡張機能が含まれるプレパッケージ・ライセンス・バージョンを購入できるオープンソース・コミュニティ・エディションを備えています。

NoSQLデータベースも、一貫性よりも可用性を優先します。

コンピュータがネットワーク上で実行される場合、一貫性のある結果（すべての回答が常に同じ）を優先するか、または「可用性」と呼ばれる長いアップタイムを優先するかを必ず決定する必要があります。これは「CAP理論」と呼ばれ、一貫性、可用性、またはパーティション・トレランスの略です。リレーショナル・データベースにより、情報が常に同期され、一貫性が保たれます。 Redisなどの一部のNoSQLデータベースでは、常にレスポンスを提供することを好みます。つまり、クエリから受け取る情報は、数秒、場合によっては最大30秒ほど不正確になる可能性があります。ソーシャルメディア・サイトでは、最新のプロフィール写真がほんの数分前に投稿されたばかりなのに、古いプロフィール写真が表示されることになります。代わりに、タイムアウトまたはエラーが発生する可能性があります。一方、銀行や金融取引では、古くて不正確な情報よりも、エラーを出して再送信する方がよい場合があります。

SQLとNoSQLの違いの詳細については、「SQLとNoSQLデータベース：その違いとは」を参照してください。

リレーショナル・データベース・アプローチの主なメリットは、テーブルを結合することで意味のある情報が得られることです。 テーブルを結合することで、データ間の関係（リレーション）、つまりテーブルがどのようにつながっているかを理解することができます。 SQLには、クエリのカウント、追加、グループ化、および結合を行う機能が含まれています。 SQLは、基本的な数学関数、小計関数、および論理変換を実行できます。 アナリストは、日付、名前、または任意の列で結果を並べ替えることができます。 これらの機能により、リレーショナル・アプローチは、今日のビジネスにおいて最も使用されているクエリ・ツールとなっています。

リレーショナル・データベースには、他のデータベース形式と比較していくつかの利点があります。

操作性

その製品寿命のおかげで、リレーショナル・データベースを中心としたコミュニティがより多く存在し、部分的に継続使用が継続されています。 SQLを使用すると、複数のテーブルからデータ・セットを取得したり、フィルタリングや集計などの単純な変換を実行したりすることも簡単になります。 リレーショナル・データベース内でインデックスを使用すると、選択したテーブルの各行を検索しなくても、この情報をすばやく見つけることができます。

これまで、リレーショナル・データベースはより柔軟性に欠けるデータ・ストレージ・オプションと見なされてきましたが、テクノロジーとDBaaSオプションの進歩により、その認識は変わりつつあります。 NoSQLデータベース製品と比較して、スキーマを開発するにはまだ多くのオーバーヘッドがありますが、リレーショナル・データベースはクラウド環境に移行するにつれて柔軟性が高まっています。

冗長性の低減

リレーショナル・データベースは2つの方法で冗長性を排除できます。 リレーショナル・モデル自体は、正規化と呼ばれるプロセスを通じて、データの冗長性を低減します。 前述したように、顧客テーブルでは、顧客情報の一意のレコードのみをログに記録する必要があり、複数のトランザクションに対してこの情報を複製する必要はありません。

ストアド・プロシージャは、反復作業の削減にも役立ちます。 たとえば、データベースへのアクセスが特定の役割、機能、またはチームに制限されている場合、ストアド・プロシージャはアクセス制御の管理に役立ちます。 これらの再利用可能な機能により、アプリケーション開発者は時間を有効活用して、よりインパクトの大きい業務に取り組むことができます。

バックアップと災害復旧の簡素化

リレーショナル・データベースはトランザクションに対応しており、システム全体の状態がいつでも一貫していることが保証されます。ほとんどのリレーショナル・データベースには、簡単なエクスポートとインポートのオプションが用意されているため、バックアップと復元が容易になります。これらのエクスポートはデータベースの実行中でも実行できるため、障害が発生した際の復元が簡単になります。最新のクラウドベースのリレーショナル・データベースは継続的なミラーリングを実行できるため、復元時のデータ損失を数秒以内に抑えられます。 IBM Cloud Databases for PostgreSQLなど、ほとんどのクラウド管理サービスではリード・レプリカを作成できます。これらのリード・レプリカを使用すると、データの読み取り専用コピーをクラウド・データセンターに保存できます。レプリカは、災害復旧のために読み取り/書き込みインスタンスに昇格することもできます。