Blog

[実況!]第四回 「T字形データモデリング手法」講義録(2009/1/9)

2017/08/16

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

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

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-文)

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

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

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

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

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

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

3枚目 10:50~

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

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

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

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

null(値無し)

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

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

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. 「みなし概念」

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

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

例:時系列が関係するもの
   配送 -> 入金 (後払い)
   入金 -> 配送 (先払い)

例:配属や従属が関係するもの
   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の補集合である

左がNo、右が日付、これを守ればOK!

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つを見ながら、それぞれ解説。

大事なこと

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

「制約・束縛」が動く。このことを理解している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関係「MO」
    • Many-Value-OR
  2. AND関係「MA」
    • Many-Value-AND

OR関係

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

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

例)

大事なポイント

MOR:ORは、1つの関数の中の多値

MAND:ANDは、2つの関数の合成(合成関数)

26枚目 18:05~

みなし概念

  1. みなしentity
    • Virtual Entity(VE)
    • 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のデータロードは遅くなることは考慮が必要。

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

-Blog