Hello, Danjo. You actually omitted one relationship. You have one-to-many, but there is also a many-to-one. Those two are similar but still different. One way to understand relationships is to imagine the real-world ways in which you would use them, i.e. the "practical" approach.
Let's do Many to Many first. You would use this in, say, an emergency clinic with many people coming in to see whichever doctor is available. I.e. it is not a formal practice with established doctor/patient relationships. It's walk-in only. Each visit would then link a doctor to a patient but over time, many patients would see one doctor and many doctors might see one patient. This visit would then be expressed by a many/many table between doctors and patients. The visit would be embodied in a junction table that points to one doctor and one patient and would include a date and a sequence number that could be used by a separate one-many table to show one visit, many symptoms.
Let's do a One to One next. This is actually very rare because it implies that both tables use the same primary key to represent the same thing. The rules of normalization would tell you to combine those tables. However, there are a FEW cases where 1/1 makes sense. When I was with the U.S. Navy as a contractor, we had a database where we had lots of personnel data, but security (classified) and privacy regulations applied to some parts (primarily medical info) of the data. So we had a general personnel table. Then we had a separate table for the secure data and a separate table for the private data. The tables had different permissions on them but we related the general table to the other tables using 1/1 linkages. You could not access the secure or private data unless you had appropriate permissions and THAT worked because of the separate tables.
Now there is one/many and many/one. You use them both for similar but not identical purposes. Let's do one-many first. Suppose you have a sales store that works by an invoicing system. The invoice becomes the document that will be the customer's receipt. On it you list each item the customer purchased. So in this one/many case, the invoice table is the one-side and the list of things purchased by the customer is is the many-side.
Suppose this store has a service department and an appliance comes in needing repair. Each appliance might be in a different state. So on the appliance ticket, the state might be "Awaiting its turn" or "Awaiting parts" or "In work" or "Awaiting pickup" or "Broke so bad God couldn't fix it." The status-code table would be referred to by each repair ticket pointing to one status. This is the many-one case - many appliances but each has only one status at the time.
