video rental ltd case study

• Demo Videos
• Interactive Product Tours
• Request Demo

Data Flow Diagram with Examples - Video Rental System Example

Data Flow Diagram (DFD) provides a visual representation of the flow of information (i.e. data) within a system. By drawing a Data Flow Diagram, you can tell the information provided by and delivered to someone who takes part in system processes, the information needed in order to complete the processes and the information needed to be stored and accessed. Data Flow Diagram has a wide use in software engineering. This article describes and explain Data Flow Diagram (DFD) by using a video rental system as an example.

Compatible edition(s): Enterprise , Professional , Standard , Modeler

• February 16, 2015
• Views: 134,204

The Video Rental System Example

Context dfd.

The figure below shows a context Data Flow Diagram that is drawn for a video rental system. It contains a process (shape) that represents the system to model, in this case, the " Video Rental Store ". It also shows the participants who will interact with the system, called the external entities. In this example, there are two external entities, namely Customer and Manager . In between the process and the external entities, there are data flow connectors indicating the existence of information exchange between customer and the system.

Context DFD is the entrance of a data flow model. It contains one and only one process and does not show any data store, which makes the diagram simple.

Level 1 DFD

The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the video rental system that is shown in the context DFD. Read through the diagram and then we will introduce some of the key concepts based on this diagram.

The Video Rental System Data Flow Diagram example contains three processes, two external entities and two data stores. Although there is no design guideline that governs the positioning of shapes in a Data Flow Diagram, we tend to put the processes in the middle and data stores and external entities on the sides to make it easier to comprehend.

Based on the diagram, we know that a Customer makes a Video request to the Rent Video process. The Rent Video process also receives Video info. from the Video Library data store. As a result, the process produces a Bill to the Customer , and stores the Rental info. into the Rental data store.

A Customer can Return Video by providing Video & Rental info . The process stores the Video info. into the Video Library data store and Rental info. into the Rental data store. As a result, Return receipt is delivered to the Customer . Although we said that the receipt is delivered as a result of the Return Video process, the Data Flow Diagram implies no such thing. It is our common sense that lead us to interpret the diagram in the way that we understand it naturally. Strictly speaking, the diagram only tells us the Return Video process receives Video & Rental info. and produces Video info. , Rental info. , and Return receipt , with no order specified. Note that Data Flow Diagram does not answer in what way and in what order the information is being used throughout a system. If this information is important and worth mentioning, consider to model it with diagrams like BPMN Business Process Diagram or UML Activity Diagram .

Finally, a Manager can receive Rental report from the Generate Rental Report process and the information involved is provided by the Rental data store.

Data Flow Diagram Tips and Cautions

Be aware of the level of details.

In this Data Flow Diagram example, the word "info" is used many times when labeling data. We have "rental info" and "video info". What if we write them explicitly as "rental date, video rented, person rent", "video id, video name and video status"? Is this correct? Well, there is no definite answer to this question but try to ask yourself a question when making a decision. Why are you drawing a DFD?

In most cases, Data Flow Diagram is drawn in the early phase of system development, where many details are yet to be confirmed. The use of general terminologies like "details", "information", "credential" certainly leave room for discussion. However, using general terms can be kind of lacking details and make the design lost it usefulness. So it really depends on the purpose of your design.

Don't mix up data flow and process flow

Some designers may feel uncomfortable when seeing a connector connecting from a data store to a process, without seeing the step of data request being shown on the diagram somehow. Some of them will try to represent a request by adding a connector between a process and a data store, labeling it "a request" or "request for something", which is wrong.

Keep in mind that Data Flow Diagram was designed for representing the exchange of information. Connectors in a Data Flow Diagram are for representing data, not for representing process flow, step or anything else. When we label a data flow that ends at a data store "a request", this literally means we are passing a request as data into a data store. Although this may be the case in implementation level as some of the DBMS do support the use of functions, which intake some values as parameters and return a result, in Data Flow Diagram, we tend to treat data store as a sole data holder that does not possess any processing capability. If you want to model the system flow or process flow, use UML Activity Diagram or BPMN Business Process Diagram instead. If you want to model the internal structure of data store, use Entity Relationship Diagram .

• Video-Rental-Store.vpp

Readers of this tutorial also read

• What is Data Flow Diagram (DFD)? How to Draw DFD?
• Data Flow Diagram: Examples - Food Ordering System
• How to Write Effective Use Cases?
• How to Develop As-Is and To-Be Business Process?
• How to Model Relational Database Design with ERD?
• Enterprise Architecture
• TOGAF ADM Software: How to Use?
• Drawing ArchiMate Diagram
• Design & Modeling
• Problem Desc. to Model
• Creating Activity Diagram
• Creating State Machine Diagram
• Creating Component Diagram
• Creating Deployment Diagram
• Cause and Effect Diagram
• Drawing Timing Diagram
• Class Diagram in Java, C# and VB
• Animating Activity Diagram
• Drawing Profile Diagram
• Attach file reference to model
• Using sub-diagrams
• UML Package Diagram
• Mult-party service in SoaML
• Drawing SoaML Diagram
• Stereotypes and tagged values
• Define custom element properties
• Merge actors in use case diagram
• Numbering sequence messages
• Using Textual Analysis
• Seq. Diagram duration constraint
• Fill-in UML state's body
• Edit attribute's initial value
• Drawing Sequence Diagram
• Test cases for SysML requirement
• Customize requirement types
• Drawing Communication Diagram
• Develop Sequence Diagram with keybaord
• Abstract Factory Pattern Tutorial
• Factory Method Pattern Tutorial
• Builder Pattern Tutorial
• Prototype Pattern Tutorial
• Singleton Pattern Tutorial
• Adapter Pattern Tutorial
• Proxy Pattern Tutorial
• Composite Pattern Tutorial
• Bridge Pattern Tutorial
• Decorator Pattern Tutorial
• Flyweight Pattern Tutorial
• Facade Pattern Tutorial
• Command Pattern Tutorial
• Chain of Responsibility Pattern Tutorial
• Interpreter Pattern Tutorial
• Iterator Pattern Tutorial
• Observer Pattern Tutorial
• Memento Pattern Tutorial
• Mediator Pattern Tutorial
• Template Pattern Tutorial
• Strategy Pattern Tutorial
• State Pattern Tutorial
• Visitor Pattern Tutorial
• Create BPMN diagram
• Business process modeling
• Business Process Mapping
• Creating BPMN diagram
• Using Data Object in BPMN
• BPD Example - Leave Application
• BPMN Intro I
• BPMN Intro II - Swimlanes
• BPMN Intro III - Flow/Connectors
• BPMN Intro IV - Data & Artifacts
• Develop As-is & To-be BPD
• Working procedures of BP tasks
• Link data object with ERD entity
• Animate BPMN business process
• BPMN process simulation
• Import Bizagi project
• Use stereotype in EPC Diagram
• Secondary pools for BPMN task
• Drill-down a BPMN sub-process
• Process simulation example
• Drawing BPMN Conversation Diagram
• BPMN 2.0 BPD
• Create Circuit Diagram
• Create Venn Diagram
• Create Floor Plan
• Create Network Diagram
• Flowchart Tutorial
• DFD Example - Customer Service
• DFD Example - Food Ordering
• DFD Example - Securities Trading
• DFD Example - Supermarket App
• DFD Example - Vehicle Main. Depot
• DFD Example - Video rental
• Functional decomposition in DFD
• Data Flow Diagram Tutorial
• Using Storyboard with User Story
• Wireframe for Android apps design
• Product Breakdown Structure
• Work Breakdown Structure
• Radar Chart tutorial
• Creating Fishbone Diagram
• Customer Journey Mapping (CJM)
• Create stereotyped model element
• Bookmark shapes
• Select shapes with Handi-Selection
• Diagram annotation with layer
• Diagram Info Shape
• Appearance of stereotyped shape
• Tidy-up diagram with Sweeper/Magnet
• Convert model element's type
• Import Visio drawing as stencil
• Create Mind Map
• What is Mind Mapping? How to Draw a Mind Map?
• Edit model elements with Excel
• Associat parent & subdiagram flow
• Listing elements with grid
• Ad-hoc idea capturing with Brainstorm Diagram
• Identify use cases from BP process
• Refactor classes to ref. project
• Create project reference
• Create nickname for multi-name set
• Animating Sequence Diagram
• Organize domaing and impl. model
• Align business goal & logic with Decision Table
• Decision Table in-action
• Discover business logic with Decision Table
• Sensible business with Decision Table
• Decision Table in EA
• Using Matrix Diagram
• Using Analysis Diagram
• SWOT Analysis Tutorial
• Five Forces Analysis Tutorial
• Agile Requirements
• Add classes to flow-of-events
• Advanced use case flow-of-events
• Test procedures in flow-of-events
• Produce use cases from BPD
• Agile Scrum Tutorial
• User Story - Confirmation items
• Mapping BPMN with User Stories
• Using Storyboard
• Using tag on user story
• Model business goals of a system
• Using UeXceler - YouTube example
• Writing effective use case
• Generate Seq. Diagram from user story
• Generate Activity Diagram from user story
• Code & DB
• Generate ERD from RedShift DB
• Generate RedShift DB from ERD
• Compare logical and physical ERD
• Design & generate SQL Server DB
• Generate ERD from DDL
• Generate DB spec. from DB
• Keep data dict. in-sync with ERD
• Database design with ERD
• Edit nullable column in ERD
• Insert sample data into ERD
• Model RDBMS with ERD
• Generate class diagram from ERD
• Oracle DB design tool
• Oracle DB design with ERD
• Mass edit DB design with Excel
• Oracle DB reverse engineering
• Generate DB change script
• Compare DB schemas visually
• Define custom implementations for ORM Class
• Hibernate ORM in Eclipse
• Using Hibernate Criteria
• Generate Hibernate mapping for Oracle DB
• Java round-trip engineering
• C++ round-trip engineering
• Generate code from State Machine
• REST API - Twitter example
• REST API - Simple Reg. example
• Form Seq. Diagram from Java
• Hibernate ORM in NetBeans
• Visual modeling in NetBeans
• UML modeling in Eclipse
• C# round-trip engineering
• Generate C# from UML in VS
• Generate Java from UML classes in NetBeans
• Keep code and UML model in-sync in Eclipse
• Task Management Guide
• Share & review process design
• Share & discuss BPD online
• Prioritize tasks in Tasifier
• Storing reference files in project
• View and Revert changes with Visual History
• Communicate process design with PostMania
• Communicate software design with PostMania
• Concurrent process modeling
• Create Use Case report
• Create software req. spec.
• Customize Doc. Composer templates
• Maintain project of glossary
• Maintain glossary for terms
• Build glossary from class model
• Extract glossary from BPMN process
• Extract glossary terms from shapes' name
• Track occurrence of glossary terms
• Derive use case from terms
• Derive data dict. from Textual Analysis
• Generate RACI from BPMN
• Customize RACI chart
• Develop Visual Paradigm plug-in
• Change application's font settings
• Hide-away toolbar buttons

Teaching with Visual Paradigm is a pleasure. It is easy-to-use, it is intuitive, and above all it does not get in the way of conveying the semantics of object oriented modeling.

Dr. Ajaz Rana

Temple University, Philadelphia

Turn every software project into a successful one.

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy .

© 2024 by Visual Paradigm. All rights reserved.

• Privacy statement

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

Chapter 3. Data Flow Diagrams

Related Papers

Nagasubramaniyan S

M Naveed Siddiqui

Sicnarf Ladublan

Lee Freeman

During the requirements analysis phase of information systems development, the user and analyst attempt to come to an agreement on the purpose of the system and the needs of the future users. When completed effectively, this process leads to the cre-ation of an information system that fulfills the intended purpose and meets the needs of users and their organization, on time and within budget [3]. This, of course, is dependent on the successful completion of the rest of the development process including the designing, coding, and testing of the system. Problems unsolved in the requirements elicitation phase may worsen during the remainder of the systems development project. As over 50 % of the errors in systems design and development are a result of inaccurate requirements, it is imperative this phase be completed accu-rately [6]. Often, information systems are designed and created that do not meet the needs of the users or fulfill their intended purpose [3, 6]. The deficiencies of t...

Journal of Intelligent Manufacturing

Ashutosh Tiwari

The Computer Journal

John Mingers

Pathum Fernando

Information Systems

Theo van der Weide

Andy Andy-eke

Arwa Aleryani

Most of information systems use nowadays were modeled and documented using structured approach. Expansion of these systems in terms of functionality and maintainability requires shift towards object-oriented documentation and design, which has been widely accepted by the business. In this paper, we compared between Data flow diagram and Use case diagram to find out the strengths and weakness over each of them. As a result, the author concluded that DFD still powerful tool through system analysis and design process, and can be included in object-oriented approach. Index Terms-System analysis and design, traditional approach, object-oriented approach, data flow diagram, use case diagram.

RELATED PAPERS

Revista médica de Chile

Sofia Salas

INPAFI (Inovasi Pembelajaran Fisika)

roslina sitorus

Comparative Political Studies

Ryan Finnigan

Heiko Hermeking

Política y Sociedad

Raquel Pastor Yuste

Études Internationales

Juan Carlos Orozco

BMJ quality & safety

Yen-Fu Chen

Journal of Surgical Oncology

〖달포차〗ᗌ은평건마 dAlpochA4.넷 은평휴게텔 은평건마

altay jamtogel

GALIP EMRE YILDIRIM

La Vanguardia

Hector Lopez

Pakistan journal of pharmaceutical sciences

Aamir Sharif

José Antonio Aravéquia

Mehmet Yüksel

The Japanese Journal of Urology

Nouval Shahab

Limnology and Oceanography

Robert Kiefer

Jahid Hossain

Operative Techniques in Cardiac and Thoracic Surgery

David McGiffin

Joytirveda Prasthanam , UGC CARE Listed Journal, ISSN 2278-0327

Radha Ranjan

Mila Marliani

Nonlinear Dynamics

Antonello Salvatori

Galicia, una autonomía que descubrir!

Andres Santiago Osalde Mercier

Daniel Ratiu

Acta Psiquiátrica Psicológica Am Lat

Victor Portavales Silva

See More Documents Like This

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024

ER Diagram Example: Video Rental System

Visual Paradigm Online (VP Online), an online Entity Relationship Diagram drawing editor that supports Entity Relationship Diagram and other diagram types such as ERD, Organization Chart and more. With the intuitive Entity Relationship Diagram editor you can draw Entity Relationship Diagram in seconds.

Explore more Entity Relationship Diagram templates

Start creating great diagrams

©2024 by Visual Paradigm. All rights reserved.

• Terms of Service
• Privacy Policy
• Security Overview

Review Question 1

Describe the two main ways in which data-flow diagrams are used to manage the complexity of systems.

A discussion of this question can be found at the end of this chapter .

Review Question 2

What are the four different system models which may include data-flow diagrams?

Review Question 3

What are the external entities in the following diagram Video-Rental LTD case study.

Figure 6.11. Find the external entities

Review Question 4

What are the data-flows between Supplier and Video-Rental LTD case study in the above diagram?

Review Question 5

What are the processes in the above diagram Video-Rental LTD case study?

Review Question 6

What are the data stores in the context diagram Video-Rental LTD case study?

Review Question 7

What does the zero mean in the top left of the Video-Rental LTD process in the context diagram?

Review Question 8

Describe the first, top level DFD created for a system.

Review Question 9

Outline the main roles of Context Diagrams.

Review Question 10

Follow the suggested steps to create a context diagram for the Video Rental LTD case study.

Review Question 11

The following Estate Agency case study will be used in this, and some later, review questions. This is the same case study as used in Chapter 4, An Introduction to Analysis and Design , but we will repeat the text here for your convenience.

Estate Agency case study

Clients wishing to put their property on the market visit the estate agent, who will take details of their house, flat or bungalow and enter them on a card which is filed according to the area, price range and type of property.

Potential buyers complete a similar type of card which is filed by buyer name in an A4 binder.

Weekly, the estate agent matches the potential buyer's requirements with the available properties and sends them the details of selected properties.

When a sale is completed, the buyer confirms that the contracts have been exchanged, client details are removed from the property file, and an invoice is sent to the client. The client receives the top copy of a three part set, with the other two copies being filed.

On receipt of the payment the invoice copies are stamped and archived. Invoices are checked on a monthly basis and for those accounts not settled within two months a reminder (the third copy of the invoice) is sent to the client.

Create a context diagram for this Estate Agency case study.

Review Question 12

What are the processes in the level 1 DFD for the Video Rental case study below?

Review Question 13

What are the data stores in the level 1 DFD above?

Review Question 14

What is meant by functional decomposition?

Under what conditions would you decompose a process on a Data-Flow Diagram?

Review Question 15

Decompose the Video Rental Level 1 DFD process “ loan of video ” into a Level 2 DFD.

Review Question 16

Create a Level 1 DFD for the Estate Agency case study based on the context diagram from the previous Review Question and the case study text.

Review Question 17

Create a Level 2 DFD for the “ invoice client ” process of the Estate Agency case study based on the Level 1 DFD from the previous Review Question and the case study text.

Review Question 18

What are some of the specific benefits of Data Flow Models?

Review Question 19

Describe each of the main elements of Data-Flow Diagrams.

Review Question 20

Describe two of the points at which Data-Flow Diagrams are used during systems analysis

Review Question 21

The details of any level 2 or lower DFD could be displayed in a level 1 DFD, so really there is no reason not to model the entire system in a single level 1 DFD and avoid all the problems of balancing and hierarchical process numbering and so on.

Review Question 22

There is no facility in the Data-Flow Modelling technique to model the order in which processes occur and data flows. When creating an information system such time-based aspects of a system are just as important as the processes and data themselves.

Why do you think that such a feature not been created as part of Data-Flow Diagrams, and how can system designers get around this omission?

Discussion of Review Question 1

Decomposition – which divides complex information into manageable chunks using a hierarchical tree structure. An overview of the problem is presented at the top level of the structure, while lower levels provide increasing depth of detail for narrower areas of the problem

Abstraction – enables software engineers to concentrate on only one aspect of the system at a time. Different models are used to model different perspective of the system. Data-Flow Diagrams concentrate on information flows and the activities which process this information.

Discussion of Review Question 2

Current System Physical model – the physical processes and data-flows and data stores of the current system may be modelled with DFDs (e.g. forms, pieces of paper, physical files and filing systems etc.)

Current System Logical model – the logical processes and data-flows and data stores of the current system may be modelled with DFDs (e.g. logical actions, logical collections of data, logical packages of information flowing etc.)

Required System Logical model – the logical processes and data-flows and data stores of the required system may be modelled with DFDs as part of the specification of the required system

Required System Physical model – the physical processes and data-flows and data stores of the required system may be modelled with DFDs as part of the design for the required system

Discussion of Review Question 3

There are two external entities shown in the above diagram (as ovals):

Customer – a customer who can borrow videos

Supplier – the local supplier

Discussion of Review Question 4

There are 3 data-flows shown in the above diagram (as named arrows):

Available titles – from Supplier to Video-Rental LTD

Order – from Video-Rental LTD to Supplier

Videos – from Supplier to Video-Rental LTD

Discussion of Review Question 5

There is just one process in the above diagram (a rectangle with three parts) - Video-Rental LTD

Discussion of Review Question 6

There are no data stores in the above diagram (rectangles with two parts)

Discussion of Review Question 7

The top left part of a process rectangle is the process number. For context diagrams, if any number at all is used, it is usually zero. The zero indicates that this is the whole system, whereas in lower level DFDs numbers like 1 and 3 indicate sub-processes of the whole system. This will become more clear when you have progressed to understanding and creating hierarchical, levelled diagrams.

Discussion of Review Question 8

A Context diagram is the first DFD to be created for a system. It represents a model of the system as a whole (i.e. as a single process) and this systems interactions with external entities that are outside the boundaries of the system, but which provide inputs to, and receive the outputs of the system being modeled.

Context diagrams have the following features:

only one process, representing the whole system

they show no data stores

they show all external entities with which the system exchanges data-flows.

Discussion of Review Question 9

Functional decomposition is the breaking down of higher level processes into their component sub-processes, data-flows and data stores as lower level DFDs.

The condition to decide to decompose a process is any time where there is some detailed aspect of the system that is not modeled by the process description alone — i.e. when a lower level DFD provides something more to the software engineer, such as sub processes, additional data stores, and data-flows that are used only for the process and which have not been modeled at the higher level DFD.

Discussion of Review Question 10

Identify data-flows by listing the major documents and information flows associated with the system.

You may find the use of the following kind of table is useful:

From the case study we can underline all potential data flows INTO AND OUT OF THE SYSTEM. At this point look for any possible data-flows, we can change our minds at any time in the process of creating a context diagram. We are not worried about data-flows that seem to be within the system at present, so the sender and receiver should always be either an external entity, or the system itself.

Video-Rental LTD is a small video rental store. The store lends videos to customers for a fee, and purchases its videos from a local supplier.

A customer wishing to borrow a video provides the empty box of the video they desire, their membership card, and payment – payment is always with the credit card used to open the customer account. The customer then returns the video to the store after watching it.

If a loaned video is overdue by a day the customer's credit card is charged, and a reminder letter is sent to them. Each day after that a further chard is made, and each week a reminder letter is sent. This continues until either the customer returns the video, or the charges are equal to the cost of replacing the video.

New customers fill out a form with their personal details and credit card details, and the counter staff give the new customer a membership card. Each new customer's form is added to the customer file.

The local video supplier sends a list of available titles to Video-Rental LTD, who decide whether to send them an order and payment. If an order is sent then the supplier sends the requested videos to the store. For each new video a new stock form is completed and placed in the stock file.

Let us consider each data-flow in turn:

video by customer when joining the store — this is a strong candidate data-flow, though we might name it 'video loan' or 'details of loaned video'

customer details by customer when joining the store — this is a strong candidate data-flow

membership card issued to customer — this is a strong candidate data flow

membership card presented by customer when renting a video — this is a strong candidate data-flow

empty video box presented by customer when renting a video — this is a strong candidate data-flow, but perhaps should be call 'request for video' or something similar

payment by customer when renting a video — this is a strong candidate data flow

return of video by customer — this is a strong candidate data flow, although the data might be 'returned video' or 'returned video details'

credit card charge by system — this is a strong candidate data flow, but in fact we have already identified a payment by the customer (when renting a video) and we could just consider this to be anther example of customer payment (for simplicity, although alternatively we could consider this a separate data-flow, the decision could be influenced on the sophistication of the systems processing of payments, and might be delayed until more detailed DFDs are produced later in the analysis procedure)

overdue reminder letter from system — this is a strong candidate data flow

payment by system for order — this is a strong candidate data flow

list of available titles from supplier — this is a strong candidate data flow

the requested videos from supplier — this is a strong candidate data flow, although might be called something like 'videos purchased'

stock form — this last data-flow is within the system, so this will not be used in the context diagram but will probably appear in a more detailed DFD later

You might have noticed

Identify external entities by identifying sources and recipients of the data-flows, which lie outside of the system under investigation.

This step is easy if we have created a table like the above, since we can just create a list of all the different entities:

supplier (a candidate might be the credit card company, but we shall choose to consider the customer to be charged in this case for simplicity)

Draw and label a process box representing the entire system.

Draw and label the external entities around the outside of the process box.

We just need to add external entity symbols for 'customer' and 'supplier'.

Add the data-flows between the external entities and the system box

we now need to add those data-flows earlier:

We can do a quick check when we have created the diagram by counting the number of flows out of, and into each entity.

From column 'sender' we can see there should be:

5 data-flows out of the system

5 data-flows out of customer

2 data-flows out of supplier

From column 'receiver' we can see there should be:

7 data-flows into the system.

3 data-flows into customer

Our context diagram looks as follows:

Discussion of Review Question 11

Create new customer

Loan of video

Stock control

Discussion of Review Question 12

There are 2 data stores:

Discussion of Review Question 13

First we start with the context diagram, since all external entities and data-flows on this diagram must appear on our Level 1 DFD:

We can now create an 'empty' Level 1 DFD with these entities and data-flows:

Identify processes . Each data-flow into the system must be received by a process. Each process must have at least one output data-flow. Each output data-flow of the system must have been sent by a process.

Now we need to identify the recipient and sending processes of the system for each data-flow. We need to replace with a system process each occurrence of 'system' as the sender or recipient in the table of data-flows created previously.

Possible processes have been inserted in the following table:

Draw the data-flows between the external entities and processes . After creating process boxes and drawing the data-flows the diagram looks as follows:

Identify data stores by establishing where documents / data needs to be held within the system. Add the data stores to the diagram, labelling them with their local name or description.

There seem to be 2 main data stores required: a store of customer details 'customer file' and a store of which videos are in stock 'stock file'.

After adding these to the diagram looks as follows:

Add data-flows flowing between processes and data stores within the system. Each data store must have at least one input data-flow and one output data-flow.

We can create a table to indicate which processes send and receive data from each data store:

After adding these data-flows the diagram looks as follows:

check diagram No record seems to be made of when a video is lent to a customer — there ought to be a data-flow from 'loan of video' to 'stock file' called something like 'item on loan'. Likewise when an item is returned the details should be recorded in a data-flow called something like 'item returned'.

Apart from these extra two data-flows the diagram appears to be correct.

So our Level 1 DFD for the Video Rental case study is now:

Discussion of Review Question 14

Make the process box on the Level 1 diagram the system boundary on the Level 2 diagram that decomposes it.

This gives us the following, “ empty ” Level 2 DFD:

Identify the processes inside the Level 2 system boundary and draw these processes and their data-flows.

For each data-flow into and out of the process for which this Level 2 diagram is being created we need to identify an appropriate sub-process to receive and send the data flows. The following table lists each data-flow and suggests a suitable sub-process to receive/send the data-flow:

Adding these processes and data-flows to the diagram we get the following:

Identify any data stores that exist entirely within the Level 2 boundary, and draw these data stores: For this example there don't appear to be any “ local ” data stores

Identify data-flows between the processes and data stores that are entirely within the Level 2 system boundary: Since there are no local data stores, there are no data-flows between processes and data stores to be added.

Check the diagram: Upon checking the diagram, we find that the process “ validate customer ” has no output data flows. Looking more closely we see that a plausible data flow out of “ validate customer ” would be something like “ loan permission ” .

Upon adding this new data-flow the diagram looks as follows:

Discussion of Review Question 15

From the case study we can underline all potential data flows INTO and OUT OF THE SYSTEM. At this point look for any possible data-flows, we can change our minds at any time in the process of creating a context diagram. We are not worried about data-flows that seem to be within the system at present, so the sender and receiver should always be either an external entity, or the system itself.

Clients wishing to put their property on the market visit the estate agent, who will take details of their house, flat or bungalow and enter them on a card which is filed according to the area, price range and type of property .

Weekly, the estate agent matches the potential buyer' requirements with the available properties and sends them the details of selected properties.

We can build a table of these data-flows, and the senders and receivers of these flows.

Rejected candidates for data-flows include:

the internal copies of the invoice - these data-flows do not go outside the system boundary so will not be part of this context diagram (but may feature on a more detailed DFD later)

the client details card is filed IN the system, so this internal data-flow will not feature on the context diagram

It is worth noting that the exchange of contracts between client and buyer is not a data-flow into or out of the system, but this data-flow between external entities is relevant so ought to be notated on the context diagram.

This step is easy if we have created a table like the above, since we can just create a list of all the different entities: client, buyer.

Draw and label a process box representing the entire system:

Draw and label the external entities around the outside of the process box. We just need to add external entity symbols for 'client' and 'buyer'

Add the data-flows between the external entities and the system box. We now need to add those data-flows earlier. Our context diagram looks as follows:

We can check the diagram quickly looking at the table:

Client should send 2 data-flows, and receive 3.

Buyer should send 2 data-flows and receive 1.

System should send 3 data-flows and receive 3.

Discussion of Review Question 16

We should start with the context diagram, and create an 'empty' Level 1 DFD with all the same external entities and data-flows:

Identify processes - Each data-flow into and out of the system must be received by /send by a process. Now you need to identify the recipient and sending processes of the system for each data-flow. We need to replace with a system process each occurrence of 'system' as the sender or recipient in the table of data-flows created previously. Possible processes have been inserted in the following table:

Draw the data-flows between the external entities and processes. We can now add these processes to the diagram, and connect the appropriate data-flows:

Identify data stores by establishing where documents / data needs to be held within the system. Add the data stores to the diagram, labelling them with their local name or description. There are two 'card' stores (clients and buyers) so these should be data stores 'property file' and 'buyer details'. A file need to be kept for the invoice copies 'invoices'. We can add these data stores to the diagram:

Add data-flows flowing between processes and data stores within the system. Each data store must have at least one input data-flow and one output data-flow (otherwise data may be stored, and never used, or a store of data must have come from nowhere!). Ensure every data store has input and output data-flows to system processes. Most processes are normally associated with at least one data store.

These data-flows can be added to the diagram:

Check diagram . We now can check the diagram for correctness, and find a process that has no output data-flow 'archive sale'. An appropriate data-flow, into data store 'invoices' would be something like 'record of payment'. The consistent and balanced Level 1 DFD now looks as follows:

However, there is another problem with the diagram — what causes the process 'invoice client' to send an invoice or reminder to the client? The only input to the process 'invoice client' is a 'reminder' from the 'invoices' data store. The answer is that there are two things that trigger this process to send a data-flow to the client:

knowledge that sale has been completed

knowledge that a payment on an issued invoice is overdue

The second is a time-based event, and not modelled explicitly in Data-Flow Diagrams. However, the first indicates there should be a data-flow from an external entity to the system indicating that contracts have been exchanged. If we look carefully at the case study again, we find that:

When a sale is completed, the buyer confirms that the contracts have been exchanged, client details are removed from the property file, and an invoice is sent to the client.

This must mean that the buyer informs the system that the sale is complete, so we must create a new data-flow from 'buyer' to 'invoice client' called something like 'confirmation of sale'. (NOTE: Since we are adding a new data-flow between the system and the external entities, we shall have to update the parent diagram — if we forget we will be reminded by any CASE tool consistency checker).

We also notice there should be a data-flow of 'client to delete' from process 'invoice client' to the data store 'property file'.

Our Level 1 DFD now looks as follows:

Discussion of Review Question 17

We should start with the Level 1 DFD, and create an 'empty' Level 2 DFD with all the same external entities and data-flows as the “ invoice client ” process.

For each data-flow into and out of the process for which this Level 2 diagram is being created we need to identify an appropriate sub-process to receive and send the data-flows. The following table lists each data-flow and suggests a suitable sub-process to receive/send the data-flow:

The last row in the table above is interesting — there doesn't appear to be a sub-process inside the “ invoice client ” process that creates the data-flow “ client to delete ” . Looking carefully at the Level 1 DFD we can see that the “ archive sale ” process is probably most appropriate to be sending the property file the details of which client to delete, since it is this process that receives the payment from the client. Therefore we need to delete this “ client to delete ” data-flow from the Level 2 DFD, and change the Level 1 DFD to have this data-flow from “ achieve sale ” to the “ property file ” .

Identify any data stores that exist entirely within the Level 2 boundary, and draw these data stores. For this example there don't appear to be any “ local ” data stores

Identify data-flows between the processes and data stores that are entirely within the Level 2 system boundary. Since there are no local data stores, there are no data-flows between processes and data stores to be added.

Check the diagram. There appear to be no inconsistencies with the diagram, so our final diagram stays the same.

Discussion of Review Question 18

Data-Flow Diagrams concentrate on the flow and transformation of data. High level Data-Flow Diagrams are decomposed to a set of more detailed diagrams.

Discussion of Review Question 19

Processes – the activities carried out by the system.

the data inputs and outputs to/from these activities.

where information is stored within the system.

the sources of data-flows into the system, and recipients of information leaving the system.

Discussion of Review Question 20

Any two of the following would be fine:

Current System Physical model – the physical processes and data-flows and data stores of the current system may be modeled with DFDs (e.g. forms, pieces of paper, physical files and filing systems etc.) [investigating current system]

Current System Logical model – the logical processes and data-flows and data stores of the current system may be modeled with DFDs (e.g. logical actions, logical collections of data, logical packages of information flowing etc.) [investigating current system]

Required System Logical model – the logical processes and data-flows and data stores of the required system may be modeled with DFDs as part of the specification of the required system

Required System Physical model – the physical processes and data-flows and data stores of the required system may be modeled with DFDs as part of the design for the required system

Discussion of Review Question 21

While, theoretically, it would be valid to model an entire system in a single level 1 DFD, for any non-trivial system such a diagram would fill an entire wall or floor of a very large room !

In the same way the a physical organisation is divided into departments or sections (or faculties for a University), to gain the benefits of local organisation and ability to manage, so levelled DFDs allow different logical functions of organisations to be abstracted and modelled together. So all sales functions of an organisation can be modelled as a single “ sales ” process, and then described at a lower level in more detail.

Obviously a major advantage of levelling is that the complexity of any single diagram can be restricted so as not to overwhelm the reader.

Discussion of Review Question 22

It should be remembered that each modelling technique (such as Data-Flow Diagrams and Entity-Relationship Diagrams) only presents one aspect of the system — the model of the complete system is formed when a number of different models are put together.

The three main traditional modelling techniques for systems analysis and specification are:

Data-Flow diagrams

Entity Relationship diagrams

Entity Life histories

The third of these, Entity Life Histories (ELHs), is the modelling technique that represents those aspects of a system that change over time. Entity Life Histories are introduced in a later unit, and play an important role in relating the processes and data stores of DFDs with the logical data models of Entity Relationship Diagrams.

Any particular modelling technique will have been designed to represent only certain aspects of a system, since any non-trivial system would be much to complex to ever model with a single technique — any resulting diagram or set of diagrams would contain more information that would be usefully understandable by users and system developers.

Video Rental System

This ERD example shows a very simple database design of a video rental system by describing the customer, movies and the producers and the attributes and relationships between them

Posted by: Jason Voss

Related posts:

Turn every software project into a successful one.

Try Visual Paradigm for Free! Or learn more about our features.

• Activity Diagram (UML)
• Amazon Web Services
• Android Mockups
• Block Diagram
• Business Process Management
• Chemical Chart
• Cisco Network Diagram
• Class Diagram (UML)
• Collaboration Diagram (UML)
• Compare & Contrast Diagram
• Component Diagram (UML)
• Concept Diagram
• Cycle Diagram
• Data Flow Diagram
• Data Flow Diagrams (YC)
• Database Diagram
• Deployment Diagram (UML)
• Entity Relationship Diagram
• Family Tree
• Fishbone / Ishikawa Diagram
• Gantt Chart
• Infographics
• iOS Mockups
• Network Diagram
• Object Diagram (UML)
• Object Process Model
• Organizational Chart
• Sequence Diagram (UML)
• Spider Diagram
• State Chart Diagram (UML)
• Story Board
• SWOT Diagram
• TQM - Total Quality Management
• Use Case Diagram (UML)
• Value Stream Mapping
• Venn Diagram
• Web Mockups
• Work Breakdown Structure

ER Diagram for a Video Rental

You can easily edit this template using Creately's ER diagram online tool . You can export it in multiple formats like JPEG, PNG and SVG and easily add it to Word documents, Powerpoint (PPT) presentations, Excel or any other documents. You can export it as a PDF for high-quality printouts.

• Flowchart Templates
• Org Chart Templates
• Concept Map Templates
• Mind Mapping Templates
• WBS Templates
• Family Tree Templates
• Network Diagram Templates
• SWOT Analysis Templates
• Genogram Templates
• Activity Diagram
• Class Diagram
• Collaboration Diagram
• Component Diagram
• Data Flow Diagrams(YC)
• Deployment Diagram
• Object Diagram
• Sequence Diagram
• State Chart Diagram
• Use Case Diagram

Related Templates