NewfieSarah said:
Okay Define "Normalised"
"Breaking the rules" ? What rules would that be?
Normalisation: The process of
efficiently organising data in a database.
First Normal Form: Each row by column entity should be atomic, meaning that for each cell of the database only one item of data should be present. Therefore, you shouldn't store - in an inventory example -
5 red widgets, 2 blue, and a green one as one piece of data. These should be broken out to three fields:
Item, Quantity, Colour. The problem by not adhering is that you can't summarise data efficiently.
Second Normal Form: Remove subsets of data by creating new tables to demonstrate entities and create the relevant relationships between. Therefore, with this, it notes that you should not have repeating groups (two ways: i.e. Course1, Course2, Course3, Course
N or, with quanitites,
Apples, Oranges, Pears. These are data subsets and should be broken out from the table they appear in to a new table, called tblCourses or tblFruits in this respect. The problem here is that you require ongoing editing (queries, forms, reports, macros, VBA) everytime you would want to add to the subset. This causes the database to grow wide (fields) when a database should grow down (rows).
Third Normal Form: That you should have no fields dependent upon another non-key field. This applies to calculations. You would not, for example, have three fields called Quantity, Price, and Total in your Orders table. The Total field is dependent on the values in Quantity and Price fields and so you can eliminate the Total field and, when you need totals, you can calculate it with a query or on a form/report. The problem here is that you would require extra updating or could report improperly based on bad data should you update the Price and neglect to change the Total. Reaching 3NF means you're calculations will never be incorrect.
You can't reach 2NF without first attaining 1NF; and you can't reach 3NF without first ensuring 2NF.
Why do you say ST McAbney that if I continue down this road that I will have to spend more time on my database??
Because, based on your explanations, you are stalling at 2NF since you are duplicating data over and over again when what you need is one table to store the PIN details (rather than duplicate them) and one table for the other information. In the latter table you would just include the Primary Key to the PIN table and ,
hey presto!, a one-to-many relationship.
If you haven't taken the query advice then I get the impression you are binding tables to your forms.
Always use queries for this! Queries can select the relevant data, aggregate it, sort it, and perform calculations. Tables just provide dumps of data. The other reason is that, the more your database grows when the forms you use are bound to a table, the slower you're database will become.