Letzten Datensatz eines Unterformulars weiterverwenden

H

Holsteiner90

Benutzer
Beiträge
5
Hallo!

Ich bin neu hier im Forum und benötige Hilfe bei einer bestehenden Microsoft Access-Datenbank. Es geht dabei um die Verwaltung eines Musikinstrumenten-Verleihs eines Musikvereins. Habe eine Datenbank übernommen, die vor einigen Jahren jemand in unserem Verein programmiert hat, der leider inzwischen von uns gegangen ist. Diese Datenbank würde ich gerne weiter pflegen und etwas verfeinern. Ich habe leider nur absolutes Grundlagenwissen und beherrsche keinen VBA-Code, den ich für die Optimierung der Datenbank vermutlich benötige. Ich hoffe, ihr könnt mir hier helfen:

In der Datenbank gibt es ein Formular, in dem die Basisdaten der Musikinstrumente (Hersteller, Modell, Seriennummer, Wert etc.) erfasst sind. In dem Formular gibt es ein Unterformular, in dem die Historie des jeweiligen Instruments erfasst wird, sprich wer wann das Instrument ausgeliehen hat o.ä.

Folgendes möchte ich optimieren:

1. In dem Formular soll es eine Art „Statusanzeige“ geben, die auf dem letzten Datensatz im Unterformular basiert. Wenn beispielsweise der letzte Datensatz des Unterformulars den Vorgang „Ausleihe“ beinhaltet, soll eine rote Textbox im Hauptformular erscheinen, die mit dem Text „verliehen“ beschriftet ist. Wenn beispielsweise der letzte Datensatz des Unterformulars den Vorgang „Rückgabe“ beinhaltet, sollte diese Textbox grün eingefärbt sein und mit „verfügbar“ beschriftet sein. Kann man das realisieren? Wenn ja, wie?

2. Zusätzlich möchte ich einen Bericht erstellen, der eine Übersicht aller Instrumente zeigt. In der letzten Spalte des Berichts soll der aktuelle Status des Instruments angezeigt werden, der ähnlich wie bei meiner ersten Frage auf dem letzten Datensatz im Unterformular basiert. Wie kann man das anstellen?
Zur besseren Verständlichkeit habe ich einen Screenshot beigefügt.

Liebe Grüße und vielen Dank im Voraus,
Holsteiner90

screenshot.JPG
 
Werbung:
Hallo Holsteiner90,
ob Wünsche erfüllbar sein werden, kann man nur beurteilen, wenn man einen Plan deines Datenbankmodells kennt.
Dazu braucht man mindestens ein aufgeräumtes und übersichtliches Bild Deines Beziehungsfensters.
Besser und schneller ist es, wenn man eine Kopie Deiner DB bekommt, in welcher nur anonymisierte Daten vorhanden sind.
Diese Kopie zipped man und sendet sie in diesen Thread.
 
Zu Deiner Frage:
Es ist nicht effizient, einen Status aus historisierten Daten abzuleiten. Kann man für kleine Lösungen oder zum Basteln machen. Hintergrund, die DB muss immer dieses Maximum finden. Mal für ein Datensatz oder dann für viele, bei einer Übersicht. Das ist anstrengend.
Fachlich gehört der Status eines Objekts zum Objekt, nicht zu irgendeinem Unterdatensatz.

Umsetzung:
Statusfeld explizit in der Tabelle des Objekts modellieren, als Integer mit Nachschlagetabelle oder für den Anfang meinetwegen auch als Text.
Datenänderungen werden dann über Trigger oder BusinessOperationen durchgeführt und ändern diesen Status direkt in dem Moment, wo das Objekt seinen Zustand ändert. (gekauft/neu> verfügbar, in Reparatur, verliehen, defekt, .. verkauft…) Nennt man Lebenszyklus. Welche Statusübergänge erlaubt sind, kann/soll man definieren/modellieren.
Eine Historie über die Vorgänge zu führen, ist davon unabhängig.
Auch eine Übersicht ist dann harmlos zu realisieren



Zu Access:
Ich verstehe nicht, warum man sich das antut, wo es kostenlose und Standard konforme DB gibt und kostenlose Programmiersprachen. Noch dazu, wo dieses System weit ab jeglicher Standards arbeitet und ein Umbau auf standardisiertes SQL usw. unglaublich aufwändig ist. Hinzu kommt die Unwägbarkeit, wie der Anbieter das Produkt zukünftig weiterentwickelt und bepreist. Bei Access hat es bereits mehrere massive Brüche in der Funktionalität gegeben. Mal ganz abgesehen von dem 365 Kram. Dann noch einen Schritt weiter in der Überlegung: Warum erlerne ich ein System, wo ich mit dem Wissen irgendwann nichts mehr anfangen kann? Minimalvoraussetzung wäre m.E. ein langfristiger, sicherer Job, der das vertretbar macht.
 
evar46 schrieb:
Hallo Holsteiner90,
ob Wünsche erfüllbar sein werden, kann man nur beurteilen, wenn man einen Plan deines Datenbankmodells kennt.
Dazu braucht man mindestens ein aufgeräumtes und übersichtliches Bild Deines Beziehungsfensters.
Besser und schneller ist es, wenn man eine Kopie Deiner DB bekommt, in welcher nur anonymisierte Daten vorhanden sind.
Diese Kopie zipped man und sendet sie in diesen Thread.
Zum Vergrößern anklicken....

Hallo evar46,

ich habe mal einen Screenshot von den Beziehungen beigefügt.
Eine anonymisierte Datenbank zu erstellen ist nicht ganz so einfach, da sich inzwischen mehrere hundert Datensätze darin befinden, und diese alle mit "echten" Namen. Aber vielleicht reicht der Screenshot ja aus.

Liebe Grüße und vielen Dank,
Holsteiner90

beziehungen.JPG
 
Hallo Holsteiner90,
Ich geb Dir mal eine Version, welche Dir verschiedene Queries (Abfragen) anbietet und welche vermeidet,
dass man in Stammdatentabellen dauernd den Inhalt eines Feldes verändert (verletzt die Regeln relationaler Datenbanken).
Schau Dir mal die Abfragen an, welche als Datenherkunft für Dein UFO funktionieren. Man kann sie per VBA einfach umschalten auf Wunsch.
Ob Du da noch unbedingt eine farbliche Änderung drin haben willst, kann man z.B. über die bedingte #formatierung
Mein DB-Modell ist nicht 100%ig identisch zu Deinem, weil ich Namen für Objekte vermeide, welche Access schon selber verwendet (Datum oder Name usw.)
Mal sehen, ob Dir das hilft. Farn´bliche Darstellungen sind dann durch Bedingte Formatierung einfach darstellbar.
 
Hier nun mein Beispiel. Ich hab Dein Beispiel nur rudimentär nachgebildet. Das anzupassen dürfte kein großes Problem sein.
 

Anhänge

  • InstrumentenVerleih_2.zip
    44,4 KB · Aufrufe: 3
@dabadepdu:
Dein Zitat: ...Fachlich gehört der Status eines Objekts zum Objekt, nicht zu irgendeinem Unterdatensatz....
Dem widerspreche ich, wenn es sich um Access als relationales Datenbanksystem handelt und
das StammdatenObjekt nur statische Daten enthalten muss.
Da wäre der Hinweis wichtig, dass man die Möglichkeiten von m:n Tabellen dort einsetzen muss,
um möglichst flexibel sein zu können.
 
evar46 schrieb:
Dem widerspreche ich, wenn es sich um Access als relationales Datenbanksystem handelt und
das StammdatenObjekt nur statische Daten enthalten muss.
Da wäre der Hinweis wichtig, dass man die Möglichkeiten von m:n Tabellen dort einsetzen muss,
um möglichst flexibel sein zu können.
Zum Vergrößern anklicken....
Die Spielregeln für relationale Datenmodellierung sind für Access auch nicht anders.
Ich bleibe bei meiner Grundaussage. Ein Status gehört zu einem Objekt. Daran ändert auch eine n:m Relation nichts. Die kann meinetwegen auch einen Status haben, wenn nötig.
Der Kern meiner Aussage betraf auch gar nicht so sehr die Modellierung, sondern den Skalierungseffekt im angefragten Fall. Es ist klar, dass die Verleihtabelle immer größer wird. Und es liegt auf der Hand, dass alle Operationen, die sich um den Status drehen, immer auf dieser stetig wachsenden Tabelle arbeiten müssen und dort Aggregatabfragen ausführen. Das ist auf Dauer nicht gut.

In der Praxis ist die perfekte Normalisierung aber auch selten. Es geht mir nicht darum, ein wissenschaftliches Modell zu fordern, sondern ein praxistaugliches. In der Praxis kann es sein, dass die von mir genannten Probleme niemals auftauchen, weil einfach beim Thema "Instrumentenverleih" viel zu wenig Daten anfallen.
 
Zitat von dabadepdu:
...In der Praxis ist die perfekte Normalisierung aber auch selten..
Zum Vergrößern anklicken....
Eine unsinnige Übernormalisierung liegt hier nicht vor, denn es werden keine Stammdaten unsinnigerweise in zuviele Tabellen aufgeteilt.
Es handelt sich darum, dass grundsätzlich Bewegungsdaten nicht in Stammdatentabellen gehören. Das ist ja wohl kein Normalisierungsproblem.
Das ist praxistauglich und sicher und keine wissenschaftlich orientierte Störrigkeit.
Bei richtiger Indexierung der Daten sehe ich keine Probleme, die per SQL Aggregierungen entstehenden Queries-Ergebnisse,
welche nicht vermeidbar sind, bezüglich der dortigen historisierten Statuszustände entsprechend aufbereitet in einem Formular
ohne spürbaren Zeitverlust anzeigen zu können. Zu Ende ist das Ganze ja sowieso bei 2gByte Datenbankgröße.
Bis dahin passen aber locker ein paar Millionen Datensätze rein.
Dass es größere Datenbanken gibt, welche aber auch komplexer und komfortabler sind, ist bekannt.
Wir werden wohl nicht zusammenkommen, fürchte ich.
 
evar46 schrieb:
Eine unsinnige Übernormalisierung liegt hier nicht vor, ...
Wir werden wohl nicht zusammenkommen, fürchte ich.
Zum Vergrößern anklicken....
Na zur Normalisierung gibt es ein Regelwerk. Und es macht Sinn. Was eine Unsinnige Übernormalisierung ist, sei mal dahin gestellt.
Ich habe ja bereits geschrieben, dass in der Praxis aus verschiedensten Gründen der formale Weg verlassen werden kann.
Und wir müssen auch nicht zusammenkommen, kein Problem. Der TE darf sich was aussuchen.
 
Werbung:
Abschliessend gesagt wird der TE einen erheblichen Aufwand gegen den Missbrauch von Eintragungen haben.
Da wird wohl nur VBA in Access ihm unterstützend helfen.
Sollte der TE das Thema als erledigt markieren wollen, sollte er das tun.
 
Zurück
Oben