Data Dictionary

A table of field, column, or variable definitions and related information. "Data about data". 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 CrudScreens. 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) [NoteAboutGeocities]

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
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)
prompt type (entry box, drop-down, combo-box, check-box, range, etc.)
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. See EventDrivenProgramming)
RegExp or a similar validation pattern, similar to COBOL "PIC's"

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.

The DataDictionary are a step toward InformationOrientedSoftwareDevelopment?. They contain information to be used to organize something rather than a table or column for each of the things themselves. A number of different kinds of tables can be classified as an InformationOrientedTable. The next step toward InformationOrientation? is to add a rich metadata field to the list of fields above.

Note that "dictionary" here has *nothing* to do with the DictionaryDataStructure. Just a name coincidence. I would perhaps call them "field dictionaries" or "field tables" if given the choice, but the name is entrenched already.

This product claims to use data dictionaries and/or schemas to generate CrudScreens:

http://www.alphora.com/tiern.asp?ID=DATAPHOR

Way before days of GUI, OOP, SQL, SSADM, etc there were data dictionaries. Two prominent dinosaurs on the BigBlue were Data Catalog and Data Manager. They attempted to address the need of DataAdministration?, as well as Database and schema generation.

Are these in use anywhere these days? What are the most prominent product in use now?

I still use them in some custom biz apps. I've see it in commercial products, but I don't remember the vendor names.

They are also used for InformationOriented VerticalArchitecture?.

For corporate systems, the Corporate Data Dictionary is an under-used resource, always buried within sub-systems and not corporate at all. What would happen if the cdd were used as a Corporate Data Dictionary for the corporation? What form would the dictionary take?

It would probably be buried in training manuals that no one read or updated (unless turnover was extreme).

CategoryInformation, CategoryMetaprogramming