# 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: ![Star schema](https://help.gocapable.com/images/att1418199072.svg) 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. --- ## Related [Data lineage diagramSource, transformation, dashboard.](https://help.gocapable.com/diagrams/data-lineage-diagram.html) [JSON structure diagramA payload somebody can actually read.](https://help.gocapable.com/diagrams/json-structure-diagram.html) [ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html) --- _Get the cardinality right and the rest follows._