Database Reference
In-Depth Information
chen Funktionen zugeordnet sein, wie der zu ersetzende Mit-
arbeiter.
Für die Festlegung des Gehaltes könnte man den Funktionen
Basissaläre hinterlegen. Dazu kommt eine Dienstalterszulage,
die ebenfalls bei den Funktionen abgelegt wird und eine indi-
viduelle Leistungskomponente, die bei den Mitarbeitern hinter-
legt wird. Auch ein Schichtzuschlag für Früh- oder Spätschich-
ten wäre vorstellbar. Das Gehalt ließe sich dann so berechnen:
TG = SZ * ( BS + DA * DAZ ) + BS * LK
Dabei gelten folgende Abkürzungen:
TG=Tagesgehalt, SZ=Schichtzuschlag (Schichttypen), BS=Basis-
salär (Funktionen), DA=Dienstalter (Mitarbeiter), DAZ=Dienst-
alterszulage (Funktionen), LK=Leistungskomponente (Mitarbei-
ter). In Klammern stehen die Entitätsmengen, wo die Salärkom-
ponenten auf Tagesbasis berechnet abgelegt werden. Somit
wird der Lohn täglich berechnet, monatlich aufsummiert und
ausbezahlt. Die Leistungskomponente wird jährlich festgelegt.
Ob so ein Lohnsystem gerecht wäre, steht hier nicht zur Dis-
kussion (objektiv gerechte Lohnsysteme gibt es sowieso nicht).
7.2.4
Kundenverwaltung
Der Supermarkt bietet ein umsatzabhängiges Rabattsystem für
Kunden an. Beispielsweise werden 2% des Umsatzes den Kun-
den gutgeschrieben. Mit diesen Guthaben können die Kunden
ausgewählte Artikel kaufen oder Einkaufsgutscheine beziehen.
Zudem soll es möglich sein, das Einkaufsverhalten der Kunden
festzuhalten, um gezielt Werbung für bestimmte Artikel zu ver-
schicken. Die Kunden brauchen dafür Kundenkarten. Dabei ist
aber unerheblich, wie viele Karten ein Kunde besitzt, da es
keine Kreditkarten sein werden, sondern bei der Bezahlung
nur dazu dienen, die Einkäufe zuordnen zu können (über ei-
nen Strichcode). Es braucht somit keine Entität „Kundenkar-
ten“, dafür aber eine Verknüpfung zwischen Kunden und Arti-
keln:
Bild 7.14:
Transformierte
mc-mc-Bezie-
hung zwischen
Artikel und
Kunden
1
mc
R018
mc
1
R019
Kunden-
artikel
Artikel
Kunden
