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

  • 1.個体
  • 2.entity≠集合
  • 3.個体指定子
    • 2-1.one and only
    • 2-2.一意性
    • 2-3.複合性
  • 4.並び
  • 昔はSEに業務を説明して、SEが解釈したシステムを作っていた
  • MRP(生産管理)や給与計算にコンピュータでのソリューションが効果的だった。
  • この頃はプログラマと顧客が直接やりとりしていた
  • 顧客の要求が増大し(ここもなんとかならない？とか)、規模が膨れ上がっていった
  • プログラマの手には負えなくなる
  • 橋渡し役として、アナリスト、GA、SEが増えた
  • 業務知識がある人にコンピュータの知識を覚えさせるより、コンピュータの専門家に業務知識を覚えさせた方が安上がりだろうとみんな思っていた
  • そのまま加速し、今の形態になる(果たして正解だったかどうか…)
  • 当然、各人の仕事量は圧倒的に増えた
  • この頃から、人によって生産量というか仕事量にかなりバラつきがあることがわかり始める(AさんとBさんで分析結果が違う等)
  • それぞれ、自分が見た顧客の業務を構造化する。という点では正しい
    • 自分が見たとは何か
      • 業務はそこにすでにあるのだから
  • PC、ネット等のインフラが整備されたため、ユーザの業務もPCの前に座りっぱ

なしになった

    • 業務分析も以前のようにはできなくなった
  • 個体には色々な名(entity/set(数学的集合))があるが、形式的構造となると、

項だけとなる

  • エンティティの定義とは
    • 個体は記号化されているのが前提
      • あれ？正規化する前提が崩れてる？
        • ERじゃ正規化できない
  • エンティティは定義不可能
    • この為に定義されていない(切断、伸長が無限にできる)
  • 変数に
    • 事実、事業や社会の問題を切断するのは難しい
  • この関係(現実的事態と形式的構成)を一致させるには？
  • 社会の一機能とする
    • エンティティを見ても仕方がない
      • 関係を見る
  • 自然言語で現実的事態を伝達していくと、エラーが増えてやがては解釈不能に

陥る(伝言ゲーム)

  • 形式的構造は誰が用いても同じ結果になる
  • ルール1
    • ユーザ言語を変形しない！(DDの辞書)
      • 仕訳して転記する
  • モデルは
    • 1.記号の演算(L-真)
    • 2.記号の意味(記号の外から見た)
  • を保証する
  • 個体指定子
  • T字(簿記から)
    • ERでは表現できない部分を表現可能
    • 左には個体指定子(認知番号)
    • 右にはそれ以外
  • 本来ならば定義不能だが、ユーザ言語で使われている単位が使用可能
    • この場合は定義することができる
  • 個体とは個体指定子が付いているもの(長年連れ添った夫婦はおい、あれで通じる)
    • これ以外は個体とは認められない
  • ex:在庫は固体の集合なので右へ
  • 個体がわからないものはポイントシート等で
  • たまに使い方が変わるパターンがある(例外でユーザーが裏技を使用)
    • よく運用でカバーとかいわれる、される
  • 個体指定子の値が一意であるか気にしないこと！
    • 一意はモデルにおける記号の演算の結果である
  • ユーザーは自然言語で伝達する為に現場（現実的事態）毎にコード体系をもって対応している
  • 演算の最初の手法が仕訳
  • 自然言語を集めて構成し、ロジックをもって、現実的事態に一致させる
  • 個体指定子(entity-setter)
    • 1.one and only
    • 一意性
    • 複合性(いくつかの個体指定子で一意性を取る)
  • エンティティ同士で結ぶ線は関係を持つ(関数、対応、写像)
  • 線(関係、関数)によって後続のエンティティに値が送り込まれる(ReusedのRで示す)