Fragebogen mit 4 Items

[Knobbi38]

Natürlich geht das mit ToogleButtons. Je Zwei Tooglebuttons stehen für annehmen/ablehnen oder es wird in einer OptionsGroup kein Tooglebutton ausgewählt. Die Steuerung und Überwachung von Regeln wird per VBA im Formular implementiert.

Ich denke, die Antwortskala muss nicht zwei Felder für minus und plus beinhalten, sondern die Items, wo einer von drei Werten eingetragen wird.

Nein, die Annahme ist so nicht richtig (siehe deine Eingangsbeitrag Vorgabe #3). Es wir genau ein Item mit +1 und ein Item mit -1 gekennzeichnet und exakt dieses wird in der tblAnwort festgehalten. Angaben zu den nicht bewerteten Items müssen nicht gespeichert werden, das ist "Papierdenke".

ABER es ist interessant, wie ein jedes der 100 Items vom Probanden bewertet wurde. Bei viermaliger Darbietung des Items (in jeweils anderer Kombination pro Quadrupel) kann für das Item ein Wert zwischen (-4 bis 4) raus kommen.

Genau das leistet die Tabelle tblAnwort, man muss nur die entsprechenden Summen pro Item bilden. Aber wie gesagt, solche Auswertungen lassen sich auch in Excel umsetzen.

Möglicherweise muss die Datenstruktur eine Antwortmatrize für die Items enthalten. Und dann summiert man mit einer Abfrage so auf, dass man es in Excel exportieren kann.

Nein, in der Datennbank wird keine Antwortmatrix vorgehalten. So eine Idee kommt oft aus dem Exelbereich, hat aber mit einem Datenmodell einer relationalen Datenbank wenig zu tun. Die Umsetzung in eine Auswertungsmatrix erfolgt ausschließlich in Excel mit den dort vorhandenen Tools wie Pivottabellen usw.

Knobbi38

[Carl]

Dann kann ich aber an der Datenbank so gut wie nichts aus eigener Kraft hinbekommen. Ich habe keine Zeit, neben der vielen Arbeit her noch ein Informatikstudium zu Datenbanktheorie zu betreiben, nur weil es nicht schön genug ist, eine exportierbare Tabelle zu speichern.

Nochmal: Es geht nicht um die Frage. Die Fragen sind egal.  Man könnte die Quadrupels genau so gut randomisieren oder Tripels oder Pentupels draus machen. Entscheidend ist nur das Item und wie es zwischen -4 und +4 geratet wurde. 9 Werte mit 0 als Mitte.

[Carl]

Die Items sind das Einzige, worum es hier geht. Die Rohwerte der Items einer Skala sollen innerhalb der Datenbank aufsummiert und zurück gegeben werden, um dann automatisch aus der Verteilungstabelle Prozentränge heraus zu suchen und sie anzuzeigen. Der Proband bekommt sofort sein Ergebnis angezeigt. Alles in Access.

Excel braucht man nur zur Erstellung der Verteilungstabelle, aber sonst nicht mehr.

Pivottabellen braucht man überhaupt nicht.

[Knobbi38]

Hallo Carl,

und was erwartest du jetzt von den Helfern?

Datenbanken zu entwerfen und zu modellieren erfordert ein gewisses Maß an Grundkenntnissen in Access, schließlich ist das nur das Tool, womit man eine Datenbankanwendung erstellen kann. Die Lernkurve ist leider etwas anders als z.B. bei Excel und eine DB Anwendung läßt sich nun mal nicht so einfach zusammenklicken, wie ein paar Formeln in XL.

Ich habe keine Zeit, neben der vielen Arbeit her noch ein Informatikstudium zu Datenbanktheorie zu betreiben

So eine Aussage kommt bei Helfern in einem Forum selten gut an, zumal sie ihre Freizeit auch  anders verbringen können, denn die meisten helfen hier ehrenamtlich. Wenn du keine Zeit hast, empfehle ich dir das Tool "LamaPoll", die haben sicherlich ein paar passende Vorlagen.

Knobbi38

Nachtrag:
Ich habe erst jetzt deinen zweiten Beitrag gesehen. Was hindert dich daran, in einer Abfrage die Summe für die Items zu bilden?

[Carl]

Wahrscheinlich gehst Du davon aus, dass ich eine Umfrage machen möchte, bei der dann die eigentliche Arbeit das Zusammenstellen und die Auswertung der Umfrage per Excel ist. Ich möchte aber einen fertigen Fragebogen, der momentan auf Papier ist und umständig mit Folien ausgezählt werden muss, als Computervariante erstellen. Es soll danach ein automatisches Auszählen, ein Aufsummieren und ein Heraussuchen der Rohwerte aus einer gegebenen Verteilungstabelle erfolgen, ohne dass noch Handarbeit erfolgen soll. (Und ja, es sollen auch veraltete Items ausgetauscht und deshalb die Verteilungstabelle nochmal überarbeitet werden.)

Ein anderes Ziel ist beispielsweise, dass ich selber aus eigener Kraft Verbesserungen vornehmen können soll, die  sich jemand wünscht, ohne dass ich hier ständig in einem Forum nachfragen muss. Es ist ja hier offensichtlich so, dass man eine komplett neue Denkweise erlernen soll. Versteh mich bitte nicht falsch, die hat sicher ihre Berechtigung und ist sicher auch schlanker als Alltagsdenken. Aber wie soll ich die, falls ich es jemals kapieren würde, anderen beibringen, die dann was dran geändert haben werden wollen?

Dann kommt noch ein weiterer Aspekt hinzu, dass nämlich eine gute Arbeit dann vorliegt, wenn das Ziel erreicht ist. Perfektion heißt, das Ziel erreichen. Wir wollen weiter kommen. Es soll voran gehen. Es ist nicht notwendig, alles innerlich schlank und perfekt zu machen. Das Ergebnis zählt. Wir haben hier beispielsweise auch kein Speicherproblem. Auch in der Natur gewinnt nie das Perfekte, sondern das passendste, das fitteste für den jeweiligen Zweck und Umgebung.

Ich brauche ein Datenmodell, das ich selber verstehen und an dem ich selber arbeiten kann. Da soll letztendlich eine Tabelle mit Spalten für Items und Zeilen für Probanden ausgegeben werden, die man dann in einer Abfrage automatisch aufsummieren kann, um dem Probanden sofort seine Werte zurück zu melden. Wie er abgeschnitten hat.

---

Nachtrag:
Ich kann das nicht. Ich müsste jeden einzelnen Schritt hier nachfragen und irgendwann werdet Ihr ungehalten.

Das wäre wie bei meinem letzten Projekt vor Jahren. Da bin ich die ganze Zeit kritisiert und beschimpft worden und habe mich letztendlich selber durch gekämpft. Willst Du wissen, was draus geworden ist?

[Bitsqueezer]

Hallo,

vielleicht solltest Du mal von "Items", "Skalen", "Fragen" usw. als reine Theorie wegkommen und mal ein simples Beispiel skizzieren. Das müssen keine echten Fragen/Antworten sein, sondern rein fiktive.
Ich kann mir nicht wirklich vorstellen, was Du eigentlich aktuell hast und was Du erreichen möchtest.

Ein Bild, eine Excel-Tabelle, vielleicht auch ein aktuelles Datenmodell, was Du schon hast.

Erst einmal wäre zu unterscheiden, daß ein Datenmodell nach Möglichkeit datenbankorientiert gebaut werden sollte, denn nur dann kann eine Datenbank Dich optimal mit ihren Funktionen unterstützen.

Und da ist der Grundsatz, daß eine Datenbank zeilenorientiert arbeitet, schon weil (bei Access) die Anzahl Felder auf 255 begrenzt ist und man Aufzählungsfelder in Spalten unbedingt vermeiden sollte (sowas wie "Antwort1", "Antwort2" usw.).

Das Datenmodell wiederum muß überhaupt nichts mit der Präsentation und Funktionalität der Anwendung zu tun haben, also wie Formulare oder Auswertungen aussehen. I.d.R. kann man aber durch Anpassung der Funktionalität an eine zeilenorientierte Datenstruktur das Leben arg einfacher machen, darüber hinaus ist es VIEL einfacher zu programmieren, wenn das Datenmodell datenbankkonform gebaut wurde.

Als simples Beispiel: Wenn Du Aufzählungsfelder hast und eine Summe daraus bilden mußt, mußt Du jedes Feld einzeln mit "+" zu einer Summe verketten. Wenn Du zeilenorientiert arbeitest, hast Du je Zeile z.B. eine Antwort und kannst sowohl Antwort 1 bis 10 wie auch 1 bis 10000 mit SUM(Antwort) summieren. Das ist jetzt allgemein gesprochen und hat nichts direkt mit Deiner Problematik zu tun.

Jeder, der nach Dir mit Deinem Datenmodell arbeiten muß, wird es ebenfalls einfacher haben, wenn Du Dich an Datenbankregeln hältst. Dazu kann Dir die Datenbank viel Arbeit abnehmen, beispielsweise das automatische Verhindern von doppelten Einträgen (Unique Index auf z.B. eine n:m-Tabelle), was bei Aufzählungsfeldern so nicht geht.

Bei 615 Beiträgen und mehreren Jahren Beteiligung hier müßtest Du eigentlich schon mal ein wenig mitbekommen haben...

dass nämlich eine gute Arbeit dann vorliegt, wenn das Ziel erreicht ist. Perfektion heißt, das Ziel erreichen.

Würde ich nicht mitgehen. Man kann "irgendwas hinwerfen", was "irgendwie funktioniert" - dann ist das Ziel kurzfristig erreicht, aber nicht zukunftsfähig. Wie Du selbst schreibst, gibt es oft Anpassungen, und die werden immer komplizierter, je weniger man die Basis ordentlich aufgebaut hat. Hat man es gleich korrekt begonnen, mag das Ziel etwas langsamer erreicht werden, dafür können Änderungen leicht eingebaut werden. Wenn man aber für jede Änderung nochmal so lange braucht wie für das ursprüngliche Ziel, dann hat man am Ende bedeutend mehr Zeit verschwendet - und kommt nicht weiter. "Perfektion heißt, das Ziel zu erreichen" ist eine sehr schräge Ansicht, weil es mit Perfektion mal gar nichts zu tun hat, ein Ziel zu erreichen.

Du schreibst oben:
"Da soll letztendlich eine Tabelle mit Spalten für Items und Zeilen für Probanden ausgegeben werden"
aber:
"Pivottabellen braucht man überhaupt nicht."

Genau das ist aber eine Pivottabelle: Daten in Spalten und Daten in Zeilen mit Summierungen in der jeweiligen Kreuzung von Spalte und Zeile.

Und auch hier gleich dazubemerkt: Auch hier bist Du auf max. 255 Spalten begrenzt, egal, wie Du es machst.

Hier ist daher dringend zu empfehlen, zeilenorientiert zu arbeiten, wie es eine Datenbank vorsieht, und dann so eine Auswertung als flache Datentabelle an Excel zu exportieren, was dann komfortable Pivottabellen mit auch Hierarchien, Zwischensummen, Kategorie-Kapselung, sehr viel mehr Spalten usw. anbietet, und leicht umkonfigurierbar ist.

Da braucht man dann gar nichts zu programmieren, um die entsprechenden Summen zu erhalten, und man kann weitere Aggregatsfunktionen auch direkt mit anzeigen, sowas wie Min, Max, Avg, Count usw.

Also, wenn Du Dein Projekt mal weniger theoretisch und mehr praktisch beschreiben könntest, kann ich mir vorstellen, etwas Sinnvolles datenbankkonform zu erstellen, und Du würdest sicher auch mehr Beteiligung bei solchen Fragen erhalten.

Darüber hinaus wäre es sicherlich auch eine Idee für Dich, eine KI Deiner Wahl zu konsultieren, die Dich im Projekt begleiten und Dir auch Designs entwerfen und schnell ändern kann und Dir jede Frage jederzeit geduldig beantwortet. Ein gewisses Grundwissen sollte man aber auch hier mitbringen.

Gruß

Christian

[Knobbi38]

Besser hätte ich es auch nicht zusammenfassen können. 

Knobbi38

[Carl]

Die Items sehen so aus. (Konzeptbild.) Gewählt wurde ein Plus und ein Minus. Die Buttons lassen jeweils nur ein Plus und ein Minus zu und deaktivieren sich dann gegenseitig. Oder vielleicht kann man das noch eleganter machen.

Sie dürfen in diesem Board keine Dateianhänge sehen. 



Im Hintergrund sollen bei jedem Item {+1 oder +1 oder 0} gespeichert werden.
* Aufsummiert werden dann die Werte aller Items einer Skala. Es gibt bsw. Skala {HW Metall oder Elektro oder Gastro usw.} Das sieht der Proband dann aber nicht.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Noch nicht geklärt sind:
* die Anzahl der Items, die es in den Test schaffen
* die Inhalte der Items
* die Anzahl der Skalen
* die Inhalte der Skalen usw..


Sie dürfen in diesem Board keine Dateianhänge sehen.


Das sind die Beziehungen. Ich möchte für die Items eine einzelne Tabelle, in der -1,1, und 0 stehen. Spalten Items, Zeilen Pbn. Ich komme sonst da nicht durch.

Die Antwort von Bitsqueezer muss ich noch genau durchlesen.

[Knobbi38]

Das speichern der 0 bringt dir nichts.

Basierend auf tblAnwort:

Code [Auswählen] Erweitern

SELECT
    i.ItemID,
    i.ItemText,
    Nz(SUM(sub.IsPlus), 0) AS Anzahl_Best,
    Nz(SUM(sub.IsMinus), 0) AS Anzahl_Worst,
    Nz(SUM(sub.IsPlus), 0) + Nz(SUM(sub.IsMinus), 0) AS Gesamt_Erwaehnungen
FROM tblItem AS i
LEFT JOIN (
    -- Plus-Nennungen isolieren
    SELECT GewaehltPlusItemID AS ItemID, 1 AS IsPlus, 0 AS IsMinus
    FROM tblAntwort

    UNION ALL

    -- Minus-Nennungen isolieren
    SELECT GewaehltMinusItemID AS ItemID, 0 AS IsPlus, 1 AS IsMinus
    FROM tblAntwort
) AS sub ON i.ItemID = sub.ItemID
GROUP BY
    i.ItemID,
    i.ItemText
ORDER BY
    Nz(SUM(sub.IsPlus), 0) DESC,
    Nz(SUM(sub.IsMinus), 0) ASC;
Das liefert dir die Summen pro Item. Zum ausprobieren die Kommentare (Zeile beginnt mit --) entfernen!

und noch eine andere Auswertung:

Code [Auswählen] Erweitern

PARAMETERS [@ProbandID] Integer;
SELECT
    s.SkalaID,
    s.Code AS Skala_Code,
    Nz(Sum(sub.Score), 0) AS Skala_NetScore
FROM (tblSkala AS s
LEFT JOIN tblItem AS i ON s.SkalaID = i.SkalaID)
LEFT JOIN (
    SELECT GewaehltPlusItemID AS ItemID, 1 AS Score
    FROM tblAntwort
    WHERE ProbandID = [@ProbandID]

    UNION ALL

    SELECT GewaehltMinusItemID AS ItemID, -1 AS Score
    FROM tblAntwort
    WHERE ProbandID = [@ProbandID]
) AS sub ON i.ItemID = sub.ItemID
GROUP BY
    s.SkalaID,
    s.Code
ORDER BY
    Nz(Sum(sub.Score), 0) DESC;
Dieses ist eine Parameterabfrage mit Bezug zu genau einem Probanden.

Wie du siehst, werden nur die +1 und -1 Antworten gebraucht und ausgewertet. Das sind nur ein zwei mögliche Beispiele! Machbar ist vieles, aber das setzt immer ein brauchbares Datenmodell voraus.

Knobbi38

[Bitsqueezer]

Hallo,

OK, das war schon mal einiges klarer.
Daß "Skala" hier eigentlich eine Gruppierung bedeutet, wird einem erst klar, wenn man den Begriff entsprechend einordnen kann - für mich ist "Skala" eine Messleiste, etwa ein Lineal oder eine Geschwindigkeitsanzeige.
Du meinst dann wahrscheinlich eher das hier, weil Du mal geschrieben hast, daß Du Mediziner bist.
https://de.wikipedia.org/wiki/Klinische_Skalen

Ich bin's nicht, daher muß man erst in Deine Gedankenwelt eintauchen, um zu verstehen, was Du eigentlich möchtest. Also danke für den Screenshot.

Was Du hier schon mal klar erkennen kannst, wenn Du das letzte von mir gelesen hast: Du hast in Deinem Entwurf Aufzählungsfelder, nämlich "tblKonfigFrage" mit Item1-4ID, und Du siehst auch gleich hier, wieviele Probleme das sofort aufwirft, schon im Datenmodell: Weil Du die Lookup-Tabelle der Items jetzt mit 4 Feldern verknüpfen mußt, womit Dein Modell schon optisch total überfrachtet ist.

Und es ist völlig unnötig, ja kontraproduktiv. Du schreibst anderweitig von "Quadrupeln", "Quintupeln" - also überlegst Du ja auch schon, was wenn es mal 5 Antworten gibt statt nur 4. Dann bist Du sofort mit Deinem Datenmodell aufgeschmissen und mußt etliches am Modell und Deiner Anwendung anpassen.

Richtig ist daher: Zeilenorientiert arbeiten, wie es in einer Datenbank üblich ist (das hat NICHTS damit zu tun, wie das am Ende dem User präsentiert wird!).

Also: Eine Tabelle für eine Fragekonfiguration, bestehend aus ID und Konfigurationsname (wenn Du keinen Namen brauchst, könntest Du das auch weglassen, aber es ist i.d.R. empfehlenswert, wenn Du die ID als AutoID baust und eine neue Zeile einfügen willst, mind. 1 Feld mehr zu haben. Außerdem beschreibt es die Konfiguration, auch wenn Du den Namen nicht anzeigst später).
Eine Tabelle mit Items und ihrer "Skala-Gruppierung" hast Du bereits korrekt - jedes Item nur 1x, zu einer SkalaID zugeordnet. Wenn viele Items immer wieder in verschiedenen Skalen vorkommen können, ist es besser, eine Item-Liste nur mit ID und Itemname anzulegen und die SkalaID per n:m-Tabelle zuzuordnen. Das ermöglicht Dir die Wiederverwendung von Items in verschiedenen Skalen. Es ermöglicht Dir dann ebenso, einen Unique Index auf die n:m-Tabelle zu legen, damit ein bestimmtes Item nur einmal einer bestimmten Skala zugeordnet werden kann.
Da in diesem Fall jedes mehrfach verwendete Item quasi ein "Item-Typ" wird, kannst Du sie auch gemeinsam summieren, also das gleiche Item über Skalengrenzen hinaus.
Wenn Du aber sagst, daß Du das nicht brauchst und jedes Item nur genau einmal je Skala brauchst und in keiner anderen Skala vorkommen kann, ist Dein Modell völlig OK (also dieser Teil... ).

Nun kommt die Konfiguration der Frage:
Du brauchst auch hier eine n:m-Tabelle, die besteht also aus der Konfig-ID und aus der ItemID. Unique Index über beide, wie gehabt, damit Du das gleiche Item nicht mehrfach zu einer Konfig-ID zuordnen kannst.

Wo ist der Unterschied? Du kannst nun Fragen konfigurieren aus nur 2 Items, aus 4, 5 oder 1000000 Items (wenn der Befragte viel Zeit hat... ).

Wenn Du Deine UI nun auf dieses Konzept anpaßt, nämlich zeilenorientiert, brauchst Du am Ende diese auch nie wieder zu ändern.

Aber als nächstes brauchst Du ja noch eine Antworttabelle.

Die Konfig-n:m-Tabelle versieht man neben den beiden besagten auch mit einer AutoID als PK.
Damit kannst Du auf jede Kombination von Konfig und ItemID mit nur einer ID zugreifen. Genau die brauchst Du dann für die Antwort:
Die Antworttabelle besteht aus der ProbandID, der KonfigZuItemID, sowie nur ein Antwortfeld (nix mit "gewählt minus" oder "gewählt plus") Das ist ein Wert als 16Bit Integer (weil 8Bit keine negativen Zahlen zuläßt, sonst könnte man auch 8Bit nehmen). Deine UI kann nun die Auswahl je Frage anbieten, ob +1 oder -1. Für die anderen beiden Items, die dann 0 sein müssen (oder auch 10000 Items, die 0 sein sollen) braucht gar nichts gespeichert zu werden, wie Knobbi das oben schon gesagt hat. Aber da ja auch der Auswahltext für alle Items angezeigt werden soll, kann man in die Antworttabelle je Item der Konfig je eine Zeile mit der ItemID einfügen. Das ist zwar theoretisch nicht nötig, macht es aber im Ergebnis einfacher und Platz auf der Platte spielt heute ja keine Rolle mehr (braucht auch kaum Platz, da nur IDs und Antwort gespeichert wird).

Also:
AntwortID (PK, AutoID)
ProbandID (FK auf Probandtabelle)
KonfigZuItemID (FK auf die n:m-Tabelle zwischen Konfig und ItemID)
Antwort

Dazu könnte man z.B. noch ein Datum in die Antworttabelle packen, wenn Du das ganze später mit dem gleichen Probanden nochmal wiederholen möchtest.

Mit der Methode kannst Du nun z.B. 5 Items mit INSERT-Abfrage (INSERT...SELECT) in die Antworttabelle schreiben mit Antwort = 0, weil ja noch nichts ausgewählt wurde.
Du könntest die Konfigtabelle auch noch mit einer Prüfungstabelle überstellen, um eine Liste von Fragen einer bestimmten Prüfung zuzuordnen.

Mit INSERT...SELECT kannst Du außerdem mit Zufallsfunktionen die Reihenfolge der Antworten beliebig ändern. Einfach ein zusätzliches "Sortierung"-Feld in die Antworttabelle und dann die Sortierzahl per Zufallsgenerator erstellen lassen. Im Formular kannst Du die Items dann per Sortierung in der erstellten Reihenfolge ausgeben lassen. Alles nicht möglich mit Aufzählungsfeldern.

Das +/- oder keine Entscheidung muß hier natürlich datensatzübergreifend feststellen, was in der aktuellen Frage noch an Antworten möglich ist. Da es aber nur um wenige Items geht innerhalb einer Frage, ist das kein Problem. Das ginge zur Not sogar mit einem Durchlaufen des Formular-Recordsets (was man normalerweise möglichst vermeidet).

Ebenso könntest Du das per SQL erledigen, was Dir als berechnetes Feld ausgibt, daß es -1 oder +1 schon gibt und dann bei allen anderen Items ein "Verbotssignal" ausgibt. Das wiederum kannst Du mit simplem ConditionalFormatting abfragen und das kann Dir dann Felder auf Disabled setzen.
Du würdest das Formular dann nicht so aufbauen wie in Deinem Screenshot, sondern ganz simpel mit der Fragenliste als Item-Listen (das ist z.B. in der Datasheet-View möglich, Unterformulare in übergeordneten Datensätzen). Access übernimmt so das meiste für Dich und wenn es mal mehr Fragen je Prüfung und/oder mehr oder weniger Antworten gibt (oder auch unterschiedliche Anzahl Antworten je Frage), ist das ebenfalls das gleiche. Weder Datenmodell noch UI müssen danach je wieder geändert werden.

Daneben kann man später eine Auswertung, wie beschrieben, mit Reports oder Excel-Export und Pivot-Tabellen oder PivotCharts bauen, was auf jeden Fall empfehlenswert in Excel zu bauen wäre. Excel kann mit PowerQuery sich die Daten auch selbst aus der Datenbank holen und mit einem Klick auf "Requery" den aktuellen Stand jederzeit anzeigen lassen, selbst wenn die Probanden noch bei der Prüfung sind.

Cool, was alles geht, wenn man es datenbankkonform macht, oder?

Und wie Du siehst: Das Datenmodell ist doch sehr einfach und leicht verständlich.


Gruß

Christian

[Knobbi38]

@ Christian:

Wie ich in #1 schon geschrieben habe, wurde hier bewusst denormalisiert, da es sich eigentlich immer nur um 4 Items pro Formular handelt.
Carl hat das Design in dem Fall einfach nur übernommen.

Wie gesagt, das Datenmodell basierte auf den Annahmen, dass es
a) um ein ForcedChoice Verfahren gerade (mit 4 Items) geht, ungerade (5 Items) ist eine anderes Verfahren und braucht auch ein anderes Formular mit anderen Regeln, und
b) die eigentliche Konfiguration/Setup in Excel gemacht wird, sprich die Zusammenstellung von Items und Skalen passiert dort und wird nur für die Befragung von dort in die entsprechenden Tabellen importiert.

Wenn jetzt die Vorgaben geändert werden sollen, muss man das Datenmodell prüfen und ggf. nochmal abändern. Ansonsten ist es eigentlich für die Tupels optimiert. Die "unübersichtliche" Darstellung im Beziehungsfenster ist den Constraints geschuldet, die Access so darstellt. Auch würde man für die Fragen keine Combobox mit Lookuptabellen verwenden, sondern die Items werden mit Labels oder Textboxen angezeigt. Für die Eingaben werden dann  4 OptionGroups mit je 2 ToogleButtons verwendet. 
 
Gruß
Knobbi38 

[Bitsqueezer]

@Knobbi: Es gibt immer mehr als einen Weg, etwas zu lösen.
Es ist kein Problem, mit der gezeigten Methode auch nur genau 4 Antworten/Fragen zu konfigurieren. Aber Du KANNST so auch andere Konfigurationen bauen.

Ja, die Darstellung der Constraints in Access ist ja bekannt und jeder vernünftige Diagrammeditor stellt das auch nur mit 2 Tabellen dar (die es ja auch wirklich sind). Ändert aber nichts am Problem, nämlich Aufzählungsfelder und mehrfache Verlinkung.

Auch ist es kein Problem, die Anwendung dahingehend zu erweitern, daß man eben diese Zusammenstellung direkt in Access vornimmt, spart dann auch den umständlichen Import.

Ich sehe nicht, warum man hier unbedingt denormalisieren sollte, man darf Anforderungen auch abändern, wenn sich dadurch eine flexiblere Lösung ergibt.

Ist mir persönlich aber auch egal. Ich wollte nur aufzeigen, wie man das Problem sehr easy datenbankkonform und flexibel lösen kann, mit geringem Aufwand in Pflege und Konfiguration, auch wenn später Änderungen einfließen.

Gruß

Christian

[Knobbi38]

Nachtrag:

Auszug von KI Gemini:

Empfehlung für Forced-Choice
Da es sich um genau 4 Items handelt (eine feste, unveränderliche Zahl), ist das Flat-Tuple Pattern (4 dedizierte Spalten) in 90 % der Fälle die beste Wahl für relationale Datenbanken. Es bietet die perfekte Balance aus der gewünschten Denormalisierungs-Performance (keine Joins nötig) und der Möglichkeit, psychometrische Auswertungen (z. B. "Wie oft wurde Item 1 als 'Most' gewählt?") nativ und performant direkt in SQL via COUNT oder SUM zu berechnen.

Das war der Grund für die Denormalisierung. Sicherlich kann man das auch anders machen, aber wegen der verschiedenen Regeln (bei z.B. 5 Items) ist das im Formular erstmal nicht so einfach zu implementieren und muss sicherlich dynamisch gemacht werden.

Sicherlich kann man das Setup auch in Access implementieren, was eher seltener gemacht wird. Wegen der bessern Auswerte- und Anzeigemöglichkeiten wird dafür oft XL bevorzugt, aber jeder wie er möchte.