SQL-Problem 2. Normalform

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.

hustbaer

Martin22 schrieb:

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?

Dass ich den von dir zitierten Text verstehe kann ich nicht behaupten, nein. Weil er mMn. vollig unverständlich geschrieben ist.
Ich weiss aber sehr wohl worum es in der 2. Normalform geht.

Wikipedia schrieb:

Eine Relation ist genau dann in zweiter Normalform, wenn sie

in der ersten Normalform ist und
für jedes Attribut a der Relation gilt:
* a ist Teil eines Schlüsselkandidaten oder
* a ist von einem Schlüsselkandidaten abhängig, aber
* a ist nicht von einer echten Teilmenge eines Schlüsselkandidaten abhängig.

Welche Spalte verletzt diese Definition, und warum?

hustbaer

tenim schrieb:

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.

Es kann sinnvoll sein. Hängt u.A. davon ab wie viel Aufwand man pro Land in die Software stecken will, und wie wichtig es ist die Adressen im "bestmöglichen" Format für die jeweiligen Länder vorliegen zu haben.
Für Shops wie Amazon z.B. kann sowas Sinn machen.

Für kleinere Projekte macht es i.A. aber nicht Sinn. Weil der Nutzen meist nicht im Verhältnis zum Aufwand steht. Und weil man sich viel zu schnell mit irgendwelchen Annahmen vertut, die dann in Wirklichkeit nicht zutreffen. Der dadurch entstehende Schaden ist dann schnell grösser als der Nutzen.

Und was die vermeidbare Redundanz angeht: Es geht hier um Normalisierung, und was die Normalisierung angeht gibt es hier keine Redundanz. Ein atomarer Wert ist ein atomarer Wert, ob das jetzt ein 100 Zeichen langer String ist oder ein 4 Byte Integer macht dabei keinen Unterschied.
Und generell halte ich den Rat/Vorschlag Strings die mehrfach vorkommen in Lookup-Tables zu verlagern für problematisch. Ja, es gibt Fälle wo das Sinn machen kann, aber der Standardfall ist eher dass man sich viel Mühe für nichts macht. Und die Nachteile sind ja wohl alles andere als vernachlässigbar...
* Man sieht nur mehr Bahnhof wenn man die Tabelle direkt in einem Management Tool anguckt
* Es ist viel aufwendiger Werte per Hand zu ändern
* Man braucht ne Garbage-Collection wenn man nicht auf ewige Zeiten Müll in der DB rumschleppen will
* Man verbrät ordentlich Rechenzeit für unnötige Joins
usw.

tenim

hustbaer schrieb:

...Und die Nachteile sind ja wohl alles andere als vernachlässigbar...
* Man sieht nur mehr Bahnhof wenn man die Tabelle direkt in einem Management Tool anguckt
* Es ist viel aufwendiger Werte per Hand zu ändern
* Man braucht ne Garbage-Collection wenn man nicht auf ewige Zeiten Müll in der DB rumschleppen will
* Man verbrät ordentlich Rechenzeit für unnötige Joins
usw.

ja, kann ich unterschreiben. und wie gesagt, es trifft ja auch für die mehrzahl aller fälle so zu. aber da der op danach fragte (reduktion von gleichen strings), hab ich ihm einen weg aufgezeigt. villeicht ist es bei ihm ja gerade sinnvoll. das können wir erst wissen, wenn wir sein komplettes datenmodell und die zu erwarteten datenmengen kennen.

übrigens verwende ich diese lookup-tabellen sehr erfolgreich in einer medizinischen datenbank. dort handelt es sich um das feld "klinik" und es existierten bis vor kurzem für jeden 5.? datensatz ca. 5 verschiedene schreibweisen für die betreffende klinik. jetzt gibt es eine lookup-tabelle, aus der sie sich die betreffende klinik auswählen können. und erst wenn sie die dort nicht finden, können sie einen eintrag manuell erstellen. die fehlerrate durch mehrfacheingaben ging daduch ca. 99% nach unten. das per programmcode zu überprüfen ginge gar nicht.

in dem sinne:

keine regel ohne ausnahme.

tenim

LOL

ich sehe gerade, was bei wikipedia zu 1.nf steht:

Jedes Attribut der Relation muss einen atomaren Wertebereich haben, und die Relation muss frei von Wiederholungsgruppen sein. (Anm.: statt „atomar“ wird auch die Bezeichnung „atomisch“ verwendet.)

Das heißt, zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (relationenwertige Attributwertebereiche) sind nicht erlaubt. Damit sind auch Wiederholungsgruppen nicht zugelassen. Kurz: Kein Attributwertebereich einer Relation in 1NF kann in weitere (sinnvolle) Teilbereiche aufgespaltet werden (Beispiel: Die Adresse darf nicht als Attribut verwendet werden, sondern muss – sofern es der zugrunde liegende Prozess erfordert – in PLZ, Ort, Straße und Hausnummer aufgeteilt werden).

Dass die Relation frei von Wiederholungsgruppen sein muss, bedeutet, dass Attribute, die gleiche oder gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen.

und genau unser adressbeispiel erfüllt damit nicht mal die erste normalform da die adresse eine zusammengesetzte entität ist und nicht mehr atomar.

Zeus

tenim schrieb:

LOL

ich sehe gerade, was bei wikipedia zu 1.nf steht:

Jedes Attribut der Relation muss einen atomaren Wertebereich haben, und die Relation muss frei von Wiederholungsgruppen sein. (Anm.: statt „atomar“ wird auch die Bezeichnung „atomisch“ verwendet.)

Das heißt, zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (relationenwertige Attributwertebereiche) sind nicht erlaubt. Damit sind auch Wiederholungsgruppen nicht zugelassen. Kurz: Kein Attributwertebereich einer Relation in 1NF kann in weitere (sinnvolle) Teilbereiche aufgespaltet werden (Beispiel: Die Adresse darf nicht als Attribut verwendet werden, sondern muss – sofern es der zugrunde liegende Prozess erfordert – in PLZ, Ort, Straße und Hausnummer aufgeteilt werden).

Dass die Relation frei von Wiederholungsgruppen sein muss, bedeutet, dass Attribute, die gleiche oder gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen.

und genau unser adressbeispiel erfüllt damit nicht mal die erste normalform da die adresse eine zusammengesetzte entität ist und nicht mehr atomar.

Äh? Das sagt das in deine Stammdaten eines Kundes die Adresse nicht in einem Feld gespeichert werden darf, weil in dem Feld dann struktierte Daten enthält.

Negative Beispiel

Kunde.Adresse = { "MeineStraße 12", "123456 Ort" }

Positive Beispiel

Kunde.Adresse01.Straße = "MeineStraße"
Kunde.Adresse01.Hausnummer = "12"
Kunde.Adresse01.PLZ = "123456"
Kunde.Adresse01.Ortt = "Ort"

Und beim Positive Beispiel liegt die Adresse auch als Enität vor. Im Anderen Fall muss man sich sonst 'Adresse01' wegdenken.

Ich habe es jetzt so gelöst:

Alle Straßen stehen redundanzfrei in einer Tabelle:

Str_ID
Strassenname

Alle Orte stehen redundanzfrei in einer Tabelle:

Ort_ID
Ortname

Die Tabelle Adresse sieht so aus:

Adr_ID
PLZ
Ort_ID
Str_ID

Die Adressen-Tabelle:

ID
Anrede_ID // Herr, Frau
Titel_ID // Dr., Prof. ...
Zusatz_ID // Ing., Dipl.
Vorname
NamZusatzID // van, von, an der ...
Name
Adr_ID
...

Die Daten für die Tabelle Adresse wurden mit Osmosis aus OSM generiert.

tenim

find ich gut, deine struktur. sicher, es ist auf eine art mehr arbeit, aber dafür insgesamt sauberer.

p.s. wenn du ein wirklich gutes modellierungstool für erm diagramme suchst, das datenbanken auch reverse-engineeren kann (diagramme aus bestehenden db´s generieren) dann nimm das:

http://www.datanamic.com/dezign/

ist imho mit abstand das beste tool auf dem markt, beherrscht den krähenfuss syntax und kann zig datenbanken ansprechen (alle wichtigen). leider kann erst die professional-version das reverse engineering.

nachteil: das tool benutzt drm, du musst es glaub ich erst aktivieren (falls dich das stört).

MFK

Martin22 schrieb:

Ich habe es jetzt so gelöst:

Na, hoffentlich musst du nie internationale Adressen speichern.

Hast du auch eine Straße namens Postfach?