Veezoo

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 sql is 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_name gives the second link its own name.
  • Many-to-many: the pairs live in a separate table, and join routes 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?

Order links to Customer twice, as buyer and as recipient, and answers show two identical Customer columns. What fixes this?

An order can use several promotions and a promotion applies to many orders, and the pairs sit in a separate table. What is recommended?