Office: (Office 2010) Komplexe Abfrage mit Unterabfragen / VBA-Baum

Hallo zusammen,

im Moment arbeite ich an einer Datenbank zum Erfassen, Verwalten und Auswerten von medizinischen Fragebögen.

Den Kern des ganzen bildet die Behandlung (tblBehandlung mit Primärschlüssel ID_BEH). Hieran hängt dann der ganze andere Kram, wie Patientendaten usw.

Jetzt geht es darum, dieser tblBehandlung die ganzen Fragebögen zuzuordnen.

Das Problem an der Sache ist, dass Anzahl und Art der Fragebögen bei jeder Behandlung variieren. Das ganze wird sogar noch durch den Messzeitpunkt (Anfang oder Ende) und den Ausfüller (Elternteil, Lehrer, usw.) differenziert.

Ich habe ca. 30 Fragebögen (nennen wir sie frbA - frbZ), mit teilweise über 200 Items. In jedem Fragebögen ist ID_BEH, sowie Messzeitpunkt und Ausfüller hinterlegt.
Jeder Fragebogen kommt in der Kombination (ID_BEH, Messzeitpunkt und Ausfüller) pro Behandlung höchstens einmal vor.

Die Fragebögen sehen dann z.B. so aus:

frbA
ID_frbA, ID_BEH, Messzeitpunkt, Ausfüller

1, 1, 1, Lehrer
2, 1, 1, Vater
3, 1, 2, Lehrer


Folgendes Beispiel:

Behandlung Nr.1 bekommt

am Anfang frbA(Lehrer), frbA(Vater) und frbT(Lehrer)
am Ende frbA(Lehrer) und frbY(Mutter)

Fragebogen, Messzeitpunkt und Ausfüller werden wiederum von Parametern bestimmt (z.B. Alter, Schulform, Diagnostik, usw)

Ich möchte das ganze jetzt auf einem Formular anzeigen, dass

A: Die richtigen Fragebögen für mich anlegt

B: Mir die passenden Fragebögen als Liste anzeigt, über die ich die Daten dann in ein Unterformular laden kann:


Zu A habe ich mir überlegt das ganze per VBA über einen verschachtelten Select-Case Baum anzulegen und die Datensätze per RS zu erstellen.

So ungefähr
Code:

Zu B:
Da liegt das Problem. Ich muss ja jedesmal die Parameter Messzeitpunkt und Ausfüller ermitteln, also wieder eine Art Baum durchlaufen um damit dann die Fragebögen zu holen.
Es sind ca. 20.000 Datensätze in tblBehandlungen. Im Worst-Case wären das pro Fragebogen 120.000 Datensätze (jeweils 3 Personen zu 2 Messzeitpunkten).

Wie sieht das mit der Stabilität und Rechenzeit aus? Besonders im Mehr-Benutzer-Betrieb?


Fallen jemandem bessere Ideen ein, als die oben genannten


Zur Info:
Das Ganze basiert auf einer Datenbank, die noch mit Access 2000 erstellt wurde. Dementsprechend werden die ganzen alten Datensätze importiert.

Die Items in den einzelnen Fragebögen sind alle einzigartig.
Die Ausprägungen sind oftmals boolean-Werte, meistens jedoch Ganzzahlskalen von 1-10

(Wie sieht das eigtl. aus in Access? Hab die ganzen Feldlängen auf byte gekürzt, in der Hoffnung, da auch nochmal etwas herauszuholen.)

Vielen Dank erstmal an alle, die bis hierher gelesen haben.

Und natürlich schonmal vielen Dank im Voraus, an diejenigen, die mir Hilfestellung dabei geben können.


Viele Grüße
Leon

:)

 

Hallo Leon,

trotz umfassender Problembeschreibung erkenne ich nicht wirklich dein Kernproblem.
Da bisher niemand geantwortet hat, scheint es nicht nur mir so zu gehen.

Damit man die Zusammenhänge erkennen kann, wäre es hilfreich das Datenmodell (Abbild des Beziehungsfensters) zu kennen.
Vielleicht kannst du auch das Gesamtproblem in einzelene Aufgaben aufteilen, damit das für uns Anwendungsfremde etwas übersichtlicher wird.

Grundsätzlich sind SQL-Abfragen VBA-Schleifen überlegen und somit vorzuziehen.
Warum Fragebögen neu erstellt werden müssen ist mir nicht klar.
I.d.R. kann man solche Aufgabenstellungen - wenn ich's richtig verstanden habe - durch Vorratstabellen, m:n-Tabellen und geeignete Joins lösen.

Den kleinstmöglichen Datentyp zu wählen ist lobenswert und wird imho viel zu häufig vernachlässigt.
Bezgl. der Datenmenge an sich brauchst du dir keine Gedanken machen.
Access kann (bei geeigneter Indizierung) auch mit ein paar Mio. Datensätzen umgehen.

 

Hallo Marsu, vielen Dank für deine Antwort.

Hmm, ich hab das mal an o.G. Beispiel nachgebaut.

Der Ablauf sieht so aus: Der Patient kommt für einen bestimmten Zeitraum in Behandlung. Das ist eine abgeschlossen Einheit (tblBehandlungen).

In jeder Behandlung müssen eine Vielzahl von Fragebögen ausgefüllt werden.
Technisch ist es eine 1:0/1 Beziehung, da jeder Fragebogen höchsten einmal ausgefüllt werden muss (Anhang 1).
Da sich z.B. der Fragebogen frbA_Anfang_Lehrer inhaltlich nicht vom frbA_Ende_Lehrer unterscheidet, werden die in einer Tabelle zusammengefasst (Anhang 2). Es müssen beim Erstellen dann halt zusätzlich noch Messzeitpunkt und Ausfüller übergeben werden.



Am Anfang werden in der tblBehandlungen bestimmte Werte erfasst (in dem Beispiel Schulform, Alter und Diagnostik). Diese Werte bestimmen dann, welche Fragebögen genau erhoben werden.

So müssen für einen Patienten, der nicht zur Schule geht, keine Lehrerfragebögen erhoben werden.
Ab einem bestimmten Alter, füllt der Patient selbst Bögen aus usw.
Da gibt es fast so viele Kombinationsmöglichkeiten, wie es Fragebögen gibt.

Deshalb mein Ansatz, mit dem Select-Case-Baum anhand dieser Werte die passenden Fragebögen (mitsamt der Parameter Messzeitpunkt und Ausfüller) zu Erstellen.

Der Aufruf erstelleFragebogen("frbA",1,"Lehrer")
würde dann z.B. per Recordset in der Tabelle "frbA" einen neuen Datensatz mit dem Messzeitpunkt 1 und dem Ausfüller "Lehrer" und der aktuellen ID_BEH erstellen.

Die Laufzeit ist hier eher nebensächlich, da dieser Schritt für jede Behandlung nur einmal ausgeführt wird.

Frage hier: Wie sieht das mit der Zuverlässigkeit im Mehrbenutzer-Betrieb (max 3 Personen) aus?
Gibt es da geschicktere Möglichkeiten?


Das Hauptproblem ist dann, an die erstellten Fragebögen (zum Ausfüllen) ranzukommen.

Ich hab da nochmal nachgedacht:
Letzendlich brauche ich nur eine Liste aller Fragebögen, mit der aktuellen ID_BEH.
Der Benutzer soll dann auf den Eintrag in der Liste klicken und in einem Unterformular den entsprechenden Fragegebogen zum Ausfüllen angezeigt bekommen.

Die Frage ist, wie ich diese Liste möglichst schnell erstelle.
Theoretisch könnte ich für jeden Fragebogen eine Abfrage erstellen, die mir den Datensatz/die Datensätze anhand der ID_BEH raussucht.

Das Ergebnis jeder Abfrage variiert dann zwischen 0 (Dieser Fragebogen muss nicht ausgefüllt werden) und 6 (Der Fragepunkt muss für diese Behandlung zu jedem Messzeitpunkt von jedem Ausfüller ausgefüllt werden).

Am Ende fülle ich dann meine Liste aus den Abfrageergebnissen 0.

Und hier mache ich mir Sorgen wegen der Geschwindigkeit. Jedes Mal ca. 30 Abfragen mit jeweils 20.000 Datensätzen.


Viele Grüße
Leon

 

Das ist immer gut. Solch einen Vorgang kann man dann und wann wiederholen. Irgendwann könnte es zur Gewohnheit werden.

Stellen Dein Professor oder am Ende Du gerade die Datenbankwelt auf den Kopf?

Im Abfragen (siehe Thementitel) in Access-(Jet-)Datenbanken gibt es das so nicht, allerdings gibt es JOIN's, die das bei einer geeigneten Tabellenstruktur einfacher und schneller erledigen.

Eher: Die Werte bestimmen primär, welche Fragen gestellt werden. Das ließe sich wie oben schon angeraten über m:n-Beziehungen definieren. Auch, an wen welche Fragen zu stellen wären. Die WERTE würde man da maßgebend in Primärtabellen erwarten.

In jedem Fall ist aber ein Fragebogen wie oben beschrieben kein Element einer sinnvollen Tabellenstruktur, sondern eine Schnittstelle zur Außenwelt (Eingabemedium: Formular, auszufüllendes Dokument, welches standardisiert ausgelesen werden kann).

Bei einer passenden Tabellenstruktur wäre das vmtl. eine Abfrage, wo bei fachgemäßer Ausführung sicher keine Geschwindigkeitssorgen auftreten (geschätzte Zeit < 1 Sekunde).

 

Hallo ebs,

Danke für deine Mühe.

Mit Professor meinst du den Forschungsleiter?

Ich war mir nicht sicher, ob man das schon als 1:n Beziehung definiert, wenn auf der n-Seite höchstens 1 Entität sein kann.

Da würde ich dich bitten, darauf nochmal genauer einzugehen. Wie sähe dann die passende Tabellenstruktur aus?

Mit m:n-Beziehung meint ihr etwa folgendes:

m-Seite
tblQuestions

n-Seite
tblAnswers

und die Fragebögen dann aus obigen Tabellen zusammensetzen?

Um das nochmal klarzustellen:
Die Fragen sind einzigartig. Es gibt keine zwei Bögen, in denen die Fragen identisch sind (abgesehen davon, dass manche Bögen mehrfach von unterschiedlichen Personen ausgefüllt werden). Aber das berücksichtige ich ja mit den zusätzlich Feldern [Messzeitpunkt] und [Ausfüller].

Die Fragen selbst (die Feldnamen in den einzelnen Fragebögentabellen) liegen als Kennung vor (z.B. M1VSFK), die Antworten dazu sind Ausprägungen im Byte-Bereich (meistens 0,1,2,3)

Die tatsächlichen "Fragen" in Textform, brauche ich nicht (bzw. sind für den Fall, dass ich sie brauche, in einer seperaten Tabelle untergebracht.)

Tut mir Leid, wenn das nicht klar genug rüber gekommen ist.


Und wie gesagt, basiert das ganze auf einer 15 Jahre alten Datenbank, an der schon diverse Leute rumgefummelt haben und die aufgrund diverser Probleme (fehlende Verknüpfungen, teilweise keine PKs definiert) langsam zusammenbricht.
Ich habe dann gesagt, ich erstelle sie neu.
Da ich aber die ganzen alten Datensätze importieren muss, kann ich das Datenmodell auch nicht komplett über den Haufen werfen.

Wüsste da ehrlich gesagt auch nicht wie man das aus o.g. Gründen machen sollte.
Oder stehe ich komplett auf dem Schlauch??


Viele Grüße
und einen frohen Nikolausabend

Leon

 

Bei fehlender Konsequenz kannst Du Dir aber auch eine neu erstellte DB sparen, sondern dann irgendwie (ein von vielen geliebter Begriff) Fragen und Ergebnisse per VBA im Vorhandenen zusammenklauben.
Ein Import von Daten muss dann eben etwas differenzierter und ausgefeilter sein, also über angebotene Standardimporte hinausgehen. Ein Datenmodell davon abhängig zu machen, wie ich billig importieren kann, erzeugt ein Riesenproblem. Die Kreativität von Datenzusammenstellern ist sehr groß.

Nein, den Datenbankprofessor: Das genannte Gebilde ist mir unbekannt und daher evtl. ein Gegenstand aktueller Forschung.

Ein Datenmodell schüttelt nicht jeder sofort aus dem Ärmel, insbesondere ich nicht, und bei fehlender Kenntnis und fehlendem Verständnis der Gesamtprojektes (bei mir immer noch sehr reichlich) um so weniger.

Da das Ganze von irgend jemand auch als bedeutsam angesehen wird, wäre nun gerade vor diesem Hintergrund auch eine sofortige Einbeziehung eines Datenbankfachmannes neben der medizinfachlichen Betreuung angeraten.
Ob ein Student (siehe eigenes Profil) mit einigen Anfangskenntnissen und in einem Forum nachfragend an der Stelle als Datenbankfachmann ausreichend ist, würde ich in Frage stellen (vorbehaltlich extremer Lernfähigkeit von Dir).
Zum Querlesen: Es war einmal eine kleine Exceltabelle ...


Daher kann ich an der Stelle nur einzelne Punte herausstellen, die mir logisch erscheinen.
Eine Frage sollte es nur genau einmal geben. Antworten darauf gibt es aber beliebig viele, nämlich pro Fall (Behandlung, Zeitpunkt u.ä.) eine.

Boolean hat als mögliche Werte auch nur -1 (True) und 0 (False), also als Ganzzahlen auswertbar. Damit könnte man die Ausprägung (Wert der Antwort) recht gut in einem Feld erfassen.
Ein Feld wäre dann sehr tauglich für Datenerfassung und Datenverarbeitung.

 

Hallo Leon,

Zeugt tatsächlich von einem "eigenwilligen" Datenmodell.
Eine neue Frage sollte ein neuer Datensatz sein und nicht eine neue Tabellenspalte.

Ohne die komplette Anwendung, deren Datenmodell und Funktionsweise
genau zu kennen, wird es schwer werden, dir zu helfen.

 

Da hast du recht. Deshalb auch meine Frage hier.
Solange am Ende nicht jeder Datensatz per Hand zerpflückt und neu eingefügt werden muss, sollte das kein Problem sein.

Ich habe eine abgeschlossene Berufsausbildung in dem Bereich. Zwar verfüge ich höchstwahrscheinlich nicht über deine Erfahrung, aber ein Student mir einigen Anfangskenntnissen bin ich auch nicht.

Und in einem Forum wie diesem eine solche Antwort zu geben, finde ich fraglich. (Das hat etwas von der pauschalen Aussage: "Elektroinstallationen nur vom Fachmann durchführen lassen"):

Deinen Text habe ich gelesen. Genauso sieht es aus. Du übergehst nur zwei wesentliche Punkte: Anforderungen und Budget.

In den meisten Fällen entsteht so eine kleine Datenbank eben aus dem Wunsch heraus, einfache Vorgänge zu erleichtern.
Wie du schon sagst, kommen mit der Zeit immer mehr Aufgaben dazu. Und irgendwann ist die Datenbank wegen fehlerhaftem Fundament überlastet und bricht zusammen.

Nur ist das ein sukzessiver Vorgang. Die Aufgabenstellung (und damit die Anforderungen) ändern sich stetig. Und ein Datenmodell, was am Anfang als richtig erscheint, funktioniert später nicht mehr, weil Aufgaben hinzugekommen sind, die am Anfang gar nicht abzusehen waren.

Und gerade bei kleineren Firmen (die m.M. nach die Zielgruppe von Access sind), die ihre ersten Schritte Richtung Digitalisierung gehen, fehlen einfach Sensibilität und finanzielle Mittel dafür (bei einer externen Lösung reden wir schließlich über Beträge im fünf- bis sechstelligen Bereich).

Mit unserer Datenbank wird es vor 15 Jahren genauso angefangen haben (damals übrigens von einem "Datenbankfachmann" erstellt).
Weil ich die Anforderungen von damals nicht kenne, kann ich auch nicht beurteilen, was sich der Ersteller dabei gedacht hat.

Ah, Danke. Jetzt ist der Groschen gefallen.
Wie sieht es mit Ausreissern aus? Also Antworten, die tatsächlich als Text erfasst werden müssen?
Eine Tabelle für jeden Datentyp? Antworten pauschal als String erfassen?

Ja, ich hätte wohl früher hier nachfragen und die Situation besser beschreiben sollen.

Die Datenbank selbst kann ich leider nicht hochladen. Reicht eine Abbildung der Beziehungen (Anhang 1)?


Das Prinzip dahinter ist folgendes:

Wenn ein Patient eine Behandlung beginnt, wird ein Aufnahmebogen abgegeben. Dieser enthält die wichtigsten Informationen, um den Patienten sowie aufnehmenden und behandelnden Therapeuten zuzuordnen und später alle zu erhebenden Diagnostik-Fragebögen zu ermitteln:

Diese Daten liegen in der Tabelle tbl_Episoden.

Die Stammdaten der Patienten liegen in der Tabelle tbl_stam_Patienten.
Stammdaten der Therapeuten in der tbl_stam_Therapeuten.
Es gibt den aufnehmenden Therapeuten (genau einer pro Episode), der direkt mit tbl_Episoden verknüpft ist und den behandelnden Therapeuten (kann wechseln), der über die Hilfstabelle tbl_util_Behandlungszeitraum verknüpft ist.

Zu jeder Episode gehört genau eine Dokumentation (tbl_doku_B - tbl_doku_F), die immer ausgefüllt werden muss (B-D am Anfang der Behandlung, E und F am Ende.)

Hier ist dann auch schon das erste Problem mit den zu Grunde liegenden Abläufen: Die Dokumentation enthält Informationen, die bereits mit dem Aufnahmebogen erfasst wurden.
Bevor ich angefangen habe, wurden große Teile dieses Bogens in der Dokumentation (tbl_doku_B) gespeichert. Angesichts der Hierarchie (Erst die Aufnahme, dann die Episode, dann die Dokumentation) natürlich problematisch. Ich habe das dann so gelöst, dass ich alle entsprechenden Felder aus tbl_doku_B nach tbl_Episoden verlagert habe. Die redundanten Daten dienen dann halt nur noch der Kontrolle.

Zusätzlich gehören zu jeder Episode eine ganze Reihe von Diagnostik-Fragebögen (s. ursprüngliche Fragestellung), die teilweise am Anfang und teilweise am Ende erhoben werden. Wann genau welcher Fragebogen von wem ausgefüllt werden muss, leitet sich aus den Angaben des Aufnahmebogens ab.

Aus Kontrollzwecken wird zu jedem Fragebogen (Dokumentation und Diagnostik) noch der Dateneingeber und das Datum erfasst.

Die Diagnostiktabellen habe ich aus der Abbildung rausgelassen (ca. 30 Stück). Diese sind über die Episoden_ID mit der Tabelle tbl_Episoden verknüpft.

Auf dieser Seite finden sich Ausschnitte einiger der Fragebögen (unter 'Forms')
http://www.aseba.org/forms.html

Zusätzlich gibt es noch etliche Hilfstabellen, in denen weitere Daten ausgegliedert sind (PLZ, Wohnort z.B.)


Mit der m:n Variante würde das ja grundlegend ungefähr so aussehen (Anhang 2).
Die Fragebogen über JOINS zusammenzufügen, ist nicht das Problem.

Nur wird hier jede Frage als seperater Datensatz abgespeichert. Jetzt habe ich aber einige Vorgaben, in denen Fragebögen zusammenhängend und vor allem konsistent betrachten werden müssen (z.B. sollen nur vollständig ausgefüllte Fragebögen abgespeichert werden. Einige Fragen sind voneinander abhängig: Wird eine Überkategorie z.B. mit 2 beantwortet, müssen alle Subfragen mit 1 beantwortet werden.)
Dazu kommen noch diverse Plausibilitätsprüfungen.

Therapeuten werden gemahnt, wenn Cluster von Bögen nicht abgegeben werden (z.B. die Dokumentation). Dies wiederum differenziert nach fehlend oder unvollständig.

An dem ganzen Prozedere lässt sich wie am Aufbau der Bögen leider nichts ändern.

Ich sehe zwar die Vorteile dieser Datenstruktur (Flexibilität), aber durch die ganzen Querverbindungen der Fragen untereinander bin ich mir nicht sicher, ob (und wie) man alle Anforderungen damit realisieren kann.


Viele Grüße
Leon

 

Einem fachlichen und monetären Profi kann ich mit meinem sechswöchigen Fernlehrgang "Datenmangement mit SQL" und etwas Lesen und Schreiben in einem Forum natürlich nicht widersprechen, und das will ich auch nicht.

Trotzdem eine Anmerkung: Ich habe noch nicht wirklich verstanden, ob Du Fragebögen hast oder erst erstellst, ob diese Fragebögen als Papier, Kopie von Papier, PDF, Tabelle oder Formular daherkommen, was davon ausgefüllt wird, wie Informationen in die Tabellen lt. Datenmodell gelangen, wo ich bei flüchtiger Betrachtung nichts von Fragen, Antworten und Fragebögen sehe.

Ein einfacher, vor allem aber schneller, direkter und fehlerfreier Informationsfluss vom Befragten zu den Tabellen des geplanten Datenmodells erscheint mir ja als Hauptaufgabe, dem sich Maßnahmen unterzuordnen haben. Mit diesem Informationsschluss stellt sich dann auch eine Verwaltung von Antworten in einer ganz anderen Art und Weise.
Wie sich da eine Anzeige von Fragebögen in einem Formular (siehe Eingangsfrage) einordnet: Keine Ahnung.

 

Die Fragebögen werden in Papierform eingereicht und müssen über Formulare eingegeben werden.
Der Anwender sucht den Patienten über eine Suchfunktion heraus, wählt die passende Episode aus und kommt über einen Button zu den Fragebögen.
Diese sind per Unterformular eingebunden und per Episoden_ID mit dieser verknüpft.

Oberste Anforderung ist leider wirklich, dass nur vollständige Datensätze (Fragebögen, also spezifische Fragencluster) gespeichert werden dürfen.
Da einzelne Fragebögen momentan als komplette Datensätze gespeichert werden, ist dies kein Problem.

Bei anderem Datenmodell (jede Frage ein separater Datensatz) bliebe mir da nur die Möglichkeit mit jeder Menge Löschabfragen bei Unvollständigkeit die angefangenen Fragen wieder zu löschen oder ich arbeite mit ungebundenen Feldern und Recordsets und prüfe vorher die Vollständigkeit.

Du meinst doch die Aufteilung von Fragen und Antworten in separate Tabellen?

Ich mag diese breiten Tabellen auch nicht. Normalerweise bevorzuge ich auch die Strukturbildung per SQL, aber so einen "speziellen" Fall hatte ich vorher noch nicht.

Ich sehe bei diesem Konzept nur jede Menge ausgegliederte Tabellen und Querverweise, die für die Formulare dann wieder zusammengefügt werden müssen.
Und am Ende lassen sich die Plausibilitätsprüfungen doch nur über VBA lösen.

bist du wahrscheinlich im Vorteil. Auf jeden Fall hast du eine andere Sichtweise auf mein Problem.

Viele Grüße
Leon

 

(An der Stelle würde ich da eher Antwortblätter sagen.)
Die Informationen sollen doch aber in den Datenmodell-Tabellen landen, oder? Insofern wäre eine Antwortentabelle wie scheinbar verwendet nur als Zwischenergebnis bis zur entgültigen Verteiliung der Daten zu sehen. Tabellen für die Aufnahme temporärer Daten haben dann aber in einem Datenmodell mit Stammdaten gar keine Rolle zu spielen, sondern sie dürfen einfach da sein, frei gestaltet werden, gelöscht und angelegt, gefüllt und geleert werden. Nach Verteilung der Daten müssen diese Antworten beseitigt werden, da man sonst Redundanz aufbauen würde.

Nun, und wenn man mit temporären Daten arbeitet, sollte man damit, zumindest ab bestimmten Größenordnungen, weder sein Frontend noch sein Backend belasten, sondern da einfach ein zusätzliches lokales Backend einsetzen, das dann als Ganzes entsorgt werden kann.

Zur Aufteilung der Daten kannst Du Dir das ansehen:
Importtabelle in m:n-Beziehung auflösen

Papier ist sicher unverzichtbar, schon wegen der herkömmlichen Dokumentation.

Trotzdem könnte man die Möglichkeit prüfen, PDF-, Word-, Access(?)-Formulare zum Ausfüllen zu benutzen, die dann per Programmroutine ausgewertet werden. Manuelles Abschreiben (durch eine medizinische Fachkraft?) kostet Zeit und birgt die Gefahr von Übertragungsfehlern.
Fachleute mit "überflüssiger" Routine zu beschäftigen statt mit wirklicher fachlicher Arbeit kostet auch Geld, Tag für Tag. Ab wann da ein fünfstelliger Betrag zusammenkommt, kann man leicht zusammenrechnen.

 

Ok, ich habe das jetzt mal so aufgebaut (s. Anhang).

tblFragebogen und tblAnswers beschreiben den strukturellen Aufbau der entsprechenden Daten. tblAnswers und tblAntwortbogen enthalten die Daten.

tblAnswers dann die bloßen Antworten und tblAntwortbogen die dazugehörigen Metadaten (wer hat die Daten eingegeben, welcher Episode müssen die Antworten zugeordnet werden, ist der Bogen vollständig).

Hey, danke. Der Code war sehr aufschlussreich.

Die Eingabe müsste dann tatsächlich in irgendeiner Form temporär zwischengespeichert werden.
Erst wenn alle Anforderungen erfüllt sind (Antworten plausibel, Antwortbogen vollständig), wird dann in die tatsächlichen Tabellen gespeichert.
Wäre natürlich auch eine Entlastung des Netzwerkes.

Allerdings ist es im Normalfall eine Person, die eingibt. Im Maximalfall haben wir drei Rechner, die auf das Backend zugreifen.

Kann man im jetzigen Zustand (Fragebogen als Datensatz) von Redundanz sprechen? Ich meine die Ausprägugnen liegen im byte-Bereich.
Problematisch sind ja nur die horizontalen Tabellen, nicht die Datensätze.

Das ist halt die große Frage, ob man bei diesem konkreten Fall nicht zugunsten der Performance auf komplette Normalisierung verzichtet.

Ist das aktuelle Datenmodell denn so falsch hinsichtlich Vermeidung von Redundanz und sonstigen Inkonsistenzen?

Auf jeden Fall. Ich habe vor kurzem den Anmeldebogen auf eine elektronische Version umgestellt, da dieser m.E. einfach zu wichtig für den ganzen Prozess ist.
Eingabefehler aufgrund unleserlich eingetragener Namen waren keine Seltenheit.
Momentan provisorisch als Word-Datei. Langfristig wünsche ich mir da eine pdf- oder sogar VB-Lösung. Da kann man die Plausibilität schon an der Quelle überprüfen.
Was die ganzen Antwortbögen angeht, ist das wohl nicht möglich. Die Anmeldung des Patienten kann nur durch eine handvoll Personen erfolgen.
Die Fragebögen selbst werden von den Therapeuten ausgefüllt (mehrere Hundert) oder an Eltern, Lehrer, usw. weitergeleitet. Da bezweifel ich, dass da die Akzeptanz vorliegt.

Gut, in unserem Fall sind das studentische Hilfskräfte.
Das Verfahren sieht so aus, dass die abgegebenen Bögen erstmal von einem Mitarbeiter überprüft werden. Bei Fehlern oder Unvollständigkeit geht der Bogen (postalisch) zurück an den Therapeuten.

Du siehst, dass allein die zu Grunde liegenden Vorgänge überarbeitet werden müssten.
Das Problem an der Sache ist, dass hinter dem Projekt einfach keine wirtschaftlichen Interessen stehen.
Letztendlich ist das Ganze ein Service für die Therapeuten.

Zusätzlich können die Daten für wissenschaftliche Arbeiten (Statistiken, usw.) extrahiert werden.

Mein Augenmerk lag also erstmal darauf, Fehlerquellen zu beseitigen. Und die liegen vorrangig beim Eingeber.

In der jetzigen Fassung wurden zum Beispiel beim Neuanlegen eines Therapeuten die bestehenden Datensätze in das Formular geladen.
Wer da nicht höllisch aufpasste, überschrieb munter bestehende Daten.

Bis jemandem dann mal aufgeffallen ist, dass plötzlich alle Therapeuten mit "A" und "B" verschwunden waren...
Das war ein Spaß, die ganzen Therapeuten wieder ihren Fällen zuzuordnen.


Also, ich habe kein Problem damit, das bestehende Datenmodell über den Haufen zu werden und einen anderen Ansatz zu wählen.
Wenn es sich im Hinblick auf die Umstände (max. 3 Eingeber, ca. 1000 Episoden pro Jahr; Wird sich nicht ändern) lohnt.

Viele Grüße
Leon

 

Davor steht ja die Frage, wie und in welcher Form die Daten genutzt und ausgewertet werden. Excel kommt ja recht gut ohne den Begriff Normalisierung aus. Statistik geht auch da, zumal mit ausgefeilteren Funktionen.

In einer Datenbank, die (zumindest theoretisch) sehr umfangreiche Datenmengen aufnimmt, hat es sich als extrem sinnvoll erwiesen, aus Prinzip eine einzelne Informationseinheit nur genau einmal (und somit nicht redundant, vielfach) zu speichern und im folgenden nur mit Schlüsseln auf diese Einheit zu verweisen. Mit Datenbank ist hier eine richtige Datenbank gemeint.
Manchmal ist ja eine Datenbank auch nur eine Sammlung von Irgendwie-Tabellen und so für Nutzung und Anwender ausreichend. Daten wegen der Speicherung zu trennen (Normalisierung) und für eine Verarbeitung über telweise viele Ebenen wieder per JOIN's zusammenzuführen ist ja auch Arbeit, die irgendwo zu begründen wäre, im allgemeinen über eine Datenkonsistenz von sehr vielen Daten dann auch in längeren Zeiträumen, was dann besonders für langlebige Lösungen interessant ist.

Da funkt es in meinem Logikprozessor nahe am Kurzschluss.

Das sehe ich ähnlich: Ehe man sich zu Details und Codes ausbreitet, muss man erst einmal über Abläufe nachdenken.

Nun, in einem Eingabeformular (Daten einfügen) hätte man gar keine Chance, bestehende Daten zu manipulieren. Das ist als an der Stelle keine Frage eines Datenmodells (da schützt nur referentielle Integrität vor einigen Fehleingaben), sondern alleine eine Benutzeroberfläche mit der Funktionalität, die dem User im positiven wie im negativen Sinne zuzumuten ist.

Zum Beziehungsbild: Mir wird jedesmal unwohl, wenn man in Beziehungen im Kreisverkehr fahren kann.

 

Zumindest für die Fragebögen, ja. Aber da hängt eben noch wesentlich mehr dran.

Haha, ja. Aber hast du deine Hausaufgaben früher gerne gemacht?
Für die Therapeuten bedeutet es natürlich mehr Arbeit. Und diese ständigen, nervigen Erinnerungen, dass Unterlagen noch nicht abgegeben wurden.

Aber für den Abschluss der Ausbildung (handelt sich um Therapeuten in Ausbildung), wird ein kompletter Fall benötigt. Und darin liegt dann der Service.

Access hat mir da die Entscheidung abgenommen: "...Die Tabelle 'tbl_Episoden' enthält zu viele Indizes..."

Ich werde also ein Modell mit m:n Beziehungen benutzen.

Naja, sind ja auch Einbahnstrassen.
Ich wüsste aber nicht, was ich da "kappen" sollte.
Ist allerdings ja auch kein "normaler" Fragebogen, in dem man sich durch jede Antwort klickt.


Da das Thema aber mittlerweile komplett von der ursprünglichen Fragestellung abweicht, und ich sicher bei dem neuen Datenmodell Hilfe gebrauchen kann (vor allem, wie ich das Speichern bei fehlender Vollständigkeit verhindern kann), habe ich ein neues Thema aufgemacht:
Datenmodell Fragebogen


Zur ursprünglichen Frage:
Ich habe das Abfischen der Daten über mehrere Parameterabfragen (eine pro Fragebogen) gelöst. Die einzelnen Abfragen werden dann per UNION-Abfrage zusammengefügt.
Das Erstellen hat wie gesagt über den verschachtelten Select... Case und Recordsets funktioniert.

Das überdenke ich dann natürlich bei dem neuen Datenmodell.


Also vielen Dank für die Antworten und das leiten auf den "richtigen" Weg.


Viele Grüße
Leon