|
|||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
データ項目のとりうる値の範囲を定義域（ドメイン）と言います。定義域は、値の範囲だけではなく、値の集合や型（タイプ）、編集形式を規定することもあります。
ずいぶん昔、定義域とは何かということが議論されました。
「たとえば、年令。人の年令は３桁必要だが、犬の年令は２桁で良いはずだ。そう考えると、年令という定義域を用意するとしても、エンティティが何かを意識しなければならない。」あるいは、「電話番号や郵便番号は、いくつかのエンティティに登場するが、表現形式や桁を規定しておきたい。そのような場合、定義域を使おう。」などです。
「なぜそんなことがわかるんですか？業務経験も無いのに！」
モデラーがお客さまから感心される瞬間です。
私たちは、中学時代にＳ＋Ｖ＋Ｏ＋Ｃ、Ｓ＋Ｖ＋Ｏ＋Ｏなど、英語の文法を学びました。
動詞が決まると、その動詞によって要求される主語や目的語が決まります。
個別の動詞に着目すれば、主語や目的語をさらに詳細化できます。
たとえば「行く」という動詞は、
誰が、どこに、どんな方法で（徒歩で、バスで）、いつ、などの単語を必要とします。
通信業のリソースエンティティには、顧客エンティティとそのサブタイプである契約顧客エンティティ・請求先顧客エンティティ・利用顧客エンティティが登場します。
ここで、顧客エンティティを実体的エンティティ、他の３つのサブタイプを役割（ロール）的エンティティと呼ぶことにします。
役割（ロール）と参照ＫＥＹと論理組織が一致した概念モデルは、バランスのとれた美しいモデルです。新規業務設計の結果として、そのような概念モデルが出来上がることがあります。
結果として業務を説明する文は、次のような表現になるかもしれません。
「契約部署が契約顧客と契約し、その際に請求先顧客の名称や住所も記入してもらいます。請求部署は、請求先顧客に対して請求しますが、その際は契約時に記入された契約顧客の住所ではなく請求先顧客の住所に請求書を送ります」
参照ＫＥＹは、ＫＥＹを参照するデータ項目です。
典型的な通信業の回線利用契約エンティティには、契約顧客コード、請求先顧客コード、利用顧客コードといった参照ＫＥＹが存在します。これらの参照ＫＥＹは、リソースエンティティ顧客が、回線利用契約に関わる際の役割（ロール）を表しています。そして、参照ＫＥＹと本質サブタイプの対応関係から分かるように、この役割（ロール）に対して特別なデータ項目が存在するとき、顧客エンティティのサブタイプとして、契約顧客、請求先顧客、利用顧客を認識することになります。（たとえば、契約顧客の住所とは別に請求先顧客の住所を管理したい場合など。）
一般に、部署（または組織）の概念データモデルは、複雑になりがちです。その理由は、便宜サブタイプと本質サブタイプが錯綜する構造となるからです。
実世界を概念データモデルとして写像するとき、どこまでを１つのエンティティとして認識し、どこまでを別なエンティティとして認識するか、基準がありません。
現状分析では、すでに認識されたデータ項目を素材として概念データモデルを作成しますから、全く同じではないが、全く別でもないエンティティ達が登場します。
断面エンティティは、別名スナップショットとも呼ばれ、対象エンティティのある時点を記録するものです。月末残高、日末在庫数などの数値（ストックデータ）を持ちます。
要約エンティティは、ある期間に発生した数量データのサマリー値をもつエンティティです。月間融資実行件数、支店別月別出荷数量などの数値（フローデータ）を持ちます。
全社あるいは連結企業全体にわたる広さのデータ基盤を設計する場合、一般のデータベース設計と異なる難しさがあります。
物流種別を整理するにあたって、ここまでは「拠点Ａから拠点Ｂに物を移すこと」を中心に考えてきました。しかし、これだけでは不都合な場合があります。
さらに追加すべき２つの観点を紹介します。
物流にはさまざまなバリエーションがあります。我々が概念モデルを作成する際に困るのは、そのバリエーションの呼び方が人によって違う場合です。
同じ企業の中でも、購買担当、生産担当、物流担当、倉庫担当など、立場によって使う言葉が違います。
メタモデルにおけるデータ項目の扱いには、２つの流派があるようです。ここでは仮に、属性データ項目派・独立データ項目派と呼ぶことにします。
１）属性データ項目派
・データ項目は必ずエンティティに従属する。
２）独立データ項目派
・データ項目はエンティティとは独立に存在する。
概念データモデルは、業務的な視点で意味の構造を表しています。論理データモデルは、実装するファイルの構造を表しています。
通常のシステム開発では、この２つを別々の工程で作成します。もちろん、まったく無関係にこの２つを作成することはありません。概念データモデルをインプットとして論理データモデルを作成します。
実世界の写像・実世界のシミュレーション・実世界の構造を反映したソフトウェア構造など、「実世界とソフトウェアの構造が一致する、あるいは同じ形になる」といったイメージが存在します。私も、モデリングを始めたころは、これがモデリングの世界観として正しいものだと思っていました。
今から１３年前になりますが、「ビジネスシステムの場合このイメージはどこか変だ」と思うようになりました。
汎用性の高いデータモデルパターンや業務フローパターンを知っている人は、それをよりどころとして業務改善ポイントを指摘できるようになります。
もちろん、我々情報システムに関わる人間が「物流拠点を統合しよう」などと言えるわけがありません。その種の業務改善は、物流のプロにお任せします。
ここで言う業務改善とは、「情報を扱う業務の改善」です。主に、「ねじまがったデータ構造を正すことによって業務的に扱う対象の幅を広げること」「情報伝達上の問題を解決すること」の２つです。
ある開発プロジェクトのメンバと会話をしたとき、要求定義工程の話になりました。話の内容がときどきすれ違うので「要求定義とはどのような意味ですか？」と聞いてみました。
すると「どのような機能をコンピュータシステムで実現するかという定義ですよ」という応え。一方で、概念データモデルを作成する工程で、我々が使っている要求定義は、「情報要求の定義」すなわち、「ユーザが仕事をするにあたってどのような情報を必要とするか」です。
この違いはどこからくるのでしょう。
「単価がどういった単位で決まるか」を知ることはビジネスのやり方そのものを深く知ることでもあります。たとえば、単価が商品コードだけでユニークに決まるビジネス。それは非常に単純なビジネスです。販売の方法に多様性がない、１回で売る数量がいつも予想の範囲におさまる、決済の方法は現金に限る、顧客の種類が少なく一様に扱える、など。しかし、ビジネスが多様化してくると事態は一変します。店頭販売とインターネット販売では別な単価、販売量ランクに応じたディスカウント単価、現金決済とカード決済では別な単価、一般店と量販店では別な単価、・・・・・。
今回は、データモデルパターンの紹介です。ＭＤＡ(Model Driven Architecture)を研究している人にはアーキタイプパターンの方が喜ばれるかもしれませんが、振る舞いに関しては記述していませんので、やはりデータモデルパターンと呼ぶ方が適切だと思っています。
連結企業全体の概念データモデリングを実施する際、今まで気づかなかったことにも注意を払う必要が出てきます。従来のコンテクストよりも広いコンテクストを扱うためです。
多くの場合、受注のＫＥＹは受注番号で、出荷のＫＥＹは出荷番号です。たまに、出荷も受注番号で代用している企業があります。この場合、「ＫＥＹが同じなら１つのエンティティ」というルールでモデリングしますから、受注と出荷が１つにくくられます。（厳密に言えば、サブストラクチャとして表現します）。２つの出来事が１つに見える例です。
イベントエンティティ?の続きです。
残っている年月日は、最新更新年月日です。
最新更新年月日があるから最新更新エンティティ見つけた！
これは変です。最新更新という業務はないからです。
年月日を表すデータ項目に着目すると、イベントエンティティを簡単に見つけることができます。しかし、これだけでは危険です。
参照ＫＥＹとは、ＫＥＹを参照しているデータ項目のことです。たとえば、顧客コード（顧客エンティティのＫＥＹ）を参照する受注顧客コード（受注エンティティの従属データ項目）が参照ＫＥＹです。ＫＥＹを新しく設計するとき、あるいはＫＥＹの意味を定義するとき、我々は参照ＫＥＹを強く意識します。
エンティティの分類の１つ、「リソース」の考察です。
実世界が「もの」と「こと」から成り立つ世界であるとすれば、リソースは「もの」を表すエンティティです。ただし、製品や設備のような「物」意外にもリソースに分類されるエンティティがあります。たとえば、組織、社員、取引先、商品、サービス種別、顧客セグメント、勘定科目などです。
コンテクストは、文脈や状況などと訳されます。モデリングのコンテクストとは、モデリングの目的や範囲から決まってくる、モデリング自身の位置づけです。
顧客ファイルの一覧表を見ていました。すると、すべての従属データ項目の値が全く同じ２件の顧客レコードを発見しました。これってどういうこと？
今日の話はそんな状況からスタートします。
販売系で頻繁に登場する事例が、受注伝票のデータモデル図です。おきまりのように受注エンティティと受注明細エンティティが親子構造で現れます。
受注明細エンティティのＫＥＹは［受注番号、受注明細番号］あるいは［受注番号、受注商品コード］が典型的です。
この２つのＫＥＹの違いはどこにあるのでしょう。
ＫＥＹを頼りにエンティティを切り出したあと、モデリング素材である画面・帳票にはＫＥＹ以外のデータ項目が残っています。これらのデータ項目をエンティティに割り当てることは、一般に正規化と呼ばれています。
日産自動車などで広く知られるようになった「クロスファンクショナルチーム」という言葉をご存知の方も多いでしょう。既存の業務機能を代表する人々を集めて、全社的あるいはＳＣＭ全体の業務改善を実施するチームのことです。
エンティティやＫＥＹの話を連続して書くつもりだったのですが、「関係」について気になることがあるので、１つだけ触れておきます。「関係」に対して積極的に発番管理するメタモデルと「データ項目番号」で代用するメタモデルの２種類があることは、すでにお話しました。
その件と少しだけ関連があります。
ＫＥＹを頼りに見つけたエンティティから、本質的なエンティティに近づくためには「値」「エンティティオカレンス」を確認すれば良いことを、前回話しました。それに関連して今回はエンティティの粒度を説明します。
ＫＥＹを頼りにエンティティを見つける方法は、誰でも同じ答えにたどり着く、よい方法です。
一方で、形式的なモデリングになりがちで、ほんもののエンティティにたどり着く保証はありません。
いくつかの限界を紹介します。
エンティティの意味は、ＫＥＹの発番ルールに縛られます。
顧客エンティティのＫＥＹである顧客コードが、企業・企業の下位にあたる組織・個人を発番範囲としていれば、顧客エンティティの意味もその範囲になります。
エンティティは、原則としてＫＥＹをもちます。ここで言うＫＥＹは、データベースのプライマリーキーではありません。エンティティオカレンス１件１件を識別するユニークＫＥＹです。そのため、実装方式に関係なく、システム設計に入る前から、エンティティのＫＥＹを見つけることができます。
MDA（Model Driven Architecture）を研究している方はすでに読んだかもしれませんが、Enterprise Patterns and MDA（Jim Arlow,Ila Neustadt 2004）には、多くのアーキタイプパターンが紹介されています。今回は、形式化された「知」のお話です。（データモデル概論ばかりではあきますよね（笑））
近年、モデルが普及してきたのでしょう、業務プロセスモデルや概念データモデルを作成することが当たり前になってきました。
基幹系業務１つ程度の大きさのデータモデルを作成することは、正直なところそれほど易しくありません。教科書で勉強した、第一正規形、第二正規形、第三正規形という手順で正規化を進められるわけでもありません。（もちろん、効率を気にしなければやっても良いですが）
人事台帳、設備台帳、証書貸付の契約書などは１つの帳票で１００以上のデータ項目があります。一般的な販売物流業務では１０００〜２０００程度のエンティティが抽出されるでしょう。
これらのエンティティをわかりやすく配置し、モデル図上で業務的意味を共有するために、エンティティをもう少し細かく分類する必要があります。そして、各分類の性質を理解しておくべきでしょう。
そろそろ「関係」から離れて、エンティティの本質に近づきたいと思います。
さしあたって、今回は簡単にエンティティを説明します。
メタモデルにエンティティが必要か否かについて、１つのエピソードをお話します。
メタモデルを設計しているときの話です。
「必要最小限の要素で成り立っていること」はすぐれたメタモデルの要件として重要だ、と考えられています。
データ項目は、自分自身の中に構造があることを許すので、
顧客コード（＝支店コード＋顧客枝番号）と内部構造を定義することができます。
この例で、データ項目は３つと認識します。
個別企業の特徴が出るのは、当該イベントエンティティと前後のイベントエンティティとの関係です。であるなら、個別企業の特徴を排除し、関係を汎用的に扱うことができれば、汎用的な業務パッケージができるはずです。
エンティティは、その性質からいくつかに分類できます。その分類の１つに「イベントエンティティ」があります。
イベントエンティティは出来事を表すデータのかたまりです。（厳密に言えば、出来事を観測した記録や将来発生する出来事も含みます）
データモデリングファシリティを深く知るためには、そのメタモデルを見る必要があります。
いくつかのデータモデリングファシリティがありますが、「関係」を明示的に扱うものとそうでないものがあります。
誰が実施しても同じ答えになる概念データモデルの作成、三番目の条件は「作成した概念データモデルを評価する視点が共有可能で、誰でもレビュできる」です。
極論を言ってしまえ！第２弾です。
参照ＫＥＹはエンティティとエンティティを関係づけるデータ項目です。たとえば、受注エンティティの従属データ項目である受注顧客コード（これが参照ＫＥＹです）は、顧客エンティティのＫＥＹである顧客コードを参照しています。
結果として、顧客エンティティと受注エンティティは１:N（すなわち同じ顧客から複数回の受注がある）という内容を表すことになります。
データ項目にいくつかの種類があるとして、その内の参照ＫＥＹはエンティティ間の関係を表現しています。
では、参照ＫＥＹでないデータ項目はどうでしょうか。
今回は少々極論を言ってしまえ！と思っています。
「エンティティ」が未定義語であったとしても、ＥＲモデルを使う人の多くは「エンティティ＝もの」と考えていたようです。「もの」といっても少し幅があり、組織・社員・顧客・商品・場所などを対象としていました。
P.P.ChenがＥＲモデルを発表してから、急速にこのモデルが普及し始めた要因の一つは、その導入のしやすさです。トップダウンに「もの」を認識し、その関係をリレーションシップで表現する方法が、直感的で扱いやすかったためです。
今回は、第２の条件「モデリング方法論として完全である」を説明します。
唯一の答えを求めて・・「誰が実施しても同じ答えになる概念データモデルの作成」の続きです。
本来であれば、「唯一の答えを求めて その２」を書くべきところ、今日は寄り道して、エンティティという言葉についてコメントします。
誰が実施しても同じ答えになる概念データモデルの作成には、どのような要件が求められるのでしょうか。
細かいことを言えばきりがないのですが、主要なところをあげれば、次の３つになると思います。
第１に、モデリングファシリティとして正しい。
第２に、モデリング方法論として完全である。
第３に、作成した概念データモデルを評価する視点が共有可能で、誰でもレビュできる。
記述する量が多くなってしまうので、今回は第１番目を説明します。
モデリングファシリティとして正しいとは何か？ここで言う正しさとは、「モデリングファシリティを構成する要素が矛盾なく必要最小限である」ことです。
データ構造を表現する視点には、概念・論理・物理があります。視点別のモデル（図）を、概念モデル・論理モデル・物理モデルといいます。
一般にＥＲモデルやＴＨモデルを適用する範囲は、概念モデルまたは論理モデルになります。
概念モデルは、実装環境に関係なく業務上の「もの」や「出来事」を忠実にデータ構造として表現します。もちろん、作業工程（グループ企業のデータアーキテクチャ設計、企業全体の現状分析や新規設計、個別業務領域の現状分析や新規設計など）ごとにアプローチの方法が異なります。
普段使用している「データモデル」という言葉は、通常２つの意味があります。
それは、「データモデリングファシリティ」と「データモデル図」です。
データモデリングファシリティとは、データモデル機能のことです。すなわち、データ構造を表現するときに使う要素（エンティティ、データ項目、定義域、関係など）と規則のことです。文法と理解しても良いでしょう。
「データモデルの種類として、ＥＲモデルとかＴＨモデルがある」と言ったとき、ここで使った「データモデル」は「データモデリングファシリティ」のことを指しています。
もう１つの「データモデル図」は、すぐにわかると思います。ＥＲモデルとかＴＨモデルといったモデル機能を使って表現した図のことを指します。
人が会話するときは、コンテクストに応じてこの２つを上手に使いわけています。
データモデルって何？という質問に答えるのは簡単なようで難しい。両親に「私はデータモデリングのコンサルティングをやっている」と仕事の説明をしても、まったく理解してもらえません。人それぞれに育ってきた環境が異なるためでしょう、説明するために使った言葉が聞きなれない言葉であったため、さらに理解を妨げる・・・といった悪循環に陥ることがあります。正直、困ります。
弊社の代表取締役会長でありITアーキテクトでもある黒澤が、「コンセプチャルモデリングの哲学」と題して、データモデル、DOA（データ中心アプローチ）、エンタープライズアーキテクチャ、仕事観、人生観について語ります。
 |
 |
 |
 |
