Zum Inhalt springen

ER-Modell


HuoFenG

Empfohlene Beiträge

Guten Morgen,

Ich soll ein ER-Modell als Ergebnis der Anforderungsanalyse erstellen.

Es geht sich um eine Datenbank, welche Grundlage für ein Organigramm werden soll.

D.H.:

Entitäten:

Mitarbeiter, Standort, Abteilung

Attribute:

Mitarbeiter: MA Nummer(Schlüssel), Vorname, Nachname, Abteilung, Arbeitsplatz, Tätigkeit, Telefonnummer, handynummer, E-Mail, Foto

Standort: SO Nummer(Schlüssel), Adresse, Bezeichnung

Abteilung: AT Nummer(Schlüssel), Bezeichnung

Verbindungen:

Mitarbeiter (n) arbeitet an (m) Standort

Mitarbeiter (n) arbeitet an (1) Abteilung

Nun meine Fragen :-)

Sollte man das Attribut Adresse in Strasse,Hausnummer,PLZ und Ort aufteilen?

Der Mitarbeiter hat das Attribut "Abteilung". Es gibt aber schon die Entität "Abteilung". Soll man dann nicht eher die Abteilung von dem Arbeitsplatz ableiten?

Fallen euch noch weitere Dinge ein?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Fallen euch noch weitere Dinge ein?

Ja. Verwende niemals einen fachlichen Wert als Schlüssel. Ändert sich der Abteilungsname hast Du ein Problem, gleiches bei Mitarbeiternummer und SO Nummer. Verwende immer rein technische Werte, die von den fachlichen Werten unabhängig sind. Des weiteren macht es das Handling deutlich einfacher, wenn die PK-Spalte in allen Tabellen immer gleich heißt, z.B. ID.

Sollte man das Attribut Adresse in Strasse,Hausnummer,PLZ und Ort aufteilen?

Unbedingt. Ansonsten kommt da nicht mehr zu prüfender Freitext rein, der nicht mehr vernünftig anzeigbar und selektierbar ist.

Der Mitarbeiter hat das Attribut "Abteilung". Es gibt aber schon die Entität "Abteilung". Soll man dann nicht eher die Abteilung von dem Arbeitsplatz ableiten?

Was soll denn in dieses Feld rein? Eine Zimmernummer? Freitext?

Dim

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja. Verwende niemals einen fachlichen Wert als Schlüssel. Ändert sich der Abteilungsname hast Du ein Problem, gleiches bei Mitarbeiternummer und SO Nummer. Verwende immer rein technische Werte, die von den fachlichen Werten unabhängig sind. Des weiteren macht es das Handling deutlich einfacher, wenn die PK-Spalte in allen Tabellen immer gleich heißt, z.B. ID.

Subjektive Meinung! -> ON UPDATE! Des weiteren steht dort überall Nummer.

Der Mitarbeiter hat das Attribut "Abteilung". Es gibt aber schon die Entität "Abteilung". Soll man dann nicht eher die Abteilung von dem Arbeitsplatz ableiten?

n:1 -> Mitarbeiter ist in Abteilung <- Nummer von Abteilung rein.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Jetzt kommen noch mehr Fragen...

Wieso ist MA-Nummer, SO-Nummer und Abtielungsnummer ein fachlicher Wert? Ich dachte ich nutze die Nummern als ID.

PK-Spalte? Kann ich mir gerade nicht übersetzen :)

n:1 -> Mitarbeiter ist in Abteilung <- Nummer von Abteilung rein.

Den versteh ich auch nicht so recht..

n = Mitarbeiter

1 = Abteilung

Wo soll nun die Nummer der Abteilung rein?

Link zu diesem Kommentar
Auf anderen Seiten teilen

n Miterarbeiter gehören zu 1 Abteilung. Das heißt du hast am Ende beliebig viele Datensätze in der Tabelle Mitarbeiter die einer Abteilung zugeordnet sind.

Das ganze lässt sich über Foreign Keys realisieren. Heißt du hast eine Tabelle Mitarbeiter und eine Tabelle Abteilung. Beide haben eine Spalte ID. Die Tabelle Mitarbeiter hat noch eine Spalte Abteilung die einen Fremdschlüsselverweis auf die ID der Abteilung hat.

WICHTIG: Spalte Abteilung in Mitarbeiter Tabelle und ID in ABteilung müssen vom selben Datentyp sein. z.B. INT(11). Wichtig hierbei ist auch die Zahl in Klammern dahinter, die angibt wie viele Zeichen höchstens verwendet werden dürfen. Dementsprechend würdest du wenn zu z.B. INT(255) in Abteilung hättest und in miterarbeiter nur INT(11) einen Fehler :)

Optische Darstellung:

Abteilung

-------------

ID int(11)

bezeichnung varchar(255)

Mitarbeiter

------------

ID int(11)

name varchar(255)

abteilung int(11) --> Foreign Key auf Abteilung.id :) und am besten ON UPDATE Cascade und ON DELETE Cascade setzen

hoffe das konnte dir helfen :)

EDIT: und PK steht für Primary Key = Primärschlüssel :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielen Dank!

Ihr habt mir sehr geholfen...

wenn ich die Datenbank dann realisiere, werdet ihr bestimmt einen neuen Thread von mir finden ;)

*Edit:

Könnt ihr mir nochmal bitte sagen wo der Unterschied bei "Mitarbeiternummer" und "ID" ist?

Macht man das nur, damit man einheitlich überall ID hat?

Link zu diesem Kommentar
Auf anderen Seiten teilen

"Mitarbeiternummer" hört sich nach einer Zahl an, die in den Personalakten steht und mit denen Abrechnungen gemacht werden.

"ID" ist ein rein technischer Wert, welcher sich wirklich nur auf einen Datensatz in der Datenbank bezieht.

Um sicherzustellen, dass eine Mitarbeiternummer in der Mitarbeitertabelle nicht doppelt vorkommt gibt es neben dem PK noch die Möglichkeit der Indizierung (MySQL: unique). Das macht SELECTs mit Where-Bedingung über den Index ähnlich schnell wie über den PK und entkoppelt den Wert gleichzeitig von der technischen Realisierung.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Subjektive Meinung! -> ON UPDATE! Des weiteren steht dort überall Nummer.

Ich kann es nur wiederholen:

Niemals einen fachlichen Wert als PK verwenden. Spalten sind billig, ON UPDATE wird nicht von allen Datenbanken unterstützt, des weiteren können nicht immer alle Abhängigkeiten mit einem FK Constraint abgebildet werden.

Ob dort eine Nummer steht oder nicht ist vollkommen egal.

Dim

Link zu diesem Kommentar
Auf anderen Seiten teilen

Der Unterschied zwischen Mitarbeiternummer und ID ist der aus reiner Datenbanksicht, dass ID ein künstlicher Primärschlüssel ist und Mitarbeiternummer wäre ein natürlicher Primärschlüssel.

MMn gibt es keine Unterscheidung zwischen Fachlichen Wert und nicht fachlich. Wenn dieser Wert einen einzigen Datensatz so eindeutig kennzeichnet, wieso ihn dann nicht als Primärschlüssel nehmen?

Das Einzige was man nicht speichern sollte in einer Datenbank sind Prozessdaten, wie z.B. das Alter einer Person. An der Stelle dann halt Fixe Werte speichern wie das Geburtsdatum

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich kann es nur wiederholen:

Niemals einen fachlichen Wert als PK verwenden.

Sorry, dass ich nochmal drauf rumhacken muss!

Aber aus welcher fachlichen Literatur hast du diese Aussage (oder nur so ein Ding von: Ich mach das so!). Und vor allem mit welcher Begründung.

Wenn du eine Behauptung aufstellst, dann solltest du sie auch begründen!

Link zu diesem Kommentar
Auf anderen Seiten teilen

es gibt keine Unterscheidung, ob fachlicher Wert oder nicht!

wie ich schon sagte, solange ein Wert einen Datensatz in einer Tabelle eindeutig kennzeichnet kann ich ihn als Primärschlüssel verwenden.

Wenn du keine fachlichen Werte nehmen würdest, würde es keine natürlichen Primärschlüssel mehr geben sondern nur künstliche.

Von daher ist das in meinen Augen ohne Sinn diese Aussage.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Sorry, dass ich nochmal drauf rumhacken muss!

Aber aus welcher fachlichen Literatur hast du diese Aussage (oder nur so ein Ding von: Ich mach das so!). Und vor allem mit welcher Begründung.

Wenn du eine Behauptung aufstellst, dann solltest du sie auch begründen!

Ich dachte, dass hätte ich schon in meinem ersten Post gemacht.

Also jetzt ausführlich:

Ausgangslage: Entwickler A verwendet, aus welchem Grund auch immer, fachliche Werte als PK.

Fall 1: Der fachliche Wert wird inhaltlich geändert.

Folgen: Alle abhängigen Werte müssen ebenfalls angepasst werden. Unterstützt die DB ON UPDATE CASCADE wird das zwar automatisch erledigt, benötigt aber auch Zeit (Performance). Bei hunderttausenden oder Millionen Datensätzen könnte da schon mal die ein oder anderen Nachfrage kommen...

Daten, die nicht per FK-Constraint am übergeordneten Satz hängen können, sind jetzt Leichen. Auch in diesem Fall dürfte das früher oder später jemandem auffallen.

Fall 2: Der Datentyp des PK ändert sich.

Sofern Entwickler A noch im Unternehmen tätig ist, hat er jetzt ein echtes Problem, denn ON UPDATE CASCADE hilft jetzt auch nichts mehr. Alle abhängigen Daten müssen per Hand migriert werden.

Fall 3: Der fachliche Wert alleine ist nicht mehr unique, weil sich fachliche Anforderungen/Prozesse geändert haben.

Folge: Uuuuuups -> Mal wieder Migration per Hand

Fall 4: Die Daten sollen mit Daten aus einem anderen System zusammengeführt werden.

Jetzt hat unser Entwickler A ein echtes Problem, denn Fall 1, 2 und 3 können jetzt gemeinsam auftreten. Er hat nun Gelegenheit nachzudenken, was er falsch gemacht hat, während er Migrationsskripte schreibt, die in allen möglichen Tabellen die PKs und FKs anpassen. Hätte er nur mal auf den alten Dim gehört, damals im Forum

Und ja: Ich mach das so, den ansonsten wären die Daten in "meiner" Datenbank (operatives System einer großen Versicherung, 3TB, ca. 2,5Mrd Datensätze, ca. 500 Tabellen) bald nur noch Kraut und Rüben.

Daher nochmal: Nie, nie, nie einen fachlichen Wert als PK verwenden. Immer einen rein technischen benutzen. Es kostet nichts, schadet nichts, der Nutzen ist unbezahlbar.

Immer im Auge behalten: Daten leben länger als man denkt.

Dim

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

Dim hat eigentlich schon alles gesagt -

IMMER einen künstlichen technischen Primärschlüssel verwenden, tut nicht weh, und gibt einem die Sicherheit, dass es niemals aufgrund von fachlichen Änderungen zu Problemen kommt.

Eine Sache wo ich aber widersprechen möchte.

Ich nenne meine Spalten nie einfach "ID" sondern gebe jeder Spalte einer Tabelle einen Präfix der sie kennzeichnet.

Als Beispiel: Tabelle "PERSON" - hier gebe ich jeder Spalte ein Präfix "P_" - die Spalte "ID" heißt also "P_ID" somit ist immer klar, dass die Spalte aus dieser Tabelle kommt - bringt im ersten Moment (wenn man das Datenmodell nicht kennt) keinen großen Vorteil - wenn allerdings das Datenmodell bekannt ist, dann birgt es unschätzbare Vorteile wenn man bei einem Join nicht drölf mal "ID" da stehen hat, sondern bspw. P_ID, A_ID, AD_ID etc...

Viele Grüße

Daij

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...