Office: (Office 2016) Alles anzeigen, das NICHT vorhanden ist

Hallo liebe Accesskönner,

ich fummel hier schon ewig rum und kriegs nicht gebacken.

Ausgangssituation:
Tabelle tHandwerker:
Code:

Tabel tWerkzeuge
Code:

Ziel: Ich möchte das alle Handwerker IDs (HID) und das Werkzeug, das NICHT in der Tabelle tHandwerker aufgeführt ist, obwohl es in der Tabelle tWerkzeuge mit Ja als erforderlich gekennzeichnet ist, aufgelistet werden.
Um Beim obigen Bsp. zu bleiben, Handwerker 1 hat keine Säge in seinem Inventar. Ich möchte also seine ID und das fehlende Werkzeug wissen. Ergebnis in diesem Fall müsste also lauten:

HID Fehlt
1 Säge

Aber egal was ich mache, ich kriege kein passendes Ergebnis.
Das hier (der letzte von vielen Versuchen):

SELECT tHandwerker.HID, tHandwerker.Werkzeug As Fehlt, tWerkzeuge.erforderlich
FROM tHandwerker RIGHT JOIN tWerkzeuge ON tHandwerker.Werkzeug = tWerkzeuge.Werkzeug
WHERE (((tHandwerker.Werkzeug) Is Null) AND ((tWerkzeuge.erforderlich)=True));

bringt gar nichts.... grummel.... Kann wer helfen bitte?
Danke!

:)

 

Hallo,
ich glaube, das Datenmodell passt noch nicht.
Wie unterscheidest Du in der Werkzeugtabelle die Handwerker ?
Mit anderen Worten, wo ist festgelegt, dass dder Schraubendreher für HID 2 nicht benötigt wird ?
Und wieso hat HID1 einen Schraubendreher obwohl in der Werkzeugtabelle bei Schraubendrehen Nein steht ?

Haben alle Handwerker die gleichen Werkzeuge ?

 

...wow... das ging ja schnell!

Hi Klaus,

Ok... das war ein schnelles Beispiel. Die Benennung passt deshalb vermutlich nicht. Vielleicht sollte man tHandwerker umbenennen in Tascheninhalte.... aber das ist nicht der Punkt. Sinn des ganzen ist, es soll überprüft werden, ob alle Handwerker in ihrem Werkzeugkasten alle Werkzeuge haben, die in der Werkzeugliste als erforderlich gekennzeichnet sind. Wenn da was fehlt, soll es angezeigt werden. Was und bei wem. Oder geht das nicht, bei redundanten HID Nummern? Was wäre die Alternative?

Nicht in der Werkzeugtabelle, sondern in der Handwerkertabelle...(HID)

 

Hallo,
Du hast meine Fragen nicht eindeutig beantwortet.

Haben alle Handwerker die gleiche Werkzeugliste ?
Wenn nein, wie unterscheidest Du dann die Handwerker

Ist das ein reales Beispiel, oder ist das erfunden ?

Im Regelfall sind Tabellen mit Ja/Nein Feldern für eine Datenbank ungeeignet.

 

...ja, alle Handwerker sollen die gleichen Werkzeuge mitführen. Andernfalls ergäbe das ja keinen Sinn....*Smilie

Die Frage nach der Unterscheidung hatte ich nachträglich beantwortet. Hattest Du während des Antwortens vermutlich nicht mehr gesehen.... über die HID in der Handwerkertabelle.

Und diese Frage:

ist irrelevant.... er hat halt einen.... woher, weshalb, egal.... hat ihm seine Frau zum Geburtstag geschenkt....*wink.gif*

Kann ich mir nicht vorstellen.... das ist die Acces Variante für true und false.... damit muss eine DB klarkommen.

 

Hallo,
es ist mir immer noch völlig unklar.

Auf diese Frage gibt es auch keine eindeutige Antwort.

Wie ich bereits schrieb, sind ja/nein Felder in einer Datenbank ungeeignet.

Hier ist eine n:m Struktur erforderlich in der in je einem Datensatz festgehalten wird wer welches Werkzeug hat.

Dann lässt sich über eine Inkonsistenzabfrage ermiltteln was bei den Handwerkern fehlt. Es sind also 3 Tabellen erforderlich.

- Handwerker
- ErforderlichesWerkzeug
- VorhandenesWerkzeug (FS zu HID, FS zu WID)

 

...ok... ich versuchs nochmal zu erklären....

Es gibt eine Liste, in der steht, was da sein muss. (Die Werkzeugliste)
Es gibt eine Liste, in der steht, wer was hat (hier die Handwerkerliste)
Vergleiche die beiden.
Wenn jemand mehr hat, als in der Wwrkzeugliste steht, macht das nichts. Aber das, was erforderlich ist, muss sich auch in seiner Werkzeugtasche befinden. Und zwar für alle das gleiche. Ein Maler braucht Pinsel und Farben. Das ist notwerndig für seinen Job. Hat er die nicht, kann er nach Hause gehen oder muss sich das besorgen. Hat er noch Frühstücksbrote in seiner Kiste, interessiert keinen...

Die Handwerkertabelle, die Du hier forderst, ist nicht notwendig. Hier gehts nicht um die Handwerker sondern um die notwendigen Werkzeuge. Und alle brauchen die gleichen. Schulze (oder HID 1) hat also einen Hammer und eine Zange. Erforderlich sind aber Hammer, Zange UND Säge. Also fehlt Schulze (oder HID 1) eine Säge. Wenn er (oder ein anderer) auch noch einen Schraubendreher hat, ist das nicht schlimm. Er ist zwar nicht erforderlich aber auch nicht verboten. Darf er haben, interessiert aber keinen. Was interessiert ist:

Wem fehlt was, das erforderlich ist. Was steht NICHT in seiner Inventarliste, . (Handwerkstasche, nenn es wie Du willst) was da eigentlich vorhanden sein müsste

Ist doch nicht so schwer.... wenn Du Pasta kochen willst, brauchst Du Nudeln. Und wenn Du Deinen Schrank mit der Rezeptliste vergleichst und keine Nudeln im Schrank findest, dann schreibst Du sie auf Deine Einkaufsliste...
Ich weiß nur nicht, wie ich Access das verklickern soll.... schau in alle Taschen, vergleiche sie mit der Werkzeugliste und sage mir wem was fehlt, obwohl er es braucht.... schreibs auf die Einkaufsliste.... die will ich haben... und für wen das ist, denn die Nachbarin braucht auch noch was.....

Umgangssprachlich formuliert würde das so lauten:
Vergleiche alle Tascheninhalte mit den notwendigen Werkzeugen und gib mir aus, welchem Handwerker welches erforderliche Werkzeug fehlt.

 

Moin,

tWerkzeuge ist für die Katz, weil dort nicht angegeben ist, für welchen Beruf das Werkzeug erforderlich ist.
Code:

 

Zur eigentlichen Frage:
Grundlagen - SQL ist leicht (11) - Reihenfolge der Abfrageabarbeitung
Der OUTER JOIN und der Filter im WHERE-Teil sind bezüglich der Abarbeitungreihenfolge gleichwertig. Wenn aber in der konkreten Konstellation der OUTER JOIN zuerst ausgeführt wird, bekommt man im Sinne des Wunsches ein falsches Ergebnis. Das kann man sich ja in Gedanken oder praktisch durchspielen.

Es wäre also nötig, die Anweisung so zu formulieren, dass zuerst der Test Erforderlich = True ausgeführt wird:
Code:

Generell:

Ja, in einer ordentlichen DB-Anwendung würde man über Schlüssel verknüpfen, nicht über die Klarnamen der Werkzeuge. Dazu würde es eine solche Tabelle Werkzeuge geben, die diese Schlüssel liefert.
Es gibt also Reserven in der Datenmodellierung. Diese sind nicht für den konkreten Fall von Bedeutung, dürften es aber im Allgemeinen schon sein. Einfache Abfragen haben oft die Grundlage, dass die Daten sauber strukturiert und modelliert sind. Auf der Autostrada muss man bei seinem Sportwagen nur Gas geben, im Innenbereich einer Altstadt ist es da deutlich anstrengender.

 

\@drambeldier

Bitte nichts hineininterpretieren, was nicht von Belang ist. Du darfst davon ausgehen, dass alle den gleichen Beruf und somit die gleichen Anforderungen haben.

Wenn ich
Code:

verwende, bekomme ich alle DS angezeigt, so wie gewünscht. Also, welcher Handwerker hat welches benötigte Werkzeug.
Ich brauch aber quasi eine Invertierung.... also eine Angabe, was er von den benötigten NICHT hat.

@ebs17,
...jepp... das scheint mir in die richtige Richtung zu gehen. Mit Unterabfrage. Dachte mir schon sowas, aber mein SQL ist schon so lange her, dass ich nicht mehr drauf kam. Deshalb hab ich Deine Anweisung auch noch nicht ganz durchschaut.
Du verwendest quasi Hilfstabellen H und W? Aber beim Einsatz Deiner Anweisung wertet er das als Parameterabfrage und will wissen wer W ist.
Müsste ich am Anfang nicht die richtigen Tabellennamen angeben? Also statt:
Code:

so?:SELECT
tHandwerker .HID,
tHandwerker .Werkzeug AS Fehlt,
tWerkzeuge.erforderlich
FROM
tHandwerker AS H...

...aber da meckert er einen Syntaxfehler in der Join Operation an....
es ist zum Mäuse melken...

 

Nein, das sind Tabellenaliase. Jedes Ding muss seinen eindeutigen Namen haben.
Grundlagen - SQL ist leicht (2) - Alias
Einen Fehler in meiner Anweisung kann ich nicht erkennen, den SELECT-Teil hatte ich nur übernommen ohne Rückschau, ob und wie das sinnvoll ist.

 

....erst mal Danke an alle, für Eure Mühen und Zeit!

Hab noch ein wenig rumgespielt und musste feststellen, das, was ich will geht wohl so nicht Entweder ich kann mir anzeigen lassen, was allen fehlt (falls allen das Gleiche fehlt) oder ich muss jeden einzelnen Handwerker gesondert abfragen. Für die, die es interessiert, das habe ich so gelöst:

Code:

Hier wird Handwerker 2 auf fehlendes Werkzeug gecheckt.
Na ja, man kann eben nicht alles haben....*frown.gif*

Special Thanks an @ebs17 für die guten Erklärungen und hier ein Link, der mir auch geholfen hat, um das Thema besser zu verstehen...

Wünsche Euch noch ein schönes Wochenende!

 

Hallo,
die Hinweise zum Datenmodell hast Du mal vorsichtshalber ignoriert. Auch von Ebs17 gab es Anmerkungen in diese Richtung.

Wenn die Handwerker ein neues Werkzeug brauchen, muss alles geändert werden, die Tabelle (es gibt ja ein neuses Feld) die Abfragen, Formulare usw. Ist das so gewollt ?

 

Nun, wenn man will, geht das schon. Ggf. muss man jedem Handwerker seine eigene Werkzeugtabelle (besser eigene Instanz der Werkzeugtabelle) geben, mit der er dann sein vorhandenes Werkzeug abgleichen kann.

Umsetzung?
Verständliches Datenmodell + vorhandene Demodatenbank.

 

Für Selbstlöser:

Vollständige Menge: Kreuzprodukt aus Handwerkerliste und bereinigter Werkzeugtabelle
Vorhandene Menge: Wohl tHandwerker (bei Werkzeugnennung wäre für mich die Bezeichnung extrem irritierend)

Gesuchte Menge ... aus Inkonsistenprüfung beider Mengen