DATA DICTIONARIES
SYS364
page 1 of 1
PURPOSE:
•
•
•
•
•
To ensure that everyone working on the development, maintenance, or usage of a system uses consistent
names and conventions for all its components
during Analysis: by the analysts when reviewing requirements with users, to serve as reference for the DFDs of
the existing system and any proposed improvements
during Design, as reference for DFDs of proposed system; as specifications for programmers, analysts, and data
entry personnel who will construct the system
during construction, to ensure naming consistency amongst programmers, etc.
during installation, as reference for DFDs when training users and planning conversion strategies
during usage, as reference for DFDs used to train new users, as reference for programmers, etc. when making
system revisions
ORGANIZATION:
The DD should be reasonably compact in a table or spreadsheet format, and be alphabetically sorted by entry name.
Traditionally, everything is in one dictionary. Many people find this difficult to use and the tabular format cannot be
optimized to present information appropriate to the kind of entry (i.e. the old one-size-fits-all problem). It is useful to
have separate sections for different types of entry (individual fields, records, files, documents, etc., plus entities, processes
(programs and procedures).
SUGGESTED CONTENT
For DFD Entities:
Name: absolutely unique, not used for anything else
Description: person, department, institution, or company
Data Source for (inputs information ) .... (reference the Data Element(s) or Data Group name this Entity provides);
Data Sink for (receives output) ... (reference the Data Element(s) or Data Group name this Entity receives)
For DFD Processes: ( computer program or manual procedure)
Name on DFD:
Number on DFD:
Description: for DFD levels 0 and 1 ... describe what this process does in general; for lower DFD levels ... document the
Manipulation or Calculation performed [formulae], pseudocode is specified at the lowest DFD level.
Input(s): (reference Data Group)
Output(s): (reference Data Group)
Frequency used: (whether by calendar, clock, or event|occasion)
For Data Elements: ( fields or columns)
Name: absolutely unique (e.g., nothing called "date", since there are so many!)
Description: fuller explanation of the content of the field
Format: data type, size, precision & scale, output editing (most convenient as COBOL PICTURE)
Membership: the DD names for groups, files, records, etc. of which this field is a part. Cross reference the element to
everywhere it appears.
Acceptable values: a list or range of valid values for this element. Define the domain.
Source: if input, the form or screen that provides it; if generated, DFD process which derives it
Destination: when output, where is it used: screens, reports, DFD processes.
Validation: (if input) how validated
For Data Groups: (ERD entity, DFD flows, records, files, databases, documents(reports), subsets of these )
Name:
Type: whether DFD Flow, or File, or Record, or Database, or Document, or subset of one of these.
If a File, what kind? E.g. Master, Transaction, Audit, History, Control.
Description: if flow, then to/from DFD names; if other, then its role in this system
[Membership: DD names for Groups which contain this one]
Content: list or "formula" for groups or elements this group contains
Organization: whether chrono, sequential, random, or indexed plus key field(s)
Volume: how many, how often or on what occasion
For Alias Entries:
( Note that some analysts include aliases together with other entries )
Name: an alternate name for another entry in the DD
Name to see for full description and features