Datensatz mit Daten im Unterformular kopieren

[gsaccess]

Zu der Diskussion unter euch Fachleuten noch eine Frage:

@Josef
Ich habe in der Tabelle Aufträge folgende Felder:
AuftragsID -Autowert =PK
Auftrag_nr - double (ohne Duplikate) - diese Zahl setzt sich aus Datum und Zeit der Auftragsanlage zusammen, Integer ist zu klein
...
mit der Auftrag_nr sind die Tabellen darunter verknüpft.(siehe Bild)
Mir wäre wichtig in den den Tabellen darunter die Auftrags_nr nicht die AuftragID mitzuführen da ich für den Import von Daten mich immer auf die eindeutige Auftrags_nr beziehen kann.

Ist dies für die Verknüpfung ein Problem oder wie du schreibst auch zulässig?
Bei der Kalkulation bin ich noch am Beheben der Redundanzen, da die Kundennr in der Kalk wirklich nicht gebraucht wird.

LG Günther

[MzKlMu]

Hallo,

diese Zahl setzt sich aus Datum und Zeit der Auftragsanlage

Das ist ja sonst nichts als die Uhrzeit mit DAtum. Das ist der DAtentyp "Datum/Uhrzeit" automatisch. Und das ist im Hintergrund eine Zahl des Typs Double. Es ist ja auch sonst nichts als ein Zeitstempel der mit Now() direkt gesetzt werden kann.

mit der Auftrag_nr sind die Tabellen darunter verknüpft.(siehe Bild)

Die Auftrag_nr ist eine Double Zahl (Fließkomma) das taugt nicht als Schlüsselfeld.
Verwende die AuftragID als Fremdschlüssel. Das gilt für alle Beziehungen über die Auftrag_nr.
Und wenn die Auftrags_nr für den Import notwendig ist, so kommt die aus einem anderen System und da ist nicht sichergestellt, dass es die gleiche Auftrag_nr auch bei den Aufträgen gibt, es ist ja wie gesagt Fließkomma. Das musst Du ändern.
Bei den Beziehungen ist im Regelfall der Typ 1 einzustellen. Das wird nur bei Bedarf in den Abfragen (dort sind es Verknüpfungen) geändert.

Ich glaube nicht, dass das Datenmodell so stimmt. Du solltest mal das ganze Beziehungsbild hier zeigen und zwar so, dass man alle Felder der TAbellen sieht. Die Felder mit den TAbellen lassen sich größer ziehen.

[gsaccess]

Danke für deine Ausführungen. Ich bin dabei noch einige Redundanzen (zB berechnete Felder)zu entfernen, dann lade ich das Beziehungsbild hoch.
Beim Bearbeiten der Datenbank haben sich folgende Fragen ergeben.
1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung um die Anzahl der Felder in einer Tabelle zu reduzieren.
2) Die Materialeingabe zb in der Kalkulation erfolgt über ein Unterformular (siehe Bild). Derzeit speichere ich beim Verlassen der Dimension die Artikelnummer ab. Die Artikelgruppe, Artikel und Dimension dienen der Suche des Artikels. Derzeit speichere ich aber auch diese drei Felder mit. Könnte ich aber über die Artikelnummer wieder abfragen. Ist das in dieser Form sinnvoll, oder wie schaut hier eine bessere Variante aus um nicht Felder die abgefragt werden können mitzuspeichern. Die Felder müssen aber im Unterformular sichtbar bleiben.


Günther

[MzKlMu]

Hallo,

1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung um die Anzahl der Felder in einer Tabelle zu reduzieren.

Wenn dieser Wunsch besteht hat man mit ziemlicher Sicherheit schon was falsch gemacht. Bei einer korrekt aufgebauten Datenbank sind im Regelfall nicht sehr viele Felder in einer Tabelle.
Ich würde z.B. denken, 30 Felder sind schon zu viel.
Ich habe erhebliche Zweifel, dass das so stimmt. Im Ufo gibt es z.B. eine Artikelgruppe, das ist aber eine Eigenschaft des Artikels und hat somit im Ufo nichts verloren. Schon gar nicht zur Auswahl. Ausgewählt muss der Artikel werden. Sind Hafo und Ufo verknüpft ? Wenn ja, über welche Felder ?

Für weitere Ratschläge wird das Beziehungsbild benötigt.

... und zwar so, dass man alle Felder der Tabellen sieht. Die Felder mit den Tabellen lassen sich größer ziehen.

[Beaker s.a.]

Hallo Günther,

1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung

Wie Klaus schon schrieb, eher nicht.
Für mich machen 1:1-Beziehungen Sinn, wenn es eine typisierte Hauptentität gibt und
die Typen abweichende Eigenschaften haben (z.B. Personen -> Hersteller, Lieferanten,
Kunden, Mitarbeiter).

gruss ekkehard

[gsaccess]

Ich staune immer wieder, wie schnell ich in diesem Forum Antworten bekomme. Vielen Dank, wirklich toll.
Zu deinen Zweifeln mit dem Unterformular:
Die Felder dienen der einfachen Suche von Artikeln. Im ersten Feld sind die Artikelgruppen, im zweiten die Artikel, im dritten die Dimension des Artikels. So lassen sich aus der großen Anzahl der Artikel sehr schnell die richtigen Artikel suchen/auswählen. Nach der Auswahl der Dimension kann die Artikelnummer gespeichert werden. (Siehe Bild Artikelsuche).

In der Anlage auch das Beziehungsbild damit du dir vorstellen kannst woran ich derzeit arbeite. Die Tabelle t_auftraege hat ca. 30 Felder. Meine Überlegung war die im Bild rot markierten Felder in eine eigene Tabelle auszugliedern, da diese den Status des Auftrages betreffen.

Günther

[MzKlMu]

Hallo,
zu den Beziehungen bzw. der Tabellenstruktur könnte man Romane schreiben, so viel gibt es da anzumerken.
Ich fange mal von Links nach rechts an, ohne Anspruch auf Vollständigkeit.
- Wie in vielen Tabellen wurde ein Primärschlüssel angelegt der aber nicht genutzt wird.
Dann kannst Du auch das PS Feld löschen und das Feld für die Beziehung zum PS machen.
- Summenfelder braucht es nicht in den Tabellen
- Bei den Kundenstammdaten sind die Felder für die Kommunikation als n:m Beziehung auszulagern, dazu ist auch eine Tabelle für die Kommunikationsart erforderlich.
- Die Adressen eines Kunden sind auszulagern (mit einer extra Tabelle für PLZ und Ort) mit einem Kennzeichenfeld für die Art der Adresse (Hausanschrift, Lieferanschrift, Rechnungsanschrift etc.)
- Beim Artikel gibt es den Primärschlüssel IDArtikel und gleichzeitig ein Feld ID das für die Beziehung genutzt wird. Warum machst Du dann dieses Feld nicht zum PS .
- Das gleiche gilt sinngemäß für die Tabelle Auftraege.
- Was soll das ReDatum in der Tabelle für die Auftraege ?
- In der Tabelle für die Angestellten ist das PS Feld AngID, das Fremdschlüsselfeld nennt sich dann ArbeiterID, das ist doch verwirrend. Abgesehen davon ist rein formal ein Unterschied zwischen Angestellten und Arbeitern.
- Die Tabelle für die Mahnungen ist falsch. Du brauchst eine Tabelle für die Mahnungsstufen (mit dem unterschiedlichen Mahnungstext) und eine Tabelle zur Zuordung der Mahnstufen zur Rechnung.
- Die Tabelle für die Zeiterfassung ist falsch und unlogisch. Da steht ein Datum drin, gleichzeitig wird auf einen Wochentag bezogen, das Datum legt aber den Wochentag schon fest. Außerdem würde man die Wochentagsfelder nicht für jeden Wochentag erfassen, sondern nur die 4 Zeitfelder mit einem zusätzlichen Feld für den Wochtag als Zahl (1=Mo). Die AZ.. Felder entfallen ersatzlos. Die AZ wird errechnet.
- Die Tabelle auftrag ist völlig unübersichtlich. Mir scheint, das ist die Rechnung. Das mit den Teilrechnungen kann so auch nicht funktionieren. Es kann ja mehr als eine Teilrechnung geben.
- Die Rechnungsanschrift sollte nur ein Fremdschlüssel sein zur Adressentabelle.
Die Rechnungen sind daher auszulagern als jeweisl ein Datensatz (Teilrechnung 1, Teilrechnung 2, Schlussrechnung. Die Mahnungen müssen dann mit der neuen Rechnungstabelle in Beziehung gesetzt werden, denn jede (Teil)Rechnung kann für sich extra gemahnt werden.
- Wieso gibt es in der TAbelle für die Stunden AZStunden  und AzMinuten ?
- In dieser Tabelle gibt es auch eine ArbeiterID aber keine Beziehung
- Es gibt eine Beziehung ohne RI
- Bei den Beziehungen ist in der Regel immer der Typ 1 einzustellen. Das wird bei Bedarf nur in den Verknüpfungen der Abfragen geändert.

Alles in allem finde ich das Datenmodell überladen und unstrukturiert. Da würde ich noch mal von vorn anfangen.

[gsaccess]

Vielen Dank für die rasche und ausführliche Analyse. Für mich heißt das zurück zum Start und die ganze Datenbank neu aufbauen.
Vor ich damit starte noch folgende Fragen:
Ich bin bisher davon ausgegangen, dass es beim Primärschlüssel immer ein Autowert sein sollte. Da dies aber für die Auftragsnummer aufgrund der Länge nicht geht (die Auftragsnummer wird so gebildet << Me.Auftrag_Nr_h = Format(Date, "yymmdd") & Format(Time, "hhmm")>>, habe ich vor die Auftragsnummer eine AuftragsID als Autowert gestellt. Da diese aber wie du richtig schreibst nicht als PS verwendet wird, macht es keinen Sinn.
Nachdem ich mir einige Videos zu den Verknüpfungen angeschaut habe, bzw. in Skripten gelesen habe kann diese Auftragsnummer in der 1:n Beziehung auch als PS verwendet werden.
Das müsste doch zB auch bei der Kundennummer funktionieren wenn ich diese als Primärschlüssel verwende und indiziert ohne Duplikate bei jeder neuen Kundennummer +1 generiere.

Bei der Übernahme in die neu zu konzipierende Datenbank funktioniert meiner Meinung nach der Autowert nicht, da sich zB Auftragsnummer und Kundennummer ja nicht ändern dürfen.

Bin ich da richtig?

Günther

[Beaker s.a.]

Hallo,
@klaus
Manno Mann, das grenzt ja schon an Arbeit (Jobbörse).
Grosses Lob von dritter Seite; - bei solchen Bildern fange ich gar nicht
erst an mir Gedanken zu machen. Ich frage mich immer wie man da als
Entwickler (der der Einzige hier ist, der seine Realität kennt) mit sowas
arbeiten kann.

@Günther

Ich bin bisher davon ausgegangen, dass es beim Primärschlüssel immer ein Autowert sein sollte.

Ist halt das bequemste, s. #8-#11.

abe ich vor die Auftragsnummer eine AuftragsID als Autowert gestellt.

Na also, geht doch.

Da diese aber wie du richtig schreibst nicht als PS verwendet wird, macht es keinen Sinn.

Dann mach sie zum PK.

Auftragsnummer in der 1:n Beziehung auch als PS verwendet werden.

Kann Ja, sollte aber nicht, s. wieder #8-#11; - gilt auch für die KundenNr.

Bei der Übernahme in die neu zu konzipierende Datenbank

Was heisst das? Der Import der jetzigen Daten in das endgültige Datenmodell?
Das geht schrittweise,
- Import der Aufträge, dabei wird die ID (AutoWert) neu vergeben
- Import der abhängigen Tabellen mit dem "alten" FS
- Überschreiben des alten FS mit der neuen ID (Verknüpfung über den alten PK)
Deine eigenen Nummern (jetzt PS) in den Stammtabellen ändern sich dabei ja nicht, nur
die FS.

gruss ekkehard

[MzKlMu]

Hallo,

die Auftragsnummer wird so gebildet << Me.Auftrag_Nr_h = Format(Date, "yymmdd") & Format(Time, "hhmm")>>

Das ist doch sonst nix wie Datum und Uhrzeit. Das geht so:

Code [Auswählen] Erweitern

Me.Auftrag_Nr_h = Format(Now, "yymmddhhnn")Das Kürzel für die Minuten ist nn, nicht mm, mm sind die Monate.
Ein solches Feld ist aber (wegen Format) ein Textfeld und daher als PS nicht so geeignet.
Diese Auftragsnummer gibt es nur in einer einzigen Tabelle, nämlich im Auftrag.
In vom Auftrag abhängigen Tabellen braucht man dann ein extra Feld für den Fremdschlüssel undd as ist eine Zahl (Longinteger) die mit der AuftragsID (dem Autowert) in Beziehung gesetzt wird.
Welchen Wert der Autowert hat ist dabei völlig bedeutungslos, der ist im Regelfall gar nicht sichtbar.
Die Kundennummer kann (in der Kundentabelle !!) extra geführt werden.

Grundregel:
Beziehungen laufen im Regelfall über den Autowert und ein Feld (Longinteger) in abhängigen Tabellen.
Also, im Auftrag gibt es ein Fremdschlüsselfeld zum Autowert (der ID) des Kunden. Im Auftrag selbst gibt es die Kundennummer nicht. Und wie gesagt, Beziehungen immer Typ1.
In Abfragen sind die Linien dann keine Beziehungen mehr, sondern Verknüpfungen, die Verknüpfungen können (müssen aber nicht) sich von den Beziehungen unterscheiden. Und in Abfragen kann dann auch der Beziehungstyp eingestellt werden (INNER-, LEFT-, RIGHT JOIN).

Bei der Übernahme in die neu zu konzipierende Datenbank funktioniert meiner Meinung nach der Autowert nicht, da sich zB Auftragsnummer und Kundennummer ja nicht ändern dürfen.

Doch, da musst Du aber etwas Aufwand betreiben und mit Aktualisierungsabfragen die Daten aktualisieren. Z.B. die Verknüpfungen in den Abfragebn so anlegen wie das jetzt ist und dann die Autowerte in den Fremdschlüsselfeldern aktualiseren. Die alten Fremdschlüsselfelder sind dann zu löschen.

Immer an einer Kopie der Datenbank testen.

Und noch ein Hinweis:
Access mus man lernen und da kann man sich auch nicht an Excel orientieren.
Access ist kein Anwenderprgramm (wie Word oder Excel) sondern eine Programm zum Entwickeln relationaler Datenbanken. Die fertige Datenbank ist dann erst das Anwenderprogramm.

Nachdem ich mir einige Videos zu den Verknüpfungen angeschaut habe,

Von Videos zu Access halte ich nicht viel, ich habe bisher nur wenige gesehen an denen ich nichts zu mecken hätte.
Hier mal ein Link zu den theoretischen Grundlagen:
https://www.hdm-stuttgart.de/~riekert/lehre/db-kelz/
Und hier noch etwas mehr aus der Praxis:
https://www.access-tutorial.de/

[gsaccess]

Danke für eure Tipps. Ich weiß jetzt so ungefähr wo die Reise hingeht.
@ekkehard zu
Ich frage mich immer wie man da als
Entwickler (der der Einzige hier ist, der seine Realität kennt) mit sowas
arbeiten kann.
Ich habe die Datenbank so übernommen und mich noch nicht getraut das Ganze neu aufzubauen, da ich mich mit Access noch nicht so gut auskenne. Eure Tipps haben mich aber ermutigt die gesamte Datenbank neu aufzubauen und dabei die Grundsätze der Normalisierung und der Vermeidung von Redundanzen einzuhalten.

@klaus
Ein ganz besonderes Danke und Lob, dass du dich mit der Tabellenstruktur so intensiv auseinandergesetzt hast.
Ich werde das Beziehungsbild hochladen wenn ich den ersten Teil umgesetzt habe. Ich hoffe, dass ich dann alles so umgesetzt habe wie du es mir in deiner ausführlichen Darstellung beschrieben hast.

Gruß Günther

[Beaker s.a.]

Hallo Günther,

Ich habe die Datenbank so übernommen und mich noch nicht getraut das Ganze neu aufzubauen,

Bevor ich damit anfange räume ich aber erstmal das Beziehungsfenster auf um einen
Überblick zu bekommen.

gruss ekkehard

[gsaccess]

Hallo Klaus,

ich habe nach deiner ausführlichen Beschreibung begonnen die Datenbank neu aufzusetzen. (Siehe Bild)
Folgende Fragen sind aufgetaucht:
1) Bei der tblKommunikationsart ist mir die n:m Beziehung nicht klar - derzeit ist es bei mir nur eine Teilung der tblKunden.
2) Ist es sinnvoll alle Verknüpfungen mit Aktuelisierungs- und Löschweitergabe zu erstellen?
3) Bei sehr kleinen Tabellen zB tblAnrede könnte auch mit dem Nachschlags Assistent gearbeitet werden
ID_AkadGradAlt    AkadGradAlt
1    Ing.
2    Dipl. Ing.
3    Mag.
4    Mag.(FH)
5    Dr.
6    Dkfm.
7    Dipl. Vw
Nachteil sehe ich, dass Ergänzungen vom Anwender nicht gemacht werden können. Ist es ein Problem in einer Datenbank mit so vielen Tabellen zu arbeiten?

LG Günther

[MzKlMu]

Hallo,
die Tabelle "tblKommunikationsart" ist falsch. Die Arten sind keine Feldnamen, sondern Datensätze und die Art ist Feldinhalt.
Dann braucht es noch eine Tabelle zur Zuordnung der Art zum Kunden. Also FS zum Kunden und FS zur Art, erst dann hast Du eine n:m Beziehung.

Ist es sinnvoll alle Verknüpfungen mit Aktuelisierungs- und Löschweitergabe zu erstellen?

Ja, ist meistens sinnvoll.

Weiterhin:
- Der Auftrag hat keine Beziehung zum Kunden.
- Wieso gibt es 2 Tabellen für den akad.Grad ?
- Auf den Nachschageassi würde ich auch bei kleinen Tabellen verzichten.
- Was ist mit einer Tabelle für die Rechnungen ?

Nachteil sehe ich, dass Ergänzungen vom Anwender nicht gemacht werden können.

Über VBA kannst Du programmieren, dass auch der Anwender Ergänzungen machen kann.

Ist es ein Problem in einer Datenbank mit so vielen Tabellen zu arbeiten?

Das Datenmodell muss stimmen, die Anzahl der Tabellen ist dabei relativ bedeutungslos.

[gsaccess]

Hallo,
vielen Dank für deine rasche und fachliche Antwort.
Wie die tblKommunikationsart aussehen soll ist mir noch nicht klar. Vielleicht kannst du mir ein Bild übermitteln wie das aussehen kann.
Bei den Verknüpfungen stelle ich also grundsätzlich Aktualisierungs und Löschweitergabe ein.
Beziehung zwischen Auftrag und Kunde habe ich hergestellt (zeigt mir wie genau du dir das Beziehungsbild anschaust, super - großes Lob!!)
2 Tabellen für den akad. Grad gibt es da die alten akad. Grade(Mag....) in der Adresse vor dem Namen die neuen akad. Grade (BEd...) hinter dem Namen stehen (Önorm 1080),
Die restlichen Tabellen (Rechnung...) bin ich am überarbeiten.

Gruß Günther