From Ajax Patterns
A Data Dictionary is table of field or variable definitions and related information. The fields may mirror database tables, screen fields, and/or report fields. Typical data dictionaries have attributes such as field name, field title, field type, maximum length, default value, and perhaps even event handlers.
Sometimes they are used merely to document parts of a system, other times they are actually processed or read by the system to generate CrudScreen's. Most RDBMS have some form of basic built-in DataDictionary to define table columns.
Think about taking all the attributes of an HTML Input tag, and making a table out of those attributes. This could form the basis of a DataDictionary. Some people find that tablizing such information helps them see patterns that one could not see if the same information was in an Input tag. Plus, one can issue queries on such data to get different viewpoints for inspection and perhaps entry.
http://geocities.com/tablizer/ddsamp.htm (Example illustrations)
Typical fields or items found in a DataDictionary:
- entity or form name or ID
- field name (such as RDBMS field name)
- field title (defaults to field name if blank)
- field type or format code. Typical types:
- Number (Float, Decimal, or Real)
- dimension(s) such as min and max values, display width, or number of decimal places.
- display or tab order
- coordinates on screen (if positional UI)
- default value (for adds)
- is required (Boolean)
- is read-only (Boolean)
- Reference to parent or containing widget/form
- list source (if a drop-down list. Could be a handler or query expression)
- various event handlers (onClick, onValidate, etc.)
Event handlers can pass an associative array (dictionary) of certain stats and items of info that the handler may need. Perhaps the event handlers could be a separate table.
Note that "dictionary" here has *nothing* to do with the Dictionary Data Structure. Just a name coincidence. I would perhaps call them "field dictionaries" or "field tables" if given the choice, but the name is entrenched already.
Sometimes screen or report columns don't match one-to-one with database columns. In such cases some kind of group or set selection would be nice such that various sub-groups of fields can be included or excluded as needed. This eliminates the need to copy very similar structures over and over, which results in better information factoring. I have used letter groupings in the past where one can include or exclude a given letter(s), but this is kind of informal. A more formal solution would be a many-to-many list to map groups to columns. Hierarchical inheritence does not seem sufficient in my experience.