3.2 Problems with flat databases
As a database, Table 1 is messy and inefficient, and does not really qualify as a properly constructed database. For instance, what happens if someone signs up to do four evening classes? To allow for this possibility we could incorporate further fields, such as Course4, Course5 and so on. But how many more fields should there be? If we choose an extravagant number, such as 20, we could be confident that no student would exceed that number of courses in a year, but the table would be wasteful as much of its content would be empty. (Even empty fields occupy space, because information about the structuring of the data must be stored whether the fields are empty or not.)
Another problem with Table 1 is the repetition of some items of data. For instance, the fact that 'Oil painting' has 15 sessions is recorded in three places in the table. A principle of good database design is to avoid repeated data such as this. When the same data is recorded in several places, there is always a possibility of clerical errors leading to inconsistency. What is more, changing the data or correcting errors means finding every repetition of that data in the table and changing it or correcting it. For instance, if the teacher on the Oil Painting course decided to add a few extra sessions, incorporating this amendment in Table 1 would mean updating several records. Ideally information about the number of sessions in a course would be recorded in just one place.