解説

• 表計算ソフトのデータを用いて，平均車両稼働率の目標比や前年同期比を分析できること。
• 過去5年間について，分析対象期間を柔軟に変更して，期間による傾向の違いを分析できること。

解説

• 〔aについて〕
  ビジネス戦略の意思決定などの目的で、データソースからデータ分析用のデータを抽出し整理したデータの集合体を「データウェアハウス」と言います。
  
  データウェアハウスでは多くの場合、データソースから抽出した分析対象の（トランザクション）データを少数のテーブル（ファクトテーブル）に格納します。そして、ファクトテーブルの外部キーから参照する主キーを持つマスタ系テーブル（ディメンションテーブル）に分析軸を格納します。このようにファクトテーブルを中心にして、ディメンションテーブルが周囲に配置されるデータモデルの構造を「スタースキーマ」と言い、関係データベースにおける多次元データベースの実装の一つです。スタースキーマでは、表の結合を少なくして処理を高速化するため、ディメンションテーブルはあえて冗長データをもたせて第2正規化までに留める（階層化しない）ことが一般的です。
  
  図3のデータモデルだと、車両稼働、貸出エンティティがファクトテーブル、カレンダ、車種、会員、駐車場エンティティがディメンションテーブルに相当します。また、ディメンションテーブルが1階層に留まっているためスタースキーマ構造と判断できます。
  
  ∴a＝ウ：スタースキーマ
  
  • 3層スキーマはデータモデルより前のデータベースの構成（概念スキーマ、外部スキーマ、内部スキーマ）を示すものであるため、不適切です。
  • 関係データベースを用いているため、データモデルはオブジェクト指向構造ではありません。
  • 正しい。
  • スノーフレークスキーマは、スタースキーマのディメンションテーブルを正規化（階層化）した構造です。図3のデータモデルではディメンションテーブルが1階層に留まっているので、スノーフレークスキーマではありません。
    
  • 駐車場エンティティに属性"地区"がありますが、図1のデータモデルを見ると、"地区"は駐車場ID→支社IDで一意に決まる属性です。推移的関数従属性が残っているので、第3正規形にはなっていません。
  • 非正規形では関係データベースにテーブル定義ができないため、不適切です。
• 〔bについて〕
  カレンダエンティティと車両稼働エンティティの間には1対多の関係があります。エンティティ同士は同じ主キーと外部キーを持たせることによって関連付けますが、カレンダエンティティの主キー"年月日"に相当する属性が車両稼働エンティティにはないので追加する必要があります。図2には「これらのいずれにおいても，年月，月別，日別，週別，曜日別といった時間軸で傾向を分析できること」が業務要件として示されているため、ある1日の駐車場・車種別の平均車両稼働率がわかる必要があります。
  よって、車両稼働エンティティでは属性"年月日"，"駐車場ID"，"車種ID"によりレコードが一意に特定されることがわかります。したがって、車両稼働エンティティの属性"年月日"は主キーの一部であり、空欄には「年月日」が当てはまります。
  
  ∴b＝年月日
  
  〔cdについて〕
  図2の業務要件には「地区別の人気車種，会員の性別・年代別の人気車種、（中略）駐車場別・会員別の遅延返却発生件数を分析できること。なお，貸出実績の件数（以下，貸出実績件数という）が多い場合を人気車種であるとみなす」とあります。この分析を行うために不足している属性を考えることになります。
  
  "地区"は駐車場エンティティに、"性別"は会員エンティティにあるので問題ありません。しかし"年代"についてはどこにもデータがありません。また会員エンティティには生年月日がないので、貸出当時の会員の年代を年月日との演算で求めることもできません。したがって、まずは「年代」を追加する必要があります。
  
  もう一つの属性は、人気車種を分析するときに必要となる「貸出実績件数」です。とちらも主キー属性ではありません。
  
  ∴cd＝年代、貸出実績件数（順不同）
  
  〔eについて〕
  会員エンティティと貸出エンティティには共通の属性「会員ID」があります。この属性「会員ID」は、会員エンティティ側では主キーであり、会員を一意に特定します。また、貸出エンティティ側では他のキーとともに主キーを構成し、貸出を一意に特定しており、同時に外部キーです。明らかに同一の会員が異なる日に車両を借りることが考えられるので、貸出エンティティには同一の会員IDをもつ複数のレコード存在しえます。したがって、会員エンティティと貸出エンティティのカーディナリティは1対多であり、空欄には「←」が当てはまります。
  
  ∴e＝←
  
  ※一般にエンティティA,B間に関係があることがわかっている場合、エンティティAの主キーの属性がエンティティBでも存在すれば、エンティティBのその属性は外部キーであることが形式的に判断できます。
  ※原則として、ある主キーをもつエンティティと、その主キーを外部キーに持つエンティティのカーディナリティ（多重度）は「1対多」です。

解説

• 〔fについて〕
  空欄の直後の「J.貸出予約コード」やWHERE句の「J.返却実績時刻」の記述から、貸出予約テーブルの取得結果で構成される副問合せR以外に、「J」と別名（相関名）が付けられたテーブルが登場し、副問合せRと結合されることがわかります。「貸出予約コード」や「返却実績時刻」という列をもつテーブルは貸出実績テーブルです。貸出予約テーブルと貸出実績テーブルは"貸出予約コード"列で関係付けられています。したがって、空欄には「INNER JOIN 貸出実績 J ON R.貸出予約コード =」が当てはまります。
  LEFT OUTER JOINと考えた方もいるかもしれませんが、図1を見ると貸出予約エンティティと貸出実績エンティティは1対1の関係です。貸出予約エンティティ対応する貸出実績エンティティは必ず存在するため、外部結合にする理由は何らありません。
  
  ∴f＝INNER JOIN 貸出実績 J ON R.貸出予約コード =
  
  〔gについて〕
  SELECT句に集約関数COUNTがあることから、GROUP BY句が必要であると判断できます。GROUP BY句を記述した場合、SELECT句に記述できる列はGROUP BY句で指定した列（とその列から一意に値を特定できる列）のみです。したがって、空欄にはSELECT句に記述されている（集計関数以外の）列でグループ化する「GROUP BY R.貸出予定年月日, R.駐車場ID, R.車種ID, R.会員ID」が当てはまります。
  
  ∴g＝GROUP BY R.貸出予定年月日，R.駐車場ID，R.車種ID，R.会員ID
  
  
• 図4のSQL文は、遅延返却発生件数を集計するためのものです。図2の業務要件には「遅延返却発生件数については前日までの実績を翌営業日の朝に確認できること」とあり、この業務要件を満たすためには毎日0時から営業開始までの間に図4のSQL文を実行しなくてはなりません。実行する頻度を2文字で答えるとなると「日次」や「毎日」「日毎」などが当てはまります。
  
  ∴日次

解説