Datasheet

Designing Applications

❑ What type of network will connect the computers? Will lack of available bandwidth

prove a problem?

❑ What security policy will the application need to operate?

❑ What type of fault tolerance or recovery issues will need to be considered?

The purpose of the technical analysis should be to produce an application architecture and

implementation framework within which the resultant application will nestle. Again, it may

well turn out that developers are not the best people to undertake this type of analysis.

Technical analysis requires a good understanding of networking, security, and technical issues

and these skills may not be present in all of your developers.

Data Analysis

By this stage, you should have a contract in place that defines what the application is meant to

provide and you will probably have a good idea of the technical infrastructure within which

the design will be implemented. The next stage is to analyze the data that you will be working

with. Now, I must confess that I frequently find this task less than stimulating, but I know that

it is imperative if I am to achieve a sound database design. As tedious as data analysis is, it sure

beats the pants off rewriting an application because a fundamental misunderstanding of the

underlying data only comes to light two weeks before the project is due to be delivered.

Now this is not a primer on data analysis. Although simple enough in theory, data analysis can

be quite complex in practice and if you are new to the subject, you would do well to get some

specialized training in this discipline.

One term you are likely to come across again and again is normalization. This is a formal

technique for the elimination of dependencies in our data. This, in turn, realizes the twin

benefits of reducing redundancy and minimizing opportunities for inconsistency being

introduced into our data. Some of the principles of normalization are intuitive and you

probably already follow them (like trying not to store a company's address twice in two

different tables), but it can take a high degree of skill and substantial experience to know when

and how to apply some of the more detailed rules, and gains can be elusive. Because of this we

will not attempt to cover the subject here. In any case, for smaller projects, formal

normalization is rarely useful.

If you are likely to be doing a lot of data analysis or are simply interested in the subject

then one of the most authoritative discussions of the theory of normalization can be found

in 'An Introduction to Database Systems' by CJ Date (Addison-Wesley, 1995, ISBN 0-

201-54329-X). A less theoretical (and thus much more accessible) approach can be found

in Database Design for Mere Mortals: A Hands-On Guide to Database Design by Michael

J. Hernandez (Addison-Wesley, 1997, ISBN 0-201-69471-9) and Professional SQL Server

2000 Database Design by Louis Davidson (Wrox Press, 2001, 1-861004-76-1).