ER-Modell

[HuoFenG]

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?

[dr.dimitri]

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

[raiserle]

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.

[HuoFenG]

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?

[Adrian3591]

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

[raiserle]

...... viele Datensätze in der INT(255) in Abteilung hättest und in miterarbeiter nur INT(11) einen Fehler

Nein. Es ist kein Fehler. Dies würde nur bei Varchar usw. auftreten [MySQL ].

Int = Int

Bearbeitet 30. Oktober 2012 von raiserle

[HuoFenG]

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?

[Leimy84]

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

[dr.dimitri]

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

[Adrian3591]

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

[raiserle]

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!

[HuoFenG]

Das ist genau der Punkt den ich nicht so recht verstehe

Ich werd das ganze nachher mit meinem Prof besprechen. Ich befürchte nur das er keine Ahnung davon hat...

Ich berichte dann spätestens morgen..

[Adrian3591]

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.

[raiserle]

Vielleicht gibt es einen Sinn. Aber dazu muss dr.dimitri mal was sagen. Und nicht einfach nur was in den Raum stellen.

[dr.dimitri]

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

[Daij]

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