基本情報技術者 2012年 秋期 午前(科目A) 問28
問題文
新たにデータ項目の命名規約を設ける場合、次の命名規約だけでは回避できない問題はどれか。
〔命名規約〕
(1) データ項目名の末尾には必ず“名“、“コード”、“数“'、“金額”、“年月日”などの区分語を付与し、区分語ごとに定めたデータ型にする。
(2) データ項目名と意味を登録した辞書を作成し、異音同義語や同音異義語が発生しないようにする。
選択肢
ア:データ項目“受信年月日”のデータ型として、日付型と文字列型が混在する。
イ:データ項目“受注金額”の取り得る値の範囲がテーブルによって異なる。(正解)
ウ:データ項目“賞与金額”と同じ意味で“ボーナス金額”というデータ項目がある。
エ:データ項目“取引先”が、“取引先コード”か“取引先名”か、判別できない。
新たにデータ項目の命名規約を設ける場合、次の命名規約だけでは回避できない問題はどれか。 【午前2 解説】
要点まとめ
- 結論→ 命名規約と辞書で防げないのは「項目ごとの取り得る値の範囲がテーブルによって異なる」問題で、正解はイです。
- 根拠→ (1)区分語でデータ型を統一し、(2)辞書で同義語や同音異義語を排除するが、値の範囲(ドメイン)は規定していないため防げません。
- 差がつくポイント→ 値の最小/最大や事業コンテキスト別の許容値はデータドメインや制約としてメタデータに明示し、DB制約で実装する必要があります。
正解の理由
正解は イ です。提示された命名規約は(1)区分語によるデータ型の標準化、(2)辞書による名称・意味の一意化を目的としています。これにより名前の揺れや同音異義の混乱、末尾語による型混在は防げますが、各テーブルで「取り得る値の範囲(業務ルールに基づく最小値・最大値・許容単位など)」を制御する仕組みは含まれていません。したがって、テーブル間で同名の項目があっても値の範囲が異なるという問題は残ります。
よくある誤解
- 命名規約だけでデータ品質のすべてが担保されると考える誤解:命名は可読性と意味の一貫性を高めますが、業務ルールや範囲制約は別の仕様で定義する必要があります。
- 辞書があればすべての差異を吸収できるという誤解:辞書は意味や同義語を統一しますが、「許容する値域」や「単位」「小数桁数」は辞書の拡張(メタデータ項目)や別のドキュメントが必要です。
解法ステップ
- 各選択肢が示す問題を命名規約(1)と辞書規定(2)に照らして検討する。
- (1)が防ぐもの:末尾区分語に基づくデータ型の混在(例:年月日 → 日付/文字列混在)。
- (2)が防ぐもの:同義語や同音異義語による意味の重複・衝突(例:「賞与金額」と「ボーナス金額」)。
- 命名規約・辞書がカバーしない領域(ドメイン制約、テーブル固有の値範囲)を特定する。
- 上記照合で防げない問題がある選択肢を正解とする(イが該当)。
選択肢別の誤答解説
- ア: データ項目“受信年月日”のデータ型として、日付型と文字列型が混在する。
→ (1)で「年月日」を末尾区分語に指定し、区分語ごとにデータ型を定めるため混在は原則回避可能です。辞書で正しい型を明示すれば防げます。 - イ: データ項目“受注金額”の取り得る値の範囲がテーブルによって異なる。
→ (正解)命名規約は名称と型、辞書は意味の一意化に関する規則であり、テーブルごとの最小値・最大値や業務別の許容レンジなどのドメイン仕様までは規定しないため回避できません。 - ウ: データ項目“賞与金額”と同じ意味で“ボーナス金額”というデータ項目がある。
→ (2)の辞書で異音同義語や同義語の統一を図るため、辞書運用と承認フローを設ければ防げます。命名規約で用語統一を強制することも可能です。 - エ: データ項目“取引先”が、“取引先コード”か“取引先名”か、判別できない。
→ (1)の区分語要求により、末尾に「コード」「名」などを付ける運用が義務化されるため、曖昧な「取引先」だけの命名は排除され、問題は回避できます。
補足コラム
命名規約とデータ辞書は「意味」と「型」の一貫性を確保するための基本ツールですが、データ品質を高めるにはさらに次の要素が必要です。
- ドメイン(domain)定義:許容値、単位、小数桁数、フォーマット、NULL可否を明示する。
- 物理制約:DBのCHECK制約、列型、外部キー、トランザクション制御などで実装。
- ガバナンス:データスチュワードによるドメイン承認とバージョン管理。
例:SQLで「注文金額」の許容範囲を定義する一例
ALTER TABLE orders ADD CONSTRAINT chk_order_amount_range CHECK (order_amount BETWEEN 0 AND 10000000);
または PostgreSQL の DOMAIN を使う方法:
CREATE DOMAIN money_amount AS numeric(12,2) CHECK (VALUE >= 0 AND VALUE <= 10000000);
FAQ
Q1: 命名規約に「金額」はあるが、具体的な上限はどこに書くべきですか?
A1: データ辞書の属性として「最小値」「最大値」「単位」「小数桁数」を追加し、必要ならDB制約やアプリのバリデーションに反映します。
A1: データ辞書の属性として「最小値」「最大値」「単位」「小数桁数」を追加し、必要ならDB制約やアプリのバリデーションに反映します。
Q2: 辞書だけで「賞与」と「ボーナス」を統一すれば済みますか?
A2: はい、辞書で公式名称を定め、既存の項目をリネームまたはマッピングすれば統一できます。ただし運用ルールと承認フローが必要です。
A2: はい、辞書で公式名称を定め、既存の項目をリネームまたはマッピングすれば統一できます。ただし運用ルールと承認フローが必要です。
Q3: テーブルごとに違う範囲が業務上必要な場合はどうする?
A3: 「コンテキスト付きドメイン」を採用し、(例)事業部Aでは0~100万円、事業部Bでは0~200万円というようにドメインを区分して管理します。命名にコンテキストを含めるか、メタデータで紐づけます。
A3: 「コンテキスト付きドメイン」を採用し、(例)事業部Aでは0~100万円、事業部Bでは0~200万円というようにドメインを区分して管理します。命名にコンテキストを含めるか、メタデータで紐づけます。
Q4: 命名規約だけで「取引先」といった曖昧語を禁止できますか?
A4: 可能です。末尾区分語の必須化や禁止語リストを制定すれば、曖昧命名を技術的・運用的に防止できます。
A4: 可能です。末尾区分語の必須化や禁止語リストを制定すれば、曖昧命名を技術的・運用的に防止できます。
関連キーワード: データ定義、データ辞書、命名規約、データ型、ドメイン制約、メタデータ、データガバナンス、スキーマ定義、チェック制約、業務ルール

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

