Sinnkrise: Relationen in Datenbanken

[Aranha]

Tag zusammen.

Ich habe eine Sinnkrise in Bezug auf Relationen in Datenbanken:

Vor vielen Jahren in der Lehre habe ich Datenbankapplikationen programmiert. Da habe ich dann MS-SQL Datenbanken entworfen, und Relationen im Designer hergestellt. Also z.B.: Feld A in Tabelle 1 hat ein 1:n Relation zum Primärindex von Tabelle 2, und n:n Verbindungen über Bewegungstabellen realisiert, usw.

Nun betreue ich eine Firma, die haben sich eine sehr umfangreiche Datenbank in Access zusammengeschnürt. Die DB wird in Access gepflegt, und für Web wird eine SPL-Dump für den MySQL Server gemacht. An der Entwicklung dieser Geschichte war ich nicht beteiligt, funktioniert trotzdem / deshalb

Nun war die Aufgabe, von der DB mal ein Diagramm zu erstellen. Ich dachte, dass sei mit dem DBDesigner kein Problem. Der zeigt mir jedoch keinerlei Relationen zwischen den Tabellen an. Access habe ich diese Info auch nicht entlocken können.

Auf Nachfrage stellte sich raus, dass die so etwas auf Design-Ebene gar nicht gemacht haben, sondern sich die Relationen nur denken und in den Abfragen und Formularen entsprechend damit umgehen. Deren Gegenfrage, wofür man so was denn überhaupt bräuchte (außer für dokumentarische Zwecke), hat mich ziemlich dumm aussehen lassen.

Ich Frage mich mittlerweile selbst, ob die Definition von Beziehungen im Designer, wie 1:n wirklich nur dokumentarischen Charakter hat, denn ich kann nicht erklären welche Technische Konsequenz oder Möglichkeiten sich daraus ergeben, wenn ich es doch einfach machen kann wie die: Einfach den Primärindex Wert des Tupels der zu Verknüfenden Tabelle eintragen, und die Verknüpfung ist hergestellt.

Ihr seht, ich bin ein wenig raus aus der DB-Geschichte, also helft mir doch bitte auf die Sprünge.

Vielen Dank im Voraus,

Aranha

[flashpixx]

Eine Antwort wofür man das brauchst ist z.B. anhand des Bsps zu sehen:

Du hast eine 1:1 Relation zwischen Tabelle A und B (A ist die Mastertabelle).

Wenn ich nun auf A einen Datensatz lösche und keine Constraints anhand von Schlüsseln habe, dann habe ich auf B Datensätze die nicht mehr von A referenziert werden. Umgekehrt kannst Du Dir vorstellen, wenn auf B ein Datensatz eingefügt wird, muss dieser eine Referenz auf A haben.

Gerade bei einer komplexen Datenbank muss man das Löschen nur auf der Mastertabelle vornehmen und alle abhängigen Datensätze werden ebenfalls durch das DBMS (cascade) gelöscht. Wenn man als Designer der DB irgendwo verbieten möchte, dass das Löschen durchgeführt wird, lässt man das Cascade ins leere laufen bzw erzeugt dann einen Fehler, wobei dann die gesamte Löschkette abgebrochen und wieder rückgängig gemacht wird (Transaktionssicherung)

Machst Du das eben nicht über die Datenbank, dann muss diese gesamte Logik in die Anwendung verlagert werden, was fehleranfälliger ist, vor allem wenn der Code nicht konsistent für alle Anwendungsteile gehalten wird

Schlüsselbeziehungen mit entsprechenden Constraints kann / soll man dafür benutzen, um den Datenstand konsistent zu halten.

Bearbeitet 3. Juli 2010 von flashpixx

[afo]

flashpixx hat natürlich vollkommen recht. Dazu kommt aber, daß nicht jedes DBMS das unterstützt. mySQL mit der Standard-Storage-Engine myISAM kann das zum Beispiel nicht.

Aber so wie du das schilderst ist die Wahrung der referenziellen Integrität wohl im Design vorgesehen. Die implementierung erfolgt nur von Hand.

[flashpixx]

mySQL mit der Standard-Storage-Engine myISAM kann das zum Beispiel nicht.

Dafür hat ja mySQL auf InnoDB gesetzt, obwohl das im Vergleich zu anderen Systemen Postgres, Oracle, MS doch noch einige Schwachstellen hat

[DocInfra]

Kann es vielleicht sein, dass die DB nur ein einzige Tabelle mit allen Informationen enthält?

[dbwizard]

Kann es vielleicht sein, dass die DB nur ein einzige Tabelle mit allen Informationen enthält?

-Dann war ein Java Programmierer am Werk... :-)

*wegrenn...*

[afo]

Kann es vielleicht sein, dass die DB nur ein einzige Tabelle mit allen Informationen enthält?

Der Op spricht eigentlich von Tabellen. Von daher gehe ich davon aus, daß die auch ohne explizite Relationen halbwegs normalisiert sind. Sonst wäre das alles ein bisschen arg...

Das InnoDB das kann, wissen aber nicht unbedingt alle. Und manche kennen InnoDB vielleicht auch garnicht. Insbesondere, wenn es sich um eine ältere Anwendung handelt.

Und wie du richtig schriebst ist Inno bei weitem nicht perfekt. So wird auch teilweise lieber die Doku angepasst, als ein Bug gefixt.

[dr.dimitri]

-Dann war ein Java Programmierer am Werk... :-)

*wegrenn...*

Naja die .Net'ler stehen uns Javafuzzis mittlerweile ja in nichts mehr nach

Ergänzend zu flashpixxs Aussage, sind PK-FK Constraints in einer Multiuser Umgebung die einzig sichere Möglichkeit die Konsistenz der Daten sicherzustellen - es sei denn, man sperrt alle betroffenen Tabellen und lässt immer nur eine Änderung gleichzeitig zu- Diese Anwendung wird das Monatsende sicherlich nicht überleben...

Beispiel:

Session A löscht Satz 1 sowie den (fachlich) untergeordneten Satz 1.1.

Session B prüft gleichzeitig, ob Satz 1 noch vorhanden ist, was erfolgreich ist, da Session A noch nicht committet hat und daher die Löschung noch nicht für andere Sichtbar ist.

Session A comittet jetzt, während Session B den Satz 1.2 insertet im festen Glauben, dass der übergeordnete Satz 1 noch vorhanden ist.

Damit sind die Daten inkonsistent und keiner weiß warum es meistens funktioniert und manchmal auch wieder nicht.

Verwendet man RI, so kümmert sich die Datenbank darum, dass entsprechende Fehlermeldungen hochkommen sofern man das versucht.

Allerdings nimmt einem RI nach wie vor nicht ab, optimistisches oder pessimistisches Locking in der Anwendung zu implementieren, da es ansonsten immer noch zu einem sog. Lost Update kommen kann. Die Daten sind dann zwar technisch konsistent der Anwender wundert sich aber, warum die Daten weg sind obwohl er fehlerfrei speichern konnte.

Dim