2 queries naar 1 query

Status
Niet open voor verdere reacties.
Maomanna,

Volgende query geeft een lijst van de voor de functie benodigde functieeisen waarnaast de al behaalde eisen worden aangegeven.
Is dit wat je zoekt?

Code:
SELECT A.Personeelsnummer, A.Voornaam, A.Achternaam, A.Functienaam, A.iEisnaamID, RE.iEisnaamID AS Aanwezig
FROM (SELECT 
     W.ID as WerknID,
     W.Personeelsnummer, 
     W.Voornaam, 
     W.Achternaam,
     F.ID, 
     F.Functienaam, 
     FE.iEisnaamID
   FROM 
     Werknemers AS W, 
     Functies AS F, 
     FunctieEisen AS FE 
   WHERE 
      W.functieID = F.ID AND
      F.ID = FE.iFunctieID)  AS A LEFT JOIN Registratieeisen AS RE ON A.iEisnaamID = RE.iEisnaamId AND A.WerknID = RE.iWerknemerID

Veel Succes.
 
Maomanna,

Als je alleen de eisen wil zien die wel volgens de functieeisen nodig zijn maar die niet in registratieeisen staan kun je de volgende
query gebruiken.

Code:
SELECT A.Personeelsnummer, A.Voornaam, A.Achternaam, A.Eisnaam
FROM (SELECT 
     W.ID as WerknID,
     W.Personeelsnummer, 
     W.Voornaam, 
     W.Achternaam,
     F.ID, 
     F.Functienaam,
     FE.iEisnaamID,
     D.Eisnaam
   FROM 
     Werknemers AS W, 
     Functies AS F, 
     FunctieEisen AS FE,
     Documentnamen AS D
   WHERE 
      W.functieID = F.ID AND
      F.ID = FE.iFunctieID AND
      FE.iEisnaamID = D.ID)  AS A LEFT JOIN Registratieeisen AS RE ON (A.iEisnaamID = RE.iEisnaamId) AND (A.WerknID = RE.iWerknemerID)
WHERE RE.iEisnaamID is NULL;

Veel Succes.
 
WAUW!!!

Ik heb er echt dagen op zitten zoeken/puzzelen/klooien!
Beide zijn echt geweldig! Thanks!

Is het vanaf hier nog moeilijk om de datumkolom uit Functieeisen toe te voegen?

In mijn beleving zou dat dan toegevoegd moeten worden achter
Code:
ON (A.iEisnaamID = RE.iEisnaamId) AND (A.WerknID = RE.iWerknemerID) AND (A.WerknDatumIndienst >= FE.dStart)
of
Code:
ON (A.iEisnaamID = RE.iEisnaamId) AND (A.WerknID = RE.iWerknemerID) AND (A.WerknDatumIndienst Between FE.dStart AND FE.dEind)

klopt dat?

En kan ik naderhand ook nieuwe verplichte documenten toevoegen met een andere start/einddatum? Het kan dan voorkomen dat er dezelfde documenten per functie verplicht zijn, maar alleen een andere start- en einddatum
 
Laatst bewerkt:
Maomanna,

Het antwoord is wat gecompliceerder. In je testbestand zijn de kolommen dSTart en dEind gelijk aan Null
Als je A.WerknDatumIndienst Between FE.dStart AND FE.dEind probeert uit te voeren waarbij FE.dStart en/of FE.dEind Null zijn
krijg je geen enkel resultaat.
Als je dit wil zul je dStart en dEind altijd moeten vullen of je zal ze in de query moeten vullen met een dummy datum,
bijvoorbeeld de datum in dienst.
Dit leid tot de volgende query:
Code:
SELECT A.Personeelsnummer, A.Voornaam, A.Achternaam, A.Eisnaam, A.dStart, A.dEind
FROM (SELECT 
     W.ID as WerknID,
     W.Personeelsnummer, 
     W.Voornaam, 
     W.Achternaam,
     F.ID, 
     F.Functienaam,
     FE.iEisnaamID,
     FE.dStart,
     FE.dEind,
     D.Eisnaam
   FROM 
     Werknemers AS W, 
     Functies AS F, 
     FunctieEisen AS FE,
     Documentnamen AS D
   WHERE 
      W.functieID = F.ID AND
      F.ID = FE.iFunctieID AND
      FE.iEisnaamID = D.ID AND
      W.Indienst BETWEEN IIF(FE.dStart is NULL, W.Indienst -1, FE.dStart) AND IIF(FE.dEind is NULL, W.Indienst +1, FE.dEind)
        )  AS A LEFT JOIN Registratieeisen AS RE ON (A.iEisnaamID = RE.iEisnaamId) AND (A.WerknID = RE.iWerknemerID)
WHERE RE.iEisnaamID is NULL;

Veel Succes.
 
Het is niet helemaal wat ik bedoel, wellicht ben ik te onduidelijk geweest.
mijn excuses.

Nu laat hij enkel de mensen zien die vanaf de datum bij dStart in dienst zijn gekomen.
De dStartdatum is een datum vanaf wanneer het document verplicht is.

Dus als ik per 01-01-2014 in dienst kom en op dat moment zijn de documenten 1,2,3,8 en 9 verplicht.

De werkgever besluit om per 01-03-2014 document 10 verplicht te stellen.
Als een van jullie op 02-03-2014 indienst komt en document 10 zit er niet bij, dan moet bij jullie naar voren komen dat document 10 ontbreekt, maar niet bij mij, daar dat op mijn datum van indienst dit document nog niet verplicht was. Ik deel de mening dat het belabberd en complex is. Zeer onduidelijk maar zo kan helaas de organisatie zijn waar ik bij werk.

Bij de eerste tweede queries, wordt nu aangegeven welke documenten ontbreken, zonder een datum.
Met de laatste komen de mensen naar voren, die vanaf de dstart indienst zijn gekomen.

In het voorbeeldbestand is Karel de Vries in dienst gekomen op 01-01-2005 en komt niet voor op de lijst.


My bad, niet goed getest. Toppie!

Er is nog wel een klein puntje, namelijk dat als besloten is dat van 01-01-2012 een diploma verplicht is. en per 01-03-2012 niet meer, dat het voor de medewerker in de tussenliggende periode wel verplicht is. Nu verdwijnt hij van de lijst als niet ontbrekend, maar moet in praktijk nog wel aangeleverd worden.
 
Laatst bewerkt:
Maomanna,

Ik begrijp je probleem niet. Voor een functie is vanaf 01-01-2012 een diploma verplicht dan wordt de diploma opgenomen in
de tabel functieeisen met de functie en met als ingangsdatum 01-01-2012 (een functieeis heeft dus altijd een ingangsdatum
anders zou hij niet opgenomen zijn).

Stel Jan is op 01-02-2012 in dienst gekomen hij heeft geen diploma. De query zal dan in een regel opgeven dat hij een diploma
moet gaan halen. Tot zover alles correct.

Als per 01-03-2012 het diploma niet meer noodzakelijk is kan deze regel na 01-03-2012 geheel uit de tabel functieeisen worden
verwijderd en komt hij ook niet meer voor in de query. Kortom een eindtijd is helemaal niet nodig, toch?

Ik snap trouwens zo wie zo niet wat je wilt met de datums. Stel dat jan in dienst is gekomen op 01-12-2011, dus een
maand voordat het diploma verplicht is, dan hoeft hij hem blijkbaar ook niet meer te halen, hij komt niet in de query voor
blijkbaar heeft hij daarvoor een vrijstelling en wordt hij ook niet verplicht alsnog naar school te gaan.

Graag een nadere omschrijving wanneer iemand nu geacht wordt wel of niet aan een functieeis te voldoen.

Veel Succes.
 
Het probleem zou zo veel simpeler zijn als je de database correct zou normaliseren :). Dan zou de hele vraag niet spelen namelijk. Je hebt dan een hoofdformulier met de werknemer en zijn functie, en in een subformulier zie je welke eisen bij die functie horen, en welke documenten wanneer zijn aangeleverd. Maar ja, dat is een heel andere aanpak...
 
ik ben het met jullie eens dat het onnodig is en erg vermoeiend! Maja zo is de organisatie eenmaal. Die datums zijn er omdat ze nogal wispelturig kunnen zijn. Elke maand kan er voor een andere functie een document verplicht worden gesteld of weggaan. De begindatum is dan nodig om te bepalen vanaf wanneer dat van kracht is.
Als het later als niet meer verplicht wordt bestempeld, blijft het document voor de mensen die tussen die datums indienst zijn gekomen wel een verplicht document.
Een paar maanden later zou het weer verplicht kunnen zijn. Het merendeel is idd zoals je beschrijft, alleen een toevoeging. In sommige gevallen worden er geschrapt en dat moet de database ook kunnen verwerken.

Afhankelijk van de datum in dienst kunnen er dus andere eisen gelden. Het is een momentopname waarbij bij het opmaken van het dossier gekeken wordt of aan de eisen voldaan is. Als dat niet zo is, moet ik deze vergaren, tot het compleet is.

Zelf ben ik er als beheerder niet echt blij mee. Ben niet de beleidmaker, dus is het lastig. Zelf zou ik ervoor kiezen dat het met terugwerkende kracht is, voor iedereen in de functie. Dan ben je van al dat gedoe af. Functie is functie toch? schaam me er toch wel lichtelijk voor.

Buiten dat is het normaliseren wel een optie, alleen heb ik geen idee hoe. De simpelere dingen heb ik wel onder de knie, maar dingen zoals de huidige query (ondanks dat na jullie feedback de informatie echt lekker loopt) is voor mij toch wel te ingewikkeld. Maar de aanhouder wint en ben jullie erg danmbaar voor alle hulp en input
 
Laatst bewerkt:
Maja zo is de organisatie eenmaal.
Een bestaande situatie mag nooit een excuus zijn om een slecht werkend systeem dan maar in tact te laten. Integendeel juist. Tijd voor heroverwegen en upgraden, zou ik zeggen! En je 'datumprobleem' is ook helemaal geen probleem meer als de db in orde is. Dan kijk je namelijk ook naar de periode waarin e.e.a. geldig is, en de eisen die op dat moment gelden. Zo moeilijk is dat allemaal niet :)
 
Laatst bewerkt:
Een bestaande situatie mag nooit een excuus zijn om een slecht werkend systeem dan maar in tact te laten. Integendeel juist. Tijd voor heroverwegen en upgraden, zou ik zeggen! En je 'datumprobleem' is ook helemaal geen probleem meer als de db in orde is. Dan kijk je namelijk ook naar de periode waarin e.e.a. geldig is, en de eisen die op dat moment gelden. Zo moeilijk is dat allemaal niet :)

Daar heb je helemaal gelijk in.

Waar zou ik moeten beginnen om de db goed te krijgen? Staat het ergens in je boek hier op Helpmij?

Snel even het een en ander nagezocht. Ik moet dus de indeling van de tabellen herordenen, zodat er geen redudante gegevens opgeslagen worden.
Tot welke schil zou ik moeten gaan?
 
Laatst bewerkt:
Als je met 'schil' de normaalvorm bedoeld, dan moet je in ieder geval normaliseren tot de 3e normaalvorm. Of je verder wilt, hangt van je zelf af :). Waar je naar moet kijken is naar de gegevens die van belang zijn voor de functie-eisen. Zo heb dus blijkbaar verschillende eisen voor verschillende periodes. Dan móet je dus per functie de verplichte documenten vaststellen met een begindatum en (eventueel) een einddatum. Je krijgt dan dus (als de eisen regelmatig veranderen) meerdere records per functie en wellicht per document, met daarin ofwel een record met begin- en einddatum (eis gold voor een bepaalde periode) ofwel een record met alleen een startdatum.
In de registratie van de functiedocumenten moet je dan dus kijken naar de datum van indienst, en welke documenten op die datum verplicht zijn. Dat is met een simpele query wel te doen. Daarbij kijk je bij nieuwe registraties naar het laatste record van een document (meestal een record met alleen een begindatum), of, als je al records hebt toegevoegd voor de toekomst, naar het record waarbij de indienst datum > startdatum en < einddatum. Dat is met een Cartesisch product te herleiden.
Per functie heb je dus een query met de geldende eisen op het moment van indiensttreding. Voor de werknemer vul je een FunctieID in, plus uiteraard het WerknemerID, en die twee gegevens sla je op in de tabel RegistratieEisen. Maar je moet dus niet meer, zoals je nu doet een DocumentID opslaan in RegistratieEisen, maar FunctieEisID uit FunctieEisen.
 
Ok helder.

Ik ga eerst normaliseren en dan verder kijken.
Als ik je verhaal goed begrijp is een best deel van de huidige inrichting goed, alleen het deel waar de registratie om de hoek komt niet.
en dat ik per functie (263 stuks) 263 queries moet gaan maken. Of een filter obv van de FunctieID uit de werknemertabel, toch?

Voor nu werkt de oplossing van Elsendoorn2134 ook. Maar toch lijkt het me handig voor de toekomst om het te normaliseren.
 
... en dat ik per functie (263 stuks) 263 queries moet gaan maken.
Nou nee, dat is nu net weer níet de bedoeling :). Eén query volstaat volgens mij. Je moet wél voor elke functie eigen records aanmaken in [FunctieEisen] waarbij je dus een iFunctieID, een iEisnaamId en een startdatum (en eventueel dus een einddatum) invult. Zodra er iets wijzigt in een functie eis (document vervalt, er komt een nieuw document bij) dan maak je een nieuw record aan voor het betreffende document, of je wijzigt het bestaande document (einddatum bijwerken). Het kan dus best zijn dat voor een functie en één document meerdere records komen (Document is verplicht van 1-1-2010 tot 1-1- 2013 en vanaf 1-1-2015 is het weer verplicht bijvoorbeeld). En je query filtert dan altijd op het laatste record van elke combinatie (dus in dit voorbeeld met 2 records heb je een FunctieEisID met de waarde 123 en een FunctieEisID met de waarde 891, en dan pak je bij 891) bij een nieuwe medewerker, of zoekt bij een bestaande het juiste record op. In dat geval heb je ofwel een record (datum in dienst ligt tussen 1-1-2010 en 1-1- 2013) ofwel bijvoorbeeld niks (datum in dienst ligt tussen 1-1-2013 en 1-1- 2015).
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan