RACT: Retrieval Augmented Column-Table Learning and Prediction for Multi-Table Schema Matching

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

RACT: Retrieval Augmented Column-Table Learning and Prediction for Multi-Table Schema Matching

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

databases datamanagement sql storage

databases, sql, data management, storage

arXiv:2606.07843v1 [cs.DB] 5 Jun 2026

RACT: Retrieval Augmented Column-Table Learning and Prediction for Multi-Table Schema Matching Leonard Traeger

Enas Khwaileh

University of Maryland, Baltimore County, USA [email protected]

Utrecht University Utrecht, The Netherlands [email protected]

Andreas Behrend

George Karabatis

Technical University of Cologne Cologne, Germany [email protected]

University of Maryland, Baltimore County, USA [email protected]

Abstract Schema matching, a critical task for integrating data from diverse sources, seeks to identify correspondences between columns across different schemas. In multi-table (holistic) schema matching, columns with similar semantic meaning may reside in tables with different contexts due to heterogeneous schema designs, where similaritybased techniques are inadequate. The focus of this paper is exploiting referential context into schema matching by introducing RACT learning and prediction, a self-supervised framework enabling the probabilistic retrieval of candidate tables for source columns to constrain relevant column candidates. Experiments demonstrate that this approach outperforms similarity-based baselines on matching multi-table schemas. In subsequent matching experiments, constraining the column search space via top-t tables improves both average matching precision and completeness by up to +70%.

Keywords Data Integration, Schema Matching, Referential Constraints ACM Reference Format: Leonard Traeger, Enas Khwaileh, Andreas Behrend, and George Karabatis. 2026. RACT: Retrieval Augmented Column-Table Learning and Prediction for Multi-Table Schema Matching. In . ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

Introduction

Schema matching is a core process in data integration that aims to identify semantically related elements across heterogeneous data models, such as those found in enterprise data, cloud spaces, and marketplaces. The matching task alone is not trivial due to linguistic and design conflicts between the schemas. Existing schema matching methods focus on two-table matching and encode column metadata (e.g., column name, data types, constraints) or the actual records (i.e., instance-based matching) into embeddings using pretrained encoder-based language models. While these embeddings are highly effective at capturing direct semantic correspondences using similarities [11, 15, 19, 29, 35, 39], they struggle to resolve contextual matches, that is, matches across relational tables that convey different contexts. Conference’17, July 2017, Washington, DC, USA 2026. ACM ISBN 978-x-xxxx-xxxx-x/YY/MM https://doi.org/10.1145/nnnnnnn.nnnnnnn

Figure 1: Example of direct (straight) and contextual (dashed) column matches in multi-table schema matching. Motivating example. Relational schemas vary due to applicationspecific requirements that result in different logical design choices (e.g., ER-Modeling). For example, Figure 1 illustrates two schemas from the retail domain on customers and orders. The TPCH schema stores the customer entities along with addresses in its C_CUSTOMER table with a separate country table N_NATION. Conversely, schema CO-Oracle stores customer profiles in the table CUSTOMERS and their logistics data separately in SHIPMENTS. Column alignments between the tables C_CUSTOMER and CUSTOMERS are straightforward. For instance, C_CUSTKEY and C_NAME of table C_CUSTOMER directly match (solid lines) to CUSTOMER_ID and FULL_NAME of table CUSTOMERS. This occurs because the two tables are semantically equivalent, they share the same context, and for such cases, comparing their entire metadata using similarities also yields high scores. Therefore, matching columns residing in tables with similar contexts correctly encode into precise embeddings for similarity-based matching. On the contrary, column matches with different table contexts are more challenging. Consider, for example, the column pairs C_ADDRESS from table C_CUSTOMER and DELIVERY_ADDRESS from table SHIPMENTS (connected through a dashed line). Both represent an ‘address’ related to a customer and they should match, even though their host tables differ in context. C_ADDRESS is a property of the customer, whereas DELIVERY_ADDRESS describes a logistical event, two completely different table contexts that both associate with a customer. Furthermore, considering that the DELIVERY_ADDRESS column also contains country names, it should also be matched to TPCH’s N_NAME column in the countries table N_NATION (second dashed line).

Figure 2: Schema Matching with Column-Table Prediction.

Problem: When we match columns that are contextually related to each other, they may sometimes belong to tables that are dissimilar. Consequently, their embeddings would be positioned away from each other, deeming them as non-matching. However, these contextually related columns should match despite their low embedding similarity. Unfortunately, all supervised [3, 35, 39], active learning [22, 38], and LLM-based [19, 28, 29] frameworks employ embedding similarity, resulting in erroneous matches. We need a matching solution that recognizes the context of each column based on existing referential constraints of its host table. Ideally, when matching TPCH’s column C_ADDRESS to the Oracle schema, one would first retrieve relevant tables such as CUSTOMERS and its structurally bound SHIPMENTS table and then better contextualize DELIVERY_ADDRESS as a similar concept. In this paper, we propose a novel framework for matching relational schemas: To overcome the problem of matching columns across tables with different contexts, we propose to first rank relevant candidate tables for source columns. Therefore, we transform each schema into a graph where the nodes represent tables and the edges represent referential constraints. Subsequently, we enrich columns with referential context from the graph and use their embeddings to self-supervise a neural model for host table prediction. Such learned models can be applied to other source schemas for constraining the search process from similarity (approximations) to target table predictions (probabilities). Figure 2 illustrates our framework as a complementary preceding phase to classical matching. We probabilistically constrain the column vector space by ranking table candidates (dotted) while preserving classical column matching using similarities (straight). Our contributions are the following: • A formal description of Column-Table Learning and Prediction to automatically navigate through relational schemas for holistic multi-table matching (Section 3). • A technique to transform relational schemas into graphs for generating retrieval augmented columns (Section 4.a). • A novel self-supervised methodology to automatically predict top-t table candidates, which contain the relevant target column for matching (Section 4.b) • An empirical evaluation of table candidate retrieval to convey the practical effectiveness of the proposed framework (Section 5). We show that our self-supervised models excel at generic (up to +13%) and larger (up to +24%) target schemas compared to a similarity-based baseline. The Holistic approach remains robust as well as efficient because only one model is required for all schemas in a scenario. • An ablation study of Column-Table Prediction for a Blocking and Matching pipeline that empirically validates an improvement in the completeness (recall) and quality (mAP) of schema matches (up to +70%).

Related Work

To the best of our knowledge, no prior work employs self-supervised learning for column-driven target table retrieval for holistic schema matching. Therefore, we review related work on traditional and language model-driven schema matching techniques. Traditional Schema Matching. Classical methods [26] either use schema metadata linguistics like column names, data types, and constraints (schema-based) such as Cupid [20] or COMA [9]. Notably, Similarity Flooding [23] converted relational schemas into graphs to propagate similarity. We also transform relational schemas into graphs, but for encoding referential context into column serializations. Alternatively, the overlap in column values (instance-based) signals similarity [6, 13, 37]. While values provide meaningful column context useful for matching, value overlap primarily signals joinability [16, 31, 40], which does not resolve contextual differences across tables. We evaluate the impact of combining schema with instance-based matching using semantic embeddings in Section 5. The hybrid system COMA++ aggregates weighted similarities based on learning them from other validated scenarios [2]. However, we holistically self-supervise Column-Table patterns among multiple relational schemas in order to probabilistically constrain the search space before fine-grained matching. Language Model-Driven Schema Matching. In modern approaches [4, 7, 15, 32], encoder-based language models are trained [6] or employ pre-trained ones [27] to transform serialized columns into embeddings. They are essential [19, 29] for efficient and effective scaling down of multi-source matching tasks by quickly approximating exponential search spaces (via Blocking) for subsequent fine-grained ranking using similarities (via Matching with e.g., Cosine or LLM re-ranking). Hättasch et al. propose a two-step approach that first blocks candidate table pairs to then match column embeddings using similarity [11]. Similarly, LLMATCH proposes a table selection phase that maps source-to-target tables [36]. Both techniques use separate table-table similarities to constrain the search space of column matching. In our approach, we bridge the conceptual column and table layers using Column-Table Learning. Alternatively, LEAPME [3], Unicorn [35], and SMUTF [39] represent supervised techniques to calibrate matching weights from annotated scenarios. Furthermore, PoWareMatch [30], Zhang et al. [38], and Alfa [22] propose active learning frameworks to reduce human labeling cost. Remadi et al. propose to validate and rerank column matches using decoder-based language models (LLM) [28]. Finally, Magneto extends LLMs as rerankers for fine-tuning encoderbased language models [19]. Notably, each of these approaches adopts similarity-based techniques to derive candidate matches for its specialized matching framework. Our approach self-supervises Column-Table patterns as a preceding phase for complementing candidate retrieval. In this context, Sheetrit et al. recently proposed to approximate the search space from column-column to Column-Table retrieval using embedding similarity (ReMatch’s Candidate Target Tables Retrieval) [29]. Inspired by self-supervised learning [34], we propose self-supervising the Column-Table patterns of schemas for retrieving candidates for external source columns. This puts our probabilistic Column-Table framework in direct comparison with ReMatch’s similarity-based retrieval, evaluated in Section 5.

(a) Retrieval Augmented Columns (Input Features and Learning Targets)

(b) Self-Supervised Column-Table Learning (Training) (c) Column-Table Prediction (Inference)

Figure 3: RACT Learning and Prediction Framework for Schema Matching

Problem Formulation

We are given a set of relational schemas 𝑆 = {𝑆 1, 𝑆 2, . . . , 𝑆𝑘 } that we refer to as a schema matching scenario. Each schema 𝑆𝑘 = {𝑡𝑘1 , 𝑡𝑘2 , . . . , 𝑡𝑘𝑖 } contains a set of tables and each table 𝑡𝑘𝑖 = {𝑐𝑘1 , 𝑐𝑘2 , . . . , 𝑐𝑘 𝑗 } contains a set of columns. For multi-source matching, the columns of one schema 𝑆𝑘 are aligned with at least another schema 𝑆𝑚 . The alignment between the schemas is not fully bijective, since they may include one-to-one and one-to-many linkages as well as non-correspondences. Schema Matches: We define the alignment between schemas as the set of column pairs between them: 𝑀 (𝑆) = {(𝑐𝑘 𝑗 , 𝑐𝑚𝑛 ), . . . : 𝑡𝑘𝑖 ∈ 𝑆𝑘 ∧ 𝑡𝑚𝑙 ∈ 𝑆𝑚 ∧ 𝑐𝑘 𝑗 ∈ 𝑡𝑘𝑖 ∧ 𝑐𝑚𝑛 ∈ 𝑡𝑚𝑙 } where 𝑆𝑘 , 𝑆𝑚 ∈ 𝑆 and 𝑘 ≠ 𝑚. A column pair (𝑐𝑘 𝑗 𝑐𝑚𝑛 ) represents semantic congruence as a symmetric relationship. Note that the set of all truly matched (correctly aligned) column pairs 𝑀 (𝑆) is unavailable in practice but constitutes the ideal output set (ground truth) of matches. Definition 1. Match Types: To assess the capability of handling schemas with heterogeneous data models, we partition the matches 𝑀 (𝑆) into two disjoint types based on the table contexts of columns:

Then, they would identify relevant tables to filter the search space to a contextualized subset of candidate columns (ref. [29]). Inspired by this human-oriented search process, our goal is to replicate this semantic intuition automatically. In order to computationally navigate through the logical schema, we aim to learn the latent distribution between the columns (attributes) and how they belong to the tables (entity types). Definition 2. Column-Table Learning. Given a schema 𝑆𝑘 , we learn a logical model L : 𝑐𝑘 𝑗 → 𝑡𝑘𝑖 that maps columns to their host tables. We formally define this as a function 𝑓𝑘 that predicts the probability distribution over the set of base tables 𝑆𝑘 = {𝑡𝑘1 , 𝑡𝑘2 , . . . , 𝑡𝑘𝑖 } given a column’s semantic context: 𝑓𝑘 (𝑐𝑘 𝑗 ) = 𝑃 (𝑡𝑘𝑖 ∈ 𝑆𝑘 | 𝑐𝑘 𝑗 )

where a high probability indicates that the column 𝑐𝑘 𝑗 semantically belongs to table 𝑡𝑘𝑖 . The goal of our work is to learn such a function for each schema. With a learned Column-Table model, we aim to search for correspondences of columns in external schemas 𝑐𝑚𝑛 ∈ 𝑆𝑚 by first predicting their top-t tables before fine-grained top-k column matching oc(1) Direct Matches (𝑀𝑑𝑖𝑟 ): Column matches 𝑐𝑘 𝑗 𝑐𝑚𝑛 (e.g., curs. Consequently, we first predict a column’s most contextually FULL_NAME C_NAME) where congruence is evident by the serelevant tables and reduce the search space by eliminating false mantics of host tables 𝑡𝑘𝑖 and 𝑡𝑚𝑙 (e.g., CUSTOMERS C_CUSTOMER). positive candidate columns. Similarity-based methods typically succeed here. (2) Contextual Matches (𝑀𝑐𝑡𝑥 ): Column matches under differing 4 Method normalization levels (e.g., vertical partitioning), where the RACT Learning is a self-supervised framework that precedes clashost tables of the column match 𝑐𝑘 𝑗 𝑐𝑚𝑛 (e.g., DELIVERY_ sical schema matching by constraining candidate host tables for a ADDRESS C_ADDRESS) are not direct semantic counterparts column from an external schema. We illustrate our framework in (e.g., SHIPMENTS ≠ C_CUSTOMER). Instead, the host table 𝑡𝑘𝑖 Figure 3 that consists of the three sequential phases, i.e., (a) Retrieval of column 𝑐𝑘 𝑗 has an adjacent table 𝑡𝑘 𝑦 , reachable via relaAugmented Columns, (b) Self-Supervised Column-Table Learning, and tionships (e.g., referential constraints), that represents the (c) Column-Table Prediction for more effective schema matching. direct counterpart of the column 𝑐𝑚𝑛 pairs’ table 𝑡𝑚𝑙 (e.g., In contrast to established matching pipelines, RACT encodes refSHIPMENTS Z CUSTOMERS C_CUSTOMER). These kinds of erential information into column embeddings as well as in the matches require resolving the schema context (e.g., logical self-supervised learning task for predicting candidate tables. modeling via referential constraints). Overview. In the first phase (a), we represent schemas as di-

Intuitively, a domain expert does not search for matches by sequentially comparing a query column 𝑐𝑚𝑛 against every potential target column in the tables of schema 𝑐𝑘 𝑗 ∈ 𝑡𝑘𝑖 ∈ 𝑆𝑘 . Instead, they would follow a top-down hierarchical search by navigating through the logical schema 𝑆𝑘 (e.g., looking at the ER diagram).

rected graphs for our retrieval augmentation procedure that encodes column context (input features) and table origins (learning targets). In the second phase (b), each schema self-supervises a feedforward neural network architecture to learn the latent distribution between columns to tables (training). In the last phase (c),

we apply the learned models for semantic Column-Table Prediction (inference) among the schemas in order to constrain contextually relevant tables before fine-grained column matching. (a) Retrieval Augmented Columns. We propose an augmentation strategy inspired by Retrieval-Augmented Generation (RAG) [17]. However, instead of retrieving unstructured text to better answer a query, we generate relational paths between tables as views that we use for augmented column representations. For example, Figure 3.a.I shows the serialized information of the original DELIVERY_ADDRESS column in the Oracle schema. It does not contain any customer context which is a problem for matching. However, serializing the column from the generated view between CUSTOMERZSHIPMENTS adds customer context (table names concatenation → view name). Hence, our rationale for column augmentation is twofold: First, integration usually necessitates conjunctive queries (e.g., contextual addresses in Figure 1). Consequently, join transformations in one schema 𝑆𝑘 (ref. ‘parallel schema realities’ [10]) may contribute to matching it to another schema 𝑆𝑚 . Second, as we aim to implement Column-Table Learning (ref. Definition 2) with data-hungry neural networks in a robust way, we advocate for increasing the column training examples. Algorithm Overview: The complete procedure for generating referential-aware column embeddings (input features) and soft multi-table labels (target features) is outlined in Algorithm 1. (a.I) Relational Schema Graph (Lines 1-2): We intend to incorporate logical modeling concepts into the schema matching process. In practice, the primary (PK) and foreign key (FK) definitions can be easily extracted from the DDL or metadata (e.g., USER_CONSTRAINTS in Oracle or INFORMATION_SCHEMA in MySQL). Alternatively, they can be profiled via functional dependencies with methods [1, 14, 16, 21, 25] that are complementary but out of scope in this work. To generate referential-aware column embeddings, we start by representing a schema as a graph. Formally, we adopt the definition by Paganelli et al. on Schema Graphs (introduced for computing Full Disjunctions) [24]. However, we extend it with explicit graph directionality because our augmentation relies on join path traversals between tables. Specifically, we observe that undirected traversals reflect random (indiscriminate) join paths, which ignore the conceptual (Entity-Relationship) data model of a schema [8]. For example, consider the CO_ORACLE schema where the transactional table SHIPMENTS references both CUSTOMERS and STORES. An undirected traversal could generate a path CUSTOMERS → SHIPMENTS → STORES, semantically clustering two independent entity types. By enforcing directionality of the ER hierarchy between strong and weak entity types, we prevent overlays between semantic concepts. The above traversal terminates at CUSTOMERS → SHIPMENTS so that generated views retain their semantic core concepts. Also, the number of generated views is reduced at the same time. Definition 3. Directional Schema Graph: Given a schema with tables 𝑆𝑘 = {𝑡𝑘1 , 𝑡𝑘2 , . . . , 𝑡𝑘𝑖 } and referential constraints 𝑅𝑘 = {(𝑡 strong , 𝑐 strong , 𝑡 weak , 𝑐 weak )} (𝑡 strong ≠ 𝑡 weak self-references excluded), we create a directional graph 𝐺𝑘 . For directionality, we strictly define 𝑡 strong as the referenced table (contains primary key 𝑐 strong ) and 𝑡 weak as the referencing table (contains foreign key 𝑐 weak ). Based on these primitives, the Directional Schema Graph 𝐺𝑘 = (𝑉𝑘 , 𝐸𝑘 ) is a graph where vertices 𝑉𝑘 represent the tables in 𝑆𝑘 .

Algorithm 1 Retrieval Augmented Columns ⊕ Input: 𝑆𝑘 = {𝑡𝑘1 , 𝑡𝑘2 , . . . , 𝑡𝑘𝑖 } schema tables, 𝐸 language encoder, 𝑅𝑘 = {(𝑡 strong , 𝑐 strong , 𝑡 weak ,𝑐 weak )} schema references, 𝑑𝑖𝑟 = {directed, inverse, undirected} directionality, 𝑑 max visited tables as view, 𝜆 decay factor for multi-table labels Output: Retrieval Augmented Columns 1: 𝐺𝑘 ← InitGraphVertices({𝑡𝑘 1 , 𝑡𝑘 2 , . . . , 𝑡𝑘𝑖 }) 2: 𝐺𝑘 ← InitGraphEdges(𝑅𝑘 , 𝑑𝑖𝑟 ) //Unweighted. 3: 𝑃𝑘 = {𝑝 1 , 𝑝 2 , . . . , 𝑝𝑧 } ← AllShortestPaths(𝐺𝑘 , 𝑑 max ) //Generate acyclic shortest paths between tables 𝑝𝑧 = {𝑡𝑘𝑎 , . . . , 𝑡𝑘𝑏 } as uniquely augmented views where |𝑝𝑧 | ∈ [1 : 𝑑 max ]. Includes singletons for original schema tables where |𝑝𝑧 | = 1. 4: 𝑅𝐴𝐶𝑘 ← ∅ 5: for all 𝑝𝑧 ∈ 𝑃𝑘 do 6: for all 𝑐𝑘 𝑗 ∈ 𝑡𝑘𝑖 ∈ 𝑝𝑧 do 𝑝 7: 𝑐𝑘 𝑧 ← Copy(𝑐𝑘𝑖 ) //Init augmented column. 𝑖 𝑝 8: 𝑐𝑘 𝑧 .table_name ← ConcatNames(𝑝𝑧 ) 𝑖 𝑝 9: 𝑐𝑘 𝑧 .weak_tables ← GetAdjacentTables(𝑝𝑧 , weak) \ 𝑝𝑧 𝑖 𝑝 10: 𝑐𝑘 𝑧 .strong_tables ← GetAdjacentTables(𝑝𝑧 , strong) \ 𝑝𝑧 𝑖 𝑝 𝑝 11: 𝑥®𝑘 𝑧 ← 𝐸 (𝑐𝑘 𝑧 ) //Embedding (input features). 𝑖 𝑖 𝑝𝑧 𝑝 12: 𝑦®𝑘 ← SetMultiTableLabels(𝑐𝑘 𝑧 , 𝜆) //Exponential 𝑖 𝑖 decay for table labeling (learning targets). 𝑝𝑧 𝑝𝑧 13: 𝑅𝐴𝐶𝑘 ← 𝑅𝐴𝐶𝑘 ∪ {(𝑥®𝑘 , 𝑦®𝑘 )} 𝑖 𝑖 14: end for 15: end for ®𝑘 , 𝑌®𝑘 ) 16: return 𝑅𝐴𝐶𝑘 = (𝑋

The edges 𝐸𝑘 are derived from 𝑅𝑘 and the directionality parameter 𝑑𝑖𝑟 where ‘directed’ reflects 1 → 𝑁 expansion (𝑡 strong → 𝑡 weak ), ‘inverse’ reflects 𝑁 → 1 expansion (𝑡 weak → 𝑡 strong ), and ‘undirected’ represents simple connectivity (ref. [24]). (a.II) Shortest Paths as Views (Line 3): With the graph 𝐺𝑘 established (Line 1-2 in Algorithm 1), we identify join paths to generate views. Specifically, we apply shortest path traversal between 𝑑𝑚𝑎𝑥 maximum visited tables to control view explosion and maintain semantic core table concepts. Formally, we define a View Path 𝑝 as an acyclic sequence of vertices (tables) traversing through edges (join paths) in 𝐺𝑘 . Each path 𝑝 ∈ 𝑃𝑘 (Line 3) represents a view with a custom join operator. We use Z 𝜃 to retain all columns. (a.III) Serialization (Lines 7-10) and Embedding (Line 11): First, we describe the process of transforming our retrieval augmented columns into input features used for Column-Table Learning (b). For every column in an augmented view, we retrieve the referential context according to its table composition and neighboring tables for its serialization. Then, we use pre-trained language encoders such as Sentence-BERT [27] to transform the sequences of words (serialization) into an embedding, a fixed-sized latent vector. Formally, given an encoder-based language model 𝐸 and some serialization 𝑠 = {𝑤 1, 𝑤 2, . . . , 𝑤𝑑 }, first each word 𝑤𝑑 ∈ 𝑠 is encoded into a set of embeddings. Consolidated as a matrix, the encoder transforms it via pooling in order to output a single condensed embedding 𝑒® ∈ R𝑑 that captures the serialization’s meaning.

Following the work in Unicorn [35] and Magneto [19], we serialize the columns in a similar way. In extension to their two-table matching objective, we additionally include the table name (i.e., ConcatNames) into each column’s serialization to contextualize column boundaries for learning multi-table associations. Based on the findings in Magneto’s verbose serialization variant, we also add prefixes “Column:”, “Table:”, “Type:”, “Constraint:”, and “Values:” which act as semantic anchors within the latent space of our neural network architecture. Similarly, we use the “[CLS]” token as a serialization convention that indicates the start of a column and “[SEP]” to control Sentence-BERT’s pooling mechanism such that column metadata components are treated as discrete features. We consider the following serialization approaches: 𝑝

𝑝

𝑆𝑒𝑟 schema (𝑐𝑘 𝑧 ) =[CLS] Column: 𝑐𝑘 𝑧 .name [SEP] Table: 𝑐𝑘 𝑧 .table_name 𝑗

𝑗

𝑝

[SEP] Type: 𝑐𝑘 𝑧 .type [SEP] Constraint: 𝑐𝑘 𝑧 .constraint 𝑗

𝑗

𝑆𝑒𝑟 schema represents the classical schema-based matching approach based on Rahm and Bernstein survey [26]. Here, the 𝑝 𝑐𝑘 𝑧 .constraint explicitly labels key columns as “PRIMARY KEY”, 𝑗 “FOREIGN KEY REFERENCES. 𝑡 strong (𝑐 strong )’, or combined. Note that this referential context is only embedded for columns that represent keys. For example, only the column CUSTOMER_ID in Oracle tables SHIPMENTS contains “...[SEP] Constraint: FOREIGN KEY REFERENCES CUSTOMERS (CUSTOMER_ID)”. On the other hand, the column DELIVERY _ADDRESS in the same SHIPMENTS table has no explicit CUSTOMER contextualization (i.e. “...[SEP] Constraint: None”). 𝑝

𝑝

𝑆𝑒𝑟 +values (𝑐𝑘 𝑧 ) =[CLS] Column: 𝑐𝑘 𝑧 .name [SEP] Table: 𝑐𝑘 𝑧 .table_name 𝑗

𝑗

𝑝

[SEP] Type: 𝑐𝑘 𝑧 .type [SEP] Constraint: 𝑐𝑘 𝑧 .constraint 𝑗

𝑗

𝑝

[SEP] Values: 𝑐𝑘 𝑧 .value1 , . . . , 𝑐𝑘 𝑧 .value5 𝑗

𝑗

𝑆𝑒𝑟 +values extends the former serialization with column values (instances) (ref. [19]), representing hybrid-based matching. To measure the impact of table names, we set 𝑆𝑒𝑟 magneto as 𝑆𝑒𝑟 +values without the table component. For both, we prevent noise from lengthy text fields (e.g., BLOBs in a DESCRIPTION column) to not surpass SentenceBERT’s token limit of 512 by only using up to five first values and truncate them to a maximum of 300 tokens (ref. [19]). While values provide context, due to distribution shifts, the embeddings of some columns that actually match may become dissimilar. For example, the matching columns FULL_NAME (CO-Oracle) and C_NAME (TPCH) likely contain disjoint sets of customer names although they refer to the same semantic concept. In such cases, matching with the schema-based approach would be more effective.

a column within a table by using the directed schema graph. It is particularly important for resolving ambiguity in our Column-Table Learning approach (ref. Definition 2). For instance, a domain-expert might mistakenly match TPCH’s C_ADDRESS from table CUSTOMERS with CO-Oracle’s WEB_ADDRESS or PHYSICAL_ADDRESS columns in table STORES, as both are addresses (ref. Figure 2). Particularly for matching relational schemas, we need to consider the referential context for effective table retrieval. Therefore, the function GetAdjacentTables introduced in Algorithm 1 retrieves the weak and strong tables of a column’s host table or tables (in case of augmented view). For example, Figure 3.a.III shows different serializations of Oracle’s DELIVERY_ADDRESS column. Both retrieve the referential context of weak entity types GetAdjacentTables((SHIPMENTS, CUSTOMER), weak) → ORDER_ITEMS and ORDERS that are similar to TPCH’s C_ADDRESS (i.e., GetAdjacentTables(C_CUSTOMER, weak) → O_ORDERS), aligning the attribute pairs closer in the semantic vector space. Note that the addition of the referential context is strictly derived from the table information of a column (i.e. GetAdjacentTa𝑝 bles(𝑐𝑘 𝑧 .table_name)). This way, the context of the column em𝑖 beddings are forced to adjust to the table surroundings within the schema graph. However, some column semantics may result in convoluted context. For example, all columns in CO-Oracle’s SHIPMENTS table (e.g., SHIPMENT_ID) are also contextualized with CUSTOMERS even though they represent different concepts. We mitigate such cases via graph directionality and 𝑑 max -limited views. Generally, when a column does not have constraints, values, or strong and weak tables, we concatenate “None” to the corresponding prefix value. In Section 5, we study the individual impacts of the serialization variants for Column-Table Prediction and Matching. (a.III) Labeling (Line 12): Finally, we now describe the generation of the learning targets for the columns. Note that any augmented column from a view is treated as a materialized combination of base tables. Hence, we only encode host tables into a multi-class vector. Naively, we could encode it as a one-hot vector. However, the binary notion would normalize the original Column-Table semantics. For example, columns from a view path would equally belong to all of its traversed tables. Therefore, we quantify the table distances from the originating host table of an column with soft-labels. In line 12, the function SetMultiTableLabels generates soft labels 𝑝 for each augmented column’s multi-table vector 𝑦®𝑘 𝑧 ∈ [0, 1] |𝑆𝑘 | . 𝑖 𝑝𝑧 Let 𝑡𝑜𝑟𝑖𝑔𝑖𝑛 be the table where column 𝑐𝑘 resides in the original 𝑖 schema, and 𝑡𝑘𝑖 ∈ 𝑝𝑧 be any traversed table in its augmented view path. We assign a column belonging to a schema’s tables 𝑆𝑘 using the exponential decay function as follows:

𝑝

𝑦®𝑘 𝑧 = 𝑝 𝑝 𝑝 𝑆𝑒𝑟 +reference (𝑐𝑘 𝑧 ) =[CLS] Column: 𝑐𝑘 𝑧 .name [SEP] Table: 𝑐𝑘 𝑧 .table_name 𝑗 𝑗 𝑗 𝑝 𝑝 [SEP] Type: 𝑐𝑘 𝑧 .type [SEP] Constraint: 𝑐𝑘 𝑧 .constraint 𝑗 𝑗 𝑝 𝑝 [SEP] Values: 𝑐𝑘 𝑧 .value1 , . . . , 𝑐𝑘 𝑧 .value5 𝑗 𝑗 𝑝 [SEP] Weak Tables: 𝑐𝑘 𝑧 .weak_tables 𝑗 𝑝 [SEP] Strong Tables: 𝑐𝑘 𝑧 .strong_tables 𝑗

𝑆𝑒𝑟 +reference is one of our contributions. It further extends the above serialization approaches by adding the referential context of

𝑖

( 𝑒 −𝜆·𝑑 (𝑡𝑜𝑟𝑖𝑔𝑖𝑛 ,𝑡 ) 0

if 𝑡 ∈ 𝑝𝑧 if 𝑡 ∈ (𝑆𝑘 \ 𝑝𝑧 )

where 𝑑 (𝑡𝑜𝑟𝑖𝑔𝑖𝑛 , 𝑡) returns the originating table distance in the schema graph 𝐺𝑘 and 𝜆 ∈ (0, 1) is the decay hyperparameter. The intuition behind soft labels is a means for balancing the independent column semantics while learning the referential schema context, controlled via 𝜆 uniformly set to 0.5. For example, the column DELIVERY_ADDRESS from the augmented view path between the tables CUSTOMERS (distance 1) and SHIPMENTS (origin) results in the target vector {CUSTOMERS=0.606, STORE=0, SHIPMENTS=1, . . . }.

Table 1: RACT Dataset with Retrieval Augmented Columns by Graph Directionality and Shortest Path Depth. Schema

#Tab./#Col.

𝑑𝑖𝑟 ectionality

𝑑 max =2

𝑑 max =3

𝑑 max =4

𝑑 max =5

𝑑 max =6

directed/inv. 16 / 156 18 / 192 undirected 25 / 269 45 / 654 49 / 746 directed/inv. 15 / 173 20 / 299 23 / 403 24 / 445 CM-MySQL 8 / 59 undirected 22 / 287 36 / 629 48 / 1013 56 / 1333 62 / 1611 directed/inv. 16 / 180 23 / 337 26 / 417 27 / 457 TPCH 8 / 61 undirected 24 / 299 44 / 753 58 / 1177 64 / 1393 directed/inv. 36 / 312 52 / 583 60 / 753 64 / 852 Sakila 15 / 70 undirected 55 / 530 101 / 1312 145 / 2249 187 / 3366 211 / 4104 The #Tab./#Col. column provides the original (i.e., 𝑑 max =1) number of tables and columns of a schema. Each 𝑑 max column provides the number of views (shortest path traversals |𝑃𝑘 |) and augmented columns of a schema. CO-Oracle

7 / 43

(b) Self-Supervised Column-Table Learning. In this phase, we implement the learning objective established in Definition 2. We instantiate the function 𝑓𝑘 using a Multilayer Perceptron (MLP) in order to learn the non-linear latent space between columns and tables in a schema. Therefore, the model takes the retrieval augmented column embeddings and processes them through two fully connected hidden layers. The final layer applies a Sigmoid activation to predict the independent probability of a column belonging to each table in 𝑆𝑘 . Before presenting our three model types (b.I) Single, (b.II) Pairwise, and (b.III) Holistic, we first elaborate on a general loss modification for our learning task. Focal Loss for Recall: Even with augmented path views, a column’s multi-table-label vector will associate membership with a small fraction of tables (sparse positives), while the vast majority are irrelevant (dense negatives). Consequently, the learning targets 𝑦® contain predominantly zeros. Standard loss functions (e.g., Binary Cross Entropy) will tend to converge to the trivial solution of predicting no table memberships at all in order to maximize accuracy. However, with our retrieval objective (c) that is similar to Blocking, we prefer a model that recommends plausible but incorrect tables over entirely missed ones. Therefore, we adopt Focal Loss [18] to counter extreme class imbalances. By down-weighting the losses of ‘easy’ negatives (e.g., CUSTOMER_ID does not belong to PRODUCTS), we force the gradient updates to focus on the sparse positive table labels (e.g., correctly map EMAIL_ADDRESS to CUSTOMERS). (b.I) Single. The naive approach is training a MLP model 𝑓𝑘 independently for each schema 𝑆𝑘 by using only its column embeddings 𝑋®𝑘 ∈ 𝑅𝐴𝐶𝑘 . However, the optimization of 𝑓𝑘 is non-trivial. Generally, the learned schema function 𝑓𝑘 should perform well on predicting its target tables 𝑌®𝑘 ∈ 𝑅𝐴𝐶𝑘 for its own columns (training phase). Secondly, the model should effectively predict candidate host tables for external 𝑆𝑚 schema columns (inference phase). Due to heterogeneity in nomenclature and normalization, the input column embeddings of one schema 𝑆𝑘 differ from those of another schema 𝑆𝑚 . Therefore, a learned function 𝑓𝑘 based on (b.I) will generalize less effectively to external schemas unless the matching columns embed nearly identically. Referring to the example provided in Figure 1, a model type (b.I) may still accurately predict correct host tables for semantically similar encoded columns. However, it will struggle predicting contextual ones as it cannot generalize to external columns that it has not seen during training.

𝑑 max =7 64 / 1721 221 / 4426

(b.II) Pairwise. To improve generalization, we propose training a MLP model on the union of input features 𝑋®𝑘𝑚 ← 𝑋®𝑘 ∪ 𝑋®𝑚 and the concatenation of learning targets 𝑌®𝑘𝑚 ← (𝑦®𝑘 , 𝑦®𝑚 )|𝑦®𝑘 ∈ 𝑌®𝑘 ∧ 𝑦®𝑚 ∈ 𝑌®𝑚 from two schemas. Consequently, we expose the model to the column embeddings and multi-table labels of both schemas that we intend to match. Notably, we also increase the number of input columns (training examples) naturally. However, the learning targets (complexity) increase as well. Learning with Masked Loss: Since we only have access to the multi-table labels of columns from their originating schema, we employ masked loss over the undefined table labels from the other schemas. Preciously, when training one column embedding of one schema 𝑋®𝑘 , we mask the prediction loss of the undefined table labels from the other schema 𝑌®𝑚 and vice versa. Consequently, the model is not penalized for the unknown table labels while the shared layers still learn generalized features. Note that the pairwise approach generalizes among columns between two schemas, but the number of model trainings increases quadratically with the number of schemas in a scenario 𝑂 (|𝑆 | 2 ). (b.III) Holistic. In the context of enterprises, cloud spaces, and data marketplaces, matching scenarios often involve more than two schemas |𝑆 | > 2. To achieve scalability, we extend the pairwise approach (b.II) to a holistic one that unions the inputs and concatenates the targets for all schemas in the matching scenario 𝑆 = {𝑆 1, 𝑆 2, . . . , 𝑆𝑘 }. This enables the model to learn universal Column-Table patterns across all schemas, effectively reducing the number of required models in a scenario from 𝑂 (|𝑆 | 2 ) (b.II) to 𝑂 (1). However, this shared learned model type increases the training data and learning target dimensionality. Nonetheless, we consider its input scale and complexity favorable to neural learning. (c) Column-Table Prediction. Once the Column-Table model 𝑓 is learned via either of the b.I, b.II, or b.III model types, we deploy it to predict the table context for external schema columns. Given a set of query columns from a source schema 𝑆𝑘 , we first encode the original columns of base tables (classical matching) into embeddings 𝑋®𝑘 (ref. Phase (a) at 𝑑𝑚𝑎𝑥 =1). We then perform a forward pass using the trained model 𝑓 to compute the probability distribution over the target tables in 𝑆𝑚 . For each query column 𝑐𝑘 𝑗 , the model outputs a likelihood score for the base tables 𝑡𝑚𝑙 ∈ 𝑆𝑚 : ŷ𝑚 = 𝜎 (𝑓 (𝑥®𝑘 𝑗 )) 𝑆𝑚

where ŷ𝑚 ∈ [0, 1] |𝑆𝑚 | represents the vector of predicted probabilities of column 𝑐𝑘 𝑗 belonging to the semantic context of the tables in 𝑆𝑚 . Note that for pairwise (b.II) and holistic (b.III) model types, this vector is a projection (slice) of the table indices of schema 𝑆𝑚 . Instead of a strict threshold (e.g., > 0.5 for Focal Loss in (b)), we rank the target tables by their predicted probability scores. Then, we constrain the top-t tables with the highest scores as the candidate set. Consequently, the traditional pipeline with column blocking (i.e., top-k columns) and matching (e.g., cosine similarity) is restricted exclusively to the columns of the top-t table candidates. Note that we aim to retrieve those tables needed to resolve both direct and contextual matches. While our referential-aware columns and pairwise/holistic model types aim to optimize high recall at lower top-t table cardinalities for candidate retrieval, they may still introduce false negatives and impact fine-grained matching.

Evaluation

In this section, we evaluate our RACT Column-Table Learning and Prediction framework as well as its impact on traditional schema matching pipelines. We first describe the experimental setup and introduce the evaluation metrics. Overall, we observe that: (1) Our self-supervised Pairwise and Holistic model types consistently achieve higher mean recall @top-t tables than ReMatch’s similarity-based baseline for both generic (up to +13%) and larger (up to +24%) target schemas. (2) In an ablation study, @top-t table prediction improves @top-k column matching in both recall and mAP (up to +70%).

5.1

Experimental Setup

With our RACT framework, we focus on holistically matching relational schemas with each other, each containing multiple tables that are connected via referential constraints. This way, we are able to evaluate Algorithm 1 and all proposed model types (ref. b.I-b.III). To this end, we curated a dataset consisting of four open-source relational schemas with semantically meaningful metadata from the retail domain: CO-Oracle1 , CM-MySQL2 , TPCH3 , and Sakila4 . Limitations of existing benchmarks: Unfortunately, common schema matching benchmarks such as those provided by the Valentine project [15] are not suitable for evaluating RACT because they consist of only table-to-table scenarios; matching a single source table to a single target table. This two-table setting applies to Wikidata5 , ChEMBL, Magellan6 , Magneto’s biomedical GDC [19], and SMUTF’s HDXSM [39]. Finally, we acknowledge recent multi-table matching scenarios in healthcare alignment by ReMatch [29] and LLMatch [36]. However, all these scenarios match source schemas to the single OMOP7 model (𝑆𝑠 → 𝑆𝑡 ) and not holistically among all of them (𝑆 1 ↔ 𝑆 2 ↔ . . . ↔ 𝑆𝑘 ) as we do. Retrieval Augmented Columns. Table 1 displays an overview of the number of tables and columns of each schema. Additionally, we 1 Oracle sample schemas: https://github.com/oracle-samples/db-sample-schemas 2 Classicmodels (MySQL tutorial schema): https://www.mysqltutorial.org/getting-

started-with-mysql/mysql-sample-database/ 3 TPCH https://www.tpc.org/TPCH/ implemented at scale-factor=1 via DuckDB 4 Sakila (MySQL sample schema): https://dev.mysql.com/doc/Sakila/en/ 5Wikidata Musicians: https://www.wikidata.org/ 6 Magellan: https://sites.google.com/site/anhaidgroup/useful-stuff/ 7 OMOP Common Data Model: https://www.ohdsi.org/data-standardization/

show the number of views and augmented columns of each schema at maximum traversed tables 𝑑 max value (ref. Algorithm 1). Note that the augmentation via directed or inverse graph directionalities is identical. Conversely, undirected graph traversals generate nearly as twice more views and augmented columns. For the CO-Oracle, CM-MySQL, and TPCH schemas, the augmentation of columns increases at a similar rate due to comparable table numbers (seven to eight). However, the Sakila schema (15 tables) returns nearly twice as many view paths. In our evaluation, we employ RACT learning with original (𝑑 max =1) and directed 𝑑 max =2 augmentation. We exclude undirected and depth 𝑑 max ≥ 3 parameter values as they mix semantic core table concepts and have shown to introduce noise to the learning task. Annotated Matches by Type. The ground truth was manually annotated by analyzing the ER diagrams and data samples, verified by two external data scientists. In Table 2, we provide an overview of the symmetric column matches between the six matching scenarios, categorized as direct or contextual matches. Note that each schema pair alignment presents its unique challenges. For instance, COOracle (i.e., SHIPMENTS) and Sakila (i.e., ADDRESS) store addresses in separate tables from customers. Incorporating referential context is needed to disambiguate column matches that yield high similarity scores. For example, the OFFICE table in CM-MySQL and the SUPPLIER table in TPCH share nearly identical columns (e.g., CODE, ADDRESS, PHONE). However, their referential contexts reveal distinct concepts. OFFICE is referenced by EMPLOYEES and CUSTOMERS (sales context), whereas SUPPLIER is linked to PARTSUPP and LINEITEM (manufacturing context). Hence, we did not annotate any matches between them. Lastly, while Sakila also models the retail domain, it specializes on film rentals. While it contains straightforward matches for its columns in CUSTOMER, ADDRESS, and STORE tables to the corresponding columns in the other retail schemas, we need to consider its referential semantics to correctly align the film rental tables with the other retail schemas. For example, TPCH↔Sakila contains column matches between ORDER≃RENTAL and PART≃FILM tables. Serialization and Embedding. We test all serialization variants in our RACT framework and encode them using Sentence-BERT8 [19, 39]. For RACT Learning and Prediction, we employ 𝑆𝑒𝑟 +reference serialization as it yielded the highest validation accuracy. Column-Table Learning Hyperparameters: We train the Single (b.I), Pairwise (b.II), and Holistic (b.III) model types with homogeneous neural network architectures. The MLP network comprises 8 Sentence-BERT (all-mpnet-base-v2) is reported as the best general purpose model (https://www.sbert.net/docs/sentence_transformer/pretrained_models.html).

Table 2: Scenarios and 𝑀 (𝑆) Annotated Matches by Type. Matching Scenario CO-Oracle ↔ CM-MySQL CO-Oracle ↔ TPCH CO-Oracle ↔ Sakila CM-MySQL ↔ TPCH CM-MySQL ↔ Sakila TPCH ↔ Sakila

Direct (𝑀𝑑𝑖𝑟 )

Contextual (𝑀𝑐𝑡𝑥 )

17 (63%) 23 (92%) 15 (54%) 24 (80%) 22 (56%) 22 (65%)

10 (37%) 2 (8%) 13 (46%) 6 (20%) 17 (44%) 12 (35%)

27 25 28 30 39 34

a densely connected 768 → 512 → 256 architecture with dropout (0.2) and ReLU activations along with a final Sigmoid layer that predicts the multi-table vector. While these and other hyperparameters could be fine-tuned individually for each model type based on schema input and target complexity, we keep hyperparameters constant to ensure a controlled evaluation environment between the architectural strategies. As we aim for a model that accurately captures all Column-Table patterns among the schemas (training), for each model type, we split the input column embeddings into 80% (train) 20% (validation) using stratified sampling and learn a 5-fold cross-validation ensemble. This way, we ensure generalization among the schemas across the entire column population at the cost of increased training time. We set the batch size to 16 to ensure granular gradient updates from individual column embeddings. We set both the Adam learning rate and L2-regularization to a low 0.001 value in order to ensure the model has the flexibility to learn subtle distinctions. Generally, we aim for a model that retains column-identity specificity (corresponds to classical similarity matching) while projecting it into the latent table space. Stronger regularization suppresses subtle cues that are needed to distinguish nearly identical CUSTOMER_ID embeddings in the table CUSTOMERS from one in SHIPMENTS. Finally, we perform a grid-search for the 𝛼 parameter in our adapted Focal Loss. We uniformly set 𝛼=0.9, as higher values consistently improved validation accuracy by focusing on the sparse positive classes (correct table or table composition of view paths). The higher weight to the positive class aligns with our recall-oriented blocking objective for Column-Table Prediction. Column-Table Baseline. We implement ReMatch’s successful similarity-based Target Table Retrieval [29]. Their approach is computationally efficient as it does not require additional model training but heavily relies on data catalogs with rich descriptions9 . While LLMs could synthesize column (e.g., SEALM [33] or SMUTF [39]) or table descriptions, accurately capturing contextual matches (e.g., TPCH’s PART_KEY and ORDERDATE to Sakila’s FILM_ID and RENTAL_DATE) inherently requires the referential schema context that our framework provides. We leave LLM-integration for future work and focus in this evaluation strictly on the retrieval mechanism itself, excluding orthogonal data augmentation. We replicate ReMatch by using 𝑆𝑒𝑟 schema (𝑐𝑘 𝑗 ) for source columns and adapt their table document structure into the following serialization: 𝑡 𝑆𝑒𝑟 ReMatch (𝑡𝑚𝑙 ) =[CLS] Table: 𝑡𝑚𝑙 .name

[SEP] Primary Keys: {𝑐.name 𝑐.type | 𝑐 ∈ 𝑡𝑚𝑙 .pks} [SEP] Foreign Keys: {𝑐.name 𝑐.type 𝑐.ref | 𝑐 ∈ 𝑡𝑚𝑙 .fks} [SEP] Columns: {𝑐.name 𝑐.type | 𝑐 ∈ 𝑡𝑚𝑙 .other}

Blocking and Matching. For Blocking, we implement embeddingbased retrieval using the FAISS library [12]. For each scenario, we build an IndexFlatL2 (Exact Nearest Neighbor) for interchanging target schema to efficiently retrieve similar top-k={1, 2, 3, 5, 10, 20} column candidates of the source schema. Note that while our ground truth matches 𝑀 ({𝑆 1, . . . , 𝑆𝑘 }) represent symmetric relationships between the schemas, the candidate sets retrieved via blocking differ based on the source (query items) and target (search 9 MIMIC-OMOP healthcare matches: https://github.com/meniData1/MIMIC_2_OMOP

items) schema assignments. For Matching, we compute the Cosine similarity for the candidates, ranked in descending order.

5.2

Evaluation Approach and Metrics

We evaluate our RACT framework in two stages. First, we measure the performance of our RACT Prediction models (b.I-III) against ReMatch [29]. Second, we measure its impact on similarity-based schema Blocking and Matching as an ablation study. Column-Table Prediction. We evaluate it as a semantic blocking mechanism. Therefore, we measure whether a source column successfully retrieves the host table of the matching target column. To this end, we adapt the annotated ground truth of schema matches 𝑀 (𝑆) (ref. Section 3) to Column-Table pairs 𝑀 ′ (𝑆). For every column pair (𝑐𝑘 𝑗 , 𝑐𝑚𝑛 ) ∈ 𝑀 (𝑆), we derive the target table 𝑡𝑚𝑙 where the matching column 𝑐𝑚𝑛 resides: 𝑀 ′ (𝑆) = {(𝑐𝑘 𝑗 , 𝑡𝑚𝑙 )|∃𝑐𝑚𝑛 : (𝑐𝑘 𝑗 , 𝑐𝑚𝑛 ) ∈ 𝑀 (𝑆) ∧ 𝑐𝑚𝑛 ∈ 𝑡𝑚𝑙 } We report Recall@top-t, defined as the proportion of query columns 𝑐𝑘 𝑗 for which the host table 𝑡𝑚𝑙 appears in the top-t table predictions sorted by the model’s output probabilities ŷ𝑚 . Ablation Study for Schema Matching. Secondly, we evaluate the impact of constraining the search space via @top-t table prediction on classical schema matching pipelines. Note that the maximum @t table cardinality value is equivalent to searching through the columns from all tables (no RACT Prediction ≡ baseline). First, we compute the standard Recall@top-k column metric [5, 15, 19]. Secondly, we compute the Mean-Average Precision (mAP) mAP@top-k column metric that extends classical precision. Specifically, it considers whether all of the true linkages tend to get ranked highly as an overall score for recommending relevant matches. Note that we compute mAP exclusively for query columns that have a match in the ground truth 𝑀 (𝑆), thereby isolating the ranking performance for linkable columns.

5.3

Results

Column-Table Prediction. The Recall@top-t scores of each pairwise matching scenario are reported in Table 3 using 𝑆𝑒𝑟 +reference serialization. To ensure validity, we trained each model type over ten independent runs and provide the mean recall performance with standard deviation at each top-t table cardinality. For each scenario, we compare our Pairwise and Holistic model types against the two baselines: the naive Single model and the similarity-based ReMatch retrieval. Without column augmentation, the Single model type contains insufficient training examples, which is why we only report the mean recall performance with retrieval augmented columns at 𝑑 max =2. However, for the Pairwise and Holistic model types, we naturally increased the training samples by merging the columns between two or more schemas. To discuss the model type performances among all scenarios, we cluster them into three categories based on the table prediction complexity: Mean(Sakila≠target): First, we discuss the mean recall of all scenarios with CO-Oracle, CM-MySQL, or the TPCH as target schemas due to the similar number of target tables (seven to eight). At @top-t=1, Single(2) reaches 0.454 and ReMatch 0.573 recall on average, whereas both the Holistic(2) (0.628) and Pairwise(1) (0.647)

models outperform the naive Single (+43%) and ReMatch baseline (+13%). At @top-t=2, the Pairwise(2) model with augmented columns slightly overtakes the un-augmented one from 0.771 to 0.785, both on par with ReMatch (0.787). The Holistic(2) model exceeds both baselines by +3% (0.81). Notably, we observe that ReMatch performs competitively in scenarios that predominantly contain direct matches (ref. Table 2), such as CM-MySQL⇔TPCH (80% direct matches) and CO-Oracle⇔CMMySQL (63% direct matches). While Pairwise models still outperform ReMatch at @top-t=1 in CM-MySQL→ CO-Oracle (0.667 vs. 0.593), CO-Oracle→CM-MySQL (0.938 vs. 0.810), CM-MySQL→TPCH (0.7 vs. 0.633), the learned Column-Table predictions provide marginal gains at higher @top-t values than the similarity baseline. Considering the mean recall performance across all smaller target schema scenarios at @top-t=3, Holistic(2) achieves 0.935 recall and consistently outperforms ReMatch and Pairwise models up to +6% as @top-t increases. In summary, for this set of matching scenarios, we reduce the search space by ≈ 60% (@top-t=3) while maintaining ≥ 90% ground truth matches. Mean(Sakila=target): Secondly, we report the mean recall of all scenarios that predict Sakila’s 16 target tables. The Column-Table prediction task is more complex, evidenced by the ReMatch baseline dropping to a starting recall of 0.446. The shared latent space enforcement in Pairwise and Holistic model types consistently outperform ReMatch and require lower top-t cardinality for full recall. However, in contrast to the simpler scenarios, models trained without view augmentation perform better. The Pairwise(1) model achieves +24% higher recall at @top-t=1 (0.551) than ReMatch. Interestingly, retrieval augmented columns at 𝑑 max = 2 consistently degrade performance (e.g., Pairwise(2) drops to 0.482). We attribute this to Sakila’s higher number of base tables introducing training complexity. Furthermore, Pairwise outperforms Holistic for Sakila targets. Note that Sakila represents a sub-domain (Movie Rental) compared to the generic retail focus of Oracle, TPCH, and MySQL, in essence resulting in a more difficult matching task, therefore, the Holistic model suffers from negative transfer. For example, Sakila’s columns in the FILM and RENTAL tables represent a minority class compared to analogous columns in PRODUCT and ORDER tables. Consequently, for analogous matches, pairwise Column-Table Learning without view-augmented columns tends to be most effective. For the CO-Oracle→Sakila scenario, all methods struggle to match Oracle’s DELIVERY_ADDRESS from table SHIPMENT to Sakila’s CITY and COUNTRY tables. In Sakila, city and country names are located multiple joins away from the customer concept (CUSTOMER → ADDRESS → CITY → COUNTRY). Since we capped the number of traversed tables at 𝑑 max =2, Sakila’s model successfully contextualizes DELIVERY_ADDRESS with the scope of CUSTOMER Z ADDRESS but is prevented from capturing the more distant CITY and COUNTRY context. In summary, for the more complex scenarios for predicting Sakila’s 16 target tables, we reduce the search space by ≈ 80% (@topt=3) while maintaining ≥ 80% ground truth matches. Mean(all): Lastly, we report the recall aggregates across all scenarios to identify a default strategy. At @top-t=1, the Pairwise model without augmentation yields the best recall with 0.623. The

(a)

(b)

𝑆𝑒𝑟 schema

𝑆𝑒𝑟 +values

𝑆𝑒𝑟 magneto

𝑆𝑒𝑟 +reference

Figure 4: Impact of Serialization for Column Blocking (@topk) and Matching (Cosine) measured in Recall (a) and mAP (b) Performance as Mean over all Scenarios.

Holistic(2) model emerges as the strongest overall approach, recovering from the false positive tables predicted at @top-t=1. Specifically, it overtakes all other model types as well as ReMatch at @top-t=2 (0.792), @top-t=3 (0.906), and @top-t=4 (0.963) until all model types converge as @top-t increases. Overall, the similaritybased ReMatch baseline consistently underperforms compared to Pairwise and Holistic models across the top-t table spectrum. Impact of Serialization for Schema Matching. 𝑆𝑒𝑟 +reference yielded higher validation accuracy and recall on ColumnTable Learning. Intuitively, encoding schema context via referential information allows the model to learn the table context more effectively. However, the added referential context (via adding “Weak Table” and “Strong Table”) may not benefit fine-grained column matching. Therefore, we design a study to evaluate the impact of the four different serialization variants using column Blocking (top-k) and Matching (Cosine similarity). In Figure 4, we report the mean recall (y-axis in a) and mean mAP (y-axis in b) over all scenarios at top-k columns (x-axis) with 𝑆𝑒𝑟 schema (dot-cyan), 𝑆𝑒𝑟 +values (square-blue), 𝑆𝑒𝑟 magneto (cross-green), and 𝑆𝑒𝑟 +reference (triangle-purple) as line plots. At any top-k column cardinality, 𝑆𝑒𝑟 +values ranks the best closely followed by 𝑆𝑒𝑟 schema for both recall and mAP, confirming our table extension to [19]. While 𝑆𝑒𝑟 schema and 𝑆𝑒𝑟 +values perform similarly, there is an evident gap (0.05 to 0.1) to the mAP and recall performance of 𝑆𝑒𝑟 magneto and 𝑆𝑒𝑟 +reference . Notably, 𝑆𝑒𝑟 magneto has higher recall deviations among the scenarios (error-bar) than others. Particularly at @top-k=1, we attribute 𝑆𝑒𝑟 magneto weaker mAP to the missing table context needed to preciously identify matches. For 𝑆𝑒𝑟 +reference , on the other hand, the added referential context overlays column semantics and leads to embedding noise instead of

Table 3: Recall Performance (Mean ± Std) by Schema Model Type for Column-Table Prediction (@top-t). Source→Target

Model Type (𝑑 max )

ReMatch Pairwise(1) CM-MySQL → CO-Oracle Pairwise(2) Holistic(1) Holistic(2)

0.593 0.963 1 0.667 ± 0.0 0.7 ± 0.027 0.963 ± 0.0 0.515 ± 0.012 0.648 ± 0.059 0.807 ± 0.023 0.663 ± 0.012 0.707 ± 0.012 0.989 ± 0.018 0.626 ± 0.027 0.733 ± 0.023 0.819 ± 0.054

@top-t 7

14 15 16

1 1 1 1 1

0.960 1 1 1 1

1 1 1 1 1

0.964 1 1 0.964 ± 0.0 0.964 ± 0.0

1 1 1 1 1

TPCH → CO-Oracle

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.440 0.680 0.800 0.880 0.880 0.648 ± 0.017 0.856 ± 0.034 0.912 ± 0.017 0.956 ± 0.013 0.972 ± 0.019 0.596 ± 0.03 0.688 ± 0.017 0.956 ± 0.013 1 1 0.516 ± 0.044 0.792 ± 0.025 0.96 ± 0.0 0.96 ± 0.0 0.96 ± 0.0 0.796 ± 0.035 0.884 ± 0.013 0.948 ± 0.019 0.992 ± 0.017 1

Sakila → CO-Oracle

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.607 0.714 0.893 0.964 0.7 ± 0.018 0.75 ± 0.029 0.993 ± 0.015 0.996 ± 0.011 0.704 ± 0.017 0.857 ± 0.051 0.921 ± 0.023 0.971 ± 0.028 0.679 ± 0.029 0.711 ± 0.026 0.932 ± 0.02 0.946 ± 0.019 0.682 ± 0.046 0.9 ± 0.037 0.957 ± 0.015 0.964 ± 0.0

ReMatch Pairwise(1) CO-Oracle → CM-MySQL Pairwise(2) Holistic(1) Holistic(2)

0.810 0.952 0.952 0.938 ± 0.032 0.962 ± 0.02 0.995 ± 0.015 0.729 ± 0.032 0.962 ± 0.03 1 0.871 ± 0.032 0.957 ± 0.015 0.967 ± 0.023 0.824 ± 0.068 0.948 ± 0.015 0.986 ± 0.023

0.952 1 1 1 1

TPCH → CM-MySQL

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.667 0.917 0.958 1 1 0.488 ± 0.02 0.579 ± 0.054 0.762 ± 0.056 0.9 ± 0.053 0.996 ± 0.013 0.488 ± 0.02 0.717 ± 0.051 0.9 ± 0.022 1 1 0.492 ± 0.018 0.629 ± 0.013 0.892 ± 0.045 0.992 ± 0.018 1 0.496 ± 0.013 0.688 ± 0.029 0.917 ± 0.0 1 1

1 1 1 1 1

Sakila → CM-MySQL

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.564 0.692 0.872 0.923 0.974 0.667 ± 0.021 0.879 ± 0.012 0.918 ± 0.011 0.933 ± 0.018 0.992 ± 0.012 0.587 ± 0.057 0.777 ± 0.017 0.949 ± 0.0 0.949 ± 0.0 0.997 ± 0.008 0.644 ± 0.019 0.897 ± 0.017 0.964 ± 0.013 0.979 ± 0.011 0.987 ± 0.014 0.446 ± 0.013 0.767 ± 0.008 0.972 ± 0.008 0.974 ± 0.0 1

1 1 1 1 1

CO-Oracle → TPCH

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.520 0.680 0.800 0.656 ± 0.021 0.804 ± 0.023 0.952 ± 0.017 0.648 ± 0.041 0.852 ± 0.027 0.948 ± 0.019 0.64 ± 0.027 0.868 ± 0.027 0.96 ± 0.0 0.776 ± 0.028 0.908 ± 0.019 0.96 ± 0.0

0.960 0.996 ± 0.013 0.984 ± 0.021 1 1

1 1 1 1 1

CM-MySQL → TPCH

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.633 0.900 0.967 0.967 1 1 1 0.64 ± 0.026 0.703 ± 0.011 0.857 ± 0.022 0.913 ± 0.032 0.963 ± 0.033 0.987 ± 0.017 1 0.7 ± 0.022 0.847 ± 0.017 0.9 ± 0.0 0.937 ± 0.011 0.96 ± 0.014 0.977 ± 0.016 0.993 ± 0.014 0.633 ± 0.0 0.773 ± 0.034 0.91 ± 0.016 0.97 ± 0.011 0.983 ± 0.018 1 1 0.68 ± 0.017 0.89 ± 0.016 0.993 ± 0.014 1 1 1 1

1 1 1 1 1

Sakila → TPCH

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.324 0.588 0.735 0.882 0.971 0.418 ± 0.023 0.703 ± 0.058 0.894 ± 0.015 0.979 ± 0.024 1 0.35 ± 0.022 0.721 ± 0.037 0.876 ± 0.012 1 1 0.426 ± 0.029 0.615 ± 0.038 0.765 ± 0.031 0.976 ± 0.012 0.979 ± 0.014 0.329 ± 0.012 0.571 ± 0.021 0.868 ± 0.021 0.988 ± 0.015 1

Mean(Sakila≠target)

ReMatch Single(2) Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.573 0.454 0.647 0.591 0.618 0.628

0.787 0.685 0.771 0.785 0.772 0.81

0.886 0.852 0.916 0.918 0.926 0.935

0.920 0.96 ± 0.0 0.96 ± 0.0 0.96 ± 0.0 1

0.943 0.930 0.960 0.980 0.976 0.991

0.920 0.96 ± 0.0 0.96 ± 0.0 0.96 ± 0.0 1

0.968 0.954 0.987 0.991 0.982 0.996

1 1 1 1 1

0.991 0.975 0.998 0.996 1 1

1 0.995 1 0.999 1 1

1 1 1 1 1 1

CO-Oracle → Sakila

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.429 0.619 0.619 0.619 0.762 0.810 0.857 0.857 0.857 0.905 0.952 0.952 0.952 0.624 ± 0.027 0.7 ± 0.045 0.838 ± 0.033 0.857 ± 0.0 0.948 ± 0.027 0.957 ± 0.027 0.967 ± 0.023 0.986 ± 0.023 0.995 ± 0.015 0.995 ± 0.015 1 1 1 0.557 ± 0.023 0.605 ± 0.023 0.786 ± 0.034 0.81 ± 0.0 0.838 ± 0.025 0.867 ± 0.02 0.91 ± 0.042 0.938 ± 0.023 0.948 ± 0.015 0.957 ± 0.015 0.99 ± 0.02 1 1 0.581 ± 0.038 0.714 ± 0.022 0.757 ± 0.035 0.805 ± 0.015 0.862 ± 0.042 0.929 ± 0.034 0.938 ± 0.023 0.952 ± 0.0 0.952 ± 0.0 0.971 ± 0.025 0.995 ± 0.015 0.995 ± 0.015 1 0.524 ± 0.0 0.71 ± 0.035 0.729 ± 0.039 0.767 ± 0.027 0.795 ± 0.023 0.814 ± 0.015 0.843 ± 0.032 0.876 ± 0.033 0.905 ± 0.0 0.91 ± 0.015 0.933 ± 0.033 0.976 ± 0.04 1

1 1 1 1 1

CM-MySQL → Sakila

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.538 0.718 0.769 0.795 0.821 0.821 0.897 0.923 0.633 ± 0.057 0.874 ± 0.028 0.897 ± 0.0 0.931 ± 0.012 0.946 ± 0.015 0.972 ± 0.008 0.985 ± 0.013 0.997 ± 0.008 0.533 ± 0.029 0.828 ± 0.024 0.895 ± 0.008 0.949 ± 0.0 0.949 ± 0.0 0.949 ± 0.0 0.977 ± 0.015 0.997 ± 0.008 0.597 ± 0.047 0.846 ± 0.024 0.892 ± 0.016 0.926 ± 0.008 0.951 ± 0.019 0.974 ± 0.012 0.992 ± 0.012 0.997 ± 0.008 0.423 ± 0.03 0.828 ± 0.042 0.9 ± 0.008 0.946 ± 0.008 0.951 ± 0.008 0.969 ± 0.011 1 1

TPCH → Sakila

ReMatch Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.370 0.593 0.667 0.741 0.741 0.741 0.741 0.778 0.852 0.889 0.396 ± 0.039 0.678 ± 0.068 0.885 ± 0.027 0.941 ± 0.036 0.97 ± 0.016 0.978 ± 0.019 0.993 ± 0.016 0.996 ± 0.012 0.996 ± 0.012 0.996 ± 0.012 0.356 ± 0.05 0.578 ± 0.036 0.837 ± 0.05 0.941 ± 0.031 0.967 ± 0.027 0.985 ± 0.019 0.996 ± 0.012 1 1 1 0.393 ± 0.047 0.678 ± 0.05 0.807 ± 0.057 0.893 ± 0.027 0.967 ± 0.021 0.996 ± 0.012 1 1 1 1 0.378 ± 0.052 0.674 ± 0.046 0.822 ± 0.034 0.93 ± 0.037 0.978 ± 0.026 1 1 1 1 1

Mean(Sakila=target)

ReMatch Single(2) Pairwise(1) Pairwise(2) Holistic(1) Holistic(2)

0.446 0.291 0.551 0.482 0.524 0.442

0.643 0.509 0.751 0.67 0.746 0.737

0.685 0.657 0.874 0.839 0.819 0.817

0.718 0.783 0.91 0.9 0.874 0.881

0.774 0.889 0.955 0.918 0.927 0.908

0.790 0.943 0.969 0.934 0.966 0.928

0.832 0.97 0.981 0.961 0.977 0.948

0.853 0.979 0.993 0.979 0.983 0.959

0.923 1 1 1 1

0.877 0.989 0.997 0.983 0.984 0.968

0.923 1 1 1 1

0.906 0.998 0.997 0.986 0.990 0.970

0.923 1 1 1 1

0.949 1 1 1 1

1 1 1 1 1

0.889 1 1 1 1

0.926 1 1 1 1

1 1 1 1 1

0.921 1 1 0.997 0.998 0.978

0.942 1 1 1 0.998 0.992

0.942 0.942 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1

ReMatch 0.541 0.751 0.836 0.887 0.919 0.941 0.958 0.951 0.877 0.906 0.921 0.942 0.942 0.942 1 1 Single(2) 0.413 0.641 0.804 0.893 0.938 0.967 0.989 0.993 0.989 0.998 1 1 1 1 1 1 Pairwise(1) 0.623 0.766 0.906 0.947 0.979 0.991 0.995 0.998 0.997 0.997 1 1 1 1 1 1 Pairwise(2) 0.563 0.757 0.898 0.96 0.973 0.980 0.990 0.993 0.983 0.986 0.997 1 1 1 1 1 Holistic(1) 0.595 0.766 0.900 0.951 0.968 0.992 0.994 0.994 0.984 0.990 0.998 0.998 1 1 1 1 Holistic(2) 0.582 0.792 0.906 0.963 0.974 0.982 0.987 0.986 0.968 0.970 0.978 0.992 1 1 1 1 𝑡 All RACT models use Retrieval Augmented Columns (ref. Algorithm 1 ⊕) with 𝑑𝑖𝑟 = directed, uniform 𝑑 max value in parenthesis, and 𝜆 = 0.5. ReMatch uses Cosine similarity between column (𝑆𝑒𝑟 schema ) and table (𝑆𝑒𝑟 ReMatch ) embeddings. The best recall per model type are formatted in bold, the second-best in underlined, and the third-best in italic font. Mean(all)

(a) CM-MySQL → CO-Oracle

(b) CO-Oracle → CM-MySQL

(d) CO-Oracle → Sakila

(e) TPCH → CO-Oracle

(f) TPCH → CM-MySQL

(g) CM-MySQL → TPCH

(h) CM-MySQL → Sakila

(i) Sakila → CO-Oracle

(j) Sakila → CM-MySQL

(k) Sakila → TPCH

(l) TPCH → Sakila

@top-k=1

@top-k=2

@top-k=3

@top-k=5

@top-k=10

@top-k=20

Figure 5: Recall Performance (y-axis) at @top-t Table Prediction (x-axis) with Holistic(2) and Blocking @top-k Column (lines). matching signal. Hence, referential context is crucial for ColumnTable learning while harming column-column similarity. Ablation Study for Schema Matching. Based on our previous findings, we evaluate the impact of Column-Table Prediction on the full matching pipeline. First, we train a Holistic model for Column-Table Prediction with 𝑑 max = 2 augmentation of 𝑆𝑒𝑟 +reference serialized column embeddings. Then, we apply classical Blocking and Matching using 𝑆𝑒𝑟 +values serialized column embeddings. In Figure 5, we report the recall performance (y-axis) for each scenario. The x-axis represents Column-Table Prediction at top-t candidates, while the colored lines {1 (cyan), 2 (orange), 3 (green), 5 (red), 10 (purple), 20 (brown)} represent Blocking with top-k column cardinality. Finally, the dashed horizontal lines indicate the baseline performance (maximum @top-t corresponds to unconstrained search) for each top-k column level. Correspondingly, we report mAP performance in Figure 6. As already observed by Bellahsene et al. [5], also each matching scenario in our dataset represents a uniquely challenging solution space. However, we observe the following patterns with our Column-Table Prediction that precedes classical similarity-based matching:

Matching Quality. All scenarios (except a) can benefit from a top-t table constrained search space yielding higher recall at several top-k column cardinalities compared to the full search baseline. Particularly for scenarios (c) and (e), recall and mAP improve by up to +70% @top-k=1-10. For @top-k=20 blocking, recall performance becomes comparable at @top-t=4/5 candidates. The only exception is scenario (d), reaching on-par recall @top-t=10 that we relate to the previously discussed high normalization of ADDRESSES, CITY, and COUNTRY tables. Contextual Alignment. Generally, scenarios with larger shares of contextual matches (d and i), (h and j), and (k and l) struggle at initial top-t table candidates in recall but recover at @top-t=3/4 tables while steadily surpassing baseline mAP performance. With RACT prediction, the contextual matches between Sakila and TPCH (i.e., FILM=PART and RENTAL=ORDER) are revealed by up to +28% recall for scenarios (k) and (l). Notably, scenarios (h) and (k) reach full recall at @top-k=20 column blocking only with a top-t table constraint. This effect demonstrates that the similarity-based spaces can benefit from referential context for matching relational schemas. Setting top-t. We observe that @top-t=4/5 candidates perform onpar or better among most matching scenarios at any top-k column

(a) CM-MySQL → CO-Oracle

(b) CO-Oracle → CM-MySQL

(d) CO-Oracle → Sakila

(e) TPCH → CO-Oracle

(f) TPCH → CM-MySQL

(g) CM-MySQL → TPCH

(h) CM-MySQL → Sakila

(i) Sakila → CO-Oracle

(j) Sakila → CM-MySQL @top-k=1

@top-k=2

@top-k=3

(k) Sakila → TPCH @top-k=5

@top-k=10

(l) TPCH → Sakila @top-k=20

Figure 6: mAP Performance (y-axis) at @top-k Table Prediction (x-axis) with Holistic(2) and Matching @top-k Column (lines). blocking, aligning with our intrinsic method analysis (Table 3). Generally, we advise lower top-t table constraints for lower top-k column blocking. On the other hand, larger top-k column blocking also benefits from larger top-t table constraints. Limitations. First, Column-Table Learning and Prediction is a probabilistic approximation that does not guarantee retrieving accurate host tables at low top-t table cardinalities. Secondly, our approach heavily relies on schema metadata and referential constraints (provided in the RACT dataset), which, in general, are obtainable but may sometimes be incomplete or unavailable. Explainability. Looking beyond top-t constraints as an optimization problem, including the table concepts via column-table candidate retrieval offers practical advantages for human-in-the-loop and LLM frameworks. Unlike opaque similarity scores between columns, RACT recommends semantically meaningful target table names, enabling practitioners (or agents) to intuitively verify and steer the search space in holistic multi-table matching scenarios.

Conclusion

In this paper, we discussed the problem of identifying matches between multiple tables in different contexts. Our RACT framework aims to solve this problem by generating directed schema graphs from relational schemas and learning the referential table context of a column using self-supervised neural network models. Subsequently, given a column in a schema, the learned RACT model predicts appropriate candidate tables of another schema. This approach significantly differs from matching methods that apply similarity-based techniques, since RACT models simultaneously learn probabilistic weights in a shared latent space among all candidate schemas. Evaluations show that our approach is more effective for scenarios containing contextual matches compared to similarity-based approaches for both table retrieval and column matching alone. At the same time, the number of models needed to train among multiple schemas reduces to a single holistically shared RACT model. In the future, we plan to extend RACT with column augmentation that is table-class balanced and weighted join paths in schema graphs.

Artifacts

All experiments were conducted in a Python Jupyter Notebook on an Intel i7-1265U CPU with 32GB memory. All relevant datasets for reproducing the experiments including the relational schemas, referential constraints, annotated ground truth matches, reported experimental results, and the executable Python Jupyter notebook RACT.ipynb are publicly accessible without monitoring in the GitHub repository https://github.com/leotraeg/RACT. A thorough description of the datasets and their origin, as well as a quick-start description of the algorithmic implementation, including performance metrics, is provided in the README.md file.

References [1] Ziawasch Abedjan, Patrick Schulze, and Felix Naumann. 2014. DFD: Efficient Functional Dependency Discovery. In Proceedings of the 23rd ACM International Conference on Conference on Information and Knowledge Management (CIKM ’14). Association for Computing Machinery, New York, NY, USA, 949–958. https: //doi.org/10.1145/2661829.2661884 [2] David Aumueller, Hong-Hai Do, Sabine Massmann, and Erhard Rahm. 2005. Schema and ontology matching with COMA++. In Proceedings of the 2005 ACM SIGMOD international conference on Management of data. ACM, Baltimore Maryland, 906–908. https://doi.org/10.1145/1066157.1066283 [3] Daniel Ayala, Inma Hernández, David Ruiz, and Erhard Rahm. 2022. LEAPME: Learning-based Property Matching with Embeddings. Data & Knowledge Engineering 137 (Jan. 2022), 101943. https://doi.org/10.1016/j.datak.2021.101943 [4] Gilbert Badaro, Mohammed Saeed, and Paolo Papotti. 2023. Transformers for Tabular Data Representation: A Survey of Models and Applications. Transactions of the Association for Computational Linguistics 11 (March 2023), 227–249. https: //doi.org/10.1162/tacl_a_00544 [5] Zohra Bellahsene, Angela Bonifati, Fabien Duchateau, and Yannis Velegrakis. 2011. On Evaluating Schema Matching and Mapping. In Schema Matching and Mapping, Zohra Bellahsene, Angela Bonifati, and Erhard Rahm (Eds.). Springer, Berlin, Heidelberg, 253–291. https://doi.org/10.1007/978-3-642-16518-4_9 [6] Riccardo Cappuzzo, Paolo Papotti, and Saravanan Thirumuruganathan. 2020. Creating Embeddings of Heterogeneous Relational Datasets for Data Integration Tasks. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (SIGMOD ’20). Association for Computing Machinery, New York, NY, USA, 1335–1349. https://doi.org/10.1145/3318464.3389742 [7] Raul Castro Fernandez, Essam Mansour, Abdulhakim A. Qahtan, Ahmed Elmagarmid, Ihab Ilyas, Samuel Madden, Mourad Ouzzani, Michael Stonebraker, and Nan Tang. 2018. Seeping Semantics: Linking Datasets Using Word Embeddings for Data Discovery. In 2018 IEEE 34th International Conference on Data Engineering (ICDE). IEEE, Paris, 989–1000. https://doi.org/10.1109/ICDE.2018.00093 [8] Peter Pin-Shan Chen. 1976. The entity-relationship model—toward a unified view of data. ACM Trans. Database Syst. 1, 1 (March 1976). https://doi.org/10. 1145/320434.320440 [9] Hong-Hai Do and Erhard Rahm. 2002. COMA: a system for flexible combination of schema matching approaches. In Proceedings of the 28th international conference on Very Large Data Bases (VLDB ’02). VLDB Endowment, Hong Kong, China, 610–621. [10] Kai Herrmann, Hannes Voigt, Andreas Behrend, Jonas Rausch, and Wolfgang Lehner. 2017. Living in Parallel Realities – Co-Existing Schema Versions with a Bidirectional Database Evolution Language. In Proceedings of the 2017 ACM International Conference on Management of Data. 1101–1116. https://doi.org/10. 1145/3035918.3064046 arXiv:1608.05564 [cs]. [11] Benjamin Hättasch, Michael Truong-Ngoc, Andreas Schmidt, and Carsten Binnig. 2022. It’s AI Match: A Two-Step Approach for Schema Matching Using Embeddings. https://doi.org/10.48550/arXiv.2203.04366 arXiv:2203.04366 [cs]. [12] Jeff Johnson, Matthijs Douze, and Herve Jegou. 2021. Billion-Scale Similarity Search with GPUs. IEEE Transactions on Big Data 7, 3 (July 2021), 535–547. https://doi.org/10.1109/TBDATA.2019.2921572 [13] Aamod Khatiwada, Grace Fan, Roee Shraga, Zixuan Chen, Wolfgang Gatterbauer, Renée J. Miller, and Mirek Riedewald. 2023. SANTOS: Relationship-based Semantic Table Union Search. Proc. ACM Manag. Data 1, 1 (May 2023), 9:1–9:25. https://doi.org/10.1145/3588689 [14] Henning Koehler and Sebastian Link. 2025. Orthogonal Keys High Precision and Recall for Mining Database Keys From Inconsistent and Incomplete Relations. IEEE Transactions on Knowledge and Data Engineering 37, 11 (Nov. 2025), 6550– 6561. https://doi.org/10.1109/TKDE.2025.3608680 [15] Christos Koutras, George Siachamis, Andra Ionescu, Kyriakos Psarakis, Jerry Brons, Marios Fragkoulis, Christoph Lofi, Angela Bonifati, and Asterios Katsifodimos. 2021. Valentine: Evaluating Matching Techniques for Dataset Discovery.

In 2021 IEEE 37th International Conference on Data Engineering (ICDE). 468–479. https://doi.org/10.1109/ICDE51399.2021.00047 ISSN: 2375-026X. [16] Christos Koutras, Jiani Zhang, Xiao Qin, Chuan Lei, Vasileios Ioannidis, Christos Faloutsos, George Karypis, and Asterios Katsifodimos. 2024. OmniMatch: Effective Self-Supervised Any-Join Discovery in Tabular Data Repositories. https://doi.org/doi:10.14778/3749646.3749715 Version Number: 1. [17] Yangning Li, Weizhi Zhang, Yuyao Yang, Wei-Chieh Huang, Yaozu Wu, Junyu Luo, Yuanchen Bei, Henry Peng Zou, Xiao Luo, Yusheng Zhao, Chunkit Chan, Yankai Chen, Zhongfen Deng, Yinghui Li, Hai-Tao Zheng, Dongyuan Li, Renhe Jiang, Ming Zhang, Yangqiu Song, and Philip S. Yu. 2025. Towards Agentic RAG with Deep Reasoning: A Survey of RAG-Reasoning Systems in LLMs. https: //doi.org/10.48550/arXiv.2507.09477 arXiv:2507.09477 [cs]. [18] Tsung-Yi Lin, Priya Goyal, Ross Girshick, Kaiming He, and Piotr Dollár. 2020. Focal Loss for Dense Object Detection. IEEE Transactions on Pattern Analysis and Machine Intelligence 42, 2 (Feb. 2020), 318–327. https://doi.org/10.1109/TPAMI. 2018.2858826 [19] Yurong Liu, Eduardo H. M. Pena, Aécio Santos, Eden Wu, and Juliana Freire. 2025. Magneto: Combining Small and Large Language Models for Schema Matching. Proceedings of the VLDB Endowment 18, 8 (April 2025), 2681–2694. https://doi. org/10.14778/3742728.3742757 [20] Jayant Madhavan, Philip A Bernstein, and Erhard Rahm. 2001. Generic Schema Matching with Cupid. VLDB (2001). [21] Marc Maynou, Sergi Nadal, Raquel Panadero, Javier Flores, Oscar Romero, and Anna Queralt. 2026. Freyja: Efficient Join Discovery in Data Lakes. IEEE Transactions on Knowledge and Data Engineering 01 (Jan. 2026), 1–12. https: //doi.org/10.1109/TKDE.2026.3656786 [22] Venkata Vamsikrishna Meduri, Abdul Quamar, Chuan Lei, Xiao Qin, and Berthold Reinwald. 2024. Alfa: active learning for graph neural network-based semantic schema alignment. The VLDB Journal 33, 4 (July 2024), 981–1011. https://doi. org/10.1007/s00778-023-00822-z [23] S. Melnik, H. Garcia-Molina, and E. Rahm. 2002. Similarity flooding: a versatile graph matching algorithm and its application to schema matching. In Proceedings 18th International Conference on Data Engineering. IEEE Comput. Soc, San Jose, CA, USA, 117–128. https://doi.org/10.1109/ICDE.2002.994702 [24] Matteo Paganelli, Domenico Beneventano, Francesco Guerra, and Paolo Sottovia. 2019. Parallelizing Computations of Full Disjunctions. Big Data Research 17 (Sept. 2019), 18–31. https://doi.org/10.1016/j.bdr.2019.07.002 [25] Thorsten Papenbrock, Jens Ehrlich, Jannik Marten, Tommy Neubert, Jan-Peer Rudolph, Martin Schönberg, Jakob Zwiener, and Felix Naumann. 2015. Functional dependency discovery: an experimental evaluation of seven algorithms. Proc. VLDB Endow. 8, 10 (June 2015), 1082–1093. https://doi.org/10.14778/2794367. 2794377 [26] Erhard Rahm and Philip A. Bernstein. 2001. A survey of approaches to automatic schema matching. The VLDB Journal 10, 4 (Dec. 2001), 334–350. https://doi.org/ 10.1007/s007780100057 [27] Nils Reimers and Iryna Gurevych. 2019. Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. https://doi.org/10.48550/ARXIV.1908.10084 Version Number: 1. [28] Adel Remadi, Karim El Hage, Yasmina Hobeika, and Francesca Bugiotti. 2024. To prompt or not to prompt: Navigating the use of Large Language Models for integrating and modeling heterogeneous data. Data & Knowledge Engineering 152 (July 2024), 102313. https://doi.org/10.1016/j.datak.2024.102313 [29] Eitam Sheetrit, Menachem Brief, Moshik Mishaeli, and Oren Elisha. 2024. ReMatch: Retrieval Enhanced Schema Matching with LLMs. https://doi.org/10. 48550/arXiv.2403.01567 arXiv:2403.01567 [cs]. [30] Roee Shraga and Avigdor Gal. 2021. PoWareMatch: a Quality-aware Deep Learning Approach to Improve Human Schema Matching. https://doi.org/10.48550/ arXiv.2109.07321 arXiv:2109.07321 [cs]. [31] Pranav Subramaniam, Udayan Khurana, Kavitha Srinivas, and Horst Samulowitz. 2023. NumJoin: Discovering Numeric Joinable Tables with Semantically Related Columns. In Proceedings of the 32nd ACM International Conference on Information and Knowledge Management. ACM, Birmingham United Kingdom, 5096–5100. https://doi.org/10.1145/3583780.3614750 [32] Yoshihiko Suhara, Jinfeng Li, Yuliang Li, Dan Zhang, Çağatay Demiralp, Chen Chen, and Wang-Chiew Tan. 2022. Annotating Columns with Pre-trained Language Models. In Proceedings of the 2022 International Conference on Management of Data (SIGMOD ’22). Association for Computing Machinery, New York, NY, USA, 1493–1503. https://doi.org/10.1145/3514221.3517906 [33] Leonard Traeger, Andreas Behrend, and George Karabatis. 2025. SEALM: Semantically Enriched Attributes with Language Models for Linkage Recommendation:. In Proceedings of the 27th International Conference on Enterprise Information Systems. SCITEPRESS - Science and Technology Publications, Porto, Portugal, 39–50. https://doi.org/10.5220/0013217700003929 [34] Leonard Traeger, Andreas Behrend, and George Karabatis. 2026. Collaborative Scoping: Self-Supervised Linkability Assessment for Schema Matching. In Proceedings 29th International Conference on Extending Database Technology (1, Vol. 29). OpenProceedings.org, Tampere, Finland. https://doi.org/10.48786/EDBT. 2026.03

[35] Jianhong Tu, Ju Fan, Nan Tang, Peng Wang, Guoliang Li, Xiaoyong Du, Xiaofeng Jia, and Song Gao. 2023. Unicorn: A Unified Multi-tasking Model for Supporting Matching Tasks in Data Integration. Proceedings of the ACM on Management of Data 1, 1 (May 2023), 1–26. https://doi.org/10.1145/3588938 [36] Sha Wang, Yuchen Li, Hanhua Xiao, Bing Tian Dai, Roy Ka-Wei Lee, Yanfei Dong, and Lambert Deng. 2025. LLMATCH: A Unified Schema Matching Framework with Large Language Models. https://doi.org/10.48550/arXiv.2507.10897 arXiv:2507.10897 [cs]. [37] Meihui Zhang, Marios Hadjieleftheriou, Beng Chin Ooi, Cecilia M. Procopiuc, and Divesh Srivastava. 2011. Automatic discovery of attributes in relational databases. In Proceedings of the 2011 ACM SIGMOD International Conference on Management of data (SIGMOD ’11). Association for Computing Machinery, New York, NY, USA, 109–120. https://doi.org/10.1145/1989323.1989336 [38] Yunjia Zhang, Avrilia Floratou, Joyce Cahoon, Subru Krishnan, Andreas C. Müller, Dalitso Banda, Fotis Psallidas, and Jignesh M. Patel. 2023. Schema Matching using Pre-Trained Language Models. In 2023 IEEE 39th International Conference on Data Engineering (ICDE). IEEE, Anaheim, CA, USA, 1558–1571. https://doi. org/10.1109/ICDE55515.2023.00123 [39] Yu Zhang, Di Mei, Haozheng Luo, Chenwei Xu, and Richard Tzong-Han Tsai. 2025. SMUTF: Schema Matching Using Generative Tags and Hybrid Features. Information Systems 133 (Aug. 2025), 102570. https://doi.org/10.1016/j.is.2025. 102570 [40] Erkang Zhu, Dong Deng, Fatemeh Nargesian, and Renée J. Miller. 2019. JOSIE: Overlap Set Similarity Search for Finding Joinable Tables in Data Lakes. In Proceedings of the 2019 International Conference on Management of Data. ACM, Amsterdam Netherlands, 847–864. https://doi.org/10.1145/3299869.3300065

RACT: Retrieval Augmented Column-Table Learning and Prediction for Multi-Table Schema Matching

Related documents