Joachim Hausmann
Datenbank

Relationales Datenbankdesign

Ein guter Datenbankentwurf ist für jedes datenbankbasierte Projekt existentiell. Durch entsprechende Überlegungen im Vorfeld können viele Fehler vermieden werden die im Nachgang gar nicht oder nur mit sehr hohem Aufwand korrigiert werden können.

Wesentliche Punkte eines guten Datenbankdesign sind unter anderem:

• Ein schneller Zugriff auf die gewünschten Informationen
Dies kann z.B. durch Primärschlüssel und Schlüssel realisiert werden. Vereinfacht ist hier jedoch zu erwähnen, dass ein guter Schlüssel für das Ermitteln einer Information einen Zeitvorteil bedeuten kann, er aber Speicherplatz kostet. Für das Einfügen oder Ändern einer entsprechenden Information wird mehr Zeit benötigt.
• Transaktionssicherheit.
Debitoren- und Kreditorenbuchungen werden normalerweise in separaten Tabellen gespeichert. Eine Buchung (Datenbanktechnisch Transaktion) erlaubt nur „Alles“ oder „Nichts“, sowie in diesem Beispiel nur eine Debitoren- einer Kreditorenbuchung entsprechen darf.
• Datenintegrität
Sie wollen z.B. sicherstellen, dass ein Bestellauftrag nur einem vorhandenen Kunden zugeordnet werden kann (eine typische ForeignKey Relation), oder dass die Versandkosten nicht größer als der Warenwert sind (eine typisches Constraint). Vielleicht ist die Problematik jedoch komplexer (z.B. wenn für den Kunden ein Eintrag in der Tabelle XY existiert und ein Eintrag in der Tabelle YZ, der nicht älter ist als 30 Tage oder in der Tabelle AB ein Eintrag mit einem Betragsbereich von A-B), dann kann hier ggf. ein Einsatz von Triggern dienlich sein.
Sie wollen ja auch keinen Kunden löschen, für den Bestellungen vorhanden sind oder ausstehen.
Einen registrierten Kunden ohne Bestellungen oder mit einer letzten Bestellung die mindestens 10 Jahre alt ist möchten Sie gerne löschen.
• Kontrolle des Speicherplatzbedarf
Durch Relationen wird der Speicherplatz entscheidend verringert. Sie Speichern z.B. die Kundenadressen in einer separaten Tabelle. Jeder neuer Auftrag wird hier mit dem entsprechenden Eintrag verknüpft.
Die Informationen sind weit gestreut und in viele Kleinteile aufgeteilt, dadurch ist eine Schätzung einfacher.
• Schemata, etc.

Für einige Unternehmen aus den verschiedensten Branchen durfte ich das DatenbankDesign erstellen. Hierbei hatte ich das Glück, kleine Datenbanken mit vielleicht 10 bis 20 Tabellen bis hin zu mehreren TerraByte großen Datenbanken und weit über 100 Tabellen zu entwerfen. Um dies zu gewährleisten, ist eine vollständiges Verständnis sowohl der Datenbank als auch des Problems von entscheidender Bedeutung.

Mit meiner Erfahrung in diesem Bereich berate und unterstütze ich Sie gerne. Rufen Sie mich an oder schreiben Sie mir eine Email, um ein erstes kostenloses Beratungsgespräch zu vereinbaren.

Datenbankprogrammierung

Steht das Datenbankdesign, so sollte die Datenbank mit Logik und Inhalt gefüllt werden. Natürlich kann man dies mit SQL-Anweisungen realisieren. Aber warum ? Natürlich kann man Daten via eines INSERT-Statement einfügen. Das Einfügen erfolgt normalerweise nicht nur über einen Weg. Sie importieren diese, Sie haben eine Benutzeroberfläche für die Eingabe, Sie erhalten die Daten über ein WebPortal oder ein Interface usw. . Sollten hier Anpassungen notwendig sein, so müssen Sie mehrere Stellen verändern. Dies ist fehleranfällig und ineffektiv. Warum also z.B. nicht eine stored Procedure nutzen?

In relationalen Datenbanken sind die Daten auf verschiedene Tabellen verteilt. So trennt man z.B. den Kunden von der Bestellung. Soll die Bestellung jedoch angezeigt oder ausgedruckt werden, so müssen die Tabellen zusammengeführt werden. Auch hier gibt es verschiedene Varianten: die Verwendung von Views, indizierten Views oder tabellenliefernden Funktionen.

Trigger können z.B. für die Datenintegrität eingesetzt werden. Sie finden jedoch auch Verwendung wenn Sie Veränderungen an den Daten mitprotokollieren wollen.

Sehr viele Bücher beschäftigen sich sehr viel ausführlicher mit diesen Themen und dabei habe ich nur sehr wenige bisher kurz skizziert. Die folgenden Themen sollte jeder Datenbankentwickler beherrschen:

• Benutzerdefinierte Datentypen
• Case
• Datentypen
• Error Handling
• Gruppieren, Sortieren und Filtern
• Indexe
• Left Outer Join, Inner Join, Right Outer Join
• Merge
• Optimierung von Abfragen
• Pivot
• Schemata
• Temporäre Tabellen
• Transaktionen
• Union, Union all, Intersect, Except
• XML

Branchenübergreifend habe ich für einfachere und komplexe Datenbanksysteme entsprechende Objekte konzipiert, programmiert und optimiert.

Mit meinem umfassenden Wissen in diesem Bereich berate und unterstütze ich Sie gerne. Rufen Sie mich an oder schreiben Sie mir eine EMail um ein erstes unverbindliches Beratungsgespräch zu vereinbaren.