scope of this book. A really good book that takes you through the entire process is Database Design for
Mere Mortals: A Hands-On Guide to Relational Database Design by Michael J. Hernandez (published
by Addison Wesley).It is essential that you understand this process fully. From this process, you will gain an understanding
of all the objects that are involved. This builds the foundation of your database.Defining the Business Objects
The next step in the design process is defining the business objects. The business objects are the
components that make up the business process. From the previous example, the book and customer would
be business objects. The business objects contain the information you want to track in your database. This is
really a two-part process; The first part is to identify the object, and the second part is to create fields that
describe this object.
Note A business object is a component of the business process. It is one of the cogs
that makes the wheels of business turn.
These objects are usually easy to identify. Most of the time, these components contain the key
information that drives the business. Sometimes they are not so easy to see. In the previous example,
you could easily point out the book and the customer as definite business objects. But what about the
transaction that occurs when a customer actually buys the book? The transaction contains vital
information but is not easily recognized as an object. This is why a thorough understanding of the
business process is necessary to build a good database.The second part of this step is creating fields or adjectives that describe the object. Think of the things
that are used or are associated with the business object. Continuing with the example, your book object
could easily consist of a Title, Publisher, Author, Price, Quantity, and Copyright Date field. The
Transaction object might contain a Transaction Date, Amount, Description, and Payment Method.
These fields further define your object. They also happen to be the fields you want to track in your
database. I find it helpful to write down all the adjectives that describe the object. Later, I eliminate
unnecessary ones or add new ones that I might have missed earlier.Defining the business objects is really the start of building your database. Later, these objects will
become tables in your database, and the descriptions will become the fields in your table.Defining the Business Rules
The third step in the design process is to establish the business rules. A business rule is a statement or
series of statements that governs the way a business is run. From the previous example, a sample business
rule would be "There are no negative transactions." Obviously, there could be (refunds, for example), but the
person running this business might decide that this would be a rule. Another example would be "Every time
an order has met the processing requirements, a shipment should occur." This type of rule helps establish
the relationships that need to exist between business objects.
There are two types of rules, the established rule (a rule imposed by the business) and the implied rule
(a rule that is based on common sense). For instance, using the example, an established rule would be
that a customer can have more than one order. An implied rule would be that every book must have a
title. This may seem silly or foolish, but it plays a major role in determining what data types to use for
your fields and whether or not a field can be empty.
Note The established rule is defined by the business. An implied rule is a rule that may
not be defined by the business but is usually defined by common sense.
The best tools to use for this step are a pencil and paper. Write down every rule—whether you think it is
silly or not. Have a person that is close to the process help you determine the rules. They will likely give
you an insight to the rules that you may not see. Later, this list you have created will save you a ton of
time during the actual creation process and will help prepare you for the next stage.Modeling the Database
The next stage of the design process is sketching out your schema. This may seem like a waste of time at
first, but I have found that things make a lot more sense when you can see them laid out in front you. I
cannot count the times I have found design flaws just by doing something as simple as sketching it out.