HuoFenG Geschrieben 30. Oktober 2012 Teilen Geschrieben 30. Oktober 2012 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 30. Oktober 2012 Teilen Geschrieben 30. Oktober 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 30. Oktober 2012 Teilen Geschrieben 30. Oktober 2012 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
HuoFenG Geschrieben 30. Oktober 2012 Autor Teilen Geschrieben 30. Oktober 2012 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Adrian3591 Geschrieben 30. Oktober 2012 Teilen Geschrieben 30. Oktober 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 30. Oktober 2012 Teilen Geschrieben 30. Oktober 2012 (bearbeitet) ...... 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
HuoFenG Geschrieben 30. Oktober 2012 Autor Teilen Geschrieben 30. Oktober 2012 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Leimy84 Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 "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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Adrian3591 Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 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! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
HuoFenG Geschrieben 31. Oktober 2012 Autor Teilen Geschrieben 31. Oktober 2012 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.. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Adrian3591 Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 Vielleicht gibt es einen Sinn. Aber dazu muss dr.dimitri mal was sagen. Und nicht einfach nur was in den Raum stellen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 31. Oktober 2012 Teilen Geschrieben 31. Oktober 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Daij Geschrieben 20. November 2012 Teilen Geschrieben 20. November 2012 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
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.