Court Geometry
Schema Reference
Scouting dossier for the nbadb warehouse model and schema-backed reference tiers
Coverage boundary
Schema-backed reference coverage is narrower than total lineage coverage
The generated schema reference layer is intentionally exact, but it does not cover every transform output yet. Use this summary to see what the contract layer currently includes before you assume an output has a schema-backed final-tier reference.
An output counts as covered only when docs-autogen can pair a lineage-tracked output with a generated schema reference entry.
The remaining 0 outputs may still appear in lineage or curated docs, but they do not yet have this schema-backed contract layer.
Source of truth: docs/lib/generated/schema-coverage.json. Refresh it with uv run nbadb docs-autogen --docs-root docs/content/docs.
Schema Reference
The nbadb analytical surface exposes public tables and views across dimensions, facts, bridges, derived aggregations, and analytics views.
Treat this section like the warehouse playbook: the curated pages explain how the lineup fits together, while the generated reference pages give you the box-score-exact schema contracts when you need to check a column, key, or constraint at 2am.
The curated pages explain how to use the model. The raw, staging, and star reference pages are generated, schema-backed artifacts: use them for exact contracts, and regenerate them instead of hand-editing when the code changes.
Work the section in three possessions
- Choose the family. Start on the curated guides when you still need judgment about grain, surface, or whether a shortcut already exists.
- Lock the join lane. Switch to Relationships once you know the tables but want the cleanest path between them.
- Verify the contract. Finish on Raw Reference, Staging Reference, or Star Reference when the question turns into exact columns, types, or nullability.
Curated family guides
Use Dimensions, Facts & Bridges, Derived Aggregations, and Analytics Views when you are still picking the right surface.
Relationships
Use Relationships when the tables are known but the join lane is still muddy.
Generated tier references
Use the generated tier pages when you need schema-backed exactness rather than routing or join advice.
Choose the right route
| If your question is... | Go to... | Why this is the right lane |
|---|---|---|
| “Who or what is this row about?” | Dimensions | Identity, history, calendar, venue, and controlled-vocabulary context live there |
| “Where do the measures actually live?” | Facts & Bridges | That scouting report groups the main measurement tables by grain and job |
| “Is there already a reusable rollup for this?” | Derived Aggregations | agg_* surfaces answer recurring season-, career-, and summary-style asks |
| “Can I skip some manual joins?” | Analytics Views | analytics_* surfaces are the fast-break outlets for notebooks and dashboards |
| “How do I join these safely?” | Relationships | It is optimized for join judgment, key lanes, and duplicate-row avoidance |
| “What are the exact fields and constraints?” | Star Reference or upstream Staging Reference / Raw Reference | Those generated pages are the contract layer |
Know which page owns which job
| Surface | Optimized for | Stop here when... | Maintenance path |
|---|---|---|---|
| Curated family guides | Table-family choice, workflow advice, and first-pass judgment | You know the family and the likely grain | Hand-authored |
| Relationships | Join patterns, key lanes, and duplicate-row avoidance | The join path is clear and you only need exact column contracts | Hand-authored |
| Generated tier references | Exact columns, types, nullability, and schema-backed constraints | You need narrative guidance or table-family choice again | Regenerate, do not hand-edit |
Choose your first pass
Pick the family
Use Dimensions, Facts & Bridges, Derived Aggregations, or Analytics Views when the first question is still "which surface actually answers this?"
Lock the join lane
Jump to Relationships once you know the tables involved but need the safest path between them.
Use the shortcut on purpose
Reach for Analytics Views or Derived Aggregations when the job repeats and you do not want to rebuild the same joins every possession.
Verify the exact contract
Go straight to Raw Reference, Staging Reference, or Star Reference when exact columns, types, and nullability matter more than narrative guidance.
If you only remember one decision tree, use this one.
flowchart TD
Start["Question in hand"] --> Family{"Still choosing the table family?"}
Family -- Yes --> Curated["Curated family pages"]
Family -- No --> Join{"Need the safest join lane?"}
Join -- Yes --> Relationships["Relationships"]
Join -- No --> Exact{"Need exact columns or nullability?"}
Exact -- Yes --> Generated["Raw / Staging / Star Reference"]
Exact -- No --> Curated
style Curated fill:#e8f5e9
style Relationships fill:#fff3e0
style Generated fill:#e1f5feText fallback: start on the curated family pages when you still need judgment, jump to Relationships when the join lane is the real question, and finish on the generated references when exact contracts matter.
Start by the handle you already have
| If you already have... | Start here | Why this is the fastest lane |
|---|---|---|
| a player or team question | Facts & Bridges or Dimensions | facts answer the measurement question, dimensions answer the identity and context question |
a game_id | Facts & Bridges | that is the cleanest way to decide whether the grain is player-game, team-game, play-by-play, shot, or rotation |
| a season-level reporting ask | Derived Aggregations | repeated rollups are often already built, which is faster than recreating them from the fact layer |
| a dashboard or notebook use case | Analytics Views | those outputs are the fast-break outlets for first-pass analysis |
| a known table pair but an uncertain join | Relationships | the join lane is the real blocker, not table-family choice |
| an exact field, type, or nullability question | Star Reference or the upstream Raw / Staging references | generated pages are optimized for contract verification, not route selection |
Read the jersey prefix
| Prefix | Read it as... | Usually start on... |
|---|---|---|
dim_ | conformed context and identity | Dimensions |
fact_ | measurable events or summaries at a defined grain | Facts & Bridges |
bridge_ | many-to-many connector | Facts & Bridges or Relationships |
agg_ | reusable pre-aggregated rollup | Derived Aggregations |
analytics_ | pre-joined convenience surface | Analytics Views |
stg_ / raw_ | upstream reference tiers used to trace the ball back to extraction | Staging Reference or Raw Reference |
Warehouse offensive system
- Star first: dimensions create stable context around fact grains so common queries stay join-friendly.
- History where it matters:
dim_playeranddim_team_historyuse SCD Type 2 semantics for time-aware identity tracking. - Conformed anchors:
player_id,team_id,game_id, andseason_yeardo most of the passing across the model. - Smallest useful grain: start at the narrowest fact that answers the question, then climb to
agg_oranalytics_only when the use case repeats.
Generated tier references
Regenerate the command-owned reference pages with:
uv run nbadb docs-autogen --docs-root docs/content/docsThat command owns the raw, staging, and star reference artifacts. Keep this index, the family guides, and Relationships curated.
Keep moving
Stay in the same possession
Keep the mental model warm with adjacent pages, section hubs, and search-friendly routes into the same topic cluster.
