Das Datenbankdesign ist einer der wichtigsten Faktoren, die zur Leistung einer Anwendung beitragen. Daher ist es von größter Bedeutung, wie gut die Datenbank gestaltet ist. Beim Datenbankdesign dreht sich alles um die effiziente Organisation von Daten basierend auf Produkt-Workflows, zukünftiger Roadmap und erwarteten Nutzungsmustern.
Das Ergebnis einer Datenbankentwurfsübung ist ein Datenmodell. Ein Datenmodell repräsentiert alle Objekte, Entitäten, Attribute, Beziehungen und Einschränkungen im System. Grob gesagt gibt es zwei Arten von Datenmodellen:logisch oder physisch . Die Darstellung des Datenmodells erfolgt durch die Erstellung eines ER-Diagramms, auch Entity-Relationship-Diagramm, ERD-Diagramm oder Datenbankdiagramm genannt.
Das physische Datenmodell bezieht sich auf die tatsächlichen Implementierungsdetails in der Datenbank. Das logische Datenmodell hingegen abstrahiert die technischen Einzelheiten der Implementierung. Dadurch wird das logische Datenmodell für das Unternehmen nutzbar. Ein wesentlicher Unterschied zwischen den beiden Modellen besteht darin, dass das logische Modell datenbankunabhängig ist, während das physische Modell spezifisch für die verwendete Datenbank sein muss.
Das richtige Datenbankdesign wird während der Anwendungsentwicklung oft unterschätzt und vernachlässigt. Die Kosten für diese Vernachlässigung werden normalerweise viel später realisiert, wenn neue Anwendungsfunktionen eingeführt werden oder wenn alte Funktionen geändert werden müssen. In diesem Fall macht das Datenbankdesign keinen Sinn mehr. Es ist zwar nicht möglich, das Design einer Datenbank zukunftssicher zu machen, aber es ist durchaus möglich, sich zu bemühen, die geschäftlichen Anwendungsfälle bestmöglich zu verstehen und die Datenbank entsprechend zu gestalten. Lesen Sie hier mehr über Tipps für ein besseres Datenbankdesign.
Lassen Sie uns vor diesem Hintergrund die Schritte des Datenbankdesigns durchgehen.
Schritt 1:Geschäftsanforderungen sammeln
Der erste Schritt besteht darin, mit dem Unternehmen über seine Anforderungen zu sprechen. Wenn das Gespräch erfolgreich ist, sollte es zu genügend Informationen führen, um mit der Arbeit an einem konzeptionellen Datenmodell zu beginnen, das eine Abstraktion des logischen Modells ist. Das Gespräch mit dem Unternehmen liefert zunächst ein vollständiges Bild der Geschäftsprozesse, das wiederum Informationen über die verschiedenen Datenpunkte liefert, die für das Unternehmen wichtig sind, um erfasst und verfolgt zu werden. Bei einem Taxibuchungsmodell lohnt es sich beispielsweise, die folgenden Fragen zu stellen:
- Möchte das Unternehmen die Fahrzeugortungsdaten in der Datenbank haben, unabhängig davon, ob es eine aktive Fahrt gibt oder nicht? Wenn ja, dann das Feld
vehicle_trip_id
in der Tabellevehicle_trips
wäre nullable . Andernfalls ist es nicht nullable . - Wünscht das Unternehmen den Verlauf der Änderungen an
trip_status
in der Datenbank gespeichert? Wenn ja, dann jedesmal dertrip_status
Änderungen gibt es einen weiteren Datensatz in dentrips
Tisch. Ansonsten jedesmal dertrip_status
Änderungen,trip_status
wird vor Ort aktualisiert.
Wie in diesem Beispiel gezeigt, würden Sie basierend auf den Eingaben des Unternehmens am Ende eine Option der anderen vorziehen. Dies würde zu einer Änderung der betroffenen Entitäten und ihrer Beziehungen führen.
Das Sammeln von Anforderungen beinhaltet im Allgemeinen auch das Initiieren eines Gesprächs über die Datensicherheit, z. B. welche Daten maskiert und verschlüsselt werden sollen. Die Anforderungssammlung führt zu einem Anforderungsdokument, das häufig durch einen Arbeitsentwurf des konzeptionellen Datenmodells unterstützt wird.
Schritt 2:Unternehmensfahrplan verstehen
Unternehmen ändern ständig ihre Prozesse; ihre Anpassungsfähigkeit macht sie weniger wahrscheinlich zu scheitern. Veränderte Geschäftsprozesse bedeuten veränderte Workflows und Datenmodelle. Obwohl es nicht möglich ist, diese Änderungen lange im Voraus zu kennen, ist es sicherlich möglich, mit der Business-Roadmap auf dem Laufenden zu bleiben.
Wenn ein Unternehmen beispielsweise plant, auf eine neue geografische Region abzuzielen, müsste das Modell Sprachunterstützung, Währungen, Zeitzonen usw. berücksichtigen. Die Vorteile des Verständnisses der langfristigen Geschäfts-Roadmap zeigen sich oft in einem reibungsloseren Übergang zu neuen Geschäftsprozessen.
Lassen Sie mich ein weiteres Beispiel nennen, bei dem es mehr um die sich ständig weiterentwickelnden Geschäftsprioritäten geht. Das Taxigeschäft war zu Beginn von COVID-19 stark betroffen. Als Taxiunternehmen möchten Sie präventiv handeln, um den Menschen zu versichern, dass Sie alles tun, um sicherzustellen, dass Ihre Fahrt im Taxi so sicher wie möglich ist, dass das Fahrzeug täglich desinfiziert wird, dass der Fahrer überhaupt eine Maske trägt Mal, und dass es in der Kabine Händedesinfektionsmittel gibt. Um nun all diese Informationen zu erfassen, werden Änderungen an zwei Entitäten vorgenommen, drivers
und vehicles
, wäre erforderlich. Mehrere boolesche Flag-Felder müssen diesen Entitäten hinzugefügt werden, um diesem geschäftlichen Anwendungsfall gerecht zu werden.
Schritt 3:Entitäten und Attribute identifizieren
Sobald die Geschäftsanforderungen erfasst sind, können die Informationen verwendet werden, um Entitäten zusammen mit den wesentlichen Attributen zu identifizieren. Eine oder mehrere Entitäten werden im Allgemeinen direkt Geschäftsprozessen zugeordnet, und die Beziehung zwischen diesen Entitäten ahmt auch den Geschäftsprozess-Workflow nach.
Dieser Schritt wird auch verwendet, um zu identifizieren, welche Attribute als Identifikatoren in den Entitäten fungieren. Bezeichner werden im physischen Modell in Primärschlüssel übersetzt. Außerdem ist es üblich, in diesem Schritt Datentypen für alle Attribute anzugeben.
Im Taxibuchungsmodell müssten Sie beispielsweise die Attribute identifizieren, die als Pflichtfelder für die Registrierung von Benutzern und Fahrern aus der Buchungs-App dienen. Die Benutzerregistrierung würde mit user_phone
erfolgen und die Fahrerregistrierung würde mit driver_phone
erfolgen .
In ähnlicher Weise werden während dieses Schritts andere Entitäten und Attribute identifiziert, nachdem sie den Geschäftsprozess-Workflows zugeordnet wurden.
Schritt 4:Beziehungen identifizieren
Nach der Identifizierung der Entitäten und ihrer Attribute besteht der nächste Schritt darin, die Beziehungen zwischen den Entitäten basierend auf den Geschäftsabläufen zu definieren, die in der Anforderungserfassungsphase dokumentiert wurden. Neben der Feststellung, dass eine Beziehung zwischen zwei Entitäten besteht, ist es auch wichtig, festzustellen, welche der folgenden vier Arten von Beziehungen zwischen ihnen bestehen. Stellen Sie sich zwei willkürliche Entitäten vor, A und B:
- Eins-zu-eins → Ein Datensatz in A entspricht höchstens einem Datensatz in B.
- One-to-many → Ein Datensatz in A entspricht vielen Datensätzen in B.
- Many-to-One → Viele Datensätze in A entsprechen höchstens einem Datensatz in B.
- Many-to-many → Viele Datensätze in A entsprechen vielen Datensätzen in B.
Bei dem Taxibuchungsmodell wurde nur eine Art von Beziehung verwendet, d. h. Eins-zu-Viele. Nehmen Sie die Beziehung zwischen users
und trips
als Beispiel. In dem Modell wird davon ausgegangen, dass nur ein Benutzer mit einer Fahrt in Verbindung stehen kann, was impliziert, dass es keine gemeinsam genutzten oder gepoolten Taxis gibt. Aber wenn es gemeinsam genutzte oder gepoolte Taxis gegeben hätte, hätte es möglicherweise eine Viele-zu-Viele-Beziehung zwischen users
und trips
, wenn viele Benutzer dieselbe trip_id
teilen .
Schritt 5:Erstellen Sie ein logisches ER-Diagramm
Nachdem Entitäten, Attribute und Entitätsbeziehungen definiert sind, besteht der unmittelbar nächste Schritt darin, das ER-Diagramm zu zeichnen. Alle oben aufgeführten Schritte können in Vertabelo durchgeführt werden. Es gibt keine festen Regeln für die Art und Weise, wie logische Modellierung durchgeführt werden soll, mit der möglichen Ausnahme der Referenznotation.
Schauen Sie sich zum Beispiel das folgende Beispiel eines logischen ER-Diagramms an. Es erfasst einen einfachen Geschäftsablauf eines Taxiunternehmens, bei dem ein Benutzer eine Fahrt mit der Möglichkeit buchen kann, das Fahrzeug zu verfolgen.
Schritt 6:Validieren Sie das logische ER-Diagramm
Die logische Modellierung ist ein Prozess, bei dem viele Geschäftsinformationen in ein Datenbankdesign übersetzt werden müssen. Ohne gründliche Prüfungen ist diese Phase der Datenbankentwicklung anfällig für Fehler, die sich später als sehr kostspielig erweisen können.
Um dies zu gewährleisten, verfügt Vertabelo über eine gründliche Liste von Prüfungen, die an einem logischen Modell durchgeführt werden können. Prüfungen können in allen Granularitäten durchgeführt werden, vom Modell als Ganzes bis hin zu einzelnen Attributen und allem dazwischen. Einige der einfachen Überprüfungen sind:
- Namen von Entitäten, Attributen, Beziehungen usw. dürfen nicht null sein und müssen eindeutig sein.
- Eine Entität muss mindestens 1 Attribut haben.
- Identifikatoren (PKs) müssen für jede Entität definiert werden.
- Das Modell muss einen der aufgelisteten Datentypen für Attribute verwenden.
Alle diese Überprüfungen sind optional und können so konfiguriert werden, dass sie übersprungen werden, wenn ein anderes Validierungs-Framework vorhanden ist. Die ordnungsgemäße Validierung von Vertabelo hilft Ihnen, mit möglichst geringem Aufwand zum nächsten Schritt zu gelangen.
Schritt 7:Erstellen Sie ein physisches ER-Diagramm
Sobald das logische ER-Diagramm erstellt ist, besteht der nächste Schritt darin, ein physisches Datenmodell zu erstellen. Das physische Datenmodell ist spezifisch für die Datenbank, in der Sie das Datenmodell bereitstellen möchten. Alle Datenbanken haben ihre eigene Implementierung von Nomenklaturregeln, Datentypen und Beschränkungen. Aus diesem Grund unterscheidet sich die Data Definition Language (DDL) oft von einer Datenbank zur anderen.
Gehen Sie folgendermaßen vor, um ein physisches Datenmodell zu erstellen:
- Suchen Sie den nächsten Datentyp in der Zieldatenbank, um den im logischen Datenmodell ausgewählten generischen Datentyp zu ersetzen.
- Befolgen Sie die von der Zieldatenbank vorgeschriebenen Nomenklaturregeln für Tabellen, Spalten und Einschränkungen.
- Ändern Sie das Modell, um es an vordefinierten Abfrage-Workflows auszurichten. Dies führt im Allgemeinen zu einer zunehmenden Redundanz zum Speichern von Joins.
- Schließlich können Sie Indizes, Partitionen, Verteilungsschlüssel und Sortierschlüssel erstellen. Hier können Sie alle leistungssteigernden Änderungen am Modell vornehmen.
Diese Schritte können mit jedem Datenmodellierungstool ausgeführt werden, mit dem Sie ein Datenmodell von Grund auf neu erstellen können. Vertabelo bietet jedoch die Möglichkeit, ein logisches Datenmodell in ein vollwertiges physisches Datenmodell für alle wichtigen Datenbanksysteme wie MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery und mehr umzuwandeln. Sobald das logische Datenmodell in ein physisches Datenmodell umgewandelt wurde, können Sie mit den vier besprochenen Schritten fortfahren.
Vertabelo hat auch die Möglichkeit, Skripte vor und nach der Bereitstellung auf Tabellenebene hinzuzufügen, zusammen mit Kommentaren auf der sehr granularen Ebene des Modells. Die Kommentare erweisen sich als praktisch, wenn die von Vertabelo angebotene Dokumentationserstellungsfunktion verwendet wird. Das Datenbankdokument kann in eines der folgenden drei Formate exportiert werden:HTML, PDF oder DOCX.
Lassen Sie uns mit dem Taxibuchungsbeispiel fortfahren und einen Blick auf das von Vertabelo generierte physische Datenmodell werfen.
Schritt 8:Validieren Sie das physische ER-Diagramm
So wie das logische ER-Diagramm validiert wurde, verfügt Vertabelo über ein Tool zum Validieren physischer ER-Diagramme mit mehreren zusätzlichen Prüfungen, z. B. ob FKs vorhanden sind oder nicht und ob die Länge eines Tabellennamens oder eines Spaltennamens das Limit basierend auf der ausgewählten Datenbank überschreitet.
Die Validierung muss nicht explizit ausgeführt werden. Dies geschieht, wenn das Diagramm geändert wird. Die Probleme mit dem Modell fallen in eine von drei Kategorien:Fehler, Warnungen und Hinweise, sortiert nach abnehmendem Schweregrad. Es gibt einen nützlichen, gut geschriebenen Artikel, der über die häufigsten Fehler spricht, die während des Datenbankdesignprozesses gemacht werden.
Schritt 9:Probleme mit dem physischen ER-Diagramm beheben
Die Ergebnisse der Validierung können Probleme identifizieren, die behoben werden müssen. Einige der häufigsten Probleme sind:
- Fehlende Fremdschlüssel, wenn Entitätsbeziehungen definiert wurden.
- Fehlende Primärschlüssel aus Tabellen.
- Nicht unterstützte Datentypen für die ausgewählte Datenbank.
Sobald diese und andere ähnliche Probleme gelöst sind, kann das Modell in ein bereitstellbares SQL-Skript für das ausgewählte Datenbankverwaltungssystem exportiert werden.
Schritt 10:Generieren Sie die DDL-Skripts zum Bereitstellen des Modells
Beim Datenbankdesign geht es nicht nur um die Erstellung von ER-Diagrammen. Eine Datenmodellierungsübung mit ER-Diagrammen ist nur dann erfolgreich, wenn sie zu etwas Verwendbarem führt. Vertabelo bietet eine praktische Option zum Exportieren des physischen Modells in ein einsatzbereites SQL-Skript. Nach der Generierung können alle ausstehenden Probleme direkt im SQL-Skript gelöst werden.
Es wird jedoch nicht empfohlen, das generierte SQL-Skript zu ändern. Es verursacht eine Drift zwischen dem physikalischen Datenmodell und dem auf der Datenbank bereitgestellten SQL-Skript, was auch eine Abweichung zwischen den eigentlichen Tabellen und der Datenbankdokumentation bedeuten kann.
Nun, da wir das Ende des Datenbankdesignprozesses erreicht haben, werfen wir einen Blick auf den von Vertabelo generierten SQL-Code.
Teilen Sie Ihre Gedanken mit
Das Datenbankdesign ist eine wichtige Aktivität in der Softwareentwicklung. Das Gebiet des Datenbankdesigns hat sich im Laufe der Jahre mit neuen Möglichkeiten entwickelt, das Design für das Unternehmen, für die Ingenieure und für die Datenanalysten darzustellen. Dies hat oft zu neuen Arten von Diagrammen, Modellierungsstandards und Notationen geführt. Ein Großteil der Entwicklung wurde im Abschnitt Design-Grundlagen behandelt.
Wir würden uns freuen zu sehen, welche Erfahrungen Sie beim Entwerfen von Datenbanken gemacht haben. Schreiben Sie uns an [email protected].