When designing tables in a database, we need to ensure that the tables are normalized.
Normalization:
There are rules that govern these forms and in this unit we will consider the rules starting from unnormalized (0NF) all the way to third normal form, 3NF.
The following series of videos is intended to help introduce these concepts. For each video, complete the related worksheet.
We have covered the importance of normalizing a database. It reduces data redundancy, decreases the opportunity for update/delete anomolies and improves data integrity generally.
In short, it will result in a reliable database.
But surely a denormalized database must have some advantages...
| Advantage | Description |
|---|---|
| Queries are simpler | Without joins to consider, queries are simpler to design |
| Queries are faster | Queries can be executed on one table, rather than navigating joins, making query-execution faster. |
| Less processing | Because joins are not needed (or reduced), less processing power is required |
Of course, in a denormalized database, there is a risk of:
However, in scenarios where a fast read is required, a denormalized database can out-perform a normalized database.
So when choose to normalize a database or leave it denormalized, the benefits will have to be weighed up against the drawbacks.
Normalizing a database reduces data redundancy. Data redundancy is where the same data is stored in multiple places in a database.
When updates occur, they have to update all of the data in all of the locations correctly.
Update anomolies refer to updates that don't do this, leading to inconsistent data.
Data redundancy also requires more storage space.
Data redundancy may, however, be intentional ie the database is storing a backup of the data.