「データベース設計論」を読む(1)

ダメなコード体系は、SEが立て直せ

T字形と出会った時に最も印象的だったのは、「顧客のコード体系に従ってデータを解析することによって、SEの恣意性を排除する」という考え方だった。
で、半年ほど、T字形はSEが顧客のコード体系に干渉することを禁じていると思っていたが、これは勘違いだった。
(この勘違いはココにコメントをくださった方々のおかげで解消した。ありがとうございました)
「データベース設計論」には、顧客のコード体系はSEの批判的検討の対象であることが明示されている。

P-35

データ設計では <中略> 事業の中で使われているコード(コード体系)の成否を判断する。

非効率的・非効果的なコードは、事業を非効率的・非効果的にする。

P-52

事業過程に対して役立つ情報体系を作るのなら、まず、管理過程の「現状(事実)」を記述しなければならない。
<中略>
ただし、かつて「F-真」を実現していた語が、今では、必ずしもそうではない事態になっているかもしれない。
それを検証するために、まず、「事実を記述する」のである。事実の記述は、検証(改定)に先行する。

これは、「顧客のコード体系がダメになっていたら、システムを再構築する前に、SEが立て直さなきゃいけない」ということですよね。


「F-真」て何?

新作にはF-真/L-真という聞いたことのない用語が頻出する。
定義はこう:

P-30

(1) F-真 (記号と個体の指示関係の中で検証される「真」概念)
(2) L-真 (F-真を前提にして、導出規則の中で検証される「真」概念)

これがT字形とどう関係あるかというと、俺理解では、
F-真とは「記号が指し示す対象がただ一つに決まって、かつ適切な対象を指していること」で、例えば resource や event のデータがF-真。
L-真とは「F-真なもの(=resourceのデータなど)のあり得る組み合わせ」で、例えば対照表(event や validation-rule)はL-真。
P-52の

かつて「F-真」を実現していた語が、今では、必ずしもそうではない事態になっているかもしれない。

とは、例えば、

  • 従業員マスターテーブルに「部門コード」列がある。
  • 従業員は技術部か営業部のどちらかに属している。
  • このたび、社長室直属の技術部隊が編成されて、数名の技術部員は所属部門がなくなってしまった。
  • 仕方がないので、この人たちの従業員マスターの部門コード列には、Nullを入れることにした。

みたいな事態を指すのだろう。