"Dé grootste en gratis computerhelpdesk van Nederland"
Vragen, Opmerken, Reacties en Tips voor de Access cursus
- Onderwerp starter OctaFish
- Startdatum
- Status
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
Hoi Marc,
Dat is een hele wezenlijke vraag, en inderdaad een kernvraag als het gaat om databases. Het probleem ligt denk ik echter niet zozeer bij het bepalen van de relaties die je moet leggen, als wel bij de stap ervoor: hoe haal je uit een tabel de herhalende gegevensgroepen die niet afhankelijk zijn van de sleutel? Want dat is dus de moeilijkste stap. Ik zal het met een paar voorbeeldjes proberen uit te leggen.
Als basis neem ik eerst een bedrijf dat artikelen levert aan jouw bedrijf. Dan kun je een tabel maken waarin je begint met de leveranciergegevens (Naam, Adres, Contactpersoon) gevolgd door het Artikelnummer, Omschrijving, Kleur en Prijs. (Ik hou het bewust even simpel). Als je 20 artikelen moet invoeren, moet je 20 keer de leveranciergegevens invoeren, en 20 keer de artikelgegevens. Daarbij ga je vermoed ik al snel denken: waarom moet ik elke keer opnieuw dezelfde leveranciergegevens inkloppen; die héb ik toch al een keer ingevoerd? Die vraag zul je jezelf niet stellen als het om de artikelen zelf gaat; die vul je namelijk maar één keer in. Je kunt dus zeggen dat de artikelgegevens uniek zijn, en de leveranciergegevens herhalend. Daarbij loop je ook nog eens het risico dat de ene werknemer V & D intypt, de volgende V&D en de derde van de oude stempel is, en Vroom en Dreesmann inklopt. Alle drie dezelfde bedrijven hebben dan wél weer hetzelfde adres... D.w.z.: is Burg. Oudlaan hetzelfde als: Burgemeester Oudlaan? Kortom: de kans op afwijkende namen maakt het alleen maar lastiger om de gegevens op de juiste manier bij elkaar te houden.
Op zo'n moment moet je de tabel gaan splitsen in 2 tabellen: een tabel Leveranciers, en een tabel Artikelen. Beide tabellen krijgen een eigen sleutelveld op basis waarvan je de opgeslagen records uniek kunt identificeren. Een artikel krijgt dus een veld ArtikelNummer, en een leverancier een veld LeverancierID. De tabellen zijn nu genormaliseerd volgend de 1e normaal. De regel die hieraan ten grondslag ligt zegt namelijk: gegevensgroepen die niet afhankelijk zijn van de andere gegevens haal je weg uit die tabel en zet je in een eigen tabel. Leveranciers hebben niets met artikelgegevens te maken (leveranciers niet uniek in de tabel, en artikelen wel). Dus de leveranciers haal je er uit.
Alleen rijst dan de vraag: hoe ga je die gegevens koppelen?
Daar is het antwoord op dit moment nog niet op te geven, want er moet nog een belangrijke vraag worden gesteld, namelijk: heb je één leverancier, of meerdere? In het eerste geval is het simpel: zet in de tabel Artikelen ook een veld LeverancierID en vul per artikel het betreffend LeverancierID in. Omdat een leverancier meerdere artikelen levert (zie hierboven) is het LeverancierID in de tabel Artikelen nooit uniek. Je krijgt dus een één-op-veel relatie tussen Leveranciers en Artikelen. Zou je het veld LeverancierID in de tabel Artikelen ook uniek maken, dan mag elke leverancier maar één artikel leveren, en dat schiet natuurlijk niet op.
Anders wordt het dus als je meerdere leveranciers hebt; dan gaat bovenstaand verhaal niet op (overigens denkt Microsoft daar anders over, maar ik wil het niet te ingewikkeld maken). Want als 4 leveranciers hetzelfde artikel kunnen leveren, dan heb je nog steeds maar één artikel dat je levert, maar heb je 4 leverancierID's die je moet opslaan. Wat ik dan vaak zie (ook hier op het forum) dat mensen dan maar 4 velden aanmaken voor een leverancierID. Dan kun je immers 4 leveranciers opslaan voor dat artikel.Probleem opgelost! Hoewel? Is dat wel zo? op het eerste gezicht kun je wel even vooruit, met je 4 leveranciers. Maar wat nu als je voor een specifiek artikel 6 leveranciers nodig hebt? Of, wat veel waarschijnlijker is, dat je 5 leveranciers hebt, die allemaal een andere prijs rekenen voor hetzelfde artikel? Je hebt maar één veld voor de prijs. Moet je dan nu ook 5 velden maken voor prijs?
Kijken we naar de volgende normalisatieregel, dan valt je op dat je nu niet te maken hebt met groepen gegevens die per record herhaald worden, zoals bij de leveranciers, maar per veld. Vijf velden voor leverancier, 5 velden voor prijs, en wellicht nog meer herhalende velden. Die extra velden zijn niet afhankelijk van het hele record, maar van een deel ervan, namelijk LeverancierID en van ArtikelID. Ook deze gegevens (die veel vervelender zijn voor een database dan de eerste variant) moeten dus de tabel uit, naar een eigen tabel. Die tabel zou je bijvoorbeeld Leverancier_Artikel kunnen noemen. Wat je hier in ieder geval in vastlegt is het LeverancierID en het ArtikelID, en de herhaalde velden. In het voorbeeldje hier is dat het veld Prijs, maar dat kunnen er dus meer zijn.
Waarom LeverancierID? Omdat je wilt vastleggen welke leverancier welk artikel levert. Waarom ArtikelID? Zelfde reden! Nu kun je een onbeperkt aantal leverancier en artikelen invoeren; elke combinatie van artikelnummer en leverancierID moet uniek zijn (elke leverancier mag elk artikel maar één keer leveren) dus de combinatie van ArtikelNummer en LeverancierID zou een goede sleutel kunnen zijn. En het veld Prijs gebruik je om voor elke combinatie een prijs vast te leggen.
Hoe ligt deze tabel nu in de relaties? Er is een één-op-veel relatie tussen Leveranciers en Leverancier_Artikel en tussen Artikelen en Leverancier_Artikel. Elke leverancier kan nog steeds veel artikelen leveren (net als in de situatie dat elk artikel maar één leverancier had) en elk artikel kan meerdere leveranciers hebben. Er is dus feitelijk een veel-op-veel relatie gelegd tussen Artikelen en Leveranciers: Veel leveranciers kunnen veel artikelen leveren, en veel artikelen worden door veel leveranciers geleverd.
Het is een beetje technisch verhaal, maar dat is het onderwerp nu eenmaal ook; ik hoop dat het wat duidelijker is geworden?
Dat is een hele wezenlijke vraag, en inderdaad een kernvraag als het gaat om databases. Het probleem ligt denk ik echter niet zozeer bij het bepalen van de relaties die je moet leggen, als wel bij de stap ervoor: hoe haal je uit een tabel de herhalende gegevensgroepen die niet afhankelijk zijn van de sleutel? Want dat is dus de moeilijkste stap. Ik zal het met een paar voorbeeldjes proberen uit te leggen.
Als basis neem ik eerst een bedrijf dat artikelen levert aan jouw bedrijf. Dan kun je een tabel maken waarin je begint met de leveranciergegevens (Naam, Adres, Contactpersoon) gevolgd door het Artikelnummer, Omschrijving, Kleur en Prijs. (Ik hou het bewust even simpel). Als je 20 artikelen moet invoeren, moet je 20 keer de leveranciergegevens invoeren, en 20 keer de artikelgegevens. Daarbij ga je vermoed ik al snel denken: waarom moet ik elke keer opnieuw dezelfde leveranciergegevens inkloppen; die héb ik toch al een keer ingevoerd? Die vraag zul je jezelf niet stellen als het om de artikelen zelf gaat; die vul je namelijk maar één keer in. Je kunt dus zeggen dat de artikelgegevens uniek zijn, en de leveranciergegevens herhalend. Daarbij loop je ook nog eens het risico dat de ene werknemer V & D intypt, de volgende V&D en de derde van de oude stempel is, en Vroom en Dreesmann inklopt. Alle drie dezelfde bedrijven hebben dan wél weer hetzelfde adres... D.w.z.: is Burg. Oudlaan hetzelfde als: Burgemeester Oudlaan? Kortom: de kans op afwijkende namen maakt het alleen maar lastiger om de gegevens op de juiste manier bij elkaar te houden.
Op zo'n moment moet je de tabel gaan splitsen in 2 tabellen: een tabel Leveranciers, en een tabel Artikelen. Beide tabellen krijgen een eigen sleutelveld op basis waarvan je de opgeslagen records uniek kunt identificeren. Een artikel krijgt dus een veld ArtikelNummer, en een leverancier een veld LeverancierID. De tabellen zijn nu genormaliseerd volgend de 1e normaal. De regel die hieraan ten grondslag ligt zegt namelijk: gegevensgroepen die niet afhankelijk zijn van de andere gegevens haal je weg uit die tabel en zet je in een eigen tabel. Leveranciers hebben niets met artikelgegevens te maken (leveranciers niet uniek in de tabel, en artikelen wel). Dus de leveranciers haal je er uit.
Alleen rijst dan de vraag: hoe ga je die gegevens koppelen?
Daar is het antwoord op dit moment nog niet op te geven, want er moet nog een belangrijke vraag worden gesteld, namelijk: heb je één leverancier, of meerdere? In het eerste geval is het simpel: zet in de tabel Artikelen ook een veld LeverancierID en vul per artikel het betreffend LeverancierID in. Omdat een leverancier meerdere artikelen levert (zie hierboven) is het LeverancierID in de tabel Artikelen nooit uniek. Je krijgt dus een één-op-veel relatie tussen Leveranciers en Artikelen. Zou je het veld LeverancierID in de tabel Artikelen ook uniek maken, dan mag elke leverancier maar één artikel leveren, en dat schiet natuurlijk niet op.
Anders wordt het dus als je meerdere leveranciers hebt; dan gaat bovenstaand verhaal niet op (overigens denkt Microsoft daar anders over, maar ik wil het niet te ingewikkeld maken). Want als 4 leveranciers hetzelfde artikel kunnen leveren, dan heb je nog steeds maar één artikel dat je levert, maar heb je 4 leverancierID's die je moet opslaan. Wat ik dan vaak zie (ook hier op het forum) dat mensen dan maar 4 velden aanmaken voor een leverancierID. Dan kun je immers 4 leveranciers opslaan voor dat artikel.Probleem opgelost! Hoewel? Is dat wel zo? op het eerste gezicht kun je wel even vooruit, met je 4 leveranciers. Maar wat nu als je voor een specifiek artikel 6 leveranciers nodig hebt? Of, wat veel waarschijnlijker is, dat je 5 leveranciers hebt, die allemaal een andere prijs rekenen voor hetzelfde artikel? Je hebt maar één veld voor de prijs. Moet je dan nu ook 5 velden maken voor prijs?
Kijken we naar de volgende normalisatieregel, dan valt je op dat je nu niet te maken hebt met groepen gegevens die per record herhaald worden, zoals bij de leveranciers, maar per veld. Vijf velden voor leverancier, 5 velden voor prijs, en wellicht nog meer herhalende velden. Die extra velden zijn niet afhankelijk van het hele record, maar van een deel ervan, namelijk LeverancierID en van ArtikelID. Ook deze gegevens (die veel vervelender zijn voor een database dan de eerste variant) moeten dus de tabel uit, naar een eigen tabel. Die tabel zou je bijvoorbeeld Leverancier_Artikel kunnen noemen. Wat je hier in ieder geval in vastlegt is het LeverancierID en het ArtikelID, en de herhaalde velden. In het voorbeeldje hier is dat het veld Prijs, maar dat kunnen er dus meer zijn.
Waarom LeverancierID? Omdat je wilt vastleggen welke leverancier welk artikel levert. Waarom ArtikelID? Zelfde reden! Nu kun je een onbeperkt aantal leverancier en artikelen invoeren; elke combinatie van artikelnummer en leverancierID moet uniek zijn (elke leverancier mag elk artikel maar één keer leveren) dus de combinatie van ArtikelNummer en LeverancierID zou een goede sleutel kunnen zijn. En het veld Prijs gebruik je om voor elke combinatie een prijs vast te leggen.
Hoe ligt deze tabel nu in de relaties? Er is een één-op-veel relatie tussen Leveranciers en Leverancier_Artikel en tussen Artikelen en Leverancier_Artikel. Elke leverancier kan nog steeds veel artikelen leveren (net als in de situatie dat elk artikel maar één leverancier had) en elk artikel kan meerdere leveranciers hebben. Er is dus feitelijk een veel-op-veel relatie gelegd tussen Artikelen en Leveranciers: Veel leveranciers kunnen veel artikelen leveren, en veel artikelen worden door veel leveranciers geleverd.
Het is een beetje technisch verhaal, maar dat is het onderwerp nu eenmaal ook; ik hoop dat het wat duidelijker is geworden?
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
De Databases voor hoofdstuk 17 ontbraken nog in het topic, en aangezien dat best een lastig hoofdstuk is met moeilijke queries, heb ik toch maar een voorbeeldje gemaakt met de uitwerkingen van de oefeningen. Ter lering ende vermaeck dus! Probeer de queries en keuzelijsten eerst zelf te maken en vergelijk jouw werk dan met de uitwerkingen!
automatisch iemand zijn gegevens doen verschijnen
beste,
ik hoop dat ik deze vraag hier mag stellen?
Ik wil bv in een rapport of mag dat daar niet, mijn naam invullen en dan automatisch mijn woongegevens, bv straat, telefoonnummer. gemeente , doen verschijnen
Hoe begin ik daar aan?
met vriendelijke groeten
marc
beste,
ik hoop dat ik deze vraag hier mag stellen?
Ik wil bv in een rapport of mag dat daar niet, mijn naam invullen en dan automatisch mijn woongegevens, bv straat, telefoonnummer. gemeente , doen verschijnen
Hoe begin ik daar aan?
met vriendelijke groeten
marc
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
Hoi Marc,
Deze vraag zou je eigenlijk in het gewone forum moeten stellen; dit draadje is bedoeld voor vragen over de Access cursus. Maar een simpel antwoord is wel te geven: zet de gegevens in de query die onder het rapport zit. Een rapport is overigens een eindproduct. De selectie zou dus al daarvoor moeten zitten, bijvoorbeeld in een formulier. En hoe dat moet, staat dan weer wel in de cursus beschreven
.
Deze vraag zou je eigenlijk in het gewone forum moeten stellen; dit draadje is bedoeld voor vragen over de Access cursus. Maar een simpel antwoord is wel te geven: zet de gegevens in de query die onder het rapport zit. Een rapport is overigens een eindproduct. De selectie zou dus al daarvoor moeten zitten, bijvoorbeeld in een formulier. En hoe dat moet, staat dan weer wel in de cursus beschreven
.
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
Dank voor het compliment! Daar doe je het uiteindelijk voor, tenslotte .
De databases die je kunt downloaden staan allemaal in dit draadje, waarbij de eerste hoofdstukken uiteraard in het begin staan vermeld. Ik moet er gelijk bijzeggen dat ik de databases waarschijnlijk nog niet allemaal compleet heb, en dat het ook handiger is om alle bijlagen in de eerste post te zetten, zodat ze allemaal bij elkaar staan. Nu is het een beetje zoeken, vrees ik. Maar je hebt me wel op een idee gebracht :thumb:
. De databases die je kunt downloaden staan allemaal in dit draadje, waarbij de eerste hoofdstukken uiteraard in het begin staan vermeld. Ik moet er gelijk bijzeggen dat ik de databases waarschijnlijk nog niet allemaal compleet heb, en dat het ook handiger is om alle bijlagen in de eerste post te zetten, zodat ze allemaal bij elkaar staan. Nu is het een beetje zoeken, vrees ik. Maar je hebt me wel op een idee gebracht :thumb:
RadboudAKF
Gebruiker
- Lid geworden
- 3 nov 2010
- Berichten
- 219
Misschien héél dom ... maar via welke link kom ik bij de cursus? Ik heb alle trefwoorden geprobeerd maar zie de cursus waarover hier wordt gesproken niet...
Jan
Jan
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
De cursus staat in de Handleidingen sectie. Daar kun je gelijk heen met bijgaande link. Daar aangekomen kun je filteren op de categorie <Office Suite>, al was ik wel zo slim om de hoofdstukken met het woord "Access" te laten beginnen, dus ze staan toch al wel bovenaan.
Beste,
Ik,weet niet of mijn vraag hier mag gesteld worden.
Het gaat over access 2013.
Ik zoek een formule waar het volgende gebeurd.
iemand sterft in maart en de familie wordt uitgenodigd 2 maanden later in mei.
ik zou een query willen maken waar ik dan een lijst kan printen van alle overleden in de maand mei!
Ik,weet niet of mijn vraag hier mag gesteld worden.
Het gaat over access 2013.
Ik zoek een formule waar het volgende gebeurd.
iemand sterft in maart en de familie wordt uitgenodigd 2 maanden later in mei.
ik zou een query willen maken waar ik dan een lijst kan printen van alle overleden in de maand mei!
Laatst bewerkt:
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
Dat is een gewone vraag en die hoort inderdaad niet thuis in dit topic. Dat is echt bedoeld voor vragen die over de cursus gaan. Ik zou zeggen: maak een nieuwe vraag aan met een duidelijk onderwerp en je krijgt geheid antwoord (waarschijnlijk van mij ).
).foutmelding bij splitsen database
Hallo Octafish,
De database die ik uit onderstaande post gehaald heb, zou ik als ik het goed begrepen heb kunnen gebruiken om te splitsen in een front- en backend, op basis van de instructies in hoofdstuk 4.
http://www.helpmij.nl/forum/showthr...ccess-cursus?p=3984185&viewfull=1#post3984185
Als ik deze db wil splitsen, krijg ik echter de volgende foutmelding: Compileerfout in expressie voor tabelniveauvalidatie.
m vr gr,
Paul.
Ik heb nog even wat verder gekeken en het probleem zit wellicht in de tabel tBedrijf. Bij het openen geeft deze de foutmelding dat de VBA module een syntaxisfout bevat. En aangezien ik de ballen verstand heb van VBA...
Verder viel het mij op dat er een aantal tabellen bij de relaties staan zonder koppelingen met de andere tabellen.
Ook ontbreken er tabellen bij de relaties zoals bijv. de tblLeden.
Maar misschien heb je dat bewust gedaan als oefening voor de cursisten???
Hallo Octafish,
De database die ik uit onderstaande post gehaald heb, zou ik als ik het goed begrepen heb kunnen gebruiken om te splitsen in een front- en backend, op basis van de instructies in hoofdstuk 4.
http://www.helpmij.nl/forum/showthr...ccess-cursus?p=3984185&viewfull=1#post3984185
Als ik deze db wil splitsen, krijg ik echter de volgende foutmelding: Compileerfout in expressie voor tabelniveauvalidatie.
m vr gr,
Paul.
Ik heb nog even wat verder gekeken en het probleem zit wellicht in de tabel tBedrijf. Bij het openen geeft deze de foutmelding dat de VBA module een syntaxisfout bevat. En aangezien ik de ballen verstand heb van VBA...
Verder viel het mij op dat er een aantal tabellen bij de relaties staan zonder koppelingen met de andere tabellen.
Ook ontbreken er tabellen bij de relaties zoals bijv. de tblLeden.
Maar misschien heb je dat bewust gedaan als oefening voor de cursisten???
Laatst bewerkt:
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 42.029
Normaal gesproken kan een 2003 db worden geopend in 2010, maar daar zit een addertje onder het gras: oudere versies hebben een Calendar Control die niet meer bestaat in 2010. En ik vermoed dat er nog een in deze db zit. Die geeft dan problemen op plaatsen (een tabel bijvoorbeeld) waar de foutmelding niks te zoeken heeft. De fout heeft doorgaans dus niks met het actieve object te maken, maar zit op een haal andere plek. Maar ik kijk er vanavond wel even naar.
Wat je ook wel zult moeten weten, is dat ik een 64-bits systeem heb.
Bij het aanmaken van knoppen in een formulier (n.a.v. hoofdstuk 6) krijg ik de melding:
De code in dit project moet worden bijgewerkt voor gebruik op 64-bits systemen. Controleer de instructies, werk ze bij en markeer ze met het kenmerk PtrSafe.
Bij het aanmaken van knoppen in een formulier (n.a.v. hoofdstuk 6) krijg ik de melding:
De code in dit project moet worden bijgewerkt voor gebruik op 64-bits systemen. Controleer de instructies, werk ze bij en markeer ze met het kenmerk PtrSafe.
Heb weer een probleempje, sorry...
In hoofdstuk 6 geef je de volgende instructies (pagina 3 en 4):
In Access 2007/2010 moet eerst een eigenschap van Access worden aangepast, anders maakt
de wizard knoppen op basis van ingebouwde macro’s. Hoewel deze knoppen prima werken,
kunnen ze niet worden bewerkt, en dat is nu net de bedoeling van deze oefening.
1. Kies in het menu Opties de groep Ontwerpfuncties voor Objecten
2. Kies in de groep Ontwerpweergave van Formulier/Rapport de optie Altijd
gebeurtenisprocedures gebruiken
3. Kies vervolgens de groep Vertrouwenscentrum en klik op de knop Instellingen voor
het vertrouwenscentrum
4. Klik nu op Instellingen voor macro’s en kies daar Alle macro’s inschakelen
5. Klik op OK, gevolgd door OK
Na het doorvoeren van deze instructies krijg ik echter na het klikken op 'Gebeurtenis opbouwen...' niet het VBA-scherm maar nog steeds het standaard scherm voor het opbouwen van macro's.
Waar kan dit aan liggen?
In hoofdstuk 6 geef je de volgende instructies (pagina 3 en 4):
In Access 2007/2010 moet eerst een eigenschap van Access worden aangepast, anders maakt
de wizard knoppen op basis van ingebouwde macro’s. Hoewel deze knoppen prima werken,
kunnen ze niet worden bewerkt, en dat is nu net de bedoeling van deze oefening.
1. Kies in het menu Opties de groep Ontwerpfuncties voor Objecten
2. Kies in de groep Ontwerpweergave van Formulier/Rapport de optie Altijd
gebeurtenisprocedures gebruiken
3. Kies vervolgens de groep Vertrouwenscentrum en klik op de knop Instellingen voor
het vertrouwenscentrum
4. Klik nu op Instellingen voor macro’s en kies daar Alle macro’s inschakelen
5. Klik op OK, gevolgd door OK
Na het doorvoeren van deze instructies krijg ik echter na het klikken op 'Gebeurtenis opbouwen...' niet het VBA-scherm maar nog steeds het standaard scherm voor het opbouwen van macro's.
Waar kan dit aan liggen?
- Status
