Thursday, January 16, 2014

Data Dictionary Example Content

Standard Dictionary, twentieth century edition. [inside]  
Following my last post on why a data dictionary is so useful, I have provided below some specific information you might want to store in a data dictionary. For a simple dictionary, you probably don't need to record everything listed below (although for larger systems you might even want more?) - it of course depends on your specific needs and issues. But hopefully this is a good start.

Fields - broken down by "area" of the database or by table
(e.g. if you are using a traditional fundraising database, then you might break it down by screen; if you have a bespoke SQL database then by table. Whatever makes sense and means you can find this information simply later on).
  • Data element name
  • Field name
  • Field label if different
  • Description/Meaning (in English, not technical)
  • Active? (i.e. is it still being used or is it just historic data)
  • Data Type
  • Data source (e.g. if it uses a Lookup table - cf below)
  • Max/Min length
  • Default value
  • Mandatory?
  • Unique?
  • Hidden?
  • Calculated field? (e.g. Age, Total Donations)
  • Causes dependency on
  • Dependent on
  • Other Business Rules/validation rules
  • Security notes
  • Primary Key/Foreign Key - if appropriate for more technical requirements

Lookup Tables
aka Drop-down lists, picklists, reference data etc.
  • Table name
  • Description/Meaning (in English, not technical)
  • Field(s) where it is used
  • All values - cf below

Each value in a Lookup table
  • Value
  • Meaning
  • Active? (i.e. is it still being used or is it just historic data)
  • Causes dependency on
  • Dependent on
And possibly other similar attributes to the Fields above


You can of course add Entity Relationship Diagrams (ERDs) which can be very useful and show the relationships between the tables.

No comments: