Enligt min erfarenhet är ER-diagram (eller UML-diagram) inte den mest användbara artefakten - med ett stort antal tabeller är diagram (särskilt omvänt konstruerade) ofta en stor invecklad röra som ingen lär sig något av.
För mina pengar kommer en del bra läsbar dokumentation (kanske kompletterad med diagram över mindre delar av systemet) att ge dig mest körsträcka. Detta inkluderar, för varje tabell:
- Beskrivningar av vad tabellen betyder och hur den används funktionellt (i användargränssnittet osv.)
- Beskrivningar av vad varje attribut betyder, om det inte är uppenbart
- Förklaringar av relationerna (främmande nycklar) från den här tabellen till andra och vice versa
- Förklaringar av ytterligare begränsningar och/eller triggers
- Ytterligare förklaring av viktiga vyer och processer som berör tabellen, om de inte redan är väldokumenterade
Med allt ovanstående, dokumentera inte för att dokumentera – dokumentation som upprepar det uppenbara kommer bara i vägen för människor. Fokusera istället på det som gjorde dig förvirrad i början och ägna några minuter åt att skriva riktigt tydliga, koncisa förklaringar. Det hjälper dig att tänka igenom det, och det kommer massivt hjälpa andra utvecklare som stöter på dessa tabeller för första gången.
Som andra har nämnt finns det ett brett utbud av verktyg som hjälper dig att hantera detta, som Enterprise Architect, Red Gate SQL Doc och de inbyggda verktygen från olika leverantörer. Men även om verktygsstöd är användbart (och till och med kritiskt, i större databaser), gör du det hårda arbetet med att förstå och förklara den konceptuella modellen för databasen är den verkliga vinsten. Ur det perspektivet kan du till och med göra det i en textfil (även om att göra det i Wiki-form skulle tillåta flera personer att samarbeta för att lägga till den dokumentationen stegvis - så varje gång någon kommer på något kan de lägga till det i den växande kroppen av dokumentation omedelbart).