It would be greatly in your best interest to take a tutorial right now. Seriously, stop whatever you're doing and take a basic access tutorial. If you don't understand the concept of a primary key, I garauntee you're going to shoot yourself in the foot if you try to develop anything. It's not a bad thing if you don't know, I'm not trying to rip on you, but you NEED to learn about it right now. NOW.
PS: Did I mention you should do this right at this moment?
I agree with Teddy, you should understand some basic Relational Database ideas before you begin developing a database. But I will give you an example of a primary key.
A primary key is a field or fields in a table that uniquely identifies a row in the table. So for example, if you wanted a table with every American's name and address in it you would need to be able to identify a particular row (or person). An ideal primary key for your table would be the Social Security number. Everyone has a unique number that identifies him or her. If you have two people with the same number then you would have many problems.
An example of a compound primary key (where more than one field is used to uniquely identify a row) might be if you were creating a table that listed all your available font sizes. If you have fonts Arial, Times New Roman, and Tahoma for example, and the font sizes are 12, 13 and 14, the primary key would be the font name and the size. Since you will have a table looking like:
If you choose the font name as a primary key, you see there are three rows with each name. If you choose the size, the same problem exists. But, if you choose the combination of the two columns, you have a unique primary key.