Relational Deep Learning

Slide 4 recalls the deep learning revolution: huge progress on sequences (text, shown as a document) and images (photos, generated images). Slide 5: these breakthroughs are fueled by Transformers (the architecture diagram next to a chart of ChatGPT's exam results). Slide 6: they are also fueled by data; the cover of The Economist reads "The world's most valuable resource: data and the new rules of competition".

Slide 7 points out where most of an organisation's valuable data actually lives: in relational databases. The three pictures are database schemas from commerce, finance and social media: boxes (tables) with lists of columns, connected by lines (key relationships).

The tension of the whole lecture is here. Deep learning won on sequences and grids. Enterprise data is neither: it is many tables linked by keys. Can deep learning work on that data directly?

Slides 8–10 list typical predictive tasks on relational data, each next to a schema picture:

• Commerce (slide 8; schema with Users, Sales and Products tables): Which products will a user purchase in the next 7 days? Will an active user churn in the next 90 days? What will be the total sales for each product in the next 30 days?
• Finance (slide 9): What will the loan outcome be (good vs bad)? What will the total number of failed loans be in the next year?
• Healthcare (slide 10): Will a patient return if discharged from the hospital? Which hospital admissions have the greatest risk to life in the next 24 hours?

Note that almost all are about the future ("in the next N days").

Slide 11, "building AI is slow and complex". The standard pipeline has five stages: input data cleaning and curation → target label engineering → feature engineering → architecture and hyperparameter search → ML Ops. It takes 6–12 months for a team of data scientists, data engineers and product engineers.

Slide 12, the impedance mismatch. Goal: learn a user churn model from sales, purchased products and browsing behaviour. The data is several tables (Users, Sales, Products, Sessions, Views). Standard ML wants one table: one row per example (user) and columns of features such as "#monthly sales", "sum of weekly item price", "#orders relative to Sunday", plus a label column. Turning many tables into this one table creates three problems:

• Features are chosen arbitrarily (which aggregations? which time windows?).
• Only a limited set of the data is used.
• Issues with point-in-time correctness / information leakage: a feature computed at the wrong time can contain information from after the prediction time.

Slide 13 asks the key question: how can we use the data without the longest tasks (extraction, transformation, loading: ETL)? We want ML algorithms that process data in its natural form.

Slide 14: why not use an LLM? Slide 15, "Some have tried": Figure 1 of the paper "Tackling prediction tasks in relational databases with LLMs" (Wydmuch, Borchmann, Graliński; Snowflake AI Research). To build one LLM example, start from the Task Table row (target, timestamp, customer ID), follow the keys to the Customers, Transactions and Products rows, and serialise everything into one nested JSON document (customer name and address, a list of transactions, each with product name, description and weight), ending with "Target": 1. Slide 16, "Prompt": what such a prompt looks like for a real retail database, a full slide of dense JSON text (product groups, colours, timestamps, prices, …) for a single example.

Slide 17, why not LLMs:

• LLMs are not trained to understand and learn from the relational nature of databases.
• Database prediction is not sequence modelling: there is no natural order of rows, and serialising destroys the structure.
• LLMs are not trained to predict the future; most database tasks are forecasts.
• Context size is limited: slide 16 shows how quickly one user's history fills the prompt.

Slide 19, modern ML: we want deep learning models that operate on relational tables, but the deep learning toolbox is designed for other input types: text (sequences), images (grids), and the picture of a crowd of people suggests sets/graphs. Relational tables need their own architecture.

Slide 21: a picture of linked tables → "Relational Deep Learning" (a neural network) → prediction.

Slide 22, definition. RDL is:

• End-to-end deep learning on relational tables (databases).
• It works directly on the tables, with no transformations and no feature engineering.
• It casts predictive tasks as graph representation learning problems.

Slide 23, impact and consequences:

• More accurate models (no feature engineering, so no information thrown away).
• More robust models (model-learned features automatically "update" over time).
• Shorter time to model (no mundane ETL work).
• Simpler infrastructure (no pipelines, no feature stores, etc.).

Slide 24, related work 1: tabular ML (the figure is a decision tree). It is great for building models on one table, but most data is not a single table. And on tabular data deep learning is not dominant (gradient-boosted trees usually win). The slide's hypothesis: a single table already contains features engineered from other tables, so information is lost before the model starts. RDL models the relations between multiple tables, unlike tabular ML.

Slide 25, related work 2: Statistical Relational Learning [Friedman et al., 1999]. It learns a distribution (a graphical model) over the relational structure; the figure shows a probabilistic relational model with Movie, Actor and "Appears" boxes, with arrows for relationships and probabilistic dependencies. Predictions come from a world model plus inductive logic programming. Its limits: it only works with categorical variables and does not scale to large data. RDL is a scalable, expressive inheritor of statistical relational learning.

For a neuro-symbolic reader: SRL is the symbolic ancestor (explicit probabilistic structure over relations, logic-based inference); RDL keeps the relational structure but replaces the hand-specified dependencies with learned message passing.

Slide 27, insight: data is a graph. The figure is a small schema: a Users table (ID), a Sales table (ID, Product_ID, Session_ID, User_ID, Price) and a Products table (Product_ID). Sales points to Users and to Products through keys.

Slide 28 draws the same data as a graph: users on the left, sales in the middle (each sale node shows its price: $20, $80, $15, $20, $80, $80, $15), products on the right (a T-shirt, sneakers, sunglasses). Each sale connects one user to one product. The arrow from schema to picture is the whole idea: rows become nodes, key references become edges.

Slide 29: once the database is a graph, familiar graph ML tasks appear:

• Node-level: churn, lifetime value, next best action.
• Link-level: product affinity, recommendations.
• Graph-level: fraud, money laundering.

Slide 30, the graph ML problem-solving pipeline: Relational DB → Graph problem (users–sales–products graph) → Graph ML (a neural network passing messages over a computation graph) → Solutions (the same graph with predicted labels such as "Churn"/"Active" attached to users).

Slide 32: real-world data is stored in databases. A transaction (a user buying a product) is stored as a row of a Transaction table with columns Trans ID, User ID, Product ID, Value, Timestamp (one highlighted row: transaction 100, user 51, product 345, value $1000, timestamp 1710281001).

Slide 33: databases are often relational. The User ID in the transaction row points to a row in the User table (User ID, Gender, e.g. 51, Male), and the Product ID points to a row in the Product table (Product ID, Category, e.g. 345, Bike). So relational databases can be seen as heterogeneous graphs.

Slide 34, mathematically:

• A database is a set of tables \(\mathcal T=\{T_1,\dots,T_n\}\).
• Links between tables are \(\mathcal L\subseteq\mathcal T\times\mathcal T\).

Slide 35: the schema graph represents the high-level structure of the heterogeneous graph. Its nodes are tables, not rows. The example has three tables: Products (ProductID, Description, Image, Size), Transactions (TransactionID, ProductID, Timestamp, CustomerID, Price) and Customers (CustomerID, Name), with edges "Bought which" (Transactions–Products) and "Bought by" (Transactions–Customers).

Slide 36: real schema graphs can be much more complex; the picture is an industrial schema with dozens of tables and many links.

In Lecture 9 terms: the schema graph plays the role of the metagraph (node types and relation types); the relational entity graph (next block) is the actual heterogeneous graph.

Slide 37, the relational entity graph: create connections via primary–foreign keys. The figure repeats the schema (Users, Sales, Products) and, below it, the users–sales–products graph.

Slide 38, the formal definition. Given a database of tables \(\mathcal T=\{T_1,\dots,T_n\}\) and relations \(\mathcal L\subseteq\mathcal T\times\mathcal T\):

• Each table is a set of entities \(v\in T_i\). Each entity has a primary key (its unique ID) and optional foreign keys (IDs of rows in other tables).
• The node set is all rows of all tables: \(\mathcal V=\bigcup_{T\in\mathcal T}T\).
• The edge set connects two entities \(v_1,v_2\) whenever the primary key of one matches a foreign key of the other.

Slide 39: entities also have features, unlike knowledge graphs. The tables show it: a transaction has a value and a timestamp, a user has a gender, a product has a category. These columns become node features (numbers, categories, text, timestamps).

Slide 41, overview of the approach: (a) define tasks (e.g., "how much will each customer buy in the next 90 days?"), (b) training table generation (gather training targets from historical data), (c) link the training table to the relational tables. Next: define tasks, then the RDL model.

Slide 42, example: predict whether a user will churn in the next 30 days. Most tasks are temporal:

• a customer's label changes over time;
• the database changes over time;
• so for every time point, any feature must be recomputed.

To define a task you need three things: an entity, a label and a time. The side note: temporal tasks are especially challenging because features are time-dependent (recompute for every time) and an entity's label can change between time steps.

Slide 43, the training table: a special table that holds the training labels as rows (entity ID, time, label).

• It supports classification, regression and multi-class tasks.
• The time column is essential for temporal prediction.
• An entity may have different labels at different times.
• Only information up to the time of the label may be used.

Slide 44 shows a small training table with columns Entity ID, Timestamp, Label: rows such as entity 99 at time 10172024 with label 1 and entity 100 with label 0.

Slide 45, the churn example. The schema is Users, Sales, Products. Task: predict whether a user is going to churn, where churn means zero sales in the next 30 days. Training table: (user, time, churn label).

Notice how the label itself is computed from the database: for a user \(u\) and time \(t\), look at Sales rows of \(u\) with timestamps in \((t, t+30\text{ days}]\). The features may only use rows with timestamp \(\le t\). This is how a training table can be generated automatically from history.

Slide 46 is the full RDL pipeline in four panels (from the RDL paper):

1. (a) Relational tables with a training table. Products (Product_ID, Description, Image, Size), Transactions (Transaction_ID, Product_ID, Timestamp, Customer_ID, Price), Customers (Customer_ID, Name), and the training table Customer LTV (90-day LTV, User_ID, SeedTime), which points to Customers.
2. (b) Entities linked by foreign keys: individual rows of each table connected through their keys.
3. (c) Relational entity graph: products 1, 2, 3 connect to transactions, transactions to customers, and customers to training-table rows (labels A and B).
4. (d) Graph neural network: for each training row (A, B), the computation tree unrolled from the entity graph: label node ← customer ← transactions ← products and other customers.

Slide 47 repeats the relational entity graph (create connections via primary–foreign keys).

Slide 48: the training labels, together with their timestamps, are attached to the graph. Each user gets label nodes, one per (time, label): for example the first user has "May '23: Churn" and "June '23: Active"; another user has "April '23: Active", "May '23: Churn", "June '23: Active". The same user is a training example several times, at different times, with different labels.

Slide 50 repeats the four-panel pipeline as the start of the "Relational GNN" section.

Slide 51, a GNN on the entity graph. A node's neighbourhood defines its computation graph. Nodes learn how to optimally use information from neighbours to get better representations. The figure: on the left the entity graph (users, sales, products) with one user highlighted; on the right two GNN computation graphs for the same user, one for the label "May '23 Churn" and one for "June '23 Active". The two trees differ, because each one may only use sales that happened before its own time.

Slide 52, GNNs on temporal graphs, with three panels:

1. (a) Schema graph: Products, Transactions, Customers with "Bought which" and "Bought by".
2. (b) Relational entity graph laid out along a time axis from 0 to 6: transactions \(v_1,\dots,v_6\), products \(v_7,v_8,v_9\), customers \(v_{10},v_{11},v_{12}\).
3. (c) Computation graphs of customer \(v_{11}\) at different times: at \(t=1\) it sees only transaction \(v_1\) (and product \(v_7\)); at \(t=3\) it sees \(v_3,v_1\) (products \(v_8,v_7\)); at \(t=5\) it sees \(v_1,v_3,v_5\) (products \(v_7,v_8,v_9\)).

So in RDL:

• the computation graph for each node is time-dependent;
• message + aggregation become time-dependent;
• sampling over neighbours is time-dependent.

Slide 53, GNN vs feature engineering. GNN-based features: a user aggregates learned messages from the sales of a T-shirt and sneakers. Hand-engineered features: columns like SUM(TRANSACTIONS.Price) over (-30, 0) days, AVG(TRANSACTIONS.Price) over (-30, 0) days, … Key message: GNN aggregation is a learnable version of hand-crafted features, and GNNs perform better because they learn the optimal features.

Slide 54 recalls relational algebra:

• A table \(R\) is a set of entities \(R=\{r_1,\dots,r_n\}\).
• Each entity is a tuple \(r_i=(r_{i1},r_{i2},\dots,r_{in})\).
• Given two tables \(R,S\), a join is a subset of the Cartesian product \(R\times S\).
• Aggregation specifies which rows are kept (and how they are combined).

Example 1, cross join: SELECT * FROM employee INNER JOIN department ON 1=1. The Employee table (Rafferty 31, Jones 33, Heisenberg 33, Robinson 34, Smith 34, Williams NULL) and the Department table (31 Sales, 33 Engineering, 34 Clerical, 35 Marketing) give all \(6\times4=24\) pairs.

Slide 55, example 2, inner join:

The SQL query joins employee and department on DepartmentID. The result keeps only matching pairs: Robinson 34 Clerical, Jones 33 Engineering, Smith 34 Clerical, Heisenberg 33 Engineering, Rafferty 31 Sales (Williams, with NULL, disappears; Marketing has no employee). Now picture \(R\times S\) as a matrix: the pairs kept are exactly the entries

These are exactly the pkey–fkey edges. The adjacency matrix of the entity graph between two tables is the inner-join indicator matrix.

Slide 56, GNNs perform a JOIN + AGG. Input: a USER_ID table (1, 2, 3) and a SALES table (user 1: 20 on 01-01, 80 on 01-02; user 2: 15 on 01-01; user 3: 20 on 01-02, 80 on 01-03). A GNN can learn the query

SELECT SUM(VALUE) FROM SALES WHERE DATE > 01-01 GROUP BY USER_ID

whose result is user 1: 80, user 2: 0, user 3: 100. The GNN layer that does this is

with a learnable aggregation \(\bigoplus\) (over the sales \(w\) joined to user \(v\): the JOIN), a temporal embedding \(\mathbf t(t_w)\) of the sale's timestamp (which can learn to zero out sales on or before 01-01: the WHERE), and a fact representation \(\mathbf x_w\) (the sale's features, here VALUE). Sum aggregation then gives the SUM … GROUP BY.

Slide 57: GNNs learn how to aggregate information.

• They can discard neighbouring information that is irrelevant for the downstream task.
• They can detect fine-grained patterns in local neighbourhoods (e.g., buying behaviour over the last year).

The figure is a schema with Users, Sales, Products, Sessions and Views tables.

Slide 58: GNNs can exchange information across training examples. Instead of treating examples as isolated rows (as tabular ML does), there is now inter-dependency between entities: users with similar features, users with similar behaviour. A GNN uses this to enrich an entity's representation. The schema figure annotates two such multi-hop questions: "How is the buying behaviour of users that have bought similar products?" and "How is the buying behaviour of users that have looked at similar products?"

Slide 59: multi-hop reasoning across table boundaries catches information that is hard to pre-compute. The figure attaches the training labels to Users and annotates paths: "Which user has bought which product?" (Users → Sales → Products) and "How active was the user in the past?" (Users → Sessions/Views).

Slide 60: first-class temporal support.

• Capture fine-grained relative and seasonal features via temporal embeddings.
• Avoid data leakage via temporal sampling directly during data loading.

The figure: a seed node at time \(T\). Its neighbours at time \(T-1\) and earlier (solid arrows) are available for sampling; the node at time \(T+1\) and everything attached to it (dashed) are not available for sampling. Leakage is prevented by construction in the sampler, not by careful feature code.

Slide 61: the vision is described in the paper "Relational Deep Learning: Graph Representation Learning on Relational Tables" (Fey, Hu, Huang, Lenssen, Ranjan, Robinson, Ying, You, Leskovec; Stanford, Kumo.AI, Max Planck Institute for Informatics, Yale, UIUC). Available at relbench.stanford.edu.

Slide 63, RelBench enables research on RDL. It is more than a collection of databases. The pipeline figure: RelBench relational databases → RelBench data, task and graph loaders → your RDL model (e.g., PyG) → RelBench evaluator → RelBench leaderboard. Features:

• Automatically download datasets.
• Load database and task tables.
• A standardised evaluation protocol that prevents temporal leakage from the test set.
• Framework-agnostic data structures: use your favourite ML stack.

Slide 64, PyTorch Frame and PyG integration: load a database as a PyG graph; train a GNN end-to-end; temporal neighbour sampling; use PyTorch Frame to encode the table columns (numerical, categorical, text, timestamp) into node features.

Slide 65, 7 diverse datasets: E-commerce (rel-amazon, rel-avito, rel-hm), Social (rel-event, rel-stack), Sports (rel-f1), Medical (rel-trial).

Slide 66, rich schemas: 3 to 15 tables; 74k to 41M rows per database; 15 to 140 columns per database; time spans from 2 weeks to 55 years. The two example schemas are rel-amazon (review, customer, product tables) and the much larger rel-trial.

Slide 67, 30 real-world predictive tasks of three kinds:

• Entity classification: rel-amazon user-churn, item-churn; rel-stack user-badge; rel-trial study-outcome; …
• Entity regression: rel-amazon user-ltv, item-ltv; rel-avito ad-ctr; rel-f1 driver-position; …
• Recommendation: rel-amazon user-item-purchase; rel-avito user-ad-visit; rel-stack user-post-comment, post-post-related; …

Slide 68: a screenshot of the website (https://relbench.stanford.edu) to get started.

Slide 70: the experiment recruited an experienced data scientist (Alejandro): 5 years in industry, specialising in financial databases, responsible for the full model-building lifecycle.

Slide 72, the representative RelBench task: the Stack Exchange database (schema shown). Question: will a user be active in the next 6 months?

Slides 73–79 build the expert's manual workflow step by step, with time spent:

1. Exploratory data analysis (EDA), 4 hours. Example observations (slide 75, three histograms): activity is seasonal; comments follow a power law; negative votes are infrequent.
2. Feature ideation, 0.5 hour. Example features: weeks_since_last_comment, badge_score, location_is_null.
3. SQL query writing, 5 hours: hundreds of lines of code (slide 77 shows a long SQL script).
4. XGBoost hyperparameter sweep, 2 hours.
5. SHAP feature-importance analysis, 1 hour.

Slide 80, the SHAP plot (each row a feature; position = impact on the model output; colour = feature value). Top features: weeks_since_last_comment, badge_score, last_q_weeks_ago, num_posts_commented, last_a_weeks_ago, num_badges, location_is_null, about_me_length, … Selected observations:

• Website "seniority" is predictive (total number of comments, badge score, etc.).
• Time since last active / commented is predictive.
• A completed bio (about me, location, etc.) is predictive.
• Number of positive/negative votes is not predictive.
• Interacting with "senior" community members is not predictive.

Slide 81: the final list of features (a long table), about 12 hours of high-quality expert work.

Notice how each feature is a hand-written JOIN + aggregation + time window. "weeks_since_last_comment" is a MAX over the user's comments; "num_posts_commented" a COUNT DISTINCT. These are exactly the operations slide 56 says a GNN layer can learn.

Slide 83, the naive baseline: XGBoost on the users table only, with no feature engineering (columns Id, AccountId, DisplayName, Location, WebsiteUrl, AboutMe, CreationDate). Test ROC-AUC 0.6842.

Slide 84: the expert data scientist reaches test ROC-AUC 0.8643, with 12 hours of manual work, ~682 lines of code and 1 hour of model training (2 days to model). Footnote: work is measured as the marginal effort to solve a new task.

Slide 85: the GNN reaches 0.8945, with under 1 hour of manual work, 54 lines of code and 1 hour of model training.

Slide 86 summarises as four bar charts (GNN vs expert): AUC-ROC 0.90 vs 0.86; hours of human work 1 vs 11; lines of code 54 vs 682; hours of model training 1 vs 1.

Slide 87, more RelBench tasks (AUC-ROC, GNN vs expert): stackex-engage 89.50 vs 86.43; stackex-badges 88.19 vs 86.14; amazon-churn 70.46 vs 67.55; amazon-product-churn 82.98 vs 81.67. The GNN wins on all four.

Reading the results: the accuracy gain (a few AUC points) is real, but the bigger change is the cost: about 10× less human time and over 10× less code. The expert's features are a good but fixed subset of the JOIN+AGG space; the GNN searches that space with gradients.