Relatie in acces

Status
Niet open voor verdere reacties.
M

ManuelBeauson

Gebruiker
Lid geworden
11 dec 2014
Berichten
146
Ik krijg steeds dezelfde foutcode bij het maken van een relatie in een database, er is geen unieke index gevonden voor het veld van de primaire tabel waarnaar wordt verwezen. Ik heb van de relatie die ik wil maken allemaal dezelfde gegevenstype gegeven en toch lukt het niet. Kan er iemand zeggen wat ik verkeerd doe. Is mijn eerste database en ben nog een beginner.

Alvast bedankt,
 
De melding geeft aan dat je geen sleutelveld gebruikt in je hoofdtabel. Je kunt alleen een één-op-veel relatie maken als je in de hoofdtabel het sleutelveld gebruikt, en dat koppelt aan een (identiek) veld in de koppeltabel waar dat veld dan géén sleutelveld is. Als je twee sleutelvelden koppelt, krijg je een één-op-één relatie.
 
Dat is inderdaad zoals je het kunt lezen. Een primaire sleutel is een veld (of combinatie van velden) die elk record uniek identificeert. D.w.z.: dat veld (of die velden) wijst (of wijzen) altijd naar precies één record; nooit meer of minder. Een voorbeeld van een unieke identifier op basis van één veld is bijvoorbeeld een persoonsrecord met BSN nummer. Dat nummer is uniek, en het record met die persoonsgegevens is dus ook uniek. Derhalve is het BSN nummer prima geschikt als sleutelveld. (als het zou mogen, en dat is niet zo).

De combinatie [Postcode]+[Huisnummer]+[toevoeging] is óók uniek, en kan dus ook als Identifier gebruikt worden. Dat geldt echter óók voor de combinatie [Postcode]+[Huisnummer]+[toevoeging]+[Woonplaats]. Van beide combinaties kun je (en mag je) een sleutel maken, maar slechts één van de 2 is een primaire sleutel. Welke? Daarvoor moet je weten wat de definitie is van een sleutelveld. En die is: (sterk versimpeld, voordat sleutelkenners aan het typen slaan) dat een primaire sleutel de combinatie is van het minimale aantal velden dat een record identificeert. En dan valt in dit voorbeeld de laatste variant af als primaire sleutel, want het veld [Plaats] is overbodig in de sleutel; die is al bepaald door de combinatie [Postcode]+[Huisnummer]+[Toevoeging]. Dus die 3 velden vormen wél een primaire sleutel, de combinatie van 4 velden vormt wél een sleutel, maar geen primaire sleutel.

Hoop dat het zo wat duidelijker is :)
Overigens zie je in een database heel vaak een Autonummerveld als sleutelveld. Dit veldtype heeft doorgaans weinig met het onderwerp van de tabel te maken, maar maakt wel unieke records aan, die ook uniek blijven (je kunt een nummer maar één keer gebruiken).
 
Alvast bedankt om uw uitleg. Ik denk dat ik verkeerd ben gestart met acces, ik moet eerst een hoofdtabel maken die alles vertegenwoordigt en dan allemaal kleinere tabellen waarmee de relatie dan wordt gemaakt
 
Ik had het idee dat je al meerdere tabellen had, want waar wil je anders een relatie mee leggen? Als je een database vanaf het begin niet goed normaliseert, krijg je vroeg of laat vanzelf problemen met de dataverwerking. Het is dus zaak om eerst een goed ontwerp te maken voordat je aan tabellen maken begint, want in een goed ontwerp ligt de basis. Wil je wat meer weten van normaliseren, lees dan de Access cursus er eens op na; de eerste hoofdstukken gaan over het opzetten en normaliseren van een database.
En wat ook helpt: post je eigen database mee met een berichtje, dan kunnen we je tips geven over hoe je het beste verder kunt gaan.
 
Ik had al meerdere tabellen gemaakt , maar volgens mij niet correct. De insteek van de database is de volgende, ik heb meerdere gebouwen , in die gebouwen zitten huurders voornamelijk studenten) maar ik verhuur ook handelspanden waar een zelfstandige activiteit is in onder gebracht. Ik wil bekomen dat ik gebouw x open en kan zien welke huurders hier in zitten , dit wou ik aan de hand van een subformulier doen. Elke maand wil ik ook kunnen ingeven dat de huurder zijn huurgelden heeft betaald , bedrag + datum.
Aangezien er ook onderhoudskosten zijn aan deze gebouwen wil ik deze ook vermelden. Huurovereenkomsten wil ik als bijlagen aan de betreffende huurder hangen als bijlagen.

Dit is ongeveer de insteek
 
Dat lijkt mij niet zo'n moeilijke opzet. Om te beginnen heb je een aantal stamtabellen. Dit zijn de tabellen waarin je de hoofdgegevens opslaat. Een tabel [tGebouwen] bijvoorbeeld, waarin alle gebouwgegevens staan. In zo'n gebouw bevinden verschillende (soorten) eenheden. Een handelspand is wat anders als een verhuurde eenheid, want een handelspand kan één compleet gebouw beslaan, en een verhuurde eenheid is doorgaans ondergebracht in een gebouw. Je hebt dus ook een tabel [tVerhuurdeEenheid] nodig om vast te leggen hoeveel en welke eenheden je per gebouw hebt. Daarnaast heb je huurders, dus dat is een tabel [tHuurders]. Huurders huren een eenheid, dus er komt ook een tabel [tHuurder_Eenheid] waarin je alle verhuurrecords vastlegt.
Daarnaast heb je onderhoud, dus je hebt ook een tabel [tLeveranciers] waarin je de leveranciers vastlegt. Leveranciers leveren diensten, dus die leg je ook vast in een tabel [tDiensten]. Niet elke leverancier levert dezelfde diensten, dus een tabel [tLeverancier_Diensten] lijkt mij ook wenselijk. Voor het onderhoud kijk je naar wat je precies wilt vastleggen. Je kunt onderhoud plegen op een gebouw, dus dat zou een ingang kunnen zijn. Maar je kunt ook onderhoud doen op een VE. Sowieso wil je alleen bij een onderhouds- of reparatieklus alleen uit díe leveranciers kunnen kiezen die bepaalde gewenste diensten leveren. Maar dat kun je met deze opzet al aardig bouwen.
Ben je ook in deze richting bezig?
 
In die richting was ik gestart. Mijn hoofdtabel wordt het tblTelefoonboek, hier komen alle velden om een huurder in op te slaan, dan de tblHuurders , hier heb ik enkel de vraag of ik terug alle velden zoals naam, adres, enz... moet vermelden of kan ik hier de link leggen tussen het telefoonboek, dat ik in de tblHuurders enkel huurderID en het gebouw dat ze in huren vermelden. Voor de betalingen te registreren heb ik nog een vraag, moet ik alle maanden van het jaar dan vermelden in de tblBetalingen
 
Je tabelnamen zijn (in mijn ogen) redelijk vreemd; een tabel tblTelefoonboek? En daar zet je de huurdersgegevens in? En dan de tabel tblHuurders om de huurgegevens in op te slaan? Ik moet er niet aan denken dat ik ooit een database zou moeten overnemen met deze naamgevingen... Ik zou ter plekke gek worden :). Namen van tabellen moeten vooral logisch zijn, en beschrijvend voor wat je er in opslaat. Een tabel tblHuurders bevat dus de huurdergegevens en een tabel tblTelefoonboek? Juist: het telefoonboek! (voor zover je dat nodig hebt, want daar heb je natuurlijk een website voor).
Zodra je tabellen hebt gekoppeld, hoef je alleen het koppelveld op te slaan. Dus (ik ga dus gewoon door met logische tabelnamen, want er zijn meer mensen die deze draadjes lezen) in de tabel tblVerhuur sla je het Huurder uit tblHuurders op, VHE uit de tabel tblHuurder_Eenheid, Begindatum huur en (als de huur is beëindigd) de Einddatum. Eventueel nog hoe er betaald wordt (maand, week, 4 weken, jaar etc) en wat je nog meer bedenkt wat belangrijk is voor het verhuurrecord. Maar dus niet nog een keer de naam, adres etc. want die weet je al op het moment dat je een HuurderID invoert. Die gegevens staan namelijk in de tabel tblHuurders.
In de tabel tblBetalingen maak je een koppeling met tblHuurders op basis van HuurderID, betaaldatum, Bedrag etc. Kortom: alle gegevens die betrekking hebben op de betaling. Dus met een keuzelijst geef je dan de termijn aan waarvoor de betaling bedoeld is. Een lijst met Maanden als het een maandelijkse termijn is, en met Weeknummers als het om een wekelijkse huur gaat. Je gaat zeker geen 12 velden maken voor de betaling, want elke betaling is een eigen record, dus wat moet je dan met de overige 11 velden? Als het goed is krijg je namelijk 12 aparte records voor de 12 betalingen.
 
Octafish, bedankt voor de snelle reactie en uitleg. Het idee van de tabel tbltelefoonboek heb ik al geschrapt, deze was niet nodig. Wat ik niet goed begrijp is dat er zoveel tabellen dienen gemaakt te worden, waarom niet een tabel gebouwen waarin de gegevens van het gebouw zitten met ook vermelding van alle kamers , onderhoudskosten , ...
Dus ik maak een tabel huurders met alle gegevens van de huurder. Dan een tabel gebouwen, hierin alle info wat betreft het gebouw. Tabel verhuring met de info wie wat huurt en in welk gebouW, huurprijs, maandelijke betaling. Voor de onderhoud van de gebouwen maak ik een leveranciers tabel aan met vermelding van mijn leveranciers.
 
Waar kan ik ergens een database zien die volledig is afgewerkt, tabellen, formulieren, interface, .... Op deze manier begrijp ik misschien beter hoe acces werkt en kan ik zien waar ik moet mee rekening houden.

Alvast bedankt,
 
Het principe van normaliseren heb ik in de cursus uitgelegd. In essentie komt het hier op neer: gegevens opslaan met zo weinig mogelijk dataredundantie. En dat is dan weer het streven om een bepaald gegeven zo weinig mogelijk op te slaan. En dat doe je door herhalende gegevens te vermijden. Zodra je constateert dat je in een tabel steeds dezelfde groep gegevens moet invoeren is de tabel niet genormaliseerd, en moet je de herhalende gegevensgroep uit die tabel halen, en opslaan in een eigen tabel. Die koppel je dan aan elkaar doordat je het sleutelveld uit de nieuwe tabel opneemt in de tabel waar de groep uit kwam. En als je zo werkt, kom je al snel aan wat meer tabellen. Maar dat geeft niet, want dat is voor het onderhoud van die tabellen ook veel beter.
Voorbeelden zijn uiteraard wel te vinden, kijk maar eens in de voorbeeld databases van Microsoft. Die zijn, al hebben ze bij Microsoft bijzonder weinig kaas gegeten van normaliseren, wel goed geprogrammeerd. Er zitten dus wel fraaie voorbeelden van formulieren in.
 
Ik heb in twee tabellen een kolom met naamGebouw , dit zijn tekstvelden, ik kan geen relatie opzetten tussen beide, komt dit omdat het tekstvelden zijn.
 
Je kunt alleen relaties leggen tussen tabellen op basis van een sleutelveld en een gerelateerd veld. Dus uit tGebouwen heb je iets als een GebouwID als sleutel, en dat veld zet je ook in de gerelateerde tabel. Een tekstveld als NaamGebouw is daar niet geschikt voor, want geen sleutelveld.
 
Probleem is een beetje dat wij in het verleden (20 jaar terug) gestart zijn met elk gebouw een naam te geven, dit gaat zowel voor de facturatie als voor alles. Nu plots alles gaan veranderen gaat niet meer. Elke naam van een gebouw bestaat uit drie letters en drie cijfers , kan ik dit zo instellen en dan toch een relatie opzetten omdat ze dan een uniek veld hebben
 
ManuelBeauson zei:
Nu plots alles gaan veranderen gaat niet meer.
Klik om te vergroten...
Dat is niet helemaal waar, want je kunt dat best aanpassen met een aantal bijwerkqueries. Maar het is wel wat werk natuurlijk, want ook je formulieren en rapporten zijn op de huidige constellatie ingericht. Maar in beginsel kom je qua relaties een heel eind als je velden toevoegt met de juiste eigenschappen, en dan met bijwerkqueries de nieuwe velden vult. Daarna kun je de oude waarden/velden verwijderen.

Maar:
ManuelBeauson zei:
Elke naam van een gebouw bestaat uit drie letters en drie cijfers
Klik om te vergroten...
Dat is geen naam in mijn ogen, maar een uniek veld. Dit vind ik een veldcode, en geen naam :). Je hebt dus in beginsel al een codeveld dat je uniek kunt maken. Ik neem althans niet aan dat die 6 tekens niet uniek zijn... Dat roept dan wel weer de vraag op wat je nu als sleutelveld gebruikt! Want je hebt in zo'n tabel maar één sleutelveld nodig.
 
Als ik het zo kan zien (de volgorde van de tabellen in het plaatje is een beetje onlogisch) zit er minstens één fout in je opzet: je hebt tblHuurders zowel aan tblGebouw als aan tblVerhuurdeEenheid gekoppeld. Die koppeling moet weg, want je hebt al een koppeling tussen huurders en gebouw middels tblVerhuurdeEenheid.
 
Octafish, ik vindt het geweldig hoe je mij helpt en ik krijg al meer inzicht in het opzetten van een database, alvast bedankt daarvoor. Het probleem met die relaties is dat ik niet weet hoe dit wanneer alles is afgewerkt er gaat uitzien, ik weet bijvoorbeeld niet welke info ik ga te zien krijgen als ik dan het afgewerkte formulier de huurders op vraag van een gebouw en wie zijn huurgelden heeft betaald.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan