ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

ハンドノート
データモデリング参考資料
平成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
名称
期
記載年月日
金額
納品書
ID
名称
期
記載年月日
金額
請求書
ID
名称
期
記載年月日
金額
注文書
ID
名称
期
記載年月日
金額
検収書
ID
名称
期
記載年月日
金額
・・・・・…
周延しない・・・
周延に至らない外延を並べるケース
書類（モノ）の『存在』を強く意識すると、モデリングを誤ることがある
『モノ』に拘るのでなく、『事態』を見抜こう
 『納品』なる事態を業務の『事実』として確認できればエンティティとして存在する
 『請求』なる事態を回収業務の一形態として確認。よって、エンティティが存在し得る
・・・と

エンティティ･ロール問題
製品
品番品名
製品概要
・・・
品質基準
品質基準コード技術要件
達成基準
検品数
不適合品率
・・・
検品
検品No.
製造ロットNo.(r)
検品数
適合品数
不適合品数
不適合品率(d)
品質基準・製品・対照表
品質基準コード(R)
品番.(R)
有効化
有効化実行日
TS
R R E
検品･合否判定
検品No.(r)
適合判定拒否判定
合否区分
ER
エンティティ･ロールとは、任意のエンティティが業務と対峙したときに、その業務に内包される
ルールあるいはルールに基づく処理の発現方法を示す

エンティティ･ロール問題（続き）
検品
検品No.
検品数
適否区分
不適合品率(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店のような商売のそれは、料亭やレストランと根本的に違うのである。
長々と言葉を連ねてきたが、これが仮想エンティティの基本的考察である。即ち、元から管理対象としていないが、
ビジネスを推進する上で貴重なデータ資源と考えられると判明した事実の扱い方を思考した結果といえる。

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』■参照いただければ！

サブセットの分析
ここでは『注文』を例にとって議論したい
 一言に『注文』といってもいろいろな種類、形式がある
 補充用注文小売店在庫の補充
 特急注文客先から急ぎの注文
 先（日）付け注文投入時期が決められている商品の事前受注
 サンプル注文商品サンプルの出荷対応
 社販注文社員の福利厚生的意味合いの強い社内販売
 セット販売注文一定量の商品をまとめた販売でスロームービングが対象になる
 ＥＤＩ注文電子商取引ここではＥＯＳ
 ＦＡＸ注文文字通り
 手書き注文文字通り
 集約注文未出荷の同一顧客からの注文を出荷業務に合わせて集約すること
 分納注文受注数量に達しなかった場合、差分を後日出荷するための注文。
バックオーダー
 代理店注文代理店契約（問屋）を交わした顧客からの注文
 専門店注文直販店契約を交わした顧客からの注文
 直販店注文自社運営の店舗からの注文

注文を分析すると！
商
売
モ
ノ
売
り
方
お
客
は
問
屋
お
客
は
専
門
店
お
客
は
社
員
商
品
を
売
る
在
庫
移
動
し
て
在
庫
引
当
す
る
E
D
I
で
受
注
す
る
F
A
X
で
受
注
す
る
注
文
書
で
受
注
す
る
売
上
計
上
す
る
経
費
計
上
す
る
即
納
注
文
す
る
先
付
け
注
文
が
あ
る
先
付
け
の
有
効
化
完
納
が
あ
る
分
納
N
G
が
あ
る
分
納
が
あ
る
セ
ッ
ト
販
売
が
あ
る
補充注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
特急注文 ○ ○ ○ ○ ○ ○ ○ ○ ○
先付け注文 ○ ○ ○ ○ ○ ○ ○ ○
サンプル注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
社販注文 ○ ○ ○ ○ ○ ○ ○ ○ ○
セット注文 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
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

付録１
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
# 名称
○ 説明
PARTY
自然人
○ 誕生日
組織
○ 名称
法人
国際組織
自治体
社団
ひとつの例として接続される接続する
こちら側他方側

PERTY TYPE
# 名称
○ 説明
サブタイプ
として
スーパータ
イプとして
 識別に関する
考察
PARTY RELATIONSHIP
# 有効日
○ 期日
○ コメント
PARTY
RELATIONSHIP TYPE
# 名称
○ 説明
PARTY
自然人
○ 誕生日
組織
○ 名称
法人
国際組織
自治体
社団
PARTY
IDENTIFIER
# 識別子の値
○ 説明
○ 有効日
○ 期日
PARTY
IDENTIFIER
TYPE
# 名称
○ 説明
にある
識別される
発番される
発番根拠
掣肘する
管理される

PERTY TYPE
# 名称
○ 説明
サブタイプ
として
スーパータ
イプとして
 名称に関する
考察
PARTY RELATIONSHIP
# 有効日
○ 期日
○ コメント
PARTY
RELATIONSHIP TYPE
# 名称
○ 説明
PARTY
自然人
○ 誕生日
組織
○ 名称
法人
国際組織
自治体
社団
PARTY
IDENTIFIER
# 識別子の値
○ 説明
○ 有効日
○ 期日
PARTY
IDENTIFIER
TYPE
# 名称
○ 説明
にある
識別される
発番される
発番根拠
PARTY NAME
# 名称の値
○ 説明
○ 有効日
○ 期日
PARTY NAME
TYPE
# 名称
○ 説明
にある
表示される
掣肘する
管理される

業務階層図の構造
業務ロール名称
業務ロール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モデル表記とは異なります

最後に・・・
佐藤正美氏の著書を紹介
佐藤正美情報システム・コンサルタント
（専門領域: データベース設計）
1953年生まれ。
1977年早稲田大学商学部卒業。
1979年早稲田大学大学院商学研究科博士前期課程修了
（財務会計論専攻）
その後、アーサー・アンダーセン、等松青木監査法人および株式会社ア
シストを経て、1991年 1月独立（株式会社 SDI 設立）、現在に至る
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 不可 2
0:生花/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

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)を含む文
「今、ここに在庫は１つあります」
この文を見ると、いくつものシーン、在庫状態が考
えられる。発話者と対話は、どこで、いつの在庫に
ついて会話しているのか？今とはいつ？どれくらい
経過しても今なのか？・・・
「雪は白い」
そもそも真理条件を与える試みが意味をなさない
その状況に応じて、この文の発話、あるいはこの文の命題は真になったり偽になったりする
「白」「雪」
 雪さんとの会話を隣で聞いていたら・・・
 お正月、初雪を愛でる・・・

ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

Similar to ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan) (8)

More from 聡鳥谷部

More from 聡鳥谷部 (11)

Recently uploaded

Recently uploaded (10)