Wofür die Normalisierung?
Hallo Leute,
ich mache gerade eine eigene Seite und habe auch schon eine MySQL Datenbank und habe von der Normalisierung gehört. Ich habe mir dazu ein paar Videos angeschaut, aber nicht wirklich verstanden. Ich habe eine Registrierungssteinbank, wo, wie schon im Namen steht, einfach die Standartdaten der Nutzer stehen. Meint ihr ich brauche eine Normalisierung für sowas normalen. Die Videos die ich geschaut habe gingen darüber dass die Leute was verkauften. Also brauche ich überhaupt eine Normalisierung für eine ganz simple Registrierungsdatenbank?
6 Antworten
Wofür die Normalisierung?
Ganz vereinfacht ausgedrückt:
Die Normalisierung von Daten dient dazu, dass man Daten zuerst einmal sauber "aufteilt" also für jede einzelne Information auch ein eigenes "Feld" (in einer Tabelle wäre das eine eigene Spalte) vorsieht. Also nicht einfach ein Feld "Name" wo dann sowohl Vor- als auch Nachname stehen (denn wie will man dann z.B. die Adressliste nach Nachnamen sortieren? Woher "weiss" man, welcher Teil innerhalb des Feldes der Nachname ist?) und auch kein einzelnes Feld "Adresse" sondern alle Daten innerhalb der Adresse in eigene, einzelne Felder etc.
Und dann geht es auch noch darum, dass man bestimmte informationen nicht unnötig mehrfach speichert. Und das man vorher nicht genau die Menge von bestimmten Daten wissen muss, die mit einem anderen Datensatz zusammenhängen.
Am Besten erklärt man das an einem Beispiel:
Nehmen wir an, Du willst eine Datenbank mit Personen, ihren Telefonnummern und ihren Adressen erstellen.
Dann kannst Du das natürlich ganz einfach machen, indem Du alle Daten in eine einzige Tabelle in der Datenbank schreibst. Ein Datensatz ist dann eine Person mit ihrer Adresse und ihrer Telefonnummer.
- Aber dann kann es eben vorkommen, dass Du bei 6 Leuten immer die gleiche Adresse stehen hast, weil sie alle im selben Mehrfamilienhaus wohnen (gleiche Strasse, Hausnummer, PLZ, Ort, Land).
- Oder es kann auch sein, das eine Person (Firma) mehr als eine Adresse hat. Willst Du dann in Deiner Tabelle für alle Einträge die Felder für mehrere Adressen anlegen, nur weil Du es für einige, wenige Personen/Firmen benötigst? Und wenn ja: Für wie viele Adressen denn? Woher weisst Du das vorher? Bei Firmen sind durchaus sehr viele Adressen möglich: Mehrere Lieferadressen (eine pro Filiale z.B. bei Geschäften), eine Rechnungsadresse oder auch mehrere, eine Adresse für den offiziellen Firmensitz etc.
Das Gleiche mit den Telefonnummern. Eine Person kann eine vorher nicht festgelegte Menge an Telefonnummern haben:
- Eine private Festnetznummer
- Eine Firmendurchwahl
- Eine private Handynummer
- Eine geschäftliche Handynummer
- Eine private Faxnummer
- Eine geschäftliche Faxnummer
- usw.
Du hast also folgendes Problem:
- Willst Du in Deiner einen Tabelle jetzt für alle Personen/Firmen immer die Felder für mehrere Adressen / Telefonnummern vorsehen, auch wenn Du sie bei 99% der Einträge nicht brauchst?
- Und woher weisst Du, wie viele Adressen und Telefonnummern Du irgendwann mal für eine Person bzw. Firma benötigen wirst? Wie legst Du die Maximalanzahl beim Design Deiner einen Tabelle fest?
Die Lösung heisst "Normalisierung".
Du legst die Informationen nicht alle in einer Tabelle ab sondern in mehreren, die mit einander "verknüpft" sind.
Also z.B. eine Tabelle mit
- Name
- Vorname
- Geburtsdatum
Weil das alles Informationen sind, die jede Person nur genau einmal hat.
Und eine Tabelle für die Adresssen mit
- Strasse
- Hausnummer
- PLZ
- Ort
- Land
- Bezeichnung der Adresse (also z.B. "Rechnungsadresse", Wohnanschrift" etc.)
für jeweils eine Adresse.
Und eine Tabelle für Telefonnummern mit
- der eigentlichen Nummer
- der Bezeichnung der Nummer (also z.B. "Fax Privat", "Mobil Geschäftlich" etc.)
Dann bekommen alle Tabellen noch einen eindeutigen technischen Schlüssel (also ein einmaliges Kennzeichen mit dem man den betreffenden Datensatz in der Tabelle genau identifizieren kann). Das ist im einfachsten Fall einfach eine laufende Nummer, die für jeden weiteren Eintrag in der Tabelle jeweils um "1" hochgezählt wird.
Also in der Tabelle mit den Personen noch ein Feld namens "Personen-ID" und in der Tabelle mit den Adressen ein Feld mit "Adress-ID" und in der Tabelle mit den Telefonnummern eine "Telefonnummern-ID".
Dann kommen wir dazu, wie wir die Daten in den einzelnen Tabellen mit einander "verknüpfen" um z.B. für eine Person alle zugehörigen Telefonnummern zu finden.
Also benötigst Du in diesem Fall zusätzlich in der Tabelle "Telefonnummer" noch ein so genanntes "Schlüsselfeld" in dem Du die jeweilige ID der Person hinein schreibst, zu der diese Telefonnummer gehört. Nennen wir das Feld "Key_Person".
So kannst Du eine Person lesen, nimmst deren ID und suchst Dir alle Telefonnummern heraus, die im Feld "Key_Person" die ID (laufende Nummer) der betreffenden Person enthalten.
Ich hoffe, die Idee ist an diesem Beispiel verständlich geworden. Im Prinzip könnte man da ganze Bücher drüber schreiben, was wann Sinn macht. Und es gibt auch entsprechende Bücher / Artikel / Webseiten die das im Detail erklären. Musst Du mal nach googlen ("Datenbanken normalisieren Anleitung" oder ähnliches).
Moin,
Generell durchaus.
Die 1. NF ist ja schon mal zum Atomatisieren, dass man nicht alle Daten in eine Zelle schreibt. Die weiteren NFs sind dazu da, dass du die Daten sinnvoll aufteilst in eigene Gruppen und sie schlussendlich in Beziehungstabellen verknüpfst.
Das spart Speicher und macht die Datenbank effektiver.
Es kommt jetzt also auf deine Datenbank an. Lass uns sagen, wir haben;
Nutzername und das Passwort (bitte das Verschlüsseln nicht vergessen!) - dann brauchst du keine Normalisierung.
Wenn wir jetzt sagen, dass der Nutzer bestellen kann;
Nutzername, Passwort, Adresse, Artikelnummer, Menge, Artikelbezeichnung, Preis
Dann benötigst du drei Tabellen - wozu registrieren sich die Nutzer denn hier? Wenn die Antwort nicht lautet "einfach so, damit sie andere Seiten sehen können", dann solltest du über die Normalisierung nachdenken.
LG
Passwörter gehören gesalzen und gehasht und nicht verschlüsselt in eine DB, nur als Nebenanmerkungen.
Technisch brauchst du das nicht.
Allerdings endet das im Chaos, wenn das ein Projekt ist, das längere Zeit genutzt und gepflegt werden soll, wenn sowas simples wie eine normalisierte DB schon nicht gegeben ist.
Die Normalisierung hat sehr wohl triftige Gründe, die aber bei einer kleinen DB mit nur 1 oder 2 Tabellen erstmal ziemlich egal sind.
Bei großen und komplexen Datenbanken kriegst du ohne Normalisierung aber schnell üble Konsistenzprobleme.
Mach es erstmal simpel. Wenn du Normalisierung brauchst, dann merkst du das schon (jetzt, wo du darüber gelesen hast).
Das geht z.B. los, wenn du mehrere Adressen für einen User pflegen können willst.
Ein relationales Datenschema zu normalisieren bedeutet, die Menge der notwendigen Tabellen und ihrer Attribute so zu wählen, dass keine Information in der Datenbank in mehr als nur einer Tabelle abgespeichert sein muss.