[Access] Projekt - Spiele-Statistik

LPJ

Ensign
Registriert
Sep. 2016
Beiträge
240
Hallo,

ich brauche eure Hilfe bei einer kleinen Datenbank, die ich als Übung aufbauen möchte, um Microsoft Access besser anwenden zu können.
Darum erwarte ich jetzt nicht unbedingt direkt eine fertige ANtwort, sondern ein paar Denkanstöße.

Mein Mitbewohner und ich wollen eine Statistik führen. Es geht um das Spiel "Tiroler Roulette"

Man legt eine Anzahl an Runden fest, es wird nacheinander gespielt und wer am Ende die meisten Punkte hat, gewinnt.

Es gibt also Spiele. Spielen finden an einem Datum statt, wobei es mehrere an einem Tag geben kann.
Ein Spiel hat mehrere Runden. Jede von jedem Spieler gespielte Runde hat eine Punktzahl bzw eine Endpunktzahl

Spieler 1Spieler 2
-2975
125131
-3128
-4063
47149
83356

Ich möchte jetzt also nicht nur die Sieger bzw Gesamtpunkte speichern, sondern auch die Spielrunden. Ich möchte als auch auswerten können, wie oft Spieler 2 gewinnt, wenn er im zweiten Versuch einen negativen Wert erzielt. Zum Beispiel.

Ich würde mich über Denkanstöße sehr freuen!
 
willst du jetzt Tips wie "sieh dir ER Diagramm, Tabellen Normalisierung und SQL an" hören? Oder willst du ein fertiges Tabellenschema sehen?
 
Ich würde gerne bei der Logik anfangen, d.h. dann wahrscheinlich beim Tabellenschema. Ich vermute, dass SQL und co bei der Abfrage ins Spiel kommen. Vielleicht stelle ich dann auch fest, dass das momentan noch zu kompliziert ist.

Aber ja, ich wünsche mir Unterstützung bei der Überlegung, welche Tabellen man braucht, damit die späteren Abfragen überhaupt möglich wären.
 
Was willst du jetzt hören? Wie weit geht überhaupt dein Wissen? Weißt du was mit Begriffen wie ER, Kardinalitäten, Chen, Frontend, Backend, ... anzufangen?
  1. Ich würde erstmal anfangen, ein ER-Diagramm zu zeichnen (z.B. mit yEd). Welche Entitäten sind notwendig? Welche Relationen?
  2. Daraus würde ich mir das physische Modell ableiten und die Attribute dort eintragen.
  3. Erstellen der SQL-Anweisungen für die Datenbank und Tabellen (Ich arbeite eher mit MariaDB, weil wozu überhaupt Access nutzen)
  4. Anschließend würde ich schauen, welche für mich wichtigen statischen Informationen ich mit SQL generieren kann und für welche ich weitergehende Programmierlogik brauche, weil es entweder mit SQL nicht möglich ist oder mir zu komplex wird. In der Regel gilt aber, dass SQL schneller ist.
  5. Frontend basteln
Ich werde dir jetzt aber nicht sagen, welche Tabellen du brauchst. Ich komme auf 3 Tabellen und eine Hilfstabelle. Oder auch nur auf eine, aber dann könnte ich auch gleich Excel nehmen). Mehr sage ich dir nicht, weil sonst mache ich die ganze Arbeit.

Man legt eine Anzahl an Runden fest, es wird nacheinander gespielt und wer am Ende die meisten Punkte hat, gewinnt.

Die Anzahl der Runden die gespielt werden würde ich nicht in der Datenbank festlegen, sondern im Frontend.
 
Zuletzt bearbeitet:
paccoderpster schrieb:
Was willst du jetzt hören? Wie weit geht überhaupt dein Wissen? Weißt du was mit Begriffen wie ER, Kardinalitäten, Chen, Frontend, Backend, ... anzufangen?
  1. Ich würde erstmal anfangen, ein ER-Diagramm zu zeichnen (z.B. mit yEd). Welche Entitäten sind notwendig? Welche Relationen?
  2. Daraus würde ich mir das physische Modell ableiten und die Attribute dort eintragen.
  3. Erstellen der SQL-Anweisungen für die Datenbank und Tabellen (Ich arbeite eher mit MariaDB, weil wozu überhaupt Access nutzen)
  4. Anschließend würde ich schauen, welche für mich wichtigen statischen Informationen ich mit SQL generieren kann und für welche ich weitergehende Programmierlogik brauche, weil es entweder mit SQL nicht möglich ist oder mir zu komplex wird. In der Regel gilt aber, dass SQL schneller ist.
  5. Frontend basteln
Ich werde dir jetzt aber nicht sagen, welche Tabellen du brauchst. Ich komme auf 3 Tabellen und eine Hilfstabelle. Oder auch nur auf eine, aber dann könnte ich auch gleich Excel nehmen). Mehr sage ich dir nicht, weil sonst mache ich die ganze Arbeit.



Die Anzahl der Runden die gespielt würde ich nicht in der Datenbank festlegen, sondern im Frontend.
Danke für deine Antwort. Ich habe kein Vorwissen. Das Spiel ist der Anlass, da mehr zu machen.
Kurz gesagt, würdest du mir aber sehr helfen, wenn du mir die Tabellen nennst, weil ich dann vielleicht weiß, worauf ich hinaus will. Das ist Schritt 1, bevor ich mich um die Umsetzung kümmern kann.

Und selbst wenn ich feststellen würde, dass mir die Umsetzung zu kompliziert ist, wäre ich froh, den Knoten aus meinem Kopf zu bekommen, da ich eben krampfhaft versucht habe zu überlegen, wie viele Tabellen wohl nötig sind, da ich mit einer nicht hingekommen bin.
 
Also ich frage jetzt mit einer bewussten Arroganz: Was würde es denn bringen, wenn ich dir die Lösung sage? Der Weg ist das Ziel. Viele überfordert a^2+b^2 = c^2 wenn die Seiten plötzlich x, y, z heißen und y zum allen Überfluss auch noch die Gegenkathete ist.

Hast du überhaupt Wissen in dem Bereich der Programmierung? Warum hast du Access ausgewählt? Ich habe jetzt mal diesen Artikel überflogen; das sieht erstmal ganz gut aus.

players(#player_id, name, ...)
matches(#match_id, startdate, ...)
round(#round_id, match_id_fk, ...)
player_match(#player_id_fk, #match_id_fk)
 
Zuletzt bearbeitet:
paccoderpster schrieb:
Also ich frage jetzt mit einer bewussten Arroganz: Was würde es denn bringen, wenn ich dir die Lösung sage? Der Weg ist das Ziel. Viele überfordert a^2+b^2 = c^2 wenn die Seiten plötzlich x, y, z heißen und y zum allen Überfluss auch noch die Gegenkathete ist.

Hast du überhaupt Wissen in dem Bereich der Programmierung? Warum hast du Access ausgewählt? Ich habe jetzt mal diesen Artikel überflogen; das sieht erstmal ganz gut aus.

players(#player_id, name, ...)
matches(#match_id, startdate, ...)
round(#round_id, match_id_fk, ...)
player_match(#player_id_fk, #match_id_fk)

Ich habe sowohl in der Schule als auch im Selbststudium ein paar Grundlagen der Programmierung gelernt. Es hapert bei mir aber an der Logik. Wenn du bei a^2+b^2 = c^2 die Seiten plötzlich umbenennst, könntest du tatsächlich auch mich aus dem Konzepz bringen.

Aber ich habe Spaß daran, deswegen beschäftige ich mich jetzt damit. Ich habe vor kurzem auch überlegt, per Access meine Kunden zu verwalten, da mein CRM-System keine Möglichkeit bietet, mehrere Notizen mit Datum pro Kunde zu speichern. Zu Access kam ich einfach, weil ich Excel nutze. Und wenn es mehrere Tabellen + Abfragen braucht, war ich der Meinung, dass es in Access Möglichkeiten geben könnte, das in einfachen Fällen ohne Skripte wie in Excel zu lösen.

Jedenfalls sieht dein Link wirklich hilfreich aus, ich werde mir das heute Abend mal durchlesen. Und deine Tabellen haben mir auch geholfen, vielen Dank! Klar: Eigentlich brauche ich für alle Objekte (bestimmt nutze ich den Begriff jetzt falsch) eine Tabelle, die mehrfach vorhanden sein können, aber immer die gleichen Eigenschaften mit verschiedenen Ausprägungen haben.
 
Ohne Skripte ist relativ. Du wirst definitiv SQL brauchen, unabhängig von der Datenbanksoftware. Für ein SQL Tutorial würde ich dir w3schools empfehlen. Mach dir am besten weitere Gedanken dazu und komm bei Detailfragen wieder. Gerne auch per Direktnachricht.

... Ich schussel bemerke gerade, dass es beim Satz des Pythagoras nicht um Gegen- und Ankathete geht, sondern um Hypotenuse und die beiden Katheten handaufstirn
 
  • Gefällt mir
Reaktionen: LPJ
Zurück
Oben