Die allermeisten Use Cases können mit binären Beziehungen modelliert werden. In diesem Video geht es um die Grundlagen, weshalb ich mich auf binäre Beziehungen beschränke und ternäre oder rekursive Beziehungstypen weglasse. (Das handhaben die Bildungspläne an Schulen (Oberstufe) und Universitäten (Grundstudium) übrigens meist auch so). Auf UA-cam findest du zu ternären Beziehungstypen aber eine Menge gutes Material.
Hier würde ich gerne noch die Konstruktion mit Mehrstellige Beziehungstypen lernen. Damit habe ich noch Schwierigkeiten (z.B. Verkäufer verkauft Auto an Kunden). Ich habe auch nichts gefunden, wie man eine "is A"- Beziehung formuliert. Das sind beides häufige Fälle. Gibt es dazu einen Film ?
Für solche Beziehungstypen habe ich leider nichts. Die stehen in meinem Unterricht nicht auf dem Lehrplan, weil sie oft relativ komplizierte Konstruktionen erfordern, die man dann auch noch in bestimmten Fällen umgehen kann. Aber auf Stackoverflow gibt es ganz gute Erklärungen dazu.
Ich besuche ein sql kurs und da kam die frage. Warum ist es nötig, eine m:n Beziehung bei der Implementieren in ein relationales Datenbanksystem, in eine 1:n Beziehung aufzulösen. Es wurde schon im Kurs erklärt aber ich habe es nicht verstanden. Könnte es mit jemand noch mal einmal in anderen worten erklären warum man das macht
(Sorry für die späte Antwort:) Wahrscheinlich meinst du, wie man definieren kann, dass eine 1:1 Beziehung besteht und NICHT eine 1:N (oder?). Das machst du, indem du dem Fremdschlüssel einen UNIQUE-Constraint gibst (Google weiß, wie man das macht). Alles klar? :-)
Ehrenmann, hat mir auf jeden Fall geholfen das Video. Eine kurze Frage noch, bei der m:n Beziehung wird die Beziehung zwischen zwei Entitäten zu einer eigenen Tabelle, die Attribute setzen sich aus den beiden Primärschlüssel der anderen beiden Entitäten zusammen. Würde man hierbei die beiden Attribute in der Darstellung als Primär- und Fremdschlüssel gleichzeitig markieren?
Leider waren meine Workbench-Einstellungen nicht optimal, deshalb sieht man nicht, dass es genau so so ist, wie du schreibst. Es müssen also beide Attribute sowohl als Primärschlüssel als auch als Fremdschlüssel gekennzeichnet sein. In der Relationenschreibweise sieht so eine Tabelle deshalb so aus: trainer_hat_fussballspieler(↑_____ , ↑ ______) (kann leider Text nicht unterstreichen, deshalb stell dir auf den Strichen die Attributnamen vor).
Kann mir Jemand Helfen? Ich verstehe die 1 zu N Beziehung noch. Aber warum kann bei einer eins zu eins ein Fremdschlüssel vom Trainer bei Fußballspieler sein?
(Vorweg: Ich beziehe mich auf etwa 5:25 im Video, wo eine 1:1-Beziehung am Beispiel Trainer-Fußballspieler erläutert wird. Wir gehen also davon aus, dass EIN Trainer nur EINEN Fußballer trainiert, was inhaltlich natürlich nicht so glaubwürdig ist.) Eine 1:1-Beziehung funktioniert wie eine 1:N-Beziehung - nur dass es egal ist, auf welcher Seite der Fremdschlüssel ist. Schau den Fußballspieler Ronaldo an - wer ist sein Trainer? Peter Schmitt, und Peter Schmitt steht als Fremdschlüssel bei Ronaldo. Genau so könnten wir aber auch fragen, schau den Trainer Peter Schmitt an - welchen Fußballer trainiert er? Ronaldo, und Ronaldo steht als Fremdschlüssel beim Trainer. Also machst du es bei der 1:1 wie bei der 1:N, nur dass es egal ist, auf welcher Seite der Fremdschlüssel steht (Hauptsache, er steht nur auf einer Seite). Bei diesem Vorgehen wäre es übrigens möglich, dass sich das ganze verhält wie eine 1:N-Beziehung (indem du bspw. mehreren Fußballern den gleichen Trainer gibst). Das müsstest du dann bspw. softwareseitig abfangen. Für den reinen Datenbankunterricht und ER-Modelle/Relationenmodelle sollte das aber keine Rolle spielen.
Die Beispiele im Video sind so einleuchtend, ich habe in meinem Skript jetzt eine Aufgabe und bin verwirrt: Geschäftspartner 1 ------(kauft)-------- * Auftrag 1 ----(verkauft)------ * Gibts da jetzt was zu beachten wenn es 2 Relationen zu den selben Entitäten gibt? Ist das richtig so: Geschäftspartner([Primärs.]G_ID) Auftrag ([Primärs.]A_ID, [Fremds.]FK_G_ID, [Fremds.]FK_A_ID)
Grundsätzlich geht es natürlich, dass du zwischen den gleichen Entitäten zwei unterschiedliche Beziehungen hast. Gut diskutiert hier: stackoverflow.com/questions/14542763/2-relationships-between-2-entities-in-er-diagram Die Frage ist, ob du in deinem Fall die Datenstruktur nicht unnötig kompliziert machst. Spontan könnte ich mir auch eine Beziehung vorstellen und in der Tabelle Auftrag noch ein Attribut "typ", da steht dann drin "kauf" oder "verkauf" o.ä.
Bei der 1:N-Beziehung MUSST du den Fremdschlüssel auf die Seite packen, wo das N ist. Bei der 1:1-Beziehung ist es egal. Deshalb kann es aussehen wie bei der 1:N-Beziehung. Also fussballer(1)----(1)trainer bedeutet, dass du entweder bei Fußballer den Fremdschlüssel einbaust oder bei Trainer. Klar? :-)
Doch, irgendwie schon :-) Was wir mit dem ER-Diagramm machen, ist ein Entwurf. Du malst das, besprichst es mit dem Kunden und gibst es anschließend dem DB-Programmierer. Wenn der Programmierer eine 1:1-Beziehung sieht, dann hat er verschiedene Möglichkeiten: 1) Wahrscheinlich würde er sagen, lass uns doch aus den beiden Tabellen eine machen (also bspw. den Trainer in die Fußballertabelle integrieren). Damit würdest du zwar eine Normalform verletzen, aber da du weißt, dass es grundsätzlich nur einen Trainer pro Fußballer UND umgekehrt geben wird, ist das ein akademisches Problem. Du könntest darauf bestehen, dass er zwei Tabellen macht (bspw. weil dir die Tabelle fussballer dann zu umfangreich wird oder weil du auf die Datensätze des Trainers andere SQL-Zugriffsrechte vergeben möchtest als auf die Datensätze der Fußballer. 2) Er könnte alternativ sagen, prima, dann programmiere ich noch was dazu, dass es auch wirklich eine 1:1-Beziehung ist. Wenn also über die Programmoberfläche, die die Datenbank nutzt, einem Fußballer ein neuer Trainer zugeordnet wird, dann prüft das Programm, ob es schon einen Trainer gibt und bietet an, den alten Trainer zu beseitigen und den neuen einzufügen. 3) Er könnte auch irgendwelche Tricks innerhalb der Datenbank anwenden (wie z.B. hier: dba.stackexchange.com/questions/118314/is-there-a-way-to-limit-the-number-of-foreign-key-references-for-a-single-table ). Aber das wäre für eine 1:1-Beziehung definitiv überkonfiguriert.
@@informatikZentrale Danke für deine detailreiche Information. Ich hatte genau dieselbe Frage wie Omar, allerdings verstehe ich jetzt, warum Omar und ich verwirrt waren. Ab 5:28 wurde ja zusätzlich wieder das ER-Diagramm eingeblendet und man kann sehen, dass Neymar und CR7 beide die trainer_ID 1 enthalten, das wäre aber eine Verletzung der 1:1 Beziehung, wenn ich mich nicht irre, denn es darf ja schließlich nur genau ein einziger Spieler von genau einem einzigen Trainer trainiert werden? Das war zumindest für mich in dem Moment verwirrend, weil ich gedanklich das 1:1 Modell angewendet habe, aber dieses ER-Diagramm das 1:N Modell gezeigt hat.
@@ricardoa-g3843 Ja, da hast du Recht, danke für die Ergänzung! Das ist im Video nicht gut gelöst. Ich könnte allerdings auch sagen, es war Absicht, damit man sieht, dass wir hier zusätzliche Prüfungen brauchen (wie in meiner Antwort oben, wo ich drei Möglichkeiten gebe, mit dem 1:1-Problem umzugehen).
Nein. Bei 1 zu n bekommt die n-Seite den Primärschlüssel von der 1-Seite. Bei 1 zu 1 darfst du dir aussuchen wer von den beiden den Primärschlüssel des anderen speichert.
Super Video, hat sehr geholfen. Der 80er Jahre Techno zwischendrin macht das ganze sehr authentisch.
:-) Vielen Dank!
Diese Videos sind gold wert. Übermorgen Datenbanken Klausur :)
Thanks - und viel Glück!!
Super und idiotensicher erklärt :D daankeschön!
Freut mich, danke
Genau das hab ich gesucht , eine ausführliche und vorallem sehr verständliche Erklärung. Danke!
Freut mich sehr!
haha ich feier deine videos, bist nen top lehrer
Thanks, @breakchiller, du weißt halt gute Pädagogik zu schätzen :-)
Sehr gut auf den Punkt gebracht. Dankeschoen!
Vielen Dank für die freundliche Rückmeldung!
Vielen herzlichen Dank für das tolle Video! Super erklärt!
Freut mich sehr!
einfach perfekt
Freut mich! 🙏
dankesehr sehr deutlich und vollstaendig
Beste Erklärung auf UA-cam.
Vielen lieben Dank 💐
Aber gerne doch - und danke für die Rückmeldung! #Ehre
Sehr gut erklärt 👍
Thanks :-)
Sehr gut erklärt und unterhaltsam sind Ihre Videos auch. Vielen Dank!
Freut mich, vielen Dank!!
Danke für das Video, super erklärt!
Mit Vergnügen, danke für die Rückmeldung!
Super Videos 😄👍🏼
Muchas gracias :-)
Ehre!
Tolles Video, du weißt wo schüler sich gedanken drum machen 6:31 ^^
Danke :-) Alles Erfahrungswerte …
True hahah mein Lehrer hat mir das nie erklärt. Wusste es bis heute nicht ^^ 3 Jahre fast in der Ausbildung !
Super erklärt! Danke dafür :)
Gerne doch - freut mich, dass es verständlich ist :-)
Danke für die klasse Videos! Ich mache seit kurzem eine Fachinformatiker Lehre und deine Videos helfen mir sehr! Beste Grüße
Danke für die nette Rückmeldung - und viel Glück weiterhin!
Vielen vielen Dank!
Sehr gerne doch!!
Ehrenmann, heute Klausur drüber
Die Frage ist eher, ob DU dich bei der Klausur mit Ehre bedeckst :-) Viel Glück!
Und was ist mit three-way associative relationship oder Kardinalitäten n-stelliger Beziehungstypen (ternär) ?
Die allermeisten Use Cases können mit binären Beziehungen modelliert werden. In diesem Video geht es um die Grundlagen, weshalb ich mich auf binäre Beziehungen beschränke und ternäre oder rekursive Beziehungstypen weglasse. (Das handhaben die Bildungspläne an Schulen (Oberstufe) und Universitäten (Grundstudium) übrigens meist auch so). Auf UA-cam findest du zu ternären Beziehungstypen aber eine Menge gutes Material.
Hier würde ich gerne noch die Konstruktion mit Mehrstellige Beziehungstypen lernen. Damit habe ich noch Schwierigkeiten (z.B. Verkäufer verkauft Auto an Kunden). Ich habe auch nichts gefunden, wie man eine "is A"- Beziehung formuliert. Das sind beides häufige Fälle. Gibt es dazu einen Film ?
Für solche Beziehungstypen habe ich leider nichts. Die stehen in meinem Unterricht nicht auf dem Lehrplan, weil sie oft relativ komplizierte Konstruktionen erfordern, die man dann auch noch in bestimmten Fällen umgehen kann. Aber auf Stackoverflow gibt es ganz gute Erklärungen dazu.
Ich besuche ein sql kurs und da kam die frage. Warum ist es nötig, eine m:n Beziehung bei der Implementieren in ein relationales Datenbanksystem, in eine 1:n Beziehung aufzulösen. Es wurde schon im Kurs erklärt aber ich habe es nicht verstanden. Könnte es mit jemand noch mal einmal in anderen worten erklären warum man das macht
Aber wie kann man mit SQL eine 1:1 oder 1:N Beziehung unterscheiden ? Geht das überhaupt ?
(Sorry für die späte Antwort:) Wahrscheinlich meinst du, wie man definieren kann, dass eine 1:1 Beziehung besteht und NICHT eine 1:N (oder?). Das machst du, indem du dem Fremdschlüssel einen UNIQUE-Constraint gibst (Google weiß, wie man das macht). Alles klar? :-)
10/10 Retter in Not 👌
10/10 Ehrenkommentarschreiber :-)
Ehrenmann, hat mir auf jeden Fall geholfen das Video. Eine kurze Frage noch, bei der m:n Beziehung wird die Beziehung zwischen zwei Entitäten zu einer eigenen Tabelle, die Attribute setzen sich aus den beiden Primärschlüssel der anderen beiden Entitäten zusammen. Würde man hierbei die beiden Attribute in der Darstellung als Primär- und Fremdschlüssel gleichzeitig markieren?
Leider waren meine Workbench-Einstellungen nicht optimal, deshalb sieht man nicht, dass es genau so so ist, wie du schreibst. Es müssen also beide Attribute sowohl als Primärschlüssel als auch als Fremdschlüssel gekennzeichnet sein. In der Relationenschreibweise sieht so eine Tabelle deshalb so aus: trainer_hat_fussballspieler(↑_____ , ↑ ______) (kann leider Text nicht unterstreichen, deshalb stell dir auf den Strichen die Attributnamen vor).
@@informatikZentrale perfekt vielen Dank!
@@ilprincipe8094 Prima das habe ich mich auch gefragt ;)
Kann mir Jemand Helfen? Ich verstehe die 1 zu N Beziehung noch. Aber warum kann bei einer eins zu eins ein Fremdschlüssel vom Trainer bei Fußballspieler sein?
(Vorweg: Ich beziehe mich auf etwa 5:25 im Video, wo eine 1:1-Beziehung am Beispiel Trainer-Fußballspieler erläutert wird. Wir gehen also davon aus, dass EIN Trainer nur EINEN Fußballer trainiert, was inhaltlich natürlich nicht so glaubwürdig ist.)
Eine 1:1-Beziehung funktioniert wie eine 1:N-Beziehung - nur dass es egal ist, auf welcher Seite der Fremdschlüssel ist. Schau den Fußballspieler Ronaldo an - wer ist sein Trainer? Peter Schmitt, und Peter Schmitt steht als Fremdschlüssel bei Ronaldo. Genau so könnten wir aber auch fragen, schau den Trainer Peter Schmitt an - welchen Fußballer trainiert er? Ronaldo, und Ronaldo steht als Fremdschlüssel beim Trainer.
Also machst du es bei der 1:1 wie bei der 1:N, nur dass es egal ist, auf welcher Seite der Fremdschlüssel steht (Hauptsache, er steht nur auf einer Seite). Bei diesem Vorgehen wäre es übrigens möglich, dass sich das ganze verhält wie eine 1:N-Beziehung (indem du bspw. mehreren Fußballern den gleichen Trainer gibst). Das müsstest du dann bspw. softwareseitig abfangen. Für den reinen Datenbankunterricht und ER-Modelle/Relationenmodelle sollte das aber keine Rolle spielen.
@@informatikZentrale Super Vielen Dank für die Ausführliche Antwort :) hat mir echt sehr geholfen bitte weiter so!
@@florian2119 Freut mich, viel Erfolg weiterhin damit!
Was ist der Unterschied zwischen Assoziative Tabelle und Join Tabelle ?
Ich würde mal sagen: Ist das gleiche.
Die Beispiele im Video sind so einleuchtend, ich habe in meinem Skript jetzt eine Aufgabe und bin verwirrt:
Geschäftspartner 1 ------(kauft)-------- * Auftrag
1 ----(verkauft)------ *
Gibts da jetzt was zu beachten wenn es 2 Relationen zu den selben Entitäten gibt?
Ist das richtig so:
Geschäftspartner([Primärs.]G_ID)
Auftrag ([Primärs.]A_ID, [Fremds.]FK_G_ID, [Fremds.]FK_A_ID)
Grundsätzlich geht es natürlich, dass du zwischen den gleichen Entitäten zwei unterschiedliche Beziehungen hast. Gut diskutiert hier: stackoverflow.com/questions/14542763/2-relationships-between-2-entities-in-er-diagram
Die Frage ist, ob du in deinem Fall die Datenstruktur nicht unnötig kompliziert machst. Spontan könnte ich mir auch eine Beziehung vorstellen und in der Tabelle Auftrag noch ein Attribut "typ", da steht dann drin "kauf" oder "verkauf" o.ä.
Danke die versäumnise des Lehrers holen Sie nach
Es freut mich, dass ich dir helfen konnte!
Hey wie kann es sein dass die 1:n Beziehung bei 1:46 genau gleich beschrieben wurde wie die 1:1 Beziehung bei 5:28?
Bei der 1:N-Beziehung MUSST du den Fremdschlüssel auf die Seite packen, wo das N ist. Bei der 1:1-Beziehung ist es egal. Deshalb kann es aussehen wie bei der 1:N-Beziehung. Also fussballer(1)----(1)trainer bedeutet, dass du entweder bei Fußballer den Fremdschlüssel einbaust oder bei Trainer. Klar? :-)
Aber das eine ist ja dann eine 1:n Beziehung. Es kann ja nicht beides sein oder wie unterscheide ich die dann ?
Doch, irgendwie schon :-) Was wir mit dem ER-Diagramm machen, ist ein Entwurf. Du malst das, besprichst es mit dem Kunden und gibst es anschließend dem DB-Programmierer. Wenn der Programmierer eine 1:1-Beziehung sieht, dann hat er verschiedene Möglichkeiten:
1) Wahrscheinlich würde er sagen, lass uns doch aus den beiden Tabellen eine machen (also bspw. den Trainer in die Fußballertabelle integrieren). Damit würdest du zwar eine Normalform verletzen, aber da du weißt, dass es grundsätzlich nur einen Trainer pro Fußballer UND umgekehrt geben wird, ist das ein akademisches Problem. Du könntest darauf bestehen, dass er zwei Tabellen macht (bspw. weil dir die Tabelle fussballer dann zu umfangreich wird oder weil du auf die Datensätze des Trainers andere SQL-Zugriffsrechte vergeben möchtest als auf die Datensätze der Fußballer.
2) Er könnte alternativ sagen, prima, dann programmiere ich noch was dazu, dass es auch wirklich eine 1:1-Beziehung ist. Wenn also über die Programmoberfläche, die die Datenbank nutzt, einem Fußballer ein neuer Trainer zugeordnet wird, dann prüft das Programm, ob es schon einen Trainer gibt und bietet an, den alten Trainer zu beseitigen und den neuen einzufügen.
3) Er könnte auch irgendwelche Tricks innerhalb der Datenbank anwenden (wie z.B. hier: dba.stackexchange.com/questions/118314/is-there-a-way-to-limit-the-number-of-foreign-key-references-for-a-single-table ). Aber das wäre für eine 1:1-Beziehung definitiv überkonfiguriert.
@@informatikZentrale Danke für deine detailreiche Information. Ich hatte genau dieselbe Frage wie Omar, allerdings verstehe ich jetzt, warum Omar und ich verwirrt waren.
Ab 5:28 wurde ja zusätzlich wieder das ER-Diagramm eingeblendet und man kann sehen, dass Neymar und CR7 beide die trainer_ID 1 enthalten, das wäre aber eine Verletzung der 1:1 Beziehung, wenn ich mich nicht irre, denn es darf ja schließlich nur genau ein einziger Spieler von genau einem einzigen Trainer trainiert werden?
Das war zumindest für mich in dem Moment verwirrend, weil ich gedanklich das 1:1 Modell angewendet habe, aber dieses ER-Diagramm das 1:N Modell gezeigt hat.
@@ricardoa-g3843 Ja, da hast du Recht, danke für die Ergänzung! Das ist im Video nicht gut gelöst. Ich könnte allerdings auch sagen, es war Absicht, damit man sieht, dass wir hier zusätzliche Prüfungen brauchen (wie in meiner Antwort oben, wo ich drei Möglichkeiten gebe, mit dem 1:1-Problem umzugehen).
5:25 Kann ich nicht nachvollziehen das ist doch genau das selbe wie bei einer 1 zu N beziehung
Nein. Bei 1 zu n bekommt die n-Seite den Primärschlüssel von der 1-Seite.
Bei 1 zu 1 darfst du dir aussuchen wer von den beiden den Primärschlüssel des anderen speichert.