1 NF einhalten

 

Das Zerlegen von Feldern ist deutlich weniger performant als das Konkatenieren. Was für Sortierung, Filterung und Gruppierung verwendet werden soll, muß sowieso in einem eigenen Feld abgelegt werden, um es indizieren zu können.
Es ist also günstiger, Vorname und Nachname abzulegen und daraus bei Bedarf Vorname & ' ' & Nachname AS VollerName zu erzeugen, als ein Feld VollerName abzulegen und daraus Vorname und Nachname zu extrahieren.
Jede Informationseinheit, die bedeutungstragend ist, also isoliert gebraucht wird, gehört in ein eigenes Feld.

 

Long-Schlüssel für Join

 

Der Datentyp Long Integer wird von allen Datentypen am schnellsten verarbeitet.

 

Kategorien auslagern

 

Kategorien werden oft für Filterungen oder Gruppierungen verwendet. Hierfür genügt im Code eine schnell verarbeitbare Ganzzahl statt eines Textes.
Da die Steuerung über Formulare erfolgt, kann man dennoch dem Benutzer in einem Kombifeld anschauliche Texte anbieten, während im Hintergrund mit Zahlen gearbeitet wird.

 

Join-Vermeidung

 

… durch assoziative (Parallel-) Schlüssel statt Denormalisierung
Es kann in Einzelfällen sinnvoll sein, AutoWert-Schlüssel mit assoziativen Schlüsseln, auch wenn dadurch Mehrfelderschlüssel entstehen, zu ergänzen. Dadurch sind die n-seitigen Nutzdaten als Fremdschlüssel bereits in der 1-Tabelle enthalten. Joins, die sonst erforderlich wären, um die Daten aus der N-Tabelle hereinzuholen, entfallen dadurch.
Wenn auf der N-Seite noch weitere Daten außer den Schlüsselfeldern vorliegen, sind im Gegenzug die dann erforderlichen Mehrfelder-Joins natürlich langsamer als die über ein AutoWert-Long-Feld. Man muß also im einzelnen abwägen, was insgesamt günstiger ist.

 

 

Selbstverständlich kann man in Beziehungen zu weiteren Tabellen nach wie vor den AutoWert-Schlüssel benutzen.
Die Tabelle tblNDaten1 könnte über fi-id beliebige Daten aus tbl1Daten beziehen, zum Beispiel auch pk1 oder pk2, während die Tabelle tblNDaten2, von der wir annehmen, daß sie nur die Daten pk1 und pk1 aus tbl1Daten benötigt, gar keinen Join braucht, da die Daten als fi1 und fi2 bereits in ihr selbst enthalten sind. Die Beziehung ist dennoch nötig, um die referentielle Integrität sicherzustellen.
Da die Relationale Theorie sowohl Fremdschlüsselredundanz, da sonst auch gar keine mehrwertigen Beziehungen möglich wären, als auch das Erstellen von Beziehungen über Parallelschlüssel ausdrücklich erlaubt, ist das Vorgehen kein Verstoß gegen Entwurfsvorschriften aus E-R-Modellierung und Normalisierung.
Natürlich darf man nicht zu derselben Tabelle zweimal dieselbe Beziehung – einmal über AutoWert und einmal über einen Parallelschlüssel – aufbauen.

 

Mehr-Ebenen-Joins

 

… mit assoziativen Schlüsseln statt AutoWert
Ein ähnlicher Trick läßt sich in einem zugegebenermaßen seltenen Fall anwenden. Wenn in einer mehrstufigen 1:n-Hierarchie häufig Joins unter Überspringung mittlerer Ebenen erforderlich sind, ist ein alternativer Aufbau zum gewohnten Long-Autowert-Beziehungsschema günstiger.

 

Normaler Aufbau:

 

 

Abfrage auf dtText0, dtText3:

 

 

Alternativer Aufbau:

 

 

Die Felder fi1, fi2, fi3 sind dabei vom Typ gruppierte Numerierung, also z. B.

 

 

Abfrage auf dtText0, dtText3:

 

 

Beim alternativen Aufbau werden die Schlüsselwerte jeder Muttertabelle durch alle darunterliegenden Ebenen vererbt und jeweils um eine weitere Numerierungsebene ergänzt. Dadurch kann ein direkter, ebenenübergreifender Join vorgenommen werden.
Diese Variante bietet natürlich nur Vorteile, wenn die Anforderung solcher Joins auch öfter auftritt. Als grundsätzliche Alternative ist das Vorgehen nicht empfehlenswert.

 

Berechnungen archivieren

 

Das Speichern von Berechnungsergebnissen ist zunächst ein Entwurfsfehler und damit verboten. Das Problem hierbei ist die Möglichkeit, widersprüchliche Daten abzulegen und die DB damit in einen inkonsistenten Zustand zu bringen. Argumente der Art, man passe durch entsprechenden Code auf, daß das nicht passiert, ziehen nicht: Erstens werden beim Aufpassen die meisten Kinder gezeugt und zweitens handelt es sich datenbanktheoretisch nicht bloß um ein Vergehen, sondern um ein Verbrechen, d. h. die reine Möglichkeit, auch ohne daß etwas passiert, ist bereits strafbar.

 

Kalkulation (Zeilenberechnung)

 

Eine Kalkulation ist eine Berechnung mit Feldinhalten innerhalb eines Datensatzes, also z. B. Netto * (1 + MWSt) AS Brutto
Solche Berechnungen sind nicht indexabhängig, da sie keine Informationen über die Reihenfolge von Daten in verschiedenen Datensätzen verarbeiten.
Diese Berechnungen sind meist sowieso sehr schnell, daher wäre eine Speicherung der Berechnungsergebnisse sinnlos. Natürlich kann man auch hier durch extrem aufwendige Kalkulationen Einbrüche erleiden, weswegen es zu diesem Thema auch noch einige Tips geben wird, im Vergleich zum Rechenaufwand bei Aggregaten sind diese Zeitverluste aber marginal.

 

Aggregation (Spaltenberechnung)

 

Eine Aggregation ist eine Berechnung oder Operation über mehrere Datensätze eines Feldes. Die meisten Aggregationen sind indexabhängig.


Bei großen Datenmengen können Aggregierungen sehr zeitintensiv werden. Das Speichern von Aggregaten ist evtl. sinnvoll, wenn die Eingangsdaten für die Berechnung invariant sind, sich nach Eingabe also sicher nicht mehr ändern. Man sollte hieran strenge Maßstäbe anlegen:


Ein Geburtsdatum beispielsweise ist keineswegs, wie man naiv meinen könnte, per se ein invariantes Datum. Das ist es nur, wenn es per Code mit entsprechender Fehlerabsicherung eingetragen wurde. Bei händischer Eingabe durch Benutzer muß jederzeit mit Eingabefehlern gerechnet werden. Wenn diese irgendwann bemerkt werden, ändert sich dann tatsächlich das Geburtsdatum einer Person – nicht im wahren Leben, aber in der Modellwelt der Datenbank. Bei darauf basierenden berechneten, gespeicherten Werten schlägt die Änderungsanomalie mit voller Härte zu.


Sinnvoll speicherbare Aggregatberechnungsergebnisse sind zum Beispiel Temporaldaten wie Anzahl/Summe am/bis zum <Datum>. Da solche Werte vom System errechnet werden, sind sie als fehlerfrei anzusehen und daher unproblematisch, weil sicher invariant.


Nach diesem Prinzip werden typischerweise u. a. Kontoführungstabellen oder Belegbuchungstabellen (Rechnungen) aufgebaut.


Wenn alle Archivbedingungen erfüllt sind, liegt hierdurch auch kein NF-Verstoß bzw. keine echte Redundanz vor.


Speziell sollte für eine Archivtabelle gelten:

 

 

 

In ähnlicher Weise kann  man auch Aggregate wie auflaufende Summen zu einem bestimmten Datum abspeichern mit dem Vorteil, die jeweils letzte Summe statt durch eine aufwendige Aggregation seit Beginn der Geschichtsschreibung durch ein schlichtes „Letzte Summe plus aktuelle Vorgänge“ zu berechnen.
Auf keinen Fall sollte man dieses Archivierungsprinzip anwenden, wenn die Eingangsdaten variabel sind: Integrität geht vor Performance.

 

Richtig indizieren

 

Das ist die eigentliche Kernvoraussetzung für die Verbesserung der Abfragegeschwindigkeit. Daher ist diesem Thema das ganze nächste Kapitel gewidmet.