ビジネスの実態がわかるデータベースの作り方：第一回 (2010/10/01)

テキストはこれ

板書はページに置く*1
ページ内の反コンピュータは時間を掛けてでも読んで欲しい*2
IT業界で使われているモデルが相当おかしいので、それを正したい
ここでいう「モデル」とは「抽象データ型モデル」を指す
1970年代からDFD、ER、クラス図などがデータモデルとして研究され使われてきた
RDBとERを日本に持ち込んだときはかなり批難された
- そんな玩具が仕事に使えるかとか言われた
歴史の悪戯としか言えないような出来事でDFDは1970年、ERは1980年、クラス図(OO)は1990年から世間に認知され始めた
RDBが流行したのは、ペンタゴンが買ったから*3
- このRDBにはエンジニアが見れば、すぐにわかる弱点があった。致命的な手続きが必要だったが、それを巧く回避したデモを行った

構造化→問題→ソリューション
- 構造化プログラミング
- 手続き型言語（COBOL...）
事業内の問題に対して、ソリューションの提案、解決を行うのが当時のSE像（カイゼン案提案型SE）
- 大量生産されるモノに対して、効果的だった（1970年代）
- 1980年に飽和する
- 前提、環境が変われば手法も変わる
- 今はそんなことしてる人はそうそういない

コード関係モデル(?)とOOは出処は同じ
よくあるコンビニのクラス図で、レジと顧客というクラスが示されているものがある
- あれはおかしい
  - 立ち読みしてるのは潜在顧客か？ｗ
    - 購入したら顧客だよね
クラス図というのは最初には書けない
- 完成するのはプログラムが作成されてテストが終わってから
- 顧客を管理しているデータがあったはずなのに、現場を見た実感をSEが図を書いたら、滅茶苦茶になるのは当たり前
- 抽象化？→クラス図？ｗ
  - そりゃフワス図（byクリプキ）

抽象データ型→ロジックで形式化（現実を徹底的に形式化する）
- 議論は昔からあったが、実感してきたのはここ数年
やりたいことは、事業を正確に記述すること
- この授業のテーマ
ロジックとしては主にAND、OR、NOTを使う
モデルは世界共通、プリミティブは不変
誰がやっても同じアウトプットにならないとおかしい
- 僕が使うAND、OR、NOTと他の人が使うAND、OR、NOTが違うなんてことは有り得ない
  - 日本、インド、例え中学生であろうと、うちの息子でも書けた
    - しかし、プロとアマでは違う
    - ソリューションにペンを入れるのがプロ、アマは書けても読めない
ソリューション→事業を正確に記述する！
- ①構造そのもの
- ②環境適用能力
  - 最近はこれが肝
  - どこも厳しい状況に置かれているし、淘汰されている

現実的事態として、顔を見たこともない人同士が事業をやっている
そこには言語で記述された体系、ルールがある（ユーザー言語）
- これを単に文字列（記号）として捉える
  - 日本語で業務分析はできないんじゃないかな
そして、集める
- 集合は必ず枚挙できる
  - 20代の男子は集合だが、美男子は集合ではない
    - 日本人は細かいことはできるが、大局は見えない
      - トップダウン
- 誰がやっても集合に含まれるメンバーは数えることができる
entity≠set/classから形式的構成
- ここにおいて無矛盾なアルゴリズムはいくつか書くことができる
  - ひとつではないのでユニークかどうかには拘らない
    - 無矛盾かどうか
現実的事態と形式的構成は時間と事態が一致したときのみ真となる
- 真とは
  - F-真（完全性）
    - 語-言語が事実的対象を記述する
  - L-真（無矛盾性）
    - （F-真を前提にして、）導出関係のなかで成立する
- がある
時間、事態をあわせて形式的構成にペンを入れていく