技術トピックス

決して陳腐化しないデータベース設計の超基礎

翔泳社『DBマガジン』2005年12月号 特集「やさしいデータベース設計・正しいデータモデリング」に掲載

石川智久
2005年12月01日
※内容は公開当時のものです

昨今、IT関連のメディアを中心に「モデリング」という言葉をよく見かけるようになりました。言葉で言うのは簡単ですが、では実際にモデリングを“まともに”行なえる技術者はどのくらいいるのでしょうか。筆者の経験から、モデリングのスキルは情報システム開発に関するスキルの中でも最重要なものの1つだと断言できます。本稿では、モデリングの中でも特にデータモデリング(DB設計)に焦点を絞り、「エンティティ」「関連」「属性」「関連の多重度」という筆者が考えるデータモデリングの4大要素を中心に、その基礎知識やスキル習得法のポイントなどを紹介していきます。

DB設計のスキルは陳腐化しない!

近年、DB設計の重要性が再認識されつつあります。今風な呼び方をすると「モデリング」と呼ばれるテーマであり、ちょっとしたブームになっているようにも思えます。例えば、IT雑誌やWebサイトなどの情報源を“チラ見”するだけで、数多くのモデリングに関する記事を見つけることができます。現在のモデリング系の記事は、最近の流行とも言えるEA(注1 )やSOA(注2 )などのキャッチーなフレーズと組み合わせた「EA・SOA成功のカギを握るモデリング手法」といった感じのテーマだったり、「O/Rマッピングで失敗しないモデリング手法」といった感じのテーマだったりします。 こうしたテーマの記事を否定するつもりはありません。

ですが、ちょっと立ち戻って考えてみてください。EAやSOA、O/Rマッピングなどの要因を考慮しなくて良いのであれば、“良い”DB設計を実践できる技術者は多いのでしょうか? あるいはモデリング手法がすでに十分に確立され、世の中に浸透しているのでしょうか? 筆者は、この問いにはっきりと「NO」と答えたいと思います。すなわち、最新動向を踏まえたモデリング手法を論じる以前に、もっとベーシックな領域で「DB設計、かくあるべし」といったテーマが論じられる必要性を強く感じています。これが本稿執筆に至った最大の動機です。本稿はDB設計に関する基礎知識を身に付けることを目的としています。そのため、キャッチーな最新の動向も紹介しませんし、一部の方々からのみ絶賛を浴びるようなアカデミックな議論をするつもりもありません。あくまで、現場で活かせる、地に足のついたスキルを学ぶことに主眼を置いています。

とはいえ、本稿は「DB設計の初心者」だけにターゲットを絞った記事でもありません。設計上のTipsやパターン/正規化理論やER図の表記法などを解説した記事はよく見かけます。ですが、現実の開発プロジェクトにおいては「どのような手順で」「どうやってDB設計を行なっていくのか?」といった実践的な視点が必要になります。本稿は、この実践的な視点に的を絞っていますので、初心者の方はもちろんのこと、すでに現場でDB設計を実践したことがある方にも、楽しんでいただけることと思います。この「実践的なDB設計の基礎知識」は決して陳腐化しません。少なくともRDBがデータベースの主流に踊り出て以降、これまで十数年にわたって通用していると言えます。おそらく、今後の十数年にわたっても、この「基本」は決して陳腐化しないでしょう(図1)。

図1 DB設計の知識は陳腐化しない

図1 DB設計の知識は陳腐化しない

DB設計とは?

さて、「DB設計」とはいったい何なのでしょうか?「いきなりどこまで立ち返っているんだ……」と呆れられた読者の方もいらっしゃるでしょうが、まずはちょっと考えてみてください。試しに検索エンジンに「DB設計」と入力してみましょう。ディスクサイズ検討、バックアップ/運用設計、初期化パラメータ設計、ERモデリング、正規化理論、業種別DB設計などなど……。いろいろなサイトが引っかかりましたね。そうしたサイトの中に「こんなのDB設計じゃない」と感じるようなものが混じっていませんか? そう、DB設計という言葉の解釈は、人によって実にさまざまなのです(注3 )。

そこでまずは、「本稿におけるDB設計」を定義しておこうと思います。では質問です。「DB設計の達人とはどのような人でしょうか?」。データ量やトランザクション量などの情報から、必要なディスクサイズやサーバースペックを見積もれる人でしょうか。あるいは、複雑怪奇なOracleのinit.oraファイルをちょちょいと変更できる人でしょうか。はたまた、2時間かかっていたバッチのSQLをちょっといじって3分足らずで終わるようにできちゃう人でしょうか。筆者の感覚では、これらの人は「データベースに関する高度な技術を持っている人」には違いありませんが、「DB設計者」ではありません。

本稿における「DB設計」とは、情報システムにおいて、どのような情報をデータベースに格納すべきかを検討し、その「格納すべき情報」を「どのような形で保持するか?」を設計することを指します。 ところで、DB設計はレベルの違いによって「論理設計」と「物理設計」に分けられます。これらの違いを簡単に述べると、論理設計は「人が読むための設計」であり、物理設計は「実際に構築するデータベースの設計」といった感じになります(図2)。

一般的にDB設計というと、論理設計と物理設計の両方を含む解釈ですが、“陳腐化しない知識を中心に解説する”ことが目的の本稿では、物理設計をあまり詳しく解説しません(注4 )。そのため、本稿では以降、論理設計のことを指して「データモデリング」あるいは単に「モデリング」という言葉を使います。また、データモデリングの結果(ER図などの成果物によって表現される)を「データモデル」あるいは単に「モデル」と呼びます。

図2 論理設計と物理設計

図2 論理設計と物理設計

データモデリングの超基礎

では続いてデータモデリングの核心へと踏み込んでいきましょう。「データモデリング設計入門」的な書籍を手にとると、はじめての人にとっては到底覚えられないような多くの難解な概念が数多く登場します。これまでに挫折した経験がある方もいらっしゃるのではないでしょうか。しかし筆者は、データモデリングの“超基礎”として覚えるべきことは、以下の4つの要素だけであると考えます。

  • エンティティ
  • 属性
  • 関連(リレーション)
  • 関連の多重度

DB設計を経験されたことがある方の中には「何で多重度を4大要素の1つに数えているのか?」と思われる方もおられるでしょう。確かに、モデリングの世界で多重度は軽視されがちな要素です。例えば「多重度が分からない場合は省略しても構わない」といったことが記されている文献も存在します。ですが筆者は「多重度はモデリングで一番重要な要素と言っても過言ではない」と思うのです。詳しくはこの後で解説します。では、これらの4大要素を1つずつ解説しましょう。

エンティティ

エンティティとは、モデリングの対象となる業務の中で管理する必要がある情報です。「管理する必要がある情報」とは、例えば、商品/契約/注文/請求/在庫など、分析対象の業務に登場する概念を指します。ここでのポイントは管理する“必要がある”という点です。例えば、音楽のダウンロードサービスといったビジネスでは、誰が何度ダウンロードしても、曲そのものは減りませんので「在庫」という概念は登場しません。すなわち、分析対象の業務において、在庫というエンティティは“必要がない”ということになるのです(注5 )。なお、ER図でもUMLのクラス図でも、エンティティは「四角形」で表現されます(図3)。

図3 エンティティとは

図3 エンティティとは

関連(リレーション)

関連(リレーション)とは、結び付きのあるエンティティ同士をリンクさせるものです。では、「結び付きのあるエンティティ」とはどのようなものでしょうか。例えば、「商品ごとに在庫を管理する」場合だと「商品」と「在庫」に、「顧客は注文を行なう」場合だと「顧客」と「注文」に関連が存在する、ということになります。なお、ER図でもUMLのクラス図でも、関連はエンティティ同士を結ぶ「線」で表現されます(図4)。

図4 関連とは

図4 関連とは

属性

属性とは、あるエンティティに従属する項目のことです。「従属する項目」とは、「エンティティを1つに定めたときに、一緒に分かる情報」だと考えてください。例えば、通販の商品カタログから欲しい商品を1つに定めると、「商品名」や「価格」も同時に分かります。この商品名や価格が「属性」です。なお、ER図でもUMLのクラス図でも、属性はエンティティの四角の中に「属性名」を記します(図5)。

図5 属性とは

図5 属性とは

関連の多重度

関連の多重度とは、関連の相対的な位置付けをよりハッキリさせるためのものです。多重度は、関連のあるエンティティAとBについて、片方から他方を見たときに「相手が1つなのか、複数なのか」ということを明らかにすることです。すなわち、「1つのAからBを見たとき」および「1つのBからAを見たとき」の相手の数を明らかにすることが、「多重度を決定する」ということになります。

さて、では「関連の相対的な位置付けをハッキリさせる」とはどういうことでしょうか。先の関連の節で取り上げた「顧客と注文」を例にとって考えてみましょう。現在モデリングを行なっており、「顧客と注文」には何かしら関連がありそうだ、ということを認識しているとしましょう。ここから多重度を検討します。一般的に考えれば「顧客:注文=1:多」というモデルになるでしょう。1人の顧客は注文を何回でも行なうことができ、1つの注文は1人の顧客から行なわれるということです。

ですが、分析対象のビジネスに、複数人からのエントリによってはじめて「注文」が成り立つ「共同購入」という概念が存在する場合はどうでしょう。この場合、1つの注文は複数人の顧客と関連を持つことになります(図6)。また、もう一歩踏み込むと、このモデルでは「共同購入に対して顧客がエントリしている状態」を表現できないことが分かります(図7)。

つまり「共同購入エントリ」というエンティティを新たに登場させないと、ビジネスを表現できていないのです(図8)。 先ほど「多重度はモデリングで一番重要な要素と言っても過言ではない」と述べました。多重度を決定するための過程は、エンティティの位置付けをハッキリさせ、エンティティの抽出もれを防ぐことにつながります。なにしろ顧客と注文の多重度を紐解かない限り、共同購入というエンティティを認識できなかったのですから。これを差し置いて「多重度は省略しても良い」と考えてしまうことは、モデリングそのものを全面放棄してしまっていることに近しいと筆者は考えます。

図6 注文と顧客の多重度検討①

図6 注文と顧客の多重度検討①

図7 共同購入に顧客がエントリしている状態

図7 共同購入に顧客がエントリしている状態

図8 注文と顧客の多重度検討②

正規化とは?

「エンティティ」「関連」「属性」「関連の多重度」という4大要素を理解していれば、基本的にはモデリングを行なうことができます。ですが、よっぽど勘の鋭い人でない限り、すぐにモデリングを実践するのは難しいと思います。ここからもう一歩抜け出すためには、正規化の考え方を理解するのが有効です。正規化というと、しばしば情報処理試験に登場するような、第1~5正規形やらボイスコッド正規形やら……、といった難しい話を発想しがちですが、本質はきわめてシンプルです。少し乱暴に定義すると、正規化とは「エンティティを、可能な限り細かい、最小単位にしておく」という考え方です。あるいは「あるエンティティの中の属性同士に従属関係を作らないようにすること」とも言えます。

例えば、注文エンティティを図9のようにモデリングしたとしましょう。注文エンティティの属性に「注文受け部門」と「注文受け担当者」がありますが、この点が「エンティティが最小単位になっていない」部分です。「担当者は1つの部署に所属している」ということは、すでに「担当者」エンティティで表わされています。このダブリを排除し「エンティティが最小単位になっている」(=正規化された)モデルは図10のようになります。

なお、しばしば誤解されがちですが、第1~5正規形、ボイスコッド正規形などの難しい考え方は、実際の現場ではあまり意識しません。例えば「さあ、第1正規形のモデルができた。次は部分関数従属を排除して第2正規形のモデルを作るぞ!」などとは決して考えません。ある程度の慣れは必要になりますが、図10のようなモデルを“いきなり作れる”のが実際です。もちろん正規化理論は、DB設計者を志す人であれば、知っておいて損はない考え方です。ただし、正規化理論をモデリングの「プロセス/進め方」として解釈するのではなく、モデルを評価/レビューする際の「観点」程度に解釈しておくのが良いでしょう。

図9 正しく正規化されていないモデル

図9 正しく正規化されていないモデル

図10 図9を正規化したモデル

図10 図9を正規化したモデル

モデルを制する者は業務システムを制する

ここまでは、モデリング超基礎知識として4大要素や正規化を解説してきました。ここからは、「モデリングができる」ということが何の役に立つのかを解説していきます。あなたが参加している開発プロジェクトに、誰よりも仕様を“広く”かつ“深く”知っているという人はいませんか? 例えば、ほかのメンバーからの仕様に関する質問をほぼ一手に引き受け、しかも仕様的にも業務的にもまったく矛盾のない答えを導き出してしまうような人です。勝手な憶測ですが、その人は“DB設計を担当した人”ではないでしょうか。すばり「デキるエンジニアはモデルが分かる」「データモデルを制する者は業務システムを制する」というのが筆者の持論です。その理由を述べます。

モデルが分かればビジネスが分かる

業務システムは「企業活動の記録」と言っても過言ではありません。皆さんがこれまでに構築してきた業務システムを思い出してみてください。データベースのI/O処理以外に、どのような処理が実装されていたでしょうか。画面出力に関するプレゼンテーションロジックにしても、データベースに格納されているデータを“いかに見せるか”という処理に過ぎません。どうでしょう、データベースと関係のない処理はほとんど存在しないと言えるのではないでしょうか(図11)。つまり、業務システムはデータベースの構造、すなわちモデルを理解すれば、その業務の全貌がほぼ理解できるのです。さらには、「注文とはどのような構造なのか?」ということを理解できれば、その業務の背景にあるビジネスの本質的な理解にもつながるのです。これが「モデルが分かればビジネスが分かる」所以であり、DB設計者が誰よりも仕様を深く理解しやすい理由でもあります。

図11 業務システムの中心にあるのはデータベース

図11 業務システムの中心にあるのはデータベース

皆さんは、開発プロジェクトに途中から参画する場合、どのようにして情報をキャッチアップしていきますか? プロジェクトに関する膨大な資料、例えば要件定義書や基本設計書などを片っ端から読んでいくのは、あまりに時間が掛かりすぎてしまいます。このような「システムを理解する」ときにも、データモデルを理解することが近道となります。具体的には、まずはER図から読んでみると良いでしょう。ER図を読む、すなわち“モデルを理解する”ことによって、そのシステムがどんなデータを取り扱っているのかが分かり、構築対象の範囲などを手っ取り早く理解できます。

ちなみに、参画したプロジェクトにER図が存在しなかったら、そのプロジェクトは少なからず「危険信号がともっている」と思って間違いないでしょう。また、データベースからリバースしたようなER図しかないような場合も、やはり危険信号と言えます。データベースからリバースしたER図は、パフォーマンスやアーキテクチャなどさまざまな要因を加味した後の「物理設計」の結果でしかありません。構築対象のシステム/業務の全体像を手っ取り早く理解するためには、人が読むことを目的としている「論理モデル」のほうが最適と言えます。

データモデリングに必要なスキル

「モデリングができる」ことが、業務システムの開発に携わる上で大きな武器になることは、ご理解いただけたと思います。では、具体的にどのようなスキルを身に付けていけば、モデリングができるようになるのでしょうか。ポイントを見ていきましょう。

モデリングに必要なスキル① 表記法を知る

モデリングのスキルを向上させるためには、まず表記法を知らなければなりません。つまり、ER図やUMLの“書き方”を知っておく必要があるということです。ここで大事なのは、表記法はあくまで“表現のための手段”に過ぎないということです。これを忘れると、例えばUMLの仕様だけにはやたら詳しいといった“モデリングオタク”になってしまうので注意が必要です。モデリングオタクが作るモデルは、さまざまな表記法を理解し、それを使うことが目的になってしまっているため、表記法自体は間違っていないものの、本人以外は誰も理解できない難解なモデルになってしまいがちです(図12)。先に解説した「4大要素」の書き方と、正規化の考え方さえ理解していれば、ほとんどのことは表現できるはずですので、スキルを高めるためには理論を追求するよりも実際にモデルを書いてみるほうが得策と言えます。

図12 モデリングオタクが作る自己満足モデル

図12 モデリングオタクが作る自己満足モデル

モデリングに必要なスキル②:モデルを考える

「モデルを考える」ということは、「どのような情報をデータベースに格納すべきか」「格納すべき情報をどのような形で保持するか?」といった点を検討し、顧客の合意を得ること、すなわちモデリングの核心部分に関するスキルです。まず必要となるのが、顧客から要求を聞き出すコミュニケーション能力です。顧客が実現したいことの“モヤモヤとした想い”を理解するためにも、作成したモデルがその“想い”を表現できていることを確認してもらうためにも、何はともあれ顧客とのコミュニケーションを円滑に進めることが大前提となります。

次に必要となるのが、論理的に物事を考える力、すなわちロジカルシンキング能力です。モデリングの過程では、常に「1つのエンティティが何か?」を考えながら進めていくことになります。また、顧客の発言の中から「微妙な矛盾」や「実は不透明なまま議論が進んでいる部分」はたまた「異音同義(注6 )や同音異義(注7 )」などといった“ツッコミどころ”を適切に検知し、その本質を追求していくことが大切です。これらを実践するためには、ロジカルシンキング能力が大切になってきます。

コミュニケーション能力もロジカルシンキング能力も、身に付けようと思って簡単に身に付けられるようなものでもありません。そう、モデリングには“なかなか身に付けられないスキル”も重要になってくるのです。一般的に、「モデリングには才能や感性が必要」と言われますが、その所以はこの点にあると言えるでしょう。これらの能力を身に付けるためには、地道で効果の見えにくい努力を積み重ねるのが、結局のところ一番の早道になります。具体的には、以下のようなトレーニングを行なうと良いでしょう(図13)。

  • 自分が関わったプロジェクトや同僚が関わっているプロジェクトなどの、さまざまなデータモデルを読み、自分なりに理解する
  • ただ理解するだけではなく、“なぜそのようなモデルになっているのか”を考える。すなわち、裏に脈々と流れる論理をつかむ
  • そのシステムのデータモデルを自分でも書いてみる。すなわち、自分なりの理論に基づくモデルを作る
  • ほかの人が作ったモデルや自分が作ったモデルを基に、多くの人と“なぜそのようなモデルにしたのか?”を議論する。
図13 モデルを考えるスキルの全体像とロードマップ

モデリングに必要なスキル③:モデルを表現する

作成されたデータモデルは、後続の開発プロセスで多くの開発者に読まれるものになります。DB設計者はこの点を意識し、モデルの“表現”にもこだわる必要があります。作成されたモデルが、例え「表記法を理解して」「適切なコミュニケーションを経ながら」「論理的に筋道の通った」綺麗なモデルであっても、それが伝わらないことには意味がないのです。

「表現の仕方」をこれほど重要視しているのには、もちろん理由があります。それは、データモデルというものが、ただ1人の誰かの勘違いによって、全体が決壊してしまうような脆さも兼ね備えているからにほかなりません。 例えば、開発者の誰かがデータモデルを正しく理解せず、DB設計者の意図しないデータを登録するように、機能を設計してしまったとしましょう。そこで登録されたデータは多くの場合、ほかの機能からも利用されるので、ほかの機能もそのつじつまを合わせるように実装されてしまうでしょう。

この悪しき連鎖によって、DB 設計者が元々想定していた「1つのエンティティとは何か?」という点が揺らいでしまいます。1つのエンティティの意味が揺らぐということは、当然そのエンティティと関連を持つ周辺のエンティティにも影響を及ぼすということです。こうして、DB設計者の本来の意図は、土台からどこかに消え失せてしまい、「綺麗なはずだったモデル」がグチャグチャに荒らされてしまうのです(図14)。DB設計者は、このようなことが起こらないように、「モデルが意図していること」を正しく伝えられるような表現を努めなければいけません。例えばER図の表現だけを考えたとしても、以下のようなポイントに気を配る必要があります。

  • エンティティや属性の「名前」にはトコトンこだわる。例えば、多少長いエンティティ名になってしまっても、分かりやすければ良しとして、「日別商品別売上数集計」などのエンティティ名を下手に省略しない
  • 視点を1つに定める。例えば1人称を自社に定めた場合は、自社が受けた注文に「発注」というエンティティ名を付けない
  • データモデルを「読む側」の視点に立つ。例えば数ページに渡るER図だと、「まず理解しておくべき重要なページ」を序盤に持ってきて、徐々に細部のモデルを解説するようなストーリーにする
  • ER図の配置の“美しさ”にこだわる。例えば人間工学的にも、左上から右下へ向かって読み進めていけるような図の配置を心がける
  • ER図の中で「特に気を付けるポイント」には補足メモを加える。例えば「基本的には1:1だが、あるケースにおいては1:*となるような関連」がある場合、その旨を補足しておく
図14 モデル本来の考え方が伝わらずに「決壊」してしまう

図14 モデル本来の考え方が伝わらずに「決壊」してしまう

パート1のまとめ

非常に駆け足ではありましたが、以上でパート1の議論は終わりです。DB設計を実践したことがない方は「DB設計ってすごく難しそうだし、責任重大な仕事っぽいな……」と感じたのではないでしょうか。筆者は、データモデルが業務システムの中核を担う以上、難しく責任重大な仕事であるのが正論だと考えます。データモデルの質の良否が、以降のプロジェクトが火の海と化すか、そうでない道に進めるかの命運の分かれ道であることには、誰も異論を唱えない事実でしょう。とはいえ、ただ責任が重いだけではなく、非常に奥が深く、面白い仕事であることも間違いありません。本稿を機に、DB設計者の道を志す方が少しでも増えてくれることを期待して、引き続きパート2にもお付き合いいただければと思います。

  • 注1:Enterprise Architecture(エンタープライズアーキテクチャ)の略称。企業全体の情報システムに関するアーキテクチャや標準化を整備するための手法。
  • 注2:Service Oriented Architecture:サービス指向アーキテクチャ。既存のシステム資産を「サービス」として定義し、サービスを組み合わせて使うことで、システムの再利用性を高める手法。
  • 注3:この業界はそんな用語ばっかりとも言えます。例えば「基本設計って何?」という問いに対する回答も十人十色でしょうね……。
  • 注4:物理設計には、特定のDBMS製品に依存した考え方などが必要になります。このため、論理設計よりも特化性が高く「陳腐化しやすい」領域であると言えるのです(決して「物理設計が重要でない」と言っているのではありません)。
  • 注5:例えば「先着500 名様に限り1 曲あたり100 円」や「購入者は同一曲を3回までダウンロード可能」といったことを実現する必要がある場合は、「在庫」のような概念が存在することになります(どちらの概念も「在庫」と呼ぶのは、あまりふさわしくないようにも思いますが……)。
  • 注6:1つの概念に複数の呼び方があること。異音同義を検知できないと、それぞれを別々のエンティティとして表現することになってしまい、後にモデルが破綻します。
  • 注7:複数の概念を1つの呼び方で認知していること。同音異議を検知できないと、本来複数のエンティティとして抽出すべきものが1つのエンティティとしてしか検知されず、やはり後にモデルが破綻します。

お問い合わせ

ウルシステムズに関するお問い合わせは以下のページからどうぞ。