Primary vs foreign keys are tricky.

When I lived in the England, the UK government kept my US Social Security number in their database. It was a "foreign" key to them, that is, a key into the US IRS database, which they could use to check up on my US tax record if they ever needed to. With respect to question 2:

    - That number had to match up with a primary key value in the IRS database. That way, they knew that my IRS record existed, that they could access it, and that it was unique.
    - It couldn't have been the primary key in their database because most UK citizens didn't have a US SSN, and a primary key can't be null.
    - It could, of course, be NULL in the UK database; most UK citizens have no IRS SSN, so their entries would be necessarily NULL. 

--------------------
There are guidelines on how to structure database schemata; they're part of what's called database "normalization". It's a big subject. We'll cover some of the most basic stuff in unit 9 (relational databases).

Mostly, I'd say that tables ought to information on single "entities", which is why we separated the table with annual demographic data for countries from the table that keeps the detailed information on the countries themselves - that way we don't have to repeat the country details for every year of the demographic data.