ER-Diagramm - bitte Feedback geben

[Stefffano]

Hallo,
ich habe für unseren Verein ein ER-Diagramm entworfen, bin aber absoluter Anfänger
(mache seit einer Woche einen Access-Lehrgang) Bin mir besonders unsicher ob die
Beziehungen unter einander richtig sind, z.B. die N:M-Beziehung zwischen Kunden
und Einzelkurs, welche Beziehung zwischen Kunden und Mitarbeitern besteht, bzw. ob ich die Mitarbeitertabelle einfach weglassen kann. Ist die Nutzung der Primär- und Fremdschlüssel korrekt? Welche und wie viele Attribute sollte die Kundentabelle enthalten, oder macht es Sinn, diese Tabelle in weitere Tabellen zu splitten. Würde mich daher sehr freuen, wenn jemand mal einen Blick drauf werfen würde und mir ein Feedback zukommen ließe.
Ansonsten allen ein schönes WE, Stefan

 

[Nico Graichen]

Hi und willkommen im Forum

Bin mir besonders unsicher ob die Beziehungen unter einander richtig sind, z.B. die N:M-Beziehung zwischen Kunden und Einzelkurs, welche Beziehung zwischen Kunden und Mitarbeitern besteht, bzw. ob ich die Mitarbeitertabelle einfach weglassen kann.

Mir stellt sich die Frage, warum es zwischen Verein und Kunde und Kunde und Einzelkurs 2 Beziehungen gibt?! Warum wird zum Bsp. zwischen Kunde und Verein die Bankverbindung gespeichert (da fehlen übrigens einige Kardinalitäten ). Wieso zahlen Kunden den Mitgliedsbeitrag Wieso haben Mitarbeiter eine Kundennummer?

Ist die Nutzung der Primär- und Fremdschlüssel korrekt?

PrimaryKey kann man so lassen, ForeignKeys hast du keine eingezeichnet, kann ich also nicht drüber urteilen.

Welche und wie viele Attribute sollte die Kundentabelle enthalten, oder macht es Sinn, diese Tabelle in weitere Tabellen zu splitten.

Die Frage welche und wieviele kannst nur du bzw. dein Auftraggeber entscheiden.
Generell lässt sich nur sagen, wenn man es berechnen kann, muss man es auch nicht speichern.
Ich würde die Adressdaten in einen extra Entitätstyp übertragen. Vorallem, da du unter Verein auch Adressdaten speicherst.

noch ein paar Fragen/Hinweise:
Hat dein Verein keine Kontonummer?
n:m Beziehungen müssen in extra Entitätstypen aufgelöst werden, bei 1:n macht das wenig Sinn.
Wieso hat ein Einzelkurs einen Kursleiter, aber wieso kann ein Kursleiter aus mehreren Personen bestehen?
Wieso werden Mitgliedsbeitrag bzw. Einzugsermächtigung an der Beziehung gespeichert? Hiier würde ich eher vorschlagen, speicher das in einem extra Entitätstyp.

so, das war's erstmal

 

[Stefffano]

Hallo Niggo,
vielen Dank für Deine Mühe, Dir alles durchzulesen und Deine Bewertung und Hinweise. Hab also noch jede Menge zu tun.

Mir stellt sich die Frage, warum es zwischen Verein und Kunde und Kunde und Einzelkurs 2 Beziehungen gibt?!

Kann man denn jeweils die beiden Voränge in jeweils einer Beziehung unterbringen?

Warum wird zum Bsp. zwischen Kunde und Verein die Bankverbindung gespeichert (da fehlen übrigens einige Kardinalitäten ). Wieso zahlen Kunden den Mitgliedsbeitrag

Zum Teil sind die Kunden auch Mitglieder, aber mehrheitlich nicht. Eine extra Tabelle für Kunden und Mitglieder wäre wohl angebracht? Brauch ich dann nicht auch extra Tabellen für Kursangebote und Kurse jeweils für Mitglieder und Kunden?

Wieso haben Mitarbeiter eine Kundennummer?

Die Mitarbeiter sind fast alle MItglieder. Da Kunden und Mitglieder momentan in einer Tabelle stehen, haben sie eine Kundennummer. Brauch wohl auch noch eine Mitarbeitertabelle? Wenn ich jetzt eine Mitglieder-, eine Kunden- und eine Mitarbeitertabelle anlege, muß ich dann in jeder Tabelle extra die Personendaten speichern, oder reicht eine PersonenTabelle, in der ich jeweils nur hinterlege, ob Mitglied, Kunde, Mitarbeiter?

PrimaryKey kann man so lassen, ForeignKeys hast du keine eingezeichnet, kann ich also nicht drüber urteilen.

Oh, dann weiß ich wohl nicht wie ein ForeignKey dargestellt wird. Das was im PDF kursiv ist, soll jedenfalls der Fremdschlüssel sein.

Ich würde die Adressdaten in einen extra Entitätstyp übertragen. Vorallem, da du unter Verein auch Adressdaten speicherst.

Das ist nur eine einzige Adresse, die von unserem Verein, bzw. von mir.

noch ein paar Fragen/Hinweise:
Hat dein Verein keine Kontonummer?

Doch, wir haben eine. Was folgt daraus?

Wieso hat ein Einzelkurs einen Kursleiter, aber wieso kann ein Kursleiter aus mehreren Personen bestehen?

Wir haben mehrere Klone eingestellt Stimmt. Wollte eigentlich ausdrücken, daß die Mitarbeiter aus mehreren Kursleitern bestehen und die Kursleiter mehrere Mitarbeiter sind. Ist aber eine N:1- Beziehung, richtig? Mehrere Mitarbeiter sind Kursleiter und ein Kursleiter ist immer Mitarbeiter.

So, jetzt mach ich mich mal an die Arbeit.

Schöne Grüße einstweilen von Stefan

 

[Nico Graichen]

Hallo Niggo,
vielen Dank für Deine Mühe, Dir alles durchzulesen und Deine Bewertung und Hinweise. Hab also noch jede Menge zu tun.Kann man denn jeweils die beiden Voränge in jeweils einer Beziehung unterbringen?

Die Daten die du zu den Relations speichern willst, sind nicht von der Beziehung abhängig sondern von den Entitäten. Und dahin gehören auch die Daten. Demnach bräuchstest du bei der Person eigentlich nur den Verein speichern.

Zum Teil sind die Kunden auch Mitglieder, aber mehrheitlich nicht. Eine extra Tabelle für Kunden und Mitglieder wäre wohl angebracht? Brauch ich dann nicht auch extra Tabellen für Kursangebote und Kurse jeweils für Mitglieder und Kunden?Die Mitarbeiter sind fast alle MItglieder. Da Kunden und Mitglieder momentan in einer Tabelle stehen, haben sie eine Kundennummer. Brauch wohl auch noch eine Mitarbeitertabelle? Wenn ich jetzt eine Mitglieder-, eine Kunden- und eine Mitarbeitertabelle anlege, muß ich dann in jeder Tabelle extra die Personendaten speichern, oder reicht eine PersonenTabelle, in der ich jeweils nur hinterlege, ob Mitglied, Kunde, Mitarbeiter?

Du solltest eine Tabelle Person machen, in der alle Gemeinsamkeiten von Personen gespeichert werden, egal ob Kunde, Mitarbeiter oder sonst wer. Für Kunden und Mitarbeiter kannst du dann extra Tabellen machen, in den nur die Daten rein kommen, die für diesen Personentyp wichtig sind.

Oh, dann weiß ich wohl nicht wie ein ForeignKey dargestellt wird. Das was im PDF kursiv ist, soll jedenfalls der Fremdschlüssel sein.

Oh, dann ist mir das nicht aufgefallen. Wäre besser, wenn du die ForeignKeys gestrichelt unterstreichst.

Das ist nur eine einzige Adresse, die von unserem Verein, bzw. von mir.

Aber die Personen haben auch Adressen

Doch, wir haben eine. Was folgt daraus?

Das du sie ggf. auch speichern solltest

Wir haben mehrere Klone eingestellt Stimmt. Wollte eigentlich ausdrücken, daß die Mitarbeiter aus mehreren Kursleitern bestehen und die Kursleiter mehrere Mitarbeiter sind. Ist aber eine N:1- Beziehung, richtig? Mehrere Mitarbeiter sind Kursleiter und ein Kursleiter ist immer Mitarbeiter.

aha, immer diese Genforschung

noch ein Tipp:
Nutz zum Zeichnen von ERDs kein Zeichenprogramm. Beim Einbringen von Änderungen wirst du sonst noch verzweifeln.
Wenn du hast nutz dafür MS Visio oder lad die unter ca.com die Testversion von ErWIn runter. Damit ist das Anlegen von ERDs weitaus einfacher und komfortabler

 

[ishino]

Ich hab mir das Ganze inhaltlich nicht so genau angeschaut, aber hätte ein paar generelle Anmerkungen zum Thema ERD:

Die Notation ist - vorsichtig ausgedrückt - ungewöhnlich. Das ist IMHO keine Geschmackssache, denn es gibt klar definierte Regeln dafür, wenn auch unterschiedliche Gesamtansätze.

Relationsbezeichnungen müssen eindeutig sein, auch wenn das manchmal nur mit Numerierungen o.ä. zu machen ist, gehört sich das einfach so.

Fremdschlüssel gehören NICHT zum Konzept des ERD, sondern ergeben sich aus der relationalen Umsetzung des Modells. Das ist ein Kardinalfehler, den ich in meiner Zeit als Mitarbeiter an der Uni ständig von unseren Studenten gesehen hab.

Das gleiche gilt für die "Tabellendenke", die sowohl der OP als auch der freundliche Berater an den Tag gelegt haben. Im ERD gibts Entitäten und Relationen, die durch Attribute beschrieben werden. Sonst nix. Tabellen entstehen bei der Umsetzung des Modells. Beim Entwurf sollte man deshalb nicht drüber nachdenken welche Tabellen man braucht, denn wenn man so an die Sache rangeht, braucht man kein ERD sondern kann gleich die relationale Umsetzung entwerfen.

Gerade bei dem Klassiker "Organisationsmodell" sollte man versuchen Hierarchien zu verwenden. Niggo hat das mit seinem Hinweis auf die Personen schon angesprochen.

 

[Stefffano]

Hallo Leute,
vielen Dank für Eure hilfreichen Informationen. Habe fleißig dran gearbeitet und jetzt eigentlich fast alles auf den Kopf gestellt und versucht das umzusetzen, was ihr mir empfohlen habt. Wenns "fertig" ist zeig ichs Euch noch mal

Insgesamt finde ich es aber ganz schön schwer.

Erstmal schöne Grüße von Stefan

 

[Stefffano]

(Access) Neues ER-Diagramm - besser so?

Hallo Leute,
ich habs nochmal versucht, es sieht zumindest wesentlich übersichtlicher aus, muß nur noch das "Personal" unterbringen.