令和4年秋期試験 午後問6【データベース】

管理人  
(No.1)
令和4年秋期試験 午後問6(データベース)についての投稿を受け付けるスレッドです。
2022.10.09 00:05
ryuさん 
(No.2)
DEFAULT
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未回答

皆さんの回答はどうでしょうか
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

になりました
2022.10.09 16:04
ぼろぼろさん 
(No.9)
a.年月
問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がただしいと判断しました。
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 (参照権限のキー二つ)

上記にしないとテーブル全体にかかる気がしてます。
2022.10.09 16:20
ぼぼぼさん 
(No.17)
UPDETEつけた同志ここにおるぞ...
2022.10.09 16:20
ありさん 
(No.18)
おおーー!書いてあったよな、違うとこに、
あれどうなんや、図2に書いてないからいらないんかやっぱ
2022.10.09 16:22
はるさん 
(No.19)
update(暗証番号)つけちゃった
2022.10.09 16:24
aさん 
(No.20)
defaultじゃなくてasって書いてしまった。
よく考えたら、今後もレコード入れるんだから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

にしました
最後思い出せんかった……
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)

って感じでした…
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]があったし年月毎で請求するってあったので
2022.10.09 17:10
ぴよさん 
(No.31)
あっ、請求先部署ありますね!確かにです!
2022.10.09 17:13
maさん 
(No.32)
外部キーの破線つけなかったら、0点かな…
 
従業員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
2022.10.09 18:00
panさん 
(No.37)
問3のgrantって、ADMINだから上長のことかと思ったけど違いますかね?
2022.10.09 18:01
りりさん 
(No.38)
FOREIGHN KEYのつづり出てこなさすぎて草
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点くらいください…
ないだろうけど
2022.10.09 20:15
GinSanaさん 
AP プラチナマイスター
(No.48)
さっき問題を見ました。
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    (フォレインキー出てこなかった)

概ね皆さまと同じ回答かな…?
2022.10.09 20:23
さん 
(No.50)
GRANTのとこって
SELECT(契約id、暗証番号)
ではだめなのですか?
2022.10.09 20:37
GinSanaさん 
AP プラチナマイスター
(No.51)
この投稿は投稿者により削除されました。(2022.10.09 20:58)
2022.10.09 20:58
さん 
(No.52)
カラム指定できると記憶していました。
2022.10.09 20:48
GinSanaさん 
AP プラチナマイスター
(No.53)
mysqlだと出来るのは確認しました。ANSI SQLレベルで出来るかはちょっと調べないとわからんです。
2022.10.09 20:50
フェネさん 
(No.54)
今見たら、MySQLだとカラム単位での権限設定ができるみたいですね
ANSI SQL(標準のお作法)だと出来ないのかな?
どうなるのだろうか
2022.10.09 20:52
あかりさん 
(No.55)
この投稿は投稿者により削除されました。(2022.10.09 20:56)
2022.10.09 20:56
GinSanaさん 
AP プラチナマイスター
(No.56)
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
2022.10.09 20:57
さん 
(No.57)
ということはSELECTで部分点で列指定で満点なんですかね?
なんかいやらしい問題てすね…
2022.10.09 20:59
GinSanaさん 
AP プラチナマイスター
(No.58)
この問題の場合は、列名に意図的に書いてあるから、列名まで書かないとダメかもしれないですね。そもそも列名が書けるのを知ってるやつがどのくらいいるだろうか・・・
2022.10.09 21:03
フェネさん 
(No.59)
いやぁ、お見事(ひっかけ問題作成者)・・・!って引っ掛けですね・・・w
2022.10.09 21:13
ポッポさん 
(No.60)
皆さま、試験お疲れ様でした!
jについて、列名記載はしたのですが、()で囲んでいない場合、別の意味になるでしょうか…
2022.10.09 21:31
ああああさん 
(No.61)
上長(ユーザーアカウント名:ADMIN)による参照が必要

と記載があるので、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=上長で、変更の権限も必要なのかなと
思ったんですが勘違いですかね。。
2022.10.09 21:55
GinSanaさん 
AP プラチナマイスター
(No.64)
たしかに、本文の
運用管理担当者のユーザアカウントに対しては適切なアクセス制御が設定されているものとする。
があるので、運用管理担当者のgrantが料金プランコード、回線番号、内線電話番号のgrantが設定されているとすれば、adminは全部が読める(契約IDと暗証番号だけ読めるのは不便きわまりない)と察するのが自然なので、そういう意味ではselectだけでいいかもしれません。
設問担当の底意地が悪かったら、運用管理担当者のgrantを聞いたかもしれないw
2022.10.09 22:10
GinSanaさん 
AP プラチナマイスター
(No.65)
>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では必須です。
2022.10.09 22:18
たこさん 
(No.66)
問3で脱字してる部分があって…。
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割ほしいなぁ。
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割は行きたいンゴね
2022.10.10 09:16
サメライド使いさんさん 
(No.69)
私は1234にシングルクォートつけませんでした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 を先に書いてしました。。
2022.10.10 10:46
GinSanaさん 
AP プラチナマイスター
(No.71)
この投稿は投稿者により削除されました。(2022.10.10 11:15)
2022.10.10 11:15
GinSanaさん 
AP プラチナマイスター
(No.72)
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
<Column definition> ::=
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さん 
AP プラチナマイスター
(No.82)
上長の契約変更の役割を考えたら、updateもgrantにいるとなっても不思議じゃない(そんな解説を見た。全部解説を書いていて、すごい早い解説書く人だった)けど、
契約変更の範囲でフルカラムに権限くれたら、契約IDや暗証番号(暗証番号はいいか)までいじれていいの?とかなると思うんですよねえ。まあ、契約IDがいじれないと思うのはプライマリといい一般常識の範囲だから、もしかしたらいじってもいいルールなのかもしれない。
updateだけ列指定でselectはフル指定で併記するってのもどうだろう?とは思いますかねえ。
2022.10.10 21:39
GinSanaさん 
AP プラチナマイスター
(No.83)
空欄Fのは、上位部署が部署を参照するためで1対多だから、  →  がぐにゃっと曲がったやつですね。仮に1対1の場合、上位部署は1つしか下位部署を有しないとかバカげた前提が必要になる。
2022.10.10 21:48
今度こそ受かりたいさん 
(No.84)
GinSanaさん、ありがとうございます。
Fは、コの下だけ矢印が有力みたいですね。
すっきりしました。
2022.10.10 21:56
てすとさん 
(No.85)
最初  請求年月  にしました
fがわかりにくかった…コの字ならもっと四角を縦長にしてほしかったですねw
最後2つkeyがいるかいらないか悩んでつけ忘れました
2022.10.10 21:57
受験生さん 
(No.86)
コの上だけ矢印では意味かわりますか?
2022.10.10 21:57
GinSanaさん 
AP プラチナマイスター
(No.87)
変わらんです。自分に向けて矢印が戻ってくれば、そこはどうでもいいはずです(デビスペでフリーハンドで自己参照のリレーションを引いたときも、そんな違いはどうでもよかったので)
というか、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 外部キー(綴り思い出せず…)
2022.10.10 22:16
アスパラガスさん 
(No.90)
問1のeを??で解答した方いますか、、、?
アプリ追加って別に一つとは限らないなと思ってそうしたんですが、
皆さんの回答拝見しても、同じ人がおらず、、、
↑となる根拠も自分には分からずの状態です!
2022.10.10 22:50
ぬるさん 
(No.91)
SELECT(契約ID、暗証番号)にしちゃったんですが、0点ではないですよね…
わざわざ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にしちゃうと
個人の従業員と利用と情報端末と契約テーブルを結合して選んだ従業員の内線電話番号とか取得するのも上長以外できなくなるのでは?
2022.10.11 05:28
GinSanaさん 
AP プラチナマイスター
(No.98)
>やるさん(No.97) 
運用管理担当者のユーザアカウントに対しては適切なアクセス制御が設定されているものとする。
という本文の制約で、運用管理担当者のアカウントは回線番号や内線電話番号だけをgrant select(column)で指定したと推察されます。そのため、上長はselect単体でフルカラムを許可したと考えられる。
2022.10.11 07:26
GinSanaさん 
AP プラチナマイスター
(No.99)
※正確には、契約IDと暗証番号以外の列を指定した、が正しい
2022.10.11 07:28
やるさん 
(No.100)
なるほどそういうことですか
たしかに解説で
~とあるので上長以外には暗証番号と契約IDを除いた参照権限が付与されていると考えられますよって~
みたいな文章があるのが目に浮かびますw
2022.10.11 12:08
フェネさん 
(No.101)
TACの解答速報見てきました

試験のミカタ の速報では SELECTのみ
TAC の速報では 列も指定してました
2022.10.11 17:53
GinSanaさん 
AP プラチナマイスター
(No.102)
TAC、列は何を指定してましたか?
むしろ上長に列指定だと不便じゃないのか?とは思います
2022.10.11 18:52
どうなんだろう?さん 
(No.103)
矢印を書くところ、1対1とか、1対多とか書いてしまった。
でもって、主キーなんかに波線とかそーいうのも書くの忘れてた。
なんたる失態!!
2022.10.11 18:55
GinSanaさん 
AP プラチナマイスター
(No.104)
※ここでいう不便とは、たとえば仮にバカ正直に上長に契約IDと暗証番号のgrant参照権限のみを与えた場合、他のしたっぱが見てもいいようなやつが見られずに、いちいちしたっぱに聞かなければならない(自分で仕事に違和感が持てない)という業務としてバカげた事態が発生することを指す。
2022.10.11 18:57
ばあーさん 
(No.105)
TACの列指定は下記でしたね。
SELECT(契約ID, 暗証番号)
2022.10.11 19:07
GinSanaさん 
AP プラチナマイスター
(No.106)
TACはそうなんですね。実運用で真似されたらたまったもんじゃないなw
2022.10.11 19:08
ばあーさん 
(No.107)
この投稿は投稿者により削除されました。(2022.10.11 19:14)
2022.10.11 19:14
GinSanaさん 
AP プラチナマイスター
(No.108)
ANSIのBNF記法の説明からすると、デフォルトが先ですね。
こういうの、ふだんのDBのクセで書いてそうだな。
2022.10.11 19:14
ばあーさん 
(No.109)
「DEFAULTが先でNOT NULLが後ですよね」の誤りです、元の投稿削除しました。
GinSanaさん返信ありがとうございました。
2022.10.11 19:15
GinSanaさん 
AP プラチナマイスター
(No.110)
※108の返信の元の記述は、どこの解答速報もnot nullのconstraintが先だったというもの

たしかに、sql99マニュアルのサンプルだと、constraintとdefaultを両方まとめて書いたサンプルが見つからなかった(まじめに探してないだけかもしれない)から、構文レベルでしか確証は持てていない。でも、データベースなら、マニュアルは読んで解答速報は書いてほしいかもしれない  どうせ後出しの解答なので
2022.10.11 19:30
さん 
(No.111)
自己参照の記号丸みをおびさせてしまったのですが、
四角にしないとみたいなルールってあるのですか?
2022.10.11 19:41
GinSanaさん 
AP プラチナマイスター
(No.112)
postgresの構造は、
create
(中略)
where column_constraint can be:
constraint constraint_name
not null
unique
primary
default value
以下略

で、constraintとしてdefaultを認識しているから、順序を気にしないのか。
改めて調べると、defaultの認識の違いから来るのは新鮮ですね
2022.10.11 19:51
DayTripperさん 
(No.113)
資格の歩き方ってサイトだと
(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の件は、どっちも項目まで含めてるようでした。
2022.10.13 14:52
GinSanaさん 
AP プラチナマイスター
(No.117)
内線電話番号の解釈にもよるかもしれない。ふつうなら1対多だけど、内線電話番号で端末と1対1にすると読み取った場合は、契約と1対1と読める。
2022.10.13 15:02
GinSanaさん 
AP プラチナマイスター
(No.118)
※117の続き
しかし、交換予定日のことを考えると、当然ながら複数の情報端末が2年またぎで同契約に対して紐づくので、これを鑑みると、1対多と考えられる。
2022.10.13 15:57
GinSanaさん 
AP プラチナマイスター
(No.119)
だから、実際には、回線番号の都合上、1つの端末ごとに契約を結んで(契約のレコードを作成して)、それらの端末の2年後以降の交換端末に対しては以前の交換前の契約を適用する(回線番号を使い回す)となると、一見すると1対1なようで、実際は1対多でないとならないと解釈できる。
2022.10.13 16:00

返信投稿用フォーム

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

その他のスレッド


Pagetop