関係スキーマは、問題文や概念データモデルに合わせて、わかりやすい順番に配置してくれている。
属性名(つまり列名)追加問題
午後Ⅰは解答欄に書き込む属性名は１つだけど午後Ⅱは複数が基本。
〇〇番号に親○○番号を追加すると再帰的な参照を含むテーブル構造となる。
目的の例：一意性を保証するため。
外部キーになっているケースが多い。また主キーは必ず一番左に書くが外部キーはその次に書かなければならないという決まりは全くなく、一番最後の属性名が外部キーになっているケースも結構ある。
[定番の属性名]
○○番号、○○コード。○○そのままということは基本的にない。
○○数量
年月日、有効期限年月
スーパタイプとサブタイプ
関係スキーマのインデントとスーパタイプとサブタイプのリレーションシップが対応している時もあるが、インデントがない場合もある。
サブタイプはスーパタイプと主キーが同じになり、他には共通の属性を持たない場合が非常に多い。しかしそうでない場合もある。以下はその例：
品目(品目番号, 品種名, 品種区分) （スーパタイプ)
製品(製品番号, 品目番号, 標準保証期間) （品目番号が外部キー)
部材(部材番号, 品目番号, 軽量単位) （品目番号が外部キー)
このような場合、スーパタイプの主キーを別途外部キーとして持たせる。
これは平成28年度の問題であり、このリレーションはすでに問題文の中に記載してあった。このリレーションをサブタイプと呼ぶのかそもそも疑わしい気もするので、「過去のIPAの試験ではこのようなケースもあった」くらいに考えておくのが良い。
また、サブタイプはスーパタイプと主キー以外の共通の属性を持たない。
エンティティ追加問題
関係スキーマにないエンティティを自分で文中から抜き取って作る。そればっかりの概念データモデルの問題もある。
新しくエンティティを追加した時には、その主キーが別のテーブルの外部キーになるか、他のテーブルの主キーを外部キーとして持つ。
サブタイプ化を疑う。
保守契約と号機というエンティティがすでにあっても、必要に応じて保守対象号機というエンティティを新たに追加する。
ロールを追加する時は以下のエンティティを追加。
ロール(ロールID, ロール名), ロール付与先(ロールID, ユーザID)