# Die generierte Pipeline (/docs/de/indicator-apps/pipeline) Jede Indikator-App trägt eine **Pipeline**, die Ovidens aus der Konfiguration der App erzeugt. Sie bauen sie nicht und Sie können sie nicht bearbeiten - sie wird neu erzeugt, sobald Sie die Struktur der App ändern - aber Sie können sie vollständig lesen, und genau darum geht es. Öffnen Sie den Editor und wählen Sie den Reiter **Pipeline** (oder drücken Sie P). ## Was Sie sehen [#was-sie-sehen] Die Pipeline hat drei Arten von Knoten. * **Relationen** sind Tabellen und keine Anweisungen. Jede trägt einen Teil der Konfiguration der App als Zeilen: ihre Indikatoren und deren Intervall, die Dimensionen, nach denen sie erfasst werden, jedes Element jeder Dimension, ihre Regeln und die dagegen erfassten Werte. * **Ihre Datenpunkte** sind je ein eigener Knoten - ein Schritt, benannt nach dem Datenpunkt, der genau die für ihn erfassten Zellen trägt. * **Engine-Schritte** sind einzelne SQL-Anweisungen über den Tabellen vor ihnen. Einige sind die Grundlagen der Plattform - der Periodenkalender, der Elementbaum der Dimensionen, die Erfassungselemente, die Befunde zu gestrandeten Daten. Die übrigen sind **je ein Schritt pro konfiguriertem Objekt**: einer je Berechnung eines Formel-Datenpunkts, einer je Satz Wertregeln eines Datenpunkts, einer je Konsistenzprüfung, einer je bedingter Gruppe. Jeder ist eine einzelne Anweisung, die Sie vollständig lesen können. Klicken Sie auf einen Knoten, um ihn zu lesen. ## Ihre Datenpunkte, je ein Schritt [#ihre-datenpunkte-je-ein-schritt] Jeder Datenpunkt, den Sie **erfassen** - eine Zahl, ein Text, ein Ja/Nein oder eine Einfachauswahl - hat einen eigenen Schritt. Öffnen Sie ihn, und Sie sehen die Zellen genau dieses Datenpunkts und sonst nichts: die Periode, für die sie erfasst wurden, je eine Spalte für jede Dimension, nach der Sie diesen Datenpunkt erfassen, und den Wert. **Jede Dimensionsspalte trägt den Namen Ihrer Dimension.** Darunter wird jede Zelle der App mit einer Adresse gespeichert, die sagt, zu welcher Dimension jedes ihrer Elemente gehört - `region` heißt also in der gespeicherten Zelle, in diesem Schritt und in allem, was Sie dagegen schreiben, dasselbe. Diese Schritte packen diese Adresse in je eine Spalte pro Dimension aus, in der Reihenfolge, in der Sie sie zugeordnet haben. Genau das macht auch das SQL erst lesenswert: eine Anweisung, die gegen `region` geschrieben ist, meint morgen noch `region`. **Ein Datenpunkt kann nach so vielen Dimensionen erfasst werden, wie Ihr Arbeitsbereich zulässt.** Darunter gibt es keine eigene Speichergrenze - die einzige Obergrenze ist die, die die Einstellungen Ihres Arbeitsbereichs nennen. Drei Spalten kommen von Ovidens und nicht von Ihnen; sie beginnen mit einem Unterstrich und können deshalb nie mit einer Ihrer eigenen Dimensionen kollidieren: `_period_type` (das Intervall), `_period_start` (welche Periode) und `_value` (der erfasste Wert selbst). Eine Dimension, die Sie `value` nennen, ist völlig zulässig und bekommt eine Spalte `value`, direkt neben `_value`. Zwei Arten von Datenpunkt haben hier keinen Schritt, jede aus eigenem Grund. Ein **Formel**-Datenpunkt hat überhaupt keine erfassten Zellen - seine Werte kommen aus seinem eigenen Engine-Schritt, der die von Ihnen konfigurierte Berechnung trägt. Der gespeicherte Wert eines **Datei**-Datenpunkts ist ein Verweis auf die hochgeladene Datei und kein Wert, den eine Ergebnistabelle tragen könnte; die Dateien selbst bleiben am Datenpunkt, wo Sie sie hochgeladen haben. Einen dieser Schritte zu lesen ist günstig: Er liest Ihre erfassten Zellen direkt, statt die ganze Engine auszuführen - das Öffnen der Daten eines Datenpunkts geht also auch in einer großen App schnell. **Jeder Knoten öffnet sich so, wie sich ein Knoten in einer Analyse-App öffnet** - dieselbe Ansicht, gleich gezeichnet, bis zum letzten Bedienelement: ein Reiter **Konfiguration** und ein Reiter **Daten**, der die Zeilen dieses Knotens in der gewohnten Tabelle zeigt. Nichts davon ist bearbeitbar - die Pipeline gehört Ovidens, nicht Ihnen - aber alles, was die Engine liest, und alles, was jeder ihrer Schritte erzeugt hat, liegt vor Ihnen. Zeilen werden beim Scrollen seitenweise gelesen, und Sie können sie sortieren, filtern und durchsuchen wie jede andere Tabelle; nichts wird weggelassen und nichts zusammengefasst. Unterschiedlich ist der Reiter Konfiguration. Eine **Relation** benennt, welchen Teil der App-Konfiguration sie trägt. Ein **Engine-Schritt** zeigt seine Anweisung **vollständig** - keine Zusammenfassung und keinen Ausschnitt - zusammen mit der Liste der Tabellen, die er liest, sodass Sie lesen können, was die Zeilen im Reiter daneben erzeugt hat. **Die Pipeline gehört Ovidens, ganz.** Kein Schritt lässt sich bearbeiten, übergeben oder übernehmen - weder in diesem Editor noch anderswo. Wenn sich mit den Bausteinen nicht ausdrücken lässt, was Sie brauchen, lesen Sie die Daten mit einem Knoten [Indikator-Daten](../analytical-apps/pipeline/indicator-data.mdx) in eine **Analyse-App**: Die hat einen echten SQL-Editor mit Vorschau und typisierten Ausgabespalten, und ihre Anweisungen gehören Ihnen. **Diese Pipeline ist kein Bild davon, wie Ihre App berechnet wird - sie ist es, was sie berechnet.** Jede Zahl, die Ihre App zeigt, kommt aus diesen Schritten: der Wert in der Zelle eines Formel-Datenpunkts, das Bestehen oder Scheitern einer Wertregel und einer Konsistenzprüfung, ob ein bedingter Datenpunkt für eine Periode gilt. Öffnen Sie den eigenen Schritt eines Formel-Datenpunkts, und Sie lesen genau die Zahlen, die das Erfassungsraster Ihnen zeigt, an denselben Koordinaten; öffnen Sie einen Schritt darüber, und Sie lesen, woraus sie berechnet wurden. Dahinter steht keine zweite, private Berechnung. **Ein Objekt, eine Anweisung.** Eine Berechnung wird nicht zur Laufzeit interpretiert - sie wird beim Speichern einmal in SQL übersetzt, und diese Anweisung ist es, die läuft. Der Schritt, den Sie lesen können, IST also Ihre Berechnung, und dazwischen steht keine Engine, die sie anders lesen könnte. Deshalb erreicht Sie eine Ablehnung auch **beim Speichern** und nicht als Befund, den Sie suchen müssen. Eine Referenz auf einen Datenpunkt, den die App nicht führt, eine Erfassungsfrequenz, die nicht zusammengeht, eine Aufschlüsselung, die sich nicht ausrichten lässt, eine Berechnung, die sich selbst liest: jede wird schon beim Erzeugen der Anweisung abgelehnt, mit der Angabe, was nicht passte. Nichts Unstimmiges wird je geschrieben - es gibt deshalb keinen Befundschritt zum Nachschlagen, denn die Ablehnung geschah, bevor es überhaupt einen Schritt gab. ## Warum "Ausführen" bei einem Engine-Schritt ausgegraut ist [#warum-ausführen-bei-einem-engine-schritt-ausgegraut-ist] Das SQL eines Schritts liegt in demselben Editor, den ein SQL-Knoten einer Analyse-App verwendet, mit derselben Schaltfläche **Ausführen** darunter - und bei einem Engine-Schritt ist sie bewusst abgeschaltet, mit der Begründung daneben. Ein Engine-Schritt ist keine Abfrage auf Tabellen, die irgendwo darauf warten, gelesen zu werden. Er läuft als ein Teil der Auswertung dieser App, über Relationen, die nur für die Dauer dieser Auswertung aufgebaut werden und danach verschwinden - für einen einzelnen Lauf gibt es also nichts zu lesen. Was diese Anweisung erzeugt hat, steht im Reiter **Daten** daneben, und das ist eine Seite des echten Ergebnisses und keine Wiederholung davon. An den Anweisungen selbst ist nichts Ovidens-spezifisch: Es ist gewöhnliches SQL für [DuckDB](https://duckdb.org). Markieren Sie den Text im Editor, um eine Kopie in einen eigenen Editor zu übernehmen und ihn dort in Ruhe zu lesen. ## Wenn der Reiter leer ist [#wenn-der-reiter-leer-ist] Die Pipeline einer App wird aus ihrer Struktur erzeugt, und eine App, die es schon vor der Pipeline gab, trägt noch keine. Jede gespeicherte Änderung an ihrer Struktur erzeugt sie: legen Sie einen Datenpunkt, eine Dimension, eine Gruppe oder eine Konsistenzprüfung an oder bearbeiten Sie eine, und der Reiter füllt sich. Jede seither angelegte App trägt ihre Pipeline von Anfang an. ## Verwaiste Daten [#verwaiste-daten] Ein Wert wird zusammen mit der Struktur gespeichert, gegen die er erfasst wurde: welcher Indikator, welche Dimensionselemente und welches Erfassungsintervall. Ändern Sie diese Struktur danach, wandern die bereits erfassten Werte nicht mit - sie bleiben zurück, außerhalb des Rasters, das der Indikator jetzt anfordert, und werden von nichts mehr gelesen. Der Reiter Pipeline meldet sie, mit dem Indikator und der Anzahl betroffener Zeilen. | Was dort steht | Was passiert ist | Was zu tun ist | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | In einem Erfassungsintervall erfasst, das der Datenpunkt nicht mehr verwendet | Das Erfassungsintervall des Indikators wurde geändert, nachdem diese Werte eingegeben wurden | Das Intervall zurückstellen, um sie zu erreichen, oder sie löschen | | Gegen eine Dimension erfasst, die der Datenpunkt nicht mehr hat | Eine Dimension wurde dem Indikator entzogen, und diese Zeilen nennen weiterhin eines ihrer Elemente | Die Dimension erneut zuweisen oder die Zeilen löschen | | Erfasst, bevor eine Dimension hinzugefügt wurde | Eine Dimension wurde hinzugefügt, nachdem diese Werte eingegeben wurden, daher nennen sie dafür kein Element | Die Werte gegen die neue Dimension erneut erfassen oder sie löschen | | Gegen ein Element erfasst, das nicht mehr aktiv ist | Ein Dimensionselement wurde gelöscht oder deaktiviert, während Werte es noch nannten | Das Element wieder aktiv setzen oder die Zeilen löschen | | Gegen ein Element auf einer anderen Ebene der Hierarchie erfasst | Der Indikator erfasst die Dimension auf einer Ebene, und diese Zeilen nennen ein aktives Element darüber oder darunter - meist, weil die Erfassungsebene nach der Eingabe geändert wurde | Den Indikator wieder auf dieser Ebene erfassen oder die Zeilen löschen | Wenn es nichts zu melden gibt, sagt der Reiter das. Konnte die Prüfung nicht ausgeführt werden - die Plattform war ausgelastet, oder Ihr Arbeitsbereich hat sein Rechenkontingent für den Monat aufgebraucht - sagt er **das** stattdessen, statt ein sauberes Ergebnis über Daten zu melden, die er nicht gelesen hat. **Die Prüfung wird bei jedem Öffnen des Reiters Pipeline neu gestellt**, es gibt also keine Schaltfläche zum Aktualisieren. Solange der Reiter offen ist, ist nichts erreichbar, was die Antwort ändern könnte: Werte werden im Erfassungsraster eingegeben und die Struktur auf den anderen Reitern bearbeitet - hierher zurückzukommen ist also genau das, was eine frische Antwort holt. **Einen dieser Werte löschen.** Wo der Wert noch eine Zelle im Erfassungsraster hat - meist nach einer geänderten Erfassungsebene oder einem geänderten Element - leeren Sie die Zelle und speichern, genau wie bei jeder anderen Korrektur. Das geht auch dann, wenn das Eintragen eines NEUEN Werts an derselben Stelle abgelehnt wird: Löschen ist immer erlaubt, denn genau so handeln Sie auf diese Liste hin. Die Zelle liest sich danach als leer, statt aus dem Raster zu verschwinden. ## Was Rechenleistung braucht, und was ohne sie passiert [#was-rechenleistung-braucht-und-was-ohne-sie-passiert] Weil die Pipeline es ist, was die App berechnet, verbrauchen sowohl das Lesen als auch das Ändern das Rechenkontingent Ihres Arbeitsbereichs. Ein Arbeitsbereich, der es aufgebraucht hat (oder eine plattformweite Pause), sagt das - statt eine Antwort zu geben, die er nicht berechnet hat. * **Der Daten-Reiter eines Schritts** führt die Engine für diesen Schritt aus. Die Zeilen einer **Relation** zu lesen nicht - eine Relation ist Ihre eigene Konfiguration, ihre Spalten und Zeilen sind kostenlos. * **Die Struktur zu ändern** braucht **keine**. Die Pipeline wird allein aus Ihrer Konfiguration neu gebaut, und eine Berechnung wird geprüft, indem die Anweisung dafür erzeugt wird - beides geschieht in Ovidens selbst. Ein Datenpunkt, eine Dimension, eine Gruppe oder eine Prüfung lässt sich also auch dann speichern, wenn keine Rechenleistung verfügbar ist, samt einer Berechnung. Was währenddessen nicht geht, ist *die Ergebnisse zu lesen*. * **Einen Wert einzugeben** prüft die Regeln der App gegen Ihre Eingabe und braucht daher ebenfalls Rechenleistung. Das ist Absicht: einen Wert anzunehmen, den die Plattform nicht prüfen konnte, ist schlechter, als Sie zu bitten, später wiederzukommen. Die Ablehnung benennt sich immer selbst und sagt, was zu tun ist; nichts wird auf einer halben Antwort gespeichert oder angezeigt. ## Warum eine Intervalländerung abgelehnt werden kann [#warum-eine-intervalländerung-abgelehnt-werden-kann] Weil ein Wert das Intervall trägt, in dem er erfasst wurde, würde eine Änderung des **Erfassungsintervalls** eines Indikators jeden bereits erfassten Wert zurücklassen. Wenn Sie den Indikator bearbeiten, lehnt Ovidens diese Änderung ab, solange solche Werte vorhanden sind, und nennt Ihnen die Anzahl der betroffenen Zeilen. Der Weg nach vorn: diese Werte zuerst löschen und danach das Intervall ändern. Eine Option "trotzdem ändern" gibt es bewusst nicht - sie wäre eine Schaltfläche, deren einzige Wirkung stiller Datenverlust ist. **Für das Wiederherstellen einer früheren Version gilt diese Prüfung nicht.** Eine Wiederherstellung setzt die gesamte App zurück, Erfassungsintervalle eingeschlossen, und kann daher Werte zurücklassen, für die eine Bearbeitung abgelehnt worden wäre. Sie wird bewusst nicht blockiert - eine Rückkehr, die Sie nicht ausführen dürfen, ist ihrerseits eine Falle - stattdessen wird das Ergebnis gemeldet statt verhindert: prüfen Sie nach dem Wiederherstellen einer Version die Liste **Verwaiste Daten** weiter oben.