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/