While analyzing our database design, we had to consider the level of normalization we wanted to achieve in our database. When comparing the three main levels of normalization with the goals we hoped to achieve, we determined that we only needed a relational database in First Normal Form in order to achieve our objectives.
Any relational table is at least in first normal form, by definition. After the initial design, we looked back and noticed that many of the fields in the database contained repeated information, such as information about event contacts. We decided, however, that when taking into consideration the level of usage this database will receive and also the skills and demands of the users, requiring all information about the contacts to be in and only in the CONTACT table would be overkill. The performance capabilities of this database will not be hindered by a few repeated fields between tables. This makes the design easier for us to implement and easier for someone in the organization to understand.
We also were concerned that information might be different between the contact information in the EVENT table and the correlating information in the CONTACT table. We took this into consideration but decided that differences will be negligible because the contact may want to be contacted directly when referring to a specific event but might want to have a separate set of contact information for general contact purposes.
Moving this database into Second Normal Form would require restructuring of the database and the UI and would make the application more complicated than needed or desired.
|
| Page Execution took real: 3.705, user: 3.230, sys: 0.120 seconds |