令和元年秋期午後問6

解答さん  
(No.1)
https://www.ap-siken.com/kakomon/01_aki/pm06.html
eに     SELECT 従業員.従業員番号,  :レポート年月
設問3(1)に   同じ日の同じ従業員番号でレコードが二つ存在するパターン。

と解答しました。正解になりると思いましでしょうか?
2021.08.15 09:33
GinSanaさん 
AP プラチナマイスター
(No.2)
eはテーブルを修飾しただけなので別に問題なくて、
設問3(1)の場合、要は主キー重複による一意制約違反を聞くわけですけど
同じ日の同じ従業員番号でレコードが二つ存在する
ってなると、レコードってすでにテーブルに入っているもんだよな・・・というより、
どのような睡眠データのパターン
と聞かれているのだから、ふつうは
○○のパターン
って答えますよね。一意制約違反を起こすパターンは
1日に2回以上睡眠を取得するパターン
がたしかにそうだよな、と。
レコードがそういうレコード(従業員番号と測定日が重複するパターン)という書き方をすると、じゃあつまりどういう事象になるんだ?というもう少し抽象化した要求だな、と
この辺りは日頃仕事をやってると上司に言われてきそうな気がしますねえ・・・。

2021.08.15 13:25
解答さん  
(No.3)
eは良かったです

そうなると、少しおしかったことはあるけど、もう少し突っ込んで聞いていて、そうといことで、ちょっと厳しそうということでしょうかね

もうひとつだけ質問していいですか
g:歩数.従業員番号 = 月次レポート.従業員番号      は      歩数.従業員番号 = 従業員番号
にしても大丈夫ですか?
2021.08.15 14:23
GinSanaさん 
AP プラチナマイスター
(No.4)
>g:歩数.従業員番号 = 月次レポート.従業員番号      は      歩数.従業員番号 = 従業員番号
>にしても大丈夫ですか?

これは、実際にやればわかりますが、DB側がどっちの従業員番号なのか区別がつきません。だからエラーが返ってきます。

2021.08.15 15:26
解答さん  
(No.5)
分かりました。レポート年月  、月間総歩数  共に月次レポート.が無かったので聞いてみました。
実際にやれるところに無いので、やれるのって良いなと思いました。
助かりました。ありがとうございました。

2021.08.15 15:45
解答さん  
(No.6)
申し訳ありません。もうひとつだけお聞きしたくなりました。

レポート年月 や  月間総歩数  は他のテーブルに同じ名前の列があっても別にエラーにはならないのでしょうか?
2021.08.15 16:17
GinSanaさん 
AP プラチナマイスター
(No.7)
この投稿は投稿者により削除されました。(2021.08.15 17:27)
2021.08.15 17:27
GinSanaさん 
AP プラチナマイスター
(No.8)
たとえばAというテーブルにX、Y、Zというカラムがいて、
Bというテーブルに
V、W、Xというカラムがいたら、
クエリを発行するときに
select
v, w, x, y
from
A
inner join
B
on
A.x = B.x

とかやったときに、vとwとyは1つしかないからDB側でテーブルが特定できますけど、Xは列名が一緒だからDB側はどっちのを持ってくればいいのかわからないんですよ。

レポート年月 や  月間総歩数は、の話に戻りますが、

そのクエリの中で別々のテーブルに同名なカラムがなければ、だったら修飾しないでもDB側が判別つくんですよ。
問題はあくまでそのクエリの中で呼ばれているカラムとテーブルが一意になるかということだけです。

つまり、仮の話ですが、
レポート年月 や  月間総歩数  
を持っている、あるテーブルを元ネタのテーブルに結合してselectする場合、
列名にテーブル名を修飾せずにレポート年月や月間総歩数を指定したらエラーになります。

2021.08.15 17:27
GinSanaさん 
AP プラチナマイスター
(No.9)
実際の環境がなければ、sqlfiddleというサイトでやってみるとかどうでしょう。
やりかたはsqlfiddle やり方  とかでググればでてきます。
2021.08.15 17:35
解答さん  
(No.10)
そうなのですね。ところで、クエリの中で呼ばれているカラムとテーブルの範囲というのはどういうふうに決まりますか?    FROM句で指定されているテーブルで決まるわけでは無いのですよね?

どう手を付けてよいかもわからなかったのでsqlfiddleの情報もありがとうございます。
2021.08.15 18:17
GinSanaさん 
AP プラチナマイスター
(No.11)
この投稿は投稿者により削除されました。(2021.08.15 18:34)
2021.08.15 18:34
GinSanaさん 
AP プラチナマイスター
(No.12)
select
列名
from
テーブル名
join
テーブル名
on
結合条件
where
条件
とあるように基本はfromで呼んだメインテーブルとjoinで呼んだテーブルすべて関わってくると思ってください。
group byとかorder byとかでもこのあたりはからんできますが。

全部修飾するのが実際問題として後腐れがないんです(ほんとに。自分は実務でも必ず修飾します)。
修飾しなかったらどうするかというと、DBが構文解析をする際にDB側で補完するって作業があります。
そこに余計にDBサーバのCPUリソースを使うから、小手先のテクニックとして修飾するのはある意味当たり前ともいえます。
2021.08.15 18:33
解答さん  
(No.13)
あげて下さった例でXは結合したから、もうそれしかないようにも見えるけど、SELECTで指定するとき、それだけだとエラーになるのですね
でもさすがに、SELECTでA.XのB.Xどっちを指定してもエラーにならず、結果も(結合してるから)同じで出るのですよね?
2021.08.15 18:34
GinSanaさん 
AP プラチナマイスター
(No.14)
>あげて下さった例でXは結合したから、もうそれしかないようにも見えるけど、SELECTで指定するとき、それだけだとエラーになるのですね

No.12でも書きましたが、修飾を書かないとDB側で補完作業があるので、どっちだよ、ってなってエラーになります。

>でもさすがに、SELECTでA.XのB.Xどっちを指定してもエラーにならず、結果も(結合してるから)同じで出るのですよね?
両方登場させるならば、列名がかぶらないことが必要です。どちらか片方しか登場しないならば、A.XとかB.Xだけでもよいです。
だから、ASで別名をつけてやる必要があります。
A.X AS AX,
B.X AS BX
みたいに。
>結果も(結合してるから)同じで出るのですよね?
結合条件によります。
inner joinは内部結合だから振り落としが働きますけど、left joinならなければnull埋めされてでてきますから、結果はちがいますね。

2021.08.15 18:43
解答さん  
(No.15)
そういうことがあるのですね。勉強になります。ありがとうございます。
試験でも修飾はすることにしてしまった方が、しなくても良いか考えるより、良くて安全そうだと思いました。

SELECT句に指定する列などは基本はfromで呼んだメインテーブルとjoinで呼んだテーブルすべて関わってくるなどと考えればよいということですよね?

WHRER句だとまた違ってきますか?
2021.08.15 18:49
GinSanaさん 
AP プラチナマイスター
(No.16)
>SELECT句に指定する列などは基本はfromで呼んだメインテーブルとjoinで呼んだテーブルすべて関わってくるなどと考えればよいということですよね?
その通りです。
>WHERE句だとまた違ってきますか?
一緒です。とにかくDB補完はどこだろうが発生します。
2021.08.15 19:02
解答さん  
(No.17)
あげて下さった

select
v, w, x, y
from
A
inner join
B
on
A.x = B.x

についてだけのつもりでしたが、より詳しい説明ありがとうございます。

両方していすると変になっちゃうんですね
100%理解できて聞けてません(素人です)がいろいろありがとうございます。
2021.08.15 19:05
解答さん  
(No.18)
そうなのですね
WHERE句では、FROM句で指定されていないテーブルの列がたまに登場するので違うかもと思いました。
ありがとうございます。
2021.08.15 19:11
GinSanaさん 
AP プラチナマイスター
(No.19)
>両方していすると変になっちゃうんですね
これは、ASで別名をつけないと、DB側で同じ名前の別名をつけたことにしちゃう(A.X AS X)からです。別名がかぶるとやはりDBは理解できないのでエラーになるのです。
2021.08.15 19:13
解答さん  
(No.20)
そういうことになるのですね。より分かりました。
ありがとうございます。助かります。
2021.08.15 19:21

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの書込みはできません。

その他のスレッド


Pagetop