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