- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#41
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Bitsqueezer - September 29, 2026, 21:14:28@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
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
#42
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Knobbi38 - September 29, 2026, 20:55:44@ 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
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
#43
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Bitsqueezer - September 29, 2026, 16:05:09Hallo,
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
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
#44
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Knobbi38 - September 29, 2026, 14:21:09Das speichern der 0 bringt dir nichts.
Basierend auf tblAnwort:
und noch eine andere Auswertung:
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
Basierend auf tblAnwort:
Code [Auswählen]
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]
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
#45
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Carl - September 29, 2026, 13:16:14Die 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.
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.
#46
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Knobbi38 - September 29, 2026, 10:36:45Besser hätte ich es auch nicht zusammenfassen können.
Knobbi38
Knobbi38
#47
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Bitsqueezer - September 29, 2026, 10:31:04Hallo,
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...
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
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...
Zitatdass 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
#48
Access Programmierung / Re: Fragebogen mit 4 Items
Letzter Beitrag von Carl - September 29, 2026, 07:08:07Wahrscheinlich 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?
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?
#49
Microsoft Outlook / Re: Outlook 2024 und Datendate...
Letzter Beitrag von Hondo - September 28, 2026, 21:55:27OK, die bescheuerten Töne sind weg, und den Hauptordner (Profilname) konnte ich mit dem Tool umbenennen.
Sieht so weit jetzt ganz brauchbar aus.
Danke für eure Hilfe.
Gruß Andi
Sieht so weit jetzt ganz brauchbar aus.
Danke für eure Hilfe.
Gruß Andi
#50
Microsoft Outlook / Re: Outlook 2024 und Datendate...
Letzter Beitrag von Hondo - September 28, 2026, 21:10:22Zitat von: Knobbi38 am September 28, 2026, 14:23:23schau doch mal bei den Optionen, ob es dort Einstellungen für Barrierefreiheit (Feedback) gibt.Danke, das hat geholfen.