Data flow diagram
Disclaimer: This work has been submitted by a student. This is not an example of the work written by our professional academic writers. You can view samples of our professional work here.
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
Published: Mon, 5 Dec 2016
Data Flow Diagram
DFD is a system modeling tool, the most popular and important representations in data flow modeling. DFD allows us to picture a system as a network of functional processes, connected to one another by “pipelines” and “holding tanks” of data. It is a structured, diagrammatic technique representing external entities, logical storage, data sinks and data flows in the system. You can also call DFD as: bubble chart, bubble diagram, process model, and work flow diagram.
Data Flow Diagram Types
- Physical Data Flow Diagram: Physical data flow diagrams are implementation-dependent and show the actual devices, department, people, etc., involved in the current system.
- Logical or Conceptual Data Flow Diagram: Logical data flow diagram represents business functions or processes. It describes the system independently of how it is actually implemented, and focuses rather on how an activity is accomplished.
The components of the data flow diagram (DFD)
- Processes: The basic processing items of a data flow diagram. They are used to transform incoming data flows into outgoing data flows. Processes that are not further decomposed have to be described by means of a textual specification. This text defines how the input data of the process are transformed into output data.
- Terminators: Data producers (data sources) or data consumers (data “sinks”) outside of the system
- Data flows: Logical channels (“pipelines”) in which data are transported; they are represented by arrows connecting the processes;
- Data store: Storage space from which data can be read with a time delay after writing them; without processing component.
Data flow diagrams are useful if:
- you have lots of calculations to carry out
- You are familiar with data flow techniques in a method you have used repeatedly before.
The approach to data flow diagramming should be as follows:
- create a data flow diagram for each of the major outputs of the system
- work back from the outputs to the inputs to construct the diagram
- add new objects where necessary to the object model as you discover the need for them in the data flow modeling
- add new operations and attributes to the object model as you discover the need for them in the data flow modelling
Data Flow Description
The data flow symbol is a line with an arrow showing the direction of flow. It should be named using words that are understood within the department or organization describing the data. The data that leaves one process is exactly that which arrives at the next process. An arrow usually at the end of the flow line indicates direction of flow.
External Entity Definition
The external entity is a source or recipient of data that is outside the boundary of investigation. The fundamental purpose of this symbol is to indicate that whatever happens at the end of the data flow,
Entity Relationship Diagram
A logical data model is documented as an entity relationship model supported by the data items for each entity (conventionally in the form of a Third Normal Form relation).Though the relationship among data store is not emphasized in data flow diagram, it is well reflected in ERD. ERD is one of the most useful model forming tools to organize this discussion. ERD is network model that describes stored data of a system at a high level of abstraction. For system analyst, ERD has a major benefit: it highlights the relationship between data stores on DFD which would otherwise only be seen in the specification process.
The main components of an ERD include:
- Entity- a subject, a duty, or an event that has a significant meaning to the future system
- Attribute – the characteristics of the entity displayed by fields or columns of a table.
- Relationship- There is 3 major types of relationship used in ERDs:
- One – one relationship
- One – many relationship
- Many – many relationship
Entity- is any type of object that we wish to store data about. Which entity types you decide to include on your diagram depends on your application. In an accounting application for a business you would store data about customers, suppliers, products, invoices and payments and if the business manufactured the products, you would need to store data about materials and production steps. Each of these would be classified as an entity type because you would want to store data about each one. In an entity-relationship diagram an entity type is shown as a box. There may be many entity types in an entity-relationship diagram. The name of an entity type is singular since it represents a type.
Attributes-The data that we want to keep about each entity within an entity type is contained in attributes. An attribute is some quality about the entities that we are interested in and want to hold on the database. In fact we store the value of the attributes on the database. Each entity within the entity type will have the same set of attributes, but in general different attribute values. For example the value of the attribute ADDRESS for a customer J. Smith in a CUSTOMER entity type might be ’10 Downing St., London’ whereas the value of the attribute ‘address’ for another customer J. Major might be ’22 Railway Cuttings, Cheam’.
Cardinality and Optionality
The maximum degree is called cardinality and the minimum degree is called Optionality. In another context the terms ‘degree’ and ‘cardinality’ have different meanings. In [Date 4th ed. p240] ‘degree’ is the term used to denote the number of attributes in a relation while `cardinality’ is the number of tipples in a relation. Here, we are not talking about relations (database tables) but relationship types, the associations between database tables and the real world entity types they model.
This entity is to store the personal Name, Address etc in to check in the Hostel.
This entity is to store the detail of stock items in order to check new item.
This entity is to store the Customer information that was get to the Room.
This entity is to store the Room that have been booking according to customer’s order.
This entity is to store the Room information of the Hostel status.
Sale & Service
This entity is to store the sale record of each customer and the item.
Entity Life History
The ELH technique is based on concepts developed by Michael Jackson for structured program design. The essential idea is that all data processing can be described in terms of sequence (order), selection (choice) and iteration (repetition) of processing components, which are derived from the data structures. In an ELH these ideas are used by analogy to model sequences, selections and iterations of events affecting an entity.
In between the ‘birth’ and ‘death’ events there may be a number of ‘life’ events. Jackson rules are observed in that the diagram shows that it is possible for there to be no changes between creation and end of life for a particular instance, as an iteration may occur zero, one or many times.
Parallel lives are used when there are two (or more) independent sets of events that can affect an entity. As events from the two sets are not dependent on each other, but only on events from their own set, they cannot be ordered together in a predictable way.
Quits and resumes are a means of jumping from one part of the diagram to another in order to cope with exceptional or unusual events. If used indiscriminately they can undermine the apparent structure of the diagram and make it more difficult to understand. Analysts should therefore use a quit and resume only when they are sure that there is no sensible way in which they can use normal Jackson structures to show what they want.
Any collection of attributes can be said to be either unnormalised or in a particular normal form depending on its compliance with the rules given below. Many normal forms have been defined. Codd originally defined first, second and third normal forms. There are some cases, particularly where keys are complex and contain many attributes, where further normalization may be required. For such cases, Boyce- Codd normal form, fourth normal form and fifth normal form also exist. In this book, normalization will only be covered up to the third normal form, since this is sufficient for most practical purposes. For further information about the other normal forms the reader is referred to Data (2000).
Report for National Hostelling Association
There are a lot of advantages when compared to the manual system and computer based system. Although our system is still window based.We will be able to room service, Ecommerce application in the future. We have made the information giving in our system easily understandable for new uses of the system.
The display area of the store is not very large. It will only display a small section of the Room & Other Sale Item that the Check in the Hostel room. My system will allow customers to choice rooms . This will allow customers to request room and service that are not on display. The customer can search the room by keyword or by category such as room,Booking No, CheckIn/Out etc or by charges. The charges will take the discount value for each invoice ie, the For manager, he will help with this activities during busy periods and will be responsible for the general management duties such as accounting, correspondence, staffing etc. The manager will also Booking and necessary from a number of customers and he will also decide which of the services will be discount prices to the customer. In order to do this, he will need the information from the system. The system also produce the monthly report in order to estimate the rooms status and the customer like and dislike of the services ie the customer trend according to the season.
These above information are explained about the functions of the National Hostelling Association.
To have a successful system design for the National Hostelling Association, I have to study the manual system first. Then I draw the context diagram. The context diagram shows the entire system as a single process surrounded by the external entities. The National Hostelling Association, Context diagram represents data input and output flows. This make to concentrate or focus on the boundary to be investigated. This can give great help in discussing with the user on the scope of the system.
Aims and objectives are given to the system so the system user cannot depart from the system needs. As the context diagram is drawn, the level 1 DFD are also easily drawn to make the system easy to look and to be understandable. This can enhance the clarity of the system to the user.
Then I create a data model to support the system information. It points the ways how the data items are grouped together into entities and identifies the relationships between the entities. To get the attributes for the entities, I studied the manual records and the receipts of the National Hostelling Association. Additional characteristics such as the optionality and degrees of relationship are needed to identify for the entities.
Then I studied how the entities change with time.ELH is described to know the creation of an entity occurrences, record the sequence of changes in the system during its life time and how it ends in the system.
Then I do the normalization which provides the sound foundation for physical design which can be implemented as the database design. For database design, all entities are included in the data dictionary which is the sources of information of the system.
Then, I create the prototype by using Visual Studio 2005. It includes searching for an item of National Hostelling Association. I also take the screenshots of the prototype and identify where the system needs the validation rule.
All the tasks shown above demonstrate an understanding of the modeling and installation of the data driven system. They demonstrate the analysis and design of a system including the prototype use interface, training plans for the users.
Preparation for the installation of the system
In order to install the system, we first need to install the hardware first. Then we need to do the data entry for the items. We also need to install the software required to run the system.
The requirements are as follows:
- Pentium IV or above
- Processors is C.P.U. 1.8 GHz or above.
- Memory (RAM) is 512MB or above.
- Hard Disk space is 1GB for my system and 10 GB for Operation System.
- Window XP
- Visual Studio 2005
- Microsoft Office Word 2003 for reading Manual Guide
Cite This Work
To export a reference to this article please select a referencing stye below: