午後問6(データベース)についての投稿を受け付けるスレッドです。

叩き台お願いします。
1.
過去3年より前の駐車場別、車種別の平均車両稼働率の目標比の分析
2.
(1)a…エ
(2)b…年月日(主キー)
    c…貸出実績件数
    d…平均車両稼働率
    e…←
3.
(1)f…INNER JOIN 貸出実績 J ON R.貸出予約コード ＝
    g…GROUP BY R.貸出予定年月日,R.駐車場
ID,R.車種ID,R.会員ID
(2)毎日
4.
年、月、車種ID

3.(1)left outer joinではダメですか？

>たかさん
図1を見ると貸出予約と貸出実績の関係が1対1なので、おそらくINNER JOINだと思います。

なるほど、そういうことなんですね。
勉強になりました。

データベース過疎りすぎ、、、
誰か解答教えてください！

d は年代かな？他に入れるものがなかったからですが。会員に年齢を持たせていないのは、経年の影響を考慮してるのかな、と。

(2)d以外18号さんの答えとほぼ同じでした。
平均車両稼働率は「車両稼働」に存在しているので違うと判断し、他の候補を探しましたが、結局回答がわからず適当に埋めてしまいました…（図４のSELECT句から貸出予定年月日と回答しましたが、これは主キーの年月日に相当するので絶対に違いますね）

スタースキーマにしちゃった、、

全然勉強量足りてないので、ほぼ間違ってるかなーと思いますが、過疎ってるので自分の回答晒します笑

1.遅延返却発生件数についての前日までの実績を翌営業日の朝に確認できること
（返却されて初めて遅延返却と認識されるのだと解釈してこれを書きました?）
2.
?ウ
(僕の持ってたテキストにはスノーフレークスキーマは載ってなかったので僕にとってはスタースキーマ一択でした笑)
2.?
b.年月日（下線実線）
c.貸出予定時刻
(業務要件に貸出予定の日付で集計と書いてたのでこれあるかなーと思っちゃいましたが、年月日があるので不要ですね。。。)
d.貸出実績件数
e.←
3.?
f.時間が足りず空欄
g.時間が足りず空欄
?毎日
?年月

参考になる回答じゃないですが。。。

(1)とか絵文字とかが全部？になっちゃってる。。。見にくくてすみません。
連投すみません。。。

問３(2)は週次では？

遅延返却発生件数は翌日朝に確認ってあるから、たぶん週次じゃない。
毎日

毎朝はだめですかね、、

吾輩も毎朝にした

頻度と聞かれて、「日毎」と答えてしまったんですが、、これでもバツですかね笑…

この投稿は投稿者により削除されました。(2021.04.18 22:45)

ワイは毎日だと何時でも当てはまるからな…と思って毎晩にしてしまった…しかし毎晩というのも曖昧やな…

毎日でも毎朝でも毎晩でも日毎でも意味合ってるから私が採点マンなら正解だけどな。

1
過去のデータが蓄積されてない為、前年同期比の分析が実現できない

2
(1)ア
(2)b:年月日（主キー）
    c:貸出実績コード
    d:返却実績時刻        （※c.dは順不同）
    e:←

3
(1)f:left outer join 貸出 j on y.貸出予約コード＝
    g:group by r.貸出予定年月日、r.駐車場ID、
       r.車種ID、r.会員ID
(2)日1(←アホ解答)

4
年月日、車種ID

データベースだけやけに難しすぎた

今回のFみたいに=で解答が終わるってのは他の年度にありましたっけ？
正解したから別に構わないんですが、ちょっと解答するときに戸惑いました。

私の解答と思考過程です。

設問1. 過去3-5年の平均車両稼働率の目標を利用した分析。

設問2. (1) オ. 第三正規形

●「問い合わせの処理性能を考慮して」とあることから、もっと正規化できるけど第3までに留めておいたよ、あんまり分割しても意味ないしね、という話なのかなと思いました。

(2) b: 年月日 (下線）
c: 貸出実績時間 (多分答えは会員年代）
d: 貸出実績件数
e: <--

●「貸出」の列名として「遅延返却発生件数」があることから、集計した結果現れる列もここに書いて良いんだ、と思いました。そこで、人気車種を決めるのに必要な貸出実績件数(RDBによる実装では、各行について、実績の有無のbooleanが入るイメージ)を加えました。
もう1つは適当に貸出実績時間と書いたのですが、「会員の性別・年代別の人気車種」を調べるのに、「会員」に氏名と性別の情報しかないので、会員年代を入れる必要があることに気づきました。会員から切り離されている理由としては、利用した当時の年代が大事だからかと思われます。

設問3. (1) f: INNER JOIN 貸出実績 J ON R.貸出予約コード =
g: GROUP BY R.貸出予定年月日, R.駐車場ID, R.車種ID, R.会員ID

(2) 日毎

●「遅延返却発生件数については前日までの実績を翌営業日の朝に確認できること」より。毎営業日の営業終了後と書きたかったけど2文字なので

設問4. 年月

●分析の時間が問題視されていることから、データマートは集計済みのデータとして以下の構造になることをイメージしていました。ただ、年月ではなく年と月を分けた方が型的によかったかもしれません。

| 年月(PK) | 人気車種ID | 遅延返却発生件数 |
| -- | -- | -- |
| 2020-01 | 0001 | 21 |
| ... | ... | ... |

設問3. (1) f: INNER JOIN 貸出実績 J ON R.貸出予約コード 
＝つけ忘れたが、部分点くれるかな？

設1理由聞いてると思って「～から」って書いたんですけど部分点あるかな？

この投稿は投稿者により削除されました。(2021.04.19 09:37)

leftjoinにしたのですが、1対1だとinnerjoinではないとバツなのですか。、

私も、INNER JOINとLEFT JOINを迷いました。
迷い過ぎて、答案を提出する時に見たらINNER LEFT JOINって
両方書いてしまったことに気付いてしまいました。
部分点を祈るばかりです。

スキーマ構造を選ぶ問題がよくわかりませんでしたが、スノーフレークスキーマが正解？

スノーフレークスキーマ答えられる人ってこの単語を聞いたことがあるの？それとも消去法？
午後の勉強法わからなさ過ぎて次もこのレベルの知識までたどり着ける自信ないんだけど

この投稿は投稿者により削除されました。(2021.04.19 18:00)

私はスノーフレークスキーマにしましたが勘です。用語も知りません。

問1.  平均車両稼働率の目標データを破棄した4-5年前について目標比が分析できない

問2. 
(1) a スタースキーマ
車両稼働と貸し出しがファクトテーブルで、それらに紐づくディメンションテーブルは雪の結晶の先っぽを持ってないからスタースキーマ
(2)
  b  年月日(主キー)
  c  貸出実績件数
  d  会員年代
  e  ←
問3
(1)
  f LEFT JOIN 貸出実績 AS J ON p.貸出予約コード = 
言われてみればINNER JOINの方が良かった。0件の処理は別途行うので1件以上の遅延があるレコード抽出だからINNER JOINが適切
 g GROUP BY R.年月日,R.車種,R.会員ID,R.駐車場ID

(2)毎日  遅延件数の要件より

問4 年月,車種,駐車場ID,会員ID
分析するときは人別に分析が必須と考える

スタースキーマは午前の過去問に合ったけどスノーフレークは初耳だった。。

１  「過去３年間…」という回答は、
    図2（業務要件）の記載から外れるので、無いような。

    解答は、「過去５年間について…」になると思われます。

余談ですが…スノーフレークスキーマなんて、ほんとに基本からはずれてて、本来、こんな形にしてはいこません。
設計としては、裏技的なものです。

スタースキーマを選択したものですが、スノーフレークスキーマという単語は試験で初耳でした。参考書にも、スタースキーマは説明もありましたが、スノーフレークスキーマは聞いたことがない言葉だったので、最後まで迷いましたが、こちらはやはり選びにくかったですね。

思うに出題趣旨としては、スノーフレークスキーマを知らなかったとしても、スタースキーマの方をしっかり理解していれば、それに合致するDB設計ということで、自信もってこれを選べるだろうという意図だったのではないかと想像します。

最後の設問、年月だけだと思うんだけど、TACの解答は年、月、車種IDになってる。。。
車種IDは外部キーであって、主キーではないですよね？？

SQLって途中点もらえるんですかねえ、、
INNER JOIN 貸出実績 J ON Y.貸出予約コード ＝ にしてしまったなあ、、あほや、、

最後の設問、
TACだと、年、月、車種ID
大原だと、年月、車種ID、会員ID、駐車場IDになっていました。
データ分析を生業にしてますが、
正直な所、年月や年、月だろうが、年月日だろうが分析にかかる時間は一緒だと思うんで、
ここらへんの表記の揺れは部分点もらえると思います
というか設問がわかりづらいのもあり、年月と車種IDが主キーでOKな気もしますが、微妙なところですね

余談ですが、主キーは複数のキーで構成される場合もあり、これを複合キーというので、
年月だけですと、行を一意に特定できないと思われます。

年月だけで行を特定できるような集計表をイメージしました！

問題文にあるよりも汎用的に使おうとしない限り年月だけで十分な気がするんですよね～(^◇^;)

ちなみにKAHさんのNo.22の投稿と全く同じ考えです！

列指向DBでなく行指向DB、の文言ってどういう意味があるのでしょうか。。

ITECの解答速報で問2（2）C  が会員の性別になっている理由わかる方いますか？
会員テーブルに性別があるのに、貸出テーブルでも持つ理由が検討もつきません。

会員の性別・年代で判断するからITECは会員の性別にしたんだと思います。
ですが、性別にするとSQLで貸出実績件数を出力する際に困るので、貸出実績件数が正解だと思います。

ありがとうございます！
貸出実績件数が正解であるのを祈ります。

年月だけが主キーだと、同じ年月で、同じ順位の人気車種、遅延件数があった場合に
行の特定は無理そうだなと思ったんですがどうなんでしょうね。

スノーフレークスキーマになるのは、マスタと結合するマスタを用意したときくらい（DWH（データウェアハウス）のスタースキーマにおいては、ファクトテーブル同士の結合やマスタテーブル同士の結合は発生しない）で、図3を見る限りにおいて結合は見られないので、スタースキーマだ、となるでしょうかね。
かつ、問合せの処理性能を考慮してとくれば、正規化されて外部キー結合が発生しまくったらコストが増えてしょうがないので、スタースキーマだ、となる。
DBスペシャリストでもまずスノーフレークスキーマは訊かれたことないです。
このあたりは  Oracle Databaseデータ・ウェアハウス・ガイド  11gリリース2 (11.2)  B56309-04  20 スキーマのモデリング化技法
などをよんでください。

この投稿は投稿者により削除されました。(2021.04.26 13:57)

No.41
>列指向DBでなく行指向DB、の文言ってどういう意味があるのでしょうか。。

行指向DBは一般的なDB（MySQLとかOracleとか）のことで、名前の通り「ディスクへのデータの書き込みが行ごとの読み書きに最適化されている」
わけですが（逆を言えば、列指向DB（ExadataとかCassandraとか）は列方向に最適化されている）、
これは得意な処理が変わるわけです。

行指向のデータベースは、追加更新削除のようなオンラインのトランザクション処理が得意
列指向データベースは、列を抜き出して操作する集計処理などが得意

毎週月曜に最新のデータにしときたいってことは、それだけ追加更新削除でもたつかれちゃあこまるわけで、
そういう方針で選んだんでしょう、たぶん。

＞GinSanaさん

ご回答ありがとうございます。
ということは行指向列指向の話は問題を解く分にはあまり関係のない話、ということで良さそうですね。
ありがとうございました。