Elena, the key to creating a relationship is to understand the implications of declaring one. I don't know your background, but I can offer a couple of thoughts.
First, you must understand normalization. To that end, either search this forum for "Normalization" or search the general web for "Database Normalization" (because normalization also applies to general math, politics, chemistry, and statistics.) Our search option is near the top of the screen, right-hand side, in the bar that also contains your login name. If you go for the general web search, limit what you read at first by only looking at results from .EDU domains, as the .COM sites have something to sell you and will be pushing their own product's proprietary viewpoints.
Once you understand normalization, you perhaps will realize that you are building a "model" of your business data flow. The three kinds of direct relationships supported by Access are one-to-one (or 1:1), one-to-many (or 1:M), and many-to-one (or M:1). The kind of relationship to use in any case will depend on what your business model suggests. (This even includes home users whose purpose is keeping recipes.)
It is exceedingly rare but not impossible to define 1:1 relationships because of what it implies. It is difficult to work with true 1:1 relationships because of Access requirements when working with them. They are unwieldy and usually occur only for special cases.
This leaves 1:M and M:1 relationships. They are the most common practical relationships. Suppose you had an invoice table and a (single) table of line items associated with each invoice, differentiated by invoice number. Your invoice:line-item table would be 1:M, one invoice to many line items. Suppose you had machinery that per your business rules could only be in one of several states. You might have a table of allowed states, in which case there would be a status code in the machinery table and each different machine would point to a single current state, or 1:M.
One minor difference between 1:M and M:1 is that it is more likely to have 0 matching records for a 1:M case without that being a structural flaw. In most M:1 cases, having no matching record on the "1" side of M:1 cases usually means you forgot something.
There is such a thing as many-to-many relationships, or M:M. For example, at a school, a student goes from class to class and each class has a different teacher. One teacher has many class sessions each day with different students in each. So this would be an M:M relationship, many students and many teachers, with multiple contacts either way. This would require what we call a junction table, which is another topic you can look up.
This is a lot for folks to digest. Take your time and look at my reading list, which includes keywords for searching: In order "database normalization" and "data relationships" and "junction table."