Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







The Functional Specifications - Data Flow Diagrams

Oracle Database Tips by Donald Burleson

The generally accepted starting point is to begin with either a traditional data flow diagram or a functional model.  (Remember from chapter 3 that a data flow diagram and functional model is almost the same thing)  Let's begin by doing a short review of object analysis.  A functional specification for any system describes the complete logical model and consists of three documents.  The data flow diagram is a pictorial description of all of the processes in the system, and it is supplemented with two other documents.  The data dictionary, that is used to define all of the data flows and data stores in our system, and the process logic specifications (mini-specs) that are used to describe each process, showing how the data flow is modified within each process.

As we may remember from Chapter 3 and our discussion of basic object analysis, the data flow diagram is the foundation of any systems analysis.  The DFD  , diagrams the processes, data flows and data stores as we decompose the system.  While these documents may be known by different names depending upon the analysis methodology that is chosen, they should contain a complete description of all of the entities in our system.  Let's begin by taking a level one data flow diagram and showing the breakdown of the processes (Figure 8.2). 

Figure 8.2 - A level one data flow diagram for filling orders.

Here we see the overall specification for the ?fill order? process, and we can easily see all of the incoming and outgoing data items.  In this case, we see ?cust_info? coming in as the input to the ?fill order? process.  Of course, ?cust_info? does not tells us about the details of this data flow, and we must go to the data dictionary to see the contents of cust_info:

cust_info =  

cust_full_name +

cust_full_address +

cust_phone_nbr + 

{ item_ID + item_quantity }

We will use these data dictionary definitions to gather the data items that are of interest to each process in our data flow diagram.  Remember, the purpose of designing methods is to map the incoming and outgoing data flows to clean, well-defined procedures that can be coupled with the database entities. 

Now let's take a look at how the fill_order process is decomposed into lower level DFDs.  Looking at the next lowest level DFD (Figure 8.3), we see that fill_order is broken down into three sub-processes, check_customer_credit, check_inventoty, and prepare_invoice.  This DFD shows all of the input and output data flows for these processes.

Figure 8.3 - A level two data flow diagram for the fill order process.

Here we see another level of detail for the fill_order process.  This process is broken down into three sub-processes, each with its own data flows and processes.  As we might guess, the departitioning of the processes will correspond to the departitioning of the methods for our object database.

Let's complete the foundation for our methods by showing the next level DFD for some of the lower-level processes, we will use the check_inventory process (Figure 8.4) and the prepare_invoice process (Figure 8.5).  We can assume that these are ?functional primitive? processes and they will serve as our lowest level methods in our example.

It is important for the mapping of methods to database objects to understand when a process has been departitioned to a level that corresponds with the functions of a database entity.  We could continue to departition this DFD, making each process smaller and smaller, but the sub-processes would not easily map to the database objects.  Hence, when we see that a process on our DFD deals with a single function on a single database entity, we know that we have reached the ?functional primitive? level, and the analysis is complete.

Figure 8.4 - The data flow diagram for the check_inventory process.

Figure 8.5 - The data flow diagram for the prepare_invoice process.

Now that we have completed the functional specifications for this system we are ready to take these definitions and create the ?prototypes? for the methods that will eventually become the methods for our database objects.




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.