Lernen Sie das ER-Diagramm (Entity Relationship), seine Teile und was bei seiner Erstellung oft schief geht, kennen.
Haben Sie jemals ein relationales Datenbankmodell erstellt? Oder vielleicht versuchen Sie, Ihre erste zu erstellen? Sie wissen (oder werden es bald herausfinden), dass es manchmal ziemlich schwierig sein kann, reale Probleme in Datenbanklogik zu übersetzen.
Eines der Werkzeuge, das Ihnen helfen könnte, ist das ER-Diagramm. Die allgemeine Weisheit beim Datenbankdesign besagt, dass es umso einfacher ist, das Datenbankmodell zu erstellen, je besser Ihr ER-Diagramm ist. Dieser wichtige Punkt gibt den Ton für alle zukünftigen Frustrationen oder Erfolge an. Mit einem guten ER-Diagramm ist das Erstellen eines relationalen Datenbankmodells recht einfach. Natürlich können in jeder Phase der Datenbankmodellierung Fehler gemacht werden. Ein gutes ER-Diagramm kann Ihnen jedoch dabei helfen, einige dieser Fehler zu vermeiden.
Sehen wir uns also an, was das ER-Diagramm ist und wie wir seine häufigen Fehler vermeiden können.
Was ist ein ER-Diagramm?
„ER-Diagramm“ oder ERD ist die Abkürzung für Entity Relationship Diagram. Es bildet das zu modellierende Problem ab, jedoch in einer strukturierten Weise, die die Beziehungen zwischen Entitäten zeigt.
Die Bausteine eines ER-Diagramms
ER-Diagramme bestehen aus den folgenden Elementen:
- Einheit
- Beziehungen
- Entitäts- oder Beziehungsattribute
Das erste Element des ER-Diagramms ist die Entität . Die Entität ist ein Objekt oder Vorkommen, über das wir Informationen speichern möchten. Grundsätzlich ist es alles, worüber wir Daten sammeln können. Beispielsweise speichern wir möglicherweise Daten zu Mitarbeitern, Schülern, Lehrern, Käufern, Produkten, Abteilungen, Zahlungen, Standorten usw.
Sobald wir Entitäten haben, ist es notwendig, Beziehungen zu erstellen . Eine Beziehung zeigt, wie eine Entität mit einer oder mehreren anderen Entitäten verbunden und assoziiert ist.
Das letzte Element des ER-Diagramms ist ein Entitäts- oder Beziehungs-Attribut . Ein Attribut ist eine Beschreibung einer Eigenschaft, die zu einer Entität oder Beziehung gehört. Attribute haben Werte. Einige Attribute für die oben erwähnten Entitäten könnten sein:
- Mitarbeiter, Schüler, Lehrer, Käufer – ID, Name, Nachname, Geburtsdatum, Adresse usw.
- Produkt – ID, Kategorie, Beschreibung, Farbe, Seriennummer usw.
- Abteilung – ID, Abteilungsname, Abteilungsleiter, Anzahl der Mitarbeiter usw.
- Zahlungen – ID, Datum und Uhrzeit, Betrag.
- Standort – Ort, Postleitzahl, Region, Land, Kontinent.
Arten von Beziehungen
Bevor wir auf die üblichen Fehler in ER-Diagrammen eingehen, ist es wichtig, die möglichen Beziehungstypen zu verstehen. Die meisten ERD-Fehler sind im Wesentlichen falsch definierte Beziehungen zwischen Entitäten.
Es gibt drei Arten von Beziehungen zwischen Entitäten:
- Eins-zu-eins (1:1)
- Eins-zu-viele (1:N)
- Many-to-Many (M:N)
Eins-zu-eins-Beziehungen (1:1)
Der erste Beziehungstyp ist Eins-zu-Eins , oder 1:1 . In dieser Beziehung kann eine einzelne Instanz einer Entität nur mit einer einzelnen Instanz einer anderen Entität verbunden werden (und natürlich umgekehrt).
Nehmen wir an, wir haben die Entität Student mit den Attributen Name und Nachname . Wir haben auch die Entität id mit dem einzigen Attribut id . Die 1:1-Beziehung würde bedeuten, dass ein Student nur eine ID-Nummer haben kann. Das bedeutet auch, dass eine ID-Nummer nur einem Studenten gehören kann.
Diese Beziehung wird in Datenbanken sehr selten gesehen. Wenn nur eine ID mit nur einem Schüler verknüpft werden kann, besteht keine Notwendigkeit, sie in zwei verschiedene Entitäten zu trennen.
Hier ist ein Beispiel für diese Beziehung:
Eins-zu-viele (1:N)-Beziehungen
Die häufigste Art von Datenbankbeziehung ist Eins-zu-Viele oder 1:N . Eine 1:n-Beziehung bedeutet, dass jede einzelne Instanz einer Entität mit mehreren Instanzen einer anderen Entität verbunden werden kann. Das bedeutet auch, dass jede Instanz der zweiten Entität nur einer Instanz der ersten Entität zugeordnet werden kann.
Beispielsweise gibt es eine Entität Käufer mit den Attributen id , Name , und Nachname . Wir möchten eine Beziehung mit der Entität Zahlung herstellen die die Attribute id hat , Datum und Wert . Dies ist eine 1:N-Beziehung, da ein Käufer eine oder mehrere Zahlungen leisten kann. Eine Zahlung kann jedoch nicht von mehreren Käufern geleistet werden; es kann nur von einem Käufer gemacht werden.
Hier ist das Beispiel:
Dieser Zusammenhang kann auch umgekehrt gesehen werden. In diesem Fall spricht man von viele-zu-eins oder N:1 . Natürlich ist dies keine neue Art von Beziehung. Es ist dasselbe wie 1:N, aber es wird aus der entgegengesetzten Richtung betrachtet.
Angenommen, wir haben die Entität Mitarbeiter mit den Attributen id , Name , und Nachname . Wir wollen Mitarbeiter gründen die Beziehung von mit der Entität Abteilung die die Attribute id hat und Name . Die Beziehung zwischen diesen beiden Entitäten ist N:1. Das bedeutet, dass jeder Mitarbeiter nur in einer Abteilung arbeiten kann, aber mehrere Mitarbeiter in derselben Abteilung arbeiten können.
Many-to-Many (M:N)-Beziehungen
Ein viele-zu-viele oder M:N Beziehung bedeutet, dass jede Instanz der ersten Entität mehr als einer Instanz der zweiten Entität zugeordnet werden kann. Das bedeutet auch, dass jede Instanz der zweiten Entität mehreren Instanzen der ersten Entität zugeordnet werden kann.
Mal sehen, wie das zwischen den Entitäten Student funktioniert und Vortrag . Sagen wir dieser Schüler hat die Attribute id , Name , und Nachname . Die Entität Vortrag hat die Attribute id und Name . Eine Viele-zu-Viele-Beziehung kann folgendermaßen interpretiert werden:Ein Student kann eine oder mehrere Vorlesungen besuchen, während eine Vorlesung von einem oder mehreren Studenten besucht werden kann.
Hier ist das Diagramm für dieses Beispiel:
In der Datenbankmodellierung werden solche Beziehungen normalerweise in zwei oder mehr 1:N- oder N:1-Beziehungen aufgeteilt, indem neue Entitäten eingeführt werden.
Typische Fehler beim Erstellen eines ER-Diagramms
Viele ER-Diagrammfehler passen in eine dieser vier Kategorien:
- Falsche Beziehungen zwischen Entitäten
- Eine Entitätsinstanz anstelle einer Entität verwenden
- Verwechslung eines Attributs mit einer Entität
- Komplexe Attribute
Sehen wir uns jeden einzeln an.
Falsche Beziehungen zwischen Entitäten
Die häufigsten Fehler treten beim Definieren der Beziehung zwischen Entitäten auf . In einer 1:1-Beziehung gibt es normalerweise keine Fehler. Es ist jedoch sehr leicht, eine 1:N-Beziehung mit einer M:N-Beziehung zu verwechseln. Dies liegt normalerweise daran, dass die vom Endbenutzer bereitgestellten Anforderungen nicht verstanden werden. Es ist wichtig, sehr klar definierte Anforderungen und ein tiefes Verständnis dafür zu haben, warum die Datenbank benötigt wird und wie sie verwendet wird. Wenn wir ein ER-Diagramm mit unzureichenden Daten und unvollständigem Verständnis erstellen, führt dies höchstwahrscheinlich dazu, dass Beziehungen zwischen Entitäten falsch definiert werden.
Schauen wir uns ein Beispiel an. Wenn Sie eine Datenbank für eine Bank erstellen, erstellen Sie höchstwahrscheinlich ein ER-Diagramm mit der Entität Kunde mit den Attributen id , Name , und Nachname . Sie haben auch eine Entität namens Konto mit den Attributen id und tippen . Wenn Ihnen die Erfahrung in der Bankenbranche fehlt, werden Sie wahrscheinlich denken, dass zwischen dem Kunden immer eine 1:N-Beziehung besteht und Konto Entitäten, wie unten gezeigt.
Ein Kunde kann mehrere Konten bei einer Bank haben. Ein Konto kann jedoch nur einem Kunden gehören. Ist das wirklich wahr? Vielleicht ist es, vielleicht ist es nicht. Viele Banken bieten Gemeinschaftskonten an, die von mehreren Kunden genutzt werden können. Erstellen Sie ein ER-Diagramm für eine Bank, die einen solchen Service anbietet? Wenn die Bank keine Gemeinschaftskonten anbietet, dann haben Sie recht:die Beziehung Kunde und Konto ist 1:N. Wenn die Bank jedoch Gemeinschaftskonten anbietet, dann ist das Verhältnis M:N.
Eine Entitätsinstanz anstelle einer Entität verwenden
Ein weiterer häufiger Fehler ist die Verwendung einer Entitätsinstanz anstelle einer Entität. Eine Entitätsinstanz ist ein einzelnes Vorkommen einer bestimmten Entität – d. h. eine Entität, die tatsächlich ein Attribut einer größeren Kategorie sein könnte.
Nehmen wir an, wir arbeiten in einem Unternehmen, das bestimmten Mitarbeitern Mobiltelefone und Laptops zuweist. In unserer Datenbank hätten wir also eine Entität namens Laptop mit den Attributen id und Modell und eine Entität namens employee mit den Attributen id , Name , und Nachname , Rechts?
Hier gibt es ein Problem:Ein Laptop ist eigentlich keine Entität – es müssen auch Mobiltelefone berücksichtigt werden. Die Lösung besteht darin, die Entität Laptop zu ersetzen mit einer allgemeineren Entität wie equipment . Diese Entität könnte die Attribute ID haben , tippen und Modell , Wie nachfolgend dargestellt. Der Typ könnte aus Werten wie Telefon bestehen , PC , Tablet und Laptop . Auf diese Weise muss nicht für jeden Gerätetyp eine separate Entität erstellt werden.
Das Beispiel finden Sie hier:
Verwechslung eines Attributs mit einer Entität
Der nächste häufige Fehler besteht darin, ein Attribut mit einer Entität zu verwechseln. Angenommen, wir haben uns entschieden, eine Entität namens employee zu erstellen das wird aus den Attributen id bestehen , Name , Nachname , Geburtsdatum , id_department , name_department , und head_department . Diese Entität wird uns Probleme bereiten, wenn wir ein Datenbankmodell erstellen, da sie aus zu vielen Attributen besteht, die diese bestimmte Entität nicht eindeutig definieren .
Denken Sie daran, dass wir Entitäten als alles definiert haben, worüber wir Daten sammeln können. In Anbetracht dessen können wir sehen, dass der aktuelle Mitarbeiter Entität kann in zwei Entitäten aufgeteilt werden:Mitarbeiter und Abteilung , Wie nachfolgend dargestellt.
Komplexe Attribute
Der letzte häufige Fehler, über den wir sprechen werden, ist das Einfügen eines komplexen Attributs in eine Entität. Mit anderen Worten, wir haben ein Attribut, das eigentlich eine eigene Entität sein sollte .
Nehmen wir an, wir haben eine Entität namens Studenten das wird durch die folgenden Attribute definiert:id , Name , Nachname , Geburtsdatum , Adresse und exam_bestanden . Hier, exam_bestanden ist ein komplexes Attribut, das aus mehr als einer Information besteht, d. h. der Prüfungs-ID und dem Datum sowie der Punktzahl des Schülers. Es so zu lassen, wäre ein Fehler. Stattdessen sollten wir eine neue Entität erstellen aus diesem komplexen Attribut . Die neue Entität könnte exams heißen und bestehen aus den folgenden Attributen:id , Datum , Studenten_ID , und Ergebnis .
Das Beispiel finden Sie hier:
Haben Sie nützliche Tipps für ER-Diagramme erhalten?
Diese vier Arten von Fehlern sind die häufigsten im Erstellungsprozess von ER-Diagrammen. Natürlich gibt es keine vollständige Liste typischer Fehler oder Fehlerarten. Im wirklichen Leben passieren wahrscheinlich viele Arten von Fehlern. Mangelnde Planung, unzureichender technischer Support und ein überstürzter Datenbankdesignprozess tragen alle ihre eigenen Probleme bei. Wenn Sie jemals Datenbanken erstellt oder von der Geschäftsseite aus daran teilgenommen haben, haben Sie wahrscheinlich einige davon erlebt! All diese Umstände führen zu verschiedenen Fehlern, von denen einige ziemlich einzigartig sind.
Haben Sie ein eigenes Beispiel für ein nicht so gutes ER-Diagramm? Oder gibt es vielleicht noch andere Fehler, die Sie häufig finden? Bitte lassen Sie es mich im Kommentarbereich wissen.
