Depending on the complexity of the database, like if you're dealing with 100+ tables, then even a good auto-generated document isn't always meaningful. It's the type of thing that management requests, but then no one really looks at. When I'm acquainting myself with a legacy database, I'll start with a reverse engineering ERD tool, but if foreign key relationships are not declared, it's limited. To better understand a database, I'll run a SQL trace within the context of a specific business processes like month-end reporting or populating a customer information screen, and then infer relationships between tables by reading the SELECT statement joins. I will then create (mostly by hand) smaller scoped ERD diagrams or Kimball style business matrix charts (which also work for normalized OLTP databases). I'll then proceed to document the database one business process at a time.
http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/kimball-data-warehouse-bus-architecture/
You know where having the automated generation of documentation came in handy? Audits. I just gave them a Word doc they glanced at the page count and we were done with that section of the audit. Winning!
Heh... I'm, going to that next time except I'm going to save on toner.... cover page and table of contents followed by two tables and 300 blank pages. 😉