Best Practices für die Neugestaltung einer Datenbank

Ich kenne einige allgemeine Best Practices beim Entwerfen einer Datenbank für eine Anwendung, aber wie sieht es mit der Neugestaltung aus?

Ich bin in einem Team, das mit der Neugestaltung einer internen Geschäftsanwendung beauftragt ist, obwohl ich "intern" sage. Leider habe ich viele, viele Leute, die keinen Kontakt zu den tatsächlichen Benutzern des Systems haben.

Das aktuelle Programm liegt in Oracle Forms vor, verteilt auf eine Reihe nicht normalisierter Tabellen, manchmal mit mehreren nahezu doppelten Tabellen, die geringfügige Abweichungen von den Daten der jeweils anderen enthalten. Die Einschränkungen liegen häufig in Form von schlecht erzwungenen gespeicherten Prozeduren vor. Sogar die Typen scheinen nicht richtig gespeichert zu sein. Ich habe alle Arten von schlechten Daten gefunden, die Oracle zu ignorieren scheint, die aber dem Import / Export-Assistenten von SQL Server (und das zu Recht) entsprechen. (Zweistellige Ganzzahlen stellen beispielsweise keine vollständige Datums- und Uhrzeitangabe dar!)

Das ursprüngliche Programm ist wahrscheinlich zwanzig Jahre alt, und alle ursprünglichen Entwickler haben sich vor so langer Zeit zurückgezogen, dass selbst die älteren Leute hier keine Ahnung haben, wer sie waren. Infolgedessen müssen auch keine sauberen Anforderungen erfüllt werden. Wir sollen lediglich die Funktionalität der vorhandenen Anwendung duplizieren und die vorhandenen Daten beibehalten.

Das Endergebnis des Umschreibens wird eine webbasierte Version sein, die auf ASP.NET mit MS SQL Server für das Back-End ausgeführt wird.

Meine beiden anderen Entwicklerteamkollegen sind viel, viel älter als ich, beide mit Business / MIS-Hintergrund, während meine CS ist. Das Senior-Mitglied hat fast ausschließlich Erfahrung mit Oracle-Formularen und das andere Mitglied hat hauptsächlich in Visual Basic mit Geschäftsanwendungen gearbeitet. Obwohl sich mein Datenbankhintergrund darauf beschränkt hat, neue Datenbanken für Projekte in MySQL oder SQLite zu entwerfen, scheine ich der einzige zu sein, der überhaupt Erfahrung mit dem Entwerfen von Datenbanken hat.

Ich habe bereits ein kleines Programm in C # geschrieben, das alle vorhandenen Daten in einem neutralen Format einliest und bereit ist, neu umgewandelt und in eine neue Datenbank gestellt zu werden. Ich plane, den Lade-Code nach dem Entwurf der Zieldatenbank zu schreiben, damit die Daten ordnungsgemäß auf die neuen normalisierten Tabellen aufgeteilt und in der richtigen Reihenfolge hinzugefügt werden können, um neuen Einschränkungen zu folgen usw. Das gleiche Programm könnte dann später erneut ausgeführt werden um die Produktionsdaten in das real neu eingesetzte fertige Redesign zu kopieren. Dies lässt die eigentliche Neugestaltung der Datenbank als Hauptsache herauszufinden.

Der Kern meiner Frage lautet also: Was sind einige bewährte Methoden für ein Redesign von der Datenbankebene bis zu einer vorhandenen Anwendung?

Ich denke, Sie wissen bereits, wie man eine Datenbank normalisiert.

Was Sie brauchen, sind Strategien zur Risikominimierung, wenn Sie die gesamte Software in die neue Datenbank verschieben.

Was ich vorschlage, ist mehr Arbeit als Kompromiss für weniger Risiko.

Normalisieren Sie die Datenbank und erstellen Sie einen Prozess, um die normalisierte Datenbank mit Daten aus der ursprünglichen Datenbank zu füllen. Die ursprüngliche Datenbank ist die Datenbank für Einfügungen, Aktualisierungen und Löschvorgänge. Die normalisierte Datenbank ist nur während der Konvertierung die Abfragedatenbank.

Ihr Auffüllprozess muss so oft ausgeführt werden, wie Abfragedaten erforderlich sind. Wenn ein Tag alte Daten akzeptabel sind, können Sie einen nächtlichen Auffüllprozess ausführen. Wenn Sie aktuellere Daten benötigen, müssen Sie einen kontinuierlichen Auffüllprozess ausführen.

Erstellen Sie den Abfrageteil Ihres neuen ASP.NET-Systems und verweisen Sie auf die neue normalisierte Datenbank.

Die Abfrageergebnisse Ihres neuen Systems sollten mit den Abfrageergebnissen des ursprünglichen Systems verglichen werden.

Sie könnten an dieser Stelle aufhören. Das ist eine Geschäftsentscheidung, keine technische Entscheidung.

In Ihrer Freizeit erstellen Sie neue Funktionen zum Einfügen, Aktualisieren und Löschen in Ihrem neuen ASP.NET-System. Während Sie die neue Funktionalität erstellen, deaktivieren Sie die entsprechenden Teile des ursprünglichen Systems. Irgendwann bleibt nichts vom ursprünglichen System übrig.

Die Vorteile einer solchen Konvertierung bestehen darin, das Risiko zu verringern, indem zuerst der Abfrageteil erstellt wird. Im Allgemeinen sind die Abfragefunktionen im Vergleich zur in die Einfüge- / Aktualisierungs- / Löschfunktionalität eingebetteten Geschäftslogik einfach.

Sie konvertieren die Einfüge- / Aktualisierungs- / Löschfunktionalität prozessweise. Wenn es ein Problem mit dem Missverständnis der Geschäftslogik gibt, kann es behoben werden, während Ihre Benutzer das ursprüngliche System verwenden.

Es sollte selbstverständlich sein, dass Ihr Bestückungsprozess besser absolut konsistent ist.

Versuchen Sie, sie davon zu überzeugen, die Entwicklung des neuen Systems an ein externes Unternehmen zu vergeben. Es gibt viele gute Entwicklungsunternehmen, die über die Ressourcen verfügen, um Anwendungen schneller und besser als Ihr begrenztes Team zu entwickeln. Eine gute Entwicklungsfirma kann Ihre Vorgesetzten auch dazu zwingen, Dinge zu tun, die sie möglicherweise nicht tun, wenn Sie sie dazu auffordern. Der PM der Firma, der viel Geld für die Entwicklung einer App bekommt, hat eine viel größere Anziehungskraft, um die Benutzer einzubeziehen als der IT-Mann viele Ebenen unterhalb der Verwaltungsbehörde, um solche Dinge zu arrangieren.

Es kostet eine Menge Geld im Voraus, aber es lohnt sich sehr, über die richtigen Ressourcen für die Entwicklung und Implementierung zu verfügen. Wenn Sie es schaffen, eine Ausschreibung zu erhalten, würde ich wetten, dass die Angebote, die Sie erhalten, anzeigen, dass das, was Sie versuchen, weitaus komplizierter ist, als Ihre Manager erkennen.

Entwerfen Sie die benötigte normalisierte Datenbank mit den benötigten Datentypen. Der schwierigste Teil ist dann die Migration der Daten. Zuerst müssen Sie einen Plan haben, wie Sie von den alten auf die neuen Daten abbilden und was Sie mit Daten tun, die nicht der neuen Struktur entsprechen. Zum Beispiel könnten Sie Daten haben, die jetzt nicht identifizierbar sind, wenn Sie nicht die richtigen Integritätsbeschränkungen hatten. Möglicherweise möchten Sie diese Daten einfach nicht verschieben oder müssen sie verschieben, sondern an einen neuen übergeordneten Datensatz mit dem Namen "Unbekannt" anhängen. Wenn ein Datum kein richtiges Datum ist, können Sie bei der Migration eine Null in das Feld eingeben? Sie benötigen Antworten auf diese Fragen. Ich schlage vor, dass einige der Entwickler daran arbeiten, die Benutzeroberfläche zu ändern, um die neue Datenbankstruktur zu verwenden, und andere, um die Migration streng zu bearbeiten. Die Migration ist eine große Aufgabe, Es wird viel Geschick und viel Zeit in Anspruch nehmen. Lass es nicht im Nachhinein.

Da Sie SQL Server verwenden, können Sie die eigentliche Migration über SSIS durchführen.

Erstellen Sie einen soliden Satz von Testfällen, damit Sie die Ergebnisse mit dem alten System vergleichen können, die mit dem neuen System identisch sind.

Da Sie über so viele Jahre an Daten verfügen, möchten Sie die Migration möglicherweise in zwei Teilen durchführen. Migrieren Sie zuerst die meisten Daten und dann, wenn es Zeit ist, live zu gehen, nur die geänderten Daten. Natürlich müssten Sie Steuerelemente in der Datenbank einrichten, um geänderte Daten zu finden, die Sie möglicherweise noch nicht haben. Sie können zu diesem Zeitpunkt auch überlegen, ob Sie einige Daten archivieren möchten.

Ich bin fast täglich mit der Neugestaltung des Datenbankschemas konfrontiert, da mehrere ältere Anwendungen unterstützt und weiterentwickelt wurden, die als MS Access-Dateien (.mdb) erstellt wurden und dann zu großen Datenbanken mit mehreren Hundert Tabellen auf MS SQL heranwuchsen Server, aber immer noch mit den "Säuglingskrankheiten" des ursprünglichen Designs. Hier sind einige Praktiken, die ich für nützlich hielt:

Versuchen Sie, die öffentlich verfügbare Oberfläche Ihres Datenbankschemas zu minimieren.

Das bedeutet, dass Sie versuchen sollten, eine öffentliche API zu entwerfen, die Sie externen Anwendungen zur Verfügung stellen. Normalerweise versuche ich, die statischen Daten als Ansichten (auch wenn sie nur auf einer einzelnen Tabelle basieren) und die dynamischen Daten als parametrisierte Ansichten oder als gespeicherte Prozeduren zu implementieren. Für Datenabfragen, bei denen nur ein einziger Wert ausreicht, können auch skalare Funktionen verwendet werden.

Nur diese (Ansichten, gespeicherte Prozeduren und skalare Funktionen) sind für externe Anwendungen (über ORM oder direkt) sichtbar und werden für alle CRUD-Vorgänge verwendet. Dieses Schema wird dann vollständig eingefroren, während Sie intern möglicherweise die zugrunde liegenden Tabellen ändern, Ihre Prozeduren verbessern usw. - dies beeinträchtigt nicht die Kompatibilität zu Ihrer Anwendung.

Versuchen Sie, nach realen Kriterien zu optimieren, nicht nach Kriterien aus Büchern.

Normalisierung ist ein großes Thema in jedem Buch über Datenbankdesign. Aber im wirklichen Leben gibt es Fälle, in denen die Normalisierung nicht viel bringt oder sogar Ihre Datenbank verlangsamt, zum Beispiel wenn Sie einige Daten haben, die wiederholt werden, aber der Prozentsatz der Wiederholungen sehr gering ist usw. Ich bin nicht gegen die Normalisierung. Ich versuche hier zu sagen, dass Sie mit Skepsis und Umsicht dagegen vorgehen müssen.

Zeichnen Sie die Profilerstellungssitzung auf und analysieren Sie sie.

Die Neugestaltung der Datenbank, die ausschließlich auf dem Datenbankschema basiert, ist nicht vollständig. Sehen Sie sich Ihre Datenbank in ihrer Dynamik an, versuchen Sie, die Engpässe bei Auslastungstests zu finden und beheben Sie diese. Im Fall von MS SQL Server gibt es einen speziellen Optimierungsratgeber , der einige Empfehlungen für den aufgezeichneten Aktivitäts-Trace generieren kann.

Hier ist meine Antwort:

1. Verstehe zuerst das aktuelle Datenbanksystem so gut du kannst. Sie müssen alle Verwendungszwecke dieses Systems sowie die Benutzer kennen. Sie müssen alle Quellen des Systems sowie die Systeme kennen, auf denen es möglicherweise als Quellsystem fungiert.

2. Sie müssen alle unterschiedlichen Verwendungszwecke des Systems identifizieren, sei es für den Betrieb oder für die Berichterstellung oder für beides. Identifizieren Sie die Anwendungen und das Upstream-System, die möglicherweise die Datenbank verwenden. Auf diese Weise kennen Sie die Elemente der aktuellen Datenbank, die veraltet sind und nicht mehr benötigt werden.

3. Analysieren und verstehen Sie auch den aktuellen ETL-Prozess, der Daten in die Datenbank lädt und Daten aus der Datenbank extrahiert.

4. Verstehen Sie alle Datenelemente der Datenbank und erstellen Sie eine Box-Matrix, mit deren Hilfe Sie doppelte Elemente identifizieren können.

5. Nachdem Sie alle Informationen erhalten haben, können Sie sich dem Redesign so nähern, als würden Sie die Datenbank zum ersten Mal mit den Informationen entwerfen, die Sie im Rahmen Ihrer Anforderungserfassung gesammelt haben.

6. Viel Glück!