Analyzing systems using data dictionaries

This chapter is about creating data dictionary from data flow diagram

1. Chapter 8
Analyzing Systems
Using Data Dictionaries
Systems Analysis and Design
Kendall & Kendall
Sixth Edition

2. Kendall & Kendall © 2005 Pearson Prentice Hall 8-2
Major Topics
•Data dictionary concepts
•Defining data flow
•Defining data structures
•Defining elements
•Defining data stores
•Using the data dictionary

3. Kendall & Kendall © 2005 Pearson Prentice Hall 8-3
Data Dictionary
•Data dictionary is a place for analyzing
the data flows and data stores of data-
oriented systems.
•The data dictionary is a reference work
of data about data (metadata).
•It collects, coordinates, and confirms
what a specific data term means to
different people in the organization.

4. Kendall & Kendall © 2005 Pearson Prentice Hall 8-4
Reasons for Using a Data
Dictionary
•Provide documentation.
•Eliminate redundancy.
•Validate the data flow diagram.
•Provide a starting point for developing
screens and reports.
•To develop the logic for DFD processes.

5. Kendall & Kendall © 2005 Pearson Prentice Hall 8-5
The Repository
•A data repository is a large collection of
project information.
•It includes:
•Information about system data.
•Procedural logic.
•Screen and report design.
•Relationships between entries.
•Project requirements and deliverables.
•Project management information.

6. Kendall & Kendall © 2005 Pearson Prentice Hall 8-6
Data Dictionary and
Data Flow Diagram

7. Kendall & Kendall © 2005 Pearson Prentice Hall 8-7
Data Dictionary Contents
Data dictionaries contain:
•Data flow.
•Data structures.
•Data elements.
•Data stores.

8. Kendall & Kendall © 2005 Pearson Prentice Hall 8-8
Defining Data Flow
•Each data flow should be defined with
descriptive information and its
composite structure or elements.
•Include the following information:
•ID - identification number.
•Label, the text that should appear on the
diagram.
•A general description of the data flow.

9. Kendall & Kendall © 2005 Pearson Prentice Hall 8-9
Defining Data Flow
(Continued)
•The source of the data flow
•This could be an external entity, a process, or a
data flow coming from a data store.
•The destination of the data flow
•Type of data flow, either:
• A record entering or leaving a file.
• Containing a report, form, or screen.
• Internal - used between processes.

10. Kendall & Kendall © 2005 Pearson Prentice Hall 8-10
Defining Data Flow
(Continued)
•The name of the data structure or
elements
•The volume per unit time
•This could be records per day or any other unit
of time.
•An area for further comments and
notations about the data flow

11. Kendall & Kendall © 2005 Pearson Prentice Hall 8-11
Data Flow Example
Name Customer Order
Description Contains customer order information and is used
to update the customer master and item files and
to produce an order record.
Source Customer External Entity
Destination Process 1, Add Customer Order
Type Screen
Data Structure Order Information
Volume/Time 10/hour
Comments An order record contains information for one
customer order. The order may be received by
mail, fax, or by telephone.

12. Kendall & Kendall © 2005 Pearson Prentice Hall 8-12
Defining Data Structures
•Data structures are a group of smaller
structures and elements.
•An algebraic notation is used to
represent the data structure.

13. Kendall & Kendall © 2005 Pearson Prentice Hall 8-13
Algebraic Notation
The symbols used are:
•Equal sign, meaning “consists of”.
•Plus sign, meaning "and”.
•Braces {} meaning repetitive elements, a
repeating element or group of elements.
•Brackets [] for an either/or situation.
•The elements listed inside are mutually
exclusive.
•Parentheses () for an optional element.

14. Kendall & Kendall © 2005 Pearson Prentice Hall 8-14
Data Structure Example
Customer Order = Customer Number +
Customer Name +
Address +
Telephone +
Catalog Number +
Order Date +
{Order Items} +
Merchandise Total +
(Tax) +
Shipping and Handling +
Order Total +
Method of Payment +
(Credit Card Type) +
(Credit Card Number) +
(Expiration Date)

15. Kendall & Kendall © 2005 Pearson Prentice Hall 8-15
Structural Records
•A structure may consist of elements or
smaller structural records.
•These are a group of fields, such as:
•Customer Name.
•Address.
•Telephone.
•Each of these must be further defined
until only elements remain.

16. Kendall & Kendall © 2005 Pearson Prentice Hall 8-16
Structural Record Example
Customer Name = First Name +
(Middle Initial) +
Last Name
Address = Street +
(Apartment) +
City +
State +
Zip +
(Zip Expansion) +
(Country)
Telephone = Area code +
Local number

17. Kendall & Kendall © 2005 Pearson Prentice Hall 8-17
Defining Elements
•Data elements should be defined with
descriptive information, length and type
of data information, validation criteria,
and default values.
•Each element should be defined once in
the data dictionary.

18. Kendall & Kendall © 2005 Pearson Prentice Hall 8-18
Defining Elements (Continued)
•Attributes of each element are:
•Element ID. This is an optional entry that
allows the analyst to build automated data
dictionary entries.
•The name of the element, descriptive and
unique
•It should be what the element is commonly
called in most programs or by the major user of
the element.

19. Kendall & Kendall © 2005 Pearson Prentice Hall 8-19
Defining Elements (Continued)
•Aliases, which are synonyms or other
names for the element
•These are names used by different users
within different systems
•Example, a Customer Number may be
called a:
•Receivable Account Number.
•Client Number.

20. Kendall & Kendall © 2005 Pearson Prentice Hall 8-20
Defining Elements (Continued)
•A short description of the element
•Whether the element is base or derived
•A base element is one that has been initially
keyed into the system.
•A derived element is one that is created by a
process, usually as the result of a calculation or
some logic.
•The length of an element
What should that be?

21. Kendall & Kendall © 2005 Pearson Prentice Hall 8-21
Determining Element Length
What should the element length be?
•Some elements have standard lengths,
such as a state abbreviation, zip code, or
telephone number.
•For other elements, the length may vary
and the analyst and user community must
decide the final length.

22. Kendall & Kendall © 2005 Pearson Prentice Hall 8-22
Determining Element Length
Percent of data that will
Element Length fit within the length
Last Name 11 98%
First Name 18 95%
Company Name 20 95%
Street 18 90%
City 17 99%

23. Kendall & Kendall © 2005 Pearson Prentice Hall 8-23
Defining Elements - Format
•Input and output formats should be included,
using coding symbols:
•Z – Display leading zeros as spaces.
•9 – Number.
•X – Character.
•X(8) - 8 characters.
•, . - Comma, decimal point, hyphen.
•These may translate into masks used to
define database fields.

24. Kendall & Kendall © 2005 Pearson Prentice Hall 8-24
Defining Elements - Validation
•Validation criteria must be defined.
•Elements are either:
•Discrete, meaning they have fixed values.
•Discrete elements are verified by checking the
values within a program.
•They may search a table of codes.
•Continuous, with a smooth range of values.
•Continuous elements are checked that the data
is within limits or ranges.

25. Kendall & Kendall © 2005 Pearson Prentice Hall 8-25
Defining Elements
•Include any default value the element
may have
•The default value is displayed on entry
screens
•Reduces the amount of keying
•Default values on GUI screens
•Initially display in drop-down lists
•Are selected when a group of radio buttons are
used

26. Kendall & Kendall © 2005 Pearson Prentice Hall 8-26
Data Element Example
Name Customer Number
Alias Client Number
Alias Receivable Account Number
Description Uniquely identifies a customer that has made any business
transaction within the last five years.
Length 6
Input Format 9(6)
Output Format 9(6)
Default Value
Continuous/Discrete Continuous
Type Numeric
Base or Derived Derived
Upper Limit <999999
Lower Limit >18
Comments The customer number must pass a modulus-11 check-digit test.

27. Kendall & Kendall © 2005 Pearson Prentice Hall 8-27
Defining Data Stores
•Data stores contain a minimal of all
base elements as well as many derived
elements.
•Data stores are created for each
different data entity; that is, each
different person, place, or thing being
stored.

28. Kendall & Kendall © 2005 Pearson Prentice Hall 8-28
Data Store Definition
•The Data Store ID
•The Data Store Name, descriptive and
unique
•An Alias for the file
•A short description of the data store
•The file type, either manual or
computerized

29. Kendall & Kendall © 2005 Pearson Prentice Hall 8-29
Data Store Definition
(Continued)
•The maximum and average number of
records on the file
•The growth per year
•This helps the analyst to predict the
amount of disk space required.

30. Kendall & Kendall © 2005 Pearson Prentice Hall 8-30
Data Store Definition - Key
Fields
•Primary and secondary keys must be
elements (or a combination of
elements) found within the data
structure.
•Example: Customer Master File
•Customer Number is the primary key,
which should be unique.
•The Customer Name, Telephone, and Zip
Code are secondary keys.

31. Kendall & Kendall © 2005 Pearson Prentice Hall 8-31
Data Store Example - Part 1
ID D1
Name Customer Master
Alias Client Master
Description Contains a record for each customer
File Type Computer
File Format Database
Record Size 200
Maximum Records 45,000
Average Records 42,000
Percent Growth/Year 6%

32. Kendall & Kendall © 2005 Pearson Prentice Hall 8-32
Data Store Example - Part 2
Data Set/Table Name Customer
Data Structure Customer Record
Primary Key Customer Number
Secondary Keys Customer Name, Telephone, Zip Code
Comments The Customer Master file records are
copied to a history file and purged if the customer has not
purchased an item within the past five years. A customer
may be retained even if he or she has not made a purchase
by requesting a catalog.

33. Kendall & Kendall © 2005 Pearson Prentice Hall 8-33
Data Dictionary and
Data Flow Diagram Levels

34. Kendall & Kendall © 2005 Pearson Prentice Hall 8-34
Using the Data Dictionary
Data dictionaries may be used to:
•Create reports, screens, and forms.
•Generate computer program source code.
•Analyze the system design for completion
and to detect design flaws.

35. Kendall & Kendall © 2005 Pearson Prentice Hall 8-35
Group Project
•Page 270 #7, #4
•Page 269 #3
The Format character code meanings are on
the bottom of p. 254 in Figure 8.8.

36. Kendall & Kendall © 2005 Pearson Prentice Hall 8-36
Customer Order

37. Kendall & Kendall © 2005 Pearson Prentice Hall 8-37
Data Structure
for Customer
Order p. 303
Algebraic Notation

38. Kendall & Kendall © 2005 Pearson Prentice Hall 8-38