SQL-Problem 2. Normalform

hustbaer

ps:
Wenn du meinst dass der Vorschlag von tenim auch nur irgendwas bezüglich Normalisierung verbessert, dann hast du Normalisierung nicht verstanden.

Einen einzelnen String ("Or_Ort") in einem Table zu packen und mit einem Surrogate ("Or_ID") zu versehen taugt höchstens zum Speicherplatz Sparen und CPU-Zeit Verheizen.

Doch, ich denke schon, dass ich die Normalisierung verstanden habe.

Deshalb schwebte mir auch eher so etwas vor:

In der Adresstabelle steht nur die PLZ.

Zusätzlich gibt es zwei Tabellen:

tblPLZ
------------
plz - ort_id

tblORTE
-------------------
ort_id | ort_name

hustbaer schrieb:

ps:
Wenn du meinst dass der Vorschlag von tenim auch nur irgendwas bezüglich Normalisierung verbessert, dann hast du Normalisierung nicht verstanden.

Einen einzelnen String ("Or_Ort") in einem Table zu packen und mit einem Surrogate ("Or_ID") zu versehen taugt höchstens zum Speicherplatz Sparen und CPU-Zeit Verheizen.

hustbaer

Wenn du die Normalformen verstanden hast, dann fehlt's vielleicht an der Erfahrung was man alles NICHT über Adressen annehmen sollte.
Anyway, ich klinke mich aus, da ich nicht den Eindruck habe dass du wirklich 'was dazulernen willst.

tenim

Der Strassenname alleine ist keine Entity.

warum? wenn man es genau aufschlüsselt ist alles eine entität.
beispiel:

* ein ort hat 0 bis viele straßen
* in einer strasse gibt es 0 bis viele hausnummern

den straßennamen selbst in einer tabelle zusammenzufassen macht absolut sinn, egal ob die straße in china, polen oder feuerland liegt. wenn sie exakt gleich heißt wie eine andere kann man das ganze in einem lookup-tabelleneintrag zusammenfassen. das spart extrem speicherplatz, vor allem wenn man millionen von datensätzen hat.

und wenn sich herausstellt, das zu einem ort die straße xyz falsch eingetragen wurde (rechtschreibfehler) und es mehrere andere datgensätze gibt die sich auch darauf beziehen weil bei denen es zufällig stimmt, dann liegt man für diesen einen datensatz einfach einen neuen eintrag an.

wikipedia:

Unter Normalisierung eines relationalen Datenschemas (Tabellenstruktur) versteht man die Aufteilung von Attributen (Tabellenspalten) in mehrere Relationen (Tabellen) gemäß den Normalisierungsregeln (s. u.), so dass eine Form entsteht, die keine vermeidbaren Redundanzen mehr enthält.

und 1000 mal "münchen" in einer tabelle ist eine vermeidbare redundanz.

MFK

tenim schrieb:

warum? wenn man es genau aufschlüsselt ist alles eine entität.
beispiel:

* ein ort hat 0 bis viele straßen
* in einer strasse gibt es 0 bis viele hausnummern

Du triffst hier falsche Annahmen über Adressformate. Es gibt Adressen ohne Straßenname oder Hausnummer.

tenim schrieb:

den straßennamen selbst in einer tabelle zusammenzufassen macht absolut sinn, egal ob die straße in china, polen oder feuerland liegt.

Und wenn du dann die Adresse in Fragmente zerlegt hast, wie stellst du sicher, dass du sie wieder zusammensetzen kannst? Wie bildest du beispielsweise ab, dass bei einer französischen Adressen die Hausnummer vor dem Straßennamen steht?

tenim

Du triffst hier falsche Annahmen über Adressformate. Es gibt Adressen ohne Straßenname oder Hausnummer.

dann sind diese beiden felder halt null und das anderen feld, welches für diese fälle existiert hat einen inhalt.

Und wenn du dann die Adresse in Fragmente zerlegt hast, wie stellst du sicher, dass du sie wieder zusammensetzen kannst? Wie bildest du beispielsweise ab, dass bei einer französischen Adressen die Hausnummer vor dem Straßennamen steht?

ich würde in der adresstabelle noch das land vermerken und dann in der abfrage
mit "case when" den straßen-string landabhängig zusammenbauen.

Was mit einer sauberen Trennung von Ort, Straße, Postleitzahlen und Vorwahl möglich ist lässt sich auf strassenkatalog.de bewundern.

Genau diese saubere Trennung hätte ich gern in meiner Adressverwaltung

MFK

tenim schrieb:

dann sind diese beiden felder halt null und das anderen feld, welches für diese fälle existiert hat einen inhalt.

Das wird bestimmt ein übersichtliches Eingabeformular.

tenim schrieb:

ich würde in der adresstabelle noch das land vermerken und dann in der abfrage
mit "case when" den straßen-string landabhängig zusammenbauen.

Vergiss nicht, dass dein "case when" auch die ganzen optionalen Adressbestandteile richtig zusammensetzen muss. Ich wünsche schon mal viel Spaß.

Martin22 schrieb:

Was mit einer sauberen Trennung von Ort, Straße, Postleitzahlen und Vorwahl möglich ist lässt sich auf strassenkatalog.de bewundern.

Dieses Google-Frontend scheitert an den beiden Straßen mit demselben Namen und derselben Postleitzahl, die es in zwei verschiedenen Orten gibt. Und natürlich ist es auf Adressen in Deutschland beschränkt. Wenn dir das reicht, bitte.

tenim

Das wird bestimmt ein übersichtliches Eingabeformular.

wo ist das problem? was soll daran unübersichtlich sein?

[land] [plz] [ort] [straße] [nr] [adresszusatz1]

oder meinst du wegen der vielen felder? hast du schon mal mit SAP-R3 gearbeitet? das ist unübersichtlich.
auderdem ist diese version sogar von vorteil: man kann die eingegebenen daten viel einfacher auf korrektheit testen. das wäre mit einem string, der alles enthält wesentlich aufwändiger.

Vergiss nicht, dass dein "case when" auch die ganzen optionalen Adressbestandteile richtig zusammensetzen muss. Ich wünsche schon mal viel Spaß.

was soll daran schwer sein?
select
case when land='DE' then str+hnr else
case when land='FR' then hnr+str else
case when land='Uranda Burundi' then adresszusatz1+hnr+zusatz4+str else
...alle anderen ausnahmen
end
end
end
AS adresse
from tabelle

so what?

SG1

tenim schrieb:

was soll daran schwer sein?
select
case when land='DE' then str+hnr else
case when land='FR' then hnr+str else
case when land='Uranda Burundi' then adresszusatz1+hnr+zusatz4+str else
...alle anderen ausnahmen
end
end
end
AS adresse
from tabelle

Das funktioniert ja nichtmal in Mannheim. Ja, da kann man jetzt 'ne eigene Ausnahme für hinzufügen. Nur: Wie viele Ausnahmen willst Du noch hinzufügen? Ich tippe mal auf 'ne mindestens dreistellige Zahl, wenn nicht mehr. Siehe https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

MFK

EDIT: SG1 hat den Link schon gepostet.

hustbaer

tenim schrieb:

und 1000 mal "münchen" in einer tabelle ist eine vermeidbare redundanz.

Welche Normalform soll es verletzen? Und zitiere mir bitte die Regel die verletzt wird.

Guckst du hier: http://home.f1.htw-berlin.de/scheibl/db/RDBMS/normalform.htm#2nf

hustbaer schrieb:

tenim schrieb:

und 1000 mal "münchen" in einer tabelle ist eine vermeidbare redundanz.

Welche Normalform soll es verletzen? Und zitiere mir bitte die Regel die verletzt wird.

SG1

Martin22 schrieb:

Guckst du hier: http://home.f1.htw-berlin.de/scheibl/db/RDBMS/normalform.htm#2nf

Die Definition auf der Seite ist richtig. Aber Du hast sie anscheinend nicht verstanden.

Wobei die Seite eh lustig ist:

Kann ich denn nicht einfach durch Einführung eines chaotischen Schlüssels die 2NF automatisch erfüllen?
Nein, denn dann liegt automatisch ein Verstoß gegen die 3NF vor.

wtf?!

hustbaer

@Martin22
Ich fürchte du musst mir schon mit eigenen Worten genau beschreiben was deiner Meinung nach die Verletzung der 2NF sein soll, wenn du möchtest dass ich dich ernst nehme.

Die 2NF wird nämlich ganz sicher nicht alleine dadurch verletzt dass in einer bestimmten Tabelle in einer bestimmten String-Splate mehrfach der selbe Wert drinnen steht. Genausowenig wie es die 2NF verletzen würde wenn in einer Integer-Spalte mehrfach der selbe Wert steht.

=> Du hast einfach Normalisierung nicht verstanden

Nochmal: Normalisierung hat nichts mit Surrogates zu tun.

tenim

Das funktioniert ja nichtmal in Mannheim.

sicher funktioniert das. hast du wenigstens anfängerkenntnisse in sql?
und ja, polemik (mannheim) ist bei vielen oft das einzige mittel, wenn sie nicht mehr weiter wissen. arm.

Welche Normalform soll es verletzen? Und zitiere mir bitte die Regel die verletzt wird.

ich habe nicht gesagt, das eine normalform verletzt wurde, sondern nur, das es eine redundanz ist, die durch eine lookup-tabelle vermieden werden kann und das man damit speicherplatz spart.

wikipedia zu redundanzen in datenbanken (wichtiger teil ist fett):

Durch Normalisierung des Datenbankschemas können Redundanzen weitgehend vermieden werden. Es gibt auch Redundanzen, die unvermeidbar sind (zum Beispiel Schlüsselredundanzen) und daher als notwendiges Übel in Kauf genommen werden. Es gibt auch Redundanzen, die in Kauf genommen werden, weil deren Vermeidung einen zu hohen Aufwand im Verhältnis zu ihrer Problematik darstellen würde, wie zum Beispiel das mehrfache Auftreten eines Attributwertes oder die doppelte Speicherung des Namens Müller für Herrn Müller und für Frau Müller.
Die absichtliche Inkaufnahme von Redundanz zur Gewinnung einer besseren Leseleistung nennt man Denormalisierung.

das beispiel mit münchen oder straßennamen ist so eine sache mit absichtlicher inkaufnahme von redundanzen, da es oft mehr aufwand machen würde mit lookup-tabellen zu arbeiten als ohne. deshalb schrieb ich auch in meinem ersten antwortpost zum op

ob das dann alles sinnvoll ist, steht auf einem anderen blatt.

SG1

tenim schrieb:

Das funktioniert ja nichtmal in Mannheim.

sicher funktioniert das. hast du wenigstens anfängerkenntnisse in sql?

Hast Du meinen Link überhaupt angeklickt? Meine Kritik bezog sich nicht auf Deine SQL-Syntax. Meine Kritik bezog sich darauf, dass Du davon ausgegangen bist, dass eine Adresse immer eine Straße beinhaltet.

und ja, polemik (mannheim) ist bei vielen oft das einzige mittel, wenn sie nicht mehr weiter wissen. arm.

ROFL

Zitat Prof. Dr.-Ing. H.-J. Scheibl

2. Normalform (2NF)

Wiederholungen in waagerechter Richtung (in den Spalten) sind Verstöße gegen die 1. Normalform. Wiederholungen in senkrechter Richtung (in den Zeilen) weisen auf einen Verstoß gegen höhere Normalformen hin. Dies ist aber nur eine hinreichende aber keine notwendige Bedingung.

Letzteres erkennen wir daran, dass auch im Wohnort der Mitarbeiter Wiederholungen (München) auftreten. Bei einem Umzug einer Entität (d. h., eines Mitarbeiters) muss aber nur dessen Wohnort geändert werden. Der Umzug einer Kostenstelle sorgt aber für eine vielfache Änderung. Auch der gemeinsame Name zweier Kostenstellenleiter ist zufällig (es sei denn, der Stellenplan erlaubt die Leitung mehrerer Abteilungen durch eine Person).

Das solltest du jetzt aber verstehen, oder?

hustbaer schrieb:

@Martin22
Ich fürchte du musst mir schon mit eigenen Worten genau beschreiben was deiner Meinung nach die Verletzung der 2NF sein soll, wenn du möchtest dass ich dich ernst nehme.

Die 2NF wird nämlich ganz sicher nicht alleine dadurch verletzt dass in einer bestimmten Tabelle in einer bestimmten String-Splate mehrfach der selbe Wert drinnen steht. Genausowenig wie es die 2NF verletzen würde wenn in einer Integer-Spalte mehrfach der selbe Wert steht.

=> Du hast einfach Normalisierung nicht verstanden

Nochmal: Normalisierung hat nichts mit Surrogates zu tun.

SG1

Martin22 schrieb:

Das solltest du jetzt aber verstehen, oder?

Du kommst ganz schön arrogant daher.

tenim

Meine Kritik bezog sich darauf, dass Du davon ausgegangen bist, dass eine Adresse immer eine Straße beinhaltet.

wie kommst du darauf das ich davon ausgegangen bin? wo hab ich das geschrieben?
im verlauf der diskussion schälte sich heraus (hast du überhaupt alle posts gelesen?) das eine adresse auch OHHNE straße und hausnummer existieren kann.

siehe dazu erster post von "MKF"

Du triffst hier falsche Annahmen über Adressformate. Es gibt Adressen ohne Straßenname oder Hausnummer.

darauf habe ich geantwortet und adresszusätze eingeführt die anhand von "case when" dynamisch rekombiniert werden können so das alle möglichkeiten abdeckbar sind. ob das jetzt in ALLEN szenarien sinnvoll ist sei dahingestellt. es ist aber möglich und auch oft sinnvoll.