In diesem Schritt werden die zu untersuchenden Objekte, sprich die Zeilen der Datenmatrixde_niert. Als Grundlage hierfur liegt eine Datenbank von Filialen verschiedenerEinzelhandler vor, die keinen Anspruch auf Korrektheit, Vollstandigkeit oder Aktualitat erhebt. Die Datenbank in liegt als .sql-Datei vor und beinhaltet verschiedene DDLundDML-Statements (Data De_nition Language und Data Manipulation Language),mit deren Hilfe die Datenbank in anderen Kontexten eingebunden werden kann. Diein der Datei enthaltene Tabelle wird im Kontext der intermediaren Java-Applikationin eine lokale SQLite-Datenbank uberfuhrt4. Auf Basis dieser SQLite-Datenbankkonnen die Filialen dann uber SQL-Statements ge_ltert und an die jeweiligen Stellenim Programmcode ubermittelt werden, siehe auch Abbildung 6 und die zugehorigeErlauterung im vorangehenden Abschnitt.

Abb. 10: Uberblick der konstanten Textvariablen fur den Verbindungsaufbau zur SAP HANA Datenbank (Screenshot aus der Java-IDE “Eclipse”)

Der relevante Ausschnitt aus der vorliegenden Datenbank ist die Ubersicht vonFilialen der EDEKA-Gruppe, die 797 Markte umfasst und im Anhang nachgeschlagenwerden kann5. Wird diese Datenmenge um Datensatze mit fehlenden odermehrfach vorkommenden Koordinaten bereinigt, bleiben 595 Datensatze mit einemeindeutigen Koordinatenpaar ubrig. Dies ist zwar keine Ubersicht aller EDEKA Filialen in Deutschland6, allerdings sind die enthaltenen Filialen laut der enthaltenenPostleitzahlen deutschlandweit verteilt, somit wird dies fur eine erste Betrachtungund zur Uberprufung des Vorgehens ausreichen. Die vorliegende Datenbank beinhaltetursprunglich eine Reihe von Daten von Filialen verschiedener Einzelhandler, wie etwaStandort, O_nungszeiten und Adresse. Die einzig relevanten Daten sind fur dieseUntersuchung allerdings die Koordinaten von EDEKA-Filialen, daher werden bei demAbruf der Daten nur die Koordinaten berucksichtigt, sowie die Adressfelder der Filialezu einem komplementaren Identi_kator der Filiale verschmolzen und inkludiert, daszugehorige Statement mit dem concatenate-Operator jj ist in Abbildung 11 als Java-String zu sehen. Der Identi_kator dient lediglich zur einfachen Ruckverfolgung derDatensatze und dazu, die manuelle Kontrolle zu vereinfachen.

Abb. 11: SQL-Statement zum Abruf der Koordinaten und Konstruktion des Identi-kators einer Filiale aus der lokalen SQLite-Datenbank (Screenshot aus der Java-IDE “Eclipse”)

Nach der Aggregation des Identi_kators werden die Daten nochmals sorgfaltigbetrachtet und es stellt sich heraus, dass auch doppelte Identi_katoren (also Adressen)vorkommen, die allerdings unterschiedliche Koordinaten aufweisen. Jede Adresse sollallerdings durch exakt ein Koordinatenpaar identi_ziert werden, dementsprechendscheint es inkorrekte Datenscatze zu geben. Hier konnen nicht mehr Duplikate viaSQL-Statements aus der Datenmenge geloscht werden, sondern es muss individuellentschieden werden, welche Koordinaten die Filiale korrekt reprasentieren7. Teilweisebe_nden sich die Koordinaten nur auf unterschiedlichem Rundungsgrad, wobei zugunstender praziseren Rundung entschieden wird, in anderen Fallen muss jedoch manuelluber einen Kartendienst uberpruft werden, welche Koordinaten der besagten Filiale amehesten entsprechen. Insgesamt sind 34 Filialen zwei- oder mehrmals in der Datenbankvorhanden, sodass insgesamt 77 Datensatze manuell uberpruft werden mussen.

Hier fallt auf, dass teils unrealistische Datensatze in der Datenbank vorhandensind, deren Koordinaten gar nicht in Deutschland liegen, sondern in Gro_britannienliegen. Abgesehen von der Tatsache, dass es in Gro_britannien keine EDEKA-Filialengibt, passt auch die Zuordnung zur naturlichsprachlichen Adresse nicht, die nachDeutschland verweist. Somit wird fur alle Duplikate hinsichtlich des Identi_katorsmanuell entschieden, welcher Datensatz aus der Datenbasis entfernt wird. Da in derDatenbasis bereits erste Fehler erkennbar sind, werden die Datensatze eingehend uberpruft und es stellt sich heraus, dass alleine 180 Datensatze einen negativenLangengrad besitzen. Deutschlands westlicher Punkt liegt jedoch bei rund 5_ ostlicherLange8, von daher scheinen diese Datensatze allesamt auf falsche Koordinaten zuverweisen. Beispielsweise fuhrt der Datensatz ‘EDEKA Gemarkenstr. 43 / EckeSchongauer Str. 45147’ nicht zu der Filiale, die dem Autor tatsachlich in der Realitatbekannt ist, sondern in den US-Bundesstaat Ohio. Der Gro_teil der Daten, dessenKoordinaten nicht innerhalb der deutschen Landesgrenzen fallen konnen, be_nden sichjedoch in Gro_britannien. Es scheint es sich hierbei um ein Muster zu handeln, demdie Schopfer der Datenbasis mit Hilfe dieser Information gezielt nachgehen konnen.Betrachtet man die anderen Filialen in der Datenbank stichprobenartig und nachden maximalen bzw. minimalen Langen- und Breitengraden, scheint es sonst keineAusrei_er in andere Himmelsrichtungen zu geben, dementsprechend reicht es fur diefolgende Untersuchung, alle 180 Datensatze mit negativem Breitengrad und 22 weitere,unpassende9 Datensatze vor der Analyse herauszu_ltern.

Bezuglich der Aktualitat der vorliegenden Datenbasis ist anzumerken, dass diemeisten der relevanten Datensatze laut der Zeitstempel in der Datenbank im Jahr2013 erzeugt wurden, somit kann nicht mehr zwangslau_g davon ausgegangen werden,dass jede der Filialen in der realen Welt noch existiert. Dementsprechend gibt eseine Unstimmigkeit zwischen den verschiedenen Datenquellen, die allerdings in Kaufgenommen wird, da die Prufung des geplanten Vorgehens hier im Vordergrund steht.Neben dieser Vorauswahl der zu untersuchenden Objekte sind die Objekte im Kontextder eigentlichen Clusteranalyse erst dann als ‘existent’ anzusehen, wenn zu denjeweiligen Koordinaten auch die Umgebungsdaten abgerufen wurden, siehe hierzu denvorangehenden Abschnitt zur Ermittlung der Variablen. Erst wenn jeder Zahler derim vorangehenden Abschnitt erklarten Datenstruktur ihren von der Geodaten-APIabgerufenen Wert besitzt, kann der Datensatz als gultig interpretiert und persistentgespeichert werden, um mit der Analyse fortzufahren. Alle dieser erzeugten Datensatzewerden demnach aus Sicht des Vorgehens zur Clusteranalyse ausgewahlt. Um den bisherausschnittsweise beschriebenen Programmcode in den Gesamtkontext einzuordnen,bietet es sich an, den Einstiegspunkt der Applikation zu betrachten.

Die Durchfuhrung des Programmcodes beginnt in der main()-Methode, in der allezu betrachtenden Filialen aus der lokalen SQLite-Datenbank abgerufen werden und ineiner Java-ArrayList festgehalten, siehe Abbildung 12. Daraufhin wird durch die Listeiteriert und fur jede Filiale die Methode aus Abbildung 8 (Methode zur Strukturierungder folgenden Methodenaufrufe) ausfuhrt, in der wiederum die Methoden aus Abbildung7 (Abruf der Umgebungsdaten uber die API)10 und Abbildung 9 (Persistente Speicherung in SAP HANA) aufgerufen werden. Ist die Schleife aus Abbildung 12durchlaufen, endet die Funktionalitat der intermediaren Java-Applikation, da fur allevorliegenden Filialen die jeweiligen Umgebungsdaten abgerufen sind und als Datensatzepersistent in der SAP HANA Datenbank vorliegen, um dort mit einer Clusteranalyseweiter betrachtet werden zu konnen.

Abb. 12: main()-Methode der intemediaren Java-Applikation fur Datenabruf, -transformation und -speicherung (Screenshot aus der Java-IDE “Eclipse”)

Nach der persistenten Speicherung der ermittelten Daten sind in den Datensatzenbereits einige Fehler innerhalb der erzeugten Datenmatrix ersichtlich. In der API istnicht vorgesehen, bestimmte Suchergebnisse rauszu_ltern, somit taucht bei der Suchenach umliegenden Supermarkten einer EDEKA-Filiale diese Filiale in ihren eigenenSuchergebnissen mit auf. Da dies jedoch konsistent fur alle betrachteten Filialender Fall ist, wird dieser Aspekt nicht als Problem eingestuft, sondern lediglich derVollstandigkeit halber erwahnt. Eine weitere Besonderheit ist die Beschrankung derSuchergebnisse auf 20 Lokalitaten in der Ruckmeldung der API. Diese Eigenschaftgeht erst aus Diskussionen in Community-Foren und darauf folgender manuellerUberprufung mit einem Radius von 1500 m hervor und wird in der Dokumentation nichterwahnt. Dies hat insbesondere bei der Betrachtung von Ballungsraumen Relevanz.Beispielsweise gibt es bei manueller Uberprufung mit gro_erem Radius in der MetropoleBerlin mehrere EDEKA-Filialen, die fur mehrere Umgebungskennzeichen die maximaleAnzahl von 20 erreichen. Hier kann aufgrund der Begrenzung zunachst nicht festgestelltwerden, ob die Anzahl tatsachlich uber 20 oder genau bei 20 liegt, und falls sieuber 20 liegt und limitiert wurde, um wieviel der Wert verfalscht ist. Dies kannwiederum bei darauf basierenden Untersuchungen wie der angestrebten Clusteranalysedie Ergebnisse verfalschen. Ein weiterer Aspekt ist die generelle Richtigkeit derDaten, die sich ebenfalls bei der manuellen Uberprufung mit einem Radius von1500 m als fragwurdig herausstellt. Etwa kann man EDEKA-Filialen beobachten,die vier umliegende Flughafen haben, was bei einem derart kleinen Umkreis hochstunwahrscheinlich ist. Eine manuelle Uberprufung des Datensatzes ergibt, dass etwaauch Parkhauser eines Flughafens mit dem Kennzeichen airport gekennzeichnet sind.Dies hat vermutlich den Hintergrund, dass die Daten der Plattform von den Nutzern oder Inhabern der Lokalitaten gepegt werden, dementsprechend werden auch hierdie Ergebnisse potentiell verfalscht. Diese beiden Aspekte werden an dieser Stelle sohingenommen, um die Analyse dennoch durchfuhren zu konnen, allerdings werden siein der spateren Evaluation der entstehenden Cluster vor dem Gesichtspunkt moglicherFehlerquellen diskutiert. Es bleiben somit 406 gultige Filialen zur Analyse ubrig.