In order to establish a relationship, you have to have data in one table that represents some sort of interaction or natural link to the data in the other table.
For instance, suppose that you have an inventory database.
One table might be a product transaction table in which you add or remove items from inventory. Another might be the table that describes items that can be in your inventory (regardless of whether any are in stock at the moment.)
A relationship in this example would require that you would have some sort of key in the descriptive table. For example, many places like Home Depot, Lowe's, and WalMart use an SKU code, which is numeric. So the primary key of the descriptive table would be the stock item's SKU number.
In the transaction table, the SKU number is what is called a foreign key. It is used to link to the data in the descriptive table. In this case, the relationship is one (description) to many (transactions). The transaction table records events in which items are added or removed from inventory. Obviously, more than one such event can occur in the lifetime of an inventory. Each transaction identifies the item added or removed through the SKU number. So the relationship between the two tables is based on the field they share in common - the SKU number.
One-to-many relationships are the most common, though one-to-one can occur. You will also find many-to-many, which Access can only implement by defining an intermediate table that has a one-to-many relationship with each of the participating tables that it references. Thus, the intermediate table implements the many-to-many relationship with an extra step.
Defining relationships becomes clearer if you normalize your tables. Normalization is the process of "purifying" your tables according to some rules that have been developed over the years that databases have existed. (Which is not that many years when you come down to it.) In general, normalization involves separation of unrelated or only semi-related data into separate tables.
You would do well to do a web search on the topic of "database normalization." This search phrase will reveal several hundred explanations of normalization. Some of these explanations offer good examples of data relationships. The Access sample MDBs that are shipped with the installation kit also offer some good examples of tables with established relations.
Now, more directly to your problem.
In order for a relationship to be valid in Access, the same data field must occur in both tables. (The two fields don't have to have the same name, though.) In the "one" side of a one-to-many relationship, the selected field MUST be indexed with no duplicates allowed.
Further, for a stringently correct relationship, there must be NO entries in the table on the "many" side of the relationship that do not occur in the table on the "one" side of the relationship. Think of this last principle using the example of a dictionary and a writer. If there is a true relationship between what is written and a dictionary, you will never see a written word that is NOT in the dictionary.
Perhaps your problem in establishing your relationships is that your table on the "one" side of the proposed relationship doesn't provide complete translation? Or isn't unique? By the way, you can still build the relationship if the translation is incomplete, but some data will get left out from some of your queries when you do that.
