リレーショナル・データベースでは、データベースの完全性を維持するためにデータの関係を注意深く管理し正確さを優先することが重要です。
例えば、従業員がどのように部門に関連付けられているかを考えてみましょう。この場合、データ関係の管理とは従業員レコードを有効な部門エントリーに正しくリンクすることを意味します。言い換えれば、各従業員はデータベース内の既存の部門に割り当てられるべきです。
データ・リレーションシップを管理するための最も重要なツールの 1 つが外部キーです。通常、外部キーは別のテーブルの主キーにリンクします。
外部キー制約の役割は、データベースの信頼性の重要な側面である参照整合性を強制することです。これにより、外部キー列の各値が参照先テーブルの主キー列の値に正しく対応することが保証されます。この場合、Employee テーブルの Department ID 列は、参照先 Department テーブルの Department ID と一致します。
この強制メカニズムは、有効な部署に対応しない従業員データなどいった対応する参照がないデータの追加を防ぎます。また、従業員との紐づきが存在する部門を削除することを防止し、そのような行為から発生するデータの不整合を防止します。重要なことは、外部キー制約が必須として設定されない限り、自動的に部署などのフィールドが必須になるわけではないということです。
InterSystems IRIS 内で外部キー制約がどのように動作するかを詳しく見てみましょう。これらの制約は、関連するテーブル間でデータがどのように相互作用するかを導き、SQL とオブジェクト・データ・モデルの両方とシームレスに統合できるようにします。
これらの制約がどのように機能するかを確認するため、Depertment テーブルと外部キー制約によって紐づく Employee テーブルからレコードを削除するとします。
Depertment は主キーを持つ参照先テーブルです。Employee テーブルは、Depertment テーブルの主キーを参照する外部キーカラムを持ちます。
この Depertment レコードを削除した場合、対応するリンクがない関連レコードが残り孤立したデータが存在することになりますが、外部キー制約の構成によっては削除がブロックされる可能性があります。
InterSystems IRIS では、管理ポータルまたは SQL スキーマ内で直接外部キー制約を定義できます。この仕組みを詳しく見てみましょう。
SQL エクスプローラで外部キー制約を含む新しいテーブルを作成したり、既存のテーブルを変更したりできます。
テーブル定義で外部キーを指定し、それを参照テーブルの主キーにリンクします。
いくつかのオプションがあります： CASCADE、SET NULL、RESTRICT、NO ACTIONです。
CASCADE オプションは、1 つのレコードの削除が自動的にすべての関連レコードの削除につながる場合に便利です。一般的な使用例は、小売システムにおける注文とそれに関連する注文詳細です。注文が削除されると、CASCADE は対応するすべての注文詳細項目も削除されることを保証し、孤立したレコードのないクリーンで一貫性のあるデータを維持します。
一方 RESTRICT オプションは、レコードが互いに決定的に依存しているシナリオでは不可欠なオプションです。例えば、企業の環境において部署にまだ従業員が割り当てられている状況で部署の削除を防ぐことができます。
SET NULL は、レコード間のリンクは必須ではないが、残りのデータの整合性を保持することが重要な状況で使用できます。例えば、ある従業員の HR ビジネスパートナーが退職する場合、その従業員のレコードでそのパートナーの ID を NULL に設定することができます。これにより、他の重要な従業員データに影響を与えることなく、その従業員には現在 HR ビジネス・パートナーが割り当てられていないことが示されます。
NO ACTION の場合、管理者がデータベースによる自動的な決定を望まず、手作業によるレビュー手順が実施されているような稀なケースでは、NO ACTION が適切となる場合もあります。
これらのアクションの柔軟性により、特定のアプリケーションのニーズに合わせてデータ整合性ルールを調整することができます。
データベースのスキーマを注意深く計画し、外部キー制約がアプリケーションのユースケースとパフォーマンス要件を論理的にサポートしていることを確認することがベストプラクティスと考えられています。
データの完全性を保証するために、外部キーを含む INISERT や UPDATE は、参照するテーブルに対する検証チェックをトリガーします。このプロセスは非常に重要ですが、追加的な検証が必要となるためパフォーマンスに影響を与える可能性があります。
InterSystems IRIS では、外部キーの定義時に NOCHECK キーワードを使用して、外部キーをメタデータとしてのみ含めることができます。この方法は、能動的な強制を回避しオーバーヘッドを削減します。これは、データの完全性が他の手段で保証されている環境で特に有用です。
最終的に、外部キー制約は、データベースのリレーションシップの整合性と信頼性を維持するためのルールを強制するために非常に重要です。InterSystems IRIS 内でこれらの制約を慎重に管理することで、安定した、信頼性の高い、一貫性のあるデータベース環境を維持することができます。

このビデオでは、遅い SQL クエリを特定し改善するプロセスを説明します。重要なのは遅いクエリが必ずしも問題であるとは限らないということ、そして速度は相対的なものであるということです。例えば、1 日 1 回実行され実行に 2 秒かかり大規模なサマリーレポートを生成するクエリは十分に速いと考えられるでしょう。
しかし、2 秒のクエリがメイン・ユーザー・インターフェースの重要な部分で 1 分間に 100 回実行されるのであれば、その効率を高めることができるかどうかよく検討する価値があります。
私たちのシステムでは、100 万行の株式取引データがあり各行が 1 つのトランザクションを表しています。私たちのシステムは、主にこの株式データに対して SQL クエリーを実行し、ダッシュボードを最新の状態に保つために使用されています。
最近、ユーザーからダッシュボードの更新が遅いという報告がありました。
この問題の原因となっているクエリを見つけるために、User ネームスペースで実行されているすべての SQL 文を調べます。SQL エクスプローラで [SQL 文] タブをクリックし、現在のネームスペース内のすべての SQL 文を表示します。
どのクエリの実行が遅いかを知りたいのでフィルタを追加して、そのテーブルで実行されているクエリだけを表示します。これにより、このテーブル上のすべてのクエリの実行回数、平均時間、合計時間などの詳細を見ることができます。合計時間でソートすると、どのクエリに最も時間がかかっているかがわかります。
ここでは、1 日に約 60 回実行されるクエリの合計時間が 106.5 秒であることがわかります。
これは、システムがこのクエリを実行するのに合計 106.5 秒を費やしたことを意味します。ここで、速度の相対性が重要になります。この場合このクエリの実行頻度を考慮すると合計時間は長いです。Data.StockData というテーブル名をクリックして、このクエリを詳しく見てみましょう。
このクエリーは、各銘柄について実行された売り取引の数を最新に集計しこの集計はメイントレーダーのダッシュボードで 5 秒ごとに更新されます。
代表的なデータでこのクエリーをテストシステムで実行すると、実行に 2 秒近くかかります。この問題を引き起こしているクエリを特定したので、そのクエリの実行速度を遅くしている原因を突き止めましょう。
遅いクエリを修正する場合、最初のステップは常にクエリ・プランを確認することです。InterSystems SQL クエリ・オプティマイザは、現在利用可能な情報で可能な限り効率的に実行されるようにクエリを自動的に処理します。
このプロセスの一環として、クエリオプティマイザは、クエリのフィルタ、集約、およびその他の処理を処理するための複数のプランを生成します。クエリオプティマイザは、テーブルの統計情報に基づいてそれらのコストを推定し実行時に最も効率的なプランを選択します。
クエリプランを見ることで、テーブルとインデックス構造をどのようにスキャンするかを確認することができます。これは、どのステップに最も時間がかかりクエリを遅くしているかを特定するのに役立ちます。この情報に基づいて、インデックスの追加や並列処理など効率を改善するための調整を行うことができます。
SQL エクスプローラからクエリプランを表示するには、クエリを入力し、[プラン表示] をクリックします。
ご覧のように、このクエリを実行する最初のステップは、ID をループしてマスターマップを読み取ることです。マスターマップは標準テーブルの主要なデータ構造で個々の行を 1 つずつ格納しています。この構造を ID でループしているので、クエリを実行する最初のステップは、テーブルのすべての行からデータを読み取ることです。行数の多いテーブルに対してこのようなマスターマップスキャンを行うクエリプランは非効率的です。
このテーブルには 100 万行以上のデータがあるため、マスターマップを読み込むのは非常に非効率的です。このプランを改善するためにクエリを調整する必要があります。
変更を加える前に、クエリオプティマイザが最新のテーブル統計情報を使用していることを確認しましょう。行数などの統計情報は、どのプランが最も効率的かを判断するのに役立ちます。これを確認するには、テーブルを選択します。次に、[アクション] メニューから [テーブルチューニング情報] をクリックします。
現在の ExtentSize（行数）はデフォルトの 100,000 に設定されています。これは、このテーブルの統計情報がまだ収集されていないことを示し、クエリ・オプティマイザは、このテーブルがかなり小さいテーブルであり、フル・テーブル・スキャンにそれほどコストがかからないと想定しています。テーブルの統計情報を収集するには、[テーブルチューニング] をクリックします。最近の製品バージョンでは、ほとんどの通常のテーブル構造についてテーブル統計が少なくとも 1 回は自動的に収集されます。ExtentSize は、テーブルのサイズがわかっていれば簡単に再確認できる統計情報です。
クエリオプティマイザが最新のテーブル統計を持っていることを確認できたので、クエリプランを再確認してみましょう。
プランは複数のモジュールで構成され、それぞれのモジュールが個別のアクションセットを実行します。モジュールは互いに呼び合い複数回呼び出されるものもあります。このモジュールはマスターマップを分割し、各分割に対して並列にモジュール A を呼び出します。
この特定の問い合わせ計画は、並列化の新しい方法である Adaptive Parallel 実行を使用しています。旧バージョンの製品では、並列化されたクエリプランは少し異なって見えます。
クエリを再度実行すると、並列化によってクエリ時間が短縮されていることがわかります。しかし、クエリプランはまだマスターマップの読み込みと ID のループを含んでいます。
理想的には、読み込むデータ量を減らすためにインデックスを使用することです。場合によっては、期待したときにインデックスが使用されないことがあります。そのような場合は、インデックスが存在し、選択可能であることを確認してください。インデックスの構築中、あるいはインデックスの構築に失敗した後、インデックスが無効になっている可能性があります。
テーブルにインデックスがあるかどうかを確認するには、SQL エクスプローラでテーブルを選択しカタログの詳細タブをクリックしてマップ/インデックスを選択します。
まだインデックスが設定されていないので、次のステップではインデックスを追加します。さまざまなインデックスや変更を試してみると、テーブルの挿入、更新、削除操作のパフォーマンスに影響を与える可能性があることに注意することが重要です。また、インデックスはストレージのコストにもなるため、慎重に追加する必要があります。可能であれば、まず代表的なデータを持つテストシステムで変更を行い、本番システムで変更を実施する前に何が最も効果的であるかを確認してください。
ここでは、テストシステムにインデックスを追加します。このクエリには、トランザクションタイプと日付の 2 つの WHERE 条件が含まれています。テーブルの約半数の行がトランザクションタイプ「SELL」を持っていると予想されますが、検索対象の日付を持つ行の数はもっと少ないはずです。そのため、トランザクションの日付にインデックスを追加し、クエリがより少ない行を読み込めるようにします。
このインデックスを作成するには、create indexコマンドを実行します。このコマンドは自動的にインデックスも作成します。
クエリプランをもう一度見てみましょう。最初のモジュール F は、クエリを並列に実行できるようにマスターマップをサブ範囲に分割します。モジュール F はモジュール A を呼び出し、モジュール B の結果を保持する temp ファイルを作成します。モジュール B は、先ほど作成したインデックスを読み込んで、一致するトランザクション日を持つ行の ID を見つけ、マスターマップからそれらの行だけを読み込みます。
クエリを再度実行すると、実行時間が 1 秒以下に短縮されていることがわかります。
Tune Table の実行とインデックスの追加は、このクエリの効率に大きな影響を与えましたが他にも検討すべきオプションがあります。
1 つのオプションは、SQL オプティマイザで様々なプランのパフォーマンスを比較することです。これらを表示するには、SQL エクスプローラのツールメニューから Alternate Show Plans を選択します。ここで、最適化しようとしているクエリを入力し可能なクエリプランを表示することができます。選択したクエリプランに特定のインデックスが期待通りに含まれていない場合、これらのプランの性能をテストすることは特に有用です。そのインデックスを使用するクエリプランを選択して試すことができそのパフォーマンスを確認することができます。
考慮すべきもう 1 つのオプションは並列処理です。私たちの場合、テーブルチューニング（Tune table）ユーティリティを実行した後、クエリはすでに自動的に並列化されていました。InterSystems IRIS は、大量のデータにアクセスするクエリに対してデフォルトでこの処理を行います。並列化された実行は、複数のプロセスに作業を分散し全体の実行時間を短縮することでクエリのパフォーマンスを向上させます。システムによっては、このAutoParallel設定が無効になっていたりこの設定が行われる閾値が高すぎる場合があります。この場合、%PARALLEL ヒントを使用して、オプティマイザに並列化するように指示することができます。
どのような変更を行うかが決まったら、適切な手順で稼働停止を最小限に抑えながら実稼働システム上でその変更を推進することができます。

データを保護する上で SQL 特権とセキュリティ・メカニズムを理解し管理することは、許可されたユーザのみがデータやストアド・プロシージャにアクセスできるようにするために非常に重要です。
このビデオでは、InterSystems IRIS 環境における SQL 特権の概要を説明します。権限管理、監査機能、SQL インジェクションの脅威からの保護だけでなく、統合認証との統合などの戦略についても学習します。
InterSystems IRIS では、SQL 特権の管理を連携認証および承認フレームワークと統合する必要があります。これにより、異なるシステムやプラットフォーム間で統一されたセキュリティ・ポリシーが可能になり、組織のアクセス権管理能力が強化されます。
たとえば、OAuth 2.0 は、クライアントが HTTP サービスに限定的にアクセスできるようにする認証フレームワークです。OpenID Connect は、OAuth 2.0 の認証プロセスを拡張し、認証を追加したものです。これらの統合により、InterSystems IRIS は、一元化されたポリシー決定に基づいてユーザの認証と認可を行い、管理オーバーヘッドを簡素化し、セキュリティ・プロトコルを強化することができます。
InterSystems IRIS の SQL 権限は、標準 SQL コマンドである GRANT および REVOKE によって管理されます。例えば、指定したテーブルに対して読み取り操作を実行する権限をユーザに割り当てるには、GRANT SELECT ON table_name TO user_name; を使用します。
InterSystems IRIS では、SELECT、INSERT、EXECUTE など、テーブル、ビュー、プロシージャなどの特定のデータベース・オブジェクトを対象としたオブジェクト固有の特権がサポートされています。また、スキーマ全体のオブジェクト特権を一度に指定することもサポートし、複数のオブジェクトにまたがるセキュリティ管理を合理化します。これらの特権と並んで、%CREATE_TABLE のようなネームスペース全体にまたがる管理特権もサポートしています。これらはネームスペース内で適用され管理者はデータベース構成のより構造的な側面を管理することができます。
このきめ細かな制御は、データベース・セキュリティ管理のベスト・プラクティスである最小特権の原則を守るための基本です。これは、ユーザが職務を遂行するために必要以上の特権を受けないようにし、偶発的または悪意のあるデータ侵害のリスクを最小限に抑えるものです。
複雑なアプリケーションでは、スキーマや役割ごとに整理されていても、すべてのオブジェクトの権限を個別に表現するのは面倒です。これを効率化するために、ストアドプロシージャがサーバー上のビジネスロジックを取り込みます。これらのプロシージャは CALL または SELECT 構文でアクセスでき、SQL、Python、または ObjectScript を使用して作成できます。ObjectScript と Python は最も柔軟性が高く、プロシージャの実装で SQL 文と ObjectScript コードを簡単に組み合わせることができます。
多くの SQL 文を含む複雑なビジネス・ロジックをカプセル化するために、ストアド・プロシージャはプロシージャ・レベルで EXECUTE 権限が割り当てられた実用的なものです。デフォルトでは、埋め込み SQL は、ストアド・プロシージャ・レベルで権限チェックが適用されることを前提に、独自に SQL 権限をチェックしません。これは、ストアド・プロシージャ内で実行される全ての SQL 操作は、プロシージャ自体に割り当てられた EXECUTE 権限を継承することを意味します。ビジネス・ロジック内に追加のチェックを追加するには、%CHECKPRIV 文を使用してプロシージャの実行中に特定のユーザ権限を検証できます。
各ユーザ、システム、またはクエリに適切な特権セットを決定するには、組織内のユーザの役割と責任を詳細に分析する必要があります。InterSystems IRIS は、管理者がこれらの設定を効果的に構成するためのツールとガイドラインを提供します。定期的に権限を見直しユーザの役割や組織のポリシーの変更に合わせて調整することが重要です。これにより、最適なセキュリティと機能を維持することができます。
SQL 監査は、包括的なセキュリティ戦略の重要なコンポーネントです。InterSystems IRIS の監査機能により管理者は、データの変更、アクセス試行、スキーマの変更など、データベー スのさまざまなアクティビティを追跡し、ログに記録することができます。これらのログは、セキュリティ監視、フォレンジック分析、規制要件への準拠、および運用上のトラブルシューティングのために非常に貴重です。
しかし、監査ログは非常に詳細であるためデータが大量に蓄積され、その結果かなりのストレージリソースが必要になります。コアな監査作業をモニタリングとアラートのための業界標準ツールで補完するのが一般的です。これらのツールは、セキュリティ情報・イベント管理システム（SIEM）と呼ばれ、組織のセキュリティを強化します。
適切な認証、認可、および監査ポリシーにより、InterSystems IRIS SQL は、アプリケーション・データの安全な場所を提供します。
SQL インジェクションと呼ばれる、SQL データベースを攻撃するために使用される一般的な手法を見てみましょう。 SQL インジェクションでは、悪意のあるユーザがアプリケーションの SQL 文を変更し連結によって悪意のあるコマンドを追加しようとします。
適切な認証ポリシーは、そもそもアプリケーションにアクセスすることを想定していないユーザを排除するのに役立ち、 適切に構成された認可ポリシーは、悪意のあるコマンドが成功するのを防ぐはずです。監査ポリシーは、失敗した試みを含むコマンドが、アラートをトリガーしたり調査を支援したりする方法でログに記録されるようにします。
InterSystems IRIS 内では、SQL インジェクションから保護するパラメータ化されたクエリなどのプログラミング技法を使用できます。例えば、ユーザ入力を直接文に連結するのではなく、SELECT * FROM users WHERE username = ? これにより、入力はコードではなくパラメータとして扱われます。
InterSystems IRIS には、SQL の権限管理を強化するいくつかの機能があります。ベスト・プラクティスを導入することで、InterSystems IRIS SQL 環境のセキュリティと整合性を大幅に強化することができます。データベース管理者とセキュリティ専門家は、新たな脅威から保護し規制基準へのコンプライアンスを確保するために、 セキュリティ戦略を継続的に評価し進化させる必要があります。これらの原則を適用することで、貴重なデータ資産を保護することができます。