Suchen...
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Aufbau einer Bestandslogik

Ein Personaldienstleister möchte seine Bewerber auswerten. Bewerber können sich auf eine offene Stelle oder initiativ in einem Portal registrieren, werden dann von den Niederlassungen überprüft – und bald mit DeltaMaster von Marketing, der Personalabteilung, dem Vertrieb und den Niederlassungsleitern ausgewertet. Allerdings liefert das Vorsystem täglich nur den heutigen Stand eines Bewerbers, ohne dass ersichtlich ist, ob gestern ein Wechsel seiner Eigenschaften stattgefunden hat. Um Zeitperiodenvergleiche oder einen historischen Bestand auswerten zu können, müssen die Daten also erstmal historisiert werden. Wie das funktioniert, wird in diesem Beitrag beschrieben.

Ein Bewerberdatensatz hat mehrere Eigenschaften, z. B. eine BewerberID, ein Registrierungsdatum, eine Niederlassungszuordnung [z. B. Fulda, Darmstadt, Nürnberg, …], eine Qualifizierung [A, B, C], eine Art Gehaltsstufe (Entgeltgruppe) [1-9] und einen Status [wait, in, abgesagt, out].

Die Marketingabteilung will die Qualität ihrer Werbekampagne bewerten und wissen, wie viele Bewerber einer bestimmten Entgeltgruppe sich in einer bestimmten Region neu registriert haben (Kennzahl „Anzahl_neue_Bewerber“ in Fulda in KW 12/2016), der Vertrieb möchte wissen, wie viele Bewerber mit bestimmten Eigenschaften befinden sich gerade im Zugriff (Bestandskennzahl „Bewerber“ in Darmstadt, unabhängig vom Datum der Registrierung); weitere Anforderungen werden sicherlich folgen.

Die Daten des Vorsystems waren schnell in den bestehenden SQL-Server importiert und die Dimensionen aus den genannten Eigenschaften und Kennzahlen schnell modelliert. Fehlten nur noch historische Daten zum Befüllen und eine Prozedur P_APP_Historisierung_Bewerber die folgendes macht:

    1. Die Daten des Vorsystems werden per SSIS in die Tabelle T_Import_Bewerber_täglich geladen

      Tabelle 1: Datenlieferung in T_Import_Bewerber_täglich vom 20.4.2016

    2. Alle neuen BewerberIDs, die noch nicht in der Historisierungstabelle T_D_Bewerber_Archiv enthalten sind, werden hinzugefügt. Dabei bekommen die Kennzahlen Anzahl_neue_Bewerber und Anzahl_Bewerber_Stichtag
      jeweils den Wert 1.

      Tabelle 2: Importergebnis neuer Bewerber in die Archivtabelle T_D_Bewerber_Archiv

    3. Alle Bewerber, die bereits in der Archivtabelle enthalten sind, aber einen anderen Status haben (im Beispiel ist der Bewerberstatus jetzt 2, vorher 1), müssen ebenfalls eingetragen werden. Weil sie vorher bereits enthalten waren (BewerberID 4711), wird die Kennzahl Anzahl_neue_Bewerber mit 0 importiert, die Kennzahl Anzahl_Bewerber_Stichtag mit 1.

      Tabelle 3: Datenlieferung in T_Import_Bewerber_täglich vom 21.4.2016

      Tabelle 4: Neu hinzugefügter Eintrag in Archivtabelle T_D_Bewerber_Archiv

    4. Der Blick auf die Archivtabelle zeigt, dass sich Bewerber 4711 am 1.4.16 sowohl im Bewerberstatus 1 als auch im Bewerberstatus 2 befindet. In Wirklichkeit ist der Bewerber allerdings aus Bewerberstatus 1 ausgetreten und befindet sich nur noch in Bewerberstatus 2. Deshalb muss der vorherige Eintrag ausgebucht werden. Dazu wird folgender neue Eintrag in die Archivtabelle geschrieben:

      Tabelle 5: Ausbuchungsvorgang in T_D_Bewerber_Archiv

Die Modellierung der Kennzahlen im Modeler erfolgte bei Anzahl_neue_Bewerber als Summenkennzahl und bei der Stichtagskennzahl als „LastNonEmpty“. So ist gewährleistet, dass eine Auswertung des Bewerbers 4711 bis zum 20.04.2016 mit seinen bis dahin geltenden Eigenschaften gewertet wird.

Die Prozedur, die die Historie erstellt, läuft nächtlich im P_Sys_Preprocess. Um zu vermeiden, dass mehrfache Ein- oder Ausbuchungen an einem Tag passieren, werden in der Prozedur zu Beginn alle Einträge mit heutigem Registrierungsdatum gelöscht. So kann die Prozedur bei Bedarf auch mehrmals täglich angestoßen werden und ist immer noch konsistent.

Und so sieht sie in T-SQL aus: