Bedeutung von ER-Diagrammen

Ich bin Student und entwickle im Rahmen meiner akademischen Laufbahn mehrere Projekte.

Bei der Entwicklung der Datenbank für eines der Projekte stießen wir auf eine Situation, in der wir darüber nachdachten, ob ERD notwendig ist oder nicht. Derzeit ist sich nicht jeder von uns einig, zuerst die ERD und dann die Datenbank daraus zu entwickeln.

Die Mehrheit der Menschen zieht es vor, die Datenbank im laufenden Betrieb mündlich gemäß den Systemanforderungen direkt auf Papier zu entwickeln.

Jetzt bin ich strikter Anhänger der Datenbankprinzipien. Ich denke, die Datenbank sollte nur aus dem ERD entwickelt werden. Ich möchte nur Folgendes wissen:

• Folgt die Branche diesen Grundsätzen?
• Verschwende ich nur meine Zeit mit der Entwicklung einer ERD?
• Was sind die Vorteile der Entwicklung einer ERD?

Stellen Sie sich die Entwicklung einer Datenbank ohne ERD ganz einfach als den Bau eines Hauses ohne Bauplan vor. Es könnte machbar sein, weil Sie denken, dass es ausreicht, nur einen Ziegelstein übereinander zu legen, um etwas zu bauen. In dem Moment, in dem jemand anderes die Verantwortung für das Projekt übernimmt, besteht jedoch Katastrophenpotential.

Nach meiner Erfahrung werden Sie von ERDs nur dann viel profitieren, wenn Sie sie in Verbindung mit CASE-Tools (ERWin, MySQL Workbench usw.) verwenden, mit denen Sie zusätzlich einige wirklich hilfreiche Vorgänge wie Forward- und Reverse Engineering ausführen können. Auch ohne diese Funktionen ist ein zentrales Schema der gesamten Datenbank nützlich, da manchmal die in der Datenbank selbst implementierten Einschränkungen nicht ausreichen, um die ganze Geschichte über die Beziehungen zwischen bestimmten Datenbankentitäten zu erzählen.

Hier ist ein Beispiel für MySQL, das, wie Sie vielleicht wissen, mehrere interne Speicher-Engines implementiert, insbesondere MyISAM und InnoDB. Es gibt signifikante Unterschiede zwischen ihnen. Einer der wichtigsten ist, dass MyISAM keine Einschränkungen unterstützt. Trotzdem wird MyISAM häufig für Webanwendungen verwendet, was bedeutet, dass die relationale Logik entweder über Geschäftslogik (Anwendungscode) oder auf andere Weise implementiert werden muss. Das Problem besteht darin, dass Sie beim Weiterleiten einer ERD mit MyISAM-Tabellen (Entitäten) MySQL die von der ERD festgelegten Einschränkungen stillschweigend ignorieren und eine Datenbank erhalten, in der die Art der Beziehungen zwischen Entitäten nicht eindeutig angegeben ist. Mit anderen Worten, nachdem Sie das Datenbanklayout entwickelt haben, können die Codeentwickler keine ordnungsgemäße Geschäftslogik ohne ERD implementieren.

ERDs sind wirklich schön, um ein klares Bild Ihrer Datenbankstruktur zu haben. Es ist nicht nur ein wichtiges Dokumentartefakt für Ihr Projekt, sondern erleichtert auch die Implementierung von Abfragen, insbesondere von Verknüpfungen zwischen Tabellen. Stellen Sie sich vor, wie schön es ist, eine Konfiguration mit zwei Monitoren zu haben. Auf der linken Seite haben Sie Ihre ERD und auf der rechten Seite Ihren Abfrageeditor. Sie können die Beziehungen zwischen Tabellen klar erkennen und Ihre Abfragen darauf basierend schreiben. Wenn Ihr Datenbankprojekt recht einfach ist und Ihr Projekt es nicht benötigt, ist es möglicherweise in Ordnung, ohne es zu leben.

ERD spart Ihnen viel mehr Zeit als Sie denken. Wenn Sie alles im laufenden Betrieb erledigen, bleiben Sie stecken, wenn Sie Junction-Tabellen erstellen möchten.

Wenn Sie einige Jahre später ohne ERD auf die Datenbank stoßen, müssen Sie viel Zeit aufwenden, um zu sehen, was in Ihrem Projekt vor sich geht.

Ich habe eine Firma und wir entwerfen ERD. Denken Sie niemals an eine Datenbank ohne ERD. (Eigentlich ist dies mein persönliches Experiment.)

ERDs waren vor einiger Zeit mehr Mainstream. IMO sind sie jetzt mehr oder weniger optional.

Derzeit beschäftigen sich einige sehr erfolgreiche Teams überhaupt nicht mit ERDs, liefern jedoch hervorragende Systeme: robust, leistungsfähig und auf lange Sicht einfach zu warten. Dies gilt insbesondere für die agile Entwicklung, wenn wir klein anfangen und minimalistische Tools verwenden.

ERDs sind natürlich eine gute Art der Kommunikation, aber keineswegs die einzige oder unter allen Umständen die beste. Einige Teams bevorzugen andere Dokumentations- und Kommunikationsmethoden.

In dieser Branche gibt es keine pauschalen Regeln.

Es ist wichtig, vor dem Schreiben des Produktionscodes zu entwerfen. Es ist auch wichtig, Prototypen zu erstellen. Datenbankmitarbeiter entwickeln Prototypen durch Schreiben von SQL. (Erinnerst du dich, was Fred Brooks über Prototypen gesagt hat?)

Grafische Sprachen, von denen ER nur eine ist, haben sich nicht als sehr gut erwiesen, um die gesamte Semantik einer Datenbank auf eine leicht und leicht verständliche Weise zu erfassen.

Sie haben sich auch nicht als sehr effektive Kommunikationsmittel erwiesen, außer zwischen Entwicklern. Beim Entwerfen von Datenbanken besteht die entscheidende Kommunikation jedoch nicht zwischen Entwicklern. Es ist zwischen Entwicklern und Domain-Experten (zwischen Entwicklern und Geschäftsleuten).

Object-Role Modeling (ORM) hat eine grafische Sprache, basiert jedoch auf "Fakten" (einfachen Sätzen). Geschäftsleute können Fakten ziemlich einfach validieren. Geschäftsleute können ein ER-Diagramm oder ein ORM-Diagramm nicht einfach validieren.