Data structures and meaning
Physical representation and datatype documentation
SQL objects with their dependencies: which view reads which table, which table feeds which report.
ddn@1New DDN source
Why use it?
Know the blast radius of a schema change before you make it.
When it helps
Impact analysis before renaming, splitting or dropping database objects.
How to read it
- Arrows point from a definition to the objects that consume it.
- A shared lookup table with many consumers is a deliberate coupling, not an accident.
What you need
- The object inventory
- Read/write relationships between objects
- Ownership per object
Things to check
- Do not treat a missing arrow as proof of no dependency — dynamic SQL and applications are outside the model until declared.
- Do not delete a consumer from the diagram to make a change look safe.
Scope of this diagram
Declared dependencies only; runtime introspection of a live database is out of scope.
Work with the converted example
- Open the viewer and select
diagram. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.