DB Lookup変換の紹介
世の中のサービスで扱うデータは、整合性を保つために重複のないデータ構造を持っています。この重複のないデータ構造には、データの保存スペースを節約できるなどさまざまな長所がある一方で、データが数多くの小さな塊に分離されるという側面もあります。元々は1つのデータ構造にまとまっていた内容が、正規化によって性質の異なる複数のデータに分かれてしまうのです。 このように分離されたデータは、共通のキーを使うことで元の形に復元できます。データベースではおなじみのJOINによる結合が、まさにこの復元のために使われます。 Xplentyでは、これまでデータ同士の結合にはJOINコンポーネントを使ってきました。データベースやAPIから取得したデータを共通のキーでつなぎ合わせられますが、結合の数が増えるほどデータ処理のロジックが分かりにくくなるという問題がありました。 今回紹介するDB Lookup変換は、JOINコンポーネントと同じ役割を担いながら、データ処理のロジックをよりシンプルにできる優れたコンポーネントです。JOINコンポーネントとの違い
同じ結合を、両方の方法で組んでみる
簡単な結合の例として、下記のような2つのテーブルを1つにまとめるケースを考えてみます。
4つのステップで設定完了
DB Lookupコンポーネントの設定は、4つのステップで構成されています。それぞれの設定内容を、主に参照テーブル（ルックアップ元）の設定を中心に見ていきましょう。ステップ1：ルックアップ元のデータベースコネクターを選択（Choose input connection）
ルックアップ用データを保持しているデータベースコネクターを選択します。ここで選んだコネクターから、参照テーブルまたはクエリ結果が読み込まれます。
ステップ2：参照元の定義と一致方式を決める（Lookup properties）
ルックアップ元の読み取り方法と、キーが一致した場合／一致しなかった場合の挙動を設定します。 Lookup source（ルックアップ元）- Table Direct：単一のテーブルをそのまま読み取ります
- Lookup schema / Lookup table：読み取り対象のスキーマとテーブルを指定します
- Custom SQL Query：SQLクエリの実行結果を読み取ります
- Query：ルックアップデータとして使用するSQLクエリを指定します
- Exact match：キーを完全一致で比較します
- Case insensitive：テキストキーの大文字・小文字を区別せずに比較します
- Fuzzy：類似度でスコアリングし、しきい値以上で最もスコアの高い一致を返します（詳細は後述の「Fuzzyマッチについて」を参照してください）
- Return nulls：ルックアップ列にnullを出力します
- Use default values：ステップ3で設定したデフォルト値を出力します
- Fail pipeline：ジョブを停止します
- First record（既定）：最初に一致した行を返します
- Last record：最後に一致した行を返します
- Fail pipeline：ジョブを停止します
- Return null：nullを返します
Fuzzyマッチについて
- Similarity threshold（類似度しきい値、0〜100） 一致とみなす最小スコアです。既定値は85で、値を大きくすると判定が厳密に、小さくすると緩やかになります。
-
Fuzzy algorithm（アルゴリズム）
- Levenshtein（既定）：文字の編集距離でスコアリングします。タイプミスや短いつづりの違いへの対応に最適です
- Jaro-Winkler：先頭部分の一致を高く評価します。氏名や略称の照合に有効です
- Soundex：発音で照合し、スコアは100または0のいずれかのみを返します。Robert / Rupertのように発音が似た名前の照合に有効ですが、Soundexでは類似度しきい値は機能しません
- キーマッピングは1組のみに対応しており、複合キーでのFuzzy一致はできません
- 比較は常に大文字・小文字を区別しません
- 最高スコアが複数行で同点になった場合は、When multiple rows matchの設定に従います
- しきい値未満のスコアは「一致なし」として扱われ、When no match is foundの設定が適用されます
- 入力行ごとにルックアップテーブル全体を走査するため、Fuzzyを使う場合はテーブルを十分小さく（目安として10万行を大きく下回る規模に）保ってください
ステップ3：照合するキーを対応付ける（Key mapping）
入力フィールドと、照合対象となるルックアップ列を対応付けます。
- Upstream field（上流フィールド）：マッピングに使う、先行するコンポーネントからのフィールド
- Lookup column（ルックアップ列）：Upstream fieldと照合する、ステップ2で定義したルックアップ元のフィールド
- 複合キーで照合したい場合は、「+ Add key mapping」で行を追加します
- 複数のマッピングを設定した場合、すべての条件を満たしたときのみ一致（論理AND）と判定されます
ステップ4：出力する列を選ぶ（Return schema）
出力に含める列を選択します。出力は「そのまま通過させる上流列」と「ルックアップから返す列」を組み合わせたものになります。Available fieldsパネルには2つのタブがあります。- Upstream fields：入力元から渡される列です。データ型は上流のコンポーネントによって決まります
- Lookup Table：ルックアップテーブルまたはクエリ結果の列が表示されます
どんなデータに向いているか
小規模な参照（マスタ）テーブルとの結合を想定したコンポーネントです。主に1対1の関係性を持つデータが対象になりますが、1対多の関係性であっても、マッチング設定次第で1対1の関係性としてデータを取得できます。- 国コード／通貨コード
- ステータスコード・区分コード
- 商品カテゴリ、商品マスタ
- ユーザーID → 氏名／メールアドレスの対応表
ユースケース3選
- 注文データに商品マスタの情報を付加する（基本形） 注文データにはproduct_idしか含まれていないため、レポート用に商品名と価格を付加したいケースです。
- 未一致でも必ず値を埋める（デフォルト値の活用） 商品マスタに未登録のproduct_idが存在していても、後続の集計処理を止めたくないケースです。
- 表記ゆれのある会社名を突き合わせる（Fuzzy match） Webフォームから届いたリード情報の会社名（自由入力）を、CRMの企業マスタと突き合わせて企業IDを付加したいケースです。
使う前に押さえておきたい制限
制限事項
- テーブルサイズの目安 目安として10万行未満のテーブルが適しています。ルックアップ元のテーブルまたはクエリ結果は全件がメモリに読み込まれるため、非常に大きなテーブルには向きません。大規模なデータ同士の結合にはJoin変換を使用してください。
- 対応しているソースの種類 現時点ではデータベースのみに対応しています。ソースがデータベース以外（REST API、ファイルなど）の場合は、従来通りJOINコンポーネントを使用してください。
注意点
- データ量に関する制限 ルックアップテーブルまたはクエリ結果は全件がメモリに読み込まれるため、目安として10万行未満に抑えてください。大規模データ同士の結合にはJoin変換を使用してください。また、Fuzzy使用時は入力行ごとにルックアップテーブル全体を走査するため、テーブルサイズの影響が特に大きくなります。
-
機能上の制限
- Fuzzy一致はキーマッピング1組のみに対応しており、複合キーには使用できません。Soundexはスコアが100か0のいずれかのみで、類似度しきい値は機能しません
- キーマッピングした列同士のデータ型が非互換の場合（数値とテキストの組み合わせなど）、一致は発生しません
- 出力列のエイリアスが重複していると、インライン警告によりPreviewとSaveがブロックされます
- プレビューの挙動 Previewはスキーマインポーターを経由して、ルックアップテーブルの先頭1,000行のみを読み込みます。そのため、プレビューで一致したからといって実際のジョブでも一致するとは限りません。最終的な確認は必ず実際のジョブ実行で行ってください。