For example, youmay have one, two, or three contact names to be placed
in their own table, with a foreign key linking back to the main row for the organization.
But because you want to see all the contact names every time you request contact information,
youmight decide to save the overhead and added development effort of the
join and simply include the three contact names in your organization table. This technique
is common in decision-support/data warehousing applications.
Of course, this violation of the rules of normalization limits the flexibility of your application
systems??”for example, if youlater decide that youneed four contact names,
some modification of every application and report that uses the contact names will be
necessary. Normalization leads to a more flexible design, which is a good thing in the
constantly changing world we live in.
For this reason, we suggest that you always implement a fully normalized database
design and then, if necessary, go back and denormalize certain tables as needed. With
this approach, youwill at least have to make a conscious decision to ???break??? the normalization,
which involves an active consideration of the price of denormalization.
Pages:
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248