Korrektes Datenmodell als Basis für effizientes SQL

Ein Artikel von Stefan Berner, ehem. Senior Consultant, Diso AG

Komplexe SQL-Statements sind ein Ärgernis in jeder Applikation. Sowohl Performancetuning als auch Fehlersuche und -behebung sind  zeitaufwändige Arbeiten. Durch richtige Datenmodellierung und -programmierung können diese Aufwände vermieden werden.

Unsere Experten haben beim Tuning von langsamem SQL einige typische Problemquellen eruieren können. Es sind dies (in Reihenfolge der zunehmenden Häufigkeit)

  • Technische Probleme der Datenbank, des Betriebssystems oder des Disksubsystems

  • Sequenzieller statt mengenorientiertem Programmierstil (3GL und OO)

  • Ungenügende SQL-Kenntnisse der Entwickelnden

  • Falsche Datenmodelle

Die beiden letzten Punkte korrelieren zudem mit schlechter Wartbarkeit. Mit anderen Worten langsame Programme sind meistens schlecht les- und damit wartbar. Und umgekehrt. Auf diese beiden Quellen für ineffizienten Datenbankcode wollen wir kurz eingehen:

Ungenügende SQL-Kenntnisse

Bei vielen Tuningeinsätzen stellten wir fest, dass teilweise Millionen von Datensätzen sequenziell durchsucht und verarbeitet wurden. Meist ging dies einher mit der Kritik, Oracle sei zu langsam für diese Art von Problemen (sic!).
Es ist erschreckend, wie viele Informatiker wenig bis nichts von Mengenlehre, dem relationalen Modell und mengenorientierter Programmierung verstehen. Die weit verbreiteten sequenziellen und objektorientierte Programmierparadigmen sind nützlich und sinnvoll für viele Aufgaben in der Informatik. Sobald es aber um die Beherrschung von grossen Datenmengen geht, kommt niemand um das relationale Modell und mengenorientierte Programmierung herum.
Wir führen diese Fälle darauf zurück, dass viele Verantwortliche zu wenig sensibilisiert sind, für die Probleme der Verarbeitung grosser Datenmengen. Es ist ein grundsätzlicher Unterschied, ob man in einer Mini-Datenbank 1000 Datensätze verwaltet oder ob man hunderte von Millionen Datensätze verarbeiten soll. Der gezielte Einsatz von —für diese Aufgaben— qualifizierten Leuten kann hier Verbesserungen bringen.

Falsches Datenmodell

1972 hat Edgar F. Codd das relationale Modell entwickelt. Es basiert auf den sauberen mathematischen Grundlagen der Mengenlehre und des Prädikatenkalküls. Es ist das bisher beste Modell für die Strukturierung von Daten und deren schnellen Verarbeitung. Gleichzeitig ist es trotz seiner Universalität das einfachste bekannte Modell. Schon der Erfinder Codd hat beschrieben, dass diese Modell sehr optimizerfreundlich ist. Das Modell enthält ein Maximum an mathematisch sauber dargestellter Strukturinformation. Zusammen mit den Statistiken der aktuellen Datenverteilung nutzt ein moderner Optimizer diese Information für optimale Zugriffspläne für grösstmögliche Performance.
Was sind denn die schlimmsten Modellsünden, die wir angetroffen haben? Kurz zusammengefasst sind es generische Modelle und die Verletzung der von Codd in seinem Modell definierten 3 Normalformen.

1. Normalform
Jedes Attribut enthält genau einen Wert zu einem Sachverhalt.

Die häufigste Verletzung sind codierte Werte. D.h. in einem Datenfeld stehen Informationen zu mehreren Aspekten. Beispiel: Eine Artikelnummer enthält die Artikelgruppe, einen Farbcode, ggf. einen Giftklassencode sowie eine fortlaufende Nummer: „A5-rot-4431“, „A7-0-g3-0923“ Das Decodieren der verdichteten Information geschieht im Code und verunmöglicht es dem Optimzier, Informationen über Struktur und Datenverteilung richtig zu nutzen. Typische SQL-Vertreter, die diese Art von Regelverletzung korrigieren sollen und dabei den Optimizer behindern, sind CASE und SUBSTR in WHERE-Bedingungen.

2. Normalform
Jedes Attribut hängt funktional vom ganzen Schlüssel einer Tabelle ab.

Funktionale Abhängigkeiten von Attributen von Teilen eines Schlüssels führen zu Redundanzen, die in aufwändigen Filtern bereinigt werden müssen.
Beispiel:
SAISON-ARTIKEL: (Artikel-Nr, Periode, Name, Preis, Rabatt)
Name und Preis gelten für den Artikel (hängen also nur von der Artikel-Nr ab), der Rabatt gilt für den Artikel währen der Periode.
Typische Korrekturbefehle für eine Verletzung der 2. Normalform sind die bekannten Performancekiller DISTINCT und ROWNUM=1.

3. Normalform
Jedes Attribut einer Tabelle hängt ausschliesslich funktional vom Schlüssel der Tabelle ab.

Zwischen zwei Attributen einer Tabelle darf es (ausser eines davon ist Schlüssel) keine Beziehung oder Abhängigkeit geben.
Beispiel:
PERSON: (AHV-Nr, Name, Vorname, … ,Wohnkantonkürzel, Wohnkantonname, …)
Kürzel und Name des Wohnkantons sind miteinander verbunden (funktional abhängig).
Typische Korrektur dieser Regelverletzung sind diejenigen der 2. Normalform plus komplexe JOIN-Bedinungen, die den Code unlesbar und langsam machen.

Generische Modelle

Generische Modelle sind äusserst beliebt bei Informatikern. Sie versuchen mit einer ‚flexiblen’ Lösung ganz viele Probleme mit einem Aufwisch zu lösen. Kurz gesagt geht es darum, dass nicht konkrete Anforderungen modelliert werden, sondern in einem Meta-Modell mittels Datenwerten ganz viele Anforderungen zur Laufzeit durch die Benutzenden modelliert werden können. Man verschiebt die Struktur der Daten in die Zusammenhänge der Meta-Daten.
Die Komplexität der generischen Lösung macht das Ergebnis schwer wartbar und fast immer zu einem Performancekiller.
Generische Modelle haben ihren berechtigten Platz für einige spezielle Anwendungen. Ihre unbedachte Anwendung bei grossen Datenmengen ist das Problem. Oft funktionieren sie bis in die Testphase. Sobald aber realistische Datenmengen geladen wurden, sind sie viel zu langsam und können mit Tuningmassnahmen selten schnell genug gemacht werden.

Fazit

Die Ursache vieler SQL-Performanceprobleme liegt im falschen Datenmodell. Es sind falsch eingesetzte generische Modelle sowie Verletzungen der Regeln des relationalen Modells, die zu schlechtem Code führen. Tuningmassnahmen führen in diesen Fällen oft nur zu kleinen Verbesserungen und machen die Lösung komplexer und damit unwartbarer.
Wir haben in mehreren Fällen zeigen können, dass ein sauberes relationales Datenmodell Performanceverbesserungen um Faktoren 100 und mehr gebracht hat. Ohne spezielle Tuningmassnahmen notabene. Zudem waren jeweils die Modelle und die SQL-Statements viel einfacher.
Darum unsere Empfehlung: bei grösseren Performanceproblemen überprüfen sie das zugrundeliegende Datenmodell und die Qualität des vorliegenden Codes, bevor Sie viel Geld in Tuningmassnahmen investieren.

Diso AG – Der Schweizer Daten- und Cloud-Experte

Die Diso AG ist ein renommierter IT-Dienstleister und langjähriger Oracle-Vertriebspartner in der Schweiz mit Schwerpunkten in den Bereichen Datenbanken und Cloud-Lösungen. Diso bietet ihren Kunden beispielsweise die Oracle Plattform as a Service-Lösung und die dazugehörige Datenmigration an. Kunden profitieren des Weiteren vom Komplettlösungsangebot im Sinne von Planung, Integration, Support inklusive Betrieb und Überwachung von IT-Infrastrukturen und Datenbanksystemen.
Im Bereich Software-Engineering entwickelt Diso massgeschneiderte IT und Software-Lösungen für unternehmensspezifische Anwendungen, wann immer sinnvoll mit einem mobile-first Ansatz. Zudem ist Diso Spezialist wenn es um die Software-basierte Optimierung von Performance geht. Auf die Kompetenz des traditionsreichen IT-Dienstleisters und Mittelständlers vertrauen bereits namhafte Kunden aus den Schwerpunktbranchen Banken, Versicherungen Detailhandel und öffentliche Verwaltung.
Die Diso designt wandlungsfähige IT-Systeme, entwickelt massgeschneiderte Software und ermöglicht die performante Verwendung und Auswertung von Informationen.

Über den Autor:

Stefan Berner war jahrelang Senior Experte bei der Diso AG, spezialisiert auf Daten- und Informationsmodellierung. Sein Fokus ist es, Daten zu nutzbaren Informationen umzuwandeln, sodass Kunden auf allen Ebenen der Digital Supply Chain ein besseres Verständnis ihrer Produkte und Kunden erlangen können.