Z mojego doświadczenia wynika, że diagramy ER (lub UML) nie są najbardziej użytecznym artefaktem - przy dużej liczbie tabel diagramy (zwłaszcza te poddane inżynierii wstecznej) są często wielkim, zawiłym bałaganem, z którego nikt się niczego nie uczy.
Za moje pieniądze jakaś dobra czytelna dla człowieka dokumentacja (być może uzupełniona schematami mniejszych fragmentów systemu) da Ci najwięcej przebiegu. Będzie to obejmować dla każdej tabeli:
- Opisy tego, co oznacza tabela i jak jest funkcjonalnie używana (w interfejsie użytkownika itp.)
- Opisy znaczenia każdego atrybutu, jeśli nie jest to oczywiste
- Wyjaśnienia relacji (kluczy obcych) z tej tabeli do innych i na odwrót
- Wyjaśnienia dodatkowych ograniczeń i/lub wyzwalaczy
- Dodatkowe wyjaśnienie głównych widoków i procesów, które dotykają tabeli, jeśli nie są jeszcze dobrze udokumentowane
Biorąc pod uwagę powyższe, nie dokumentuj dla samego dokumentowania - dokumentacja, która powtarza to, co oczywiste, po prostu przeszkadza ludziom. Zamiast tego skup się na rzeczach, które na początku Cię zdezorientowały i poświęć kilka minut na pisanie naprawdę jasnych, zwięzłych wyjaśnień. Pomoże Ci to przemyśleć i masowo pomóż innym programistom, którzy po raz pierwszy natknęli się na te tabele.
Jak wspomnieli inni, istnieje szeroka gama narzędzi, które pomagają w zarządzaniu tym, takich jak Enterprise Architect, Red Gate SQL Doc i wbudowane narzędzia różnych dostawców. Ale chociaż obsługa narzędzi jest pomocna (a nawet krytyczna, w przypadku większych baz danych), wykonując ciężką pracę zrozumienia i wyjaśnianie konceptualny model bazy danych to prawdziwa wygrana. Z tej perspektywy możesz to zrobić nawet w pliku tekstowym (chociaż zrobienie tego w formie Wiki pozwoliłoby kilku osobom współpracować nad stopniowym dodawaniem do tej dokumentacji - więc za każdym razem, gdy ktoś coś wymyśli, może dodać to do rosnącego ciała dokumentacji natychmiast).
