Sollen lange und/oder komplex strukturierte Codepläne sortiert werden, sollte die hierarchische Struktur der Codes, d.h. die Einteilung in OVER-(OVER-)CODES erhalten bleiben.
Dafür stellt GESStabs zwei Tabellenformate (TABLEFORMAT) bereit:
1.AUTOSORTTREE: kleinteilige Baum-orientierte Methode
2.AUTOOVERSORT: Sortierung der Gesamttabelle mit mehreren Häufigkeiten
AUTOSORTTREE ersetzt als verbesserte Neuimplementierung AUTOOVERSORT (siehe dafür Abgelöste Befehle).
Bestehende Skripte, in denen AUTOOVERSORT verwendet wird, werden unverändert nach der AUTOOVERSORT-Methode abgearbeitet.
Die beiden Methoden sind nicht kompatibel; daraus ergibt sich, dass die Verwendung beider TABLEFORMATs zu einem Fehlerabbruch (Syntaxfehler 744) führt.
Tabellenformat zur hierarchischen Sortierung von Tabellen.
Syntax:
TABLEFORMAT +/- AUTOSORTTREE;
Im Folgenden werden
•die grundlegenden Begrifflichkeiten geklärt,
•typische Code-Strukturen in Tabellen beschrieben,
•manuelle Einstellungsmöglichkeiten für Einzellabels sowie
•die optische Kennzeichnung zusammenhangsloser Labels erläutert,
•die gezielte Positionierung von Overcodes ohne Obermenge beschrieben und
•Anwendungsbeispiele für AUTOSORTTREE gegeben.
In der AUTOSORTTREE-Methode spielen die Begriffe 'Teilmenge' und 'Obermenge' eine wichtige Rolle: Wenn OVERCODE A alle Codes eines anderen OVERCODE B enthält, A und B aber nicht identisch sind, dann wird B als eine echte Teilmenge von A betrachtet, Für das vorliegende Problem der Sortierung bedeutet das, dass A dann in der Hierarchie B übergeordnet ist, A ist eine Obermenge von B.
Tipp: Verwendet man im Skript die syntaktischen Konstrukte OVERCODE/OVEROVERCODE, dann ist automatisch sichergestellt, dass alle Overcodes, die in einem Ovrocercode benannt werden, echte Untermengen des Overovercodes sind.
Vor der Sortierung werden im ersten Schritt alle Overcodes daraufhin untersucht, ob sie Untermengen von anderen Overcodes darstellen. Die Overcodes werden in einen Baum sortiert, der die Eigenschaften Untermengen/Obermengen und die Zählergebnisse berücksichtigt.
Typische Code-Strukturen in Tabellen
Betrachtet man die zu sortierenden Tabellen unter der Perspektive der Hierarchie der Overcodes, sind mehrere typische Konstellationen erkennbar.
A.Es gibt einen Overcode, der die Obermenge der Codes aller übrigen Overcodes enthält. Dann gibt es einen Baum mit einer Wurzel, von der alle Elemente abhängen.
B.Die Tabelle besteht aus mehreren Teilbäumen nebeneinander. Der einfachste Fall sind mehrere Overcodes, die jeweils disjunkte Codes enthalten: die Hierarchie ist dann sehr flach, es gibt nur Codes unter Overcodes. Relativ beliebt sind auch Tabellen, deren Labels in zwei logisch nebeneinander stehenden Hierarchien angeordnet sind: die Menge aller positiven Nennungen und die Menge der negativen.
C.Die Tabelle enthält Codes, die überhaupt keinem Overcode zugeordnet sind, für die in der hierarchisch aufgebauten Tabelle ein Platz zu finden ist. Die Konvention ist, dass diese nach allen Overcodes/Codes am Ende der Tabelle ausgegeben werden.
Grundsätzlich ist es für den/die Tabellen-Leser/in am einfachsten nachvollziehbar, wenn die sortierte Struktur sich strikt aus der Hierarchie und den Zählergebnissen ergibt. Die Welt mit Kunden kennt aber oft andere Prioritäten und der/die Tabellierer/in muss dann händisch eingreifen.
Die Werkzeuge zur händischen Änderung der Sortierreihenfolge sind die Label-Eigenschaften BOTTOM und SORTCLASS:
Mittels der SORTCLASS als Eigenschaft von Codes und Overcodes kann man im Skript in die Reihenfolge von Objekten auf derselben Ebene eingreifen. Die Sortierung findet immer nur zwischen Objekten derselben Ebene statt. Oben wurde die Zuordnung der atomaren Codes zu dem direkt darüber liegenden Overcode erwähnt. Eine SORTCLASS kann die Positionierung nur innerhalb der Elemente der direkten Obermenge beeinflussen.
Auch mit der Label-Eigenschaft BOTTOM kann man die Position von Codes und Overcodes modifizieren. Deren Wirkung ist elementar: es wird lediglich die betroffene Zeile verschoben, und zwar zum Bottom, dem Ende der Tabelle.
Optische Kennzeichnung von Labels, die aus der Sortierung ausgeschlossen sind (z.B. aufgrund von NORANKING oder SORTCLASS).
Syntax:
RECHIPREFIX = "<Zeichenfolge>";
Die definierte Zeichenfolge wird dem/n betroffenen Labeltext/en in der Tabellenansicht automatisch vorangestellt.
Gezielte Positionierung von Overcodes, die keinem übergeordneten OverOvercode angehören.
Syntax:
OVERCODE "OCname" SORTPOSITION LINE <number>
OVERCODE "OCname 1" SORTPOSITION AFTER <OCname 2>
LINE positioniert den Overcode absolut an der angegebenen Zeilennummer in der Tabelle.
Mit AFTER kann relativ angegeben werden, nach welchem anderen Overcode der Overcode platziert werden soll.
... für die folgenden Beispiele ist die Variable 'myvar': VALUELABELS f1m = 1 "Code 1" 2 "Code 2" 3 "Code 3" 4 "Code 4" 5 "Code 5" 6 "Code 6" 7 "Code 7" 8 "Code 8" 9 "Code 9" 10 "Code 10" 11 "Code 11" 12 "Code 12" 13 "Code 13" 14 "Code 14" 15 "Code 15" 16 "Code 16" 17 "Code 17" 18 "Code 18" 19 "Code 19" 20 "Code 20" 98 "SONSTIGES" OVERCODE 01:10 "POSITIV 1-10" #oc OVERCODE 11:20 "NEGATIV 11-20" #oc OVERCODE 1:5 "OC 1-5" #oc OVERCODE 6:10 "OC 6-10" #oc OVERCODE 11:15 "OC 11-15" #oc OVERCODE 16:20 "OC 16-20" #oc ; Die OVERCODEs werden zur besseren Übersichtlichkeit in der Tabelle mit dem #expand #oc formatiert. Sie zerlegen die Tabelle in zwei Teilbäume, deren Wurzeln "POSITIV 1-10" und "NEGATIV 11-20" sind. |
Beispiel 1: Sortierung mit TableFormat AutoSortTree und RechiPreFix
TABLEFORMAT = -AUTOOVERSORT +AUTOSORTTREE; TABLE = 1 BY f1m SORT ABSOLUTE DESCEND; Das Resultat unterscheidet sich nicht von dem mit AUTOOVERSORT, die Tabelle sieht wenig überraschend so aus: Das Resultat unterscheidet sich kaum von dem mit AUTOOVERSORT. Der sichtbare Unterschied ist die Kennzeichnung des Codes 98 als ein verwaister Code, der nicht zugeordnet werden konnte, und mit einem RECHIPREFIX gekennzeichnet wird, der selbst festgelegt werden kann. Er kann beim Tabellieren benutzt werden, um bei unübersichtlichen OVERCODEs solche Effekte schneller zu finden. RECHIPREFIX = "----> ";
 Tabelle 1 Eine kurze Anmerkung zur Struktur der Tabelle: Alle übrigen Overcodes sind Untermengen des Gesamt-Overcodes 1:30. Die Tabelle (und alle folgenden bis einschließlich die in Beispiel 3) haben die Struktur A. |
Es gibt zwei Wege, die Position von OVERCODEs mit identischer Definitionsmenge festzulegen. Einmal den relativen mit SORTPOSITION AFTER, oder den absoluten mit der SORTPOSITION LINE. Wir geben "(OOC) Alle Nennungen" den Overcodenamen AN, und dem "(OOC) Alle Fälle" geben wir das Ziel SORTPOSITION AFTER AN. Damit machen wir aus diesen beiden OVERCODEs eine Kombination, die Zeile ohne SORTPOSITION steht weiter oben. Diese Methode funktioniert an allen Stellen der Tabelle. OVERCODE SUM AN 01:20 98 "(OOC) Alle Nennungen" #oc OVERCODE 01:20 98 c #oc SORTPOSITION AFTER AN OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc  Tabelle 2 Das 'Kochrezept' an dieser Stelle lautet: Wenn zwei OVERCODEs aufeinanderfolgend ausgegeben werden sollen, dann bekommt derjenige, der an erster Stelle stehen soll, einen Namen '<ocname>', und der andere wird mit der Anweisung SORTPOSITION AFTER <ocname> versehen. Wenn der Algorithmus zwei OVERCODEs mit derselben Definitionsmenge an Codes findet, muss entschieden werden, welcher der beiden in der Sortiermenge bleibt, und welcher für das spätere Einfügen 'beiseite gelegt' wird. Wenn bei diesem Vergleich einer der beiden OVERCODEs eine SORTPOSITION-Angabe enthält, wird dieser in den Einfüge-Baum verlagert. Das ist sinnvoll, denn dieser Overcode enthält die Information, wo er eingefügt werden soll. Der andere bleibt in der Sortierung, und steht damit in der Tabelle weiter oben. Bezogen auf das obige Beispiel: '(OOC) Alle Fälle' hat die Information SORTPOSITION AFTER AN und soll also hinter den OVERCODE mit diesem Namen ausgegeben werden. Der '(OOC) Alle Nennungen' verbleibt im Sortierbaum und steht damit vorn. Wenn ein OVERCODE eine SORTPOSITION AFTER <ocname> enthält, es aber keinen OVERCODE gibt, der diesen Namen hat, dann wird er als 'verwaister OVERCODE' am Ende der Tabelle erscheinen. Ein Overcode mit einem RECHIPREFIX ist also ein wichtiger Hinweis, die Namensverweise zu prüfen. Die Namen werden case-insentiv verglichen, 'AN' und 'an' gelten also als gleich. Dieses Spiel kann man, wenn man möchte, für weitere OVERCODEs in der Tabelle wiederholen, die nächste Tabelle enthält auch die Nennungen für NEGATIV und POSITIV, die Nennungen stehen jeweils vorn.
OVERCODE SUM AN 01:20 98 "(OOC) Alle Nennungen" #oc OVERCODE 01:20 98 "(OOC) Alle Fälle" #oc SORTPOSITION AFTER AN OVERCODE SUM NP 01:10 "Nennungen POSITIV 1-10" #oc OVERCODE SUM NN 11:20 "Nennungen NEGATIV 11-20" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc SORTPOSITION AFTER NP OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc SORTPOSITION AFTER NN OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc  Tabelle 3 Die Methode, die Position von OVERCODEs mit der Option AFTER zu bestimmen, ist die flexibelste, wenn man mehrere Brutto-Zusatzzeilen, die Nennungen, in der Tabelle positionieren will. Geht es nur um „Alle Nennungen“, ist es am bequemsten, diese auf die LINE 1 'festzunageln':
OVERCODE SUM 01:20 98 "(OOC) Alle Nennungen" #oc SORTPOSITION LINE 1 OVERCODE 01:20 98 "(OOC) Alle Fälle" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc
 Tabelle 4 Mit demselben Ergebnis könnte man auch „Alle Fälle“ auf LINE 2 schicken. |
Eine AUTOSORTTREE-Tabelle von einer Variablen ohne OVERCODEs ist für diesen Algorithmus schwer zu knacken; wenn es keine OVERCODEs gibt, können sie auch nicht hierarchisch sortiert werden. AUTOSORTTREE wird in diesem Fall einfach ignoriert.  Tabelle 5 |
Beispiel 4: Sortiereigenschaft Bottom
BOTTOM verschiebt nur die aufgeführten Zeilen, davon abhängige weitere Codes oder OVERCODEs bleiben unberührt. OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc BOTTOM OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc BOTTOM OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc  Tabelle 6 |
Beispiel 5: Sortiereigenschaft SortClass
Werden OVERCODEs mit einer SORTCLASS verschoben, wandern die abhängigen Zeilen mit. OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc sortclass 1 OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc sortclass 5 OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc  Tabelle 7
|
Beispiel 6: Codes ohne Overcodes
Nicht in OVERCODEs enthaltene Codes landen als verwaist am Ende der Tabelle und bekommen einen RECHIPREFIX. OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:4 "(OC) Positiv 1-4" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:13 "(OC) Negativ 11-13" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc
 Tabelle 8
|
Beispiel 7: SORTCLASS und BOTTOM im Vergleich
OVERCODE SUM 1:18 "SUMME der NENNUNGEN (Codes 1-18)" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:4 "(OC) Positiv 1-4" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:13 "(OC) Negativ 11-13" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc  Tabelle 9 Die Sortierung dieser Tabelle zu erklären ist nicht ganz einfach. Tatsächlich hat der Algorithmus die Tabelle in zwei Tabellen zerlegt, Es gibt zwei Wurzeln: NEGATIV 11-20 und Summe der Nennungen. Bei der Sortierung der Wurzeln spielt nach BOTTOM (hier irrelevant) der Pfad von der Wurzel zu den Blättern die wichtigste Rolle, nur wenn diese gleich sind können weitere Kriterien wie z.B. die Zellenbesetzung eine Rolle spielen. Dass der 'OOC NEGATIV 11-20' am Beginn der Tabelle steht und nicht die Summe der Nennungen, liegt am geringeren Gewicht der Zellenbesetzung gegenüber dem Sortierpfad. Man erkennt sofort, dass bei diesen OVERCODEs nicht alles nach Plan gelaufen ist; die Ausweisung der RECHIPREFIXES unten gibt auch schnell einen Hinweis, wo zu suchen ist. OVERCODE SUM 1:20 "SUMME der NENNUNGEN (Codes 1-20)" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc 1 "Code 1" 2 "Code 2" …. 18 "Code 18" 19 "Code 19" BOTTOM 20 "Code 20" 98 "SONSTIGES" ;  Tabelle 10 OVERCODE SUM 1:20 "SUMME der NENNUNGEN (Codes 1-20)" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc 1 "Code 1" 2 "Code 2" …… 18 "Code 18" 19 "Code 19" sortclass 1 20 "Code 20" 98 "SONSTIGES" ;  Tabelle 11 Eine SORTCLASS am Code beeinflusst nur die Sortierung zwischen den Codes auf derselben Baum-Ebene. SORTCLASS wird also deutlich anders behandelt als BOTTOM. OVERCODE SUM 1:20 98 "SUMME der NENNUNGEN (Codes 1-20 + 98)" #oc OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc
 Tabelle 12 Die Summe der Nennungen umfasst auch 'SONSTIGES', die Zeile wird trotzdem als verwaist behandelt und erhält einen RECHIPREFIX. OVERCODE 01:10 "(OOC) POSITIV 1-10" #oc OVERCODE 11:20 "(OOC) NEGATIV 11-20" #oc OVERCODE 1:5 "(OC) Positiv 1-5" #oc OVERCODE 6:10 "(OC) Positiv 6-10" #oc OVERCODE 11:15 "(OC) Negativ 11-15" #oc OVERCODE 16:20 "(OC) Negativ 16-20" #oc
 Tabelle 13 |