HOME»応用情報技術者試験掲示板»令和4年秋期試験 午後問6【データベース】
投稿する
たぶんその形ですね
mysqlとかpostgresの独自実装レベルで、標準SQLとしてはありません。
GRANT
pgsql-jp.github.io/current/html/sql-grant.html
確かにそうですね、納得しました。ありがとうございます。
実線つけてしまったけど部分点あると嬉しいな...
運用管理担当者のユーザアカウントに対しては適切なアクセス制御が設定されているものとする。
という本文の制約で、運用管理担当者のアカウントは回線番号や内線電話番号だけをgrant select(column)で指定したと推察されます。そのため、上長はselect単体でフルカラムを許可したと考えられる。
»[3829] 令和4年秋期試験 午後問8【情報システム開発】 投稿数:21
»[3828] 令和4年秋期試験 午後問9【プロジェクトマネジメント】 投稿数:35
令和4年秋期試験 午後問6【データベース】 [3831]
管理人(No.1)
令和4年秋期試験 午後問6(データベース)についての投稿を受け付けるスレッドです。
2022.10.09 00:05
ryuさん(No.2)
DEFAULT
FOREIGN KEY
出てこなかったの悔しすぎる...
FOREIGN KEY
出てこなかったの悔しすぎる...
2022.10.09 15:40
あかりさん(No.3)
FOREIGN KEYそれだぁ……出てこなくてPRIMARY KEY2回書いた……
2022.10.09 15:49
受験生さん(No.4)
問1.a{料金プランコード}b↑c{情報端末ID}d{従業員ID}e↓f↰
問2.カ
問3.
jSELECT
kCHAR(4) NOT NULL DEFAULT '1234'
lPRIMARY KEY
m未回答
皆さんの回答はどうでしょうか
問2.カ
問3.
jSELECT
kCHAR(4) NOT NULL DEFAULT '1234'
lPRIMARY KEY
m未回答
皆さんの回答はどうでしょうか
2022.10.09 15:51
あさん(No.5)
データベースのprimary keyのkeyを抜かしたとかって部分点入りますかね、、
2022.10.09 15:55
いさん(No.6)
aは請求年月にしました。
デフォルトもプライマリーもスペル間違えました。
デフォルトもプライマリーもスペル間違えました。
2022.10.09 15:58
defaultさん(No.7)
defaultの綴り間違えました、泣きそうです。
2022.10.09 15:59
Fooさん(No.8)
設問1
a 部署ID(外部キー)
b↑
c従業員ID(外部キー)
d情報端末ID(外部キー)
e↓
f(1対多を上から下に表現)
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL DEFAUL('1234')
l PRIMARY KEY
m FOREIGN KEY
になりました
a 部署ID(外部キー)
b↑
c従業員ID(外部キー)
d情報端末ID(外部キー)
e↓
f(1対多を上から下に表現)
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL DEFAUL('1234')
l PRIMARY KEY
m FOREIGN KEY
になりました
2022.10.09 16:04
ぼろぼろさん(No.9)
a.年月
問2.ユニーク以外Yにしました
問2.ユニーク以外Yにしました
2022.10.09 16:04
いさん(No.10)
情報端末と契約って1:1じゃないのかな
2022.10.09 16:07
いさん(No.11)
プライマリーってユニーク必須じゃないっけ
2022.10.09 16:08
ぼろぼろさん(No.12)
主キー制約の場合はユニーク制約の指定は不要。
問題文にもユニーク制約を指定しないと記載あるのでNがただしいと判断しました。
問題文にもユニーク制約を指定しないと記載あるのでNがただしいと判断しました。
2022.10.09 16:11
aさん(No.13)
PKはnot null有のunique無って問題になかった?
2022.10.09 16:12
あさん(No.14)
私も情報端末と契約は1:1だと思ったけど、違うかな。。
2022.10.09 16:13
ありさん(No.15)
Selectのとこupdateつけた同士いないか、、、
2022.10.09 16:18
いさん(No.16)
selectのとこは
select (参照権限のキー二つ)
上記にしないとテーブル全体にかかる気がしてます。
select (参照権限のキー二つ)
上記にしないとテーブル全体にかかる気がしてます。
2022.10.09 16:20
ぼぼぼさん(No.17)
UPDETEつけた同志ここにおるぞ...
2022.10.09 16:20
ありさん(No.18)
おおーー!書いてあったよな、違うとこに、
あれどうなんや、図2に書いてないからいらないんかやっぱ
あれどうなんや、図2に書いてないからいらないんかやっぱ
2022.10.09 16:22
はるさん(No.19)
update(暗証番号)つけちゃった
2022.10.09 16:24
aさん(No.20)
defaultじゃなくてasって書いてしまった。
よく考えたら、今後もレコード入れるんだからdefaultじゃなきゃだめだな
よく考えたら、今後もレコード入れるんだからdefaultじゃなきゃだめだな
2022.10.09 16:37
しょしんしゃさん(No.21)
ワイもupdateつけたで
2022.10.09 16:37
おさん(No.22)
GRANTって列指定できたんでしたっけ、、SELECTだけ書いてしまった
2022.10.09 16:40
教えてさん(No.23)
この投稿は投稿者により削除されました。(2022.10.09 19:04)
2022.10.09 19:04
あかりさん(No.24)
部署ID(外部キー)
│
従業員ID(外部キー)
情報端末ID(外部キー)
↓
? ※これを線対称にして左に90°傾けたやつ(伝われ)
オ
SELECT
CHAR(4) NOT NULL DEFAULT '1234'
PRIMARY KEY
PRIMARY KEY
にしました
最後思い出せんかった……
│
従業員ID(外部キー)
情報端末ID(外部キー)
↓
? ※これを線対称にして左に90°傾けたやつ(伝われ)
オ
SELECT
CHAR(4) NOT NULL DEFAULT '1234'
PRIMARY KEY
PRIMARY KEY
にしました
最後思い出せんかった……
2022.10.09 16:50
あかりさん(No.25)
ぐるっと矢印表示されんやないかーいww
2022.10.09 16:51
ぱよちんさん(No.26)
しまった。defaultつけるの今気づいた。
一ミスやんけ
一ミスやんけ
2022.10.09 16:52
ぴよさん(No.27)
部署ID ↑ 作業員ID 情報端末ID ↓ ?
(全部外部キー)
オ
grant select
char(4) not null status ’1234’,
(正しくは×status→○default)
primary key
forieng key
(正しくはforien key)
って感じでした…
(全部外部キー)
オ
grant select
char(4) not null status ’1234’,
(正しくは×status→○default)
primary key
forieng key
(正しくはforien key)
って感じでした…
2022.10.09 16:52
ふさん(No.28)
aは請求年月にしました
2022.10.09 17:01
いさん(No.29)
aは請求年月or年月でしょうね
2022.10.09 17:05
Fさん(No.30)
自分はaは年月にしました
部署は[請求部署ID]があったし年月毎で請求するってあったので
部署は[請求部署ID]があったし年月毎で請求するってあったので
2022.10.09 17:10
ぴよさん(No.31)
あっ、請求先部署ありますね!確かにです!
2022.10.09 17:13
maさん(No.32)
外部キーの破線つけなかったら、0点かな…
従業員ID(外部キー)
情報端末ID(外部キー)
従業員ID(外部キー)
情報端末ID(外部キー)
2022.10.09 17:32
Eさん(No.33)
外部キーは破線つけないと×ですよー
2022.10.09 17:39
maさん(No.34)
ですよね(o;д;)o
2022.10.09 17:39
おもちさん(No.35)
結局最初の外部キーってなんですの?
2022.10.09 17:48
ばあーさん(No.36)
問1
a請求年月
b↑
c情報端末ID
d従業員ID
f??
問2
オ
問3
j SELECT
k CHAR(4) NOT NULL DEFAULT '1234'
l PRIMARY KEY
m FOREIGN KEY
a請求年月
b↑
c情報端末ID
d従業員ID
f??
問2
オ
問3
j SELECT
k CHAR(4) NOT NULL DEFAULT '1234'
l PRIMARY KEY
m FOREIGN KEY
2022.10.09 18:00
panさん(No.37)
問3のgrantって、ADMINだから上長のことかと思ったけど違いますかね?
2022.10.09 18:01
りりさん(No.38)
FOREIGHN KEYのつづり出てこなさすぎて草
DEFAULTは普通に忘れてたなあ
DEFAULTは普通に忘れてたなあ
2022.10.09 18:04
panさん(No.39)
空欄fですが、自表から出て自表に戻ってくるような形をした矢印ですかね?
2022.10.09 18:10
aさん(No.40)
-
|
←
|
←
2022.10.09 18:14
panさん(No.41)
>>a
たぶんその形ですね
2022.10.09 18:15
コさん(No.42)
1:1だと思ってコの字の形が正解かと思ってしまいました
2022.10.09 18:39
教えてさん(No.43)
この投稿は投稿者により削除されました。(2022.10.09 19:03)
2022.10.09 19:03
教えてさん(No.44)
←
|
-
じゃなくてですか?
|
-
じゃなくてですか?
2022.10.09 19:05
DayTripperさん(No.45)
俺 F んとこ間違えて
<--------
|
|
|
|
--------- ってしちゃったけどダイジョブかなぁ
<--------
|
|
|
|
--------- ってしちゃったけどダイジョブかなぁ
2022.10.09 19:44
やばしさん(No.46)
primarykeyとforeignkeyのkeyを付け忘れたんですけど
部分点もらえますかね…?
部分点もらえますかね…?
2022.10.09 20:12
あああああさん(No.47)
デフォルト出てこなかった…
1点くらいください…
ないだろうけど
1点くらいください…
ないだろうけど
2022.10.09 20:15
GinSanaさん(No.48)
★AP プラチナマイスター
さっき問題を見ました。
ER図に直接書くんじゃなく、fみたいな聞き方(自己参照)をすると、むしろ書きづらくないかwとは思いました
たぶん、テーブル設計が応用で聞かれたのは初めてじゃないかと思うくらいですね(DBSPで平成26年以降は午後2で聞かれますが)
バイト長の計算はなかったですが
grantは参照onlyだからselectでいいですね adminだと世の中はだいたいall privilegesですが、さすがにそれだと底意地が悪い(スペルがね)からかもしれない・・・
ER図に直接書くんじゃなく、fみたいな聞き方(自己参照)をすると、むしろ書きづらくないかwとは思いました
たぶん、テーブル設計が応用で聞かれたのは初めてじゃないかと思うくらいですね(DBSPで平成26年以降は午後2で聞かれますが)
バイト長の計算はなかったですが
grantは参照onlyだからselectでいいですね adminだと世の中はだいたいall privilegesですが、さすがにそれだと底意地が悪い(スペルがね)からかもしれない・・・
2022.10.09 20:20
フェネさん(No.49)
【設問1】
a:請求年月
b:↑ (2年で端末交換する および 破棄日があるので上が多と判断)
c:従業員ID(点線)
d:情報端末ID(点線) cとdはたぶん順不同
f:←
|
- (自己参照の1対多は自信ない)
【設問2】
オ (PKはUKにせず、非NULLを設定する との記述あり)
【設問3】
j:SELECT
k:CHAR(4) NOT NULL DEFAULT '1234'
l:PRIMARY KEY
m:REFFERENCE KEY (フォレインキー出てこなかった)
概ね皆さまと同じ回答かな…?
a:請求年月
b:↑ (2年で端末交換する および 破棄日があるので上が多と判断)
c:従業員ID(点線)
d:情報端末ID(点線) cとdはたぶん順不同
f:←
|
- (自己参照の1対多は自信ない)
【設問2】
オ (PKはUKにせず、非NULLを設定する との記述あり)
【設問3】
j:SELECT
k:CHAR(4) NOT NULL DEFAULT '1234'
l:PRIMARY KEY
m:REFFERENCE KEY (フォレインキー出てこなかった)
概ね皆さまと同じ回答かな…?
2022.10.09 20:23
あさん(No.50)
GRANTのとこって
SELECT(契約id、暗証番号)
ではだめなのですか?
SELECT(契約id、暗証番号)
ではだめなのですか?
2022.10.09 20:37
GinSanaさん(No.51)
★AP プラチナマイスター
この投稿は投稿者により削除されました。(2022.10.09 20:58)
2022.10.09 20:58
あさん(No.52)
カラム指定できると記憶していました。
2022.10.09 20:48
GinSanaさん(No.53)
★AP プラチナマイスター
mysqlだと出来るのは確認しました。ANSI SQLレベルで出来るかはちょっと調べないとわからんです。
2022.10.09 20:50
フェネさん(No.54)
今見たら、MySQLだとカラム単位での権限設定ができるみたいですね
ANSI SQL(標準のお作法)だと出来ないのかな?
どうなるのだろうか
ANSI SQL(標準のお作法)だと出来ないのかな?
どうなるのだろうか
2022.10.09 20:52
あかりさん(No.55)
この投稿は投稿者により削除されました。(2022.10.09 20:56)
2022.10.09 20:56
GinSanaさん(No.56)
★AP プラチナマイスター
github.com/crate/sql-99/blob/55ee2e51d91e8201109f9f1a74ea0a9e4b402532/docs/chapters/15.rst#grant-statement
申し訳ない、できるそうです。ふだん列名で指定しないから思いこんでいた。
申し訳ない、できるそうです。ふだん列名で指定しないから思いこんでいた。
<privileges> ::=
<object privileges> ON <Object name>
<Object name> ::=
[ TABLE ] <Table name> |
DOMAIN <Domain name> |
CHARACTER SET <Character set name> |
COLLATION <Collation name> |
TRANSLATION <Translation name> |
TYPE <UDT name> |
<specific routine designator>
<object privileges> ::=
ALL PRIVILEGES |
<action> [ {,<action>}... ]
<action> ::=
DELETE |
SELECT [ (<Column name> [ {,<Column name>} ... ]) ] |
INSERT [ (<Column name> [ {,<Column name>} ... ]) ] |
UPDATE [ (<Column name> [ {,<Column name>} ... ]) ] |
REFERENCES [ (<Column name> [ {,<Column name>} ... ]) ] |
TRIGGER |
UNDER |
USAGE |
EXECUTE
<object privileges> ON <Object name>
<Object name> ::=
[ TABLE ] <Table name> |
DOMAIN <Domain name> |
CHARACTER SET <Character set name> |
COLLATION <Collation name> |
TRANSLATION <Translation name> |
TYPE <UDT name> |
<specific routine designator>
<object privileges> ::=
ALL PRIVILEGES |
<action> [ {,<action>}... ]
<action> ::=
DELETE |
SELECT [ (<Column name> [ {,<Column name>} ... ]) ] |
INSERT [ (<Column name> [ {,<Column name>} ... ]) ] |
UPDATE [ (<Column name> [ {,<Column name>} ... ]) ] |
REFERENCES [ (<Column name> [ {,<Column name>} ... ]) ] |
TRIGGER |
UNDER |
USAGE |
EXECUTE
2022.10.09 20:57
あさん(No.57)
ということはSELECTで部分点で列指定で満点なんですかね?
なんかいやらしい問題てすね…
なんかいやらしい問題てすね…
2022.10.09 20:59
GinSanaさん(No.58)
★AP プラチナマイスター
この問題の場合は、列名に意図的に書いてあるから、列名まで書かないとダメかもしれないですね。そもそも列名が書けるのを知ってるやつがどのくらいいるだろうか・・・
2022.10.09 21:03
フェネさん(No.59)
いやぁ、お見事(ひっかけ問題作成者)・・・!って引っ掛けですね・・・w
2022.10.09 21:13
ポッポさん(No.60)
皆さま、試験お疲れ様でした!
jについて、列名記載はしたのですが、()で囲んでいない場合、別の意味になるでしょうか…
jについて、列名記載はしたのですが、()で囲んでいない場合、別の意味になるでしょうか…
2022.10.09 21:31
ああああさん(No.61)
上長(ユーザーアカウント名:ADMIN)による参照が必要
と記載があるので、SELECTで良いかと。
上長にADMINて…とは思いました。
列指定が正解ならエグいです…
ちな、all privilegesもよぎりましたがスペルが分からず読み直したら、文頭の記載があってSELECTでええやん。てなりました。
と記載があるので、SELECTで良いかと。
上長にADMINて…とは思いました。
列指定が正解ならエグいです…
ちな、all privilegesもよぎりましたがスペルが分からず読み直したら、文頭の記載があってSELECTでええやん。てなりました。
2022.10.09 21:31
受験生さん(No.62)
ALL PRIVILEGEはALLの省略形もありますよね?
2022.10.09 21:32
panさん(No.63)
上長(ユーザーアカウント名:ADMIN)による参照が必要
これ見落としてました
表2ヒアリング表の項番4に気を取られすぎました
上長が契約変更を行う、ってあるから、ADMIN=上長で、変更の権限も必要なのかなと
思ったんですが勘違いですかね。。
これ見落としてました
表2ヒアリング表の項番4に気を取られすぎました
上長が契約変更を行う、ってあるから、ADMIN=上長で、変更の権限も必要なのかなと
思ったんですが勘違いですかね。。
2022.10.09 21:55
GinSanaさん(No.64)
★AP プラチナマイスター
たしかに、本文の
設問担当の底意地が悪かったら、運用管理担当者のgrantを聞いたかもしれないw
運用管理担当者のユーザアカウントに対しては適切なアクセス制御が設定されているものとする。
があるので、運用管理担当者のgrantが料金プランコード、回線番号、内線電話番号のgrantが設定されているとすれば、adminは全部が読める(契約IDと暗証番号だけ読めるのは不便きわまりない)と察するのが自然なので、そういう意味ではselectだけでいいかもしれません。設問担当の底意地が悪かったら、運用管理担当者のgrantを聞いたかもしれないw
2022.10.09 22:10
GinSanaさん(No.65)
★AP プラチナマイスター
>ALL PRIVILEGEはALLの省略形もありますよね?
mysqlとかpostgresの独自実装レベルで、標準SQLとしてはありません。
GRANT
pgsql-jp.github.io/current/html/sql-grant.html
ALL PRIVILEGES
Grant all of the privileges available for the object's type. The <literal>PRIVILEGES</literal> key word is optional in <productname>PostgreSQL</productname>, though it is required by strict SQL.
対象の型に対して利用可能な全ての権限を一度に付与します。 PRIVILEGESキーワードはPostgreSQLでは省略可能ですが、厳密なSQLでは必須です。
Grant all of the privileges available for the object's type. The <literal>PRIVILEGES</literal> key word is optional in <productname>PostgreSQL</productname>, though it is required by strict SQL.
対象の型に対して利用可能な全ての権限を一度に付与します。 PRIVILEGESキーワードはPostgreSQLでは省略可能ですが、厳密なSQLでは必須です。
2022.10.09 22:18
たこさん(No.66)
問3で脱字してる部分があって…。
0点になりますよね。
0点になりますよね。
2022.10.10 02:26
ビンゴさん(No.67)
設問1
a 請求年月
b↑
c従業員ID(外部キー)
d情報端末ID(外部キー)
e↓
f矢印をぐるっと下から上へ
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL DEFAULT ('1234')
l PRIMARY KEY
m REFERENCE KEY
設問2は本文の説明書きを見落としてて、最初カを選択していました。
悔しかったのは問3のkで、迷った末にデフォルト値に
()を付けてしまいました。()がついたSQLも見たような気が
したのですが幻だったのでしょうか。。。部分点をお恵みいただきたいな
と思ってます!(ムリか)
mはもう、かすりもしませんでしたね。フォーリンキーが
まったく出てきませんでした。この問題だけが得点源だったので
ちょっと辛い。点数7割ほしいなぁ。
a 請求年月
b↑
c従業員ID(外部キー)
d情報端末ID(外部キー)
e↓
f矢印をぐるっと下から上へ
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL DEFAULT ('1234')
l PRIMARY KEY
m REFERENCE KEY
設問2は本文の説明書きを見落としてて、最初カを選択していました。
悔しかったのは問3のkで、迷った末にデフォルト値に
()を付けてしまいました。()がついたSQLも見たような気が
したのですが幻だったのでしょうか。。。部分点をお恵みいただきたいな
と思ってます!(ムリか)
mはもう、かすりもしませんでしたね。フォーリンキーが
まったく出てきませんでした。この問題だけが得点源だったので
ちょっと辛い。点数7割ほしいなぁ。
2022.10.10 09:07
やきとりさん(No.68)
【設問1】
a:年月
b:↑
c:従業員ID(点線)
d:情報端末ID(点線)
e:↓
f:多対多の記号
【設問2】
オ
【設問3】
j:契約ID,暗証番号 (これは間違いですね・・)
k:CHAR(4) NOT NULL DEFALTE '1234' (スペル間違いました・・。)
l:PRIMARY KEY
m:FK (フォーリン英語で書けず。。)
ここで6割は行きたいンゴね
a:年月
b:↑
c:従業員ID(点線)
d:情報端末ID(点線)
e:↓
f:多対多の記号
【設問2】
オ
【設問3】
j:契約ID,暗証番号 (これは間違いですね・・)
k:CHAR(4) NOT NULL DEFALTE '1234' (スペル間違いました・・。)
l:PRIMARY KEY
m:FK (フォーリン英語で書けず。。)
ここで6割は行きたいンゴね
2022.10.10 09:16
サメライド使いさんさん(No.69)
私は1234にシングルクォートつけませんでしたorz
実際にMySQL v5.7で実行はできたので正解にしてほしいorz
実際にMySQL v5.7で実行はできたので正解にしてほしいorz
2022.10.10 10:37
匿名さん(No.70)
k:CHAR(4) DEFAULT '1234' NOT NULL
にしたんですが、NOT NULL と DEFAULT '1234' は順不同ですかね?oracleでは NOT NULL を先に書くとエラーになるので DEFAULT を先に書いてしました。。
にしたんですが、NOT NULL と DEFAULT '1234' は順不同ですかね?oracleでは NOT NULL を先に書くとエラーになるので DEFAULT を先に書いてしました。。
2022.10.10 10:46
GinSanaさん(No.71)
★AP プラチナマイスター
この投稿は投稿者により削除されました。(2022.10.10 11:15)
2022.10.10 11:15
GinSanaさん(No.72)
★AP プラチナマイスター
not nullがconstraint(制約)なので、ANSI SQLの順序としてはデフォルトが先でnot null(制約類)が後ですね。
SQL-99 Complete, Really
Peter Gulutzan, Trudy Pelzer
Chapter 18 -- SQL Table and View
github.com/crate/sql-99/blob/55ee2e51d91e8201109f9f1a74ea0a9e4b402532/docs/chapters/18.rst
SQL-99 Complete, Really
Peter Gulutzan, Trudy Pelzer
Chapter 18 -- SQL Table and View
github.com/crate/sql-99/blob/55ee2e51d91e8201109f9f1a74ea0a9e4b402532/docs/chapters/18.rst
<Column definition> ::=
unqualified <Column name>
{ <data type> | <Domain name> }
[ <reference scope check> ]
[ DEFAULT default value ]
[ <Column Constraint> list ]
[ COLLATE <Collation name> ]
(以下略)
unqualified <Column name>
{ <data type> | <Domain name> }
[ <reference scope check> ]
[ DEFAULT default value ]
[ <Column Constraint> list ]
[ COLLATE <Collation name> ]
(以下略)
2022.10.10 11:16
ぬるさん(No.73)
どっかの解答速報に権限設定のとこUPDATEもいるってなってましたが、ヒアリング結果ではなく、あくまであの表に対する権限設定問われているのでいらないですよね…
2022.10.10 13:10
うーさん(No.74)
やはり、j:契約ID,暗証番号 はだめですか?
2022.10.10 14:13
kさん(No.75)
PRIMARY と FOREIGN に KEY
つけるの忘れました、、、
部分点貰えるんでしょうか、、、、
つけるの忘れました、、、
部分点貰えるんでしょうか、、、、
2022.10.10 15:15
tukaretenaさん(No.76)
DEFAULT='1234'にしてしまった~~
2022.10.10 16:44
ばあーさん(No.77)
ANSI SQL準拠だと、DEFAULTが先でNOT NULLが後か、、、。
自分含めて引っかかった人多そう。
そして得点調整で多めの配点ありそう。
自分含めて引っかかった人多そう。
そして得点調整で多めの配点ありそう。
2022.10.10 16:55
たさん(No.78)
結局 GRANT のところは SELECT だけでいいのでしょうか、、
2022.10.10 18:09
Hiroさん(No.79)
bって↑か|で割れてるけど↑じゃないのかな?
同じ契約で端末変えれるし、
携帯番号も機種変したら使い回すし、
……という期待(笑)
誰か賛同者か違う意見の方いますか?
同じ契約で端末変えれるし、
携帯番号も機種変したら使い回すし、
……という期待(笑)
誰か賛同者か違う意見の方いますか?
2022.10.10 18:25
Hiroさん(No.80)
SELECTだけで文法的にはいいはずです
2022.10.10 18:26
今度こそ受かりたいさん(No.81)
空欄Fの穴埋め、カーディナリティの問題は結局何が正解ぽいですかね。コの字、コの字の上だけ矢印、下だけ矢印、上下両方矢印?
2022.10.10 21:18
GinSanaさん(No.82)
★AP プラチナマイスター
上長の契約変更の役割を考えたら、updateもgrantにいるとなっても不思議じゃない(そんな解説を見た。全部解説を書いていて、すごい早い解説書く人だった)けど、
契約変更の範囲でフルカラムに権限くれたら、契約IDや暗証番号(暗証番号はいいか)までいじれていいの?とかなると思うんですよねえ。まあ、契約IDがいじれないと思うのはプライマリといい一般常識の範囲だから、もしかしたらいじってもいいルールなのかもしれない。
updateだけ列指定でselectはフル指定で併記するってのもどうだろう?とは思いますかねえ。
契約変更の範囲でフルカラムに権限くれたら、契約IDや暗証番号(暗証番号はいいか)までいじれていいの?とかなると思うんですよねえ。まあ、契約IDがいじれないと思うのはプライマリといい一般常識の範囲だから、もしかしたらいじってもいいルールなのかもしれない。
updateだけ列指定でselectはフル指定で併記するってのもどうだろう?とは思いますかねえ。
2022.10.10 21:39
GinSanaさん(No.83)
★AP プラチナマイスター
空欄Fのは、上位部署が部署を参照するためで1対多だから、 → がぐにゃっと曲がったやつですね。仮に1対1の場合、上位部署は1つしか下位部署を有しないとかバカげた前提が必要になる。
2022.10.10 21:48
今度こそ受かりたいさん(No.84)
GinSanaさん、ありがとうございます。
Fは、コの下だけ矢印が有力みたいですね。
すっきりしました。
Fは、コの下だけ矢印が有力みたいですね。
すっきりしました。
2022.10.10 21:56
てすとさん(No.85)
最初 請求年月 にしました
fがわかりにくかった…コの字ならもっと四角を縦長にしてほしかったですねw
最後2つkeyがいるかいらないか悩んでつけ忘れました
fがわかりにくかった…コの字ならもっと四角を縦長にしてほしかったですねw
最後2つkeyがいるかいらないか悩んでつけ忘れました
2022.10.10 21:57
受験生さん(No.86)
コの上だけ矢印では意味かわりますか?
2022.10.10 21:57
GinSanaさん(No.87)
★AP プラチナマイスター
変わらんです。自分に向けて矢印が戻ってくれば、そこはどうでもいいはずです(デビスペでフリーハンドで自己参照のリレーションを引いたときも、そんな違いはどうでもよかったので)
というか、Fの領域が短すぎて、ヒントにしかならんですね。
というか、Fの領域が短すぎて、ヒントにしかならんですね。
2022.10.10 22:00
ばあーさん(No.88)
fの線は「コ」に矢印じゃなくて「つ」に矢印にしちゃったよ、トホホ
2022.10.10 22:13
かずさん(No.89)
設問1
a 部署ID(請求年月ですかね…)
b↑
c従業員ID(外部)
d情報端末ID(外部)
e↓
f コ(下の線に←)
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL (デフォルト書き漏れ)
l PRIMARY KEY
m 外部キー(綴り思い出せず…)
a 部署ID(請求年月ですかね…)
b↑
c従業員ID(外部)
d情報端末ID(外部)
e↓
f コ(下の線に←)
設問2
オ
設問3
j SELECT
k CHAR(4) NOT NULL (デフォルト書き漏れ)
l PRIMARY KEY
m 外部キー(綴り思い出せず…)
2022.10.10 22:16
アスパラガスさん(No.90)
問1のeを??で解答した方いますか、、、?
アプリ追加って別に一つとは限らないなと思ってそうしたんですが、
皆さんの回答拝見しても、同じ人がおらず、、、
↑となる根拠も自分には分からずの状態です!
アプリ追加って別に一つとは限らないなと思ってそうしたんですが、
皆さんの回答拝見しても、同じ人がおらず、、、
↑となる根拠も自分には分からずの状態です!
2022.10.10 22:50
ぬるさん(No.91)
SELECT(契約ID、暗証番号)にしちゃったんですが、0点ではないですよね…
わざわざ2つの列だけに参照必要と書いてあるので騙されました…
わざわざ2つの列だけに参照必要と書いてあるので騙されました…
2022.10.10 22:51
アスパラガスさん(No.92)
↑
なんか文字化けしてますが、
上下の矢印です!
なんか文字化けしてますが、
上下の矢印です!
2022.10.10 22:51
たくみさん(No.93)
aって請求年月じゃないとダメですかね…
年月だけにしてしまいました…
年月だけにしてしまいました…
2022.10.10 23:05
名無しさん(No.94)
空欄aについて
請求年月に実線つけた方いませんか?
年月まで主キーに含めないと異なる年月が入らない気がするのですが...
請求年月に実線つけた方いませんか?
年月まで主キーに含めないと異なる年月が入らない気がするのですが...
2022.10.10 23:52
ンゴオオオさん(No.95)
請求番号が異なればいいだけなので請求年月がキーにかかわる必要はないのでは
複数レコードで同じ番号である必要性=請求番号でグルーピングする必要性は特にないですし
(年月が違うだけで元になっている契約が同じ、というようなグルーピングは必要ですがすでに外部キーがある)
複数レコードで同じ番号である必要性=請求番号でグルーピングする必要性は特にないですし
(年月が違うだけで元になっている契約が同じ、というようなグルーピングは必要ですがすでに外部キーがある)
2022.10.11 00:13
名無しさん(No.96)
>請求番号が異なればいいだけ
確かにそうですね、納得しました。ありがとうございます。
実線つけてしまったけど部分点あると嬉しいな...
2022.10.11 00:35
やるさん(No.97)
GRANTでSELECTを上長(ADMIN)以外に縛ると
いちいち契約の暗証番号以外の情報を参照したいときも上長に依頼しなきゃいけないってこと?って言う疑問が出ますね…
回線番号や内線電話番号もカラムにあるテーブルだし
GRANT SELECTにしちゃうと
個人の従業員と利用と情報端末と契約テーブルを結合して選んだ従業員の内線電話番号とか取得するのも上長以外できなくなるのでは?
いちいち契約の暗証番号以外の情報を参照したいときも上長に依頼しなきゃいけないってこと?って言う疑問が出ますね…
回線番号や内線電話番号もカラムにあるテーブルだし
GRANT SELECTにしちゃうと
個人の従業員と利用と情報端末と契約テーブルを結合して選んだ従業員の内線電話番号とか取得するのも上長以外できなくなるのでは?
2022.10.11 05:28
GinSanaさん(No.98)
★AP プラチナマイスター
>やるさん(No.97)
運用管理担当者のユーザアカウントに対しては適切なアクセス制御が設定されているものとする。
という本文の制約で、運用管理担当者のアカウントは回線番号や内線電話番号だけをgrant select(column)で指定したと推察されます。そのため、上長はselect単体でフルカラムを許可したと考えられる。
2022.10.11 07:26
GinSanaさん(No.99)
★AP プラチナマイスター
※正確には、契約IDと暗証番号以外の列を指定した、が正しい
2022.10.11 07:28
やるさん(No.100)
なるほどそういうことですか
たしかに解説で
~とあるので上長以外には暗証番号と契約IDを除いた参照権限が付与されていると考えられますよって~
みたいな文章があるのが目に浮かびますw
たしかに解説で
~とあるので上長以外には暗証番号と契約IDを除いた参照権限が付与されていると考えられますよって~
みたいな文章があるのが目に浮かびますw
2022.10.11 12:08
フェネさん(No.101)
TACの解答速報見てきました
試験のミカタ の速報では SELECTのみ
TAC の速報では 列も指定してました
試験のミカタ の速報では SELECTのみ
TAC の速報では 列も指定してました
2022.10.11 17:53
GinSanaさん(No.102)
★AP プラチナマイスター
TAC、列は何を指定してましたか?
むしろ上長に列指定だと不便じゃないのか?とは思います
むしろ上長に列指定だと不便じゃないのか?とは思います
2022.10.11 18:52
どうなんだろう?さん(No.103)
矢印を書くところ、1対1とか、1対多とか書いてしまった。
でもって、主キーなんかに波線とかそーいうのも書くの忘れてた。
なんたる失態!!
でもって、主キーなんかに波線とかそーいうのも書くの忘れてた。
なんたる失態!!
2022.10.11 18:55
GinSanaさん(No.104)
★AP プラチナマイスター
※ここでいう不便とは、たとえば仮にバカ正直に上長に契約IDと暗証番号のgrant参照権限のみを与えた場合、他のしたっぱが見てもいいようなやつが見られずに、いちいちしたっぱに聞かなければならない(自分で仕事に違和感が持てない)という業務としてバカげた事態が発生することを指す。
2022.10.11 18:57
ばあーさん(No.105)
TACの列指定は下記でしたね。
SELECT(契約ID, 暗証番号)
SELECT(契約ID, 暗証番号)
2022.10.11 19:07
GinSanaさん(No.106)
★AP プラチナマイスター
TACはそうなんですね。実運用で真似されたらたまったもんじゃないなw
2022.10.11 19:08
ばあーさん(No.107)
この投稿は投稿者により削除されました。(2022.10.11 19:14)
2022.10.11 19:14
GinSanaさん(No.108)
★AP プラチナマイスター
ANSIのBNF記法の説明からすると、デフォルトが先ですね。
こういうの、ふだんのDBのクセで書いてそうだな。
こういうの、ふだんのDBのクセで書いてそうだな。
2022.10.11 19:14
ばあーさん(No.109)
「DEFAULTが先でNOT NULLが後ですよね」の誤りです、元の投稿削除しました。
GinSanaさん返信ありがとうございました。
GinSanaさん返信ありがとうございました。
2022.10.11 19:15
GinSanaさん(No.110)
★AP プラチナマイスター
※108の返信の元の記述は、どこの解答速報もnot nullのconstraintが先だったというもの
たしかに、sql99マニュアルのサンプルだと、constraintとdefaultを両方まとめて書いたサンプルが見つからなかった(まじめに探してないだけかもしれない)から、構文レベルでしか確証は持てていない。でも、データベースなら、マニュアルは読んで解答速報は書いてほしいかもしれない どうせ後出しの解答なので
たしかに、sql99マニュアルのサンプルだと、constraintとdefaultを両方まとめて書いたサンプルが見つからなかった(まじめに探してないだけかもしれない)から、構文レベルでしか確証は持てていない。でも、データベースなら、マニュアルは読んで解答速報は書いてほしいかもしれない どうせ後出しの解答なので
2022.10.11 19:30
あさん(No.111)
自己参照の記号丸みをおびさせてしまったのですが、
四角にしないとみたいなルールってあるのですか?
四角にしないとみたいなルールってあるのですか?
2022.10.11 19:41
GinSanaさん(No.112)
★AP プラチナマイスター
postgresの構造は、
改めて調べると、defaultの認識の違いから来るのは新鮮ですね
create
(中略)
where column_constraint can be:
constraint constraint_name
not null
unique
primary
default value
以下略
で、constraintとしてdefaultを認識しているから、順序を気にしないのか。(中略)
where column_constraint can be:
constraint constraint_name
not null
unique
primary
default value
以下略
改めて調べると、defaultの認識の違いから来るのは新鮮ですね
2022.10.11 19:51
DayTripperさん(No.113)
資格の歩き方ってサイトだと
(1)aが請求年月になっているのに、TACだと年月だけになってる
どっちがいいんだろ
(1)aが請求年月になっているのに、TACだと年月だけになってる
どっちがいいんだろ
2022.10.11 20:00
ばあーさん(No.114)
部署IDが"請求先部署ID"となっているので、年月も"請求年月"が適切な気がしますねー。
テーブル名からして請求年月ということは分かりそうなのでどっちでも正解だとは思いますが。
テーブル名からして請求年月ということは分かりそうなのでどっちでも正解だとは思いますが。
2022.10.11 20:02
やほさん(No.115)
終了5分前に 請求年月 から 請求時年月 に変えたワタクシ
意味は伝わるし、年月別集計の要件も満たせるし、ダイジョブダナー(汗)
意味は伝わるし、年月別集計の要件も満たせるし、ダイジョブダナー(汗)
2022.10.11 21:36
フェネさん(No.116)
iTECきてました!
TACと違うのは、
設問1のb
TAC:↑ iTEC:|
(契約に端末を複数持てるかどうかで割れてる)
設問1のf
自己参照で一対多(iTECは下側に矢印がついている)
GRANTの件は、どっちも項目まで含めてるようでした。
TACと違うのは、
設問1のb
TAC:↑ iTEC:|
(契約に端末を複数持てるかどうかで割れてる)
設問1のf
自己参照で一対多(iTECは下側に矢印がついている)
GRANTの件は、どっちも項目まで含めてるようでした。
2022.10.13 14:52
GinSanaさん(No.117)
★AP プラチナマイスター
内線電話番号の解釈にもよるかもしれない。ふつうなら1対多だけど、内線電話番号で端末と1対1にすると読み取った場合は、契約と1対1と読める。
2022.10.13 15:02
GinSanaさん(No.118)
★AP プラチナマイスター
※117の続き
しかし、交換予定日のことを考えると、当然ながら複数の情報端末が2年またぎで同契約に対して紐づくので、これを鑑みると、1対多と考えられる。
しかし、交換予定日のことを考えると、当然ながら複数の情報端末が2年またぎで同契約に対して紐づくので、これを鑑みると、1対多と考えられる。
2022.10.13 15:57
GinSanaさん(No.119)
★AP プラチナマイスター
だから、実際には、回線番号の都合上、1つの端末ごとに契約を結んで(契約のレコードを作成して)、それらの端末の2年後以降の交換端末に対しては以前の交換前の契約を適用する(回線番号を使い回す)となると、一見すると1対1なようで、実際は1対多でないとならないと解釈できる。
2022.10.13 16:00
その他のスレッド
»[3830] 令和4年秋期試験 午後問7【組込みシステム開発】 投稿数:127»[3829] 令和4年秋期試験 午後問8【情報システム開発】 投稿数:21
»[3828] 令和4年秋期試験 午後問9【プロジェクトマネジメント】 投稿数:35