Ich habe gerade meinen ersten Online-Datenbankkurs begonnen und habe eine Hausaufgabe, um aus einer Liste von Spezifikationen ein Entity-Relationship-Diagramm (ERD) zu erstellen.

Die Spezifikationen sind wie folgt:

1. Das Unternehmen ist in Abteilungen organisiert. Jede Abteilung hat einen Namen, eine eindeutige Nummer und einen bestimmten Mitarbeiter, der die Abteilung verwaltet. Wir verfolgen den Starttermin, an dem der Mitarbeiter mit der Leitung der Abteilung begonnen hat. Eine Abteilung kann mehrere Standorte haben.

2. Eine Abteilung steuert eine Reihe von Projekten, von denen jedes einen Namen, eine eindeutige Nummer und einen einzelnen Standort hat.

3. Wir speichern den Namen, die SSN, die Adresse, das Gehalt, das Geschlecht und das Geburtsdatum jedes Mitarbeiters. Ein Mitarbeiter ist einer Abteilung zugeordnet, kann jedoch an mehreren Projekten arbeiten, die nicht unbedingt von derselben Abteilung gesteuert werden müssen. Wir verfolgen die Anzahl der Stunden pro Woche, die ein Mitarbeiter für jedes Projekt arbeitet. Wir verfolgen auch den direkten Vorgesetzten jedes Mitarbeiters.

4. Wir möchten die Angehörigen jedes Mitarbeiters zu Versicherungszwecken im Auge behalten. Wir behalten den Vornamen, das Geburtsdatum und die Beziehung des abhängigen Mitarbeiters zum Mitarbeiter bei.

Für Ihre erste Datenbankklasse und Ihren ersten Versuch eines ER-Diagramms (ERD) haben Sie meiner Meinung nach großartige Arbeit geleistet! Ich möchte Ihnen im Zusammenhang mit dem Prozess, den ich verwende, um eine Reihe von Anforderungen, wie Sie sie erhalten haben, aufzuschlüsseln und einen Diagrammentwurf zu erstellen, ein Feedback geben. Mit diesem Ansatz helfe ich Ihnen hoffentlich bei der Entwicklung der Fähigkeiten der ER-Modellierung und des Datenbankdesigns und gebe Ihnen nicht nur eine Antwort auf eine Hausaufgabe.

Finden Sie die Entitäten und Beziehungen

Die Idee hinter einer ERD ist es, die Entitäten zu identifizieren - Dinge , die für das Unternehmen von grundlegender Bedeutung sind - und wie sie zusammenhängen . Daher der Name Entity-Relationship Diagram. Ziel ist es an dieser Stelle nicht , eine Datenbank zu entwerfen oder zu implementieren, sondern ein strukturierteres Verständnis des interessierenden Bereichs zu entwickeln, auf dem eine Datenbank letztendlich basieren wird. Ein guter Weg, um mit dem Finden der Entitäten zu beginnen, besteht darin, nach den Substantiven in den Anforderungen zu suchen und dann diejenigen auszuwählen, die Personen, Orte, Dinge, Konzepte oder Ereignisse sind. Dann können Sie die meisten Beziehungen finden, indem Sie nach den Verben suchen, die diese Substantive verbinden. Hier ist mein erster Versuch, Entitäten und Beziehungen in den bereitgestellten Anforderungen zu finden:

Ich habe die Substantive in einem hellen Grün und die Verben in einem hellen Rosa hervorgehoben. Beachten Sie nun, dass es ein Substantiv gibt - Supervisor - das dunkler grün hervorgehoben ist. Wir werden das vorerst ignorieren. Wenn wir vergleichen, was ich gefunden habe, mit dem, was Sie auf Ihrer ERD platziert haben, sind wir auf derselben Seite! Der einzige Unterschied ist, dass ich auch den Ort hervorgehoben habe . Ich kann sehen, warum dies von Ihrer ERD weggelassen wurde, da es nicht eindeutig eine Einheit ist. Sie können es sich genauso gut als ein Attribut vorstellen - eine gemeinsame Eigenschaft oder Eigenschaft, die alle Entitäten in einem Entitätstyp gemeinsam nutzen - der Abteilung und des Projekts, und so haben Sie es modelliert. Der Grund, warum ich es zu einem Entitätstyp erhoben habe, ist folgender:

Eine Abteilung kann mehrere Standorte haben

Dies weist darauf hin, dass jede Abteilung einem oder mehreren Standorten zugeordnet ist und daher auf ihren eigenen Entitätstyp aufgeteilt werden muss. Ein zweiter Grund, es zu erhöhen, ist, dass wir uns einen Ort als einen Ort vorstellen können und als solcher seine eigenen Attribute wie Name, Adresse, Stadt, Bundesland, Postleitzahl usw. haben würden. Ein dritter Grund für die Erhöhung ist, dass der Standort von mehr als einem Entitätstyp referenziert wird - der Abteilung und dem Projekt. Wenn Sie feststellen, dass das betreffende Element von mehr als einer bereits identifizierten Entität referenziert wird, sollten Sie es als eigenständige Entität betrachten, die sich auf die anderen bezieht , und nicht einfach als Attributder anderen. Es gibt jedoch keine Wissenschaft dazu - es ist nur ein Urteilsspruch. Aus diesem Grund befindet sich das ER-Diagramm auf konzeptioneller Ebene als subjektiv für individuelle Perspektiven. Die Entität einer Person ist das Attribut einer anderen Person, abhängig von ihrer Perspektive auf den interessierenden Bereich.

In Bezug auf die Beziehungen ist hier eine Liste dessen, was ich in Pink hervorgehoben habe:

1. Mitarbeiter leitet Abteilung
2. Abteilung steuert Projekt
3. Mitarbeiter der Abteilung zugeordnet
4. Mitarbeiter arbeitet am Projekt
5. Mitarbeiter hat Abhängige

Von diesen haben Sie alle bis auf den ersten identifiziert. Dies führt zusammen mit dem bereits erwähnten Supervisor zu einer Diskussion der Rollen, die wir später verschieben werden. Im Moment versuchen wir nur, die Grundlagen zu identifizieren, und ich würde sagen, Sie hatten Recht.

Assoziative Einheiten

Wenn wir uns die Beziehungen ansehen, haben wir einige, die viele zu viele sind. Die Anforderungen besagen, dass ein Mitarbeiter an vielen Projekten arbeiten kann, die nicht unbedingt von derselben Abteilung gesteuert werden. Angesichts der Tatsache, dass die meisten Projekte mehr als ein Mitglied haben, können wir davon ausgehen, dass dies eine Beziehung von vielen zu vielen ist. Wenn Sie eine solche Beziehung in einer ERD haben, ist es durchaus akzeptabel, viele zu viele Beziehungslinien anzuzeigen. Normalerweise verwende ich die Viele-zu-Viele-Beziehung jedoch nur, wenn ich überhaupt keine Attribute zeige. Da wir sie hier zeigen, ziehe ich es vor, die vielen zu vielen Beziehungen zu einer assoziativen Einheit aufzulösen . Selbst wenn es jetzt keine Attribute für die Entität gibt, können wir im Verlauf der Analyse einige aufdecken. Bei Mitarbeitern und Projekten haben wir jedoch Attribute- die geleisteten Arbeitsstunden - die für diese Beziehung hinzugefügt werden müssen, und daher muss sie gelöst werden, indem die assoziative Entität erstellt wird, um sie anzuzeigen. Daher erstellen wir eine assoziierte Entität namens Projektzuweisung . Aber wir sind immer noch nicht fertig. Die Anforderung erfordert, dass wir die pro Woche geleisteten Arbeitsstunden kennen . Wenn Sie darüber nachdenken, stellen Sie fest, dass das Projekt viele Wochen dauern würde, und wir müssen jede Woche die Arbeitsstunden dieses Mitarbeiters für dieses Projekt aufzeichnen . Daher ist ein anderer Entitätstyp erforderlich, den ich Arbeitsstunden genannt habe, von denen es pro Projektzuweisung viele Vorkommen geben wird. Dieser Entitätstyp enthält das Wochenenddatum und die geleisteten Arbeitsstunden.

Wenn Sie einen Standortentitätstyp erstellen, bedeutet die Anforderung, dass eine Abteilung mehrere Standorte haben kann, dass wir jetzt eine Beziehung haben, in der eine Abteilung viele Standorte haben kann. Es ist auch davon auszugehen, dass an einem Standort viele Abteilungen tätig sein werden. Daher habe ich eine weitere assoziative Entität namens Operating Site hinzugefügt , um dies zu zeigen.

Finden Sie die Attribute

Die Attribute wurden in den Anforderungen mit Aussagen wie: ziemlich klar aufgelistet.

1. Jede Abteilung hat einen Namen, eine eindeutige Nummer,
2. Verfolgen Sie das Startdatum, an dem der Mitarbeiter mit der Verwaltung der Abteilung begonnen hat
3. Projekte, von denen jedes einen Namen, eine eindeutige Nummer hat,
4. Speichern Sie den Namen, die SSN, die Adresse, das Gehalt, das Geschlecht und das Geburtsdatum jedes Mitarbeiters.
5. Verfolgen Sie die Anzahl der Stunden pro Woche, die ein Mitarbeiter für jedes Projekt arbeitet.
6. Behalten Sie den Vornamen, das Geburtsdatum und die Beziehung des abhängigen Mitarbeiters zum Mitarbeiter bei.

An dieser Stelle liste ich die identifizierten Entitäten und Beziehungen auf und platziere die Attribute, die mit dem Entitätstyp identifiziert wurden, zu dem sie gehören:

1. Abteilung - Nummer, Name
2. Mitarbeiter - Name, SSN, Adresse, Gehalt, Geschlecht, Geburtsdatum
3. Lage - ???
4. Projektnummer , Name
5. Abhängig - Vorname, Geschlecht, Geburtsdatum, Beziehung

Hinweis Ich kann keine Attribute für den Standort finden. Dies wäre eine rote Fahne, um zum Geschäft zurückzukehren und zusätzliche Informationen über Standorte zu erhalten!

Listen Sie dann die Beziehungen und ihre Attribute auf:

1. Mitarbeiter verwaltet Abteilung - Startdatum
2. Abteilung steuert Project -
3. Mitarbeiter der Abteilung zugeordnet -
4. Mitarbeiter arbeitet am Projekt - Stunden pro Woche
5. Mitarbeiter hat abhängig -
6. Abteilung hat Standort -

Für die letzten beiden Beziehungen das Verb hat ist nicht sehr aussagekräftig, aber das war , wie die Anforderungen formuliert wurden. Die Entität hat ein Attribut. Warum sollten dies also keine Attribute sein? Ich habe vorhin besprochen, warum ich den Standort als Entitätstyp festlegen möchte. Für Abhängige ist die Wahl klarer, da jeder Mitarbeiter viele Abhängige hat und daher in eine eigene Einheit aufgeteilt werden muss. Sobald dies erledigt ist, könnten wir den Sprung machen, um das Verb zu verbessern. Vielleicht kümmert sich so etwas wie ein Mitarbeiter um Abhängige und die Abteilung arbeitet vor Ort.

Jetzt sind wir in der Lage, das Diagramm zu erstellen. Folgendes habe ich:

Dies wurde mit Oracle SQL Developer Data Modeler erstellt - einem kostenlosen Download - ein großartiges Tool, wenn Sie den Prozess für das Entwerfen und Erstellen von Datenbanken fortsetzen möchten.

Primärschlüssel

Sie haben Primärschlüssel identifiziert. Technisch gesehen erfordert eine ERD nicht einmal, dass Sie Schlüssel berücksichtigen. Wenn Sie sich die ERD als ein Werkzeug zur Modellierung des Geschäfts vorstellen, ist es nicht wichtig, an dieser Stelle genau zu bestimmen, wie Sie ein Vorkommen jeder Entität eindeutig identifizieren. Stattdessen können Sie , dass Sie zu einem späteren Zeitpunkt übernehmen wird dies herausfinden , und konzentrieren sich stattdessen nur auf den Entitäten, ihre Beziehungen und ihre Attribute. Es ist eine gute Idee, Notiz , die Attribute sindDies ist für jede Entität eindeutig, da dies bei der Auswahl der Schlüssel hilfreich ist. Sobald Sie das Diagramm fertiggestellt und mit dem Unternehmen wiederholt haben, können Sie es durch Auswahl der richtigen Schlüssel noch einmal vervollständigen. In meinem Diagramm habe ich nur festgestellt, dass die beiden in den Anforderungen als eindeutig genannten Zahlen im Diagramm eindeutig sind, wobei ein U neben dem Attributnamen verwendet wird.

Entitätsrollen

Um nun den dunkelgrün hervorgehobenen Supervisor anzusprechen, den ich zuvor erwähnt habe. In den Anforderungen heißt es: "Eine Abteilung hat einen Mitarbeiter, der die Abteilung leitet." Sie fahren fort: "Wir verfolgen auch den direkten Vorgesetzten jedes Mitarbeiters." Was wir hier haben, ist eine Entität - eine Person - die verschiedene Rollen spielt. Der Mitarbeiter kann ein Manager sein . Der Mitarbeiter kann ein Vorgesetzter sein . Wie lösen wir das? Zuerst müssen wir entscheiden, ob der Manager und der Vorgesetzte dasselbe sind! Ist es der Fall , dass der Manager einer Abteilung ist auch der Supervisor der ihm zugeordneten Mitarbeiter? Wenn ja, ist die Lösung einfach. Ein neuer Entitätstyp namensDer zugewiesene Manager kann mit einer Eins-zu-Viele-Beziehung von Abteilung zu Mitarbeiter und von Mitarbeiter zu Mitarbeiter erstellt werden, mit einem einzigen Attribut des Startdatums, an dem dieser Mitarbeiter mit der Verwaltung dieser Abteilung begonnen hat. Anschließend wird der Vorgesetzte jedes Mitarbeiters an den Leiter der Abteilung übergeben, der er zugeordnet ist. Wenn nein, können wir eine rekursive Beziehung von Mitarbeiter zu Mitarbeiter hinzufügen, um den Vorgesetzten und den Mitarbeiter darzustellen. Dies ist der einfachste Ansatz, führt jedoch zu einer Vermischung von Rollen im selben Entitätstyp. Ein besserer Ansatz besteht darin, einen neuen Entitätstyp mit dem Namen Assigned Supervisor hinzuzufügenmit zwei Eins-zu-Viele-Beziehungen vom Mitarbeiter zum Mitarbeiter - eine zur Vertretung des Vorgesetzten und die andere zur Vertretung des Vorgesetzten. Wenn es ein Datum gibt, an dem die Aufgabe begann und endete, kann dies ebenfalls hinzugefügt werden.

Fazit

Hoffentlich ist dies zusammen mit der Beschreibung des Prozesses, mit dem er entwickelt wurde, ein gutes Lernwerkzeug, um zu verstehen, wie Sie von einer Beschreibung eines Geschäftsprozesses zu einem Entwurf einer ERD gelangen. Ich sage Entwurf, weil es nur ein Ausgangspunkt ist. Nach Abschluss dient es als Kommunikationsmittel, um die Anforderungen zu validieren, Lücken zu finden, neue aufzudecken usw., bevor mit der Programmierung oder sogar dem Systemdesign begonnen wird. Denken Sie daran, dass es ein Fehler ist, ein System zu erstellen, das falsch verstandene Anforderungen implementiert, und dass es viel billiger ist, eine ERD zu modifizieren als ein funktionierendes System!

Verweise

Zwei wirklich gute Referenzen für ER-Diagramme sind Steve Hobermans Data Modeling Made Simple , das einen guten Überblick bietet, und David Hays Enterprise Model Patterns , die einen umfassenden Einblick in gängige Muster geben, die Sie bei der Analyse von Organisationen finden. Beide Referenzen enthalten viel detailliertere Informationen zur Beschreibung von Beziehungen mithilfe von Verb- und Präpositionalsätzen, zur Identifizierung und Nichtidentifizierung von Beziehungen sowie zu starken und schwachen Entitäten - Konzepte, die ich nicht angesprochen habe. Fabian Pascals Reihe " Practical Database Foundation"ist auch exzellent und hat ein großartiges erstes Papier, das die Bücher perfekt ergänzt, da Fabian den gesamten Prozess der Ermittlung der Datenanforderungen beschreibt. Denken Sie daran, dass ER-Diagramme nur Schlüssel und Referenzen anzeigen können, während es in der Tat viel mehr Arten von Geschäftsregeln gibt, die in der ultimativen Datenbank untersucht und implementiert werden können.

Im Geiste des Lernens, da dies Hausaufgaben sind, werde ich Ihnen ein Feedback geben, ohne Ihnen die Diagramme zu geben. Ich werde auch einige SqlServer-spezifische Begriffe verwenden, aber Sie sollten in der Lage sein, mit minimalem Aufwand herauszufinden, was ich sage.

Eine Sache, die mir sofort aufgefallen ist, ist Ihre Verwendung der SSN als PK. Ich weiß, dass dies eine großartige Idee zu sein scheint, da es sich theoretisch um eine einzigartige, persönlich identifizierbare Information handelt. Leider gibt es schlechte Menschen auf der Welt, die die Daten in Ihrer Datenbank missbrauchen, wenn Sie dies zulassen. Daher möchten wir wertvolle Informationen nicht als einfachen Text speichern. Sie müssen also mitteilen, dass die SSN verschlüsselt ist. Eine andere Sache ist, dass Sie häufig PKs als FK in einer anderen Tabelle verwenden. Wir möchten uns nicht über vertrauliche Daten in unseren Tabellen verteilen, auch wenn die Daten verschlüsselt sind.

Dies führt zu meinem nächsten allgemeinen Rat. Ich würde ein IDENTITYoder GUIDals PK für Ihre Employee/ DependantTabellen verwenden. Sie können hier und hier eine Diskussion über die Kompromisse sehen . Ich persönlich tendiere dazu, IDENTITYKolumnen zu bevorzugen , aber es gibt viele Leute, die dem aus vielen guten Gründen nicht zustimmen würden.

Es sieht auch so aus, als hätten Sie die Stunden pro Woche und Projekt nicht berücksichtigt. Wie es steht und Employeehat Employee Weekly Hours. Sie müssen stattdessen Stunden pro Projekt haben.

Schließlich ist ein Spaltenname von WeeklyHoursoder weekly_hoursfür alle viel schöner als Weekly Hours, da für den Speicherplatz das Entkommen der Namen erforderlich ist, um keine echte Lesbarkeit zu erzielen. Es ist auch nicht erforderlich, den Tabellennamen dem Spaltennamen voranzustellen, dh EmployeeSalaryschlecht, Salarygut. In ähnlicher Weise DependentSexist es schlimmer als IsMalewenn Sie nicht eine umfassendere Option für Geschlecht / Geschlecht wünschen. In diesem Fall benötigen Sie eine Tabelle mit den Optionen.

Für einen Start benötigen Sie eine abhängige ID als Primärschlüssel in Ihrer abhängigen Tabelle (Identität / Autonummer).

Wenn ein Mitarbeiter an mehreren Projekten arbeitet, benötigen Sie eine Nachschlagetabelle für Mitarbeiter und Projekt. Sie sollten den Mitarbeiter nicht direkt mit dem Projekt verknüpfen.

Wie bei Project benötigen Sie für mehrere Abteilungen eine separate Tabelle, um die Suche zwischen Standorten und Abteilungen aufrechtzuerhalten.

Sie benötigen eine Arbeitszeittabelle, um die Arbeitszeiten eines Mitarbeiters zu speichern. Dazu gehört auch der Fremdschlüssel für Projekte. (Sie können die nächste Stufe erreichen, indem Sie die Start- und Endzeit der Arbeit eingeben und ein berechnetes Feld verwenden, um die Stunden zu berechnen.