We are here with you hands in hands to facilitate your learning & don't appreciate the idea of copying or replicating solutions. Read More>>
+ 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)
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.
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
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).
.+ 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)
how i start the block diagram
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
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
Here is an example of a rough pencil and paper DFD:
Each DFD summarizes a collection of simple statements. The above diagram implies some of the following facts:
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.
There are several different notations for DFD icons:
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.
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.
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.
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.
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:
The table shows the three types of DFD and is followed by definitions and examples.
|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.|
Note: 3 or 4 levels is usualy enough. Don't get too detailed. Other techniques [ r1.html ] are better.
|Processes||Activity diagrams, Use Cases, and Scenarios. Prototypes.|
|Data flows||Data dictionary entries and coding techniques.|
|Stores||Entity Relationship Diagrams, Tables, and Normalization|
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.
plzzzzzzzzzzzzzzz koi tou solution upload kar de
nai ban raha, plzzzzzzzzzzzz