Felder mit bestimmtem Textinhalt zählen und summieren

[Hache]

Hallo!

Mal wieder ein neues Forum.  Ich setze mich gerade das erste Mal mit Access auseinander. Ich werde mein eigentliches Anliegen (fachspezifisch) mal in ein leichteres Beispiel umsetzen und mein Bestes geben!

Daher auch direkt meine Frage:

Und zwar nehmen wir an, ich möchte eine Tabelle erstellen, die eine Übersicht darüber geben soll, welcher Lieferant welche Kunden beliefert. Es gibt zehn, elf, zwölf Lieferanten und jeder Lieferant hat eine unterschiedliche Anzahl an Kunden. In der ersten Spalte (Text) steht der Lieferant. In der zweiten Spalte stehen die Kundennamen (Text), insgesamt mehrere Hundert. Die dritte bis fünfte Spalte (Ja/Nein) sind beschriftet mit "Äpfel", "Birnen" und "Bananen" und geben an, welcher Kunde was bekommen hat.

Was ich jetzt machen möchte, ist folgendes: Nehmen wir an, einer der Lieferanten heißt "Obsthandel Schmidt". Das Endergebnis soll so sein, dass im Bericht in der ersten Spalte der Name des Lieferanten steht, dann folgen die Spalten Äpfel, Birnen, Bananen, wo auch jeweils die Summen der Bestellungen drunterstehen, und als letztes soll die Spalte mit der Gesamtzahl der Kunden dieses Lieferanten kommen.

Letzteres bekomme ich einfach nicht hin! Da bräuchte ich Hilfe. Wie mache ich das?

Die Rahmenbedingungen sind folgende:
- Es kommen jeden Tag neue Kunden und Bestellungen rein, die aufgenommen werden müssen (natürlich auch mit Stammkunden).
- Es soll für jeden Monat ein neuer Bericht mit den aktuellen Zahlen erstellt werden.

Ich hoffe ich hab alles Wesentliche angegeben, aber was noch fehlt (bestimmt irgendwas) werd ich auf Nachfrage natürlich gerne ergänzen.

Danke schon mal für etwaige Bemühungen!

Gruß
Kai

[Beaker s.a.]

Hallo Kai,

Und zwar nehmen wir an, ich möchte eine Tabelle erstellen, die eine Übersicht darüber geben soll, welcher Lieferant welche Kunden beliefert.

Das macht im Endeffekt eine Abfrage.
Dazu benötigst du aber mehrere Tabellen (die dann in o.a. Abfrage zusammengeführt
werden.
Du brauchst:
mindestens eine Tabelle für die "Personen" (Lieferanten/Kunden). Ob L oder K wird
mit einem Kennzeichen festgelegt.
eine Tabelle um die L und K miteinander zu verknüpfen. Diese Tabelle enthält zwei
Fremdschlüssel-Felder, eins für den L und eins für den K. Falls ein K nur einen L haben
kann, reicht es in die Personentabelle ein FK-Feld zu integrieren in das bei den K die ID
des L eingetragen wird.
eine Tabelle für die Waren.
eine Tabelle, die nun wiederum die Waren mit der L/K-Verbindung zusammenbringt
(wieder zwei FK-Felder, - hier Waren und L/K-Kombi)
evtl. braucht es noch eine Tabelle, die L und Waren in Beziehung setzt
weitere Tabellen werden benötigt wenn eine "Person" mehrere Adressen
(Post, Email usw.) haben kann.
gruss ekkehard

[Hache]

Hi ekkehard,

Danke für deine Antwort!

Wenn ich das richtig verstehe, müsste ich dann aber zur Eingabe der Daten immer zwischen den ganzen Tabellen hin- und herspringen, oder? Das heißt, ich hätte nirgendwo alle Daten auf einmal im Blick? Das wäre wohl nämlich sehr hinderlich und nicht im Sinne des Erfinders... :/

Dummerweise kann ein Kunde auch mehrere Lieferanten haben.

Und ja, optionale Daten wie Telefonnummer, Geburtsdatum usw. werden auch benötigt und eingetragen.

[crystal]

Hallo Kai,

Ekkehard hat schon Recht: wenn du eine solche Tabelle wie in Excel "hintereinander weg" führst, ist das keine Datenbank, sondern eine Liste...

Es wäre schon sinnvoll, zumindest Lieferanten und Kunden in separaten Tabellen zu führen und ihnen eindeutige Nummern zu geben.

Aber - des Menschen Wille ist sein Himmelreich.
Ausgehend von einer Tabelle "Waren" mit den Feldern

wid, autowert, primärschlüssel
wlieferant, text
wkunde, text
waepfel, ja/nein
wbirnen, ja/nein
wbananen, ja/nein

und ein paar Spieldaten

liefert die Abfrage

Code [Auswählen] Erweitern

SELECT
   waren.wlieferant,
   Count(waren.wkunde) AS Anzahl-kunden,
   abs(Sum(waren.waepfel)) AS Summe-aepfel,
   abs(Sum(waren.wbirnen)) AS Summe-birnen,
   abs(Sum(waren.wbananen)) AS Summe-bananen
FROM waren
GROUP BY waren.wlieferant;


formal das gewünschte Ergebnis. Dabei wird die Anzahl der Kunden jedes Lieferanten (Gruppierung) gezählt (ohne Rücksicht auf Tippfehler oder mehrfache Einträge) und die Obst-Häkchen (ja/nein) werden einfach summiert. Da "ja" intern als "-1" dargestellt wird, noch die abs-Funktion bemüht und fertig.

Dies ist aber - wie gesagt - nur die "Auswertung" einer einfachen Liste und hat mit einer Datenbank eher wenig zu tun.

lg
crystal

[Beaker s.a.]

Hallo,
@Kai

Wenn ich das richtig verstehe, müsste ich dann aber zur Eingabe der Daten immer zwischen den ganzen Tabellen hin- und herspringen, oder?

Nein. Mit den Tabellen arbeitest du nur während der Entwicklung. In der
stehenden Anwendung wird alles über Formulare/Berichte gesteuert und angezeigt.

Dummerweise kann ein Kunde auch mehrere Lieferanten haben.

Da ist nichts Dummes dran, das lässt sich über eine Zwischentabelle darstellen, wie
bereits beschrieben.

crystals Lösung ist eher Quick&Dirty, worauf er aber auch hinweist

nur die "Auswertung" einer einfachen Liste und hat mit einer Datenbank eher wenig zu tun.

@crystal

Es wäre schon sinnvoll, zumindest Lieferanten und Kunden in separaten Tabellen zu führen und ihnen eindeutige Nummern zu geben.

Ist wohl Geschmacksache, ob man das in zwei Tabellen teilt oder per Kennzeichen.
Ich persönlich bevorzuge in so einem Fall sogar drei Tabellen:
tblKonten mit allen Feldern, die sowohl bei Kunden als auch Lieferanten benötigt
werden, und jeweils eine 1:1 verknüpfte Tabelle für Kunden/Lieferanten-spezifischen
Feldern (s.Abb.*). Diesen Konstrukt würde ich aber immer auch von den
benötigten Daten (Feldern) abhängig machen.

gruss ekkehard

[Beaker s.a.]

Uuups, hier noch die *Abb.

[ebs17]

Die dritte bis fünfte Spalte (Ja/Nein) sind beschriftet mit "Äpfel", "Birnen" und "Bananen" und geben an, welcher Kunde was bekommen hat.

Das wäre dann eine erhebliche Baustelle für eine notwendige Normalisierung sofern Du DATENBANK lernen willst.
Wenn Du mal sinnvoll auswerten möchtest, wieviel ein Kunde an einen Lieferanten für alle Waren zu zahlen hätte, hätte man ein deutliches Problem mit den auf mehrere Spalten verteilten Daten, abgesehen davon, dass durch die Begrenzung der Spaltenzahl auf 255 in Access (Jet) das Warenangebot zwangsweise überschaubar bleiben müsste.