Referenzieren in Datenbanken

[francy_space]

Hallo,

als Neuling arbeite ich mich in die Datenbankwelt ein.

Eine Sache habe ich nicht ganz verstanden: Datenbanken sind ja dafür da, Redundanzen zu vermeiden. Sprich, ändere ich den Namen eines Kunden an einer Stelle, so möchte ich, dass die anderen Stellen diese Änderung automatisch bei sich einspeichern. Sprich, die anderen Stellen referenzieren (verweisen) auf den Wert, den ich an der einen Stelle umgeändert hatte.

Stimmt diese Logik? Danke.

 

[KitKat::new()]

Eine Sache habe ich nicht ganz verstanden: Datenbanken sind ja dafür da, Redundanzen zu vermeiden.

Dafür is Normalisierung der Tabellenstruktur innerhalb der Datenbank da.
In einer Datenbank kannst du beliebig viel Redundanz haben.

 

[LorD-AcE]

https://www.informatikzentrale.de/normalisierung.html

 

[RalphS]

Redundanz vermeiden ist nicht primär Ziel von DBMS. Aber es fällt automatisch mit ab, wenn man sich an ACID halten kann und will.

Wenn man das Ganze auftrennt nach olap und oltp, dann wird das etwas deutlicher.
Beschränken wir uns auf zweiteres, dann gibt es per Design keine Redundanz; gibt es doch welche, dann war das absichtlich Designverletzung (in Ausnahmefällen sinnvoll) oder man hat etwas falsch gemacht.

Beliebig viel Redundanz

ist allerdings pauschal inkorrekt. DBMS sind keine excel Tabellen, weder transactional noch analytical.

 

[KitKat::new()]

Aber es fällt automatisch mit ab, wenn man sich an ACID halten kann und will.

Eigentlich nicht. Das Transaktionsverhalten ist unabhängig davon was die Transaktionen aus User-Sicht inhaltlich in der Datenbank machen.
Detailierte Erklärung gibts hier: https://en.wikipedia.org/wiki/ACID#Atomicity

Beispiel: Konsistenz
Wenn eine Datenbanktransaktion Konsistenz garantiert, ist es egal wie oft ich innerhalb der Transaktion eine Redundanz drin habe.
Aus Datenbanksicht und aus Usersicht ist die Datenbank dann stetig in einem konsistenten Zustand.

Wenn ich die Redundanz über zwei Transaktionen verteile, gibts aus Datenbanksicht immmer noch eine Konsistenzgarantie, jedoch gibts Spielraum für Konsistenz aus Usersicht.

Beschränken wir uns auf zweiteres, dann gibt es per Design keine Redundanz; gibt es doch welche, dann war das absichtlich Designverletzung (in Ausnahmefällen sinnvoll) oder man hat etwas falsch gemacht.

Das ist ja schon ein Widerspruch in sich... per Design keine, aber man kanns trotzdem machen? 🙄

ist allerdings pauschal inkorrekt. DBMS sind keine excel Tabellen, weder transactional noch analytical.

Das kannst du sicher noch besser erklären, sodass ich das auch verstehe.
Es ist übrigens absolut kein Problem Excel-Tabellen in einer Datenbank nachzubilden.

 

[Tokolosh]

Ok, die Antworten beziehen sich ja alle auf die Datenbank an sich. Könnte es sein, dass damit gemeint ist, dass die Datenbank selber Redundanzen an anderer Stelle vermeidet? Dass diese so gesehen als "single source of truth" fungiert? Oder ist der Gedanke zu weit hergeholt?

Mich irritiert das Beispiel mit dem Kundennamen ein wenig in dem Zusammenhang. Also würde dort ein Kundenname so als String in mehreren Tabellen auftauchen, wäre es sowieso keine Datenbank im eigentlichen Sinne. Oder ist das Blödsinn, was ich hier verzapfe?

 

[RalphS]

@KitKat::new() wir reden aneinander vorbei. Es geht nicht um die Transaktion, es geht um die Datenbank.

Das Stichwort Transaktion fiel nur, weil explizit das analytische Modell (olap) als Gegensatz zum transaktionalen (oltp) Redundanz durchaus erlaubt.

Acidity fiel weil man natürlich hergehen kann und eine Spalte Name mit Inhalt “Peter Panda” haben kann. Die ist in sich noch nicht redundant, sorgt aber dafür, daß ich nicht ohne weiteres an deren Einzelteile komme und das wiederum begünstigt Redundanz in Form von weiteren Spalten. Dieses Mal nur den Nachnamen.

Klar kann ich excel Tabellen nachbilden.
Aber
A sehen diese in der dB völlig anders aus als in Excel - denn die Darstellung ist nicht Sache der DB, im Gegensatz zu Excel—; oder
B ich mache etwas grundlegendes falsch.

Und nein, natürlich muss ich mich nicht streng an Vorgaben halten. Würde ich das, dann könnte ich nirgends eine Summe unterbringen, weil diese Redundanz bedeutet; auch dann nicht wenn diese sich selten ändert. Stattdessen müßte sie streng per Design mit jeder Abfrage neu berechnet werden.

Macht natürlich keiner. Vor allem dann nicht, wenn man außer den transaktionalen auch analytische Funktionen benötigt, die jeweils einige Zeit zur Berechnung brauchen.

 

[KitKat::new()]

Würde ich das, dann könnte ich nirgends eine Summe unterbringen, weil diese Redundanz bedeutet; auch dann nicht wenn diese sich selten ändert.

Könntest du mit Views

Ansonsten verstehe ich nicht was du mit dem Post überhaupt sagen willst.
Vielleicht erklärst du einfach Mal was mich daran hindern soll beliebig viel Redundanz in eine DB zu packen (auch wenn es sinnlos wäre - wie auch abseits von DBs)