Lecture – 12 Data Modeling – ER Diagrams, Mapping -Transcript

Introduction

We’ll continue our discussion on process modeling. In the previous lecture, we talked about functional decomposition as a first step in process modeling. Given the complex process, we should try to decompose it into sub-processes or smaller processes which can be better understood in terms of what actions they do.

Data Flow Diagrams

We’ll now continue with the process modeling and look at another important tool called Data Flow Diagrams. Data Flow Diagrams are a very popular tool for describing functions which are required in a given system. And these functions are specified in terms of processors as well as the data used by these processes. So this is one important difference from function decomposition diagram where we do not show data explicitly whereas in the case of Data Flow Diagrams both the processes and the data which will flow among those processes would be shown. That’s why they are called Data Flow Diagrams.

We may do function decomposition diagrams before doing data flow diagram. However we may also do data flow diagrams directly but it is better to think about function decomposition beforehand and it would be a good practice to do function decomposition before, because this function decomposition would be anyway required when we do data flow diagrams. So having done it earlier before coming to data flow diagrams would always be more fruitful. Data flow diagrams have more content than function decomposition diagrams obviously because now we will be explicitly showing the flow of data.

Data flow diagrams are very simple pictorial tools. They represent the functional and the data flow in the form of a diagram. And therefore they are very easy to understand by all people, users as well as managements. So they have become very popular in the analysis phase for representing the functions performed by a particular application.

Data flow diagrams are also unambiguous and concise. They can describe processing both at the physical level as well as at the logical level. Remember that at physical level we describe the way things are done rather than what needs to be done. So we can have both data flow diagrams. In fact, usually when you’re studying the existing system, you are studying it at the physical level. Therefore if you represent these in the form of a data flow diagram, the diagram will be at the physical level representing both what is done and how it is done currently.

After doing this, you will move towards preparation of a logical level data flow diagram where we emphasize what needs to be done and not necessarily how it should be done because the how part is really the part to be addressed during the design phase.

DFDs facilitate top down development. In fact, that is the strength of the tool so that you can introduce more and more details as you do step-by-step decomposition of these diagrams. They permit outlining of preferences and scope. So when you are discussing different alternatives with the users or the management, you can clearly mark those alternatives on the data flow diagram itself so that the people can understand the scope of the application software that we are proposing. So it’s another use for data flow diagrams.

DFD Notations

Here is the notation that we use in diagramming the data flows. In the diagram, you show data flow through an arrow. Usually the arrow will be labeled with the kind of data which flows on that. Then we show the sources of data or the sources which use this information. These are generally the external entities and these entities are shown using either a rectangle like this, or it may be a double-edged rectangle. I am giving here two different representations and both are used in the industry. You can choose one of them. The one on the left is simpler to draw when we are doing the data flow diagrams by hand. So we will probably prefer this. But whereas when you use tools for doing data flow diagrams any one of them could be used by us. So sources and sinks of data and information typically are the users of this system. And these would be shown as external entities.

Then processes are either shown as a circle which is also called a bubble, or a rectangle with the rounded corners, and we label them with some number for easy reference. So process is shown. And then finally we also show data either through a pair of lines or by a small box which represents a collection of data. And that box may also be labeled with a number for ease of referencing.