Wie genau funktionieren Relationen in (My)SQL

[Gast]

Abend!

Die Frage ist mir fast schon unangenehm, aber ich habe nach wie vor nicht herausgefunden, wie man genau "Relationen" im Bezug auf (My)SQL zu verstehen hat.

Also ich habe mir jetzt ein schönes Datenbankschema ausgedacht, welches die ersten 3 Normalformen einhält.
Aber wie stelle ich die Relationen jetzt codetechnisch her? Früher habe ich dafür immer JOINs benutz, weil ich dachte, MySQL sei aufgrund JOINs ein RDBMS.
Aber da muss doch mehr dahinterstecken. Geht das nicht irgendwie automatisch? Ich bin schon über Begrifffe wie Foreign Key etc. gestoßen, aber so richtig klick hat es noch nicht gemacht.

Wäre um etwas Aufklärung dankbar, eventuell habt ihr ja auch einen Link zu einer eher einfachen Einführung parat.

Danke

[robobimbo]

Wenn Du weisst, dass Du die ersten drei Normalformen einhältst, dann kann es nicht sein, dass dir eine Fremdschlüsselbeziehung nichts sagt.

[Gast]

Ich habe mich an eine übliche Beschreibung der Normalformen gehalten wie man sie zuhauf findet und das einzige, was ich dabei gelernt habe ist, dass man unter bestimmten Umständen (wie sie in Satz 1-3 beschrieben werden) den Inhalt von Feldern als ID festlegt, die auf andere Tabellen verweisen. Das ist alles. Das wusste ich auch früher schon und habe meine Tabellen so gestaltet, nur habe ich da aber immer joins benutzt bei den queries. Wie man aber konkret damit umgeht bei den querys, sowas findet man bei der Beschreibung der Normalformen nicht.

[Spasstiger]

Bei deinen komischen Fachbegriffen blicke ich nicht durch (Join, RDBMS), obwohl ich auch mal ein bischen SQL gelernt habe. Aber mir scheint, dass du dich noch nicht wirklich intensiv mit den Grundlagen von relationalen Datenbanken beschäftigt hast.
Eigentlich gibt es klare Grundregeln, wie man Relationen bzw. ER-Diagramme in Tabellen umsetzt und die Abfragen gestaltet (man kann die Tabellen von manchen Umgebung sogar automatisch anlegen lassen, wenn man das ER-Diagramm erstellt hat). Was du machen willst, klingt auch ein bischen nach Reverse Engineering und nicht nach einem sauberen Vorgehen bei der Erstellung einer Datenbank.

/EDIT: Führe dir das mal zu Gemüte: http://vorlesungen.ias.uni-stuttgart.de/vorlesung/index_st2.php (§7). Man erstellt relationale Datenbanksysteme nicht, indem man SQL lernt, sondern indem man die Konzepte von relationen Datenbanken kennen und verstehen lernt.
Und sorry schonmal, falls ich dich falsch einschätze.

/EDIT2: Mit RDBMS meinst du wahrscheinlich ein Relationales Datenbank-Management-System. Da ich nicht täglich mit diesen Begriffen zu tun hab, war mir die Abkürzung erstmal nicht geläufig.

[ESAD]

"fachbegriffe"
join = teil von der sql syntax um zwei tabellen zu verknüpfen
RDBMS = relationales datenbank management system


was willst du denn genau tun? automatisch abfragen erstellen lassen? ja dafür gibts tools wo man das zusammenklicken kann wenn man die joins nicht schreiben will.

aber die realtionen entstehen eben dadurch dass du die normalformen einhältst und dann eben mit joins, kreuzprodukt und unions darauf rumwerks.

aber es klingt so wie als solltest du dir einmal ein bisschen was anlesen warum man die normalformen überhaupt verwendet. primary/foreign key pärchen sind hierbei ebenfalls ein wichtiger teil dem man z.b. beim löschen beachten muss

[Gast]

Was du machen willst, klingt auch ein bischen nach Reverse Engineering und nicht nach einem sauberen Vorgehen bei der Erstellung einer Datenbank.

Hm, ich überlege mir die Tabellen und Felder, die ich brauche. Da habe ich dann meistens nur wenige Tabellen mit vielen Feldern. Dann gucke ich, wo ich die Haupsätze anwenden und die Tabellen verknüpfen kann, das resultiert dann meist in mehreren Tabellen mit weniger Feldern, also als zuvor.

Was passt daran genau nicht? Also die Frage ist ernst gemeint, ich lerne gerne dazu.

Danke für den Link übrigens :)



was willst du denn genau tun? automatisch abfragen erstellen lassen? ja dafür gibts tools wo man das zusammenklicken kann wenn man die joins nicht schreiben will.

aber die realtionen entstehen eben dadurch dass du die normalformen einhältst und dann eben mit joins, kreuzprodukt und unions darauf rumwerks.

aber es klingt so wie als solltest du dir einmal ein bisschen was anlesen warum man die normalformen überhaupt verwendet. primary/foreign key pärchen sind hierbei ebenfalls ein wichtiger teil dem man z.b. beim löschen beachten muss

Ich glaube, ich habe mich nur dumm ausgedrückt, das zeigen mir die Fragen :) Meine Schuld, sorry.

Also ich kann mir schon denken, dass ein Kernpunkt einer relationalen DB die Einhaltung von möglichst vielen der Normalformen ist. Deshalb habe ich das ja auch immer versucht.

Ich wollte jetzt eher wissen, wie man in MySQL damit umgeht, wenn man das Design schon ausgearbeitet hat. Bisher habe ich zum "Verknüpfen" immer joins benutzt, aber wie gesagt frage ich mich, ob das alles gewesen sein kann. Dann ist ein relationales Datenbanksystem ja auch nur ne stinknormale Datenbank, die Queries unterstützt, in denen man schon innerhalb der Abfrage 2 Tabellen oder mehr ansprechen kann. Dass man mit ids auf Felder anderer Tabellen zeigt, das kann man doch mit jeder Datenbank machen. Nur dass die Verknüpfung mangels fehlenden Befehlen nicht im Query, sondern im aufrufenden Code stattfinden müsste.

InnoDB zum Beispiel habe ich noch nie benutzt, aber nur dieses scheint diese Foreign Keys anzubieten. Das klingt schonmal nach einer Erweiterung. Ich suche ja nach einem Aha-Effekt.

Bisher schreibe ich immer umständlich join dies, join das.
Kann man das nicht so lösen, dass ich einen Query genau so formuliere, als hätte ich keine der normalformen angewendet?

Zum Beispiel select username, adress, telephone, age from xy where userid = x =

Auch wenn adress, telephone und age in Wirklichkeit in ganz anderen Tabellen stecken als in xy, und xy nur die "Haupttabelle" darstellt wo der User an seine id gekoppelt wird.

Kurz gesagt hab ich einfach nur gehofft, dass da mehr dahintersteckt als alles mit joins und co. verknüpfen zu müssen.

[Spasstiger]

Danke für den Link übrigens :)
Hier noch den wichtigeren Teil: http://www.ias.uni-stuttgart.de/st2/lehrmaterialien/uebung.html
Übung 7, Übung 8, Übung 9. Erst die Theoriefolien zu den Aufgaben reinziehen, dann die Aufgaben bearbeiten. Ich denke, du wirst was dazulernen können.

Ich sehe übrigens gerade, dass auch der Begriff Join in den zuerst verlinkten Folien auftaucht. Da sieht man mal, was von einer Vorlesung hängenbleibt. :D

[ESAD]

Hm, ich überlege mir die Tabellen und Felder, die ich brauche. Da habe ich dann meistens nur wenige Tabellen mit vielen Feldern. Dann gucke ich, wo ich die Haupsätze anwenden und die Tabellen verknüpfen kann, das resultiert dann meist in mehreren Tabellen mit weniger Feldern, also als zuvor.

Was passt daran genau nicht? Also die Frage ist ernst gemeint, ich lerne gerne dazu.

Danke für den Link übrigens :)



Ich glaube, ich habe mich nur dumm ausgedrückt, das zeigen mir die Fragen :) Meine Schuld, sorry.

Also ich kann mir schon denken, dass ein Kernpunkt einer relationalen DB die Einhaltung von möglichst vielen der Normalformen ist. Deshalb habe ich das ja auch immer versucht.

Ich wollte jetzt eher wissen, wie man in MySQL damit umgeht, wenn man das Design schon ausgearbeitet hat. Bisher habe ich zum "Verknüpfen" immer joins benutzt, aber wie gesagt frage ich mich, ob das alles gewesen sein kann. Dann ist ein relationales Datenbanksystem ja auch nur ne stinknormale Datenbank, die Queries unterstützt, in denen man schon innerhalb der Abfrage 2 Tabellen oder mehr ansprechen kann. Dass man mit ids auf Felder anderer Tabellen zeigt, das kann man doch mit jeder Datenbank machen. Nur dass die Verknüpfung mangels fehlenden Befehlen nicht im Query, sondern im aufrufenden Code stattfinden müsste.

InnoDB zum Beispiel habe ich noch nie benutzt, aber nur dieses scheint diese Foreign Keys anzubieten. Das klingt schonmal nach einer Erweiterung. Ich suche ja nach einem Aha-Effekt.

Bisher schreibe ich immer umständlich join dies, join das.
Kann man das nicht so lösen, dass ich einen Query genau so formuliere, als hätte ich keine der normalformen angewendet?

Zum Beispiel select username, adress, telephone, age from xy where userid = x =

Auch wenn adress, telephone und age in Wirklichkeit in ganz anderen Tabellen stecken als in xy, und xy nur die "Haupttabelle" darstellt wo der User an seine id gekoppelt wird.

Kurz gesagt hab ich einfach nur gehofft, dass da mehr dahintersteckt als alles mit joins und co. verknüpfen zu müssen.

und die datenbank weis genau woher wo sie die daten herfangen soll? glaskugel? wenn dus allerdings in einem programm brauchst kannst dir mal z.b. hibernate anschauen. da musst du aber eban auch vorher konfigurieren was, wie, woher.

oder du machst nen view draus und machst ein select darauf. nur ist dann wieder mehr aufwand mit dem auflösen von inserts.

btw. primary/foreign key kann eigentlich jede mir bekannte db mit der ich mehr gemacht hab. mssql, oracle, mysql. und wie gesagt hier bringt es z.b. eine erleichterung beim löschen (sichwort: Cascadiertes Löschen)

[Ganon]

btw. primary/foreign key kann eigentlich jede mir bekannte db mit der ich mehr gemacht hab. mssql, oracle, mysql.

Vorsicht bei MySQL ;) MySQL kann so erst mal gar nichts. Erst die gewählte Datenbank dahinter entscheidet was MySQL kann. MyISAM unterstützt z.B. keine Fremdschlüssel. InnoDB hingegen schon.

So, zum Thema:

Nein, Datenbanken holen nicht automatisch mehr Daten rein, als du abfragst und das ist auch gut so. Denn nur weil ich z.B. die Adress-ID in meinen Auftrag schreibe, möchte ich beim Abfragen des Auftrags nicht gleich die Adresse samt allen Kontakten und sonstigen Adressinformationen haben.

Fremdschlüssel dienen in erster Linie dazu eine Datenprüfung vorzunehmen. Du kannst z.B. keinen Datensatz löschen der per Fremdschlüssel irgendwo eingetragen ist. Oder wie schon gesagt, dass wenn du den Datensatz löschst, dass dann auch alle anderen Datensätze gelöscht werden, die davon abhängen. Unterstützt eine Datenbank keine Fremdschlüssel hast du diese Features halt nicht, aber die Daten kannst du trotzdem abfragen.

Darum ist man bei der Normalisierung auch immer "vorsichtig". Theorie der Normalisierung schön und gut, aber wenn man für simple Abfragen 3-4 JOINs braucht, dann stellt man den Sinn der Normalisierung irgendwann in Frage ;)

Wenn du automatische SQL-Generierung haben willst, bietet sich bei Java z.B. JPA an (hier schon mal genannt eine Implementierung davon ist Hibernate). Hier definierst du deine Datenbank als normale Java-Objekte mit ihrern Gettern/Settern und bestimmst dann was Hibernate bei session.get(Auftrag.class, id) alles holen soll und was nicht. Aber die Lernkurve ist hier sehr steil.

Einige Datenbanken wie PostgreSQL bieten auch Views an. So kannst du auch deine Abfrage mit 4 JOINs in eine View packen und die dann normal Abfragen.

[AlecWhite]

Also ich kann mir schon denken, dass ein Kernpunkt einer relationalen DB die Einhaltung von möglichst vielen der Normalformen ist. Deshalb habe ich das ja auch immer versucht.
Dann ist ein relationales Datenbanksystem ja auch nur ne stinknormale Datenbank, die Queries unterstützt, in denen man schon innerhalb der Abfrage 2 Tabellen oder mehr ansprechen kann.
Ich denke hier liegt das grundlegende Verständnisproblem.

Der Begriff "Relation" sagt dabei eigentlich alles aus: In der Datenbank werden Mengen von n-Tupeln gespeichert - wie diese Tupel hingegen aussehen ist der Datenbank egal. Mehr ist das ganze Geheimnis schon mal nicht und mehr leistet eine Datenbank (vorerst) nicht. Das DBMS (in deinen Fall der mySQL Server) sorgt für eine Abstraktionsschicht zwischen den Daten und der Anwendung, so daß alle Anwendungen in gleicher Weise auf die Daten zugreifen können. Das Gegenteil hierzu wäre, dass du Daten in einem eigenen Format auf der Festplatte speicherst, z.B. ein Savegame auf der Platte anlegst. Des Weitern sorgt das DBMS auch dafür das die Daten integer bleiben (ACID Prinzip).

Bei den Normalformen geht es darum, die Datenbasis möglichst redundanzfrei zu halten.

Ich wollte jetzt eher wissen, wie man in MySQL damit umgeht, wenn man das Design schon ausgearbeitet hat. Bisher habe ich zum "Verknüpfen" immer joins benutzt, aber wie gesagt frage ich mich, ob das alles gewesen sein kann.
Jepp, das ist alles. Du kannst natürlich Views auf Basis deiner SQL Queries erstellen - und dann einfach diese Views abfragen. Intern ändert sich nichts.


Bisher schreibe ich immer umständlich join dies, join das.
Kann man das nicht so lösen, dass ich einen Query genau so formuliere, als hätte ich keine der normalformen angewendet?

Das Schlagwort hierfür heißt: View.

InnoDB zum Beispiel habe ich noch nie benutzt, aber nur dieses scheint diese Foreign Keys anzubieten. Das klingt schonmal nach einer Erweiterung. Ich suche ja nach einem Aha-Effekt..
Foreign Keys (FK) dienen in erste Linie der Erhaltung der referentiellen Integrität der Daten. Beispiel: Ein Kunde hat mehrere Adressen. Bei FK kann man sicherstellen, dass wenn ein Kunde gelöscht wird, alle seine Adressen mitgelöscht werden. Oder was auch geht: Ein Mandant hat mehrere Kunden - falls der Mandant gelöscht werden soll, kann das System sicherstellen, dass auch vorher alle Kunden gelöscht sein müssen.

Das ganze soll dazu dienen die Datenlogik von der Anwendung in das DBMS zu verlagern (so daß eine fehlerhafte Anwendung keine fehlerhaften Daten zurücklässt - dabei immer im Hinterkopf behalten, dass Daten von mehreren Anwendungen benutzt werden)