Database Reference
In-Depth Information
collecting and understanding information that relates to how a database, in
its physical implementation, will perform. Initially, you should note any in-
formation gathered during the observation, interview, and use case phases
to determine how much data will be created and manipulated and how that
data will be stored. Additionally, if you are replacing an existing online sys-
tem, you'll get an idea of how the current system performs and how that
will translate into the new system.
Reads versus Writes
When you are conducting user interviews and observations, be sure to note
the kinds of data manipulation taking place. Are users primarily inputting
data, or are they retrieving and updating existing data? How many times
does the same record get touched? Knowing the answers to questions like
these can help you get an idea of how the eventual application will handle
the data in your database.
For example, consider a project to redesign a work-flow application for
high school teachers who need to track attendance and grades. During
multiple observations with the teachers and administrators, you see teach-
ers inputting attendance for each student every day, but they may enter
grades only once a week. In addition to gathering information about what
data is collected and how users enter that data (in terms of data types and
so on), you note that they update attendance records often but update
grades less often.
In another observation, you see a school administrator running reports
on student attendance based on multiple criteria: daily, monthly, per stu-
dent, per department, and so on. However, they've told you they access
grades only on a quarterly basis (semester quarters—every eight weeks—
and not calendar quarters). Similarly, you've noted that the grades call for
a moderate number of writes in the database (on a weekly basis) and an
even lower number of reads. You now know that the attendance records
have a high number of writes but a lower number of reads. Again, this in-
formation may not necessarily affect design, but it helps you leverage cer-
tain specific features of SQL Server 2008 in the physical implementation
phase. In Chapters 9 and 10 we go into detail; for now, it's enough to know
that gathering this information during the requirements gathering phase of
design is important for future use.
Search WWH ::




Custom Search