aki_prj23_transparenzregister/documentations/research/Timeseries/Overview.md

Timeseries (deutsch: Zeitreihen) im Kontext des Transparenzregisters Kapitalgesellschaften

Leitfragen

1. Was zeichnet Timeseries Daten aus?
2. Wie werden Timeseries effizient gespeichert?
3. Welche Daten sind für den vorstehenden Use Case relevant und wie werden diese möglichts optimal (gemäß Software Qualitätskriterien wie Skalierbarkeit u.ä.) modelliert?
4. Passt die Struktur und Handhabung von Timeseries Daten auf den Use Case?
5. Wo können die benötigten Daten abgerufen werden?
6. Wie könnte ein beispielhafter Datensatz (ggf. in Form eines Pandas DataFrames) aussehen?

Timeseries

Hinter Timeseries (oder Zeitreihen) verbergen sich Datenpunkte meistens numerischer Natur aber auch andere Datentypen sind möglich, die Werte einer Kennzahl oder Entität entlang der Zeit-Achse darstellen. Nennenswerte Beispiele sind die Herzfrequenz eines Menschen sowie Aktienkurse börsennotierter Unternehmen. Es wird generell zwischen Metriken (engl.: Metrics; bei regelmäßigem Intervall) und Ereignissen (engl.: Events; bei unregelmäßigen Intervallen) unterschieden.

--vgl. influxdata - What is time series data?

Einige zentrale Eigenschaften von Daten, die als Zeitreihen modelliert werden, sind:

1. Unveränderbarkeit (engl.: Immutability): Da Zeitreihen in der Regel in zeitlicher Reihenfolge aufgenommen werden, werden sie normalerweise lediglich an die bestehende Reihe angehangen und nachträglich nicht mehr angepasst. Der entscheidende Identifikator des Datensatzes besteht dabei aus dem Zeitstempel (engl.: Timestamp) sowie der zugeordneten Entität (z.B. einem Sensor). Andere Features, die als Primärschlüssel fungieren können, sind nicht vorgesehen.
2. Lebensdauer (engl.: Retention policy): Da Zeitreihen in hoher Frequenz geschrieben aber mit höherem Alter seltener gelesen werden, ist es üblich alte Daten zu löschen bzw. aggregiert zu speichern, um langfristig Speicher zu sparen.
3. Aggregation (engl.: Aggregation): In den meisten Use Cases werden nicht alle Daten gleichzeitig oder nur einzelne Datensätze, sondern Werte eines definierten Zeitraumes abgefragt und häufig aggregiert (z.B. als Summe oder Durchschnitt) zurückgegeben.
4. Hohes Schreib- zu Lese-Verhältnis (engl.: High write/read ratio): Timeseries Daten werden in der Regel in hoher Frequenz (kurzen Intervallen) geschrieben jedoch nur gelegentlich bzw. wie in Punkt 3 angemerkt aggregiert abgerufen, sodass schreibende Zugriffe zur Datenbank die lesenden an Volumen übertreffen.

-- vgl. TDengine - Characteristics of Time-Series Data

Modellierung relevanter Kennzahlen

Ist die Timeseries Modellierung für den Use Case geeignet?

Die im Rahmen der vorher durchgeführten Analyse von für den Use Case relevanten Unternehmenskennzahlen zeichnen sich durch ein Merkmal aus: sie basieren auf einer jährlich bis maximal jedes Quartal aufgestellten Kennzahl wie den Gewinn oder Umsatz des Unternehmens. Daraus resultiert eine für Zeitreihen geringe Datenfrequenz - üblich sind hier minütlich bis unter sekündlich geschriebene Daten.

Des Weiteren ist jeder Datensatz nicht nur an die Zeit-Achse, sondern eine weitere Entität wie eines Quartals oder Jahresabschluss gebunden. Dies spiegelt nicht nur in der Berechnung der Kennzahl für ein einzelnes Unternehmen, sondern auch den Vergleich zwischen Mehreren wieder: Hier ist es möglich, dass Unternehmen ihre Ergebnisse zu unterschiedlichen Zeiten aber den selben Ereignissen veröffentlichen. Immerhin ist es realistisch, dass ein Unternehmen seinen Jahresabschluss deutlich früher als ein anderes der Öffentlichkeit zur Verfügung stellt. So eine Abfrage ließe sich zwar durchaus über die Einführung einer zeitlichen Einschränkung filtern, jedoch ist auch hier die Verknüpfung zu einem Jahres- oder Quartalsabschluss von höherem Interesse.

In Folge dessen eignet sich eine zeitreihenbasierte Modellierung nicht für die zentralen Unternehmenskennzahlen.

Für die Speicherung und Verwaltung von Aktienkursen börsennotierter Unternehmen - folglich nicht aller Kapitalgesellschaften, die im Use Case behandelt werden - bietet sich der Einsatz einer Timeseries Datenbank jedoch durchaus an, da Daten hier nicht nur in sehr hoher Frequenz geschrieben, sondern auch im bekannten Muster abgefragt werden. Demzufolge mag sich eine Modellierung auf Basis der Polyglot persistence (Verwendung verschiedener Datenspeicher-Technologien) auf Gesamtsicht eignen, sodass Kennzahlen sowie Stammdaten von Unternehmen in einer relationalen DB gespeichert und abhängig ihrer Unternehmensform mit Aktienkursen aus einer Timeseries DB angereichert werden.

Dieser Ansatz wäre nicht nur für diese Anforderung lohnenswert, sondern kann auch die effiziente Speicherung der Unternehmensverflechtungen vereinfachen, da für diesen Anwendungszweck eine Graphen-Datenbank ins Spiel gebracht werden könnte, die die Relationen zwischen Unternehmen und Unternehmen leicht traversierbar speichert. Es ist daher auch abzuwägen, ob diese nicht auch die Aufgaben des relationalen Modells übernehmen könnte, um die Fülle anforderungsspezifischen DB Technologien zu reduzieren, um auch so die Komplexität des Gesamtsystems gering zu halten.

Um einen geeigneten Zugang zu den Daten von extern (z.B. der Datenvisualisierungs-Schicht in Form einer Web-App) zu ermöglichen, ist der Einsatz von GraphQL sinnvoll. Dies ermöglicht dem Client die gesamte Datenbasis zu durchforsten und den benötigten Datenbestand abzufragen. Der GraphQL Server kann dabei durch seine Resolver Struktur problemlos mehrere Datenquellen (siehe oben angesprochene Polyglot Persistence) kombinieren.

Überblick über Datenrelationen

erDiagram
    Kapitalgesellschaft ||--o{ Jahresabschluss : veroeffentlicht
    Wirtschaftspruefer ||--o{ Jahresabschluss : prueft
    Jahresabschluss ||--o{ Metriken : beinhaltet
    Kapitalgesellschaft ||--o{ Branche : operiert_in
    Person ||--o{ Vorstand : agiert_als
    Person ||--o{ Wirtschaftspruefer : agiert_als
    Vorstand ||--o{ Kapitalgesellschaft: leitet

    Kapitalgesellschaft {
    }
    Branche {
    }
    Jahresabschluss {
    }