シナリオを理解する:
* エンタープライズ ジオデータベース フィーチャ データセットが誤って削除されました。
* 組織はデータセットを元の状態に復元する必要があります。
利用可能なテクノロジー:
* 高可用性: 高可用性設定 (例: フェイルオーバー システム) により、ハードウェアまたはソフトウェアの障害発生時にもジオデータベースへの継続的なアクセスが確保されます。ただし、高可用性では誤って削除されたデータは復元されません。
* バックアップ: バックアップは、特定の時点で取得されたジオデータベースのスナップショットです。これにより、管理者は削除されたデータセットを復元したり、データ損失シナリオから回復したりできます。
* アーカイブ: アーカイブはバージョン管理されたジオデータベース内の履歴編集を追跡しますが、誤って削除されたデータセットの回復は提供しません。
データセットを回復する手順:
* エンタープライズ ジオデータベースの最新のバックアップを特定します。
* ジオデータベースを復元するか、バックアップから特定のフィーチャ データセットを抽出します。
* 復元されたデータを確認し、必要に応じて進行中の更新と同期します。
参考文献:
* Esri ドキュメント: バックアップと復元。
* データ保護のベスト プラクティス: データの損失を防ぐために定期的なバックアップを実装するためのガイドライン。
正解が B である理由: バックアップは、誤って削除されたフィーチャ データセットを回復するための最も信頼性の高いソリューションです。高可用性により稼働時間は保証されますが、データの回復には対応していません。また、アーカイブではデータセット全体を保存するのではなく、編集内容を追跡します。

シナリオを理解する:
* クエリは、inspector_name に基づいて行をフィルタリングし、結果を Inspection_date で並べ替えます。
* インデックスを作成すると、クエリ実行中にスキャンされる行数が減り、データの取得が最適化されます。
インデックス作成に関する重要な考慮事項:
* プライマリ フィルター列:inspector_name 列は、WHERE 句のプライマリ フィルターです。
この列にインデックスを付けると、フィルター条件に一致する行をすばやく識別できます。
* ソートの最適化: ORDER BY Inspection_date 句では、inspection_date を複合インデックスの 2 番目の列としてインデックス付けすることで、フィルタリングされた結果のソートが高速化されます。
インデックスの選択:
* Inspection_date と Inspection_name の複合インデックスにより、効率的なクエリ実行が可能になります。
*inspector_name は高速フィルタリングを保証します。
* Inspection_date はソートを最適化します。
* facility_type のような無関係な列はクエリの一部ではないため、インデックス作成は不要です。
インデックスを作成する手順:
* エンタープライズ ジオデータベースでは、データベース管理ツールまたは SQL コマンドを使用して複合インデックスを作成します。
インデックスidx_facility_inspectionsを作成します
ON facility_inspections (検査官名、検査日);
参考文献:
* Esri ドキュメント: インデックスの作成と管理。
* SQL インデックスのベスト プラクティス: クエリを最適化するための複合インデックス作成のガイドライン。
正解が D である理由:inspector_name と Inspection_date の複合インデックスはクエリ構造を直接処理し、WHERE フィルターと ORDER BY 句の両方を最適化します。

スタンバイ データ センターに同等のデータが存在することを必要とする大規模な政府機関にとって、データベース レプリケーションは理想的なソリューションです。
1. データベースレプリケーションとは何ですか?
* データベース レプリケーションでは、プライマリ データベースからセカンダリ データベースにほぼリアルタイムで、またはスケジュールに基づいてデータを複製します。
* これにより、両方のデータベースが同期され、一方のデータベースに障害が発生した場合でもデータを提供できるようになります。
2. データベースレプリケーションが要件に適合する理由
* スタンバイ データ センター: データベース レプリケーションにより、セカンダリ データ センターのデータの完全に同等なコピーが提供されます。
* 高可用性と災害復旧: プライマリ データベースが使用できない場合、スタンバイ データベースがすぐに引き継ぎ、ビジネスの継続性を確保します。
3. 他の選択肢はないのでしょうか?
* ジオデータベースレプリケーション:
* ジオデータベース コンテンツを複製するように設計されていますが、通常はフィールド編集の同期など、GIS 固有のワークフローに使用されます。データベースの非空間コンポーネントの同等性は保証されません。
* 大規模な組織全体のレプリケーションのニーズには適していません。
* 切断された同期:
* これは、デバイスが後で編集内容を中央データベースと同期するオフライン編集ワークフローで使用されます。同等のスタンバイ データベースを維持するのには適していません。
4. データベースレプリケーションの種類
* 非同期レプリケーション: 更新はスケジュールされた間隔でレプリケートされるため、柔軟性は得られますが、若干の遅延が発生します。
* 同期レプリケーション: 更新はリアルタイムで行われるため、両方のデータベースが常に同一であることが保証されます。
データベースレプリケーションを実装する手順:
* 組織の DBMS (SQL Server、PostgreSQL、Oracle など) でプライマリ データベースとスタンバイ データベースを構成します。
* DBMS の組み込みレプリケーション ツール (SQL Server の Always On、PostgreSQL のストリーミング レプリケーションなど) を使用します。
* レプリケーション プロセスが正しく機能していることを確認するために監視を設定します。
Esri ドキュメントおよび学習リソースからの参照:
* DBMSにおけるデータベースレプリケーション
* データベースレプリケーションによる災害復旧
結論：
データベース レプリケーションは、スタンバイ データ センターに同等のデータを確立し、高可用性と災害復旧を保証するために推奨されるテクノロジです。

シナリオを理解する:
* エンタープライズ ジオデータベースは、フェデレーション データベースからの「プッシュ」SQL プロセスを通じて定期的に更新を受け取ります。
* ビジネス ルールでは、データ挿入プロセス中に属性値の変換または修正が必要になります。
* GIS 管理者には、属性値がこれらのルールに準拠していることを確認するためのメカニズムが必要です。
オプションの概要:
* 属性ルール:
* 属性ルールは、データ編集中に計算や制約を適用することで、データの整合性を強化できます。
* 計算ルールを使用すると、特定のロジックに基づいて属性値を自動的に導出できるため、値がビジネス ルールに準拠していることが保証されます。
* DBMS トリガー: DBMS トリガーは、データベース イベント (挿入など) が発生したときにプロシージャを実行します。
ただし、これらはジオデータベース環境の外部で管理されるため、ArcGIS ワークフローとの統合性が低くなります。
* 空間ビュー:空間ビューは空間データと非空間データを組み合わせますが、データの読み込み中または編集中に属性値を適用または変更することはありません。
属性ルールを構成する手順:
* 変換が必要なフィールドに計算属性ルールを定義します。
* ビジネス ルールに基づいて属性値を導出または検証するロジックを指定します。
* ルールをデータセットに適用します。
* データが挿入されると、ルールによって値が自動的に更新または修正されます。
参考文献:
* Esri ドキュメント: 属性ルール。
* 属性ルール タイプ: エンタープライズ ジオデータベースで計算ルールと検証ルールを使用するためのベスト プラクティス。
正解が A である理由: 属性ルールは、属性値を管理し、データ編集中にビジネス ロジックに準拠することを保証するように特別に設計されています。DBMS トリガーは外部にあり、ジオデータベース中心ではありませんが、空間ビューは挿入中の値の変換をサポートしていません。