Database Systems Engineer Examination

アイテック模試午後II 問2
勤務実績管理システムの概念データベースモデルとデータベース設計に関する問題
H12午後II 問２とH16午後I 問３をミックスして題材にした感じ。

設問１
　H13午後II 問２っぽい問題

設問１（１），（２）
　H13午後II 問２ 設問１（１），（２）と同じ
　欠落しているエンティティ＆リレーションを追加し，追加したスキーマの記述
　定番っす。
　しかし。。。
　「○○の一覧データは“勤務実績集計”テーブルへ格納される」って書いておいて，そのテーブルがないって。。。どうよ。追加が１個しかないハズないから一生懸命，要件を探しちまったよ。（最終的には気付いたんだが。。）　

設問１（３）
　H13午後II 問２ 設問１（３）と同じ

設問１（４）
　属性が不完全なスキーマの完成。定番。

設問２
　午後I のＳＱＬ問題のSQL記述以外の設問っぽい問題

設問２（１）
　履歴テーブルからある時間軸上の１点の時点のデータを読むための抽出方法の記述。
　履歴管理が分かっていればぜんぜん問題ではない。

設問２（２）
　設問２（１）の性能向上対策。（１）で困った事を書けばいい。

設問３（１）
　画面と説明文から，属性が不完全なスキーマを完成させる。定番

設問３（２）
　H16午後II 問１の設問３（２）の類問
　・時間軸上有効なＰＪで
　・入力時点で従業員がＰＪに所属している
　と，いうのは簡単。
　もうひとつ
　・勤務時間＝作業時間の合計
　確かに最終的にはそうだろうけど。。。「原則として，毎日退社時に当日の勤務実績を入力するルール」でもねぇ。。。入力途中の登録（更新）もアリなんじゃないのかなぁ。。。
　あくまでルールなんだし，原則なんだから，つまりは「業務的に許されない制約ではない（H14午後II 問１設問３（２）参照）」ので，「＝（イコール）」の制約はキツイと思う。
　ということで，私は「上限の制約だけ」で十分だと思ったんだけど。。。
　・勤務時間＞＝作業時間の合計　　アイテック採点だと部分点かな。。。

設問４
　H12午後II 問２の設問３（２）をちょっと高度にしたような内容。

設問４（１）
　組織変換履歴は良いとして
　組織階層変更履歴は。。。何？要件からはそうは読み難いんだが。。。
　「所属先の変更履歴（所属期間と現在の所属先を管理する」
　あと，組織新設時に変更履歴が生成されるかどうか，つまり，変更管理のスタート地点が明確でないと。。。解答が定まらないのでは？

　組織階層変更履歴（組織コード，所属終了年月日，変更前親組織コード，変更前親組織所属期間）

　なんてのもアリになる気もする（これを解答に書いたわけじゃない）んだけどなぁ。。。

設問４（２）
　（１）の連鎖で不正解。。。
　基本的には設問２（１）に同じ。

【関連記事】
　アイテック模試午後II 問1反省とメモ
　アイテック模試午後II 完了
　アイテック模試午後II
　模試帰ってくる

アイテック模試午後II 問１
H16午後II 問2に酷似した問題（問題の概要についてはここを参照されたし）

設問１
・スーパータイプ／サブタイプからリレーションを引く場合，及びスーパータイプ／サブタイプへリレーションを引く場合，スーパータイプ側／サブタイプ側どちらに引くかよく吟味すること。

（オマケ？）
　[製造オーダ]－[生産実績]
　　　　↓　　　　　　　　↓
　[作業オーダ]－[工程別生産実績]
　解答例にない余計な線を引いていたが減点なし。採点ミスか？それぞれ１：１の組合せ（横）間なので，縦の多：多は見逃してくれたのか。。。冗長な線であることは違いないが。。。

設問２
・外部キー（製造番号と品目コード）があるからと，線を引きまくるとビジネスロジックにないリレーションを引くことになる。
・ビジネスロジックでの「暗黙のリレーション」は概念データモデルでは線を引かない。いや，引けないはずだ。
・外部キーの下点線。「○○番号」だからといって外部キーとは限らない。
　（発注明細の主キーは｛発注番号，発注明細番号｝である場合，あるテーブルに「発注明細番号」しかない場合）

設問３
・外部キーの下点線。「○○番号」だからといって外部キーとは限らない。
　（発注明細の主キーは｛発注番号，発注明細番号｝である場合，あるテーブルに「発注明細番号」しかない場合）
　・・・見直し時に，引き忘れ！っと思って思わず引いてしまったんだよな。。。（苦；
・理由の説明は問題文から引用を。

【関連記事】
　アイテック模試午後II 完了
　アイテック模試午後II
　模試帰ってくる

アイテック模試午後I 問３
　データベース分析・設計系問題（問題の概要についてはここを参照されたし）

設問１
・主キーの線引き。問題文を読まなくても線が引けるが，念のため確認を。

（別視点）
設問１（２）を正規化理論っぽく分解すると
　発注(発注番号，発注年月日）
　発注明細１（発注番号，ＳＫＵコード）
　発注明細２（発注番号，ＳＫＵコード，発注枝番，納品予定年月日，発注数量）
と，できるのかも。設計的には「発注明細１」は不要でしょうね。。。

設問２
・連関エンティティの実装
・売上原価の要件をうまく解釈できず。問題文の表現が良くないのでは。。。

発注した商品が仕入先から納品されると，納品単位で仕入伝票番号を付与する。“仕入明細”は，納品された商品の明細で，ＳＫＵ別に仕入数量と仕入単価を保持する。Ｍ社は売上原価を，その都度後入先出によって把握するが，“仕入明細”はこの売上原価を計算する場合の基礎資料となる。

設問３
・汎化＆カテゴリ識別子
・組合せグループ管理

【関連記事】
　模試帰ってくる
　アイテック模試午後I
　アイテック模試午後I 完了

アイテック模試午後I 問２
　SQL系問題（問題の概要についてはここを参照されたし）

問１，問３の見直しに時間をかけたせいもあって，問２はケアレスミスが多かった。
見直しの時間配分も考えないとな。。。

設問１
・ａ，ｂ，ｃと順番に埋めていっても良いが，順番に拘らず，分かる所から埋めていって全体の雰囲気を掴んだ方が時間短縮できそう。
・WHERE の条件文を無意識に「AND」で繋がないように。。。（情けなや）
・条件で『 [ 　]　'日付' AND '日付'』，BETWEENが入るのは言うまでもないが，何のBETWEENか列名を忘れないように。
・GROUP BY句はSELECTの列名にあわせて
・必要なテーブル名の修飾を忘れずに。（全部修飾するという解答もアリか？ｗ）
・余計なテーブルをFROM句に指定していないか見直すこと
・『副問合せ AS 相関名（別名）』があったら，相関名はどこかで参照されている。
・HAVING！
・ORDER BYの降順は「DESC」，昇順は「ASC」（省略可）

設問２
　サマリテーブルの設計
・提示されている表の属性のうち「マスタ系の導出可能属性」を除いた属性をきちんと保持するように

設問３
NOT EXISTSが２段の商演算（デ技P106）
　基本は設問１と同じ。

【関連記事】
　模試帰ってくる
　アイテック模試午後I
　アイテック模試午後I 完了

アイテック模試午後I 問１
　基礎理論系問題（問題の概要についてはここを参照されたし）

設問１
　・図は「主な関数従属性」である。問題文，意味と制約で示されている関数従属を見落とさないように。
　・正規形の理由。前問で候補キーを指摘していても，候補キーを例示すること。（減点された。。。）

設問２
　・推移的関数従属の指摘で，「候補キー→候補キー→非キー属性」としないように。

（問題へのクレーム）
　「同じ法人部門から同一年月日時分に荷届先の異なる複数の配送を受け付けることがある。」
　　の記述で
　「同じ法人部門から同一年月日時分に同一荷届先の複数の配送を受け付けることはない。」
　　とは読めないのでは。。。
　問題の流れで気付くけど。。。

設問３
　解説ではここの疑問が拭えない。。。

　配送料金サイズ種別（料金コード，サイズ，配送種別）
　配送料金発着地（料金コード，発地コード，着地コード）

　と，分割したスキーマで

　配送料金は配送距離（発地コードと着地コードの組合せ）と配送品のサイズ，配送種別（通常便またはクール便）によって決まる。

　と，いう要件を不具合なく満たせるのだろうか。。。
　まぁ，そういう料金体系なんだろう。。。

【関連記事】
　模試帰ってくる
　アイテック模試午後I
　アイテック模試午後I 完了

問16　スパイラルモデルの説明　正解率：46.6%
　スパイラルモデルとラウンドトリップを混同。。

スパイラルモデル
　独立性の高いサブシステムごとに，設計，プログラミング，テストを行い，順次サブシステムごとに繰り返していく手法である。

ラウンドトリップ
　要求分析，システム設計，製造，テスト，運用，保守という順に逐次作業を進める開発手法である。

問28　ER図によるネットワーク表現　正解率：21.2%
　ER図のループ構造（自己参照リレーション）のロール名の読み方が逆だった。。。
　意味合いを考えて，ちゃんと見直せば間違いに気付いたと思うなぁ。。。勿体無い。

問29　適切なER図　正解率：67.3%
　ER図のロール名をミスり，冗長な方を誤選択。
　「住む場合もあり，住まない場合もある」に惑わされたな。。反省

問30　カーソル　正解率：37.2%
　SQL（CURSOR）の問題。条件反射的に過去問で見たことがある選択肢（H15AM31,H16AM31）を選ぶ。
　「CURRENT OF」は位置付けUPDATEとDELETEの場合の構文と。。。
　ん～。。。SQLは応用が全く効いてない（苦笑

問32　同じ結果が得られるSQL文　正解率：42.3%
　正解はしたものの。。。「商品.価格」と「注文.注文番号」は無視でいいんすか。。。

問37　分散DBの透過性　正解率：47.9%
　ポカミスっぽい。アだけ読んで誤選択肢「移動に対する透過性」をマークっぽいな。。。
　位置に対する透過性：「データベースが分散配置されていても，利用者は分散業況を意識しないで利用できる。」
　デ技：P190 (5)透過性の実現

問38　ACID　正解率：24.3%
　一貫性を問われ迷うことなく隔離性を選択している。。。「順番」という単語に惑わされた？
　一貫性：「トランザクション処理の終了状態にかかわらず，データベースは一貫性を保っていること」（デ技P123）
　・H16AM39:「データベースの内容が矛盾のない状態であること」
　・H15AM30:「トランザクションの実行の結果が矛盾した状態になることはない。」
　・H14AM38:「データベースの整合性制約を保つ。」

問39　READ UNCOMMITTED　正解率：38.6%
　アイソレーションレベルはちとニガテ意識が。。。
　READ UNCOMMITTEDのトランザクションに書込みを認めない理由。
　書込むと「ダーティライト」ということですか。。。デ技P132-133

問40　性能問題と適切な解決策　正解率：30.7%
　お～。。。再編成のつもりで再構成を選択していた。。。
　オーバーフロー領域：再編成
　並行実行性：SERIALIZABLE → REPEATABLE READ
　ランダムアクセスの大きいＤＢ：複数ディスク分割

問42　整合性制約　正解率：74.1%
　参照制約＝外部キー制約っすね。。。

問45　インデックス　正解率：12.1%
　「二項のファイル」ってそういう意味だったのね。。。（キー値，ポインタ）
　ビットマップインデックスは，値の種類が少ない列に付けても有効。（次元データに有効）

問46　JavaとJDBC　正解率：43.2%
　守備範囲外っす。捨てかな。

問52　セキュリティポリシ　正解率：14.5%
　クソ問題ｗ

【関連記事】
　アイテック模試午前完了
　アイテック模試午前
　模試帰ってくる

アイテック公開模擬テスト＠午後II

問1：中堅製造メーカの生産関連業務の概念データモデル
問2：勤務実績管理システムの概念データモデルとデータベース設計

問題をざっと見て
問1はスーパータイプ／サブタイプ系
問2はH16午後II 問1に酷似した「テーブルの制約」が見えて
問2の方が簡単そうに見えたので，問1を選択。

問１
　設問１　未完成の概念データモデルその１
　　設問１（１）　エンティティタイプ名の穴埋め
　　設問１（２）　リレーションシップの補完　（スキーマ＆(3)から）
　　設問１（３）　スキーマ構造の補完　（帳票からのボトムアップ）
　設問２　未完成の概念データモデルその２
　　設問２（１）　リレーションシップの補完　（スキーマ＆(2)から）
　　設問２（２）　スキーマ構造の補完　（要件＆画面イメージから）
　設問３　サブタイプ化，汎化，専化
　　設問３（１）　サブタイプ化時の関係スキーマ（共通でない属性の指摘）
　　設問３（２）　サブタイプ化時の関係スキーマ（共通でない属性の指摘）
　　設問３（３）　スーパータイプ／サブタイプの関係スキーマ
　　設問３（４）　スーパータイプ／サブタイプ化する理由

設問１（１）はH16午後II 問1の設問１（１）に酷似
設問２はH13午後II 問1の設問３に似ている
設問３はH16午後II 問2の設問３に酷似

設問１
　設問１（３）で図５のグロス生産の作業オーダに人名以外に，「製造番号」が入っていることに気付くのが遅れ時間を浪費する（遠い目）

設問２
　設問２（１）は１：１か１：多か要件を問題文で確認しながら慎重に。

設問３
　設問２がきちんとできていないと設問３がツライ。連鎖的に不正解になる可能性を秘めている。
　設問３をやりながら，設問２のミスをチェックするといった感じ。
　H16午後II 問2をきちんと理解できていれば苦労は少ない。（と，思う）

関連記事
　アイテック模試午後II 完了
　アイテック模試届く
　模試

アイテック公開模擬テスト＠午後I

問1：データベースの基礎理論
問2：SQL
問3：データベース設計
問4：データベースの業務運用

もちろん，問1，問2，問3を選択

問１
基礎理論：物流会社の配送管理に関するデータベース
　設問１（１）　候補キーの指摘
　設問１（２）　正規形名の指摘とその理由
　設問２（１）　非キー属性の指摘
　設問２（２）　推移的関数従属の指摘
　設問２（３）　推移的関数従属の更新不良の具体例
　設問２（４）　第3正規形への分割
　設問３（１）　自明でない多値従属性の記述
　設問３（２）　ボイスコッド正規形であるが第4正規形でない理由
　設問３（３）　第4正規形への分割

　設問１（１）と設問２（１）が逆だが，H16午後I 問1の題材が変わっただけ。

　ひっかかるのは，設問３（３）
　「H16午後I 問1」的にこう書かせたいのかなというのは容易に想像がついたがｗ
　その分割をするとインスタンス（表２）的にはＯＫなんだが，表１の意味と制約を満足できるのか疑問。
　でも，他にどうしろと。。。
　とりあえず，「こう書かせたい」というのは書かずに，意味と制約を満足できる分割を施す。（たぶん不正解なんだろうな。。）

問２
SQL：クレジット会社の販売分析システム
　設問１（１）　SQLの穴埋め（副問合せ）
　設問１（２）　集約テーブルに必要な列名の指摘
　設問２（１）　SQLの穴埋め（副問合せ）

　H16午後I 問2の設問２（３）が設問２（２）になり，テーブル構造はH16午後I 問2とH13午後I 問２を合体させたような感じ。
　時間があれば間違わない問題でしょう。
　図２が。。。「○○博満，△○仙一，○□大介，□○彰」。。。彰ってダレだ。。。分からん。

問３
データベース設計：衣類品小売業の販売管理システム
　設問１（１）　主キーの指摘
　設問１（２）　冗長なテーブル構造の正規化
　設問２（１）　テーブルへの列名の追加（時系列性保持）
　設問２（２）　テーブルの追加（記述エンティティ/連関エンティティどっちだ！？）
　設問２（３）　テーブルの追加（連関テーブル:後継品）
　設問３（１）　テーブルの統合（エンティティタイプの同一化）
　設問３（２）　テーブルの追加（組合せ管理）
　設問３（３）　テーブルの追加（組合せ管理）

　題材はH15午後II 問2に類似。午後I にしてはボリュームがあり過ぎると思うのだが。。。

　ひっかかるのは，設問２（２）
　後入先出法での売上原価管理のためのテーブル追加
　「入」の方は仕入明細で分かるので「出」と「入」と対応させて管理できればいい。
　「出」の管理を
　・仕入明細の明細として数量を管理する方法 と
　・販売実績明細と仕入明細の多対多の関連と数量を管理する方法 と
　ふたつあると思うが，要件からどっちが良いのか判断できない。
　解答はとりあえず，後者で書いてみた。

　あと，設問３（１）。
　同一化するのはいいんだけど，カテゴリ識別子の要否が不明。
　とりあえず，区分として書いておく。

関連記事
　アイテック模試午後I 完了
　アイテック模試届く
　模試

アイテック公開模擬テスト＠午前

問01～20：コンピュータシステム，システムの開発と運用
問21～45：データベース技術
問46～55：セキュリティと標準化（うちセキュリティ7問）

問題について，調べた内容は以下のとおり

問13
　最近流行り(?)のwebサービス

問33
1.　SELECT * FROM 商品 CROSS JOIN 注文
2.　SELECT * FROM 商品 JOIN 注文 ON 商品.商品コード = 注文.商品コード
3.　SELECT * FROM 商品 JOIN 注文 USING 商品コード
4.　SELECT * FROM 商品 NATURAL JOIN 注文

1=直積，4=自然結合
2,3は等結合なのか自然結合なのか。。。NATURALがないので等結合だよな。
選択リストで列名を指定せず「*」で出力しているサンプルがない。。

3は
　SELECT * FROM 商品 JOIN 注文 USING (商品コード)
カッコはいらないのか？？

問46
　Java＆JDBCに関する問題。守備範囲外 (?_?)
　・EJBは，米Sun Microsoft社が公開した分散コンピューティング環境のコンポーネント仕様（デ技P424）
　・JDBCのAPIは，X/OPENのSQL/CLIに基づいて設計されている（デ技P426）
　・一度張ったDBコネクションをAPサーバがプールし，次に同じユーザや他のユーザからDBアクセスのリクエストが来たとき，そのDBコネクションを利用する。（デ技P428）
　・自動コミットモード

関連記事
　アイテック模試午前完了
　アイテック模試届く
　模試

過去問に飽きたころ↓に挑戦してみよう！
iTAC内テクニカルエンジニア（データベース）掲示板（2002.05.01-2003.12.31までのログ）より

設問１

設問２

問題（設問2）　投稿者：シカ狂う　投稿日：3/12 14:17:40

> ＜主キー＞
> 被保険者記号、被保険者番号、交付年月日
> ＜外部キー＞
> 色コード、続柄コード1、続柄コード2、続柄コード3、続柄コード4

グッドです。おそらく問題ないかと。
（私も受験生な身分である手前、あまり自信がないので怪しい所あったら突っ込みお願いします）

> [被保険者記号]→[保険者番号]
> 保険証の更新は組合に関わらず全国統一ってことで、
> 整理：[交付年月日]→[色コード] （交付年月日がある期間に属している場合、色コードが一意に決定する）

ではそれも踏まえてそろそろ次の設問を。

被保険者（交付年月日、色コード、被保険者記号、被保険者番号、
被保険者氏名、フリガナ、被保険者住所、被保険者生年月日、資格取得年月、
事業所所在地、事業所名称、
保険者所在地、保険者番号、保険者名称、
被扶養者氏名1、被扶養者フリガナ1、続柄コード1、生年月日1、性別1、
被扶養者氏名2、被扶養者フリガナ2、続柄コード2、生年月日2、性別2、
被扶養者氏名3、被扶養者フリガナ3、続柄コード3、生年月日3、性別3、
被扶養者氏名4、被扶養者フリガナ4、続柄コード4、生年月日4、性別4）

設問2
関係“被保険者”は、第1、第2、第3の各正規形のいずれに該当するか、最も適切な正規形名を答えよ。
また、その根拠を、
(1)40字以内で述べよ。（短めバージョン）
(2)具体的に80字以内で述べよ。（長めバージョン）
（H14からは例のH12のボイスコッド正規形とも思わせるアヤ問を排除するために、
このような親切な該当方式に変えたんでしょうかね。）

ちなみに
> ＜主キー＞
> 被保険者記号、被保険者番号、交付年月日
> ※ 同じ日に2回以上再交付をしないことが条件（多分無いと思うけど）

ではオマケ設問。
同じ日に2回以上再交付の可能性がある場合、これを一意に識別するにはどのような属性を追加すればよいか。
追加すべき属性名を答え、その値の設定方法を述べよ。

過去問に飽きたころ↓に挑戦してみよう！
iTAC内テクニカルエンジニア（データベース）掲示板（2002.05.01-2003.12.31までのログ）より

設問１

健康保険被保険者証の様式をヒントにボトムアップアプローチの問題　投稿者：シカ狂う　投稿日：3/10 14:08:34

システムの帳票、画面からのデータ項目の拾い出し→正規化→E-Rモデルの作成
をボトムアップアプローチといいます。
午後Ⅱの定番ですが、以下のような健康保険被保険者証の様式をヒントに、そのような問題を作問してみようと思います。
（あくまで作問に徹しているため、下の様式は現実とかけ離れている箇所もあるかと思いますがご容赦ください）

　　　　　　　　　　　　健康保険被保険者証
交付年月日　　　：2000年01月01日
被保険者番号　　：111111
被保険者氏名　　：川崎次郎　フリガナ：カワサキジロウ
被保険者住所　　：神奈川県川崎市高津区高津1-2-3
被保険者生年月日：1945年01月01日
資格取得年月　　：1970年08月
事業所所在地　　：神奈川県横浜市中央区中央1-2-3
事業所名称　　　：あいうえお株式会社
保険者所在地　　：神奈川県横浜市○○区○○1-2-3
保険者番号　　　：1111
保険者名称　　　：○○社会保険事務所

被扶養者氏名　　　フリガナ　　続柄コード　続柄　　生年月日　　　性別
川崎花子　　　カワサキハナコ　　　02　　　妻　　1950年02月02日　女
川崎智子　　　カワサキトモコ　　　21　　　長女　1975年03月03日　女

（念のため、住所はH13春DB午後Ⅰ問2を引用したものであり、実在するものではありません。）

まずこれを関係スキーマとして表してみます。

被保険者（交付年月日、被保険者番号、被保険者氏名、被保険者住所、被保険者生年月日、
資格取得年月、事業所所在地、事業所名称、保険者所在地、保険者番号、保険者名称、
被扶養者氏名1、被扶養者フリガナ1、続柄コード1、生年月日1、性別1、
被扶養者氏名2、被扶養者フリガナ2、続柄コード2、生年月日2、性別2、
被扶養者氏名3、被扶養者フリガナ3、続柄コード3、生年月日3、性別3、
被扶養者氏名4、被扶養者フリガナ4、続柄コード4、生年月日4、性別4）

続柄（続柄コード、続柄名）

#「性別」はさすがに2値なのでコード化しないほうがよいでしょうか。

問題点1：主キー、外部キーが明示されていない。

設問1
関係スキーマ“被保険者”の主キー、外部キーを示せ。

この題材のおもしろさは、“被保険者”をうまく工夫して分割して正規化すると、
家族が被扶養者から抜け出した国民健康保険被保険者証のようなスキーマが得られることです。
（ってかなりかなり無理があるでしょうか^^；）

Re:問題　投稿者：シカ狂う　投稿日：3/10 21:10:28

あ、そういえばこれってけっこう業務知識がいるので、属性の意味を書き忘れてました。
とりあえず必要最低限なものだけ。

被保険者番号：健康保険組合の中で一意になるように振られた、被保険者を識別する番号
　健康保険組合に入った順番に新しい番号が付与される。
保険者番号：健康保険組合を一意に識別する番号
　2002年10月1日現在の全国の健康保険組合数は1,687である。

もしかして現実とはちょっと違うでしょうか？あまり詳しくないのでどんどん突っ込みお願いします。

問題（条件追加）　投稿者：シカ狂う　投稿日：3/10 22:50:24

健康保険被保険者証は定期的に再交付せねばなりません。
健康保険被保険者証は再交付ごとに色が変わり、その一つ一つを識別したい。

Re:問題　投稿者：シカ狂う　投稿日：3/11 10:03:46

> ただ、紛失などによる再交付でも色が変わるのか？
> また、被保険者証の色が保持されていなくてもいいのか？という点を確認したいところです。

なるほど、では紛失などによる再交付の場合は色は変わらないものとします。
以下のように色テーブルを新たに追加し、色コードという属性を“被保険者”に追加します。
同じ色の再利用はしないものとします。

また、少し勘違いしていたようなのですが、
> 被保険者番号：健康保険組合の中で一意になるように振られた、被保険者を識別する番号
> 健康保険組合に入った順番に新しい番号が付与される。
ではなく、
被保険者番号：健康保険組合に加入している会社の中で一意になるように振られた、被保険者を識別する番号
　会社に入った順番に新しい番号が付与される。
であり、新たに
被保険者記号：会社を一意に識別する記号
というのを設けます。
#場合によっては、この記号と番号を一緒にして記号番号としているところもあるようですが、ここでは分けます。

被保険者（交付年月日、色コード、被保険者記号、被保険者番号、
被保険者氏名、フリガナ、被保険者住所、被保険者生年月日、資格取得年月、
事業所所在地、事業所名称、
保険者所在地、保険者番号、保険者名称、
被扶養者氏名1、被扶養者フリガナ1、続柄コード1、生年月日1、性別1、
被扶養者氏名2、被扶養者フリガナ2、続柄コード2、生年月日2、性別2、
被扶養者氏名3、被扶養者フリガナ3、続柄コード3、生年月日3、性別3、
被扶養者氏名4、被扶養者フリガナ4、続柄コード4、生年月日4、性別4）

続柄（続柄コード、続柄名）

色（色コード、色名称）

設問３（１）

解答例
　「レンズだけあるいはフレームだけを買い換えた場合である。」

記述はどちらの立場で？
　お客さまの視点： 買い換えた場合
　お店の視点： 販売した場合

どっちでもいいよね。きっと。
でも，顧客（システム利用者）と話す時は，後者のお店の視点よね。たぶん。

納得いかんぞＩＴＥＣ！！

参照成約の問題

参照表の外部キーで参照されている被参照表の対応する主キーを削除するとき，参照している外部キーの値を含む行を削除する場合がある。

参照表＝子テーブル
被参照表＝親テーブル

置き換えてみる

　子テーブルの外部キーで参照されている親テーブルの対応する主キーを削除するとき，参照している外部キーの値を含む行を削除する場合がある。

しっくりこない

　「子テーブルの主キー」を「外部キーとして参照している親テーブルのレコード（行）」を削除するとき，「子テーブルのレコード（行）」を削除する場合がある。

なら分かるんだけどね。。。