Tabelle erstellen, deren Feldnamen (Spalten) aus einer anderen Tabelle stammen

[rene_walsch]

Liebe Foristen,

ich möchte in MS Access per Knopfdruck eine Tabelle erstellen, deren Spaltennamen aus einer und deren Zeilennamen (Inhalt des ersten Feldes der Datensätze) aus einer anderen Tabelle stammen. Beispiel: tbLaborwerte (enthält eine variable Anzahl von Laborwerten), tbVisiten (Enthält eine variable Anzahl von Arztbesuchen)

Messwert	Vorstellung	Erste Wiedervorstellung	Abschlussbesuch
Blutzucker
Testosteron
Natrium

Die Visitenfelder sollen dabei von Ja/Nein-Typ (Boolean) und zunächst NIL oder Nein sein (kann ich in dieser Box leider nicht visualisieren). Ziel ist es, zu Beginn einer Behandlung alle notwendigen Laborbestimmungen per Mausklick auszuwählen. Dabei sind sowohl die Zahl der benötigten Laborwerte als auch die Zahl der Visiten für jeden Patienten verschieden, weshalb ich das Problem nicht mit starren Tabellen lösen kann. Es sind auch sehr viel mehr Messwerte und Visiten als in diesem Beispiel.

Mir geht es vor allem um Schritt 1, die Erstellung einer leeren Tabelle, deren Feldnamen (bis auf den ersten) einer anderen Tabelle entnommen werden. Geht das per SQL oder VB? Schritt 2 ist dann eine simple Anfügeabfrage.

Für Hilfe wäre ich dankbar!
René

 

[dabadepdu]

Creates a make-table query.
Syntax
SELECT field1[, field2[, ...]] INTO newtable [IN externaldatabase]
FROM source

SELECT...INTO Statement - Microsoft Support

support.microsoft.com

Deine Beschreibung ist mir nicht wirklich verständlich. Die Beschreibung von Formularverhalten oder ähnlichem hat nichts mit SQL zu tun und hilft nicht selten. Es macht den Eindruck, dass Du etwas tust, was man normalerweise nicht macht, höchstens in einem Entwicklungsprozess. Falls ein normales Verhalten während der Nutzung sein soll, frag Dich bitte, wie die erzeugten Tabellen später (automatisch) weiter genutzt werden (durch Fomulare, Reports, etc) oder ob sie sauber wieder entfernt werden, falls es temporären Charakter hat.
Am besten, man findet einen Weg, der ohne die dynamische Erzeugung auskommt.

 

[rene_walsch]

Vielen Dank für die Antwort.

Gruß,
René

 

[ukulele]

Erstens: Das, was du vorzuhaben scheinst, ist mit "normalem" SQL Code nicht einfach möglich. Natürlich ließe sich das bauen, z.B. mit dynamischem SQL, das würde allerdings definitiv ein richtiges DBMS erfordern. Access ist zwar eine Datenbank die mit SQL arbeitet und ähnlich aufgebaut ist, es handelt sich aber nicht um ein vollwertiges DBMS.

Zweitens: Dein Vorhaben ist mit ziemlicher Sicherheit Unsinn, aus organisatorischer Sicht, wie @dabadepdu schon geschrieben hat. Ein Access Front End käme damit gar nicht klar. Grund ist aber nicht das Access hier schwächelt sondern das das einfach nicht der Weg ist wie relationale Datenbanken aufgebaut werden. Stichwort ist Normalisierung. Du scheinst aus jedem Datensatz eine Entität machen zu wollen, SQL ist aber keine Tabellenkalkulation oder ähnliches.

 

[rene_walsch]

Hallo ukelele,

am angefügten Beispiel siehst Du die Dimension meines Anliegens (ich manage klinische Studien):

28 Visiten=Spaltenköpfe und 31 Aktivitäten=Zeilenköpfe. Für die Berechnung der Visitenkosten benötige ich die Information, ob die jeweilige Aktivität beim jeweiligen Visit gefordert ist. Wenn ich der klassischen Master-Detail-Logik relationaler Datenbanken folge, also Studie-Visite-Aktivität (1:n:m), muss ich 28 Visiten und 31 Aktivitäten anlegen, dann jede Visite einzeln aufrufen und in einem Unterformular die Aktivitäten von Hand aus einer Picklist auswählen. Da ist schnell ein Arbeitstag weg und die Arbeit quälend ermüdend. Um wieviel eleganter wäre es, wenn ich 28 Visiten in eine Tabelle eingebe und 31 Aktivitäten in eine zweite (macht 59 Klicks), dann auf einen Knopf drücke (60. Klick) und eine Tabelle mit 29 Spalten und 32 Zeilen erhalte, deren Felddatentyp Boolean ist (ich weiß, dass es den in SQL nicht wirklich gibt). Mit einer solchen Tabelle kann ein Access-Formular ganz hervorragend umgehen. Dann wähle ich in diesem Datenblattformular per Mausklick die etwa 150 Aktivitäten in zwei, drei Minuten aus, die tatsächlich stattfinden sollen (die schwarzen Punkte in der Grafik). Mausklicks in einer Ja/Nein-Box sind zudem deutlich weniger aufwändig sind als die Auswahl aus langen Picklisten, das Ganze würde keine halbe Stunde dauern. Ich halte diese Überlegungen keineswegs für "Unsinn". Da das Institut etwa zwei neue Studien pro Jahr auflegt, würde das Ganze etwa zwei Arbeitstage pro Jahr sparen.

"SQL ist aber keine Tabellenkalkulation". Danke, verstanden (und zwar vor etwa 30 Jahren ;-) Ich hatte mich an dieses Forum gewandt, weil andere im Gegensatz zu mir täglich programmieren und den erforderlichen SQL- oder VB-Code vermutlich locker aus dem Handgelenk schütteln können. Ich hatte an VB-Code ähnlich dem hier gedacht:

SQLStatement='CREATE TABLE tbVisitsActivities (Activity TEXT, '
with tbVisits do
begin
Repeat
SQLStatement = SQLStatement + tbVisits.VisitName + ' SMALLINT,'
Until (EoF)
end
SQLStatement=SQLStatement +');'
SQLStatement.Execute

Vielen Dank für Deine Zeit.

Gruß,
René

 

[ukulele]

Also es gibt im wesentlichen zwei Ansätze:

"Eingabeorientiert"
Ich würde mindestens eine Tabelle Studien anlegen, die dann 1:n mit einer Untertabelle zusammen arbeitet. Dann musst du nicht, wenn du pro Studie eine Tabelle anlegst, dich auch um irgendwie kopierte Access-Formulare kümmern.

Dein Screenshot hat 31 Zeilen, das wären dann EIN Datensatz in der Untertabelle mit 31 * irgendwas Spalten für Booleans (Boolean oder BIT gibt es natürlich auch in SQL, heißt vielleicht je nach DBMS anders). Aus einer Vorlage kopierst du dann den einen Datensatz in eine neue Studie, mit SQL oder VB ist egal.

Dadurch schnelle Eingabe mit einem Formular über alle Vorgänge (Visiten, Aktivitäten, was auch immer), es muss aber jedes mal die Tabellendefinition und das Formular angepasst werden wenn sich die Studie irgendwie vom Vorgänger unterscheidet. Flexibel ist das nicht: Die Studien können sich eigentlich gar nicht ändern ohne jedes mal was "dran zu kleben". Mit relationalen Datenbanken hat das nichts gemeinsam.

"Verarbeitungsorientiert"
Du normalisierst das ordentlich durch, jede Entität eine Tabelle. Das wäre sehr flexibel, man kann aber einfach nicht jeden Datensatz auf einer pivotierten Ansicht gleichzeitig bearbeiten (jedenfalls nicht mit Access im Front End). Aber abgesehen von der Eingabe sind die Daten super. Du kannst jede Studie komplett variieren, du kannst archivieren, Templates kann man sich auch bauen um eine leere Studie anzulegen und vor allem kannst du auswerten. Willst du wissen nach wie vielen Visiten ein Teilnehmer durchschnittlich gestorben ist? Kein Problem...

Du befasst dich jetzt zurecht mit der Eingabe. Aufwendig zu bauen weil viel Fleißarbeit aber dafür kann man schön ja / nein durchklicken um Informationen zu erfassen. Wobei ich mir die Frage stelle kommen die Informationen alle auf einmal in die Datenbank oder bei jeder Visite genau ein Teil? Wenn alle auf einmal, warum macht man sich dann überhaupt die Mühe wenn das nur passiert wenn alles gelaufen ist?

Du sagst aber nichts über das, was im Anschluss passiert, was möchte man damit tun?

Naürlich muss man sich nicht mal entscheiden. Du kannst auch für die Eingabe eine Excel oder Access Datei anlegen und diese dann in einen SQL Server übernehmen. Beim Datenimport musst du dann halt einmal viel Code produzieren aber könntest damit die Daten in eine rechte, relationale Form überführen.

 

[dabadepdu]

Danke, verstanden (und zwar vor etwa 30 Jahren ;-) Ich hatte mich an dieses Forum gewandt, weil andere im Gegensatz zu mir täglich programmieren und den erforderlichen SQL- oder VB-Code vermutlich locker aus dem Handgelenk schütteln können. Ich hatte an VB-Code ähnlich dem hier gedacht:

Mmh, ich bin nicht sicher, ob Du das verstanden hast. Vielleicht was Normalisierung ist, aber vielleicht nicht, was die Auswirkungen sind / wären, wenn man gegen die Normalisierung arbeitet.
Du kannst Dir natürlich Code bauen, der Dir Statements zusammen stellt, die die gewünschte Tabelle erzeugen. Aber was kommt dann?

Du musst Dir auch Code bauen, um diese Tabellen abzufragen. Das geht auch noch relativ einfach. Zuletzt musst Du Dir dann Code bauen, um Reports davon / dafür anzulegen. Und natürlich das was Du suchst, sogar Masken zur Bearbeitung?
Nehmen wir als Beispiel die Fragestellung, wieviel Visiten wurden durchgeführt (am Tag, auf Station, ...). Jeder Fall, für den Du die Anzahl der Visiten brauchst, benötigt eine Aufsummierung über 28 Spalten. In einer normalisierten Tabelle wäre es dagegen nur eine Summe.
Weiter, wenn es jemals mehr oder weniger Visiten werden, dann ist Spalte 29 oder 30 fällig und Du musst alle Code Teile erweitern, die dynamisch SQL zusammenbauen, ebenso die Formulare, Abfragen und Reports.

Wenn Du scharf darauf bist, das zu machen, mach es halt, es ist kein Hexenwerk, Texte (Spaltennamen) zu einem SQL Statement zusammenzubauen. Du wirst das sehr oft machen müssen und es wäre dann ratsam, dafür generalisierte Funktionen zu programmieren. Ich vermute, das wird Dir aber niemand hier abnehmen. Auch bzw. weil die meisten hier das schon länger machen und wenig Sinn darin sehen, Dinge zu erstellen oder vorzumachen, die sie für falsch halten.

Ich kann Dein Grundproblem sehr gut verstehen. Wir haben mal Komponenten entwickelt, die Kreuztabellen (Pivottabellen) dynamisch aus normalisierten Tabellen erzeugen und editierbar machen, visuell nicht per SQL. Das ist viel Aufwand und mit etwas Glück dankt es einem der ein oder andere Anwender später bei der Eingabe von Daten. Tja, die Komponenten sind mittlerweile auf dem Schrott.

Pivottabellen sind idR das Ergebnis eines Reports, also einer gezielten Auswertung von normalisierten Tabellen. Sie sind nicht das klassische Werkzeug zur Datenpflege, erst Recht kein probates Mittel zur Speicherung von Daten in SQL / Tabellen.

 

[MDDaniel]

Dabei sind sowohl die Zahl der benötigten Laborwerte als auch die Zahl der Visiten für jeden Patienten verschieden, weshalb ich das Problem nicht mit starren Tabellen lösen kann.

Wozu willst du dafür unterschiedliche Tabelle erstellen?
Die Information die du speichern willst besteht doch aus:
Messwert
Laborwert
Visite

Das ist egal für welche Visite. Wenn du diese Daten untereinander schreibst kannst du damit jedes Formular und jeden Bericht bauen.