Häufigkeiten und Kreuztabellen aus zweidimensionalem Array errechnen

[jobo]

Offenbar gibt es sehr unterschiedliche Vorstellungen zum Begriff, Kreuztabellen, etc. Was mensch72 vorschlägt, habe ich entweder nicht verstanden oder geht über die Anforderung hinaus?

Vielleicht kann der TE nun anhand seiner Beschreibung (Jahr 1) mal darstellen, wie er die Kreuztabelle nun darstellt. Alle Spalten, ein paar Beispieldaten.
Außerdem: Gibt es irgendwelche Notwendigkeiten, verschiedene Jahrgangsdaten zu verknüpfen?
Welche Rolle spielt die Reihenfolge v01-v05? Ist das nicht beliebig, also am Ende eine reine Darstellungs- oder Labelfrage?

[Blup]

Die Ausgangsdaten sind also in einer Tabelle enthalten, deren Feldnamen und Feldreihenfolge sich von Jahr zu Jahr ändern.
Dabei können Felder entfallen oder neue hinzukommen.

Eine Software soll natürlich im Kern nicht verändert werden.
Aber was ist bei dir der Kern? Dazu ein Beispiel.

Es soll eine Ergebnismenge aus einer Menge von Feldern berechnet werden, deren Inhalt für den Anwendungsfall fest definiert ist.
Diese Vorschrift soll sich nicht ändern. Es muss dafür gesorgt werden, das diese Felder immer verfügbar sind.
Eine Möglichkeit wäre die Tabelle durch eine View zu kapseln, die du Jahr für Jahr anpasst.
Innerhalb der View können Hilfstabellen oder Datenbankprozeduren benutzt werden, um die Daten aufzubereiten.

Code:

CREATE VIEW V_EINGANGSDATEN(
    SPALTE1,
    SPALTE2,
    SPALTE3)
AS
select v01 spalte1, v03 spalte2, v05b + v05a spalte3
from   t_eingangsdaten
where  (v02 = 0)
;

select spalte1, spalte2, spalte3 from v_eingangsdaten;

Alle Abfragen richten sich nur an die View, Änderungen sind dann nur an einer Stelle notwendig.

[Benmik]

Ich finde es jetzt auch schwer, einen Weg von mensch72s Vorschlägen zu einer praktischen Implementierung zu finden.
Einen VIEW kannte ich noch nicht. Er würde aber nicht das Problem der wechselnden Feld- und Wertbezeichnungen lösen, die dem Anwender angezeigt werden müssen.

Nochmal: Auf die Struktur der DB habe ich keinen Einfluss. Wenn V01 im ersten Jahr das Alter ist, im zweiten die Größe und im dritten die PLZ, dann ist das so. Der Anwender hat 1 - 3 Klapplisten, in die in der Reihenfolge des Auftritts in der DB alle Felder (mit ihren Feldbezeichnungen) eingetragen sind. Aus diesen Listen wählt er dann die Felder für die einfache Häufigkeit oder eine Kreuztabelle mit 2 oder 3 Feldern aus. Das Programm muss dann immer wissen, ob V01 im gegebenen Jahr als "Alter", "Größe" oder "PLZ" als erster Eintrag in der Klappliste erscheinen muss.

Die von mir im stillen Hirnkästlein ersonnene Lösung, die noch der Bestätigung durch eine praktische Implementierung harrt, sieht so aus:

1. Für das erste Jahr erstelle ich eine Enumeration, also ungefähr so: type TFeldpos = (fAlter01,fGröße01,fGeschlecht01,fPLZ01,fPersImHHE01,fPersImHHK01) .

2. Ich definiere eine Klasse TFeld mit allen Informationen, die ich über ein Feld brauche; also z.B. die laufende Nummer (die Enumeration), Typ, Bezeichnung, mögliche Werte, Wertbezeichungen und Weiteres.

3. Ich definiere eine hardkodierte Liste type TFeldListe = class(TObjectList<TFeld>) , in die die bisher vorhandenen 6 Felder aufnommen werden. Dabei erstelle ich die 6 bisher vorhandenen TFeld .

4. Zur Laufzeit erstelle ich eine weitere Liste type TDBListe = class(TObjectList<TFeld>) und füge per Add die Objekte der FeldListe hinzu. Im ersten Jahr ist das natürlich einfach.

5. Im Betrieb gilt: Listindex Klappliste = Pos Feld in DB = Pos Feldobjekt in der DBListe. Damit sollte die Handhabung leicht funktionieren. An die Eigenschaften des Feldes in der DBListe komme ich über FeldListe[DBListe[xx].LfdNr] (= TFeldPos ) heran.

6. Die Berechnung der Altersgruppen läuft über den Eintrag in der DBListe, der FeldListe[fAlter01] entspricht.

Jetzt kommt das zweite Jahr und es wird spannend.

Das Feld "Geschlecht" hat sich geändert. An die 7. Stelle der Enumeration kommt jetzt fGeschlecht02 , der FeldListe wird ein 7. Objekt hinzugefügt. Die Erstellung der DBListe beginnt mit DBListe.Add(FeldListe[fGeschlecht02]); .

In allen folgenden Jahren geht es analog. Für jede neue oder geänderte Variable wird ein neues TFeld erstellt und an FeldListe angehängt. Die jährliche Arbeit besteht dann darin, eine neue, jahresspezifische DBListe zu erstellen. Wenn sich jetzt aber zwischen V04 und V82 nichts ändert, dann kann ich die Add von V05 - V81 einfach kopieren. Wird ein geändertes Feld für eine Berechnung verwendet, dann kommt eben eine If..Then - Konstruktion zum Einsatz.

In Betrachtung dessen, was sich in den letzten über 10 Jahren wie oft und in welcher Form geändert hat, sagt mein Hirnkästlein, das müsste funktionieren. Was Delphi dazu sagt, das könnte leider was ganz anderes sein...

[Blup]

Alles was sich ändert würde ich aus einer Konfigurationsdatei oder einer Datenbank lesen.
Auch mögliche Werte, Wertbezeichungen, usw.
Selbst welche Ergebnisfelder es gibt und die zugehörige Berechnungsvorschrift kann man dort ablegen.

Vieleicht ist die Beschreibung der IDEA-Schnittstelle in dem Zusammenhang interessant:
https://audicon.net/downloads/330

[Benmik]

Das ist wirklich interessant. Das gibt mir die vermisste Ahnung davon, wie ein Profi das lösen würde. Auf eine XML-basierte Beschreibungsdatei hätte ich auch kommen können - heute kann man nicht mehr pinkeln gehen, ohne den Vorgang standardisiert in XML zu dokumentieren.

Im konkreten Fall ist mir der Aufwand allerdings zu hoch. Und standardisiert arbeiten muss ich auch nicht, da nach mir keiner den Code weiterführen wird.

Außerdem meine ich, dass meine selbstgestrickte Lösung der Profilösung in Grundsätzen eigentlich ziemlich gleich ist. Die TFeldliste ist im Grunde genommen eine Datenbank, die hierarchisch gegliedert Informationen enthält, die in einem einheitlichen Format abgelegt sind. Ob die Datenorganisation jetzt in XML oder in einem Delphi-Format erfolgt, macht das praktisch einen Unterschied?

Aber vielen Dank für den Hinweis!

[Benmik]

Ich würde gern zum (vorläufigen) Abschluss die Information geben, dass das hier in #9 vorgestellte Konzept tatsächlich funktioniert. Es ist zudem auch noch schneller als der Gang über die Datenbankkomponente.

Für den Start ist es allerdings eine Wahnsinnsarbeit, die ganzen Feldbeschreibungen (allein die Datenbank von 2017 hat 181 Felder, ohne die errechneten Zusatzfelder) zu erstellen. Dazu kommen noch die Anpassungen von etwa 12 anderen Auswertjahren; aber erste Versuche haben gezeigt, dass das Hinzufügen eines Jahres bei vorhandenem Grundstock nur einen Bruchteil der Arbeit kostet, die ich sonst jedes Jahr immer hatte.