Referentiële integriteit inbouwen in Access/VB

[Verwijderd]

Voor een groepswerk informatica moeten we (vertrekkende van een EER, use case en data flow) Access door middel van Ado.net linken aan Visual Basic 2005 express.

In de opgave staat er onder andere dat we moeten toelichten welke keuzes we maakten omtrent referentiële integriteit: update en delete effect.
Hierbij hebben we het onderscheid gezien tussen cascade, set null en restrict.
We snappen het onderscheid hier wel tussen, maar waar in godsnaam moet dit verwerkt worden?
Met andere woorden: waar in de code moeten we dit eigenlijk plaatsen?

Alvast bedant!

[jvdmeer]

Nergens in de code?

Bij een normaal DBMS zou je dit aangeven in de database. Weet niet of Access dit ondersteunt.

[rapture]

Stel dat je een forum maakt, je hebt in de databases een tabel met users, aan users kan je een tabel met posten hangen. Als je een post delete, dan is er geen probleem. Maar als je een user delete, dan heb je posten, die van geen enkele user zijn. We hebben dan een probleem, je kan in de code voorzien, dat eerst alle posten van de user gedelete wordt, daarna kan je de user deleten.

[Verwijderd]

Bij het aanmaken van je tabel geef je aan wat moet gebeuren met, bijvoorbeeld, on delete:

SQL:

foreign key prodkey references product (prodkey) 
   on delete cascade 

Ik denk dat je dit wel een nuttig stuk kan vinden:
http://publib.boulder.ibm...rick.doc6.3/wag/wag29.htm

[Dido]

In Access kun je relaties aanmaken tussen je tabellen (met zo'n handige wizard )
Onder tools-->relationships

Dan kun je je tabellen op een werkblad zetten en vervolgens een veldje (PK) naar een ander veldje slepen (FK), dan krijg j eeen pop-upje waar je kunt kiezen wat voor relatie je wilt (open, gesloten, LAT, gay, mormoons, etc ) en daar kun je ook je ref. integrity kwijt.

[Verwijderd]

Access

Daar had ik even overheen gelezen

[Dido]

Da's Freudiaans, denk ik

[Verwijderd]

Dido schreef op dinsdag 27 november 2007 @ 19:13:
Da's Freudiaans, denk ik

[whoami]

rapture schreef op dinsdag 27 november 2007 @ 18:50:
Stel dat je een forum maakt, je hebt in de databases een tabel met users, aan users kan je een tabel met posten hangen. Als je een post delete, dan is er geen probleem. Maar als je een user delete, dan heb je posten, die van geen enkele user zijn. We hebben dan een probleem, je kan in de code voorzien, dat eerst alle posten van de user gedelete wordt, daarna kan je de user deleten.

De topicstarter zegt dat hij weet wat referentiele integriteit is.

Zoals reeds gezegd: welke optie je wilt gebruiken in je foreign key definieer je in je DBMS; je hoeft er in je code geen rekening mee te houden.

[MrBucket]

whoami schreef op dinsdag 27 november 2007 @ 20:35:
[...]

De topicstarter zegt dat hij weet wat referentiele integriteit is.

De naam van de topicstarter lijkt me een vrouw te impliceren...

Zoals reeds gezegd: welke optie je wilt gebruiken in je foreign key definieer je in je DBMS; je hoeft er in je code geen rekening mee te houden.

Yup. Oftewel: bij het aanmaken van je foreign key in de database kun je specificeren wat er moet gebeuren om de foreign key constraint af te dwingen.

In MS SQL Server (T-SQL) zou het iets worden als:

SQL:

ALTER TABLE Accounts FOREIGN KEY fkey1 (CustNo) REFERENCES Customers ON UPDATE CASCADE

In MS Access is hier ongetwijfeld ook een manier voor om dit zonder tekstuele commando's te kunnen doen.

[Verwijderd]

Super, al die antwoorden :-)
Bij access kan dit inderdaad aangevinkt worden bij de eigenschappen van de relationships, maar we dachten dat dit ook in visual basic moet gestopt worden.
Want, stel dat ik (om het voorbeeld van hierboven aan te halen) in VB zeg dat ik een user wil deleten en in access is gezet dat eerst alle posten moeten verwijderd worden.
Hoe weet VB dit dan? Of, hoe kan dan in VB weergegeven worden dat dit een ongeldige bewerking is?
'k vrees dak dit forum nog vaak zal nodig hebben, want als leken is het niet evident om efkes een programma van nul te programmeren...

[cspare]

Verwijderd schreef op dinsdag 27 november 2007 @ 22:02:
Hoe weet VB dit dan? Of, hoe kan dan in VB weergegeven worden dat dit een ongeldige bewerking is?

Dat is ook meteen het grootste probleem van cascade imo.. je database kan er snel mee omgaan maar je raakt wel je invloed kwijt in het geheel. veel mensen vinden cascade delete dan ook evil

want als leken is het niet evident om efkes een programma van nul te programmeren...

Dan zit je waarschijnlijk op de verkeerde opleiding

[Verwijderd]

Bij een opleiding Toegepast Economische Wetenschappen verwacht je inderdaad niet van te moeten programmeren in VB...

[RobIII]

Verwijderd schreef op dinsdag 27 november 2007 @ 22:02:
Hoe weet VB dit dan?

Dat is nou net het mooie; de database heeft z'n eigen verantwoordelijkheid, net als VB. De database is 'aangenomen' om je data consistent te houden; VB neem je aan voor de business logica en GUI capabiliteiten. Het zal VB dus werkelijk roesten hoe (en OF) Access een cascade uitvoert of niet. Uiteraard; als een cascade niet uitgevoerd wordt is de bewerking ongeldig (zegt je datamodel en dus Access) en dus schopt Access op zijn beurt een "daar begin ik niet aan, zoek 't mooi zelf uit" terug naar VB op het moment dat je het toch zou proberen. Zie het als een uitsmijter die je er niet langs laat als je iets probeert te doen wat niet mag.

Verwijderd schreef op dinsdag 27 november 2007 @ 22:02:
Of, hoe kan dan in VB weergegeven worden dat dit een ongeldige bewerking is?

As said; Access (eigenlijk de onderliggende lagen, maar boeie) zal een "exception" gooien als je iets probeert te doen wat niet mag van je datamodel; zie die exception als een rode vlag waarop staat: "No can do!". Vervolgens gaat VB op z'n bek als je geen exception handling hebt. Heb je die wel (in VB6 is dat helaas niet veel meer dan "On error goto somelabel") dan vang je de fout en handel je 'm naar wens af.

Verwijderd schreef op dinsdag 27 november 2007 @ 22:02:
Want, stel dat ik (om het voorbeeld van hierboven aan te halen) in VB zeg dat ik een user wil deleten en in access is gezet dat eerst alle posten moeten verwijderd worden.

Voor de duidelijkheid dus: Access (lees: je DBMS) zal de cascade uitvoeren (mits ingesteld), niet VB.

[ Voor 18% gewijzigd door RobIII op 27-11-2007 23:23 ]

[Gomez12]

Verwijderd schreef op dinsdag 27 november 2007 @ 22:02:
Hoe weet VB dit dan? Of, hoe kan dan in VB weergegeven worden dat dit een ongeldige bewerking is?

Niet, niet.
Als het in de database gedefinieerd is dan weet in principe VB hier niets vanaf, alleen bij weergeven van een topic ziet VB misschien opeens gaten in de data ( als je post 1 ophaalt dan post2 dan post3, dan kan ineens post2 niet meer bestaan, maar als jij gewoon de posts ophaalt die aan het topic hangen dan ziet VB helemaal niets, want hij weet gewoon niet dat er ooit een post 2 bestaan heeft. )

Daarom is het ook niet perse een ongeldige bewerking, mits goed toegepast.
Dus bijv bij een forum zou ik bij een user delete ( zou ik zowieso nooit bouwen, maar dat is een andere discussie ) hooguit met een cascaded delete zijn fotoalbum leeggooien, zijn icoontjes weggooien ( ruimte besparing en niet boeiend om te bewaren ) maar zijn posts zou ik of gewoon afblijven ( referentiele integriteit maakt dit moeilijk omdat een post bijna altijd een bestaande user moet hebben ) of ze met een update onder een speciale user hangen ( genaamd : Deleteduserposts ) .
Denk je maar eens in wat er gebeurt als een mod hier zijn account verwijdert, al zijn posts verdwijnen dus een heleboel topics gaan spaak lopen, maar alle topics die hij gesloten heeft hebben opeens ook geen sluitmessage meer, waardoor je weer users gaat vragen waarom is topic x of y op slot gezet zonder sluitmessage etc etc.
'k vrees dak dit forum nog vaak zal nodig hebben, want als leken is het niet evident om efkes een programma van nul te programmeren...
[/quote]

[RobIII]

Gomez12 schreef op dinsdag 27 november 2007 @ 23:24:
[...]
Dus bijv bij een forum zou ik bij een user delete ( zou ik zowieso nooit bouwen, maar dat is een andere discussie ) hooguit met een cascaded delete zijn fotoalbum leeggooien, zijn icoontjes weggooien ( ruimte besparing en niet boeiend om te bewaren ) maar zijn posts zou ik of gewoon afblijven ( referentiele integriteit maakt dit moeilijk omdat een post bijna altijd een bestaande user moet hebben ) of ze met een update onder een speciale user hangen ( genaamd : Deleteduserposts )

De methode die je hier omschrijft is misschien nog wel erger dan alleen de user weggooien en je referentiële integriteit te grabbel leggen Als je bij een delete records moet gaan bijwerken (moven naar een dummy user) en daarbij ook nog een 'selectief' data weggooit dan zou ik persoonlijk opteren voor een extra status voor een user (bijv. "deleted" toevoegen aan het lijstje) of een extra veld toevoegen voor de deleted status en het record (de user) uit alle overzichten etc. weglaten, maar de posts blijven dus wel degelijk gekoppeld aan die user. In (bijvoorbeeld) een 'verjaardagen' overzicht kun je die user(s) met een simpele where-clause er uit filteren. Met een 'delete' kun je dan (als je het doet om ruimte besparende redenen) alsnog wel een 'cleanup' doen van z'n account, maar in principe zou ik ook die gegevens gewoon 'markeren' als deleted. Het is (IMHO) of alles weg, of alles bewaren en eruit filteren waar het niet gewenst is. Een ander nadeel met alles onder 'deleteduser' hangen is dat je naderhand nooit meer onderscheid tussen de verschillende deleted accounts kunt maken.

Het gevaar van cascades is (de naam zegt het eigenlijk al een beetje) dat je soms niet echt een goed overzicht hebt van wat er verwijderd gaat worden. In het geval van een user en posts is het nog te overzien, maar als een delete van een user helemaal 'escaleert' naar posts, historische tabellen, statistische tabellen, medische gegevens en verzin nog 50 andere tabellen waaraan data zit (die op hun beurt ook weer zouden kunnen cascaden) dan is een cascade wel heel link ja. Zie overigens ook dit stukje; er zijn namelijk nog meer mogelijkheden

[ Voor 3% gewijzigd door RobIII op 28-11-2007 00:01 ]

[NMe]

Met cascades moet je hoe dan ook altijd oppassen. Het lullige aan dingen die automatisch gebeuren is juist dat het automatisch gebeurt en je soms spul weggooit zonder het te merken als je ergens vergeet rekening mee te houden. En dan is het dus gewoon weg.

[Freee!!]

Referentiële integriteit heeft voor- en nadelen, maar het is nog altijd beter dan een compleet inconsistente database (hoewel dat laatste een goede werkverschaffer is ).

[Verwijderd]

Dankjewel allemaal!!
Is er trouwens in access ergens echt aan te doen welk effect er moet toegepast worden? Of houdt het op bij het aanvinken van 'referentiële integriteit afdwingen' ?

[RobIII]

Verwijderd schreef op woensdag 28 november 2007 @ 17:35:
Is er trouwens in access ergens echt aan te doen welk effect er moet toegepast worden? Of houdt het op bij het aanvinken van 'referentiële integriteit afdwingen' ?

Euh... récht onder het vinkje waar je het over hebt staan de opties

[Verwijderd]

Zo stom ben ik ook niet!!
Maar zie jij daar hoe je kan kiezen tussen 'ON UPDATE CASCADE', 'ON UPDATE SET NULL' of 'ON UPDATE RESTRICT'?!
Ik in ieder geval niet en dat is nu net wat wij nodig hebben!

[whoami]

Eh, blijkbaar moet je toch eens beter lezen want het staat toch echt in dat schermpje dat RobIII gepost heeft .... (Al is het dan niet in 't engels, maar in het nederlands, en moet je een beetje begrijpend lezen. ... )

[Apen-nootjes]

Nog even inhaken op wat whoami zegt:
On Update Cascade == Gerelateerde velden trapsgewijs bijwerken
On Update Set Null == Gerelateerde records trapsgewijs verwijderen

[Verwijderd]

Apen-nootjes schreef op donderdag 29 november 2007 @ 22:30:
Nog even inhaken op wat whoami zegt: [html]<!-- ja, ja.. ik kouw het maar voor... -->[/html]
On Update Cascade == Gerelateerde velden trapsgewijs bijwerken
On Update Set Null == Gerelateerde records trapsgewijs verwijderen

Geen ervaring met Access, maar 'Gerelateerde records trapsgewijs verwijderen' lijkt me toch wel iets anders dan 'Gerelateerde velden trapsgewijs resetten' (on update set null).
In 't laatste geval verlies je alleen links naar FK's die niet meer bestaan, in 't eerste geval verlies je daadwerkelijk data.

In real life zou dit helemaal geen probleem zijn: biedt Access niet de mogelijkheden die je nodig hebt, dan pak je toch MSSQL2005 Express? Maar bij een schoolopdracht heb je niet altijd die keus. Of je moet de kont tegen de krib gooien, en daar zijn meiden over 't algemeen beter in dan jongens.

[whoami]

Idd, gerelateerde records trapsgewijs verwijderen : cascade.

[RobIII]

Verwijderd schreef op donderdag 29 november 2007 @ 21:07:
Zo stom ben ik ook niet!!
Maar zie jij daar hoe je kan kiezen tussen 'ON UPDATE CASCADE', 'ON UPDATE SET NULL' of 'ON UPDATE RESTRICT'?!
Ik in ieder geval niet en dat is nu net wat wij nodig hebben!

Zelfde schermpje, nu in het Engels dan...

[ Voor 9% gewijzigd door RobIII op 30-11-2007 09:28 ]

[EfBe]

Whoa, 25 posts over referential integrity in access...

No offence, maar ookal is de help soms hondsberoerd in office, ZO triest is deze nu ook weer niet.

[Creepy]

Verwijderd schreef op donderdag 29 november 2007 @ 21:07:
Zo stom ben ik ook niet!!
Maar zie jij daar hoe je kan kiezen tussen 'ON UPDATE CASCADE', 'ON UPDATE SET NULL' of 'ON UPDATE RESTRICT'?!
Ik in ieder geval niet en dat is nu net wat wij nodig hebben!

No offence maar vertaal dat schermpje gewoon ff naar het Engels en ie ziet dat die checkboxes precies doen wat jij nodig hebt.

Dit gaat echt te ver nu. Zo moeilijk is het nu ook weer net en zelfs met een kant en klare screenshot die aangeeft waar het staat ga je lopen roepen dat het niet het juiste is terwijl dat het dus wel is. Denk aub een volgende keer iets langer na voordat je post want de daadwerkelijke oplossing had je na een paar posts in dit topic toch wel zelf moeten kunnen bedenken. Daarnaast zijn er ook nog docenten die het je eventueel compleet kunnen laten zien hoe het werkt of je in elk geval de juiste richting op hadden moeten kunnen sturen.

[ Voor 9% gewijzigd door Creepy op 30-11-2007 10:07 . Reden: typo :-) ]