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

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

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

試験お疲れ様ですー！

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

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

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

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

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.宿泊日

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

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.宿泊日

こうしました。

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

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

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

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

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

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

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

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

min必要ありますか？

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

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

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

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

たしかに、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:17)

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

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

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

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

設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も表名付け忘れた。。。

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.宿泊日

設問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.宿泊日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

→なんとかさん

私も一意キー制約と書いてしまいました。
オラクルマスターの資格の参考書で覚えたのですが、間違いなのでしょうか？

お分かりになる方がいれば、ご教授いただけたらうれしいです。

minがいるかいらないかですが、
MySQL8.0でも試してみました。
ERROR:Subquery returns more than 1 row
と出るのでサブクエリが複数行でてしまうことによるエラーです。
minをつけることで問題なく結果が得られました。
minは必要ですね。
他のverや種類で試してminが必要なかったらそのverと種類教えていただけると幸いです。

i:t2.部屋ID = t1.部屋ID 
j: t2.宿泊日 = t1.宿泊日
でも大丈夫ですか？

>>56 です。
先程MySQLで逆にIDを書いてみたところ、重複レコードの抽出はしてくれました。
SQL初心者なので、これが正解はわかりませんが…
受かってて欲しいです…

Having count(*)のところをなんか勢い余ってhaving by count(*) って書いてしまった…
さすがに部分点くれないだろうな…

2.
c Not in 
d HAVING COUNT(部屋種別ID)
では部分点もらえないでしょうか。

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

>>テスターさん
NOT INは部分点厳しいです。

ですが、HAVING COUNT(部屋種別ID)と
HAVING COUNT(*)は同一の動作をすると思いますので、正解～部分点入ると思います。

itecが最後に解答を出しましたが、空欄hはMINなしですね。
MINなしで解答したので、これが正解ならうれしい…。

3.
(1)部屋ID, 宿泊日
上記に下点線をつけてしまったのですが、だめですかね。。。。