Access 2010 Datenbank wie am einfachsten aufbauen

[Dr.Cornwallis]

Liebe Gemeinde,

ich brauche eure Hilfe, wie würdet ihr in Access 2010 eine Datenbank aufbauen bzw. die ug. Anforderungen bei folgenden Gegebenheiten umsetzen:

1 Table: Tor
2 Table: Tour
3 Table: Ziel
4 Table: Wochentag

Nun soll mit diesen Tabellen folgendes passieren/entstehen:

Im Frontend(Formular) soll man ein Tor konfigurieren können, dabei muss der Wochentag berücksichtigt werden(jeder Wochentag hat eine eigene Konfig, diese gilt aber dann für jede Woche im Jahr/wiederholt sich bzw. ändert sie sich eher selten).
Im Formular soll festgelegt werden: welche Ziele bei welcher Tour bei welchen Tor an welchen Wochentag zu welcher Uhrzeit(Abfahrt), dazu kommen noch ein paar Zusatzinfos, die aber für diese Fragestellung keine Rolle spielen bzw. man dann leicht hinzufügen kann.
Am Besten wäre es wenn man ein Formular öffnet wo man das Tor wählt und dann mit Kontrollkästchen die jeweiligen Ziele, Touren und Wochentage und Abfahrtszeiten(Abfahrtszeit der Tour) festlegen kann.
Dh.: ich konfiguriere zb.: Tor 1 Konfiguration für Mittwoch, Tour X, Ziele: AAAA, BBBB, CCCC, Mittwoch, 16:00 -> dh. hier müssten 3 Datensätze angelegt bzw. aktualisiert(wenn schon vorhanden) werden
Tor 1 Konfiguration für Donnerstag, TourY, Ziele: DDDD,EEEEE,FFFFF, Donnerstag, 21:00 -> 3 DS
Tor 2 Konfiguration für Freitag, TourZ, Ziele: GGGG, HHHH, IIIII, Freitag, 06:00 -> 3DS

Bis jetzt habe ich ein Formular mit dem man die Datensätze via Kombifeld zusammenbauen kann, danach werden die erstellten Datensätze in einen eigenen Table geschrieben.
Das Problem ist dass ich den kompletten Datensatz pro Ziel anlegen muss(mit allen Daten, Tor, Tour etc....), was für den User dann auf jeden Fall zu kompliziert wird, am besten wäre wenn wie am Beispiel oben(Tor 1) ich 1x das Tor wähle, mit den Kontrollkästchen die Tour auswähle, die Ziele für die Tour hinzufüge und dann pro Ziel ein eigener DS erzeugt wird(oder aktualisiert wird).


Kurzinfo: Die Ziele der Touren ändern sich, Tour zu Tor ändert sich, die Wochentage ändern sich.
Hat hier jemand einen Masterplan bzw. eine ähnliche MusterDB, bin etwas überfordert.



Bitte um Hilfe!

Vielen Dank!

Gruß

Dr.

[Lachtaube]

Ich habe so recht keine Vorstellung, was Du da in der Praxis nachbilden willst. Vorstellen könnte ich mir ggf. (Kontroll-)(Rund-)Fahrten auf einem größeren Betriebsgelände mit Fahrrad/PKW/oä.. Vielleicht kannst Du etwas mehr über den realen Hintergrund erzählen und mitteilen, zu was die DB herangezogen werden soll (Dienstplan?), ohne auch nur ein einziges Formular im Hinterkopf zu haben.

[Dr.Cornwallis]

Daraus soll ein Report für jeden Tag entstehen wo steht: Tour 1 fährt am Tor x am Wochentag x die Ziele x y und z um Uhrzeit x(Abfahrt) an. Tour 1 fährt am Tor x am Wochentag y die Ziele usw....an
                                                                                   

Die Touren sind in der Praxis Anhänger, Ziele die Kunden und die Tore wo die Anhänger befüllt werden.
Wie gesagt ich hätte bereits ein Formular mit Kombifeldern wo man einen Datensatz zusammenbasteln kann, dieser wird dann in einen neuen Table geschrieben.

Gruß

Dr.

[Lachtaube]

Sorry, aber mir ist die Kurzschilderung zu oberflächlich, um daraus auch nur halbwegs ein Datenmodell ableiten zu können. Vielleicht steigt ja ein(e) andere(r) Helfer(in) ein.

[Beaker s.a.]

Hello Doc,
Mir geht es wie Lachtaube, so wirklich fällt einem dazu (erstmal) nicht ein, aber

Die Touren sind in der Praxis Anhänger, Ziele die Kunden und die Tore wo die Anhänger befüllt werden.

1. Dann bleibe auch bei der Praxis. Die kennt hier i.Ü. keiner.
2. Für mich sind Touren und Anhänger (Fahrzeuge) unterschiedliche Entitäten,
die u.U. sogar noch voneinander abhängig sind.

Zeige doch mal ein Bild von deinen Tabellen (Hardcopy des Beziehungsfensters,
mit allen Tabellen und allen Feldern).
Dann kann hier vielleicht jemand was dazu sagen.
Vorher, also bevor das Datenmodell (DM) steht, brauchst du auch gar nicht mit
Formularen/Berichten anfangen. Da fängst du nur an irgendwie rum zu würgen,
was mit einem ordentlichen DM z.T./u.U. gar nicht nötig wird.

gruss ekkehard

[Dr.Cornwallis]

Moin,

im Anhang eine Übersicht der Rohtabellen, das sind alle Rohdaten aus denen man die Datensätze bauen soll.
Nun müsste man einen Datensatz zusammenbauen der folgende Infos enthält:

Am Tor 1 fährt am Montag Kurs 1, Kurs 2, Kurs3, Kurs 1 steuert die Ziele x, y und z mit der Abfahrtszeit 16:00 an, Kurs 2 etc(Ziele, Abfahrt)....
Am Tor 1 fährt am Dienstag Kurs x........
Am Tor 2 fährt am Dienstag Kurs y........

Aus diesen Datensätzen wird dann ein Report generiert, der nach Toren und dann nach Kursen gruppiert ist, diesen habe ich soweit auch fertig, funktioniert auch alles so wie es soll, es geht mir rein um die Konfiguration der Tore(also den Datensatz zusammenbauen) dies soll so einfach wie möglich sein und ich bin mit meiner derzeitigen Lösung nicht zufrieden.
Der Report wird dann täglich zu den Toren gelegt(pro Tor ein eigenes Blatt), dort sind dann die Kurse+Abfahrt und deren Ziele aufgelistet, die Verlader trägt dann die Lademenge für jedes Ziel/Kurs in leere Felder am Report ein(rechts neben den Zielen). Die ausgefüllten Reports werden dann von einem User in die DB eingepflegt, dort wird dann die Auslastung in %, freie Plätze und andere Werte berechnet, das habe ich ebenfalls alles bereits fertig. Ich kann auf Wunsch auch gerne die DB hochladen, dann ändere ich einfach sensible Daten.

Gruß

Dr.

[crystal]

Hallo,

ich glaube, dein Problem ist folgendes:
du versuchst, Daten aus mehreren Tabellen "optisch" zusammenzustellen und daraus neue Datensätze zu erstellen. Dieser Ansatz entspricht etwa den Möglichkeiten, die Excel bietet.

Eine Datenbank wie Access allerdings "lebt" von Relationen, also Beziehungen zwischen verschiedenen Tabellen.

Versuche Mal, so zu denken:
Das Auslieferungslager hat mehrere Tore.
Im Lager werden im Tagesverlauf mehrere Touren abgewickelt, d. h. von den Lagerarbeitern werden Waren für die Empfänger einer bzw. mehrerer Touren zusammengestellt und in die Tour-gebundenen Hänger verladen.
Eine Tour hat mehrere Kunden, die anzufahren sind.
Ein Kunde hat mehrere Waren, die er bekommt (was hier wohl einfach nur summiert wird).

Das sind alles 1:n-Beziehungen. 1 Tour:n Kunden

Um nun z.B. die Waren für eine bestimmte Tour zusammen zu stellen, muss der Lagerarbeiter die Kunden wissen, um die Waren bereit stellen zu können (und ggf. auch noch wissen, wo er diese Waren im Lager findet).

Hierfür brauchst du also zumindest eine 1:n-Struktur:
Tour 1
   Kunde1
   Kunde2
   Kunde3
   usw.
oder sogar

Tour 1
   Kunde1
      Ware1
      Ware2
      ...
   Kunde2
      Ware1
      ...

Um solche Abhängigkeiten (Beziehungen, Relationen) in Access abzubilden, bedient man sich an der Oberfläche zumeist eines Formulars, in dessen Kopf die allgemeinen Tour-Daten stehen (quasi als Überschrift). In diesem Formular gibt es dann ein Unterformular (oft tabellarisch), in dem die Kunden dieser Tour dargestellt werden. Beim Erstellen einer Ladeliste wählt der User (Disponent) die Tour und dann trägt er im Unterformular nacheinander alle Kunden der Tour ein, für die aktuell Waren zu liefern sind. Dies kann anschließend gedruckt werden.

Wichtig ist allerdings, dass diese 1:n-Beziehungen bereits in den Tabellen verankert ist - erst dann kann man die Oberfläche, also das Formular mit seinen Unterformularen sinnvoll gestalten.

Bei diesem Ablauf ergibt sich ein kleines Problem: wenn der Disponent dabei ist, Waren für eine bestimmte Tour zusammenzustellen, möchte er natürlich auch nur diejenigen Kunden sehen, die mit der betreffenden Tour überhaupt angefahren werden UND für die aktuell Waren vorhanden sind. Hier brauchst du also die Information, welchem Kunden welche Tour zugeordnet ist. Außerdem will der Disponent vielleicht entscheiden, das Ware, die erst heute angekommen ist, nicht sofort ausgeliefert wird (begrenzter Platz im Anhänger), was wiederum bedeutet, dass er zu jedem Kunden die jeweils vorhandenen Waren/Posten (mit Eingangs-Datum und ggf. einem "Dringend"-Vermerk und Informationen zur Größe oder zum Gewicht des Postens) sehen möchte. Dann kann er entscheiden, welche Posten jetzt ausgeliefert werden sollen (Häkchen machen).

Deine Idee, das alles mit den wenigen Rohtabellen, die ohne Beziehung in der Luft stehen, und mit ein paar Kontrollkästchen zu machen, wird nicht funktionieren.

Ich denke, du musst deine Idee zunächst noch einmal überdenken und aus den gewünschten Abläufen die erforderlichen Daten ermitteln, z.B.: welche Infos braucht der Disponent beim Zusammenstellen einer Tour? Außerdem musst du dich wohl mit 1:n-Beziehungen auseinandersetzen (Beispiel-DBs gibt es im Internet zu Hauf).

Betrachte meinen Beitrag bitte als Denkanstoß.

lg
crystal

[Beaker s.a.]

Hello Doc,
Ergänzend zu crystals ausführlichen Ausführungen noch eine
Anmerkung bezüglich Benamsung der ID-Felder.
Gönne deren Namen einen Bezug zur Tabelle, - also z.B. BasisID,
GroupID, KursID usw.
Du wirst es später zu schätzen wissen.
gruss ekkehard