Fragen zur Herangehensweise an Formular zur reinen Anzeige von Attributen

[Popeye99]

Hallo Access Spezialisten

ich bin selber ziemlicher Neuling was Microsoft Access angeht und habe daher bzgl. meiner Idee mindestens eine Frage der Umsetzung.

Ziel ist es ein Formular für Mitarbeiter zu erstellen mithilfe dessen sie die Attribute für unterschiedliche Statuscodes mehrerer Tabellen nachschauen können.
Die Mitarbeiter die mit dem Formular arbeiten sollen fügen keinerlei Daten hinzu und sollen diese auch nicht bearbeiten können. Wichtig ist nur daß sie gezielt eine der Tabellen wählen können und sich dort anhand der Eingabe des Primärschlüssel (Nummerierte "Statuscodes" in diesem Fall) die dem Wert dazugehörigen Attribute anzeigen lassen. Im besten Fall haben die Mitarbeiter nachher nur eine accdb Datei die durch Doppelklick sofort in die angedachte Maske/Formular springt

Ich habe das mal kurz aufgemalt, wie ich mir das vorstelle:
Beispiel für Formular Oberfläche

Frage wäre einerseits ob das machbar klingt oder ich da irgendwo einen fundamentalen Denkfehler habe. Und zweitens vielleicht einen guten Ansatz wie ich dieses Formular anlege oder worauf ich achten muss.

[andyfau]

Hallo Popeye99,

ich würde wie folgt vorgehen:
- für jede der 3 Tabellen eine Abfrage erstellen (* alle Felder) plus den Tabellenname als eigene Spalte (Tabname:"zBTabelle1")
Dadurch bekommst Du eine Ergänzung deines Primärschlüssels mit dem Tabellennamen hin. Notwendig damit Du eventuell gleiche Statuscodes später trotzdem als Einzelsätze vorliegen hast.
- diese drei Abfragen dann in einer Unionabfrage zusammenführen. (Hierbei werden gleiche Feldnamen in den 3 Tabellen vorausgesetzt!)
 

Code [Auswählen] Erweitern

SELECT Tab1.*
FROM Tab1
UNION
SELECT Tab2.*
FROM Tab2
UNION SELECT Tab3.*
FROM Tab3;
- Diese Unionabfrage ist dann die Grundlage für dein Formular.
- Für das Kombifeld würde ich noch eine Minitabelle mit den Tabellenname anlegen oder einfach ein zweispaltiges Kombifeld mit der Unionabfrage als Datenquelle. Die Attributfelder ergeben sich dann automatisch.

Viel Spaß beim tüfteln und beste Grüße
Andreas

[MzKlMu]

Hallo,
@Popeye99 Die von Dir angedachte Struktur ist falsch. Auch von Unionabfragen ist hier dringend abzuraten.

Warum sind das 3 Tabellen und was ist der Unterschied der 3 TAbellen ?

Hier liegt eine ganz klassische n:m Beziehung vor.

- eine Tabelle für den Status
- eine Tabelle für die Atribute (nicht in 7 Feldern, sondern als 7 Datensätze)
- eine Tabelle für die Zuordnung der Atribute

Erkläre das Vorhaben mal genauer.

[DF6GL]

Hallo,

m. M. nach gibt es einen "einen fundamentalen Denkfehler".


Die 3 (oder mehr gleichartigen) Tabellen gehören zu einer zusammengefasst. Die Unterscheidung, von welcher Tabelle die Daten gekommen sind, führt man in einer weiteren Tabelle, z. B. "tbStatusArt", die die Bedeutung der Tabellennamen enthält.

Diese beiden Tabellen stehen als 1-n-Beziehung miteinander über die Schlüsselfelder in Beziehung.

Wenn ein konkretes Datenbeispiel (Tabellennamen, Feldnamen, Feldinhalt ) hier vorläge, könnte eine  konkrete DB-Demo erstellt werden.

[Popeye99]

Es geht prinzipiell um 3 verschiedene Maschinentypen, die jedoch alle mit einem Statuscode Set von sagen wir mal 0-100 arbeiten. Während aber z.b. der Statuscode 50 von Maschine 1 (=Tabelle 1) bei "Attribut 1" einen Wert von "A" hat, hat aber Maschine 2 (=Tabelle 2) bei "Attribut 1" einen anderen Wert, z.B.  "B"  oder "F" usw.
Die Unterteilung in unterschiedliche Tabellen hielt ich für sinnvoll, um die Datenbank relativ unkompliziert um einen 4ten oder 5ten Maschinentyp erweitern zu können ohne Bestehendes anpacken zu müssen.

Der Anwendungsbereich ist dafür gedacht, daß wenn ein Mitarbeiter den Statuscode einer der Maschinentypen gemeldet bekommt, er sofort die passenden Attributswerte nachschauen kann.

[Popeye99]

ich versuche mal die grundlegenden 3 Tabellen mit konkreten Tabellennamen, Feldnamen und Inhalt anzulegen, so daß es da konkretere Fragestellungen ermöglicht

[MzKlMu]

Hallo,

... um die Datenbank relativ unkompliziert um einen 4ten oder 5ten Maschinentyp ...

genau das Gegenteil ist der Fall.
Eine neue Maschine in einer neuen Tabelle würde die Anpassung aller Objekte (Formulare, Abfragen, Berichte erforderlich machen.
Sind alle Maschinen in einer Tabelle, ist eine neue Maschine ein neuer Datensatz, fertig.

PS:
Das zitieren vollständiger Beiträge ist unerwünscht. Zitate verlängern unnötigerweise die Themen. Und wie Du siehst, geht auch ohne Zitate nichts verloren, man weis auch so genau was gemeint ist.

[andyfau]

Hallo,
in meinem Beitrag bin ich davon ausgegangen, dass die drei Tabellen bereits als gegeben vorhanden sind und die Schwierigkeit darin besteht diese zusammenzuführen und dann anzuzeigen.
Wenn die Datenbank insgesamt noch in der Entstehung ist, sollten die Tabellen, genau aus den genannten Gründen von Klaus, nach den Regeln der Normalform angelegt werden, bevor man sich an Formulare, Abfrage, etc. macht.
Vielleicht hilft der folgenden Link:
https://www.datenbanken-verstehen.de/datenmodellierung/normalisierung

Beste Grüße
Andreas

[Popeye99]

Die Tabellen bestehen bereits Nur wie ihr schon gemerkt habe arbeite ich hier mit Platzhaltern wie "Maschinentyp" und "Attribut" etc. da ich die Tabellen leider aus Datenschutzgründen nicht in Klartext hier reinsetzen kann. Daher hatte ich vor von den Tabellen Kurzversionen zu erstellen, die aber in der Struktur gleich sind und halt nur mit Platzhaltern arbeiten. Mir geht es ja um das prinzip, daher ist es ja irgendwo wurst ob ich jetzt mit einer Tabelle mit 5 oder 500 Statuscodes arbeite

[ebs17]

Die Unterteilung in unterschiedliche Tabellen hielt ich für sinnvoll, um die Datenbank relativ unkompliziert um einen 4ten oder 5ten Maschinentyp erweitern zu können ohne Bestehendes anpacken zu müssen.

Genau das ist das Ziel einer vernünftigen Datenmodellierung und Planung.
Statt bei Erweiterung eine weitere Tabelle mit gleichen Eigenschaften hinzuzufügen gönnt man der einen Tabelle ein weiteres Feld, auf welchen Typ sich die Eigenschaften beziehen. So muss man bei neuem nur Datensätze anfügen statt neue Tabellen einzubinden, womöglich "komplex, dynamisch, intelligent", alles das, was jeder aus dem Stegreif so gut beherrscht ...

Die Tabellen bestehen bereits

Es wäre im Fall des Falls ein Riesenproblem, wenn da eventuell umstrukturiert werden müsste, weil sich da jemand wichtiges Gedanken in einer falschen Weise gemacht hat?

Mir geht es ja um das prinzip

Dazu zeigt man vor allem das Beziehungsbild (Datenmodell). Tabellen- und Feldnamen verstoßen in den alterseltensten Fällen gegen den Datenschutz, helfen aber im Überblick zu einem Verständnis des Ganzen.

Also beginne damit, das richtige Bild zu zeigen.

Art und Weise von anzeigenden Formularen bauen dann auf den geplanten Tabellenstrukturen auf wie ein Haus auf dem Fundament.

[MzKlMu]

Hallo,

.. Datenschutzgründen nicht in Klartext ...

wenn sich aus Tabellen und Feldnamen Betriebsgeheimnisse ableiten lassen, hat man in den meisten Fällen bereits einen Fehler in der Struktur gemacht.

[Beaker s.a.]

Hallo,
Wenn ich das Bild des TS richtig interpretiere, wird man wohl
mehr als drei Tabellen benötigen. Es gibt ja schon alleine drei
Entitäten  - Maschinen, Status und Attribute.
Leider muss ich jetzt weg. Ich denke aber später noch mal darüber
nach. Falls es bis dahin nicht schon ein anderer gemacht hat.

gruss ekkehard