Unieke key die ruwe data met detail bestand matcht

Status
Niet open voor verdere reacties.

Etkroket

Gebruiker
Lid geworden
31 dec 2009
Berichten
12
Ik ben bezig met het bouwen van een Access Database en zou daarbij graag een beroep willen doen op de expertise van deze forumleden.
Op maandelijkse basis krijg ik van ongeveer 15 verschillende mensen bestanden aangeleverd. Deze bestanden zijn te verdelen in 2 categorieen:
1. Ruwe data. Het template voor dit type bestand is voor iedereen gelijk en bevat de volgende gegevens: maand, materiaal code + naam, bedrijfscode + naam, hoeveelheid en (algemene) details. Ik voeg deze ruwe data samen en dit dient als input voor de afdeling Finance.
2. Detail bestand. Dit kan verschillen per dataprovider. Om een voorbeeld te geven: als men in de ruwe data 10 gebruikers van materiaal code 1 aangeeft, bevat dit bestand de gebruikersgegevens van deze 10 mensen.

De database moet daarom (het liefst) het volgende kunnen:
- Ik krijg veel verzoeken voor het aanleveren van historische data. De database moet het mogelijk maken om een overzicht per bedrijf of per materiaal code te maken.
- Daarnaast moet de database de link kunnen leggen tussen de ruwe data en de detail bestanden. Dit is vooral iets waar ik nu niet uitkom. Hoe link ik de ruwe data (in het voorbeeld de quantity van 10) aan de details in het detailbestand? Hoe maak ik de unieke key die de details van januari voor een bepaald bedrijf en materiaal code linkt aan de line in de ruwe data?
- De diverse detailbestanden zijn niet uniform. Echter, het detailbestand bij materiaal code x is wel iedere maand gelijk. Hoe kan ik dit op een handige manier in Access laden? Op dit moment ben ik nog veel aan het knippen en plakken in Excel. Kost veel tijd en de Excel bestanden worden enorm groot en traag. Kan dit slimmer?
- Ik heb een sheet in Excel met een overzicht van prijzen, materiaal codes, verantwoordelijke mensen etc. De database moet met een query in staat zijn om de materiaal code te gebruiken om deze datasets te linken aan elkaar.
- Dan is er nog een sheet met een overzicht van company codes en bedrijfsnamen. Het punt is hier dat er vanuit het verleden verschillende codes voor hetzelfde bedrijf bestaan. Bedrijf A kan bijvoorbeeld 3 verschillende codes hebben. Met deze sheet moet het mogelijk zijn om de diverse codes terug te leiden naar de echte code die we gebruiken om de rekeningen uit te sturen. Is er een query om automatisch te checken of de juiste code in de ruwe data en het detailbestand is gebruikt?

Zie de bijlage voor een voorbeeld van het template. Hopelijk is dit voldoende duidelijk om een eerste antwoord te kunnen geven. Alvast heel veel dank en ik hoor graag als er iets nog niet duidelijk is.

Groet,
Etkroket
Bekijk bijlage Template Example.xlsx
 
Heel even dacht ik dat je velden gecombineerd kreeg aangeleverd (materiaal code + naam, bedrijfscode + naam) maar dat is gelukkig niet het geval. Dus dat scheelt. Dit:
- De diverse detailbestanden zijn niet uniform. Echter, het detailbestand bij materiaal code x is wel iedere maand gelijk.
is echter een beetje verontrustend. Datagegevens die niet uniform worden aangeleverd, zijn bijna niet naar een (wél uniform ingerichte) tabel over te halen. Dus daar moet je echt even naar kijken. En dit:
Het punt is hier dat er vanuit het verleden verschillende codes voor hetzelfde bedrijf bestaan. Bedrijf A kan bijvoorbeeld 3 verschillende codes hebben
is ook niet iets waar je erg vrolijk van word. Al is dat met wat elbow grease nog wel op te lossen.

Wat je in ieder geval zou moeten doen:
1. Tabellen maken voor je brongegevens, zoals Customers en Materials.
2. Tabellen maken voor je datagegevens. Hierbij heb je minstens 2 tabellen nodig: [Input] en [Input_Details]. Om maar even de namen uit je Excel aan te houden.
3. In de in 2 genoemde tabellen neem je verwijsvelden op naar CompanyID en MaterialID. Meer niet; de andere gegevens staan in de stamtabellen.
4. Je legt relaties tussen [Customers] + [Materials] met [Input] ( op basis dus van CompanyID en MaterialID) en [Input] en [Input_Details] (op basis van InputID)

Verder kun je een aantal importscripts maken die de aangeleverde data importeert in (ik zou eerst importtabellen gebruiken, maar dat hoeft niet) de verschillende tabellen. Omdat je Detail bestand niet uniform is, zul je daar vermoedelijke verschillende importspecificaties voor moeten maken.
 
Beste OctaFish,

Dank voor je antwoord. Ik heb nog eens gekeken met de dataproviders en het moet mogelijk zijn om (bijna) alles te gieten in 1 inputformat.
Voor het bestand wat niet in het format past, zal ik een aparte database met de gegeven instructies.

Mijn vraag is nu of ik de relaties goed heb gelinkt op deze manier (zie bijlage)?

Daarnaast vraag ik me af hoe ik de data het best erbij kan laden iedere maand. Is het aan te raden om een aparte tabel te maken voor iedere maand en die te linken aan elkaar? Of beter om de data iedere maand aan te vullen in de bestaande tabel? Indien het laatste, kan iemand tips geven hoe dit werkt?

Alvast weer heel hartelijk dank!

Groet,

Etkroket

Relationships.PNG
 
Als dit plaatje uit je productie db komt, heb je nog wel wat werk te doen. Om te beginnen: geen van de relaties heeft <Referentiële Integriteit>. En zonder dat vinkje zijn alle relaties volkomen waardeloos. Je kunt bijvoorbeeld nu ook het veld [Month Nr] Uit [Input Detail] koppelen aan het veld [Business] in Customer]. Werkt net zo goed (lees: net zo slecht) als de relatie die je nu hebt gelegd. Verder snap ik de relatie tussen [Input Detail] en [Input] niet. Die is er namelijk niet :). En die zou er dus nu juist wél moeten zijn! En wat doen de velden [Details1],[Details2] en [Details3] in de tabel [Input]? Die moeten daar dus weg. Daarvoor heb je nu juist de tabel [Input Detail] maar dan moet die wel gekoppeld zijn aan [Input]. En wat doet het veld [Customer] in [Input Detail]? Kan daar helemaal weg, want de koppeling tussen [Customer] en [Input] ligt al in de tabel [Input]. Daar heb je overigens een veld teveel staan, want de [Customer name] moet daar natuurlijk weg. Je slaat namelijk alleen het veld [Customer code] op.

Hetzelfde geldt voor [Material Name]. Kan (nee: moet) weg. En de velden [Month] en [Month Number]? Allebei weg, en vervangen door een Datumveld! Sowieso moet één van de 2 velden weg, want wat is volgens jou de combinatie van [Month] = "April' en [Month Number] = 11? Nopril? Avember? U zegt het maar :).
 
Dank weer voor de moeite. Het is duidelijk mijn eerste keer met Access, dus excuses voor mijn onkunde op dit vlak.

Zie de bijlage voor een nieuw plaatje met Relations. Ik snap nog niet hoe de link tussen [Input] en [Input_Detail] goed gelegd kan worden.

Hoe zorg ik ervoor dat een rij in tabel [Input] gelinkt wordt met de rijen in [Input_Detail]?
Om een voorbeeld te geven: zeg dat ik 6 users van Material Code A heb met Company Code 123456.
In [Input_Detail] verwacht ik dan 6 lijnen met de individuele users per lijn.
Zorgt de link tussen InputID en Input_DetailID ervoor dat deze goed getagged worden?

Daarnaast zou ik het liefst zien dat ik een importscript draai waarbij de data automatisch in de tabel geplaatst wordt onder de laatste rij. Is dat mogelijk of moet ik iedere maand nieuwe tabellen aanleggen?


Relationships-v2.png
 
Dank weer voor de moeite. Het is duidelijk mijn eerste keer met Access, dus excuses voor mijn onkunde op dit vlak.
Je kunt iemand nooit verwijten dat-ie iets niet weet, hooguit dat-ie weigert om het te leren :).
Ik zou in ieder geval de veldnamen aanpassen; sleutelvelden die in elke tabel dezelfde naam hebben zijn erg verwarrend. Dus in [Input] noem je het veld [ID] om naar [InputID]. In [Input_Details] mis je dat veld, dus kan je ook niet koppelen. Een sleutelveld in de ene tabel kun je zelden koppelen aan het sleutelveld van de andere, dat gaat fout. En de tabel [Materials] hoort m.i. niet gekoppeld te zijn aan [Input] (veld moet daar dus weg) maar aan [Input_Details].
 
En de tabel [Materials] hoort m.i. niet gekoppeld te zijn aan [Input] (veld moet daar dus weg) maar aan [Input_Details].

Dit snap ik niet. Kun je uitleggen waarom?

En: mijn vraag blijft hoe ik Input en Input_Details met elkaar kan koppelen zodat de juiste records gelinkt zijn (zie eerder bericht). Kun je hier nog op ingaan?
 
Jouw laatste vraag is precies wat ik in mijn antwoord probeer duidelijk te maken. Een tabel met een gekoppelde tabel kun je alleen koppelen als het sleutelveld uit de hoofdtabel terug komt in de gekoppelde tabel. In jouw geval is dat dus: het sleutelveld ([InputID]) moet ook in de tabel [Input_Details] worden opgenomen. Met dat veld maak je dan een één-op-veel relatie tussen [Input] en [Input_Details]. In [Input] is het veld ([InputID] een sleutelveld, in [Input_Details] is het veld dat uiteraard niet. Want je kunt per Input meerdere records maken in Input_Details.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan