Na minha experiência, os diagramas ER (ou UML) não são o artefato mais útil - com um grande número de tabelas, os diagramas (especialmente os de engenharia reversa) geralmente são uma grande bagunça complicada da qual ninguém aprende nada.

Para meu dinheiro, alguma boa documentação legível por humanos (talvez complementada com diagramas de partes menores do sistema) fornecerá a maior quilometragem. Isso incluirá, para cada tabela:

• Descrições do significado da tabela e como ela é usada funcionalmente (na interface do usuário etc.)
• Descrições do significado de cada atributo, caso não seja óbvio
• Explicações das relações (chaves estrangeiras) desta tabela para outras e vice-versa
• Explicações de restrições e/ou gatilhos adicionais
• Explicação adicional das principais visualizações e procs que tocam na tabela, se ainda não estiverem bem documentados

Com todos os itens acima, não documente por documentar - a documentação que reafirma o óbvio apenas atrapalha as pessoas. Em vez disso, concentre-se nas coisas que o confundiram no início e passe alguns minutos escrevendo explicações realmente claras e concisas. Isso ajudará você a pensar sobre isso e massivamente ajude outros desenvolvedores que se deparam com essas tabelas pela primeira vez.

Como outros já mencionaram, há uma grande variedade de ferramentas para ajudá-lo a gerenciar isso, como Enterprise Architect, Red Gate SQL Doc e as ferramentas integradas de vários fornecedores. Mas, embora o suporte da ferramenta seja útil (e até crítico, em bancos de dados maiores), fazer o trabalho duro de entender e explicando o modelo conceitual do banco de dados é a verdadeira vitória. A partir dessa perspectiva, você pode até fazê-lo em um arquivo de texto (embora fazê-lo no formato Wiki permitiria que várias pessoas colaborassem para adicionar a essa documentação de forma incremental - então, toda vez que alguém descobrir algo, ele poderá adicioná-lo ao corpo crescente de documentação instantaneamente).