Relationship

A school clerk wanted to track which students take which courses. She added a course_id to the students table. It worked until one student signed up for a second course, and there was nowhere to put it. So she turned it around: a student_id on the courses table. Same problem again. A course has thirty students.

Then the real question came up: what grade did this student get in that course? It fits in neither table. Not the student, who has five grades. Not the course, which has thirty. The fact had no home.

What she was missing is the relationship. It is its own thing, not just a column added to one side.

A join is not a relationship

You have foreign keys, so surely you have relationships? Not quite. A join is the database step that matches rows from two tables when a value in one equals a value in the other. That is all it knows: two ids are equal. It does not know if the customer placed the order, returned it, or cancelled it. Take the column names away and a join is just 42 = 42.

A relationship keeps the meaning that the join throws away: a direction (the customer acts on the order), a verb (places), and a shape (one customer, many orders). Get the shape wrong and the model quietly accepts data that cannot be true.

Try it. For each pair, pick the shape.

The grade finds a home

Back to the school clerk. Once the enrollment is a relationship of its own, the grade has a clear place to sit: on the link itself, next to the date. A fact that belongs to the pair sits on the pair, not on either side.

Why this matters for an AI agent

This is where an AI agent stops being a search box and starts being useful. With bare foreign keys, an agent sees matching ids and guesses what they mean. It might join Supplier to Customer just because they share a region, and give you a wrong answer. Give it named, directional relationships and it can follow how your business really connects: this customer, to their orders, to the shipments that carried them.

Real relationships are what let an agent answer a question nobody built ahead of time.

What Fabric calls it

In Microsoft Fabric these are relationship types: named, directional, with a cardinality, and their own properties when the link carries facts. Underneath, a relationship type is bound to real key columns across your sources. That binding is what turns a declared link into actual edges. When the graph materializes into real data, the relationship instances become those labeled edges, and both the nodes and the edges carry their properties. A data agent, Fabric's name for an AI agent grounded in your data, walks those edges to answer a question nobody built ahead of time.

One note on status, because it is a split, not one label for everything. The graph engine is generally available as of July 2026, and so are the data agent and the Power BI semantic model. The ontology item, where your relationship types actually live, is still in preview.

The one trap

Do not mistake the foreign key for the relationship. The key is a mechanism: an id that matches an id. The relationship is the meaning on top of it: a direction, a verb, a shape, and sometimes facts of its own. Skip it and you get joins that run but say nothing, and connection facts like a grade with nowhere to live.

Model relationships on purpose and your entities stop being disconnected. But so far the relationship is only a declaration: Customer places Order, named and given a direction, but connecting nothing yet. Nothing links until you wire it to the real key columns in your data. That wiring comes next: relationship binding.