今回は、SQLが投入されてから結果が返されるまでの内部ステップと、効率的な実行処理を行うための「クエリ最適化（Query Optimization）」の流れを整理した。

1. SQL処理の5つのステップ

一般的なRDBMSにおいて、SQL文は主に以下の5つの段階を経て実行される。

• ① Parsing（構文解析）
  送られてきたSQLの文法的な正しさ（シンタックスチェック）を解釈・検証する。
  SQL実行後の最初のプロセスとして、Parser（構文解析器）がSQLのロジカルな構造を関係演算を表す「Query Tree（クエリツリー）」へ変換する。
• ② Query Validation（クエリ検証・意味解析）
  SQL内に指定されたテーブルや列（カラム）がデータベース上に実際に存在するか、アクセス権限があるかなどの「意味的妥当性」を検証する。
• ③ Optimization（最適化 / クエリ最適化）
  関係演算を表す Query Tree を、実際のアクセス手順である「物理的な実行プラン（Execution Plan）」へ変換する。
  通常、データ取得の手順には複数のバリエーション（多くのプラン）が存在するため、その中で最も効率が良い（低コストな）実行プランを選択する。
• ④ Plan Compile（プランコンパイル）
  クエリオプティマイザ（Query Optimizer）によって選択された最適な計画を、実行エンジンが直接処理できるマシンコードや内部コマンド形式へコンパイル・変換する。
• ⑤ Execution（実行）
  Query 実行エンジン（Execution Engine）が物理プランに従ってストレージやキャッシュメモリからデータを読み書きし、最終的な結果をクライアントへ返す。

2. クエリ最適化（Query Optimization）の役割

SQLの処理工程の中で、パフォーマンスを決定づける最も重要なコンポーネントが「クエリオプティマイザ（Query Optimizer）」である。

3. まとめ

SQLは「データ取得の結果」を指示するだけで、裏側ではParser（構文解析器）による Query Tree の生成と、Query Optimizer（最適化エンジン）による物理実行プランの決定という高度な処理が自動的に行われている。

SQLパフォーマンスチューニングにおいては、オプティマイザが意図通りの最適な実行プランを選択できるよう、「最新の統計情報（Statistics）の維持」や「適切なインデックス設計」を行うことが重要となる。

CAP定理とは、「分散システムにおいて『一貫性』『可用性』『分断耐性』の3つの性質を、同時にすべて（3つとも）満たすことはできない」というトレードオフの定理を指す。

1. CAP定理の3つの構成要素

分散システムが備えるべき3つの評価軸の定義は以下の通りである。

• C：Consistency（一貫性）
  システムにあるオペレーションを行った後、どのノード（サーバー）にアクセスしても常に最新で同じデータ（一貫性）が保たれている性質。
  分散システムで一貫性を担保するためには、あるノードでデータ更新（Update）が発生した場合、他のすべてのノードにもその結果を即座に同期・反映しなければならない。
• A：Availability（可用性）
  システムを構成するノードの一部が故障（ダウン）しても、システム全体としてはレスポンスを返し続け、正常に稼働し続けなければならない性質。
  エラーを返さず、常にすべての正常なノードが読み書きの要求に応答できることが求められる。
• P：Partition Tolerance（分断耐性）
  ノード間を結ぶネットワークが障害等で分断され、通信が一時的に不通・切断されても、システムとしては停止せずに稼働し続けなければならない性質。

2. なぜ3つ同時に満たせないのか？

ネットワーク分断（P）が発生した状況を想像してみよう。ノードAとノードBの間で通信ができない状態である。

このとき、ノードAに書き込みリクエストが届いた場合、選択肢は2つしかない。

• 選択肢①：一貫性（C）を優先する ➔ ノードBへデータ更新を同期できないため、エラーを返して書き込みを拒否する。（可用性 A が犠牲になる）
• 選択肢②：可用性（A）を優先する ➔ ノードAだけで書き込みを完了させ、応答を返す。しかしノードBのデータは古いままになる。（一貫性 C が犠牲になる）

このように、現実の分散環境において「分断（P）」の発生を完全に回避することは不可能なため、実質的に分散システムは「CP型」か「AP型」のどちらかを選択（トレードオフ）せざるを得ないのである。

3. NoSQLにおけるCAPによる分類

近代のNoSQLデータベースは、この3つのうち「どれを重視し、どれを妥協するか」という設計思想（トレードオフ）によって、大きく3つのタイプに分類することができる。

4. まとめ

「すべての面で完璧なデータベース」は存在しない。システム要件に応じて、「一貫性（C）」を絶対に譲れないのか、あるいは「高可用性（A）」を取って一時的な不整合（Eventual Consistency：結果的一貫性）を許容するのかを見極めることが、適切なDB選定の第一歩となる。

今回は、Tomcat のセットアップから Struts 1.1 サンプルアプリケーション（struts-blank）の稼働確認までを整理した。

1. 現代環境（Mac OS 15.7.7 + Java 21）における Tomcat の準備

Struts 1.1 は 2003 年頃の製品であり、当時の Servlet API 仕様（2.3）に深く依存している。最新の Tomcat 11 などでは動作しない可能性が高いため、今回は安定して動作確認が可能な Apache Tomcat 9.0系 を採用する。

• Step 1: Tomcat のダウンロードと展開
  公式サイトより apache-tomcat-9.0.120.zip を取得し、ターミナルから unzip で展開・配置する。
• Step 2: JAVA_HOME の確認
  Temurin-21 のパスが正しく通っていることを確認してサーバーを起動する。

2. ターミナル操作によるサンプルアプリのデプロイ

今回は、最小構成である struts-blank.war を Tomcat にデプロイし、動作確認を行う。

3. まとめ

最新の Mac OS および Java 21 環境において、Struts 1.1 の土台が完成した。
「Welcome!」画面が表示されたことで、開発環境のベースラインが確保されたことになる。今回の検証で「動く環境」を手に入れたため、次回からはより踏み込んだ内部構造の解析へステップを進めていく。

そして、このトランザクション処理が安全かつ正確に行われるために、RDBMSが保証すべき4つの性質の頭文字をとったものが「ACID（アシッド）特性」だ。
今回は、システム開発やデータベース設計の基本となるACID特性をわかりやすく整理した。

1. ACID特性の4つの要素

データベースのデータ破壊を防ぎ、整合性を完璧に保つためにRDBMSが備えるべき4つの原則は以下の通りである。

• A：Atomicity（原子性 / All or Nothing）
  トランザクションに含まれる一連のデータ操作は、「すべて完全に実行される（Commit）」か「まったく実行されなかった状態に戻る（Rollback）」かのどちらか一方にしかならない性質。
  途中でエラーやシステム障害が発生した場合、中途半端に一部だけが更新された状態が残ることは絶対にない。
• C：Consistency（一貫性 / 整合性）
  トランザクションの開始前と終了後で、データベースの整合性制約（主キー制約、外部キー制約、NOT NULL制約など）が常に満たされている性質。
  ルールに違反するような不正なデータ変更が行われそうになった場合、トランザクション全体が自動的に取り消される。
• I：Isolation（独立性 / 隔離性）
  複数のトランザクションが同時に並行実行されていても、互いの処理過程が干渉・影響し合わない性質。
  他のトランザクションからは「まだ確定していない途中の状態」が見えず、あたかも1つずつ順番に実行（直列化）されたかのような結果が保証される。
• D：Durability（永続性 / 堅牢性）
  トランザクションが一度確定（Commit）または取消（Rollback）した時点で、その結果は永続的に記憶され、絶対に失われない性質。
  確定直後にサーバーの電源が落ちたりシステム障害が発生したりしても、REDOログ等の仕組みによってデータは確実に復元される。

2. 具体例：銀行の口座振込で考えるACID

「Aさんの口座からBさんの口座へ1万円を振り込む」というトランザクション（①A口座から1万円引く ➔ ②B口座に1万円足す）を例に挙げると、ACID特性の重要性がより明確になる。

3. まとめ

Webアプリケーションや基幹システムにおいて、データの辻褄が合わなくなるバグを防いでいるのは、RDBMSが提供するこのACID特性のおかげである。

システム設計時には、特に「隔離性（Isolation）レベルの設定（Dirty ReadやPhantom Readの防犯）」や「デッドロックの防止」など、ACID特性を意識したトランザクション設計を行うことが求められる。

今回は、データベースを正しく管理・運用するためにRDBMSが備えるべき12の原則をわかりやすく整理した。

1. コッドの12のルール（RDBMSの要件定義）

コッド博士は、システムが独自の拡張や物理的な制約に頼らず、純粋に「リレーショナルモデル」としてデータの一貫性・独立性を保つために以下の12原則（および原則0である「完全なリレーショナル機能による管理」）を定めた。

• ① 情報の表現原則（Information Rule）
  テーブル名や列名、制約といったメタデータを含め、データベース内のすべての情報は「表（リレーション）のセルに格納された値」として一元的に記録されなければならない。
• ② アクセスの保証（Guaranteed Access Rule）
  すべてのデータ要素は、「テーブル名」「主キー（Primary Key）の値」「列（ドメイン）名」の組み合わせによって論理的に一意指定してアクセス可能でなければならない（物理アドレスやポインタの指定は不可）。
• ③ NULLの統一的扱い（Systematic Treatment of Null Values）
  「値が存在しない（未知）」「適用不能」を表す NULL は、データ型に関わらず、システム全体で統一かつ体系的な方法で処理されなければならない。
• ④ オンライン・アクティブ・カタログ（Dynamic Online Catalog）
  データベース構造を保持するカタログ（データディクショナリ）自体も通常のデータと同じ表形式で表現され、通常のSQL等のデータアクセス言語を使ってオンラインで照会できなければならない。
• ⑤ 包括的なデータ言語の原則（Comprehensive Data Sublanguage Rule）
  データの定義（DDL）、ビューの定義、データの操作（DML）、整合性制約、トランザクション制御（COMMIT/ROLLBACK）などが、単一の明確に定義された言語（SQLなど）で完結して実現できなければならない。
• ⑥ ビューの更新原則（View Updating Rule）
  理論的に更新可能なビューに対して更新（INSERT / UPDATE / DELETE）が発行された場合、RDBMSがそれを検知し、裏側にある実表（基底テーブル）に対して正しく更新処理を反映しなければならない。
• ⑦ 高水準の挿入・更新・削除（High-Level Insert, Update, and Delete）
  データ操作言語は、一度の命令（クエリ）で1行ずつ処理するのではなく、複数の行（タプル／集合）をひと括りで集合処理できなければならない。
• ⑧ 物理的データ独立性（Physical Data Independence）
  データの記憶形式やアクセスパス（インデックス構造やファイルの配置場所など）といった物理的な変更を行っても、アプリケーションプログラムのコードに影響を与えてはならない。
• ⑨ 論理的データ独立性（Logical Data Independence）
  テーブルの分割・結合など、データベースの論理構造を変更した場合でも、既存のアプリケーションプログラムへの影響を最小限に抑えられなければならない（ビュー等の活用）。
• ⑩ 整合性制約の独立性（Integrity Independence）
  主キー制約や外部キー制約などのデータ整合性制約は、アプリ側のプログラム内に記述するのではなく、RDBMS内のカタログに直接定義・保持されなければならない。制約が変更されてもアプリ側に影響を与えない。
• ⑪ 分散の独立性（Distribution Independence）
  データベースが複数のサーバやネットワーク上に分散配置されたとしても、アプリケーション側からはあたかも単一のローカルデータベースを操作しているように見えなければならない（位置の透過性）。
• ⑫ 規約無効化の否定（Non-Subversion Rule）
  RDBMSに低水準（レコード単位など）のインターフェースが存在する場合でも、その経路を使ってRDBMSに定義された整合性制約やセキュリティ規約を回避・破壊できてはならない。

2. まとめ：現代RDBMSにおける位置づけ

コッドの12のルールは、SQLデータベースの理想型を示した厳格な基準である。現実の主要なRDBMS（Oracle、PostgreSQL、MySQL、SQL Serverなど）であっても、これら12のルールを完全（100%）に満たしている製品は少ない。

しかし、「物理データからの独立」「集合操作」「整合性制約のRDBMS側での一元管理」といった根幹のコンセプトは、現代のデータベース設計やアプリケーション開発においても変わらない基礎知識として息づいている。

1. オプティマイザーとは

データベースアクセスを最適化する仕組み、およびそのシステムをオプティマイザーと呼ぶ。

オプティマイザーは、ユーザーから送られてきたSQL文を構文解析（パース）し、テーブルの構造やインデックスの有無を分析する。その後、内部で複数の実行計画（プラン）を組み立て、その中から最も効率が良いと判断したアクセス経路を検出して実行に移す役割を担っている。

2. オプティマイザーの2つの種類

SQL文の実行計画を選択・決定する手法には、歴史的な経緯やアプローチの違いにより、大きく分けて次の2種類が存在する。

（1）ルールベース・オプティマイザー（RBO）

ルールベースのオプティマイザーは、データの量や状態に関わらず、あらかじめシステムに組み込まれた固定の優先順位（ルール）に則って、機械的に実行計画を決定する。

一般的には、以下のようなアクセス・パス（経路）の優先順位が定義されており、より上位の条件にマッチするインデックス等があれば、それを優先的に選択する。

• （ア）ユニーク・キーまたは主キーによる単一行アクセス（最優先）
• （イ）インデックス付きのクラスター・キー
• （ウ）複合インデックス（複数カラムを組み合わせたインデックス）
• （エ）単一カラム・インデックス
• （オ）ソート／マージ結合
• （カ）インデックス付きカラムの MAX または MIN 関数
• （キ）インデックス付きカラムの ORDER BY
• （ク）テーブル全体のスキャン（フルスキャン）（最も優先順位が低い）

（2）コストベース・オプティマイザー（CBO）

現在の主要なDBMS（Oracle、PostgreSQL、MySQL、SQL Serverなど）で主流となっているのが、このコストベースである。
あらかじめデータベース内に収集・蓄積されている、テーブルのレコード数、カラムの平均長、インデックスの深さ、データの分布度といった「統計情報」を基にする。

オプティマイザーは内部で複数の実行計画をシミュレーションし、それぞれのパターンで発生する「コスト」を計算して、最もコストが低いプランを採用する。

※ここでいう「コスト」とは、SQL文を実行するために必要と予測される、CPU処理時間やディスクI/O（読み書き）の経過時間に比例する見積値のことである。データ量が少なければフルスキャンを選び、データ量が多ければインデックスを選ぶ、といった柔軟な判断が可能となる。

3. まとめ

ルールベースは「構造」だけで判断するためデータ量の変化に弱く、現代の複雑なシステムでは不都合が生じやすい。そのため、現在のRDB運用においては、定期的に ANALYZE などのコマンドを実行して最新の「統計情報」を維持し、コストベース・オプティマイザーに正しい判断をさせることが、パフォーマンス管理における最大の鉄則となっている。

今回は、データベース設計や情報処理試験でも極めて重要となる、標準SQLにおける「更新可能なビュー」が満たすべき8つの厳格な条件を整理した。

1. 更新可能なビュー（Updatable View）の8大条件

DBMSがビューの向こう側にある実テーブル（基底テーブル）に対して、どのレコードのどの列を書き換えるべきかを一意に特定（マッピング）できる必要があるため、以下の条件が定められている。

• ① 1つだけのテーブルから作られていること
  複数のテーブルを結合（JOIN）して作成されたビューは、原則として標準SQLでは直接更新できない。対象となる基底テーブルが単一である必要がある。
• ② GROUP BY 句を使っていないこと
  データをグループ化してしまうと、ビュー上の1行が基底テーブルの複数行をまとめたものになってしまうため、どの行を更新すべきか特定できなくなる。
• ③ HAVING 句を使っていないこと
  GROUP BY と同様に、グループ化された集計結果に対する絞り込みを行う句が含まれているビューは更新対象外となる。
• ④ 集約関数（SUM, AVG, COUNT, MAX, MIN など）を使っていないこと
  計算・集計された結果の値を書き換えようとしても、基底テーブルの元のデータをどう変更すればよいか計算が成り立たないためである。
• ⑤ 計算列を使っていないこと
  SELECT col1 + col2 AS total のような演算式によって算出された列（計算列）は、直接値を書き換えることができない。
• ⑥ UNION、INTERSECT、EXCEPT を使っていないこと
  集合演算子を用いて複数のクエリ結果を統合・比較しているビューは、データの出所を一意にマッピングできないため更新できない。
• ⑦ SELECT DISTINCT 句を使っていないこと
  重複行を排除（一意化）して表示されたビューは、実テーブルのどの行に対応しているかの追跡性が失われるため、更新が許可されない。
• ⑧ ビューに含まれない基底テーブルのすべての列が、NULLを許可するか、デフォルト値が指定されていること
  ビュー経由で INSERT（行追加）を行う際、ビューに定義されていない列にはデータが渡らない。そのため、それらの列が NOT NULL（かつデフォルト値なし）の制約を持っていると、実テーブル側で制約エラーが発生して挿入できなくなる。

2. まとめ：実務でのアプローチ

上記のように、標準SQLでビューを更新可能にするためのハードルはかなり高い。実テーブルとビューの列が「1対1」できれいに対応しているシンプルなビューだけが、そのまま更新できる仕様になっている。

もし、これらの条件を満たさない複雑なビュー（複数テーブルの結合ビューなど）に対してどうしても更新処理を行いたい場合は、PostgreSQL等の主要なDBMSでサポートされているINSTEAD OF トリガーをビューに実装し、内部の更新ロジックを開発者が手動で記述するアプローチをとるのが一般的である。

対話型シェルにログインして実行する基本方法から、シェルスクリプトなどの自動化（バッチ処理）に組み込む際の本質的な外部実行プロセスまで、ステップバイステップで検証を進めていく。

1. 開発環境の準備（ターミナルの操作）

まずはUbuntu環境に PostgreSQL が導入されているか確認する。未インストールの場合は、パッケージ管理システムの apt を用いて以下の通り導入を行う。

■ インストールの確認と実行

2. スクリプトファイルの作成

検証用の作業ディレクトリを作成し、テストとして「Hello World」の文字列を出力するだけのシンプルなSQLファイルを用意する。

■ 作業フォルダの作成と移動

■ テスト用SQLファイルの作成（コマンドラインより生成）

3. PostgreSQLへのログイン

UbuntuにおけるPostgreSQLの初期設定では、データベースの最高管理権限は postgres という名前のOSユーザーに紐づけられている。
そのため、以下のようにOSの管理者権限を介して psql シェルへログインする。

■ 管理者権限（スーパーユーザー）でのログイン

※ sudo -u postgres を付与することで、ログインパスワードの入力を求めることなく、安全にPostgreSQLの内部プロンプトへ入ることができる。

4. ファイルの実行（対話モードでの実践）

psql の対話型プロンプト内で、先ほど作成した外部の .sql ファイルを読み込んで実行させる。

■ スクリプトの実行メタコマンド

プロンプト postgres=# が表示されている状態で、ファイルを指定して以下のインクルードコマンドを入力する。

■ 期待される実行出力

無事に結果が得られたら、以下のメタコマンドで対話型シェルを終了（離脱）する。

5. 本質的な「検証」：OSコマンドラインからの非対話実行

実際のシステム運用や、シェルスクリプト（Cronジョブなど）による自動バッチ処理にSQLを組み込む際、わざわざ対話モードに手動ログインするのは現実的ではない。
そこで、プロンプトに入らず、Ubuntuのコマンドラインから直接SQLファイルを流し込んで結果を得る方法を検証する。

ターミナル上で、ディレクトリが ~/psql-study にあることを確認し、以下のコマンドを実行する。

■ 技術解説：-f オプションの役割

-f（file）オプションを使用することで、指定したファイルの中身を直接PostgreSQLのエンジンにパイプラインで流し込み、実行結果をそのまま標準出力（stdout）としてターミナルへ戻すことができる。

この非対話コマンドが正常に通れば、「SQLファイルの外部実行プロセス」がUbuntu環境において正しくセットアップできている証明となる。これをベースに、シェルスクリプトでのデータ抽出や定期バックアップタスク等への応用が可能だ。

1. フルバックアップ（完全バックアップ）

対象となるデータベース内のすべてのデータを丸ごと丸ごとバックアップする方式。

• 仕組み： 基準となる時点のデータを1つのまとまったファイルとして完全に複製する。
• メリット： 復旧（リストア）作業が極めてシンプルである。万が一の際は、このフルバックアップデータを1回書き戻すだけで、その時点の状態を完全に再現できる。
• デメリット： データ量に比例して、バックアップの実行時間が最も長くかかり、保管に必要なストレージ容量も最大となる。

2. 差分バックアップ（ディファレンシャル）

「最後のフルバックアップ」から「現在」までの間に変更・追加されたデータのみを抽出してバックアップする方式。

• 仕組み： 起点は常に「直近のフルバックアップ」となる。そのため、フルバックアップからの日数が経つにつれて、日毎に差分データのサイズは徐々に肥大化していく。
• メリット： 復旧（リストア）の際は、「直近のフルバックアップ」と「最新の差分バックアップ」の計2点があれば良いため、比較的スピーディーに復旧が完了する。
• デメリット： フルバックアップから次のフルバックアップまでの期間が長いと、後半の差分バックアップのサイズが大きくなり、日々のバックアップ時間が長くなってしまう。

3. 増分バックアップ（インクリメンタル）

フルか差分かを問わず、「前回のバックアップ（直近の何らかのバックアップ）」から「現在」までの間に変更・追加されたデータのみを抽出する方式。

• 仕組み： 常に「一回前のバックアップ時点」からの変化量だけを追いかける。日々のデータ量は最小限に抑えられる。
• メリット： 日常的なバックアップ実行時間が最も短く、消費するストレージ容量も最小限に抑えることができる。高頻度（1時間毎など）でバックアップを取りたい場合に最適。
• デメリット： 復旧（リストア）のハードルが上がる。復旧には「直近のフルバックアップ」に加え、それ以降に取得したすべての増分バックアップファイルを順番通りにすべて適用する必要がある。もし途中の1世代でもファイルが破損していると、それ以降のデータに復旧できなくなるリスクがある。

4. まとめ：各方式の比較表と選定戦略

運用の現場では、どれか一つの方式だけを採用するのではなく、一般的に「週末にフルバックアップを取得し、平日に差分（または増分）を取得する」といった組み合わせによる戦略（世代管理）がとられる。

システムの許容できる停止時間（RTO）や、データ復旧の目標地点（RPO）、利用可能なディスク予算のバランスを考慮し、最適なバックアップ計画を組み立ててほしい。

1. 初期ユーザーの定義状態とアカウントステータス

まずは、データベース作成直後の初期状態で、どのようなユーザーが存在しているのかを一覧で確認します。Oracle全体のユーザー情報を一元管理している DBA_USERS ビューから、主要なユーザーとそのアカウント状態（STATUS）を抽出してみましょう。なお、このクエリはすべて切り出された私たちの個室（PDB）側の環境を覗いています。

【結果解説：ACCOUNT_STATUS（アカウント状態）の意味】
ズラリと並んだ実行結果のステータスには、Oracleのセキュリティ設計の基本がそのまま現れています。

• OPEN（オープン）：現在、正常にログインして操作ができる「生きている」ユーザーです。私たちが使う ADMIN や、裏で常に稼働している主要なコアシステム（SYS や SYSTEM）など、ごく僅かなアカウントだけがこの状態を許されています。
• LOCKED（ロック）：アカウントが凍結されている状態です。これらはOracle内部の特定の機能（監査や監視など）を動かすためだけに用意された専用ユーザーであり、悪意ある第三者が乗っ取って外部から不正ログインできないよう、安全のために最初からガチガチに鍵がかけされています。
• EXPIRED & LOCKED（期限切れ＆ロック）：パスワードの有効期限が切れ、さらにアカウントもロックされている二重ロック状態です（上記抜粋外の多くのシステムユーザーが該当します）。現在は使われていない、完全に眠っている内部機能用のスキーマです。

【マルチテナントの仕様：なぜPDBにSYSやSYSTEMがいるの？】
「全体の親玉（CDB）ではなく個室（PDB）を見ているのに、なぜ最高権限のSYSやSYSTEMが一覧に並んでいるの？」と疑問に思うかもしれません。
これはマルチテナントの仕様によるものです。新しく個室（PDB）が作成された瞬間、その個室単体を管理・独立稼働させるためのシステムユーザー一式が、各PDBの内部にも自動的に複製されて配置される仕組みになっています。つまり、ここに並んでいる `SYS` や `SYSTEM` は、全体の親玉ではなく「この個室専用に配属された管理ユーザー」なのです。PaaSの自律運用の邪魔をしないよう、安全に制御されています。

2. まとめ

実機のデータ・ディクショナリからユーザー構造を紐解くことで、PaaS環境であってもOracle Databaseとしての堅牢なシステム構成がそのまま引き継がれていることが確認できました。

ストレージ（論理・物理）に続き、ユーザーの初期状態まで確認できました。完全管理型（PaaS）データベースの内部検証シリーズはここで一区切りとなります。
次回第8回は、この「枠からはみ出せない」PaaSの安心安全な世界から飛び出し、「もう一つの無料枠（Compute VM）」を立ち上げて、Linuxのroot権限、そしてデータベース全体の親玉であるCDB$ROOTまですべてを自分の完全な支配下に置く『IaaS型・23ai Express Edition 自作構築編』へ突入します。コントロールを100%自分で握るインフラ構築の世界へ。どうぞお楽しみに！