« 「科学研究」としてのシステム開発 | トップページ | 仕様変更にも良し悪しがある »

2017.02.15

「命名標準」に振り回されないために

 テーブルやフィールドの命名標準は悩ましい問題だ。「フィールドIDが全角日本語であることの意義」で全角日本語で設定することの合理性について述べたが、いくつかの技術的障害や習慣の影響もあって、なかなか広まっていないのが現状である。

 いっぽう、英語表現にこだわっている職場もあるが、英語に堪能な技術者ばかりでないために、けっきょくどの国の人間が見ても了解不能な表現になっていたりする。表現が的確であったとしても、文字列として長過ぎては作業記憶に納まらないので仕事がやりづらい。かといって省略形を駆使して短めにすると、符牒のようになって第三者にわかりにくくなる。

 「一覧順」の問題もある。全角日本語なり、半角の英語や日本語ローマ字でdescriptive(記述的)な表現をすると、一覧した場合の並び順が二の次になる。とくにテーブルの並び順というのは、仕様管理におけるエンジニアリング課題のひとつなので、それがコントロールできないのはつらい。

 けっきょく、テーブルやフィールドの命名標準には、開発者の数だけスタイルがあって、それぞれに一長一短があって正答はない、というのが真実なのだろう。では今後も我々は、多かれ少なかれ自分の意に沿わない命名標準に振り回されるしかないのだろうか。

 あきらめてはいけない。「『仮想DB』としての開発用プラットフォーム」の記事で、複数の異種データベースにまたがるテーブル群が、論理的な単一DB上にあるかのように扱えると説明した。同じように、テーブルやフィールドの物理名を、開発者にとって都合の良い論理名にoverrideできるというのも、開発環境が提供すべき大切な役割だ。意に沿わない物理名に、プロジェクト毎に使いやすい「源氏名(げんじな)」を一元的に付与するのである。

 たとえば、テーブルについてはT0001,T0002,...、フィールドはF001,F002,...といった調子で命名された既存テーブルを扱う羽目になったとしよう(非常に困惑させられるが、実在の命名標準である)。これに、プロジェクトのロケールを考慮したdescriptiveな源氏名を与える。すると、業務ロジックやアプリ定義において、テーブルやフィールドを源氏名で指定できるようになる。以下のように、読みやすさがまるで違う。

      <物理名>  <源氏名>
テーブル:T0023 → PurchaseOrder
フィールド:F001 → orderNumber
フィールド:F002 → vendorCode
フィールド:F003 → itemCode
フィールド:F004 → orderStatus

<業務ロジックの一部(物理名を使った場合)>
readPurchaseOrder = createTableOperator('Select', 'T0023');
readPurchaseOrder.setKeyValue('F003', T0018_F001.value);
readPurchaseOrder.setKeyValue('F004 !=', 'CANCELED');
if (readPurchaseOrder.next()) {
    T0018_F001.error = 'Deactivating is not allowed as ...';
}

<業務ロジックの一部(源氏名を使った場合)>
readPurchaseOrder = createTableOperator('Select', 'PurchaseOrder');
readPurchaseOrder.setKeyValue('itemCode', ItemMaster_itemCode.value);
readPurchaseOrder.setKeyValue('orderStarus !=', 'CANCELED');
if (readPurchaseOrder.next()) {
    ItemMaster_itemCode.error = 'Deactivating is not allowed as ...';
}

 テーブル名やフィールド名としてこの例のようなキャメル表記(大文字小文字混じり)の値を与えることは、一般に面倒だったり不可能だったりするが、なにしろ源氏名なので自由に付与できてしまう。半角英数字だけでなく全角日本語も使えていいし、テーブルの並び順も別途指定できたほうがいい。ただし、いったん設定された源氏名については、開発環境によって変更が制約されなければいけない。さまざまな定義がその表現にもとづいて展開されているはずなので、自由に変更できては不整合が生じるからだ。

 一般にシステム保守の手間は、コードまわりに偏っている。そして、コードに含まれる「変数名」がわかりにくいことが、その保守性や可読性を損なっているという現実がある。作業変数の命名については自由が利くが、既存のデータベースが関わる場合、その上の要素については物理名を与件として受け入れざるを得ない。そのことがシステムの保守性に隠然たる影響を及ぼしている。前回記事で、システム記述に「人間にとってわかりやすい仕様説明書」と「機械にとって矛盾のない動作指図書」の二面性を与えられると説明したが、源氏名を付与できるというのは、前者としての効果を高めるための良い工夫である。

 ただし、源氏名の効果にも限界はある。テーブルやフィールドの表現をどうするかは重大な問題ではあるが、設計品質上の本質ではない。カギは「関数従属性」や「ドメイン制約」にもとづくキー設計やエンティティの切り出しの巧拙にある。複合主キー要件を無視しているとか、反対に必要以上の項目が複合主キーに突っ込まれているとか、はたまた同一主キーのテーブルがやたらとあるといった粗雑な設計であれば、テーブル名やフィールド名をわかりやすい表現に置き換えてもたいした効果はない。そもそも、設計の拙いテーブルやフィールドには、端的な表現を与えることが難しい。曖昧だったり多義的だったりするからだ。

 その意味で、テーブルやフィールドの命名標準など些末な問題で、DB設計スキルを磨くことのほうがよほど大事である。的確に構成されたDBさえあれば、「人間にとってわかりやすい仕様説明書」が書けるからだ。そして、機械(開発環境)がそれを「動作指図書」として読み込んで、仕様どおりに動作してくれる時代だからだ。命名標準に悩む前に、DB設計スキルを含む「要件に対する適切な仕様を生み出す力」を身につけよう。

|

« 「科学研究」としてのシステム開発 | トップページ | 仕様変更にも良し悪しがある »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「命名標準」に振り回されないために:

« 「科学研究」としてのシステム開発 | トップページ | 仕様変更にも良し悪しがある »