Aufbau meiner Datenbank/Tabelle - Verbessern? So lassen?

In dem Anwendungskontext wird keine Adress-ID benötigt.
Das habe ich auch nicht behauptet. Ich wollte nur das "bleibt einem gar nichts anderes übrig" aus Posting #15 von @mihe7 relativieren. Er hat aber ein reales Problem angesprochen und das:
tblZahlungseingänge
KnId,Datum_Zahlungseingang

Jede einzelne Rechnung "besitzt" dann halt die Adresse die in tblKunde jeweils gespeichert ist.
ist keine Lösung dafür.
 
Ganz einfach frage. Was ist wenn der Kunde seine Zahlungsmethoden ändern will? Dann kannst du im Moment nicht wissen ab wann er die neue Zahlungsverzug benutzen möchte, BTW wie lange die alte gilt. Deswegen auch hier eine eigene Tabelle mit der Zahlungsart in einer 1:n Beziehung und ein paar mehr Angaben als du sie gerade hast. U.a. Eben. Ein „startDate“ oder sowas.

Gruß

Claus
 
Ganz einfach frage. Was ist wenn der Kunde seine Zahlungsmethoden ändern will? Dann kannst du im Moment nicht wissen ab wann er die neue Zahlungsverzug benutzen möchte, BTW wie lange die alte gilt. Deswegen auch hier eine eigene Tabelle mit der Zahlungsart in einer 1:n Beziehung und ein paar mehr Angaben als du sie gerade hast. U.a. Eben. Ein „startDate“ oder sowas.

Gruß

Claus
Das was ich hier bisher an Tabellen genannt habe ist nur ein Teil der Datenbank. Über eine Tabelle tblZugang wird das Datum erfasst wann ein neuer Kunde dazugekommen ist. Ändert der Kunde die Zahlungsmethode wird das Zugangsdatum aktuallisiert. Er wird quasi als Neuer Kunde behandelt. Der Anwender wird darüber in Kenntniss gesetzt. In dem Anwendungskontext ist das erlaubt.
 
Und in drei Monaten gibts dann die Anforderung, dass es so doch nicht geht, und man beißt sich ins Bein, dass man es nicht von Anfang an „richtig“ gemacht hat ;P
 
Aber durch weitere Normalisierung ergeben sich Alternativen, z.B. indem man die Adressdaten in eine eigene Tabelle auslagert. Beim Umzug erstellt man eine neue Adresse und verknüpft deren ID mit dem Kundenstamm. Alte Rechnungen behalten ihre Adress-ID, neue Rechnungen bekommen die neue. Dann sind wie üblich wieder nur die Schlüssel redundant.
Im Prinzip hast Du völlig Recht. Wir sind irgendwann zu dem Schluss gekommen, dass wir Dokumente auch als solche behandeln: wir speichern die Inhalte komplett inkl. aller Daten separat und damit in der Regel redundant. Das ist jetzt zig Jahre her, vielleicht sollte ich mal darüber nachdenken, ob ich das heute wieder so machen sollte :)
 
Das was ich hier bisher an Tabellen genannt habe ist nur ein Teil der Datenbank. Über eine Tabelle tblZugang wird das Datum erfasst wann ein neuer Kunde dazugekommen ist. Ändert der Kunde die Zahlungsmethode wird das Zugangsdatum aktuallisiert. Er wird quasi als Neuer Kunde behandelt. Der Anwender wird darüber in Kenntniss gesetzt. In dem Anwendungskontext ist das erlaubt.
Hm, ging es bei der Frage
Klar es ist irgendwie übersichtlicher, aber dies kann ja eigentlich kein Grund sein eine etwas größere Tabelle zu splitten ?
nun um die Nachteile denormalisierter Daten oder nur darum, ob du mit den Nachteilen leben kannst? Man kann natürlich immer technische oder organisatorische Workarounds finden und manchmal kann das auch der pragmatischere Weg sein. Das ändert aber doch nichts an den prinzipiellen Nachteilen. Normalerweise entstehen auch nach der Einführung noch viele neue Anforderungen. Mit vernünftig normalisierten Daten ist man da in der Regel flexibler aufgestellt, als wenn man aufpassen muß, dass alte Workarounds nicht platzen.
 
Hm, ging es bei der Frage
nun um die Nachteile denormalisierter Daten oder nur darum, ob du mit den Nachteilen leben kannst?
Mir ging es um die Nachteile von "großen" Tabellen gegenüber das Splitten einer solchen Tabelle (
so wie es mir in #4 vorgeschlagen wurde). Ich hatte gedacht man splitten immer aufgrund von Normalisierung. Da sich in dem Beispiel aber der Normalisierungsgrad nicht geändert, war ich ein wenig verwundert.

Geändert an der Struktur wird jetzt eh nichts mehr :D Auch wenn es hinsichtlich der Wartung nicht optimal ist ^^
 
Zuletzt bearbeitet:
Mir ging es um die Nachteile von "großen" Tabellen gegenüber das Splitten einer solchen Tabelle
Das liegt auf der Hand: werden thematisch nicht zusammengehörige Attribute in einer Tabelle zusammengefasst, führt man für diese weitgehend unabhängigen Attribute eine Abhängigkeit ein. Sie können also weder unabhängig voneinander verändert werden, noch kann der Zugriff unabhängig geregelt werden.

Da sich in dem Beispiel aber der Normalisierungsgrad nicht geändert, war ich ein wenig verwundert.
Das Beispiel ist in 3. NF, Deine Tabelle aus #1 dagegen nicht.
 
Das Beispiel ist in 3. NF, Deine Tabelle aus #1 dagegen nicht.
Hm, da bin ich anderer Meinung. Dass die Tabelle aus #1 mindestens in der 2. Nf ist, sind wir uns einig, oder ? Die Bedingung für die 3. Nf ist die, dass unter den Nicht-Schlüssel-Attributen keine Abhängigkeiten herrschen. Sprich: Ich kann nicht von einem Attribut auf das andere schließen. Das sollte meiner Meinung eigentlich der Fall sein. Ich kann lediglich anhand von einzelnen Attributen den Werteberech anderer Attribute bestimmen. Beispielsweise bei der Bezahlung: Falls ein Kunde ein Barzahler ist, dann kann ich sagen, dass der Zahlungsintervall !null ist. Ich kann aber nicht explizit sagen, dass es ein Wöchentlicher/Monatlicher etc. bezahler ist.
 
@jhjh Die Überlegung ist gut (daher der Like), denn formal betrachtet ist das keine funktionale Abhängigkeit, weil für einen Wert aus Polygon der Kreis nicht eindeutig bestimmbar ist.

Damit habe ich allerdings ein Problem, denn eine erhebliche Abhängigkeit zwischen Polygon und Kreis ist nicht von der Hand zu weisen, schließlich existiert eine funktionale Abhängigkeit für alle Polygon != null (bzw. Keis != null).

Wie sich der Widerspruch auflösen lässt: Du hast ein zusätzliches Attribut, das in der Tabelle fehlt, weil Du es aus den Werten implizit ableitest, nämlich den Typ. Wenn Du also gedanklich den Typ mit in die Tabelle aufnimmst, dann folgt aus Polygon != null && Kreis == null => Typ = 'Polygon' und aus Polygon == null && Kreis != null => Typ = 'Kreis'.
 
Ich hatte mal ein Attribut 'Typ' drinn. Hatte ich aber entfernt, weil dieser unnötig ist, da wie du schon sagtest, ich dies aus den Werten implizit ableiten kann. :D Dass eine gewisse Abhängigkeit zwischen Kreis und Polygon (und auch zwischen anderen Attributen) herrscht ist mir klar, nur halt irgendwie keine"vollständige Abhängigkeit" :)
 
Dort wäre das Attribut Typ (bzw. Art) aber nicht überflüssig. Auf jeden Fall ist es interessant zu sehen, dass man durch das Entfernen von Attributen formal eine NF herstellen kann, die sich bei Abbildung des konzeptionellen Modells nicht ergeben würde.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben