Tabelle "normalisieren"

[Biene_Maja]

Habe folgende Tabelle die ich normalisieren will:

Unternehmen

-Name
-Wohnort
-Gehalt
-Jahresbudget  (für alle Projekte)
-altes Gehalt
-ProzÄnderung (Prozentuale Änderung des Gehalts des Mitarbeiters)
-geplantesBudget (für das jeweilige Projekt)
-PName ( Projekt-Name in dem der Mitarbeiter ist - jeder Mitarbeiter ist nur in einem Projekt)

Hatte mir gedacht für die 1. NF erstelle ich eine Mitarbeiter-ID die dann der Primärschlüssel wird, wodurch die Tabelle ja dann imho auch direkt in der 2. NF ist. Aber wie sähe die Tabelle dann in der 3. NF aus ?
Hoffe ich habe alles verständlich erklärt und ihr könnt mir helfen :)

MfG

Biene_Maja

[Tom]

Hello,

Habe folgende Tabelle die ich normalisieren will:

Unternehmen

-Name
-Wohnort
-Gehalt
-Jahresbudget  (für alle Projekte)
-altes Gehalt
-ProzÄnderung (Prozentuale Änderung des Gehalts des Mitarbeiters)
-geplantesBudget (für das jeweilige Projekt)
-PName ( Projekt-Name in dem der Mitarbeiter ist - jeder Mitarbeiter ist nur in einem Projekt)

Hatte mir gedacht für die 1. NF erstelle ich eine Mitarbeiter-ID die dann der Primärschlüssel wird, wodurch die Tabelle ja dann imho auch direkt in der 2. NF ist. Aber wie sähe die Tabelle dann in der 3. NF aus ?
Hoffe ich habe alles verständlich erklärt und ihr könnt mir helfen :)

in der Praxis mache ich es eigentlich immer so:

• welche Daten ändern sich gar nicht oder äußerst selten? -> Stammdaten
• welche Daten haben auch im wahren Leben einen engen Bezug? -> Clusterung
• welche Daten könnten sich über die Lebensdauer der Datenbank häufiger ändern?
    -> veränderliche Eigenschaften des Stammobjektes -> Bewegungsdaten.

Für jeden Bewegungsdatentyp benötigst Du dann eine eigene Tabelle.

Daten, die Du durch reproduzierbare Rechnung auseinander ableiten kannst, gehören nicht in die Tabelle. Bei Dir wäre das z.B. %-Änderung des Gehaltes. Gehalt benötigt eine eigene Tabelle.

Ich würde das so aufteilen:

Mitarbeiter           Gehalt              Projekt           Projektbudget
  ===========           =============       =============     =============

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Bio]

Sup!

-Name
-Wohnort
-Gehalt
-Jahresbudget  (für alle Projekte)
-altes Gehalt
-ProzÄnderung (Prozentuale Änderung des Gehalts des Mitarbeiters)
-geplantesBudget (für das jeweilige Projekt)
-PName ( Projekt-Name in dem der Mitarbeiter ist - jeder Mitarbeiter ist nur in einem Projekt)

http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Dritte_Normalform_.283NF.29

Ich würde mal sagen:

Es sollte eine eigene Tabelle für Projekt / Projektbudget geben, denn das Projekt hängt nicht von der Mitarbeiter ID ab.

Jahresbudget sollte in einer eigenen Tabelle stehen.

ProzÄnderung scheint Blödsinn zu sein.

Also:

Mitarbeiter: Mitarbeiter-ID, Name, Wohnort, Projekt-ID
Projekt: Projekt-ID, Projekt-Budget
Firma: Gesamt-Budget

Was das Gehalt angeht - vielleicht solltest Du da eine Tabelle mit der Entwicklung machen, wenn die überhaupt wichtig ist:

Gehalt: Euro, Jahr, Mitarbeiter-ID

Dann könnte das schon ziemlich normalisiert sein. Wikipedia lesen bildet natürlich dennoch im Zweifel.

Gruesse,

Bio

[Biene_Maja]

Danke für die Antworten :)
Das Problem ist, das ist ne Aufgabe von nem Prof von mir, deswegen auch die Sinnhaftigkeit ;)

Hatte mir die 3. NF dann so gedacht

Mitarbeiter-Tabelle

-MID
-Name
-Wohnort
-PName

Projekt-Tabelle

-Pname
-Budget

Gehalt-Tabelle

-Gehalt
-a. Gehalt
-Änderung

weiss nur nicht wie ich die Gehaltstabelle jetzt mit der Mitarbeiter-Tabelle verbinde ...
Könnte mir da vllt. jemand helfen und mir sagen ob die Normalformen so richtig sind ?

[Bio]

Sup!

-Gehalt
-a. Gehalt
-Änderung

weiss nur nicht wie ich die Gehaltstabelle jetzt mit der Mitarbeiter-Tabelle verbinde ...

Tja. Wahrscheinlich kann man das Gehalt und die Änderung auch beim Mitarbeiter speichern, denn jeder Mitarbeiter hat ja genau ein aktuelle/altes Gehalt, und diese sind beide unabhängig vom Namen, Projekt etc.

Aber die Änderung zu speichern halte ich für eine Falle, denn die Änderung ist ja aus Gehalt/altes Gehalt erreichenbar und damit redundant und damit transitiv abhängig und damit nicht in 3NF. Ich würde es gar nicht speichern; die Datenbank kann's einem ja trotzdem sagen.

Gruesse,

Bio

[Tom]

Hello,

Danke für die Antworten :)
Das Problem ist, das ist ne Aufgabe von nem Prof von mir, deswegen auch die Sinnhaftigkeit ;)

Hatte mir die 3. NF dann so gedacht

Mitarbeiter-Tabelle

-id_mitarbeiter
-Name
-Wohnort
-PName

Projekt-Tabelle

(-id_projekt)

-Pname
-Budget

Gehalt-Tabelle

(-id_gehalt)
  -gehalt
  -seit_datum
  -id_mitarbeiter          # brauchst Du unbedingt, da hier ja die Gehälter aller MAs stehen

Das mit der %-Änderung ist eine Falle, möchte ich tippen.

Ich würde in der Praxis immer eine ID als Datenunabhängigen Primary Key vergeben.
Es ist nämlich z.B. leicht möglich, dass sich der Projektname während der Laufzeit ändert oder ein Schreibfehler berichtigt werden soll... Die Beziehungen sollten daher immer vom Klartext unabhängig sein.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

Hello,

Danke für die Antworten :)
Das Problem ist, das ist ne Aufgabe von nem Prof von mir, deswegen auch die Sinnhaftigkeit ;)

Hatte mir die 3. NF dann so gedacht

Mitarbeiter-Tabelle

-id_mitarbeiter
-Name
-Wohnort

-id_projekt

Projekt-Tabelle

-id_projekt

-Pname
-Budget

Gehalt-Tabelle

(-id_gehalt)
  -gehalt
  -seit_datum
  -id_mitarbeiter          # brauchst Du unbedingt, da hier ja die Gehälter aller MAs stehen

Das mit der %-Änderung ist eine Falle, möchte ich tippen.

Ich würde in der Praxis immer eine ID als Datenunabhängigen Primary Key vergeben.
Es ist nämlich z.B. leicht möglich, dass sich der Projektname während der Laufzeit ändert oder ein Schreibfehler berichtigt werden soll... Die Beziehungen sollten daher immer vom Klartext unabhängig sein.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Ilja]

yo,

wenn es eine aufgabe deines prof. ist, dann solltest du nicht nur eine lösung präsentieren, sondern vor allem auch den weg verstehen und erklären können. normalisierung ist nicht ganz so trivial und wird in aller regel falsch angewandt. wichtig ist vor allem zu verstehen, warum normalisierung überhaupt erst zur anwendung kommt und dann werden die regeln auch verständlicher.

und kurz noch zu deinem konkreten beispiel, ohne weitere infos ist sie nicht zu lösen. zum beispiel fehlt die info, ob das gehalt von dem mitarbeiter abhängig ist oder aber von den projekten, an dem er teil nimmt, ob ein mitarbeiter nur an einem projekt teilnehmen kann oder an mehreren, etc.

aber mein tipp für dich ist, überführe alles erst einmal in die 0. Normallform.

Ilja