このセクションでは、SQL を最適化してパフォーマンスを最大限に高めるためのヒントについて説明します。

フローの順序。 SPSS Modelerのデータ・マイニング機能の方が標準 SQL でサポートされる従来のデータ処理操作より豊かであるため、ノードの関数が意味論的に SQL に相当するものを持たない場合、SQL 生成が停止する可能性があります。 このようなことが発生すると、以後の下流のノードに対しても、SQL 生成が抑制されます。 したがって、SQL を停止させる可能性のある操作はできるだけ下流に配置するようにノードを再配置すると、パフォーマンスを著しく向上させることができます。 SQL オプティマイザーは、一定量の再配列を自動的に行うことができますが、さらに改善できる可能性があります。 この有力な候補は条件抽出ノードであり、しばしば前方へ移動されます。 詳しくは、 SQL プッシュバックをサポートするノード を参照してください。

CLEM 式: フローを並べ替えることができない場合は、ノード・オプション (CLEM 式) を変更するか、操作の実行方法を変更することで、SQL 生成が阻害されないようにすることができます。 レコード作成や条件抽出、および類似したノードは、すべての CLEM 式の演算子が SQL と機能的に同等なので、通常は SQL で表現できます。 ほとんどの演算子は表現できますが、SQL 生成を阻害する演算子がいくつかあります (特にシーケンス関数 [“@ functions”])。 ときには、生成されたクエリーがデータベースで処理するには複雑過ぎて、生成が停止することもあります。 詳しくは、 SQL プッシュバックをサポートする CLEM 式と演算子 を参照してください。

複数の入力ノード。 フローに複数のデータ・インポート・ノードが含まれている場合、各インポート・ブランチに対して SQL 生成が個別に適用されます。 生成がある枝で停止すると、別の枝で続行できます。 2 つの枝が併合される (さらに両方の枝は併合用に SQL で表現できる) 場合は、併合自体がしばしばデータベース結合に置き換えられて、生成は下流方向へと続きます。

スコアリング・モデル。 生成されたモデルを SQL にレンダリングすることで、一部のモデルでデータベース内のスコアリングがサポートされます。 しかし、モデルによっては、データベース内で必ずしも効果的に評価されるとは限らない極端に複雑な SQL 式を生成する場合があります。 そのため、生成後の各モデル・ナゲットに対して、SQL 生成を個別に有効にする必要があります。 モデル・ナゲットによって SQL 生成が禁止されている場合は、そのモデル・ナゲットの設定を開いて「このモデルの SQL を生成」を選択します (一部のモデルについては、SQL 生成を制御するための追加のオプションを使用できる場合があります)。 このオプションが実行予定のアプリケーションにとって有益であるかを確認するために、テストしてください。 詳しくは、 SQL プッシュバックをサポートするノード を参照してください。

モデルの SQL 生成が効果的に機能するかどうかを確認するためにモデル作成ノードをテストする場合は、まず SPSS Modelerからすべてのフローを保存することをお勧めします。 生成された SQL の処理中に、一部のデータベース・システムが停止する場合があります (複雑な SQL の場合など)。

データベース・キャッシング: フロー内の重要な点 (レコード結合ノードやレコード集計ノードの後など) でデータを保存するためにノード・キャッシュを使用している場合は、SQL 最適化とともにデータベース・キャッシングが有効になっていることを確認してください。 ほとんどの場合、この設定によりデータが、ファイル・システムでなくデータベース内の一時テーブルへ、キャッシュされます。

ベンダー固有の SQL。 生成される SQL のほとんどは標準準拠 (SQL-92)ですが、非標準のベンダー固有の機能は実用的な場所で利用されています。 SQL 最適化の程度は、データベース ソースに応じて変化します。