Formularinhalt in Tabelle anfügen und Historie erhalten

[DieOmer]

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

[DF6GL]

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.

Wie 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.

Struktur dafür:
.
.

??

Abfragen da eine Type zwei Abtriebe haben kann, welche alle zusammen in tblAbtriebe sind.

siehe oben..

Die 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.

Die 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.

[DieOmer]

Danke für deinen Willkommensgruß

Besonderer Dank an die sehr umfassende Antwort.

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.

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.

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 

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)

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.

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

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...

Wie 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.

Struktur dafür:
.
.

??

sollte den Aufbau der Datenbank darstellen. Wie ist der Arbeitsablauf und wie spiegel ich das in der Datenbank wieder...

Abfragen da eine Type zwei Abtriebe haben kann, welche alle zusammen in tblAbtriebe sind.

siehe oben..

siehe Erklärung oben...

Die 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

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.

[DF6GL]

Hallo,


der Vergleich mit einem Auto ist überflüssig, einen Schrauber kann ich mir auch so vorstellen. 

"Regeln" etwas rechachieren

siehe Links 1 und 1a in meiner Signatur

Kann 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...)

Schrauber 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.

Da 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.

.. 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)

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

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.

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

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).

[DieOmer]

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?

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.

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.

[DieOmer]

Hoffe ist Regelkonform...
Daten anonymisiert.

EC-HandschrauberneuV0.28-Kopie.accdb

[DF6GL]

Hallo,

Hoffe 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.

[DieOmer]

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 

[DF6GL]

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?

[DieOmer]

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)

[DF6GL]

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.

[DieOmer]

Also hätte ich das hier:

PK-Werte? Also die technischen Werte hinter der AbtriebID

[DF6GL]

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.

[MaggieMay]

Hi,

korrigiere den Tippfehler in "tbvlModule"

sowie auch den Tippfehler in "tblAbtiebe".

[DieOmer]

Hi,

Empfohlen, aber nicht unbedingt nötig wären noch Datumsfelder in den einzelnen Tabellen (z. Erfassdatum, ÄnderDatum, oder Ähnliches).

Gemacht.

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