第四回 「T字形データモデリング手法」（2009/1/9）の個人的な講義録です。

なお、講師が講義内にて話した話し言葉を、なるべくそのまま書いています。
一部、省略したり整形した部分もありますが、リアルタイムでタイピングした講義録ということで、ご了承下さい。
正確な内容が知りたいという神経質な方は、次回のＩＴＡＡ研修を受けるなり、他の研修を受けるなりして頂ければと思います。

1枚目 9:40～

モデル（model）

基礎となった学論

• 数学基礎論
• 言語哲学

モデルの全体像

1. 生成規則（構造を作るための一般的な文法）
2. 指示規則（作られた構造が正しいかどうか）
3. 画法（diagramming）（お絵かき、モデルを図にすること）

生成規則=モデルと勘違いされやすい。

「その事業の制約・束縛」「ビジネス上の制約・束縛」「ユーザの制約・束縛」を、
一つも取りこぼすことなく、抽出することができますか？
=> 今まで苦しんでいたのは、実は正規化することではなく、制約・束縛を取りこぼさずに抽出することだった。

画法は、自分が使いやすい表記を使ってください。
こだわりたいのは画法ではなく、「網羅性」

「生成規則」->一般「手続き」として

• 網羅性（一つも取りこぼしがないこと）
• 検証可能性（抽出した要素が正しいかどうか）
• 事業を「正確に」記述する

関数

• 変換
• 対応

関数の例
y = f(x)
f(on) = 表示
f(120) = 1
f(4) = 250
関数とは、我々の業界で何を表すかというと

ブラックボックス（f）（論理法則・文法）に対してあるもの（x）をいれると、結果（y）が出てくる

「ある現実的な事態（事業過程、管理過程）に対するXX管理」
ある情報を渡し、意味を伝達し、形式的（論理法則を使って形成）

我々がモデルに対して勘違いしたこと

• モデルとは解釈だ、という勘違いをした（数十年前のSI業界）
  1. 現実的事態に対する解釈、と考えていた
  2. 作られた構造に対する解釈

「すでに現場で使われている情報のやりとり」「その事業特有の意味の伝達」は、SEが変えることの出来ないこと

• 現実的事態に対する解釈は、SEの仕事ではない。現場がやること。
  • 本当に現実的事態に対する解釈をしたい場合、SEが実際に現場に行って数年間経験を積まないと無理。

ユーザの言語を変形しないで、論理的な構造に直さない限り、「事業を正確に記述」することは出来ない。

ここで作られた論理構造が、本当に真なのか検証が必要。
出来る限り機械的に、一般手続きとして表現する。

作られた論理構造が正しいかどうか、どうやって検証をするのか

作られた論理構造を、現実の世界に対して当てはめてみることが大事。

ここで間違っていけないのは、
・ 作られた論理構造をユーザが保有する情報に当てはめてはいけない
ということ。
=>コンピュータ業界の人間は、ここを勘違いしている。

2枚目 10:20～

何を持ってあなたがやった仕事が「正しい（真）」とするか。

「真」とは

true とは

1. 「L-真」（文法に従って）
   • 文法に従って、無矛盾に、論理法則が作成されているかどうか、ということ
   • 「妥当な構造」を取っただけ
     • これを保証しているのは「論理法則」
2. 「F-真」（事実的な）
   • 作られた論理構造を現実世界にあてはめた際、正しかったかどうか、ということ
   • 「真とされる値」
     • これを保証しているのは、事業などの「制約・束縛」

真理条件（T-文）

「虚構・隠ぺい・改ざん」なし

• 事業で使われている自然言語「情報」に対して、矛盾がないか

注意：ここまで出てきた話では、ビジネス上の制約・束縛に関する話題は出てきていない。

注意：「論理法則」と「制約・束縛」を混同してはいけない。

本日の講義では、「妥当な構造」に関する議論と、「真とされる値」に対する議論の２つを、それぞれ分けて実施します。
この２つを、一般手続きとして実施します。

本日の講義では、「無矛盾（=L-真）（=構文論）」と「完全性（=F-真）（=意味論）」という単語を頻繁に使うので、まずはこの２つを覚えてください。

3枚目 10:50～

技術の一覧の洗い出しをするに当たって、事前の解説

（ロジックを使った）形式的な構成 =「 個体（集合）（=セット）（=クラス）」　＋　「関係」
f(x) = f(x, y)

①個体が一次、関係は二次

②関係が一次、個体は変数

null（値無し）

充足していない、値がない、値ではない。
SEはnullに鈍感。
nullを認めるのはモデル違反。

• nullは２つの値を持っている。
  • 定義されていない。
  • 定義されているが、値を持っていない。

nullは、trueともfalseとも言えない。
もし、nullを認めるなら、以下の4値でやってください。

1. true
2. false
3. undefined
4. unknown

でも、SEは2値でやりたがる。

1. true
2. false

高度関係モデルからRDBから派生したproductが作成されたが、高度関係モデルとproductはかけはなれてしまった。
理由：高度関係モデルはnullを認めていないが、productはnullを認めている。

時代は変わり、E-R図が登場

正規化をしてE-R図で書けばいいと日本中に言ってしまったが、これは間違っていた。

正規化をしてE-R図で書いたものは、モデルではない。
論文を読むと、E-R図のエンティティに対する定義が存在しなかった。

現場は実体主義、我々は関係主義。

技術の一覧

• 事業の解析
  1. 「個体の認知」
  2. 「関係の性質」
  3. 「関係の文法」

　　　　　　↓

• 検算
  1. 「データの周延」
     • 正しいクラスになっているかどうか
  2. 「データの多値」
     • 一つの値が複数の価値を持っている
     • クラスという概念を持ってこないと、分析・設計が上手くいかない

　　　　　　↓

• 適用
  1. 「みなし概念」

我々が現場で扱っているデータには２種類がある

• データとデータの並びが関係するもの
• データとデータの並びが関係しないもの

例：時系列が関係するもの
　　　配送 -> 入金　（後払い）
　　　入金 -> 配送　（先払い）

例：配属や従属が関係するもの
　　　AはBの父親です。　≠　BはAの父親です。
　　　AとBは友達です。　＝　BとAは友達です。

セット＝集合　　「個体の認知」「関係の性質」「関係の文法」「データの周延」
クラス＝概念　　「データの多値」「みなし概念」

4枚目 11:20～

個体（集合）とは

1. 定義不能
2. 個体とは、誰がやったって同じになる
   1. 帰属するか、帰属しないか
   2. メンバーを選ぶ　（x=y）（x≠y）

指示する
合意

例）
ある企業では、ある規則に従って、これを「商品」と決めた。

「個体（エンティティ）（モノ）である　＝　個体指定子（エンティティーセンター）」が付与された対象であること

誤解されている例： エンティティーセンターをユニークキーやマスタとしてしまっている。

捨てて欲しいこと

捨てて欲しいこと：
　　30年～40年前の考え方（一意・マスターキー・ユニークキー）といったデタラメな考え方を捨ててください。

エンティティーセンターという考え方をきちんと身につけてください。

「在庫」　＝　「構成されたリスト」

「言葉」や「意味」は、現実で解釈済です。我々SEが勝手に変えることはできません。それを変えようとするからおかしなことになるんです。

本来、個体（エンティティ）は定義不能です。
ただし、現場では実際に定義しています。
現実では、個体の認知が先です。
現実での個体とは、これ、これ、これと指を指して認知できるものです。
在庫は、エンティティではありません。構成されるものです。

5枚目 12:50～

個体識別子（entity-senter）とは

個体である = Df 固定指定子を付与された対象である。

1. 一意性

1. 複合構成

1. 一意性

絶対に守って欲しいルール
[マスターキー・ユニークキー]を捨てろ

個体指定子と一意性は別問題。
モデルを作る際は、マスターキー・ユニークキーを見つけようとしないで欲しい。

2. 複合構成

個体そのものは、「one and only」

1970年代

6枚目 13:10～

1970年代

構造的プログラミング

部門コードと従業員Noをつかってマスターキー・ユニークキーにしようとしている。
=>これはだめ！

複合構成-①

1980年代

「充足」概念

　　　　↓

一見、認知Noだが、、、

部品No(34)
34桁のそれぞれの桁に対して、それぞれ意味が付与されている場合は、

＊をつけて、ユーザと再検討すること。

7枚目 13:20～

複合構成③

ここで、部門コードと作成日をマスターキー・ユニークキーにするのは、間違い。
どんどん事業モデルと、自分が作成したモデルがずれてくる。

じゃぁどうするか、、、

8枚目 13:30～

「関係」とは

「関係」の性質

ここで・・・数学者は

と書きたがる。

ここで、2つの性質があることに気付く。

1. 対称性
   • R(a, b) = R(b, a)
   • 例）恋人である
2. 非対称性
   • R(a, b) ≠ R(b, a)
   • 例）父親である

ここで、またミスを犯した。
「よし、じゃぁあとは対称性を見つければいいんだ」
対称性・非対称性を見つけて、満足してしまうというミスを犯した。

例）
出荷 -> 出荷日
入庫 -> 入庫日
従業員 -> 従業員日はない、入社日はある
部門 -> 部門日はない

ここで、現場は、なぜ正規化がうまくいかなかったのかがわかってきた。

そこで、日付があるものをevent、日付がないものをresourceとする。

なお、この日付は、取引日（過去日）のようなものを指す。
将来の日付は含まない。

日付

• 入社日
  • 従業員
• 設置日
  • 部門

---

• 有効日　適用日

9枚目 13:50～

まとめ

1. 個体（entity)とは、、、
   • Df 個体指定子を付与されている対象である
2. event（（取引・行為・出来事）とは、、、
   • Df 性質として「日付」が帰属する
3. resourceとは、、、
   • Df eventの補集合である

左がＮｏ、右が日付、これを守ればＯＫ！

10枚目 14:00～

「関係」文法

aRb ≡ R(a, b)

• a≠b
  • ①event - 対 - resource
  • ②event - 対 - event
    • 「先行・後続」関係
  • ③resource - 対 - resource
• a＝b（再帰）
  • ④一つの集合の中のメンバー並べたもの

エンティティ（個体）は、必ずe（event）かr（resource）を書いてください。

eventは、時系列で並べてください。
eventの前後がわからない場合は、上下で並べて書いてください。

resourceは並べても意味はありません。eventの上下に散らしておけばいいです。
いろんなeventに関連しそうなresourceは、まん中に書いておくと、後で困らなくなります。

ここでは、きちんと並べようとしなくてよいです。
後の工程で、きちんと整列されていきます。
あとでお客様が読める状態になります。

お客様と再契約しなかった事例

1. ある顧客でCRMをやりたい。
   • 顧客の右側には、、、名称・住所・電話番号しか書いてなかった。
   • 顧客を大事にしますと言っていながら、顧客のことを知ろうとしていなかった。
2. コンビニでの事例。
   • あるお客様が午前中に何を買ったのか管理していなかった。
3. 日常の精密機械を扱っている会社
   • シェアNo.1だったが、じわじわシェアが落ちてきた。
   • 地域密着型、地域コミュニティを大切にした販売戦略をしていきたい、という要望。
   • 地域コードはあったが、右側には何もなかった。名称もなかった。
   • 実データは、地域には関心がないことを示していた。

つまり、実データは嘘をつかない。

お客様と我々の立ち位置の違い

• 現場に立って、現場を解析しようとすると、我々は当たり前だがかなうわけない
• 形式的にまとめて構造化さえすれば、現場と我々は対等に立てない

文法の話に戻って、、、

　　　　　　　（行為者）　　（行為、出来事）
基本形 = resource が event に関与する

resourceの認知番号が、eventに入ることになる。

event - 対 - event
先行イベントのNoが、後続イベントに入ればよい。

11枚目 14:25～

ここで、うっかりある現象を忘れるというミスを犯した。

event(複数) - 対 - event

• 先行イベントが複数ある後続イベント

上記は間違い！

こういう場合は・・・・

名前は「対応表」
並び替えたらダメ、という意味。

event（複数） - 対 - event（複数）の場合

即、現場に行ってください。

現場は仕事をやりづらくなっているはずです。
現場の仕事を改善する必要があるポイントが眠っているからです。
担当者が裏で隠しているデータがある場合が多いです。

12枚目 14:35～

resource - 対 - resource

名前は「対応表」
並び替えても平気、いう意味。

---

• Trueの否定形はFalse
• Falseの否定形はTrue
• Nullの否定形はNull

モデルでは、Nullは充足しない、ということを気をつけておいてください。

13枚目 15:05～

「在庫」はentityか？

対照表の例）

対照表の文法

1. 構文論として（文法）、 resourceの束
2. 意味論としては、基本的にeventとして「解釈」

14枚目 15:15～

「商品」はentityか？

=> テキストにある事例を2つを見ながら、それぞれ解説。

大事なこと

データディクショナリがデータベースを管理する、という考え方もある。
=>現存するＲＤＢでデータディクショナリをまともに実装しているものはない。

「制約・束縛」が動く。このことを理解しているSEが少ない。

15枚目 15:45～

a=b（再帰）（recarsive）

縦のサーチ：（DFS）（Depth First Search）
横のサーチ：（BFS）（Breadth First Search）

縦の階層：階数
横の総：次数

16枚目 16:00～

event

昔の設計では・・・

17枚目 16:15～

データ周延

今まで個人しか無かった顧客データ。
方針が変わって法人も対称にしろと言われた。
やっつけで、性別の中に法人を組み込んだ。

{集める}　数学で言う集合。

(並べる)　数学で言う構成。順番が重要

18枚目 16:20～

さて、？に入るのは何でしょう？

？は、個人？人間？

さて、どちらが正しい概念ですか？
その概念が妥当とは、何を判断基準にしましたか？

個人と人間では、概念も判断基準も変わりますよね？

本来は、誰がやっても同じ結果にならなければいけない。

セット： {x∈a | f(x)}

RDBは、セットと第1階で設計する。

オブジェクト指向は、クラスで設計する。

「切断」した場合

切断した理由を必ず記述すること。

切断時の記号

= 部分集合の構成が同じ

X 部分集合の構成が相違

19枚目 16:35～

箱と線だけでは、モデルは出来ません。
必ず、切断という概念が入って、集合ごとに区別していく必要があります。
切断によって分割された集合の下位層は、同じ条件で切断出来るとは限りません。

1.切断（分割・細分）

1. AND?
2. 階数

20枚目 16:55～

下記は両方とも間違い。

上下を入れ替えて意味が通じる場合、切断が間違っている。

21枚目 22枚目 17:15～

データの多値

多値とは

1. OR関係「ＭＯ」
   • Many-Value-OR
2. AND関係「ＭＡ」
   • Many-Value-AND

OR関係

{従業員No,名称,,,,,部門コード(R)}
　　　　　　　　　　なぜ8桁とかにしているの？
　　　　　　　　　　よくある理由：最大値がわからないから
　　　　　　　　　　　=>実はモデルの充足エラー

23枚目 24枚目 25枚目 17:35～

例）

大事なポイント

ＭＯＲ：ORは、1つの関数の中の多値

ＭＡＮＤ：ANDは、2つの関数の合成（合成関数）

26枚目 18:05～

みなし概念

1. みなしentity
   • Virtual Entity（ＶＥ）
   • entityの純度を上げる（精度を上げる）
2. みなしスーパーセット
   • （概念的スーパーセット）＝クラス

みなし概念（みなしentity）の例

1. 1つのresourceの中に、event的性質が混入している。
2. 1つのresourceの中に、ほかのresource的性質が混入している。
3. 1つのeventの中に、resource的性質が混入している。
4. 1つのeventの中に、ほかのevent的性質が混入している。

27枚目 28枚目 18:20～

VEのうち、必ずしも存在しない場合は、線の途中に白丸を書く

29枚目 18:30～

R(a, b)

1. aとbは別々
2. aはbに含まれる
3. bはaに含まれる
4. aとbは、位置が交わる
5. aとbは、外延は同じ

30枚目 18:40～

モデルとしてのコッド関係モデル ≠ プロダクトとしてのRDB

コッド関係モデル

• 4値
• テーブル

プロダクトとしてのRDB

• テーブル
• index
• IF
• Null
• 配列

以下はDont's

1. CREATE VIEW
2. ORDER-BY
3. NULL
4. IF
5. ・・・

SQLは、コッドの関係モデルを使うと。。。

1. 集合論演算
2. リレーショナル代数演算
   • SELECT, JOIN, PROJECTION

31枚目 18:45～

例）
（セット）
従業員番号の集合 × 名称の集合 × 退職日の集合

セットから要素を取ってきたものをタプルという。
また、こういう手法を「セット・アット・ア・タイム法」と言う。

（タプル）
R{01∈番号, A∈名称, 1/9∈退職日}
「F-真」はtrue
R{02∈番号, A∈名称, 1/9∈退職日}
「F-真」はtrue
R{03∈番号, B∈名称, Null∈退職日} <- 取って来れない（充足しない）

logical view

RDBの内部

最短の検索ルートを決める手法

1. I/O主体：ルールベース
2. CPU主体：コストベース

次のメッセージが出たら「しまった」と思ってください

SQL文中にANDやORが記述されると構文論と意味論の両方を考慮するために
traverse-tableが作成されて、意味論の精査を実施するために、
検索時間が余計にかかる。

インデックスの作り方

欲しいデータを、欲しい順番に並べて、インデックスを作る。
order-byを別途書かなくてもいいようにするのがコツ。

RDBでは、KeysをVIEWとして使えばよい。パフォーマンスも抜群に上がる。
create viewをcreate indexにしてしまえばいいだけ。

最後のまとめ

1. 個体の認知
   • 箱の左側は「No」
2. 関係の性質
   • 箱の右側は「DATE」
3. 関係の文法
   • aRb にて関係を見つける、時系列にも注意
4. データの周延
   • 箱の右側に区分コードがあったら、切断してみる
   • 上下を入れ替えて意味が通じたらおかしいと気付こう
5. データの多値
   • MOR（1つの関数に複数の値）なのか、MAND（合成関数で表現出来る事業モデル）なのか
6. みなし概念
   • VEを活用しよう
7. パフォーマンス向上
   • create indexを活用しよう。ただしメモリには注意。
   • indexを使うとバッチetcのデータロードは遅くなることは考慮が必要。

※ モデルが出てくるのは、みなし概念以降の工程