Podle mých zkušeností nejsou ER (nebo UML) diagramy tím nejužitečnějším artefaktem – s velkým množstvím tabulek jsou diagramy (zejména ty reverzní inženýrství) často velkým zamotaným nepořádkem, ze kterého se nikdo nic nenaučí.
Za moje peníze vám nějaká dobrá, člověkem čitelná dokumentace (možná doplněná schématy menších částí systému) poskytne nejvíce kilometrů. To bude pro každou tabulku zahrnovat:
- Popis toho, co tabulka znamená a jak se funkčně používá (v uživatelském rozhraní atd.)
- Popis toho, co jednotlivé atributy znamenají, pokud to není zřejmé
- Vysvětlení vztahů (cizí klíče) z této tabulky k ostatním a naopak
- Vysvětlení dalších omezení a/nebo spouštěčů
- Další vysvětlení hlavních zobrazení a procesů, které se dotýkají tabulky, pokud již nejsou dobře zdokumentovány
Se všemi výše uvedenými skutečnostmi nedokumentujte kvůli dokumentaci – dokumentace, která opakuje to, co je zřejmé, lidem prostě překáží. Místo toho se zaměřte na věci, které vás zpočátku zmátly, a věnujte několik minut psaní opravdu jasných a stručných vysvětlení. Pomůže vám to promyslet a bude to masivně pomoci dalším vývojářům, kteří se s těmito tabulkami setkají poprvé.
Jak již uvedli jiní, existuje široká škála nástrojů, které vám pomohou toto spravovat, jako je Enterprise Architect, Red Gate SQL Doc a vestavěné nástroje od různých dodavatelů. Ale zatímco podpora nástrojů je užitečná (a ve větších databázích dokonce kritická), odvedete tvrdou práci na pochopení a vysvětlení koncepční model databáze je skutečnou výhrou. Z tohoto hlediska to můžete dokonce udělat v textovém souboru (ačkoli to udělat ve formě Wiki by umožnilo několika lidem spolupracovat na postupném přidávání do této dokumentace - takže pokaždé, když někdo něco zjistí, může to přidat do rostoucího těla dokumentace okamžitě).