mirror of
https://github.com/fhswf/aki_prj23_transparenzregister.git
synced 2025-04-25 01:42:33 +02:00
Philipp Horstenkamp
7e05792634
Reworked the index.rst as requested in our meeting. Made drawio background transparent. Minor tweaks. --------- Co-authored-by: Tristan Nolde <tristan.nolde@yahoo.de>
102 lines
6.2 KiB
Markdown
102 lines
6.2 KiB
Markdown
# 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.
|
|
|
|
--<cite>vgl. [influxdata - What is time series data?](https://www.influxdata.com/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.
|
|
|
|
<cite>--
|
|
vgl. [TDengine - Characteristics of Time-Series Data](https://tdengine.com/tsdb/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](../data_and_metrics.md) 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
|
|
|
|
```{mermaid}
|
|
|
|
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 {
|
|
}
|
|
```
|