決して陳腐化しないデータベース設計の超基礎   翔泳社『DBマガジン』2005年12月号 特集「やさしいデータベース設計・正しいデータモデリング」に掲載   石川智久

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設計の知識は陳腐化しない

DB設計とは？

さて、「DB設計」とはいったい何なのでしょうか？「いきなりどこまで立ち返っているんだ……」と呆れられた読者の方もいらっしゃるでしょうが、まずはちょっと考えてみてください。試しに検索エンジンに「DB設計」と入力してみましょう。ディスクサイズ検討、バックアップ／運用設計、初期化パラメータ設計、ERモデリング、正規化理論、業種別DB設計などなど……。いろいろなサイトが引っかかりましたね。そうしたサイトの中に「こんなのDB設計じゃない」と感じるようなものが混じっていませんか？ そう、DB設計という言葉の解釈は、人によって実にさまざまなのです注3。そこでまずは、「本稿におけるDB設計」を定義しておこうと思います。では質問です。「DB設計の達人とはどのような人でしょうか？」。データ量やトランザクション量などの情報から、必要なディスクサイズやサーバースペックを見積もれる人でしょうか。あるいは、複雑怪奇なOracleのinit.oraファイルをちょちょいと変更できる人でしょうか。はたまた、2時間かかっていたバッチのSQLをちょっといじって3分足らずで終わるようにできちゃう人でしょうか。筆者の感覚では、これらの人は「データベースに関する高度な技術を持っている人」には違いありませんが、「DB設計者」ではありません。本稿における「DB設計」とは、情報システムにおいて、どのような情報をデータベースに格納すべきかを検討し、その「格納すべき情報」を「どのような形で保持するか？」を設計することを指します。 ところで、DB設計はレベルの違いによって「論理設計」と「物理設計」に分けられます。これらの違いを簡単に述べると、論理設計は「人が読むための設計」であり、物理設計は「実際に構築するデータベースの設計」といった感じになります（図2）。一般的にDB設計というと、論理設計と物理設計の両方を含む解釈ですが、“陳腐化しない知識を中心に解説する”ことが目的の本稿では、物理設計をあまり詳しく解説しません注4。そのため、本稿では以降、論理設計のことを指して「データモデリング」あるいは単に「モデリング」という言葉を使います。また、データモデリングの結果（ER図などの成果物によって表現される）を「データモデル」あるいは単に「モデル」と呼びます。

図2 論理設計と物理設計

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

では続いてデータモデリングの核心へと踏み込んでいきましょう。「データモデリング設計入門」的な書籍を手にとると、はじめての人にとっては到底覚えられないような多くの難解な概念が数多く登場します。これまでに挫折した経験がある方もいらっしゃるのではないでしょうか。しかし筆者は、データモデリングの“超基礎”として覚えるべきことは、以下の4つの要素だけであると考えます。
① エンティティ
② 属性
③ 関連（リレーション）
④ 関連の多重度
DB設計を経験されたことがある方の中には「何で多重度を4大要素の1つに数えているのか？」と思われる方もおられるでしょう。確かに、モデリングの世界で多重度は軽視されがちな要素です。例えば「多重度が分からない場合は省略しても構わない」といったことが記されている文献も存在します。ですが筆者は「多重度はモデリングで一番重要な要素と言っても過言ではない」と思うのです。詳しくはこの後で解説します。では、これらの4大要素を1つずつ解説しましょう。

エンティティ

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

図3 エンティティとは

関連（リレーション）

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

図4 関連とは

属性

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

図5 属性とは

関連の多重度

関連の多重度とは、関連の相対的な位置付けをよりハッキリさせるためのものです。多重度は、関連のあるエンティティAとBについて、片方から他方を見たときに「相手が1つなのか、複数なのか」ということを明らかにすることです。すなわち、「1つのAからBを見たとき」および「1つのBからAを見たとき」の相手の数を明らかにすることが、「多重度を決定する」ということになります。さて、では「関連の相対的な位置付けをハッキリさせる」とはどういうことでしょうか。先の関連の節で取り上げた「顧客と注文」を例にとって考えてみましょう。現在モデリングを行なっており、「顧客と注文」には何かしら関連がありそうだ、ということを認識しているとしましょう。ここから多重度を検討します。一般的に考えれば「顧客：注文＝1：多」というモデルになるでしょう。1人の顧客は注文を何回でも行なうことができ、1つの注文は1人の顧客から行なわれるということです。ですが、分析対象のビジネスに、複数人からのエントリによってはじめて「注文」が成り立つ「共同購入」という概念が存在する場合はどうでしょう。この場合、1つの注文は複数人の顧客と関連を持つことになります（図6）。また、もう一歩踏み込むと、このモデルでは「共同購入に対して顧客がエントリしている状態」を表現できないことが分かります（図7）。つまり「共同購入エントリ」というエンティティを新たに登場させないと、ビジネスを表現できていないのです（図8）。 先ほど「多重度はモデリングで一番重要な要素と言っても過言ではない」と述べました。多重度を決定するための過程は、エンティティの位置付けをハッキリさせ、エンティティの抽出もれを防ぐことにつながります。なにしろ顧客と注文の多重度を紐解かない限り、共同購入というエンティティを認識できなかったのですから。これを差し置いて「多重度は省略しても良い」と考えてしまうことは、モデリングそのものを全面放棄してしまっていることに近しいと筆者は考えます。

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

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

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

 

（注1）Enterprise Architecture（エンタープライズアーキテクチャ）の略称。企業全体の情報システムに関するアーキテクチャや標準化を整備するための手法。

（注2）Service Oriented Architecture：サービス指向アーキテクチャ。既存のシステム資産を「サービス」として定義し、サービスを組み合わせて使うことで、システムの再利用性を高める手法。

（注3）この業界はそんな用語ばっかりとも言えます。例えば「基本設計って何？」という問いに対する回答も十人十色でしょうね……。

（注4）物理設計には、特定のDBMS製品に依存した考え方などが必要になります。このため、論理設計よりも特化性が高く「陳腐化しやすい」領域であると言えるのです（決して「物理設計が重要でない」と言っているのではありません）。

（注5）例えば「先着500 名様に限り1 曲あたり100 円」や「購入者は同一曲を3回までダウンロード可能」といったことを実現する必要がある場合は、「在庫」のような概念が存在することになります（どちらの概念も「在庫」と呼ぶのは、あまりふさわしくないようにも思いますが……）。