Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are interested in sharing the meta data and data dictionary among the team. I know that we can use the Extended Properties for this purpose, but based on my experience I've seen it gets out of date easily, because team members tend to forget to update them or skip this step.

I'm wondering if there is a more convenient way to create the data dictionary which can be maintained with the least amount of effort and time.

Thank you.

share|improve this question

closed as not a real question by Mark Storey-Smith, StanleyJohns, Phil, Max Vernon, ypercubeᵀᴹ May 12 '13 at 15:50

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Good question, with no "perfect" answer. On one project, we created a Wiki site, but this has the same problem as your Extended Properties. So make it a part of the project to document everything, at the end of a sprint or dev cycle (depending on methodology). – user1240 Oct 25 '12 at 23:10
See this question: Version control for database objects – ypercubeᵀᴹ May 12 '13 at 15:49
Use Dataedo, forget abut extended properties. – Bad Pitt May 5 '15 at 13:46

In our data warehouse, we built an application (data warehouse tracker) which maintains versions of data warehouse objects over time. When employees in our data warehouse (project manager, data modeler, DBA, ETL developer, Quality Assurance, data warehouse specialist, report writer, etc...) work on a project to build a new data model, we attach new objects and existing objects to those projects. Every change to a database object requires an explanation of what the object is being used for or what they are fixing in that object (new/change to data model, script being run to fix a data quality issue, ETL source code migration within informatica, defect being logged to a batch--or ETL staging or atomic run for data migration, report bug, etc...). When there is a report request using that column (or table), we require a comment about why they are using that object. If an defect is logged to that object, we attach a comment for the defect. Someone reading about that object can see all changes made to that object, so they can get a good understanding of what it's used for.

We started using Meta Data Manager in Informatica, but nobody ever updated the descriptions within the data dictionary. Because there may be different definitions of that object, we store the definition of all changes over time. Our new approach works well, because anyone can go and correct someone else's mistake, and that keeps everyone honest. Everyone using the object can comment on it's definition. We still track source lineage within Informatica, but we just link to that lineage from our data warehouse tracker.

share|improve this answer
"Every change to a database object requires an explanation of what the object is being used for or what they are fixing in that object " : isn't that normally termed "source code control"? – Mitch Wheat May 12 '13 at 3:58
The post you referred me to(above) was a good starting point.Thanks for that. – Sky May 12 '13 at 22:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.