令和7年秋期試験 午後Ⅱ問1についての投稿を受け付けるスレッドです。

お疲れさまでした
設問3から一気にわからなくなって、実力不足を痛感しました
帰宅してから復習します

お疲れ様でした。
記述記述&記述でしたね。解答用紙が机上に置かれたとき絶望感すごかったです。
問2もいっぱい書かされたっぽいですし、最後の紙の試験ですしいっぱい書かせてやろうってことですかね(笑)

PayPayでこんな障害が起こるはずがないっっ

お疲れ様でした。
やっぱ物理選択者ってあんまいないんですかね。。？
個人的には物理設計大好きマン！(反対に概念設計は複雑になりすぎると頭パンクする。。)なので午後2は迷わず問1選んでます。

ちなみに午後1はR5のように概念・論理設計が問1と問2の2問出てましたね。
自分は問2選択しましたが、結構早めに解き終われたのでよかったです。
※問1はみるからに。。って感じだったので速攻避けました。

午後2の問1ですが、今回結構アタリだったかなって思ってますが皆さんどうでしょう？
業務内容や実装方式の流れも解きながらイメージついて、トランザクション分離レベルについても結構対策はしてたので、個人的には手応えアリでした。
的外れなこと書いてなきゃ良いですが。。

全然わからないのとこんな単純な回答でいいの？と思う問題に二分された気がしましたね～
とりあえず埋めたけど的はずれだと思うので多分ダメそうです。根拠が足りなすぎて参りました

私は物理が馴染むので問1選びましたが書込数みても圧倒的に論理人気なんですね！汗

初めての受験だったので難易度の具合は分かりませんが、午後の試験は時間が足りなくなりがちですね🥲

問題用紙に答えを転記できなかったので自己採点は記憶を元にとなりそうで、しばらくもやもやしそうな予感です…

お絵かきが苦手な私は迷わず1に飛びつきました
MERGE INTOやらMATCHEDやらのSQLでダメかも！となりましたがそこそこ上手くいったように感じます

みなさんメッセージとか業務上の不都合わかりましたか？

私はメッセージはロールバック実行指示で、業務上の不都合は決済時にポイントを使用しての決済ができなくなる、といった内容だったと思います。

この投稿は投稿者により削除されました。(2025.10.17 03:09)

>業務上の不都合
ポイント消費不要の決済まで止まる
という旨で回答しました！

2.(2)はどうされたしたか？以下にしたのですが、同じでしょうか、、
eロールバック実行指示
fコミット準備指示
gトランザクションを終了

ご参考まで、自分の復元回答を載せておきます。
※ ちょいちょい自身ないです。。。

■午後2 問1
--------------------------------------------------

●設問1
(1) a：SUM(獲得ポイント数)
    b：残高反映F IS FALSE
    c：残数 = 残数 + 加算ポイント数
    d：B.ポイント会員#, B.有効期限年月, 加算ポイント数
(2) (a) 参照したデータを後続で使用することがないから。
    (b) 有効行の参照後、別処理で有効範囲の行挿入時に不正となるから。
        ※ 言いたいこと上手く纏められず無理やり詰めた感じになっています。。。

●設問2
(1) (a) ⑬
    (b) ロールバック実行指示
    (c) 決済DBのトランザクションが時点Aではコミットされていないが時点Bではコミットされている。
(2) (a) e：コミット実行指示
        f：ロールバック実行指示
        g：トランザクションを終了
    (b) 決済処理が完了しないため、ユーザを待たせてしまう。
    (c) 決済した情報は登録されるが、使用されたポイント情報は未反映となる。

●設問3
(1) (a) テーブル名：決済残高
        列名：処理済F
        処理概要：処理済FがFALSEならTRUEに更新し、TRUEであれば処理を完了させる。
        ※ 自身なし。。。
    (b) 先頭：更新中FがTRUEの場合はリトライを実施し、FALSEの場合はTRUEに更新した上で後続のステップを処理する。
        末尾：更新中FをFALSEに更新する。
(2) (a) h："決済残高"から該当の決済会員#の残高に決済金額を加算する。
        i："決済履歴"からホスト変数hv1～hv6に該当する行を削除する。
    (b) j：【P】ポイント会員#, 【P】有効期限年月
          ※ 【P】は主キーを表しています。
(3) 事例：7
    内容："ポイント残高"に使用ポイント情報は反映されていないが、ポイント使用履歴データが存在する。

>ryuさん

言葉遣いは少々違いますが、言いたい事は概ね一緒でした。なんか手応えなくてちょっと自信なかったのですが、安心しました。

設問3(2)(b)は自分も最初そうしてたのですが、「同じ有効期限年月でも、何回かに分けて使われることあるじゃん」って気づいて、代理キーとして履歴#を主キーにして、その2つは外部キーにしました。

>ryuさん
ありがとうございます！
私もほとんど同じです。
設問3(1)aは私は以下のように回答しました。
 テーブル名：決済履歴
 追加列名 ：決済指示#
 処理概要 ：決済履歴に処理対象の決済指示#のデータが存在しない場合、後続のステップを継続
自信がある訳では無いですが…。


ちなみに知見あれば教えていただきたいのですが、
クエリの穴埋め問題について下記のように私は回答しました。

設問1(1)c：
A.残数 = A.残数 + B.加算ポイント数
※その他の問題も同様

上記とした場合も○は貰えるのもなのでしょうか。。

>ryuさん
>お疲れさん
回答ありがとうございます🙇
お疲れさんの箇所は、私もお疲れさんと同じ内容で回答しました。


最後の問は、逆のこと書いて書きました。
ポイント利用履歴の方が無いとを回答しました。

自分も論理設計は文章量的に無理！と思ってたのですが、論理のほうが人気なんですね。。

>No.15 おさかなさん
うわ、ほんとですね。
同じ有効期限年月が繰り返されるので、確かにそれを主キーにはできませんね。。。
最後時間なくて焦った結果、浅はかでした笑
ご指摘ありがとうございます。

> No.16 お疲れさん
はい、問題ないと思われます。
カラムがどのテーブルのものか特定できる場合はテーブル名（別名を定義している場合はエイリアス）をつけなくても良いのですが（自分の回答がそれです）、つけたとしてもSQLは問題なく実行できますので、今回の場合どちらでも問題ないかと思いますね。

同じくお絵書き苦手で加えて長文読むも遅いし、午後午後2は問1を選びました。全問答えを埋めましたが、自信がなかったです。みなさんの内容を見って少し安心しました。
設問3(1)(a)が一番難しいと思います。決済指示#+状態が正しそう．．．後設問3(b)は【P】履歴#、ポイント会員#、有効期限年月、消込日にしました

設問3(2)(i)で、もし同じ人・同じ店・同じ日に同じ使用ポイント数でポイント使うことが2回あって、2回目が途中でエラーになったら、ホスト変数の値だけで削除行を特定すると履歴テーブルから1回目の履歴も消えちゃう？とか考えちゃったんですけど考えすぎですかね......

"ポイント使用履歴"の当該会員のデータの中で履歴#が最大の行を削除する みたいに書きました
でも履歴#は連番とは明記されていなくて最大の履歴#が最新レコードなのか保証できないかもです、わからない

お疲れ様でした！
皆様の解答とほぼ同じで安心しました・・

お疲れ様でした！
概念が苦手すぎて午後1も2もガッツリお絵描きから逃げたんですが、あっちの阿鼻叫喚を見ると運が良かったのかもしれませんね……

こっちを盛り上げたい&色々自信ないので、私も復元回答を共有させてください（フォーマットお借りします）
ツッコミ諸々大歓迎です〜

■午後2 問1
--------------------------------------------------

●設問1
(1) a：SUM(獲得ポイント数)
    b：残高反映F IS FALSE
    c：残数 = 残数 + 加算ポイント数
    d：B.ポイント会員#, B.有効期限年月, 加算ポイント数
(2) (a) 同じ決済会員が同時に複数の支払いを行うことはないから。
※ 設問の決済サービスの概要からほぼそのまま引用
    (b) 使用可能ポイントを超えたポイントが使用され得るため。
※ 自信なし。REPEATABLE READじゃダメだからファントムリードの問題？と思ったが、ポイント残高にINSERTしていないので腑に落ちない。REPEATABLE READじゃ共有ロックをかける→利用可否判断は同時に走ってしまうから合ってる、かなあ……？

●設問2
(1) (a) ⑨
    (b) ロールバック実行指示
    (c) 時点Aではメモリ上で処理しており、まだ実DBに反映していないが、時点Bでは反映している。
※ 自信なし。
(2) (a) e：コミット実行指示
        f：ロールバック実行指示
        g：トランザクションを終了
    (b) 決済残高テーブルがロックされ、入金などの決済サービスが使えない。
    (c) 決済サービスの残高のみ消費され、ポイントサービスのポイントは未消費の状態。

●設問3
(1) (a) テーブル名：決済残高
        列名：決済指示#
        処理概要：決済履歴に、決済指示#が一致する列があるかチェックし、あれば終了する。
    (b) 先頭：更新中FがTRUEの場合はトランザクションを終了し、FALSEの場合はTRUEに更新する。
※ 自信なし。冷静に考えたら終了せずに待ってリトライする気がしてきた……
        末尾：更新中FをFALSEに更新する。
(2) (a) h：決済会員の決済残高から、減算した決済金額を加算する。
        i：ホスト変数から追加した行を特定し、削除する。
※ 当たり前すぎて見落としがないか不安になる。
    (b) j：【P】ポイント会員#, 【P】有効期限年月, 【P】決済指示#
※ 【P】は主キー。前者2つだけだと複数回の消し込みに対応できない+どの決済指示で行われたのかを同定できない気がしたので。
(3) 事例：7
    内容：P3-1が取消できず、ポイント残高は消込されているのに、ポイント使用履歴がない状態になる。

>Milkyさん
回答ありがとうございます🙇
3(2)ですが、【P】ポイント会員#, 【P】有効期限年月, 【P】履歴#(ポイント使用と同じにすることを想定)としました。考えとしては、同じでしょうか？

皆様お疲れ様です。結構とんちんかんな解答をしていますが、解答再現載せておきます！
該当なんて言葉使っていなかった気もするものの、とりあえずこんなもので……

問1
(1)
a:SUM(獲得ポイント数)
b:残高反映F IS FALSE
c:残数=残数+加算ポイント数
d::hv1, B.有効期限年月, 加算ポイント数
(2)
(a)同決済会員が同時に複数の入金や決済処理は行わないから
(b)P3-2処理中にP2に追加された行を読み込んでしまうから

問2
(1)
(a)⑬
(b)ロールバック
(c)時点Aではテーブルが更新されていないが、時点Bでは更新されている
(2)
e:コミット実行指示
f:ロールバック実行指示
g:トランザクションを終了
(b)ポイントを使用した決済が出来なくなる
(c)決済履歴テーブルの使用ポイント数に相当するポイント使用履歴が存在しない状態

問3
(1)
(a)テーブル名：決済残高 列名：最終決済日時
処理概要：連携される決済指示日時と最終決済日時が相違している場合のみ、次ステップに進む
(b)
先頭：該当取引の更新中FがFALSEであればTRUEにする。TRUEであれば一定時間後に再実行する。
末尾：更新中FをFALSEにする
(2)
(a)
h:決済指示テーブルの決済金額を、該当決済会員の残高に加算する
i:該当取引の決済履歴の行を削除する
j:履歴（主）、ポイント会員#(外)、有効期限年月
(3)
事例：事例6
不整合内容：P3-2が複数回実行されることにより使用可能ポイント数が使用ポイント数を下回るという不整合。

1(2)a:「決済会員について、頭のupdateで専有ロックをかけれるため」としたのですが、同じ方いますでしょうか🙇

>こうきさん
【P】履歴# について、ポイントとかの履歴#は設問見た感じサロゲートキーの位置付けだと思うので、それを使うなら以下のようになる気がします。

【P】履歴#, 【F】ポイント会員#, 有効期限年月, 【F】決済指示#
（決済指示#は決済指示との関連付けがないと補償トランザクションがないため必須？）

ポイントDBは外部キーは定義できないと記載されていたので、外部キーを表す点線は入れなかったのですが、どうなんでしょうか？

> No.28 ジョンさん
そうでした。ToBeでのポイントDBについてはNoSQL仕様のDBを使用するということで外部キーが定義できないと文章中にありましたね。
試験中ちゃんとマークしてたのに今読み返して気づいた。。。
ですので、ポイントDBに作成するポイント消込履歴テーブルには外部キーの定義ができないですね。
また、ちょっとメタ読みですが設問文にも着目すると
とあります。この時、解答に外部キーも含まれる場合は主キーと同様に外部キーについても記載があるのがこれまでのセオリーでした。
それも踏まえると外部キーの使用はなさそうな気がしてきましたね。。

改めて設問3(2)(b)ですが、ここでやりたいことはステップP3-2で実施した消込処理を元に戻せればよいわけですね。
ポイント残高からどの会員#のどの有効期限年月のポイント残数をいくら消し込んだか、を記録できればよさそうです。
下記のスレッドで、
>No.19
同一会員に対し有効期限年月が複数繰り返されると記載していましたが、ポイント残高の主キーはポイント会員#と有効期限年月で、その単位にP3-2のUPDATE（ポイント消込処理）が繰り返されますので、同一会員で、同一の有効期限年月が複数回処理されるということもなさそうです。

もう少し実装の解像度を高くすると、このポイント消込履歴テーブルはP3-2での消込処理時のみで生きていればよいわけで、無事消込処理が完了したら処理最後に初期化（処理対象のポイント会員#をキーにしてDELETE）してあげれば、主キーの重複になることもなさそうです。

結果として、自分が回答として記載していました設問3(2)(b)の空欄jについては
が濃厚な気がしてきましたね。これで事足りそうな気がします。
そうだといいな。。

設問2(2)(a)5か9か13で迷って、結局9にしましたが同志いませんか？
「コミット準備指示」というのがどういう指示をしてどういうメカニズムで可否を出すのかは問題文に明記がなかったですが、コミット準備ができてしまえば処理は無事できていると判断できると思ったので9にしましたが何か見落としてますかね…。これについて皆さんの考えを伺えれば幸いです。

今見返したらポイントDBって複数ノードに分散可能なNoSQLなんですね…
それならラストの記述はBACE特性を踏まえて「トランザクションの内容が各ノードに反映されるまでデータがノード間で一致しない」とか答えるべきだったのかなとか今更ながら思ったり…

設問1の(1)bって、残高反映F = FALSEでも良いのでしょうか？

TACで自己採点してみました…。

厳しめ: 51点
甘め: 68点

これ受かりますかね…問1の方が問2よりも簡単だったっぽいことを考えると上振れの得点調整は期待できないか…。
皆さんどうでしたか？

58〜68点くらいです。

設問3(2)bの属性は結局どれが正解なんだろうか...
TACとITECで違うし。

こう言う属性系って部分点出るんかな...