応用情報技術者過去問題 平成29年春期 午後問6
⇄問題文と設問を画面2分割で開く⇱問題PDF問6 データベース
稟議申請システムに関する次の記述を読んで,設問1~4に答えよ。
S社では,機器の購入や他社との契約の金額が10万円を超える場合には,承認権をもつ者による承認が必要である。承認を得る際,担当者は決まった書式に従った稟議申請書を作成し,稟議申請をする。
稟議申請には,大きく分けて購買稟議と契約稟議がある。購買稟議の場合は,申請者の所属部署の部長,購買部の担当者,購買部の部長の順で,承認が必要となる。また,契約稟議の場合は,申請者の直属の上司,所属部署の部長の順で,承認が必要となる。稟議申請書の書式は,購買稟議と契約稟議とで異なり,書式の種類は今後増える可能性がある。ただし,申請者自身が承認者になるような稟議申請は行えない。
S社では,これまで紙の帳票で稟議申請を行っていたが,社内業務を効率化するために,稟議申請システムを開発して,Webシステム上で稟議を行うことにした。
〔稟議申請システムの概要〕
稟議申請システムには,ログイン画面,作成画面,一覧画面及び詳細画面の四つの画面がある。
ログイン画面では,利用者がユーザIDとパスワードを入力し,ログインする。
作成画面では,申請者が稟議申請に必要な事項を入力し,申請する。
一覧画面では,現在申請されている稟議申請を一覧の形式で見ることができる。稟議申請の一覧には,自分が申請した稟議申請と,自分が承認者に含まれている稟議申請が表示される。一覧から稟議申請を選択すると詳細画面が表示される。
詳細画面では,稟議申請の内容と現在の承認の状態を確認できる。承認者が詳細画面を参照すると,稟議申請の内容のほかに承認入力欄が表示され,承認又は否認の入力を行うことができる。
〔作成画面〕
稟議申請は,書式ごとに必要な入力項目が一部異なる。申請者は,あらかじめ書式を選択してから内容を入力する。作成画面のレイアウトを図1に示す。
申請者は,稟議申請の内容を入力した後,申請を行う。承認の申請先は定義に従ってシステムが自動で設定するので,申請者が指定する必要はない。 稟議申請の入力項目は申請書項目と呼ばれ,書式ごとに項目を一意に識別する項目キーと,項目値の組合せで管理される。項目の定義を表1に示す。〔詳細画面〕
詳細画面では,図1の内容が編集不可の状態で表示される。また,現在ログイン中の利用者に承認順が回ってきている稟議申請の場合は,画面に承認コメントの入力欄と,承認・否認のボタンが表示される。
承認者は,稟議申請の内容を確認し検討した上で,必要に応じてコメントを入力し,承認又は否認のボタンを押す。稟議申請は,承認者全員が承認すると可決となり,承認者のうち1人が否認した時点で否決となる。稟議申請が否決された場合,申請者は内容を修正して再度申請するか,申請を取りやめるかを判断する。
〔データベースの設計)
稟議申請システムのデータベースの設計を行った。設計したデータベースのE-R図を図2に,エンティティの概要を表2に示す。 例えば図1の購買稟議申請の金額欄の場合,申請書項目マスタには,項目キーが'amount',項目名が'金額',項目値の型が'整数'のタプルが,申請書項目には,項目キーが'amount',項目値が'2500000'のタプルが登録される。
このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして,適切なデータ型で表定義した関係データベースによって,データを管理する。
〔一覧画面〕
稟議申請の一覧画面には,申請書ID,タイトル,申請日,申請者のユーザ名及び所属部署名を表示する。画面に表示する情報を検索するSQL文を図3に示す。ログイン中の利用者のユーザIDは,埋込み変数":ユーザID"に設定されている。 また,経理部からの要望で,可決された稟議申請について,金額と支払日の一覧を出力できる機能を追加することになった。ただし,契約稟議については初回支払額だけ出力されればよい。金額と支払日の一覧を検索するSQL文を図4に示す。購買稟議申請の書式IDは'購買',契約稟議申請の書式IDは'契約'である。〔組織の改廃〕
運用開始後,利用者の部署異動や部署名の変更が行われることが想定されるが,システムの画面上で過去の稟議申請を参照した際には,申請時の情報が表示される必要がある。しかし,図2の設計では①この要件を満たせない部分があるので,あるエンティティに属性を追加すると同時に図3のSQL文も修正することにした。
S社では,機器の購入や他社との契約の金額が10万円を超える場合には,承認権をもつ者による承認が必要である。承認を得る際,担当者は決まった書式に従った稟議申請書を作成し,稟議申請をする。
稟議申請には,大きく分けて購買稟議と契約稟議がある。購買稟議の場合は,申請者の所属部署の部長,購買部の担当者,購買部の部長の順で,承認が必要となる。また,契約稟議の場合は,申請者の直属の上司,所属部署の部長の順で,承認が必要となる。稟議申請書の書式は,購買稟議と契約稟議とで異なり,書式の種類は今後増える可能性がある。ただし,申請者自身が承認者になるような稟議申請は行えない。
S社では,これまで紙の帳票で稟議申請を行っていたが,社内業務を効率化するために,稟議申請システムを開発して,Webシステム上で稟議を行うことにした。
〔稟議申請システムの概要〕
稟議申請システムには,ログイン画面,作成画面,一覧画面及び詳細画面の四つの画面がある。
ログイン画面では,利用者がユーザIDとパスワードを入力し,ログインする。
作成画面では,申請者が稟議申請に必要な事項を入力し,申請する。
一覧画面では,現在申請されている稟議申請を一覧の形式で見ることができる。稟議申請の一覧には,自分が申請した稟議申請と,自分が承認者に含まれている稟議申請が表示される。一覧から稟議申請を選択すると詳細画面が表示される。
詳細画面では,稟議申請の内容と現在の承認の状態を確認できる。承認者が詳細画面を参照すると,稟議申請の内容のほかに承認入力欄が表示され,承認又は否認の入力を行うことができる。
〔作成画面〕
稟議申請は,書式ごとに必要な入力項目が一部異なる。申請者は,あらかじめ書式を選択してから内容を入力する。作成画面のレイアウトを図1に示す。
申請者は,稟議申請の内容を入力した後,申請を行う。承認の申請先は定義に従ってシステムが自動で設定するので,申請者が指定する必要はない。 稟議申請の入力項目は申請書項目と呼ばれ,書式ごとに項目を一意に識別する項目キーと,項目値の組合せで管理される。項目の定義を表1に示す。〔詳細画面〕
詳細画面では,図1の内容が編集不可の状態で表示される。また,現在ログイン中の利用者に承認順が回ってきている稟議申請の場合は,画面に承認コメントの入力欄と,承認・否認のボタンが表示される。
承認者は,稟議申請の内容を確認し検討した上で,必要に応じてコメントを入力し,承認又は否認のボタンを押す。稟議申請は,承認者全員が承認すると可決となり,承認者のうち1人が否認した時点で否決となる。稟議申請が否決された場合,申請者は内容を修正して再度申請するか,申請を取りやめるかを判断する。
〔データベースの設計)
稟議申請システムのデータベースの設計を行った。設計したデータベースのE-R図を図2に,エンティティの概要を表2に示す。 例えば図1の購買稟議申請の金額欄の場合,申請書項目マスタには,項目キーが'amount',項目名が'金額',項目値の型が'整数'のタプルが,申請書項目には,項目キーが'amount',項目値が'2500000'のタプルが登録される。
このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして,適切なデータ型で表定義した関係データベースによって,データを管理する。
〔一覧画面〕
稟議申請の一覧画面には,申請書ID,タイトル,申請日,申請者のユーザ名及び所属部署名を表示する。画面に表示する情報を検索するSQL文を図3に示す。ログイン中の利用者のユーザIDは,埋込み変数":ユーザID"に設定されている。 また,経理部からの要望で,可決された稟議申請について,金額と支払日の一覧を出力できる機能を追加することになった。ただし,契約稟議については初回支払額だけ出力されればよい。金額と支払日の一覧を検索するSQL文を図4に示す。購買稟議申請の書式IDは'購買',契約稟議申請の書式IDは'契約'である。〔組織の改廃〕
運用開始後,利用者の部署異動や部署名の変更が行われることが想定されるが,システムの画面上で過去の稟議申請を参照した際には,申請時の情報が表示される必要がある。しかし,図2の設計では①この要件を満たせない部分があるので,あるエンティティに属性を追加すると同時に図3のSQL文も修正することにした。
設問1
図2のE-R図中のa,bに入れる適切なエンティティ間の関連及び属性名を答え,E-R図を完成させよ。ここで,エンティティ間の関連及び属性名の表記は図2の凡例に倣うこと。
(※正誤判定の都合上、主キー属性は{属性名}、外部キー属性は(属性名)と入力してください)
(※正誤判定の都合上、主キー属性は{属性名}、外部キー属性は(属性名)と入力してください)
解答入力欄
- a:
- b:
解答例・解答の要点
- a:→
- b:書式ID
解説
〔aについて〕
承認申請エンティティと承認者情報エンティティには共通の属性"承認申請ID"があります。この属性"承認申請ID"は、承認申請側では主キーであり、承認申請を一意に特定します。また、承認者情報エンティティ側では外部キーであり、承認申請の主キーを参照します。
表2では承認者情報エンティティの説明として「稟議申請の承認者を管理する」としており、加えて本文中には「購買稟議の場合は,申請者の所属部署の部長,購買部の担当者,購買部の部長の順で,承認が必要となる」とあるので、1つの承認申請に対して複数の承認者がつくことがわかります。したがって、承認申請エンティティと承認者情報エンティティのカーディナリティは1対多であり、[a]には"1"側から"多"側に向けた矢印である「→」が当てはまります。
原則として、ある主キーをもつエンティティと、その主キーを外部キーに持つエンティティのカーディナリティ(多重度)は、主キー側を"1"、外部キー側を"多"として「1対多」になります。
∴a=→
〔bについて〕
書式マスタエンティティと申請書エンティティのカーディナリティは1対多であるにもかかわらず、申請書エンティティ側には書式マスタエンティティの主キーである"書式ID"に相当する属性がありません。よって、"書式ID"という属性を追加すればよいと考えられます。この場合、申請書エンティティの属性"書式ID"は、書式マスタエンティティの主キーを参照する外部キーです。したがって、[b]には「書式ID」が当てはまります。
また、図4のSQL文で「申請書.書式ID」という属性が使われていることからも書式IDを追加すべきであるとわかります。
∴b=書式ID
承認申請エンティティと承認者情報エンティティには共通の属性"承認申請ID"があります。この属性"承認申請ID"は、承認申請側では主キーであり、承認申請を一意に特定します。また、承認者情報エンティティ側では外部キーであり、承認申請の主キーを参照します。
表2では承認者情報エンティティの説明として「稟議申請の承認者を管理する」としており、加えて本文中には「購買稟議の場合は,申請者の所属部署の部長,購買部の担当者,購買部の部長の順で,承認が必要となる」とあるので、1つの承認申請に対して複数の承認者がつくことがわかります。したがって、承認申請エンティティと承認者情報エンティティのカーディナリティは1対多であり、[a]には"1"側から"多"側に向けた矢印である「→」が当てはまります。
原則として、ある主キーをもつエンティティと、その主キーを外部キーに持つエンティティのカーディナリティ(多重度)は、主キー側を"1"、外部キー側を"多"として「1対多」になります。
∴a=→
〔bについて〕
書式マスタエンティティと申請書エンティティのカーディナリティは1対多であるにもかかわらず、申請書エンティティ側には書式マスタエンティティの主キーである"書式ID"に相当する属性がありません。よって、"書式ID"という属性を追加すればよいと考えられます。この場合、申請書エンティティの属性"書式ID"は、書式マスタエンティティの主キーを参照する外部キーです。したがって、[b]には「書式ID」が当てはまります。
また、図4のSQL文で「申請書.書式ID」という属性が使われていることからも書式IDを追加すべきであるとわかります。
∴b=書式ID
設問2
図3中のc,dに入れる適切な字句又は式を答えよ。
解答入力欄
- c:
- d:
解答例・解答の要点
- c:承認者情報.承認申請ID = 承認申請.承認申請ID
- d:承認者情報.承認者ユーザID = :ユーザID
解説
〔稟議申請システムの概要〕には、「一覧画面では,現在申請されている稟議申請を一覧の形式で見ることができる。稟議申請の一覧には,自分が申請した稟議申請と,自分が承認者に含まれている稟議申請が表示される」とあります。
図3のSQL文のWHERE句では、
〔cについて〕
[c]および[d]を含む副問合せ文では、承認者情報表と別の表を内部結合し、申請書IDをSELECTしています。承認者情報表と関連がある表のうち、申請者IDを含むのは承認申請表です。よって、申請書IDを参照するため、共通属性である承認申請ID列で承認者情報表と承認申請表を結合しなければなりません。したがって、[c]には「承認者情報.承認申請ID = 承認申請.承認申請ID」が当てはまります。
∴c=承認者情報.承認申請ID = 承認申請.承認申請ID
〔dについて〕
WHERE句ではログイン中の利用者が承認者であるという条件を指定します。ログイン中の利用者の利用者のユーザIDは埋め込み変数":ユーザID"に設定されているので、承認者情報表の承認者ユーザID列の値が":ユーザID"であるものを選択すればよいと考えられます。したがって、[d]には「承認者情報.承認者ユーザID = :ユーザID」が当てはまります(承認者情報.は省略可)。
∴d=承認者情報.承認者ユーザID = :ユーザID
図3のSQL文のWHERE句では、
- 承認申請.承認申請状態 NOT IN ('可決', '否決')
- 現在申請されているレコ―ド
- 申請書.申請者ユーザID = :ユーザID
- 自分(ログイン中の利用者)が申請した
〔cについて〕
[c]および[d]を含む副問合せ文では、承認者情報表と別の表を内部結合し、申請書IDをSELECTしています。承認者情報表と関連がある表のうち、申請者IDを含むのは承認申請表です。よって、申請書IDを参照するため、共通属性である承認申請ID列で承認者情報表と承認申請表を結合しなければなりません。したがって、[c]には「承認者情報.承認申請ID = 承認申請.承認申請ID」が当てはまります。
∴c=承認者情報.承認申請ID = 承認申請.承認申請ID
〔dについて〕
WHERE句ではログイン中の利用者が承認者であるという条件を指定します。ログイン中の利用者の利用者のユーザIDは埋め込み変数":ユーザID"に設定されているので、承認者情報表の承認者ユーザID列の値が":ユーザID"であるものを選択すればよいと考えられます。したがって、[d]には「承認者情報.承認者ユーザID = :ユーザID」が当てはまります(承認者情報.は省略可)。
∴d=承認者情報.承認者ユーザID = :ユーザID
設問3
図4中のe~hに入れる適切な字句又は式を答えよ。
解答入力欄
- e:
- f:
- g:
- h:
解答例・解答の要点
- e:t1.項目値
- f:t2.項目値
- g:申請書.申請書ID = t1.申請書ID
- h:申請書.申請書ID = t2.申請書ID
解説
まず結合条件を考えてから、SELECTで抜き出す属性を考えます。
〔g、hについて〕
申請書と申請書項目を内部結合する際の属性を記述します。2つの表は申請書IDで関連付けられているので、申請書ID列で結合するしかありません。[g]の方は申請書項目にt1のエイリアスを指定しているため「申請書.申請書ID = t1.申請書ID」、[f]の方はt2のエイリアスを指定しているため「申請書.申請書ID = t2.申請書ID」が当てはまります。
∴g=申請書.申請書ID = t1.申請書ID
h=申請書.申請書ID = t2.申請書ID
〔e、fについて〕
上記の結合によって作成される中間表を考えます。
t1との結合によって申請書IDと各項目が関連付けられると次のようになります(書式IDが"購買"の例)。さらに、t2との結合によって結合済の表の各行に各項目が関連付けられるので、中間表の行は、"name - name"、"name - amount"、…、"description - description"というように各項目の組が網羅されることとなります。この中間表から以下の2つに該当する行を選択します。
∴e=t1.項目値
f=t2.項目値
〔g、hについて〕
申請書と申請書項目を内部結合する際の属性を記述します。2つの表は申請書IDで関連付けられているので、申請書ID列で結合するしかありません。[g]の方は申請書項目にt1のエイリアスを指定しているため「申請書.申請書ID = t1.申請書ID」、[f]の方はt2のエイリアスを指定しているため「申請書.申請書ID = t2.申請書ID」が当てはまります。
∴g=申請書.申請書ID = t1.申請書ID
h=申請書.申請書ID = t2.申請書ID
〔e、fについて〕
上記の結合によって作成される中間表を考えます。
t1との結合によって申請書IDと各項目が関連付けられると次のようになります(書式IDが"購買"の例)。さらに、t2との結合によって結合済の表の各行に各項目が関連付けられるので、中間表の行は、"name - name"、"name - amount"、…、"description - description"というように各項目の組が網羅されることとなります。この中間表から以下の2つに該当する行を選択します。
- 書式IDが"購買"、t1の項目キーが"amount"、t2の項目キーが"pay_date"
- 書式IDが"契約"、t1の項目キーが"pay_inirial"、t2の項目キーが"start_date"
∴e=t1.項目値
f=t2.項目値
設問4
本文中の下線①について,どのエンティティに何の属性を追加したかを答えよ。
解答入力欄
- エンティティ:
- 属性:
解答例・解答の要点
- エンティティ:申請書
- 属性:申請時部署名
解説
稟議申請を参照する際、申請書エンティティでは、属性"申請書ユーザID"を外部キーとしてユーザエンティティを経由し、部署マスタエンティティの部署名を参照しています。このとき、ユーザエンティティや部署マスタエンティティには参照時点の部署に関する情報が格納されているので、過去の部署情報は参照できず、常に最新の部署名を参照することになります。これにより、部署の異動や部署名の変更があったときに申請時の部署名が表示されない不具合が生じます。この問題の解消には、稟議申請を行ったときに、そのときの申請者の所属部署名を記録できる属性を申請書エンティティに追加する必要があります。部署IDにすると、部署名の変更に対応できないので部署名としなければなりません。
したがって、答えは「申請書」エンティティに属性「申請時部署名」を追加です。
∴エンティティ:申請書
属性:申請時部署名
したがって、答えは「申請書」エンティティに属性「申請時部署名」を追加です。
∴エンティティ:申請書
属性:申請時部署名