Here's an exerpt from a posting by Pat Hartman (one of the parts of the book she is or was writing). Since the thread has so many posts, I felt it would serve you better to just post the part that was applicable instead of making you wade through it. However, that being said, here is the link, in case you do:
http://www.access-programmers.co.uk/forums/showthread.php?s=&threadid=8864&perpage=15&pagenumber=7
FROM PAT HARTMAN:
Here's a little on Normalization. Comments welcome. You may send them to my email.
Data Normalization
Normalizing a database is considered by most people to be more art than science. Some people will need to work harder to understand the concepts and to help you, I’ll include several detailed examples of common business objects. Understanding why you need to normalize your data structures is imperative.
The actual process of normalization is iterative. There are three basic forms that are described in more detail later in this section plus two more advanced forms that are beyond the scope of this book. Once you have gathered your requirements and documented your business rules, you need to gather into logical groupings all the data items that your analysis has uncovered.
Normalization is the process of removing unwanted functional dependencies from your application’s entities (tables). A functional dependency is implied if the value of an attribute can be determined by simply knowing the value of another attribute. For example, if we know a student’s Student Id, we can determine his name and address; therefore there is a functional dependency between a Student Id and the student’s informational attributes.
First Normal Form (1NF)
Eliminate repeating groups and separate all non-atomic attributes.
Repeating groups are sets of fields that frequently include some attribute of data as part of their field names. Obvious ones are attributes such as JanPayment, FebPayment, MarPayment, … DecPayment. Notice how the word “Payment” repeats. Each time it repeats it is prefixed with a piece of data. In this example the piece of data is the month in which the payment was made. Sometimes numeric suffixes such as Contact1 and Contact2 will be used. This is also a repeating group. In this case the suffix isn’t really data related to the contact; it simply provides a way of assigning a unique name to the individual items of a repeating group.
The most difficult type of repeating group to identify is one where no part of the name repeats. An example of this would be a group of fields that are used to hold different amounts related to a rental property. The field names might be; Insurance, LawnMaintenance, Electricity, Water, Sewage, etc. If you think about the purpose of these attributes, you will see that they are all types of expenses and if you wanted, you could add a common suffix such as “Expense” and the fact that these attributes form a repeating group will become apparent.
The creation of repeating groups is one of the most common mistakes made by people designing their first database. It looks like it should be so much easier to just make a bunch of fields to hold these various attributes than to define a separate table to hold them. The problems only start to surface later on in the development phase when the user discovers additional members of the repeating groups and realizes that the tables, forms, reports, and queries all need to be changed to add new expense types or additional contacts or perhaps a second year’s worth of payments. Sometimes the problems show up when certain types of calculations or analytical reports need to be created. We’ll talk more about these problems later when we get to working with the examples.
Non-atomic fields are another common problem area. Many systems are originally designed to use a single field to hold multiple pieces of information such as one field that holds first, middle, and last names. Why create individual fields when the user says he doesn’t need them? The answer is that users do not, nor should they be expected to understand the processing that needs to go on behind the scenes. If you need to sort the non-atomic name field by surname, you’ll need to write VBA code to separate the surname from the rest of the parts of a name. Or you may need to separate the name parts because there is a new requirement to send letters and you want to address them properly - Dear Mr. Jones. The code to separate the parts can be quite complex and will probably not perform the separation accurately in all cases.
Sometimes non-atomic fields evolve over time. Your sales department now wants to track the job titles for your customers. Rather than add a new column to the table you (or they) decide to just add the job title to the name field so that now it looks like “Mary Jane Smith President”. That just complicates your parsing routine even more.
_______________________________________
So, there's a starting point for you.
