Datenstruktur

Datenbanken

Es gibt im Account von FIGO zwei Typen von Datenbanken:

  • "base" - beinhaltet in der Tabelle "core_users" alle Nutzer-Accounts. Die anderen Tabellen sind nicht in Verwendung
  • Projektdatenbanken - beinhalten alle Daten zu Ärzten, Besuchen, Rollenhierachie, Nutzerdaten, ...

Projektdaten

In den Projektdatenbanken gibt es folgende Tabellen (kann im Einzelfall abweichen):

  • core_adresses - Stammdaten der Ärtze (Namen, Titel, Anrede, ...)
  • core_additionalData - Projektdaten der Ärzte (diverse Klassifizierungen wie Fachrichtungen)
  • core_files - Da Dateien (z.B.: Druckansicht von Ärzten, Aktivitätsbericht, ...) außerhalb des Webroots generiert werden, befindet sich da die Auflösungstabelle für das Download-Gateway
  • core_houses - Standort- und Kontaktdaten von Praxen
  • core_landscapes - Gebietsstruktur, Postleitzahlen und Ortschaften werden darin erfasst und z.T. noch in Gebiete gruppiert
  • core_log - Eingabeprotokoll damit sich nachvollziehen lässt, welcher Nutzer welche Eingaben im System getätigt hat
  • core_masterperiod - in einigen Projekt kann man über die Projekteinstellungen (im Frontend) zeitliche Perioden für zusätzliche Statistiken festlegen - das sind dabei die Hauptzeiträume, die sich zusätzlich unterteilen lassen
  • core_nonprotocol - die erfassten Tagesberichte, also z.B.: Urlaub, Krankheit, ...
  • core_notes - Es können zu Ärzten Notizen angelegt werden
  • core_protocol - die dokumentierten Besuche
  • core_relations - die Auflösungstabelle (s.u.)
  • core_subperiod - die zusätzliche Unterteilung der Hauptzeiträume (core_masterperiod)
  • core_tours - Nutzer können Tourenpläne anlegen, in denen sie mehrere Ärzte ablegen
  • core_userData - Zusatzinformationen zu den Nutzern aus der "core_users", muss (inkl. Relation) vorhanden sein um sich einloggen zu können

Relationen

Anstatt mehrerer Auflösungstabellen verwenden wir nur eine und Verknüpfen die Daten anhand eines Schlüsselwortes (z.B.: user2userData).

  • user2userData - Nutzer (core_users) zu Nutzerdaten (core_userData)
  • user2user - Nutzer (core_users) zu Nutzer (core_users). Bildet die Hierachie im Projekt ab, es gilt immer rid1 (höhere Stufe) zu rid2 (niedrigere Stufe).
    • in der Regel folgt es in den System folgender Reihenfolge: Admin -> Projektleiter -> Innendienst -> Außendienst
  • user2tour - die angelegten Tourennpläne (core_toures) eines Nutzers
  • user2protocol - die angelegten Dokumentationen (core_protocol) eines Nutzers
  • user2nonprotocol - die angelegten Tagesberichte (core_nonprotocol) eines Nutzers
  • user2landscape - Zuordnung von Nutzern (core_users) zu Gebieten (core_landscapes)
  • user2file - die heruntergeladenen Dateien eines Nutzers (core_files)
  • user2address - neben den Gebieten werden die Ärzte (core_addresses) einem Nutzer auch noch direkt zugeordnet
  • tour2address - die zugeordneten Ärzte zu einem Tourenplan
  • protocol2address - der zugehörige Arzt (core_addresses) zu einer Besuchsdokumentation (core_protocol)
  • house2landscape - Standorte (core_houses) werden abhängig von ihrer PLZ/Ort zu einem Gebiet (core_landscapes) zugeordnet
  • address2house - die Zuordnung von Ärzten (core_addresses) zu einem (oder mehreren) Standorten, es gibt einen Hauptstandort (siehe xmldata der Relation) und keinen oder mehrere Nebenstandorte
  • address2additional - Verknüpfung von Arzt-Stammdaten (core_addresses) mit Arzt-Projektdaten (core_additionalData)