Tabellen ohne Referenz in Access-Formular zusammenführen

[Beaker s.a.]

Hallo Schanko,

Da es wie gesagt funktioniert und du mir bis jetzt leider auch noch nicht logisch dargestellt hast, warum ich meinen Aufbau denn zwingend so anpassen muss, wie du es im Kopf hast, lasse ich es auch erstmal so.
Ich möchte dich hier nicht angreifen, ich verstehe einfach nicht, warum es nur EINE Lösung geben soll?!

Is' aber so, - siehe Klaus' letzte Antwort und, vor Allem, das was du in seinen Links
nachlesen kannst.
Bei deinem nächsten Problem, kommt mit "lasse ich es auch erstmal so" garantiert,
wirst du als Erstes wieder darauf hingewiesen werden, das dein Datenmodell nicht
stimmt. Und je später du das einsiehst je mehr Aufwand und Probleme kommen auf
dich zu. Ausserdem wird die ganze Entwicklung der Anwendung (Abfrage/Formuale usw.)
SEHR viel einfacher mit einem korrekten Datenmodell.
Ich will dich wirklich nicht entmutigen, aber IMO musst du nach deinem letzten Post
wirklich noch mal ganz von vorne anfangen. Ihr wollt am Ende auch "Spass" mit deiner
Anwendung haben. Und wenn die Basis stimmt wirst du auch sehen, wie viel Spass das
Lernen von Access/VBA beim Entwickeln der Anwendung machen kann (Motivation
vorausgesetzt).
Und wenn dann irgendwann Cheffe bei dir ankommt und fragt "Ich bräuchte noch
diese Auswertung oder jene Funktion, geht das?" schaust du dir dein (korrektes) DM
an, lächelst ihn an und sagst: "Klar, zeige ich Ihnen übermorgen." 
Also frisch ans Werk, Hilfe bekommst du hier sicher auch weiterhin.
gruss ekkehard

[Der_Schanko]

Guten Abend,

zunächst noch einmal danke für eure Rückmeldungen.

Ich habe mir heute schon mal angefangen die Links anzuschauen.

Werde die ganzen Daten jetzt erstmal übergangsweise "manuell" speichern und meine DB überdenken und neuplanen.

Wahrscheinlich ist der Einstieg in Access mit so einer DB nicht unbedingt optimal, aber mit eurer Hilfe packe ich das sicherlich.

Wie gesagt werde ich meine Tabellenstruktur noch einmal überdenken (nachdem ich mich mit den ganzen Informationen beschäftigt habe, die ich hier schon erhalten habe.)

Ich melde mich auf jeden Fall wenn meine neue Struktur fertig ist!

Schönen Abend
Schanko

[crystal]

Hallo Schanko,

laß dich nicht entmutigen. Viele Pofis betrachten die Normalisierung als unumstößliches Gesetz, als conditio-sine-qua-non (Voraussetzung ohne die nichts geht) und die Verletzung dieses Gesetzes als höchst zu bestrafen.

Du kommst vermutlich von Excel und da beschäftigt man sich eher selten mit Normalisierung und scheut sich auch nicht, Redundanzen (mehrfach vorkommende Werte) in den Tabellen zu haben; dabei darf das Wort Tabelle nicht mit dem Begriff Tabelle bei (relationalen) Datenbanken verwechselt werden.

Excel führt anschaulich Daten zusammen, die in eine Tabellenzeile gehören, wobei jede Spalte ihre Überschrift hat. Es ist dabei immer noch EINE Tabelle, so wie man sie auf einem Batt Papier oder als Formularbuch entwerfen würde.

Die Normalisierung auf dem Weg zu einer relationalen Datenbank besteht nun darin, sich mit den Inhalten der Excel-Tabellen-Spalten zu beschäftigen und sich zu fragen, ob es hier wiederkehrende Werte gibt, wie z.B. eine Personal-Id. Diese lagert man dann in eine zweite Datenbank-Tabelle aus (ohne Duplikate) und speichert in der Haupttabelle nur noch den Verweis (Referenz) auf die zweite. Somit hat man prinzipiell die Möglichkeit, auch auf andere Daten der zweiten Tabelle zuzugreifen (Name, Vorname etc.). [Sowas könnte man auch in Excel machen, indem man in der Spalte Personal-Id Daten nur über ein Pulldown-Feld auswählbar macht. Schon wäre dann bezüglich dieses einen Feldes eine relationale Tabellen-Struktur entstanden. Man könnte Excel-Anwendungen also durchaus relational und normalisiert gestalten, aber es werden dann noch immer keine internen Mechanismen bereitgestellt, die relationale Datenbank-Systeme auszeichnen (referentielle Integrität, Abfragen über mehrere Tabellen mit verknüpften/referenzierten Werten usw.)]

Ich glaube, dein eigentliches Problem ist es, anschaulich und übersichtlich darstellen zu können, welche Geräte an welchem Tag unter wessen Schichtleitung von welchen Mitarbeitern genutzt wurden usw. Dies ist also einfach nur eine Frage der Darstellung!

Angenommen du speicherst, wer zu einem Zeitpunkt ein Gerät (oder eine Geräte-Kombination) bekommt. Zusätzlich hast du gespeichert, welche Schicht das war und wer Schichtleiter.

Um nun eine übersichtliche Darstellung zu bekommen, musst du z.B.
>> in der Geräte-Tabelle nachschauen, wie die Stick-Ids lauten
>> in der Mitarbeiter-Tabelle den Namen nachschlagen
>> in der Schicht-Tabelle den Gruppenleiter holen
usw.

Hört sich aufwändig an. Ist es aber nicht, weil es in Access problemlos möglich ist, eine solche Fragestellung an die Datenbank zu richten. Du tendierst eher dazu, diese Daten gleich bei Eingabe, so wie man sie am Bildschirm sieht, abzuspeichern (wie Excel es machen würde).

Und hier entsteht das Problem, das Access-Profis sofort kritisieren. Die Lösung deines Problems besteht aber einfach nur darin, eine vernünftige Datenbasis zu konstruieren (Datenmodell) und dir passende Abfragen zusammenzusetzen, die deinen (Darstellungs-)Wünschen entsprechen. Viele Profis fordern aber, dass du zunächst ein "Normalisierungs-Seminar" mit mindestens der Note "Gut" abschließt.

Es ginge aber durchaus auch anders, wenn man pragmatisch (und unter Missachtung der "Gesetze") vorgeht und sich fragt:
1. Welche Lebensdauer haben Wer-was-wann-Datensätze?
2. Ist es erforderlich, z.B. nach einem Jahr zu wissen, wer damals welches Gerät hatte?
3. Wie oft ändert sich die Person des Schichtleiters?
4. Wie oft ändert sich die Gruppierung von Geräten (Handheld + Drucker)?
usw.

Ich vermute, dass viele dieser Daten nach kurzer Zeit (z.B. 2 Monaten) völlig uninteressant werden und deshalb plädiere ich für eine teilweise De-Normalisierung.

Speichere die Basisdaten (Personal, Geräte, Kombis usw.) in einzelnen Tabellen. Baue ein Formular, das aus diesen Tabellen IDs und Klartexte holt und speicher das in einer neuen Tabelle. Vielleicht ist Schichtleiter heute Herr Schmidt und morgen Frau Schulze. Statt nun eine komplizierte Schicht-Tabelle mit Zeiträumen zu bauen, kannst du das auch in eine kleine Tabelle mit genau einem Datensatz "Wer ist gerade Schichtleiter" schreiben und den Namen redundant unter Missachtung aller Normalisierungs-Regeln in der Wer-wann-was-Tabelle speichern.
Und sollte jemand einmal fragen, wie oft Geräte nicht rechtzeitig zurück gegeben wurden, wenn xyz Schichtleiter war, ist das auch noch möglich.


Ich möchte betonen, dass das skizzierte Vorgehen keine hoch-professionelle Lösung ist und ein paar Dinge dabei unberücksichtiegt bleiben. Es ist eine pragmatische Lösung, die sich daran orientiert, was der Fragesteller (vermutlich) möchte und für die tägliche Arbeit braucht. Klein und fein, mit Knopfdruck abrufbar. Es ist ein Kompromiss zwischen sinnvoller Normalisierung und praktischem Nutzen, aber auch zwischen der Offensichtlichkeit einer Excel-Tabelle und einer vielleicht verwirrenden Sammlung von Tabellen und Abfragen in Access. Und es ist ein kleiner Versuch, dem Fragesteller das Thema Normalisierung anschaulich näher zu bringen und ihm gleichzeitig Mut zu machen, darauf teilweise zu verzichten. Und ich weiß, dass ich dafür negative Kritik erhalten werde...

[Der_Schanko]

Hallo zusammen,

ich habe mich mit den geposteten Links beschäftigt und versucht meine Tabellenstruktur zu überarbeiten.
Ihr findet meinen Entwurf im Anhang.

Zur Erläuterung:

• In tblMitarbeiter wird die Zuordnung Gruppenleiter & Schichtleiter über ein JA/NEIN Feld definiert.
• In tblBereich werden die Gruppenleiter über die MitarbeiterID definiert
• Jeder Mitarbeiter besitzt einen Schlüssel. Eine Schlüsselnummer kommt immer in zweifacher Ausführung vor (Früh- und Spätschicht). Dies muss als gegeben hingenommen werden. Eine Schlüsselnummer (zwei Schlüssel - zwei Mitarbeiter) werden immer genau einem Fach zugeteilt in das später die Handhelds und Drucker gelegt werden.
• Die Schichtleiter in tblSchicht sind durch die MitarbeiterID definiert

Dazu ist eine extra Tabelle erforderlich die Handheld und Drucker kombiniert (Gerätegruppe)

Die Tabellen für die Mitarbeiter- und die Gerätergruppen sind (wie man sieht) geplant. Allerdings weiß ich nicht wie ich diese mit den anderen Tabellen verknüpfen soll. Zwei Beziehungen zwischen Tabellen funktionieren ja nicht.
Außerdem weiß ich nicht welche felder in diesen Tabellen auftauchen müssen.

Meine Vermutung:
Um Redundanzen zu vermeiden würde ich in der "Gruppentabellen" nur die jeweiligen IDs verknüpfen.
Den Rest sollte sich Access doch eigentlich über die definierten Beziehungen ziehen können?!

laß dich nicht entmutigen. Viele Pofis betrachten die Normalisierung als unumstößliches Gesetz, als conditio-sine-qua-non (Voraussetzung ohne die nichts geht) und die Verletzung dieses Gesetzes als höchst zu bestrafen.

Nein entmutigen lasse ich mich so schnell nicht. Ich bin auch durchaus gewillt diese Normalisierung zu erlernen und einzuhalten. Mir ist es jedoch extrem wichtig zu verstehen, warum ich etwas nach bestimmten Richtlinien machen soll. Hierbei haben die zusätzlichen Erläuterungen und die angefügten Links schon sehr geholfen!

Ich hoffe das kann man auch anhand meiner Tabellenstruktur erkennen.

Ich bin gespannt auf euer Feedback!

LG Schanko

[Beaker s.a.]

Hallo Schanko,
Siehste, wird doch.
In die Gruppentabellen gehören diese Fremdschlüssel nicht, da gehören nur die Attribute
der Gruppen hinein.
Um diese Tabellen mit den anderen beiden Tabellen (MA und Geraete) zu verbinden musst
du noch zwei Tabellen anlegen (MitarbeiterZuMAGruppe und GeraetZuGGruppe).
Diese erhalten ausser einem PK (Autowert) nur je zwei FK-Felder für die PK aus Mitarbeiter
und Geräte. Das nennt man eine n:m-Tabelle.
Ergebnis: ein MA kann zu n Gruppen gehören, und jeder Gruppe können n MA zugeordnet
sein. Für Geraete und deren Gruppen gilt es entsprechend.
Für die Zukunft; - wenn du irgendwo auf nummerierte Felder triffst, gehören diese als ein
Datensatz in eine neue Tabelle.
gruss ekkehard

[Der_Schanko]

Hallo ekkehard,

In die Gruppentabellen gehören diese Fremdschlüssel nicht, da gehören nur die Attribute
der Gruppen hinein.

Ich hoffe das habe ich jetzt richtig umgesetzt.
Aber um erhlich zu sein verstehe ich noch nicht ganz, warum ich das jetzt gemacht habe.
Vielleicht könntest du mir das noch einmal in kurzen Sätzen erklären?

Für die Zukunft; - wenn du irgendwo auf nummerierte Felder triffst, gehören diese als ein
Datensatz in eine neue Tabelle.

Was meinst du damit?

Sollte meine Struktur jetzt korrekt sein, kann ich mich doch an den Entwuf der Formulare machen oder?
Muss ich für das Festlegen der Mitarbeitergruppe und der Gerätegruppe jeweils ein eigenständiges Formular machen?
Oder kann ich diese Zuordnung in einem Endlosformular vornehmen?

Meine Vermutung:
Getrennte Formulare.
Wenn ja, wie führe ich Sie für den Benutzer zusammen?

Anbei mal meine DB und die Tabellenstruktur.
Die DB habe ich natürlich um Unternehmensdetails kürzen müssen.
Alle Werte sind natürlich frei erfunden, stellen in Ihrer Struktur aber die Ausgangslage dar.

Edit1:
Auf welcher Basis baue ich denn mein Formular am besten auf (Zuordnung MA & Geräte).
Probiere gerade rum, will aber nicht so wirklich funktionieren...

Edit2:
Ich habe die Beziehung zwischen tblZuordnungMitarbeitergruppeZuGerätegruppe und tblMitarbeitergruppe bzw. tblGerätegruppe in eine 1:1 Beziehung geändert, da jedes Mitarbeiter-/Gerätepaar nur einmal in der Zuordnung vorkommen darf!

LG
Schanko

[Beaker s.a.]

Hallo Schanko,
So wie ich das sehe, sollte das so passen.
In der Anlage ist jetzt auch eine .mdb dabei. Da können sich andere
(bessere) das auch mal anschauen.
Zuordnungen erfolgen meist in Unterformularen.
gruss ekkehard

[Der_Schanko]

Guten Morgen,

sehr gut, hab gestern auch schon ein bisschen weiter damit gearbeitet und das ein oder andere Testformular erstellt (Nichts was man hier vorzeigen müsste  )

In der Anlage ist jetzt auch eine .mdb dabei.

Ich weiß gerade nicht, ob ich dich richtig verstehe. Meinst du meinen oder deinen Anhang ekkehard?
Bei dir finde ich nämlich nichts... 

Was mir jetzt fehlt ist eine strukturierte Vorgehensweise, wie ich letztenendes an mein Ergebnis komme.
Wie erstelle ich Geräte- bzw. Mitarbeitergruppen. Ich habe zwar die benötigten Tabellen, weiß aber noch nicht, wie ich diese einsetzen muss...
Im Prinzip werden die Gruppen ja in den Tabellen tblMitarbeiterZuGruppe und tblGerätezuGruppe erstellt. Hier führe ich ja jeweils die MitarbeiterID bzw. GeräteID auf und vergebe für ein Paar immer eine Gruppennummer, die dann in tblMitarbeitergruppen und tblGerätegruppen als Primärschlüssel eingetragen wird.
Hierbei würde aber noch manueller Aufwand entstehen, weil ich ja in letztgenannter Tabelle erstmal ein paar Nummern erzeugen müsste.

Mein Ansatz für ein Formular (frmGerätegruppenErzeugen) würde wie folgt aussehen:

• Datensatzquelle für zB die Gerätegruppen wäre eine Abfrage qryGeräte (Zusammengesetzt aus tblGeräte & tblGeräteart)die alle notwendigen Gerätedaten beinhaltet (Seriennummer, Name, Geräteart)
• Im Endlosformular selbst kann der Anwender nun immer zwei Seriennummern (1xHandheld & 1xDrucker) zueinander zuordnen. Dies ergibt eine Gerätegruppe.
• Der Tabellstruktur zufolge muss für diese Gerätegruppe immer eine ID erzeugt werden, die in tblGerätegruppen gespeichert wird. Hier wird es interessant: Meinem aktuellen Verständnis nach müsste der Primärschlüssel in der tblGerätegruppen erzeugt werden und nicht in einem Formular. Hilfreich wäre hier eine etwas detailliertere Beschreibung oder ein Beispiel in der angehängten DB.
• Sobald ich die Mitarbeiter- und Gerätegruppen in eigenständigen Formularen erzeugt habe, gilt es ja diese ebenfalls miteinander zu verknüpfen. Hier das gleiche Spiel wie zuvor...Ich habe keine richtige Vorstellung wie ich an dieses Thema herangehen muss.

Sollten meine Ansätze in der Aufzählung falsch sein, so möchte ich noch einmal meinen ersten Gedanken zur Zuordnung in einem einzigen Formular aufführen(vielleicht geht das ja auch, ich sehe es nur nicht:

• Endlosformular
• In einer Zeile des Formulars wird das Gerätepaar und das Mitarbeiterpaar festgelegt

Aufbauend auf diesem Formular könnte ich ja dann verschiedene Berichte generieren (wie zB ein Übersicht über die Geräte- & Mitarbeiterzuordnung inkl. Schlüsselnummer, Fach, Bereich & Bauteil)

Ich hoffe weiterhin auf eure Hilfe!

LG Schanko

[Beaker s.a.]

Hallo,
Na super, ich mal wieder  - jetzt aber ...
gruss

[DF6GL]

Hallo,,
seit ihr sicher, dass dieses Beziehungsmodell der Aufgabe gerecht wird?

[Beaker s.a.]

Hallo Franz,
Nicht wirklich muss ich zugeben 
Bin z.Zt. mit dem Kopf immer irgendwie woanders.
Was meinst du, die Tabelle "tblZuordnungMitarbeitergruppeZuGerätegruppe"
eher direkt mit den MA verknüpfen (tblMitarbeiterZuGeraeteGruppe) also
FK IngMitarbeiterID (um bei seiner Notation zu bleiben) statt lngMitarbeiterGruppeID?
gruss ekkehard

P.S. Vielleicht sollte ich mich lieber raushalten, wenn ich Probleme mit der Abstraktion
der abzubildenden (fremden) Realität habe.

[DF6GL]

Hallo,

ich will mich jetzt nicht sehr hier einmischen und den ganze Thread nachvollziehen, habe nur anhand des Beziehungsschemas keine durchgängige Logik erkannt. Soll heißen, was damit dargestellt werden soll, ist mir unklar.

[Beaker s.a.]

Hallo Franz,

Soll heißen, was damit dargestellt werden soll, ist mir unklar.

So hätte ich mein P.S. auch formulieren können 
Ich hatte das aus diesem "entwickelt" (#14)

Zitat

•Es gibt einen Pool an Handhelds & Druckern, die immer paarweise ausgehändigt werden

Dazu ist eine extra Tabelle erforderlich die Handheld und Drucker kombiniert (Gerätegruppe)

Zitat

•Es gibt den Mitarbeiterstamm, der sich über die verschiedenen Schichttypen verteilt. In der Regel arbeiten also zwei Mitarbeiter (jeweils aus einer Schicht) mit ein und dem selben Paar Handheld+Drucker

Gleiches wie zuvor. Du bildest über die beiden Mitarbeiter eine Gruppe mit einem Primärschlüssel und die Mitarbeitergruppe wird dann der Gerätegruppe zugeordnet.

Beim letzten Absatz habe ich aber nicht aufgepasst, - muss 1:n statt n:m.
Korrektur anbei.
Würde mich freuen wenn du es dir nochmal anschaust.

nicht sehr

Vielleicht ein bisschen? 
gruss ekkehard

[DF6GL]

Hallo,

vielleicht wäre es erst sinnvoll, die Anordnung der Tabellen im Beziehungsfenster so zu ordnen, wie ich es dargestellt habe. Jeweils die 1-Tabellen links der zugehörenden n-Tabelle platzieren und entspr. "Spalten" zu binden.  Dann wäre die Übersichtlichkeit der Zusammenhänge viel besser....   


Es ist nicht nur die 1:1- Verbindung, auch die Nicht-Verwendung der m:n-Tabellen ist zu hinterfragen.

[Beaker s.a.]

Hallo Franz,

vielleicht wäre es erst sinnvoll, die Anordnung der Tabellen im Beziehungsfenster so zu ordnen, wie ich es dargestellt habe

Hat wohl jeder so seinen eigenes Verständnis.
Mit den Tabellen (bei dir links, bei mir gar nicht im Bild) hatte ich mich noch nicht
beschäftigt.

Es ist nicht nur die 1:1- Verbindung

Das würde ich so auflösen (s. Anlage)

auch die Nicht-Verwendung der m:n-Tabellen ist zu hinterfragen.

Welche? Die Zuordnung MAGruppen zu GeraeteGruppen?
Lässt sich ja wieder herstellen.
gruss ekkehard