There are two main kinds of database:
1. Simple lists that could have been done using Excel but Access was handy and has nicer reports.
2. Your business is complex enough that you need a database to track what it does.
In case 2, the database will become a model of your business. Relationships in your database reflect real-world relationships in whatever business model you are building with that database.
So suppose you buy widgets from Acme Widgets and sprockets from Spacely Sprockets. You will have an inventory table that shows widgets and sprockets (among other things). You will have a supplier table that shows Acme Widgets and Spacely Sprockets (among other suppliers). And you will have fields or junction tables that show what you get from which supplier. The latter sentence describes a "relationship."
The relationship itself is embodied in a pair of fields that must contain the same information (and preferably be short). The relationship is expressed via a syntactical thing called a JOIN where the two tables are named and joined across the field that they have in common. Then the database engine, having the description of that relationship, associates records where the corresponding fields have identical values. That is the mechanical part of the relationship. All you have to do is
1. Assure that your design includes such fields as the embodiment / supporting data for each required relationship. (You can re-use fields if two different tables are related in similar ways to the same common table.)
2. Assure that you keep those fields "pure" i.e. never put anything in those fields that doesn't correspond to the relationship. I.e. no rogue records.
To do this right, you should also Google-search "Normalization" and pick any articles you like from reputable college sources. Without a filter, you might get, oh, a couple of gazillion hits on normalization. If you filter on .EDU sites, that will limit your response.
