Product database

[KupCom]

Hallo allemaal,

Voor mijn werk willen we op onze locatie een database opbouwen. Mij leek het handigst om dit te kunnen doen met Access. Hieronder een korte beschrijving, is dit mogelijk en kan/wil iemand mij hierbij assisteren?
Het is bedoeling dat we alle producten met omschrijving, productnummer, productcategorie en opmerkingen in een tabel hebben. Ook moeten wij in deze tabel kunnen aangeven of dit artikel in de winkel als showmodel staat (liefst met een waarde; dus 0 is bijvoorbeeld niet een 1 is wel).

Vervolgens moeten we op basis van de waarde een rapport (c.q. lijst) kunnen uitprinten. Deze uitgeprinte lijst willen we sorteren op basis van de productcategorie en productnummer. Op deze lijst moet dus productcategorie, productnummer, omschrijvingen, en opmerkingen komen te staan. Deze lijst(en) willen we naast de folder en prijskaarten kunnen leggen. Dan hoeven we niet telkens te zoeken of het showmodel wel of niet aanwezig is...

 

[OctaFish]

Dat is zeker wel mogelijk; Microsoft geeft een aantal templates op de website waar je eens een blik op kan werpen. Ik zou wel goed nadenken over de opzet van je gegevens, en niet alles in één tabel gooien. Dat levert doorgaans een slecht te onderhouden tabel op. Gebruik dus opzoektabellen voor je categorieën die je koppelt aan je artikeltabel om maar eens wat te noemen. En een tabel met Leveranciers, Merken etc. Om aan te geven of een artikel een showroommodel is kun je een Ja/Nee veld gebruiken. Dat slaat dan wel niet de waarden 0 en 1 op, maar wel 0 en -1. Dus daar is prima op te filteren.

 

[KupCom]

De tabel wil ik zo simpel mogelijk houden, met alleen de velden: omschrijving, productnummer, productcategorie, opmerkingen, en showmodel. Eventueel gekoppeld aan een Excel bestand, als dit op den duur gemakkelijker is voor de andere medewerkers. Ik heb nog nooit gewerkt met opzoektabellen (wat inderdaad wel handig is voor de categorieën). Ook een rapport maken op basis van een waarde heb ik nog nooit gedaan.

Kan/wil iemand een hele simpele basis leggen, dus bijv. het aanleggen van de opzoek/product-tabel en de rapporten op basis van waarde in het showroom veld? Dan kan ik zelf misschien wel verder met de hulp van het forum.

 

[OctaFish]

Ik zou, als ik jou was, eerst de procedures eens rustig op papier zetten. Je denkt teveel vanuit het eindresultaat, en in Access is dat meestal een doodlopende weg. Bedenk eerst wat je wilt kunnen doen in de db, en ga daarna denken aan de manier waarop je dat kunt realiseren. Opmerkingen als:

De tabel wil ik zo simpel mogelijk houden ... () Eventueel gekoppeld aan een Excel bestand, als dit op den duur gemakkelijker is voor de andere medewerkers.

wekken niet de indruk dat je e.e.a. al goed hebt uitgewerkt. Tabellen maak je niet met de opzet om ze 'zo simpel mogelijk te houden', maar met het oogmerk om die gegevens op te slaan die je nodig hebt in je processen. Hetzelfde geldt voor opzoektabellen: die maak je omdat je herhalende gegevens niet wilt opslaan in je hoofdtabel omdat dat de kans op fouten verhoogt, en dubbele gegevens oplevert in je tabel. Voorbeeldje: als je een veld Categorie maakt in je tabel waarin een gebruiker zelf de categorie moet intypen, dan kan dat de ene keer "kinder kleding" zijn, een andere keer "kinderkleding" en een onhandige gebruiker kan net zo makkelijk "kinder kledign" intypen. Voor de database zijn dat 3 verschillende categorieën. Om dat soort problemen te voorkomen, gebruik je dus opzoektabellen.
Heb je gegevens uit Excel nodig, dan moet je ook daar goed over nadenken; zijn die gegevens wel genormaliseerd, worden ze (en de structuur) regelmatig aangepast? etc.
Kortom: maak eerst een goed ontwerp, en bekijk dan hoe simpel je dat kunt uitvoeren. En niet: hoe maak ik een simpele tabel...

 

[KupCom]

Ik zou, als ik jou was, eerst de procedures eens rustig op papier zetten. Je denkt teveel vanuit het eindresultaat, en in Access is dat meestal een doodlopende weg. Bedenk eerst wat je wilt kunnen doen in de db, en ga daarna denken aan de manier waarop je dat kunt realiseren. Opmerkingen als:

wekken niet de indruk dat je e.e.a. al goed hebt uitgewerkt. Tabellen maak je niet met de opzet om ze 'zo simpel mogelijk te houden', maar met het oogmerk om die gegevens op te slaan die je nodig hebt in je processen. Hetzelfde geldt voor opzoektabellen: die maak je omdat je herhalende gegevens niet wilt opslaan in je hoofdtabel omdat dat de kans op fouten verhoogt, en dubbele gegevens oplevert in je tabel. Voorbeeldje: als je een veld Categorie maakt in je tabel waarin een gebruiker zelf de categorie moet intypen, dan kan dat de ene keer "kinder kleding" zijn, een andere keer "kinderkleding" en een onhandige gebruiker kan net zo makkelijk "kinder kledign" intypen. Voor de database zijn dat 3 verschillende categorieën. Om dat soort problemen te voorkomen, gebruik je dus opzoektabellen.
Heb je gegevens uit Excel nodig, dan moet je ook daar goed over nadenken; zijn die gegevens wel genormaliseerd, worden ze (en de structuur) regelmatig aangepast? etc.
Kortom: maak eerst een goed ontwerp, en bekijk dan hoe simpel je dat kunt uitvoeren. En niet: hoe maak ik een simpele tabel...

Je hebt helemaal gelijk! De basis en het doel heb ik al goed in mijn hoofd en ook zo helder mogelijk uitgewerkt in mijn beginpost. Ben zojuist begonnen met het aanleggen van de productentabel, dit moet hoe dan ook gebeuren en vergt nog niet zo heel veel kennis. Maar op welke wijze kan ik de fouten in de categorie voorkomen? Moet ik een tabel aanmaken met daarin alle mogelijke categorieën en die weer koppelen aan de bewuste rij in de product-tabel?

 

[OctaFish]

Dat is inderdaad de juiste oplossing. In je categorie tabel leg je in ieder geval een CategorieID vast en de Categorie omschrijving waarbij CategorieID het sleutelveld wordt, en in je producten tabel neem je een veld CategorieID op. In het Relaties venster koppel je de twee tabellen aan elkaar op basis van CategorieID waarbij je de optie <Referentieële integriteit afdwingen> in ieder geval aanvinkt. Op die manier voorkom je dat je categorieën kunt kiezen die niet bestaan.
Zelf ben ik absoluut geen voorstander van het maken van opzoeklijsten in de tabel zelf; ik maar de keuzelijst wel op de formulieren. In de tabel wil ik altijd de opgeslagen waarden zien. Dus voor CategorieID gebruik ik een gewoon tekstveld. Kom je nooit voor verrassingen te staan in rapporten e.d.

Overigens is het niet nodig om een volledig bericht te quooten als dat bericht er pal boven staat. Je kunt hem namelijk heel wat beter in de normale opmaak lezen dan als quoot... Nu dwing je de lezer tot onnodig scrollen

 

[KupCom]

Nu gaat het even te ver: ik heb nu een opzoeklijst maar dan dat ik de categorie kan kiezen dus niet op basis van een ID. Is dat voor het sorteren wel wenselijker? Zie bijgaand wat ik tot dusver als test in elkaar heb gezet. Voor het bijhouden leek me de optie om de juiste categorie te selecteren handiger.

Zie hier de bijlage: Bekijk bijlage HelpMij.zip

 

[KupCom]

Ik ben even aan het knutselen geweest en ik heb alles al zoals ik het wil hebben

 

[KupCom]

Loop tegen een probleem aan bij het volgende: ik ben bezig om een schakelbord te maken met verschillende knoppen. Nu wil ik ook een knop maken om twee query's opnieuw uit te voeren, deze twee query's maken twee tabellen aan: een met artikelen waar wel een showmodel van is en een waar geen showmodel voor is.

Echter krijg ik het niet voor elkaar om een actie te maken die de twee query's opnieuw uitvoert. Deze actie moet aangestuurd worden met een druk op de knop.

 

[OctaFish]

Waarom zou je nieuwe tabellen aanmaken? Ik zou geen enkele reden kunnen bedenken om dat niet met selectiequeries te doen.

 

[KupCom]

Sorry, dat bedoelde ik ook (newbie op het gebied van Access). Past deze query automatisch de gegevens aan? Dus als ik iets wijzig in de tabel dat de query deze wijziging gelijk meeneemt? Dacht dat het verstandiger was om de query dan opnieuw uit te voeren..

 

[OctaFish]

Queries zijn gebaseerd op de gegevens in de onderliggende tabellen, en zijn normaal gesproken dynamisch. (normaal gesproken; met enige moeite kun je ze statisch krijgen, maar dat zal ik je voorlopig niet aandoen )
Een query laat dus altijd de actuele gegevens zien. Wel kan het zijn, als je een formulier gebruikt, dat het formulier ververst moet worden, omdat je in een formulier de gegevens a.h.w. tijdelijk 'bevriest' totdat je een handeling doet (volgende record laten zien, vorige record etc.)