En mi experiencia, los diagramas ER (o UML) no son el artefacto más útil:con una gran cantidad de tablas, los diagramas (especialmente los de ingeniería inversa) suelen ser un gran lío complicado del que nadie aprende nada.
Por mi dinero, una buena documentación legible por humanos (quizás complementada con diagramas de porciones más pequeñas del sistema) le dará la mayor ventaja. Esto incluirá, para cada tabla:
- Descripciones de lo que significa la tabla y cómo se usa funcionalmente (en la interfaz de usuario, etc.)
- Descripciones de lo que significa cada atributo, si no es obvio
- Explicaciones de las relaciones (claves foráneas) de esta tabla a otras, y viceversa
- Explicaciones de restricciones y/o disparadores adicionales
- Explicación adicional de las principales vistas y procesos que tocan la mesa, si aún no están bien documentados
Con todo lo anterior, no documente por documentar:la documentación que reafirma lo obvio simplemente se interpone en el camino de las personas. En su lugar, concéntrese en las cosas que lo confundieron al principio y dedique unos minutos a escribir explicaciones realmente claras y concisas. Eso te ayudará a pensarlo bien, y masivamente ayudar a otros desarrolladores que se encuentren con estas tablas por primera vez.
Como han mencionado otros, existe una amplia variedad de herramientas para ayudarlo a administrar esto, como Enterprise Architect, Red Gate SQL Doc y las herramientas integradas de varios proveedores. Pero si bien el soporte de herramientas es útil (e incluso crítico, en bases de datos más grandes), hacer el trabajo duro de comprender y explicar el modelo conceptual de la base de datos es la verdadera victoria. Desde esa perspectiva, incluso puede hacerlo en un archivo de texto (aunque hacerlo en forma Wiki permitiría que varias personas colaboraran para agregar a esa documentación de forma incremental, por lo que, cada vez que alguien descubre algo, puede agregarlo al cuerpo en crecimiento de documentación al instante).
