Skip to main content
GIFRÖST / Compare

Define schema pairs before tables are suggested.

Schema mapping decides where Compare starts looking for matching objects. One source schema can be paired with any target schema, and each side can be filtered before the platform proposes concrete table pairs.

Starting pointChoose the trusted source schema and the target schema to validate.
Flexible pairingThe number of schema mappings is not limited.
Filtering modesUse exact names or wildcard patterns on both sides.
Main benefitReduce noise before table mapping even begins.

How schema mapping works​

This step determines which parts of the source and target environments should be compared against each other. It is the broadest matching layer in the workflow, so good schema mapping reduces manual cleanup later.

Step 01Select source and target schemas

The interface exposes two inputs: Source Schema and Target Schema. Each is populated from the selected databases.

Step 02Create as many schema pairs as needed

A single reconciliation can include multiple schema mappings, and every pair can be edited or removed later.

Step 03Control table visibility inside each pair

Before Compare proposes table pairs, you can filter which tables are even eligible on the source and target side.

OutcomeA cleaner base for automatic table matching

Good schema filters make later table mapping faster, more precise, and easier to review.

Filtering modes​

Each side of the schema pair can apply its own table filter. This is especially useful when a schema contains technical, historical, or temporary tables that should not participate in the comparison.

Mode 01Exact names

Includes all tables from the selected schema with no additional filtering. Use it when the schema is already clean and comparison-ready.

Mode 02Wildcard pattern

Filters tables by name using a pattern such as LOG_%. The rule can be applied as LIKE or NOT LIKE.

When wildcard filtering helps most

Large schemas Narrow the comparison to business tables instead of scanning every object.

Mixed naming conventions Align source and target subsets even when schemas contain extra prefixes.

Temporary exclusions Drop archive, staging, or technical tables without changing the schema itself.

Example schema inventory​

Candidate 1Eligible for pairing
SOURCE_TABLE_1TARGET_TABLE_1
Candidate 2Eligible for pairing
SOURCE_TABLE_2TARGET_TABLE_2
Candidate 3Eligible for pairing
MY_SOURCE_TABLE_1MY_TARGET_TABLE_1
Candidate 4Eligible for pairing
MY_SOURCE_TABLE_2MY_TARGET_TABLE_2
Candidate 5Eligible for pairing
DUMMY_TABLEDUMMY_TABLE
Partial inventoryBinding gap detected
No source candidateMY_DUMMY_TABLE

This view is easier to read as an object inventory than as a flat table because the operator can immediately spot complete source-target candidates and incomplete bindings.

Example pattern matches​

Rule set 12 resolved
SOURCE_%TARGET_%
SOURCE_TABLE_1 = TARGET_TABLE_1SOURCE_TABLE_2 = TARGET_TABLE_2
Rule set 22 resolved
MY_SOURCE_%MY_TARGET_%
MY_SOURCE_TABLE_1 = MY_TARGET_TABLE_1MY_SOURCE_TABLE_2 = MY_TARGET_TABLE_2
Rule set 32 resolved
SOURCE_%MY_TARGET_%
SOURCE_TABLE_1 = MY_TARGET_TABLE_1SOURCE_TABLE_2 = MY_TARGET_TABLE_2
Rule set 41 resolved
DUMMY_TABLE%_TABLE
DUMMY_TABLE = DUMMY_TABLE
Rule set 5No resolved pair
DUMMY_TABLETARGET_%_
No table pair entered the candidate set

Pattern design directly affects which table pairs are proposed later. If the source and target filters do not produce a compatible set, Compare will have nothing meaningful to match.