Nun, so wie ich das sehe, haben alle deine Tabellen einen Primärschlüssel namens ID. Das ist soweit schonmal ganz gut.
Komischerweise scheinen sich deinen Tabellen in keinster Weise auf einander zu beziehen, daher kann ich aus dem Modell nicht wirklich herausbekommen, wie deine Anwendung arbeitet.

Natürlich kann man eine Anwendung bauen, ohne feste Fremdschlüsselbeziehungen in der Datenbank. Diese (im Falle von MySQL, ich denke bei MSSQL ist es ähnlich) dienen, neben dem dass sie zumeist indiziert sind, als Blockade für Löschungen, wenn anderswo noch Referenzen auf Zeilen in dieser Tabelle existieren. Rein praktisch gesprochen.

Logisch gesehen, ist es wichtig, dass man sich der Beziehungen seiner Tabellen untereinander bewusst ist, und auch entsprechend designed. Aus einer Gut überlegten Datenbank lässt sich oftmals der Programmablauf ableiten, bzw. wird geradezu vorgeschrieben.

Ohne Tabellenbeziehungen sagst Du dem Leser: alle Tabellen sind unabhängig voneinander und haben nichts miteinander zu tun. Da Du es anders beschreibst (Stichwort Join), widerspricht Deine App aber dem Datenbankschema.
Das Joinen von (Primär)IDs hingegen ergibt nur kurz Sinn. Und zwar, wenn ein User immer nur einen Login haben kann, ein Guthaben, ein VerbundenesGerät (Umlaute in der DB?!?) und eine SufZeit (also wenn ich nur zu einer Zeit saufen kann, dann werd ich aber grantig! ; entweder Suffzeit oder wahrscheinlich eher Surfzeit). Wenn dem so wäre: Was bringt Dir das? Dann könntest Du gleich alles in eine Tabelle hauen. Mit Fremdschlüssel-IDs kannst Du aber eine 1:n-Beziehung aufbauen. Ein User kann mehrere Logins haben (keine Ahnung, ob das sinnvoll ist). Oder mehrere SuffSurfzeiten. Oder Guthaben.

Ich denke das Hauptverständnisproblem ist hierbei die Art der Verknüpfung von Informationen (Stichwort Relationale Datenbanken).

Im Anhang siehst du in vereinfachter Form, wie die Verknüpfungen hergestellt werden. Zum Beispiel lagert man sowas wie Länder in einer separaten Tabelle, um die Datenredundanz zu verringern und das Joinen zu vereinfachen.

Einfaches Beispiel (5 Tabellen):

Artikel
Land
Frachtkosten
Mehrwertsteuer
Kunde

Du willst jetzt ein Angebot erstellen und rufst den Kunden auf:

Über die folgenden JOINs ermittelst du die Frachtkosten und Mehrwertsteuer die in Rechnung gestellt werden
Kunde.LandesID -> Land.ID
Land.ID -> Frachtkosten.LandID
Land.ID -> Mehrwertsteuer.LandID

● Tabelle
● Feld

ForeignKeys bieten dir für die voneinander abhängige Datensätze neue Möglichkeiten. Du kannst beispielsweise Wenn beispielsweise ein Kunde aus der Kundentabelle gelöscht wird kannst du das löschen kaskadieren auf die Tabelle Zahlungsinformationen, damit die gleich mit entfernt werden. Standardmäßig wird beispielsweise auch das Löschen eines Datensatzes vom SQL-Server abgelehnt solange noch abhängige ForeignKey-Einträge in anderen Tabellen auf den Datensatz verweisen. Es gibt noch bedeutend mehr Möglichkeiten und Funktionen, aber ich denke das Prinzip sollte an dieser Stelle klar sein. Gerade für SQL gibts es unglaublich viele Infos im Internet, einfach mal google.de anschubsen. Ich persönlich mochte die Erklärungen von W3school. Das hat mir damals sehr geholfen SQL zu verstehen.

Hier knapp und grundsätzlich: Grundlagen: Relationale Datenmodellierung
Relationale Datenmodellierung ist vom Prinzip her nicht an Datenbanken gebunden.