rink_rewさんの助け合いフォーラム投稿一覧
「LED」は、辞書で引こうとすると
「LE」よりは後ろになる。
※広辞苑でいえば、「愛(あい)」よりも「間(あいだ)」の方が後ろになるイメージ。同じ理論で「LAN」は「LE」よりは前になる。
※広辞苑でいうところの、「間(あいだ)」が「赤(あか)」より前になるイメージ。「HI～」については、「LE」よりも前。
※そもそも頭文字が「L」より前な「H」なので、
辞書で引いたら圧倒的に早く出てくるといった具合。
そうですね。その理解で良いと思います。
この問題自体は運営さんが既に修正してくれたみたいですが、PostgreSQLの公式マニュアルでも「SELECT FOR UPDATE が〜〜」や「SELECT FOR SHARE を〜〜」といった表現がバンバン使われてはいるので、実際の試験では迷わない設問が出ることを祈りたいですね。
https://www.postgresql.jp/document/14/html/explicit-locking.html#LOCKING-ROWS
その選択肢で言いたい話は、こういうことですよね？
列定義のサイズ（長さ）を指しているので、「列のサイズ」のほうがしっくりくるかなと思いました。
逆に「データのサイズ」だと、実際に格納されているデータのサイズを指しているように感じられました。
SQL> desc tbl_a
名前 NULL? 型
----------------------------------------- -------- ----------------------------
ID NUMBER
NAME VARCHAR2(10)
SQL> desc tbl_b
名前 NULL? 型
----------------------------------------- -------- ----------------------------
ID NUMBER
NAME VARCHAR2(20) <--- サイズが異なる
SQL> select * from tbl_a;
ID NAME
---------- ----------
1 AAA
2 BBB
SQL> select * from tbl_b;
ID NAME
---------- --------------------
1 AAA
3 CCC
SQL> select id, name from tbl_a
2 union
3 select id, name from tbl_b;
ID NAME
---------- --------------------
1 AAA
2 BBB
3 CCC <--- 正常に実行できる
SQL>
私も問題文を読んで一瞬「ん？」と思いましたが、
「MANAGER_ID列がNULLの人」 = 「上司という立場の人」
という意味だと認識していました。
なので、「MANAGER_ID列がNULLである部署3の上司について」という文言でも変だと感じなかったのですが、言われてみれば、junext25さんのおっしゃってるようにもとらえられるなとも思いました。
「MANAGER_ID列がNULLのデータを除外する」という目的で「e.manager_id IS NOT NULL」が使われているということは言えるかなと思います。
確かにON句においてフィルタリングの条件的なものを書くことは可能ですが、それも結局は「結合条件」ではと思います。ON句に指定する条件は結合処理時における結合条件、WHERE句は結合結果に対する絞り込み条件を指定するというのが基本ですし。
黒本を書籍を見ても、ON句には結合の条件を指定する例しか記載はなく、Oracle Master SilverSQLとしてはこの理解で良いように思います。
RRのかわりにRRRRが、YYのかわりにYYYYが適用されて試行されるとのことなので、どちらも2桁も4桁も対応していると言って良いのではと思います。
実試験的には、この点の知識で迷わせるような問題が出ないことを祈りたいですね。
確かに実機で試してみると、記載されている create view 文で作成したビューに insert ができますね。
少し調べてみたのですが、AIさんによると、以下のような回答があり、内部的な最適化により実行できてしまうこともあるようです。
これは Oracle の内部的なビュー最適化メカニズムによるものです。
SELECT DISTINCT col1 FROM test1 GROUP BY col1;
この場合、Oracleのクエリオプティマイザが 「DISTINCT と GROUP BY が冗長」 であることを認識し、内部的にクエリを最適化します。
ただ、公式ドキュメント上は、本設問の解説文のように、DISTINCTやGROUP BY等が含むSELECTが使用されている場合には、行の挿入、更新、削除はできないと記載されていました。
黒本でも、やはり「ビュー定義のSELECT文に以下が含まれる場合、ビューへDMLを実行することはできない」と記載されており、その中に、DISTINCTやGROUP BYが列挙されていました。
実際に実行できる挙動が見られたので気になってしまうとは思いますが、実際のSilver SQL試験向けの知識としては、列挙されているような要素を含む場合には「DMLが実行できない」と覚えて差し支えはないかなと思います。
よく知られているテキスト（オラクルマスター教科書、黒本等）でも「表のデータを変更するSQL文をDMLと呼ぶ」と記載されてたりするんですよね。
でもおっしゃる通り、SELECTは「照会」ですので、データを変更するわけでは無いですよね。
実際に試してみましたが、あるユーザーが作成したプライベートシノニムを使用して、他のユーザーから対象の表にアクセスすることはできないようです。
SQL> GRANT CREATE SYNONYM TO User1;
権限付与が成功しました。
SQL> CONN user1/user1
接続されました。
SQL> SELECT * FROM TestTable01;
ID NAME
---------- --------------------------------------------------
1 AAA
SQL> CREATE SYNONYM Pri_tbl01A FOR TestTable01; <- User1がプライベートシノニム「Pri_tbl01A」を作成
シノニムが作成されました。
SQL> SELECT * FROM Pri_tbl01A;
ID NAME
---------- --------------------------------------------------
1 AAA
SQL> GRANT SELECT ON TestTable01 TO User2;
権限付与が成功しました。
SQL> CONN user2/user2
接続されました。
SQL> SELECT * FROM user1.TestTable01; <-User2が、User1のTestTable01への参照権限を持っていることを確認
ID NAME
---------- --------------------------------------------------
1 AAA
SQL> SELECT * from Pri_tbl01A; <-User1が作成したプライベートシノニム「Pri_tbl01A」でアクセスできない
SELECT * from Pri_tbl01A
*
行1でエラーが発生しました。:
ORA-00942: 表またはビューが存在しません。
SQL> conn sys/sys as sysdba
接続されました。
SQL> CREATE PUBLIC SYNONYM Pub_tbl01A FOR User1.TestTable01; <-管理者でパブリックシノニム「Pub_tbl01A」を作成
シノニムが作成されました。
SQL> CONN user2/user2
接続されました。
SQL> SELECT * FROM Pub_tbl01A; <- 管理者が作成したパブリックシノニム「Pub_tbl01A」を使用して、User2は、User1のTestTable01にアクセスできる
ID NAME
---------- --------------------------------------------------
1 AAA
SQL>
追記で問題には「なお、ユーザーAにはCREATE SYNONYM権限が付与されています。」と記載されていますが、publicシノニムを作成するにはCREATE PUBLIC SYNONYM権限が必要ではないんでしょうか？
本設問では、データベース管理者がパブリックシノニムを作成する選択肢が正当ですので、ユーザーAが CREATE PUBLIC SYNONYM権限を持っていなくても影響はありません。
外部キー制約で参照されている列の値の更新や行の削除については、ご認識の通りだと思いますが、「表自体の削除」は依存する行の有無に関わらずできないようです。
SQL> CREATE TABLE tbl_parent (
2 deptno NUMBER(4) PRIMARY KEY,
3 name VARCHAR2(10)
4 );
表が作成されました。
SQL> CREATE TABLE tbl_child(
2 empno NUMBER(4) PRIMARY KEY,
3 name VARCHAR2(10),
4 deptno NUMBER REFERENCES tbl_parent(deptno)
5 );
表が作成されました。
SQL> DROP TABLE tbl_parent;
DROP TABLE tbl_parent
*
行1でエラーが発生しました。:
ORA-02449: 表の一意キーまたは主キーが外部キーに参照されています。
SQL>
この問題の「参考」にも以下の記載があります。
FOREIGN KEY制約の親表として指定された表は、参照されている行がない場合でも削除できなくなります。親表を削除したい場合は、FOREIGN KEY制約を定義した表を削除してから親表を削除します。
そうですね。私も同じ認識で、索引や制約など種類が違えば同じ名称が使えると思います。
↓みたいな話ですよね。
SQL> CREATE TABLE test_obj (
2 id NUMBER PRIMARY KEY,
3 name VARCHAR2(50)
4 );
表が作成されました。
SQL> CREATE TABLE test_obj (
2 id NUMBER
3 );
CREATE TABLE test_obj (
*
行1でエラーが発生しました。:
ORA-00955: すでに使用されているオブジェクト名です。
-> 同じ名称の表は作成できない。
SQL> CREATE VIEW test_obj AS
2 SELECT * FROM dual;
SELECT * FROM dual
*
行2でエラーが発生しました。:
ORA-00955: すでに使用されているオブジェクト名です。
-> ビューもダメ
SQL> CREATE INDEX test_obj ON test_obj(name);
索引が作成されました。
SQL> SELECT OBJECT_NAME, OBJECT_TYPE
2 FROM USER_OBJECTS
3 WHERE OBJECT_NAME = 'TEST_OBJ';
OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_TYPE
-----------------------
TEST_OBJ
TABLE
TEST_OBJ
INDEX
SQL>
-> すでに存在する表「test_obj」と同じ名称の索引が作成できる
INDEXオブジェクト権限もALTERオブジェクト権限もあると思います。
SQL言語リファレンス
https://docs.oracle.com/cd/F19136_01/sqlrf/GRANT.html#GUID-20B4E2C0-A7F8-4BC8-A5E8-BE61BDC41AC3__BGBCIIEG
以下の理解で合っているでしょうか？
「自動セグメント領域管理（ASSM）」は、セグメント内の空き領域をビットマップで管理する方式です。
一方、「ローカル管理表領域（LMT）」もビットマップを使用しますが、これはエクステントの割り当て情報の管理に使われるものであり、セグメント内の空き領域の管理方法とは異なります。
そうですね。その理解で良いと思います。
- 自動セグメント領域管理
-> セグメントの領域管理 - 表領域のローカル管理
-> エクステントの割り当て情報管理
この問題の「参考」や問題ID:29633の「参考」にも記載の通り、リスナーが必要です。
公式マニュアルの以下も参考になるかもしれません。
https://docs.oracle.com/cd/F19136_01/admqs/getting-started-with-database-administration.html#GUID-EB851101-07BE-4038-BB9D-06E01CC7F5D5
次のコマンドを使用して、ポートがリスナーに登録されていることを確認します。
$ lsnrctl status | grep -i 5502 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=hostname.example.com)(PORT=5502) )(Security=(my_wallet_directory=/$ORACLE_BASE/admin/sid/xdb_wallet)) (Presentation=HTTP)(Session=RAW))
データベースの起動・停止やデータベースのバックアップ・リカバリができるのは、Enterprise Manager Cloud Control ではないですか？
(もしくは、EM Expressの前身的な、昔のEnterprise Manager Database Control でも出来たような気がします。)
EM Expressでは、Flash版でもOracle JET版でもこれらの操作は行えないと思います。
列別名を二重引用符(")で囲んだ場合は、ORDER BY句でも同様に列別名を二重引用符(")で囲む必要があります。
解説にあるこの文章は、「（ネーミング規則に反する）列別名を二重引用符(")で囲んだ場合は、」ということを意味しているのだと思います。
つまり、正答の選択肢の一つである「SELECT employee_name "社員名" FROM employees ORDER BY 社員名;」については、
- 「社員名」は漢字を使用しているだけなのでそもそも(")で囲まなくても良い
- そもそも(")で囲まなくても良いものについては、ORDER BY句で(")で囲まずに使用できる
- だから、列別名では「"社員名"」と(")で囲まれていてORDER BY句では「社員名」と(")で囲まれていないが、正常に実行できる
ということだと思います。
受験したのは結構昔なので記憶がかなり曖昧ですが、問題文に「日付の表示形式は○○-⬜︎⬜︎-△△です。」的な文章見かけたことはあった気はしますが、一方で、問題文にその情報が明記されてなくて「どれが月でどれが日だよ...」と迷ったような問題があったような記憶もあります。
あまり参考にならなくてすみません...。
私も気になってちょっと調べてみたのですが、実際に付与しようとすると、付与自体は成功するようです。
SQL> CREATE OR REPLACE VIEW emp_view AS
2 SELECT employee_id, employee_name, department_id
3 FROM employees;
ビューが作成されました。
SQL> GRANT REFERENCES ON emp_view TO testuser01;
権限付与が成功しました。
SQL>
手持ちのオラクルマスター教科書（黒本）見てみたのですが、Silver DBAのテキストとSilver SQLのテキストで、記載が異なってました。
※Silver SQLの方は「主なオブジェクト権限」の一覧に、「ビュー」のオブジェクト権限として「REFERENCES」の記載があるが、Silver DBAの方は記載がない。
公式マニュアルみると、「表18-2 オブジェクト権限(操作対象のデータベース・オブジェクト別)」にビュー権限として「REFERENCES」入っていて、付与できそうに見える。
https://docs.oracle.com/cd/F19136_01/sqlrf/GRANT.html
実試験でこういう問題が出題されると、回答に困りますね...。
2は、USINGの結合列としてdepartment_idが指定されていて、結合列に別名がついている（SELECT d.department_id ~~~~の d.department_id の部分）という話ですかね。
日本語の問題とも言えるかもしれませんが、解説の「USING句を指定した結合では、結合列に表接頭辞を使用できません。」はどちらのケースも説明できている、と言えないこともないかなと思いました。
SQL> SELECT d.department_id, e.employee_name FROM departments d JOIN employees e USING(department_id);
SELECT d.department_id, e.employee_name FROM departments d JOIN employees e USING(department_id)
*
行1でエラーが発生しました。:
ORA-25154: USING句の列の部分には修飾子を持てません。
SQL> SELECT department_id, e.employee_name FROM departments d JOIN employees e USING(department_id);
DEPARTMENT_ID EMPLOYEE_NAME
------------- ------------------------------
1 山田二郎
2 佐藤昭夫
3 山口洋子
4 田中浩介
5 加藤昭彦
1 佐々木明子
1 菊池浩二
1 中山大輔
2 星野健一
3 斎藤京子
4 吉田亜希
DEPARTMENT_ID EMPLOYEE_NAME
------------- ------------------------------
5 阿部伊吹
1 米村真司
2 伊藤佳奈
3 橋本淳
4 井上悦子
5 渡辺和也
1 塚本孝
1 野口圭子
1 内田雄介
1 高田明
1 坂本真
22行が選択されました。
SQL>
実際の試験でどのように出題される可能性があるかまではわかりませんが、解説のとおり「current_time」は「トランザクションの開始時刻」の方が正確な説明ですよね。
ちなみに、「時刻」なのか「日時」なのか、「日時」には「時刻」も含まれるではないか、という点については、こういう試験では「より適切な選択肢」が正当となることが多い気がするので、問題文が「現在の時刻を取得する」なので、「current_timestamp」と「current_time」が選択肢にあって正答を一つ選ぶ問題であれば「current_time」の方が正答になると考えておいた方が無難かなとは思います。
この辺は過去にもフォーラムで議論があったみたいです。
https://mondai.ping-t.com/g/posts/1444
一応空白は入ってるように見えますが、解説に載っている出力結果のキャプチャの通り、本来はもっと空白が長い（月の単語の中で一番長いSeptemberに合わせているらしい）はずではありますね。
ただ、FMをつけた場合は、空白が全くなくなり、月の単語とカンマが隣接するので、正当の選択肢にFMがないこと自体は正しいと言える思います。
SQL> SELECT TO_CHAR(SYSDATE, 'Ddspth "of" Month, YYYY') FROM dual;
TO_CHAR(SYSDATE,'DDSPTH"OF"MONTH,YYYY')
------------------------------------------------------------
Twenty-Third of March , 2025
SQL> SELECT TO_CHAR(SYSDATE, 'Ddspth "of" FMMonth, YYYY') FROM dual;
TO_CHAR(SYSDATE,'DDSPTH"OF"FMMONTH,YYYY')
------------------------------------------------------------
Twenty-Third of March, 2025
SQL>
「現在、コミットしていないトランザクションがない」は、その後に示されているDELETE文が、トランザクションの途中で実行される訳ではないという前提を示しているだけです。SQL Plusなどで新規に接続した直後をイメージすると良いと思います。
その上で、解説にもある通りDELETE文はDMLであり、DELETE文の実行で新しいトランザクションが開始され、コミットされるまではROLLBACKが可能です。