ハンドノート t字形erモデル　セミナー資料　(author; s.toriyabe systems design...

ハンドノート

データモデリング参考資料

平成27年2月11日作成

システムズ･デザイン株式会社

鳥谷部聡

はじめに

このハンドノートは、筆者が個人的にDOAの勉強をする中で習得したこと、考察したことを記述したもので

す。したがって、本書に記載の方法論提唱者が公式に認めたものではないことをまず表明します。

殊にT字形ER手法については、佐藤正美氏が出版した過去の書籍、また、筆者が氏から指導を受けた当時の

知識をもとに記述したもので、現在、佐藤師が提唱しているTMと明らかに違う部分があることを理解の上で

ページをめくっていただきたい。

なぜ、古い手法に固執するかとの問いに「わかり易いからだよ」と応えたい。筆者がDOAを学び始めのきっ

かけをつくってくれた当時のボスが佐藤師の書籍を紹介してくれた時『なせ、佐藤さんのデータ中心指向な

のですか？』の問いに「いろいろ見た中で、この本が一番わかり易い」と語ってくれたことを思い出す。T字

形ER手法が多くの読者の目にとまったのは、わかり易いからだろうと、小生は勝手に解釈している。昨今、

当時と違う反応を示す人が少なくないことに驚きを禁じえない。

最後に、本資料を作成するに当たり、そのきっかけをつくってくれた佐野初夫氏と盟友渡辺幸三氏に衷心か

ら謝辞を述べたい。

お二人とも、いつもありがとう。

そして、師匠として尊敬する佐藤正美氏に改めて御礼申し上げます。

師匠。常に温かく見守っていただき、ありがとうございます。

平成27年2月11日

筆者

2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 2

業務階層図における『役割と種類』


与信管理【新規】限度設定

【継続】評価見直

与信管理

契約（受注）限度確認

契約内容検証

売上計上売上計上

請求請求手続

Superset Subset

Superset Subset

取引先に対する信用限度の管理を行う

新規の取引先に対し財務情報等より取引限度額や取引条件を設定する

継続取引先に対し最新の財務情報等より取引限度額や取引条件の見直しを行う

業務階層図はHeader/Details構造になっており、役割と種類の関係で表現することができる

業務の上位概念を共通の性質、下位をその具体例を示すものとして捉えると、Superset / Subsetの関係として定義することができる（内包/外延）

出荷事実を確認し売上伝票を計上する

売買契約を締結する

Superset Subset

業務階層とAP機能の関係


業務の上位概念

業務の具体例

業務の具体例の詳細

AP機能

AP機能の種類

AP機能の具体例の詳細

表記方式

T字形ERモデル


表記方式


T字形ER手法ではHeader/Detailsの構造を、Superset/Subsetの表記法で表す

Superset

Header

Details

表記方式


Headerは単票形式、Detailsは一覧形式

Superset

Header

Details

表記方式


Superset

Subset

Subset

スーパーセット/ サブセット

Superset 区分

区分

Subset

Subset

相違のスーパーセット / サブセット

同意のスーパーセット / サブセット

表記方式


ENTITY RECURSIVE

再帰表

表記方式


RESOURCE RESOURCE

QUASI-EVENT

対照表

表記方式


EVENT EVENT

MAPPING LIST

対応表

表記方式


RESOURCE VIRTUAL ENTITY

EVENT VIRTUAL ENTITY

仮想エンティティ

表記方式


RESOURCE ENTITY ROLE

EVENT ENTITY ROLE

エンティティ・ロール

表記方式


0または1 １以上

※ リレーションシップ上に表記

カージナリティ

表記方式


エンティティ名称

個体指示子

リユース_1(R)

リユース_2(R)

・・・リユース_n(R)

性質_1

性質_2

・・・性質_n

エンティ

ティの種類

記表位置

表記方式


与信審査

与信審査申請No.

顧客No.(R)

性質_1

性質_2

・・・性質_n

E

E: EVENT

イベント系エンティティ

R: RESOURCE

リソース系エンティティ

VE: VURTUAL ENTITY

仮想エンティティ

ER: ENTITY ROLE

エンティティ･ロール

TS: QUASI ENTITY

対照表

ML: MAPPING LIST

対応表

エンティティの記標

表記方式


エンティティ名称

個体指示子

リユース_1(R)

リユース_2(R)

・・・リユース_n(R)

性質_1

性質_2

・・・性質_n

エンティ

ティの種類

個体指示子観察対象であるエンティティに包含されるデータ項目のうち、識別子に当たるもの

リユース(R)

他のエンティティの個体指示子に当たります。リレーションシップによって発生します

個体指示子とリユース

表記方式


与信審査

与信審査申請No.

顧客No.(R)

性質_1

性質_2

・・・性質_n

E 性質観察対象であるエンティティに包含されるデータ項目に当たるもの日付テキスト数値計算値ブーリアンバイナリーイメージ他の性質の値のコ

ピー

アトリビュート

対照表の表記例


県コード. 県名市コード. 市_名称区コード. 区_名称

県市区

県・市・区・対照表

県コード(R)

市コード(R)

区コード(R)

都道府県名(d)

市_名称(d)

区_名称(d)

県・市・対照表

県コード(R)

市コード(R)

市・区・対照表

市コード(R)

区コード(R)

R R R

TS TS

TS

対照表の表記例



県市区

県・市・区・対照表

県コード(R)

市コード(R)

区コード(R)

都道府県名(d)

市_名称(d)

区_名称(d)


県コード(R)

市コード(R)

R R R

TS

TS

商談DTL

エンティティの表記例


商談

商談HDR

商談No.

H_Rev.No.

リードNo.(R)

商談日予算

案件化予定日

要望総額（D)

対応時間

商談明細No

D_Rev.No...

商談No.(R)

H_revNo.(R)

品番(R)

商談詳細メモ

要望金額要望数量希望納期

リード

リードNo. 氏名職位

所属部署(d)

商談品目

品番商談許可期日

品名説明

提供価格決定方式メモ

R

R

E

E

イベント系エンティティの表記ルール

1. リソース系エンティティの個体指示子をリレーションシップによりリユースとして継受する

2. イベント系エンティティ→イベント系エンティティのリレーションシップにより継受側が元側の個体指示子を継受する

3. ただし、リレーションシップの元側のカージナリティが ”n”の場合、対応表を経由する


リソース系エンティティの表記ルール

1. イベント系エンティティではないエンティティ

個体指示子を持つイベント系エンティティ以外のエンティティをリソース系エンティティという

2. リソース系エンティティ間のリレーションシップでは、対照表が生じるカージナリティに影響されない


描くヒント

T字形ERモデル


エンティティを見つけるためのコツ！

コード体系に注目し、エンティティをあるままに取り出す

例えば、・・・ある会社の顧客管理体系をみると・・・

コード (code) 番号ナンバー (Num.) に注目カスタマーコード（10桁）

1000290000

4120110000

9090130000

当然、このコードは”意味あり”だと一目でわかる

そこで、さらにコードを分析する。


店舗取引先

複合コードの中に潜むエンティティ


100029 0000 取引先コード店舗連番

取引先コード. 取引先名称取引先所在地

店舗連番

カスタマーコード

R R

取引先・カスタマー・対照表カスタマー

取引先コード(R)

店舗連番(R)

店舗名店舗所在地連絡先

TS

コードの種類と役割

役割を見る

1002900000 一次取引先

4120110000 代理店取引先

9090130000 サンプル出荷用

種類を見る

1002900000 本店

1002900001 青山店

1002900003 渋谷店

1002900004 心斎橋店

4120110000 本店

9090130000 サンプル出荷用（営業1部）

9090140000 サンプル出荷用（大阪営業部）

■ 下4桁”0000”は必ず本店

構成を見る

###### + #### ■ 6桁（取引先企業）+ 4桁（店舗連番）で構成


属性について

1. エンティティの『性質』という

2. テーブルの列（カラム）に当たる単項

3. プロパティ、アトリビュートと言い換えることができる

【ここからは読まなくていいよ】

※ ひとつの対象を知るには、たしかにその外的な特徴を知る必要はない、だがその内的特徴すべてを知らねばならぬ（引用：『論考』2-01231 L・ウィトゲンシュタイン著藤本隆志/坂井秀寿訳法政大学出版局）。

※ モデルを言語体系の一種と考えると、モデルは観察者が見た対象を像と見做して言語的アプローチで表現したものと言える。こう考えると、モデルの意味とはモデルによって言語表現された対象の内容記述に他ならない。

※ 内容主義的意味論にとって重要な概念は、“真理”と“現実との一致”だ。モデルの真偽はモデルの意義と現実への一致･不一致に尽きる。形式主義を貫いた考え方だ。

※ ところが、内容主義的意味論は、先に例示した指示詞（私 / 今 / ここ…）が混じった言語-

文、別の言い方をすれば叙述文以外の言語-文で、その対象あるいは事実の総体である世界を説明できない。

※ だから、言語-文の意義と現実への一致・不一致をその説明とする形式主義ではなく、対象

の役割を説明することを求める機能主義的意味論のほうが、より多くの対象の意味概念を捉えることができる。

※ 在庫推移監視法・・・いつでも『今』の在庫関係を計算する・・・これは秀逸


性質

『時間』タイムスタンプ契約日

『数値』個数単価

『種類』商品など

『個体』個体No. 被保険者番号（ユニーク検証）

『状態』商談の段階

『区分』グルーピング・タグ期

『２値』新旧真偽

『内容』記述文

『計算値』累計合計（表示のみ/DB保存）

『状態値』在庫有り高

『複製』送付状住所

その他に映像データ、URLなどもある・・・


ポイントをまとめると

※ コード体系（番号，No.，ID，CODE）の中から最小（Minimal）を見つけ

てエンティティになるかを検討する

※ T字形ER手法は、言語の記号化とその使用（表記）に形式主義を貫いてお

り、数理論理学の隷下にある・・・・・・『隷下』は言い過ぎか・・・

※ すべてのエンティティは、その役割 (role) を観察することはできるが、ビ

ジネス上の意味があるとは限らない

※ アトリビュートは、名称、日付、数値、計算値、コメント、住所など、

コード体系が持つようなルールは存在せず、その規則は一般的かつ社会的

共通認識の範疇にある。但し、コード体系に拘り過ぎると本質を見失うこともあるので注意！

例えば、電話番号を分解することはできるが、固定電話の市外局番・市内局番・顧客番号の体系が

携帯電話番号には適用できない。携帯電話番号の場合、キャリア識別番号（5桁）＋個別番号（6桁）

となる。ここに拘りを持って分析しても貧果に陥る可能性が高い。『連絡先』である電話番号は、通

話料あるいは可搬性の視点から固定電話と携帯電話を識別できる上3桁 070, 080, 090 の判別ができれば

よい。


データをより深く見る

T字形ERモデル


データモデルで取り扱うデータには

1. 事実になる可能性のあるデータそのデータが業務の事実として成立･存在の可能性があるケース

単価×数量を顧客に提示

ある瞬間の在庫推移・数量

計算値は、ある時点で、参考・照会の目的で計算し表示するのみでデータベースに記録しないケースがある。

2. 被参照データある業務において、すでに存在するデータを参照･利用するケース

顧客情報の一部である顧客名、所在地を請求に利用する

地図に現在位置を表示する

すでに請求済みで未回収の債権金額を督促する

計算値のみならず、既存のデータを参照･利用するケースは多い。

3. 事実として確認済みのデータ業務の事実に対応し、証跡として記録･保存するケース

例えば顧客に提示する目的で作成された見積書に記載された金額は、その見積書の発行および顧客への提示という事実に対応する。このようなケースでは、データはデータベースに記録される

見積書に記載の、提示金額。例えば、単価、数量、合計、値引き額

一般的なデータ。但し、特殊な役割を担うものもあり、また種類は空の星、海の真砂の如し。


計算値問題


価格交渉は、ビジネスで最も重要な業務となる。売り手は利益の確保、買い手は徹底的なコストダウン。双方が主張をぶつけ合い妥当な着地点を模索する。商談段階では、先ず買い手から調達仕様の提示があり、売り手はその要求に見合う提案を行う。提案が買い手にとって魅力的であり、また売り手にとって売値がしっかりと利益を確保できる妥当な線上に落ち着けば、商談が成立し案件化に至る。ところで、売り手は商品に単価を設定しており、確保すべき利益水準を腹の内に秘める。例えば、単価と数量を掛け合わせて、調達価格が決まると、交渉段階で売り手側は正札をいったん提示し、値引き交渉に応じるだろう。ネゴシロを踏まえながら、交渉は進む。一方、システムは単価×数量で顧客への提示金額を画面に表示する。商品マスタと価格マスタがあれば、造作もないことだ。しかし、ビジネスはそれほど簡単なものではない。コンピュータは交渉に応じることができないからだ。単純計算の金額が通用することはまずない。そこで、・・・・

単価×数量商品を選択

数量を入力

金額を表示提示額を記録

価格交渉見積書

計算値問題（続き）


単価×数量商品を選択

数量を入力

金額を表示提示額を記録

価格交渉見積書

タッチポイント

単価×数量で算出した金額を上書き保存

単価×数量で算出した金額とは別に提示額を記録

金額（Ｄ）

初期表示：単価×数量

手入力をＤＢに書き込む

金額（ｄ）

初期表示：単価×数量

提示額

手入力をＤＢに書き込む

処理

一意性検証の検討


情報漏えい事故が世間を騒がすと、その度にセキュリティは一時的にせよ厳しくなる。例えば社員証が入館セキュリティのカードキーをかねている場合であっても、ソーシャル･エンジニアリングの問題は残る。入退室時、セキュリティゲートに社員証を翳さないと出入りができないようなセキュリティゲートの運用をしていたとしても、カードキーの認証が社員コードの場合、問題は解決しない。複数のカードキーを持つことができるからだ。そこで、入退室に有効なカードキーは必ず1枚しかない状態を作らなければならない。つまり、社員証は一人一枚の状態にしなければ、セキュリティ上有効ではないのだ。これをモデルにすると、常識と思っていたものと違う景色が見えてくる。

カードキー社員

社員コード. 氏名生年月日住所メールアドレス

製造番号

R R

社員・カードキー･対照表

社員コード(R)

製造番号(R)

有効化年月日有効/無効区分無効化年月日

TS

有効なものは１個の社員コードにカードキー1枚

カージナリティが n:m になる理由は、社員が複数枚カードキーを手にすることが考えられるため。

一意性の検討


リソースには『タイプ』と『オカレンス』がある。タイプは、『ある種類の一群において１つを識別する』ためのもので、その代表例が『商品』である。商品にも個体は存在するが、品番が同じであればそれらは同一の形、性能、名称、価格になると想定できる。一方、オカレンスは個体を識別する。同じ品番であっても世界に１つだけの存在を識別するための番号が付けられる。あなたの存在をざっくりと識別するのであれば姓名でもいいが、同姓同名の他人とあなたを識別するためには、姓名だけでは十分でない、・・・となる。そこで、住所、生年月日、写真つきの公的証明書が必要となる、・・・

商品

品番品名上代サイズ色素材・・・

R 例えば（工業）商品を考察すると、設計書があり規格書があり、原材料は同じものを使って製造される

同じものは、論理的にいつでも作れる

個体を意識することはない・・・

一意性の検討


リソースには『タイプ』と『オカレンス』がある・・・と、既に提示したが、オカレンスの代表例として取り上げられるのが『顧客』である。しかしながら、個体と一意性は同じではない。ビジネスを起点にすると、商品はタイプ、顧客はオカレンスだ！と、云っても異論はあるまい・・・ではオカレンスが『一意性検証』に該当するのだろか。

企業顧客

顧客コード. 商号代表者氏名所在地資本金設立年月日・・・

R

代表者が交代すると、顧客コードをそのままに履歴が発生する

業務データベースならば、履歴を管理する必要は必然と考えられるため、顧客コードとは別の個体指示子を設定し、一意性を担保する必要がある

※ リソースを『タイプ』と『オカレンス』に分けて分析するのは今や常識？となった。この分析方針を明確に打ち出したのは、データ総研創業者の椿正明氏である。

個人情報の取り扱い


個人情報保護法に対するコンプライアンス問題をクリアするためにモデリング当事者は面白くもないことをめいっぱい考え、企業は掛けたくない金を、これまた大いにつぎ込まなければならない。個人情報保護の問題とプライバシー保護は、実は根を同じにするものではないからだ。企業の目的は、適切な形で利益を上げることにある。つまり企業が収集した個人情報は、商業的利益の獲得を追及するために利用するためで事業活動の一部法の定める規制と刑事罰にばかり気をとられていては、個人情報の有効利用に思い至らない。そこで、どのような利用方法が個人情報保護の対象になり、その対象となる個人情報とはどのようなものなのかを理解しないと、モデリングの結果が有効であると言い切ることはできない。このような視点で検討を進めようと思う。

普通の個人情報

特別な個人情報

この差に法の考えるプライバシーが垣間見える

※ あくまでも、筆者『個人』の見解です。・・・ここ重要！



個人情報をビジネス利用する場合、検索可能な状態にデータを整理し、検索方式を整備する

これを『個人情報データベース』という

個人情報データベースを保持したその時点で『個人情報取扱事業者』となる

個人情報保護を法に従って適切に取り扱う義務が生じる

※ 但し、６ヶ月以上にわたり五千件の個人情報を取り扱う場合に限定※ 従業員も含まれる。五千人以上の従業員を擁する企業は、是非なし



匿名化問題ー盗難対策

連結不可能匿名化

連結可能匿名化

個人情報データベースの要件である検索性において、任意の個人情報を特定できないように識別子（個人ID）を符号化（エンコーディング）

符号（エンコード）や識別子への変換対応表を残さない方法による匿名化

連結不可能匿名化と同じように、個人情報データベースにおいて任意の個人を特定する識別子（個人ID）情報を特定できないように識別子を符号化

連結不可能匿名化との違いは、任意の個人を識別できるように識別子変換対応表を残す点

非アクセス型暗号化連結不可能匿名化、連結可能匿名化はデータベースへ

のアクセスを符号化する方法非アクセス型暗号化はデータベースそのものを暗号化

する方法データベース管理システム側で暗号化/複合化すること

が前提



暗号化問題ー盗聴対策

通信暗号化盗聴対策クライアント～データベース間の通信の暗号化

※ その他、複合化したデータをダウンロードできないこと、クライアント側画面のPrtScの無効化など、検討を要する問題はあるが、ここでは割愛

※ 帳票管理の問題、つまり印刷した納品書、請求書などの管理と申込書、契約書などの原義の問題も、個人情報保護の対象となるが、ここでは割愛



個人情報

個人情報ID(R). 氏名住所郵便番号生年月日

VE

個人情報

個人情報ID(R). 婚歴

クレジットカード

・・・

VE

普通の個人情報

特別な個人情報

個人識別

個人識別コード. パスフレーズ有効期日

R

個人情報識別

個人情報識別コード

R 個人情報

個人情報ID.

R

個人情報識別・個人情報・対照表

個人情報識別コード(R)

個人情報ID.(R)

有効化有効化実行日

TS

個人識別・個人情報識別・対照表

個人情報識別コード(R)

個人情報ID.(R)


TS

公開情報非公開情報

連結可能匿名化暗号化

日付と時間と


法人税法施行規則第５５条第２項に規定されている総勘定元帳の「記載年月日」と

は、仕訳帳から総勘定元帳へ個々の取引を転記している場合は、転記した取引の取引年月日となり、一定期間の取引の合計金額を総勘定元帳に転記している場合は、一般的に複式簿記の原則に従って処理される日（集計対象とした期間の末日など）が記載年月日となります

ＩＴシステム要件訂正削除の履歴電子認証関連性の確認見読可能性検索性と完全性標準化など

「その範囲を指定して条件を設定することができる」とは、課税期間ごとの国税関係帳簿書類別に日付又は金額の任意の範囲を指定して条件設定を行い検索ができること

国税関係書類

等々・・・

受領書

貨物

検収書

受取書

領収書

検収書

契約書

見積書

送り状

請求書

注文書

請求書

納品書

国税関係書類例

出典：国税庁HP

https://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/dennshichobo/jirei/

日付と時間と


ＩＴシステム要件訂正削除の履歴電子認証関連性の確認見読可能性検索性標準化など

電子帳簿･タイプ# 記載年月日レンジ# 金額レンジ･顧客名称

電子帳簿アプリ# アプリID

検索性

見読性

完全性

電子帳簿国税関係書類

# ID

･期

受領書

送り状

見積書

契約書

領収書

検収書

注文書

請求書

納品書

貨物

受取書

検収書

電子帳簿国税関係書類･タイプ

# 帳簿名称･用途

管理

利用可能

機能例

具体化

一例

具体化

周延に至らない外延


国税関係書類

ID名称期記載年月日金額

納品書


請求書


注文書


検収書


・・・・・…周延しない・・・

周延に至らない外延を並べるケース書類（モノ）の『存在』を強く意識すると、モデリングを誤ることがある『モノ』に拘るのでなく、『事態』を見抜こう

『納品』なる事態を業務の『事実』として確認できればエンティティとして存在する『請求』なる事態を回収業務の一形態として確認。よって、エンティティが存在し得る・・・と

エンティティ･ロール問題


製品

品番品名製品概要・・・

品質基準

品質基準コード技術要件達成基準検品数不適合品率・・・

検品

検品No.製造ロットNo.(r)

検品数適合品数不適合品数不適合品率(d)

品質基準・製品・対照表

品質基準コード(R)

品番.(R)


TS

R R E

検品･合否判定

検品No.(r)製造ロットNo.(r)

適合判定拒否判定

合否区分

ER

エンティティ･ロールとは、任意のエンティティが業務と対峙したときに、その業務に内包されるルールあるいはルールに基づく処理の発現方法を示す

エンティティ･ロール問題（続き）


検品

検品No.製造ロットNo.(r)

検品数適否区分不適合品率(d)

E 検品･合否

検品No.(r) 適合もしくは不適合の結果数

ER適合区分

前頁のデータモデルは、以下の書き換えが成り立つ

※ 前ページでは、「検品・合否判定」をサブセットで提示した。一方、下図は検品のオカレンス（繰返）のように表現している

※ データモデルを作成する仮定で、VE型とスーパーセット/サブセット型のどちらを選択すればいいか判断に迷う分析者が少なくない理由と考えられる

※ データモデルを『データの置き場作り』と考えると、分析が・・・

VE問題


個人情報

個人情報ID(R). 氏名住所郵便番号生年月日

VE

機微情報

個人情報ID(R). 婚歴

クレジットカード

・・・

VE

個人情報

個人情報ID.

R

VE問題は、T字形ER手法によるモデリングの急所と化した・・・誇張した表現かもしれないが、VE（仮想エンティティ）とスーパーセット･サブセットの折り合

いは、T字形ER手法にとって問題になったと言わざるを得ない方法論に沿って着実に行えば解決できるのだが、多くモデリング施行者にとっては、VEは頻発

する存在であり、モデリングが成功しているのか不安感に苛まれる一事であるそこで、VEについて今一度論じたい。

VE問題


VEについて「帰属」をVEの論拠に採用する傾向の解説もあるが、本書では『業務の事実』の視点から解説を試みる。

筆者は本書の中で「仮想エンティティ（逐語訳）」という詞を使用する。しかし、佐藤師は「みなしエンティティ」

という詞を使用して解説している。

（http://www.sdi-net.co.jp/FAQ073.htmを参照）

データモデルの対象と一般的認識の違いさて、議論が飛躍しているように見えることを承知で；

ウィスキーには肴が必要だ

チョコレートは肴になる

よってウィスキーの肴にチョコレートは適合する

ウィスキーの肴として、チョコレートをお品書き（あるいはメニュー）に書き入れる料亭（あるいはレストラン、ビ

ストロ・・・）があるだろうか？

議論が砕けすぎで不謹慎だと言う誹りをあえて受けるとして、料亭は、酒よりも料理を堪能する店である。一方、料

理に拘らず・・・というよりも料理でない別のものが主たる商品である店（以下、「A店」という）では、肴は何で

もよい。100円ショップで買ってきたチョコレートをガラスの器に盛って提供することへの抵抗などもとよりない。

100円ショップでは、商品を1個100円で販売するため、売れた品に頓着がないように、A店はチョコレートの原価に

心砕くわけではない。飲食業であっても、A店のような商売のそれは、料亭やレストランと根本的に違うのである。

長々と言葉を連ねてきたが、これが仮想エンティティの基本的考察である。即ち、元から管理対象としていないが、

ビジネスを推進する上で貴重なデータ資源と考えられると判明した事実の扱い方を思考した結果といえる。

http://www.sdi-net.co.jp/FAQ073.htm

VEを考えるための視座


業務の違い / 制度由来？・・・組織のなかで、・・・勘定組織は仕訳を標準化・定制化するために定められたコード体系であり、ビジネス上の組織とは

分けて管理される。例えば、ある事業に関連して組織が分かれたとき、勘定組織の対応は、休眠し

ていたコードを割り振り仕訳を標準化するといった方法が、一般的な処置に思える。

ビジネスの中には仮想空間、あるいは並行世界（パラレルワールド）が存在する

その好例が、帳簿であり、総勘定元帳である

帳簿、総勘定元帳の世界では、価値を金に置き換えて、その流れを仕訳によって記録するという

興味深いルールが存在する

一方、コツコツと実績を積み上げて事実を形作る業務の世界では、価値創造はあらゆる場面に存

在し、改善は常態化している

一般的な組織では、内部の組織変更は定期的に発生し、その度に設置日を管理することは可能だ

しかし、前述とは別の体系を持つ帳簿、総勘定元帳の世界では、業務世界の事実と異なる公理系

によって、その世界が作られていると考えてよい。そのため、業務世界と勘定の世界では、既に

世界を表す総体が違うと捉えるべきである

以上が『データの帰属性』を論ずる前提であり、VEの使用を考える上での道筋となる。

VEは「事実の存在を確認する役割」を持つ


平成27年2月11日株式会社××××総務ご担当者殿

□□□□□株式会社カストママーケティング部

○野△雄

～～～について拝啓。平素より小社製品に格別のご愛顧を頂戴し、改めて御礼申し上げます。

さて、このたび～～～の販売を開始することとなり、つきましては、小社製品のお得意様に特別ご優待のご案内を以下の通り行うこととまりました。ご多忙中のところまことに恐縮ではございますが、ぜひともご来場いただきますよう衷心よりお願いする次第です。

敬具記

１．平成27年3月12日午後3時より２．ホテル・・・緋龍の間３．お申し込みは、以下のWebサイトで承ります。

http://www.□□□□□.co.jp/～～～/

当日のご来場確認は、お客様のメールアドレスで承ります。恐れ入りますが名刺を2枚後用意ください。

顧客区分によって既存顧客（左文面の総務ご担当者殿）の違いを表そうとするのではなく、「リード」として管理するのがこの場合適切

顧客（スーパーセット）の中の既存顧客（サブセット）と見込み顧客（サブセット）を設けてテータを保持することに収まりを着けることはできるが、従前からの概念に囚われることで、ビジネスのあり方を表現したデータモデルとは言い難い状態に陥る

加えて、VEで分析したと称しても、スーパーセット･サブセットの形にならないことの説明、論拠が定まらない

VEで事実の存在を確認することの重要性

データ管理上の問題を解決するためのVE


もうひとつ、VEの使いどころを検討する際に説明しておきたいことがある。それは、データの管理上の問

題を解決するためにVEを用いると言うものである。

先に示した『個人情報』が好例である

経済産業省個人情報保護ガイドライン参照のこと（http://www.meti.go.jp/policy/it_policy/privacy/）

一般的な個人情報と機微情報の取り扱いの違いに触れている

機微情報として、クレジットカード情報を例に挙げている。業務の世界では、一般的な個人情報と機微

情報の取得のタイミングが一致するとは限らないし、また機微情報を永続的に保持するとも限らない

さらに、Webサイトでの買い物で『購入』→『精算』の際、クレジットカード情報を登録しておけば、

速やかな精算へとプロセスをすすめることができるが、クレジットカード情報の登録がない場合、『精

算方法を選択』し、クレジットカードを選択した場合『クレジットカード情報の入力』→『その情報の

真偽判定』→真の場合、『精算』というプロセスを経ることになる。

また、クレジットカード情報をマイページ等に登録する場合、複数のクレジットカード情報を登録する

場合もあるだろう

このような業務の事実（この場合、事業者サイドのみならず、利用者も含まれる）を考えると、これは

VEでなく、エンティティ･ロール（ER）を使って、モデルを描くことを考えねばならない

『データの帰属性』問題を考える筋道の参考になれば幸甚である

VEを描いてみよう


設問前頁で提示した例をもとに、VEを使って顧客関連のデータモデルを完成させよ。

解答欄

『見込み顧客』の考察


既存顧客

顧客コード

R

見込み顧客

顧客コード仮氏名

R

顧客

顧客コード氏名住所郵便番号顧客区分生年月日．．．

R ×顧客区分

見込み情報

顧客コード仮氏名

VE顧客

顧客コード氏名住所郵便番号顧客区分生年月日．．．

R ○

顧客区分

顧客

顧客コード氏名

住所

郵便番号

生年月日．．．

R リード

リードID 会社名（Ｄ）部署名（Ｄ）役職名所在地郵便番号

R

『VEを使ってはならぬ！』が正解

設問が『病題』ですな！

スーパーセット・サブセット問題

Ｔ字形ＥＲ手法では、いくつか特徴的な詞が登場する。ここでは『周延』について解説する。

スーパーセット / サブセットでは、サブセットが全てで切った状態を『周延』という

サブセットを出し切るにはどのような工程を経ることになるのだろうか？


区分、種別を分析する

業務上の区別を分析する

区分、種別のうち、業務上の区別によらないものを排除する

ソート用のキー

レポート用の区分、種別など・・・

スーパーセット・サブセットには・・・

同一のスーパーセット / サブセット

i. 区分により２つ以上のサブセットが成立する要件を満たす

ii. したがって、エンティティ内のドメインは共通


i. 区分により２つ以上のサブセットが成立する要件を満たすケースがある

ii. エンティティ内のドメイン（構成ドメイン）が以下の点で相違するならば『相違のスーパーセット / サブセット』にする

① サブセット間でドメインの異同がある

② サブセット間のドメインに一見異同がないように見えるが、データの桁、型、名称（エリアス、シノニム、ホモニムをググってください）に異同がある場合※

SDI http://www.sdi-net.co.jp/news472.htm

※ DLCPで思い出すのが『Xupper』■参照いただければ！


http://www.sdi-net.co.jp/news472.htm

http://intelligencebox.net/?paged=2

サブセットの分析

ここでは『注文』を例にとって議論したい

一言に『注文』といってもいろいろな種類、形式がある補充用注文小売店在庫の補充

特急注文客先から急ぎの注文

先（日）付け注文投入時期が決められている商品の事前受注

サンプル注文商品サンプルの出荷対応

社販注文社員の福利厚生的意味合いの強い社内販売

セット販売注文一定量の商品をまとめた販売でスロームービングが対象になる

ＥＤＩ注文電子商取引ここではＥＯＳ

ＦＡＸ注文文字通り

手書き注文文字通り

集約注文未出荷の同一顧客からの注文を出荷業務に合わせて集約すること

分納注文受注数量に達しなかった場合、差分を後日出荷するための注文。バックオーダー

代理店注文代理店契約（問屋）を交わした顧客からの注文

専門店注文直販店契約を交わした顧客からの注文

直販店注文自社運営の店舗からの注文


注文を分析すると！


商売モノ

売り方

お

客

は

問屋

お

客

は

専門店

お

客

は

社員

商品を

売

る

在庫移動し

て

在庫引当す

る

EDIで

受

注

す

る

FAXで受

注

す

る

注文書で受

注

す

る

売上計

上

す

る

経費計

上

す

る

即納注

文

す

る

先付け注

文

が

あ

る

先付けの有効化

完納が

あ

る

分納NGが

あ

る

分納が

あ

る

セ

ット販売が

あ

る

補充注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

特急注文 ○ ○ ○ ○ ○ ○ ○ ○ ○

先付け注文 ○ ○ ○ ○ ○ ○ ○ ○

サンプル注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

社販注文 ○ ○ ○ ○ ○ ○ ○ ○ ○

セット注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

EDI注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

FAX注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

手書き注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

集約注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

分納注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

代理店注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

専門店注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

直販店注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

出荷

タマ

納期

顧客

媒体

勘定

スーパーセットを分析！


注文DTL

注文

注文HDR

注文No.

H_Rev.No.

顧客No.(R)

受注日

希望納期

出荷完了予定日

受注金額（D）

注文メモ

注文明細No

D_Rev.No.

注文No.(R)

H_revNo.(R)

品番(R)

注文詳細メモ

受注明細金額（D）

下代（D）

受注数量

予定納期

E

E

アトリビュート（主要活動）

アトリビュート（価値提案）

アトリビュート（収益またはコスト）

アトリビュート（収益またはコスト）

アトリビュート（顧客との関係）

リソース（主要リソース）

アトリビュート（主要活動）

『注文』の成立可否を決定する重要な要件事実

サブセット化の検討


主要リソースであり顧客分類は重要なビジネス上の要件問屋と店舗（個人を含む）の区分は２つ

顧客：顧客No.

注文：受注日

注文は顧客との関係に該当し、受注日は主要活動の結果を示す受注の要件事実ではあるものの、サブセット化の要件から外すこと

が可能

注文：希望納期納期回答は、顧客に対する価値提案にあたる即納とそれ以外（先付け）の区分は２つ

注文：受注金額（D）収益またはコスト（サンプルの場合）に相当収益を生むものとコストを生むものの区分は２つ

注文明細：受注明細金額（d）収益またはコスト（サンプルの場合）に相当収益を生むものとコストを生むものの区分は２つ

注文明細：下代（d）

顧客との関係としたが、価値提案にも相当する注文明細の一般属性であり、サブセット化の要件から外すことが可

能

注文明細：受注数量

受注日とともに注文の主要活動を示す注文明細の一般属性であり、サブセット化の要件から外すことが可

能

サブセット化の『何階建て？』を考える

『サブセット化の検討』では「注文」エンティティを構成するドメイン類がどのような性格のものであるかを提示した

サブセット化を検討する場合、どこから着手するかで悩む場合もあるだろう。筆者も初期段階で師匠から幾度となくご指導をいただいたことを思い出す・・・

蓋然性・抽象性の高い順に層を成すのが一般的

高層（スーパーセットに近い）サブセットの方に蓋然的、抽象的なサブセットを置くほうがERモデルの表現上わかり易い

例に戻って検討してみよう！


『注文』のサブセット化検討


主要リソースであり顧客分類は重要なビジネス上の要件問屋と店舗（個人を含む）の区分は２つ

顧客：顧客No.

注文：希望納期納期回答は、顧客に対する価値提案にあたる即納とそれ以外（先付け）の区分は２つ

注文明細：受注明細金額（d）収益またはコスト（サンプルの場合）に相当収益を生むものとコストを生むものの区分は２つ

顧客

納期

収益・コスト

顧客

納期

収益・コスト

顧客

納期

収益・コスト収益・コスト

納期

顧客

いくつかあるパターンからどれを選択するか？蓋然的に、恣意的にならぬようあくまで形式的に！

選択！そして周延


顧客

納期

収益・コスト

サンプル注文販売

補充注文先付け注文

そもそも『サンプル出荷』は注文ではない。出荷機能が利用できるため、便利さに着目して適用が拡大、常態化し『サンプル注文』なる奇異な詞は発生したのでは？

※ 社販、特急注文、セット販売は補充注文の各形態に過ぎず、販売/営業上の取り扱いの差（運用の差）でしかない。※ EDI, FAX, 用紙による区別は媒体の違いであり注文としての本質に変わりはない、これらの区分は対象からはずす。但し、用紙による注文は分納可であり、セット販売、社販は用紙での注文し

か受け付けない。これは、業務プロセス上の管理（統制）のため。※ 集約注文は受注後の後処理であり、『注文』ではない。出荷指示の際、顧客、向け先ごとに注文を集約する処理。通常の出荷指示のほか、先付け注文の有効化の際、集約が行われる。

※ 顧客を『代理店』『専門店』『直販店』としたが、『社販』の『社員』も同様にあつかう。但し、社販は、福利厚生的一面から利益を生まず、また担当営業もついていないことから営業成績や費目上の処理に違いがあるため、扱いが異なる。

※ …etc…

顧客による注文の偏りがあることから、業務上重要な視点となる。

販売戦略、商品戦略上の重要な視点となる。

代理店注文からの注文

専門店/直販店からの注文

代理店注文からの注文

専門店/直販店からの注文

×

×

＝＝

注文

蓋然性問題

1. 例では、個体指示子の『花･副資材コード』と『仕入用資材-識別』が3つある各々のサブセットに「唯一」且つ「一個」に分かれる

2. スーパーセットは、サブセットの全体を表す概念であり、集合x1,x2,x3の全体集合Xに相当する

3. T字形ER手法では、スーパーセットを蓋然的なレベルまで上げて、あえて表記することがある

※ ここで注意すべきは蓋然性問題は２点事態の蓋然性客体世界における事態成立の可能性

判断の蓋然性モデル作成者の判断による事態成立の可能性

即ち、客観的に「事実」を分析･可視化するべきモデルに主観的判断が混ざり込む可能性が生ずる

事態：花は生花とプリザーブド･フラワーの両方を仕入れる可能性がある

判断：花は、生花とプリザーブド･フラワーの両方を仕入れるにマチガイない！


この資料の補足

イベント系エンティティ（イベント）の定義

連続的な時間の概念に従属するため、エンティティの性質として業務の事実に即した「日付」を内包する

リソース系エンティティ（リソース）の定義

イベント系エンティティ以外のエンティティをリソース系エンティティと定義する（P∨￢P）


この資料の補足（続き）

佐藤師の方法論に対する取り組みは、現在TM1.3に至る

このハンドノートは、旧来のT字形ERモデル手法をベースにしていることを表明しておきます

TM1.3に興味のある方は、以下のURLから情報を得ることができます

TM1.0～TM1.3に関する情報は、以下のURLを参照してください。

参照･引用：http://www.sdi-net.co.jp/tm-versions.htm#13

「抽象データ型モデル」の説明資料

ダウンロード：http://www.sdi-net.co.jp/model-outline.pdf

TM1.1 の説明資料

ダウンロード：http://www.sdi-net.co.jp/tm-1-1.pdf


http://www.sdi-net.co.jp/tm-versions.htm#13

付録１

David C. Hay のモデル


David C.Hay氏のモデル


イニング

野球の試合

野球の試合はすべからく1から複数のイニング（表と裏の対で回をなす）で構成される

すべからくイニングは野球の試合の一つの部品であり、ある1つの試合に属する

すべからく

一部

イニング野球の試合

一部に属する

構成される

＜リレーションシップ名＞

＜1つ目のエンティティ＞

＜2つ目のエンティティ＞

~である

～の可能性がある

ひとつにして唯一の

ひとつから複数の

野球の試合はイニングによって構成される

イニングは野球の試合の一部でありある試合に属する

Data Model Patterns: Conventions of Thought, Second Edition Part One: The Enterprise Model

David C. Hay San Diego, Cal, USA March 16, 2008

Parties


PARTY# 広義の識別子

自然人• 誕生日

組織• 名称

法人

国際組織

自治体

社団

PERTY TYPE

# 名称• 説明

具体的に提示するひとつの例として

サブタイプとして

スーパータイプとして

サブタイプを中に描く

PARTYの『種類』によって、PARTYは具体化する。

種類に対する考察

Data Model Patterns: Conventions of Thought, Second

Edition Part One: The Enterprise Model


2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 702015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd

PERTY TYPE

# 名称○ 説明




リレーションシップに関する考察

PARTY RELATIONSHIP# 有効日○ 期日○ コメント

PARTY

RELATIONSHIP TYPE# 名称○ 説明


自然人○ 誕生日

組織○ 名称

法人

国際組織

自治体

社団

具体的に提示するひとつの例として接続される接続する

こちら側他方側





PERTY TYPE

# 名称○ 説明




識別に関する考察


PARTY




組織○ 名称

法人

国際組織

自治体

社団



PARTY

IDENTIFIER# 識別子の値○ 説明○ 有効日○ 期日

PARTY

IDENTIFIER

TYPE# 名称○ 説明

にある

識別される

発番される

発番根拠


掣肘する

管理される





PERTY TYPE

# 名称○ 説明




名称に関する考察


PARTY




組織○ 名称

法人

国際組織

自治体

社団



PARTY

IDENTIFIER# 識別子の値○ 説明○ 有効日○ 期日

PARTY

IDENTIFIER


にある

識別される

発番される

発番根拠


PARTY NAME# 名称の値○ 説明○ 有効日○ 期日

PARTY NAME



にある

表示される

掣肘する

管理される




業務階層図の構造


業務ロール名称

業務ロールID(FK)

業務名称

業務ロールID

業務ID

業務種類

業務ロール

業務ロールID(FK)

業務説明頻度年間稼働累計時間

業務ID

業務・プロパティ

P Z

Function Area → Function

Function → Process

Process → Activity

Activity → Procedure

Procedure → Task

業務ID(FK)

機能名称

機能ID

機能

Z

David C.Hayモデルの特徴

1. 『役割（role）』と『種類（type）』を組にしたエンティティを配置して、意味論モデルを構成している

2. エンティティは具体的な（concrete）事物を表現するが、この意味論モデルは分析対象のテンプレート（型）のような機能を果たしている

3. 上記によりモデルが単純になり、高い可読性を獲得している

4. また、モデルの大きさもコンパクトになる。A4紙に20

個以内程度に収めるのが理想的


付録２

DOA そもそも・・・


そもそも・・・

そもそも、データモデルが目指すSDLCとは？


業務に役立つシステムを『安･短･簡』で調達する

どうやって？

事業・戦略・業務とシステムの隙間をぴったり埋めれば、無駄な開発がなくなるじゃん！

それでｪ～？

変化はシステムが惹起するわけでない。

処理量の増加、製品の変遷、経年変化、人の入れ替わり、・・・これらに対しシステムは器用に変化できない

そもそも・・・続き


だからァ～？

システム視点で『変化の激しいところ』と『安定しているところ』を分離して考えてみると、、、、、、、、、

プログラムとデータ構造という結論に至った。

プログラムは不便になったら使い捨てる！

データ構造は変化に強い安定性を目指す！

そんなわけで・・・！


DOA誕生しました

ERモデルは・・・


Dr. Peter P. Chen

エンティティ－リレーションシップモデルは1976年にマサチューセッツ工科大学（当時）のPeter P. Chen氏が開発し、論文発表した表記法です

He is the originator of the Entity-Relationship Model (ER

Model)…

出典/引用http://www.csc.lsu.edu/~chen/

※ Peter P. Chen氏のERモデルは、現在ＩＴ分野で最も利用例の多い表記法であるIDEF1Xをはじめとする諸々のERモデル表記とは異なります

http://www.csc.lsu.edu/~chen/

最後に・・・


佐藤正美氏の著書を紹介

佐藤正美情報システム・コンサルタント

（専門領域: データベース設計）

1953年生まれ。

1977年早稲田大学商学部卒業。

1979年早稲田大学大学院商学研究科博士前期課程修了

（財務会計論専攻）

その後、アーサー・アンダーセン、等松青木監査法人および株式会社ア

シストを経て、1991年 1月独立（株式会社 SDI 設立）、現在に至る

http://www.sdi-net.co.jp/より転載

http://www.sdi-net.co.jp/

付録３

問題提起


これから・・・


問題提起

データ・モデルの分析は、市場の変化が起因しているかの検証はさておき、安定したデータ構造の構築（ミニマルカバー：Minimal Cover）を目指していたのだが・・・

例えば、商品と顧客の関係・・・製造家（企業）が生産した製品（⇒製造工程あるいは情報の加工を経てできるモノ）が流通に移動することで商品（⇒『売り手と買い手の関係』あるモノ）となり消費者に渡る『商品』

この商品と顧客の関係が、徐々に安定を失っている・・・※システムのライフサイクルが短くなり、ITコストのぞうかにつながる

のではないか

DOAのモデリングはこのままでいいのか！

次のステップに上がるために


安定とは、データ構造と事実の関係で定義することができる（以下）【安定の定義】：事実との対応関係が確認できる指示関係。指示関係を一定時間継続的に維持できること。言い替えるとデータ構造と事実の指示関係が一定時間成立するような事実もしくはデータ構造をみつけだすことが安定化の条件となる

【指示関係】：形式意味論では、「文⇔論理的に可能な事態全体」の対応から真理条件にある関係を規定すること。

では、どのくらいの時間、指示関係が継続すれば「安定」と呼べるのか？

現状を鑑み、安定化に該当あるいは適した事実とデータ構造を見出す方法をモデリングに加えるべきではないのか？

現在知られているデータモデリングの手法は、規定できないものに範囲を拡大しても分析可能なのか？

規定できないものをモデリングは排除してもいいのか？時間的要素を取り除けるのか？つまり安定を捨てて指示関係だけにするのか？

次のステップに上がるために


現状を鑑み、安定化（あるいはシステムのライフサイクルを考慮した分析）に有効な手法をモデリングに加えるべきではないか？

仮に加えるとして、現在知られている分析手法のなかで適用可能な手法はあるか？

いま一つ、DOAで検討すべきこと！・・・は

仮想例題

FLEUR MEMOIR


とある花屋では・・・


店舗販売ネット販売

花屋といえば駅の近く

生花

プレゼント

お遣い物どちらかと言えば女性が客？

花束

バラ、カーネーション、カサブランカ

アレンジメント

キク匂い

店員さんのサロン水仕事

ガラスのショーケース

ラッピングクール宅配

カード決済楽●

予約

カード決済

銀座新地

胡蝶蘭母の日

お正月

法事

法事慶事

季節感ゴミ

誕生日

鉢植え

スケート開店祝

メッセージ

ホテルのテナント

観葉植物

鉢植え

花瓶

システム構築の目的


効率的な仕入・販売を支援する業務システムの構築

商品と在庫① 花束の組み合わせは事前に「商品」として決めうちされている。１個の商品あたり、どの「単品（後述）」がどれだけ必要かも決めら

れている。シングルレベルしかない部品表のようなもの。単品の在庫も含めて、保管場所は１箇所で、これが増える予定もない

② 花束の材料となるそれぞれの花は「単品」として管理される。「単品」はそれぞれ特定の仕入先から購入され、単品毎に品質維持可能

日数が決められている。購入後にその日数を超えると結束には利用できずに廃棄されなければならない。なお、受注・出荷されるもの

は「商品」のみであって、単品がそのまま出荷されることはない

得意先と受注・出荷③ リピータを期待するので、得意先（個人のみ）情報を管理したい。届け先は毎回違う可能性があるが、前回の受注情報から届け先を簡

単にコピーできるような機能は欲しい

④ １回の受注で、１箇所の届け先に対する１種類の商品１個を、「届け日」と「お届けメッセージ」、「お届け先電話番号」とともに受

け付ける。出荷日は届け先に関係なく届け日の前日とする

⑤ いったん受注を受けてから、届け日の変更が要望されることがある。その際には可能な限り変更に対応できるようにしたいが、指定日

に出荷変更できないようならばその旨を顧客に直ちに伝えられるようでなければならない。

⑥ 単品を結束して商品（花束）にするための工程は十分に効率化されていて、材料さえあれば一瞬で結束可能とみなしてよい。したがっ

て、出荷日当日に結束指示すれば出荷可能である

発注と入荷⑦ 単品を発注する際、単品毎に発注リードタイム（入荷されるまでにかかる日数）が異なる。発注リードタイムさえ越えていれば、どん

な将来の入荷向けの単品も発注可能だし、入荷日の変更要望も受け付けてもらえる

⑧ 「単品」毎に購入単位数が決まっている。たとえば、５０本必要だとしても、購入単位が１００本ならば１００本買わなければならな

い。なお、仕入先の供給能力は十分かつ、納期も正確とみなしてよい。

⑨ 発注の判断は、在庫推移をみながら人間が行う。したがって、自動発注処理を考える必要はない

代金の扱い⑩ ＩＤの登録の際にクレジットカード情報を入れるため請求や入金に関しては考慮する必要はない

⑪ 入荷の実績情報があれば処理できるので、仕入先への支払に関しても考慮する必要はない

現状の画面・帳票⑫ 添付資料(花束問題伝票V1.0.ppt)のとおりであるが、現状のままでは使いにくいと感じているため、ユーザとしては全面的に刷新しても

かまわないと考えている

要求（要望＋要件）


①_1 商品構成管理

①_2 在庫保管場所

②_1 材料管理

②_2 仕入先

②_3 材料廃棄条件

②_4 材料転売の禁止

③_1 得意先管理

③_2 得意先・届先紐付け

④_1 受注・受付

⑤_1 出荷日変更受付

⑥_1 受注後出荷100%

⑦_1 発注リードタイム & FIFO

⑦_2 発注入荷日変更依頼

⑧_1 発注ロット

⑨_1 発注ノーテーション

⑩_1 回収・クレジットカード

⑪_1 入荷実績・支払処理

業務階層図


営業出荷仕入

実棚数チェック

入荷予定チェック

販売予定チェック

仕入決定

仕入発注

入荷予定更新

伝票整理（買掛）

商品デザイン

商品レシピ開発

商品規格書作成

サイトにアップ

受注分析

売上集計

レシピ見直し

販売・マーケ

集客

得意客認証

得意客登録管理

受注・受付

受注

お届け日変更受付

商品変更対応

商品出荷

出荷デマンド集計

材料準備

出荷作業計画

出荷指示作成

商品製造

メッセージ対応

パッキング

検収確認

顧客管理

請求案内

受注履歴管理

回収

請求案内

支払確認

入金・消込

売掛債権更新

支出

支払請求確認

送金指示

送金処理確認

買掛債権更新

小売業の『鉄板』


1. 仕入

2. 加工

3. 販売

4. 回収

仕入・買掛・債務・支払口座ＰＯ計画・入荷・検品・入庫

出荷前加工・仕掛ワークロード計画・品質管理製品在庫

顧客・受注・出荷・納品・検収商品在庫・商談・営業・アド与信・与信限度額・掛取引

売上・売掛・利益入金消込・回収口座売掛残・督促・貸倒/引当処理

・・

要求事項の確認


①_1 商品構成管理いわば「花束レシピ」が存在する。商品の規格として材料である花の組み合わせと数量（構成）が決められている。

規格書は、商品の主材料、副資材により構成される。主材料：生花、ブリザードフラワー、アートフラワー副資材：ラッピングペーパー、テープ、リボン、ケー

ス、フローラルフォーム、スタンド、装飾小物

⑧_1 発注ロット、⑨_1 発注ノーテーションに

関連し、材料の消費量の計測が受注段階で計算可能な情報が商品構成管理にある。

花束レシピはひとつの商品（花束）に対応する。例えば「大輪赤バラ＆カスミソウ」に（大）（中）（小）がある場合、夫々にレシピが存在し、それぞれがひとつの商品として識別される。

花束レシピがなければ商品は存在しない。原価構成の視点から、商品の上代は変動する。



①_2 在庫保管場所在庫とは、保管場所（倉庫と棚）と保管対象物によるマトリクスで構成される・・・が、本件では保管場所が一箇所であり帳簿と実棚（現物）の精査が毎日行われるような関係にある（⑥_1 受注後出荷100%）ため、各材料にアドレス（棚番）を付けて管理することとした。

但し、アドレスによる管理は現物のみとし、発注済∧入荷前の数値管理は除外する。

材料の消費はFIFO（「ファイフォ」「フィフォ」と発音）

とする（⑦_1 発注リードタイム & FIFOと関連）。



②_1 材料管理

②_2 仕入先

②_3 材料廃棄条件

材料管理上の「単品」とは、品種、色、柄、花の大きさなどが一定の範囲にあるものをいう。

材料の仕入先は花卉生産者との直接取引のみとし、花卉市場からの調達は行わない。

花卉生産者との商取引関係を強固にするためにも、品質に関する要求は高い。生産者側と合意のもと品質基準を設け、生産者側に出荷品質の徹底を図る努力をお願いしている。

しかしながら、品質基準に至らない場合、入荷拒否（リジェクト）することが可能。

リジェクトによる商材欠品が発生した場合、花束の構成を変更してもいいか、注文先に確認する。

※ 因みに「単品飲み放題」とは、単品料理を注文する形に飲み放題をプラスしたい方たち向けプランのこと！

かき



②_4 材料転売の禁止商材は転売しない。

※ 入荷した商材は、全て買い取られ、商品に加工されて出荷する。

※ 加工工程での損耗は全て自己リスクとして受容する。

※ 従って、入荷後の返品はない。

※ 入荷後、自社店舗（リアル店舗）に材料を部門間移動（振り替え）することはない。



③_1 得意先管理

③_2 得意先・届先紐付け

顧客は得意先として管理得意先は個人のみ注文には、得意先登録が必要得意先

注文履歴で届け先を検索、表示、再利用可能にする

商品とは別に「お届けメッセージ」を同梱することができる

注文受付時に発注者から「届け先のお名前」「住所」「電話番号」を取得する。

注文受付時に発注者の「お名前」「住所」「連絡先」「お届け日」を取得する。



④_1 受注・受付

⑤_1 出荷日変更受付

商品とは別に「お届けメッセージ」を同梱することができる

注文受付時に発注者から「届け先のお名前」「住所」「電話番号」を取得する。

注文受付時に発注者の「お名前」「住所」「連絡先」「お届け日」を取得する。

お届け日変更を受け付ける

店からの「出荷日（予定日）」は「お届け日」の前日とする

よって、当日受付・出荷は不可



⑥_1 受注後出荷100% 指定されたお届け日に出荷変更できないようならば、発注者に直ちに対応を伝える。

そのために「受付」は受注後も発生する（⑤_1

出荷日変更受付）。出荷日直前までお届け日変更を実現するリジェクトによる商品の変更対応

前日受付→注文成立なら、出荷100%を成し遂げる。



⑦_1 発注リードタイム & FIFO

⑦_2 発注入荷日変更依頼

⑧_1 発注ロット

⑨_1 発注ノーテーション

FIFO実現のために、P（仕入）/I（在庫）/S（販売予定による材料の消費数量）のバランスによる。

材料の仕入は発注ノーテーションを参考に店舗スタッフが実施する。

発注ノーテーションは、発注リードタイムとリードタイム間に消費される材料の量から割り出した安全在庫量をトリガとして発せられる。

発注ロットとは、材料である「単品」の仕入単位である。発注は仕入単位である発注ロットを整数で示す。

入荷日を変更することが可能である。



⑩_1 回収・クレジットカード顧客は得意先登録時にクレジットカードの決済を申し込む。

回収先は、クレジットカード会社



⑪_1 入荷実績・支払処理入荷の実績情報で仕入先に支払処理を実行

手順

1. コード体系を見つけよう！

画面･帳票･ファイルレイアウト・・・ヒントになるものは、いろいろある・・・

2. コードが新たに追加される刹那、共に発生するデータ（この場合は『値』）をコードと共にグルーピング

値 ⇒ どんな種類の値なのか？値の種別をズバッと一言で説明する詞 → 『メタデータ』を見つけたコードと共に籠盛にする・・・リンゴはリンゴ、ミカンはミカン

3. 集めたメタデータに次の関係が成り立つか、検証しよう

コード⇔データ 1:1に対応

データ⇔データ相互に独立した存在

4. よし、エンティティにしよう！

エンティティは業務の事実の対応する

エンティティ同士の依存関係も業務の事実に対応する


さぁ、はじめよう！ T字形データモデル


コード体系を見つけ、選ぶ

※「花束問題伝票V1.0-1」より

お客様（得意先）ID＝メールアドレス花束コード花コード加工指示書発注番号（得意先）

仕入先棚番花束レシピコード発注番号（仕入先）

コード体系を付与して管理したいものもある・・・

ちょっと蛇足・・・


データ・タイプ（型）

数値 numeric

文字 varchar

日時 timestamp

連番 serial

美しいERダイアグラムを描くために

1. 紙面は横長にツールに頼らず先ずは手書きを経験しよう

手を動かして、考えて、形を見て、また手を動かす・・・これぞ上達の早道！

2. 紙面上下にリソース系エンティティを配置リソースでイベントをサンドウィッチや～

3. イベント系エンティティは中央に、左から右に時間の流れを意識して配置しよう

リレーションシップをエンティティ間に張ることを意識して、どのような配置が線の交錯が少なくなるか考えながら、もちろん、矩形の大きさも工夫して！

4. 留意すべきは対照表とサブセットの置き場

エンティティをキッチリ隙なく配置すると、対照表やサブセットの置き場がなくなるので、意識してある程度の隙間は残しておくこと

※ データモデルについて、その作成過程において技術を強調する人たちがいるが、ちょっと考えればそんなもんぢゃないことくらい、速攻でわかるよねェ。

※ 書き慣れる！そして、一度書いたものを推敲し、なぜそのように紙面に表現されたのかを考察する！当たり前に描いたものの常識を疑う姿勢を忘れずに


さあ、エンティティをつくってみよう！


論理名物理名データ型桁 Key Null 初期値メモ

得意先 Customer

得意先-識別 customer_seq serial PK 不可得意先コード customer_code varchar 6 不可得意先-氏名 customer_name varchar 10 不可得意先-氏名（かな） customer_kana varchar 20 不可得意先-おところ customer_address varchar 40 不可得意先-郵便番号 customer_zip numeric 7 不可

得意先-連絡先 customer_phone varchar 11 不可

エンティティをつくろう



クレジットカード Card

クレジットカード番号 card_num numeric 16 PK 不可サイン card_signiture varchar 40 不可有効期限-年 card_goodthru_yy varchar 2 不可有効期限-月 card_goodthru_mm varchar 2 不可

セキュリティコード security_code numeric 4 不可

VISA_CVV2

Master_CVC2

Diners_securitycode

Amex_CID

国際ブランド Cardbrand

国際ブランド種類 brand_type varchar 10 不可

得意先アカウント Customer_account

得意先アカウントID custacct_id varchar 30 PK 不可メールアドレス

得意先アカウントパスワード Customer_account_pass

得意先アカウント-パスワード-識別 custacct_pass_seq serial PK 不可得意先アカウント-パスワード custacct_pass varchar 30 不可

得意先アカウント-パスワード設定日 custacct_pass_date timestamp




仕入先 Supplier

仕入先-識別 sup_seq serial PK 不可仕入先コード sup_code varchar 10 不可仕入先-名称 sup_name varchar 10 不可仕入先-名称（かな） customer_kana varchar 20 不可仕入先-所在地 sup_address varchar 40 不可仕入先-郵便番号 sup_zip varchar 7 不可仕入先-連絡先 sup_phone varchar 11 不可仕入先-メールアドレス sup_mailaddr varchar 30 不可

仕入先区分 sup_type numeric 1 不可 2 0:農家/1:問屋2:その他




仕入材 Material

仕入用資材-識別 material_seq serial PK 不可仕入用資材コード material_code varchar 10 PK 不可仕入材-品名 material_name varchar 20 不可仕入材-和名

仕入材-最小単位 sku numeric 4 不可

仕入材区分 material_type numeric 1 3 不可 20:生花/1:生花以外の花2:

小物･包蔵材等/3:その他

品質保持可能日数 term_sell_by_date numeric 3 不可産地 production_center varchar 20

発注ロット unit_purchased numeric 4 不可主材フラグ import_flag numeric 1 0 0:副資材/1:主材料

輸入フラグ import_flag numeric 1 0 0:国内/1:輸入

花 Bloom

花-識別 bloom_seq serial PK 不可

花コード bloom_code varchar 10 不可

副材料 Secondary_Material

副材料-識別 secondary_mat_seq serial PK 不可

副材料コード secondary_mat_code varchar 10 不可




花束 Bouquet

花束コード bouquet_code varchar 10 PK 不可

花束説明 bouquet_descr varchar 50 不可

花束レシピ Recipe

花束規格-識別 recipe_seq serial PK 不可材料-使用量 recipe_quantity numeric 4 不可

材料-使用原価(D) recipe_cost numeric 6.1

花束価格 Bouquet_Price

花束価格-識別 bouquet_price_seq serial PK 不可花束価格-上代 bouquet_list_price numeric 8 不可花束価格-下代 bouquet_wholesale_price numeric 8 不可花束原価(D) bouquet_cost numeric 8 不可

花束価格-有効日 bouquet_price_effv_date timestamp 不可 sysdate

仕入単価 Purchase_Price

仕入単価-識別 purprice_seq serial PK 不可仕入単価 unit_purprice numeric 6 不可

仕入単価-有効日 purprice_effv_date timestamp 不可 sysdate




加工指示 Production_Order

加工指示番号 po_num numeric 5 PK 不可加工指示-発効日 po_date timestamp 不可 sysdate

加工指示-数量 po_quantity numeric 3 不可

加工指示明細-花 Production_Order_Dtl_b

加工指示明細-識別 po_dtl_seq serial PK 不可

材料-使用量（D) po_quantity numeric 3 不可

加工指示明細-副材料 Production_Order_Dtl_s

加工指示明細-識別 po_dtl_seq serial PK 不可

材料-使用量（D) po_quantity numeric 3 不可




顧客受注 Customer_Order

顧客受注番号 cust_order_num numeric 5 PK 不可顧客受注-受注日 cust_order_date timestamp 不可得意先-氏名(D) customer_name varchar 10 不可得意先-氏名（かな）(D) customer_kana varchar 20 不可得意先-おところ(D) customer_address varchar 40 不可得意先-郵便番号(D) customer_zip numeric 7 不可

得意先-連絡先(D) customer_phone varchar 11 不可

顧客受注-明細 Customer_Order_Dtl

顧客受注-明細番号 cust_order_dtl_num numeric 5 PK 不可出荷予定日 sched_ship_date timestamp 不可花束説明(d) bouquet_descr varchar 50 不可顧客受注-受注数量 cust_order_quantity numeric 2 不可届け先-氏名 consignee_name varchar 10 不可届け先-氏名（かな） consignee_kana varchar 20 不可届け先-おところ consignee_address varchar 40 不可届け先-郵便番号 consignee_zip numeric 7 不可届け先-連絡先 consignee_phone varchar 11 不可

荷主-メッセージ consignor_mesage varchar 50




仕入発注 Purchase_Order

仕入発注番号 pur_order_num numeric 5 PK 不可仕入発注-受注日 pur_order_order_date timestamp 不可仕入先-名称(D) sup_name varchar 10 不可

仕入先-所在地(D) sup_address varchar 40 不可

仕入発注-明細 Pur_Order_Dtl

仕入発注-明細番号 pur_order_dtl_num numeric 5 PK 不可入荷予定日 sched_rcv_date timestamp 不可仕入単価（D) unit_purprice numeric 6 不可仕入発注-数量 pur_order_quantity numeric 3 不可

仕入発注-仕入材合計(D) pur_order_item_amt numeric 5

棚 Shelf

棚番 Active_address numeric 5 FK 不可

リソース/イベントの見分け方

ざっくり見分ける方法として1. コード体系（個体指示子）を持つエンティティは、その名称に『名詞』を冠する

2. この名詞にサ変が有効に機能するかを検討する

i. 未然、終止、仮定の活用が自然な詞として聞き取れる場合、そのエンティティは『時による変化』を性質として内包している。

ii. 未然

① 請求させず請求させない請求させぬ

② 顧客させず顧客させない顧客させぬ

③ 商品させず商品させない商品させぬ

iii. 終止

① 請求する請求ス

② 顧客する顧客ス

③ 商品する商品ス

iv. 仮定

① 請求するとき請求すれば

② 顧客するとき顧客すれば・・・＞コピュラかぁ？

③ 商品するとき商品すれば・・・＞ぢゃ、俺はうなぎね！的な…

『在庫』について

在庫させず在庫する在庫するときと言う言い回しは聞きなれている。が、しかし、.．．．

在庫を持たせず在庫を持つ在庫を持つときが正解～い！個体指示子もないし・・・よってNG


ERダイアグラム


『在庫』エンティティがない！


そもそも、在庫はエンティティではありませんが・・・先に掲示したデータモデルをご覧いただくと判るとおり、在庫と名づく矩形

が・・・ない！ T字形ERモデルでも、TH法でも、在庫は一般とエンティティと違った扱いをする

そこで、在庫について簡単に解説しておきたい

やっぱりね残りものには訳がある

【出典】#女子会川柳

在庫の推移問題


2/18 2/19 2/20 2/21 2/22 2/23

在庫（＋）

在庫（－）

オーダーオーダー入荷


オーダーオーダー










200 200

90 180 160 40 50 30

80

80 190 10 4050 10 10

引当済

在庫の状態問題


在庫（＋）

在庫（－）

入荷

検品

入庫

返品

返品検査

戻し

返品再送

仕入先返品

出荷

取置き

保留

在庫総数

移動数

引当不可

総在庫数から引当不可を控除したものが引当可能在庫

在庫をデータモデルで表現すべきか！


在庫は「今現在の・・・」といった推移と状態の性質を内包している

『今』の一つ前の『今』との間で在庫は変動するでは、『今』と一つ前の『今』をどうやって定めるのか！？

在庫の『静状態とは・・・』に定めないと、一つ前の『今』が定まらない月締めの在庫残高を調べるために『静状態』を設ける…

業務後に棚卸しを実施するために『静状態』を設ける…

期末決算のために『静状態』を設ける…

※「業務の事実」を捉えるデータモデルを作るうえで、制度上の要求を無視することはできない

※但し、事実の捉え方が刹那的な場合、確認に至らない事象（事態）に範囲を拡大して捉える覚悟が必要だ

在庫を描いてみよう


設問在庫とは・・・を考えて、在庫を構成するデータ要素（項目）を列挙せよ。但し、この場合の在庫とは、任意の材料を対象にしたものである。

解答欄

付録４

ツール紹介


手法・ツールのご紹介

BPEC

BPデザイナーズ http://www.bp-designers.com/about_bpec.html

sdc紹介ページ http://www.sdcj.co.jp/bpec/index.html

楽々Framework3住友電工情報システム http://www.sei-info.co.jp/framework/framework3_top.html

sdc紹介ページ http://www.sdcj.co.jp/rakrak_framework3/index.html


http://www.bp-designers.com/about_bpec.html

http://www.sdcj.co.jp/bpec/index.html

http://www.sei-info.co.jp/framework/framework3_top.html

http://www.sdcj.co.jp/rakrak_framework3/index.html

Coffee Break !

『都』と『大阪』の『鉄』事情総延長 / 利用者数

東京地下鉄株式会社（旧帝都高速度交通営団） 195.1km

10,404,188 人/日

東京都交通局（都営地下鉄） 109.0km

2,456,882 人/日

大阪市交通局（地下鉄・ニュートラム） 129.9km

2,193,000 人/日

初乗り

JR東日本 133円 140円

JR西日本 120円

東京地下鉄（東京メトロ） 165円 170円

都営地下鉄 175円 180円

東京メトロとの乗り継ぎそれぞれの運賃の合算額から70円引

大阪市交通局 180円

バスとの乗り継ぎ 290円

都営地下鉄と同じぐらいの規模で料金も同程度。

大阪市民267万人。一方、東京特別区（23区）の人口は907万人。都民は1339万人。経済規模の差は大き

い。インフラに効率を求めるだけではスープラである経済に高効果を齎すことは難しい。視点はインフラが経済に齎す効果。さて、大阪に居する方々は、どうお考えですかな？・・・『都！構想』


付録５

方法論の根拠など


モードモダンモデル

語源：modus 意味は『方式・手法』

1. モード

方式・手法が最も頻繁に、あるいは顕著にみられる状態を示す、という意味がある

2. モダン

時間の流れから方式・手法が継起し、それが今に至る、という意味がある

3. モデル方式・手法を模倣する、という意味がある

1252015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd

認識に関する考察

アプリオリ経験から隔絶した絶対的認識。例外なく絶対的な普遍性 →必然性

アポステリオリ経験的認識。積み上げた経験から導き出される機能的普遍性 →妥当性

分析的判断主語概念を述語で説明するのみ。既知概念に限られる →解明的判断

総合的判断与えられた主語・述語概念を総合して認識を拡張する →拡張的判断


フレーゲの数学に対する認識

アプリオリ・アポステリオリ/分析的判断・総合的判断の区別を、

『判断の内容にではなく、判断を下すことの正当化に関係』にあると主張した

数学的真理は、幾何学的真理と算術的真理の２つにより成り立つ

幾何学的真理

算術的真理

空間にある図形の真理性の証明は直観が根拠となる →総合的判断

厳密な証明による。少数の原初的真理に遡ることができる

公理これ以上論理的推論を重ねても証明不可能な原初的真理公理は、定義を用いて自明な命題をつくることができる

定義意味が未確立な言語・記号を『意味の約定』により公理に使用根本命題とは、公理を表現するもの


佐藤師が示したモデル概念

指示関係（F-真）

現実的事態文

（構造）

意味

語彙

意義

合意

文法（L-真）

現実的事態モデル解釈者

指示関係（指示する）表現関係（表現する）

意味関係（意味する）

出展：『SEのためのモデルへのいざないデータモデルとは何か（佐藤正美著 SRC ）』


形式意味論の世界観

文の指示対象である事態は、その文が真（または偽）になる条件（真理条件）を備えていると考える

文は、可能性、必然性、条件による妥当性をも表現するため、形式意味論は「可能世界」にまでその論点を拡張することになる

可能世界意味論では、指示対象と文の関係が論理的に可能な状況全体を対象とする

可能世界とは、文が指示対象に対して「真」をとる事実の集合である

形式意味論の目標は、世界で成立している事態⇒事実を規定するモデルを追求することにあり、そのために言語（による表現）と対応関係を扱うことを基本とする


イディオムの問題

任意の単語であっても、組み合わさることで（一定の配列をなすことで）単語に準ずる形態素や表意性を持つことがある

慣用句として観察されるこうした言語表現をイディオムという。イディオムは文化的、社会的背景の下、用例と意味が固定しており、字面を負って解釈することはできない

イディオムは、使用する者たちの間で文化的、社会的背景をあるレベルで共有していないと解釈や理解が進まない

言語－文字（たとえば単語）においても、このような解釈と理解の問題は存在する。自然言語と形式意味論の問題は、言語表現として言語－文字の捉え方にある

形式意味論では、言語表現は記号として処理（真偽判断）され、一方、自然言語による表現（たとえば会話）は、意味の伝達に理解の主目的が置かれる


認知科学における意味の問題

鯖を読む

鯖を読む：都合のいいようにごまかすこと

経験により連想する詞には意味に違いがある。認知科学では「心の問題」という

結びつかない詞の組み合わせに意味が載る


さて、・・・

ゴットロープ・フレーゲFriedrich Ludwig Gottlob Frege

ルートヴィヒ・ヨーゼフ・ヨーハン・ウィトゲンシュタインLudwig Josef Johann Wittgenstein

アルフレト・タルスキAlfred Tarski

ドナルド・ハーバート・デイヴィッドソンDonald Herbert Davidson

ルドルフ・カルナップRudolf Carnap

カール・ライムント・ポパーSir Karl Raimund Popper


T字形ER手法のモデル論

命題の記号化

真理関数･真理表

恒真文

『何でもあり？』

のシステムを創造

する

T規約x∈

Tr

で

あ

るの

は,P

と

き,

ま

た

そ

の

と

き

に

限る

生成規則･指示規則

第三世界の自立性

開発から保守に至

るSE

の本分

『モデル』の前提

「在庫が１つある」を” P”とする

出展：『SEのためのモデルへのいざないデータモデルとは何か（佐藤正美著 SRC ）』


あれあれ・・・

対象言語の二値性メタ言語が対象言語の文を全く含まないこともある！

「私」や「ここ」、「今」といった指標詞(indexicals)を含む文

「今、ここに在庫は１つあります」

この文を見ると、いくつものシーン、在庫状態が考えられる。発話者と対話は、どこで、いつの在庫について会話しているのか？今とはいつ？どれくらい経過しても今なのか？・・・

「雪は白い」

そもそも真理条件を与える試みが意味をなさない

その状況に応じて、この文の発話、あるいはこの文の命題は真になったり偽になったりする

「白」「雪」

雪さんとの会話を隣で聞いていたら・・・お正月、初雪を愛でる・・・


付録６

ビジネス検討


『届け先にｎ種類の花束を贈る』検討


『加えてイベントにも対応』検討


付録７

データモデルとプロセスフロー


1995年3月のできごと

今から長い『枕』を記述します。

阪神・淡路大震災のあった年、小生は外資系アパレル企業の情報システム部に所属していた。当時、佐藤正美氏に師事し、データモデリングを勉強中であった。あれは、3月20日の朝。出勤すると携帯電話の着信音が鳴った。何かと思いディスプレイを見ると、親友からの電話だとわかり応答した。「おい、大丈夫か？」「え?!」「地下鉄恵比寿の駅で大変なことが起こっているぞ！体は大丈夫か？」「俺は、地下鉄つかってないから大丈夫だが、いったい何があったんだ？・・・」地下鉄サリン事件を知ったのはこのときだった。

同僚が日比谷線を利用していて「今日は霞ヶ関の駅に止まらず通過したんだ。時刻表から遅れていたものだから、急行運転に切り替えたのかと思ったよ！地下鉄でも急行運転することあるんだな！ん？・・・冗談だよ、何か異常があったとおもったよ！」

営業部の女性社員が被害にあった。サリンの影響で瞳孔が収縮し、暗いと訴えていたと後で知った。

グルによる魂の救済、積極的に死をもたらすことで意識を神の次元へと移し変える・・・このような教義を真剣に受け止め、従った若者がいて、それを指示した教祖がいた。地下鉄サリン事件、その前をさかのぼれば松本サリン事件。常軌を逸したカルトの教義に端を発する悲劇を今も私たちは目にするのである。

当時、子供たちは幼く、サリンがどんなものかもわかっていなかったようで、帰宅した小生に何を聞くでもなし、父親の心配をするでもなかった。その日、こんな家族の対応に、これだけ数がいるのに俺のことなど誰も気にもしないのか！と、正直がっかりもした。しかし、後になって事実が露見するにつれ、組織的で計画的な大事件の構図が報道で徐々知られるようになり、罪もなく関わりもない命が一方的に奪われたのだとわかると、子供たちにはこのままわからないほうがよかったのだと思えてきた。

今も後遺症に苦しむ人々、遺族の皆様の心痛ははかるに余りある。

この未曾有の事件を引き起こしたカルト教団は、後に山梨県内で大規模な捕り物が勃発し、司直の手によって教祖をはじめとする多くの幹部に極刑判決が言い渡されたれ、刑が確定した。周知の通りである。そして、この事件を契機に『テロ』と言う詞が定着し、駅からはゴミ箱が撤去された。

話し変わって、時は元禄16年、春まだ浅い2月4日。亡君の敵、吉良上野介を討ち伊予松山藩松平家にお預けとなった大石主税良金は16歳。この日、将として松平家お預け10名の先として切腹した。この切腹を命じる前、ときの将軍綱吉は、上野寛永寺輪王寺門主公弁法親王に意見を

求め赤穂義士の助命を模索したが、若い者が後の人生で道をはずれ、この名誉が泥にまみれぬよう腹を切らせよと諭されたと言う。先んじて名誉の死を与えることこそ武門の誉れ！と。

人生を完全に遂げることの意味を考えさせられる。他人が決めた道理によって、他人により齎された死を受容れることが、私たちにとってどんな意味を持つのだろうか。このような死はあまりにも不合理であり、見方によっては安直だ。これが日常というこのなのか。・・・あるいは異常と言えるのか・・・


今度こそデータと業務プロセスとの関係?!

1. 業務プロセスを中心に、業務の手順やその過程を分析してシステム開発に取り組む手法をプロセス中心アプローチ（POA：冗談交じりにポアとい

う人もいる）という

2. DOA（データ中心アプローチ）に携わる一部の人たちにPOAを対極と見做す向きがある

既に、エンティティ･ロールで解説したとおり、データモデルによる業務プロセスのモデル化の可能性を提示した

3. DOAは業務プロセスをどの程度分析することが可能なのか？

4. データモデルで業務プロセスを分析することに利点があるのか？

5. そもそも、エンティティ･ロールはPOAではないかと言う意見･批判

6. 業務の事実から『あるべき姿』を導き出すとは


3, 4 について、論じてみようあとは論点が異なるのでこの場で論じない

POAの特徴

1. 業務のモデリングを実施する

2. 業務プロセスに見合ったデータ構造を設計する

3. 特定業務を短期間に設計・実装することを目指す

4. よって、業務プロセス実現のための機能を重視した要求定義・設計プロセスを経る


プロセスフローモデルとは？

一言に『業務モデル』といっても様々な種類がある

1. 業務プロセスと称しながらデータフローを描くモデル

2. NOMA方式のプロセスフローモデル

3. BPMNのプロセスフローモデル

4. BPECによる業務階層図…

5. UML ユースケース

6. UML アクティビティ･ダイアグラム


プロセス中心と業務モデル


3, 4 について論じてみよう

DOAは業務プロセスをどの程度分析することが可能なのか？

一般的にERモデルは、エンティティの関連をリレーションとして表現する。ER

モデル上では線にあたる。エンティティ間の結線はキー（KEY）に由来する

KEYはエンティティの中にあり、一意制約キー（Unique Key）と参照キー

（Reference key）に分かれる

任意のエンティティに配置された同名のKEYをリレーションで結線する

KEYによりエンティティとリレーションシップは成立する

それでは、エンティティ、リレーションシップ双方の成立に拘る

KEYの束縛から解放されたなら、ERモデルはどうなるのだろう

か？

DOAによるは業務プロセスの分析可能範囲


カードキー社員

社員コード. 氏名生年月日住所メールアドレス

製造番号

R R

社員・カードキー･対照表

社員コード(R)

製造番号(R)

有効化年月日有効/無効区分無効化年月日

TS

有効なものは１個の社員コードにカードキー1枚

カージナリティが n:m になる理由は、社員が複数枚カードキーを手にすることが考えられるため。

業務の事実の存在を示すコード体系（個体指示子：Identifier）と個々のデータを識別するKEYは、夫々が異なる目的を持つ。よって同じ視点で論じられない

但し、コード体系を主軸にデータモデルを作図 / 推敲する場合でも、その実は『KEYの束縛』に似た制約に煩わされる

その束縛とは、ズバリ『一意性』！一方、業務プロセスの分析では、一意性に注視することは先ずない

T字形ERモデルで分析できる業務プロセス


データモデルの分析主題はキーによるエンティティとリレーショッ

プの生成、その結果のデータ構造の提示にある

もし、KEYではなく『業務の事実』のエビデンスであるコード体系

を分析対象にしたら、業務プロセスをどこまで分析できるのか？

コード体系自体の分析でわかること

複合コード

ばらす / 掛け合わせる

同一コード体系内の種類

実業務視点 / 分析業務視点

コード体系と共に発生するデータの分析でわかること

まとめる / 引き継ぐ

共に生まれる / 後から生まれる

T字形ERモデルの各要素とプロセスの対応

コード体系自体の分析でわかるプロセスに関すること

複合コード

ばらす

掛け合わせる

同一コード体系内の種類

実業務視点

分析業務視点

コード体系と共に発生するデータの分析でわかること

まとめる / 引き継ぐ

共に生まれる / 後から生まれる

何かを確認する / 種類にしたがって結果が現れる


最小単位の『事実』を見つける

リソースの場合、対照表に該当

スーパーセット･サブセットに該当

区分･種別 / データ再利用・並べ替え

イベント/ 対照表 / 対応表に該当

エンティティ / VEに該当

エンティティ･ロール

データモデルで業務プロセスを分析すること


3, 4 に論じてみよう

データモデルで業務プロセスを分析することに利点があるのか？

プロセスフローモデルによる業務プロセスの分析では、その対象を概略⇔詳細に層別するケースが多い

また、ダイアグラムの作成過程で、プロセスを度々追加 / 削除する柔軟性がある

プロセスフローモデルは、プロセスの動性をコマ撮りしたスナップショット業務フローの軸とは、業務に携わる人？組織が担う役割？写像したモデル

の分析目標は？

データモデルで表現できないものをプロセスフローは表現していると仮定すると、データモデルにとって業務プロセスフローは必要なパートナーだと考えられないか？

では、データモデルでは表現できないものとはなにか？

プロセスフローの特徴

1. システム開発者の目は、業務の『関係者』と『手順』に着目し、『業務や作業』を『機能』として捉える

機能は、設計が必要。よって基本的な設計を施した後、機能を部品化することは可能（楽々Framework3が実現）

T字形ERモデルのリレーションシップは『手順』を示している場合もある

しかし、リレーションシップはそもそも『キーの束縛』の影響下にあり、手順を表現するものではない

2. また、分析対象となる業務を『概略⇔詳細』に層別するケースが多い

データモデルでは、概念モデル⇔論理モデル⇔物理モデルを描き分けることはあるが、業務階層の層別を示したものではない

3. データモデルは機能遷移/ 分岐を表現することに向いていない機能遷移 / 分岐がわかっていればデータモデル上のエンティティ等を指し示すこ

とはできるが、データモデルに描き込むことは困難

4. 前述の『業務や作業』の階層をデータモデルの表記法を使って表現することは可能である（以下、参照のこと）

ハンドノート業務階層図における『役割と種類』

ハンドノート業務階層とAP機能の関係

付録１David C. Hay のモデル業務階層図の構造


データモデルと業務プロセスフローの関係

1. 業務の事実を捉えるのに、データモデルとプロセスフ

ローモデルは相互を保管しあう関係

2. データモデルでは、次の事柄をダイアグラム上に表現

することが難しい

データモデルで表現が難しいのは、業務の手順、業務

の層別（概略⇔詳細）、そして機能遷移 / 分岐である

また、『主管組織』『担当者』『タイミング（ランダ

ム / 日に一度 / 月に一度など）』をアトリビュートリス

トに記載することはできるが、ダイアグラム上に表記

することがない


付録８

正規化問題


正規化


正規化とは

正規化を例えてみれば、フルーツバスケットの中から『リンゴ』『梨』『桃』『苺』『ラズベリー』を選り分け夫々の籠に盛ること

1. 第1正規形では、同一の情報のグループが繰り返し出現している部分を分離する

2. 第2正規形では、複合主キーと関数従属関係をもつ属性を分解、分離し、分解した表のキー項目（外部キー）を定義する

3. 第3正規形では、第2正規形から主キー以外の属性の相互依存関係を検証し、従属性が認められるものを分離し、分解した表のキー項目を定義する

4. 特に外部キー（T字形ERのでは『リユース：（Ｒ）』）を検討（T

字形ER手法では検証となる）する


関数従属とは

1. ボイス･コッド正規形

ボイス・コッド正規形は、非キー属性間で関数従属性を許さない第3正規形に加えて、候補

キーを構成する属性群の中に候補キー以外の属性が決定項となる関数従属性をも許さない。

2. 一意性を担保する最小の構成（…Minimal）の主キー

非キー属性から主キー⇒そのインスタンスは1:1 関係が検証されている

たとえば市区町村なるエンティティを切り出したとき、『西区』は大阪市、堺市、神戸市、

名古屋市に存在する。つまり『区』と『都道府県』では、『西区』を一意に引き当てられ

ない。


区市

区県

◎

×大阪府内には、大阪市と堺市に西区があるため、県レベルではズバッと一つに言い当てられない

県

271004 大阪市

281000 神戸市

271403 堺市

231002 名古屋市

27000 大阪府

28000 兵庫県

27000 大阪府

23000 愛知県

271063 西区

281115 西区

271446 西区

231045 西区

バイナリ方式で・・・


271004 大阪市

281000 神戸市

271403 堺市

231002 名古屋市

27000 大阪府

28000 兵庫県

27000 大阪府

23000 愛知県

271063 西区

281115 西区

271446 西区

231045 西区

区市◎ 県

区市

市県バイナリ

バイナリ

バイナリ

T字形ER手法では、リソース系エンティティのリレーションシップをBinary

方式で表記し、N-Aray方式を禁じている（対照表により推移的関数従属性を表出させている）

バイナリ分析の問題点



県市区


県コード(R)

市コード(R)

区コード(R)

都道府県名(d)

市_名称(d)

区_名称(d)


県コード(R)

市コード(R)

市・区・対照表

市コード(R)

区コード(R)

R R R

TS TS

TS結局、この対照表だけあれば事足りる・・・

ある試験問題からの考察

正規化は問題視されるべきなのに、データベース設計の免罪符になっている。まずは、この問題について考えてほしい

出典：http://www.fe-siken.com/kakomon/21_haru/q32.html

基本情報技術者試験ドットコム

午前問32

"従業員"表を第3正規形にしたものはどれか。ここで，下線部は主キーを表す。従業員 (従業員番号，従業員氏名，{技能コード，技能名，技能経験年数})

({ }は繰返しを表す)


（ア）

（イ）

（ウ）

（エ）

従業員番号従業員氏名

技能コード技能名技能経験年数

従業員番号従業員氏名技能コード技能経験年数

技能コード技能名

従業員番号技能コード技能経験年数


技能名技能コード

従業員番号技能コード


技能コード技能名

技能経験年数

http://www.fe-siken.com/kakomon/21_haru/q32.html

問題提起

簡単な設問なので解答に関する解説の要を認めないも

のとし、ここではとりわけ正規形について議論したい

（正解は、前述のサイトで確認できる）


正規化

『視点』が一定に定まらない情報を同時に扱っている！

先ず、一言申し上げておきたい。出題者に対する筆者の敬意は衷心からのもので、これから展開する議論に設問云々の意図はまったくない

筆者がこの設問に感じる疑問を以下に提示したい。論点は、この設問から答案を導き出している受験者諸氏が受けた教育、与えられた知識に違和感を感じざるを得ないという筆者の直覚である

この設問では『技能の認定は個人に与えられるものである』という前提が蔑ろにされている。情報の整理において、起点の置き方に問題があるのではないか？

この設問の前提には、個人が組織に所属する関係（端的に言えば雇用関係）を解消した時点で、技能の管理を行わないという根本的な問題を孕んでいる

組織が展開する事業が組織に所属する役職員のみで賄われているとは、今のご時勢とても考えられない。組織が有資格者、有技能者の管理を行う理由は、事業展開において、有資格者、有技能者の存在が必須の案件に対応するためと解釈すべきだ

事業から業務へと視点を移す際、業務の事実を分析する手法としてモデリングを選択したならば、有資格者、有技能者を組織の帰属によらず管理すべきと解釈するほうが理に適っている

そう考えると、この設問の問題点は、異なる視点のモノ（事実）をひとつの考え方（情報の整理の仕方）に嵌め込もうとする点にあり、偶々『正規化』について問う問題だったため、正規化とは既に論じた『一意性の束縛』の下にある機械的作業に他ならないとのメッセージを発していると結論することができる・・・（言掛り、粗探しとの批判を承知で）


正規化と事業･業務の間に存在するギャップ

正規化を考えることが事業･業務との間に矛盾を生じる

具体的には、技能コードから『技能』エンティティを形成しているが、事業･業務上の視点から、資格の価値、有効性をどのように捉えるべきか？

一方、正規形はデータ構造を可視化するための手法である。その核心部にあるのが関数従属性

では、事業、業務を支援するシステムを構築するための技術とはなにか？


論点の提示

1. One fact in one place

2. 実装独立と実装従属


One fact in one place

1. “One fact in one place”は、データモデリングの原点ともいえるルール。データモデリングは、”Onefact in one

place”の実現に、キーに対する関数従属性という方法を見出した

2. 個人的経験になるが、”One fact in one place”と聞くと、その重要性を提示してくれた真野正氏と議論を交わしたことを思い出す


実装独立と実装従属

1. 椿正明氏が提示した考え方で、筆者は意味論モデルの根底にある思想だと考えている

2. 対向に実装従属と言う考え方がある。正規化は実装従属段階で適用する手法である

3. システム構築の手順としては実装独立から実装従属に仕様の詳細化が進む


T字形ER手法では

1. One fact in one place

正規形を意識せずに正規化相当の成果を得ることは、形式意味論の適用で可能

佐藤師は形式意味論の可能性に強く惹かれたと筆者は直覚する

T字形ER手法は、コード体系の分析で形式意味論によるアプローチを実現する

2. 実装独立と実装従属 T字形ER手法では、データモデルであるT字形ERモデルとキー

をテーマとしたインデキシング設計を分ける。データの実装対象がリレーショナル･データベースであるため、データ格納方式とデータ検索方式をセットにした考え方だ。

インデキシング設計は実装従属の分析に含まれる


真野正氏の著書


真野正 ITコンサルタント

株式会社データアーキテクト代表取締役

HP: http://dataarch.co.jp/

http://dataarch.co.jp/

付録９

スーパーセット / サブセット


なにもかも

ひとつの民が世代を越えて文化、言語を他国で維持することはきつい。

東北地方には様々な神が祀られ、祭祀をまもる地域の伝統、神楽などの歌舞音曲、食、作物、自然、言葉といった文化が里と

強く結びつき、営々と時を経て継承されてきた。福島県内の一部の里では、今までの当たり前、将来も変わすにあるはずの生ま

れながらの生活が、風景が、ブッツリと断絶したのだ。

2000年にわたり途絶えていた言語を復活し、日常言語として教育を受けこれを母語として使う人を育てるという人類史上初め

ての事業を成し遂げた民族がある。この民族は彼らの信仰のなかで神から約束されたとされる地に、現在約806万人の国家を形成

している。彼らは、信仰と文化を守るために約束の地に帰ることを民族の悲願としていた。数十世代を重ねてのことだ。

福島県内のある神社の宮司が文化の断絶と悲鳴を上げた放射能問題。放射能汚染地域は、避難指示解除準備区域、居住制限区

域、帰還困難区域に分かれる。ことに帰還困難区域は5年を経てもなお年間積算放射線量が50ミリシーベルトを下らない地区であ

る。文化の継承は年々困難さを増すだろう。祭祀や文化に詳しいお年寄りたちの、残念ながら残された時間は少ない。

廃炉に30年。今40歳代の親が孫をもうける頃の話だ。ことに、原発に近い地は、既にふるさとの地を離れ、三世代目ともなれ

ば異地の文化に染まり旧地の文化の継承者としての資格を逸することだろう。

原発近くの里では、廃炉の作業が進む中で万一の事態が出来する可能性が否定できない以上、そこに住民が戻ることは許可さ

れない、とも考えられる。

震災直後、避難所に当てられたある学校の体育館に身を寄せていた、遠くを見つめるかのように、それでいて焦点の定まらな

い女性。母親なのだろうか。その姿を見て改めて言葉にできない恐怖、財産も、家族も、その人生で積み重ね、得てきた多くの

ものを失った体験者に対して掛ける言葉を持ち合わせない無力を感じたと吐露した現地調査担当者の、あの時の言葉と無力感に

充ちた表情を今も思い出す。泥描き部隊の一員だった小生は、このような場面に遭遇したことがなかった。夕食のとき聞きたこ

れらの言葉に、小生にとって強烈な衝撃となって突き刺さった。身を切られる思いとは、自責の念とは、小生が思っているほど

生易しいものではないことを知った。その悲痛があまりにも深く、いくら考えても想像することは小生にできない。

郷土を、家族を、生活の拠り所を失った民の心は、これからどこに向かうのだろうか。


Superset / Subset

花屋問題で作成したERモデル中に登場した相違のスーパーセット / サブセット


Superset / Subset

例えば、『花』の下層にさらにサブセットを設けることができる。


Superset / Subset

同一のスーパーセット / サブセット

i. 区分により２つ以上のサブセットが成立する要件を満たす

ii. したがって、エンティティ内のドメインはいずれも共通


i. 区分により２つ以上のサブセットが成立する要件を満たすケースがある

ii. エンティティ内のドメイン（構成ドメイン）が以下の点で相違するならば『相違のスーパーセット / サブセット』にする

① サブセット間でドメインの多少（異同）が分析される

② サブセット間のドメインに一見異同がないように見えるが、データの桁、型、名称（エリアス、シノニム、ホモニムをググってください）に異同がある場合※

SDI http://www.sdi-net.co.jp/news472.htm

※ DLCPで思い出すのが『Xupper』■参照いただければ！


http://www.sdi-net.co.jp/news472.htm

http://intelligencebox.net/?paged=2

蓋然性問題

1. 例では、個体指示子の『花･副資材コード』と『仕入用資材-識別』が3つある各々のサブセットに「唯一」且つ「一個」に分かれる

2. スーパーセットは、サブセットの全体を表す概念であり、集合x1,x2,x3の全体集合Xに相当する

3. T字形ER手法では、スーパーセットを蓋然的なレベルまで上げて、あえて表記することがある

※ ここで注意すべきは蓋然性問題は２点事態の蓋然性客体世界における事態成立の可能性

判断の蓋然性モデル作成者の判断による事態成立の可能性

即ち、客観的に「事実」を分析･可視化するべきモデルに主観的判断が混ざり込む可能性が生ずる

事態：花は生花とプリザーブド･フラワーの両方を仕入れる可能性がある

判断：花は、生花とプリザーブド･フラワーの両方を仕入れるにマチガイない！


付録１０

コード体系雑記


『コード体系』

組織による事業の取り組み、あるいは実務執行を『業務』と考えると、その内容を標準化すれば業務に関わる要員増や旧来よりも短時間で処理が可能となる。これは業務のキャパシティを増やすと言う議論だが、今は標準化を起点とした多様性への対応に関心が寄せられている。

標準化には３つの主だった要素がある。

情報交換規約（プロトコル）の標準化

用語・コードの標準化

フォーマットの標準化

例えば、総勘定元帳から有価証券報告書に転記するルールが情報交換規約の標準化、仕訳の仕方と勘定科目が用語・コードの標準化、帳簿の記載方法（記帳）がフォーマットの標準化。

コード標準化は、情報交換規約標準とフォーマット標準に欠かせない。紙媒体に記帳を考えると、コード体系が整備されていれば人が違っても検索も記帳も変更も可能だ。

ところが、帳簿がコンピュータに置き換わって、「一意性問題」が浮上した。コンピュータはある一定の手順を踏まないと何事も処理ができないという頑固者だ。そこで、コンピュータに認識させるための『一つ（一意）』を決めなければならない。紙ならば伝票に記載した届け先に赤線引いて間違った箇所を直すことがある。これは一枚の伝票に訂正書き込みしているだけなのだか、コンピュータの処理では通常訂正前と訂正後の２つのデータを持たせる。ここが人の持つ感覚と外れているところ。業務で使っているコード、番号、No.とは違った理由で一意を定める体系を『キー』と呼んでいる。

T字形ER手法の分析対象はキーではなく、コード体系である。一方、『一意性の束縛』の影響をコード体系も受ける。そもそもコード体系はインデックス（ここでは単純に『索引』）の役割を担っており一意性を担保するのは当然だといえる。この点に視線を合わせて正規化を検討すれば、コード体系でもなんら問題なく正規形を導き出すことが可能だ。複雑なのは・・


ブランド牛の価格と安全性の確認

推移的関数従属、部分的関数従属といったキー項目対非キー項目の正規化検証ルールにも顕れている粒度の問題。

「今日はスキ焼！」となれば、精肉店かスーパーマーケットで「どんな肉にしようかなぁ。奮発してブランド牛・・・グラム880円、これ、いくかぁ！」なんてこともあるでしょう。ブランド牛グラム780円はリブロースの薄切りの値段。880円はお得と思うかもしれない。そこで、貴君らはネットで他店の値段を調べるかもしれない。でだ、この肉の安全性が気になるかもしれない。そうなると、罹病の有無を調べたくなる。個体識別番号10桁が判ればこちらのサイト（https://www.id.nlbc.go.jp）のデータベースで検索することができる。手にした牛肉の値段と安全性とでは、貴君らが知りたいと望んだ情報に到達するための経路、情報管理の方法が違うことをご理解いただけただろう。

店舗Aが販売する牛肉のうち、Yというブランド牛のグラムあたりの値段を他店と比較す

るには・・・ブランド名と部位を選択して検索する

店舗Aが販売する牛肉のうち、Yというブランド牛の罹病有無を調べるには・・・個体識

別番号10桁をhttps://www/id/nibc.go.jpのDBで検索する

口にして美味く胃に納めて満足するだけのものに・・・牛の個体識別番号が10桁なんてことを貴君らの半数以上が知っていたとは到底考えられないのだが・・・


https://www.id.nlbc.go.jp/

https://www/id/nibc.go.jpのDB

Shopping!


店舗Xで売ってるすき焼用薄切り

http://members3.jcom.home.ne.jp/taichi329/ne-meat_page/ne-meat.html

http://members3.jcom.home.ne.jp/taichi329/ne-meat_page/ne-meat.html

Beef !


個体識別番号

罹患有無

関数従属云々のまえに

当該個体特有の属性情報を入手するための個体識別番号、一方、ブランドによって裏打ちされた品質と食味、販売店の消費者に対する付加価値である価格。この２つに個体識別による情報取得という動機を消費者が抱くことはまずない。

正規化系統の諸般資料を閲覧しても、その説明の中心が関数従属性におかれ、キー分析とDB設計に終止している。

T字形ER手法が着目するコード体系の分析では、例えば推移的関数従属がデータモデル上に現れる（既に対照表をバイナリ方式で表記することを説明した；p21-p23参照）。

T字形が『事実』に拘る理由を示す好例と考えている。

さて、議論をもう一度牛肉に戻そう。

買い物客が求める情報は次の２点

近くの店舗で売られているブランド牛の単価

その牛肉の安全性

ブランド牛の単価は、販売店、ブランド、部位が分かれば調べられる。一方、安全性を調べるには個体識別番号を知る必要がある。

個体識別番号を表示ラベルに載せているのだから、『個体識別番号による安全性を確認しました』と表示すればいい。表示ラベル上に価格と安全性の２つの情報が並ぶ。これをエンティティで表すべきか？・・・

ここで、販売店の視点を入れて、販売したものを個別管理すると仮定したなら、表示ラベルを管理対象にするか検討すべきだろう。

誰のためのシステムか混乱してきたが、データモデルを眺めながらこうした検討をするのがT字形ERモデルの目的になる。


ハンドノート t字形erモデル セミナー資料 (author; s.toriyabe systems design...

Technology

ハンドノート t字形erモデル　セミナー資料　(author; s.toriyabe systems design...