Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Richtige Planung einer Datenbank... für Anfänger?

Begonnen von Nerymon, März 04, 2020, 10:56:45

⏪ vorheriges - nächstes ⏩

Nerymon

Hallo zusammen, wie der Titel des Thema schon verrät bin ich ein blutiger Anfänger, und bestimmt fände ich die Antworten nach denen ich suche schon tausendfach hier und im Netz, aber bitte seid Nachsichtig mit dem kleinen Welpen, er kann noch nicht mal ordentlich stehen, und wäre sehr dankbar für etwas Starthilfe ^^

Allerdings habe ich wenigstens schon in Erfahrung gebracht, dass richtige Planung zum Um und Auf einer Datenbank gehört. Nur, dort hakt es eben schon. Denn jeder Plan braucht einen Grundriss, und dort verzettele ich mich sehr rasch, wenn die Anforderungen steigen.

Zur Erklärung: Um Access zu üben habe ich mir ein einfaches Szenario überlegt, dass sich gut erweitern lässt: Ein Go-Kart Rennen.

Im einfachsten Fall habe ich drei Teilnehmer - und ein Rennen. Das bedeutet, ich brauche auch nur eine einzige Tabelle, welche die Namen der Fahrer und ihrer Platzierung enthält. (Genauso wie ein Notizbuch mit Telefonnummern)
Soweit ist noch alles klar. Hooorayyy...!

Um einen Schwierigkeitsgrad dazu zu nehmen erhöhe ich die Zahl der Rennen auf drei Stück. Auch das ist mir noch lösbar - ich benötige nunmehr eben drei Tabellen. In diese trage ich die Namen der Fahrer und ihre Positionen ein, und kann dann schon einige Daten abfragen. Z.B. Wer hat welches Rennen gewonnen, wer hat am öftesten gesiegt, wer nie, usw, usw.

Auf der nächsten Stufe bleibe ich bei drei Rennen, habe aber nun fünf mögliche Fahrer. Das ändert nun nach meinem Verstehen nicht viel. Es genügen immer noch die drei Tabellen der drei Rennen.

Wenn nun aber die Zahl der Rennen mit der Zeit steigt (auf 10, 20, und mehr) benötige ich auch für jedes weitere Rennen eine weitere Tabelle. Und wenn ich nun zum Beispiel noch mehr Details einbauen möchte, zum Beispiel auch die Orte eintragen möchte, an denen die Rennen stattfinden, oder Zwischenplatzierungen innerhalb der Rennen habe ich das Gefühl, dass sich die Anzahl der benötigten Tabellen sehr rasch exponentiell erhöht.  :-\

Wenn ich aber stets einen bestimmten Fahrerpool habe, aus meinetwegen 10 Personen, die diese Rennen bestreiten wäre es doch sinnvoller die Tabellen von den Fahrern ausgehend zu gestalten. So kann ich ihre Platzierungen in den einzelnen Rennen in der jeweiligen Fahrertabelle eintragen - aber auch das scheint mir nur bis zu einem gewissen Punkt möglich, denn ich bräuchte ja auch die Orte an denen die Rennen stattfanden. Aber da nicht jeder Fahrer bei jedem Rennen teilnehmen kann... bräuchte ich doch auch wieder Tabellen für die jeweiligen Rennen.

Und ab hier beginnen für mich Redundanz und Chaos - und Kopfschmerzen.

Welche mich auch leider dazu bringen euch nun am Rockzipfel zu hängen. Hättet ihr Tipps für mich, oder interessante Artikel zu dem Thema, egal ob nun auf deutsch oder englisch, oder sonst etwas, das mir weiterhelfen und/oder mich erleuchten könnte?




MzKlMu

Hallo,
Deine Überlegungen sind grundsätzlich völlig falsch.
Du brauchst nicht für jedes Rennen eine Tabelle, in die Fahrertabelle kommen auch keine Wertungen.
Du brauchst folgende Tabellen:
- Fahrer (die reinen Fahrerdaten)
- Rennen (Ort, Datum, Uhrzeit usw. die reinen Rennen Daten).
- FahrerRennen In diese Tabelle kommt ein FS zum Renne, ein FS zum Fahrer und ein Feld für die Plazierung.
Wahrscheinlich wird noch eine 4.Tabelle benötigt mit einem Fremdschlüssel (FS) zu FahrerRennen für die Zwischenplazierungen und ggf. entsprechende Runde.

Mit diesen 4 Tabellen kannst Du alles abdecken, egal wie viele rennen Fahrer und Zwischenplazierungen.

Du wirst Dich unbdingt mit den Grundlagen beschäftigen müssen, siehe hierzu:
https://www.hdm-stuttgart.de/~riekert/lehre/db-kelz/
und
https://www.access-tutorial.de/
Gruß Klaus

DF6GL

Hallo,


hier muss man schon einhaken:

ZitatIm einfachsten Fall habe ich drei Teilnehmer - und ein Rennen. Das bedeutet, ich brauche auch nur eine einzige Tabelle, welche die Namen der Fahrer und ihrer Platzierung enthält. (Genauso wie ein Notizbuch mit Telefonnummern)
Soweit ist noch alles klar. Hooorayyy...!

nix "Hooorayyy"...   



Du hast (als Ausgangssituation):

Rennen  --> Tabelle "tblRennen"  mit allen Angaben, die zu einem Rennen gehören, und mit dem obligatorischen Primärschlüssel "RennID" (Feld als Autowert)

Teilnehmer ---> Tabelle tblTeilnehmer  mit allen Angaben, die zu einem Teilnehmer gehören, und mit dem obligatorischen Primärschlüssel "TeilnehmerID"  (Autowert)

Renn-Teilnehmer  ---> Tabelle "tblRennTeiln",  mit allen spezifischen Daten, die zu einem bestimmten Teilnehmer gehören, der an einem bestimmten Rennen teilnimmt.  Zusätzlich neben dem Primärschlüssel (Autowert) benötigt diese Tabelle noch zwei Fremdschlüsselfelder, um darin die RennID und die TeilnehmerID zur Zuordnung eines Teilnehmers zu einem Rennen abzuspeichern.


Dies nur als grundlegendes Prinzip. (---> Normalisierung) . Es gibt in Folge viel mehr weitere Tabellen, in die die angesprochenen Erweiterungen abgelegt werden müssen. Das Prinzip der Entwicklung ist aber das Gleiche.


Siehe u. st. Links 1, 1a und 1b  bezgl. der (erforderlichen) Normalisierung.

Mehrere gleichartige Tabellen haben zu müssen, ist der falsche Denkansatz.

Nerymon

Zitat von: DF6GL am März 04, 2020, 11:23:17

Renn-Teilnehmer  ---> Tabelle "tblRennTeiln",  mit allen spezifischen Daten, die zu einem bestimmten Teilnehmer gehören, der an einem bestimmten Rennen teilnimmt.  Zusätzlich neben dem Primärschlüssel (Autowert) benötigt diese Tabelle noch zwei Fremdschlüsselfelder, um darin die RennID und die TeilnehmerID zur Zuordnung eines Teilnehmers zu einem Rennen abzuspeichern.


Dies nur als grundlegendes Prinzip. (---> Normalisierung) . Es gibt in Folge viel mehr weitere Tabellen, in die die angesprochenen Erweiterungen abgelegt werden müssen. Das Prinzip der Entwicklung ist aber das Gleiche.


Ahh... durch die Fremdschlüssel wird also innerhalb einer Tabelle auf bestimmte Daten einer anderen Tabelle querverwiesen; Könnte man es - im Prinzip - so verstehen?

Ansonsten schonmal vielen Dank euch Beiden, ich wusste dass ich völlig im Wald stehe, und das sehr tief. Ich lasse mir eure Denkanstösse mal gut durch den Kopf gehen, folge mal den beiden Links - und wenn ich darf komm ich nochmal wieder hierher zurück, wenn ich etwas weiter bin. Noch bin ich nämlich voller Fragen...  ^^ Aber Danke nochmal!

Beaker s.a.

Hallo Nerymon,
ZitatKönnte man es - im Prinzip - so verstehen?
Ja, so isses.
Zur praktischen Übung empfehle ich immer gerne wieder dieses Tool
http://www.buch.andreasstern.de/adamo.php
Muss man sich auch ein bisschen reinfuchsen, ist aber nicht so schwer,
wenn du dich eh durch die von Franz empfohlenen Links "kämpfen" willst.
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

Nerymon

Danke, im Moment bin ich am Access-Tutorial von Herrn Asal dran, und mittlerweile verstehe ich auch meinen grundsätzlichen Irrtum Eingangs... Dem Beispiel im Tutorial zu folgen gelingt mir auch einigermassen - auch wenn ich noch nicht wirklich ganz verstehe, was genau ich da immer tue. :D
Praktische Übung ist da sicherlich von Nutzen. Vielen Dank für den Link!