Hallo,
mein Name ist Dennis und ich hab ein Problem wo ich mich seit Tagen im Kreis drehe und lese.
Ich versuche eine DB zur Verwaltung unserer Schrauber zu basteln. Meine Kenntnisse beschränken sich derzeit auf V2B Access Grundlagen. nicht wirklich SQL - eher nicht und VBA... nicht des erwähnens wert. Bisher hab ich Bröckchen aufgelesen und mit viel Glück implementieren können.
Ziel der DB ist, das ich ein Prüfprotokoll ausdrucke welches dem Schrauber zum derzeitigen Zeitpunkt zugehörig ist. Wird dieser neu geprüft, bekommt dieser Schrauber ein neues Protokoll mit seinen Stammdaten und ein paar neuen Grundwerten (Prüfer, Datum, Wirkungsgrad) Es könnte aber auch sein, dass sich mal was an den Grundwerten ändert, daher müsste auch dies wieder historisch nachvollziebar sein.
Nehm ich die Prüfprozedur auf, möchte ich die Protokolle gruppiert aufrufen können (anhand der T-Nummer)um seinen Lebenslauf etwas nachvollziehen zu können und ein neues Protokoll erstellen. Bei Stammdatenänderung diese einpflegen, die relevanten Daten ändern und zum Datenbestand zuschreiben.
Fehlen mir Daten oder Vorlagen müssen diese vorher erst aufgenommen werden. Das funktioniert auch schon mal.
Soviel zur gestellten Aufgabe.
Jetzt habe ich mit Gedanken gemacht zum DB-Design und versucht die Wirklichkeit zu reduzieren und alles zu normalisieren.
Was hab ich bisher:
Tabellen wo alle Daten so weit wie möglich atomisiert sind.
Beziehungen erstellt mit ref.Integrität
Abfragen und Formulare, wo ich die Daten sichtbar habe.
Probleme:
- korrekte Zuordnung Stamm- zu Massendaten (bin mir nicht sicher ob ich das gerafft und gut aufgeführt habe)
- korrekte Beziehungen?
- Formulardaten sind nicht historisch speicherbar.
Meine derzeitige Hauptfrage ist:
Wie bekomme ich es hin, dass ich den angezeigten Datensatz im Formular(Protokoll) abgespeichert bekomme.
Struktur dafür:
- frmSchrauberNeu holt sich die Daten aus qrySchrauberNeu + frmSchrauberNeuUnter
- frmSchrauberNeuUnter aus qrySchrauberNeuUnter
- qrySchrauberNeuUnter aus weiteren Tabellen und zwei Abfragen.
- Abfragen da eine Type zwei Abtriebe haben kann, welche alle zusammen in tblAbtriebe sind.
Die Anzeige der hinterlegten Daten zur ID hab ich durch Spaltenanzahlen sowie Verknüpfungen von Werten "Benutzerfreundlich" im Formular
Ich hänge zwei Bilder an um vielleicht die Beziehungne und den Sinn zu verteutlichen.
Die tblSchrauberAnfuege ist derzeit gedacht als Sammelbecken für die Schrauber in allen Varianten. Aber dann könnte ich auch eine risige Tabelle machen und hätte viele Daten dann doppelt und nicht durch Verküpfungen in normalisierter Form. Sie zeigt aber die relevanten Daten die für einen Schrauber nötig sind.
Ich hoffe das ich soweit verständlich geschrieben habe und das mir wer helfen kann. Ich dreh mich nämlich seit einer Woche im Kreis.
Fragen immer her
Kritik ebenso, denn noch kann ich alles ändern ohne auf Daten Rücksicht nehmen zu müssen.
Gruß Dennis
Hallo Dennis und willkommen im Forum.
Um bei der Tabellenstruktur anzufangen:
Vervollständige zunächst die Tabellenstruktur bezgl. der Normalisierungsregeln (z. B. TypStuetzX, schAbtX... ,usw. )
Abfragen in die Beziehungen einzubinden, ist hier fragwürdig.
Bezeichnet "tblType" wirklich den inhaltlichen Sinn dieser Tabelle? ( sollte eher "tblSchrauberDetails" oder "tblSchrauberModule" oder "tblSchrauberBauteile" heißen. Dabei ist mir jetzt die Bedeutung von "Abtrieb" nicht bekannt. Ich vermute, es handelt sich hierbei um eine Vorrichtung zur Vorwärtsbewegung des Schraubers an einer Maschine. Es könnte sich aber auch um eine "Eigenschaft" des Schraubers selber handeln. Wenn (wie später erwähnt,) ein Schrauber mehrere Abtriebe besitzen kann, so ist hier eine weitere Tabelle "tblSchrauberAbtriebe" zu verwenden. Hier sollte noch eine genaue Datenstruktur-Analyse durchgeführt werden.
TbProtokolle hat falsche Beziehung zu tblSchrauber und sollte "umgedreht" werden (1-tblSchrauber -- n-tblProtokolle)
tblPrüfer (und tblMWGTyp) sollten diesen Aufbau haben (Primärschlüssel als Autowert):
tblPrüfer
PRUID (PK, Autowert
PRU_Vorname
PRU_Nachname
PRU_....
tblMWGTyp
MWGTID (PK, Autowert)
MWGT_Bezeichnung (TEXT)
.
.
Zu den Problemen:
a) Was sind Massendaten?
b) oben angesprochen
c) unverständlich.. Formulare zeigen Tabellendaten an, die im Normalfall damit eingebbar, editierbar und löschbar sind.
ZitatWie bekomme ich es hin, dass ich den angezeigten Datensatz im Formular(Protokoll) abgespeichert bekomme.
Wenn tblProtokolle n-1 mit tblSchrauber in Beziehung gesetzt wird, können beliebig viele Protokolle für jeden einzelnen Schrauber erstellt werden. Ob auch "proWirkX" in dieser Tabelle normalisiert werden müssen (sollten) kann ich jetzt nicht beurteilen.
ZitatStruktur dafür:
.
.
??
ZitatAbfragen da eine Type zwei Abtriebe haben kann, welche alle zusammen in tblAbtriebe sind.
siehe oben..
ZitatDie Anzeige der hinterlegten Daten zur ID hab ich durch Spaltenanzahlen sowie Verknüpfungen von Werten "Benutzerfreundlich" im Formular
Was meinst Du damit?
Es sollte für jede Tabelle (mindestens) ein Formular existieren. In Tabellen(ansichten) wird beim Betrieb der DB nichts eingegeben oder editiert, nur über die Formulare. Die Tabellen sind für die Bediener nicht zu sehen und tabu.
ZitatDie tblSchrauberAnfuege ist derzeit gedacht als Sammelbecken für die Schrauber in allen Varianten. Aber dann könnte ich auch eine riesige Tabelle machen und hätte viele Daten dann doppelt und nicht durch Verküpfungen in normalisierter Form. Sie zeigt aber die relevanten Daten die für einen Schrauber nötig sind
Diese Tabelle ist überflüssig (unsinnig), wie auch das Vorgehen als solches. Alle für den jeweiligen Zweck erforderlichen Daten können aus den vorhandenen Tabellendaten mittels Abfragen (wenn überhaupt erforderlich) mit den Formularen und Berichten angezeigt (bzw. editiert) werden.
Danke für deinen Willkommensgruß
Besonderer Dank an die sehr umfassende Antwort.
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Um bei der Tabellenstruktur anzufangen:
Vervollständige zunächst die Tabellenstruktur bezgl. der Normalisierungsregeln (z. B. TypStuetzX, schAbtX... ,usw. )
Da erwischtst du mich schon recht kalt. Werde zu den "Regeln" etwas rechachieren müssen. (Sind mir noch nicht in Fleisch und Blut übergegangen) Werde aber versuchen das zu verbessern.
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Abfragen in die Beziehungen einzubinden, ist hier fragwürdig.
Kann ich die Beziehung einfach rausschmeißen? Von dem Sinn her und von der Funktion, tut das ja erstmal keinen Abbruch.
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Bezeichnet "tblType" wirklich den inhaltlichen Sinn dieser Tabelle? ( sollte eher "tblSchrauberDetails" oder "tblSchrauberModule" oder "tblSchrauberBauteile" heißen.
Ein Vergleich:
Schrauber=Auto
Hersteller=VW
Type=Golf
(so in etwa) Die Type ist ein Inditz darauf, worum es etwas mehr im Detail geht.
VW-Golf-Variant-TDI-103Kw
Damit währe wohl auch geklärt was ich beruflich mache ::)
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Dabei ist mir jetzt die Bedeutung von "Abtrieb" nicht bekannt.
Siehe Bilder 1-3
Schrauber hat Motor - Getriebe - Abtrieb
Auto hat Motor - Getriebe - Räder.... Und ja... so verschieden wie du sie im Autozubehör kaufen kannst. (Größe, Sinn, Zweck... In Größenangaben, Hersteller und Produktionsdatum)
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Wenn (wie später erwähnt,) ein Schrauber mehrere Abtriebe besitzen kann, so ist hier eine weitere Tabelle "tblSchrauberAbtriebe" zu verwenden. Hier sollte noch eine genaue Datenstruktur-Analyse durchgeführt werden.
hmmm du siehst bei den Bildern z.B. einen Schrauber mit 90° Winkelabtrieb (im Kreis). Da kann es vorkommen das ein Flachabtrieb drauf montiert wird... (3D Zeichnung)
Wichtig sind die Untersetzungen. Die bestimmen später, wie die Steuerung errechnet, dass eine Schraube eine bestimmte Drehzahl hat beim schrauben.
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
TbProtokolle hat falsche Beziehung zu tblSchrauber und sollte "umgedreht" werden (1-tblSchrauber -- n-tblProtokolle)
tblPrüfer (und tblMWGTyp) sollten diesen Aufbau haben (Primärschlüssel als Autowert):
tblPrüfer
PRUID (PK, Autowert
PRU_Vorname
PRU_Nachname
PRU_....
tblMWGTyp
MWGTID (PK, Autowert)
MWGT_Bezeichnung (TEXT)
.
.
Werde ich korigieren. Dahte aber, währe einfacher, Da nur diese Werte von Belang und einzigartig sind
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Zu den Problemen:
a) Was sind Massendaten?
b) oben angesprochen
c) unverständlich.. Formulare zeigen Tabellendaten an, die im Normalfall damit eingebbar, editierbar und löschbar sind.
a) Tabelleneinteilung: Stammdaten entahlten die wesendlichen Teile. Detailtabellen (Massendaten) die die Daten, die die Stammdaten füttern. Die Frage/das Problem war, das ich nicht sicher war-ob ich sie richtig zugeortnet habe. (1:n Beziehungen)
Darauf hab ich ja schon deine Antwort mit dem umdrehen von Schrauber zu Protokoll.
c) ja stimmt schon, Derzeit habe ich die absolute Basis. Rufe ich einen Datensatz auf (Schrauber) könnte ich ihn verändern, aber das gilt dann für alle.
Schrauber T100000 kommt zur Rep. ich rufe T100000 auf. Jetzt hat dieser Schrauber einen zusätzlichen Abtrieb bekommen, zum Abtrieb 1 (Winkelkopf) ist ein Abtrieb 2 (Flachabtrieb) gekommen.
Ich darf aber auch nicht das Protokoll mit den Daten von vor der Rep. mit den neuen Daten überschreiben. Genauso die Fehlermeldung von früher mit heute...
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
ZitatWie bekomme ich es hin, dass ich den angezeigten Datensatz im Formular(Protokoll) abgespeichert bekomme.
Wenn tblProtokolle n-1 mit tblSchrauber in Beziehung gesetzt wird, können beliebig viele Protokolle für jeden einzelnen Schrauber erstellt werden. Ob auch "proWirkX" in dieser Tabelle normalisiert werden müssen (sollten) kann ich jetzt nicht beurteilen.
Mit der Umkehrung würde ich bestimmt schon mal die Historie halten. Werde ich machen - Ist auch einläuchtend. Da bin ich so nicht drauf gekommen.
proWirkX... Ich habe immer zu einem Schrauber 5 Wirkungsgrad-Angaben. Daraus errechnet die Steuerung, wie sie ihrer Vorgaben anpassen muss, das genau DIESER Schraber am ende die Schraube mit genau dem Drehmoment fest zieht die die Parameter in der Steuerung verlangen.
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
ZitatStruktur dafür:
.
.
??
sollte den Aufbau der Datenbank darstellen. Wie ist der Arbeitsablauf und wie spiegel ich das in der Datenbank wieder...
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
ZitatAbfragen da eine Type zwei Abtriebe haben kann, welche alle zusammen in tblAbtriebe sind.
siehe oben..
siehe Erklärung oben...
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
ZitatDie Anzeige der hinterlegten Daten zur ID hab ich durch Spaltenanzahlen sowie Verknüpfungen von Werten "Benutzerfreundlich" im Formular
Was meinst Du damit?
Normal würde im Formular nur die ID stehen. Durch 2 Spaltenansicht mit Spaltenbreite 0cm und einer Abfrage sowie Verküpfen von mehreren Spalten. Somit wird Spalte ID ausgeblendet und mehrere Spalten zusammen dargestellt. (Aus Nachname / Vorname wird Nachname, Vorname) Also mehrere Atribute? zusammengerechnet
Zitat von: DF6GL am Januar 16, 2016, 10:20:37
Diese Tabelle ist überflüssig (unsinnig), wie auch das Vorgehen als solches. Alle für den jeweiligen Zweck erforderlichen Daten können aus den vorhandenen Tabellendaten mittels Abfragen (wenn überhaupt erforderlich) mit den Formularen und Berichten angezeigt (bzw. editiert) werden.
Das würde sich tatsächlich erledigen wenn ich die Beziehungen von Schrauerb zu Protokoll umdrehe. Ich müsste dann nur erreichen, dass wenn ich im Formular, Daten ändere, ein neuer Datensatz angelgt wird und dieser dann im Protokoll hinterlegt wird.
So werde ich das im laufe der Woche mal versuchen umzusetzen.
Ich hoffe so etwas Licht ins Dunkel gebracht zu haben.
Danke schon mal an alle, die sich dies alles durchgelesen haben.
Ich werde erst mal die nächsten Tage mit den Denkansätzen arbeiten und versuchen die DB zugänglich zu machen um es euch anfassbar zu machen.
Hallo,
der Vergleich mit einem Auto ist überflüssig, einen Schrauber kann ich mir auch so vorstellen. :P 8) ;) :)
Zitat"Regeln" etwas rechachieren
siehe Links 1 und 1a in meiner Signatur
ZitatKann ich die Beziehung einfach rausschmeißen?
was sonst? Dadurch fehlende, den realen Datenverhältnissen entspr. Tabellen-Beziehungen müssen halt eingebaut werden.
Abtrieb: Die Frage war nur so zu verstehen, ob der Abtrieb ein Bestandteil (Bauteil, Modul) des Schraubers ist oder der Abtrieb als externe Vorrichtung einen Schrauber als ganzes bewegt.
Dein Vergleich hinkt, eher so:
Schrauber=Golf
Hersteller=VW
Type=Variant evtl. hier auch "Variant-TDI-103Kw", wenn man keine Hierarchie braucht und die Normalisierung überzogen wäre
(Dies nur zur "Sichtweise" auf Datenbedeutung...)
ZitatSchrauber hat Motor - Getriebe - Abtrieb
Auto hat Motor - Getriebe - Räder.... Und ja... so verschieden wie du sie im Autozubehör kaufen kannst
Die Gesamtheit dieser Werte sind "Bauteile" oder "Module" (bleiben wir bei diesem Ausdruck) und fänden sich in einer (Stamm-) Tabelle "tblModule" wieder. Diese Tabelle gehört mit 1-n Beziehung an "tblSchrauberModule" angebunden.
Solche Tabellennamen sollen den Sinn einer Tabelle verdeutlichen:
tblModule ist unabhängig und enthält alle möglichen und vorkommenden Module.
tblSchrauberModule enthält die Zuordnungen von Modulen zu einem bestimmten Schrauber.
ZitatDa kann es vorkommen das ein Flachabtrieb drauf montiert wird... (3D Zeichnung)
Was soll die DB eigentlich insgesamt leisten? Soll die einem Produktionsplan folgen, d. h. eine Planung darstellen, in welcher Konfiguration ein bestimmter Schrauber gerade eingesetzt werden soll oder geht es nur um Prüfprotokolle, die in mehr oder weniger regelmäßigen Abständen erstellt werden müssen?
Vermutlich handelt es sich um eine Db zur Wartung/Reparatur von Produktionswerkzeugen. Dann sollte eine gewisse Nachverfolgbarkeit (Historie) gewährleistet sein.
Wenn Konfiguration, dann fehlen die entspr. Tabellen, die die aktuelle, bzw. die zeitlich veränderten Konfigurationen erfassen.
Zitat.. erledigen wenn ich die Beziehungen von Schrauerb zu Protokoll umdrehe. Ich müsste dann nur erreichen, dass wenn ich im Formular, Daten ändere, ein neuer Datensatz angelgt wird und dieser dann im Protokoll hinterlegt wird.
Wenn eine Historie, bzw. dynamische Schrauberkonfiguration im Spiel ist, dann ist die Beziehung tblProtokolle zu tblSchrauber nicht mehr korrekt...
Bis hierhin dreht sich alles um die Basis der Db, d. h. um Datenanalyse und Aufgabe der Db
Zu Darstellungen (Formularen)
ZitatNormal würde im Formular nur die ID stehen. Durch 2 Spaltenansicht mit Spaltenbreite 0cm und einer Abfrage sowie Verküpfen von mehreren Spalten. Somit wird Spalte ID ausgeblendet und mehrere Spalten zusammen dargestellt. (Aus Nachname / Vorname wird Nachname, Vorname) Also mehrere Atribute? zusammengerechnet
Da sprichst Du ein Kombifeld an, mit dem ein bestimmter DS aus einer (Stamm-) Tabelle ausgewählt und dessen ID-Wert abgespeichert wird. Ein solches Kombi hat Eigenschaften (Spaltenbreiten, Spaltenanzahl, etc..) , mit denen die (Daten-)Anzeige im Formular beliebig gespeichert werden kann. Ein solches Kombi ist aber nur eines von vielen Steuerelementen , die im Formular zur Anzeige (der Daten aus der entspr. Tabelle, bzw. Abfrage) verwendet werden können.
ZitatVerküpfen von mehreren Spalten. Somit wird Spalte ID ausgeblendet und mehrere Spalten zusammen dargestellt. (Aus Nachname / Vorname wird Nachname, Vorname) Also mehrere Atribute? zusammengerechnet
Das kannst Du machen, musst Du aber nicht...
Abschließend zur Verdeutlichung:
Erst, und nur erst dann, wenn der Tabellenaufbau, sprich -konstruktion korrekt und vollständig entspr. den realen Datenverhältnissen und der Aufgabe der DB (Tabellen, Tabellenfelder, Feld-Datentypen, Beziehungen) erzeugt wurde, kommen die Formulare ins Spiel. Dann erfolgt damit auch die Umsetzung eines Ablaufkonzeptes (Bedienung der DB).
Zitat von: DF6GL am Januar 17, 2016, 09:32:36
Die Gesamtheit dieser Werte sind "Bauteile" oder "Module" (bleiben wir bei diesem Ausdruck) und fänden sich in einer (Stamm-) Tabelle "tblModule" wieder. Diese Tabelle gehört mit 1-n Beziehung an "tblSchrauberModule" angebunden.
Solche Tabellennamen sollen den Sinn einer Tabelle verdeutlichen:
tblModule ist unabhängig und enthält alle möglichen und vorkommenden Module.
tblSchrauberModule enthält die Zuordnungen von Modulen zu einem bestimmten Schrauber.
Also schreibe ich alle "Module" in einen Tabelle. Dabei schmeiß ich dann tblAbtriebe/Getriebe/Messwertaufnehmer/MotorenMWAtypen/Servodateien komplett raus?
Zitat von: DF6GL am Januar 17, 2016, 09:32:36
Was soll die DB eigentlich insgesamt leisten? Soll die einem Produktionsplan folgen, d. h. eine Planung darstellen, in welcher Konfiguration ein bestimmter Schrauber gerade eingesetzt werden soll oder geht es nur um Prüfprotokolle, die in mehr oder weniger regelmäßigen Abständen erstellt werden müssen?
Vermutlich handelt es sich um eine Db zur Wartung/Reparatur von Produktionswerkzeugen. Dann sollte eine gewisse Nachverfolgbarkeit (Historie) gewährleistet sein.
Korrekt.
Ich brauche nur eine suche nach den T-Nummern. (zu finden derzeit in der tblSchrauber [schTNr])
Wenn ich dann durch die Datensätze navigiere kann ich in den Beschreibungen alle nötigen Infos sehen, was der Schrauber an Problemen hatte und ob sich bestimmt Muster wiederholen. Außerdem Umbauten oder Anpassung von Werten wie Nennmomente(MWG) oder Untersetzungen (Getriebestufen).
Wir warten/reparieren und prüfen die Schrauber.
Zitat von: DF6GL am Januar 17, 2016, 09:32:36
Wenn Konfiguration, dann fehlen die entspr. Tabellen, die die aktuelle, bzw. die zeitlich veränderten Konfigurationen erfassen.
Wenn das in den Prüfprotokollen erfast ist und ich nach T-Nummer filter - ist das auch ausreichend.
Ich will erreichen, dass ich durch aufruf der Protokolle zu T-Nr: Txxx die Prokolle habe, sehe was war in den letzten Reparaturen und mit diesen Werten (als Vorlage einen neuen Datensatz kopiere/dupliziere) wo ich das Duplikat dann anpasse - da sich mindestens der Wirkungsgrad und der Rep-Breicht, Prüfer und Datum ändern.
Ich werde in Kürze mal eine Datenbank mit aktuellem Stand uploaden.
Hoffe ist Regelkonform...
Daten anonymisiert.
EC-HandschrauberneuV0.28-Kopie.accdb (http://www.file-upload.net/download-11222269/EC-HandschrauberneuV0.28-Kopie.accdb.html)
Hallo,
ZitatHoffe ist Regelkonform
kann ich gar nicht bestätigen...
Lies mal u. st. Links 1 und 1a
Ich befürchte, der ganze Tabellenaufbau stellt nicht die Realität dar.
Stelle mal (auf einem Stück Papier) zusammen, was alles zu einem Schrauber einzeln (!) gehört, also z. B. der Motor (Das ergibt später die Tabelle tblSchrauber). Ich nehme nicht an, dass in einem bestimmten Schrauber unterschiedliche Motoren eingebaut werden können. Bauteile (Module) , die alternativ eingebaut werden können, d. h. je nach Verwendung am bestimmten Schrauber umgebaut/eingesetzt werden können, führst Du separat auf (---> ergibt weitere Tabelle tblSchrauberVarianten).
Wenn das passiert ist, normalisierst Du die Tabellen, d. h. beim Beispiel "Motor" wird eine Stammtabelle "tblMotoren" angelegt und mit tblSchrauber in 1:n-Beziehung gesetzt.
Beim Beispiel "Abtriebe" (die, soweit ich es verstanden habe, alternativ als "Varianten" verwendet werden), ergibt das eine Tabelle "tblSchrauberVarianten" , die mit tbl-Schrauber in 1:n-Beziehung gesetzt wird. Die Abtriebe (Abtriebsdaten) selber sind für sich in der Tabelle "tblAbtriebe" (1) als Stammtabelle abzulegen und es ist eine 1:n_Beziehung zu "tblSchrauberVarianten" (n) herzustellen.
Die Tabelle "tblProtokolle" (die eigentlich "tblMesswerte" heißen sollte), wird dann nicht an tblSchrauber, sondern an tblSchrauberVarianten angebunden ( mit Beziehung 1-tblSchrauberVarianten --- n-tblProtokolle)
Dieses Prinzip wird hierarchisch solange umgesetzt, bis alle Daten (in Tabellen) "untergebracht" sind.
Zitat von: DF6GL am Januar 18, 2016, 09:41:52
Stelle mal (auf einem Stück Papier) zusammen, was alles zu einem Schrauber einzeln (!) gehört, also z. B. der Motor (Das ergibt später die Tabelle tblSchrauber). Ich nehme nicht an, dass in einem bestimmten Schrauber unterschiedliche Motoren eingebaut werden können. Bauteile (Module) , die alternativ eingebaut werden können, d. h. je nach Verwendung am bestimmten Schrauber umgebaut/eingesetzt werden können, führst Du separat auf (---> ergibt weitere Tabelle tblSchrauberVarianten).
Siehe Bild
Doch es könnten sich Motoren in ihren Grunddaten ändern (z.B. durch Modellpflege/Update)
Motor, Getriebe, Messwertaufnehmer, Abtrieb 1 und 2 sind die wesentlichen festen Bauteile welche sich ändern können.
Stützsellen geben die Messpunkte vor. Sie bilden den GesamtMessbereich in dem der Schrauber eingesetzt werden kann.
Hinter den Modulen sind ihre Kenngrößen erfasst.
Zur Normalisierung arbeite ich dran, nebenbei muss ja auch noch repariert werden ;)
Hallo,
ok, dann verallgemeinere ich :
Alle unveränderliche Größen (z. B. Seriennummer, Hersteller, Anschaffungsdatum, etc) gehören in tblSchrauber, alle sich möglicherweise zeitlich ändernden Größen gehören in tblSchrauberVarianten. Bei den Abtrieben bin ich immer noch im Klaren:
Gibt es gleichzeitig 2 Abtriebe (hier: wieviele maximal) bei einem Schrauber oder nur einen, der sich ändern kann?
Es gibt immer zwei, auch wenn keiner, einer oder zwei aufgebaut sind.
Die Schrauber-Steuerung verlangt zwei Eingaben. Kein Abtrieb ist also Untersetzung =1 und damit:
Abtrieb 1 = 1 (kein Abtrieb)
Abtrieb 2 = 1 (kein Abtrieb)
Hallo,
ok, dann lass die Felder Abtrieb1_ID und Abtrieb2_ID in der tblSchrauberVarianten und setze je eine Beziehung auf die tblAbtriebe. Dann bedeutet NULL in SV_Abtrieb1_ID_f ,bzw. SV_Abtrieb2_ID_f , dass kein Abtrieb verbaut ist, ansonsten bedeutet der Wert den bestimmten Abtrieb entspr. der PK-Wert aus tblAbtriebe.
Also hätte ich das hier:
PK-Werte? Also die technischen Werte hinter der AbtriebID
Hi,
ok, das sieht schon besser aus...
korrigiere den Tippfehler in "tbvlModule" und entferne das Feld tblSchauber.schmodIDRef.
Empfohlen, aber nicht unbedingt nötig wären noch Datumsfelder in den einzelnen Tabellen (z. Erfassdatum, ÄnderDatum, oder Ähnliches).
Fehlt nur noch tblProtokolle (und evtl. tblPrüfer).... Diese enthält neben den Schlüsselfeldern (PK=Primary Key) ein Datumsfeld (Protokolldatum) und die aus tblModule entfernten Felder "modStuetzStelleX" und "modWirkungsgradX" (Ich nehme an, diese Felder sind die eigentlichen Protokolldaten...) und ein Feld für den "Prüfer", das entweder direkt den Namen enthält oder den Namen(-PK-Wert) aus Tabelle tblPrüfer bezieht. Welche weiteren Daten in Deinen Protokollen stehen müssen, weißt Du selber besser ;) .
Mit dieser Konstruktion können dann für jede Schraubervariante (jedes Schraubermodul) beliebig viele Protokolle erstellt werden. Dabei ist darauf zu achten, dass ein tblModule-Datensatz nachträglich nicht geändert werden darf, sonst hat das Auswirkungen auf den Inhalt der gespeicherten Protokolle. Natürlich dürfen jederzeit neue Modul(datensätze) angelegt werden.
Sollen die Protokolle unveränderlich archiviert werden, so könnte hier eine Archivierungstabelle (tblProtArchiv) helfen, in der lediglich die im Protokoll sichtbaren Felder, bzw. Werte abgespeichert werden. Diese Tabelle hat keine Beziehungen zu den anderen Tabellen.
Hi,
Zitat von: DF6GL am Januar 19, 2016, 09:13:25
korrigiere den Tippfehler in "tbvlModule"
sowie auch den Tippfehler in "tblAbtiebe".
Zitat von: DF6GL am Januar 19, 2016, 09:13:25
Hi,
Empfohlen, aber nicht unbedingt nötig wären noch Datumsfelder in den einzelnen Tabellen (z. Erfassdatum, ÄnderDatum, oder Ähnliches).
Gemacht.
Zitat von: DF6GL am Januar 19, 2016, 09:13:25
Fehlt nur noch tblProtokolle (und evtl. tblPrüfer).... Diese enthält neben den Schlüsselfeldern (PK=Primary Key) ein Datumsfeld (Protokolldatum) und die aus tblModule entfernten Felder "modStuetzStelleX" und "modWirkungsgradX" (Ich nehme an, diese Felder sind die eigentlichen Protokolldaten...) und ein Feld für den "Prüfer", das entweder direkt den Namen enthält oder den Namen(-PK-Wert) aus Tabelle tblPrüfer bezieht.
- tblProtokolle und tblPuefer angefügt.
- modWirkungsgrad in tblProtokolle geschoben
- modStuetzpunkte in tblSchrauber geschoben. (Machen sich da besser, da diese eher gleichbleibend sind)
- in tblSchrauber und tbl Abtriebe den Hersteller ergänzt und ausgelagert
- aus tblMotoren die Servodateien ausgelagert (wenige die sich wiederholen und Änderungen daran nicht Änderungen der technischen Daten am Motor einschließen müssen)
- aus tblMesswertgeber die Gebertypen ausgelagert. (Es gibt 4 und wiederholen sich laufend)
Hoffe habe erstmal nix vergessen und die Änderungen sind nachvollziebar und richtig.
Edit:
aus tblModule die typSchIDRef raus
die Präfixe von typ auf mod geändert
Hallo,
ok, sieht soweit gut aus...
ZitatmodStuetzpunkte in tblSchrauber geschoben. (Machen sich da besser, da diese eher gleichbleibend sind)
Was denn nun: Gleichbleibend oder doch veränderlich? Auch wenn es nur einmal passieren würde, ist es nicht "gleichbleibend".
Nun geht's an die Formulare, go ahead 8)
Veränderbar.
Es kann immer sein, dass ein Schrauber aufgrund von besonderen Wünschen andere Vorgaben bekommt.
Vor den Formularen:
Riesen Dank schon mal bis hier her!
Zu den Formularen:
Da bin ich gerade dabei, einige zu erstellen.
Vorerst ein frmSchrauber mit Unterformularen und deren technischen Werten. Dazu mache ich gerade Abfragen um die Steuerelemente zu füllen.
So das ich einen Schrauber aufnehmen kann.
Hallo,
dann gehören solche Daten in tblModule als neue Variante.
Vielleicht sollte die tblModule tatsächlich besser in tblVarianten umbenannt werden....
ZitatDazu mache ich gerade Abfragen um die Steuerelemente zu füllen.
Das ist zunächst überflüssig...
Erstell einfach für die 1-Tabellen im Normalfall ein Einzel-Formular auf Basis der entspr. Tabelle( Datenherkunft erhält Tabellennamen). Du brauchst nur im Navibereich eine Tabelle zu markieren und unter Menüpunkt "Erstellen" auf Punkt "Formular" klicken.
Nicht vergessen, den Formularnamen einen passenden (gescheiten) Namen zu geben, z. B. für das Formular mit Basis zu tblSchrauber: "frmSchrauber".
Für n-Tabellen (speziell tblVarianten) erstellst Du ein Endlosform ("mehrere Elemente") mit Namen "frmVarianten"
In frmSchrauber fügst Du das Endlosform dann als UFO ein. (Mit Drag&Drop aus dem Navibereich auf den Detailbereich des frmSchrauber ziehen).. Die nötigen Eigenschaften "Verknüpfen von/nach" werden dabei automatisch gesetzt (weil eine Beziehung zwischen den Tabellen definiert wurde).
Für
Hallo,
ich bin noch nicht geplatz und hab auch nicht aufgegeben.
Bei meinen bisherigen Versuchen bin ich auch eigneltich gut weit gekommen.
Aaaaaaber:
Ich hab das Problem das ich es so gestaltet habe, das mir die Variante als eine Art Vorlage dient. So ist auch eigentlich der Plan - Variante ist Vorlage mit den Parametern die einen Schrauber aus machen. Wenn ich aber einen Parameter am Schrauber änder, will ich nicht die Variante ändern.
Hat da wer eine Idee in welcher Richtung das was wird?
Derzeit fällt mir nur so eine Lösung ein:
Schrauber auf nehmen - Variante ausfählen und die einzelnen Module zum Schrauber (per Anfüge-Abfrage) in die tabSchrauber "kopieren"
Kann ich / oder geht das / macht es Sinn....
Die tblSchrauber und die Varianten mit den Modulen in Beziehung zu setzen und aber die Schrauber nicht mit den Varianten?
Ich will also Schrauber aufnehmen und anhand der Variante (als Vorlage) die Konfiguration verpassen, aber die Konfig. am Schrauber unabhängig von der tblVarianten ändern können.
Hoffe das ist verstäntlich ausgedrückt
Gruß Dennis
Hallo,
versteh nicht ganz , was Du willst...
Zitatwill ich nicht die Variante ändern.
warum nicht?
zeige mal einen Screenshot vom akt. Beziehungsfenster..
Damit alles so funktioniert wie es sollte (also Schrauber aufnehmen und mit Variante als Vorlage) musste ich die Beziehungen drehen...
Ich kann ja mal die DB hochladen falls es was hilft.
http://www.file-upload.net/download-11343303/EC-HandschrauberbetaV0.40.bak.accdb.html