Daten normalisieren

Bisher waren diese Daten, die wir behandelt haben, in einer jeweils einzigen Tabelle. Selbst wenn ich mehrere Tabellen benutzt hatte, mit und ohne Index. Aber alle Daten befanden sich in einer Tabelle und für eine relationale Datenbank ist das ein grundsätzlicher Konzeptfehler. Ich will Ihnen das kurz demonstrieren mit einem Datenmodell. Das könnte Ihnen übrigens bekannt vorkommen. Das steckt hinter Outlook, welches überhaupt nicht normalisiert ist. Wenn diese Tabelle als einzige Datentabelle in einer Datenbank stünde, dann wäre sie voller redundanter Daten. Deswegen, das ist keine normalisierte Tabelle und normalisierte Tabellen sparen eine Menge Platz und über die Geschwindigkeit müssen wir dann später noch mal reden. Also wenn ich mir das mal genauer angucke – ich habe das rote Kreuz ein bisschen heller gemacht, damit Sie es wieder lesen können. Wenn diese Daten normalisiert werden sollten, dann würde ich zum Beispiel erst mal eine Tabelle für die Personeninformationen herausgreifen. Alle diese Felder gehören zur Person selber. Dazu kommt alles, was die Firma betrifft. Diese Felder betreffen die Firma. Genaugenommen ist es hier nur ein Feld. Ich habe für Firmen häufig zwei Namen, nämlich den langen Namen, der juristisch alle GmbH und Co.KG Zusätze enthält, und den kurzen Namen, so wie man die Firma kurz benennt. Aber letzten Endes ist es eine Tabelle, die Informationen zu einer Firma enthält, die wiederum dann mit der Person verknüpft werden kann. Wenn also die Person zu einer Firma gehört, steht da nur ein Fremdschlüssel drin. Wenn Sie viele Personen zur gleichen Firma haben, müssen Sie nicht die Daten der Firma immer wieder einzeln nachliefern. Dann kommen die übrigen Daten, die noch ein bisschen komplizierter sind, nämlich die Kontaktdaten und die Adressen. Die stehen ja hier genau in der Ursprungstabelle mit drin. Wenn ich also Telefon geschäftlich und Telefon privat unterscheide und ein Mobiltelefon angebe, dann scheitere ich an dem Moment, wo jemand ein zweites Mobiltelefon oder eine zweite geschäftliche Nummer hat. Also diese Angaben erlauben keine eins zu n Anhänge. Sprich ich könnte hier jetzt mehrere Daten hinterlegen, und zwar ich behandele das immer sehr allgemein, das können sowohl Telefonnummern als auch Internetseiten und Ähnliches sein. Das heißt, alles was hier drin enthalten ist, ist letzten Endes ein Wert in einer Kontaktdatentabelle. Natürlich könnte man sagen, auch Adressen sind nur Kontaktdaten. Aber an der Stelle werden Sie feststellen, während hier oben ein einzelner Wert reicht, eine Telefonnummer, eine URL oder so, sind es hier unten immer Pakete von Werten. Also alles, was die Adresse betrifft, tritt in vier oder fünf Einzelwerten gemeinsam auf. Und damit ist auch schon klar, eine Person könnte mehrere Adressen haben, sowie eine Person mehrere Kontaktdaten haben könnte. Auch das gilt übrigens für eine Firma. Es ist für eine Firma fast selbstverständlich, dass es eine Rechnungsadresse, eine Postadresse, mehrere Niederlassungsadressen, vielleicht, wenn es um Projekte geht, noch Baustellenadressen oder sonst was hat. Also, dass hier ein Kontakt exakt eine Adresse und eine begrenzte Anzahl von Kontaktdaten hat, ist eher erstaunlich. Damit wäre diese Tabelle leidlich normalisiert. Und ich sage es schon mal für die Puristen, die da drauf gucken und sagen das stimmt doch noch gar nicht. Nee, die ist nicht wirklich gut normalisiert. Da unten geht’s direkt weiter. Ich greife den Teil mal so ein bisschen raus. Die Adresse selber ist überhaupt nicht normalisiert. Also, wenn ich das jetzt mal hier ein bisschen nur in einer Kurzfassung zeige: Wenn ich eine Adresse habe, dann ist der Ort ein Fremdschlüssel auf die Liste der Orte. Dort ist zum Beispiel Postleitzahl und der Name hinterlegt und darin wiederum ein Fremdschlüssel auf die Liste der, wie immer es heißt, Provinzen, Bundesländer, Kantone. Und die wiederum gehören zu einem Staat. Da fehlt also noch ein bisschen Normalisierung. Das spare ich mir jetzt an der Stelle. Es geht ja eigentlich mehr so ums Prinzip, wo man was wie machen sollte. Und damit sind wir beim eigentlichen Problem: Wir sollten diese Normalisierung auch mal prüfen. Die ist jetzt inhaltlich vielleicht perfekt, aber vielleicht ist sie viel langsamer. Vielleicht haben wir uns durch die Perfektion einer Normalisierung einfach ganz viel Performanceverlust eingehandelt. Also müssen wir die Daten prüfen. Dafür gibt es diese verschiedenen Varianten. Einmal die Tabelle VieleDaten, die halbe Million steht zusammen und in diesem Fall die halbe Million Daten ist verteilt auf zwei Tabellen. Das hat nebenbei den Vorteil, dass, in diesem Fall haben wir diese geteilten Varianten, dass diese Ober Tabelle, wie ich sie hier genannt habe, verschiedene Unterdaten enthalten kann. In nicht normalisierten Tabellen kann ich ja für jeden Namen, sage ich mal, nur genau eine Zahl, ein Datum oder sowas angeben. Hier sehen Sie für den Namen Peter Janker jetzt hier als Beispiel, der hat in der unteren Tabelle exakt einen Datensatz. Der Harald Janker hat dort gar keinen Datensatz und Udo Janker wiederum hat dort vier Datensätze. Das wäre mit einer nicht normalisierten Tabelle gar nicht möglich. Da kann ich nur genau einen Datensatz haben. Hier darf ich 0 bis n untergeordnete Kinddatensätze dazu haben. Das ist also auch inhaltlich ein Vorteil. Das ist sozusagen die Person zu einer oder mehreren Adressen oder vielleicht gar keiner. Sie lösen auch inhaltliche Probleme mit der Normalisierung, aber wenn Sie denn normalisiert haben, möchten Sie das natürlich nicht so, dass Sie dabei ganz viel verlieren. Dann gucken wir uns doch mal an, worauf es hinausläuft. Also wenn ich die Daten in einer einzigen Tabelle speicher und ich sage mal fast die gleichen Daten in zwei Tabellen, dann braucht eine Tabelle 31 Millisekunden, wenn ich die Daten dort auslese und zwei Tabellen plötzlich 602 Millisekunden. Kurz gesagt, wir haben mal eben eine Verschlechterung auf fast 2000 % und deswegen müssen wir uns an der Stelle ganz deutlich fragen: Ist das also ein Problem und wir sollten wieder abbrechen? Nein, auf keinen Fall. Normalisierung ist inhaltlich zwingend notwendig. Wie schon erwähnt, wenn eine Person mehrere Adressen hat, geht das nicht anders als mit eins zu n Daten. Nicht normalisierte Daten sind keine Option, sondern schlicht fehlerhaft. Und da sind wir wieder bei schnell oder falsch. Zeitverlust ist besser als Datenverlust. Wenn Sie Daten nicht speichern können, ist es egal, wie schnell Sie drankommen. Sie müssen also dafür sorgen, dass Tabellen normalisiert sind, auch wenn Sie dabei ein bisschen Zeitverlust haben. Den werden wir verbessern, kann ich Ihnen versprechen. Auch da gibt es gute und schlechte Methoden. Aber ganz deutlich: Normalisierung ist zwingend, auch wenn es erstmal nach Zeitverlust aussieht. Die Alternative ist ein Datenverlust.