データベーススペシャリスト 2018年午前2 問07

問題文

商品情報に価格、サイズなどの管理項目を追加する場合でもスキーマ変更を不要とするために、“管理項目”表を次のSQL文で定義した。“管理項目”表の“ID”は商品ごとに付与する。このとき、同じIDの商品に対して、異なる商品名を定義できないようにしたい。aに入れる字句はどれか。

🖊️ 解答を隠して解いてみる

選択肢

ア：UNIQUE (ID)

イ：UNIQUE(ID, 項目名)（正解）

ウ：UNIQUE(ID, 項目名、値)

エ：UNIQUE(項目名、値)

🔒 解説は解答すると表示されます

複合一意制約【午前2解説】

正解の理由

商品ごとに複数の属性（商品名、価格など）を持たせるEAV的な構成では、同じ商品IDに対して同じ属性（例えば「商品名」）が複数行登録されるのを防ぐ必要があります。選択肢イの UNIQUE(ID, 項目名) を定義すると、(ID, 項目名) の組がテーブル内で重複できなくなり、同一の ID に対して「商品名」行を二つ以上登録できなくなります。結果として、同じIDに異なる商品名を定義することが防がれ、設問の要件を満たします。

解法ステップ

要件を整理する：同じ ID に対して「商品名」を複数（かつ異なる値で）定義できないようにしたい。
テーブルの行構成を確認する：各行は (ID, 項目名, 値) のように属性を表現している。
制約の設計：同一 ID と同一項目名の組は一意でなければならない → 複合一意制約を設定する。
SQL に落とし込む：CREATE 文内に UNIQUE(ID, 項目名) を追加するか、既存テーブルなら ALTER TABLE で追加する。

例：CREATE TABLE に組み込む場合

CREATE TABLE 管理項目 (
    ID       INTEGER NOT NULL,
    項目名   VARCHAR(20) NOT NULL,
    データ型 VARCHAR(10) NOT NULL,
    値       VARCHAR(100) NOT NULL,
    UNIQUE (ID, 項目名)
);

既存テーブルへ追加する場合

ALTER TABLE 管理項目
ADD CONSTRAINT uq_id_項目名 UNIQUE (ID, 項目名);

選択肢別の誤答解説

ア: UNIQUE (ID)
ID 列だけを一意にすると、同じ商品に複数の属性行（商品名・価格・商品番号など）を持てなくなります。商品ごとに複数行を想定している設計に対して過剰であり不適切です。
イ: UNIQUE(ID, 項目名)
(ID, 項目名) の組が一意であれば、同一 ID に対して同じ項目（例えば「商品名」）の行が二つ以上登録できなくなり、異なる商品名を設定することもできなくなります。したがって要件を満たします。
ウ: UNIQUE(ID, 項目名、値)
(ID, 項目名, 値) の組を一意にする制約は、値が異なれば同じ (ID, 項目名) の複数行を許容してしまいます。つまり同じ ID に対し異なる「商品名」(値) を登録できてしまい、要件を満たしません。
エ: UNIQUE(項目名、値)
項目名と値の組が重複しないようにするだけで、ID ごとの重複制御になりません。別の ID に対して同じ (項目名, 値) を禁止するだけで、同じ ID に別の値を持つ項目を登録するのを防げません。

よくある誤解

UNIQUE(ID) を使えば「ID 内の値の重複を防げる」と考える誤解：ID単独で一意にすると、設計上期待される「複数属性を持つ行」がそもそも作れなくなります。
UNIQUE に値を含めれば安全という誤解：値を含めると値が異なれば重複と見なされないため、むしろ目的に反します。
UNIQUE と PRIMARY KEY の混同：PRIMARY KEY も一意制約ですが NOT NULL が暗黙的に要求されます。本件では (ID, 項目名) を主キーにすることでも同様の効果が得られますが、設計意図に応じて選びます。

補足コラム

このような (ID, 項目名, 値) の構成は EAV（Entity–Attribute–Value）モデルに相当し、柔軟性はあるものの制約や整合性管理が難しくなります。属性ごとの型検査や必須性、複数回の登録を禁止したい属性（今回の「商品名」など）には適切な一意制約やチェック制約を設けることが重要です。属性ごとに専用のカラムを持つ正規化（固定カラム設計）と比較して、利便性と整合性のトレードオフを意識してください。

FAQ

Q: PRIMARY KEY に (ID, 項目名) を指定しても良いですか？
A: はい。PRIMARY KEY にすれば NOT NULL と一意性が保証され、同様の効果が得られます。設計上どちらが適切かは要件次第です。

Q: NULL の扱いは気にする必要がありますか？
A: 多くの DBMS では UNIQUE 制約下で NULL 値の扱いが特殊です（複数の NULL を許すものもあります）が、本例では各列が NOT NULL 指定なので問題になりません。

Q: 値の整合性（型や範囲）も保証できますか？
A: CHECK 制約やデータ型、トリガー等で保証します。EAV では属性ごとに適切な型や検証を行う工夫が必要です。

関連キーワード: UNIQUE制約、複合キー、EAVモデル、CREATE TABLE、ALTER TABLE、一意性制約、データ整合性

← 前の問題へこの年度をクイズで解く次の問題へ →

\ せっかくなら /

データベーススペシャリストを
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！