Updated: 9/27/2001

This is a partial screen-shot of a production Data Dictionary (DD) for web-based forms.

Other columns not shown here include:

• Help text (for a given form field).
• Various formatting options, such as currency (dollar) or blank-when-zero.
• SQL options (ignore when adding or editing, for example).
• Number of rows in large text fields (memos).
• DD Record ID.
• Programmer note (internal documentation).
• Whether nulls are allowed.
• More "group#" and "order#" columns (open-ended).

Note that the table that this example came from does not convert (or display) capitalization consistently for certain fields. Fortunately, the engine that uses this DD can interpret the codes either way because it is more or less DB-vendor-neutral. (Capitalization and validation have to be added on a vendor-specific basis unless/until some standard is agreed on.) It also only reads the first letter of the "Group1" field. Thus, the rest of the content beyond the first letter of that field only serves as documentation. The group field(s) allows different users to have different access.

Also note that if a field is missing a title entry ("fldTitle"), then the used title defaults to the field name ("fldName").

The slightly thicker line dividing the "fldName" and the "fldType" column indicates that the left two fields are "froze" in place in this particular table browser view. This allows one to pan left and right among the columns, yet still see the first two columns. (They are only "locked" horizontally, not vertically.)

This "field lock" feature is a feature of the table browser, and not the DD itself. I am only describing it to illustrate how table browser features can assist in viewing data dictionaries and other kinds of tables. An alternative to horizontal field locking is to provide an optional split screen, where each section scrolls independently in the horizontal direction. Visual Foxpro provided this feature, as did some AS/400 table browsers.

Another convenient feature provided by some table browsers is a "zoom" view of a particular cell. For example, the help text (not shown) is far to long to read entirely in the view shown. The zoom-view would open a larger window for a given cell so that the full text can be worked with or viewed. For example, one might put the cursor over a certain cell, and then press the F3 key to have a pop-up text window that allows a wider and larger view of that particular cell.

Some browsers can also display help or "tip" text in the status bar (not shown) as one moves the cursor to a given column. For example, it may briefly describe what the meanings of abbreviations and codes are for that column. If the cursor is in the "fldType" column, the status-bar or help-bar may say, "C=character, N=number, D=date/time, Y=yes/no (checkbox), M=memo (large text), L=list (dropdown)". That way the DD manager/developer does not have to memorize the code meanings.

The same information in a linear view (such as OO class/object attributes) would be much harder to navigate and view. Especially hard in the linear view is spotting patterns in a particular column. For example, we can easily see which rows don't have "all" or "A" in the Group1 column. (Even if an OO IDE can group by attributes across classes, it is using a different tool for code than it is for data. IOW, re-inventing the wheel.)

Note that this data dictionary has no programming code in it's fields. Such control tables don't need programming code in them to qualify as control tables nor data dictionaries.

Also, the framework that uses this DD layout allows many elements to be dynamically generated (overridden). For example, a pick-list can come from a query instead of being determined up-front. The code for such roughly resembles:

  routine pickListOverride(stage, field, value)
    ....
    if field = "hobbies" and stage="display" 
       value = getMyHobbies(value)    // get comma-sep. list items
    end if
    if field="email" and stage="validate"
       if containsBlanks(trim(value))
          AddFormError("Invalid Email Address")
       end if
       ....
    end if
    ....
  end routine

In practice, picklists have an optional "key" value to pair with each description. Thus, a fancier system may reference a table or a query to return or reference the list (table) of key-value pairs. See the discussion about "translation tables" under Challenge 6.

Example 2

This is a screen-shot of the sample report criteria table from Challenge 6. Note the similarities to the prior data dictionary. It is kind of a scaled-down version of the first example. This example shows the annotation message at the bottom. In this case the cursor is in the "TheList" field. (We called it "PickList" in the prior example. So much for consistency in naming.)

The field width defaults to about 20 if its zero or blank in the table. This is the input box width. The data entry width limit default is much longer since text can scroll in most current UI text boxes. However, if an explicit width is given, then the data entry is limited to that length value.

Terminology Issues

Someone has suggested that such be called "field dictionaries" instead of data dictionaries. However, "data dictionary" is already in common use. But, it is sometimes associated with high-end schemas instead of screen-fields. I will leave it to somebody else to sort out the terminology.