ドジャース, 大谷翔平, イチロー, T字形ER手法, 組織管理システム, チーム, メンバー, 選手

システム開発＜基本編＞サンプルER図の解析

前回の記事で、ER図の解析方法について記載しましたが、今回は、間違いやすいER図について、

問題提起をして、解説して行きたいと思います。

サンプルER図（問題提起）
1. サンプルER図
2. 検証
T字形ER図（問題解決）
1. T字形ER図
2. 検証
まとめ

サンプルER図（問題提起）

サンプルER図

下記のサンプルER図を見て下さい。

これは、スポーツなどでチームやメンバーを管理する「組織管理システム」のER図の一部です。

今回も全体のER図が描かれていないので、少し難しいかもしれませんが、

【チーム（エンティティ：teams）】
【役割（エンティティ：roles）】…選手、監督、コーチ、オーナー、通訳、ドクター　等
【メンバー（エンティティ：members）】
【契約（エンティティ：contracts）】
【通貨（エンティティ：currencies】…日本円、ドル、ユーロ、韓国ウォン、中国元　等

と、「リレーションシップ（Relationship：関連）」になります。

利用ツール：A5:SQL Mk-2

検証

こちらも、開発現場で、ついついやりがちなケースかと思います。

どの部分が問題かと言うと、前回の記事と似ていて

【メンバー（エンティティ：members）】

が問題になります。

別の記事でも記載しましたが、上記のサンプルER図でも、プログラマーの立場で、

何も疑問に思わないまま、管理画面を開発する事は可能だと思います。

また、お客様の性質に寄って、「このままで問題が無い」「責任は、お客様が持つ」と

判断されたら、そのまま突っ走るのも、賢明なのかもしれません。

しかし、シニアエンジニアや若手エンジニアの方々が、様々な現場から指名されるような逸材を

目指すのでしたら、是非、疑問を感じて、データベースやコード体系、アトリビュートと

向き合って検証・解析して、問題を解決してもらえればと思います。

では、実際に検証してみます。

先ずは、サンプルER図について。

【メンバー（リソース：members）】を見る限り、メンバーがチームに依存しています。
現役のチームとメンバーを管理するだけの「組織管理システム」であれば、特に問題有りません。
過去のメンバーの履歴や、将来的にチームと契約（ドラフト）しそうな若手メンバー、海外から参入するメンバーの事前登録が必要かもしれませんが、このままでは出来ません。
メジャーリーグ・ベースボール・ゲームやメジャーリーグ・ベースボール・グッズを売るサイトで、「組織管理システム」を構築すると想定します。
大谷翔平選手は、過去にエンジェルスに在籍していて、現在はドジャースに在籍しています。もしかしたら、将来的に別チームと契約するかもしれません。
【メンバー（リソース：members）】に、大谷翔平選手をエンジェルスとドジャースの両方を登録すると、大谷翔平選手のメンバー名（固有名詞）が重複登録となり、冗長化してしまいます。
「データベース（テーブル）構成」は、【正規化】することが基本概念と伝えて来ましたが、【メンバー（リソース：members）】だと、【正規化】から反してしまいます。
大谷翔平さん（個人）はチームに依存せず、個人に依存するメンバー名（固有名詞）や国籍の情報は、別テーブル（エンティティ）で管理すべきです。

T字形ER図（問題解決）

T字形ER図

T字形ER図で解析すると、下記のER図になります。

【チーム（リソース：teams）】
【役割（リソース：roles）】…選手、監督、コーチ、オーナー、通訳、ドクター　等
【チーム.役割（対照表：team_roles）】
【メンバー（リソース：members）】
【チーム.役割.メンバー（対照表：team_role_members）】
【契約（イベント：contracts）】
【通貨（リソース：currencies】…日本円、ドル、ユーロ、韓国ウォン、中国元　等

と、「リレーションシップ（Relationship：関連）」になります。

＜論理名＞

＜物理名＞

利用ツール：MODEL-builder version2

検証

では、T字形ER図で検証してみます。

【メンバー（リソース：members）】のアトリビュートには、他のエンティティに依存しないメンバー名（固有名詞）や国籍がが記載されています。サンプルER図のように、【チーム.役割.メンバー（対照表：team_role_members）】のアトリビュートに記載すると、【正規化】から反してしまいます。
【メンバー（リソース：members）】が独立して作成されているので、将来的にチームと契約（ドラフト）しそうな若手メンバーや海外から参入するメンバーの事前登録が出来ます。
【チーム.役割.メンバー（対照表：team_role_members）】のアトリビュートには、「通称名（ニックネーム）」「背番号」「ロッカー番号」とチームに依存する内容が記載されています。
「通称名（ニックネーム）」ですが、「イチロー」のように、どのチームに行っても変わらない場合は、　【メンバー（リソース：members）】のアトリビュートに記載しても良いかもしれませんが、汎用的に分析して、例えばマリナーズでは「イチロー」、ヤンキースでは「スモールベースボール」、マリーンズでは「レーザービーム」など、別の呼び方が有るように考えた方が良いと思います。「通称名（ニックネーム）」が重複したからと言っても、固有名詞では無いので、【正規化】から反しているとは思えません。
「背番号」ですが、契約に依存する場合は、【契約（イベント：contracts）】のアトリビュートに記載するのも良いかもしれませんが、新たに参入して来たルーキーに「背番号」を譲る事も有るので、【チーム.役割.メンバー（対照表：team_role_members）】のアトリビュートに記載しています。
同じ「チーム」で「背番号」が頻繁に変わる場合、歴史が必要になる「組織管理システム」であれば、【チーム.役割.メンバー（対照表：team_role_members）】とは別のエンティティ（テーブル）を作って、管理する必要が有ります。例えば、グッズ販売をするビジネスは、「背番号」の歴史がある別のエンティティ（テーブル）が必要だと思います。
「背番号」は世界的（一般的）に見て数値なので、データ形式は「数値（INTまたはNumber）型」として、利用するRDBMSに合わせて下さい。
お客様の意向で、独自の「組織管理システム」を開発する際、「背番号」をローマ数字（Ⅰ、Ⅱ、Ⅲ…）や漢字、ローマ字等で表現する場合には、データ形式は「文字列（VARCHAR）型」で設定すると良いと思います。
「ロッカー番号」ですが、複数のロッカーを所有する場合は、【チーム.役割.メンバー（対照表：team_role_members）】とは別のエンティティ（テーブル）を作って、管理する必要が有ります。今回は、「1つのロッカーを所有するもの」として設定しました。
「ロッカー番号」は、「No.12」「D-3」「008-2」…等、汎用的に考えてデータ形式は「文字列（VARCHAR）型」で設定しています。