応用情報技術者 試験情報＆徹底解説

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

データベース意味わからんすぎて無事死亡でした

僕もsql書くところが分からなかったです。
上のアは一時テーブルを作成する処理的なので合ってますか？
書き方分からなかったのでクリエイトテーブルって入れちゃいましたが...💦

インデックスとかわかんね〜
主キーにはインデックス付いてますって主キーはツリーインデックス付けなくて良いって意味か？  あれ

インデックスは、ノーマークでした、、、

スペル間違えたが、  WITH  Recursive ですね
再帰処理です

SQLを特化して勉強したけど真っ先に捨てました

DB取るつもりでいたけど1問目見て危険を感じたから文系セットにしました

>>6
なんじゃそれ
CREATE VIEW と UNIONちゃうんかい

Index系はちょっと前方一致とかで怪しいですが、b木インデックスきくっっちゃ効くので、名称となんかのキーIDにそれぞれつけました

>>9
UNIONは合ってると思います
自分もUNION

a自己参照の1対多の矢印
b-
c追跡番号
d←
eCREATE VIEW
fUNION
g出品.カテゴリID=指定カテゴリ.カテゴリID
hLIKE %:キーワード%
ア、ウ、オ
出品  カテゴリID、出品価格、商品状態、出品状況
カテゴリ  上位カテゴリID

難しかったです
fはUNIONじゃダメですかね〜笑

CREATE VIEWとUNIONでてきた？
LIKEの構文忘れてたんだけど
LIKE ':キーワード'
であってたのかな…

>>6
WITHまでは出てきましたけど再帰処理までは考えられなかったですね…

recursiveだけだと部分点なし？？

よくわからなくて、WITHとUNION ALLにしました。

LIKE '%:キーワード%' にできるんですかね。。
迷って結局ワイルドカードは付けなかった。

僕も迷ったけど文中で該当の値を格納するいうてるからってワイルドカードつけなかった…

likeってインデックス効くんだっけ？
効かないと思って抜いちゃった〜

LIKEって変数展開必要じゃないですか？

選択問題から5問解いて、データベースが1番自信なかったので捨てました

'%hoge'、'%hoge%'のように前方側で曖昧検索してたらインデックスは効きませんね。

実務でOracle使ってるからWITHは分かった
Recursiveってなんスか？実務で使わんもの出すのやめてもろて

create viewとwithで分かれてるけどwithが正解ですね。withはテーブル名 asの後は()で囲うけど、create viewは囲わないでそのままselectが来る。

WITH  Recursiveと
union all
です。

そういう構文なので
Recursiveがないと多分ダメだし
同様にallがないとダメだと思います

問題文に部分一致があるからLIKE '%:キーワード%' が正しそう。
その場合インデックスは効かないので、最後のインデックスの問題では解答から外す必要がありますね。

Union だけでも動いてたような気がするが‥
つけとくべきだったか。。
実務では確かに使う機会殆ど無いですね
最近だとシーケンス採番とそれサブキーにするやつのInsert文だったかな

LIKEいるのか…%で囲ってるから部分点ください…

DB得意だったのにどんどんダメになってくる…

自己参照のER図って矢印どっち巻きとかある？

union allでは重複レコードを排除せず検索結果に同じデータが複数表示されると思いunionにしました。

自己参照の関連は過去問でどちらでも正解なので大丈夫かと思います。

union all :全部出力
union:同じデータ(重複)を除いて出力

集約関数使われてないから一応どっちでもセーフかも？

>>32 >>33
あざます！
後は無意識に  LIKE  * hoge* にしちゃったので  部分点か正解にしてもらえるかですねw

自分はインデックスは、
ア、ウ、オ
にしましたが皆さんは何にしましたか？？

WITHはかけたけど
WITH RECURSIVEはむりです。。

ぼくもあ、う、おです

普通に検索結果だから重複してもいんじゃねって思ってきた

LIKE "%:キーワード%"にした
ぼこぼこです
得点調整あるといいな

SQL書くところの一番最初は「CREATE VIEW」だと思ってましたが違うんですかね💦

Withのところ、Withにしては空白が長かったような、、、下がUnionで文字数同じなのにWithの空白の方がだいぶ大きかったからCreate tableに書き換えてしまった

選んだ時点でドボンの悪問でしたね。

likeのやつ、
LIKE '%'||:キーワード||'%'
にした。
さすがに〇欲しいなあ。。

使ってる参考書でRECURSIVE見たことないからWITHだけにしてしまった
DBは爆死か…

最初WITHだと思ってたけど、指定カテゴリから下位カテゴリをすべて検索するってあったから再帰なのは気づいたけど、RECURSIVEの綴り間違えた
RECURCIVEにしてしまった。。。

LIKE '%(:キーワード)%' ってしてもうた。
部分点なしの0点だろうか…

最初のハコ、意味わからなさ過ぎたけど
recursiveってなんぞや?!仕事じゃ全く聞いたことないぞそんなの!
当て字に近いけど消去法で入るとしたらこれかと思い「create view」と書きました

>likeってインデックス効くんだっけ？
ここ、めんどくさいところ。

%なにがし% → きかない
なにがし% → きく

要は、インデックスってソート済みデータの様な概念なので、部分一致では利かせようがないのです。

…というのが実務目線の話ですが、試験としてはどうなりますかね。

ダブルクオートにしちゃった。。

あと2つのSQL繋げるところ、うっかりleft joinと書いてしまった。
そうだよね、同じテーブル見ているんだから普通に結合させて良かった。
難易度も後半手が出なかったので、今回の一番のしくじりはここを選んでしまった事でした。
こんなこと考えながらインデックス貼る人なんているの?!
こういう場合、本番データからマスクしてコピーしてきて、実際試すでしょ…
ってこういうこと考えたら試験は負けなんですよね。
ぎゃふん。

イ、ウ、オにしちゃったけど3つあってないと◯もらえない？

設問3 (2)出品表でインデックス設定するのは商品状態、出品状況も含みますかね？
Tさんの方針(5%以下～)では対象外なのは分かりますが、
設問では「高速化に寄与する列名」としか記載されていなかったので、高速化はするだろということで回答に加えてましたが・・・

設問1
a コ (上が←)
b ー
c 追跡番号
d ←
設問2
e WITH
f UNION
g 出品.カテゴリID = 指定カテゴリ.カテゴリID
h LIKE '%:キーワード%'
設問3
(1) ア、ウ、カ
(2)
出品表：出品ID、カテゴリID、商品状態、出品状況
カテゴリ表：カテゴリID、上位カテゴリID

WITHはWITHじゃないの？
RECURSIVEって応用情報問題じゃ完全初見だし仕事でも使ったことない
綴りの難しさ含めてこれを解答させるの酷だと思うんだが…

主キーにはインデックスがあるから、
出品表の出品IDとカテゴリ表のカテゴリIDにはつけなくていい？と予想

記号はイ、ウ、オにしました。。
部分点ないですかねぇ…

dは→かなと思ったのですが、可能性はどうでしょうか？

フォロー元利用者に対してと、フォロー先に対して。

令和6春でも、同じ方向の矢印が2つある関係があったので、これもそうかなと思った次第です。。

like ％:キーワード％じゃだめなのか？
埋め込み変数だから文字列扱いしたらだめな気がしてシングルクォーテーション外したんだけど

>like ％:キーワード％じゃだめなのか？
考えてみるといらん気してきた
SQL実行ツール上でクエリ書く場合はむしろ''で囲むとバインド変数が動かなくなるから
ただstring文字列にしてクエリを変数に読み込ませる場合はいる（その場合 str += 'LIKE %' + :キーワード + '%';みたいな書き方になるけども）
でもIPAもそこまで細かく考えない気がするからあってもなくても採点に影響しなさそう

この投稿は投稿者により削除されました。(2024.10.13 20:02)

たしかに埋め込み変数だから like ％:キーワード％ にクォート要らないかも
あってもなくても◯っぽい

DB編
1
a：コの矢印（自己参照）
b：→（発送.取引先IDの外部参照）
c：追跡番号（P30、表1、項番5）
d：→
2本同じ向きで引くやり方があったか？と思ったが、←の場合、OracleやPostgresにある遅延制約で考えないと相互外部参照でインサートする際に実装のしようがない。ANSI SQLにそんな概念あったのかはわからない。
2
e：WITH RECURSIVE
再帰は実務だとデータ増幅によく使う。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000ddiw-att/2019h31h_db_pm2_qs.pdf
P15、表10で出たのの焼き直し。
f：UNION ALL
UNION ALL以下を繰り返して結果が出なくなるまで処理をする。
g：指定カテゴリ.カテゴリID＝出品.カテゴリID
h：LIKE '%:キーワード%'
シングルクォートはあったほうがよかったような気もするが、些末なことかもしれない

単純な興味なんですけどLIKE '%:キーワード%'で実際に埋め込み変数の部分一致検索できるDBMSってあるんですかね？業務で同じこと実装しようとしたときこのコードだと無理だった記憶があるんですよ
「LIKE '%' + :キーワード + '%'」「LIKE '%' || :キーワード || '%'」「LIKE CONCAT('%', :キーワード, '%')」あたりだとそういう実行結果になるのは試したことあるんですけど

私もそのままだと変数展開できない認識です！
LIKE '%:キーワード%'だと'キーワード'という固定の文字列で検索されてしまうと思います！

やっぱりLIKE '%:キーワード%'だと実際には上手くいかないですよね
ただLIKE '%' + :キーワード + '%'の方だと、文字列結合の構文はDBMSごとに違うので、正答がひとつに定まらない問題を出すのか？と思ってかなり迷いました

設問3(2)出品表:カテゴリID,商品名,商品説明
    カテゴリ表:カテゴリ名,上位カテゴリID
 
WHRER句で指定&カーディナリティ高中&データ一様分布の列が、インデックス作成による検索パフォーマンス向上が見込めるため、上の回答にしました。
商品状態列や出品状況列はカーディナリティが低なので、インデックス作成効果が薄く、作成対象列から外れると思うのですがいかがでしょうか？

補足
主キーは自動でインデックスが作成されるため回答に含めていません

この投稿は投稿者により削除されました。(2024.10.13 21:22)

この投稿は投稿者により削除されました。(2024.10.13 21:25)

CSharpのSystem.Data.OracleClientだとこんな書き方で昔突破できた・・・と思ったら、
よくよく考えたらバインド変数の値自体に％を入れないといけない（like :hogeで、hoge＝%fuga%のように）インチキ仕様なのを思い出しました。
やっぱりシングルクォートはあかんかったようで。

問1のbは多分"ー"ですね
どちらのテーブルも単一主キーの結構レアパターン

今回のレベル高いな…
WITH RECURSIVEはデータベーススペシャリストのレベルやろ

bは業務要件の記述的に「-」ですかね。間違えました。

hは「LIKE '%:キーワード%'」で通ってほしいです。。。

設問3の(1)ア,ウ,オにしたのですが違いますかね…？

結局のところ、
LIKE '%:キーワード%'  と  LIKE %:キーワード%
UNION ALL と  UNION
どっちが正解をもらえるんでしょうね。
DBボロボロですから、ちょっとでも点数欲しいなぁ。

ところでSQL文を小文字にしてしまったのですが（例えばwithとかlike）、特に大文字という指定はないしこれでもDBは動くから別に問題ないですよね？
なぜ本文に倣って大文字にしなかったんだ・・・

自己採点のため過去問見てるんだけど
今回より難しい回が無い…！

1のbは→と書きたくなるのですが、
「一つの取引は分割して発送できない」と本文にあるので、おそらく「ー」ではないでしょうか

1a ↩️     1b  ー    1c 追跡番号    1d ←
2e WITH RECURSIVE
2f UNION ALL
2g 指定カテゴリ.カテゴリID = 出品.カテゴリID
2h LIKE '%:キーワード%'
3-1  ウ、オ、キ
3-2 出品表: 出品ID、出品者ID、出品価格
3-2 カテゴリ表: カテゴリID、カテゴリ名

たまたま緑本で再帰構造の回をやって印象に残ってたのでWITH RECURSIVEいけましたが、これ書かせようとするのはひどいなあと思いました
b-treeインデックスは知らなかったのでお手上げ
平均点だいぶ低そうだし、3-1で1個や2個正解でも部分点を付けるような救済措置来ないかなと勝手に願っています

DB選ぶんじゃなかった（泣）
他に移る時間もなかったし。

埋め込み変数に""はおかしいと思って、
LIKE :キーワード
としました。これもおかしいとは思ったけど…。
cは追跡番号か…。
ここで半分取れてないと危ないんだけどなぁ。

チャットGPTに確認したところ3-1はア、ウ、オが正解みたいです

UNIONではなくUNION ALLにした人なんでそうしたんでしょう？
自分は迷った結果重複を含める根拠が見当たらないと思って咄嗟にUNIONにしたのですが

まあかなり間違えていますが自分の回答を貼ります。

設問1 : 
(a) (自己参照)
(b) -
(c) 追跡番号
(d) ←
設問2 : 
(e) WITH
(f) UNION
設問3
(1) ア, オ, キ
(2) 出品表 : 商品名, 商品説明, 出品価格
カテゴリ表 : カテゴリ名

(g) 出品.カテゴリID = 指定カテゴリ.カテゴリID
(h) SIMILAR TO :キーワード

以上が抜けたので書きますが、similar to は使用用途が違いましたね

union all にした理由は…
たまたまつい最近仕事で会社のチャットBOTに聞いたらunionは重複削除でパフォーマンスが落ちる的な回答もらってそれ思い出して書きました
いつも重複ない結果になるならunion allの方が良いかなと…
あれ、重複するのか

ちなみに、「UNION」と解答しましたが、理由は以下です。

・「UNION」か「UNION ALL」か、悩んだら「UNION」と決めていたから
・空欄の大きさ的に、1語かなと思ったから。

理由よっわww

問3（2)
出品:カテゴリID、出品価格
カテゴリ:カテゴリID
としてみましたが、どうでしょうか…？

出品:
  出品IDはpkだから除外
  出品者IDは、sqlの高速化に寄与しないから除外
  商品名、商品説明は、部分一致でindex効かないから除外
  商品状態、出品状況は、データ分布が一様分布なので5%以下に絞り込めないので除外(ここ考慮に含めるのか悩んだ)

カテゴリ:
  カテゴリIDはpkだから除外
  カテゴリ名は、sqlの高速化に寄与しないから除外

union allが正解でunionが不正解なら6割ギリいかん

UNIONって重複排除の関係でテーブルアクセス回数が増えて性能が落ちるので、実務では極力使わないようにしています。特に今回は再帰処理でループ回数分の差が出るので、UNION ALLが望ましいと思います。(最上位の上位カテゴリがNULLなので重複しない)
試験なので、UNIONも⚪︎でいいとは思います。

この問題だとUNION、UNION ALL共に同じ結果になるのでどちらも正解で良いと思ってます。
業務だと性能面的を重視するのであればUNION ALLを使うべきですが、性能面を加味するような記述もないので。

問3(2)
出品表は、カテゴリID、出品価格 になるかなと。
曖昧検索になるため、商品名、商品説明は除外になります。
カテゴリ表は、上位カテゴリID になりそうですが、問題文が「SQL文の実行性能の高速化に寄与する列名」なので主キーのカテゴリIDも含まれるでしょとか思いましたがどうなんでしょうかね。。

私もUNIONに関しては出力結果が同じなためどちらも正解だと思います

TAC  令和6年度秋期 情報処理技術者試験  応用情報技術者 講評より

これは前回だか前々回の分析関数もそうなんですが、DBスペシャリストで使ったネタは忘れた頃に使われる傾向があるように思います。

dの解答速報が、石田宏実さんと資格部で割れてますね。

多くの人が←としてるんですけど、私は→にしました。

なにか見落とした・・・？

私もdは→にしました

フォロー先ユーザーとフォロー元ユーザーの多対多の関係をフォローという中間テーブルで分解して具体的に表現しているだけだから、dは→一択じゃね
「ER図 多対多 分解」とかでググると考え方の記事が出てくる

a ↩️ b- c 追跡番号 d →
e with recursive
f union all
g 指定カテゴリ.カテゴリID = 出品.カテゴリID
h like concat('%', concat(:キーワード, '%'))
ア, ウ, オ
出品表 カテゴリID, 出品価格
カテゴリ表 上位カテゴリID

dを→にしたんですが違います？

私もdは→にしました。
スタディングの解答速報も→ですね。

私は←にしました

普通の多：多だったら⇔でいいじゃんとは思いながら日和って←を書いた...

それにしても不安になる問題が多いですね。

LIKEはRDBMSによって書き方変わるなぁと思いながら、表紙の方の演算子を見て＋が妥当かなと思って
LIKE '%' + :キーワード + '%'
にしました。

WITHもOracleやSQLServerはRECURSIVEを省略しても大丈夫なので、WITHと書いてしまいましたが、RECURSIVEつけとけばよかった。
UNION ALLはもう業務で馴染んでるのでUNIONの頭はなかったですが、ここを見ていると不安になる。。

連投すみませんが、めっちゃ細かいこというと埋め込み変数に値を渡すときに
%を前後に付けてから渡せばLIKE :キーワードで済むのにｗ

何を思ったのか、Cを｢商品の追跡番号｣と書いてしまいました…
セーフであって欲しいですがどうなんでしょう。

https://www.ap-siken.com/kakomon/27_aki/pm06.html

上記の過去問のSQLが、今回の問題そっくりでした。
このSQLに倣うと、

e：WITH RECURSIVE
f：UNION ALL

が模範解答で確定。別解に「UNION」でOKになるかというところでしょうか。

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

解答速報見る感じUNION ALLじゃないとだめそうですね

UNION がダメな理由どこにも無いと思いますが

LIKEはやっぱり変数展開必要なのか？

UNIONで部分点もらえないかな？…
その一問の差が結構でかい

別解を用意してくれるTACでもUNIONALLに別解がなかったので厳しいのかなと解釈しました

LIKE '%' AND ：キーワード AND '%'
と書いてしまった…。
部分点無いかな…。

業務でアプリケーション開発をやってる身としては、インデックスの問はサービス問題でした。
今回のように部分一致検索ではインデックスが効かないことも知っていたので。
開発業務をしない方はイメージもしにくく、難問だったかも知れませんが、個人的には業務に活かせる良問だったのではと思います。

SQL文って部分点もらえますか？
例えば、LIKE ：キーワードと書いた場合など

試しに試験内容のテーブルとデータを作ってクエリを実行してみたんですけど、UNION、UNION ALL共に結果は同じでした。
これでUNIONが間違いになるのは解せないですね。
それなら回答が1つのみの問題を作らないとダメでしょと思います。

回答が1つのみの問題を作ってしまうと
裏で合格率の調整や操作ができないでしょ

UNIONもUNION ALLも結果が同じで問題文の制約上で解答が一つに縛られるように定められていないならどちらも正解になるのが正しいあり方だと思いますよ。

過去の午後のセキュリティやネットワークの問題でも2要素認証という語が答えになる問題のとき多要素認証・多段階認証・2段階認証 と答えの語が複数ちゃんと割り当てられたりしてますから解答が複数あるという状態になるでしょう。

記述試験なんですから記述の答え方が人によって変わるなんて当然あることなんですし答えをどっちにも合わして採点しないと資格試験として物議を醸すレベルで問題になってしまうと思います。

自身もUNIONと答えたから、願望も含まれますが、大丈夫だと思いますよ。

実際にUNIONとUNION ALL両方OKだった過去問があります。

https://www.ap-siken.com/kakomon/31_haru/pm06.html

結果が変わらないと山田さんも実証してくださいましたし、通ると思ってます。

自分の動作環境ではLIKE ＊ : キーワード ＊で同じ動きするんですが、部分点の見込み0ですかね。これ合ってたら60点なるんですよね。知らんけど。

まあこの試験のSQLは標準SQL準拠の前提だからね…その仕様で構文エラーになるようなSQLだとたぶんダメなんじゃないだろうか。知らんけど。

いつもの癖でDを書く際に、真ん中に横点を付けてしまいました。
不正解、もしくは減点等あり得ますでしょうか...。

いつもZに斜線入れるような感じなので、そのあたりは特にないんじゃないですかね。

GinSanaさん
ご回答いただきありがとうございます
安心しました...！

Itecは「LIKE ％:キーワード％」だった
ほんと悪問やね

私は1~3の候補が浮かびましたが、3にしました。
この問題に関してはめちゃくちゃ考えて回答を出したので、不正解でも悔いはないです。

1. LIKE ％:キーワード％
シングルクォートで囲ってないから文字列として認識されずエラーが出るのから違うか。

2. LIKE '％:キーワード％'
いや、シングルクォートで囲ってるから:キーワードがそのままの文字として認識されないか？

3. LIKE CONCAT('%', CONCAT(:キーワード, '%'))
mysqlでだけど動いた実績あるからこれにしよ。ただ応用情報でCONCAT出たこと無さそうだけど知らね。

SQLServerに慣れ親しみすぎてLIKE '%' + :キーワード + '%'と書いてしまいましたが、文字列結合の標準はOracleなどで使われている||でTACの答えは正確に思いますね...

問題冊子の最初の方の疑似言語の演算子見て、プラスで間違いないとか思ってましたが、あれはプログラミング用で、SQLは標準があるのでそれを使わないとキツそうですね。
どんな環境でも動作するという考えで採点されると、他のところもRECURSIVE省略不可、とかUNION ALLじゃなきゃダメとなってしまいそう...