How to Design a Database

Part One of a Six-Part Series on Access Databases for Accountants

By Roberta Ann Jones, Digital Springs, Inc.

(April 5, 1999) - Developing a database for information storage and retrieval is not
appropriate for all situations. Poorly designed databases can create more problems
than they solve. Learning when to use databases, and how to design efficient
databases, is essential for successful system implementation.

Database Use by Accountants

A database is a storage facility for data related to a particular application or purpose.
A relational database consists of two or more tables of data. Each table is composed
of two or more rows of data, each row is composed of two or more columns of data.
Each table contains data about one particular subject. Each row constitutes one
record in the database. Each column represents one type, or field, of data.

Database programs, such as Access 97, provide a relatively painless means of

building unique databases and retrieving information from those databases.

Uniquely developed databases can be used to supply an entire accounting system for
a firm. More likely, however, in today's environment, the database will be developed
to supplement purchased software (known as canned software) or a legacy (a.k.a.,
existing) system. Supplemental databases can provide a custom fit for accounting
software, client time and billing software, project management software and more.
Supplemental databases may also allow a firm to extend the useful life of their
existing system by providing faster and more complete information retrieval than the
existing system allows.

Because accounting applications are very similar from one firm to another within the
same industry (and even across industries for basic general ledger work) there are
already canned, or off-the-shelf programs available for every size firm in virtually
every industry. These packages already utilize databases as their primary means of
data storage.

Examples of these canned programs are Peachtree, Solomon and SAP. For the
majority of applications, one of these canned programs is apt to adequately address
a system's requirements. For an application that requires something more, a
database can be built that supplements the canned programs either as a stand alone
database or an integrated part of the canned program.

A uniquely developed database should not, therefore, be a first response to an

information problem. Developing a new database from "scratch" will be time-
consuming and usually expensive. It may take a consultant several months to design
and develop a database that duplicates the capabilities of Peachtree, for example. It
is not cost effective to invest this time and money when an adequate canned
package already exists.

Before a decision is made to develop a unique database for a firm, a thorough search
of the available software is indicated. A database should be developed only after it
has been ascertained that no canned package exists that will solve a particular
system implementation. Software and magazines exist to aid the accountant in
identifying these packages. Information on most packages is also available on the
Internet or from value-added retailers.
 A database should be developed only after it has been
ascertained that no canned package exists that will solve a
particular system implementation.

Database Design
Efficient databases take up less storage room and provide easier information retrieval
than inefficient databases. It is entirely possible to design a database that will not
allow retrieval of the information desired. Attempting to fix problems after the fact
may be difficult. For example, changing a field's data type after data is entered into a
table may cause data loss and/or necessitate time-consuming data conversion.
Budgeting some planning time at the beginning of a database project can save time,
money and frustration at the end of a project.
An efficient database should have four qualities.

Low data redundancy or duplication. To the greatest extent possible data

should not be stored in more than one table. When each piece of information
is stored in only one table, updates happen in only one place. This helps
ensure the integrity of the database. The exceptions are fields used as
primary and foreign keys. Primary keys are fields that are unique to each
record. Social security numbers can be used as primary keys, for instance. A
foreign key is a field in a table that is a primary key in another table. Foreign
keys may duplicate primary keys in good database design.

Integrity. This refers to the accuracy and completeness of the database. This
is akin to the "all and only all" concept of financial accounting. It is this
particular quality that makes accountants a natural choice for designing
databases. Accountants are already trained and experienced in evaluating the
integrity of information.

Independence. Dependence of the data among tables and/or records can

create problems with data integrity and data retrieval. Many of the problems
anticipated when the year 2,000 arrives are the result of data dependency on
the system date.

Integration. This refers to the ability to pull data from different tables
together for one purpose. Access 97 is designed to make integration easy and
natural. Even so, care must be taken in setting primary and foreign keys in
order to ensure proper integration.
Certain key procedures have been developed to help achieve quality database
design. The most important procedure in developing an efficient database is to
adequately plan the database before touching the computer keyboard.
During the planning stage the purpose of the database should be determined and
clearly stated. From the purpose will follow what information is required from the
database. The system outputs and the contents of those outputs can then be
identified. Mock-ups of the required outputs, such as reports and documents, can
prove very helpful in identifying the exact content required.

This is the time to determine if the reports and documents currently in use are
necessarily the reports and documents that should be in use. Take this opportunity to
revise and update all reports and forms related to the database. Rather than
maintaining the status quo, try to determine if there are better methods or different
information that will better help the firm achieve its objectives. Mock-up forms and
reports will later be reproduced using Access 97.

Talk to potential users of the database to learn their expectations regarding output.
User involvement serves at least two purposes. First, users may be able to provide
mockup reports and the current forms used to record data. Secondly, user
involvement at the beginning of the project can lead to user acceptance at the end of
the project. Without user acceptance the project is doomed to ultimate failure.

The most important procedure in

developing an efficient database is to
adequately plan the database before
touching the computer keyboard.

Once the outputs and the output elements have been established, then the database
tables can be designed. First, determine the tables that will be needed and which
fields will be needed in each table. This may be an iterative process. Field content
may affect table design and table design will certainly affect field content. Sketch and
rework tables on paper first. Recall the fundamental principle that a table should not
contain duplicate information. Except for primary and foreign keys, information
should not be duplicated among the tables and each table should contain information
about only one subject.
Relate each field directly to the subject of the table. There is no need to create fields
for derived or calculated data; this is a waste of storage space. Include all the
necessary data in its smallest logical parts. For example, use two fields for first and
last name rather than one field for an entire name. Identify fields with unique values
that can be used as primary keys and therefore used to uniquely identify a specific
row in a table.

As the tables are being established determine the relationships among the tables.
Every foreign key must either be null or have a value corresponding to the value of a
primary key in another table. Unless these relationships are specifically established in
Access 97 data from more than one table cannot be combined into a single report or
query.

Refine the table design before entering the data. It is much easier to make changes
before data is entered. Be sure that each column in a table represents a
characteristic of the record identified by the primary key. Each column in any row
must hold only a single value. The values in every row of a specific column must be
of the same data type. Be careful to choose the correct data type. For instance, zip
codes work best as text data rather than as numerical data because numerical data
will not store leading zeros. Finally, be certain that neither column order nor row
order is significant.

Only after the above has been accomplished should the database designer begin to
use Access 97 to build the database. After the tables have been built in Access 97
and some test data has been entered, Access 97 analysis tools may be used as a
final check on the table design. The table analyzer wizard can analyze the design one
table at a time and propose new table structures and relationships. The table
analyzer wizard can also restructure a table into new related tables.

The Access 97 performance analyzer can make suggestions for improving the entire
database after the forms and reports are built. Forms, reports and queries should
follow naturally from the mock-ups used to identify the table contents.

Source: 1999, Digital Springs, Inc. All Rights Reserved. Reprinted with
permission.