Data Dictionary Fundamentals

The templates in the back of your Casebook are actually very good. I’m going to use these to explain what is involved in a data dictionary. There are other formats for preparing data dictionaries, the point is to thoroughly document the the system.

Purpose of a Data Dictionary: To DOCUMENT for all posterity the data elements, structures, flows, stores, processes, and external entities in the system to be designed.

Optimum Format: The structures and elements are on the ERD. The Data Flows, Processes, and External Entities are from the DFDs. Number the objects on the diagrams and refer to those objects in the data dictionary by thier numbers. Use "dot notation." Example: Diagram 1 has 4 processes, 1,2,3,4. The explosion for process 1 will be Diagram 1.1, 1.2, etc, depending on how much detail can be derived from your Diagram 1. Explosions of 1.1 would be 1.1.1, 1.1.2, etc. The Listings of your objects have the page numbers of the object descriptions.

Here are the definitions of these items. Keep in mind that a data dictionary can be created INDEPENDENT of the how the system will be implemented (ie A DBMS such as Sybase or Oracle, spreadsheet, or yellow legal pad.) Please refer to the Casebook Appendix on page 79 for each of the following.

Data Stores: A inventory of data. The whole of the data in a small system. A database. Very large systems may have more than one database. Data Store Listing: The A# page is a reference to the page number of each data store description. More than one data store description on each page is OK. Data Store Description:

Brief description: A description which distinguishes this data store from others. In FSS, I would anticipate only one data store.

Organization/Volume/Physical Implementation Info: How is the data store organized, ie geographically, functionally. How big (MB) the data store is expected to be. What implementation considerations are there? If this is a proposed data dictionary, keep your mind open, if it’s an existing data dictionary, go ahead and note what DBMS (or color legal pad) you will be using. Note any other implementation issues.

Contents: List the structures in the data store.

Inflows and outflows: List these.

Data Structures: Specific arrangements of data attributed (elements) that define the organization of a single instance of a data flow. Data structures belong to a particular data store. Think about this... Remember that this could be manifested in any way from a yellow legal pad to an advanced DBMS. One instance of data flow could be the answers on a form. The answers would be put in to an organized structure. However, I’d like for you to keep your mind open to the possibility that the "answers on your form may actually populate more than one "table" in a database. For example, you may desire to collect information about an instance of an "employee." Employees pave payroll information, perhaps work address information, and human resources information. Because the purpose of this information is to serve several systems or data flows, you might want to store the whole of the employee information in several data structures. Data Structure Listing: Same as Data Store Listing above. Data Structure Description:

Brief Description: Same as above.

Contents: List the data element (or attribute) names. Just list them, no need to give details.

Used in Data Store(s), Data Structure(s), Data Flows(s): List these.

Data Elements: The descriptive property or characteristic of an entity. In database terms, this is a "attribute" or a "field." In Microsoft and other vendor terms, this is a "property." Therefore, the data element is part of a data structure, which is part of a data store. It has a source, and there may be data entry rules you wish to enforce on this element. Data Element Listing: Same as above. Data Element Description:

Brief Description: Same as above. Must distinguish from other elements.

Value Range/interpretation: Has to do with datatype or range of acceptible values. Example: a data element for zip code is any group of 5 digits (or 5+4) Must be numbers, must be 5 digits. Or, another example, a code must be "A" through "E."

Source/Policy/Control/Editing Info: Where does the data element come from? Example: Source: "from order form line 12" What are some business rules about this data? Must this element also exist in another structure before it can exist in this one?

Used in Data Store(s), Data Structure(s), Data Flows(s): List these.

Data Flows: Represent an input of data to a process, or the output of data (or information) from a process. A data flow is also used to represent the creation, deletion, or updating of data in a file or database (called a "data sore" in the Data Flow Diagram (DFD.) Note that a data flow is not a process, but the passing of data only. These are represented in the DFD. Each data flow is a part of a DFD Explosion of a particular process. Data Flow Listing: Same as above. Data Flow Description: Note the DFD Explosion #.

Brief Description: Same as above.

Volume/Physical Implementation Info: What is the volume of this data flow per day, week, month, whatever is appropriate? Does this dataflow require an Internet connection? A car?

Source and Destination: Fill out as appropriate. What are the sources and destinations of this data flow?

Processes: Work performed on or in response to, incoming data flows or conditions. The FSS Context Diagram includes "FSS System" and all the inputs and outputs of the FSS system. The DFD Diagram 0 (if you’d included everything, just as an example) would be 1. Accounts Payable, 2. Order Processing, 3. Catering Processing, 4. Payroll Processing, 5. Accounts Payable Processing, 6. Warehouse Processing, 7. Inventory Processing, and 8. Store Processing. Each of these processes has inputs and outputs that are independent of the other. Process Listing: Same as above. Process Description: Note the DFD Explosion #.

Brief Description: Same as above.

Purpose/Physical Implementation Info: Why do we need this process? State a specific purpose. Indicate any implementation issues. Does the process need to accept certain types of data? Certain type of DBMS or ODBC? What are the inflows and outflows? (If inflows and outflows are the same... then you have a data flow and not a process.)

External Entities: A person, organization unit, other system, or other organization that lies outside the scope of the project but that interacts with the system being studied. External entities provide the net inputs into a system and receive net outputs from the system. This and the others are definitions from the book. Basically, external entities are those entities that are outside the scope of the project or system at hand. External Entities Listing: Same as above. External Entities Description:

Brief Description: Same as above.

Inflows and Outflows: List here. These are the interfaces to the system (in this case, FSS)

Interface Constraints/Misc. Info: For Example: ODBC, Internet.