HOME»データベーススペシャリスト掲示板»R3 午後1 設問2 (1)-h,i,k(3)-k
投稿する
»[0590] R2午後Ⅱ問2 サブタイプについて 投稿数:3
»[0589] R02 午後2問2設問2 概念モデルと関係スキーマ 投稿数:6
R3 午後1 設問2 (1)-h,i,k(3)-k [0592]
piyoさん(No.1)
R3 午後1 設問2 (1)-h,i,k(3)-kについて、
公式解答では設置済個数の条件がないですが、物件設備.設置済個数の制約の記載がなく0の可能性もあるので、設置済個数 > 0の条件をつける必要があるのではないでしょうか?(例えば2-(1)-hの場合はS1.設備名='エアコン' AND BS1.設置済個数 > 0が正しい)
SQL6,7はテーブル移行の検証なのでまあ公式解答通りでもOKだと思いますが、Viewは今後の運用でも利用されると考えると公式解答のままだとNGな気がします
公式解答では設置済個数の条件がないですが、物件設備.設置済個数の制約の記載がなく0の可能性もあるので、設置済個数 > 0の条件をつける必要があるのではないでしょうか?(例えば2-(1)-hの場合はS1.設備名='エアコン' AND BS1.設置済個数 > 0が正しい)
SQL6,7はテーブル移行の検証なのでまあ公式解答通りでもOKだと思いますが、Viewは今後の運用でも利用されると考えると公式解答のままだとNGな気がします
2023.09.23 18:10
GinSanaさん(No.2)
★DB ゴールドマイスター
この投稿は投稿者により削除されました。(2023.09.23 18:49)
2023.09.23 18:49
GinSanaさん(No.3)
★DB ゴールドマイスター
P23の3.(4)で設置済個数列に1を設定し、正確な個数を移行後に設定する とあるので、移行作業中(SQL6、SQL7を使用する移行作業検証中を含む)は0はありません。
ふつうは設置済個数が0のレコードは新物件の行から削除されるでしょうが、仮に削除されなかったとしたら、入れないと不都合でしょうかね。レコードを消せよ、とたぶん実際の現場なら言うかもしれませんが。なんのための設計なんだと。
kよりはoに、つまり結合段階の条件として書きたいですね。左外部結合によるNULLが発生するとわかっていて純粋に判定を書くのがなんか気持ち悪いので、条件分岐に書くなら書くでコアレスで書くと思います。それを言い出すと、そもそも非ヌル制約ついてないんだから結合条件だって大差ないだろうが、とはなるんですが、左外部結合で発生するNULLよりは問題文的に発生しないだろうな、とか思ったりするんですよね。
ふつうは設置済個数が0のレコードは新物件の行から削除されるでしょうが、仮に削除されなかったとしたら、入れないと不都合でしょうかね。レコードを消せよ、とたぶん実際の現場なら言うかもしれませんが。なんのための設計なんだと。
kよりはoに、つまり結合段階の条件として書きたいですね。左外部結合によるNULLが発生するとわかっていて純粋に判定を書くのがなんか気持ち悪いので、条件分岐に書くなら書くでコアレスで書くと思います。それを言い出すと、そもそも非ヌル制約ついてないんだから結合条件だって大差ないだろうが、とはなるんですが、左外部結合で発生するNULLよりは問題文的に発生しないだろうな、とか思ったりするんですよね。
2023.09.23 18:55
piyoさん(No.4)
返信ありがとうございます。
はい、なので、最初に書いた通りSQL6,7はテーブル移行の検証なのでまあ公式解答通りでもOKだと思います。使いまわしができなくなるおそれがあるので好みではないですが(以前似たようなテーブル設計で社内Wikiの検証ページに書いたクエリを別の人が使いまわして痛い目にあった)
ここに関しては0にするほうが一般的だと思うんですよね。0にするだけならupdate権限で済みますが行の削除だとdelete権限を付与する必要があるので。まあどっちでも「なんのための設計なんだ〜」って思うほどではないですが、ドキュメントには残しとけよとは思いますね。
これは確かに。
> P23の3.(4)で設置済個数列に1を設定し、正確な個数を移行後に設定する とあるので、移行作業中(SQL6、SQL7を使用する移行作業検証中を含む)は0はありません。
はい、なので、最初に書いた通りSQL6,7はテーブル移行の検証なのでまあ公式解答通りでもOKだと思います。使いまわしができなくなるおそれがあるので好みではないですが(以前似たようなテーブル設計で社内Wikiの検証ページに書いたクエリを別の人が使いまわして痛い目にあった)
> ふつうは設置済個数が0のレコードは新物件の行から削除される
ここに関しては0にするほうが一般的だと思うんですよね。0にするだけならupdate権限で済みますが行の削除だとdelete権限を付与する必要があるので。まあどっちでも「なんのための設計なんだ〜」って思うほどではないですが、ドキュメントには残しとけよとは思いますね。
> kよりはoに、つまり結合段階の条件として書きたいですね
これは確かに。
2023.09.23 19:53
GinSanaさん(No.5)
★DB ゴールドマイスター
トランザクションでない新物件からdeleteの権限は私だったら抜かないとは思います。間違って入れた場合に、物理削除が一般ロールで出来ないのはつらいですね。主キーも主キーなので論理削除も大変です。
権限をガチガチにやるとそれはそれでろくなことになってないんですよね。
権限をガチガチにやるとそれはそれでろくなことになってないんですよね。
2023.09.23 20:10
piyoさん(No.6)
物件登録や更新を行うユーザはエンジニアでなく営業職などの一般社員で、SQL直叩きでなくWebUIなどからの利用になると思われるので、権限絞っても問題なさそうだし変なことさせないために不要な権限はつけたくないですね。余計な権限をつけるとちょっとブラウザ拡張書ける人などがハックしだすので
2023.09.23 20:34
その他のスレッド
»[0591] 「~別」、「 ~ごとに」の解釈について 投稿数:3»[0590] R2午後Ⅱ問2 サブタイプについて 投稿数:3
»[0589] R02 午後2問2設問2 概念モデルと関係スキーマ 投稿数:6