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

最終更新日：2020-05-15（記事の情報は現在から1652日前のものです）

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：オブジェクト関係マッピング）」があります。しかしこの手法では、オブジェクト内のデータの興味深い部分を保持できません。データを取り出してバラバラにしてしまう上に、処理のオーバーヘッドが増えてしまうという課題も残ります。