Documenting custom databases is a very nebulous concept. It's not often done and almost never done well... The idea is to include all of the information needed to 1) use the information in the database, 2) maintain or moddify the database structure,and/or 3) create new uses for the information in the datbase.
The audience may be technical or non-technical.
Once you have decided on the use and audience for the document then you can decide what level of detail or abstraction is needed.For example if the audience is technical and the use is maintenance or modification then what is usually considered ok for documentation is a collection of excel speadsheets which describe the various tables and their fields, as well as a listing ofthe indices on the tables. There should be a diagram which describes the interconnection of table through lookups, referential integrety, master/detail etc. The commented code for all stored procedures and/or triggers should be included.
If the audience is non-technical then you would have to "digest" this information and describe it in "plain English". Commented code is a waste of time for non-techs and instead a list of business rules applied is more appropriate.
As far as formats go, the "standards" can be found in books on the topic, but in the real world (outside the Fortune 500) those standards are not very common place.
If you wish, you may contact me at apf2.IHateSpam@apf2.com. (remove the commentary...)
Good Luck!
Al Franco, II
APF Creations
Pamplona, Spain