Ch 8 - Analyzing Systems Using Data Dictionaries

The Data Dictionary

A reference work of data (that is, metadata)

• Used to catalog data processes, flows, stores, structures, and elements

• Ensures consistency in naming and definitions across the system

Automated Data Dictionaries

(part of the computer-aided software engineering [CASE] tools) are valuable for their capacity to cross-reference data items, thereby allowing necessary program changes to all applications that share a common element.

• Some computerized data dictionaries automatically catalog data items

• Others provide a template to promote the person filling in the dictionary

Need for Understanding the Data Dictionary

May be used to:

1. Validate the DFD for completeness and accuracy

2. Provide a starting point for developing screens and reports

3. Determine the contents of data stored in files

4. Develop the logic for DFD processes

5. Create extensible markup language (XML)

The Data Repository

A shared collection of project information and team contributions

May contain the following:

1. Information about the data maintained by the system, including data flows, data stores, record structures, elements, entities, and messages

2. Procedural logic and use cases

3. Screen and report design

4. Data relationships, such as how one data structure is linked to another

5. Project requirements and final system deliverables

6. Project management information, such as delivery schedules, achievements, issues that need resolving, and project users

Defining the Data Flows

First components to be defined. May be summarized using the following:

1. An optional id number. Sometimes the ID is coded using a scheme to identify the system and the application in the system

2. A unique descriptive name for the data flow. This name is the text that should appear on the diagram and should be referenced in all descriptions using the data flow.

3. A general description of the data flow.

4. The source of the data flow. The source could be an external entity, a process, or a

   data flow coming from a data store.

5. The destination of the data flow (same items listed under the source).

6. An indication of whether the data flow is a record entering or leaving a file or a record containing a report, form, or screen. If the data flow contains data that are used between processes, it is designated as internal.

7. The name of the data structure describing the elements found in this data flow. For a simple data flow, it could be one or several elements.

8. The volume per unit of time. The data could be records per day or any other unit of time.

9. An area for further comments and notations about the data flow.

Data Structures

Describe using algebraic notation:

• An equal sign (=) means “is composed of.”

• A plus sign (+) means “and.”

• Braces {} indicate repetitive elements, also called repeating groups or tables. There may be one repeating element or several in a group. The repeating group may have conditions, such as a fixed number of repetitions, or upper and lower limits for the number of repetitions.

• Brackets [] are used for an either/or situation. Either one element or another may be present, but not both. The elements listed between the brackets are mutually exclusive.

• Parentheses () are used for an optional element. Optional elements may be left blank on entry screens and may contain spaces or zeros for numeric fields in file structures.

structural records

some of the entries are elements but others can be CUSTOMER NAME, ADDRESS, and TELEPHONE are groups of elements

Physical Design Elements

1. Key fields used to locate records in a database table. An example is an item number, which is not required for a business to function but is necessary for identifying and locating computer records.

2. Codes to identify the status of master records, such as whether an employee is active (currently employed) or inactive. Such codes can be maintained on files that produce tax information.

3. Transaction codes are used to identify types of records when a file contains different record types. An example is a credit file containing records for returned items as well as records of payments.

4. Repeating group entries containing a count of how many items are in the group.

5. Limits on the number of items in a repeated group.

6. A password used by a customer accessing a secure website.

Repeating Items

If the group repeats a fixed number of times, that number is placed next to the opening brace, as in 12 {Monthly Sales}, indicating the group repeats 12 times, once for each month in the year. If no number is indicated, the group repeats indefinitely.

Data Elements

1. Element ID

2. The name of the Element

3. Aliases, which are synonyms or other names for the element

4. A short description of the element

5. Whether the element is base or derived

6. The length of an element

7. The type of data: numeric, date, alphabetic, varcher, or character

8. Input and output formats

9. Validation criteria

10. Any default value the element may have

11. An additional comment or remarks area

Data Stores

Data stores are created for eah different data entity being stored

1. The data store ID

2. The. data store name

3. An alias for the table

4. A short description of the data store

5. The file type, either computer or manual

6. The format designates whether the file is a database table or a simple flat file

7. The maximum and avg number of records on the file as well as the anticipated growth per year

8. The file or data name

9. The data structure name

10. Primary and secondary keys

Creating a Data Dictionary

Analyzing Input and Output

1. A descriptive name for the input or output. If the data flow is on a logical diagram, the name should identify what the data are

2. The user contact responsible for further details clarification, design feedback and final approval

3. Whether the data is input or p

Components of a Data Dictionary

• Data Flows

  • Movement of data between processes, stores, or external entities

• Data Structures

  • Logical groupings of data elements (e.g., CUSTOMER = First Name + Last Name + Address)

• Data Elements

  • The smallest units of data (e.g., Firsst name, Zip code)

• Data Stores

  • Locations where data is held (e.g, databases, files)

Data Dictionary Conventions (Algebraic Notation)

Symbol	Meaning
=	"Is composed of"
+	"And" (concatenation)
{ }	Repeating elements (e.g., {Order Line})
[ ]	Mutually exclusive options (e.g., `[Credit Card	Debit Card]`)
( )	Optional elements (e.g., (Middle Initial))

Logical Data Structures

Represents business view of data (what users see).
Example: Customer Name, Address

Physical Structure

	Includes technical details (keys, codes, storage formats).
	Example: Customer_ID (Primary Key), Status_Code (A=Active, I=Inactive).

Based Element

Entered directly into the system (e.g., Unit Price)

Derived Element

Calculated or derived from other elements (e.g., Total = Quantity x Unit Price)

Automated Data Dictionaries & CASE Tools

• Cross-reference data elements to ensure consistency.

• Help track changes across multiple programs.

• Support large systems with thousands of data elements.

Data Repository

• A larger collection of project information, including:

  • Data flows, stores, and elements.

  • Screen/report designs.

  • Procedural logic (use cases).

  • Project management details.

Extensible Markup Language (XML)

• enables data exchange between different systems.

Document Type Definition (DTD)

Ensures XML documents follow a valid structure

XML Schemas

Provide stricter validation (data types, lengths, constraints

Metadata

Data that describes other data

Data Flow

Movement of data between processes, stores, or external entities

Data Structure

A logical grouping of data elements (e.g., CUSTOMER = First Name + Last Name + Address)

Base Element

Data entered directly into the system (e.g., Unit Price).

Derived Element

Data calculated from other elements (e.g., Total = Quantity × Unit Price).

Repository

A shared collection of project information, including data, designs, and requirements

DTD (Document Type Definition)

Defines the structure of an XML document.

Schema

A stricter alternative to DTD, specifying data types and constraints.

Why is a data dictionary important?

• Ensures consistency, avoids redundancy, validates DFDs, and aids in system design.

How does XML relate to data dictionaries?

Data dictionaries define the structure, which can be used to generate XML documents.

What is the purpose of a DTD?

Ensures an XML document follows the correct structure.

What are CASE tools?

Computer-Aided Software Engineering tools that automate data dictionary management.

Summary

A data dictionary is essential for organizing and standardizing system data. It helps analysts validate DFDs, design interfaces, and ensure consistency. Automated tools (CASE) enhance efficiency, while XML enables data exchange across different platforms. Understanding logical vs. physical structures and base vs. derived elements is key to effective system design.

How does a data dictionary relate to DFDs?

• The data dictionary documents and expands the components (data flows, stores, processes) identified in DFDs, ensuring clarity and accuracy.

What are the four main components of a data dictionary?

• Data Flows (movement of data),

• Data Structures (groupings of elements, e.g., CUSTOMER = Name + Address),

• Data Elements (atomic units, e.g., First Name),

• Data Stores (where data is held, e.g., databases).

Explain the difference between base and derived elements.

• Base elements: Directly input/stored (e.g., Unit Price).

• Derived elements: Calculated from other data (e.g., Total = Quantity × Unit Price).

What is the difference between a data dictionary and a repository?

• Data dictionary: Focuses on metadata (data definitions).

• Repository: Broader; includes DFDs, screen designs, project plans, and other documentation.

How can a data dictionary help in designing XML documents?

• It provides the structure and definitions of data elements, which can be mapped directly to XML tags (e.g., <customer> for CUSTOMER).

What is a DTD, and how does it ensure valid XML?

• A Document Type Definition (DTD) defines the allowed structure of an XML document (e.g., required elements, order). It validates XML by checking compliance.

Why is a schema more powerful than a DTD?

• Schemas support data types (e.g., integers, dates), constraints (e.g., field lengths), and are written in XML, making them more flexible than DTDs.