I recommend reading up on Normal Forms, which are linked to from Database Normalization, as that ought to give you a good idea about what a primary key is. Their purpose is to ensure a good database design. Each higher normal form up to 4NF includes all of the conditions for the lower ones. Generally, you should stick with 4NF, unless you have a good reason not to.
While you might as well read up on 5NF there is rarely a need to deal with it.
The purpose of the primary key is to (uniquely) identify all the other data in the row, but it does not have to be a single column. It might just as well be multi column.
A primary key is equivalent to an index with a uniqueness constraint, although I don't remember if the SQL standard demands that standard compliant databases must index the primary key, or if it's implementation dependent.
When you say ID field, I assume you are talking about an integer field, but it does not have to be. If you have a table holding information about users allowed to login someplace, you could for example use their usernames as primary key.
But, even in the above case it can be convenient to use an integer field whose sole purpose is to be the primary key. It does add a few bytes of extra data storage, but that is rarely a big deal with the current storage available. And if you set that field as auto increment, you won't have to find out and keep track of what ids are not used, since the database automatically provide a new unique integer on each new insert (usually one higher than the last insert).
If it's not set as auto increment, and assuming more than one user might query the database at the same time, you would need a transaction safe database, and start a transaction, check for the highest id presently used (or somehow find out where the first "gap" is form a previous delete), then use that value when inserting, and finally ending the transaction.
If the above conditions are not met, then the following could happen:
User A: checks for unused id, which e.g. is 10
User B: checks for unused id, 10
User A inserts with value of 10
User B: inserts with value of 10 - error. primary key has to be unique.
And as a sidenote, I did a quick check on those wikipedia pages, and while I've been told that the the things they taught me at the Uni several years ago about atomicity of values as a requirement for 1NF has since changed, the first table on the page on DKNF still seems unacceptable to me. The reason is that the half of the center column is dependent only on the first column, while the other half is only dependent on the last column. Would be interesting to get some feedback on that matter.
But, apart from that, since the example table used is still not in 3NF I find it to be a rather lousy example. And since I've never read about (or at least don't remember) DKNF before today, I'd be happy if someone could give me an example of a relation in 4NF that breaks DKNF.
