collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 80
  • Punkt Versteckte: 1
  • Punkt Mitglieder: 2
  • Punkt Benutzer Online:

* Forenstatistik

  • stats Mitglieder insgesamt: 14132
  • stats Beiträge insgesamt: 68386
  • stats Themen insgesamt: 9210
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 17
  • stats Am meisten online: 415

Autor Thema: Statistik  (Gelesen 1043 mal)

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Statistik
« am: September 18, 2018, 19:50:18 »
Ich weiß, Access ist nicht für Statistik entwickelt. Aber ich möchte über eine Abfrage Summen bilden und prozentuale Anteile berechnen, die dann in einem Diagramm ausgegeben werden.

Bitte nicht gleich druff hauen. Meine Idee ist:

(1) Eine Abfrage und ein HF mit einem Endlos-UFO, das auf der Abfrage basiert.
(2) in dem HF soll es ein Feld geben, in das man eine Zahl eingeben kann. Zum Beispiel "2017". Mit dieser Zahl wird dann ein Filter in der Abfrage angesteuert. Zum Beispiel werden dann nur DS aus 17 angezeigt.
(3) in der Kopfzeile des endlos-UFO's bringe ich Zählfelder unter, die auszählen, wieviele DS gerade angezeigt werden. Die werden dann vom HF ausgelesen.
(4) Damit steuere ich formularbasiert eine Formel an, die dann Werte ausgibt, welche zur Erstellung einer Graphik verwendet werden.

Haltet Ihr diesen Plan für umsetzbar und wenn nein, was würdet Ihr statt dessen empfehlen?

Carl
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23512
Re: Statistik
« Antwort #1 am: September 18, 2018, 20:18:01 »
Hallo,

1) und 2) sind noch verständlich.

3) und 4) sind unklar, wie damit zu einem Diagramm zu kommen ist.



3)  Datensätze werden nicht anhand der Anzahl "ausgelesen", eher anhand eines Kriteriums selektiert (gefiltert). Das bedeutet, dass das HF auf einer Tabelle/Abfrage basieren muss, die die gewünschten Felder enthält, was ja dann mehr oder weniger identisch mit dem UFO wäre.

4) "steuere ich formularbasiert eine Formel an"   ?? 
       "die dann Werte ausgibt"   wohin ausgibt? 

Ein Diagramm hat in aller Regel eine Abfrage als Datenbasis (Rowsource). Insofern könnte gleich die für das UFO verwendete (und gefilterte) Abfrage für ein Diagramm dienen.

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #2 am: September 18, 2018, 21:51:45 »
Also mit 3) habe ich Erfahrungen, das funktioniert problemlos. Man bringt im Formularkopf ein Zählfeld unter, dessen Wert dann im HF abgerufen wird. Damit kann man genau ermitteln, wieviele DS gerade aktuell angezeigt werden. (und somit auch gefiltert sind) Das ist notwendig, weil es auch formularbasierte Filter gibt, die also nicht auf eine Abfrage zurück gehen.

Das HF basiert nicht auf der Abfrage, nur das UF. Das HF filtert aber formularbasiert.

Ich brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht. Damit der User dort z.B. einen Zeitraum eingeben kann, nach dem gefiltert werden soll. Oder ein Textfeld, um z.B. alle einzuschließen, die mit "abc*" anfangen.

zu 4) Man kann in einem ungebundenen Feld etwas nach einer selbst geschriebenen Formel berechnen lassen, da sehe ich keine Probleme. In dem Feld steht dann einfach eine Zahl, z.B. 14 (Prozent). Diese Felder erzeuge man dann für alle Merkmalsausprägungen des gewünschten Kriteriums, so dass sie sich zu 100 summieren.

z.B. drei ungebundene Felder im HF
[erfolgreichbeendet] = 56
[abgebrochen] = 14
[nochimProzess] = 30

Allerdings weiß ich auch noch nicht, wie ich damit zu einem Diagramm kommen kann. Es müsste dann wahrscheinlich auch eine formularbasierte Graphik sein.

Kennt jemand eine beispiel-db, wo sowas mal behandelt wurde?

Carl
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23512
Re: Statistik
« Antwort #3 am: September 20, 2018, 09:00:42 »
Hallo,

recht schwierig, dies zu verstehen...

3)   Was ist denn ein Zählfeld?   Ein Steuerelement mit Inhalt  =Anzahl(*)  Im Formularkopf des UFO's  ?


Zitat
Das ist notwendig, weil es auch formularbasierte Filter gibt, die also nicht auf eine Abfrage zurück gehen.


Warum ist so ein "Zählfeld" notwendig?

Zitat
Das HF basiert nicht auf der Abfrage, nur das UF.

Heißt das, es ist ungebunden


Zitat
Das HF filtert aber formularbasiert.
 
??  Ein "formularbasierter Filter" (des HF) würde die im HF angezeigten Datensätze filtern.  Die gibt es aber nicht, weil es ungebunden(?) ist.

Zitat
Ich brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht.

Du brauchst also eine Referenz auf ein Steuerelement in der Where-Condition einer Abfrage?

Schreibe im Abfrageentwurf im Feld "Bedingung"   z. B. Forms![MeinFormular]![MeinTextfeld]
, um exakt zu vergleichen.

Bei einer Ähnlichkeits-(TeilString-) Überprüfung lautet die Bedingung dann so:

Wie "*" & Forms![MeinFormular]![MeinTextfeld] & "*"

Beim Vergleich am Anfang eines Textes:

Wie  Forms![MeinFormular]![MeinTextfeld] & "*"



4)  Selbstverständlich kann man in einem ungebundenen Form und mit Hilfe von Textfeldern Berechnungen durchführen.  Die Ergebnisse sind aber nur solange sichtbar, wie das Form geöffnet ist.  Welche Berechnungen hier durchgeführten werden sollen, ist zunächst unerheblich.



Es soll also ein Diagramm auf Basis dieser ungebundenen Eingabefelder und der daraus berechneten Werte erstellt werden?

Wie gesagt, benötigt ein Diagramm eine Abfrage in seiner Eigenschaft "Rowsource". Die Abfrage könnte aus den ungebundenen Steuerfeldern zusammengesetzt werden, sofern (nur) diese im Diagramm im HF (beim Klick auf "btnShowResult")  dargestellt werden sollen:

Sub btnShowResult_Click()
Dim strSQL as String
strSQL = "Select " & Me![erfolgreichbeendet] & " as Success, " & Me![abgebrochen] & " as Canceled, " & Me![nochimProzess] & " as InProgress   from [irgendeineTabelle]"
Me!MeinDiagramm.Rowsource = strSQL

End Sub

Zitat
Diese Felder erzeuge man dann für alle Merkmalsausprägungen des gewünschten Kriteriums, so dass sie sich zu 100 summieren.

Dem kann ich immer noch nicht folgen..  ???

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #4 am: September 20, 2018, 19:11:10 »
Zitat
3)   Was ist denn ein Zählfeld?   Ein Steuerelement mit Inhalt  =Anzahl(*)  Im Formularkopf des UFO's  ?

Ja.

Mit ihm wollte ich die Anzahl der formularbasiert gefilterten Datensätze zählen; also die, die gerade angezeigt werden.

Ich benötige keine Tabelle, um die Ergebnisse irgendwo abzulegen.

Zitat
Heißt das, es ist ungebunden

Ja, ich würde das HF ungebunden lassen. Warum soll man es an eine Tabelle binden, wenn es doch nur als Träger für die Filter und für die Anzeige der Ergebnisse benötigt wird.

Zitat
Zitat
Das HF filtert aber formularbasiert.
 
??  Ein "formularbasierter Filter" (des HF) würde die im HF angezeigten Datensätze filtern.  Die gibt es aber nicht, weil es ungebunden(?) ist.

Ich mache ins HF ein UFO und das wird dann gefiltert.


Zitat
Zitat
Ich brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht.

Du brauchst also eine Referenz auf ein Steuerelement in der Where-Condition einer Abfrage? Schreibe im Abfrageentwurf im Feld "Bedingung"   z. B. Forms![MeinFormular]![MeinTextfeld]
, um exakt zu vergleichen.

Referenz, okay! Ich setzt mich ran.

Carl
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #5 am: September 20, 2018, 19:15:06 »
Ich hab nochmal ne Zwischenfrage zum Datenmodell.

gegeben ist eine Tabelle in der so "Kopfdaten" sind wie Name, Geburtsdatum, Geschlecht usw..

Wenn ich jetzt für z.B. einen dreijährigen Prozess 21 Datumsfelder habe, die in einer Excel-Datei neben einander stehen.

Soll man dann trotzdem die Datumsfelder in einer anderen Tabelle ablegen und nicht in die Tabelle mit den Kopfdaten anhängen? Und die Kopfdaten und die Datumstabelle in einer Abfrage zusammen führen als Grundlage für das Formular?

Warum? Damit sich die User seltener gegenseitig überschreiben?

Carl
 

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7503
Re: Statistik
« Antwort #6 am: September 20, 2018, 19:24:04 »
Hallo,
wenn man es datenbankkonform/Regelgerecht macht, so gibt es eine Tabelle für die Kopfdaten und eine Tabelle zur Erfassung der Datumswerte, aber nicht mit 21 Feldern, sondern in einem Feld mit 21 Datensätzen. Die Tabelle braucht dann einen Fremdschlüssel zu den Kopfdaten.
Was wird denn noch zu einem Datum gespeichert, es wird ja bestimmt nicht nur das Datum erfasst.
Gruß
Klaus
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #7 am: September 20, 2018, 19:55:28 »
Was wird denn noch zu einem Datum gespeichert, es wird ja bestimmt nicht nur das Datum erfasst.

Es wird noch für jedes Datum ein Checkkästchen benötigt, das angibt, ob der zum jeweiligen Datum fällige Vorgang erfolgt ist.

Damit verstehe ich aber noch immer nicht, was der Nachteil wäre, wenn man alle Datumsfelder in die Kopfdatentabelle bringt.

Die Anzahl der Datumsfelder ändert sich nie.

Carl
« Letzte Änderung: September 20, 2018, 20:10:37 von Carl »
 

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7503
Re: Statistik
« Antwort #8 am: September 20, 2018, 20:20:50 »
Hallo,
Zitat
Es wird noch für jedes Datum ein Checkkästchen benötigt, das angibt, ob der zum jeweiligen Datum fällige Vorgang erfolgt ist.
Dann fehlt noch eine Tabelle für die Vorgänge und in die extra Tabelle muss dann ein Fremdschlüssel zum Vorgang. Das wäre dann eine n:m Beziehung zwischen Vorgang und Kopfdaten.
Das Datum, ist das dann das Erledigungsdatum, wenn ja, entfällt auch das Ja/Nein Feld.

Zitat
wenn man alle Datumsfelder in die Kopfdatentabelle bringt.
Dann versuche mal in einer solchen Tabelle das höchste Datum zu finden
Gruß
Klaus
 

Offline ebs17

  • Access-Meister
  • ***
  • Beiträge: 951
Re: Statistik
« Antwort #9 am: September 20, 2018, 21:42:06 »
Zitat
ich möchte über eine Abfrage Summen bilden und prozentuale Anteile berechnen
Das geht prinzipiell. Was Du da mit Formularen veranstaltest, ist unklar.
"über eine Abfrage" ist wohl nur so gesagt oder gelogen?
Mit freundlichem Glück Auf!

Eberhard
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #10 am: September 21, 2018, 16:41:21 »
Also ja! Es ähm war gelogen!

Über eine Abfrage, weil die Ergebnisse ja dynamisch angezeigt werden und nicht gespeichert werden sollen. Und formularbasiert, weil die Anwender anschaulichen denken. (what you see is what you get) Es kann da schon mal vorkommen, dass einzelne DS auf Formularebene ausgeblendet werden sollen, um die Statistik zu "schönen". Das ist nicht meine Sache, aber bei Excel ist das natürlich super leicht möglich. Und wenn beim Übergang zu Access diese Möglichkeit nicht verfügbar ist, sinkt die Akzeptanz. Dann wird die DB nur ungern angenommen. Man sagt dann, Access sei nicht so gut und überhaupt. Die wollen dann plötzlich kein Access mehr. ...



Carl
« Letzte Änderung: September 21, 2018, 17:02:57 von Carl »
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 400
Re: Statistik
« Antwort #11 am: Oktober 04, 2018, 10:43:51 »
Ich habe nochmal eine Frage an Klaus wegen dem Datenmodell:

Ich habe eine Tabelle "Kopfdaten", in der jeder DS einen Vorgang  darstellt und in dem Kopfdaten stehen. Und dann sollen zu jedem DS in dieser Tabelle 21 Datumsfelder + zu jedem dieser Felder ein chckkästchen, ob der Vorgang erfolgreich war.

Es kann niemals vorkommen, dass ein Vorgang mehr oder weniger als diese 21 Daten erfordert. Zum Beispiel wird kein Vorgang mehrfach durchlaufen.

Meine Frage:
Habe ich das richtig verstanden, dass man trotzdem für diese Datumsfelder eine zweite Tabelle anlegen soll? Zum Beispiel um Bearbeitungskonflikte zu vermeiden? Also es gibt immer nur eine 1:1-Zuordnung wie in einer langen Zeile einer Excel-Tabelle, nie beispielsweise mal ein wiederholtes Ausfüllen für den selben Vorgang.

Ich meine ich hätte nichts gegen eine zweite Tabelle für die 21 Felder, aber wie kann man gewährleisten, dass in dieser zweiten Datums-Tabelle immer auch ein DS angelegt wird, wenn in der Kopfdatentabelle ein neuer DS hinzu kommt?

Carl
 

Offline Lachtaube

  • Access Guru
  • ****
  • Beiträge: 1432
Re: Statistik
« Antwort #12 am: Oktober 04, 2018, 10:56:09 »
Zu dem Wie: könnte man in Access-Versionen >= 2010 ein After Insert Datenmakro beauftragen, 21 Datensätze in einer anderen Tabelle anzulegen, die alle als Fremdschlüssel den Wert des Primärschlüssels des neu angelegten Datensatzes erhalten. In niedrigeren Versionen ohne Datenmakros kann man das Gleiche über Formularsteuerung erzwingen, indem man im Nach Einfügen Ereignis des Formulars das Erstellen z.B. durch Ausführen einer Anfügeabfrage anleiert.
Grüße von der (⌒▽⌒)
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23512
Re: Statistik
« Antwort #13 am: Oktober 04, 2018, 11:07:33 »
Hallo,

m. M. nach sollte erst die Bedeutung dieser 21 Datumsfelder geklärt werden.

DB-gerecht und beziehungsgerecht wäre, für jeden Vorgang  (tblVorgaenge) in einer Detailtabelle (tblVorgangDetails) mit 1:n-Beziehung  jeweils nur dasjenige Datum einzutragen  (hinzuzufügen), an dem der Vorgang erfolgreich war.


In diesem Kontext ist nicht zu verstehen, warum es 21 Termine geben sollte, die "Vorgang erfolgreich" definieren können (sollen).

Vermutlich soll aber das Datumsfeld  unterschiedliche Vorgangsdetails   entspr. kennzeichnen.  In diesem Fall wäre in tblVorgangdetails auch nur (neben den Schlüsselfeldern) eine Bezeichnung des Vorgangdetails (evtl. weiter normalisiert mit einer Tabelle "tblDetails", in der alle möglichen "Vorgangsdetails" hinterlegt sind und wiederum über die Schlüsselfelder in Beziehung zu tblVorgangDetails steht) und ein Datum(sfeld) erfolderlich.  Ein "Haken" ist überflüssig.


Sind die Datumsfelder und die "Haken" (die ohnehin überflüssig sind. Ein leeres Datumsfeld ist gleichbedeutend mit "erfolglos") nur zur "Ansicht " gut, soll heißen, es wird mit diesen Feldern keine weitere Analyse, bzw. Berechnung durchgeführt, könnten diese 21 Datumsfelder (weil unveränderlich in ihrer Anzahl und ihrer einzelnen Bedeutung) auch direkt in tblVorgaenge bleiben.




Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7503
Re: Statistik
« Antwort #14 am: Oktober 04, 2018, 11:51:15 »
Hallo,
wie Franz schon sage, sollte die Bedeutung der 21 Datumsfelder geklärt werden.
Nenne mal ein paar Beispiele für die Namen der 21 Felder ?
Wahrscheinlich fehlt hier noch eine weitere Tabelle in der die Bedeutung der 21 Felder als je ein Datensatz erfasst ist, damit hier eine n:m Beziehung mit 3 Tabellen aufgebaut werden kann.
Gruß
Klaus
 

 

Design-Frage für eine Statistik

Begonnen von CarlBoard Access Programmierung

Antworten: 6
Aufrufe: 1278
Letzter Beitrag Dezember 17, 2017, 11:51:30
von Carl
Statistik DS pro PLZ Abfrage

Begonnen von Andreas_80Board Formular

Antworten: 3
Aufrufe: 801
Letzter Beitrag Januar 11, 2018, 16:26:55
von Andreas_80
Statistik in Access - Zeigt nur Werte ab 2 an

Begonnen von werwolfBoard Formular

Antworten: 2
Aufrufe: 125
Letzter Beitrag November 06, 2018, 15:22:55
von werwolf