Finding data ownership can be a really worthwhile task. There you are with the task of documenting a database, someone suggests that you google a few definitions and and do a bit of cut and paste. Then you decide to do something worthwhile, and determine who owns the data, this may cause a few sharp intakes of breath from those that think the IT department owns the data. If you want to attach a bit of methodology, think of applying a Zachman Framework to the data structure as a business model (don’t get too hung up on Zachman). Once you’ve started identifying ownership you can start thinking about dependencies, permissions, life-cycle’s and all sorts of other data goodness. That list of data owners will be useful for a number of roles, managers, analysts, testers etc. The structure may not be simple, you may find records with multiple owners and have to negotiate who is the master, and it’s a good idea to have a single master, for transactional data it may be you!
This is where the a governance model comes into play, IT can be the keeper of the metadata, assuming you have the luxury of an IT department else the responsibility falls to the data owner. The owner will have contributors and consumers and needs to be aware of who they are and what their rights are. Individual data items may be owned by customers, please consider confidentiality and privacy considerations. Useful information can be collected down to the individual data item, you may need to define some domain information for some data items, alternate names and scope.
Once all this information is is collected, or maybe even sooner, it is important to publish, and publish so that all stakeholders can access the information. Then when someone says “We need a new keyword for this!”, they can find the ownership and responsibilities of “keyword” and act accordingly. Database documentation, if you build it well, it will be adopted and maintained by the business as an asset.