Wenn Sie einen Blogbeitrag über Datenbankmodellierung schreiben, müssen Sie darauf vorbereitet sein, dass Ihr abstraktes Modell nicht den Bedürfnissen der meisten Leser entspricht. Der Grund ist einfach. Echte Datenbankmodelle werden normalerweise in enger Beziehung zu bestimmten Geschäfts- und Entwicklungsanforderungen erstellt, während dies bei Blogmodellen nicht der Fall ist.
In den letzten Wochen habe ich Blogbeiträge über das Erstellen von Datenbankmodellen geschrieben. Die Themen reichten von einem allgemeinen Ansatz zur Datenbankmodellierung über ein einfaches Online-Forum bis hin zu einem Modell für eine komplexere Online-Umfrage.
Für jedes Datenbankmodell, das ich erstelle, versuche ich, die Geschäftsdomäne klar zu verstehen und in meinem Kopf das Gesamtbild des Modells auszuarbeiten.
Die Herausforderung der abstrakten Datenbankentwicklung
Normalerweise als Lösungs-Architekt , nehme ich spezifische Geschäftsanforderungen und wandle diese in die technischen Details dessen um, was von der technischen Seite erstellt werden muss:Übersetzen von der Geschäftssprache in die Fachsprache – Entwurf der Algorithmen auf hohem Niveau und Modellierung der Datenanforderungen für die Algorithmen.
Leider kann ich nicht über die realen Datenbankmodelle bloggen, die ich bei der Arbeit erstelle. Zum einen sind sie sehr geschäftsspezifisch und zum anderen bin ich durch Vertraulichkeitsvereinbarungen eingeschränkt. Für den Blog erstelle ich einen reinen Abstract Konzept ohne spezifische Geschäftsanforderungen, außer denen, die meiner Meinung nach in der Geschäftsdomäne existieren. Nun, das ist in Ordnung; Ich habe eine ziemlich gute Vorstellungskraft und weise häufig darauf hin, dass Ihre Anforderungen anders sein können, wenn ich die Entscheidungen beschreibe, die ich treffe. Aber dieser Blogging-Prozess hat mich darüber nachdenken lassen, wie sehr sich dieser Prozess von der Erstellung der Modelle in einem echten Projekt unterscheidet.
Der reale Entwicklungsprozess
In einer realen Situation würde ich eng mit dem Entwicklungsteam zusammenarbeiten, nachdem ich die allgemeine Lösung und das technische Design in einem interaktiven Verfahren erstellt habe so, dass das Modell den Entwicklungsanforderungen entspricht.
Die Entwickler könnten sich darüber beschweren, dass das Datenmodell zu normalisiert ist, um eine hohe Leistung zu unterstützen, oder sie könnten in bestimmten Bereichen eine zusätzliche Normalisierung verlangen. Wenn irgendwelche Alternate Keys fehlen würden, würden sich die Entwickler ziemlich schnell beschweren und wir würden es auch beim Performance-Test der Datenbank bemerken.
Wir würden überlegen, wie die genauen Feldlängen sein sollten, basierend auf der maximalen Länge der zu speichernden Daten und auf Designs von Bildschirmen für die Eingabe und Anzeige der Daten. Natürlich sind die genauen Feldlängen in einem konzeptionellen Datenbankmodell nicht wichtig.
Wir würden Beispiele dafür durcharbeiten, welche Daten in den Tabellen gespeichert werden und wie sie von der Anwendung verwendet werden, und Skripts erstellen, um die Tabellen für Komponententests der Anwendung vorab zu füllen. Auf diese Weise würden wir die Eckfälle abfangen, um sicherzustellen, dass das Modell die Grenzen der Anwendung unterstützt.
Im Grunde genommen würden wir das Modell so lange massieren, bis es die geschäftlichen und nicht funktionalen Anforderungen des Systems wirklich unterstützt, indem wir einen iterativen Prozess verwenden, bis wir ein Modell zu etwas entwickelt haben, das wir alle trotz der darin eingebauten Kompromisse akzeptieren können.
Wie gesagt, es wäre ein sehr iterativer Prozess, der sich über viele Monate hinziehen könnte, während der Anwendungscode, die Benutzeroberflächen und die Anwendungsschnittstellen entwickelt werden.
Einschränkungen von gut gemeintem Feedback
In der aktuellen Blogging-Situation gibt mir meine zugegebenermaßen begrenzte Anzahl von Lesern zwar Feedback zu Problemen und Herausforderungen, die sie bei den Modellen beobachten, aber zwangsläufig oberflächlich. Ich bezweifle, dass einer der Leser die Modelle direkt verwendet, um eine Anwendung zu erstellen und herauszufinden, was wirklich funktioniert und wo es Probleme gibt.
Kommentare wie „Modell nicht gut durchdacht“ sind also mit ziemlicher Sicherheit richtig. Auf der anderen Seite ist „es fehlen FKs“ ziemlich genau, aber ich habe hoffentlich im Text des Artikels erklärt, warum ich einen Fremdschlüssel einfüge oder nicht.
Schlussfolgerung
Bitte lesen Sie diesen Beitrag nicht als Beschwerde oder als Kommentar zum Feedback der Leser, sondern ich denke über die Schwierigkeit nach, ein Datenbankmodell zu erstellen, wenn Sie sich nicht in einer Umgebung befinden, die einen interaktiven Austausch mit einer Iteration ermöglicht Entwicklungsprozess.
Es gibt wahrscheinlich andere Situationen, in denen Datenbankmodellierer vom Entwicklungsprozess abgeschnitten sind, aber ich habe jetzt erkannt, wie gefährlich das wäre und wie anfällig für Probleme sie wären.
Können Sie sich ein Datenbankmodell vorstellen, das nie geändert wird? Nie eine einzelne Anpassung einer Spalte, nie das Hinzufügen eines Fremdschlüssels, nie die Notwendigkeit einer neuen Tabelle. Ehrlich gesagt, die einzige Situation, die ich mir so vorstellen kann, ist, wenn die Anwendung, die die Datenbank verwendet, sich nicht mehr weiterentwickelt und eine Sackgasse erreicht hat:das Lebensende.
