Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

データモデリングのパターン

原文: Patterns of Data Modeling

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2011/07/12 14:00

 データベース設計とは、一言でいえば、現実に存在し、実際に活動している企業をサポートするために役立つ、現実世界を的確に表現した抽象的または概念的なモデルを作成することです。(原文:Patterns of Data Modeling、2011/02/22投稿)

本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。
※編集部注:掲載しているブログ内容は執筆時点での情報のため、現在とは異なる場合があります。

 ほとんどの場合、私たちは、モデル化されるビジネスエンティティが何か直観的に分かります。つまり、顧客は顧客エンティティとしてモデル化し、請求書は請求書エンティティとしてモデル化します。その後、これらの抽象的な「エンティティ」を主キー制約や外部キー制約を備えたリレーショナルテーブルに変換します。

 このような直観には、もちろんきちんとした方法論が存在します。その方法論とは、リレーションの正規化という理論であり、特に、関数従属性、多値従属性、および包含従属性について論じています。正規化の理論は難しすぎて十分理解できないという読者のために、Michael Blahaが最近出した書籍『Patterns of Data Modeling』では、スキーマデザインを考える新しい切り口として、オブジェクト指向アプリケーションプログラミングのデザインパターンに似た考え方を採用しています。本書は2009年の夏に刊行され、現在ではペーパーバック版が入手できます。本書の一部はオンラインでも閲覧できます。

 Blahaは、スキーマデザインの「パターン」を多数列挙しており、これらのパターンは、特定のビジネス上の問題に対応する具体的なソリューション設計の基礎として使用できます。この本は6つの部分で構成されていますが、メインであるパートIとパートIIIは次のような内容です。

 数学的テンプレートにはツリー、有向グラフと無向グラフ、項目の説明(準同型)、およびスタースキーマが含まれます。

 住所、顧客、項目、フライト、支払いなど、20個の具体的なビジネスエンティティのUMLモデルの詳細な例が含まれます。

  • 著者が「数学的テンプレート」と呼んでいる、いくつかの汎用モデルの説明
  • 「アーキタイプ」の説明

 列挙された各パターンはIDEF1X図とUML図の両方で説明されており、多くの場合、リレーションインスタンスのサンプルとSQLクエリの例が付随しています。例として、本書30ページに掲載されている管理階層のUML図を紹介します。このモデルはツリーパターンに基づくもので、履歴情報を扱うために一部修正が加えられています。

 また、より汎用的なサンプルモデルに対するクエリの例として、次のようなSQLコード例が紹介されています。

長所

 『Patterns of Data Modeling』では、一般的なビジネスエンティティをいかにモデル化するかというアイディア(つまりBlahaのアーキタイプ)が多数紹介されているだけでなく、より抽象的な設計についても書かれています。これは非常に有益な本です。これらのモデリングパターンは、概念モデルの設計におけるトレードオフや避けるべき落とし穴を見極めようとするときに役立ちます。

 本書のパートVIは、これらのUMLモデルをリレーショナルデータベースの設計へと落とし込む方法についての解説にあてられています。UMLモデルとリレーションとのマッピングに関する話の中で、実装のトレードオフについても取り上げられています。その代表的な例は、エンティティ-型階層(Entity-Type Hierarchy:ETH)モデルを一連のリレーションとしてモデル化する方法です。

短所

 本書で取り上げているパターンモデルの数はいささか多すぎます。全245ページという分量は決して少なくないのですが、多くのセクションは表面的な記述にとどまっており、詳しい背景情報やその他の省略された詳細を知るには、引用されている参照文献を読まなければなりません。例えば、セクション16.5では主キーの選び方について触れていますが、キー選択のトレードオフに関してはほとんど何も説明していません。しかしこれはコンピューターシステムを設計するうえで非常に重要なポイントです(例えば、こちらこちらを参照)。

 本書のもう1つの短所は、汎用モデルに関してはSQLの例があるのに、アーキタイプに関しては例がなく、紹介されているモデルの具体的な側面についてのパフォーマンス的なトレードオフが考慮されていないという点です。例えば、先ほど紹介した1番目の図2.37のSQLクエリを見てみましょう。このような選言命題が必要なのは、現在の期間をNULLで表しているからです(つまり、有効日が不明ということです)。この(単純な)モデリング方法の決定はパフォーマンスに影響を与えます。これは重要な問題です。なぜなら結局のところ、我々は現実世界を適切にモデル化したスキーマを設計することだけを目的としているわけではなく、さらに、そのモデルを効果的かつ効率的に操作できるコンピューターシステムを設計、実装することを目指しているからです。

参考資料



  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • Glenn Paulley(Glenn Paulley)

    カナダ オンタリオ州 ウォータールー R&DセンターにてSQL Anywhere 開発における Director of Engineering としてクエリ・オプティマイザなどの開発をリードしている。 ・IvanAnywhere

バックナンバー

連載:Glenn Paulley氏 データベース関連ブログ 翻訳記事

もっと読む

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5