ER-Diagramme 2: Beziehungen (1:1, 1:N, N:M)
HTML-код
- Опубликовано: 26 сен 2017
- Ich erkläre hier ausführlich und verständlich:
- Unterschied Chen-Notation bei ER-Diagrammen vs. Darstellung durch MySQL-Workbench
- 1:N-Beziehung: Fremdschlüssel auf der N-Seite
- 1:1-Beziehung: Fremdschlüssel in beliebiger Tabelle
- N:M-Beziehung: Assoziative Tabellen; der Trick mit der Liste
Inhalt:
0:05 - 1:N-Beziehung im ER-Diagramm/als Tabellen (Beispiel Trainer - Fußballspieler)
1:40 - Fremdschlüssel zur Realisierung von 1:n-Beziehung (oder auch 1:1-Beziehung)
4:09 - Realisierung einer 1:1-Beziehung: In welche Tabelle kommt der Fremdschlüssel?
5:58 - n:m-Beziehung in Chen-Notation
6:48 - n:m-Beziehung im Relationenmodell/Tabellenstruktur
8:27 - Assoziative Tabelle (n:m-Tabelle)
9:22 - Zusammengesetzter Primärschlüssel in der assoziativen Tabelle
10:42 - Zusammenfassung
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!!
Genau das hab ich gesucht , eine ausführliche und vorallem sehr verständliche Erklärung. Danke!
Freut mich sehr!
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!
Super Video! Hat mir gut geholfen, das ganze Thema mal richtig zu verstehen !
Freut mich sehr, danke für die Rückmeldung!!
Beste Erklärung auf RUclips.
Vielen lieben Dank 💐
Aber gerne doch - und danke für die Rückmeldung! #Ehre
Sehr gut erklärt und unterhaltsam sind Ihre Videos auch. Vielen Dank!
Freut mich, vielen Dank!!
dankesehr sehr deutlich und vollstaendig
Sehr gut erklärt 👍
Thanks :-)
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 !
Danke für das Video, super erklärt!
Mit Vergnügen, danke für die Rückmeldung!
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!
haha ich feier deine videos, bist nen top lehrer
Thanks, @breakchiller, du weißt halt gute Pädagogik zu schätzen :-)
Vielen vielen Dank!
Sehr gerne doch!!
Super erklärt! Danke dafür :)
Gerne doch - freut mich, dass es verständlich ist :-)
einfach perfekt
Freut mich! 🙏
Super Videos 😄👍🏼
Muchas gracias :-)
Ehrenmann, heute Klausur drüber
Die Frage ist eher, ob DU dich bei der Klausur mit Ehre bedeckst :-) Viel Glück!
Ehre!
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 ;)
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 RUclips findest du zu ternären Beziehungstypen aber eine Menge gutes Material.
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!
Was ist der Unterschied zwischen Assoziative Tabelle und Join Tabelle ?
Ich würde mal sagen: Ist das gleiche.
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
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!
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? :-)
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.
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).