SlideShare a Scribd company logo
1 of 56
Chapter 10 
Analyzing Systems 
Using Data Dictionaries 
Systems Analysis and Design 
Kendall and Kendall 
Fifth Edition
Major Topics 
 Data dictionary concepts 
 Defining data flow 
 Defining data structures 
 Defining elements 
 Defining data stores 
 Using the data dictionary 
 Data dictionary analysis 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-2
Data Dictionary 
 Data dictionary is a main method 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-3
Reasons for Using a Data 
Dictionary 
 The data dictionary may be used for the 
following reasons: 
 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-4
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-5
Data Dictionary Contents 
 Data dictionaries contain 
 Data flow 
 Data structures 
 Elements 
 Data stores 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-6
Defining Data Flow 
 Each data flow should be defined with 
descriptive information and it's 
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-7
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-8
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-9
Data Flow Example 
Name Customer Order 
Description Contains customer order information and is used 
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 
Kendall & 
Kendall 
to update the customer master and item files and 
to produce an order record. 
customer order. The order may be received by 
mail, fax, or by telephone. 
Copyright © 2002 by 
Prentice Hall, Inc. 10-10
Defining Data Structures 
 Data structures are a group of smaller 
structures and elements 
 An algebraic notation is used to 
represent the data structure 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-11
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-12
Repeating Groups 
 A repeating group may be 
 A sub-form 
 A screen or form table 
 A program table, matrix, or array 
 There may be one repeating element or 
several within the group 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-13
Repeating Groups 
 The repeating group may have 
 Conditions 
 A fixed number of repetitions 
 Upper and lower limits for the number of 
repetitions 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-14
Physical and Logical Data 
Structures 
 Data structures may be either logical or 
physical 
 Logical data structures indicate the 
composition of the data familiar to the 
user 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-15
Physical Data Structures 
 Include elements and information 
necessary to implement the system 
 Additional physical elements include 
 Key fields used to locate records 
 Codes to indicate record status 
 Codes to identify records when multiple 
record types exist on a single file 
 A count of repeating group entries 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-16
Data Structure Example 
Customer Order = Customer Number + 
Kendall & 
Kendall 
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) 
Copyright © 2002 by 
Prentice Hall, Inc. 10-17
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-18
General Structural Records 
 Structural records and elements that 
are used within many different systems 
should be given a non-system-specific 
name, such as street, city, and zip 
 The names do not reflect a functional 
area 
 This allows the analyst to define them 
once and use in many different 
applications 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-19
Structural Record Example 
Kendall & 
Kendall 
Customer Name = First Name + 
(Middle Initial) + 
Last Name 
Address = Street + 
(Apartment) + 
City + 
State + 
Zip + 
(Zip Expansion) + 
(Country) 
Telephone = Area code + 
Copyright © Local 2002 number 
by 
Prentice Hall, Inc. 10-20
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-21
Defining Elements 
 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-22
Defining Elements 
 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-23
Defining Elements 
 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-24
Defining Elements 
 The length of an element 
 This should be the stored length of the item 
 The length used on a screen or printed 
lengths may differ 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-25
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-26
Determining Element Length 
 Numeric amount lengths should be 
determined by figuring the largest number 
the amount will contain and then allowing 
room for expansion 
 Totals should be large enough to 
accommodate the numbers accumulated 
into them 
 It is often useful to sample historical data to 
determine a suitable length 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-27
Determining Element Length 
Element Length fit within the length 
Last Name 11 98% 
First Name 18 95% 
Company Name 20 95% 
Street 18 90% 
City 17 99% 
Kendall & 
Kendall 
Percent of data that will 
Copyright © 2002 by 
Prentice Hall, Inc. 10-28
Data Truncation 
 If the element is too small, the data will 
be truncated 
 The analyst must decide how this will 
affect the system outputs 
 If a last name is truncated, mail would 
usually still be delivered 
 A truncated email address or Web 
address is not usable 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-29
Data Format 
 The type of data, either numeric, date, 
alphabetic or alphanumeric or other 
microcomputer formats 
 Storage type for numeric data 
 Mainframe: packed, binary, display 
 Microcomputer (PC) formats 
 PC formats depend on how the data will be 
used, such as Currency, Number, or 
Scientific 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-30
Personal Computer Formats 
Bit - A value of 1 or 0, a true/false value 
Char, varchar, text - Any alphanumeric character 
Datetime, smalldatetime - Alphanumeric data, several formats 
Decimal, numeric - Numeric data that is accurate to the least significant digit 
Float, real - Floating point values that contain an approximate decimal value 
Int, smallint, tinyint - Only integer (whole digit) data 
Money, smallmoney - Monetary numbers accurate to four decimal places 
Binary, varbinary, image - Binary strings (sound, picture, video) 
Cursor, timestamp, uniqueidentifier - A value that is always unique 
Kendall & 
Kendall 
Can contain a whole and decimal portion 
within a database 
Copyright © 2002 by 
Prentice Hall, Inc. 10-31
Defining Elements - Format 
 Input and output formats should be 
included, using coding symbols: 
 Z - Zero suppress 
 9 - Number 
 X - Character 
 X(8) - 8 characters 
 . , - Comma, decimal point, hyphen 
 These may translate into masks used to 
define database fields 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-32
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-33
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-34
Defining Elements 
 An additional comment or remarks area 
 This might be used to indicate the 
format of the date, special validation 
that is required, the check-digit method 
used, and so on 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-35
Data Element Example 
Name Customer Number 
Alias Client Number 
Alias Receivable Account Number 
Description Uniquely identifies a customer that has made any business 
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 
Discrete Value/Meaning 
Comments The customer number must pass a modulus-11 check-digit test. 
Kendall & 
Kendall 
transaction within the last five years. 
Copyright © 2002 by 
Prentice Hall, Inc. 10-36
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-37
Defining Data Stores 
 Data flow base elements are grouped 
together and a data store is created for 
each unique group 
 Since a data flow may only show part of 
the collective data, called the user view, 
you may have to examine many 
different data flow structures to arrive at 
a complete data store description 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-38
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-39
Data Store Definition 
 If the file is computerized, the file format 
designates whether the file is a 
database file or the format of a 
traditional flat file 
 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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-40
Data Store Definition 
 The data set name specifies the table or 
file name, if known 
 In the initial design stages, this may be left 
blank 
 The data structure should use a name 
found in the data dictionary 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-41
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-42
Data Store Example - Part 1 
ID D1 
Name Customer Master File 
Alias Client Master File 
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% 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-43
Data Store Example - Part 2 
Data Set/Table Name Customer 
Copy Member Custmast 
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. 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-44
Data Dictionary and Data Flow 
Diagram Levels 
 Data dictionary entries vary according 
to the level of the corresponding data 
flow diagram 
 Data dictionaries are created in a top-down 
 Data dictionary entries may be used to 
validate parent and child data flow 
diagram level balancing 
Kendall & 
Kendall 
manner 
Copyright © 2002 by 
Prentice Hall, Inc. 10-45
Data Dictionary and Data Flow 
Diagram Levels 
 Whole structures, such as the whole 
report or screen, are used on the top 
level of the data flow diagram 
 Either the context level or diagram zero 
 Data structures are used on 
intermediate-level data flow diagram 
 Elements are used on lower-level data 
flow diagrams 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-46
Creating Data Dictionaries 
 1. Information from interviews and JAD 
sessions is summarized on Input and 
Output Analysis Forms 
 This provides a means of summarizing 
system data and how it is used 
 2. Each structure or group of elements 
is analyzed 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-47
Creating Data Dictionaries 
 3. Each element should be analyzed by 
asking the following questions: 
 A. Are there many of the field? 
 If the answer is yes, indicate that the field is a 
repeating field using the { } symbols 
 B. Is the element mutually exclusive of 
another element? 
 If the answer is yes, surround the two fields 
with the [ | ] symbols 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-48
Creating Data Dictionaries 
 C. Is the field an optional entry or 
optionally printed or displayed? 
 If so, surround the field with parenthesis ( ) 
 4. All data entered into the system must 
be stored 
 Create one file or database file for each 
different type of data that must be stored 
 Add a key field that is unique to each file 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-49
Determining Data Store 
Contents 
 Data stores may be determined by 
analyzing data flows 
 Each data store should consist of 
elements on the data flows that are 
logically related, meaning they describe 
the same entity 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-50
Maintaining the Data 
Dictionary 
 To have maximum power, the data 
dictionary should be tied into other 
programs in the system 
 When an item is updated or deleted 
from the data dictionary it is 
automatically updated or deleted from 
the database 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-51
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 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-52
Creating Reports, Screens, 
Forms 
 To create screens, reports, and forms 
 Use the element definitions to create fields 
 Arrange the fields in an aesthetically 
pleasing screen, form, or report, using 
design guidelines and common sense 
 Repeating groups become columns 
 Structural records are grouped together on 
the screen, report, or form 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-53
Data Dictionary Analysis 
 The data dictionary may be used in 
conjunction with the data flow diagram 
to analyze the design, detecting flaws 
and areas that need clarification 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-54
Data Dictionary Analysis 
 Some considerations for analysis are 
 All base elements on an output data flow 
must be present on an input data flow to 
the process producing the output 
 Base elements are keyed and should 
never be created by a process 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-55
Data Dictionary Analysis 
 A derived element should be output from at 
least one process that it is not input into 
 The elements that are present on a data 
flow into or coming from a data store must 
be contained within the data store 
Kendall & 
Kendall 
Copyright © 2002 by 
Prentice Hall, Inc. 10-56

More Related Content

What's hot

What's hot (20)

Chap22
Chap22Chap22
Chap22
 
Chap20
Chap20Chap20
Chap20
 
Chap06
Chap06Chap06
Chap06
 
Chap01
Chap01Chap01
Chap01
 
Chap12
Chap12Chap12
Chap12
 
Chap07
Chap07Chap07
Chap07
 
Chap09
Chap09Chap09
Chap09
 
Chap04
Chap04Chap04
Chap04
 
Kendall sad8e ch03
Kendall sad8e ch03Kendall sad8e ch03
Kendall sad8e ch03
 
Ch10-Program Design
Ch10-Program DesignCh10-Program Design
Ch10-Program Design
 
Eform & Workflow Software
Eform & Workflow SoftwareEform & Workflow Software
Eform & Workflow Software
 
A Quick Introduction to E-Forms
A Quick Introduction to E-FormsA Quick Introduction to E-Forms
A Quick Introduction to E-Forms
 
Designing database week ix part 1
Designing database week ix part 1Designing database week ix part 1
Designing database week ix part 1
 
837 preparation for testing
837 preparation for testing837 preparation for testing
837 preparation for testing
 
Datamodelling
DatamodellingDatamodelling
Datamodelling
 
MDMF DPGI Presentation
MDMF DPGI PresentationMDMF DPGI Presentation
MDMF DPGI Presentation
 
Select an e forms vendor
Select an e forms vendorSelect an e forms vendor
Select an e forms vendor
 
Edifact
EdifactEdifact
Edifact
 
Edi,idoc,ale
Edi,idoc,aleEdi,idoc,ale
Edi,idoc,ale
 
Ale Idoc Edi
Ale Idoc EdiAle Idoc Edi
Ale Idoc Edi
 

Similar to Chap10

Similar to Chap10 (20)

Data dictionary
Data dictionaryData dictionary
Data dictionary
 
Final
FinalFinal
Final
 
New
NewNew
New
 
Chap02
Chap02Chap02
Chap02
 
Data quality and bi
Data quality and biData quality and bi
Data quality and bi
 
Into dq ed wrazen
Into dq ed wrazenInto dq ed wrazen
Into dq ed wrazen
 
Data Quality Technical Architecture
Data Quality Technical ArchitectureData Quality Technical Architecture
Data Quality Technical Architecture
 
Chapter 1
Chapter 1Chapter 1
Chapter 1
 
Chap01
Chap01Chap01
Chap01
 
Metadata Melodies Webinar with David Loshin Presentation
Metadata Melodies Webinar with David Loshin PresentationMetadata Melodies Webinar with David Loshin Presentation
Metadata Melodies Webinar with David Loshin Presentation
 
06. Transformation Logic Template (Source to Target)
06. Transformation Logic Template (Source to Target)06. Transformation Logic Template (Source to Target)
06. Transformation Logic Template (Source to Target)
 
Oil and gas big data edition
Oil and gas  big data editionOil and gas  big data edition
Oil and gas big data edition
 
03. Business Information Requirements Template
03. Business Information Requirements Template03. Business Information Requirements Template
03. Business Information Requirements Template
 
Intro_toDB.ppt
Intro_toDB.pptIntro_toDB.ppt
Intro_toDB.ppt
 
Chapter 12
Chapter 12Chapter 12
Chapter 12
 
DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)
 
Data Warehousing
Data WarehousingData Warehousing
Data Warehousing
 
Reactive Data Centric Architectures with DDS
Reactive Data Centric Architectures with DDSReactive Data Centric Architectures with DDS
Reactive Data Centric Architectures with DDS
 
Suman saha data architect
Suman saha data architectSuman saha data architect
Suman saha data architect
 
SURENDRANATH GANDLA4
SURENDRANATH GANDLA4SURENDRANATH GANDLA4
SURENDRANATH GANDLA4
 

Chap10

  • 1. Chapter 10 Analyzing Systems Using Data Dictionaries Systems Analysis and Design Kendall and Kendall Fifth Edition
  • 2. Major Topics  Data dictionary concepts  Defining data flow  Defining data structures  Defining elements  Defining data stores  Using the data dictionary  Data dictionary analysis Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-2
  • 3. Data Dictionary  Data dictionary is a main method 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-3
  • 4. Reasons for Using a Data Dictionary  The data dictionary may be used for the following reasons:  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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-4
  • 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-5
  • 6. Data Dictionary Contents  Data dictionaries contain  Data flow  Data structures  Elements  Data stores Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-6
  • 7. Defining Data Flow  Each data flow should be defined with descriptive information and it's 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-7
  • 8. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-8
  • 9. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-9
  • 10. Data Flow Example Name Customer Order Description Contains customer order information and is used 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 Kendall & Kendall to update the customer master and item files and to produce an order record. customer order. The order may be received by mail, fax, or by telephone. Copyright © 2002 by Prentice Hall, Inc. 10-10
  • 11. Defining Data Structures  Data structures are a group of smaller structures and elements  An algebraic notation is used to represent the data structure Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-11
  • 12. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-12
  • 13. Repeating Groups  A repeating group may be  A sub-form  A screen or form table  A program table, matrix, or array  There may be one repeating element or several within the group Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-13
  • 14. Repeating Groups  The repeating group may have  Conditions  A fixed number of repetitions  Upper and lower limits for the number of repetitions Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-14
  • 15. Physical and Logical Data Structures  Data structures may be either logical or physical  Logical data structures indicate the composition of the data familiar to the user Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-15
  • 16. Physical Data Structures  Include elements and information necessary to implement the system  Additional physical elements include  Key fields used to locate records  Codes to indicate record status  Codes to identify records when multiple record types exist on a single file  A count of repeating group entries Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-16
  • 17. Data Structure Example Customer Order = Customer Number + Kendall & Kendall 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) Copyright © 2002 by Prentice Hall, Inc. 10-17
  • 18. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-18
  • 19. General Structural Records  Structural records and elements that are used within many different systems should be given a non-system-specific name, such as street, city, and zip  The names do not reflect a functional area  This allows the analyst to define them once and use in many different applications Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-19
  • 20. Structural Record Example Kendall & Kendall Customer Name = First Name + (Middle Initial) + Last Name Address = Street + (Apartment) + City + State + Zip + (Zip Expansion) + (Country) Telephone = Area code + Copyright © Local 2002 number by Prentice Hall, Inc. 10-20
  • 21. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-21
  • 22. Defining Elements  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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-22
  • 23. Defining Elements  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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-23
  • 24. Defining Elements  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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-24
  • 25. Defining Elements  The length of an element  This should be the stored length of the item  The length used on a screen or printed lengths may differ Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-25
  • 26. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-26
  • 27. Determining Element Length  Numeric amount lengths should be determined by figuring the largest number the amount will contain and then allowing room for expansion  Totals should be large enough to accommodate the numbers accumulated into them  It is often useful to sample historical data to determine a suitable length Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-27
  • 28. Determining Element Length Element Length fit within the length Last Name 11 98% First Name 18 95% Company Name 20 95% Street 18 90% City 17 99% Kendall & Kendall Percent of data that will Copyright © 2002 by Prentice Hall, Inc. 10-28
  • 29. Data Truncation  If the element is too small, the data will be truncated  The analyst must decide how this will affect the system outputs  If a last name is truncated, mail would usually still be delivered  A truncated email address or Web address is not usable Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-29
  • 30. Data Format  The type of data, either numeric, date, alphabetic or alphanumeric or other microcomputer formats  Storage type for numeric data  Mainframe: packed, binary, display  Microcomputer (PC) formats  PC formats depend on how the data will be used, such as Currency, Number, or Scientific Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-30
  • 31. Personal Computer Formats Bit - A value of 1 or 0, a true/false value Char, varchar, text - Any alphanumeric character Datetime, smalldatetime - Alphanumeric data, several formats Decimal, numeric - Numeric data that is accurate to the least significant digit Float, real - Floating point values that contain an approximate decimal value Int, smallint, tinyint - Only integer (whole digit) data Money, smallmoney - Monetary numbers accurate to four decimal places Binary, varbinary, image - Binary strings (sound, picture, video) Cursor, timestamp, uniqueidentifier - A value that is always unique Kendall & Kendall Can contain a whole and decimal portion within a database Copyright © 2002 by Prentice Hall, Inc. 10-31
  • 32. Defining Elements - Format  Input and output formats should be included, using coding symbols:  Z - Zero suppress  9 - Number  X - Character  X(8) - 8 characters  . , - Comma, decimal point, hyphen  These may translate into masks used to define database fields Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-32
  • 33. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-33
  • 34. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-34
  • 35. Defining Elements  An additional comment or remarks area  This might be used to indicate the format of the date, special validation that is required, the check-digit method used, and so on Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-35
  • 36. Data Element Example Name Customer Number Alias Client Number Alias Receivable Account Number Description Uniquely identifies a customer that has made any business 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 Discrete Value/Meaning Comments The customer number must pass a modulus-11 check-digit test. Kendall & Kendall transaction within the last five years. Copyright © 2002 by Prentice Hall, Inc. 10-36
  • 37. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-37
  • 38. Defining Data Stores  Data flow base elements are grouped together and a data store is created for each unique group  Since a data flow may only show part of the collective data, called the user view, you may have to examine many different data flow structures to arrive at a complete data store description Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-38
  • 39. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-39
  • 40. Data Store Definition  If the file is computerized, the file format designates whether the file is a database file or the format of a traditional flat file  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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-40
  • 41. Data Store Definition  The data set name specifies the table or file name, if known  In the initial design stages, this may be left blank  The data structure should use a name found in the data dictionary Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-41
  • 42. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-42
  • 43. Data Store Example - Part 1 ID D1 Name Customer Master File Alias Client Master File 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% Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-43
  • 44. Data Store Example - Part 2 Data Set/Table Name Customer Copy Member Custmast 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. Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-44
  • 45. Data Dictionary and Data Flow Diagram Levels  Data dictionary entries vary according to the level of the corresponding data flow diagram  Data dictionaries are created in a top-down  Data dictionary entries may be used to validate parent and child data flow diagram level balancing Kendall & Kendall manner Copyright © 2002 by Prentice Hall, Inc. 10-45
  • 46. Data Dictionary and Data Flow Diagram Levels  Whole structures, such as the whole report or screen, are used on the top level of the data flow diagram  Either the context level or diagram zero  Data structures are used on intermediate-level data flow diagram  Elements are used on lower-level data flow diagrams Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-46
  • 47. Creating Data Dictionaries  1. Information from interviews and JAD sessions is summarized on Input and Output Analysis Forms  This provides a means of summarizing system data and how it is used  2. Each structure or group of elements is analyzed Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-47
  • 48. Creating Data Dictionaries  3. Each element should be analyzed by asking the following questions:  A. Are there many of the field?  If the answer is yes, indicate that the field is a repeating field using the { } symbols  B. Is the element mutually exclusive of another element?  If the answer is yes, surround the two fields with the [ | ] symbols Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-48
  • 49. Creating Data Dictionaries  C. Is the field an optional entry or optionally printed or displayed?  If so, surround the field with parenthesis ( )  4. All data entered into the system must be stored  Create one file or database file for each different type of data that must be stored  Add a key field that is unique to each file Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-49
  • 50. Determining Data Store Contents  Data stores may be determined by analyzing data flows  Each data store should consist of elements on the data flows that are logically related, meaning they describe the same entity Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-50
  • 51. Maintaining the Data Dictionary  To have maximum power, the data dictionary should be tied into other programs in the system  When an item is updated or deleted from the data dictionary it is automatically updated or deleted from the database Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-51
  • 52. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-52
  • 53. Creating Reports, Screens, Forms  To create screens, reports, and forms  Use the element definitions to create fields  Arrange the fields in an aesthetically pleasing screen, form, or report, using design guidelines and common sense  Repeating groups become columns  Structural records are grouped together on the screen, report, or form Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-53
  • 54. Data Dictionary Analysis  The data dictionary may be used in conjunction with the data flow diagram to analyze the design, detecting flaws and areas that need clarification Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-54
  • 55. Data Dictionary Analysis  Some considerations for analysis are  All base elements on an output data flow must be present on an input data flow to the process producing the output  Base elements are keyed and should never be created by a process Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-55
  • 56. Data Dictionary Analysis  A derived element should be output from at least one process that it is not input into  The elements that are present on a data flow into or coming from a data store must be contained within the data store Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 10-56