10 INPUT "Geben Sie bitte Ihren Namen ein: ", A$
20 PRINT "Guten Tag, "; A$
30 INPUT "Wie viele Sterne möchten Sie"; S
35 S$ = ""
40 FOR I = 1 TO S
50 S$ = S$ + "*"
55 NEXT I
60 PRINT S$
70 INPUT "Möchten Sie noch mehr Sterne"; Q$
80 IF LEN(Q$) = 0 THEN GOTO 70
90 L$ = LEFT$(Q$, 1)
100 IF (L$ = "J") OR (L$ = "j") THEN GOTO 30
110 PRINT "Auf Wiedersehen";
120 FOR I = 1 TO 10
130 PRINT A$; " ";
140 NEXT I
150 PRINTSQL Cossacks
1984 — 2024
Ziel
Probleme
Meilensteine
1984: Karteikasten
Erste Form der Erfassung
Intensive Verwendung von Abkürzungen
Strukturen:
Stand (Adelig: Ja/Nein)
Grundbesitzer (Ja/Nein)
Dienstdaten
Probleme:
keine Auswertungen und Suche möglich
Zugriff nur über Person möglich
1986: Intermezzo - Programmierung mit BASIC
1. Sorry, von dem Programm sind leider keine Code-Zeilen mehr überliefert.
1987-1996: WordPerfect (1)
1987-1996: WordPerfect (2)
Strukturierte Personendaten im Kopf
Datums orientierte Darstellung der Karriere
Erweiterbar
Ohne Abkürzungen würde es unübersichtlich
Bemerkungen und Kommentare zur Person
Örtliche Register pro Rang möglich
Darstellung wie bei George Gayecki
Für jede Position steht eine Quellenangabe zur Verfügung
1 Zeile = 1 Eintrag
Erfassung auch der Gesandtschaften bzw. Teilnehmer von Gesandtschaften
Ab 1997: LAMP
seit 1997: Architektur
Figure 1. LAMP Architektur
Seit 1997: Konsequenzen
1997-2016: PHP4
1997-2016: GUI
Hier ein paar Beispiele der ersten Version der "SQL Cossacks"-Webseite (Version 0.75 vom 12.12.2015).
|
|
|
|
2017: Migration nach PHP7
Mehrsprachigkeit
Mehrsprachigkeit (Deutsch, Englisch, Ukrainisch und Russisch)
 | Die russische Version wurde am 21.02.2022 in Reaktion auf die Rede von Vladimir Putin, in der er der Ukraine jegliche kulturelle und nationale Eigenständigkeit absprach, wieder abgestellt. Russische Nutzer sollten die ukrainische Version nutzen. Vielleicht fördert dies ein tieferes Verständnis für die sprachliche und kulturelle Eigenständigkeit des Nachbarn! |
Datenbestand
Datenmodell
Der eigentliche Zweck dieses Foliensatzes ist, eine(n) Dritte(n) an die grundlegenden Strukturen der SQL-Cossacks-Webseite heranzuführen.
Wie alles in der Anwendung: Das Datenmodell ist work-in-progress !
Kern der Anwendung ist stets die Person bzw. der Dienstdatensatz. Es gäbe vielleicht noch andere Ansätze, aber so tickt SQL-Cossacks eben.
Organisation und Beziehungen sind hybrid durch Relationen und Kreuztabellen realisiert.
Sie sind damit erweiterbar, konfigurierbar und "flexibel"
Relevante Daten sind möglichst in der Datenbank vorzuhalten.
Ursprünglich war die Datenbank "einsprachig". Die Herstellung einer durchgängigen Mehrsprachigkeit ist noch in Arbeit.
 | Wieviel Komplexität will man zulassen ? KIS (Keep-it-simple) vereinfacht - verbaut aber auch Wege ins Detail. |
Erkenntnisse
Zentrale Datenobjekte
Basisobjekte sind cossack, military_position und legate - und damit jeweils die Person.
"Gesandtschaften" und "Organisationen" sowie Allokationen sind "hybrid" abgebildet:
Erst das Zusammenspiel mehrerer Tabellen ergibt die Organisation oder Gesandtschaft,
U.U. müssen lokale und organisatorische Ebenen synchronisiert werden,
Bei Gesandtschaften werden über cross references Start und Ziel abgebildet.
cossack (1) 
"Kosak" ist Kern und Ausgangspunkt für alle Daten in der Anwendung.
Die ID ist systemweit eindeutig.
Namen:
Um Kosaken per Namen eindeutig zu indentifizieren, werden modernisierte Einheitsnamen verwendet.[1]
Abweichende Schreibweisen von Namen in den Quellen finden in den Bewegungsdaten (military_positions) Berücksichtigung.
Für Nutzer aus der Ukraine kann ein Kosak auch über kyrillische Einheitsnamen gesucht werden.
Seit 2022 werden auch weibliche Kosaken in der Datenbank vorgehalten.
Geburts- und Todesdaten, - nur soweit bekannt.
"Region" ermöglicht, auch regionale Einzugsbereiche über den eigentlichen Heimatort hinaus zu verwalten.
1. Zur Anwendung kommt hier die in Deutschland übliche, wissenschaftliche Umschrift (щ = šč).
cossack (2)
cossack (3) Ende
military_position (1) 
1. ACHTUNG Fehlerquelle! Die hybride Einordnung in eine Organisationsstruktur in den Kreuztabellen, kann von der Zuordnung in diesen Datensätzen abweichen!
military_position (2)
military_position (3)
legate (1) 
1. Achtung ! Da diese in den ersten Jahren nicht mitgeführt wurden, sind nicht für alle Datensätze die Schreibweisen erfasst worden.
legate (2)
legations
Die Tabelle legates hält Daten zu Boten- und Gesandtengängen "atomar" vor. Um ganze Gesandtschaften in SQL-Cossacks abbilden zu können, bündelt die Tabelle legations mehrere Gesandte zu einer Gruppe von Personen. Vorteile:
Mehrere Gesandte können als Gruppe gebündelt werden.
Das Ranking innerhalb dieser Gesandtschaft (z.B. "Kopf" der Gesandtschaft) kann abgebildet werden.
Alle Informationen zu einer Gesandtschaft sind gebündelt sichtbar und mischen sich nicht mit anderen Gesandtschaften.
Sonstige Tabellen (1)
Sonstige Tabellen (2)
Hierarchien und Kreuztabellen
Probleme der Hierarchisierung
Eltern-Kind-Beziehungen (1)
Die einfachste Form der Hierarchiebildung (Über- und Unterordnung) wird über eine gesonderte Spalte (parent_id) in den Tabellen realisiert. Dabei wird bei einer untergeordneten Instanz lediglich die id der übergeordneten in diesem Feld referenziert. Solche Zuordnungen müssen einfach sein, - sind aber auch recht statisch.
Um etwa Untereinheiten nach Waffengattung unterscheiden zu können, können die "Infanterie"-Einheiten gesondert erfasst und dem Hauptregiment zugeordnet werden:
Eltern-Kind-Beziehungen (2): Andere Beispiele
Ranghierarchie (1)
Das ursprüngliche Ziel war, Karrieren darstellen zu können. "Karrieren" sind "Auf-" und "Abstieg", d.h. die Einnahme eines Ranges entspricht einer Position auf einer Wertigkeitsskala. Unabhängig davon, dass eine starre Strukturierung immer problematisch ist, muss im System eine Struktur hinterlegt sein, die eine solche Über- und Unterordnung wiedergibt.
Um eine rudimentäre Ordnung herzustellen, musste zunächst eine Abstufung von Rängen auf jeder Führungsebene erfolgen. Diese Abstufung orientiert sich zur Zeit an den von den Kosakengruppen der ersten Hälfte des 17. Jh.s entwickelten Wertigkeiten.[1]
| Ein noch ungelöstes Problem ist daher die Abbildung von sich ändernden Wertigkeiten. So war der Rang des osavul in der Anfangszeit bedeutsamer als der des oboznyj. |
1. Siehe hierzu: Kumke, Carsten: Führer und Geführte bei den Zaporoger Kosaken, Berlin 1993, S. 251 ff.
Ranghierarchie (2): vertikal
Ranghierarchie (3): horizontal
Vereinfachte Darstellung !
Hauptanführer mit jeweils unterschiedlichen Rangbezeichnungen, aber auf Ebene 00
Stellvertreter werden in den gleichen Level eingeordnet.
Hierarchisierung wird auch genutzt, um Abfolge der Ränge ganzer Einheiten zu generieren.
Stellt man eine "1" den Level-Angaben vorweg, repräsentiert dies die Rangpalette auf Heeresebene.
Ranghierarchie (4)
1. Der košovyj otaman im Zaporižž’ja wird mit dem RK-Level 103 geführt; seine "Organisation" kann nur über weitere einschränkende Anweisungen generiert werden.
Organisation (1)
Organisation (2)
Organisation (3): sotni-kurinni-Beziehung
Die Zugehörigkeit von kurinni zu sotni ist über die Kreuztabelle sotkur realisiert. Sie ordnet eine kurinnja einfach einer oder mehrerer Hundertschaften zu.
Gründe:
kurinnja-Zugehörigkeiten werden im 17. Jh. höchstens im Rahmen von Registern genannt. Wenn unbekannt, wurden die Kosaken der kurinnja der Hundertschaftszentrale zugeordnet.
Da ein Wechsel einer kurinnja zwischen einzelnen Hundertschaften selten belegt ist, wurde die Zugehörigkeit nicht durch eine Zeitangabe differenziert.
Durch die sotni_kurinni-Beziehung können alle zu einer sotnja gehörigen kurinni gelistet werden; umgekehrt können zu einer kurinnja alle sotni aufgeführt werden, zu denen die kurinnja einmal gehört hat.
| Das Listing von Kosaken auf kurinnja-Ebene listet grundsätzlich alle Kosaken auf, die für den jeweiligen Ort belegt sind. Es gibt keine Substrukturen, die etwa Rücksicht auf Heeres- oder Polkzugehörigkeit nehmen. |
Organisation (4): Regimenter
Organisation (5): Über-/Unterordnung
1. Dieses Phänomen und der damit vorbundene Titel des sivers’kyj het’man-Dynastie der Zolotarenki in den 1650er Jahren scheint mir immer noch nicht ausreichend erforscht zu sein.
Organisation (6): polky - sotni-Beziehungen
Die Zuordnung von Hundertschaften zu Regimentern erfolgt analog zu den → sotni-kurinni-Beziehungen mittels der Kreuztabelle polksot.
Im Unterschied zu der statischen kurinni-Beziehung wurde polksot-Zuordnung jedoch durch Zeitraum-Informationen dynamisiert. Auf diese Weise können temporäre Reorganisationen und Zwischenzustände sehr gut abgebildet werden.
Das folgende Beispiel zeigt, dass die sotnja Bilocerkivka (ID 49) mehrfach zwischen den Regimentern Poltava (ID 47), Kremenčuk (ID 27) und Myrhorod (ID 33) gewechselt ist.
Gesandte und Kuriere
Kosaken haben auf allen Ebenen mit allen Ebenen inländischer und ausländischer Obrigkeiten kommuniziert.
Bloße Start-Ziel-Definitionen reichen deshalb nicht aus, wenn
sowohl die Hierarchie-Ebene des Ziels (Zar von Moskau, nachgeordneter Verwalter in Putivl')
als auch die Hierarchie-Ebene des Starts (siehe die intensiven autonomen Kontakte zwischen allen Ebenen der Kosaken mit russischen Instanzen)
als auch der innerkosakische Informationsaustausch auf verschiedenen Ebenen
variieren können.
Das alles muss nicht nur implementiert, es muss auch sichergestellt werden, dass bei der Eingabe der Daten Transparenz für den Anwender gewahrt bleibt.
| Die zur Zeit implementierte Lösung deckt die Anforderungen zwar ab, - sie ist aber m.E. nicht besonders transparent. Spätere Änderungen/Vereinfachungen sind nicht ausgeschlossen. |
Implementierung
Start-/Zieldefinition
Die folgende (vereinfachende) Darstellung gibt die Beziehungen nochmals wieder:
Über- und Unterordnung
1. Gemeint ist hier, dass etwa zwischen dem Gesandschaftsführern und seinem zugehörigen Tross unterschieden werden kann.
Laravel / PHP-Framework
Hilfestellungen
Offene Punkte
Es ist schon öfter darauf hingewiesen worden, dass die Anwendung auch nach so langer Zeit
weder vollendet worden ist
noch alle Probleme behoben bzw. geklärt worden sind.
Bei allen Problemen darf nicht vergessen werden:
| Es besteht die Gefahr, dem Nutzer eine Datengenauigkeit vorzuspiegeln, die es nicht gibt ! An bestimmten Stellen stösst man immer auf Unschärfen, die nicht zu vermeiden sind. |
Hier eine Aufstellung.
Offene Punkte (1): Lokalisierung von Kosaken
Sofern Quellen verarbeitet werden, bei denen es sich nicht um Register, Eideslisten oder Konskriptionsverzeichnisse handelt, ist eine Lokalisierung eines Kosaken bis hinunter zur kurinnja häufig nicht möglich. In diesen Fällen sind zwei verschiedene, leider nicht konsequent angewandte Zuordnungsverfahren vorgenommen worden:
Zuordnung immer zum Zentrum der nächst höheren bekannten Einheit → Ist nur das Regiment bekannt, dann wird der Kosak auch der sotnja und der kurinnja des Regimentszentrums zugeordnet (Polk: Poltava, Sotnja: Poltava, Kurinnja: Poltava).
Ähnliches Verfahren, nur dass zwischen eindeutiger Zuordnung und mutmaßlicher Zuordnung unterschieden wird, indem für jeden Ort ein eigener Datensatz verwendet wird → Regiment: Poltava, Sotnja: [Poltava], Kurinnja: [Poltava]
| Es gibt in diesen Feldern nie den Wert NULL ! |
Mit beiden Varianten bin ich nicht glücklich. Ich neige zur Zeit dazu, es bei der ersten Variante zu belassen. Zumal die zweite Variante nicht sauber implementiert ist.
Offene Punkte (2): Irreguläre Einheiten
Die Abbildung irregulärer Einheiten erfolgt zur Zeit damit, dass sie - irgendwie - in das vorgegebene Organisationsschema eingebettet werden. Erkennbar wird dies nur an den Bezeichnungen und insgesamt schlecht ausgeprägten oder nicht stimmigen Organisationsstruktur.
Solche irregulären Einheiten sind etwa:
Hoftruppen / Angehörige privater Armeen
Aufständische Einheiten mehr bäuerlichen Charakters
Söldner im Dienste der Kosaken (v.a. seit den 1660er Jahren)
Ganze Verbände während der Zeit der Rujina
 | Auch die "Umsetzbarkeit" der implementierten "Organisation" darf im übrigen nicht soweit übertrieben werden, dass man - wie noch heute vereinzelt in der Literatur sehen kann - von XXX_ZARUBA sprechen könnte. |