Bedeutung von ER-Diagrammen


10

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?

Das ER / EER-Diagramm zeigt die Wechselbeziehungen zwischen Entitäten und vergrößert auch Systemfunktionalisten.

Wenn Sie ein kostenloses Tool zum Erstellen einer ERD für SQL Server wünschen ... Informationen finden Sie hier ... facebook.com/DataModelerTool oder hier ... plus.google.com/108968161662966473138
Carter Medlin

Meiner Meinung nach erfassen ERDs nicht alles Wichtige - Änderungen der Beziehung im Laufe der Zeit, des Transaktionsvolumens, der Vererbung in objektmodellierten Systemen, werden zu einer Beziehung usw. Insbesondere berücksichtigt ERD alle Verben und hinterlässt große Lücken im Datenbankdesign. Stellen Sie sich vor, Sie lesen einen Roman, der nur aus Substantiven besteht. Ich finde, dass sie nützliche Werkzeuge sind, aber sicherlich nicht kritisch, am besten nach einem schönen Mittagessen auf den Rücken von Servietten gemalt.
Pojo-Typ

Antworten:


13

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.


1
Wenn wir mit Ihrem "Bauplan" -Vergleich den ganzen Weg gehen, müssen wir ein System bauen und können es niemals ändern, es sei denn, wir müssen das Ganze abreißen. Dies wird in einer dynamischen Umgebung nicht funktionieren.
AK

1
Der Zweck des "Bauplans" besteht nicht darin, den Entwicklungsprozess oder das Projekt selbst zu zementieren, sondern immer einen Überblick über den Zustand des aktuellen Projekts zu geben. Niemand hindert tatsächlich jemanden daran, neue Entitäten oder Beziehungen hinzuzufügen (wodurch Änderungen am Plan vorgenommen werden), aber andere müssen auch über diese Änderungen Bescheid wissen.
Brezanac

5

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.


4

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.)


4

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.


+1 aber welche anderen Möglichkeiten der Dokumentation und Kommunikation werden in Bezug auf Datenbanken verwendet?
Wunder173

@ miracle173 Ein gutes Buch ist: "Agile Prinzipien, Muster und Praktiken in C #". Ich mag auch Artikel über verhaltensgesteuerte Entwicklung von Dan North auf dannorth.net
AK

1
Was meinst du damit some teams prefer other ways? Ich denke, dies hätte zu vielen Abstimmungen führen können, wenn dies als Antwort auf Stackoverflow veröffentlicht wurde!
Pmpr

2

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.


1
+1 Aber kennen Sie Zahlen oder Studien, die Ihre Behauptungen über die Probleme der Kommunikation mit grafischen Sprachen stützen?
Wunder173

Ich bin kein Akademiker, daher verfolge ich die Forschung nicht genau. Eine grafische Sprache, die nicht die gesamte Semantik einer Datenbank erfasst (z. B. eine ERD), kann offensichtlich nicht die gesamte Semantik kommunizieren. Das ist Teil von Terry Halpins Forschung. Für die Kommunikation mit Domain-Experten benötigen Sie dafür keine Recherche. Sie müssen nur versuchen, einem Domain-Experten, der nur eine 8. Klasse hat, ein ER-Diagramm zu erklären. Vergleichen Sie diese Erfahrung mit dem Versuch, den Satz "Jede Adresse hat nur eine Postleitzahl" zu erklären. Der Satz gewinnt jedes Mal.
Mike Sherrill 'Cat Recall'
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.