JEMUGの入会案内をご覧ください。
2019データモデリングコンテスト結果発表
多数のご応募ありがとうございます。コンテスト開始以来、最多数の応募になりました。また、JEMUG会員以外の方からも応募いただき、記念すべき年になりました。
コロナウィルスの影響などで、会議の開催ができず、発表が遅くなったことをお詫び申し上げます。票が割れたのですが審査の結果、
JEMUG賞
Georgiamoonさん
FETEC賞
游悠さん
となりました。おめでとうございます。
作成していただいたモデルは、それぞれ下記のとおりです。
Georgiamoonさん
游悠さん
いずれ、作者の自作解説をご紹介する機会があると思いますが、出題者として意外だったのは、複数の方が、「伝票」や「送り状」に現れる項目を分析しておられたことです。評価の際にも、それに該当するエンティティがあるかということを評価項目に含めていらっしゃる方が複数おられました。
出題の「追跡サービスの画面」に現れる項目の中には、伝票に記載されている項目もありますが、伝票の中には荷物のサイズなど、今回の出題の対象外の項目もたくさんあります。書いても間違いというわけではありませんが、この部分は今回のコンテストの主題ではありません。
出題者は、荷物が保管と輸送(集荷や配達を含む)という2つの状態を交互に取りながら、目的地に到達する、ということをどのように表現するかがポイントだと思っていました。帳票分析は、分析の入り口としては、有効な場合もありますが、今回は帳票になっていない(公開されていない帳票としては存在するはずの)データの領域が多かったと思います。
2019データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2019データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】
宅配便の追跡をするサービスに関するデータモデルを25エンティティ以内で作成してください。以下で示す各社のサービスを共通に表現できるモデルにしてください。なお、概念データモデルについては、後述の「概念データモデルの定義」を参照のこと(いろいろな表記法を使われていると思いますが、このコンテストでは IDEF1X で書いてください)。
—————————————————————————————————
宅配便が受け付けられると、A社の場合、検索の結果このように表示されます。
"11/13 19:00-21:00" は、着日・配達時間を指定して発送したので、その日付のことです(多分)。
その後、検索する都度、輸送の経過が以下のように表示されます。(伝票番号等のヘッダー行の表示は省略。明細行の一番右の列は、トランザクション番号のようなものではないかと思われます。問い合わせの時に使用するのでしょう。)
—————————————————————————————————
—————————————————————————————————
—————————————————————————————————
—————————————————————————————————
—————————————————————————————————
ちなみに、同様なサービスを提供している他社の追跡サービスは、こんな表示が出てきます。
【B社の例】
【C社の例】
【応募方法】
1.ファイル形式
- 以下のうち、いずれかとする。
- erwin Data Modeler (以下 erwin) を使用して作成したファイル(.erwin)
このソフトウェアには試用版(FREE TRIAL)があるので、こちらを使って作成しても可。 - PDFファイル(.pdf)
A4もしくはA3サイズ1ページに全体像を収めること.。
- 2.送付方法
作成したファイルをメールに添付し、以下の様式に従って送付すること。
送付先: kunisawa_naoki@yahoo.co.jp
件名:最初の部分に、"【2019データモデリングコンテスト】"と記載すること。
本文:本文中には、氏名(本名)と連絡先メールアドレスを記載すること(必須)。匿名希望の場合は、その旨明記した上でハンドル名を付記すること(任意)。
(匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される)
応募は1名1件のみ。応募後の修正は締切日までは可とする。応募後の取り下げは認めない。
※(注記)応募作品の著作権について
応募作品の著作権(引用、再配布に関する権利)はJEMUG に帰属する。JEMUG および同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】
2020年1月31日
【賞】
JEMUG賞、FETEC賞各1名。
審査はJEMUGメンバーにより2月の会議で行う。
ささやかな賞品あり(お渡し方法は可能な範囲で応相談)。
【結果発表】
2020年2月下旬、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【審査基準】
○しろまる概念データモデルの定義
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用した場合など)は、その属性の Definition 欄に定義/説明を書いておくか、注釈(コメント)にてデータモデル上に付記しておくこと。IDEF1X記法については、http://idef.ru/documents/Idef1x.pdf を参照。
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。
○しろまる抽象化のレベル
25 エンティティ以内で表現するという制約のため、ある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
【ヒント】
このコンテストの目的は、業務知識の有無、例外事項の記述を問うものではなく、モデリングのパターンを使い、適切な抽象度で表現するスキルを比較検討しようとするものです。宅配便も天災や事故などにより途中で貨物が滅失した場合など、どういう記載になるのか想像もつきませんが、そういうことを求めているわけではありません。
今回は、おそらく少数のエンティテイで表現できてしまうのではないかと思いますが、今までのコンテストと同じ条件で「25エンティティ以内」とします。
2018データモデリングコンテスト結果発表
コンテストに応募いただき、まことにありがとうございました。
18日開催されたJEMUG会議において、審査いたしました結果、
FETEC賞 游悠さん
敢闘賞 髙橋さん
の受賞が決まりました。おめでとうございます。今回はJEMUG賞は該当作なしとなりました。
出題者のSさんから、解答例をいただきましたので、紹介します。
今回の出題は、いわゆる「マスター」がほとんどなく「トランザクション」だけで構成されているといってもよい、一風変わったモデルでした。(マスターとは何か、という問題には深入りしないでおきます。)
FETEC賞 游悠さんのモデルは、
敢闘賞 髙橋さんのモデルは、
です。
ツリー(木)構造を、Sさんは自己参照(【ブロックヘッダー】のところ)、游悠さんはサブタイプ(【マークルツリー】とそのサブタイプのところ)、高橋さんは有向グラフのパターン(【ブロック】【ブロック_再帰表】のところ)、で表現しています。
2018データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2018データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】
以下の説明サイトの記述およびデータサンプルから、"ビットコイン(Bitcoin)取引"を表現する概念データモデルを25エンティティ以内で作成せよ。なお、概念データモデルについては、後述の「概念データモデルの定義」を参照すること。(リンクを自動生成しないため":"を全角にしてある)
1.説明サイト「ビットコインのしくみ」(サイト内のリンク先は出題の対象外)
(1)Bitcoinの仕組み
http://bitcoin.peryaudo.org/design.html
(2)Bitcoinの細部(「コインの量の上限とマイニングの難易度」と「マイニングプール」の記述は出題の対象外)
http://bitcoin.peryaudo.org/detail.html
2.データサンプル
(1)「取引(トランザクション)」のデータサンプル https://www.blockchain.com/ja/btc/tx/85f8b14943052809f44a1a356e1b0060d49366a12cb66dca52a27bd786123b7c
(2)「ブロック」のデータサンプル https://www.blockchain.com/ja/btc/block/0000000000000000358fa848b19facc99fa1d6d56775eeee5025d8f34f77b31f
(3)「アドレス」のデータサンプル https://www.blockchain.com/ja/btc/address/1JLMKRdweJBagAA6o3wBR9P9BZWWmz3jdD
なお、「アドレス」は公開鍵から、公開鍵は秘密鍵から、ハッシュ等の様々な演算やエンコードを経て生成されますが、ここでは単純に"他の人にビットコインを送信するために使用される識別子"として扱ってください。
【応募方法】
1.ファイル形式
- 以下のうち、いずれかとする。
- erwin Data Modeler (以下 erwin) を使用して作成したファイル(.erwin)
このソフトウェアには試用版(FREE TRIAL)があるので、こちらを使って作成しても可。 - PDFファイル(.pdf)
A4もしくはA3サイズ1ページに全体像を収めること.。
- 2.送付方法
作成したファイルをメールに添付し、以下の様式に従って送付すること。
送付先: kunisawa_naoki@yahoo.co.jp
件名:最初の部分に、"【2018データモデリングコンテスト】"と記載すること。
本文:本文中には、氏名(本名)と連絡先メールアドレスを記載すること(必須)。匿名希望の場合は、その旨明記した上でハンドル名を付記すること(任意)。
(匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される)
応募は1名1件のみ。応募後の修正は締切日までは可とする。応募後の取り下げは認めない。
※(注記)応募作品の著作権について
応募作品の著作権(引用、再配布に関する権利)はJEMUG に帰属する。JEMUG および同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】
2019年1月31日
【賞】
JEMUG賞、FETEC賞各1名。
審査はJEMUGメンバーにより2月の会議で行う。
ささやかな賞品あり(お渡し方法は可能な範囲で応相談)。
【結果発表】
2019年2月下旬、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【審査基準】
○しろまる概念データモデルの定義
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用した場合など)は、その属性の Definition 欄に定義/説明を書いておくか、注釈(コメント)にてデータモデル上に付記しておくこと。IDEF1X記法については、http://idef.ru/documents/Idef1x.pdf を参照。
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。
○しろまる抽象化のレベル
25 エンティティ以内で表現するという制約のため、ある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
【ヒント】
「取引(トランザクション) 、「アドレス」、「ブロック」の関係がどのように表現されるか、ブロックチェーンはどのような関係で表現されるかが、ビットコイン取引を表す概念データモデルの鍵になると思います。なお、「取引(トランザクション)」の内容の確認方法は、以下のサイトが参考になります。
ビットコインのトランザクション内容の確認
http://moblock.jp/articles/18383#1609621
(リンクを自動生成しないため":"を全角にしてあります)
【質問について】
質問は、kunisawa_naoki@yahoo.co.jp までメールで送付する。(間違っても「bitcoinのしくみ」の作者や、BLOCKCHAIN社に問い合わせたりしないこと。)「件名」の最初の部分に、"【2018データモデリングコンテスト】"と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。
【審査内容について】
本コンテストに関わる審査内容の質問についてはお答えいたしかねますので、あらかじめご了承ください。
游悠さんによる、2017データモデリングコンテスト FETEC賞自作解説
恒例によりまして、受賞者の方には自作解説をお願いしました。
游悠さん自作解説をお届けします。
今回の課題は提示された資料の表している概念をデータモデルで表記するとういうものでした。これは内容をどの視点で捉えるかにより、作成するモデルに違いの出る結果となったようです。応募者の多くは電子殻表のマスタを表現しようとしましたが、当方はある元素の電子状態がどのようなものかを現実世界として捉え、いわばボトムアップで示すようなモデルを作ろうと考えた点で独自の表現になったように思えます。この視点の違いを、もう一方の受賞者のデータモデルと比較して読むと面白いのではないでしょうか。
このモデルは主に3つの部分で成ります。一つはモデル図の右上の白色で表現する箇所。ここは元素周期表と元素の関係を表現します。元素という性質は周期表の「周期」と「族」の2元表で多くは配置されますが、ランタノイドおよびアクチノイドに属する元素はこの規則に単純に当てはまりません。それを分類可能としたのが「元素群カテゴリ」です。そして周期表に属する元素の性質と対応するものとして元素実体を示しています。この実体は原子核と電子から組合わされますが、今回の課題資料の範囲では元素同位体は説明に入っておらず、単に「原子核実体」エンティティで表すだけにしました。
一方の電子群の実体を表現するために二番目の部分があります。それが、オレンジとピンク色で示される「電子実体」群です。これらの電子実体群のそれぞれがどういう位置付けなのかを見ることができるようにした表現です。これにより、最外殻電子(主に自由電子と呼ばれるもの)を個別に表現でき、またイオン化した個別の元素状態を知ることができるようになります。
モデル図の三番目が左半分にある青、緑色の部分です。ここは、電子殻軌道のフォームを表しており、元素がどのフォームの軌道に結びついて電子実体を収容し得るのかを対応付けして表現できます。元素固有の取り得る電子殻軌道の形との関係を付けるために「電子配置」エンティティがあります。そして電子実体群と、取り得る電子殻軌道のどこにそれぞれの電子が配置されているかという現在の状態として表せるようにしています。これにより「動的に」具体的個別元素と電子配置の取っている姿を示せるというものです。
以上
2017データモデリングコンテスト結果発表
コンテストに応募いただき、まことにありがとうございました。26日開催されたJEMUG会議において、審査いたしました結果、
JEMUG賞 Sさん
FETEC賞 游悠さん
の受賞が決まりました。おめでとうございます。
SさんのER図は
游悠さんのER図は
2017データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2017データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】
Wikipedia の
電子配置
http://ja.wikipedia.org/wiki/%E9%9B%BB%E5%AD%90%E9%85%8D%E7%BD%AE
電子殻
http://ja.wikipedia.org/wiki/%E9%9B%BB%E5%AD%90%E6%AE%BB
の記述をもとに、ここで述べられている諸概念を表現するデータモデルを25エンティティ以内で作成してください。
【審査基準】にある「概念データモデル」レベルで回答いただきます。「一般属性の記載については任意」と書いてありますが、(削除) 「要領」の末尾についている「別記様式」に現れるデータ項目について、主要なものはなるべくモデルに表現してください。 (削除ここまで) (訂正:コメント参照 2017年12月30日)(必ずしも全てのデータ項目を取り込む必要はありません。)
【応募方法】erwin Data Modeler (以下 erwin) を使用して作成する。このソフトウェアには試用版(FREE TRIAL)があるので、こちらを使って作成しても可。作成した.erwin ファイルをメールに添付してkunisawa_naoki@yahoo.co.jp まで送付する。「件名」の最初の部分に、"【2017データモデリングコンテスト】"と記載すること。メールの「本文」に氏名(本名は必須、匿名希望の場合はその旨明記した上でハンドル名を付記)、連絡先メールアドレスを記載すること。匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される。応募は1名1件のみ。応募後の修正は締切日までは可とするが、応募後の取り消しは認めない。応募作品の著作権(引用、再配布に関する権利)はJEMUG に帰属する。JEMUG および同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】2018年1月31日
【賞】JEMUG賞、FETEC賞 各1名。審査はJEMUGメンバーにより2月(日程未定)の会議で行う。ささやかな賞品あり(お渡し方法は可能な範囲でご要望に応じます)。
【結果発表】2018年2月下旬、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【審査基準】
○しろまる概念データモデルの定義
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用した場合など)は、その属性の Definition 欄に定義/説明を書いておくこと。
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。
===【ヒント】===
原子核の周りを、粒子状の電子が軌道を描いて回っている、という、古典的なモデルを、取り上げます。原子そのものに関する原子番号、周期、族、電子の殻、軌道などがモデル化され、実際の元素がデータとして格納できるようなモデルを考えてください。
==========
○しろまる抽象化のレベル
25 エンティティ以内で表現するという制約のため、ある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
○しろまる質問
質問は、kunisawa_naoki@yahoo.co.jp までメールで送付する。「件名」の最初の部分に、"【2017データモデリングコンテスト】"と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。
ERWIN DATA MODELER [FREE TRIAL]
erwin の community edition はなくなりましたが、試用版がWebで公開されています。FETEC の西嶋さんに教えていただきましたので、お伝えします。
http://erwin.com/resources/software-trials/
を開いてみてください。
erwin Data Modeler の下にある TRY NOW のボタンをクリックしてください。
右のほうにあるフォームの必要項目を入力して下さい。ちなみにメールアドレスに関しては、フリーのアドレスはダメなようです。yahoo のメールは使えませんでした。入力が終わったら、フォームの下の方にある Download Trial のボタンを押してください。
erwin Data Modeler 64-bit version
erwin Data Modeler 32-bit version
が、クリッカブルになっていますので、どちらかを選んでください。ダウンロードが始まります。落ちてきた exe ファイルを実行すればインストールできます。もう一つ、この画面の
To get your license file, click here.
の、"here" の部分がクリッカブルになっています。起動させるときに TRIAL 版のライセンスファイル(ERwinEvalLicense.lic)が必要になりますので。これもダウンロードしてください。
インストーラーに従ってインストールした後、erwin を起動すると、
というダイアログが出てきますので、Use Local licence を選択して、Install License File ボタンをクリックして下さい。開いた画面から、先ほどダウンロードした License File を選択すると、erwin が使えるようになります。
現在インストールすると、r9.7 がインストールされます。
游悠さんの自作解説
↑ 画像をクリックすると、ER図の詳細が確認できます。
モデル作成のポイントについての解説 Written by 游悠 (2016年12月13日)
今回授賞したデータモデル作成時の考慮ポイントについて簡単に説明します。利用したモデル作成ツールには、ERWinのコミニュティエデションを使用しているため、25エンティティ以内でコンテスト応募ERモデルを作成するという条件があることも考慮条件でした。
- 基本エンティティの取扱いについて
- E、I、Oエンティティについて
- Aエンティティについて
- Edgesエンティティと関係性(リレーション)の表現について
まず、Panama文書DB情報(今回csvファイルとして提供)の基本エンティティとして、Officers、Intermediaries、Entities、Addressesの4つを取り出すことができます(以下、それぞれ「O」、「I」、「E」、「A」と略す)。これらはデータ特性からノードIdがキーとなっていることが分かり、元々利用されているグラフDB(Neo4J)との関係からみて、ノードというエンティティのサブタイプとして扱えることになりました。そこで確認が必要なのは、ノードId単独でO、I、E、Aの各エンティティの全データがユニークに識別できるかということです(つまり、ノードエンティテイの主キー(PK)として、ノードId単独項目が使えるかということ)。データ調査の結果、OとIのノードIdには1,100件を越える値の重複があることが分りました。この件数は単なる入力誤りなどによるものでなく、DB作成者の意図によるものと考えられます(例えば、OとIの中の出現者(人または企業)は、時々の果たす役割で使い分けられている)。そこでノードエンティティの主キーには、ノード型コードの追加が必要であると結論付けをしました。そして基本4エンティティの共通属性としてvalid_until、source_ID、country_code(国コード)の3項目を取り出せます。この中で国コードは、データを調べると1件当たりに複数の国を記述していることが分るため、CountryとNodeとの関係として取り出しました。これは単なる多対多として表現できますが、ここでは記入順番が判断の優先度と係わる可能性も考慮し、連番で識別できる形で表現しています。valid_untilとsource_IDはノードエンティティへの属性項目として記述し、
モデル全体エンティティ数制限の関係からモデルエンティティとしては表現せず、コード値についてコメント内に補足をするに止めました。
これらのエンティティ内データには、企業名と個人名が混在するため、これらを区別する意図としてパーティ区分エンティティを切り出しました。これは特にEのcompany_type項目の位置付けに注目させる表現として役立つと考えています。Eについては、jurisdiction(租税回避地)がモデル表現理解の上で意味を持つという考え方から、租税回避地エンティティとして見える形で表しています。
また、Eエンティティの日本語名称は、「エンティティアカウント」と名称表示しました。その理由として、エンティティの属する各レコード(ロウ)の開設日などの項目を設けた視点を取り入れ、取引口座という解釈を与えるためであることを付記します。
住所項目はIとEには項目として存在し、Oには存在しません。そしてこのAが別途のエンティティとして元のDBで扱われています。そしてこれに係わる関係性がリレーションとして使われています。このため、Aエンティティの持つ住所情報は、DB作成者のデータ利用の意図を表すと考え、IとEでのaddress項目はレコードに関する「住所地表記」として項目命名し、またAエンティティは「住所地情報」として名称付けを行い、名称によりそれぞれの位置付けを区別するモデル表現にしました。
パナマ文書情報がグラフDBを用いて開示されていることの大きな目的の中で、この関係性表現を理解することが大切であると筆者は判断しました。このため、Edgesのcsvファイルで提供される関係性情報を今回のデータモデルでもきちんと表現するのが重要と考えました。それがNode間の関係としてEdgesエンティティを記述した理由です。Edgesエンティティの主キーには、リレーションタイプ(関係性型)を含めています。この関係性型は、元のパナマ文書DBではグラフ上のエッジ(有向辺)として示される関係性(78種類(※(注記)1))を、その関係性の果たす役割(繋いでいるノードの型や意味合いなど)によって9種類に筆者が分類したものです。この関係性型の中で最も属する種類が多かったのが「オフィサー-エンティティ関係(オフィサー位置付け))で、63種類ありました(例えば、取締役、株主など)。そこでこの関係種類をオフィサー役割として取り出し、エンティティ表現したものです。上記の9分類を関係性型分類エンティティのサブタイプ化しました。
以上のような考え方で、全体25エンティティというツール制限一杯で表したものが、今回の授賞したER図です。
筆者はまた、このパナマ文書DB(グラフDB)の全体像がER図表記だけでは捉えにくいという考え方をして、別途ネットワークグラフ表現を用いた分かり易い概念図も作成しました。それは紙面の関係でここでは明示していません。この内容について関心のある方は、モデリングコンテスト主催者を経由して、連絡先明示の上、別途筆者宛お問合せ下さい。
注 ※(注記)1 元のDBではユニーク値は80種類となりますが、例えば「Shareholder of」と「shareholder of」という具合に同一として扱えると判断できるものがあり、それらを一緒にして、78種類あるとしました。
(以上)
2016データモデリングコンテスト結果発表
データモデリングコンテストに多数応募いただきありがとうございました。12月9日のJEMUG会議で、厳正な審査の結果、受賞者を次のように決定しました。
JEMUG賞 (匿名希望)游悠さん
FETEC賞 (匿名希望)Sさん
游悠さん、Sさんおめでとうございます。すでに、受賞された方には、結果をお知らせしています。
游悠さんのモデル、
↑ 画像をクリックすると、ER図の詳細が確認できます。
Sさんのモデル
↑ 画像をクリックすると、ER図の詳細が確認できます。
游悠さんは、【Node(ノード)】【Edges】【Relation Type】、Sさんは【Nodes】【All_edges】【Rel_types】、この部分で同じ構造があります。これは有向グラフパターンの応用で、出題者が「グラフデータベース「Neo4j」で実装されています。」と書いてあったことが手がかりになったと思います。
【Node(ノード)】あるいは【Nodes】の下に、4つのサブタイプが来ることも共通しています。ただ、惜しくも受賞は逃されましたが、一人の方が、【Address】を独立したエンティティではなくその他のサブタイプの属性とされた方がいらっしゃいました。もし「その他の属性」がそれぞれ一つだけの【Address】しか持たないのであればそういう選択肢もあるわけですが、グラフデータベースに実装する場合の考慮点を示唆した考え方だと思います。
游悠さんの「自作解説」を引き続きお届けします。
2016データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2016データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】
「パナマ文書」のデータベースが、国際調査報道ジャーナリスト連合(ICIJ)のサイト上に公開されている。(以下のURLでは、リンクを自動生成しないため":"を全角にしてある箇所があるのでご注意ください。)
■しかくブラウザ上で検索可能なデータベース
https://offshoreleaks.icij.org/
初めてアクセスした際などに、データベース使用前の確認画面が出ることがある。「データベースに含まれるいかなる人物や企業が法律を破った、またはその他の不適切な行動したということを示唆したりほのめかしたりする意図はない」といった内容を一通り読んで理解したら、確認画面の左下にあるチェックボックスをオンにして、「SUBMIT」ボタンをクリックする。
■しかくオリジナルのデータベースをCSVファイルに変換したもの
https://offshoreleaks.icij.org/pages/database
第2パラグラフ中ほどの「You may download an archive of all these files here.」の「here」のリンクをクリックすると、ZIP圧縮ファイルをダウンロードできる。ZIP圧縮ファイルの中には6つのファイルが含まれており、1つは説明のテキストファイルで、残りの以下5つのファイルがデータベースを変換したものとなる。
- Addresses.csv
- all_edges.csv
- Entities.csv
- Intermediaries.csv
- Officers.csv
これらに従って、パナマ文書のデータを正確に読み解くための概念データモデルを作成せよ。なお、概念データモデルについては、後述の【概念データモデルの定義】を参照すること。
【応募方法】
1.ファイル形式
ERwinDataModeler Community Edition(無償)を使用して作成するか、あるいはこのソフトで読み込み可能なファイル形式(.erwin)で応募すること。(ERwinには上位互換性があり、以前のバージョンで作成したファイルも読み込み可能だが、場合によってはファイル形式の変換を依頼することがある)
2.送付方法
作成した.erwin ファイルをメールに添付し、以下の様式に従って送付すること。
送付先: kunisawa_naoki@yahoo.co.jp
件名について:最初の部分に、"【2016データモデリングコンテスト】"と記載すること。
本文について:本文中には、氏名(本名)と連絡先メールアドレスを記載すること(必須)。匿名希望の場合は、その旨明記した上でハンドル名を付記すること(任意)。
(匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される)
3.応募作品について
応募は1名1件のみ。
応募後の修正は締切日までは可とする。応募後の取り下げは認めない。
※(注記)応募作品の著作権について
応募作品の著作権(引用、再配布に関する権利)はJEMUGに帰属する。JEMUGおよび同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】2016年11月30日
【賞】JEMUG賞、FETEC賞各1名。
審査はJEMUGメンバーにより12月の会議で行う。
ささやかな賞品あり(お渡し方法は可能な範囲で応相談)。
【結果発表】2016年1月下旬、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【概念データモデルの定義】
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用した場合など)は、その属性の Definition 欄に定義/説明を書いておくこと。IDEF1X記法については、http://www.idef.com/pdf/Idef1x.pdf を参照。
【ERwinDataModeler Community Editionの入手方法】
ERwin, Incの以下のサイトより無償でダウンロードできる。
http://erwin.com/products/data-modeler/community-edition
画面右側の「Download Now」をクリックし、簡単なユーザー登録の後にダウンロード画面が表示されるので、32bit版もしくは64bit版のいずれかを選択してダウンロードすること。
【審査基準】
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。なお、データモデルで表現しきれない仕様のうち、特筆すべきものがあれば注釈(コメント)にてデータモデル上に付記すること。
○しろまる目的との整合性
概念データモデルの定義には、「一般属性の記載については任意」とあるが、「パナマ文書のデータを正確に読み解く」目的を満たすために必要なものはデータモデルに表現すること。必ずしも全てのデータ項目を取り込む必要はないが、目的との整合性は審査の対象となる。
○しろまる抽象化のレベル
ERwinDataModeler Community Editionは25 エンティティまでしか表現できないため、この制約内でモデルを書くことが必要となる。そのためにはある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
【日本語名を使用する場合の注意事項】
エンティティ名やデータ項目の日本語名への翻訳は不要。もし日本語名を使用したい場合は、日本語名に続けてカッコ付けでオリジナルの英語名を付記するなど、元の英語名との関係がわかるようにすること。
【ヒント】
「企業(Entities)」や「役員(Officers)といったものの関係が概念データモデルではどのように表現されるか、また生データから読み取れるデータの規則性が概念データモデルではどのように表現されるか、これらがパナマ文章のデータを正確に読み解くためのデータモデルの鍵になると思います。
パナマ文書のデータベースの使い方は、以下のサイトが参考になります。
http://gigazine.net/news/20160510-panama-papers-database/
(リンクを自動生成しないため":"を全角にしてあります)
【質問について】
質問は、kunisawa_naoki@yahoo.co.jp までメールで送付する。(間違っても国際調査報道ジャーナリスト連合(ICIJ)や、パナマ文書に出てくる企業や人物に問い合わせたりしないこと。)「件名」の最初の部分に、"【2016データモデリングコンテスト】"と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。
ご参考までですが、パナマ文書のブラウザ上で検索可能なデータベースは、NoSQLのひとつであるグラフデータベース「Neo4j」で実装されています。グラフデータベースによってビジュアルに表現される関係が、概念データモデルではどのように表現されるのか理解することで、グラフデータベースの使いどころや、リレーショナルデータベースとの使い分けを検討しやすくなるかと思います。
Sさんの自作解説
↑ 画像をクリックすると、ER図の詳細が確認できます。
モデルの位置づけ(分析モデル)
- 回答のデータモデルは、証拠物件取扱要領が制定された趣旨(目的)と要点に適合すること、およびその説明ができることを意識して記述した、業務の分析モデルです。
モデル化の進め方
- 取扱要領の制定の趣旨には、
(1)証拠物件が滅失、損傷、散逸等することのないよう取扱いを適正にする
(2)取扱いの手続きについて更に明確にする
とあります。
制定の要点として
(a)責任区分を明確にし、管理体制の確立を図る
(b)分任保管、出納状況を明らかにする
(c)責任者不在の場合における証拠物件の仮出し等の要領を定める
といった内容が掲げられています。
これらを踏まえた上で、証拠物件に関わる各種取扱いでどのようにデータの管理がなされているか、取扱要領の文章と帳票の構造から、ひとつひとつ読み解いて分析し、モデル化していきました。
モデルの説明
1.制定の趣旨(目的)や要点と強く関係する部分の記述
(1)管理体制 ※(注記)要点(a)に対応
証拠物件の責任区分については【責任】に持たせ、【組織】のどの【従業員】に責任を持たせているかについては、【責任者】に持たせています。
ある時点での責任の所在が後からでも判別できるよう、【責任者】を識別する情報として[指定日]を持たせました。
(2)分任保管 ※(注記)要点(b)に対応
取扱要領の第8の2には、
・様式第2の「保管引継・返還書」を作成して引き継ぐ
・適宜の袋等に収納し、取扱責任者の印で封かんする
・袋等が複数に及ぶ場合は事件番号に枝番号を加える
とあります。
【事件】に対して複数回発生する【保管引継】に、それぞれ[枝番]が振られた複数の袋を管理する【保管引継明細】がぶら下がります。袋には1つ以上の【証拠物件】が封かんされているとし、その内訳を【保管引継明細証拠物件】に持たせました。これがないと、どの証拠物件を引き継いだのか不明確になるためです。
【保管引継】の後に発生する【返還】は、引継ぎとは発生のタイミングの異なる出来事であるとして、【保管引継】から切り出しています。
【分任保管管理】では、年ごと、分任保管部署ごとに作成される分任保管管理簿に記録している[引継年月日]や[保管期限]、[事件番号]を管理します。
(3)出納状況(責任者不在の場合を含む) ※(注記)要点(c)に対応
取扱要領の第9の1には、
・様式第3の「証拠物件出納表」を記載し、仮出しを受ける
取扱要領の第9の3には、
・本署当番責任者等が保管する証拠物件の仮出しを受ける場合は、その都度出納表を記載し、本署当番責任者等の承認を得る
とあります。
ここで問題となるのが、取扱責任者への引継ぎの完了していない、宿日直時間帯に生じた証拠物件(証拠品番号が振られていない証拠物件)の取扱いです。
取扱要領の第11の3には、
・様式第6の「当番引継簿」を保管設備に備え付け、証拠物件が生じた場合に記載する
・当番引継簿の末尾に出納表を編てつして出納状況を明確にする
とあります。
事件の主管部署による【証拠物件】の管理に先立ち、本署当番責任者は、宿日直時間帯に生じた証拠物件を自らの責任で管理し、さらに本署当番責任者等の間の引継ぎを記録する必要があります。
宿直時間帯に生じた証拠物件(証拠品番号なし)の管理は【本署当番等保管証拠物件】で、本署当番責任者等の間の引継ぎの記録は、【本署当番等保管証拠物件引継】で管理します。
【仮出し】は、【取扱責任者保管中】である[証拠品番号]の振られた証拠物件と、【本署当番責任者等保管中】である[証拠品番号]の振られていない証拠物件の両方に対して行われます。
2.その他の部分の記述
(1)封印・開披
【事件】に対して複数回発生する【封印】ごとに、複数の証拠品が【封印明細】に記録されます。【開披】は【封印】とは発生タイミングが異なります。
(2)送致・払出し
送致や払出しは、事件、証拠物件の単位で行われます。
送致は【証拠品送致状況】、払出しは【払出】で管理しています。
(3)証拠物件の状態
保管引継や返還、仮出しから返納など、証拠物件の状態変化の記録をトレースできるよう、証拠物件の状態変化の履歴を【証拠物件状態】に持たせました。
抽象化に対する私の考え(今回のお題に限って)
(1)人と組織と役割
証拠物件取扱業務で管理が必要となる範囲の記述に留めています。いわゆるパターンによる汎用化は行っていません。理由は、2つあります。
1)管理の対象範囲がわかりづらくなる
例えば、管理対象外となるであろう組織改変や人事異動までも管理の対象としているように、パターンモデル上は見えてしまう。
2)正しい理解が得られにくくなる
業務で扱いのない汎用的なパターンモデルの用語についてその定義を述べた上でモデルの説明する必要があるため、説明がしづらくなる上に、正しい理解も得られにくくなる。
なお、これらは分析モデルとしての話です。パターンモデルを用いて設計、実装するかどうかは別の議論と考えています。
(2)証拠物件に関わる各種取扱い
取扱いごとに管理の単位が異なることを正しく表現するため、証拠物件に関わるイベントの抽象化は行っていません。
・【保管引継明細】は事件、保管引継、袋(枝番号)の単位であり、証拠物件の単位ではない。
・【仮出し】は事件、証拠物件の単位で行われる他、[証拠品番号]が振られていない証拠物件(本署当番責任者等が管理する証拠物件)に対しても行われる。
・一度に複数の証拠物件が【封印】されるが、【開披】は封印単位で行われる。(封印された複数の証拠物件のうち、その一部のみを開披することはない)
・送致や払出しは、事件、証拠物件の単位で行われる。
(3)決裁
さまざまな取扱いにおいて発生する承認や決裁については、【決裁】にまとめました。
Editor の自作解説
↑クリックするとER図の詳細が確認できます。
こんにちは。自分で出題しておいて賞をもらった Editor です。受賞者の皆様には、自作解説をお願いしたので、まず私から始めます。(他の方々もお願いしますよ。)
出題者ですから事前に出題内容はわかっており、「問題の理解」という点ではもちろん有利な立場にありました。モデルを作るのに要した時間は10時間とちょっとくらいです。前に記事にした「有限個の値リストからなるドメイン定義」をやってみたので、ER図を描くだけならもう少し早くできたと思います。
今回のモデルの特徴は2つあると思います。一つは無理やり【パーティ】を使ってみたこと。もう一つは【証拠品イベント】で証拠品に関する様々なイベントを抽象化することです。
【パーティ】は、今回の分析対象範囲では警察の組織と警察の【職員】がほとんどで、あとの登場人物は、証拠品の【所有者】、【被害者】、【被疑者】くらいのものです。この3者に関する組織情報などは保持しておらず、「名寄せ」の余地など実際上皆無ということになりますから、そもそも【パーティ】を持ち出すメリットはほとんどないと考えられます。それでも【パーティ】を使うとこうなるということをやってみたかったということです。
【証拠品イベント】はこのモデルを簡素化する(そして25エンティティに「押し込める」)ために中核的なアイデアになると考えていましたし、募集要項のなかでヒントを出しておいたのですが、これをやらなかった場合は大変な苦労をすることになったと覆います。(たぶんSさんは苦労されたと思います。)
この汎化された【証拠品イベント】と【職員】(単なる「人」ではなく、「何年何月にどこそこのこれこれの職位に配属された何さん」という属性を持った「担当者」)の間に交差エンティティとして【イベント関係者】がありますが、一つの【証拠品イベント】(たとえば"引継")に複数の【イベント関係者】(例えば"引き渡し者"と"引き受け者")があり、一つの【職員】は複数の【証拠品イベント】に関係するわけですから、このモデルの中ではおそらくこのエンティティが最も多くのタプルを抱え込むことになると思います。(【職員】に分析対象業務にかかわらない大量のタプルが登録されない限り。)
この【イベント関係者】のように、汎化されたエンティティ同士の交差エンティティを持つべきではない。つまり【証拠品イベント】と【職員】にサブタイプ(たとえば【分任保管開始】イベントや【分任保管資格者】職員)を作ってサブタイプ間にリレーションを設定すべきであるとの意見もあり、そういう方のモデルも見てみたかったのですが、そういう応募作がなかったことは残念です。25エンティティの中に納まらなかったからだと思いますが。
宿日直等時間帯に発生した証拠品については「本署当番責任者」と呼ばれる担当者が証拠品を管理し、場合によっては「出納」も行う、ということが『取扱要綱』に書いてあります。おそらくこの時にはまだ、《事件場番号ー番号》や《証拠品番号》が発番されていないのではないかという指摘がありました。このことは私は見落としていたのですが、これを考慮すると、モデルは
↑クリックするとER図の詳細が確認できます。
【証拠品】にサロゲートキーを振って、【事件】との従属関係を参照関係(nullを許す)に変更します。これで、【事件】と紐づかない状態の【証拠品】を記録することができます。必ずしも必要というわけではありませんが、サブタイプに【仮保管証拠品】と【保管証拠品】をつけて、【証拠品】のステータスの違いを統合したことを明記しておきます。
仮保管状態と保管状態で【証拠品】の粒度が違ったらどうするか?・・・それは一旦何かの【証拠品イベント】で登録を仮抹消して、新たな《証拠品管理番号》を振り出すしかないでしょうね。(そのために【証拠品】同士の関係づけを管理するエンティティを作るかどうか、これは業務の要求次第。)
普段、サロゲートキー回避派である私が、こういう時だけサロゲートキーを使うのはけしからん・・・とかいうご批判は、歓迎します。答えのない泥沼にはまりそうですが。
2015データモデリングコンテストの結果
29日の会議で、2015データモデリングコンテストの受賞作が決まりましたので発表いたします。発表が遅くなりましたことをお詫び申し上げます。
JEMUG賞 Sさん(匿名希望)
CAJ賞 Kさん(匿名希望)
JSYS賞 Editor(JEMUG GUEST ROOM の「中の人」 : 出題者である「私」はいままで応募していなかったのですが、お勧めがあって前回から応募するようにしています。今回は賞をいただきましたが、厳正な投票の結果ですのでご容赦ください。)
それぞれのモデルを掲示します。
Sさん
S1A
↑クリックするとER図の詳細が確認できます。
Kさん
応募作K
↑クリックするとER図の詳細が確認できます。
Editor
応募作E
↑クリックするとER図の詳細が確認できます。
審査の中で大きなポイントになった点は、「証拠品番号」(年別および係別に一連の事件番号を付したうえで一連の証拠品番号を付す)が付番されない時点の証拠物件(宿日直時間帯に発生した証拠物件)をどう表現するかで、これをクリアしていたのはSさんだけでした。表現しようとしている物の主キーが、スコープに置いている期間で変わってしまうという問題は、例えば工場にあるときの自動車(型番+製造番号)と陸運局に届けた自動車(ナンバープレート)を通してスコープに置きたい場合など、応用可能性がある問題ですね。(出題者はこの問題の中にそういう側面があることは想像していませんでした。)
それぞれの方の「自作解説」を予定していますので、乞うご期待。
有限個の値リストからなるドメインの定義の仕方
データモデルを作っていると、自分独自のドメインを定義したくなることがあります。属性を定義するとデータ型はプルダウンメニューで選べます。たとえば曜日を表すドメインはデータ型は文字列ですが、実現値は"日曜""月曜""火曜""水曜""木曜""金曜""土曜"の七通りしかとることができない、ということを表現したくなります。
ERwinにはこれを表現する方法があります。ちょっと長くなりますが、操作手順を書いておきます。ERwin のリポジトリの機能の一端が伺えると思いますので、時間があるときに追いかけてみてください。
例えば、学校の時間割のように、曜日と時限で授業科目が決まっているような場合を考えます。まず普通にモデルを書きます。
このとき、≪曜日≫の属性はまだデフォルトの文字列です。
Model Explorer の Validation Rules を右クリックし、新しいルール「曜日」を追加します。
ルール「曜日」を右クリックし、Properties ウィンドウを開きます。
Type のプルダウンメニューから Valid Values を選びます。すると、Expression の入力エリアが変わって、値の入力ができるようになります。
‘曜日’ Valid Valies の下にある New ボタンを使って値を入力していきます。
全部入力が終わったら Close ボタンを押します。Model Explorer の Domains を右クリックし、新しいドメイン「曜日」を追加します。
ドメイン「曜日」を右クリックし、Properties ウィンドウを開きます。「曜日」というドメインのデータ型を適切に修正します。下にある Constraint タブを開いて、Use Inherited Constraint のチェックボックスを外すと、Validation 欄のプルダウンが使えるようになりますので、先ほど作成したルール「曜日」を選択します。入力が終わったら Close ボタンでウィンドウを閉じます。
モデル画面の【曜日】エンティティの≪曜日≫属性の Properties ウィンドウを開きます。Parent Domain のプルダウンから先ほど作成したドメイン「曜日」を選択します。Logical Data Type が自動的に変更されるので、確認して下さい。下にある Constraint タブを開けると、Use Inherited Constraint チェックボックスが自動的に外れます。Validation プルダウンメニューからルール「曜日」を選択してください。入力が終わったら Close ボタンでウィンドウを閉じます。
論理モデルとしての作業は以上で終わりです。参照制約で継承されている【授業】エンティティの≪曜日≫属性が連動して変更されていることをご確認ください。(リポジトリがモデルの背後にあることが実感できますね。)
ちなみに物理モデルを作ってDDLを生成すると、
CREATE TYPE [曜日]
FROM CHAR(4) NULL
という型が定義され、【曜日】エンティティは、
CREATE TABLE [曜日]
(
[曜日] [曜日] NOT NULL
CONSTRAINT [曜日_952321812]
CHECK ( [曜日]=’Valid_Value_198′ OR [曜日]=’Valid_Value_197′ OR
[曜日]=’Valid_Value_196′ OR [曜日]=’Valid_Value_195′ OR
[曜日]=’Valid_Value_194′ OR [曜日]=’Valid_Value_193′ OR
[曜日]=’Valid_Value_192′ )
)
こんな風になります。
2015データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2015データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】
警視庁が定めた「証拠物件取扱要領」(以下「要領」)という文書が下記に公開されています。
http://www.keishicho.metro.tokyo.jp/sikumi/kunrei/keiji_pdf/keisou/012.pdf (リンクを自動生成しないため”:”を全角にしてあります)
この文書に従い、証拠物件の管理をするために必要なデータについてデータモデルを作成してください。
例によって【審査基準】にある「概念データモデル」レベルで回答いただきます。「一般属性の記載については任意」と書いてありますが、「要領」の末尾についている「別記様式」に現れるデータ項目について、主要なものはなるべくモデルに表現してください。(必ずしも全てのデータ項目を取り込む必要はありません。)
【応募方法】CA ErwinDataModeler Community Edition (以下CAEDMCE) を使用して作成するか、あるいはこのソフトで読み込み可能なファイル形式(上位互換性があるので、以前のバージョンの ERwin で作成したファイルも読み込み可能ということになっていますが、場合によってはファイル形式の変換をお願いすることがあります)で応募すること。作成した.erwin ファイルをメールに添付してkunisawa_naoki@yahoo.co.jp まで送付する。「件名」の最初の部分に、"【2015データモデリングコンテスト】"と記載すること。メールの「本文」に氏名(本名は必須、匿名希望の場合はその旨明記した上でハンドル名を付記)、連絡先メールアドレスを記載すること。匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される。応募は1名1件のみ。応募後の修正は締切日までは可とするが、応募後の取り消しは認めない。応募作品の著作権(引用、再配布に関する権利)はJEMUG に帰属する。JEMUG および同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】2015年11月30日
【賞】JEMUG賞、CAJ賞、J-SYS賞 各1名。審査はJEMUGメンバーにより12月(日程未定)の会議で行う。ささやかな賞品あり(お渡し方法は可能な範囲でご要望に応じます)。
【結果発表】2016年1月上旬、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【審査基準】
○しろまる概念データモデルの定義
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用
した場合など)は、その属性の Definition 欄に定義/説明を書いておくこと。IDEF1X記法については、http://www.idef.com/pdf/Idef1x.pdf を参照。
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。
===【ヒント】===
証拠物件は「押収」された後、「封印」されたり「開披」されたり「仮出し」されたり「払出し」されたりするイベントによって、いくつかの状態を遷移することになります。また証拠物件を巡って、「管理責任者」「取扱責任者」「取扱補助者」「分任保管責任者」「本署当番責任者」がそれぞれの役割を果たすことになります。証拠物件のイベントあるいは状態と、役割の関係をどう表現するか、がデータモデルの主要構造になると思います。
==========
○しろまる抽象化のレベル
CAEDMCE は25 エンティティまでしか表現できないため、この制約内でモデルを書くことが必要。そのためにはある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
○しろまる質問
質問は、kunisawa_naoki@yahoo.co.jp までメールで送付する。(間違っても警視庁に問い合わせたりしないこと。)「件名」の最初の部分に、"【2015データモデリングコンテスト】"と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。
2014データモデリングコンテストの結果
12月のJEMUG会議で応募いただいたモデルを検討した結果、
J-SYS賞:脇本 康宣 様
に決定しました。応募が少なかったため、今回は JEMUG賞、CAJ賞 は該当無しと致します。
それでは脇本さんのモデルをご覧ください。
【統計値】がいわゆる"ファクトテーブル"になりますが、スタースキーマ、スノーフレークスキーマとは全く異なるモデルになっています。むしろ統計の出典情報を記載することで、データリネージの情報を持たせようとしたモデルだといえると思います。
スノーフレークスキーマにしようと思えば、たとえば
こんな風にしていくわけですが、このようなモデルがよいのかどうか、疑問もあります。脇本さんのモデルの場合、【統計カテゴリ】の自己参照関係で集計項目の関係を表現できますが、「四半季」を「年」と「年度」の二通りに集計するといった関係は表現できません。ただ、今回の出題のような場合、そこまでやる必要があるのかということになります。
【データ源泉】という見慣れない名前のエンティティがありますがこれについてはいずれご本人に語っていただきましょう。
今回の出題は、業務目的が不明確だとか、要件が不明確だとか、出題自体に対するコメントもありましたが、情報系のデータベースは「データをきちんと整理しておいてね」程度の要件で始まるものです。「この目的変数の予測をするためにこれこれの説明変数を使って回帰分析したい」などという具体的な目的が仮にあっても、それに特化した設計など、とても怖くてできません・・・というのが実態ではないでしょうか。
==1月10日追記==
作成者の脇本さんからコメントをいただきました。
【データ源泉】については
○しろまる説明
・統計値のデータ源泉(ファイル)を格納するエンティティ○しろまるタプルイメージ
統計提供元ID :1 (→LPガス協会)
統計ID :1 (→価格)
データ源泉ID :1 (→連番)
名前 :”平成26年度LPガス CIF価格”
取得元URL :”http://www.j-lpgas.gr.jp/stat/kakaku/exden201410.xls”
ファイルスタンプ :2014年11月27日 17:10:03
取得日 :2014年12月25日 10:31:28
統計値は必ず1つのデータ源泉に紐づきます。
それを利用して、統計値のデータ源泉の確認や
データ差し替えを想定して、統計値の取得元が何かを
記録したいという考えで、このエンティティを設定しました。
ということです。
このモデル全体については、
「誰が見てもわかりやすいデータモデル」を
コンセプトにデータモデルを作成しました。ポイント
1.適度なエンティティ数
認知工学の世界では、人間の短期記憶の容量は 7±2といわれている。(ジョージ・ミラーなど)それを考慮して、エンティティ数を9以下になる ように抽象化や再帰を使ってエンティティ数を減らしています。
2.主キーは原則ナチュラルキーで
出題範囲のデータ構造がきちんと理解するために、サロゲートキーではなく、ナチュラルキーで記載。
ということです。DFDについても、ひとつのダイアグラムに含まれる適切なアクティビティの数について、デマルコが大体同じくらいの数を挙げていました。(詳しい数字は忘れました。)DFDはあらかじめ階層的に展開することが前提のダイアグラムなので、アクティビティの数をコントロールすることは比較的容易ですが、ERDも抽象化レベルとサブジェクトエリアをうまくコントロールすれば、わかりやすくなりますね。
ナチュラルキーの話は、よくご存じの方はご存知でしょうが、持ち出すと紛糾するので、私がこれ以上「燃料を補給する」のはやめておきます。(笑)
四半季(期)データを「年」と「年度」の二通りに集計する問題については、
この関係はデータモデル上表現する必要はないと考えました。(公開されているデータをそのまま格納するため。)また、「四半期」と「年」が両方存在していた場合でも別の「時系列区分」を持つ「統計項目」として扱うことができますので、この構造でデータの保持は可能と考えています。
これはまったくそのとのとおりで、「年」と「年度」を別の時系列データだと思ってそれぞれに《統計項目ID》を発行してしまえば、なんだって持ててしまいます。スタースキーマがインデックスをたくさんつけるのは、ひとつにはSQLで GROUP BY しようという意図からだと思いますが、ストレージの容量をあまり気にしなくてもよくなった状況では、このような時系列データの場合、そのためだけなら、このような仕掛けは必要なくなったのではないでしょうか?データの意味を明らかにする、というもうひとつの目的は、別の手段で達成することも可能だと思います。
FIPS 184 はどこへ行った?
IDEF1X は FIPS 184 という名前で、アメリカ政府の規格になっており、その規格書は、NIST のホームページの中の、
http://www.itl.nist.gov/fipspubs/idef1x.doc
にあったのですが、今回、データモデリングコンテストの募集要項の記事を書いていて、このリンクが切れていることに気が付きました。このURLに行こうとすると、NISTの別のページに飛んでしまいます。
http://csrc.nist.gov/publications/PubsFIPS.html
に FIPS の規格一覧があるのですが、この中にも該当する規格は見当たりません。この中にあるのは概ねセキュリティや暗号関係の規格だけのようです。
IDEF1X の規格書は、
http://www.idef.com/pdf/Idef1x.pdf
からも入手できるので、それ自体が問題ではないのですが、IDEF1X はどこか別の規格に統合されるか何かして、扱いが変わったのかもしれませんね。
どなたか、このあたりの情報をご存知の方、コメントで教えていただけませんか?
2014データモデリングコンテスト募集要項
JEMUGでは下記の要領で『2014データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。
【出題】今年は統計情報のデータモデルに関する出題です。"スタースキーマ"、"スノーフレークスキーマ"の定石通りに考えるのも「あり」ですが、今回は対象が月次あるいは四半期の「時系列データ」に限定されているので、そこを考慮していただいた回答も歓迎します。
例によって【審査基準】にある「概念データモデル」レベルで回答いただきます。「一般属性の記載については任意」と書いてありますが、今回は特に"トン"や"円"などの≪単位≫と"年次""四半期""月次""年度"などの≪時系列区分≫を属性として持たせるとすれば、どのエンティティに持たせるのか記入してください。また、属性として持たせないならば、どのように表現するのか、モデル中に注記してください。
それでは出題です。
http://www.j-lpgas.gr.jp/stat/index.html
こちらに、日本LPガス協会が作成した価格、需給、都道府県別販売量の統計があります。
http://www.meti.go.jp/statistics/tyo/seidou/result/ichiran/08_seidou.html#menu2
このページから 鉱業・石油・石炭製品 を選んで、Excel シートをダウンロードし、石油・鉱物等 のシートを開くと、液化石油ガスの生産動態統計があります。
http://www.stat.go.jp/data/kakei/2.htm#syousai
こちらの 4.詳細結果表 から
・二人以上の世帯 –> 月 –> (対象月の選択) -> 品目分類 –> 4-1表
・単身世帯 –> 四半期 –> (対象期の選択) -> <品目分類>1世帯当たり品目別支出金額 –> 9表
・総世帯 –> 四半期 –>(対象月の選択) -> <品目分類>1世帯当たり品目別支出金額 –> 10表
と辿っていくと、家計調査のプロパンガスに関する統計があります。
これらの統計を過去にさかのぼって各月・各四半期の値を記録するデータモデルを作ってください。
【応募方法】CA ErwinDataModeler Community Edition (以下CAEDMCE) を使用して作成するか、あるいはこのソフトで読み込み可能なファイル形式(上位互換性があるので、以前のバージョンの ERwin で作成したファイルも読み込み可能ということになっていますが、場合によってはファイル形式の変換をお願いすることがあります)で応募すること。作成した.erwin ファイルをメールに添付してkunisawa_naoki@yahoo.co.jp まで送付する。「件名」の最初の部分に、"【2014データモデリングコンテスト】"と記載すること。メールの「本文」に氏名(本名は必須、匿名希望の場合はその旨明記した上でハンドル名を付記)、連絡先メールアドレスを記載すること。匿名希望の場合もJEMUGメンバー内では事務手続き上本名・メールアドレスが開示される。応募は1名1件のみ。応募後の修正は締切日までは可とするが、応募後の取り消しは認めない。応募作品の著作権(引用、再配布に関する権利)はJEMUG に帰属する。JEMUG および同会の会員は各種媒体上で応募者に断りなく応募作品を公開・引用し、コメントする権利を保有する。
【締切】2014年11月20日
【賞】JEMUG賞、CAJ賞、J-SYS賞 各1名。審査はJEMUGメンバーにより12月(日程未定)の会議で行う。ささやかな賞品あり(お渡し方法は可能な範囲でご要望に応じます)。
【結果発表】2015年1月31日、https://jemugguestroom.wordpress.com/ サイト上で発表。匿名希望の方はハンドル名で発表。
【審査基準】
○しろまる概念データモデルの定義
このコンテストでいう概念データモデルとは、
1.エンティティおよびエンティティ名
2.主キー(一般属性の記載については任意であるが、明らかに間違っている場合は審査の対象とする)
3.リレーション(関係)およびそれに伴う外部キー(多対多の関係は不可)
4.リレーションの種別(従属関係/参照関係)およびカーディナリティ/オプショナリティ
5.シノニム(ロール名)が発生する場合のリレーション名(それ以外のリレーション名は任意)
が明記されている、IDEF1X記法のダイアグラムである。主キーに関するデータ型、データ長、ドメインの記述は必須ではない。分析対象に直接現れない主キー/外部キーを用いる場合(例えばサロゲートキーを使用した場合など)は、その属性の Definition 欄に定義/説明を書いておくこと。IDEF1X記法については、http://www.idef.com/pdf/Idef1x.pdf を参照。
○しろまるモデルの表現
モデルが読みやすく表現されているかどうかということは審査の対象になる。特に、エンティティの種別によって配置を決めるなどの制約は設けないが、リレーションを表す線が関係ないエンティティの下をくぐるなどの配慮を欠く表現は避けること。
○しろまる仕様の理解
ある程度の「仕様理解の差」が発生することが考えられるが、その妥当性については審査の場で判断する。
[ヒント]
- たとえば日本LPガス協会の 『LPガス都道府県別販売量』の用途合計・都道府県合計・プロパン/ブタン合計の値と、『需給月報』販売計・数量(トン)・プロパン/ブタン合計の値は一致しています。このような合計‐内訳の関係をモデルで表現できるとよいのですが、端数処理などで合計値が合わない場合もあります。このような関係をすべて導出項目であるとしてモデルから排除してしまうのも、情報系のモデルとしては窮屈だと思うのですが・・・
○しろまる抽象化のレベル
CAEDMCE は25 エンティティまでしか表現できないため、この制約内でモデルを書くことが必要。そのためにはある程度、エンティティの抽象度を上げていく(たとえば、「係」「課」「部」「本部」というエンティティを用いずに「組織」エンティティと自己参照リレーションで表現するという場合のように)必要があるが、抽象度が高ければよいというものではなく、25エンティティの制約の中で可能な限りわかりやすいモデルを志向すること。
○しろまる質問
質問は、kunisawa_naoki@yahoo.co.jp までメールで送付する。「件名」の最初の部分に、"【2014データモデリングコンテスト】"と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。
データモデルにおける”ユニフィケーション”
外部キーはすべからくリレーション(参照制約)によって発生し、全ての外部キーは対応するリレーションを一つだけ持つ、というのが普通なのですが、時にそうではないモデルに遭遇する場合があります。
ごく普通にある【組織】【社員】【所属】のモデルに【管理】というエンティティを付け加えたモデルを考えてみましょう。【社員】は【組織】にある期間【所属】し、その中で「管理する」「管理される」という有向グラフパターンで【管理】が設定されます。
image
ここまではごく普通のモデルで、外部キーはそれぞれ対応するリレーションを一つ持っています。
ここに、《管理する所属の組織ID》は《管理される所属の組織ID》と同じでなければならない、という制約を加えてみましょう。先程のモデルでは、総務部の【社員】を経理部の管理者が【管理】するというデータも受け入れてしまいますので、そういう"不正な"データを参照制約で排除しようというわけです。
【管理】の外部キー《組織ID》は「管理する」「管理される」という2つのリレーションで共有されています。これを"ユニフィケーション"と呼ぶのだそうです。
【管理】は有向グラフパターンではなく、木構造で表現すべき、というご指摘もごもっともですが、ユニフィケーションという現象は、木構造でも同じく発生します。この場合は従属関係ではなく参照関係になるので、外部キー《親組織ID》が原則的には一般属性になりますが、ユニフィケーションすると主キーの《組織ID》に《親組織ID》が吸収されてしまいます。
こうしておけば、総務部の【社員】を経理部の管理者が【管理】するというケースは、モデル上で排除できることになりますが、こういうテクニックを使うべきではない、という議論もあり、皆様のご意見をうかがいたい次第。