# ER Model Begrenzung auf Zeiteinheiten.



## mugsawaay (21. Dez 2018)

Werden im ER Modell Begrenzungen eingetragen, falls ja, wie?

1. Beispiel: Redakteure schreiben Beiträge. n zu m Zuordnung ist klar.

2. Was, wenn ein Redakteur nur einen Beitrag pro Tag schreiben darf? Wird das wie unter 1. behandelt?


----------



## VfL_Freak (21. Dez 2018)

Moin,

n : 1 ... oder was meinst Du?

VG Klaus


----------



## mugsawaay (21. Dez 2018)

Geneu das ist ja meine Frage?
viele Redakteure dürfen viele Beiträge schreiben, also n:m
das gilt immer noch.
aber was mache ich mit der Einschränkung nur einen Beitrag pro Tag?


----------



## mihe7 (21. Dez 2018)

mugsawaay hat gesagt.:


> Redakteure schreiben Beiträge. n zu m Zuordnung ist klar.


So klar ist das mit der Formulierung nicht. n:m wäre es nur, wenn an einem Beitrag mehrere Redakteure schreiben.

Ist das so? Dann frage ich mich, wie ich die nächste Formulierung verstehen soll. Redakteur A schreibt heute einen Beitrag und morgen schreibt den selben (=am selben) Beitrag Redakteur B?


----------



## mugsawaay (21. Dez 2018)

OK!

a. Redakteure schreiben Beiträge.
b. Ein Beitrag wird von genau einem Redakteur geschrieben

Es gibt eine Relation Redakteure [0,*]    "schreiben" Beiträge
Es gibt eine Relation Beiträge [1,1]         "werden von Redakteuren geschrieben"

Einschränkung: Es darf pro Tag nur ein Beitrag je Redakteur geschrieben werden.

(Das funktioniert ja auch prima, das kann die Datenbank abfangen ggf. kann das auch softwaretechnisch abgefangen werden, alles kein Problem.)

Spielt das für das ER Modell überhaupt eine Rolle? Genausogut könnte man ja sagen: Beiträge dürfen nur zu bestimmten Zeiten, z.B. vor Redaktionsschluss abgegeben werden. Es geht einzig um die zeitliche Einschränkung. Kann dies im ER Modell dokumentiert werden? Wenn ja, wie?


----------



## mihe7 (21. Dez 2018)

mugsawaay hat gesagt.:


> Spielt das für das ER Modell überhaupt eine Rolle?


Schon. Man kann den Beitrag somit als von einem Redakteur abhängig sehen (https://de.wikipedia.org/wiki/Schwache_Entität). Der Key bestünde dann aus dem Datum des Beitrags und dem Fremdschlüssel zum Redakteur.


----------



## mrBrown (21. Dez 2018)

mugsawaay hat gesagt.:


> a. Redakteure schreiben Beiträge.
> b. Ein Beitrag wird von genau einem Redakteur geschrieben
> 
> Es gibt eine Relation Redakteure [0,*] "schreiben" Beiträge
> Es gibt eine Relation Beiträge [1,1] "werden von Redakteuren geschrieben"


Das solltest du allerdings als eine Relation, und nicht als zwei ausdrücken.


```
Redakteure-[1,1]---schreiben>--[0,*]-Beiträge
```


----------



## mugsawaay (22. Dez 2018)

ok, danke. Wie meinst du das eine Relation? Jetzt verstehe ich gar nichts mehr.
Ich glaub ich mach mal ein Beispiel, die Relationen Redakteure und Beiträge sind vorgegeben, da habe ich keinen Einfluß drauf.
1. Es existiert eine Relation Redakteure, diese können Beiträge schreiben müssen es aber nicht.
Ich lass mal alle nicht relevanten Spalten weg, dann bleibt quasi nur die "ID" die in der Relation "Beiträge" als Fremdschlüssel verwendet wird.
 Die Relation Beiträge hat folgende Spalten: Text, Tag, Fremdschlüssel
Unter der Annahme es gibt 2 Redakteure(1,2) Beispiel für Relation Beiträge.

blabla, Montag, 3 --> nicht ok, funktioniert. Schlüssel existiert nicht
blabal, Montag, 2--> ok
blabla, Montag, 2--> ok funktioniert auch, darf aber nicht weil Montag schon existiert
wenn ich jetzt Tag auf unique abprüfe geht es, aber dann geht folgendes nicht mehr.

blabla, Montag, 1--> ok
blabla, Montag, 2--> müßte funktionieren, weil Redakteur 2 montags ja noch keinen Artikel geschrieben hat, geht aber wegen unique nicht.


----------



## mrBrown (22. Dez 2018)

mugsawaay hat gesagt.:


> ok, danke. Wie meinst du das eine Relation? Jetzt verstehe ich gar nichts mehr.


Sorry, irgendwie grad 'n Brett vor'm Kopf gehabt und Unsinn geschrieben.
Hatte deins so verstanden, als gibt es zwei Beziehungen zwischen Redakteur und Beiträgen...




mugsawaay hat gesagt.:


> 1. Es existiert eine Relation Redakteure, diese können Beiträge schreiben müssen es aber nicht.
> Ich lass mal alle nicht relevanten Spalten weg, dann bleibt quasi nur die "ID" die in der Relation "Beiträge" als Fremdschlüssel verwendet wird.
> Die Relation Beiträge hat folgende Spalten: Text, Tag, Fremdschlüssel
> Unter der Annahme es gibt 2 Redakteure(1,2) Beispiel für Relation Beiträge.
> ...



Nicht "Montag" sollte unique sein, sondern das Tupel (Tag, Redakteur).


blabla, Montag, 1--> ok, (Montag, 1) gibts noch nicht
blabla, Montag, 2--> ok, (Montag, 2) gibts noch nicht
foo, Montag, 2--> nicht ok, (Montag, 2) gibts schon


----------



## mugsawaay (22. Dez 2018)

Jo endlich sind wir beieinander. Wie ich das in java machen würde weiß ich, wenn ich das über meine Oberfläche eingebe kann ich das ja abprüfen. Gibt es auch die Möglichkeit das die DB das selbst überprüft?


----------



## mrBrown (22. Dez 2018)

mugsawaay hat gesagt.:


> Gibt es auch die Möglichkeit das die DB das selbst überprüft?


Ein UNIQUE-Constraint über beide Werte hinzufügen.


----------



## mugsawaay (23. Dez 2018)

Vielen Dank! Das ist ja super. Funktioniert perfekt.
Bleibt nur noch das Problem, wie man sowas im ER Model darstellt. Ich würde jetzt in der Relation "Beiträge" die Spalten Tag und Fremdschlüssel z.B. gestrichelt unterstreichen, um sie so als eindeutiges Tuppel zu makieren.


----------

