RDB（リレーショナルデータベース）とは？関係データベースとNoSQLとの違い

RDB（Relational Database：関係データベース）は、企業の情報システム構築に必要不可欠です。最近はRDBに代わって、NoSQLデータベースが台頭してきています。RDBとNoSQLの違い、近年のデータベース事情について解説します。

RDBとは

「RDB」は「Relational Database（リレーショナルデータベース）」の略で、日本語に訳すと「関係データベース」となります。RDBはデータを複数の表として管理し、表と表の間の関係を定義することで、複雑なデータの関連性を扱えるようにしています。

企業の基幹システムや情報管理システムなどの大規模な用途から、個人の住所録のような小規模な用途まで、さまざまな規模でデータ管理に利用されています。なお、RDBを管理するシステムは「RDBMS」と呼ばれ、代表的なものとしてOracle Database、MySQL、Accessなどがあります。

RDBの使い方

RDBの表は、テーブルとも呼びます。テーブルは「列（カラム）」と「行（レコード）」で構成されます。

画像の例で説明すると、「顧客番号」「顧客氏名」など、縦に並ぶデータが「列（カラム）」で、「00001」や「相田孝之」など、横に並ぶデータが「行（レコード）」です。

テーブルには、レコードを識別するための「主キー（Primary Key）」を作成します。会社では、社員一人ひとりに「社員番号」が付与されます。これと同様に、テーブルでもレコードを特定するために主キーを設定します。この画像の例では、「顧客」の主キーは「顧客番号」です。

また、顧客番号は「販売」の中でも使用されています。この「顧客番号」について、「顧客」テーブルの「顧客番号」以外は入力できないという制約（参照整合性制約といいます）を設定できます。このようにしてテーブルとテーブルの間のデータの関係を定義していきます。

RDBの作成やデータの定義、操作には、SQL（Structured Query Language：構造化問い合わせ言語）という言語を使用します。ただし、通常はシステム担当者が他のプログラミング言語で入力画面などを作成し、利用者はその画面を通じてデータの操作を行います。

画面操作を通じて、データを操作するためのSQLがプログラムで自動的に作成され、システムの利用者はSQLを意識することなくデータの登録や変更ができます。

RDBに代わるNoSQLデータベース

NoSQLデータベースとは

RDBは表形式でデータを管理するため、システムで取り扱うデータの構造が複雑になったり、データ量が膨大になったりすると、データの一貫性を保つためシステムの処理速度が遅くなってしまうという問題があります。この課題への対応策として登場したのが、「NoSQLデータベース」と呼ばれるものです。「NoSQL」は一般に「Not Only SQL」の略として解釈されています。

近年、コンピュータの処理能力向上に伴い大規模なデータを取り扱えるようになっています。この流れを受けて、多くのNoSQLデータベースでは処理速度の確保のため、データの格納や取得が高度に最適化されています。そのため、機能を最小限に抑えているものもあります。

NoSQLデータベースのメリット・デメリット

NoSQLデータベースのメリット

データの格納および取得が高度に最適化されている
大規模データに対応できる
多種多様なデータに対して柔軟に対応できる
NoSQLデータベースのデメリット
データの整合性が確保されない
登録済みデータの加工は基本的に不可能、可能でも最小限
データの並べ替えには注意が必要

NoSQLデータベースの分類

主なNoSQLデータベースの種類には、次のようなものがあります。

キー・バリュー型：キーとバリュー（値）の組み合わせで管理するもの。大半はバリューとして単純なバイナリデータのみが格納できる。
ソート済みカラム指向：行キーに対してカラム（名前と値の組み合わせ）の集合を持つ。行ごとに任意の名前や数のカラムを格納できる。
ドキュメント指向：XMLやJSONといったスキーマレスでデータ構造が柔軟なもの。

RDBからNoSQLへの移行を検討する理由

理由1：変化に対応するように設計されていない

RDBでは、データを行と列の表形式で扱います。システムの規模にもよりますが、データベースの設計は何か月も時間をかけて行います。年単位で時間がかかることもあります。

また、システム構築後に変更が生じた場合も、変更内容が適切か、他のシステムへの影響はないかといった検証や検討を長い時間をかけて行います。近年では、テキストだけでなく音声や画像といった非構造データを扱う機会も増えていますが、RDBではこれらに柔軟に対応できない場合があります。

理由2：多種多様なデータに対応するように設計されていない

情報システムで扱うデータは、コンピュータの処理性能の向上に伴い、多種多様になっています。データの形式などを整理した「構造化データ」もあれば、音声や映像のような「非構造化データ」もあります。

このような多種多様なデータに対しては、表形式に整理する「データモデリング」に多くの時間がかかるRDBでは、柔軟に対応できません。

理由3：弾力的な拡張性を実現するように設計されていない

クラウドサービスの普及によって、多くの企業はシステムの一部または全部をクラウドで実行するようになっています。すると、データ量やユーザー数の増加に応じて容量を追加・拡張したり、ユーザーの需要がなくなった場合に縮退したりすることを考慮しなければなりません。

RDBの場合、その拡張は困難です。それは、原則として1台のサーバーで実行するように設計されているからです。システムを拡張する必要がある場合には、より巨大・複雑で高価、かつ独占的なハードウェアを購入しなくてはならないということもあります。

理由4：現代的なシステム開発には合わない

現代の情報システム開発では、JavaやC#などのオブジェクト指向のプログラミング言語を使用します。これらのプログラミング言語では、データ構造をデータとコード（属性とメソッド）を含む「オブジェクト」として扱います。このようなデータの取扱い方はRDBとは大きく異なっており、データベースとプログラミングの間でミスマッチが発生してしまいます。

このミスマッチを回避する策として「ORM（Object-Relational Mapping：オブジェクト関係マッピング）」があります。しかし、この手法では、オブジェクト内の重要なデータ構造や特徴をそのまま保持できません。データを取り出してバラバラにしてしまう上に、処理のオーバーヘッドが増えてしまうという課題も残ります。