【データベース】計算で出せるデータは保存しない？「導出属性」の設計思想｜情報処理問題1000本ノック
データベースのテーブル（実体）を設計する際、どの項目を保存すべきか。他の項目から自動的に計算して導き出せる「導出属性」の扱い方を攻略しましょう。
1. 【 問題 】：データモデルにおける属性の分類
【 問題 】 データベースの概念設計（ER図の作成など）において、実体（エンティティ）が持つ属性（カラム）のうち、その値をデータベース内に物理的なデータとして直接保持しなくても、他の属性の値を基に計算や加工（演算）を行うことによって自動的に導き出すことができる項目を何と呼ぶでしょうか？
① 主キー属性 (Primary Key Attribute)
② 導出属性 (Derived Attribute)
③ 複合属性 (Composite Attribute)
④ 多値属性 (Multivalued Attribute)
2. 正解：
正解： ② 導出属性（どうしゅつぞくせい）
3. 解説：データの重複を無くし、矛盾（バグ）の芽を摘む
データベースの正規化や設計においては、「無駄なデータは持たない（一元管理）」が鉄則です。その中心にある概念が導出属性です。
・具体例：お買い物のテーブルにおいて、「単価」と「数量」があれば、それらを掛け算することで「金額」が導き出せます。また、「生年月日」があれば、現在のシステム日付から「年齢」を導き出せます。この場合の「金額」や「年齢」が導出属性です。 ← ココが問題の正解！
・なぜ物理保存を避けるのか？：もし「金額」をわざわざ固定のデータとして保存してしまうと、後から「数量を3個から2個に変更したのに、金額のデータを書き換え忘れた」というミスが起きた際、データに矛盾（バグ）が発生してしまいます。そのため、導出属性はデータとして保存せず、SQL文の中で「単価 × 数量 AS 金額」のようにその都度計算させる（またはビューや生成列を使う）のが基本デザインとなります。
★ ① 主キー属性：テーブル内のデータを一意に（1行だけに）識別するための、重複も空（NULL）も許されない超重要なコード（社員番号や注文IDなど）です。
★ ③ 複合属性：「住所」という項目の中に「都道府県・市区町村・番地」が含まれているように、さらに細かく分解できる属性のことです（RDBの設計では通常、分解して保存します）。
★ ④ 多値属性：1人の社員に対して「保有資格」が複数あるように、1つの枠の中に複数の値が入ってしまう属性のことです（RDBでは第1正規化によって別テーブルに分離します）。
1. 理解のコツ: 「レシート」をイメージしてください。
・お店のレジで、「リンゴ 150円（単価）」を「3個（数量）」買ったとき、合計が「450円（金額）」になるのは小学生でも分かりますよね。この450円という数字は、わざわざ頭の中に暗記しておかなくても、150×3というルール（演算）さえ分かっていればいつでもその場で生み出せます。この、他の情報から後出しで計算できる項目が導出属性です。
2. 試験対策の視点: 「他の属性から演算を行うことで導出できる」「単価と数量から金額」というドンピシャの例え話が来たら導出属性が一択です。基本情報や応用情報の午前試験では、概念データモデル（リレーション）を正しく設計できているかを問う問題や、システム設計の「無駄なデータを持たせない」という正規化の思想の基本としてよく出題されます。
4. まとめ
「データベースの容量を節約し、かつデータの計算ミス（不整合）を防ぐため、他のデータからの計算によってその都度導き出すべき項目」。これが導出属性です。パフォーマンスの都合であえて物理保存する（サマリーテーブルを作る）場合もありますが、基本設計の段階では「計算で出せるものは、元データだけをスマートに持つ」というこの思想がデータモデリングの土台となります。