Difference between one-to-many and many-to-one relationship

Question

What is the real difference between one-to-many and many-to-one relationship? It is only reversed, kind of?

I can\'t find any \'good-and-easy-to-understand\' tutoria

Answer 1

Example

Two tables with one relation

SQL

In SQL, there is only one kind of relationship, it is called a Reference. (Your front end may do helpful or confusing things [such as in some of the Answers], but that is a different story.)

• A Foreign Key in one table (the referencing table)
  References
  a Primary Key in another table (the referenced table)

• In SQL terms, Bar references Foo
  Not the other way around

  CREATE TABLE Foo (
      Foo   CHAR(10)  NOT NULL, -- primary key
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK             -- constraint name
          PRIMARY KEY (Foo)     -- pk
      )  
  CREATE TABLE Bar (
      Bar   CHAR(10)  NOT NULL, -- primary key
      Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK                -- constraint name
          PRIMARY KEY (Bar),       -- pk
      CONSTRAINT Foo_HasMany_Bars  -- constraint name
          FOREIGN KEY   (Foo)      -- fk in (this) referencing table
          REFERENCES Foo(Foo)      -- pk in referenced table
      )
  

• Since Foo.Foo is a Primary Key, it is unique, there is only one row for any given value of Foo

• Since Bar.Foo is a Reference, a Foreign Key, and there is no unique index on it, there can be many rows for any given value of Foo
• Therefore the relation Foo::Bar is one-to-many
• Now you can perceive (look at) the relation the other way around, Bar::Foo is many-to-one
  • But do not let that confuse you: for any one Bar row, there is just one Foo row that it References
• In SQL, that is all we have. That is all that is necessary.

What is the real difference between one to many and many to one relationship?

There is only one relation, therefore there is no difference. Perception (from one "end" or the other "end") or reading it backwards, does not change the relation.

Cardinality

Cardinality is declared first in the data model, which means Logical and Physical (the intent), and then in the implementation (the intent realised).

Cardinality

One to zero-to-many
In SQL that (the above) is all that is required.

One to one-to-many
You need a Transaction to enforce the one in the Referencing table.

One to zero-to-one
You need in Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

One to one
You need a Transaction to enforce the one in the Referencing table.

Many to many
There is no such thing at the Physical level (recall, there is only one type of relation in SQL).

At the early Logical levels during the modelling exercise, it is convenient to draw such a relation. Before the model gets close to implementation, it had better be elevated to using only things that can exist. Such a relation is resolved by implementing an Associative Table.

Many-to-many Resolved