Aufbau Datenbank mit 3 bekannten Unbekannten

[Paul-Werner]

Einen wunderschönen guten sonnigen Morgen,

ist das Wetter nicht toll?
Es ist trocken und warm. Einfach genial.

Eines vorneweg: Achtung öffentlicher Dienst. Wir denken hier "etwas" anders. Auf unseren PC ist Access installiert, aber VBA komplett unterbunden.
Ich habe mir deshalb den DB-Browser portabel geholt und mir mit SQLite meine Datenabfragen gebastelt. Nicht immer perfekt, aber für meinen Bedarf ausreichend.

Ich habe einmal wieder einen Auftrag bekommen. Ich muss drei Informationen in mehreren n:n:n Verbindungen zusammenbringen.

Eigentlich ein Job für unsere ITler. Die werden von den gewählten ohne Fachwissen ständig für anderes abgezogen. Also muss man sich selbst behelfen.

Für jede dieser drei Informationen lege ich eine Tabelle an.

• Mittelanforderungen/Mittelrückmeldung (t_ma)
• Mittelzusagen/Mitteleinzug (t_mzu)
• Mittelbereitstellung/Einzug (t_mb)

Die Tabellen enthalten selbstverständlich mehr Spalten. Zum besseren Verständnis habe ich gekürzt.

Es gibt mehrere mögliche Szenarien.

Alternative 1: (Idealfall)
1. Mittelanforderung (Buchungsstelle, Jahr, Betrag)
2. Mittelzusage (Buchungsstelle, Jahr und Betrag stimmen überein)
3. Mittelbereitstellung (Buchungsstelle, Jahr und Betrag stimmen überein)

Alternative 2:
1. Mittelzusage (mit Buchungsstelle, Jahr und Betrag, Geschäftszeichen)
2. Mittelbereitstellung (Buchungsstelle, Jahr und Betrag, Geschäftszeichen stimmen überein)

Alternative 3:
1. Mittelanforderung (Buchungsstelle, Jahr, Betrag)
2. Mittelzusage (Buchungsstelle stimmt überein, Betrag auf mehrere Jahre aufgeteilt, Geschäftszeichen)
3. Mittelbereitstellung (wie 2.)

Alternative 4:
1. Mittelzusage (Buchungsstellen, diverse Beträge, Geschäftszeichen auf mehrere Jahre aufgeteilt)
2. Mittelbereitstellung (wie 1.)

Alternative 5:
1. Mehrere Mittelanforderungen (Buchungsstellen, Jahre, Beträge)
2. Mittelzusage (über mehrere Mittelanforderungen und Geschäftszeichen zusammengefasst)
3. Mittelbereitstellung (ähnlich wie 1.)

Für die Mittelanforderungen/-rückmeldungen/-zusagen/-einzug gibt es nur E-Mail oder Papier. Diese Daten werde ich IMMER per Hand eintragen müssen.
Die Daten zur Mittelbereitstellung kann ich mir als csv oder xlsx aus unserer Datenbank holen.

Am Ende muss ich sehen können, wann und was zu welcher Mittelanforderung zugesagt wurde und wann und was bereitgestellt wurde. Bzw. wann und welche Mittel zugesagt wurden und wann und wie bereitgestellt.

Vom Gedanken her müsste ich eine ID haben, welche je nachdem was ich zuerst erfasse (Mittelanforderung/Mittelzusage) laufend generiert wird (eigene Tabelle t_ID Trigger before insert).
Dann müsste ich je nach den Alternativen N:N:N Verknüpfungen erstellen.

Ist mein Gedankengang sinnvoll?
Oder kann mir jemand einen guten Rat geben?

Vielen Dank schon einmal
und ein schönes Wochenende

Euer
Paul-Werner

 

[ukulele]

Du machst das jetzt in SQLite oder muss das später in Access laufen? Wie genau läuft Eingabe / Ausgabe? Die Datenstruktur richtig hin zu bekommen ist eigentlich das kleinere Problem, aber irgendwie muss das am Ende natürlich bedienbar sein ohne selbst SQL Befehle abzusetzen.

Deine Tabellenstrukur ist leider schlecht, das kannst du hervorragend an deinem Idealfall sehen. Du setzt in alle drei Tabellen den selben Inhalt, die selben Informationen. Bei einer ordentlichen Normalisierung würde man gleich erkennen das das nicht der Weg sein sollte, auch wenn das jetzt natürlich eine vereinfachte Darstellung ist. Dein Idealfall ist in etwa so als ob du ein Auto erst Rot, dann Grün und dann Blau lackierst und dafür drei Entitäten (Tabellen) anlegst in dem am Ende das selbe Auto in jeder Tabelle einmal steht.

Jetzt ist das relativ leicht abzufragen, wenn man es ordnungsgemäß normalisiert wären die Informationen nicht mehr redundant aber die Abfragen werden etwas an Komplexität zulegen. Am Ende muss man sich dann für einen praxisorientierten Mittelweg entsteiden.

Mal so grob als Orientierung:
tbl_Vorgang (VorgangsID,Geschäftszeichen,[...])

tbl_Ereignis (EreignisID,VorgangsFK,Datum,VZvon,VZbis,Typ,Betrag in €,Stückelung,Buchungsstelle)
Einträge:
xx.xx.xxxx 01.01.2023 31.12.2024 Anforderung 1201 1 xy
xx.xx.xxxx 01.01.2023 31.12.2024 Bewilligung 1200 24 xy
xx.xx.xxxx 01.01.2023 31.12.2024 Mittelzusage 1200 24 xy (ich erkenne den Unterschied zwischen Bewilligung und Zusage nicht aber irgendwo wird ggf. gestückelt)
01.01.2023 01.01.2023 31.01.2023 Bereitstellung 50 1 xy
...

Eventuell gehört die Buchungsstelle auch in tbl_Vorgang wenn das immer die selbe ist.

 

[Paul-Werner]

Hallo Ukulele,

vielen Dank. Du hast mir wieder einmal einen Schubs in die richtige Richtung gegeben.
Die Normalisierung ist, da in der Papierform nicht existent, nicht bei mir in den Gedanken gewesen.

Ja, vorerst SQLite (Vielleicht bekomme ich auch LO-Base zum Laufen). Wenn denn doch einmal einer der ITler für seine eigentliche Tätigkeit Zeit hat kann ich sagen: Bitte in ACCESSS-Server und GUI-Client, in SQLite hat es funktioniert. Die haben die Berechtigungen dafür.

Bei den Buchungsstellen handelt es sich um mehrere. Unter Umständen erfolgt die Mittelanforderung auf eine Buchungsstelle, die Zusage erfolgt über mehrere verschiedene Buchungsstellen.

Einen schönen Gruß
Paul-Werner

 

[ukulele]

Leider ist Access (es gibt keinen "Access-Server") kein vollwertiges DBMS sondern nur eine Datenbank-Datei. SQLite bin ich jetzt nicht ganz sicher kann aber deutlich mehr, z.B. Trigger. Bei Access muss das alles irgendwie mit VB gefummelt werden, es gibt keine Event-Trigger.

Access hat dafür einige Möglichkeiten als Front-End zu fungieren. Aber grade dann wird man hähufig dazu verleitet solche Datenmodelle wie du am Anfang zu nutzen weil es besser zu den Möglichkeiten der GUI passt. Das kann von einem praktischen Standpunkt her okay sein aber man sollte sich am Anfang Gedanken machen was am Ende da stehen soll. Willst nur du das einsetzen ist das vielleicht was für Access. Soll das die ganze Verwaltung einsetzen muss man eher ein DBMS + Frontend nutzen, z.B. einen Webserver mit allem drum und dran.

 

[dabadepdu]

Wenn die Eigenarten von SQLite bekannt sind/ berücksichtigt werden (Stichwort Type Affinity) und vielleicht noch nicht mal ein GUI nötig ist (Das Datenmodell ist sehr übersichtlich), wäre das für den beschrieben Fall meine Wahl. Vielleicht auch LO, was ja ähnliche Problemzonen bietet wie Access, aber dafür transparent und kostenlos ist.

Mit dem Datenmodell von @ukulele könnte man das einfach in einem SQLite DB Editor eintragen.
SQLite unterstützt m.E. auch das Anbinden (Link?), jedenfalls Import von CSV per SQL bzw. mit einfachen Kommandos.

Das ist keine Hexerei, sondern einfach Entwickler Handwerkszeug. Nicht unbedingt für den Endverbraucher gedacht, funktioniert aber.
Eingedenk dessen sollte man vielleicht im Hintergrund dafür sorgen, dass die Dateien stets gut gesichert werden, fallls man mal was zerschießt.

 

[Paul-Werner]

Einen wunderschönen guten Morgen nach dem wunderbar sonnigem Wochenende,

Ich jedenfalls habe es genossen.

@ukulele
Ich meinte Acces-Frontend ./, Access Backend. (Das kann ich mir nur leider nicht merken) Und wegen der Einschränkungen von Access bin ich nicht begeistert davon. Warum VBA wenn es das normierte SQL gibt? LO will Java und das ist bei uns auch nicht installiert..
Webserver mit MySQL o.ä. wäre die beste Lösung, Aber da spielt unsere IT nicht mit. Dass ich einiges mit meinen selbst gebastelten protablen SQLite mache schrammt mehr als nah an einer Abmahnung oder schlimmerem vorbei. Du sollst Ergebnisse bringen bekommst aber das Werkzeug dafür nicht. (Poliker ohne Ahnung und Hintergrundwissen dafür aber Anschaffen wo es lang geht. Und jeder Hinterbänkler, der sich die letzten Jahre nur seinen A... warmgesessen hat will jetzt Daten haben um zu zeigen was ER alles für SEINEN Wahlkreis getan hat. Es geht auf die Wahlen zu. Bei der DB, bei welcher Du mir vor einiger Zeit geholfen hast ging es genau darum. Ich kann gesicherte Daten liefern. Sogar innerhalb der Vorgabezeiten.)

@dabadepdu
Der Einfachheit halber kopiere ich jedes Mal, bevor ich an meiner DB bastle die in ein Backupverzeichnis.
Einiges funktioniert schon. Ich habe meine Daten aus den Export-CSV des Buchunggssystems.
Was ich noch bauen muss ist meine Eingaben und dann die Verknüpfungen zwischen (Mittelanforderungen und) Mittelzuweisung und Mittelbereitstellung.

Ich werde sicherlich öfter Fragen haben. Das Teil muss ich zwischendurch erstellen.

Allseits schon einmal eine schöne Woche
Paul-Werner

 

[dabadepdu]

Warum VBA wenn es das normierte SQL gibt? LO will Java und das ist bei uns auch nicht installiert..
Webserver mit MySQL o.ä. wäre die beste Lösung

Naja, "normiert" ist SQL, real existierende Implementierungen (von Herstellern relationaler Datenbanken) sind da mal mehr oder weniger nahe dran. Jeder will gerne etwas besonderes können (nicht alle, aber die meisten), da klemmt es schonmal beim Standard.
Die beste Lösung wäre vermutlich nicht mit MySQL, was relativ weit vom Standard weg ist, relativ wenig Weiterentwicklung bietet und m.E. eher nur noch ein Teaser Produkt des Herstellers ist, um sein fettes und teures Kernprodukt zu verkaufen.
Webserver mit Postgres wäre m.E. die beste Lösung.

Was Du schreibst, ist wieder mal ein trauriger Einblick in Dinge, die man wahrscheinlich gar nicht wissen will. Es bestätigt meinen Eindruck, den ich am Rande irgendwelcher EVergaben bekomme. Ach und die Bahn, da kommt ja jetzt(!?) die Digitalisierung, sogar KI, und alles wird gut, haha.

Ich frag mal ganz doof:
Kannst Du die benötigte Software (kostenlose DB) oder Server (paar Euro 50 pro Monat Miete) nich beantragen?

 

[castorp]

LO will Java und das ist bei uns auch nicht installiert..

LO unterstützt auch seit einiger Zeit auch Firebird als embedded Datenbank. Soweit ich weiß, ist dafür kein Java mehr notwendig ist.

Man muss es aber erst aktivieren:



Danach ist das eine Auswahlmöglichkeit beim Anlegen einer Datenbank:


Als relationale Datenbank ist das auf jeden Fall besser als Access.

 

[Paul-Werner]

da bin ich wieder einmal.
Die ... haben sich einige neue Aufgaben einfallen lassen. Deswegen bin ich weit hinter meinem Zeitplan hinterher.

Kann bitte jemand die Abfrage ansehen?
Wenn ich das erste oder zweite Select alleine verwende gibt es keine Probleme.
Verwende ich UNION bekomme ich "Datentypenkonflikt im Kriterienausdruck"
Dabei habe ich das erste nach unten kopiert und lediglich _A durch _B ersetzt.

SELECT
I_zuw_EPL_A.Buchungsdatum,
REPLACE(I_zuw_EPL_A.Aktenzeichen," ","") AS GZ,
Left(Replace(I_zuw_EPL_A.ZielHHStelle," ",""),10) AS BSt,
I_zuw_EPL_A.Mittel,
IIf(I_zuw_EPL_A.[Ziel-Fälligkeitsjahr] Is Null,
(SELECT max(right(Buchungsdatum,4)) FROM I_zuw_EPL_A ),I_zuw_EPL_A.[Ziel-Fälligkeitsjahr]) AS Jahr_feallig, I_zuw_EPL_A.Art, I_zuw_EPL_A.Referat, CDbl(I_zuw_EPL_A.Betrag) AS Betrag
FROM I_zuw_EPL_A

UNION

SELECT
I_zuw_EPL_B.Buchungsdatum,
REPLACE(I_zuw_EPL_B.Aktenzeichen," ","") AS GZ,
Left(Replace(I_zuw_EPL_B.ZielHHStelle," ",""),10) AS BSt,
I_zuw_EPL_B.Mittel,
IIf(I_zuw_EPL_B.[Ziel-Fälligkeitsjahr] Is Null,
(SELECT max(right(Buchungsdatum,4)) FROM I_zuw_EPL_B ),I_zuw_EPL_B.[Ziel-Fälligkeitsjahr]) AS Jahr_feallig, I_zuw_EPL_B.Art, I_zuw_EPL_B.Referat, CDbl(I_zuw_EPL_B.Betrag) AS Betrag
FROM I_zuw_EPL_B

Es geht mir darum 2 CSV-Dateien nur einzubinden, nicht als eigenständige Tabelle in der DB zu haben.
Die beiden CSV-Dateien exportiere ich bei Bedarf jedes Mal frisch aus dem Buchungssystem.


Der Fehler muss in den Zeilen liegen:

REPLACE(I_zuw_EPL_A.Aktenzeichen," ","") AS GZ,

REPLACE(I_zuw_EPL_B.Aktenzeichen," ","") AS GZ,

Eine Zeile tiefer habe ich bereits ein Replace und das funktioniert problemlos.

Danke schon einmal

Ein schönes Wochenende

Paul-Werner

 

[ukulele]

Das heißt bei den Tabellen I_zuw_EPL_A und B handelt es sich tatsächlich um CSV Dateien? CSV Dateien haben ja keinen Spaltentyp, er interpretiert also das was da steht. Wenn du jetzt 2 Dateien hast mit je einer Spalte A und in der ersten stehen Zahlen und in der 2ten stehen Buchstaben dann interpretiert er die erste als Integer und die 2te als Zeichenkette. Dann versucht er zu verbinden und dann knallts. Guck dir mal die Werte in der ersten Zeile in Aktenzeichen ein.

Um das zu vermeiden kann man explizit als Zeichenkette casten, je nach DBMS.