Schema Mapping Review¶
Procedure — instantiates Mapping Reconciliation
A structured review of field-to-field, class-to-class, type-to-type, or entity-to-entity mappings across systems or datasets.
Schema Mapping Review is the disciplined, element-by-element procedure for reconciling two structural representations — the fields of one database against the fields of another, the classes of one object model against another, the entity tables of two systems being merged. Its defining move is that it works at the level of the schema's own structure: for each source element it fixes the corresponding target element and pins down the structural facts of the link — data type, cardinality, direction, nullability, transformation — and then rolls those decisions into one canonical schema map that a migration or integration can execute against. It cares about whether a customer_id is a stable key or a per-region sequence, whether status is one enum in system A and three flags in system B — not about whether the word "customer" means the same thing to two teams. That structural focus is exactly what separates it from its meaning-oriented twin.
Example¶
Two companies merge, and with them two CRM databases. Sales-side Account records must be reconciled against support-side Organization records so a single unified system can be built. A Schema Mapping Review first bounds the job: source = the sales schema v6, target = the support schema v3, scope = the account and contact tables only — the billing tables are explicitly out. The reviewers then walk each field. Account.name maps cleanly to Organization.legal_name, one-to-one, string-to-string. But Account.owner is a single user reference while Organization allows a team of owners — a one-to-many cardinality mismatch that the procedure records as such, choosing "collapse to primary owner, retain the rest as secondary_owners." Account.region is a free-text field; Organization.region is a controlled code list, so the record notes a type coercion plus a lookup. The output is a canonical schema map: a signed-off table of every field pair with its type, cardinality, and transformation, complete enough that an engineer can build the migration without re-deciding anything.
How it works¶
- Bound the pair, then freeze it. Fix exactly which two schemas, which versions, and which subset of elements are in scope, so the review does not sprawl into a general integration debate.
- Enumerate, don't sample. Every in-scope element gets a row; the procedure's rigor is that no field is left implicitly "obvious."
- Record the structural facts per pair. For each correspondence, capture type compatibility, cardinality (1:1, 1:n, n:1), direction, and any required transformation — the facts an executor needs, not the rationale a debate needs.
- Consolidate into one canonical map. The reviewed pairs are merged into a single authoritative schema mapping that supersedes the competing originals for the defined migration purpose.
Tuning parameters¶
- Element granularity — table-level, field-level, or value-level review. Finer granularity catches type and enum mismatches but multiplies the row count; coarse review is fast but ships hidden coercions.
- Coverage rule — exhaustive versus risk-sampled. Exhaustive review guarantees no field is missed but is expensive on wide schemas; sampling is cheaper and riskier.
- Transformation depth — whether the map records only the correspondence or the full coercion logic. Recording logic makes the map executable but pushes the review toward implementation.
- Sign-off strictness — how many reviewers must approve each contested pair. More sign-off reduces error but slows throughput.
- Direction — one-way (source→target for a migration) or bidirectional (for ongoing sync). Bidirectional maps must resolve round-trip loss and cost far more to certify.
When it helps, and when it misleads¶
Its strength is executable precision: because it fixes the structural facts of every field pair, its output can be handed to an engineer and run, with far less back-and-forth than a prose crosswalk. It is the natural tool for migrations, master-data consolidation, and integration work where the schemas are known and the question is genuinely "which field goes where, and how does the type survive the trip."
Its failure mode is structural false equivalence: two fields with the same name and type are mapped as identical when their meaning diverges[1] — an impedance mismatch the procedure is blind to, because it inspects shape, not sense. A classic misuse is running the review on fields whose real conflict is semantic (two teams' incompatible definitions of "active customer") and declaring victory when the types line up, shipping a map that is structurally sound and substantively wrong. The guarding discipline is to route any pair whose disagreement is about meaning out of this procedure and into meaning-oriented reconciliation, and to keep the review honest about what it certifies: structural fit, not conceptual agreement.
How it implements the components¶
Schema Mapping Review realizes the structural correspondence face of the archetype:
mapping_scope_pair— the review's first act is bounding exactly which two schemas, versions, and element subset are being reconciled.correspondence_record— each field pair becomes a record carrying type, cardinality, direction, and transformation, the structural facts of the link.canonical_mapping— the reviewed pairs consolidate into one authoritative schema map that downstream migration uses in place of the competing originals.
It does NOT implement the meaning-preservation side — traceability_record (a running memory of prior interpretive decisions) or residual_ambiguity_log — that is Translation Memory Review, its hazard-twin; the separating fact is that this review certifies structural fit and publishes a canonical schema map, while the twin certifies meaning and instead keeps a running translation memory plus a residual log. Nor does it run the validation_test, which is Code Crosswalk Validation.
Related¶
- Instantiates: Mapping Reconciliation — the element-by-element, structural way to perform the archetype.
- Sibling mechanisms: Crosswalk Reconciliation Workshop · Ontology Alignment Session · Mapping Conflict Matrix · Translation Memory Review · Code Crosswalk Validation · Standard-Setting Process · Reconciliation Report
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Schema Mapping Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a structured review of field-to-field, class-to-class, type-to-type, or entity-to-entity mappings across systems or datasets.
Independent corroboration: The frozen evidence defines Schema Mapping Review as 'A structured review of field-to-field, class-to-class, type-to-type, or entity-to-entity mappings across systems or datasets', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Reviewing field, class, type, and entity correspondences across systems is data integration and software interoperability engineering. NIST defines schemas to support semantic and syntactic interoperability, while Library of Congress crosswalks demonstrate information-science stewardship of concrete mappings.
Related originating lineages:
- Data Science & Analytics — data_science contributes measurement, dashboards, mapping, and operational analytics to the mechanism's formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
- Library & Information Science — Schema Mapping Review's terminology and operating form—a structured review of field-to-field, class-to-class, type-to-type, or entity-to-entity mappings across systems or datasets—are rooted most directly in library and information-science stewardship.
- Organizational & Management Science — organizational_management contributes ownership, decision rights, operating routines, and institutional learning to the mechanism's formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
Review resolution: The blind reviewers disagreed on primary lineage (computer_science versus library_information_science); authoritative or primary research supports computer_science as the best historical origin. Reviewing field, class, type, and entity correspondences across systems is data integration and software interoperability engineering. NIST defines schemas to support semantic and syntactic interoperability, while Library of Congress crosswalks demonstrate information-science stewardship of concrete mappings. The cited NIST, Attribute Metadata Schema for Interoperability; Library of Congress, MODS Conversions and Mappings directly supports the defining operation used in that choice. All independently supported contributing domains are retained without an arbitrary cap, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NIST, Attribute Metadata Schema for Interoperability
- Library of Congress, MODS Conversions and Mappings
References¶
[1] Euzenat, J., & Shvaiko, P. Ontology Matching. 2nd ed., Springer Berlin Heidelberg (2013). Treats divergent meaning across heterogeneous ontologies as a semantic matching problem. registry ↩