Database Reference
In-Depth Information
Figure 2.2. How I viewed the general Normalization process
I kept these facts in mind and then posed the following questions.
1.
If we assume that a thoroughly normalized table is properly and efficiently de-
signed, couldn't we identify the specific characteristics of such a table and state
these to be the attributes of an ideal table structure?
2.
Couldn't we then use that ideal table as a model for all tables we create for the
database throughout the design process?
The answer to both questions, of course, is yes, so I began in earnest to develop the basis
for my “new” design methodology. I first compiled distinct sets of guidelines for creating
soundstructures byidentifying the final characteristics ofawell-defined database that
suc-
cessfully
passed the tests of
each
normal form. I then conducted a few tests, using the new
guidelines to create table structures for a new database and to correct flaws in the table
structures of an existing database. These tests went very well, so I decided to apply this
technique to the entire traditional design methodology. I formulated guidelines to address
other issues associated with the traditional design method, such as domains, subtypes, re-
lationships, data integrity, and referential integrity. After I completed the new guidelines, I
performed more tests and found that my methodology worked quite well.
The main advantage of my design methodology is that it removes many aspects of the tra-
ditional design methodology that new database developers find intimidating. For example,
