JEMUGの入会案内をご覧ください。

2019データモデリングコンテスト結果発表

金, 06 3月 2020 22:30:35 +0900 コメントを残す

多数のご応募ありがとうございます。コンテスト開始以来、最多数の応募になりました。また、JEMUG会員以外の方からも応募いただき、記念すべき年になりました。

コロナウィルスの影響などで、会議の開催ができず、発表が遅くなったことをお詫び申し上げます。票が割れたのですが審査の結果、

JEMUG賞
Georgiamoonさん

FETEC賞
游悠さん

となりました。おめでとうございます。

作成していただいたモデルは、それぞれ下記のとおりです。

Georgiamoonさん

image

 

游悠さん

image

いずれ、作者の自作解説をご紹介する機会があると思いますが、出題者として意外だったのは、複数の方が、「伝票」や「送り状」に現れる項目を分析しておられたことです。評価の際にも、それに該当するエンティティがあるかということを評価項目に含めていらっしゃる方が複数おられました。

出題の「追跡サービスの画面」に現れる項目の中には、伝票に記載されている項目もありますが、伝票の中には荷物のサイズなど、今回の出題の対象外の項目もたくさんあります。書いても間違いというわけではありませんが、この部分は今回のコンテストの主題ではありません。

出題者は、荷物が保管と輸送(集荷や配達を含む)という2つの状態を交互に取りながら、目的地に到達する、ということをどのように表現するかがポイントだと思っていました。帳票分析は、分析の入り口としては、有効な場合もありますが、今回は帳票になっていない(公開されていない帳票としては存在するはずの)データの領域が多かったと思います。

カテゴリー:データモデル

2019データモデリングコンテスト募集要項

金, 13 12月 2019 06:33:28 +0900 1件のコメント

JEMUGでは下記の要領で『2019データモデリングコンテスト』を開催します。JEMUGメンバーに限らず、どなたでも応募できますので関心のある方はふるってご応募ください。

【出題】

宅配便の追跡をするサービスに関するデータモデルを25エンティティ以内で作成してください。以下で示す各社のサービスを共通に表現できるモデルにしてください。なお、概念データモデルについては、後述の「概念データモデルの定義」を参照のこと(いろいろな表記法を使われていると思いますが、このコンテストでは IDEF1X で書いてください)。

 

—————————————————————————————————

 

宅配便が受け付けられると、A社の場合、検索の結果このように表示されます。

image

 

”11/13 19:00-21:00” は、着日・配達時間を指定して発送したので、その日付のことです(多分)。

その後、検索する都度、輸送の経過が以下のように表示されます。(伝票番号等のヘッダー行の表示は省略。明細行の一番右の列は、トランザクション番号のようなものではないかと思われます。問い合わせの時に使用するのでしょう。)

image

—————————————————————————————————

image

—————————————————————————————————

image

—————————————————————————————————

image

—————————————————————————————————

image

—————————————————————————————————

image

ちなみに、同様なサービスを提供している他社の追跡サービスは、こんな表示が出てきます。

【B社の例】

image

【C社の例】

image

 

【応募方法】

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データモデリングコンテスト結果発表

水, 20 2月 2019 03:58:48 +0900 コメントを残す

コンテストに応募いただき、まことにありがとうございました。

18日開催されたJEMUG会議において、審査いたしました結果、

FETEC賞 游悠さん
敢闘賞 髙橋さん

の受賞が決まりました。おめでとうございます。今回はJEMUG賞は該当作なしとなりました。

出題者のSさんから、解答例をいただきましたので、紹介します。

image

今回の出題は、いわゆる「マスター」がほとんどなく「トランザクション」だけで構成されているといってもよい、一風変わったモデルでした。(マスターとは何か、という問題には深入りしないでおきます。)

FETEC賞 游悠さんのモデルは、

image

敢闘賞 髙橋さんのモデルは、

image

です。

ツリー(木)構造を、Sさんは自己参照(【ブロックヘッダー】のところ)、游悠さんはサブタイプ(【マークルツリー】とそのサブタイプのところ)、高橋さんは有向グラフのパターン(【ブロック】【ブロック_再帰表】のところ)、で表現しています。

カテゴリー:データモデル タグ:

2018データモデリングコンテスト募集要項

土, 15 12月 2018 19:12:21 +0900 コメントを残す

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賞自作解説

日, 11 3月 2018 10:56:42 +0900 コメントを残す

恒例によりまして、受賞者の方には自作解説をお願いしました。

游悠さん自作解説をお届けします。

1

今回の課題は提示された資料の表している概念をデータモデルで表記するとういうものでした。これは内容をどの視点で捉えるかにより、作成するモデルに違いの出る結果となったようです。応募者の多くは電子殻表のマスタを表現しようとしましたが、当方はある元素の電子状態がどのようなものかを現実世界として捉え、いわばボトムアップで示すようなモデルを作ろうと考えた点で独自の表現になったように思えます。この視点の違いを、もう一方の受賞者のデータモデルと比較して読むと面白いのではないでしょうか。

このモデルは主に3つの部分で成ります。一つはモデル図の右上の白色で表現する箇所。ここは元素周期表と元素の関係を表現します。元素という性質は周期表の「周期」と「族」の2元表で多くは配置されますが、ランタノイドおよびアクチノイドに属する元素はこの規則に単純に当てはまりません。それを分類可能としたのが「元素群カテゴリ」です。そして周期表に属する元素の性質と対応するものとして元素実体を示しています。この実体は原子核と電子から組合わされますが、今回の課題資料の範囲では元素同位体は説明に入っておらず、単に「原子核実体」エンティティで表すだけにしました。

一方の電子群の実体を表現するために二番目の部分があります。それが、オレンジとピンク色で示される「電子実体」群です。これらの電子実体群のそれぞれがどういう位置付けなのかを見ることができるようにした表現です。これにより、最外殻電子(主に自由電子と呼ばれるもの)を個別に表現でき、またイオン化した個別の元素状態を知ることができるようになります。

モデル図の三番目が左半分にある青、緑色の部分です。ここは、電子殻軌道のフォームを表しており、元素がどのフォームの軌道に結びついて電子実体を収容し得るのかを対応付けして表現できます。元素固有の取り得る電子殻軌道の形との関係を付けるために「電子配置」エンティティがあります。そして電子実体群と、取り得る電子殻軌道のどこにそれぞれの電子が配置されているかという現在の状態として表せるようにしています。これにより「動的に」具体的個別元素と電子配置の取っている姿を示せるというものです。

以上

カテゴリー:データモデル タグ:

2017データモデリングコンテスト結果発表

火, 27 2月 2018 12:26:24 +0900 コメントを残す

コンテストに応募いただき、まことにありがとうございました。26日開催されたJEMUG会議において、審査いたしました結果、

JEMUG賞 Sさん

FETEC賞 游悠さん

の受賞が決まりました。おめでとうございます。

SさんのER図は

S

 

游悠さんのER図は

1

カテゴリー:データモデル タグ:

2017データモデリングコンテスト募集要項

水, 20 12月 2017 12:54:31 +0900 2件のコメント

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データモデリングコンテスト】”と記載すること。質問の内容によっては回答しない場合もある。審査にかかわるような重要な質問については、公平を期すために、このブログ記事に対するコメントの形で掲載する。

カテゴリー:データモデル タグ: