データベーススペシャリスト試験 2012年 午後1 問02
データベースの設計に関する次の記述を読んで、設問1〜3に答えよ。
D 社は、教育、生活など、様々な分野にわたる書籍の出版及びメディアを提供する会社である。幾つかの部門では会員制の Web サイトを立ち上げ、販売促進に利用している。しかし,Web サイトごとに会員登録が必要であり、利用者から改善の要望が寄せられていた。また、D 社にとっても複数の Web サイトにまたがる共通のサービスを提供できないなどの問題があった。
D 社は、各 Web サイトがもつ会員情報を統合管理するための会員管理システムを構築することとなり、そのための新データベースの設計を情報システム部のJ君が担当することになった。
〔新データベース上で扱う情報〕
(1) 会員とは,Web サイトを利用するために必要な情報を登録した利用者である。 会員には、一般会員と期限付き会員の会員区分がある。
① 一般会員とは、個人情報、認証情報などを D 社に提示して会員登録し,Webサイトの全てのコンテンツを閲覧できる会員である。
② 期限付き会員とは、簡便な会員登録だけを行い、特定のコンテンツだけが閲覧できる会員である。 一般会員と異なり、定められた有効期限を過ぎると Webサイトを利用できなくなる。
(2) 会員は,Web サイトごとに利用登録を行うことで、その Web サイトを利用することができる。会員が利用する Web サイトごとに利用開始年月日を管理する。
(3) サービスとは、“ニュース”、“ブログ”など,Web サイトで提供される会員向けの機能である。サービスは,Web サイトごとに複数提供され、Web サイト ID とサービスID の組合せによって識別される。
(4) コンテンツとは、ブログサービスの“記事一覧”、“コメント投稿”など、サービスを構成する個々の要素である。 コンテンツはコンテンツIDによって識別され、コンテンツごとに Web サイトのトップページの URL からの相対パス(ディレクトリ)が特定される。 また、会員はログイン後に任意のコンテンツをお気に入りとして登録することができる。お気に入りは、登録した日時の順に表示される。
(5) 権限区分とは、コンテンツに対して利用が可能な権限の種類である。権限区分には“参照可”、“参照不可”、“参照及び投稿可” の3種類があり、コンテンツ ID と会員区分の組合せでいずれかに定められる。
(6) 掲示板とは、メッセージを投稿し、会員同士でコミュニケーションを行うための機能である。会員は、タイトルと説明文を入力して掲示板を開設することができる。掲示板は,Web サイト ID と掲示板 ID の組合せによって一意に識別される。
(7) メッセージとは、掲示板に投稿された文章である。会員は、掲示板にメッセージを新規投稿できるだけでなく、第三者からの投稿メッセージに対して返信することができる。 メッセージの返信が行われると、返信対象の投稿メッセージ (親メッセージ)との関係はツリー構造で表示される。 メッセージは、掲示板単位に連番のメッセージ番号によって、一意に識別される。
〔Web サイト、掲示板の例〕
D社で運営している Web サイトの例を図1に、掲示板の例を図2に示す。


〔新データベースのテーブル構造の設計〕
J君は、新データベースのテーブル構造を図3のように設計した。
なお、“掲示板” はサービスと同様に Web サイトの一機能であるが、サービスとは異なるテーブルとして設計した。

J君の上司であるK部長は、J君が設計したテーブル構造をレビューし、次の①〜③を指摘した。
〔K部長の指摘事項〕
① 図3中のテーブルの一部に、列名、主キー、外部キーが記入されていない。
② “掲示板” テーブルは、第3正規形に正規化されていない。
③ 掲示板に投稿されたメッセージに対する返信が、どのメッセージに対する返信であるかを管理できない。
〔事業部門からの要望〕
設計の途中で、事業部門から次の要望が寄せられ、対応することになった。
(ア) 有償サービスの提供:D 社で作成した付加価値の高いコンテンツは、有償で提供したい(例:月額課金制で電子書籍などの特定コンテンツの閲覧・ダウンロードができるサービス)。
J君はこの要望に対応するために、次の内容について概念データモデル上で検討した。
・会員の区分として、一般会員、期限付き会員の他に、“有償会員”を新規に追加する。
・サービスの区分として、“有償サービス”を新設する。 〔新データベースのテーブル構造の設計〕 で定義したサービスは“無償サービス”とする。
・有償会員が購入したサービスを管理するために、“購入サービス”を新たに定義する。
(イ) メールマガジンの配信: Web サイトに関連する情報を提供するために、会員向けのメールマガジン (以下、メルマガという)を配信したい。
この要望に対する業務要件は次のとおりである。
・Web サイトは、複数種類のメルマガを配信できる。 メルマガは Web サイト IDとメルマガ ID の組合せによって一意に識別し、メルマガ名を管理する。
・配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する。
・会員は、利用している Web サイトについて、複数のメルマガを購読できる。 会員が購読しているメルマガごとに、購読開始日を管理する。
・メルマガを購読している会員は、当該メルマガのバックナンバを閲覧できる。
〔データの移行〕
J君は、各 Web サイトの重複した会員データを統合することを視野に入れ、データの移行作業の検討を行った。まず,J君は複数の既存 Web サイトのデータベースから、“一般会員” テーブルに相当する登録済の会員データを入手し、整理した。 Web サイトA〜Cから抽出した会員データの一部を、それぞれ表 1〜3 に示す。
なお、表 1,2のテーブルの主キーは会員番号であり、それぞれ異なるルールで番号が割り振られている。 また、表3のテーブルの主キーはメールアドレスである。



次にJ君は整理した結果を踏まえて、データを移行するための作業内容及び作業方法を検討し、次の表4の手順で移行データの作成を行うことにした。 また、表4の作業は、各 Web サイトから抽出した会員データが保存された作業用ファイル上で行うことにした。

解答に当たっては、巻頭の表記ルールに従うこと。
なお、テーブル構造の表記は、"関係データベースのテーブル (表) 構造の表記ルール” を用いること。 さらに、主キー及び外部キーを明記せよ。
設問1:J君が設計したテーブルの構造(図3)に対する 〔K 部長の指摘事項〕について、(1)〜(3)に答えよ。
(1)
図3 中の(a)〜(c)に適切な字句を入れ、主キーを示して、“お気に入り”テーブルを完成させよ。また、“サービス”、“コンテンツ”及び“利用権限”テーブルの主キー、外部キーを示せ。(a, b, cは順不同)
模範解答
a:会員番号
b:コンテンツ
c:登録日時
サービス(WebサイトID 、サービスID、サービス名)
コンテンツ(コンテンツID、WebサイトID、サービスID、コンテンツ名、ディレクトリ)
利用権限(コンテンツID、会員区分、権限区分)
解説
解答の論理構成
-
“お気に入り”テーブルの列決定
- 引用【問題文】(4)「会員はログイン後に任意のコンテンツをお気に入りとして登録」
- 同じ(4)「お気に入りは、登録した日時の順に表示」
→ 必要列=会員を特定する「会員番号」、対象コンテンツを特定する「コンテンツID」、表示順を決める「登録日時」。
→ 1 会員が同一コンテンツを複数登録しない運用なら、主キー=(会員番号、コンテンツID)。
-
“サービス”テーブル
- 引用【問題文】(3)「サービスは、Web サイトごとに複数提供され、Web サイト ID とサービスID の組合せによって識別」
→ 主キー=(WebサイトID, サービスID)。
→ 外部キー:WebサイトID → “Webサイト”テーブル(想定)。
- 引用【問題文】(3)「サービスは、Web サイトごとに複数提供され、Web サイト ID とサービスID の組合せによって識別」
-
“コンテンツ”テーブル
- 引用【問題文】(4)「コンテンツはコンテンツIDによって識別され」
- さらに「サービスを構成」なのでサービスにも従属。
→ 主キー=コンテンツID。
→ 外部キー:(WebサイトID, サービスID) → “サービス”テーブル。
-
“利用権限”テーブル
- 引用【問題文】(5)「権限区分には… コンテンツ ID と会員区分の組合せでいずれかに定められる」
→ 主キー=(コンテンツID, 会員区分)。
→ 外部キー:コンテンツID → “コンテンツ”テーブル、会員区分 → “会員”マスタ。
- 引用【問題文】(5)「権限区分には… コンテンツ ID と会員区分の組合せでいずれかに定められる」
-
まとめて表記
- お気に入り(<主キー>会員番号、コンテンツID, 登録日時)
- サービス(<主キー>WebサイトID, サービスID, サービス名)
- コンテンツ(<主キー>コンテンツID, <外部キー>WebサイトID, サービスID, コンテンツ名、ディレクトリ)
- 利用権限(<主キー>コンテンツID, 会員区分、権限区分)
誤りやすいポイント
- 「b:コンテンツ」を「コンテンツ名」と取り違え、主キー列を誤記する。正しくは「コンテンツID」。
- “サービス”の主キーをサービスID単独にしてしまい、Webサイト間で重複する可能性を見落とす。
- “利用権限”で「権限区分」を主キーに含めてしまう。問題文は「コンテンツ ID と会員区分の組合せでいずれかに定められる」と明示。
FAQ
Q: “お気に入り”で「登録日時」を主キーに含めなくても良いのですか?
A: はい。表示順を決めるための列なので一意性を担保する必要はなく、複合主キー(会員番号、コンテンツID)で一意に識別できます。
A: はい。表示順を決めるための列なので一意性を担保する必要はなく、複合主キー(会員番号、コンテンツID)で一意に識別できます。
Q: “コンテンツ”の主キーを複合キーにしない理由は?
A: (4) で「コンテンツはコンテンツIDによって識別される」と明言されているため、単一キーで十分です。
A: (4) で「コンテンツはコンテンツIDによって識別される」と明言されているため、単一キーで十分です。
Q: “利用権限”に「権限区分」が外部キーとして不要なのは?
A: 「権限区分」はマスタ管理(“参照可”等)される可能性がありますが、問題文は参照規定を示していないため、ここでは外部キー要件に含めません。
A: 「権限区分」はマスタ管理(“参照可”等)される可能性がありますが、問題文は参照規定を示していないため、ここでは外部キー要件に含めません。
関連キーワード: 複合主キー、外部キー制約、第3正規形、エンティティ識別、正規化
設問1:J君が設計したテーブルの構造(図3)に対する 〔K 部長の指摘事項〕について、(1)〜(3)に答えよ。
(2)
“掲示板”テーブルは、第1正規形、第2正規形、第3正規形のうち、どこまで正規化されているかを答えよ。 また、その判別根拠を75字以内で具体的に述べよ。
模範解答
正規形:第1正規形
判別根拠:属性が全て単一値をとり、タイトル、説明文などの属性が、候補キーの一部である Webサイト ID,掲示板 IDに対して部分関数従属している。
解説
解答の論理構成
- 【問題文】にある〔K部長の指摘事項〕「② “掲示板” テーブルは、第3正規形に正規化されていない。」が出発点。
- “掲示板”テーブルの候補キーは【問題文】「掲示板は、Web サイト ID と掲示板 ID の組合せによって一意に識別される。」から“Web サイト ID”+“掲示板 ID”。
- “タイトル”や“説明文”は掲示板固有情報なので、“掲示板 ID”だけで一意になります。これは「複合キーの一部(掲示板 ID)のみ」への依存=部分関数従属。
- 部分関数従属が残っている関係は第2正規形を満たさないため、第1正規形止まりとなります。
- したがって模範解答の「正規形:第1正規形」「判別根拠:…部分関数従属している。」が導かれます。
誤りやすいポイント
- 「列が重複しないし繰返しもないから第3正規形」と早合点しやすい。複合キーの依存関係をチェックしないミスが頻発。
- 「掲示板 ID が一意だから単一キー」と勘違いし、“Web サイト ID”を候補キー要素から外してしまう。
- 第2正規形と第3正規形の区別を「部分関数従属」「推移的関数従属」の違いで整理できず混同する。
FAQ
Q: “掲示板 ID”を全体で一意に振れば第3正規形になりますか?
A: なります。ただし「Web サイト ID」との複合キーを解消し、外部キーとして“Web サイト ID”を保持する新設計が必要です。
A: なります。ただし「Web サイト ID」との複合キーを解消し、外部キーとして“Web サイト ID”を保持する新設計が必要です。
Q: 部分関数従属を解消する典型的な方法は?
A: 部分関数従属している属性を切り出し、新しいテーブル(ここでは“掲示板”を掲示板基本情報テーブルとし、“Web サイト-掲示板対応”テーブルを追加など)に分割して正規化します。
A: 部分関数従属している属性を切り出し、新しいテーブル(ここでは“掲示板”を掲示板基本情報テーブルとし、“Web サイト-掲示板対応”テーブルを追加など)に分割して正規化します。
Q: 正規化を進めるとパフォーマンスが落ちるのでは?
A: 第2・第3正規形への正規化は更新・整合性の利点が大きく、検索速度はインデックス設計やビューで補えます。不要な冗長性放置による異常のほうがリスクです。
A: 第2・第3正規形への正規化は更新・整合性の利点が大きく、検索速度はインデックス設計やビューで補えます。不要な冗長性放置による異常のほうがリスクです。
関連キーワード: 正規化、部分関数従属、第1正規形、候補キー、関数従属性
設問1:J君が設計したテーブルの構造(図3)に対する 〔K 部長の指摘事項〕について、(1)〜(3)に答えよ。
(3)
〔K 部長の指摘事項〕 ②、③の問題を解消し、第3 正規形に分解した“掲示板” テーブルの構造を示せ。
模範解答
掲示板(WebサイトID、掲示板ID、タイトル、掲示板開設日時、説明文、掲示板開設者会員番号)
メッセージ(WebサイトID、掲示板ID、メッセージ番号、メッセージ本文、メッセージ投稿者会員番号、メッセージ投稿日時、親メッセージ番号)
解説
解答の論理構成
- 現状把握
“掲示板” にタイトルや説明文だけでなくメッセージ本文まで入っていると仮定すると、主キー〈WebサイトID, 掲示板ID〉に対しメッセージ本文は部分関数従属していない(メッセージ番号が必要)ため第3正規形違反。 - 正規化手順
① 主キーを決定:掲示板‐レベルは〈WebサイトID, 掲示板ID〉、メッセージ‐レベルはさらに〈メッセージ番号〉を加える。
② 部分関数従属の排除:メッセージ本文・メッセージ投稿者会員番号・メッセージ投稿日時は掲示板キーに「従属+追加識別子」が必要なので分離。
③ 推移的従属の排除:掲示板開設者など掲示板キーに直接依存する属性は残す。 - 返信管理
問題文(7)で「返信対象の投稿メッセージ (親メッセージ)」と明示されているため、メッセージ表に自己参照外部キー〈親メッセージ番号〉を設ける。NULL ならルート投稿、値ありなら返信投稿。 - 完成形
模範解答と同一の2表構成となり、指摘②③は同時に解消される。
誤りやすいポイント
- メッセージの主キーに「親メッセージ番号」を入れてしまう
→ 返信がない投稿で NULL を許せなくなり、主キー条件を満たせません。 - 掲示板開設者会員番号・メッセージ投稿者会員番号を単なる列として外部キー制約を設定し忘れる
→ 整合性欠如で孤児レコードが発生します。 - 「掲示板ID」だけを掲示板表の主キーにする
→ Web サイトを跨いで ID が重複する可能性を排除できません。
FAQ
Q: 「第3正規形」を一言で言うと?
A: すべての非キー属性が主キーに対して完全関数従属し、非キー同士の従属(推移的従属)がない状態です。
A: すべての非キー属性が主キーに対して完全関数従属し、非キー同士の従属(推移的従属)がない状態です。
Q: 自己参照外部キーに制約を付けると登録順序に困りませんか?
A: ルート投稿は〈親メッセージ番号〉NULL で先に登録できます。返信は親メッセージが既に存在する前提なので通常の外部キー制約で整合性を保てます。
A: ルート投稿は〈親メッセージ番号〉NULL で先に登録できます。返信は親メッセージが既に存在する前提なので通常の外部キー制約で整合性を保てます。
Q: 掲示板開設日時とメッセージ投稿日時は別テーブルにすべき?
A: 時系列分析が共通であっても、関数従属が異なるため掲示板とメッセージで別々に保持する方が正規化の原則に合致します。
A: 時系列分析が共通であっても、関数従属が異なるため掲示板とメッセージで別々に保持する方が正規化の原則に合致します。
関連キーワード: 第3正規形、外部キー、自己参照、関数従属、主キー
設問2:〔事業部門からの要望〕 について、(1)、(2)に答えよ。
(1)
要望(ア)の有償サービスの提供に対応するために、概念データモデル上で検討したときの図を次に示す。 エンティティタイプ名及びリレーションシップを記入し、要望(ア)を満たす概念データモデルを完成させよ。
なお、エンティティタイプ間の対応関係にゼロを含むか否かの表記は不要である。


模範解答

解説
解答の論理構成
-
会員側
- 要件より「一般会員」「期限付き会員」「有償会員」の3区分が必要。
- 3者はいずれもスーパークラス「会員」の下位エンティティなので、左側3枠に順に記入。
-
サービス側
- 既存サービス=無償であるため「無償サービス」
- 追加要件で「有償サービス」を新設
- したがって、右上2枠は「無償サービス」「有償サービス」
-
有償会員と有償サービスの関係
- 要件文「“購入サービス”を新たに定義する。」から、多対多対応用の連結エンティティが必要
- 右下枠に「購入サービス」を配置し、有償サービスと1対多、有償会員と1対多で結ぶ
-
リレーションシップ命名
- 会員と無償サービス:閲覧や登録を表す語として汎用性の高い「利用」
- 有償会員と購入サービス:金銭対価が発生する行為であるため「購入」
以上を満たすと図の空白はすべて埋まり、概念データモデルが完成する。
誤りやすいポイント
- 「購入サービス」をリレーションシップ(菱形)で描き、エンティティ枠を使わない
- 「有償サービス」と「無償サービス」を同じエンティティにまとめてしまい区分属性で済ませようとする
- 無償サービスにも購入リレーションシップを付けてしまう(要件外)
FAQ
Q: 「購入サービス」は本当にエンティティにしないといけませんか?
A: 多対多を解消し、購入日や金額など将来追加される可能性の高い属性を保持できるようにするため、エンティティ化しておく方が拡張性に優れます。
A: 多対多を解消し、購入日や金額など将来追加される可能性の高い属性を保持できるようにするため、エンティティ化しておく方が拡張性に優れます。
Q: 「利用」と「購入」を別リレーションシップに分ける理由は?
A: 無償サービスは支払いを伴わず、購入という概念が成立しません。行為の性質が異なるためリレーションシップを分離します。
A: 無償サービスは支払いを伴わず、購入という概念が成立しません。行為の性質が異なるためリレーションシップを分離します。
関連キーワード: エンティティ、リレーションシップ、正規化、多対多解消、概念データモデル
設問2:〔事業部門からの要望〕 について、(1)、(2)に答えよ。
(2)
要望(イ)のメルマガの配信に対応するためのテーブルの構造を示せ。なお、列名は本文中の用語を用いること。
模範解答
メルマガ(WebサイトID、メルマガID、メルマガ名)
購読メルマガ(WebサイトID、メルマガID、会員番号、購読開始日)
バックナンバ(WebサイトID、メルマガID、配信日時、メルマガ本文)
解説
解答の論理構成
- まずメルマガ自体を定義
- 【問題文】「“メルマガは Web サイト IDとメルマガ ID の組合せによって一意に識別し、メルマガ名を管理する。」
⇒ 実体:メルマガ
⇒ 主キー: WebサイトID 、メルマガID
⇒ 属性:メルマガ名
- 【問題文】「“メルマガは Web サイト IDとメルマガ ID の組合せによって一意に識別し、メルマガ名を管理する。」
- 会員とメルマガの多対多関係を解消
- 【問題文】「会員は、利用している Web サイトについて、複数のメルマガを購読できる。」
⇒ N 対 N を 1 対 N × N 対 1 に分割する中間表が必要
⇒ 実体:購読メルマガ
⇒ 主キー: WebサイトID 、メルマガID 、会員番号
⇒ 属性:購読開始日
- 【問題文】「会員は、利用している Web サイトについて、複数のメルマガを購読できる。」
- 配信履歴(バックナンバ)を管理
- 【問題文】「配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する。」
⇒ 実体:バックナンバ
⇒ 主キー: WebサイトID 、メルマガID 、配信日時
⇒ 属性:メルマガ本文
- 【問題文】「配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する。」
- 参照整合性
- 購読メルマガ と バックナンバ の外部キーは( WebサイトID 、メルマガID )で メルマガ を参照。
- 購読メルマガ の外部キー( 会員番号 )は 会員 を参照。
これで全文要件をカバーし、第 3 正規形も満たします。
誤りやすいポイント
- メルマガID を単独主キーにして「 WebサイトID を列追加」しただけにする → 複数サイトで ID が重複したとき一意性が崩れる。
- 購読メルマガ の主キーを( 会員番号 、メルマガID )とし WebサイトID を含め忘れる → 異なる Web サイトのメルマガを区別できなくなる。
- バックナンバ で 配信日時 を PK に入れず、最新だけ保持する想定にしてしまう → 履歴閲覧要件を満たせない。
FAQ
Q: 配信日時は日付列だけでも良いですか?
A: メールマガジンは一日に複数配信される可能性があるため、日時(タイムスタンプ)で管理する方が安全です。
A: メールマガジンは一日に複数配信される可能性があるため、日時(タイムスタンプ)で管理する方が安全です。
Q: 購読メルマガ の主キーに 購読開始日 を入れる必要は?
A: 「購読開始日」は履歴ではなく状態属性なので主キーに含めません。購読を解除・再登録する場合は別途履歴テーブルを追加します。
A: 「購読開始日」は履歴ではなく状態属性なので主キーに含めません。購読を解除・再登録する場合は別途履歴テーブルを追加します。
Q: バックナンバ に 会員番号 を入れてもいいですか?
A: Back ナンバは配信実体であり、閲覧権限は「メルマガを購読している会員」が判定します。従って会員番号は不要です。
A: Back ナンバは配信実体であり、閲覧権限は「メルマガを購読している会員」が判定します。従って会員番号は不要です。
関連キーワード: 正規化、複合主キー、外部キー制約、多対多関係、履歴管理
設問3:表4の移行データの作成手順について、表 1〜3 に表示されている会員データから考えられる範囲で、次の(1)〜(4)に答えよ。
(1)
Web サイト B と Web サイト Cで実施する手順1のデータの編集内容を一つずつ挙げ、それぞれ 20字以内で述べよ。
模範解答
B:氏名を姓と名に分離する。
C:住所に含まれる都道府県を分離する。
解説
解答の論理構成
- 手順1の目的を確認
- 【問題文】“旧データベースと項目の構成方法が異なるデータを編集する。”
- 具体作業:“分割・統合” によって新DBと同じ項目構成に合わせる。
- WebサイトB(表2)の列構成を確認
- 列 “氏名漢字” に “斎藤△太郎” の形式で姓と名が同一セルに格納。
- 新DBでは【問題文】表1と同様に “姓(漢字)”“名(漢字)” が別列。
- よって “姓名分離” が必須。
- WebサイトC(表3)の列構成を確認
- “住所” 列には “東京都文京区◯◯2-28-8-102” のように都道府県+市区町村以下が混在。
- 新DBでは表1・表2と同様に “都道府県” 列が独立している。
- よって “都道府県抽出” が必要。
- 以上より編集内容をまとめる
- B:氏名列を 姓 と 名 に切り出す。
- C:住所列から 都道府県 を切り出す。
誤りやすいポイント
- “フリガナを統一” など手順3で求められる標準化と混同する。
- C の編集対象を “メールアドレス” と誤認し、重複チェックを挙げてしまう。
- “分離” と “統合” の両方を羅列し、20字以内を超過する。
FAQ
Q: WebサイトBで “ふりがな” 列も編集対象に含めるべきですか?
A: 手順1は項目構成の差異解消が目的なので、姓名が一つの列になっている “氏名” が優先です。ふりがな列は別列ですが構造は同様なので、同時に分離しても差し支えありません。
A: 手順1は項目構成の差異解消が目的なので、姓名が一つの列になっている “氏名” が優先です。ふりがな列は別列ですが構造は同様なので、同時に分離しても差し支えありません。
Q: 都道府県の抽出は正規化(第3正規形)と同じ考え方ですか?
A: 目的は似ていますが、ここでは移行前データを新DBの列構成に合わせるための加工であり、テーブル設計そのものの正規化とは段階が異なります。
A: 目的は似ていますが、ここでは移行前データを新DBの列構成に合わせるための加工であり、テーブル設計そのものの正規化とは段階が異なります。
Q: 20字以内に収めるポイントは?
A: 動詞+対象+操作内容で簡潔にまとめるのがコツです(例:「氏名を姓名に分離」)。
A: 動詞+対象+操作内容で簡潔にまとめるのがコツです(例:「氏名を姓名に分離」)。
関連キーワード: データ移行、項目分割、正規化、キー統一、データクレンジング
設問3:表4の移行データの作成手順について、表 1〜3 に表示されている会員データから考えられる範囲で、次の(1)〜(4)に答えよ。
(2)
手順2 の作業方法だけでは、問題が発生する可能性がある。その問題について、原因を含めて60字以内で述べよ。
模範解答
Web サイト A と Web サイト B で採番されている番号の範囲が重複するので、データの投入時に一意制約違反が発生する。
解説
解答の論理構成
- 【問題文】の手順2の作業方法
「Web サイト A 及び B の会員番号は流用」すると定義されています。 - 各サイトの採番規則
- 表1 注1: 「連番7桁+入会年の西暦下2桁」
- 表2 注2: 「『00000000』〜『99999999』の連番」
- 規則を重ね合わせると、例えば A の「001234501」と B の「000012345」など、先頭の
0
を含めた 9 桁/8 桁の違いを無視できないまま流用すると、同一値が発生するリスクがある。 - 新 DB では会員番号が主キーとなるため、重複は「一意制約違反」を招き、移行が停止する。
- よって模範解答のように「番号範囲が重複→一意制約違反」と整理される。
誤りやすいポイント
- 「9桁と8桁だから重複しない」と思い込む
先頭ゼロ有無や桁埋め処理で同一キーになるケースを見落としがちです。 - Cサイトに番号を付番する作業だけを問題視し,A・Bの衝突を失念する。
- 重複時の影響を「データが上書きされる」と誤答し、一意制約違反という RDB のエラーを示せない。
FAQ
Q: 会員番号を文字列型で保持すれば衝突は防げませんか?
A: 文字列でも値が同じなら主キー重複です。桁数や書式の差異ではなく“値の一意性”を保証する必要があります。
A: 文字列でも値が同じなら主キー重複です。桁数や書式の差異ではなく“値の一意性”を保証する必要があります。
Q: 手順2で新規付番するのは C だけですが,A・B にも再採番すべきですか?
A: グローバルで唯一となる採番体系(プレフィックス追加、シーケンス採番など)を再設計し,A・B も含めて付け直すのが安全です。
A: グローバルで唯一となる採番体系(プレフィックス追加、シーケンス採番など)を再設計し,A・B も含めて付け直すのが安全です。
関連キーワード: 一意制約、主キー、データ移行、重複キー、番号管理
設問3:表4の移行データの作成手順について、表 1〜3 に表示されている会員データから考えられる範囲で、次の(1)〜(4)に答えよ。
(3)
手順3の作業方法に示した例以外に標準化すべきことを二つ挙げ、それぞれ30字以内で述べよ。
模範解答
①・姓と名に含まれる旧字体の漢字を新字体に変更する。
②・住所の丁目以降の表記を、算用数字とハイフンに変換する。
・市町村合併などで変更された住所を現在のものに修正する。
解説
解答の論理構成
- 手順3の目的
【問題文】“標準データに変換する”と明示。よって変換候補を抽出。 - 氏名フィールドの差異
表1“斎藤”、表2“斎藤△太郎”のように旧字体と新字体が混在。さらに“△”=空白の有無も不統一。旧→新字体に統一すれば検索一致率が向上。 - 住所フィールドの差異
表1“文京区◯◯◯2-28-8-102”、表2“文京区〇〇2-28-8-102”のように全角数字・漢数字・ハイフン種別が混在。算用数字+半角ハイフンへ統一すればソート/範囲検索が容易。
また、“千葉県千葉市中央区●1-1”と市町村合併後の“千葉市”のように古い地名が残る可能性がある。最新地名へ更新することで郵送トラブルを防ぐ。 - 以上より、模範解答の二点が適切。
誤りやすいポイント
- 「フリガナをカタカナへ統一」は手順3の例“ひらがなに変換”と重複するため不可。
- “メールアドレスのドメイン統一”は業務要件外。標準化対象は氏名・住所など“個人情報”に限定する。
- 二つ挙げよ→「住所の全角→半角」と「市町村合併後の修正」を別回答にすると30字超えや重複扱いになる恐れ。
FAQ
Q: 旧字体→新字体は外字登録でも対応できるのでは?
A: 外字は検索や外部連携で不利です。標準化で“常用漢字”へ揃える方が保守負荷が低減します。
A: 外字は検索や外部連携で不利です。標準化で“常用漢字”へ揃える方が保守負荷が低減します。
Q: 住所の最新化はマスタ参照だけで十分?
A: 郵便番号データベースなど外部マスタで自動置換後、目視確認を行う運用を定義するのが一般的です。
A: 郵便番号データベースなど外部マスタで自動置換後、目視確認を行う運用を定義するのが一般的です。
Q: “空白を削除”も回答候補になる?
A: “△は空白”は氏名カラムのフォーマットゆれですが、例示の“ひらがな変換”と同系統と判断されやすく、他の独立した観点を挙げる方が安全です。
A: “△は空白”は氏名カラムのフォーマットゆれですが、例示の“ひらがな変換”と同系統と判断されやすく、他の独立した観点を挙げる方が安全です。
関連キーワード: データクレンジング、標準化、住所正規化、文字コード、データ移行
設問3:表4の移行データの作成手順について、表 1〜3 に表示されている会員データから考えられる範囲で、次の(1)〜(4)に答えよ。
(4)
手順4中の(d)に入れる適切な作業内容を、50字以内で述べよ。
模範解答
複数の Webサイトを利用している、同一人物であると考えられる会員の会員データを特定する。
解説
解答の論理構成
- 【問題文】では手順4の作業方法に「この作業を行うための具体的な判定基準、ルールは別途定義する。」とあります。これは“判定=同一人物かどうか”を意味します。
- さらに冒頭で「各 Web サイトの重複した会員データを統合する」と述べられており、目的は重複レコードの統合です。
- 手順1〜3で形式統一までは完了していますが、まだ重複行は残存します。そこで、同一人物と考えられる複数行を「特定」する処理が必要になります。
- 以上より、(d)には「複数の Web サイトを利用している、同一人物であると考えられる会員の会員データを特定する」が妥当となります。
誤りやすいポイント
- 「削除」や「統合」と書いてしまう
手順4は“候補の特定”であり、削除・統合は手順5以降です。 - 判定基準の作成と誤解する
判定基準は「別途定義する」と既に書かれているため、(d)は基準作成ではなく特定作業です。 - 「重複データの検索」だけを書く
“同一人物であると考えられる”という主旨を明示しないと減点対象となります。
FAQ
Q: 手順2で会員番号を統一したのに、なぜまだ重複が残るのですか?
A: 会員番号は Web サイト単位で発番されており、別サイトでは同一人物でも異なる番号が付いているためです。
A: 会員番号は Web サイト単位で発番されており、別サイトでは同一人物でも異なる番号が付いているためです。
Q: 手順4で特定した後、具体的な統合はどの手順ですか?
A: 統合や削除の確定は「手順5」で「移行対象のデータを確定する」と示されています。
A: 統合や削除の確定は「手順5」で「移行対象のデータを確定する」と示されています。
Q: 判定基準にはどんな項目が使われますか?
A: 例として「姓」「名」「フリガナ」「住所」「メールアドレス」などが考えられますが、詳細は別途定義です。
A: 例として「姓」「名」「フリガナ」「住所」「メールアドレス」などが考えられますが、詳細は別途定義です。
関連キーワード: 正規化、主キー、重複データ、データクレンジング、データ統合
