Office: (Office 2010) Datenmakro?

Liebe Access-Profis,

ich braue eine Idee, einen Wegweiser!
In meine DB verwalte ich den Einsatz von Lehrkräften. Nun fallen Lehrkräfte aus (Krankheit, Mutterschutz, Elternzeit, Todfall, Beurlaubung ohne Bezüge…). Zu diesen Ausfällen verändert sich die Anzahl der bezahlten Stunden; wohlgemerkt, diese Anzahl wird nicht immer auf '0' gesetzt, sondern sie läuft bei Krankheit im gewohnten Umfang weiter.

Wenn jetzt die Anwender bei einer Kollegin die folgenden Ausfälle eingeben:
- Beschäftigungsverbot wg. Schwangerschaft von 11.11.2019 – 30.03.2020 (Deputat verändert sich nicht)
- Mutterschutz von 16.04.2020 23.07.2020 (Deputat verändert sich nicht)
- Elternzeit von 24.07.2020 – 24.07.2022 (Deputat verändert sich auf '0')

Diese Vorgänge werden in der tbl_VORGAENGE gespeichert.

In einer anderen Tabelle 'tbl_AVLEHRERDEPUTAT' werden für jede Lehrkraft die Anzahl der Ausfallstunden.

Welcher Automatismus stellt sicher, dass das Deputat beim Datumwechsel vom 23.07. auf den 24.07. auf '0' wechselt?
Oder anders formuliert: Wie kann ich die aktuellen Ausfallstunden – auch bei vorhersehbaren Ausfällen (Beurlaubungsantrag, Elternzeiten, OP-Terminen, Ruhestand) automatisiert in die 'tbl_AVLEHRERDEPUTAT' übertragen?

Mache ich dies mit einem Datenmakro im Abgleich mit dem aktuellen Systemdatum?

Vorab vielen Dank für jeden Impuls!

Viele Grüße
gromax

:)

 

Auf keinen Fall mit einem Datenmakro. Um hier weiterhelfen zu können werden weitere Informationen benötigt. Wie sieht das Datenmodell aus? Zeige bitte ein Bild vom Beziehungsfenster.

 

Berechnungsergebnisse würde man vorzugsweise nicht speichern (0. Normalform), sondern z.B. eine gescheite Abfrage auf eine durchdachte Tabellenstruktur verwenden.

 

Wie Elmar schon sagte: bitte mal die komplette Struktur zeigen.

Ich würde da - ohne das jetzt zu kennen - folgendermassen rangehen:
In den Stammdaten gibt es (hoffentlich) eine Tabelle mit den verschiedenen Ausfall-Arten.
Die haben dann jeweils einen Fremdschlüssel in tbl_VORGAENGE
In tbl_AUSFALLARTEN ist zusätzlich zum Begriff hinterlegt, was bei beginn - vielleicht auch bei Ende - der Ausfallzeit passiert. Vielleicht gibt es ja noch andere Regelungen, nicht nur hinsichtlich der Deputat-Stunden ...

Dann muss es einen Automatismus geben, gesteuert durch Timer oder beim Öffnen der Access-DB, dass für jeden Tag die Tabelle mit den Vorgängen gescannt wird, ob am fraglichen Tag eine Ausfallzeit beginnt (oder endet).

Und dann kann das Programm in tbl_AUSFALLARTEN nachschauen, was zu geschehen hat und das entsprechend tun.

Dabei muss zusätzlich sichergestellt werden, dass das für jeden Kalendertag nur genau einmal stattfindet - sowas kann man mit einer tbl_KALENDER ganz gut erledigen, wo es für jeden Kalendertag genau einen Datensatz gibt.

Stichwort "Datenmakro": wie Elmar ganz richtig anmerkte, Finger weg.
Alle Manipulationen an Daten sollten programmgesteuert über SQL Anweisungen (INSERT, UPDATE, DELETE) ausgelöst werden.

 

Hallo Elmar, hallo Hans-Christian,

anbei die DB-Struktur.
Vielleicht gebe ich kurz einige Informationen dazu weiter:

tbl_EINSAETZE: Hier treffen sich die Lehrpersonen und die jeweilige Schule.
tbl_VORGAENGE: Hier werden Ausfälle und auch Rückkehren aus Beurlaubungen bzw. Teilzeiten in Elternzeiten abgelegt.
tbl_DEPUTATE: Jeder Lehrer hat über bestimmte Zeiträume ein Deputat; dieses ist nicht dasselbe wie die tatsächlich im Einsatz befindliche Stundenanzahl
tbl_REDUKTIONEN: Für verschiedene Tätigkeiten (Bsp. Schulleitung) wird die zu unterrichtende Stundenanzahl vermindert; das Deputat bleibt davon unberührt.
tbl_AVLEHRERDEPUTAT: Für bestimmte Vorgangsarten werden die entfallenden Stunden hier gespeichert; diese Stundenanzahl kann zur sachgrundbezogenen Befristung von Ersatzlehrkräften bzw. Vertragslehrkräften zu dessen Finanzierung hinterlegt werden.
tbl_AVHINTERLEGUNGEN: Wird eine Vertragslehrkraft tatsächlich eingestellt, wird diese hier gespeichert.

Mein Problem ist also:
Bei mehreren künftigen Ausfällen (OP-Termin in der Zukunft, Mutterschutz, Elternzeiten… - vgl. Beispiel aus meiner Erst-Anfrage), die heute eingetragen werden können, weil die Zeitspannen ja schon bekannt sind, sollte die dann aktuell hinterlegte Stundenanzahl im Formular aufgerufen werden.

Wenn ich schließend auch Eberhard mit aufrufen darf:
Warum verdammt Ihr die Datenmakros? Ist es damit technisch nicht machbar? Ist diese Technik nur zur Protokollierung der Aktivitäten innerhalb einer DB von Interesse (vgl Literatur 'Hölscher' - 'Minhorst')? Was gibt es denn für Anwendungsbereiche, bei denen Ihr die Datenmakros einsetzen würdet?
Sorry für diesen Zusatz, aber ich habe/bin dran mich darin einzulesen.

Vielen Dank
gromax



Vorab vielen Dank
gromax

 

KEINE!
Neben SQL kommt sinnvoll nur VBA zum Einsatz, Datenmakros sind kleine Hilfsmittel von Microsoft, Anfängern in ACCESS das Leben mit einer Datenbankanwendung zu erleichtern. Letztendlich wird jedoch das Gegenteil damit erreicht, denn Datenmakros kommen schnell an das Ende ihrer Möglichkeiten und frustieren den Anfänger-Anwender mehr als sie ihm helfen.
PS: Der Autor Lorenz Hölscher schreibt über den Einsatz eines Datenmakros als Möglichkeit, eine Mailbenachrichtigung zu erhalten. Dafür mag ein Datenmakro noch sinnvoll sein, nicht aber, um mit Makros eine ganze Datenbank zu steuern.
Habe mir das Bild des Beziehungsfensters (welches man übrigens als Bilddatei direkt hier einstellen kann) kurz im PDF angesehen. So ganz erschließt sich mir noch nicht der Sinn und Zweck des Aufbaues. In Datenbanken werden in der Regel keine Ergebnisse von Berechnungen (z.B. wer hat wie viele Stunden Deputat angesammelt) gespeichert.
Habe mich aktuell informiert: Die Unterrichtszeiten der Lehrkräfte werden als Deputat oder Pflichtstunden bezeichnet.

 

Hallo,
@elmar
Datenmakros sind sehr wohl zu empfehlen.
Du verwechselst auch Datenmakros mit den normalen Access Makros die ich auch für überflüssig betrachte.
Datenmakros sind erst ab Access2010 verfügbar (die normalen Makros gibt es schon viel länger) und können Datenänderungen bereits auf Tabellenebene überwachen. Da sind sonst nix wie die seit langem bei Access vermissten Trigger.
Siehe hierzu:
https://access-im-unternehmen.de/Dat...n_Access_2010/
https://www.akademie.de/wissen/acces...makros-trigger
https://docplayer.org/7491367-Datenm...m-kapitel.html

 

Hallo,

das ist richtig, Datenmakros sollten als Ersatz für die schmerzlich vermissten Trigger dienen. Man kann einiges mit diesen Makros machen, das Problem ist aber, daß in dem gängigen Umfeld mit der Aufteilung FE/BE diese Datenmakros praktisch nicht wartbar sind und kein Datenaustausch mit dem FE möglich ist.
Beispiel: man könnte damit ein Audit-System realisieren, aber leider gibt es keine Möglichkeit, den aktuellen Benutzer zu übergeben. Für eine Multiuser-Umgebung also nicht zu gebrauchen. Es ist wie bei "Radio Eriwan": im Prinzip ja, aber irgendwie ist es immer nie richtig zu Ende gedacht.

Ulrich

 

Das Datenmodell jedoch gibt (mir) noch Rätsel auf:

tbl_REDUKTIONEN steht in keiner Beziehung zu den Lehrpersonen.
tbl_AVHINTERLEGUNGEN hat etwas mit Vertragslehrkraft , also LehrerInnen zu tun.
Warum sind solche Kräfte nicht in der Lehrertabelle enthalten?
tbl_AVLEHRERDEPUTAT bzw. deren Daten soll etwas mit Ersatzlehrkräften / Vertragslehrkräften zu tun haben -
aber ohne Verbindung zur tbl_LEHRER macht das doch keinen Sinn?
tbl_VORGAENGE: Ausfälle und auch Rückkehren aus Beurlaubungen bzw. Teilzeiten in Elternzeiten von Lehrkräften...
auch hier fehlt der Bezug zur tbl_LEHRER.
Abschließend noch etwas zur tbl_LEHRER: hier würde ich nur die "Grunddaten" zur Person ablegen, aber andere "Eigenschaften" und
Merkmale in einer extra Tabelle ablegen.
@NeuerMann1978: Deine Meinung kann ich keinesfalls teilen. Die Begründung liefert dankenswerter Weise Ulrich.

 

Ich stehe Datenmakros positiv gegenüber. Ereignisse und Aktionen auf Tabellenebene sind sehr mächtig und umfassender, als wenn man selber eine Umsetzung programmieren muss, die dann alle Editieraufgaben an Tabellendaten erfassen soll.
Die angebotenen Möglichkeiten erscheinen mir aber noch sehr gering, um damit etwas "richtiges" umsetzen zu können.
Möglichkeiten sehe ich nur auf Ebene ein und desselben Datensatzes (Gültigkeitsprüfungen, Blocken von Löschen und Editieren).
Meine Beschäftigung damit ist aber noch sehr rudimentär.

Aktuelle Stunden sind ein Berechnungsergebnis. Der Übertrag in eine Stammdatentabelle ist eine Speicherung. Das ist also datenbanktechnisch grundsätzlich diskutabel.
Warum: Wenn man Daten am Ausgangspunkt der Berechnung ändert, müsste das gespeicherte Berechnungsergebnis gesichert ebenfalls korrigiert werden. Das muss man erst einmal hinkriegen. Man müsste also, um auf Datenmakros zu reduzieren, bei den Vorgängen Neuanlage, Editierung und Löschen eines Datensatzes überwachen und eine Reaktion vornehmen. Mach das mal ohne zusätzliche Bedingungen.

Auswertungen bezogen auf einen Zeitpunkt oder Zeitraum würde man live fahren, idealerweise nur mit einer Auswahlabfrage, bei komplexeren Vorgängen durchaus mit Einbeziehung von VBA, temporären Tabellen usw. Das ist meine Aussage bezogen auf jenen Beitrag.

Den Wortlaut "aktuell" würde ich auf heute beziehen, weniger verschoben auf den nächsten Monat und/oder verschoben auf ein paar Jahre.
Da wäre mir also im Umfeld unklar, was nun passieren soll.

Auch würde ich unterscheiden wollen zwischen einem Ist (passiert bis heute) und einem Plan. Pläne werden kaum hundertprozentig eingehalten, sondern dienen eher zur Lieferung von Richtwerten, weil man ja noch keine vollzogene Realität hat.

 

Hallo, liebe Unterstützer,

vorab vielen Dank, dass Ihr so rege geantwortet/diskutiert habt und sorry für meine späte Reaktion – ich war leider nicht in der Lage frühzeitiger zu antworten.

@elmar
Deiner auch deren anderen Skepsis zu folgen, habe ich den herkömmlichen Weg beschritten; wie Eberhard geschrieben hat, versuchre ich nun über Abfragen und entsprechende Filterungen den Weg zu finden.
Zur Erklärung der Tabellen:
Grundsätzlich ist die zentrale Entität meiner DB der Einsatz (tbl_EINSAETZE); hier treffen sich Lehrkräfte und die Schule(n) und hier angebunden finden sich die übrigen Entitäten (Ausfälle – Reduktionen – Dienste – Hinterlegungen – Verträge).
Die Entrümpelung/Atomisierung der tbl_LEHRER ist sicherlich machbar und hat sich soweit tradiert.

Was meinst Du denn mit den "berechneten Daten"; wenn ich tagesaktuell Berichte abrufe, müssen darin doch Lehrerwochenstunden (Lwh) berechnet dargestellt sein?!

@hans-Christian
Deine Überlegungen habe ich auch mit dem Hinweis von Eberhard umgesetzt; so wird in einer Abfrage die 'Aktualität' mit >>aktuell: Wenn([AVLED_von]=Datum();"X";Null)

 

Der bezieht sich darauf, dass die Änderung der Daten durch eine Zeitsteuerung stattfinden könnte. Wenn Du sicher sein willst, dass das für jeden Kalendertag ausgeführt wird, gäbe es diese Möglichkeit.
Ich schrieb aber auch, dass das jeweils beim Öffnen der DB ausgelöst werden kann.

 

Hallo gromax,

was mit FE und BE gemeint ist, ist klar, oder?

Der Hinweis bezog sich auf die Datenmakros im BE und diese sind, wie andere Makros in Access auch, nur schlecht zu dokumentieren und können im BE nicht richtig gewartet werden.

Ulrich

 

Bei "diese Aktivitäten" müsste man genau definieren, was damit im Einzelnen gemeint ist.

Automatik auf Tabellenebene halte ich für sinnvoll und wünschenswert,
- um ungewünschte Anfüge-, Editier- oder Löschaktionen abzublocken,
- um Gültigkeitsregeln durchzusetzen und Datenvalidität sicherzustellen,
- um solche Aktionen zu loggen, also in einer zusätzlichen Tabelle zu dokumentieren.
Das alles hat mit Performancegewinn wenig zu tun. Im Gegenteil: Prüfen statt Nichtstun ist Arbeit und beansprucht eigene Ressourcen. Sicherheit kostet auch Geld - aber gut, wenn man sie hat oder gar in Anspruch nehmen muss.

Auswertungen oder gar Abspeicherung von Berechnungsergebnissen (Ablage in Sonderzone abseits von Stammdaten, Exporte) würde ich nicht auf der Basis von Tabellenereignissen ausführen wollen, sondern genau dann, wenn sie wirklich benötigt werden. Somit würde ich als Entwickler/User auch solche Aktionen selber anstoßen wollen, schon um die Kontrolle darüber zu haben.
Ich kann mir nicht vorstellen, dass so etwas Ziel von Datenmakros/Triggern sein soll.

Automatismen können auch sehr anstrengend sein, wenn sie nicht wirklich sauber und belastbar integriert sind: Wenn der Airbag schon anspringt, wenn eine Fliege gegen die Stoßstange donnert, lässt der Spaß ziemlich schnell nach.