Probleme bei Normalisierung der Tabelle

[Christoph]

Hi zusammen,

ich beschäftige mich gerade mit dem Datenbankentwurf zur Verwaltung von
ca. 600 Artikeln, diese sind wiederum in fünf Produktgruppen unterteilt. Hier ist die Ausgangstabelle (Primärschlüssel ist Art.Nr.):

Art.-Nr.|Bezeichnung|Produktgruppe|Langtext|Größe|Werbeanbringung|Bild
UPD-xx   Schlauchb   Umhängeband   UPD-mitx 10    Siebdruck       jpg
LH       VIP-Karte   Namensschild  LH-mit.. Anfra auf Anfrage     jpg
CS-yyy   Lifestyle    Sonnenbrille CS-mit.. Anfra auf Anfrage     jpg
CI-zzz   Anhänger     LED          CI-mit.. Anfre auf Anfrage     jpg
CI-www   Diverse      WerbepräsenteCI-mit.. Anfra auf Anfrage     jpg

Nun möchte ich die vorgenannte Tabelle nach den 3 Normalisierungsvor-
schriften überprüfen bzw. umformen, habe aber ein Verständnisproblem zu Normalisierungsvorschrift 2 und 3. Wie muss ich hier ansetzen, alle Daten könnten doch in einer Tabelle enthalten bleiben, oder?
Unter: http://www.little-idiot.de/mysql/mysql-255.html habe ich mir die Info schon durchgelesen, nur noch nicht ganz verstanden.

Danke für den Denkanstoss
Christoph

[Matze]

Moin.

Nun möchte ich die vorgenannte Tabelle nach den 3 Normalisierungsvor-
schriften überprüfen bzw. umformen, habe aber ein Verständnisproblem zu Normalisierungsvorschrift 2 und 3. Wie muss ich hier ansetzen, alle Daten könnten doch in einer Tabelle enthalten bleiben, oder?

Die zweite und dritte Normalisierungsvorschriften bewirken nunmal, dass manche Daten in weitere Tabellen kopiert werden, um Redundanzen zu verringern.
Wenn du deine Daten in einer Tabelle behalten willst solltest du deine Datenbank nicht normalisieren.

Matze

[Christoph]

Ist es denn hier angebracht, alles in einer Tabelle zu lassen, oder
können nachher Fehler entstehen? Ich möchte es von Anfang an richtig
machen!

Christoph

Datenbank nicht normalisieren.

Matze

[Matze]

Art.Nr.|Bezeichnung|Produktgruppe|Langtext|Größe|Werbeanbringung|Bild
UPD-xx   Schlauchb   Umhängeband   UPD-mitx 10    Siebdruck       jpg
LH       VIP-Karte   Namensschild  LH-mit.. Anfra auf Anfrage     jpg
CS-yyy   Lifestyle    Sonnenbrille CS-mit.. Anfra auf Anfrage     jpg
CI-zzz   Anhänger     LED          CI-mit.. Anfre auf Anfrage     jpg
CI-www   Diverse      WerbepräsenteCI-mit.. Anfra auf Anfrage     jpg

Das eigentliche Ergebnis ist bei einer normalisierten, und einer nicht normalisierten Datenbank das gleiche.
In deinem Beispiel sehe ich aber, dass bei der Größe beim Artikel CI-zzz "Anfre" statt "Anfra" steht, und ich denke einfach mal, dass das ein Tippfehler ist.
Solche Flüchtigkeitsfehler würden durch Normalisieren dazu führen, dass es entweder bei allen Falsch ist, oder bei allen Richtig.

[Christoph]

Ja, stimmt ist ein Schreibfehler!

Nur, was meinst du mit ...durch Normalisieren... allen Falsch oder
Richtig?

Christoph

Normalisieren dazu führen, dass es entweder bei allen Falsch ist, oder bei allen Richtig.

[Matze]

Es sieht zum Beispiel in deiner Tabelle so aus, als könnte man Größe, Werbeanbringung und Bild in eine zweite Tabelle schreiben, und über eine id mit der ersten verknüpfen.

Dann hättest du:

Tabelle 1:
Art.-Nr.|Bezeichnung|Produktgruppe|Langtext|Typ
UPD-xx   Schlauchb   Umhängeband   UPD-mitx 1
LH       VIP-Karte   Namensschild  LH-mit.. 2
CS-yyy   Lifestyle    Sonnenbrille CS-mit.. 2
CI-zzz   Anhänger     LED          CI-mit.. 2
CI-www   Diverse      WerbepräsenteCI-mit.. 2

Tabelle 2:
Typ|Größe|Webeanbringung|Bild
1   10    Siebdruck      jpg
2   Anfra auf Anfrage    jpg

Wenn du nun statt Anfra aus Versehen Anfre in die Tabelle schreibst ist der Fehler bei allen Artikeln mit dem Typ 2

[Ilja]

yo,

Die zweite und dritte Normalisierungsvorschriften bewirken nunmal, dass manche Daten in weitere Tabellen kopiert werden, um Redundanzen zu verringern.

primär geht es in der 2. und 3. normalform um abhängigkeiten der daten und nicht darum, alle redundanzen zu entfernen.

Ilja

[Ludger]

Hi,

primär geht es in der 2. und 3. normalform um abhängigkeiten der daten und nicht darum, alle redundanzen zu entfernen.

richtig, es kann sogar sein, dass auf der bestehenden Datenbasis ueberhaupt keine Redundanzen entfernt werden. (Was aber nicht sein kann, ist, dass die Datenbasis redundanter wird.   ;-)

Gruss,
Ludger

[dedlfix]

ich beschäftige mich gerade mit dem Datenbankentwurf zur Verwaltung von
ca. 600 Artikeln, diese sind wiederum in fünf Produktgruppen unterteilt. Hier ist die Ausgangstabelle (Primärschlüssel ist Art.Nr.):

[...]

... alle Daten könnten doch in einer Tabelle enthalten bleiben, oder?

Ja, so wie du das gemacht hast sieht das erstmal nicht ganz schlecht aus.
Deine Tabelle beinhaltet Artikel mit diversen Eigenschaften, die nur zum Artikel gehören.

Obsthändler Krämer mischt in seinem Entwurf Kundendaten, Produktdaten und Bestelldaten und erhält damit Redundanzen und Probleme.

Folgendes Szenario:
Die Webseite deines Onlineshops soll zuerst die Produktgruppen zusammen mit einem Erläuterungstext und einem Icon anzeigen. Diese Daten sollen aus der DB abgefragt werden. Der Kunde wählt eine Produktgruppe und sieht dann alle Artikel daraus. Sprich: Jeder Artikel ist einer Produktgruppe zugeordnet.

Dafür brauchst du zwei Tabellen:
Tabelle Produktgruppe mit den Feldern ID, Name, Erlaeuterung, Icon, ...
Tabelle Artikel mit den Feldern ID, Bezeichnung, Langtext, ..., ID_Produktgruppe

Der Name der Produktgruppe gehört nicht in die Tabelle Artikel, sondern wird über ID_Produktgruppe mit der ID aus der Tabelle Produktgruppe verknüpft.

Weiterhin empfiehlt es sich Datenhaltungsspezifika nicht mit den Daten zu vermischen. Der Primärschlüssel wird benötigt, um einen _Datensatz_ anzusprechen, nicht einen _Artikel_.
Man nimmt deshalb als Primärschlüssel etwas generisches (Zahl, GUID, ...). Das gleiche gilt für Felder, die der Verknüpfung dienen (ID_Produktgruppe statt deren Name).

Wenn dir später auffällt, dass die Artikelnummer nicht stimmt und du die änderst, bekommst du ein Problem mit den Daten von Bestellungen, die dann auf eine nicht mehr existierende Artikelnummer verweisen. Ebenso verhält es sich wenn du den Namen einer Produktgruppe ändern willst.

[Ludger]

Hi,

Art.-Nr.|Bezeichnung|Produktgruppe|Langtext|Größe|Werbeanbringung|Bild
UPD-xx   Schlauchb   Umhängeband   UPD-mitx 10    Siebdruck       jpg
LH       VIP-Karte   Namensschild  LH-mit.. Anfra auf Anfrage     jpg
CS-yyy   Lifestyle    Sonnenbrille CS-mit.. Anfra auf Anfrage     jpg
CI-zzz   Anhänger     LED          CI-mit.. Anfre auf Anfrage     jpg
CI-www   Diverse      WerbepräsenteCI-mit.. Anfra auf Anfrage     jpg

Nr. = Primaerschluessel (Tipp: eventuell einen bedeutungsfreien Primaerschluessel "hinzubauen")
Bezeichnung = hmm, wiederholt sich da vielleicht etwas? Waere das eine eigene Entitaet? Dann schnell eine "Nachschlagetabelle" bilden!
Produktgruppe = sicher eine eigene Entitaet, neue Tabelle erstellen
Langtext = ein Attribut der Tabelle, frei waehlbarer Text, also keine neue Tabelle
Groesse = dito
Werbeanbringung = Tja, neue Tabelle, aber sinnvollen Namen auswaehlen
Bild = besser wohl Grafik-Dateityp, neue Tabelle

Nun möchte ich die vorgenannte Tabelle nach den 3 Normalisierungsvor-
schriften überprüfen bzw. umformen, habe aber ein Verständnisproblem zu Normalisierungsvorschrift 2 und 3.

Vergiss die BCNFs, ist mehr was fuer Studis, eine konsequente Umsetzung in der Praxis ist toedlich (fuer den Umsetzenden).

Gruss,
Ludger