Veezoo

Module 3 · Lecture 3.1

Think in Business Concepts, Not Tables

Why the grain of a table decides your numbers, and how business concepts get classes of their own.

One wide table, the classic Sample Superstore dataset, and inside it orders, line items, products, customers and regions. The lecture opens with the question every new dataset deserves. What does one row represent?

You will see the same dataset answer two nearly identical questions very differently, watch the model get corrected, and see one question left broken on purpose for a later lecture to repair.

Key points

  • Concepts, not tables: a business concept does not map to a physical table, and one wide table routinely holds several concepts at once.
  • Grain decides the numbers: when one row is an order line, counting rows reports line counts as order counts, and nothing flags the mistake.
  • Names describe storage: a generated class carries the name of its table, so rename it to say what one instance actually is.
  • Renaming is safe: it changes the model only, and the table in the database keeps the name it had.
  • Promote what people ask about: a concept deserves its own top-level class, where it can hold its own attributes and measures and take on new data later.
  • Attributes follow their concept: an order date describes the order, not the individual line item.
  • Concepts need relationships: until two concepts are connected, a question that spans both of them cannot be answered.

Check your understanding

A table holds one row per product inside an order, and order IDs repeat across rows. What does one row represent?

The generated class is called "Sample Superstore Orders", but one instance of it is a single order line. What does the lecture do?

Order is now a top-level class with Order Date on it, and "sales by order date last month" fails. Why?