Data modeling and database design

As an accontant, we are the key person to use company data for reporting, analysis, control etc purpose. Also, we are depends on these data to make decision. So we must speak out what is your need in your daily work.

Learning outcomes:
How to draw DFD and system flowchart
What is difference in between these two tools.


The important of documentation:

Tools of documentation
- Narratives
- Flowcharts
- Diagrams
- Other written material

Documentation covers the who, what, when, where, why, and how of:
- Data entry
- Processing
- Storage
- Information output
- System controls

Using the documentation:
- read documentation to understand how a system work.
- evaluate the strengths and weaknesses of an entity's internal controls.
- peruse documentation to determine if a proposed system meets the needs of its users.
- prepare documentation to demonstrate how a proposed system would work.
- prepare documentation to demonstrate the understanding of a system of internal controls.

Two most common documentation tools are:
- Data flow diagrams (DFD)
- Flowcharts

Data Flow Diagrams (DFD):

Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

DFD consists four elements*
- Data sources and destinations
- Data flows
- Transformation processes
- Data stores


Please refer PowerPoint Notes, how to draw these notations.

-----------------------------------------------------------------------------------------------

* Remarks:
In IT world, there are two Data Flow Diagram Notations: Yourdon & Coad or Gane & Sarson. )
If you have interest, please read :
http://www.smartdraw.com/tutorials/software/dfd/tutorial_01.htm
-----------------------------------------------------------------------------------------------

15 rules to draw DFD

•RULE 1: Understand the system. Observe the flow of information and interview people involved to gain that understanding.
•RULE 2: Ignore control processes and control actions (e.g., error corrections). Only very critical error paths should be included.
•RULE 3: Determine the system boundaries—where it starts and stops. If you’re not sure about a process, include it for the time being.
•RULE 4: Draw the context diagram first, and then draw successively greater levels of detail.
•RULE 5: Identify and label all data flows. The only ones that do not have to be labeled are those that go into or come out of data stores.
•RULE 6: Data flows that always flow together should be grouped together. Those that do not flow together should be shown on separate lines
•RULE 7: Show a process (circle) wherever a data flow is converted from one form to another. Likewise, every process should have at least one incoming data flow and at least one outgoing data flow.
•RULE 8: Transformation processes that are logically related or occur simultaneously can be grouped in one bubble.
•RULE 9: Number each process sequentially. A process labeled 5.0 would be exploded at the next level into processes numbered 5.1, 5.2, etc. A process labeled 5.2 would be exploded into 5.21, 5.22, etc
•RULE 10: Process names should include action verbs, such as update, prepare, etc.
•RULE 11: Identify and label all data stores, whether temporary or permanent.
•RULE 12: Identify and label all sources and destinations. An entity can be both a source and destination. You may wish to include such items twice on the diagram, if needed, to avoid excessive or crossing lines.
•RULE 13: As much as possible, organize the flow from top to bottom and left to right.
•RULE 14: You’re not likely to get it beautiful the first time, so plan to go through several iterations of refinements.
•RULE 15: On the final copy, lines should not cross. On each page, include:
–The name of the DFD
–The date prepared
–The preparer’s name