Hallo Leute,
Ich soll für die Firma eine Reparatur DB erstellen, bin auch schon recht weit vor rann gekommen.
Habe ein Hauptformular zum Auswählen der Geräte nach Interner Nummer das klappt auch.
Darin ist ein Unterformular enthalten, wo man nun diverse Sachen eingeben soll, was auch noch klappt. Und diese Daten werden dann an einer Tabelle übergeben.
Und jetzt stellen sich meine Probleme ein.
Wenn man sich die Tabelle anschaut stimmt sie nicht mit den Daten im Unterformular überein. So zb wo im Unterformular die Artikelnummer steht, sehe ich in der Tabelle die ID Nummer und nicht die Artikelnummer. Genauso bei den AW im Unterformular sieht man eine Summe und in der Tabelle nicht.
Und so wie man jetzt die Tabelle sieht wird sie auch nach Excel Übergeben, was natürlich ungünstig ist da man ja keine Kosten berechnen kann.
Und warum wenn das Hautformular gestartet wird im Unterformular schon eine Interne Nummer zu sehen obwohl im Hauptformular noch keine Interne Nummer ausgewählt ist. Wie bekommt man es hin das das Unterformular beim Starten leer ist, oder wenn man eine andere Interne Nummer auswählt.
Hat da vielleicht einer eine Verständliche Idee warum das so ist, und was man tun kann damit man zum Erfolg gelangt.
Hänge mal ein Auszug meiner DB zur besseren Verständlichkeit mit ran.
Hallo,
gleich einige Anmerkungen (bei 187 Beiträgen sollte aber Vieles schon klar sein...)
Zitatbin auch schon recht weit voran gekommen
aber leider nicht auf dem richtigen Weg...
Die DB-Entwicklung beginnt zuallererst mit dem Erstellen eines Datenbankkonzeptes (Tabellenstruktur) anhand der vorhandenen und auch fehlenden Daten in Hinblick auf die Zielsetzung der DB-Aufgabe.
Die Formularerstellung ist zunächst sekundär . Bevor die Tabellenstruktur nicht stimmig (normalisiert, siehe u. st. Links 1, 1a und 1b) erzeugt ist, haben Formulare keinen Sinn und es werden sich Probleme einstellen, wie Du gerade merkst.
Zitat
So zb wo im Unterformular die Artikelnummer steht, sehe ich in der Tabelle die ID Nummer und nicht die Artikelnummer.
Wieso wundert Dich das? Das ist normal, richtig und gewünscht.. In einer relationalen DB werden nur die Referenzen auf Daten aus anderen Tabellen gespeichert und nicht die Werte selber. ( siehe wiederum bei den o. g. Links). Das Auswahlkombi speichert nur die "ErsatzID" (Steuerelementinhalt, gebundene Spalte) ab, was hier korrekt umgesetzt ist.
ZitatUnd warum wenn das Hautformular gestartet wird im Unterformular schon eine Interne Nummer zu sehen obwohl im Hauptformular noch keine Interne Nummer ausgewählt ist
Ein Formular zeigt bei Laden immer den ersten aus den in seiner Datenherkunft stehenden Datensätzen (Ergebnis einer Abfrage) an, sofern keine anderweitigen Maßnahmen ergriffen wurden.
ZitatWie bekommt man es hin das das Unterformular beim Starten leer ist, oder wenn man eine andere Interne Nummer auswählt.
Warum soll das so sein? Ist das eine Vorgabe an die Ablauf-, bzw. Bedienungssteuerung?
ZitatHat da vielleicht einer eine Verständliche Idee warum das so ist, und was man tun kann damit man zum Erfolg gelangt.
Habe ich oben beschrieben. Zum Erfolg (der noch zu definieren wäre, was das eigentlich ist) kommst Du, wenn Du
-- Dich erst mit den Grundlagen von Access und rel. DB-Systemen auseinandersetzt (eindeutige Benamsung, Datentypen, Primär-/Fremdschlüsseln und v. a. m.)
-- Die Daten zusammenstellt und strukturiert (normalisiert und in Beziehung mit referenzieller Integrität gesetzt) als Tabellenstruktur abbildest
-- für jede Tabelle ein separates Einzel- oder Endlosform je nach Anforderung erzeugst und 1:n-Tabellenbeziehungen mit einer HFO/UFO-Konstruktion visualisierst.
-- Sobald mit diesen Formularen ein grundlegender (Daten-)Betrieb der DB möglich ist, können die Form mit einer weitergehenden Ablaufsteuerung ausgestattet werden (z. B. Suchvorgänge oder auch der Excel-Export, der allerdings seinem Sinn nach zu hinterfragen ist)
Hallo,
auch von mir noch weitere Anmerkungen, die auch in das gleiche Horn blasen:
In der Beispieldb sind keine Beziehungen eingerichtet, was aber auch nicht funktionieren würde, da keine passenden Schlüsselfelder eingerichtet wurden. Beziehungen und Verknüpfungen laufen über den Primärschlüssel und nicht über die InterneNr, das ist ja der Sinn eines Primärschlüssels.
Die Tabelle tblHersteller ist irreführend, das sind ja nicht die Hersteller, sondern die eigentlichen Geräte. Für die Hersteller ist eine extra Tabelle erforderlich die nur die reinen Herstellerdaten enthält und die Gerätetabelle kommt nur ein Fremdschlüssel zum Hersteller..
Auch der Excelexport ist zu hinterfragen (wie von Franz auch).
Was willst Du in Excel berechnen was in Access nicht gehen würde ?
Ich glaube nicht, dass es da Berechnungen gibt die Access nicht auch erledigen kann.
Hier gibt es noch viel zu tun, so jedenfalls wird das nix.
Hallo,
@ DF6GL
@ MzKIMu
Danke euch für eure Antworten und Ihr habt ja recht mit den Beziehungen. Aber ich stehe da irgend wie auf den Kriegsfuß ich weiß immer nicht wie weit ich da Tabellen auseinander nehmen muß dmit das passt.
Ich habe da mal eine Beziehungs Übersicht mit ran gehangen würde die den so gehen oder müßte man das alles noch weiter zerbröseln.
Hallo,
nein, das passt hinten und vorn nicht. Du kannst doch nicht einfach die ID verbinden. Das ist Chaos, sonst nix.
Zu einem Primärschlüssel braucht es einen Fremdschlüssel, der überall fehlt.
Und wieso nennst Du eine Tabelle Hersteller, wenn die Geräte drin stehen?
Dir fehlen vollständig die wichtigsten Grundlagen zu Access und ohne diese geht gar nix.
https://www.access-tutorial.de/
Hallo Uwe,
Und wenn du das gelesen hast, installierst du dir mal dieses Tool:
http://www.buch.andreasstern.de/adamo.php (http://www.buch.andreasstern.de/adamo.php)
Damit kannst du das Gelesene zum Lernen erstmal praktisch anwenden.
Dabei verstehst du dann auch ganz schnell das Prinzip hinter den Schlüssel-
feldern. Und dann kannst du beginnen deine Realität damit darzustellen/um-
zusetzen.
Das mag am Anfang zwar nervig sein, weil man das Gefühl hat "nicht vorwärts"
zu kommen, du wirst dir aber später bei der Gestaltung der GUI jede Menge
Zeit und Probleme ersparen, wenn du diesen Weg gehst.
gruss ekkehard
Hallo,
@ MzKlMu,
@ DF6GL,
@ Beaker s.a, danke für den Tip mit Adamo damit habe ich die Beziehungen erstellt. Und habe auch noch so einiges in neue Tabellen aufgenommen.
Wenn Ihr mal über die Beziehungen drüber schauen könntet das währe super, und mir ein Feed Back darüber geben ob das so OK ist.
Danke euch für eure Hilfe
Hallo,
wer soll dieses Linienchaos auflösen ?
Versuche das Beziehungsbild mal zu ordnen und zu strukturieren, damit man da überhaupt was erkennt. Das dürfte auch zu viel des Guten an Tabellen sein. Die Tabellen kann man schieben und so versuchen Kreuzungen zu vermeiden. Das ist Aufwand, aber unerlässlich.
Was mir auf die Schnelle aufgefallen ist, wird für eine Reparatur mehrere Mitarbeiter erfasst, oder ist das nur einer ?
Das gleiche gilt sinngemäß auch für das Material.
Da gibt es noch einige Ungereimtheiten. Aber ordne erst mal das Bild, daa+nn sehen wir weiter.
PS:
Der Zwischschritt über Word für das Bild ist überflüssig. Bilde kann man direkt hier hochladen.
Hallo Uwe,
Lies doch erstmal das Tutorial (das Kapitel über Tabellen reicht doch zunächst)
bevor du mit adamo "rummachst". Und vor allem mache es schrittweise und
überlege dir vorher welche Entitäten in welcher Weise zueinander in Beziehung
stehen.
gruss ekkehard
Hallo
@ Beaker s.a,
@ MzKlMu,
ich hoffe das es jetzt der richtige Weg ist, habe die Tabellen alle noch mal Überprüft sowie die Beziehungen etwas geordnet.
Freue mich auf euer Feed Back.
Gruß Uwe01
Hallo,
naja, unter "ordnen" verstehe ich etwas anderes.. siehe Bild.
Die Beziehungen und der Tabellenaufbau werfen Fragen auf und müssen dringend überarbeitet werden, um die reale Datensituation abzubilden...
Hallo DF6GL,
hast recht deine Anordnung sieht sauberer aus ;).
Aber was meinst du jetzt mit den Tabellenaufbau und was für Fragen werden da aufgeworfen? Könntest du das mal etwas genauer schreiben.
Danke
Hallo,
stimmen die Beziehungen und die Tabellen mit der realen Situation über ein?
Was sollen die beiden Beziehungen zwischen tblBatterie und tblGeraet?
Was soll die DB bewirken? Was soll sie als Ergebnisse liefern, bzw. was soll damit bearbeitet werden?
Hallo DF6GL,
ich würde behaupten das die Beziehungen und Tabellen der Situation über ein stimmen.
Die DB soll für eine Stapler Werkstatt sein wo alle Geräte aufgenommen werden sollen. Sowie einen Überblick über UVV Termine geben. Des weiteren sollen auch Arbeitnachweise erstellt werden, sowie auch ein Export nach Excel. Damit man in Excel nach Geräte Filtern kann für eine Übersicht der Kosten von Reparaturen.
Gruß Uwe01
Hallo,
ich halten den Aufbau in Teilen immer noch für falsch.
Du solltest mal die n:m Beziehungen erklären.
Z.B. die Tabelle "tblrep_Ger".
Die halte ich für überflüssig. Mit einer Reparatur wird ein Gerät repariert, also muss in die Tabelle "tblReparatur" einfach ein Fremdschlüssel zum Gerät.
Repariert ihr auch die Ladegeräte, oder nur die reinen FFZ ?
Die Tabelle tblModell braucht einen FS zum Hersteller und dann wird der Fremdschlüssel zum Modell in der Gerätetabelle gespeichert und nicht der Hersteller, denn vom Modell kommst Du auch direkt zum Hersteller.
Zu den Batterein, jede Batterie hat eine Seriennummer, kann diese Seriennummer bzw. diese Batterie dann auch in allen Geräten verwendet werden?
Willst Du zu einer Reparatur mehrere Mitarbeiter erfassen, oder macht eine Reparatur nur immer ein Mitarbeiter (hatte ich schon mal gefragt) ?
Wo erfasst Du die Arbeitszeit der Monteure?
Brauchst Du ja wenn Du Kosten erfassen willst.
Die n:m Zwischentabelle zur Erfassung des Materials für eine Reparatur fehlt. Du brauchst ja für eine Reparatur mehrere Materialien. Die Felder Artikelnummer und Artikelbezeichnung in der Tabelle tblReparatur können ersatzlos gelöscht werden.
Die Tabelle mit der Internennummer halte ich für überflüssig.
Was bedeutet das Feld rep_internenummer ?
Ich sehe da noch viel mehr Klärungsbedarf, aber eins nach dem anderen.
ZitatDamit man in Excel nach Geräte Filtern kann für eine Übersicht der Kosten von Reparaturen.
Was willst Du dauernd mit Excel ?
Das kann Access viel einfacher, da braucht es kein Excel.
PS:
Ich bin mit diesem Adamo etwas skeptischer, man sollte es schon anwenden, aber erst dann, wenn man die Grundlagen von Access verstanden hat. Man läuft sonst Gefahr, zu viele n:m Beziehungen anzulegen, was mir hier auch der Fall zu sein scheint.
Hallo Klaus,
ZitatIch bin mit diesem Adamo etwas skeptischer,
Natürlich muss man damit umzugehen lernen. Und ohne Basiswissen bringt
das auch nicht viel; - bin ich ganz bei dir.
Wenn man sich aber das Tutorial hernimmt und das dort Gezeigte in adamo
umsetzt, sollte man den Aufbau einer DB (der Normalisierung) und den Sinn
von Schlüsselfeldern recht schnell verstehen.
Ich schrieb ja nicht umsonst
ZitatUnd wenn du das gelesen hast,
und alles Weitere als ich auf das Tool hinwies.
gruss ekkehard