Database Reference
In-Depth Information
Using Appropriate Diagrams
Most people, including technical people such as programmers and system
administrators, find it easier to conceptualize complex topics if you use a
visual aid. How many times have you been having a discussion with some-
one and said, “I wish I had a whiteboard”? This is because we are often
talking about numerous systems, and we are also talking about data move-
ment through a given system. This is particularly true of data models and
databases; we need to visualize how data enters the system, what is done
to it, where it is stored, and how we can retrieve it.
To this end, it is often helpful to create a number of diagrams that look
at the data model you have created. Initially, if you used a modeling tool,
you can actually export an image file (jpeg, BMP, etc.) of the actual model.
You can create views of the model that show only the entities, or the enti-
ties and their attributes, or even all the entities, their attributes, and rela-
tionships. You can usually generate an image of the physical model or
database as well. Because of its portable format, this kind of file can be use-
ful when you're posting documentation to a document management tool or
even a Web site. Unfortunately, without a technical person to explain the
data model, most nontechnical users can get very little actual information
out of the visual representation of the model.
For nontechnical folks, flowcharts are often the best way to represent
what is happening with the data. You can label the names of the entities as
objects inside the flowchart.
Using Report Examples
When you are discussing the proposed data model with various individuals,
one of the most helpful things you can do is deliver samples of what they
will actually see after the model is built. Often this means building mock-
ups of deliverables, such as application windows or reports. Reporting ex-
amples, in particular, provide a quick way for end users to understand the
kind of data that they will see in the end product. Because this is what they
are most concerned about, spend some quality time developing sample re-
ports to present when you meet with the nontechnical stakeholders.
Converting Tech to Business
Imagine, for a moment, that you have to take your car to a mechanic be-
cause it has a problem whose cause you cannot determine. All you know is
that the car makes a sound it hasn't made before, and you know it can't be
Search WWH ::
Custom Search