« 自治体システムは日本に1個あればいい | トップページ | 成果物のサイズとシステムの保守性 »

2012.03.19

危ういデータモデルを見破るコツ

 ひところよりもデータモデル(ER図)を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。

 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための3つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。

1.キー設計が甘い

 データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のようなもので、これがいい加減だとテーブル関連までフニャけたものになる。

 たとえば、オブジェクト指向の発想に引きずられたデータモデルはそういうものになることがある。構想された永続クラスをテーブルとみなすには、それぞれに「オブジェクトID」に相当する単独キー(id)を与えればいい――設計者がそのように考えてしまうためだ。また、ある種のWEBアプリ用フレームワークではサロゲートキーが強制される。最初にこれに慣れると、単独キーでモデリングする癖がつく。

 ところが、本格的な業務システムの帳簿組織には「ナチュラルキーではない複合主キー」にもとづく関数従属性や、動的に成立する関数従属性や、気づかれにくいドメイン制約といった複雑なデータ要件が含まれている。「全テーブルに単独キー(id)を与える」という設計スタイルは単純明快で受け入れられやすいが、出来上がるモデルは精妙なデータ要件を反映しない。サロゲートキーを施すにしても、本来のデータ要件を確実に把握したうえで慎重にやらないと不完全な帳簿組織が出来上がる。

 プログラム域で躍動する複雑な変数群のあり方をデザインするための方法論としては「オブジェクト指向設計(OOD)」以外の選択肢はないだろう。しかし、複雑なデータベースをデザインする際には、「関数従属性」や「ドメイン制約」に着目するデータ指向手法(DOA)を使うべきだ。少なくとも、対象によって道具(方法論)を使い分けられることは、ソフトウエア技術者の基本的な素養である。OODだろうがDOAだろうが、それ一本槍では行き詰まる。どちらが優れているかという問題ではない。答は「使い分けよ」である。

2.「多対多」を含んでいる

 テーブル間の「多重度(cardinality)」には「1対1」や「1対多」などがあるが、ある種のデータモデル図法において「多対多」が記法として許されていることが私には理解できない。「多対多」を含むデータモデルはどう考えても未完成なもので、検収してはいけない。

 たとえば「出荷情報」と「請求情報」の間になんらかの関係がありそうなことくらいは素人でもわかる。それらをエンティティとみなして次のような図にすることに何のスキルも判断も要らない。もちろん、この図からはほとんど何も読み取れない。

┌────┐     ┌────┐
│ 出荷 |     | 請求 │
├────┤*    *├────┤
│*出荷id├─────┤*請求id│
│ …  |     | …  │
└────┘     └────┘

 一部のデータモデリングの教科書には「多対多が生じたら『交差エンティティ』を導入して解消しましょう」と説明されていたりするが、そもそも多対多を含めながらモデリングを進めるという姿勢がおかしい。データモデリングというのは、すべてのエンティティを対象として一挙にできるものではなく、いくつかの領域毎に区切って進めざるを得ないものだ。その領域分けがまともであれば、含まれるエンティティ同士の多くが「多対多」の関係にあるので、メモとして記すことさえ意味がない。

 データモデルは「エンティティ間の多重度を示す図面」ではない。繰り返すがそれはデータ項目間の「関数従属性」と「ドメイン(定義域)制約」を視覚化するための図面である。それらを分析することによって、たまたま多重度までが明らかになっているだけの話で、「エンティティ間の見かけの多重度だけを示す図面」では役にたたない。もちろん、見かけ上の多重度さえいい加減なモデルは論外である。

 なお、分析済みのエンティティの一部を割愛したものが「概念モデル」として示されることがある。その上に多対多が載っているのを見たことがあるかもしれない。たしかに一部のエンティティを意図的に隠すのだから、多対多はカジュアルに出現する。しかしそのようなモデルは「概念モデル」ではなく「概要モデル」とか「集約モデル」と呼ばれるべきだ(そもそもそういう図面が何かの役にたつとは私にはとても思えないのだが)。

3.他の設計要素を支えない

 キーが明確だし、多対多関係も含まれていない――それでも安心はできない。データモデルは「他の設計要素を支えるもの」として検証されていなければいけない。たとえば、請求と出荷の間の「多対多」を解消しようとして次のように修正しただけでは意味がない。

┌────┐     ┌────┐
│ 出荷 |     | 請求 │
├────┤     ├────┤
│*出荷id|     |*請求id│
│ …  |     | …  │
└┬───┘     └───┬┘
 |1             1|
 |  ┌───────┐  |
 |  │ 出荷・請求 │  |
 |  ├───────┤  |
 |  *│*出荷請求id │  |
 └――┤・出荷id   │*  |
    │・請求id   ├──┘
    │ …     |
    └───────┘

 なぜなら、このモデルと矛盾しない機能定義(UI)や業務定義(業務マニュアル)が提示されていないからだ。じっさいこのモデルを渡されて、まともな出荷・請求業務を想像できる人はいないだろう。描きっぱなしの無責任なモデルと言わざるを得ない。

 データモデルが完成したということは、関連要素が互いを支えあうところまで検討が尽くされているということだ。この意味で、データモデリングは「データモデルを描く仕事」ではない。データモデル「だけ」なら中学生でも描けるだろう。他の設計要素との整合性を配慮しながら全体をまとめる専門スキルが、モデラーには求められている。

 以上の兆候のいずれかが認められるデータモデルを受け取ったのであれば、プロジェクト管理者と相談したほうがいい。そんなデータモデルには未検討の要素が多すぎて、モデラーに代わってモデリングの続きを延々とやるハメになる恐れがある。それはあなたの仕事ではない。

|

« 自治体システムは日本に1個あればいい | トップページ | 成果物のサイズとシステムの保守性 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 危ういデータモデルを見破るコツ:

« 自治体システムは日本に1個あればいい | トップページ | 成果物のサイズとシステムの保守性 »