Denk dir bei den Beziehungen immer beide wege einmal aus. Das linke nimmst du immer als eins. Danach bildest du sätze so wie unten und nimmst nur den rechten teil. Dann hast du deine nötige beziehung.

Also wenn du Foto und Album hast dann.
1) Foto -> Album (Ein Foto hat...
2) Album -> Foto (Ein Album hat...

Erstes Beispiel:
Ein Foto kann in mehreren Alben vorkommen (1:n)
Ein Album kann mehrere Fotos haben (1:n)

Daraus resultiert dann eine (n:m) beziehung


Zweites Beispiel:
Ein Foto kann in einem Album vorkommen (1:1)
Ein Album kann mehrere Fotos haben (1:n)

Daraus resultiert dann eine (1:n) beziehung


Drittes Beispiel:
Ein Foto kann in einem Album vorkommen (1:1)
Ein Album kann ein Foto haben (1:1)

Daraus resultiert dann eine (1:1) beziehung.


Ansonsten ein anderer Ansatz ist es nach objekten zu denken. Du hast einmal ein Album mit Attributen und einmal hast du ein Foto mit Attributen. Beides sind unterschiedliche Objekte können also schon keine 1:1 beziehung haben. Bzw je nachdem was du tust kannst du es schon machen. Wenn du aber irgendwann mal erweiterst wirst du dir wahrscheinlich dann ins knie schießen. Oder die SQL abfragen werden unnötig kompliziert.

Und eigentlich solltest du den Schritt schon davor getan haben, den dadurch schließt du automatisch 1:1 beziehungen aus. Also beim DB Design denkst du dir alle Komponenten aus. Denkst dir die Attribute aus welches jedes Objekt haben kann. Und zuletzt denkst du darüber nach ob die einzelnen Komponenten 1:n oder n:m zueinander stehen. 1:1 kann in dem Fall schon gar nicht mehr auftreten wenn du so vorgehst.

Ich würde allerdiengs zu N:M zu raten. So könnte man ein Foto gleichzeitig unter der Rubrik/Album "Fun" aber gleichzeitig auch "Hobby" oder gleichzeitig auch "Urlaub" einordnen...