Connections
Foreign keys & relationship binding
You named the relationship and nothing connected. Naming a link is not wiring it. Binding points it at the real key column that carries it.
You defined the relationship: Customer places Order. You open the graph. The customers sit on the left, the orders on the right, and not a single line between them.
The relationship you named is real. Nothing is connected to it.
Naming a relationship is not the same as wiring it. The orders table has a customer_id column that points at a customer, but the ontology does not know that yet. Binding is where you tell it: the "places" link lives in this column.
The foreign key is the wire
Every order already carries the id of the customer who placed it, sitting in a column called customer_id. That column is the relationship, written into the data. Binding connects the two: this relationship type is carried by this column. Now each order finds its customer by matching keys, and an edge appears.
And when a key does not match, watch what happens.
O-104 points at customer C4. There is no C4. So no edge forms, and the order is left with no connection. That is referential integrity: a link forms only when the foreign key points at a row that really exists. A broken key is not an error message. It is a silent gap in the graph.
Wire it yourself. Pick the column that carries "places" and watch the edges form.
Wire the relationship
The relationship Customer places Order is named, but nothing is connected yet. Which column carries it?
Pick a column to bind the relationship to.
Why this matters for an AI agent
Naming the relationship told the agent that customers place orders. Binding is what actually lets it walk from a customer to their orders in your data. Without the wire, the agent knows the relationship exists in theory and cannot follow it.
Worse, broken foreign keys turn into gaps the agent cannot see. Ask "how many orders did Acme place," and if one order's customer_id was mistyped, the agent answers three when the truth is four, and it sounds just as sure, because the fourth order never connected. The quality of every answer depends on the quality of your bindings.
Check yourself
You bind the 'places' relationship to orders.customer_id. Some old orders have a customer_id that matches no customer (deleted accounts, bad imports). What happens to those orders in the graph?
Binding the relationship type in Fabric
In Microsoft Fabric you bind the relationship type to the key columns, from orders.customer_id to customers.customerId, and it becomes real edges between instances. That is the step that turns a declared link into actual edges when the graph materializes. It needs an identified primary key on the entity type first, because a foreign key has to have something to find. Once the binding is in place, each relationship instance becomes a labeled edge, and edges can carry properties of their own.
Do not expect generation to finish this for you. Generate an ontology from a Power BI semantic model and the relationships arrive, in Microsoft's own words, "defined, but not fully configured and bound to data". Reviewing and binding those relationship types is documented manual work you do afterwards. Generation is a starting point, not a finished ontology. This lives in Fabric IQ's ontology item, which is in preview as of July 2026.
The one trap
Do not assume a named relationship is a working one. The name is a promise; the binding is the wire that keeps it. A relationship with no binding is just a picture, not a real link. A relationship bound to a column full of broken keys is worse, because it looks connected but silently is not.
Now the edges are real. The interesting question is what you can do once you can walk them. Follow the connections across several hops, and answers appear that no single table could give. That is traversal.
Do it yourself
Build this step in the interactive Ontology Lab.
Open the lab →Milestone
Finished this concept? Mark it learned to track your progress.