Perhaps you could tell us a little of your database plans and the business it will support.
Suppose you were an Import/Export company (hypothetical for concept only).
Let's say you have import Products from some Countries and export the Product to other Countries.
In other words a Product has a CountryOfOrigin and CountryOfDestination. Let's use the ISOCountryCode to represent Countries.
So you could have tables:
Code:
tblISOCountry
ISOCountryCode PK
ISOCountryName
tblProduct
ProductID PK
ProductDesc
OtherProductInfo
The Country table could be a reference lookup table
ProductID 0010
ProductName Pickled Herring
ISOCountryCode
alpha2 DK
alpha3 DNK
num3 208
Countryname Denmark
..
..
alpha2 BG
alpha3 BGR
num3 100
CountryName Bulgaria
...
Origins Destinations
tblISOCountry tblProduct tblISOCountry
+ ProductID 0010
+-------------------------> CountryOfOrigin 208
CountryOfDestination 100 <---------------+
to represent the import of Pickled Herring from Denmark and export to Bulgaria.
The ISOCountry table is used as a Country reference/lookup table. In a data model the table may be identified several times since it is a "lookup/reference" to a value that has meaning to you and your database. In this example Origin and Destination values come from the same reference table. You could have the Table identified many times if you were identifying different countries/ports or waypoints on a shipping itinerary.
I often build a data model (Erwin/Toad..). It acts as analysis and design document and can be part of the plan for the database. It can be a blueprint for your design. It can be used for training and development. As part of a planning document it is a reference to any who have to work with the database or modify the database or make decisions on whether or not to proceed with the database/application. You can use the relationships window to build the model, but you can build a model with pencil and paper (preferred -since it keeps you from jumping into a solution(physical database) before you have done the analysis and design). Too many people jump into physical database and end up with un-normalized structures and a myriad of issues/problems mostly stemming from an untested model. Relationships can be used to enforce referential integrity (but beware of split databases -relationships in front end don't affect back end). You can create joins in query window.
Good luck with your project.