サブジェクトエリアを考える

大規模なデータモデリングを行う場合,データモデルをいくつかに分割して作成するのが一般的である。この部分図を,データモデリングツールではサブジェクトエリア(ERwin),あるいはサブモデル(ER/Studio)と呼んでいる。以下,このBlogではサブジェクトエリアという用語を使用する。

データモデリング分科会で,このサブジェクトエリアはどういった単位で作成すべきか,あるいは,その単位には理論的な裏付けがあるのだろうかという問題提起があり,これについて分科会でディスカッションを行った。

大規模システムの設計・開発では,いくつかのサブシステムに分割し,それぞれのサブシステムごとに設計・開発が行われるのが普通だが,大規模データモデルも同様に分割してモデリングすることが妥当と思われる。しかし,時々,模造紙を何枚も張り合わせた,ものすごく巨大なデータモデルを見ることがある。さぞかし,維持管理が大変だろうと思われるが,分割したら分割されたサブジェクトエリア間の関連がわかりにくくなるという問題もあるのか、あるいはサブジェクトエリアにデータモデルを分割するという概念に馴染みがないのかもしれない。

問題提起された課題は以下が代表的なものである。
1 サブジェクトエリアび分割の基準や理論的裏付けはあるのか?
2 サブジェクトエリアに書かれるエンティティ数はどのくらいが妥当か?
3 サブジェクトエリア間で,重複して描かれるエンティティがあっても良いのか?それとも,サブジェクトエリア間でエンティティは排他であるべきか?

まず,サブジェクトエリアの分割基準についてだが,理論的裏付けは難しいものの,ベスト・プラクティス,あるいはリファレンスとなるべきモデルはありそうである。残念ながら日本語訳は出ていないが,アメリカのデータモデラーであれば,まず絶対に読んでいるData Model Resource Book(L. Silverston)のVol.1では,
People and Organization
Products
Ordering Products
Shipments
Work Effort
Invoicing
Accounting and Budgeting
Human Resources
といったサブジェクトをあげている。サブジェクトエリアを考えるうえで,かなり拠り所になるかと思う。ちなみにアメリカでは業界団体,あるいはIBMやOracle,テラデータといったベンダーが提供しているデータモデルも,これに類似したサブジェクトエリアを設定している。理論的裏付けはともかく,かなり類似しているように感じている。これらのサブジェクトエリアは,図書分類に似ているという指摘もあった。分割範囲が大分類から細分化していく点も図書分類に類似している。

次にサブジェクトエリア単位のエンティティ数について。これは分科会で数10から,最大100以下といった経験を共有できた。数はけっこうバラつきが多いが,これはどこまでサブタイプを設定するかにもよるかと思う。あまりにも多い場合はさらに細分化した単位にサブジェクトエリアを分割するほうが良いだろう。

サブジェクトエリア間でエンティティが重複して良いのかについて。サブジェクトエリアを図書分類のように考えると,1つのエンティティが複数のサブジェクトエリアに所属するということはあり得ない。しかし,厳密に重複なしとすると,いろいろと支障が出てしまう。例えば,製品の担当者の関連,製品と売上の関連といったものは,図書分類的なサブジェクトエリアでは表現できない。こうした関連を表すためのアプローチの1つとしては,あるサブジェクトエリアのデータモデル図に,そこに属するエンティティと関連がある周辺サブジェクトエリアのエンティティも参考として書き加えるというテクニックがある。みもう1つは業務視点(たとえば受注業務)でデータモデル図を作成することである。これを組み合わせるとサブジェクトエリアを縦軸と横軸で表すことになり,ビジネスルール等をデータモデルで表現することができる。(全てのビジネスルールではないが,データ構造で表現できるビジネスルール),ただ,この縦軸・横軸の組み合わせをサブジェクトエリアとして考えるべきではという問いかけもあった。

参考となるサブジェクトエリアを,それぞれの企業にあてはめ,そこに独自部分をモデリングしていくと,出来上がるデータモデルの品質やモデリングにかかる時間の点で大きなメリットがあると信じている。このテーマについては今後もより具体的、実践的に議論を深めていきたいと考えており,データモデリング分科会では再度,取り上げていきたいテーマである。

マネジメントへの挑戦

データ管理は何のためにやるのでしょうか?
企業であれば,競争に打ち勝つため,極論をいうと生き抜くためのマネジメントの一環だと私は思っています。

であれば,データに携わる我々はもっと経営について関心をもつべきかと思います。ということで,今年のお正月は、復刻版の「マネジメントへの挑戦(一倉定)」を読んでみました。私にとっては遠縁かつ高校(旧制中学)の先輩にあたる方ですが,これまで著作は読んだことはなく,名前のみ知っていました。

基本的に読みやすい本なのですが,目から鱗の個所が多々あり,今年はいいスタートが切れた感じです。その中で,いくつか内容を紹介したいと思います。

① バランスのとれた組織ではダメ
「すぐれた会社,成長する企業は,組織面だけでなく,いろいろな面でつねにバランスをやぶって前進している。アンバランスが成長途次の姿なのである。」

組織のアンバランスさを大事にする,組織がどんどん変化する。こうしたことに情報システムはポジティブに反応できていないのではないか。組織変更するとシステム改修が発生して大変とか,時間がかかるとかはよく聞く話ですよね。要件定義の要素として可変性分析がありますが,組織については可変であるという前提で,データモデリングしておきたいところです。

② 二つの原価計算
全部原価計算と直接原価計算
すごく乱暴な言い方をすると,全部原価計算とは,間接費も案分・配賦して製品ごとの原価を算出する財務会計としての原価,直接原価計算は直接費と間接費に分けて管理する管理会計としての原価

本書では,どの製品を捨て,どの製品を伸ばしていくかは直接原価計算でなければ判定できないということを主張しているわけです。詳細は省きますが,全部原価計算の場合,配賦ということが経営判断を誤らせる元凶ではないかと思います。

企業が大きく,複雑になってくると,この配賦コストの仕組みも複雑になり,これを取り去った直接費を取り出して分析することが困難になってきます。これは,情報システムが全てのデータを最小粒度で保持していれば,直接費と間接費を分離できるかもしれませんが,事業部門,子会社,関連会社を通して原価を正しく分析しようとしても,データフローの途中でデータが合算され分離できなくなっているケースが多々あります。トランザクションデータを加工前の状態で保持していれば,集計軸を変えれば良いだけですが,合算されてしまうとどうにもなりません。

他にも企業レベルで情報システムとそのデータモデルを考えるうえで,多くの示唆を得られる個所が多々あります。機会あれば,他の個所もデータ管理やデータモデルと絡めて紹介したいと思います。

ワインのデータモデル

DAMA日本支部データモデル分科会では、データモデルについてであれば、DMBOKの枠にとらわれずに様々な話題を取り上げて議論・情報共有をしています。今年度は具体的なモデルについて、それぞれの考え方を議論・共有するという取り組みもしています。

さて、このblogではお題をワインとデータモデルとしてみました。ワインは歴史が長いだけあって、バリエーションが非常に多いです。データモデルのちょっとした題材に使えそうです。このモデルの拡張といったお題も、そのうち分科会で取り上げてみるかもしれません。興味を持たれた方はぜひ分科会への参加をご検討ください。DAMA会員であれば、どなたも参加できます。

ワインの基本要素としては、ブドウの種類、色(赤、白、ロゼ)、発泡性かどうか、場所といったことになるかと思います。

オールドワールド(フランス、イタリア、スペイン等)は地名(地方、村、畑など)がまず書かれて、ブドウの品種は書かれていなかったりしますが、ニューワールド(カルフォルニア、オーストラリア、チリ等)は、ブドウの品種がまず書かれるパターンがかつては主流でした。

イタリアワイン キャンティクラシコ(これは伝統的なキャンティ地域という意味)

また、オールドワールドでは、複数のぶどう品種を組み合わせることも多いのですが、ニューワールドでは単一品種で勝負したワインが主流です。カルフォルニアワインが有名になったきっかけはカベルネ・ソーヴィニヨンですし、今、コスパの良さで人気のチリカベはチリのカベルネ・ソーヴィニヨンの略語です。

こちらはイタリアのワイン一族(サッシカイア)がチリで作っているワイン
ピノ・ノワールというブドウ品種名が記載されています。 これはフランス、ブルゴーニュ原産です。

カベルネ・ソーヴィニヨンはフランスのボルドーが原産ですが、ボルドーではカベルネ・ソーヴィニヨンは単独でワインを作るのではなく、メルローという品種と組み合わせることが圧倒的に多いです。

さて、これらを念頭においてデータモデルにしてみます。

中心となるデータはワインですので、まず、これをエンティティとします。「ワイン」エンティティのインスタンスですが、同じ名前のワインでも作り手、ヴィンテージが違うとものすごく値段が違うので、それごとにインスタンスを作成することにします。主キーは「ワインコード」としてみましたが、これだと粒度がわからないので、「ワイン名」+「ヴィンテージ(ブドウを収穫した年)」*「作り手コード」を代替キーとします。シャンパーニュは原則としてヴィンテージは入らないので、その場合はNV(ノン・ヴィンテージ)と設定することにします。

「ブドウ品種」エンティティの主キーは「ブドウ品種名」とします。インスタンスはカベルネ・ソービニヨン、メルロー、シャルドネ、ソービニヨン・ブランなど。いま、日本で売っているワインの大部分はここであげた4品種から作られたものですね。

ワインによっては複数のワイン品種から作られますので、データモデルでは、「ワイン」エンティティと「ブドウ品種」エンティティはn:nの関連があることになります。n:nを1:nにするために交差エンティティ(関連エンティティという呼び方もあります)をモデルに追加しましょう。ここでは「ワインブドウ品種」というエンティティ名とします。「ワインブドウ品種」エンティティの主キーは、「ワインコード」+「ブドウ品種コード」の複合キーとするのが普通かと思います。

交差エンティティによってn:nを2つの1:nに変換しましたが、この2つにはどのような違いがあるでしょう?

「ワイン」のインスタンスなしで、「ワインブドウ品種」のインスタンスはありえません。

一方、ブドウ品種はワインに向くものと生食に向くものがありますので、「ブドウ品種」のインスタンスをワインに使われるものに限定しない限り。「ワインブドウ品種」に対応しない「ブドウ品種」のインスタンスがあり得ます。こういったことは「ブドウ品種」エンティティに、その定義を書いておくことで明確になります。

そう考えると、2つの1:nの関連には違いが出てきます。

カーディナリティを厳密に書くと、1:1..nと1:0..nとなります。

サンプルに掲げたER図にはそれ以外の要素もあります。「地方」エンティティに再帰リレーションシップがあることや、格付が「地方」と「ワイン」の両方にあるところ、「ワイン分類」の「バランス分類コード」とは何を意味しているのかなど。これを発展させてワインの販売管理のモデルを考えてみるなどは次回のお楽しみにとっておきます。

データモデルのスコープを広げよう

小規模なシステムで,単独で稼働するようなものであればデータモデルはDB設計の前段と捉えてもそれほど問題にならないが,企業や政府のシステムは複雑で,多数のシステムから構成されているため,全体を見通すことが難しい。企業合併や買収もあると,システムがそこかしこで分断され,無理やりのデータ変換や,EXCEL等の利用も含めた人間系を介在させることで,なんとかやりくりしていることも多い。

また,多数のシステムのうちのいくつかは外部から購入したパッケージやクラウドサービスを利用しているのも普通であろう。これらは内部のデータ構造はブラックボックスであることも多く,当該組織に合わせて最適なデータモデルというわけにはいかないことも多いだろう。しかし,全て自前のカスタムシステムで組織全体のシステムを構築することは時間的にも,コストの面でも現実的ではない。いや,時間をかけてもビジネスの変化についていけないシステムを長期間かけて構築することになりかねず,出来上がったときは,既に陳腐化している恐れもある。パッケージやクラウドサービスを組み合わせて使うことを前提として考えるべきだろう。

では,その前提に立ち、システム群を全体最適な構造に再構成し、どう維持していくかという課題に対する答えが、システム群を横断するエンタープライズレベルのデータモデルである。注意してほしいのは、個々のシステム内に閉じているローカルなデータは対象とせず、システム間で共有、連携されるグローバルなデータにフォーカスすることである。

データモデルとDB設計は密接な関係があるが(混同されている場合も多い),パッケージやクラウドサービス,継続使用可能なレガシーシステムを活かしつつ,アドホックでなく,アーキテクチャとしての連携を成功させる鍵は、システム群を横断するデータモデルである。DB設計のスコープは個々のシステムだが,エンタープライズレベルにスコープを広げたデータモデルが必要とされているのである。ただし、DB設計だけに引き継がれるのではなく、連携データのフォーマットやメタデータ定義、コード定義につながるのである。

DMBOK2では,DMBOK1にはなかった幾つかの章があるが,その1つとして「第8章 データ統合と相互運用性」がある。ここでは直接、データモデルに言及しておらず、テクニカルなデータ連携アーキテクチャに関する記述がメインだが、それだけではデータ統合はできない。 データHUB,EAI,ESB等が取り上げられているが,こうしたテクニカルなプラットフォームだけでは,個々のパーツ(システムやサービス)を全体最適の観点でつなぎあわせることはできない。

データモデルの適用スコープをここまで広げ,複数のシステムが会話する共通語としてデータモデルとメタデータ定義を行い,それに基づいて,個々のシステムが会話,連携できるようにすることがポイントである。アイテムや顧客についてはエンタープライズレベルのデータモデルに合わせてることで、複数のシステムが無理なく連携可能となる。

種々の事情があり,制約も多いため,安易な批判は避けたいが,特別給付金の電子受付と個々の自治体のシステムがうまく連携できなかったのも,こうした複数システムのスコープでモデルを作成できなかったことも関係しているのではないかとも思えるのである。