Repository navigation
Backend 2.4 Datenmodell
#2.4 Datenmodell
Verantwortliche/r: Maren, Tabea
Die Daten werden vom Frontend über eine einzige Schnittstelle des Backends bezogen. Darüber wird sowohl der Zugriff auf die Daten aus der Datenbank als auch auf die Daten aus Foursquare.com bereitgestellt.
Alle Daten, die aus Foursquare.com gezogen werden können, werden nicht in der Datenbank gespeichert, mit Ausnahme der barID, durch die die Zuordnung zu den Foursquare-Daten ermöglicht wird. Für diese Zuordnung wird die barID in der Tabelle "bar" als Primary Key verwendet und bezieht sich einerseits als FK auf den PK der Foursquare-Daten und andererseits als PK für den FK in "happyHour".
Das folgenden Datenmodell beschreibt die Datenbankstruktur in der H2 Datenbank. Auf Basis dessen wird vom Backend Team in der Datenbank ein Schema erstellt, in das die Daten eingepflegt werden.
Das Marketing Team ist für die Beschaffung der Happy-Hour-Daten zuständig. Beschreibung der Schnittstelle: Marketing-Backend-Schnittstelle
| barReport | Wertebereich | Sonstiges |
|---|---|---|
| id | integer | PK |
| barID | string | FK |
| description | string |
In dieser Tabelle wird gespeichert, ob die Bar durch einen User gemeldet wurden ist oder nicht. Dafür erfolgt die Zuordnung zu der Bar über die barID. Hinzu kommt eine Fehlerbeschreibung, die durch den Nutzer eingegeben werden kann und ein Boolean, der standardmäßig false ist. Bei einer Meldung durch den Nutzer, soll der Boolean auf true gesetzt werden.
| user | Wertebereich | Sonstiges |
|---|---|---|
| name | string | NOT NULL |
| hashPw | string | NOT NULL |
In der "user"-Tabelle werden Administrator User hinterlegt. Diese Administrator können sich anmelden und mit ihrem Name und Passwort authentifizieren. Das Passwort wird als MD5 Hash in der Datenbank abgelegt. Der Name muss hierfür eindeutig sein.
| happyHour | Wertebereich | Sonstiges |
|---|---|---|
| id | integer | PK |
| barID | string | FK |
| description | string | |
| start | time | NOT NULL |
| end | time | |
| monday | boolean | NOT NULL |
| tuesday | boolean | NOT NULL |
| wednesday | boolean | NOT NULL |
| thursday | boolean | NOT NULL |
| friday | boolean | NOT NULL |
| saturday | boolean | NOT NULL |
| sunday | boolean | NOT NULL |
In der "happyHour"-Tabelle werden alle Daten bezüglich den Happy Hours der Bars gespeichert. Wie oben beschrieben wird als Primary Key die bar ID verwendet, die durch das Marketing und Datenbeschaffungs-Team über den hier beschriebenen Weg hergeleitet wird. Die restlichen Informationen zu den Happy Hours, wie eine Kurzbeschreibung, Start- und Endzeit, sowie den Wochentag, wird ebenfalls über das Marketing und Datenbeschaffungs-Team zusammengetragen und in die Datenbanktabelle eingefügt.
| route | Wertebereich | Sonstiges |
|---|---|---|
| hash | string | PK |
| data | string | NOT NULL |
| top | boolean | NOT NULL |
Die route Tabelle enthält die Routen, die durch den Nutzer geshared werden. Hierfür wird der Link der Route und ein Hashwert gespeichert, der alle Daten bezüglich der Route enthält. Hinzu kommt ein Boolean, der standardmäßig false ist. Er wird nur auf true gesetzt bei den vereinbarten top-Routen, die manuell eingegeben werden. Es werden sieben Top-routen festegesetzt - für jeden Wochentag eine vordefinierte Route -, die nicht veränderbar sind.
Folgender Link enthält einen Client, das dazugehörige Passwort, den Stand der Daten und zum Schluss den Namen, nach dem gesucht wird. Der Beginn kann einfach übernommen werden, am Ende kann der Name der gesuchten Bar eingeben werden (im Beispiel wird nach Sausalitos in Stuttgart gesucht)
Die ID ist in der Antwort enthalten. Hier ein Teil der Antwort aus der Beispielabfrage:
{"meta":{"code":200},"response":{"venues":[{"id":"544ad6ce498e91fa4dc24507","name":"Sausalitos"
ID von Sausalitos in der Marienstraße Stuttgart wäre: 544ad6ce498e91fa4dc24507
Alle Daten, die aus Foursquare.com gezogen werden können, sind in folgender Tabelle aufgelistet. Sie werden standardmäßig über den selben Weg, wie die oben beschriebene Herleitung der barID, aus Foursquare gezogen. Allerdings wird statt der Suche nach dem Name der Bar, nach der ID der Bar gesucht. Die Daten aus Foursquare werden nicht in der Datenbank gespeichert. Diese Daten werden lediglich gecacht zur Verfügung gestellt. Für das Cachen der Daten wird Google Guava verwendet. Der Ablauf bei einer Anfrage wird im nächsten Unterkapitel dargestellt.
| barFoursquareDaten | Wertebereich | Sonstiges |
|---|---|---|
| barID | string | PK |
| barBild | string | |
| barBeschreibung | string | |
| barOeffnungszeiten | string | |
| barAdresse | string | |
| barLongitude | string | |
| barLatitude | string | |
| barName | string | |
| barBewertung | string | |
| euroBewertung | string | |
| barTelefonnummer | string |
Bei einer Anfrage nach Daten aus dem Frontend wird überprüft, ob diese Daten aktuell im Cache vorliegen oder nicht. Sind sie dort vorhanden, werden sie von dort ausgegeben. Ist dies nicht der Fall wird über die REST Schnittstelle Foursquare aufgerufen und über die barID die restlichen benötigten Daten ausgelesen und in den Cache gespeichert und anschließend ausgegeben. Bei der Speicherung um Cache wird ebenfalls eine Cache-Zeit in den Settings gespeichert, nach deren Ablauf die Daten aus dem Cache gelöscht werden. Bei dem unterstützenden Framwork, das hierfür verwendet wird, wurde sich für Google Guava verwendet, da es das Cachen vereinfacht und man sich anschließend sich nicht mehr darum kümmern muss, dass alte Cache-Einträge gelöscht werden.
