2. Logical Data Dictionary
• Data Dictionary
• Is a mean of recording metadata of a system
• The Logical Data Model is to record and
analyze data requirements independently of
how these requirements are going to be met
• The Physical Data Model is to record design
decisions in terms of its implementation.
Hence Data Dictionary
• Is a mechanism for recording the data require-
ments and data resources of an organization.
• Is a tool for Analysis and Design phases of SD
3. Data Dictionary (DD)
– Data Dictionary
– Is simply a record of data about data, or metadata
– Can be compiled manually or by a fully automated
package
– Links different techniques and components of system
together
– Is not a static mechanism, but the information stored in
will improve/increase and will be updated with time
– Provides a logical bridge between Analysis & Design
– Serves as back-bone for CASE tools
In Structured System Analysis and Design, DD holds data
about 3 of the 4 components of DFDs i.e. Data Stores,
Processes and Data Flows. Further, the Data
Elements and Data Structures need be defined to
elaborate composition of Data Flows and Data Stores
4. Templates - DD Components
– Data Element:
Name: A meaningful unique name
Description: Short description of meaning of DE
Aliases: Several dept may refer same DE by different
names or terms
Type: Character, Numeric or Alphanumeric
Format: Used to prepare format checks in subsequent
system design
Values: To embody different codes to represent different
categories
Security: Who can modify, add or delete the given DE
Editing: How +ve or –ve numbers be differentiated
Comments: To record some special information about the
DE
5. Templates – DD Components.
– Data Structure
A Data Structure is made up of data elements and other
data structures. Thus Data Dictionary should contain its
complete info, explicitly mentioning which elements are
Optional, Repeated or mutually exclusive.
Optional Structure: Placed in square brackets eg [PREV-
SURNAME]
Alternate Structure: Place in braces eg {FATHER-NAME,
HUSBAND-NAME}
Iterations of Structure: Marked with an asterisk eg
COURSE-REGISTERED * (1-5) with number of iterations
placed, if known, in parentheses, here applicant can
register in 1,2,3..5 courses
Volume Information: Collected at the end of the form and
used for resource estimation
6. Backus Naur Form
A Notation primarily used to define the syntax of programming languages, can also be used to
define Data Elements and Data Structures
= Left of the sign consists of whatever is on right
+ Equivalent to ‘and’
{…;…;…} Only one of the item is to be chosen – Selection
[ … ] Optional i.e. zero or one occurrence
(…) Item contains from zero to an infinite number of
occurrences of whatever inside braces – Iteration
*…* Comment i.e. it does not constitute the part of def
Some examples of terms of Data Dictionary
AGREED-PURCHASE-PRICE = *Price provisionally agreed between the purchaser and vendor *
CENTRAL-HEATING = CENTRAL-HEATING-TYPE + CENTRAL-HEATING-DEGREE
CENTRAL-HEATING-TYPE = {GAS ; ELECTRIC ; SOLID-FUEL }
CENTRAL-HEATING-DEGREE = { MAJOR ; AVERAGE ; MINOR }
14. Templates – DD Comps ..
– Data Store
– Contents of Data Store can be written more clearly and
with less chance of error. Further, interrelationships of
parts of systems are also represented by the
occurrences of the structures. All data flows coming-in
and going-out are recorded
– Data Flow
– Its Source, Sink and composition be recorded.
– Process
– Along with inputs and outputs to the process, its logic or
working can also be recorded into the template
15.
16.
17.
18.
19.
20. Data Dictionary (DD)
– Data Dictionary
– Is simply a record of data about data
– Can be compiled manually or by a fully automated
package
– Links different techniques and components of system
together
– Is not a static mechanism, but the information stored in
will improve/increase and will be updated with time
– Provides a logical bridge between Analysis & Design
– Serves as back-bone for CASE tools
In Structured System Analysis and Design, DD holds data
about 3 of the 4 components of DFDs i.e. Stores,
Processes and Data Flows. Further, the data Elements
and Data Structures need be defined to elaborate
composition of Data Flows and Data Stores
21. References
• Tom DeMarco (1978); Structured Analysis and System
Specifications
• Chris Gane and Trish Sarson (1979) Structured Analysis
: Tools and Techniques
• Paul Beynon-Davies (1989); Information Systems
Development, Macmilon, London, UK
• Steve Skidmore and Brenda Wroe (192); Introducing
System Analysis, NCC Publications, BPB Plublications,
India
• Wayne P Stevens (1991); Software Design: Concepts
and Methods, Printice Hall, London, UK
27. Guidelines for Constructing DFDs
– Read the Problem Specification or listen carefully to the
verbal specification of Problem
– Analyze and identify the Externals
– List down the Activities and Sub-activities, preferably in
indented format, depicting hierarchy
– In reply to question ‘How you managed to publish so
much?’ Prof C A Hoar told:
‘I take a ream of white paper, handful of sharpened lead
pencils, a thick good quality eraser, sit at a lonely place
and start writing’
[Prof C A Hoar]‘
– Follow Prof Hoar’s advice
28. – On a A4 sheet draw Externals at the
periphery, mark the Data Flows originating
from or destined to these Externals, and
then draw a Process in the Middle of the
page, with a name most appropriate for the
system.
– Link Externals to this central Process by
extending Data Flows. Name the Data
Flows
– This is the 0-Level or Context Diagram
Be Reminded - first few DFDs would be (probably) wrong, so
Be patient and persistent. Failures are to learn and key to
SUCCESS
29. – To Identify Externals, read problem specs, mark or
underline Nouns; these can be Externals, data
flows or Data Stores, so look into the context how
these are used, if these are acting as sources or
destinations for data, then these are Externals
– Mark Verbs representing actions these indicate
activities or sub-activities, you have to decide their
correlation-ship, i.e. which is sub-activity of which
activity
– To draw, 1st level or Overview Diagram, take an
A4 sheet, draw a dashed line boundary, a larger
rectangle and transfer all data flows from the
Context Diagram to this
– Now look for each of the activities and associate a
Process to it, and so draw Processes for them.
30. – Concentrate on each of the processes, and
workout the possible data flows coming-in and
going-out of these Processes, to demonstrate the
requisite functionality
– Introduce any of the Data Stores, if needed, and
Data Flows thru these Data Stores is preferred, it
helps in de-linking the Processes later
– Now extend the inherited Data Flows, to the
respective Processes, instead of their termination
or origination from Boundary
– Label or name and number all Processes, Data
Flows and Data Stores as per Guidelines
– Explode the Processes, where needed i.e. the
ones having more functionality and activity
31. Courses Registration at KICSIT
Read the Case Study and draw logical
Data Flow Diagrams, up to three levels,
i.e
Context or 0-Level,
1st Level or Overview Diagram and
2nd Level diagrams for the
processes having sufficient
functionality
32. Courses Registration @ KICSIT
Home Assignment
– I hope every body tried to
• Understand the Problem and
• make the Data Flow Diagrams up to 2nd or 3rd
level
– Results of an attempt to make these DFDs
are presented:
• These are correct, but still open for
discussion and correction, if any.
37. The DFDs are to be revised and updated accordingly, and top-
down and bottom-up iterations among different levels of DFDs
are to be carried out to ensure consistency and balancing.