| データベーススペシャリスト 平成１２年度 午後�機〔簑� |
|
|
 |
データベース設計に関する記述を読んで，設問1〜3に答えよ。
保険調剤薬局であるＭ薬局の調剤管理システムの開発を任されたＮ君は，Ｍ薬局の業務内容を元に,
データベースのテーブル構造を設計した。上司のＯ氏は，Ｎ君にデ−タの冗長性を排除したテーブル構造とするようにと指示した。
〔Ｍ薬局の業務内容〕
(1) Ｍ薬局は，複数の店とそれらを管理する本社からなる。店番号で各店を管理する。
各店には１名以上の薬剤師が配置されている。
(2) 患者には，薬とその説明書(図1)を渡す。説明書には次の事項を記載する。
1. 薬に関する情報：薬の名称，用法("朝:1個，就寝:1個"，"朝:1個，昼:1個，夕:1個"，"医師の指示どおり"など)，
用量(内外区分(内服と外用の区分)と処方量)，形/色/記号，効能/副作用など，複数の薬の間での注意事項/副作用
など
2. 医療機関，薬局に関する情報：医療機関の住所，名称，電話番号，医師名，薬局住所，名称，電話番号，薬剤師名
3. 患者に関する情報：患者名，作成日
(3) 医師が作成する処方せんには，作成日，患者指名，保険証番号，医療機関名，処方した医師，１種類以上の薬の名称，その用法と処方量(投薬日数，本数など)が記載されている。同じ医師が，同じ患者に同じ日に２回以上の処方せんを作成することはない。また同じ日に異なる医師が，同じ患者に同じ薬の異なる用法と用量を処方する場合がある。
(4) 薬の管理は次のようにする。
1. 薬は，成分量を含めた名称ごとに薬番号で識別する。
例えば，薬名"○○○ 100��"と"○○○ 500��"(○○○が同じ名称)は，異なる薬番号で管理する。
2. 製薬会社から，薬後との効能/副作用などの情報が提供される。この情報には，
・使用できない疾患
・服用に伴う副作用(食欲不振，おう吐，肝障害など)
・日常での注意点(眠気，めまいなどの発生)
・同時に服用できない薬名（成分名）
などが含まれる。これらの中から患者に伝えるものを選択し，図1の"効能/副作用など"又は，
"注意事項/副作用など"として示す。
3. "効能/副作用など"は，複数の薬で同じものがある。例えば，複数の製薬会社から発売している薬及び分量だけが
異なる薬は，すべての"効能/副作用など"が同じとなる場合がある。
4. 薬名又は薬番号が決まれば，形/色/記号が一意に決まる。
5. 薬名ごとに，内外区分，保険点数，単価，製薬会社を管理する。
┌───────────────────────────────────────┐
│ │
│ あなたにお渡しするお薬です。 │
│ 作成日 ○年○月○日│
│ □□ □□様 │
│ │
│ 薬名 形／色／記号 効能／副作用など │
│ 用法 │
│ 用量 │
│ ───────────────────────────────────── │
│ ＡＡＡＡＡ 100�咫．�プセル／赤白／319 □熱を下げる薬です。 │
│ 朝:1個，就寝:1個 ◇生活上の注意：タバコ，アルコール類，│
│ ［内服 4日分］ コーヒー類は胃腸障害を強めるおそれ │
│ があります。 │
│ ───────────────────────────────────── │
│ ＢＢＢＢＢ 100�咫‐�剤／白／KY01 □細菌感染を抑える薬です。(抗生物質) │
│ 朝:1個，昼:1個，夕:1個 ◇眠気を催すこともがありますので，車 │
│ ［内服 4日分］ の運転や危険をともなう機械の操作な │
│ どには十分気をつけてください。 │
│ ───────────────────────────────────── │
│ ＣＣＣＣＣ 7％ 顆粒／白／ □口の中の傷口や炎症部分を殺菌・消毒 │
│ 医師の指示どおり する薬です。 │
│ ［外用 12回分］ □うがい薬です。100mlの水に溶かして │
│ ください。 │
│ ◇飲み込まないでください。 │
│ │
│ ［注意事項／副作用など］ │
│ │
│ │
│ │
│ │
│ 処方せん発行 XX市YY区ZZZ1-2-3 保険薬局の XX市YY区ZZZ 2-2-2 │
│ の医療機関 ＷＷＷクリニック 住所と名称 Ｍ薬局ＨＨＨ店 │
│ 電話番号 099(999)9999 電話番号 099(999)8888 │
│ 医師名 ○○ ○○ 薬剤氏名 ○○ ○○ │
│ │
│ 他の医療機関にかかる場合には，この一覧表を見せてください。 │
│ │
└───────────────────────────────────────┘
図1 患者に渡す説明書
［テーブル構造］
Ｎ君は，業務内容に基づき，テーブル構造を図2のように設計した。このテーブル構造を見たＯ氏は，いくつかの問題点を指摘した。
問題点(1) "処方"テーブルが，第2正規形でない。
問題点(2) 異なる業者ですべての"効能/副作用など"の同じ薬が製造されているが，この場合を管理できない。
問題点(3) 複数の薬の間での"注意事項/副作用など"が，管理できていない。
店
┌───┬──┬───┬─────┐
│店番号│店名│店住所│店電話番号│
└───┴──┴───┴─────┘
薬剤師
┌─────┬────┬───┐
│薬剤師番号│薬剤氏名│店番号│
└─────┴────┴───┘
薬
┌───┬──┬─┬─┬──┬────┬────┬──┬──────┐
│薬番号│薬名│形│色│記号│内外区分│保険点数│単価│製薬会社番号│
└───┴──┴─┴─┴──┴────┴────┴──┴──────┘
効能/副作用
┌───┬──┬────────┬────────┬────┐
│薬番号│連番│効能／副作用区分│効能／副作用など│表示有無│
└───┴──┴────────┴────────┴────┘
用法用量
┌──────┬───┬────┬───┐
│用法用量番号│用法名│内外区分│単位名│
└──────┴───┴────┴───┘
医師
┌────┬───┬─────┬──┬────┐
│医師番号│医師名│医療機関名│住所│電話番号│
└────┴───┴─────┴──┴────┘
製薬会社
┌──────┬─────┬───────┐
│製薬会社番号│製薬会社名│連絡先電話番号│
└──────┴─────┴───────┘
患者
┌────┬───────┬────┬──┬──┬────┐
│患者番号│健康保険証番号│被保険者│続柄│氏名│生年月日│
└────┴───────┴────┴──┴──┴────┘
処方
┌───┬────┬───┬──────┬───┬────┬─────┐
│年月日│患者番号│薬番号│用法用量番号│処方量│医師番号│薬剤師番号│
└───┴────┴───┴──────┴───┴────┴─────┘
図2 調剤管理システムのテーブル構造
設問1
Ｏ氏が指摘した問題点(1)について，次の問いに答えよ。
（１）"薬"及び"処方"テーブルの主キー及び外部キーを，表記ルールに従い，下線で示せ。
（２）"処方"テーブルが第2正規形でない理由を，70字以内で述べよ。
（３）"処方"テーブルを第2正規形にして，主キーとなる列を表記ルールに従い，下線で示せ。
設問2
Ｏ氏が指摘した問題点(2)を解決するため，図2のあるテーブルに列を追加することにした。該当するテーブル名と追加した列名を答えよ。このとき列名は，格納するデータの意味を表す名称とせよ。
設問3
Ｏ氏が指摘した問題点(3)を解決するため，新たなテーブルを追加することにした。
（１）2種類の薬の間での"注意事項/副作用など"えお管理するテーブル構造（テーブル名，列名，主キー）を示せ。このときテーブル名及び列名は，格納するデータの意味を表す名称とせよ。また，該当する２種類の薬の間での"注意事項/副作用など"が複数列挙される場合でも，全体を一つの文字列として格納するものとする。
（２）(1)のテーブル構造に列を一つ追加し，3種類以上の薬の間での"注意事項／副作用など"を管理
できるようにした。追加した列には，どのような値を格納するかを40字以内で述べよ。
|
| 解答 |
|
|
|
|
データベースの基礎理論に関する次の記述を読んで，設問1，2に答えよ。
通信教育講座の受講生を管理するデータについて，関係データモデルに基づくモデル化を行った。
関係スキーマとして取り上げた属性を，表に示す。それらの属性間の関数従属性を，一つの関係として図示したものが図1である。図2の１は，関係“通信講座”の関係スキーマであり，2はそれを三つの関係スキーマに分解したものである。関数従属性の記法は，図3のとおりである。
表 属性及びその意味と制約
┌────────┬───────────────────────────────┐
│ 属性 │ 意味と制約 │
├────────┼───────────────────────────────┤
│会員番号 │本通信教育講座に会員登録している受験生に割り振られた一意な番号│
├────────┼───────────────────────────────┤
│氏名，住所，性別│受験生の氏名，住所，性別 │
├────────┼───────────────────────────────┤
│講座名 │開講している講座名 │
├────────┼───────────────────────────────┤
│受講番号 │新規に受講申込みをする際に，受験生ごとに振られる一意な番号。 │
│ │同じ講座を2度申し込むことはできない。 │
├────────┼───────────────────────────────┤
│学費支払日 │学費が支払わたれた年月日 │
├────────┼───────────────────────────────┤
│開始日 │教材セットを送付した日 │
├────────┼───────────────────────────────┤
│修了日 │修了書証申請が受講生からあり，資格認定で承認された年月日 │
├────────┼───────────────────────────────┤
│提出日 │課題提出の受付年月日。同じ日に二つ以上の課題答案を同時に提出す│
│ │ることは出来ない。 │
├────────┼───────────────────────────────┤
│課題答案 │課題，レポートなどの答案 │
├────────┼───────────────────────────────┤
│課題番号 │各講座事に定められている課題の連番。同じ番号の課題を再提出する│
│ │場合もありえる。 │
├────────┼───────────────────────────────┤
│指導者 │課題答案の添削指導者。受講生の受講番号ごと，講座番号ごとに事前│
│ │の担当の指導者を割り振る。 │
├────────┼───────────────────────────────┤
│講評，点数 │課題答案の添削結果の講評，点数 │
├────────┼───────────────────────────────┤
│返却日 │課題答案を返却した日 │
└────────┴───────────────────────────────┘
┌───────────┐
│ ┌───────┐ │ ┌─────┐
│ │┌─────┐├─┼──→│学費支払日│
┌─────┐ │ ││ 講座名 ││ │ └─────┘
│ 氏 名 │←┐│ │└─────┘│ │ ┌─────┐
└─────┘ ││ │ ├─┼──→│ 開始日 │
┌─────┐ ││ │┌─────┐│ │ └─────┘
│ 住 所 │←┼┼─┼┤会員番号 ││ │ ┌─────┐
└─────┘ ││ │└─────┘├─┼──→│ 修了日 │
┌─────┐ ││ │ │ │ └─────┘
│ 年 収 │←┘│ │ │ │ ┌──────────┐
└─────┘ │ │ │ │ │┌────────┐│ ┌─────┐
│ │ ├─┼─┼┼→┌────┐ ├┼→│ 指導者 │
│ │ │←┼─┼┼─┤受験番号│ ││ └─────┘
│ └───────┘ │ ││ └────┘ ││ ┌─────┐
│ ┌─────┐ ├→││ ┌────┐ │├→│ 講 評 │
│ │ 提出日 │ │←┤│ │課題番号│ ││ └─────┘
│ └─────┘ │ ││ └────┘ ││ ┌─────┐
└───────────┘ │└────────┘├→│ 点 数 │
│ │ └─────┘
│ ┌────┐ │ ┌─────┐
│ │課題答案│ ├→│ 返却日 │
│ └────┘ │ └─────┘
└──────────┘
図1 関係”通信講座”の関数従属性
┌─┬──────────────────────────────────────┐
│１│通信講座（会員番号，氏名，住所，性別，講座名，受講番号，学費支払日，開始日 │
│ │ 修了日，提出日，課題答案，課題番号，指導者，講評，点数，返却日） │
├─┼──────────────────────────────────────┤
│ │受講生 （会員番号，氏名，住所，性別） │
│２│受講 （講座名，会員番号，受講番号，学費支払日，開始日，修了日） │
│ │課題添削（受講番号，提出日，課題答案，課題番号，指導者，講評，点数，返却日）│
└─┴──────────────────────────────────────┘
図2 関係スキーマ
┌──┬─────────┬───────────┬───────────┐
│ │ │┌────┐ │┌────┐ │
│ │ ││┌──┐│ ││┌──┐│ │
│ │ │││ Ａ ││ ┌──┐│││ Ａ ││ ┌──┐│
│ │┌──┐ ┌──┐││└──┘├→│ Ｃ │││└──┘│←┤ Ｃ ││
│凡例││ Ａ │→│ Ｂ │││┌──┐│ └──┘││┌──┐│ └──┘│
│ │└──┘ └──┘│││ Ｂ ││ │││ Ｂ ││ │
│ │ ││└──┘│ ││└──┘│ │
│ │ │└────┘ │└────┘ │
├──┼─────────┼───────────┼───────────┤
│ │ │ │ Ｃ→｛Ａ,Ｂ｝ │
│ │ Ａ → Ｂ │ ｛Ａ,Ｂ｝→Ｃ │ Ｃ→ Ａ │
│ │ │ │ Ｃ→ Ｂ │
└──┴─────────┴───────────┴───────────┘
図3 関数従属性の記法
設問1
関係スキーマ１について，次の間いに答えよ。
（１）関係“通信講座”の候補キーをすべて答えよ。
（２）非キー属性が，候補キーに完全関数従属していない例を具体的に一つ挙げよ。
（３）関係“通信講座”のヰにある推移的関数従属の例を具体的に一つ挙げよ。
設問2
関係スキーマ２について，次の間いに答えよ。
（１）関係“受講”，“課題添削”はそれぞれ何正規形か，最も適切な正規形名を答えよ。また，関係“受講”について，その根拠を具体的に80字以内で述べよ。
（２）関係“課題添削”で問題となるタプル挿入時の不都合を具体的に60字以内で述べよ。
（３）その不都合を解消するために，関係“課題添削”を適切な関係に分割した結果を示せ。
|
| 解答 |
|
|
|
|
データベースセキュリティに関する次の記述を読んで，設問1〜3に答えよ。
Ｙ社は，サービス業を営む大企業である。Ｙ社では，企業の収益や発展に貢献するための活動を”施策”と定義し，施策別に予算と実績の管理を行なうことにした。この新しい業績管理手法の導入に当たり，施策別の予算と支払実績を管理する”業績情報管理システム”を構築することになった。”業績情報管理システム”は，予算と実績にかかわるデータベースをエンドユーザが参照したり，データをダウンロードしたりすることができるシステムである。
なお，データの更新は，他システムからバッチ処理によって行なう。
”業績情報管理システム”では，エンドユーザがデータにアクセスできるようにするために，関係データベース管理システム(RDBMS)と組み合わせて，データアクセスツールを採用することにした。
〔業績情報管理システムのテーブル〕
業績情報管理システムのテーブル構造を図1に示す(外部キーの表示はしていない)。
施策
┌───┬────┬─────┬─────┬──────┬──┐
│施策ID│施策名称│費用見積額│期待効果額│主幹部コード│内容│
│￣￣￣│ │ │ │ │ │
└───┴────┴─────┴─────┴──────┴──┘
施策グループ
┌───┬──────┐
│施策ID│参画部コード│
│￣￣￣│￣￣￣￣￣￣│
└───┴──────┘
年度予算
┌──┬────┬───┬─────┬───┐
│年度│課コード│施策ID│支払年月日│予算額│
│￣￣│￣￣￣￣│￣￣￣│￣￣￣￣￣│ │
└──┴────┴───┴─────┴───┘
支払実績
┌─────┬────┬───┬────┬──┐
│支払年月日│課コード│施策ID│支払金額│摘要│
│￣￣￣￣￣│￣￣￣￣│￣￣￣│ │ │
└─────┴────┴───┴────┴──┘
社員
┌───┬─┬─┬──────┬──┬────┬─────┬────┬────┐
│社員ID│姓│名│所属課コード│職位│生年月日│入社年月日│電話番号│ユーザID│
│￣￣￣│ │ │ │ │ │ │ │ │
└───┴─┴─┴──────┴──┴────┴─────┴────┴────┘
部
┌────┬───┐
│部コード│部名称│
│￣￣￣￣│ │
└────┴───┘
課
┌────┬───┬──────┐
│課コード│課名称│所属課コード│
│￣￣￣￣│ │ │
└────┴───┴──────┘
図1 業績情報管理システムのテーブル構造
〔業績情報管理システムのシステム基盤〕
(1) RDBMSのアクセス制御
Ｙ社が採用したRDBMSは，”役割”という構成要素を有する。”役割”は，同一のアクセス権限を有する”ユーザ”のグループである。このRDBMSでは，テーブルやVIEWに対するアクセス権限を”ユーザ”と”役割”に対して付与することができる（図2の【1】,【2】）また，”ユーザ”に対して”役割”を与えることができる。（図2の【3】）
┌──────────────────────────────────┐
│ ┌───────┐ │
│ ┌──────→│テーブル／VIEW│←──────┐ │
│ │ └───────┘ │ │
│ 【2】│ ↑【4】 │【1】 │
│ │ ↓ │ │
│ │ ┌───────┐ │ │
│ │ ┌────→│ビジネスビュー│←────┐ │ │
│ │ │ └───────┘ │ │ │
│ │ │【6】 【5】│ │ │
│ ↓ ↓ ↓ ↓ │
│ ┌─────┐ ┌─────┐ │
│ │ 役 割 │←─────────────→│ ユーザ │ │
│ └─────┘ 【3】 └─────┘ │
└──────────────────────────────────┘
図2 アクセス権限有無の関係イメージ
(2) データアクセスツール
Ｙ社が採用したデータアクセスツールは，エンドユーザがSQLを記述することなくテーブルやVIEWを参照できるようにするツールである。データアクセスツールが表示するテーブルやVIEW及びその列のリストから参照したいものを選択したり，ダウンロードしたりすることができる。また，各列に対する抽出条件を定義することもできる。
データアクセスツールには，RDBMSのテーブルやVIEWに対する検索を”ビジネスビュー”として定義し利用するための機能がある。(図2の【4】)。”ビジネスビュー”の定義はSELECT文を用いて検索条件を記述する形式のもので，SELECT文ではRDBMSのユーザID(”ユーザを一意に識別するID”)などいくつかホスト変数を利用することができる。定義したSQLはRDBMSのテーブルやVIEWのように参照することができる。また，”ユーザ”や”役割”が”ビジネスビュー”にアクセスする権限を付与したり，削除したりすることができる。(図2の【5】，【6】)。
データアクセスツールを利用するには，ユーザIDを入力してログインする必要がある。データアクセスツールのユーザIDは，RDBMSのユーザIDとして用いられる。
Ｙ社では，社員ごとに固有のユーザIDを与えることにした。
〔データアクセス制御要件〕
ユーザに対してデータアクセスツールを会して自由なアクセスを許可するにあたり，データに対するアクセス制御を入念に設計する必要が生じた。Ｙ社のシステム部は，ユーザのデータアクセス制御要件を調査した。調査したアクセス制御要件のうち，データ参照の制御要件は，表のとおりである。
表 データ参照の制御要件
┌──────┬─┬─┬─┬─┬─┐
│ ＼テーブル│施│年│支│社│ │
│ユー＼ │策│度│払│員│…│
│ザの ＼ │ │予│実│ │ │
│所属部門＼ │ │算│績│ │ │
├──────┼─┼─┼─┼─┼─┤
│経営企画部 │○│○│○│×│ │
├──────┼─┼─┼─┼─┼─┤
│経理部 │△│○│○│×│ │
├──────┼─┼─┼─┼─┼─┤
│総務部 │△│△│○│×│ │
├──────┼─┼─┼─┼─┼─┤
│人事部 │△│△│△│○│ │
├──────┼─┼─┼─┼─┼─┤
│その他の部 │△│△│△│×│ │
└──────┴─┴─┴─┴─┴─┘
説明：○：テーブルのすべてのデータに対する参照権限をもたせる。
△：テーブルの一部の列や行だけ参照権限をもたせる。
×：テーブルに対する参照権限がない。
表の”△”で示したテーブルの一部の列や行の対する参照には，次のような要件がある。
(1) 経営企画部，経理以外の部に所属するユーザは，”年度予算”テーブルの自分が所属する部の予算だけを
参照することができる。
(2) 施策テーブルの”施策ID”，”施策名称”，”内容”，”主幹部コード”は誰でも参照できる。
”費用見積額”や”効果期待額”は，施策に参画している部に所属しているユーザだけが参照できる。
設問1
Ｙ社の業績情報管理システムのユーザ管理について，次の問いに答えよ。
（１）Ｙ社におけるユーザIDの付与方法に関して，運営上非効率である点を，具体的に50字以内で述べよ。
（２）Ｙ社のデータアクセス制御要件を検討した結果，アクセス権限の管理を効率的に行なうために，RDBMSの"役割"を利用することにした。Y者のデータアクセス制御要件から"役割"をどのように利用するのが適切と考えられるか。"役割"の定義と，"役割"へのアクセス権限の付与について70字以内で述べよ。
設問2
表のデータ参照制御要件によると，"社員"テーブルの参照権限は人事部に所属するユーザだけに与えられる。一方で，データアクセス制御要件�，鯔�たすためには"社員"テーブルの必要最小限の情報を公開する"ユーザ管理"VIEWを作成することにした。次の問いに答えよ。
（１）"ユーザ管理"VIEWには，"社員"テーブルのどのカラムを含める必要があるか答えよ。
（２）"ユーザ管理"VIEWに対する権限を付与する次のSQL文中の【a】に入れる適切な字句を答えよ
GRANT 【 a 】
設問3
データアクセス制御要件�△鮗存修垢襪燭瓩法�"ビジネスビュー"を作成することにした。施策の"費用見積額"や"期待効果額"を参照する"ビジネスビュー"を定義する次のSQL文中の【b】，【c】に入れる適切な字句を答えよ。ここで，":user"は，ログイン時のユーザIDが格納されるホスト変数である。
SELECT * FROM 施策
【 b 】
WHERE :USER = 社員.ユーザID
AND 社員.所属課コード = 課.課コード
AND 課.所属部コード = 施策グループ.参画部コード
AND 【 c 】）
|
| 解答 |
|
|
|
|
リポジトリシステムに関する次の記述を読んで，設問1〜3に答えよ。
Ａ社の情報システム部では，アプリケーション開発のプロジェクトにおいて，データ中心アプローチの考え方に基づいたデータベース設計を実施している。データベース設計の手順は次のとおりである。
〔データベース設計の手順〕
(1) 業務マニュアル，業務フロー，ユーザへのヒアリング結果に基にして，業務の骨格をあらわす概念データモデルをトップダウン的に作成する。
(2) 入出力（画面や帳票）を素材にしてデータ項目を洗い出し，正規化を行なって，(1)で作成したモデル情報を付加し，詳細な概念データモデルをボトムアップ的に作成する。
(3) 原則として，概念データモデルをそのまま物理データベースの構造として定義する。ただし，必要に応じて関係データベース管理システム(RDBMS)の特性や処理要求を加味して，冗長データ項目の付加，項目の繰り返しなどの非正規化や，制御用データ項目の追加を行なう。
Ａ社での現状では，手順(1)，(2)で作成された概念データモデルは，図として残されるだけである。手順(3)では，図として記述された概念データモデルの情報を，再度テーブル情報としてRDBMSや開発ツールに大して入力しなければならない。Ａ社では，メインフレームやクライアントサーバなど，さまざま環境にデータベースが構築されており，環境ごとにこうした情報を入力するのが煩雑な作業となっている。
そこで，Ａ社のデータ管理者であるＢ君は，概念データモデルの情報を格納し，物理データベース設計工程にその情報を受け渡すための，リポジトリシステムを構築することにした。
Ｂ君は，図1の3階層からなるリポジトリシステムを考案した。1階層目は，概念データモデルの情報を格納するリポジトリである。3階層目は，物理データベースの情報を格納するリポジトリである。からに，両者を橋渡しするための2階層目のリポジトリが必要であると考えた。そして便宜上，1階層目を”概念リポジトリ”，2階層目を”ブリッジリポジトリ”，3階層目を”物理リポジトリ”と呼ぶことにした。
図2は，3階層のリポジトリシステム内の値のイメージを，エンティティタイプとテーブルの関係について例示したものである。
Ｂ君は，”物理リポジトリ”については，実装環境ごとの存在するRDBMSのディレクトリや，開発環境に内蔵されたリポジトリをそのまま利用することとし，”概念リポジトリ”と”ブリッジリポジトリ”を新しく構築することにした。
まず，Ｂ君が着手したのは，”概念リポジトリ”の設計である。
┌────────┐
┌────────┐ ┌─────────┐ ┌┴───────┐│
│概念データモデル│←→│概念と物理の橋渡し│←→┌┴───────┐││
│のリポジトリ │ │のリポジトリ │ │物理データベース│├┘
└────────┘ └─────────┘ │のリポジトリ ├┘
概念リポジトリ ブリッジリポジトリ └────────┘
物理リポジトリ
図1 Ｂ君が考案した3階層のリポジトリシステム
┌──────┐
│┌────┐│
││テーブル││
│├────┤│
││SHAIN ││
┌────────┐ ┌───────────────────┐ ││SHOHIN ││
│┌──────┐│ │┌──────┬─────┬────┐│ ││： ││
││エンティティ││ ││エンティティ│ 物 理 │テーブル││←→││ ││
││タイプ ││ ││タイプ │リポジトリ│ ││ │└────┘│
│├──────┤│ │├──────┼─────┼────┤│ └──────┘
││社員 ││←→ ││社員 │Ａ │SHAIN ││ 物理リポジトリA
││商品 ││ ││社員 │Ｂ │TBL01 ││ ┌──────┐
││： ││ ││商品 │Ａ │SHOHIN ││←→│┌────┐│
││ ││ ││商品 │Ｂ │TBL02 ││ ││テーブル││
│└──────┘│ ││： │： │： ││ ││タイプ ││
└────────┘ ││ │ │ ││ │├────┤│
概念リポジトリ │└──────┴─────┴────┘│ ││TBL01 ││
└───────────────────┘ ││TBL02 ││
ブリッジリポジトリ ││： ││
││ ││
│└────┘│
└──────┘
物理リポジトリB
図2 リポジトリシステム内の値のイメージ
┌──────┐ ┌──────┐
│エンティティ│ 1 対 1 │エンティティ│
│ タイプ名 ├──────┤ タイプ名 │
└──────┘ └──────┘
┌──────┐ ┌──────┐
│エンティティ│ 1 対 多 │エンティティ│
│ タイプ名 ├─────→│ タイプ名 │
└──────┘ └──────┘
┌──────┐ ┌──────┐
│エンティティ│ 多 対 多 │エンティティ│
│ タイプ名 │←────→│ タイプ名 │
└──────┘ └──────┘
図3 エンティティタイプとリレーションシップの表記ルール
┌─────┐
│ スーパー│
│ タイプ │
└──┬──┘
＿＿＿／＼＿＿＿
│ ￣￣ │
┌───┴──┐ ┌──┴───┐
│サブタイプ名│ │サブタイプ名│
└──────┘ └──────┘
図4 スーパータイプとサブタイプの表記ルール
┌──────────────┐
│ エンティティタイプ名 │
├──────────────┤
│ 属性名１，属性名２， … │
│ ──── ‥…‥… │
│ …，属性名ｎ │
│ │
└──────────────┘
図5 エンティティタイプの属性の表記ルール
┌──┐
↓ │ｄ
┌─────┐ ┌─────┐│
│ ｃ │←──┤ ａ ├┘
└─────┘ └─┬─┬─┘
↓ ↓ｅ
┌─────┐
│ ｂ │
└─────┘
図6 Ｂ君が作成したメタデータモデル
〔”概念リポジトリ”の機能設計〕
次に，Ｂ君は”概念リポジトリ”の機能設計に着手した。Ｂ君は，属性に関する情報がもれなくかつ正確に定義されていることが，”概念リポジトリ”だけでなく，”物理リポジトリ”を含むリポジトリシステム全体の情報の有用性を高めるかぎになると考え，それをサポートする機能を盛り込むことにした。
本来，概念データモデル上では，RDBMSに実装する属性のシンボル名(SQL名)や，データ型，数値の桁数などは管理対象外である。しかしこうした情報は，実装環境が異なっても共通に使用する可能性が高いものであるから，”物理リポジトリ”に対して入力するよりも，”概念リポジトリ”に入力し，”物理リポジトリ”の受け渡すほうが得策とＢ君は考えた。
その上で，Ｂ君が洗い出した属性定義上の課題は次の3点である。
(1)図6のメタデータモデルでは，【 f 】とそれを参照する【 g 】が異なる属性として認識され，異なる名称が与えられることになる。概念データモデル上の日本語名称では，【 f 】と【 g 】に異なる名称が与えられても何ら問題が生じないが，後々RDBMSに実装することを想定すると，【 f 】と【 g 】のシンボル名は同じであるほうが，アプリケーションから見たテーブルの操作や，保守局面での影響度分析上，好ましい。
(2)Ａ社では，属性のシンボル名の命名を，データ管理者が行なうのではなく，各開発担当者が行なっている。この体勢は今後も変更する予定はない。しかし，開発担当者が個人個人のセンスに依存した命名を行なっていると，同音異義語や異音同義語の発生を防ぐことは難しい。
(3)属性に関する定義情報は，名称だけではない。データ型や，数値の桁数や単位などを標準化した上で管理しなければならない。
Ｂ君はこれら課題の解決策を盛り込んだ”概念リポジトリ”の機能設計を実施した。
設問1
次の問いに答えよ。
（１）図6のエンティティタイプa〜cのエンティティタイプ命を答えよ。
（２）図6のリレーションシップbのもつ役割を30字以内で答えよ。
（３）図6のeの二つのリレーションシップの持つ役割を40字以内で答えよ。
設問2
次の問いに答えよ
（１）本文中の【 f 】，【 g 】に入る適切な用語を答えよ。
（２）Ｂ君の考えた属性定義上の課題(2)の同音異義語や異音同義語の発生を減らすために，"概念リポジトリ”が備えるべき機能を30字以内で述べよ。
（３）B君が考えた属性定義上の課題(3)の標準化を行なうために，"概念リポジトリ"の構造である図6のメタデータモデル上に追加すべきエンティティタイプがある。そのエンティティタイプ名を答えよ。
設問3
Ｂ君が考案した"ブリッジリポジトリ"が持つべき役割を二つ，それぞれ40字以内で述べよ。
|
| 解答 |
|
|
|