Smart Drive’s Datenmodell

Smart Drive’s Datenmodell

Daten sind für unser Geschäftsmodell von großer Bedeutung. Deshalb haben wir uns Gedanken über unser initiales Datenmodell gemacht und ein ERD erstellt. Dieses ist für den Anfang mit nur drei Entitäten nicht groß, sieht dabei jedoch schon Daten für die Zukunft vor.

Kern unseres Geschäftsmodells sind die aufgezeichneten Fahrdaten unserer Kunden, die aktuell insgesamt sechs Messwerte umfassen. Obwohl zunächst nur die Beschleunigungsdaten in X, Y und Z-Richtung zur Auswertung verwendet werden, speichern wir die gemessenen Rotationsdaten für zukünftige Auswertungen ebenfalls ab. Das bietet uns zu einem späteren Zeitpunkt die Möglichkeit auf die bereits gesammelten Daten für mögliche Machine Learning Anwendungen zurückgreifen zu können. Essentiell für die Messreihen sind Zeitstempel der einzelnen Messwerte, damit diese in korrekter Reihenfolge ausgewertet und visualisiert werden können. Außerdem wichtig ist die Zuordnung zu einem bestimmten IoT-Device, damit Kunden nur die Daten des ausgewählten Device sehen können. Dafür wird die ID des Device, der die Messung durchgeführt hat, als Fremdschlüssel aufgenommen. Da von einem Device zu einem Zeitpunkt maximal ein Messwert vorhanden sein kann, kann ein Messpunkt mit den beiden Attributen Zeitpunkt der Messung und ID des messenden Device eindeutig identifiziert werden, sodass diese den Primärschlüssel bilden.

Zur Messung des Fahrverhaltens unserer Kunden, werden unsere selbst produzierten IoT-Devices an die Kunden ausgegeben. Dabei kann ein Kunde mehr als ein Gerät kaufen. Wir speichern den Typ des Geräts und das Ausgabedatum an den Kunden, um regelmäßige Wartung und schnelle Fehleranalyse zu gewährleisten. Jedes Device bekommt eine von der Balena Cloud generierte eindeutige ID, die als Primärschlüssel verwendet wird. Zusätzlich wird als Fremdschlüssel die Kundennummer des Kunden aufgenommen, der das Device gekauft hat.

Zudem speichern wir Daten unserer Kunden. Zunächst wurde im ERD nur eine minimale Auswahl an Attributen modelliert, da weiteres für die technische Umsetzung nicht erforderlich ist. Zu einem späteren Zeitpunkt müssen hier Adressdaten u. a. hinzugefüht werden. Die Erweiterung stellt kein Problem dar, da jeder Kunde bereits jetzt eine eindeutige Kundennummer bekommt, die als Primärschlüssel verwendet wird. Die Kundennummer besteht aus 6 Zeichen, wobei die 26 Buchstaben des Alphabets sowie die Ziffern 0-9 verwendet werden können. Daraus ergibt sich eine Menge von (26 + 10)^6 = 2.176.782.336 möglichen Kundennummern. Diese Menge sollte für die Dauer unseres Geschäfts ausreichen.

Relationenschema

Um unser Datenmodell in einem relationalen DBMS umzusetzen, muss das oben erklärte ERD in ein Relationenschema transformiert werden. Die Umsetzung ist in diesem Fall relativ simpel, da jede Beziehung eine 1:n Beziehung ist. Das bedeutet, dass keine Verknüpfungstabellen notwendig sind, da die Beziehung in der Tabelle der Entität abgebildet werden kann. Ansonsten wird pro Identität eine Tabelle mit den im ERD modellierten Primärschlüsseln verwendet.

Kunde

Kd.-Nr.	Vorname	Nachname	Geburtsdatum
1ab23c	Max	Mustermann	13.12.1999

Das SQL-Statement zur Erstellung der Tabelle sieht wie folgt aus.

CREATE TABLE Kunde (
	Kundennummer VARCHAR(6),
	Vorname VARCHAR(64) NOT NULL,
	Nachname VARCHAR(64) NOT NULL,
	Geburtsdatum DATE NOT NULL,
	PRIMARY KEY (Kundennummer)
);

Iot-Device

Device ID	Kd.-Nr.	Typ	Ausgabedatum
e6567070007e0e09652ae54dc8131af2	1ab23c	Raspberry Pi 4	15.06.2021

CREATE TABLE Device (
	Device_ID VARCHAR(32),
	Kundennummer VARCHAR(6) NOT NULL,
	Typ VARCHAR(128) NOT NULL,
	Ausgabedatum DATE NOT NULL,
	PRIMARY KEY (Device_ID)
);

Fahrdatum

Zeitstempel	Device ID	X_Beschleunigung	Y_Beschleunigung	Z_Beschleunigung	X_Rotation	Y_Rotation	Z_Rotation
2021-06-25 19:09:32.909	e6567070007e0e09652ae54dc8131af2	1.06689453125	-0.021728515625	-0.03759765625	-245	-108	294

CREATE TABLE Fahrdatum (
	Zeitstempel TIMESTAMP,
	Device_ID VARCHAR(32),
	X_acc DECIMAL,
	Y_acc DECIMAL,
	Z_acc DECIMAL,
	X_rot SMALLINT,
	Y_rot SMALLINT,
	Z_rot SMALLINT,
	PRIMARY KEY (Zeitstempel, Device_ID)
);

Auswahl der Datentypen

Für die gemessenen Beschleunigungswerte wurde der Datentyp DECIMAL der PostgreSQL Datenbank ausgewählt, da die Nachkommastellen dieser Werte essentiell sind. Ein Ganzzahl-Datentyp kommt daher nicht in Betracht und es wurde der kleinere Datentyp für Gleitkommazahlen gewählt. Es können bis zu 16.383 Stellen nach dem Komma exakt gespeichert werden. Der Bedarf an Speicherplatz ist für diesen Datentyp variabel, also abhängig von den tatsächlich gespeicherten Werten.

Da die Rotationswerte nur ganzzahlig im Wertebereich von -360 bis 360 möglich sind, wurde dafür der Typ SMALLINT ausgewält. Damit sind Werte von -32.768 bis +32.767 in den Spalten speicherbar. Dafür werden pro Wert 2 Byte Speicherplatz benötigt.