A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process

aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated.

What is the main merit of DFD? The main merit of DFD is that it provides an overview of what data flows in a system, what transformations are done on the data, what files are used and where results flow. 1. DFDs are easier to understand by technical and nontechnical audiences 2. DFDs can provide a high level system overview, complete with boundaries and connections to other systems 3. DFDs can provide a detailed representation of system components What is the role of DFD as a documentation aid? It is a good documentation aid which is understood by both programmers and non-programmers (i.e., laypersons). As DFD specifies only what processes areperformed and not how they are performed it is easily understood by a nonprogramming user.

Processes

Processes are work or actions performed on incoming data flows to produce outgoing data flows. These show data transformation or change. Data coming into a process must be "worked on" or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always "running" and ready to accept data. Major functions of processes are computations and making decisions. Each process may have dramatically different timing: yearly, weekly, daily. Naming Processes Processes are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word "process". Each process should represent one function or action. If there is an "and" in the name, you likely have more than one function (and process). For example, get invoice ,update customer and create Order Processes are numbered within the diagram as convenient. Levels of detail are shown by decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6. Processes should generally move from top to bottom and left to right. Data Flow Data flow represents the input (or output) of data to (or from) a process ("data in motion"). Data flows only data, not control. Represent the minimum essential data the process needs. Using only the minimum essential data reduces the dependence between processes. Data flows must begin and/or end at a process. Data flows are always named. Name is not to include the word "data". Should be given unique names. Names should be some identifying noun. For example, order, payment, complaint. Data Stores or

Data Stores are repository for data that are temporarily or permanently recorded within the system. It is an "inventory" of data. These are common link between data and process models. Only processes may connect with data stores. There can be two or more systems that share a data store. This can occur in the case of one system updating the data store, while the other system only accesses the data. Data stores are named with an appropriate name, not to include the word "file", Names should consist of plural nouns describing the collection of data. Like customers, orders, and products. These may be duplicated. These are detailed in the data dictionary or with data description diagrams. What do you understand by levelling of DFD?

A context diagram is expanded into a number of inter-related processes. Each process may be further expanded into a set of inter-connected sub processes. This procedure of expanding a DFD is known as levelling.

Types of DFDs Context Diagram

A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system

Level 0 Diagram
A data flow diagram (DFD) that represents a systems major processes, data flows and data stores at a high level of detail

Level n Diagram
Further Refinement Context Diagram One process, numbered 0. Sources and sinks (external entities) as squares Main data flows depicted No internal data stores are shown They are inside the system External data stores are shown as external entities Level-1 Diagram describes the overall processing of the system show one process for each major processing step or functional requirement data flows from the context appear on system diagram also (level balancing) can show a single data store to represent all data in aggregate at this level And so on..

A data dictionary, or metadata repository, as defined in the IBM Dictionary of Computing, is a "centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format."[1] The term may have one of several closely related meanings pertaining to databases and database management systems (DBMS): a document describing a database or collection of databases an integral component of a DBMS that is required to determine its structure a piece of middleware that extends or supplants the native data dictionary of a DBMS

A data dictionary is in fact a database implementation as well as they contain data information about data. It is typically structured in tables and views just like other data in a database. Most data dictionaries are central to a database and are very important tool for kinds of users from the data consumers to application designers to database developers and administrators. A data dictionary is used when finding information about users, objects, schema and storage structures. Every time a data definition language (DDL) statement is issued, the data dictionary becomes modified. Benefits of a DDS are mainly due to the fact that it is a central store of information about the database. Benefits include improved documentation and control consistency in data use easier data analysis reduced data redundancy simpler programming the enforcement of standards better means of estimating the effect of change. A DDS provides two sets of facilities: To record and analyse data requirements independently of how they are going to be met - conceptual data models (entities, attributes, relationships). To record and design decisions in terms of database or file structures implemented and the programs which access them internal schema.