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

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

Sat, 15 Dec 2018 19:12:21 +0000 コメントをどうぞ

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

Sun, 11 Mar 2018 10:56:42 +0000 コメントをどうぞ

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

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

1

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

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

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

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

以上

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

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

Tue, 27 Feb 2018 12:26:24 +0000 コメントをどうぞ

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

JEMUG賞 Sさん

FETEC賞 游悠さん

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

SさんのER図は

S

 

游悠さんのER図は

1

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

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

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

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

ERWIN DATA MODELER [FREE TRIAL]

Sat, 03 Jun 2017 15:33:29 +0000 コメントをどうぞ

erwin の community edition はなくなりましたが、試用版がWebで公開されています。FETEC の西嶋さんに教えていただきましたので、お伝えします。

http://erwin.com/resources/software-trials/

を開いてみてください。

image

erwin Data Modeler の下にある TRY NOW のボタンをクリックしてください。

image

右のほうにあるフォームの必要項目を入力して下さい。ちなみにメールアドレスに関しては、フリーのアドレスはダメなようです。yahoo のメールは使えませんでした。入力が終わったら、フォームの下の方にある Download Trial のボタンを押してください。

image

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 を起動すると、

image

というダイアログが出てきますので、Use Local licence を選択して、Install License File ボタンをクリックして下さい。開いた画面から、先ほどダウンロードした License File を選択すると、erwin が使えるようになります。

現在インストールすると、r9.7 がインストールされます。

カテゴリー:未分類

游悠さんの自作解説

Sat, 31 Dec 2016 13:09:57 +0000 コメントをどうぞ

游悠

画像をクリックすると、ER図の詳細が確認できます。

 

モデル作成のポイントについての解説 Written by 游悠 (2016.12.13)

今回授賞したデータモデル作成時の考慮ポイントについて簡単に説明します。利用したモデル作成ツールには、ERWinのコミニュティエデションを使用しているため、25エンティティ以内でコンテスト応募ERモデルを作成するという条件があることも考慮条件でした。

 

  1. 基本エンティティの取扱いについて
  2. まず、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はノードエンティティへの属性項目として記述し、

    モデル全体エンティティ数制限の関係からモデルエンティティとしては表現せず、コード値についてコメント内に補足をするに止めました。

     

  3. E、I、Oエンティティについて
  4. これらのエンティティ内データには、企業名と個人名が混在するため、これらを区別する意図としてパーティ区分エンティティを切り出しました。これは特にEのcompany_type項目の位置付けに注目させる表現として役立つと考えています。Eについては、jurisdiction(租税回避地)がモデル表現理解の上で意味を持つという考え方から、租税回避地エンティティとして見える形で表しています。

    また、Eエンティティの日本語名称は、「エンティティアカウント」と名称表示しました。その理由として、エンティティの属する各レコード(ロウ)の開設日などの項目を設けた視点を取り入れ、取引口座という解釈を与えるためであることを付記します。

     

  5. Aエンティティについて
  6. 住所項目はIとEには項目として存在し、Oには存在しません。そしてこのAが別途のエンティティとして元のDBで扱われています。そしてこれに係わる関係性がリレーションとして使われています。このため、Aエンティティの持つ住所情報は、DB作成者のデータ利用の意図を表すと考え、IとEでのaddress項目はレコードに関する「住所地表記」として項目命名し、またAエンティティは「住所地情報」として名称付けを行い、名称によりそれぞれの位置付けを区別するモデル表現にしました。

     

  7. Edgesエンティティと関係性(リレーション)の表現について
  8. パナマ文書情報がグラフ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データモデリングコンテスト結果発表

    Sat, 31 Dec 2016 11:58:48 +0000 コメントをどうぞ

    データモデリングコンテストに多数応募いただきありがとうございました。12月9日のJEMUG会議で、厳正な審査の結果、受賞者を次のように決定しました。

    JEMUG賞 (匿名希望)游悠さん
    FETEC賞 (匿名希望)Sさん

    游悠さん、Sさんおめでとうございます。すでに、受賞された方には、結果をお知らせしています。

    游悠さんのモデル、

    游悠

    画像をクリックすると、ER図の詳細が確認できます。

     

    Sさんのモデル

    image

    画像をクリックすると、ER図の詳細が確認できます。

     

    游悠さんは、【Node(ノード)】【Edges】【Relation Type】、Sさんは【Nodes】【All_edges】【Rel_types】、この部分で同じ構造があります。これは有向グラフパターンの応用で、出題者が「グラフデータベース「Neo4j」で実装されています。」と書いてあったことが手がかりになったと思います。

    【Node(ノード)】あるいは【Nodes】の下に、4つのサブタイプが来ることも共通しています。ただ、惜しくも受賞は逃されましたが、一人の方が、【Address】を独立したエンティティではなくその他のサブタイプの属性とされた方がいらっしゃいました。もし「その他の属性」がそれぞれ一つだけの【Address】しか持たないのであればそういう選択肢もあるわけですが、グラフデータベースに実装する場合の考慮点を示唆した考え方だと思います。

    游悠さんの「自作解説」を引き続きお届けします。