process-mining
2024.10
true
- リリース ノート
- はじめる前に
- 基本情報
- Integrations
- プロセス アプリを使用する
- アプリを作成する
- データを読み込む
- プロセス アプリをカスタマイズする
- ダッシュボードをパブリッシュする
- アプリ テンプレート
- その他のリソース
- すぐに使えるタグと期限日
- ローカル環境でデータ変換を編集する
- ローカルのテスト環境を設定する
- カスタムのスループット時間メトリック
- Snowflake と SQL Server の SQL の違い
- 入力データを読み込むための設定
- イベント ログをデザインする
- SAP Ariba の抽出ツールを拡張する
- パフォーマンス特性
Snowflake と SQL Server の SQL の違い
Process Mining
Last updated 2024年11月11日
Snowflake と SQL Server の SQL の違い
ローカルの開発環境では SQL Server で変換が実行され、Automation Suite の Process Mining では Snowflake が使用されます。ほとんどの SQL ステートメントは SQL Server と Snowflake の両方で動作しますが、構文が若干異なる可能性があり、それによって戻り値が異なる場合があります。
両方のデータベース システムで動作する SQL ステートメントを書くには、以下のようにします。
- フィールド名を二重引用符で囲みます (例:
Table."Field"
)。 -
Snowflake と SQL Server で異なる SQL 関数を使用しないようにします (例:
string_agg()
とlistagg()
)。pm_utils
パッケージには、両方のデータベースで動作する関数が一式付属しています。詳しくは、「Multiple databases」をご覧ください。たとえばstring_agg()
やlistagg()
を使用する代わりにpm_utils.string_agg()
を使用すれば、両方のデータベースで結果の挙動が同じになります。pm_utils
に目的の関数が含まれていない場合は、各データベースで適切な関数が呼び出されるように Jinja ステートメントを作成する必要があります。
文字列と結合するには、
pm_utils.concat()
関数を使用します。この関数を使用すると、SQL Server と Snowflake の両方で同じ結果が生成されます。
例:
pm_utils.concat("This is a nice string", null)
= "This is a nice string"
文字列の連結は、+
や ||
などの演算子で行うべきではありません。これらの演算子は両方のデータベースで異なる (Snowflake では ||
が使用され、SQL Server では +
が使用される) ためです。また、標準の concat()
関数の挙動も両方のシステムで異なります。具体的には以下のような違いがあります。
SQL Server |
Snowflake |
---|---|
null 値は無視され、空の文字列として扱われます。
|
null 値があると、結果全体が null になります。
|
並べ替えは、Snowflake と SQL Server で異なる方法で処理されます。
例:
... order by "Attribute_1" desc, "Attribute_2" ...
値 "A" と " A" をグループ化すると、SQL Server では 1 つの値と見なされますが、Snowflake では 2 つの異なる値として見なされます。したがって、お使いのデータでこの問題が発生する可能性がある場合は、トリミングをお勧めします。
既定では、SQL Server では大文字と小文字が区別されません。一方 Snowflake では大文字と小文字が区別されます。つまり、
Table."Field" = "Some_value"
と Table."Field" = "SOME_VALUE"
は、SQL Server では同じ結果のセットが返されますが、Snowflake では 2 つの異なる結果のセットが返される可能性があります。
問題が発生しないように、ローカルの SQL Server データベースの挙動を Snowflake の挙動と一致するように変更することをお勧めします。これは、データベースの照合順序を大文字と小文字を区別する値に設定することで達成できます。