ekke
9b4c7625d2
Condenses the 96-page generated data dictionary into ten pages that can be read in one sitting: what the four schemas are for, what the table-name prefixes mean, every table with one line on what it holds, and a set of observations for the database team. The generated dictionary stays the authority on columns and types; this is the document to read first. Two diagrams carry the part the dictionary cannot show. Figure 1 is the four schemas and the fact that each of the other three has its own name for the district it refers to — district_id, district_ref, project_district_id — none of them enforced. Figure 2 is the relationships per schema, drawing the distinction that matters most: solid arrows are the nine foreign keys the database actually declares, dashed arrows are joins that exist only because two tables agree. That distinction produced three findings worth acting on, all in section 3: permit is the only schema with referential integrity, and even there comments and stages join on application_code text rather than the id; dataroom's versioning chain is held together by uuid alone; and the two enforced keys in spatial point at the legacy parcels table rather than the live lu_parcels, which is worth checking before either building table is relied on. A fourth is a loose end — zoning_districts references reference.zoning_types, a schema the dictionary does not cover at all. Diagrams are committed as SVG (editable) alongside the PNG the document embeds, following the pattern already used for the staged-upload and OpenTopography figures. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
62 lines
4.5 KiB
XML
62 lines
4.5 KiB
XML
