[DB] Normalisierungsfrage

Hallo, ich stehe mal wieder vor einem Problem, dass best. viele von Euch kennen. Dazu ein kleines Beispiel:

Wir versuchen Mitarbeiter einem Projekt zuzuordnen. An einem Projekt können nicht nur Mitarbeiter unserer Firma mitarbeiten, sonder auch z. B. Freelancer.

Die Freelancer können nicht als Mitarbeiter geführt werden.

Tabellen:

Projekt:
  [u]schluessel[/u]
  weitere Projektdaten

Mitarbeiter:
  [u]mitarbeiter_id[/u]
  weitere Mitarbeiterdaten

Freelancer:
  [u]freelancer_id[/u]
  weitere Freelancerdaten

Projektteam:
  [u]projekt_schluessel[/u]
  [u]mitarbeiter_id[/u]
  [u]freelancer_id[/u]

Dieses Datenmodell löst das Problem auf die einfachste Weise. Das einzige was mich immer an dieser Lösung stört ist, dass entweder die Mitarbeiter_id oder die Freelancer_id null sein muss. IMHO ist das nicht gerade elegant gelöst. Entweder der Programmierer muss dies sicherstellen, oder z. B. der DB-Admin mittels plsql.

Nun meine eigentliche Frage dazu: Wie löst ihr solche Probleme? Gibt es schönere/sauberer Lösungen dafür?

Besten Dank im voraus...

entelechie

ich wuerde zwei kreuztabellen einfuehren:
zwischen projekt <-> mitarbeiter und projekt <-> freelancer.
das duerfte die sauberste loesung sein. beide ids in
einer tabelle mitzufuehren geht natuerlich is aber fehleranfaelliger.

Unix-Tom

Wieso müssen Mitarbeiter und Freelancer getrennt sein. Somit kannst du jedem eine ID geben, die Freelancer makieren und gut ist es.
Die Felder sind doch sowieso bei beiden vorhandem (Adresse, Tel, u.s.w.)

gomberl

wenn wir jetzt von einem korrekten modell ausgehen dann geht das folgendermassen (meiner meinung nach)

"freelancer" und "angestellte" sind "mitarbeiter"
das heisst mitarbeiter ist ein super entity typ von den 2 sub entitiy typen mitarbeiter und angestellte

dadurch löst du auch das problem von 2 verschiedenen tabellen mit basis daten
das heisst alle daten die sowohl ein angestellter als auch ein freelancer haben (name, geburtsdatum, usw) werden im super entity typ mitarbeiter gespeichert
die unterschiedlichen daten dann in den jeweiligen sub entity typen (zB stundenlohn, firmenanschrift, UID nummer, usw)

wichtig ist: ein sub datentyp hat einen primary key der genau dem primary key des super datentypen entspricht. dieser primary key ist gleichzeitig auch foreign key auf die super tabelle

ein projekt hat dann multiple mitarbeiter zugeordnet in einer m:n tabelle
das wäre eine saubere implementierung für das problem

gomberl

mi+chl

das problem hab ich vor kurzem auch mal gehabt, lösung siehe gomberl.

das ganze kann man dann noch weiter stricken, je nach dem was du brauchst.

z.B.:
Subjekte => personen und firmen
personen => mitarbeiter und kunden
mitarbeiter => angestellte und freelancer

wenn du das immer brav 1:1 verknüpfst, dann gibts sicher keine probleme, dann kann z.B. auch ein angestellter gleichzeitig kunde sein

mfg

Hallo, danke erstmal für die vielen Antworten.

Das hört sich alles schon gut an, ich habe mich bloß etwas schlecht ausgedrückt, bzw. ein schlechtes Bsp. gewählt. Ein ähnlicher Problemfall wäre zum Bsp., dass ein Projekt von einem Subunternehmen ausgeführt werden kann.

Dieses Subunternehmen wird in einer Tabelle Subunternehmen gespeichert. Allerdings kann ein Projekt auch von einem Gruppenunternehmen(innerhalb der selben Firmengruppe) bearbeitet werden. Diese stehen z. B. in der Tabelle Gruppenunternehmen. Also würde der Fremdschlüssel in der Projekttabelle auf 2 versch. Tabellen verweisen können.

Man kann natürlich auch mit zwei Fremdschlüsseln in der Projkettabelle arbeiten, wo wir wieder das Problem haben, dass einer von beiden null sein muss.

Wie meint Ihr kann man das Problem elegant lösen? Ihr habt da bestimmt schon etwas mehr Erfahrung mit.

Besten Dank im voraus!

gomberl

schau dir mi+chl's letzten vorschlag an
das ist genau was du brauchst
quasi eine weiterfuehrung dessen was ich vorgeschlagen habe

denke es dir mal durch und dann frage wenn du noch fragen hast

Man kann natürlich auch mit zwei Fremdschlüsseln in der Projkettabelle arbeiten, wo wir wieder das Problem haben, dass einer von beiden null sein muss.

das halte ich fuer keine gute idee
ich schaetze mal ein mitarbeiter kann in mehreren projekten arbeiten und allerdings kann ein projekt auch mehrere tabellen zugewiesen haben
dementsprechend hast du eine m:n beziehung und musst eine zwischentabelle machen (primary key ist foreign key subjekt und foreign key projekt zusammen)

lg

gomberl

Danke... Bin bloß noch etwas verunsichert

Also wenn ich das alles richtig verstanden habe, dann macht man z.b. bei dem Mitarbeiter/Freelancer folgende Struktur:

Projekt:
  [u]schluessel[/u] PK
  weitere Projektdaten

Mitarbeiter:
 [u]mitarbeiter_id[/u] PK
  weitere Mitarbeiterdaten sowohl Freelancer als auch Angestellte

Angestellter:
  [u]angestellter_id[/u] PK / FK
  spezifische Angestelltendaten, wie Sozialversicherungsnummer, Gehalt

Freelancer: 
  [u]freelancer_id[/u] PK / FK
  spezifische Freelancerdaten

Projektteam:
  [u]projekt_schluessel[/u] PK
  [u]mitarbeiter_id[/u] PK

Beziehungen:
Projekt 1:n Projektteam
Projektteam n:m Mitarbeiter
Mitarbeiter 1:1 Angestellter
Mitarbeiter 1:1 Freelancer

Habe ich das so richtig verstanden? Ich glaube das ist noch irgendwo der Wurm drinne.

Mich wunderte das nur deshalb, weil in diesem Fall vom Mitarbeiter Schlüssel 2 Fremdschlüssel Beziehungen ausgehen. Das hatte ich vorhe noch nicht gesehen. Klingt auch ehrlich gesagt immer noch ein bischen unlogisch für mich. Dieses Constraints sagen ja aus, dass sich der Mitarbeiter Schlüssel sowohl in Angestellter- als auch in der Freelancertabelle befinden muss?

Danke!

gomberl

okay
hier mein vorschlag (ausgehend von nur mitarbeiter und freelancern, keine firmen (als teilprojektnehmer) ) - nicht viel anders als deiner

Projekt:
  [u]schluessel[/u] PK
  weitere Projektdaten

Mitarbeiter:
 [u]mitarbeiter_id[/u] PK
  weitere Mitarbeiterdaten sowohl Freelancer als auch Angestellte

Angestellter:
  [u]mitarbeiter_id[/u] PK / FK
  spezifische Angestelltendaten, wie Sozialversicherungsnummer, Gehalt

Freelancer: 
  [u]mitarbeiter_id[/u] PK / FK
  spezifische Freelancerdaten

Projektteam:
  [u]projekt_schluessel[/u] PK / FK
  [u]mitarbeiter_id[/u] PK / FK

angestellter.mitarbeiter_id sowie freelancer.mitarbeiter_id zeigen auf mitarbeiter.mitarbeiter_id

Oraklus schrieb:

Habe ich das so richtig verstanden? Ich glaube das ist noch irgendwo der Wurm drinne.

Mich wunderte das nur deshalb, weil in diesem Fall vom Mitarbeiter Schlüssel 2 Fremdschlüssel Beziehungen ausgehen. Das hatte ich vorhe noch nicht gesehen. Klingt auch ehrlich gesagt immer noch ein bischen unlogisch für mich. Dieses Constraints sagen ja aus, dass sich der Mitarbeiter Schlüssel sowohl in Angestellter- als auch in der Freelancertabelle befinden muss?

Danke!

das ist eben nicht richtig - die fremdschluesselbeziehung geht nicht von mitarbeiter aus, sondern von angestellter/freelancer und beziehen sich auf mitarbeiter (PK) - das nennt man eine is-a beziehung
angestellter.mitarbeiter_id, sowie freelancer.mitarbeiter_id sind sowohl fk auf mitarbeiter als auch pk ihrer eigenen tabelle (der pk eines sub entity typen ist derselbe des super entity typen - exact derselbe)

ein mitarbeiter "is-a" freelancer oder "is-a" angestellter - das ist ausschliessend - du musst pruefen das die gleiche mitarbeiter_id nicht im angestellten und mitarbeiter table sind

such im internet unter super-sub entity type, dort findest du jede menge informationen ueber diese modellierung

ich hoffe geholfen zu haben

Danke sehr sogar...

Du kennst nicht vielleicht ein freies Tool mit dem man ERM Modele grafisch(für den Ausruck) erstellen kan?

Trotzdem nochmals danke!

gomberl

dbdesigner heisst das glaube ich

das sollte funktionieren

ist irgendwie connected zu mysql