Normalformen erklären

bandy

Bekanntes Mitglied
Hallo,

wer kann mir einfach den Unterschied zwischen erster -, zweiter - und dritter Normalform erklaeren?:bahnhof::bahnhof:
 
Zuletzt bearbeitet von einem Moderator:
S

SlaterB

Gast
die Area nimmt großzügig alle Arten von Aufgaben auf,
also insbesondere Fragen, die den Fragesteller gar nicht zu interessieren scheinen

nimm doch mal an, es gäbe noch niemandeb, der diese willkürliche Beschreibungen, die auch überall gut nachzulesen sind, definiert hätte,
wäre die Welt jetzt eine schlechtere?
was für ein Problem hast du, wofür musst du das wissen usw.,
mit entsprechenden überzeugenden Ausführungen sähe es vielleicht weniger nach Hausaufgabe auf,
nur der Standardsatz 'ist es nicht' hilft wenig
 

bandy

Bekanntes Mitglied
was für ein Problem hast du, wofür musst du das wissen usw.,
mit entsprechenden überzeugenden Ausführungen sähe es vielleicht weniger nach Hausaufgabe auf,
nur der Standardsatz 'ist es nicht' hilft wenig[/QUOTE

Ist Schulstoff, deswegen moechte es verstehen. Wenn man die Beispiele bei wikipedia etc. liesst bleiben trotzdem viele Fragen offen, vorallem der wirkliche Sinn dieser Sache
 
M

maki

Gast
Stelle konkrete Fragen, dann bekommst du konrete Antworten.

Was ist dir denn noch unklar?
 
F

Firephoenix

Gast
Also zu dem Sinn der Normalformen allgemein:
Du vermeidest Datenredundanzen und Anomalien bei Änderungen.

Ein Beispiel:
Du hast eine Tabelle deren Relation so aussieht:
Forum(Benutzer,Beitrag,Registrierungsdatum,Beitragsdatum)

Das Registrierungsdatum des Benutzers hat z.b. garnichts mit seinem Beitrag im Forum zu tun, allerdings müsstest du es jedes mal kopieren wenn der Benutzer nur einen Beitrag schreibt.
Mit einer höheren Normalform könntest du das z.b. so Auflösen (Benutzer-Beitrag ist 0:n, da ein Beitrag immer nur von einem User geschrieben wird - Edit von Mods etc mal wegabstrahiert :p - also könnte man z.b. den User zum Posting speichern)
User:(UserId#,Name,Registrationsdatum)
Beitrag:(PostingId#,Inhalt,Erstellungsdatum,Autor) - Autor wäre der Fremdschlüssel UserId aus der Tabelle User.
ändert jetzt z.b. der Benutzer Name o.ä. müsste man das nur noch an einer Stelle ändern, durch die Ids kriegst du auch eine schönere Trennung.

Und das ganze ist natürlich wesentlich schöner auch in Wiki, auch mit ähnlichen Beispielen ;)
 

xehpuk

Top Contributor
Dann gibt es doch keine Datenredundanzen etc. ? oder?:bahnhof:
Das ist keine gültige DB-Tabelle. In der zweiten Zeile fehlen diverse Felder. Hast du sie jetzt nur nicht befüllt, um die offensichtlich redundanten Stellen zu verstecken? ;)
Fragwürdig ist, ob man die ganzen Beträge persistent halten soll. Womöglich sind die Artikelpreise auch redundant. Es sei denn, sie werden immer verhandelt.
 

bandy

Bekanntes Mitglied
Das ist keine gültige DB-Tabelle. In der zweiten Zeile fehlen diverse Felder. Hast du sie jetzt nur nicht befüllt, um die offensichtlich redundanten Stellen zu verstecken? ;)
Fragwürdig ist, ob man die ganzen Beträge persistent halten soll. Womöglich sind die Artikelpreise auch redundant. Es sei denn, sie werden immer verhandelt.

Nein nein, nein nein, es handelt sich in diesem Beispiel von Abspeicherung von Bestellungen. Unter Auftragsnummer wird quasie der rest gespeichert, Bestelldatum, Lieferdatum, Artikel, Anzahl, Preis, Internetshop(Firma) und Endbetrag. Da es mehrere Artikel vorliegen, wird die Tabelle an den Stellen die unterschiedlich sind weiter nach unten erweitert. Da es selbe Bestellung ist, ist Bestellnummer, Bestelldatum, Lieferdatum ... und Endbetrag gleich, deswegen stehen bei zweitem Artikel diese Felder rechts und links leer. So ist es gemeint.
 
F

Firephoenix

Gast
Dann als Beispiel:
Du hast eine Tabelle in der das Gerät "Akku" und sein Produktionsort "Japan" abgelegt sind.
Jetzt möchtest du wissen welche Firma wo herstellt (insbesondere diesen Akku) und führst einen Join über den Akku durch.
Das Feld firma ist leer also kannst du die Information nicht herstellen obwohl das aus den Tabellenköpfen her möglich sein sollte.
Das wäre allerdings weniger ein Normalformproblem sondern einfach eine unvollständige Tabelle.

Geht man davon aus, dass die Tabelle korrekt befüllt wäre und schaut sich nur die Tabellenrelation an kann man allerdings stur nach Wiki( Normalisierung (Datenbank) ? Wikipedia ) die NF durchgehen:

1. NF: Die 1. NF ist offenbar gegeben, die Daten betrachte ich hier als atomaren wert.
2. NF: Wenn du nur die Bestellnummer als Primärschlüssel hast ist die 2 NF auch erfüllt
3. NF: Es darf kein nichtschlüssel transitiv von dem Primärschlüssel abhängen
Sagen wir mal der Artikel ist von der Bestellnummer abhängig.
Welche Firma dazu gehört hängt aber direkt von dem Artikel ab.
Somit hängt Firma transitiv von einem Schlüsselkandidaten ab und die 3NF ist verletzt.

Die 3NF fängt nämlich genau diese Datenredundanz ab.
Auf der Basis kannst du ja mal versuchen die 3NF aus deiner Tabelle herzustellen, schau dir dazu am besten mal in Ruhe die Beispiele in Wiki an, die sind in diesem Artikel wirklich mal gut zu gebrauchen :)
Gruß
 
M

maki

Gast
Betrag und Endbetrag lässt sich aus Preis, Anzahl und die Summe errechnen, sind also redundant.
 

bandy

Bekanntes Mitglied
Ist die erste NF hier richtig so?

1NF.JPG


und wurde diese so richtig zerlegt in die zweite NF ?


2NF.JPG


und wie kann ich es noch in 3NF zerlegen?:bahnhof:
 

Neue Themen


Oben