基本情報技術者 2015年 春期 午前（科目A） 問29

データ項目命名規約の限界【午前解説】

正解の理由

解法ステップ

1. 命題の規約（1）（2）が何を保証するかを正確に把握する（型の統一、語彙の一意化）。
2. 各選択肢が示す問題が「型」「語彙」「意味の判別」「値域／業務制約」のどれに該当するか分類する。
3. 規約でカバーできる問題（型の混在、同義語・同音異義語、名称の曖昧さ）とできない問題（ドメインや業務制約の差）を比較する。
4. 規約で明示的にカバーされていない選択肢を正解とする。

選択肢別の誤答解説

• ア: データ項目“受信年月日”のデータ型として、日付型と文字列型が混在する。
  → 誤り。規約（1）で区分語ごとに定めたデータ型にすることを義務付けているため、型の混在は回避可能です。
• イ: データ項目“受注金額”の取り得る値の範囲がテーブルによって異なる。
  → 正解。取り得る値の範囲（ドメイン、業務ルール）は命名規約と辞書だけでは統一できないため、別途ドメイン定義や制約が必要です。 (イ)
• ウ: データ項目“賞与金額”と同じ意味で“ボーナス金額”というデータ項目がある。
  → 誤り。規約（2）で辞書に登録し、異音同義語を発生させないようにするため、同義語の重複は防げます。
• エ: データ項目“取引先”が、“取引先コード”か“取引先名”か、判別できない。
  → 誤り。末尾に“コード”や“名”などの区分語を付与するルールがあるため、判別できない状態は避けられます。

よくある誤解

• 命名規約があればデータ品質は全て担保される：命名は可読性や型の統一には効くが、値域や整合性ルールまでは保証しない点を見落としがちです。
• データ辞書を作れば自動的に運用される：辞書の存在だけで運用・検証ルールが実行されるわけではなく、設計・実装・テスト工程での運用が必要です。
• 接尾語だけで業務意味が完全に伝わる：接尾語は型を示すが、業務上の単位や通貨、端数処理など詳細ルールは別途定義が要ります。

補足コラム

-- 受注金額の範囲をテーブルごとに統一してチェックする例
CREATE TABLE orders (
  order_id INT PRIMARY KEY,
  order_amount NUMERIC(12,2) NOT NULL,
  CONSTRAINT chk_order_amount_range CHECK (order_amount BETWEEN 0 AND 1000000)
);

FAQ