DB Lookup変換の紹介
世の中のサービスで扱うデータは、整合性を保つために重複しないデータ構造を持っています。
この重複しないデータ構造は、データの保存スペースも節約できるなどの様々な長所の一方で、数多い、かつ小さな塊に分離されます。
元々は1つのデータ構造で格納された内容が、重複しない構造に変換によって性質が異なるデータになります。
このように分離されたデータ同士は、共通のキーで元のデータに復元出来ます。データベースだとよくご存知のJoinによる結合がその復元に使われます。
Xplentyではデータ同士の結合には今まではJOINコンポーネントを使っておりました。データベースやAPIからのデータを共通のキーで繋げましたが、結合の数が多くなればなるほどデータ処理のロジックが分かりにくくなってしまう問題がありました。
今回、紹介するDB Lookup変換は、JOINコンポーネントと同じ役目を担うが、データ処理のロジックを簡略化出来るとても優れたコンポーネントです。
JOINコンポーネントとの違い
同じ結合を、両方の方法で組んでみる
簡単な結合の例だと下記のような2つのテーブルを1つにまとめることでしょう。

この結合をJOINコンポーネントとDB Lookupでそれぞれ実装してみると下記の図の通りです。
ご覧のように結果は同じですが、DB Lookupの方が1つのコンポーネントで完結するため、データを流れがよりシンプリになっています。

また、参照系のテーブルとの結合が多くなるに伴れ、パッケージの内容が煩雑になったり、データの流れが把握しにくくなりました。それに反してDB Lookupの例では一直線でとてもスッキリした流れになります。
3つの結合を行う処理をJOINコンポーネントとDB Lookupコンポーネントでそれぞれ実装の模様をご覧頂ければ一目瞭然です。

4つのステップで設定完了
DB Lookupコンポーネントの設定は、4つのステップに構成されています。各々の設定内容は見てみましょう。主に参照テーブルを意味するルックアップ元を設定が
ステップ 1: ルックアップ元のデータベースコネクターを選択(Choose input connection)
ルックアップ用データを保持しているデータベースコネクターを選択し、そこから参照テーブルまたはクエリ結果が読み込まれます。

ステップ 2: 参照元の定義と一致方式を決める(Lookup properties)
ルックアップ元の読み取り方法と、一致時/未一致時の挙動を設定します。
- Look source
- Match type(一致方式)
- Exact match: キーを完全一致で比較
- Case insensitive: テキストキーの大文字・小文字を無視して比較
- Fuzzy: 類似度でスコアリングし、しきい値以上の最良一致を返す(詳細内容は、<< Fuzzyマッチについて >> をご参照ください)
- When no match is found(未一致時)
- Return nulls: ルックアップ列にnullを出力
- Use default values: 設定したデフォルト値を出力(ステップ3で設定)
- Fail pipeline: ジョブを停止する
- When multiple rows match(複数一致時の対応)
- 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 では類似度しきい値は無効)
※ Fuzzy 使用時の注意点
- キーマッピングは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 つのタブがあります。
どんなデータに向いているか
小規模な参照(マスタ)テーブルの利用を想定しています。主に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 のみで、類似度しきい値は機能しません
- キーマッピングした列同士のデータ型が非互換の場合、一致が発生しません(数値 vs テキストなど)。
- 出力列のエイリアスが重複していると、インライン警告により PreviewとSave がブロックされます
- プレビューの挙動
Preview はスキーマインポータ経由でルックアップテーブルの先頭 1,000 行のみを読み込みます
そのため、プレビューでの一致が実ジョブでの一致を保証するわけではありませんので、最終確認は必ず実際のジョブ実行で行ってください。
まとめ — 結合ロジックを1コンポーネントに畳む
如何でしょうか?
JOINのような結合が出来るけれどもパッケージのデータ処理ロジックをよりシンプリに作ってくれるDB Lookupコンポーネントはとても魅力だと思います。
今まで、JOINコンポーネントの使用で疲れている方には朗報だし、今からXplentyでデータパイプラインを構築する方にはより分かりやすいロジックを組められるのではないかと思います。
よりシンプリになったXplenty、公式ホームページの今すぐデモ予約にて今すぐ試してみませんか?






