Advies over het maken van een Trefwoorden database

Status
Niet open voor verdere reacties.

BromsnorII

Gebruiker
Lid geworden
27 sep 2006
Berichten
94
Hallo,

Ik heb veel Word artikelen in bestanden staan. Van elk artikel maak ik Index lijsten die ik separaat als tabel wil gaan opslaan. Vervolgens denk ik erover om een formulier te maken met informatie over het artikel zoals de bron, auteur, titel, auteur enz. en een zoek functie voor de trefoorden. Uiteindelijk moet het een rapport opleven waarin de het trefwoord en alle artikelen en de pagina's worden weergegeven..... waarin dat trefwoord voorkomt.

Per artikel wordt dit dus 1 tabel die dezelfde naam heeft als het artikel, dus heel veel tabellen. Ik heb echter geen idee hoe ik nu door al die tabellen moet zoeken. En is dit uberhaubt een goede oplossing.

Bij voorbaat dank voor jullie meedenken,

Groet,
Sietse
 
Het klinkt als een hoop (haqndmatig) werk, want je kunt een Word index niet zonder meer inlezen in Access. Misschien nog wel in Excel, en van daaruit naar Access. Maar dan nog blijft het een hoop knip- en plakwerk. De documentgegevens zoals Auteur, titel etc. kun je nog wel middels een macro uitlezen. Maar voor de index zou je dus wat meer moeten programmeren vrees ik.
 
Hallo OctaFish,

Dank voor je snelle reactie, Ik heb via excel een macro kunnen maken die de indexlijst omzet in een kolom met trefwoorden en een kolom met pagina's en deze kan ik zo in acces importeren. Dus dat probleem is getackled. Het overige is idd handwerk maar dat is niet zo'n probleem. Wat wel een probleem is, is hoe kan ik via een dropdowbox een artikel zoeken als ik alleen de tabellen heb. Ik probeer een tabel met alle artikel-titels te vermijden want dat heeft dubbele data.

Groet,
Sietse
 
Wat wel een probleem is, is hoe kan ik via een dropdowbox een artikel zoeken als ik alleen de tabellen heb.
Ik mag toch wel aannemen dat je ergens die data hebt staan? Een keuzelijst maken 'uit dunne lucht' lijkt mij wel heel lastig :). En een keuzelijst opbouwen op basis van al je documenten doorlopen op de eigenschap <Titel> lijkt mij onbegonnen werk.
 
Al die data staat in die trefwoord tabellen. Dus een keuzelijst maken die gevuld wordt met de titels van al die trefwoord tabellen. Daarnaast moet ik ook nog een tabel maken die alle gegeven als bron, auteur enz. herbergen. Maar dat lukt mij wel. Het zoeken naar tabelnamen zit ik mee. Moet dan met een query?
 
Ik begreep je niet hele aan geloofsijver aangaande de dubbele data. Als je de tabel met gegevens al hebt, lijkt mijnen extra tabel ook niet nodig en kun je de keuzelijst gewoon op je tabel baseren.
 
Ik denk dat ik niet goed heb uitgelegd wat ik wil. Maar bij nader inzien is de oplossing, van elk artikel een trefwoorden tabel maken ook niet de goed, omdat er dan theoretisch er veel dubbele data kan ontstaan. (In principe kan in elk trefwoorden tabel een trefwoord komen wat in ander tabellen ook wordt opgenomen). Nu moet ik dus iets verzinnen wat controleert of een trefwoord al in de data voor komt. Ik krijg dan een tabel waarin de velden; trefwoord, artikel en pagina nummers (dit wordt 1 veld) zijn opgenomen?

Hoe kan ik controleren of data al ergens is opgeslagen?


Groet,
Sietse
 
Laten we eens terug naar de basis, want ik snap er eigenlijk steeds minder van.
Per artikel wordt dit dus 1 tabel die dezelfde naam heeft als het artikel, dus heel veel tabellen.
Hier gaat het m.i. namelijk al fout. In een database sla je één entiteit op in één tabel, niet voor elke entiteit zijn eigen tabel. Dat is a) gekkenwerk en b) hopeloos in het gebruik. Als je van een artikel meerdere eigenschappen hebt die je wilt opslaan, dan denk ik dat je een tabel Artikelen nodig hebt (met een nummer, locatie, beschrijving etc.) en een gekoppelde tabel waarin je het ArtikelID opslaat en de eigenschap van dat artikel. Dus als je van een artikel de Bron hebt, de Auteur(s) dan zou je de Bron in de hoofdtabel zetten, en de auteurs in een gekoppelde tabel, want een artikel kan meerdere auteurs hebben die je apart op wilt slaan. Voor de trefwoorden idem; je hebt per artikel meerdere trefwoorden, en dat kan variëren. Dus voor elk trefwoord één record. Je kunt dan op basis van artikel zien welke trefwoorden etc. er zijn (gekoppeld doorlopend formulier op hoofdformulier) en andersom: op een hoofdformulier Trefwoorden kun je in een doorlopend formulier zien in welke artkelen dat trefwoord staat. En uiteraard de verschillende zoekfuncties die je voor je trefwoorden wilt hebben.

Zo zou ik het dus aanpakken.
 
Per artikel wordt dit dus 1 tabel die dezelfde naam heeft als het artikel, dus heel veel tabellen.
Hier gaat het m.i. namelijk al fout.
De achterliggende reden waarom starters zo beginnen is vaak omdat Access wordt vergeleken met Excel. Ik kan mij dit voorstellen want vaak zie je plaatjes van records met velden alsof het een Excel blad is. Access is een relationele database en bij jouw vraag ligt de nadruk op relationeel.

Ik kan mij aardig vinden in het verhaal van ocatafish.

Het is de bedoeling dat artikelen met hun basis eigenschappen (auteur, jaar) als records in 1 tabel "Artikelen" komen te staan. De artikelen zijn immers uniek, elk record in de tabel is 1 uniek artikel. Aan deze tabel kan je bijvoorbeeld een 2e tabel "Trefwoorden" koppelen met een 1 op veel relatie zodat je trefwoorden naar verschillende artikelen kan verwijzen. Heb je samenvattingen (grotere tekst), dan zet je die eventueel in een aparte tabel "Samenvatting". Dit laatste is niet perse nodig maar wordt vaak gedaan i.v.m. performance. Je kan met een query door één of meerdere tabellen zoeken omdat er relaties zijn gelegd tussen de tabellen.
 
Laatst bewerkt:
Jaaaa, Ik begin denk ik begin te snappen waar ik verkeerd ga denken. Bedankt OctaFish en Bron. Ik ga zoeken voor meer informatie over gekoppelde tabellen. Ik hoop dat ik nog terug mag komen als ik meer vragen heb??

Groet,
Sietse
 
Ik ga zoeken voor meer informatie over gekoppelde tabellen.
De beginselen worden keurig netjes (ahem) uitgelegd in de Access cursus die in de Handleidingen sectie staat. Daar lees je ook waar de term 'relationeel' vandaan komt, en dat is dus niet wat Bron je vertelt :). Maar de strekking is wel goed: je moet je gegevens opslaan op basis van op zijn minst de derde normaal; als je dat doet, heb je een bruikbare structuur.
 
en dat is dus niet wat Bron je vertelt
@octafish, je leest mijn berichtje verkeerd! Het is slechts een omschrijving in een paar zinnen, geen cursus. Ik heb net even de tabellen Artikelen, ArtikelInfo, Auteurs en Trefwoorden gemaakt met de relaties ertussen en het werkt preceis zoals ik heb uitgelegd. Ik zou zeggen, maak de DB ook eens.

Er zijn trouwens veel variaties mogelijk. Als er per artikel weinig trefwoorden zijn dan kan dit veld in tabel Artikelen worden opgenomen met een index. Kleine info velden (titel, jaar) worden meestal ook in tabel Artikelen opgenomen. Dit is geen probleem omdat Access bedoeld is als single user DB (meerdere users kan), en je met queries de records kan opvragen/updaten, en het waarschijnlijk niet om vele duizenden artikelen gaat. Als het wel om heel veel artikelen zou gaan dan is een SQL server wellicht een betere keuze.

** aanvulling
Een prima begin voor wat info over relatie in Access (klik)
 
Laatst bewerkt:
Ik zou zeggen, maak de DB ook eens.
Ik hoop niet dat je hiermee wil zeggen dat ik nog nooit tabellen in een database aan elkaar heb gekoppeld :). Ik reageerde overigens slechts op de niet geheel correcte manier waarop je relaties beschreef. Wellicht is het handiger als ik de Engelse termen gebruik, dan zie je het verschil hopelijk wel. In die taal spreek je over een ‘Relational database’ en leg je in de database ‘Relationships’ tussen de tabellen. De Relation is hier de manier waarop Access de gegevens opslaat, namelijk relationeel. En niet lineair. Jammer genoeg is dat verschil er niet in het Nederlands, daar heeft het woord ‘Relatie’ meerdere betekenissen.

En dan staat hier dus iets
Kleine info velden (titel, jaar) worden meestal ook in tabel Artikelen opgenomen. Dit is geen probleem omdat Access bedoeld is als single user DB (meerdere users kan)
Wat echt niet klopt. De grootte van velden heeft niets te maken met de manier waarop je ze opslaat. Het enige aspect dat telt is: hoort een eigenschap onlosmakelijk bij het record, of niet. Eén artikel heeft één titel, en een titel is dus onlosmakelijk verbonden met dat artikel. Derhalve sla je de titel op in de tabel tblArtikelen. Evenzo geld dat voor het jaar van publicatie; dat kan ook maar één waarde bevatten. Anders is dat voor auteurs; een artikel kan meerdere auteurs hebben. Dus dan maak je in de tabel geen 5 velden om maximaal 5 auteurs op te slaan, maar gebruik je een koppeltabel.

De opmerking dat kleine info velden in de tabel geen probleem zijn, omdat Access een single user db is, zit er wat mij betreft dan echt helemaal naast; niet alleen is Access niet gebouwd als single user applicatie, maar als multi-user omgeving (weliswaar niet voor hele grote groepen gebruikers, dan kun je beter upgraden naar SQL server), maar dat heeft dus niks met velden in een tabel te maken.

Hartstikke goed dat je TS wat theorie mee wil geven; ik ga er zonder meer van uit dat je de beginselen prima beheerst. Maar dan wel graag correcte informatie :).
 
Haha, het is grappig om de Engelse vertaling uit een WiKi te halen. Hele grote verhalen om vooral te laten zien hoe goed je zelf denkt dat je bent. Heeft TS hier iets aan: NEE. Zinloze discussie dus die je begint. Maar ach, je hebt altijd gelijk, je bent heeeel erg goed in alles (ben je nu tevreden). De woorden uit deze laatste zin is slechts "informatie", hoe ik het zeg is de "betekenis".
 
Laatst bewerkt:
@bron:
Haha, het is grappig om de Engelse vertaling uit een WiKi te halen.
Mijn kennisbron is dermate GROOT dat ik geen Engelse vertaling uit een wiki hoef te halen, gewoon parate kennis zeg maar, desalniettemin dank voor je complimenten. Lezen is een kunst die je blijkbaar minder goed beheerst dan het maken van databases; ik heb nergens geschreven dat je een beginner bent. Alleen dat je de beginselen prima beheerst. En daar is toch niks mis mee? Als een redelijk ervaren Access gebruiker durf ik dat van mijzelf in ieder geval ook rustig te beweren...
Bovendien begon jij met extra informatie uit te dissen waar TS m.i. niet om gevraagd heeft. En die dus, in mijn optiek, niet helemaal klopt. En op dat moment vind ik dat ik daar een aanvulling op moet geven, ja. Liever geen informatie dan foute (of, in jouw geval, niet geheel correcte).
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan