tabellen / relatie problemen

[lilx]

hallo,

Momenteel ben ik bezig met een project voor school. Daar moet ik een Microsoft Office Access database maken voor een middelbare school. Zij hebben mij gevraagd om een database te maken voor hun stage leerlingen.

Momenteel stuit ik op het probleem met mijn tabellen / relatie. Waar ik van mening ben dat dit een van de belangrijkste punten zijn van het ontwikkelen van een database.

De bedoeling van de database.
De database beschikt over enkele tabellen waar de studenten, organisatie(stage bedrijf) en docenten in staan. Wat ik probeer is een stagebedrijf te koppelen aan de student, maar dit wil mijn niet lukken
Uiteindelijk is het doel. Dat stage bedrijven gekoppeld kunnen worden aan leerlingen en docenten deze beheren. Daarbij gaat de leerling alleen de mogelijkheid hebben tot alleen-lezen om een stage bedrijf te vinden en docenten de koppeling maken en zei via dit systeem een stagebezoek kunnen inplannen. Dit willen zei op ene systeem van postcode van de docente en zo zoekt het systeem de twee dichtbijzijnde postcodes op.

Voorbeeld:
Postcode is 2302 krijgt de leerlaar alle studenten die op stage zitten in de postcodes.
2300, 2301,2302,2304,2305

Ik hoop dat jullie mij met deze probleem kunnen helpen want momenteel zit ik heel te klussen met de relaties en tabellen structuur maar helaas kom ik er niet uit..

 

[OctaFish]

Zonder de database te zien, is het moeilijk te zeggen waarom de tabellen niet te koppelen zijn. Je kunt eerst eens kijken naar de volgende zaken:
1. Zijn de twee velden die je gebruikt om te koppelen van hetzelfde gegevenstype?
2. Staan er in de gerelateerde (de veel-kant van de relatie) tabel waarden die niet in de hoofdtabel staan?
Dit zijn twee van de meest voorkomende problemen met relaties.

Ad 1. Als in de hoofdtabel een autonummerveld wordt gebruikt als sleutelveld, dan moet je in de te koppelen tabel koppelen met een veld dat van het type [Numerier - Lange Integer] is. Heeft dit veld de instelling Tekst, dan kun je dus niet koppelen met dit veld. Je zult dan eerst de veldeigenschap moeten veranderen in Numeriek.
Ad 2. Als de gegevenstypen gelijk zijn, dan kan het nog zijn dat je in de hoofdtabel bijvoorbeeld 3 records hebt met de nummers 1,2 en 4, (record 3 is verwijderd) en in de gekoppelde tabel staan nog 2 records die koppelen met het verwijderde record (3 dus). In dat geval kun je ook niet (correct) koppelen met de hoofdtabel, want een relatie is alleen goed als je Referentiële Integriteit kunt afdwingen, en dat houdt in dat in de gekoppelde tabel geen verwijzing mag staan naar records die niet bestaan in de hoofdtabel.
Controleer dus eerst of deze twee gevallen al dan niet voorkomen...

 

[lilx]

mijn excuses dat ik niet heb geüpload wat ik tot nu toe hebt. ik heb deze nu in de bijlage gezet. dit is het laatste wat ik heb waarvan ik dacht dat ik op het goede spoor was. nadat is het een beetje een zooitje geworden met proberen.

zover ik weet heb ik mijn goed aan de regels van relatie gehouden. dus als er een autonummer gebruikt wordt moet er aan de andere kant numeriek gebruikt worden. en zijn al mijn relaties met referentie afgedwongen. dus ik denk dat mijn koppel methode (logica) voor het gebruik van de data niet goed is.

 

[OctaFish]

Geeft niks.... Wat wel geeft, is dat het een 2007 versie is. Want daar loop ik met een grote boog omheen Heb je ook een 2003 versie?

 

[lilx]

is het goed als ik deze opsla met een 2003 bestandsindeling?

 

[OctaFish]

Meer dan voortreffelijk!

 

[lilx]

het duurde wat langer ik had Access 2007 functies in mijn tabel om die reden kon ik hem niet opslaan als 2003 format maar dat is opgelost

hierbij in de bijlage mijn database tot nu toe in 2003 formaat.

 

[OctaFish]

Ik heb 'm geopend, en constateer dat ongeveer de helft van de gelegde relaties tussen de tabellen niet deugt. D.w.z. dat de optie Referentiële Integriteit niet was geactiveerd, wat wel moet om de relatie werkbaar te maken. Overigens waren de relaties wel aan te passen, dus daar zit verder geen probleem.
Wel een probleem is, dat je zoveel mogelijk tabellen aan elkaar geknoopt hebt; ook tabellen die in wezen niks met elkaar te maken hebben. Hiermee haal je jezelf allerlei problemen op de hals. Bij het leggen van relaties tussen de verschillende tabellen is het belangrijk dat je relaties legt tussen tabellen die van elkaar afhankelijk zijn. Een tabel als Woonplaats wordt in verschillende andere tabellen gebruikt, maar als je die tabel koppelt aan alle tabellen waarin een Woonplaats voorkomt, leg je verbanden tussen tabellen die niks met elkaar te maken hebben, zoals Docenten en Organisaties. Ook al hebben die allebei een woonplaats, je wilt de tabel Woonplaats niet als verbindende tabel tussen Organisatie en docenten hebben.
Wat ik mis, of misschien is die er wel, maar heb je dat nog niet verteld, is welke tabellen je niet aan elkaar kunt koppelen. Je had het over Studenten en Stagebedrijven. Als je die wilt koppelen, moet je een tabel hebben waarin je vastlegt welke student Doe je met student_ID) naar welk stagebedrijf gaat (organisatie_ID?) Daar hoort dan, neem ik aan, ook een datumperiode bij?

 

[lilx]

ik was er niet van bewust dat door middel van meerdere tabellen te koppelen aan een opzoektabel je zo ook een onderlinge relatie maakt met elkaar. ik begrijp van je post dat je niet totaal zicht op wat ik wil bereiken.
ten eerste heb ik mijn tabellen opgesplitst naar hopelijk de beste vorm van normalisatie. Ik hoop dus dat dit redelijk goed is gedaan.

- student is het hoofdpunt van de database. de student moet gekoppeld worden aan een stage.
- organisatie is het stagebedrijf waar dus een student aan wordt gekoppeld
- docent is bedoeld om uiteindelijk routes te kunnen maken voor leraren om op stagebezoek te gaan.

werkzaamheid hoe ik het nu ingebeeld heb is het volgende (sommige functies kunnen er nog niet in zitten, dit is omdat ik eerste de koppeling tussen student en organisatie goed wil hebben):

1. gebruiker logt in met mogelijkheid leerling of docent, leerling gaan de rechten krijgen tot alleen-lezen en docenten krijgen volledig beheer. De reden is waarom de leerling zelf geen rechten krijgen omdat een leerling met kwade bedoeling er een puinzooi kan maken. Terwijl zei deze database uiteindelijk gaan gebruiken om alleen contact op te nemen met beschikbare bedrijven. En wijzigingen voeren docenten (gebruikersaccount docenten) alleen in.

Na het inloggen(gaan we ervan uit dat we nu volledige rechten hebben)
2. wil ik een formulier hebben waar ik de student kan zien per record daarin heb ik in gedachte om een subformulier te hebben met de organisaties(stagebedrijven).

3. in dat formulier wil ik de mogelijk hebben als dit tevens ook mogelijk is. Om een vinkje te kunnen zetten achter de stage bedrijf waar de student op zit, met de optie per student mag je niet meer dan 1 bedrijf hebben aangevinkt.

Waarbij tbl_stage moet dienen als hoofdformulier. In deze tabel wil ik dus dat de gegevens van student en organisatie samenkomen.

Momenteel heb ik eigenlijk zoveel geprobeerd dat ik mijn inzicht erin kwijt ben. Dus mogen er suggesties zijn naar een andere opbouw zou ik dat graag willen horen

 

[OctaFish]

OK, de tabel Stage is dus de verbindende schakel tussen Organisatie en Student. Deze tabel moet dan gekoppeld worden tussen Organisatie en Student. Nu heb je daar de tabel Student_Interview tussen hangen.
De reden dat je Stage en Student niet kan koppelen, is dat je de optie Index op <Ja, Geen duplicaten> had staan. Hiermee geef je aan dat een student maar één stage mag lopen. Zelfs dat zo is, zou ik die instelling toch veranderen in <Ja, Duplicaten OK>. Nu kun je namelijk wel Referentiële integriteit afdwingen. Overigens is met een beetje spelen de één-op-één relatie ook wel te leggen. Je hebt tussen Student en Student_Interview ook een één-op-één relatie liggen. Ook hier heb je dus ingesteld dat een student maar één interview mag doen. Dat moet dan dus wel een positief gesprek opleveren, anders heb je geen stage.... Lijkt mij eerlijk gezegd toch ook niet de bedoeling?

 

[OctaFish]

Kijk eens of deze relaties voor je kunnen werken.

 

[lilx]

mijn gedachte met een op een bij de student_interview. is dat er maar 1 record is van de student. waarin zijn historie (stappen voordat de stage begint) kan worden opgenomen. denkend aan, stage formulieren ingeleverd, akkoord stagebedrijf, mogelijk commentaar / voorgaande afspraken. en deze record steeds weer te wijzigen bij veranderingen. diepgaande historie opbouw is niet van toepassing en zou verwarrend kunnen werken voor de docenten.

bedankt voor de sample ik zal er naar kijken met de hoop dat ik zo verder kan. ik hou je hierover op de hoogte.

 

[OctaFish]

Door jouw opzet (geen historie) kun je ook nooit meer zien of iemand al eerder iets gedaan heeft in die tabel. Door in een formulier bijvoorbeeld altijd het laatste record te laten zien/bijwerken, heb je volgens mij geen probleem met verwarrende situaties... Maar het is een keuze, die je uiteraard kunt maken.