HOME»応用情報技術者試験掲示板»令和2年秋期試験 午後問6【データベース】

応用情報技術者試験掲示板

掲示板検索:

[2297]令和2年秋期試験 午後問6【データベース】

ミルキー@管理人(No.1)

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

2020.10.18 00:06
Nayutaさん(No.2)

最後のSQLについて。
同一日、同一部屋の予約が3件以上あった場合、SQLはエラーになると思うのですが、そのようなケースは無視しているのでしょうか。

2020.10.18 15:40
疲れたさん(No.3)

予約IDが最初の予約より大きいやつって条件なので、3件以上でも問題ないと思いました

2020.10.18 15:43
もえさん(No.4)

試験お疲れ様ですー!

皆様どのようにご回答しましたかー?

2020.10.18 15:45
雑魚さん(No.5)

相関副問い合わせを使うものと思われます。つまり、一行ずつ評価されるためエラーにはなりません。

2020.10.18 15:58
Nayutaさん(No.6)

> 相関副問い合わせを使うものと思われます。つまり、一行ずつ評価されるためエラーにはなりません。
その仕様が分かっていませんでした。
教えてくださりありがとうございます!

2020.10.18 16:01
雑魚さん(No.7)

どういたしまして。まあ私は選択忘れで落ちるの濃厚ですが。。。(やらかし)

2020.10.18 16:02
郷ひろみの誕生日さん(No.8)

1 a. ─ b.施設ID(外部キー)
2 c. 部屋.部屋ID NOT EXISTS
   d.HAVING COUNT(*)
3 (1) e.部屋ID
         f.宿泊日
    (2) g.一意性制約
    (3) h. t2.予約ID
          i.  t1.部屋ID = t2.部屋ID
          j.  t1.宿泊日 = t2.宿泊日

にしました。システム開発が難しくて代替で取ったので自信がないです…

2020.10.18 16:16
klさん(No.9)

1 a. → b.施設ID(外部キー)
2 c. NOT EXISTS
   d.HAVING COUNT(*)
3 (1) e.部屋ID
         f.宿泊日
    (2) g.一意制約
    (3) h. t2.予約ID
          i.  t1.部屋ID = t2.部屋ID
          j.  t1.宿泊日 = t2.宿泊日

こうしました。

2020.10.18 16:23
郷ひろみの誕生日さん(No.10)

予約の時 部屋数が複数になることもあるのでaは確かに一対多ですね、、、

2020.10.18 16:30
はせさん(No.11)

1.→,施設id…(外部キー)
2.not exists,having count(*)
3.予約id,部屋id(ここ多分間違い),一意制約
  t2.予約id
    t1.宿泊日 = t2.宿泊日
    t1.部屋id = t2.部屋id

一意制約は、一意性制約じゃなくても良いでしょうか?

2020.10.18 16:30
新人さん(No.12)

hは  MIN(t2.予約ID)ではないですか?

2020.10.18 16:37
klさん(No.13)

MINいりそう!
t2で最小のやつ出してないの今気づきました!汗

2020.10.18 16:40
さん(No.14)

UNIQUE制約にしましたがこれでもありでしょうか…?

2020.10.18 16:42
ap_02さん(No.15)

ユニーク制約って解答しました、、、

2020.10.18 16:46
ap_02さん(No.16)

あー、MIN書き忘れたー、、、

2020.10.18 16:48
にゃんこさん(No.17)

min必要ありますか?

2020.10.18 16:56
ねぎさん(No.18)

min入れると、t2のすべてのレコードの中で最小の予約IDを、t1.予約IDと比較するからおかしくないです?

2020.10.18 16:58
さん(No.19)

min入れるとgroupbyが必要になるのでは…?(自信ない)

2020.10.18 17:01
klさん(No.20)

minがないと3つ以上同じ宿泊日、部屋IDの予約があったときに
複数の結果を比較演算してしまいませんか?
私は2つのときしか考えていなかったので、minつけませんでしたが汗

2020.10.18 17:08
マルティンスさん(No.21)

この投稿は投稿者により削除されました。(2020.10.18 17:11)

2020.10.18 17:11
ap_02さん(No.22)

たしかに、MINは集計関数ということを考えればGROUP BY必要そうですが、、、
今は何を言われても正解に感じます笑

設1:a→、b施設ID [点線]
設2:c  NOT EXISTS
     d  HAVING COUNT(*)
設3:e  部屋ID
     f  宿泊日
     g  ユニーク制約
     h  t2.予約ID
     i  t1.部屋ID  =  t2.部屋ID
     j  t1.宿泊日  =  t2.宿泊日

2020.10.18 17:10
落ちたさん(No.23)

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

2020.10.18 17:17
ゲストさん(No.24)

設1のaはーじゃないですか?
部屋種別ごとに予約を取ると記述があるので、別部屋予約するときは予約を取り直すのかと思ったのですが、、

2020.10.18 17:17
hhさん(No.25)

min必要ですねこれ。。。groupbyはなくても使えます。。(私はminをつけませんでしたが、、)
リレーションですが、「→」でしょうか。
私は「-」にしました。問題文に予約はへの部屋の種別ごとに行うと書いてあったところからの判断です。(自信ない。。)

2020.10.18 17:20
二回目さん(No.26)

予約の種別ごとなので→だと思います

2020.10.18 17:21
ap_02さん(No.27)

僕は部屋数の関係から→にしました。
仮に、予約IDが001の者が2部屋予約したと仮定し、予約明細表には
「予約明細ID:01
予約ID:001
部屋ID:A001
...」
「予約明細ID:02
予約ID:001
部屋ID:A002
...」
が挿入されるのでは?と思いました。

2020.10.18 17:29
アップルさん(No.28)

設1:a→、b施設ID [点線]
設2:c  EXISTS
     d  HAVING COUNT(*)
設3:e  部屋ID
     f  予約ID
     g  一意制約
     h  distinct 予約ID
     i  t1.部屋ID  =  t2.部屋ID
     j  t1.予約ID =  t2.予約ID

not existsなのか。hも表名付け忘れた。。。

2020.10.18 17:51
ぺりかんさん(No.29)

DBはいつも苦手なので、、今回は埋まった方です汗

1. 
a →
b施設ID(実線をつけた泣)

2.
c EXSITS (NOTでしたか、、)
d HAVING COUNT(※)

3.
(1)部屋ID, 宿泊日
(2)一意制約(こんな言葉あるのかしら)
(3)
h t2.予約ID
i t1.部屋ID = t2. 部屋ID
j t1.宿泊日 = t2.宿泊日

2020.10.18 18:18
ひろさん(No.30)

設問1 a: -> b: 施設ID
設問2 c: (わかりませんでした) d: (わかりませんでした)
設問3 (1) e: 部屋ID f: 宿泊日 (2) g: 一意性制約 (3) h: 予約ID i: t2.部屋ID = t1.部屋ID j: t2.宿泊日 = t1.宿泊日

副問い合わせが読み取れないのは勉強不足ですね...

2020.10.18 18:58
アップルさん(No.31)

そうか、相関副問合せだからdistinct要らないか。
t1.予約id < t2.予約IDが入るのかな。

もう一つはわからないね。

2020.10.18 19:46
アップルさん(No.32)

読み返してみたら、宿泊日が正解っぽいな。残念。
あとNOT EXISTSだね。部分点ください!

2020.10.18 20:57
サイダイさん(No.33)

複合外部キー制約はだめですか?

2020.10.18 21:38
たまゆさん(No.34)

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

2020.10.20 09:18
ぷーさん(No.35)

having countの所大文字ではなく小文字で書いたんですけど、大文字じゃないと不正解になるんでしょうか?

2020.10.18 23:34
落ちそうさん(No.36)

あーEXSITSの最後s抜けててスペルミス
あとHAVINGがどうしても出てこなかった…
いちいちこの辺の細かく覚えてないよ泣

2020.10.19 01:15
呑むしかねぇさん(No.37)

sqlって部分点あったりするのかなー?

2020.10.19 02:16
たかおさん(No.38)

1番最後の
i t1.部屋ID = t2. 部屋ID
j t1.宿泊日 = t2.宿泊日
って、
以下みたいな
i:t2.部屋ID = t1.部屋ID 
j: t2.宿泊日 = t1.宿泊日
でも大丈夫?左右逆に書いてしまったんだが…

2020.10.19 06:39
klさん(No.39)

色々考えてたらminいるのかいらないのかわからなくなってしまいました笑

2020.10.19 09:02
ITAGUさん(No.40)

複合外部キー制約じゃないの?

2020.10.19 11:32
SQLが希望さん(No.41)

問題をハッキリと覚えていませんが…
MINを付けないと>の条件に対して複数行返すことになるため、実際に実行するとエラーになると思われます。

2020.10.19 16:09
丸つけ忘れた可能性さん(No.42)

一意性制約ですが一意性では正解にならないですかね

2020.10.19 17:03
ねずみさん(No.43)

一意性でも良いと思いますよ。
同様にユニーク制約とか一意制約とかも正解だと私は思います。

2020.10.19 17:45
たまゆさん(No.44)

似たSQLを組んで実行したところ、皆さんの言う通り「2行以上が戻されます」のエラーを吐いたのでminは必要ですね。
お騒がせしてすみません。34は間違っているので消しときました。

2020.10.20 09:21
タオルさん(No.45)

みんなが部屋ID, 宿泊日、一意制約のお答えですか。
予約IDと予約明細IDの複合主キーにしてしまいました。違うんですね。

2020.10.20 10:40
@@@さん(No.46)

同じ宿泊日と同じ部屋の予約が重複して入らないようにって言ってるから
宿泊日と部屋IDで決定。
複合キーに対して「追加した制約」だから一意性制約。
複合外部キー、複合主キーという言葉はありますけど
複合外部キー制約、複合主キー制約なんて言葉ググっても出てこないのですが
存在するのでしょうか?

2020.10.20 11:08
あららさん(No.47)

宿泊日と部屋IDを逆で記入したのですが、採点されますか?

2020.10.20 11:25
ろんさん(No.48)

minなしver とminありver  を組んで動かしましたが、両方同じ動きをしました。
minがなかろうが、自動的に一つずつ比較して、最終的にはminと同じ感じに。。

SQLのverと種類によるのかな。。。

2020.10.20 11:29
@@@さん(No.49)

>>ろんさん
verによるかもしれませんね。
>>no.44たまゆさん
が削除してしまった内容では職場のSQLが似たようなもので
min無しでちゃんと動いてたとのことでした。
>>no.44
こちらの確認の際に同じ環境で実行されているのでしたら
わかりませんが、もし違う環境で実行されているとしたら
verによって動作が変わるものかと思われます。

2020.10.20 12:15
@@@さん(No.50)

訂正:verや種類の違いによって変わるものかと思います

2020.10.20 12:21
なんとかさん(No.51)

一意キー制約ではだめでしょうか。

2020.10.20 13:45
ろんさん(No.52)

応用情報ってSQLのバージョン指定とかってありましたっけ?
なかった場合はどちらでも正解?

2020.10.20 13:52
うえうえさん(No.53)

not existで部分点ください、神様

2020.10.20 13:55
@@@さん(No.54)

私が知っている限りでは
昔はSQLの「値  <>  値」を「値  != 値」と書くことはできませんでしたが、現在のバージョンではどちらも有効となっており、応用情報の過去問でどちらでも可になっていた記憶があります。
なので、ver違いで使えるものは恐らくどちらでも正解になると思います
(ただし、昔使えなかったものが今使える場合に限ると思います。逆に言えば、昔使えたのに今使えない場合は不正解になるかもしれません。)

*******************
***あくまでも個人的な意見です***
*******************

2020.10.20 14:04
すんさん(No.55)

一意制約のところを主キー制約と書いてしまいました、、
本問において、主キー制約がおかしい理由を教えていただきたいです‥

2020.10.20 14:48
オイルロッカーさん(No.56)

最後の回答って
i:t2.部屋ID = t1.部屋ID 
j: t2.宿泊日 = t1.宿泊日
でも可ですか?

2020.10.20 17:13
受かってて!さん(No.57)

1. 集計関数COUNT(*)は大文字じゃないとバツですか?
2. MINが必要かどうか、このサイト内での結論は今時点ではどちらでしょうか。

2020.10.20 17:32
ap_02さん(No.58)

TAC、大原ともにMIN付き解答を出しました。
よって、MINは必要だということではないでしょうか?

2020.10.20 17:41
あいさん(No.59)

MINなしでも動いてしまうけど,
正確なのはMINあり..

2020.10.20 17:47
ゲストさん(No.60)

動くのに不正解にされるのは納得いかないですね
(私は確認してませんが)

2020.10.20 17:52
にじくじゃくさん(No.61)

すみません、HAVING COUNT(施設ID) は不正解でしょうか?

2020.10.20 19:36
サイダイさん(No.62)

HAVINGだけ合っていても部分点くれないですよね?
誰か教えて下さい

2020.10.20 21:56
たまゆさん(No.63)

>>49
お恥ずかしいながら、No34で覚えていると言っていたチェックSQLですが、
不等号を使っていたのはテーブル結合の方で、where句はin使ってました。申し訳ないです。

ちなみに私が試した環境はOracle11gです。

2020.10.20 23:27
たまゆさん(No.64)

大前提としてSQLはどれでも大文字小文字の区別はないです。(データを除く)
なので、どちらで書いても正解だと思います。

>>55
調べてみると、プライマリーキーはテーブルにつき1つしか作れないようです。
予約明細テーブルは既に予約明細IDがプライマリーキーとして設計されているので
ユニーク制約までで止まるのではないかなと思います。

2020.10.21 00:06

【返信投稿用フォーム】

お名前(10文字以内)

顔アイコン


本文(2,000文字以内)

記事削除用パスワード(20文字以内)

プレビュー

※宣伝や迷惑行為を防止するため当サイトとIPAサイト以外のURLを含む記事の投稿は禁止されています。

投稿記事削除用フォーム

投稿No. パスワード 
© 2010-2020 応用情報技術者試験ドットコム All Rights Reserved.

Pagetop