Define Your Data

Define Your Data
B
efore you create your database’s data tables and fill those tables with values, you should set
aside some time for defining your data. You start defining your data by determining the goals,
results, or outcomes that you want your data to help you achieve. Next, you determine the
technical requirements for gathering, entering, storing, using, and analyzing your data.
Equipped with this information, you can better select a suitable database management sys-
tem and better design your tables, fields, and table relations.
2.1 Determine Your Goals, Results, or Outcomes
Many individuals and organizations start defining and designing a database by creating some
data tables, relating the tables together, and filling them with values. These steps alone are not
sufficient for a well-planned database definition and design. You should first determine the
goals, results, or outcomes you need your data to help you achieve. You should then determine
how collecting and analyzing data will help you achieve those goals, results, or outcomes.
Doing so can help provide a broader view of the types of tables and relationships among those
tables to better capture and analyze all of your data.
Quick Start
First, gather key folks who are involved in the designing of your database, those who collect,
enter, and analyze your data, and finally those who make important decisions based on that
data. Then, collect information from these people to help you better design your database.
How To
The key folks involved with your database and its data should be prepared to answer three
questions:
Question #1: What are your goals, and what are the goals of our organization? This can be
broken down into the following:
• What goals are we trying to achieve by collecting this data?
• What kinds of problems or issues are we facing that this data may help address?
• What are we trying to measure, track, or analyze with this data?
35
CHAPTER 2
■ ■ ■

7516Ch02.qxp 1/5/07 3:04 PM Page 35
• From whom or from where are we collecting this data?
• How often are we collecting this data?
Q
uestion #2
:
What results are you looking for, and what result is our organization trying to
achieve? This means the following:
• What do we need to do with this data once we have collected it?
• What results are we hoping to achieve by collecting, measuring, tracking, or ana-
lyzing this data?
Question #3: What would a successful outcome look like for you and for our organization?
• What would a successful outcome look like once we have collected, measured,
tracked, or analyzed this data?
• How do we envision ultimately benefiting from successfully collecting, measuring,
tracking, or analyzing this data?
Use the results of this information-gathering session to develop a plan to better design
your database.
■
Tip
Don’t underestimate the power of clearly defining your and your organization’s goals, results, and out-
comes that your data will help you achieve. For example, clear goals can help you focus on collecting only
the most important data to reach your desired results and outcomes. Focusing on collecting only the most
important data can result in a less cluttered database design that is easier to use and consumes fewer com-
puting resources.
Try It
The ExcelDB_Ch02_01.doc file in the Source Code/Download section of the Apress web site,
, contains a v
ersion of the questions in the preceding “How To” section.
You could use this file in helping determine your organization’s goals, results, or outcomes you

need your data to help you achieve.
2.2 Determine Requirements for Collecting,
Storing, Analyzing, and Maintaining Your Data
After determining the overall goals, results, or outcomes for your data, you should choose a
database management system to collect, store, analyze, and maintain your data. You should
also determine whether you have any specific needs for remote users, Web-based users, secu-
rity requirements, and so on. To choose the most appropriate database management system,
you should first determine your technical requirements. From there, you should gather your
CHAPTER 2
■
DEFINE YOUR DATA36
7516Ch02.qxp 1/5/07 3:04 PM Page 36
other nontechnical organizational needs and requirements to help ensure the best possible
d
atabase design. Doing this can keep you from wasting time and money later on, as you have
a database management system and a database design that is able to handle your require-
ments as you go.
Quick Start
First, gather key folks who are involved in selecting and purchasing your database management
system; designing your database; collecting, entering, and analyzing your data; and making
important decisions based on your data. Second, gather both technical and nontechnical
requirements from these folks to help you select the best database management system and
better design your database.
How To
These key folks, working together as a team, should be prepared to answer the following
questions:
• Who will be using the database? What data entry, data analysis, and decision-making
tasks will they be expected to perform?
• Who will be providing technical support for the database? What data management and
data maintenance tasks will technical support specialists be expected to perform and

how often? What defects with the database will technical support specialists be expected
to fix and how often?
• Can you estimate how many data tables, data fields, data records, and data table rela-
tionships you may be initially creating for the database?
• Can you estimate how many additional data tables, data fields, data records, and data
table relationships you may be creating over time for the database?
• How often will the data be changed? Who will make these changes?
• What is the estimated greatest number of people who may need to access the database
at the same time? In how many remote locations do these people exist?
• Do you need to support data transactions—grouping together related sets of data
record additions, changes, and deletions, and committing or rolling back each of these
tr
ansaction sets as a single data operation? H
o
w often are data transactions expected to
take place, and how many data transactions are expected to occur at the same time?
• How many remote computers may need direct access to this database? How many
remote computers could operate with a snapshot copy of this database? What is the
longest amount of time that could pass befor
e these remote snapshot data copies must
be refreshed with the latest snapshot of the most accurate data?
•
Do y
ou need to import, export, or synchronize data across a wide array of database
management systems
, and if so
, ho
w many and b
y which softwar
e manufacturers?

•
Do y
ou hav
e any special requirements for advanced data backup and restore needs,
and if so, what are those requirements?
CHAPTER 2
■
DEFINE YOUR DATA 37
7516Ch02.qxp 1/5/07 3:04 PM Page 37
• Will data access be offered over an intranet, an extranet, or over the Web? If so, what
l
evels of data access need to be supported?
• Do you have any special security needs, such as controlling who has access to view,
change, and maintain the data? Do you have any ongoing data logging or audit tracking
requirements?
• What computing resources are available? Is there a budget for increasing these resources?
Use the results of this information-gathering session to help you select and purchase your
database management system, and also to help you better design your database.
■
Tip
You can also use the guidance in “Section 1.6: Choose the Right Database Product” in Chapter 1 to
help you select and purchase your database management system.
Try It
The ExcelDB_Ch02_02.doc file in the Source Code/Download section of the Apress web site,
, contains a version of the questions in the preceding “How To” section.
You could use this file in helping you select and purchase your database management system,
and also to help you better design your database.
2.3 Design Your Data
Now you have determined what goals, results, or outcomes you need your data to help you
achieve. You have determined your requirements for collecting, storing, analyzing, and main-

taining your data. You have also selected a database format and a database management
system. Now you are ready to design your data tables, data fields, and, where applicable, your
data table relationships.
Quick Start
I
f y
ou hav
e selected a flat file database format, you can simply begin entering data values and
data records. Similarly, if you have selected a nonrelational database format, you can simply
begin entering data field names, and then enter data values and data records. If you have
selected
a r
elational database for
mat, you should consider additional design considerations,
such as defining primary keys, foreign keys, and data table relationships. For multidimensional
database formats, even more design considerations (such as dimensions, levels, and members)
should be consider
ed.
How To
To design a relational database’s tables, records, and fields, do the following:
CHAPTER 2
■
DEFINE YOUR DATA38
7516Ch02.qxp 1/5/07 3:04 PM Page 38
Step 1: Examine your data to see if you can break it further into its most indivisible parts.
F
or example, consider two record scenarios for real estate property listings. The first
record scenario might contain the following:
•
Property address: 123 Main Street Northwest, Mountain City, Idaho, 88812

• Year house built: 2002
• Property owners: John Doe and Jane Doe, a married couple
• Property assessed value: $225,000 in 2002; $230,000 in 2003; $235,000 in 2004;
$237,000 in 2005; $240,000 in 2006
•
Property parcel number: Lot 921, plat 47, parcel E2, as recorded in the year 2002 on
page 114 of Springsville County Public Records
The second record scenario might contain the following:
•
Property address: 234 Second Street Northwest, Mountain City, Idaho, 88812
• Year house built: 2003
• Property owners: John Q. Public and David Doe
• Property assessed value: $275,000 in 2003; $285,000 in 2004; $299,000 in 2005;
$302,000 in 2006
•
Property parcel number: Lot 919, plat 34, parcel E1, as recorded in the year 2003 on
page 382 of Springsville County Public Records
In these two records, notice the following:
• The property address information could be divided into data fields such as street
address, city, state, and postal code.
• The property owners could be listed by individual name.
• The property assessed value information could be divided into individual year and
value data fields.
• The property parcel numbers could be divided into data fields such as lot, plat,
parcel, year recorded, pages recorded, and volume recorded.
Step 2: Examine your data to see if you can group related information into individual data
tables
. I
n this example
, y

ou could create individual tables for the following:
• Property addresses
•
Years that houses were built on the properties (e.g., if a house is rebuilt on a prop-
erty due to remodeling or disaster)
• Property owners
• Property assessed values
• Property parcel numbers
Step 3: Begin adding data records to individual data tables. The property addresses data
table could be presented with the records shown in Table 2-1.
CHAPTER 2
■
DEFINE YOUR DATA 39
7516Ch02.qxp 1/5/07 3:04 PM Page 39