We are here with you hands in hands to facilitate your learning & don't appreciate the idea of copying or replicating solutions. Read More>>

Looking For Something at vustudents.ning.com? Click Here to Search


+ Link For Assignments, GDBs & Online Quizzes Solution


+ Link For Past Papers, Solved MCQs, Short Notes & More

Dear Students! Share your Assignments / GDBs / Quizzes files as you receive in your LMS, So it can be discussed/solved timely. Add Discussion

How to Add New Discussion in Study Group ? Step By Step Guide Click Here.

Database Management System (CS403)
Assignment No.1
Total Marks: 10
Your assignment must be uploaded before or on 9th November 2012.
Rules for Marking
It should be clear that your assignment will not get any credit if:
1. The assignment is submitted after due date
2. The assignment is copied
The objectives of this assignment are,
1. Giving the idea of the most common tool used for designing database systems i.e. Data Flow Diagram. It is used to design systems graphically and expresses different details of system in different DFD levels.
2. To become familiar with the flow of data between different processes and to hide complexities in any given system.


In this course we are going to develop a complete physical database for “Trade Management System” that will computerize all the necessary Trade Management processes for a small business shop, BEST Mart. For this we will divide this whole project in small 4 to 5 assignment chunks and will try to cover every phase of database development life cycle from scratch to execution. Scenario for the Trade Management System is given below.
There exists a BEST Mart- a shopping centre, whose owner wants to computerize his business by developing Trade Management System. For this, owner hires a Database Administrator and put up a real world scenario and requirements as given below:
Trade Management System permits users to proficiently initiate and evaluate the process of requirement for the BEST Mart. Procedure begins when a client comes to BEST Mart, selects the cart and place the things in cart and goes towards salesman. The salesman examines the code of each selected item. On entry system will display invoice with some details like name of the product, its related magnitude/quantity and total sales line items along with total bill. After placing order, client will ahead to accountant counter to pay bill.
Trade Management System will support both types of customers, Registered and Non-Register. For Registered customers it is necessary for system to check whether he/she is on credit bases or not. For non-registered customers, it must have to be registered only by
©Virtual University of Pakistan 2
the Owner of the BEST Mart. Information about number of creditors and debtors are
known by the accounts department.
System will show flexibility in a sense that it should accept all payment methods i.e.
cash, credit and cash with credit.
Same is the scenario with Administrator/Owner of BEST Mart to purchase items from
different vendors on cash, credit or combination of two. The stock department and Sale
department will need to generate reports about stock status sale in different time span.
Task Description:
This Assignment is starting phase and in this assignment you will focus only on the
tasks given below:
1. You are required to identify all the processes in the system.
2. You are required to mention all the data stores in which data is stored.
3. Find out all the external entities interacting with the system
4. Create a Context level DFD
5. Create a level zero DFD
6. Create a detailed DFD of every process if needed
You have to perform all these steps give above in your solution file.

Use all concepts you have studied so far and techniques discussed particularly
in lecture 5 and 6 regarding this assignment.
Drawing Final Data Flow Model:
You can use any tool for drawing like MS Office or Visio.
Important things to consider:
1. As happens in real world that everyone visualize a problem in different way so the
solutions of all students should be according to their own thinking not taken from
some source.
2. As this is preliminary phase of our system so it is recommended that you identify
as much processes and their relationships as you can (some of them may be
eliminated in coming assignments).

+ How to Follow the New Added Discussions at Your Mail Address?

+ How to Join Subject Study Groups & Get Helping Material?

+ How to become Top Reputation, Angels, Intellectual, Featured Members & Moderators?

+ VU Students Reserves The Right to Delete Your Profile, If?

See Your Saved Posts Timeline

Views: 12583


+ http://bit.ly/vucodes (Link for Assignments, GDBs & Online Quizzes Solution)

+ http://bit.ly/papersvu (Link for Past Papers, Solved MCQs, Short Notes & More)

+ Click Here to Search (Looking For something at vustudents.ning.com?)

+ Click Here To Join (Our facebook study Group)

Replies to This Discussion

how i start the block diagram

Learn how to make ER diagram in MS visio 2012 (in urdu)  :-) 



Best of luck to all

Listen to video lec-12 for detail about context level and level-0 DFD...after 15 min duration it explains context level

I am using this site for making DFD ,, I try to paste diagram in ms word but there is some error ...plz tell me how to paste it in ms word.......Plz help
Bellow is given site address

sara sis.. try to paste it in paint then in word.

Plz is assignment ka solution send karo?

tell me the processes used in this assignment ??

Plz give us the correct solution 

Nhi ban rha hy DFD

Bilkul mujse b nahee ban raha

For understanding the concept of the DFD 

read this 

Definitions of DFDs

  1. DFDs::="Data Flow Diagrams".
  2. DFD::="A diagram that shows how data moves through processes and stores, from sources to sinks, in a system". A data flow diagram has 
    1. External Entities -- Where data comes from or goes to
      • Sources -- Where data comes from
      • Sinks -- Where data goes to
      • Some External Entities are both sources for some data and sinks for other data.
    2. Processes -- Where things happen to data
    3. Stores -- Where data is held ready for future use
    4. Data Flows -- connecting processes to and from entities, processes, and stores.

    Here is an example of a rough pencil and paper DFD:

    [Author (entity) writes Document(store) and prints Document to Printer]

    Each DFD summarizes a collection of simple statements. The above diagram implies some of the following facts: 

    1. The Author makes changes to the document.
    2. The Author reads a preview of the document.
    3. The document is printed on the printer.

    Physical and Logical Data Flow Diagrams

    A DFD can be used to model the physical structure of a system. The physical model describes and names the hardware and software involved. Each process is one program, but may be a subsystem of programs. Each store is a separate file (think of a folder in a filing cabinet) or a table in an data base. In other words, physical DFDs show the architecture of the system not its underlying logic. However this information is better shown using an UML Deployment Diagram.

    In a logical DFD there is no mention of how something is done. No technology is mentioned. Several programs may be inside a single process. Avoid drawing DFDs that show the inner workings of a program -- they are better ways to picture internal architecture of software. One program may even implement several processes. Stores are not described in terms of their media (data base, mag tape, disk, RAM,...) but are named for the entities (outside the system) that they store information about (student, teacher, ...).

    As a rule you should aim to move to logical DFDs as soon as possible. You can then solve the logical problems in the system without getting confused in the technology. This process produces a top-level design for a new system and is the start for specifying data and programs.

    Notations for DFDs

    There are three different icons in a DFD: External entity, Process, and store.

    There are several different notations for DFD icons: 

    1. Yourdon and/or De Marco
    2. Gane & Sarson
    3. SSADM(Structured System Analysis and Design Methodology)
    4. Unified Modeling Language Component diagrams.

    [Four Notations for DFDs]

    The SSADM DFD notation was developed by the British Civil Service (with LBMS Ltd.) from the Gane and Sarson notation. It is used in England and what used to be the British Commonwealth. As far as I can judge the Gane and Sarson form is most often used notation in the USA. The Gane and Sarson notation also allows a process box to have three compartments. These are used for: (top) a unique process ID. (middle) description of the function of the process. (bottom) the location where the process is carried out of the actor responsible for the process.

    I will use Gane and Sarson and encourage you to do so as well in this course. But different enterprises will use different notations.

    Below I have some notes [ UML notations for DFDs ] that show how the UML is used and explains why you should, for now, use one of the other notations rather than the UML.

    Semantics of DFDs

    Many people misunderstand DFDs -- they don't know what they mean. They have the wrong 
    . This section is about the meaning of the parts of a DFD. It is vital that you study the meaning of diagrams as well as just learning the notation (syntax).

    Semantics of External Entities in DFDs

    External entities are outside the current system. There are 
    . Sources show how data that flows into the system from outside. Sinks show where data leaves the systems. Some entities are both sources and sinks. We tend to think of entities as being people. But they can be parts of other systems -- hardware and/or software. The key point is that we can not redesign external entities. Our system has to fit them. They are also the main source of disturbances that the system must handle. We can not control the input from an external source unless we have a process to handle anything that can happen and sieve out the data that is needed for our system.

    Semantics of Processes in DFDs

    Processes are the only active part of a DFD. It is the only place where results can be computed, data processed, and decisions made. Data does not flow without there being a process to move it. A process is best thought of as a continuously running program. They handle whole streams of data. They may wait when the data is not available but they do not stop. They may repeat the same computation on each item of data as it arrives. They can make decisions and route input data to different outputs. Processes can also wait to be asked for data and then provide it to one their outputs. Try to not see them as steps in an algorithm -- use an activity diagram (later) for algorithms.

    Some processes are subsystems. This helps keep the diagrams of complex diagrams simple. They are shown as a whole process in some DFDs. Each is also defined by a DFD. This is called the refinement of the process. Such processes can contain hidden data stores and sub-processes. There is a potential tree of refinements.

    Semantics of Data Stores in DFDs

    Stores are places where data is placed, and where it waits to be used. Some people use the 
    1.  mnemonic to describe the interaction between a process and a data store:
    2. CRUD::acronym=Create + Read + Update + Delete.

      Ultimately the data flows between processes and data stores are (nowadays) programmed using the Structured Query Language --(SQL).

         SELECT StudentName FROM Student WHERE Student.id = "123-45-6789"
      However it is a mistake to go in to this level of detail in a DFD. A single data flow attached to a data store can be implemented by any number of SQL-type statements.

      On the other hand you should aim to have each data store labeled with the name of a single type of real world object. The data store holds records about all entities of some type or other. The name of the data store should reflect the type of entity. Ultimately they become tables in a database or file.

      Traditionally, creating data in a data store -- adding new records -- is shown by an arrow that flows from a process to a data store. Reading data is indicate by an arrow from the store to the process that needs it. Updates and deletions are shown as two way arrows since data has to be read and then rewritten.

      Notice that a data store is needed whenever data is reordered or reorganized. On the other hand if the store is a queue or buffer, so that the first item of data to arrive is the first to be output then we don't show a data store: arrows are understood to be buffered by a queue.

      Another simplification: you can put the same data store in several places. Traditionally you mark stores like this with an extra stripe at the left hand end. It also helps if you give each store a unique Id.

      Semantics of Arrows in DFDs

      The meaning of a data flow (arrow in a DFD) is subtler than you might guess. It depends on the symbols at each end: process, Entity, or Store.

      Notice that only a process can move data. So each data flow must either come from or go to a process. We do not permit data flows to connect entities or stores unless a process is involved.

      Connections between processes and entities define the interfaces between the system and its environment. It is rarely unambiguous what data is communicated. Thus these data flows must be described -- at least given a name.

      Similarly, it is not clear when you connect one process to another process with an unlabeled arrow what is going on. The arrow needs to be named with the data being transmitted. The name will need further definition (later) in a Data Dictionary. Occasionally you will meet a doubled headed arrow -- here someone has to define the protocol that describes the conversation between the two connected processes.

      Notice that in real systems (unlike computer programs) data flows between processes are buffered. One process writes the data and the data waits in a queue until the other process reads it. The writer doesn't have to wait for the data to be taken away. For example when you send me Email it is automatically stored before I read it. Similarly "Snail Mail" is put in my box. Memos, rosters, etc. are all buffered for me. So when Modeling a real system you don't have to say that data in a data flow is in a queue. This buffering is implicit in the the Data Flow model.

      A data flow out of a store can only go to a process. It indicates that the process reads the data in the store but does not change it. External entities and stores are not allowed to read data directly -- they must get the data indirectly via a process. However, you don't have to label and document these data flows if the process can read the whole store. You only have to document the data flow from a data store if the process accesses only a part of the store.

      A data flow into a store must again come from a process. It indicates any combination of the three basic operations: Create, Update, or Delete. Again if the arrow is unlabeled then it is assumed that the process can (or will) change any item in the store.

      A double-headed arrow between a data store and a process indicates that the process may: create, read, delete and update the data in the store. Some omit the arrow heads in this case.

    . . . . . . . . . ( end of section Semantics of DFDsContents | End>>

    Drawing DFDs

    Keep DFDs simple by keeping them abstract, logical, or essential -- don't document the media and format of the information -- just give it a meaningful name. Note: you can keep a list of the current or planned media/formats in a "data dictionary". Similarly a DFD should not show the current type of a part: people, procedures, hardware, and software all tend to be implementations of processes. The type of a component should be noted in a data dictionary (see [ a5.html ] ). Neither should a DFD show steps in a user scenario like "login" and "logout". These can be analyzed later in the process using more suitable tools.

    Do DFDs quickly -- pencil and paper, chalk-board. Only tidy them up when some else needs to see them. Use a tool only to impress people. However, even when sketching roughly follow the rules and avoid the errors listed on this page.

    Some people put unique short identifiers on each part of a DFD. Avoid this if you can! But in those cases where the boxes are numbered, here are the rules: processes are numbered 1,1.1, 1.2, ... and data stores have an id that starts with "D" plus a number. External entities can be given single lower case letters to be their unique id. These ids are good for linking the same part in different diagrams. For example, the parts numbered 1.1, 1.2, 1.3, etc. are all parts of the process numbered 1. Similarly, 1.2.1, 1.2.3, etc. are subparts of process 1.2.

    Never use more than one piece of paper for a DFD. The trick is to have layers of detail. We do this by expanding, exploding, or refining a process into a lower level diagram. This is done by taking a process and drawing a DFD that would replace it in the original DFD. There are three levels of detail commonly needed: context, level-0, and level-1. Here is a picture of how refinement works:

    Three levels of DFD

    The table shows the three types of DFD and is followed by definitions and examples. 

    Level Content
    Process Context Shows one process with its inputs and outputs only.
    System Context One process + surrounding external entities
    Level-0 Make the central process BIG and draw stores, processes, and flows inside
    Level-1 Take a process on the level-0 and repeat the expansion in another DFD
    Level-n+1 Take a level n process and refine it.

    (Close Table)
    Note: 3 or 4 levels is usualy enough. Don't get too detailed. Other techniques [ r1.html ] are better.

    Examples of DFD Levels -- Conext Level0 Level1


    [Level 0]

    [Level 1]

    A Note on level terminology

    I will be following well known textbooks on the naming of the levels. The Wikipedia seems to use a different form.

    Definitions of DFDs

  3. Context_DFD::DFD=Shows a system as a single process surrounded by external entities. This should show a single process -- your system surrounded by the external entities that send it data and get data from it. Each data flow should be named. No internal details allowed -- they come later. No data stores, no sub-processes: just establishes the Boundary between the system and its environment.

    One Process takes questions and answers from faculty and uses them to tutor students

  4. Level_0_DFD::=DFD=Shows the main functions in a system as processes.... At this level you show up to about a dozen main functions that the system provides, plus the data stores and external entities that interact with the processes. A Level_0_DFD always expands a Context_DFD

    Expansion of Tutor DFD into 2 data stores and 5 processes

  5. Level_1_DFD::DFD=Takes a single process in a Level_0_DFD and shows the details inside it.

  6. Fish_eye_DFD::DFD=Shows a DFD inside a box representing a process in another DFD. We have a central focus where we show the details but round the edge we have higher level symbols. An excellent way to refine a Context DFD to Level 0, a Level 0 process to Level 1, and so on. It is called a fish-eye diagram Because when a fish looks up out of the water it sees the whole 180 degree view compressed into a small circle. In the center of the view things look big. Further out the look small.

    Refining a DFD

    The process of finding out what is inside a process has many names: leveling, refinement, filling in the details, partitioning, exploding, decomposing, ... It is an important strategy for analyzing a problem. Start with the big picture -- the context -- then break it into smaller and smaller parts. Ultimately, as you decompose or refine processes, you will find yourself needing to express logical rules, algorithms, and types of data. Do not use a DFD to express complex logic, algorithms, or data structures. Instead, record these details by using techniques introduced later in this course: 
    Processes Activity diagrams, Use Cases, and Scenarios. Prototypes.
    External Entities Persona
    Data flows Data dictionary entries and coding techniques.
    Stores Entity Relationship Diagrams, Tables, and Normalization

    (Close Table)

    Bottom-Up DFDs are chaotic

    The above is a top-down procedure. You can also draw rough DFDs of parts of the organization and link them together to get an "end-to-end" model. Here is an example from the first time this course was taught.

    [Free Information System for students 2003]

    These tend to be a little chaotic and unstructured. You may be forced to do this when interviewing people and starting design. But as soon as possible shift to top-down/refinement.

    Principle -- DFDs are systems not programs

    My Law: DFDs are good for recording how a system works. They are a way of choosing what parts of a system to change and which to protect. They can be used to define the inputs and outputs to a program. You can use them to plan a collection of new and old software (system design). BUT don't use them to design the internals of a program. You will make errors. There are more modern techniques for designing programs.

    Rules of DFDs -- DFD Errors

    Notice and learn the rules below. The key thought is that data never moves unless a process moves it.

  7. DFD_Errors::=following, 
    1. Process names must start with a verb and describe an action. Try the "Hey Mom Test." A process name should make sense when prefixed by "Hey, Mom, I'm going to .....". Some describe producing an output for each input (Calculate tax) but most do more -- Prepare monthly summary from weekly data. Stores and external entities should be named with specific noun phrases. They must not indicate any activity. They are passive. All data stores must be named after the specific data they store. Information about people would be in a data store called "Person" for example.

    2. Data flows do not transfer control. An arrow is not a function call or a go to! The processes run in parallel. They can stop and wait for incoming data. It is OK for a flow to send a message, trigger, or signal without other data. However control is not transferred. The sender does not have to wait for a reply.

    3. Name all data flows between processes. Unlabeled arrows between processes are often control flows and so wrong. However: arrows leaving and entering a well-named store only have to be named when they provide access to only parts of the data in the store.

    4. No Flowcharts. Do not use normal flow chart symbols like decision diamonds, START, STOP etc. in a DFD. All parts of a DFD exist at the same time and operate in parallel. A process can read and store data long before and after producing an output. Processes consumes streams of data and produce streams of data.

    5. No magic data flows. Data does not move without a process to move it. So each arrow must have at least one process. Never show arrows connecting an external entry to another entity, or to a data store. Never have an arrow that connects a data store to another store. Examples: Waiter and cook. Coordinator and secretary. Teacher and student. Student to student records. Customer to bank account.

plzzzzzzzzzzzzzzz koi tou solution upload kar de

nai ban raha, plzzzzzzzzzzzz


Latest Activity

HAROON "DOLPHIN SQUAD" updated their profile
38 minutes ago
Moureen Max left a comment for Saddi
4 hours ago
Moureen Max left a comment for Muhammad Hassan Akbar
4 hours ago
Moureen Max left a comment for Muhammad Moin khan
4 hours ago
Moureen Max left a comment for Junaid
4 hours ago
Moureen Max left a comment for hafsa irum
4 hours ago
Moureen Max left a comment for ramla shireen
4 hours ago
Moureen Max left a comment for Raheela kanwal
4 hours ago
Moureen Max left a comment for AAMIR SHAHZAD BUTT
4 hours ago
Moureen Max left a comment for Iqbal
4 hours ago
Moureen Max left a comment for Bilal Raza
4 hours ago
Moureen Max left a comment for A-butt
4 hours ago

Today Top Members 

© 2020   Created by +M.Tariq Malik.   Powered by

Promote Us  |  Report an Issue  |  Privacy Policy  |  Terms of Service