Tipps für besseres Datenbankdesign

Im Laufe der Jahre habe ich als Datenmodellierer und Datenbankarchitekt festgestellt, dass es einige Regeln gibt, die bei der Datenmodellierung und -entwicklung befolgt werden sollten. Hier beschreibe ich einige Tipps in der Hoffnung, dass sie Ihnen helfen könnten. Ich habe die Tipps in der Reihenfolge aufgelistet, in der sie während des Projektlebenszyklus auftreten, anstatt sie nach Wichtigkeit oder Häufigkeit aufzulisten.

1. Vorausplanen

Wer nicht plant, plant zu scheitern.

Alan Lakein

Ein Problem, das ich gesehen habe, ist, wenn die Datenmodellierung gleichzeitig mit der Softwareentwicklung erfolgt. Das ist, als würde man das Fundament bauen, bevor man die Blaupausen fertigstellt. In der Vergangenheit schien die Planung ein naheliegender Schritt vor Beginn der Entwicklung zu sein. Entwicklungsteams würden keine Datenbanken ohne Planung erstellen, genauso wie Architekten keine Gebäude ohne Baupläne bauen würden.

Bei der Anwendungsentwicklung ist es wichtig, die Art der Daten zu verstehen.

Die Planung wird oft ignoriert, sodass Entwickler einfach „mit dem Programmieren beginnen“ können. Das Projekt beginnt und wenn Probleme auftreten, gibt es keinen Spielraum im Zeitplan, um sie anzugehen. Entwickler nehmen Abkürzungen mit der Absicht, sie später zu beheben, aber das passiert selten, wenn überhaupt.

Durch sorgfältige Planung stellen Sie sicher, dass Sie am Ende eine ordnungsgemäße Datenbank erhalten, die nicht zusammengehackt wurde. Wenn Sie nicht die Zeit und Mühe aufwenden, sich im Voraus mit den für die Prozesse erforderlichen Daten zu befassen, zahlen Sie später mit einer Datenbank, die überarbeitet, ersetzt oder verschrottet werden muss.

Auch wenn die Planung nicht immer abgeschlossen ist, folgen viele Datenmodellierer diesen Richtlinien. Das heißt nicht, dass wir jeden Designbedarf im Voraus vorhersagen können, aber die meisten Modellierer glauben, dass es die Mühe wert ist, die Daten und ihre Verwendung zu verstehen. Sie möchten kein Design für die Transaktionsverarbeitung, wenn es um die Erstellung von Analyseberichten geht.

Die Zeiten haben sich geändert; Agile Methoden sind weiter verbreitet, sodass Datenbankteams ihren Ansatz zur Datenmodellierung überdenken müssen. In Agile wird anstelle von Entity Relationship Diagrams das Domain Model aus Use Cases verwendet. Der Planungsbedarf hat jedoch nicht abgenommen. Wir müssen die Daten verstehen und verstehen, was sie bewirken sollen. Im Allgemeinen müssen sich die ersten paar Sprints auf das Datendesign konzentrieren.

Es ist also nicht Agile, das das Problem für Datenbankmodellierer ist, sondern eher Personen, die die Natur von Daten nicht verstehen. Einige sehen Datenbankentwicklung als dasselbe wie Anwendungsentwicklung. Datenbankmodellierung und Softwareentwicklung sind unterschiedlich und erfordern einen angemessenen Fokus.

Die Datenbank ist der Kern der meisten Softwareanwendungen. Sie müssen sich die Zeit nehmen, die Anforderungen zu analysieren und zu analysieren, wie das Datenmodell sie erfüllt. Dies verringert die Wahrscheinlichkeit, dass die Entwicklung Kurs und Richtung verliert.

Die Entwickler müssen die Bedeutung von Daten und ihren Beitrag zum Entwicklungsprozess verstehen. Wir leben im Informationszeitalter. Anwendungen zeigen Daten an und bearbeiten sie. Es sind die in den Daten enthaltenen Informationen, die der Anwendung Bedeutung verleihen.

Es ist nicht möglich, jede Anforderung oder jedes Problem vorherzusehen, aber es ist wichtig, sich durch sorgfältige Planung auf Probleme vorzubereiten.

2. Dokumentieren Sie Ihr Modell

Bei der Erstellung eines Datenmodells scheint alles offensichtlich. Sie benennen die Objekte so, dass ihr Zweck offensichtlich ist und jeder die Bedeutung versteht, wenn er nur den Namen liest. Das mag stimmen, ist aber nicht so offensichtlich, wie Sie vielleicht denken. Machen Sie bei der Auswahl von Namen für Tabellen und Spalten deutlich, wofür die einzelnen Objekte verwendet werden. Mit der Zeit wird die Bedeutung von Objekten ohne Dokumentation unklar.

Die Verwendung einer Namenskonvention ist ein Schritt in Richtung einer effektiven Dokumentation. Wenn Sie in Zukunft Änderungen vornehmen müssen, werden Sie jede vorhandene Dokumentation zu schätzen wissen. Ein kurzes, einfaches Dokument, das die Entscheidungen beschreibt, die Sie getroffen haben, und das Design beschreibt, hilft dabei, die Designauswahl zu diesem Zeitpunkt zu erklären.

Sie möchten genügend Dokumentation, damit die Datenbank von einem neuen Administrator verwaltet werden kann und dieser die Bedeutung verstehen kann, ohne dass er Sie erneut um eine Erklärung bitten muss. Wenn das Datenmodell und die Umgebung nicht dokumentiert sind, ist es schwierig, es zu pflegen oder zu ändern, wenn sich die Anforderungen ändern.

Die Dokumentation hat teilweise wenig mit der Datenmodellierung zu tun. Bei der Dokumentation geht es darum, das Design zu kommunizieren und für die Zukunft verständlich zu machen.

Die Dokumentation ist oft ein nachträglicher Einfall. Bei knappen Zeitplänen wird die Dokumentation ignoriert. Dies ist jedoch eine technische Schuld mit hohen Kosten. Kürzungen während des Entwicklungszyklus werden in Zukunft Kosten für Datenbankänderungen, Problemidentifizierung, Verfolgung von Fehlern und für das Verständnis des Datenmodells und der Art der Daten verursachen.

Beispielsweise haben Datenmodelle oft ein „ID“-Feld als Primärschlüssel für eine Tabelle oder einen Teil des Namens eines Schlüssels. Dies kann ein Primärschlüssel wie TransactionID sein auf der Transaction Tisch. Wenn einige Tabellen „Nummer“ als Teil des Namens eines Schlüssels verwenden, dann ist es gut zu dokumentieren, warum. Vielleicht ReferenceNumber wird als Name des Primärschlüssels auf der Nachricht verwendet, da die Referenz im Geschäftsbereich so genannt wird. Beispielsweise enthalten Finanznachrichten bei Finanzdienstleistungen normalerweise eine Referenznummer.

Dokumentieren Sie die Definition von Tabellen, Spalten und Beziehungen, damit Programmierer auf die Informationen zugreifen können. Die Dokumentation muss die Erwartungen an die Datenbankstruktur beschreiben.

Im Vertabelo-Tool kann ich sofort Kommentare zu jedem Element einfügen:Tabellen, Spalten, Verweise, alternative Schlüssel, was bedeutet, dass die Dokumentation sofort mit meinem Modell gespeichert wird und nicht in einem separaten Dokument, das separat gepflegt werden muss.

Schlechte oder fehlende Dokumentation ist oft auf kurzsichtiges Denken zurückzuführen, aber ignorieren Sie nicht deren Bedeutung. Dies ist noch ein Problem, das angegangen werden muss.

3. Konventionen einhalten

Namenskonventionen scheinen während des Entwurfs nicht wichtig zu sein. In Wirklichkeit geben Namen den Einblick, um ein Modell zu verstehen. Sie sind eine Einführung und sollten logisch sein.

Uneinheitliche Benennung ist zwecklos. Es frustriert nur Entwickler, die auf die Daten zugreifen müssen, Administratoren der Datenbank und Modellierer, die in Zukunft Änderungen vornehmen müssen.

Wenn „ID“ für einige künstliche Schlüssel verwendet wird, einige Tabellen jedoch eine andere Namenskonvention (z. B. Zahl) verwenden, verschwenden Entwickler, Analysten und DBAs möglicherweise Zeit, um die Ausnahmen zu verstehen. Auch schwache Namenskonventionen führen zu Fehlern in der Entwicklung, da die Namensgebung nicht konsistent ist.

Hand in Hand mit der Dokumentation sorgt die Verwendung einer Namenskonvention dafür, dass jemand das Modell in Zukunft versteht. Wechseln Sie nicht willkürlich zwischen der Verwendung von „ID“ (wie CustomerID). ) und „Nummer“ (AccountNumber ) als Schlüssel für Tabellen. Machen Sie nur Ausnahmen von den Konventionen, wenn sie gerechtfertigt sind. Dokumentieren Sie, was die Ausnahme ist und warum die Konvention nicht eingehalten wird.

Gleiches gilt für kryptische Namen wie „XRT1“ – sind das die erweiterten Referenztabellen? Deine Vermutung ist genauso gut wie meine. Ich hoffe, dass der Designer wusste, warum er einen so kryptischen Namen gewählt hat, aber ich bezweifle, dass die nächste Person, die auf die Datenbank zugreift, den Grund erraten kann.

Namenskonventionen sind eine Frage der persönlichen Wahl. Stellen Sie sicher, dass Entscheidungen konsistent und dokumentiert sind.

Wenn es mir gelungen ist, Sie davon zu überzeugen, die Namenskonvention in Ihrem Datenbankdesign anzuwenden, können Sie gerne meinen nächsten Artikel lesen, der sich ausschließlich diesem Thema widmet.

4. Denken Sie sorgfältig über Schlüssel nach

Schlüssel erzeugen oft Kontroversen:Primärschlüssel, Fremdschlüssel und künstliche Schlüssel. Tabellen benötigen einen Primärschlüssel, der jede Zeile identifiziert. Die Kunst besteht darin, zu entscheiden, welche Spalten Teil des Primärschlüssels sein sollen und welche Werte enthalten sein sollen.

Für eine ordnungsgemäße Normalisierung benötigt jede Tabelle einen Identifizierungsschlüssel. Die Eindeutigkeit muss gewährleistet sein. Natürliche Schlüssel und Primärschlüssel müssen jedoch nicht identisch sein. Tatsächlich sind sie es möglicherweise nicht, solange die Tabelle einen natürlichen Schlüssel hat.

Einige Datenmodellierer bevorzugen einen künstlichen Schlüssel für die Eindeutigkeit. Einige Modellierer bevorzugen jedoch einen natürlichen Schlüssel, um die Datenintegrität sicherzustellen.

Sollten wir also einen natürlichen Schlüssel als Primärschlüssel verwenden? Eine Herausforderung entsteht, wenn der natürliche Schlüssel geändert werden muss. Wenn der natürliche Schlüssel aus vielen Spalten besteht, müssen Sie möglicherweise an vielen Stellen Änderungen vornehmen. Eine weitere Herausforderung besteht darin, einen künstlichen Schlüssel als einzigen Schlüssel für eine Tabelle zu verwenden.

Beispielsweise könnten Sie eine Tabelle haben, in der Informationen zu Produkten gespeichert sind. Die Tabelle kann mit einem künstlichen Schlüssel wie einer Sequenz, einem Code für den kurzen alphabetischen Namen für das Produkt und der Produktdefinition definiert werden. Wenn die Eindeutigkeit nur durch den künstlichen Schlüssel gewährleistet ist, können zwei Zeilen mit demselben Produktcode vorhanden sein. Handelt es sich um dasselbe Produkt, das zweimal eingegeben wird? Vielleicht ist ein Schlüssel mit dem Produktcode besser geeignet.

5. Verwenden Sie Integritätsprüfungen mit Bedacht

Um die Datenintegrität zu gewährleisten, benötigen wir Fremdschlüssel und Einschränkungen. Achten Sie darauf, diese Integritätsprüfungen nicht zu häufig oder zu wenig zu verwenden.

Domänentabellen sind effektiv, um die Integrität zu erzwingen. Domänentabellen funktionieren gut, wenn viele Werte geprüft werden müssen oder sich die zu prüfenden Werte häufig ändern.

Ein Problem kann sein, dass Entwickler entscheiden, dass die Anwendung die Integrität überprüft. Das Problem dabei ist, dass viele Anwendungen auf eine zentrale Datenbank zugreifen können. Außerdem möchten Sie im Allgemeinen die Daten dort schützen, wo sie sind:in der Datenbank.

Wenn die möglichen Werte begrenzt sind oder in einem Bereich liegen, ist möglicherweise eine Prüfbedingung vorzuziehen. Nehmen wir an, dass Nachrichten entweder als eingehend oder als ausgehend definiert sind, in diesem Fall ist kein Fremdschlüssel erforderlich. Aber für so etwas wie gültige Währungen mögen diese zwar statisch erscheinen, sie ändern sich jedoch von Zeit zu Zeit. Länder treten einer Währungsunion bei und Währungen ändern sich.

Anwendungen sollten auch Integritätsprüfungen durchführen, aber verlassen Sie sich bei der Integritätsprüfung nicht nur auf die Anwendung. Das Definieren von Integritätsregeln für die Datenbank stellt sicher, dass diese Regeln niemals verletzt werden. Auf diese Weise erfüllen die Daten jederzeit die definierten Integritätsregeln.

6. Vergiss Indexe in deinem Design nicht

Ein gewisses Indizierungsdesign ist während der Datenbankmodellierung nützlich, selbst wenn sich Indizes während der tatsächlichen Bereitstellung und Verwendung ändern können. Natürlich ist es möglich, zu viele Indizes zu haben, genauso wie es möglich ist, zu wenige zu haben.

Die Indexierung ist ein fortlaufender Prozess. Während des Entwurfs starten Sie den Prozess an Ihrem Modell. Die Entwurfsarbeit betrifft die Primärschlüssel und Einschränkungen.

Indizes sind wichtig, wenn Abfragen zu den Daten in Erwägung gezogen werden. Bei der Modellierung sollten Sie berücksichtigen, wie die Daten abgefragt werden. Achten Sie darauf, nicht zu überindizieren. Die Indizierung dreht sich um die Abfrageoptimierung.

7. Vermeiden Sie allgemeine Nachschlagetabellen

Ich habe oft eine gemeinsame Nachschlagetabelle für Attributpaare gesehen. Das Definieren einer einzigen, generischen Domänentabelle vereinfacht das Design. Dieser Stil von Domänentabellen ist eine abstrakte Definition für das Halten von Text. Ich habe gehört, dass es eine „Zulässiger-Wert“- oder „Gültige-Werte“-Tabelle genannt wird, aber der Begriff „MUCK“-Tabelle wurde 2006 für dieses Antimuster geprägt:Massively Unified Code-Key.

MUCK-Tabellen enthalten nicht zusammenhängende Daten.

Beispielsweise könnten Sie eine Tabelle haben, die die Domäne, den Eintrag und eine Beschreibung definiert. Wenn Sie an das obige Nachrichtenbeispiel zurückdenken, könnten zwei Einträge lauten:

Fügen Sie nun Einträge für eine andere Domain hinzu:

Das ist nur ein Durcheinander. Was bedeutet die Tabelle?

Nur zum Spaß habe ich ein einfaches Beispiel einer MUCK-Tabelle (oder OTLT, „One True Lookup Table“, wenn Sie ein Tolkien-Fan sind) modelliert und einige Kommentare eingefügt. Bitte beachten Sie, dass dies ein Anti-Pattern ist und ich nicht empfehle, es in Ihrem Datenmodell zu verwenden.

Bei MUCK-Tabellen können keine Constraints definiert werden. MUCKs können zu vielen Zeilen ohne Bedeutung werden. Wenn Sie eine andere Tabelle abfragen müssen, um die Bedeutung eines Felds zu verstehen, ist dies nicht ideal.

Diese „Anything goes“-Tabellen machen Integritätsprüfungen komplex oder sogar unmöglich. Ein Grund, warum diese Tabellen erstellt werden können, liegt darin, dass mehrere Tabellen in der Datenbank eine ähnliche Definition haben. Dann werden Datenintegritätsprüfungen unmöglich. Außerdem können sie ziemlich groß werden.

Die Normalisierung sollte von MUCK-Tabellen wegführen. Eine einzelne Tabelle sollte eine einzelne Domäne darstellen; statt einer einzigen (MUCK)-Tabelle, die alle Domänen darstellt. Ohne MUCK-Tabellen können wir Fremdschlüsselbeschränkungen einrichten.

Verwenden Sie separate Tabellen für Domänenobjekte, anstatt sie in eine einzige Tabelle zu stopfen. Dies ermöglicht die richtigen Spaltentypen, Einschränkungen und Beziehungen. Eine „Zulässige Werte“-Tabelle ist nur Mist und hat in einem Datenmodell nichts zu suchen.

8. Definieren Sie eine Archivierungsstrategie

Allzu oft habe ich Datenbanken gesehen, die ohne eine angemessene Strategie zur Datenaufbewahrung und -archivierung erstellt wurden. Wie lange werden Daten in aktiven Datenbanktabellen online verfügbar gehalten? Die meisten Systeme sind darauf ausgelegt, Daten „für immer“ in der Datenbank zu halten. Für die meisten Systeme ist dies keine vernünftige langfristige Datenaufbewahrungsstrategie. Irgendwann sollten aktive Daten archiviert werden.

Ein Ansatz, den ich befürworte, besteht darin, die Datenaufbewahrung als Teil Ihrer Designüberlegungen einzubeziehen. Werden Sie aktive und historische Tabellen haben, damit das Einfügen neuer Zeilen in die aktiven Tabellen schnell bleibt, während die Suche nach historischen Daten optimiert werden kann?

Dadurch wird vermieden, dass die Archivierung in Ihrer Datenbank zusätzlich zum ursprünglichen Design neu gestaltet werden muss.

9. Testen Sie früh, testen Sie oft

Um Al Capone (oder John Van Buren, Sohn des 8. US-Präsidenten) zu paraphrasieren:„Teste früh, teste oft“. Damit gehen Sie den Weg der Continuous Integration. Das Testen in einem frühen Entwicklungsstadium spart Zeit und Geld.

Testen ist immer eine Herausforderung im Entwicklungsplan. Am Ende eines Agile Sprints steht oft eine Testphase und am Ende der Entwicklung ein Systemtest. Das Testen ist im Allgemeinen das erste, was man unter Druck setzen muss, wenn die Zeit knapp wird.

Beim Testen der Datenbank sollte das Ziel sein, eine Produktionsumgebung zu simulieren:„Ein Tag im Leben der Datenbank“. Welche Volumina sind zu erwarten? Welche Benutzerinteraktionen sind wahrscheinlich? Werden die Grenzfälle behandelt?

Daher müssen der Testplan und das richtige Testen ein integraler Bestandteil der Datenmodellierung und Datenbankentwicklung sein.

Schlussfolgerung

Dies sind die Hauptprobleme, die mir bei der Arbeit mit Datenmodellierern und der Überprüfung von Datenmodellen aufgefallen sind. Wenn Sie diese Tipps beachten, wird Ihre Datenbank besser gestaltet und robuster. Die Amortisation einiger dieser Investitionen ist jedoch nicht immer offensichtlich oder sichtbar. Planen, dokumentieren, verwenden Sie Standards, erstellen Sie Schlüssel, stellen Sie die Integrität sicher, führen Sie Indizierungen durch, vermeiden Sie MUCK, entwickeln Sie Strategien und testen Sie!

Keine dieser Aktivitäten nimmt enorm viel Zeit in Anspruch und hat dennoch enorme Auswirkungen auf die Qualität Ihres Datenmodells.

Was halten Sie von diesen Tipps?

Haben Sie eigene Tipps?