Star schema

Analytics schemas are shaped differently from transactional ones: one big fact table in the middle, dimension tables around it, deliberately denormalised so queries stay simple.

Drawing it is the quickest way to explain why the warehouse does not look like production.

#When to reach for one

Documenting a data warehouse or mart for analysts.
Designing a new fact table and arguing about its grain.
Explaining to engineers why the reporting schema repeats itself on purpose.

#How to draw it in Capable

Route	Use when
Mermaid	The relationships are simple; text keeps it current.
draw.io	Presentation versions where the star shape is the message.

#A worked example

A sales fact table with four dimensions:

The source, which you can paste into a new diagram and edit:

erDiagram
  DIM_DATE ||--o{ FACT_SALES : "when"
  DIM_CUSTOMER ||--o{ FACT_SALES : "who"
  DIM_PRODUCT ||--o{ FACT_SALES : "what"
  DIM_STORE ||--o{ FACT_SALES : "where"
  FACT_SALES {
    date_key int FK
    customer_key int FK
    product_key int FK
    store_key int FK
    quantity int
    net_amount numeric
  }

#A few things that catch people out

State the grain of the fact table on the diagram. One row per what?
A snowflake schema normalises the dimensions. Say which one you are drawing.
Dimension tables repeat data deliberately. That is not a mistake to correct.

Data lineage diagram

Source, transformation, dashboard.

JSON structure diagram

A payload somebody can actually read.

Examples

Working diagrams you can copy.

Get the cardinality right and the rest follows.