変更が頻繁に行われている今日、データモデリングは大きな課題となっています。これは、リレーショナルデータベースには多大な時間とリソースが必要なためです。リレーショナルデータベースを使用すると、テーブルの列の追加や置換などのシンプルな変更でさえ、100万ドルにものぼる作業が生じます。

最高情報責任者(CIO)から開発者までのあらゆる人々が、リレーショナルデータベースは今日のデータの課題に対応できるよう設計されていないという事実に気付いています。その理由は、データの急増と、最近市場に導入された新しいデータベース製品によるものです。製品の種類は毎年増加しています。実際、この傾向は何年も続いており、米連邦政府の前CIOであるVivek Kundra氏は、2009年の会議で次のようにコメントしています。

“This notion of thinking about data in a structured, relational database is dead.”
Vivek Kundra, Former CIO of the U.S. Federal Government

これから数週間のうちに、この意見が正しい主な理由、つまり、リレーショナルデータベースが今日のデータの課題を解決できない主な理由について説明するブログ記事のシリーズを執筆する予定です。それぞれの記事で、リレーショナルデータベースが今日のデータの課題を解決できない主な理由を1つずつ説明します。最初の理由は、リレーショナルデータベースが変更処理向けに設計されていないというものです。

データの多様化に伴う今日の課題

現在では、あらゆるものが高速化しています。データの作成や変更も高速化しています。さらに、市場のダイナミクスや新たな管理、オンデマンドサービス、買収やスピンオフに対応できるよう規定された新たなビジネス要件に対応するため、データに実行される質問も急速に変化しています。現在、意思決定は数日でなく数分で下され、そうした意思決定を支援するデータは適切な形式で提供される必要があります。また、レイテンシを短縮し、効率性を向上させる必要があります。

さらに、データは多様化の一途をたどっているため、急速に増加し、変化するさまざまな形態、サイズ、種類のデータへの対応に組織は苦慮しています。一般的に、新しいアプリケーション、合併や買収、データの再利用が、さまざまな構造化データを作り出してしまう原因です。使途不明の非構造化データについては言うまでもありません。

こうしたことが問題となる理由を理解するため、リレーショナルデータベースでデータがどのようにモデリングされるかについて詳しく見てみましょう。

実体関連図(ERD)の作成

リレーショナルデータベースは、行と列からなるテーブル内にデータを配置します。これは、Microsoft Excelのスプレッドシートとよく似ています。各行には一意のエントリが、各列には一意の属性が表示され、各列がテーブルの各行を一意に識別するための主キーとして選択されます。

それでは、お客様とお客様が発注した製品用のリレーショナルデータベースをモデリングしてみましょう。まずは、「お客様」というテーブルを作成し、主キーとして使用する「お客様ID」という列を作成します。また、それぞれのお客様に関する各属性に対し、追加の列、例えば、それぞれに保存されるデータタイプを定義する「名」、「姓」、「住所」などを作成します。次に、「お客様ID」を「注文」という他のテーブルにリンクします。このテーブルには、お客様の購入情報を保存します。「注文」テーブルの各行には、一意の識別子と、「お客様」テーブルの主キーへの参照データを入力します。

続けてさまざまなテーブルを作成し、エンティティの整合性参照整合性の制約をすべて満たす設計にします。また、反復する列がなく、列がすべて一意の主キーに依存し、テーブル間で情報が重複しないように、すべてを適切に「正規化」します。こうした制約はデータの一貫性を維持し、高速なクエリを約束するものであり、リレーショナルモデルの代表的な特徴です。

こうしたデータモデルやスキーマの設計プロセスには、専門のチームを結成し、作成するテーブルと列の名前を決定する必要があります。これは重要なプロセスであり、最終結果は通常、大規模な実体関連図(ERD)で表現されます。そして、すべての人が優れたスキーマを参照できるようにプリントアウトされ、廊下の目立つ場所に掲示されます。

ERDの一例は、以下のとおりです。

実体関連図(ERD)

Oracle BRM 7.3データベース(Tridens IT Solutions提供)

変更に伴う問題

データのモデリングは、さまざまな理由から非常に重要です。スキーマは、データを表現し、クエリを実行する一貫した方法を生み出します。データのモデリング方法に注意を払わなければ、どの組織も成功を収めることはできません。問題なのはスキーマではなく、リレーショナルデータベースでは事前にすべてをモデリングする必要があるということです。さらに、複数の異なるスキーマが存在している場合や、スキーマに変更が必要である場合、リレーショナルデータベースではスキーマをスムーズに処理できません。このように、リレーショナルモデルは組織にとって対応が面倒なものになりつつあります。

第一に、そのプロセスには、データベースのサイズによって、数年とは言わないまでも数か月かかります。リレーショナルスキーマは複雑なため、データのロードやアプリケーションの構築を行う前に、すべてのモデリングを完了する必要があります。私は大規模な政府機関の製品およびプロジェクト管理を担当したことがありますが、事前に作成したガントチャートどおりに進行した計画は1つとしてないことを認めるのにやぶさかでなく、事前に人々の合意を得ることはほぼ不可能です。

第二に、データベース上にアプリケーションを構築した後で変更が必要になった場合、プロセスに多大な時間やリソースが必要になり、さらに数か月や数年かかる可能性があります。リレーショナルデータベースの利点は、慎重に設計された関係と、冗長性の排除です。これらによってシステム全体が非常に迅速に機能します。しかし、このアプローチの弱点は、1つのテーブルに若干変更を加えるだけでシステム全体に影響が及ぶ可能性があることであり、これについては慎重に進める必要があります。

“A good analogy is to think of the relational model is like a sensitive, complex rainforest ecosystem in which one small change can result in cascading impacts across the database and through the application stack.”

あるMarkLogicのお客様(フォーチュン100のテクノロジー企業)の見積もりによると、テーブルの1列を追加または置換するなどのシンプルな変更でさえ、100万ドルの作業が発生する可能性があります。さらに、聞くところによると、より複雑なデータモデリングプロジェクトになればそれよりも高い見積もりとなり、約5年間かかるうえ、何百万ドルものコストがかかります。

現在、変更は頻繁に発生しており、リレーショナルデータベースには時間とリソースが必要なため、データモデリングは大きな課題となっています。変更しなくても済む「完璧な」データモデルの作成と再作成を行うために、データモデリングとETLプロセスに毎年数十億ドルが費やされています。

そして、誰もがこうしたことを繰り返しているのです。


このシリーズの次のブログでは、リレーショナルデータベースが多様なデータの処理向けに設計されていない理由について説明していますので、ご一読ください。また、ホワイトペーパー『リレーショナルを超えて(Beyond Relational)』をダウンロードして、リレーショナルデータベースが適さない理由についての詳細をご確認ください。

このシリーズの記事の一覧は、以下のとおりです。

  1. 変更処理向けに設計されていないRDBMS
  2. 混合データ向けに設計されていないRDBMS
  3. 拡張向けに設計されていないRDBMS
  4. 混合ワークロード向けに設計されていないRDBMS
  5. 最新のアプリケーション開発には適していないRDBMS

当ウェブサイトではクッキーを使用しています。

当Webサイトを継続利用することにより、お客様はMarkLogicのプライバシーステートメントに従ってクッキーの使用に同意するものとします。