Wie heeft er kennis van Microsoft Access (2010)

[Munthunter]

Beste forumleden,

Ik ben voor mijn eigen overzicht bezig een database op te zetten in Microsoft Access 2010, waarmee ik mijn verzameling bijvoorbeeld kan bijhouden. Op zich lukt dat aardig en met behulp van Google en andere hulpbronnen en de ingebouwde helpfunctie kom ik al een heel eind. Echter loop ik nu bijvoorbeeld weer vast op de relaties tussen bepaalde tabellen en query's. Is er iemand die wat meer ervaring heeft met dit programma en mij daarbij kan helpen? Het lijkt mij ook interessant als dit bestand kan worden gebruikt door de forumleden, wanneer het klaar is.

Reacties zijn welkom, ik hoop dat we samen een mooi en werkbaar bestand kunnen maken.

Ps. Ik werk met Access 2010, maar volgens mij verschilt dat niet er veel met de 2007 (en eerdere) versies.

Vriendelijke groeten,

Jeroen - Munthunter

[neozion]

kan je normaliseren?

[Munthunter]

Kijk daar heb ik al wat aan, heb even gekeken op Google wat je bedoeld met het normaliseren in Access en dit is iets wat ik mee kan/moet nemen. Zou je mij eventueel kunnen bijstaan bij het opmaken van het bestand? Misschien dat ik het nu veel te omslachtig doe en dat het dus slimmer en makkelijker kan.

Gr. Jeroen

[neozion]

Kijk daar heb ik al wat aan, heb even gekeken op Google wat je bedoeld met het normaliseren in Access en dit is iets wat ik mee kan/moet nemen. Zou je mij eventueel kunnen bijstaan bij het opmaken van het bestand? Misschien dat ik het nu veel te omslachtig doe en dat het dus slimmer en makkelijker kan.

Gr. Jeroen

In een ver verleden heb ik 4 jaar informatica gestudeerd toen dat allemaal net begon. Access was er nog niet en databases werden nog gebouwd in oracle op unix. Tijdens de jarenlange kwellingen in de theorieklassen werd het normaliseren er hardhandig ingemept. Kon je dat niet dan werd het nooit iets met je als db beheerder.
(Ben niets voor niets huisman geworden, al had dat ook andere redenen)

Maar ik heb ooit ook het idee gehad om de munten in een database te zetten. Dan zit je weer met het probleem wat je als primaire key gaat gebruiken, de km nummering was een optie, En wat als secundaire? Dan moet je het land of staat voorvgebruiken. Maar sommige munten heb ik dubbel, vaak omdat ze countermarked zijn, uiteindelijk een spreadsheet gebouwd die in de jaren is bijgeschaafd tot een perfecte database die vele malen overzichtelijker is dan een access db. Geen gezeur icm het missen van de primaire keys
Grote nadeel is de overzichtelijkheid van een normale genormaliseerde db, je kan de lijsten opvragen, maar die zijn nooit overzichtelijk

Jeroen, als je een voorbeeld van mijn db wilt zien moet je even een email sturen, dan wil ik je graag wat toe mailen.

[Munthunter]

Jeroen, als je een voorbeeld van mijn db wilt zien moet je even een email sturen, dan wil ik je graag wat toe mailen.

► Laat Spoiler zien

Kun je die naar info@munthunter.nl sturen?

Bij voorbaat dank!

Gr. Jeroen

[rinuske]

ik ben geen informatica mens maar weet wel het een en ander van data, op mijn werk gebruikten we tot nu toe oracle access een redelijke database in mijn ogen ,maar erg sterk veroudert
nu zijn we over gegaan op SAP ,is in mijn ogen de perfecte database
ik weet alleen niet of dit ook voor particulieren beschikbaar is, dit is op bijna alles toepasbaar
misschien dat er andere leden wat meer vanaf weten, ik ben tenslotte maar een gebruiker hiervan

[llinde]

nu zijn we over gegaan op SAP ,is in mijn ogen de perfecte database

SAP is geen database, maar een ERP (http://nl.wikipedia.org/wiki/Enterprise ... e_planning), of het wel of niet voor particulieren verkrijgbaar is weet ik niet, maar er is ook geen particulier die er zinnig gebruik van kan maken, zeker niet voor de enorme kosten die gemoeid zijn bij een SAP implementatie.
Nadeel van software als SAP is dat je je bedrijfsvoering volledig aan SAP moet aanpassen in plaats van andersom, SAP is ongelofelijk kostbaar om aan te passen aan jouw bedrijf en je zult deze hoge kosten ook iedere keer weer hebben bij een nieuwe release.

Luit

[Munthunter]

Ik heb Access en daar wil ik hem in maken, vandaar ook de deze titel. Ik kan er verder weinig aan om alle beschikbare databasesoftware voorbij te zien komen en hoe die werken.

Hoop dat er iemand is die (samen met) mij de database kan helpen opbouwen.

Gr. Jeroen

@Neozion, bedankt voor de printscreens. Ik heb zelf een zeer uitgebreide en redelijk doortellende spreadsheet, maar zou graag in Access een makkelijker en eenvoudiger te bewerken overzicht willen maken. Excel ken ik overigens behoorlijk goed.

[spatbord]

Ik heb zelf geen access (te duur), maar sla wel vaak spul op vanuit excel in een .mdb (microsoft database, het bestandsformaat dat access ook gebruikt), wat ik vervolgens weer vanuit een andere spreadsheet kan benaderen. Het opslaan doe ik met behulp van VBA, het eruit halen met VBA of pivottables. Als je al veel info in excel hebt kan VBA dan ook handig zijn om data over te zetten naar Access. MDB Viewer Plus is gratis software waarmee je MDB bestanden kunt lezen/bewerken (een uitgeklede versie van access dus eigenlijk), dat gebruik ik dan ook nog af en toe.

Als je een dergelijke route wil bewandelen kan ik misschien nog wel wat hulp bieden, als het puur om werken in Access zelf gaat niet.

[neozion]

Graag gedaan jeroen.
Theoretisch weet ik het allemaal nog wel, maar met access heb ik helaas geen ervaring.

Qua tips kan ik je meegeven dat je eerst alle tabellen moet maken die je nodig hebt, daarna ga je ze normaliseren. Zodoende koppel je ze ook aan elkaar.
Zorg dat je een goed primaire sleutel neem. Bv een eigen catalogusnummer

[Munthunter]

Ben al flink aan het zoeken op het internet en ga gewoon aan het proberen. Hulp is welkom, maar zal wel een gerichte vraag hier plaatsen. Zie ook veel fora die deze materie als onderwerp hebben.

Gr. Jeroen

[peterpaul31]

Ik heb ook een database in Access. Eigenlijk bestaat die uit één echte tabel. De primary key in deze is het automatisch door Access aangemaakte nummer. Het voordeel van 1 tabel is dat je niets hoeft te koppelen en dat je (zeker met de huidige versie van access) heel makkelijk kan filteren. Ik kan dus bijvoorbeeld heel makkelijk al mijn zilveren munten filteren, munten per land, gebied of werelddeel, per periode, kwaliteit etc.
Wat natuurlijk wel heel belangrijk is, is hoe je die tabel inricht. Toen ik er 15 jaar geleden aan begon had ik bijvoorbeeld nog geen kolom 'slag aantal' . Toen ik deze later toe ging voegen, moest ik dus weer veel gegevens invoeren. Het resultaat is dat ik nog steeds niet bij alle munten de bekende aantallen heb ingevoerd.

[peterpaul31]

, uiteindelijk een spreadsheet gebouwd die in de jaren is bijgeschaafd tot een perfecte database die vele malen overzichtelijker is dan een access db. Geen gezeur icm het missen van de primaire keys
Grote nadeel is de overzichtelijkheid van een normale genormaliseerde db, je kan de lijsten opvragen, maar die zijn nooit overzichtelijk

Jeroen, als je een voorbeeld van mijn db wilt zien moet je even een email sturen, dan wil ik je graag wat toe mailen.

Ik kan vanuit mijn database in Access mijn bestand overzetten in Excel. Wat ik niet weet, is of dit andersom ook kan. Dat zou betekenen dat je wel overzichtelijk lijsten kan opvragen.

[llinde]

Het voordeel van 1 tabel is dat je niets hoeft te koppelen en dat je (zeker met de huidige versie van access) heel makkelijk kan filteren.

En dat is dan dus precies het tegenovergestelde van een genormaliseerde database...
Door de grote rekencapaciteit van de tegenwoordige computers is dit overigens voor kleine databases, waaronder die van onze muntverzamelingen eigenlijk ook geen enkel probleem meer. Ook het registreren van wat redundante gegevens is op deze schaal geen enkele belemmering dus ook dat is geen reden om af te zien van deze "platte" database.
Waar je wel erg op moet letten is dat als je de informatie die bijvoorbeeld bij een bepaalde nominale waarde hoort, registreert bij elk jaar van deze waarde, je extra aandacht moet hebben voor het gelijk houden van al deze informatie.
En bij het registreren van bijvoorbeeld een nieuw jaar van zo'n munt is het ook wat lastiger om alvast de gegevens behorend bij de waarde op te halen, ze staan immers niet in een "eigen" tabel opgeslagen.
Kortom: voor- en nadelen aan het normaliseren, maar in mijn ogen, zeker als informaticus, heeft het normaliseren toch vooral voordelen.

Luit

[neozion]

Kortom: voor- en nadelen aan het normaliseren, maar in mijn ogen, zeker als informaticus, heeft het normaliseren toch vooral voordelen.

Luit

Volledig mee eens.