Module 3 · Lecture 3.5
Relationships & Cardinality
How relationships connect classes: cardinality, naming, two links to one target, and many-to-many through a hidden join table.
A Knowledge Graph with customers, products, orders and promotions can already answer questions about each class on its own, but "which customers ordered a certain product?" needs those classes connected. The first video builds relationships from scratch: choosing the cardinality, writing the relationship, giving it a name that reads well in answers, pointing one class at another twice for a buyer and a recipient, and routing a many-to-many case through a hidden join table.
The second video applies all of that to the Knowledge Graph used throughout this module, adding the missing relationship between Line Item and Order so that "sales by order date last month" works again.
Videos
How relationships work
Applied to our example Knowledge Graph
Key points
- What it is: a relationship tells Veezoo how two classes connect, and under the hood it defines the SQL join between their tables.
- Cardinality first: one customer has many orders, so the relationship lives on the many side and points to the one side.
- The linking column: the relationship's
sqlis the foreign key column that matches the target class's identifier. - No mirrors needed: a nested class that simply repeats a top-level class is replaced by an explicit relationship to that class.
- A name of its own: an Order is "Placed By" a Customer, and that name is visible in the graph and usable in questions.
- Two links, one target: Order can point to Customer twice, as buyer and as recipient, and
to_namegives the second link its own name. - Many-to-many: the pairs live in a separate table, and
joinroutes the relationship through it while that table stays hidden.
Check your understanding
The orders table carries a customer ID, and one customer can place many orders. Where does the relationship live?
The relationship sits where the many is and points at the one side through the foreign key, and many-to-one is the default.
Order links to Customer twice, as buyer and as recipient, and answers show two identical Customer columns. What fixes this?
to_name renames the target class inside one relationship, so users can ask for orders by recipient.
An order can use several promotions and a promotion applies to many orders, and the pairs sit in a separate table. What is recommended?
The extra table is plumbing, so join performs the hop while only Order and Promotion stay visible.