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', '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設計スキルを含む「要件に対する適切な仕様を生み出す力」を身につけよう。

| | コメント (0) | トラックバック (0)

«「科学研究」としてのシステム開発