Normalisation is the process of distributing data in such a manner that it is not generally repeated.
For instance, if you have a table called "Employees", which stores employee data, and a table called "Departments", which stores data for departments into which each employee falls, you would not, in a normalised structure store the Department name in each employee record.
If we had three Departments, called "Sales", "Finance" and "Human Resources", and each employee in the Employee table had to belong to one department, it would be a waste of disk space to store the word "Sales" etc. in each employee record to designate which department they belonged to. "But", I hear you cry, "disk space is no longer the same issue it used to be in the early days when relational databases were first created!" Entirely correct, and although the original thinking around normalisation was centred around disk utilisation (for it was a most precious resource in them thar days) it quickly showed itself to be a logical methodology for maintaining a data state that was both compatible to human and computer processes.
Say, for example, in the Departments table, you have a department called "Sales", and you have 1000 employees in the Employees table linked to that department. If you link each employee to the department name, and then decide to change the name of the department to "Super Sales", you will have to go through 1000 records and change the name of the department in each one. But, if you have a department called "Sales", that is linked to 1000 employee records through a department_id called "1", you can easily change the department name to "Super Sales", and all queries drawing back employee information for that department will automatically register the department name as "Super Sales".
There are various levels of normalisation, with Third Normal Form being the one most database folks try to obtain, and anything beyond that a dream. However, normalisation has its own problems. If, for instance you have 10 million records in a system from which you need to obtain data trends (data mining) or statistical reports, normalisation becomes a burden, because the linking of various tables to other tables in any SQL query is a time-related and performance issue. In heavy reporting and data-mining applications it is the usual practice to 'de-normalise' the data; that is, putting the department name back into a cross-reference table that includes the employee data and department data, to obtain the benefit of speed within the query process.
If you're confused, don't worry, so is every other database 'newbie'. Database modelling and design is an intuitive process. When you become skilled at it you just "know" what is the right thing to do. One common mistake of new database modellers is to normalise things to hell and gone just because the theory says they should.
Forget the theory. Use the Force.