Datenbank-Normalisierung - nicht nur für Weicheier!

Vor ein paar Wochen hatte ich hier mal einen Artikel abgesetzt, in dem es um das arkane Thema "Normalisierung" von Datenbanken geht. (Junge Heißkisten unter den Entwicklern sind oft der Meinung, dass Normalisierung etwas für ängstliche Weicheier ist. Die alten Hasen warnen vor den zu saloppen Umgang mit dem Thema.) OK, dass hört sich, als wäre es nur etwas für echte Hardcore-Techies. Tatsächlich kann man die Konsequenzen von gutem - oder nicht so gutem - Design von Datenbank-Anwendungen auch als absoluter EDV-Laie jederzeit im Web betrachten.

Ein schönes Beispiel sind die bei vielen Bloggern bekannten blogstats-Statistiken der deutschen Weblog-Plattform blogg.de. Auch ich checke die (ja, *rotwerd*, ich bin eitel) jedes Wochenende einmal. Hier kann man sich zum Beispiel ansehen, wer in der deutschen Blogosphäre am meisten von anderen Bloggern zitiert wird etc. Zum Beispiel gibt es zwei Top100-Listen, die aus diesem "Zitiertwerden" eine Rangfolge bauen: die Alltime-Hitliste, die heute immer noch mit 1389 Verweisen in 419 Quellen (anderen Blogs) von Moes PlasticThinking angeführt wird, und dann die Top100Live, in der nur die Links verzeichnet werden, die noch auf den Startseiten der Blogs stehen, und in der das BILDblog mit 77 Verweisen aus 71 Quellen führt.

Soweit so gut! Tatsächlich steht in der letzten Liste aber auch das Weblog US-Wahl 2004 auf Platz 42, das noch mit 23 Verweisen aus 15 Quellen geführt wird. Hoppla ... US-Wahl? Ist das nicht schon eine Weile her? Ja und tatsächlich bezieht sich auf dieses Weblog bei genauerer Betrachtung auch nur noch ein einziges anderes Weblog (1 Verweis aus 1 Quelle)!

Witzig? Ja schon. Aber es gibt noch interessantere Fälle ... 

freakshow, mit angeblich 26 Verweisen aus 25 Quellen auf Platz 15 geführt, ist scheinbar gar nicht mehr online und weist bei genauerer Betrachtung 0 Verweise in 0 Quellen auf.

Geht man die gesamte Top100Live durch, findet man je nach Tageszeit und Wochentag bei knapp einem Drittel der Einträge Widersprüche zwischen den Angaben in der Hitliste und den detaillierten Auflistungen der Links.

Wie kann das kommen? Ganz einfach: keine Normalisierung!

Die Datenbank bei Blogstats, die über 28.000 deutschsprachige Weblogs analysiert, ist nicht vollständig normalisiert. Und das ist auch verständlich. Ständig aktuell zu berechnen, welche Weblogs wie oft von wie vielen anderen Weblogs verlinkt werden, wäre in eine normalisierten Datenbank zwar mit einem sehr einfachen Befehl möglich. An diesem Befehl hätten die Rechner aber minutenlang, vielleicht stundenlang zu knabbern! Denn zum Erstellen der Hitliste muss für jedes der 28.000 Weblogs ja einmal "durchgezählt" werden, wieviele Einträge darauf verweisen; 28.000-mal! Und die resultierende Liste dann sortiert werden.

Deshalb haben sich die Entwickler entschlossen, die Zahl der Verweise auf ein bestimmtes Weblog nicht ständig aktuell zu halten, sondern immer nur dann zu aktualisieren, wenn in diesem Blog ein neuer Artikel erscheint. Klingt plausibel und reduziert den Berechnungsaufwand gewaltig. Hat aber auch den unschönen Nachteil, dass die Verlinkungszahlen bei einem Weblog, in dem keinen neuen Beiträge mehr erscheinen, nie aktualisiert werden!

Das soll nicht dazu dienen, blogstats in die Pfanne zu hauen. Schließlich ist es bei so einer Hitliste nicht wirklich tragisch, wenn da ein paar Ausreißer drin sind. blogstats ist nur ein einfaches Beispiel. Es zeigt allerdings sehr schön, welche Konsequenzen ein abstraktes Thema wie "Normalisierung" ganz praktisch haben kann - und für die ITler unter uns zeigt es, dass Normalisierung nicht nur etwas für die langweiligen alten Fürze aus dem Elfenbeinturm der Informatik ist.

Wie gesagt, bei Blogstats sind die Auswirkungen der De-Normalisierung harmlos und tun keinem weh. Wenn es um Geld, Sicherheit etc. geht, sieh das anders aus. De-Normalisierung ist in der Praxis fast immer unerläßlich - aber Systemarchitekten und Entwickler sollten sich über die Konsequenzen genau im klaren sein. Man mag sich Performance damit erkaufen. Widersprüchliche Daten in einer Anwendung reduzieren aber zumindest das Vertrauen der Nutzer in Qualität und Zuverlässigkeit eines solchen Systems. Und im Geschäftsleben kann das zu "richtig Ärger" führen.

You have to know the rules, to break them ...

Comments

[Manfred]

Tausend Dank für diesen ungemein pragmatischen Illustrierungsansatz eines höchst theoretischen Themas!!!

[Norbert]

"Deshalb haben sich die Entwickler entschlossen, die Zahl der Verweise auf ein bestimmtes Weblog nicht ständig aktuell zu halten, sondern immer nur dann zu aktualisieren, wenn in diesem Blog ein neuer Artikel erscheint. Klingt plausibel und reduziert den Berechnungsaufwand gewaltig. Hat aber auch den unschönen Nachteil, dass die Verlinkungszahlen bei einem Weblog, in dem keinen neuen Beiträge mehr erscheinen, nie aktualisiert werden!"

...und genau das ist der Grund fuer das Uebel; nicht die fehlende oder gar falsche Normalisierung!

Ziel der Normalisierung ist es ja, Redundanzen und Konsistenz (weitesgehend) sicherzustellen. Aber das kann natuerlich nur dann funktionieren, wenn die Datenbasis bzw. -befuellung der wirklichen Welt entspricht.

In diesem Beispiel scheint der Design-Fehler eher in der Entscheidung zu liegen, die Datenbasis eines Weblogs nicht regelmaessiger zu aktualsieren. Im Moment sehe ich hier nur einen (Denk)-Fehler: "Weblogs werden staendig aktualsiert! - deshalb kommen wir auch staendig wieder!".

Ist ein kleiner Bug und kann sicherlich durch ein regelmaessig laufendes Script behoben werden.

[Markus Breuer]

wenn ich eine normalisierte, relationale datenbank habe, ergeben alle SELECTS (insbesondere, wenn ich schreibende operationen mit transaktionen umschließe) auf einem zustand der tabellen stets konsistente ergebnisse. genau das ist einer der wichtigsten gründe für normalisierung.

btw: es geht nicht um die korrekte abbildung der welt sondern nur (?) um interne konsistenz der abfragen zu einem zeitpunkt x.

denksportaufgabe: überlege dir das "kleine script", dass die konsistenz der datenbank in dieser frage (hitliste der länge N) sicherstellt. nächste aufgabe: überlege dir drei denkbare anwendungen, die auch nach durchlauf dieses "kleinen scripts" nach wie vor inkonsistente auswertungen ergeben (übernehme ich zur not).

ja, natürlich gibt es solche lösungen. genau das ist der grund, weshalb in vielen grossen projekten behutsam de-normaliisierung betrieben wird. solche "kleinen scripts" lösen aber immer nur die konsistenzprobleme in hinsicht auf eine fragestellung. das führt dazu, dass im laufe der zeit oft viele "kleine skripts" laufen, die einiges der performancevorteile der de- normalisierung auffressen - und im zusammenspiel "lustige" effekte ergeben können.

nochmal, die aussage lautet: de-normalisierung ist kein verbrechen, oft nötig und sinnvoll - hat aber nachteile (auf dauer oft mehr, als man am anfang glaubt). mehr nicht und auch nicht weniger.

[Sencer]

Hi Norbert,

>Ziel der Normalisierung ist es ja, Redundanzen und
>Konsistenz (weitesgehend) sicherzustellen.

Vermutlich nur ein kleiner Tippfehler, aber der Vollständigkeit halber: Ziel der Normalisierung ist es ja, Redundanzen _zu vermeiden_ und Konsistenz (weitesgehend) sicherzustellen.

Hätte Blogstats nur normalisierte Datenbestände gäbe es auch überall konsistente Zahlen. Die Tatsache, dass man sich aus Performance-Gründen entschieden hat, Redundanzen vorzuhalten (absolut legitimer Grund), war letztlich ausschlaggebend dafür, dass solche Inkonsistenzen auftreten konnten.
Natürlich kann man auch bei De-Normalisierung konsistente Daten halten (trotz Redundanzen), allerdings fordert das eben mehr Aufwand, Sorgfalt etc. bei jedem Zugriff und jedem Feature auf/mit den Daten. Also ist die De-Normalisierung schon Grund für das Übel. Man könnte vielleicht mathematisch sagen: es ist notwendig, aber nicht hinreichend. ;) (Murphy erledigt dann den Rest... :P)

Stimme Markus v.a. in den letzten beiden Absätzen voll zu.

[Norbert]

"btw: es geht nicht um die korrekte abbildung der welt sondern nur (?) um interne konsistenz der abfragen zu einem zeitpunkt x."

Genau, und die Datenbasis fuer die Auswertung zum Zeitpunkt x ist entscheidend. Ich kenne keine Architektur und keine Details zu Blogstats; koennte mir aber vorstellen, dass es mind. einen dreistufigen Prozess in der Auswertung gibt:

#1 Besuchen der Weblogs und registrieren der Links
#2 Auswertung der Verlinkung im Batch-Betrieb (nachts o.ae.)
#3 Darstellen der Ergebnisse "live" auf Blogstats

Wenn #1 nicht regelmaessig erfolgt, bleibt #2 und #3 irgendwann in der Historie stecken.

"denksportaufgabe: überlege dir das "kleine script", dass die konsistenz der datenbank in dieser frage (hitliste der länge N) sicherstellt"

Fuer die gegebene Fragestellung ist das ein regelmaessiges Wiederholen von #1; das Wort Script wollte ich hier nicht wortwoertlich verstanden wissen.

Ich bin auch fuer Normalisierung und habe taeglich mit ihr zu tun/kaempfen.

Ich halte Blogstats fuer kein gutes Beispiel, weil eine Normalisierung der Datenbank hier nicht (alleine) zum Erfolg fuehrt.

nochmal zitiert - es geht:
"...um interne konsistenz der abfragen zu einem zeitpunkt x."

Ich sehe nicht, wo die normalisierte Variante der Datenbank hier Vorteile bringt. Normalisierung heisst ja nicht zwangslaeufig "echtzeitfaehige" Bereitstellung/Aufbereitung der 28.xxx-Blog-Daten.

Eine normalisiertes Modell kann ja auch NULL Daten enthalten; die Ergebnisse werden dadurch nicht besser!

Idealerweise wuerde Blogstats natuerlich auf den "Echt-Daten" der 28.xxx-Blogs opperieren; aber dass das utopisch ist duerfte klar sein:) Also muss vorher eine Art Aggregation erfolgen (Angenommene Schritte #1-3).

Blogstats ist doch eine Art Data-Warehouse mit entsprechenden Auswertungen. Data-Warehouses sind auch nicht "aktuell" (im idealen Sinne) und oft weit von der zweiten und dritten Normalform entfernt! Deshalb - und nochmal - ist Blogstats kein gutes Beispiel fuer Pro-Normalisierung!

[Norbert]

Nachtrag:

Mea maxima culpa! Ich bin den Links "bei genauerer Betrachtung" nicht gefolgt. Faelschlicherweise nahm ich an, es wuerde sich um Links auf das jeweils im Kontext zitierte Blog handeln!

Mein ungenaues Lesen fuehrte zu einer falschen Annahme und *ich* konnte in Folge die Analyse nicht nachvollziehen; es kam zu meinen Anmerkungen.

Ich kann somit nur noch sagen: "Alles zurueck auf Anfang!" Und kann ich kann die Kritik nun nachvollziehen und bestaetigen.

Gut, dass das gerade per E-Mail noch deutlich wurde:-)

[mbo]

als derjenige, der die "De-Normalisierung" verbrochen hat, möchte ich noch ein paar Dinge anmerken:

Ja, es würde Sinn machen, die top100 Listen mehrmals am Tag in ihrer Gänze neu berechnen zu lassen, zumindestens die Blogs, die dafür in Frage kommen. (Und diese Auswertung dann mit Zusatz "Stand vom 11.11 11:11H" zu versehen)

Aber das würde die Top100 Listen immer noch nicht in Echtzeit liefern. Im Gegensatz dazu kommen die Ergebnisse der Detailansichten in Echtzeit aus der DB. Deshalb die Inkonsistenzen. Ob deshalb die DB keine Normalisierung besitzt?

Welchen tatsächlichen Nutzen die TOP100Listen in Echtzeit haben sollten, lässt sich eigentlich auch nicht wirklich vermitteln, vor allem wenn der Preis dafür eine hohe Last für die DB bedeuten würde? Aber das siehst du, glaube ich, ähnlich.