[access] wat is er mis met dit ontwerp(je)

[cinnamon]

we hebben een tabel met io benamingen
typical kan één of meerdere van deze io hebben

verbruikers is van een bepaald type typical

io van een verbruiker is weer een keuze uit de io van de gekozen typical

mijn vraag, is dit databasetechisch correct wat hier gemaakt is

overige opmerkingen overigens ook welkom

[mulder]

Heeft een Verbruiker meerdere Verbuikers_IO?

[Verwijderd]

schrijf eens uit wat je wilt, het lijkt me nogal vreemd dit (er zit een kring in)

[cinnamon]

Don Facundo schreef op 08 oktober 2002 @ 19:35:
Heeft een Verbruiker meerdere Verbuikers_IO?

Ja, verbruiker_io is een deel van typical_io voor een bepaalde typical

Verwijderd schreef op 08 oktober 2002 @ 20:12:
schrijf eens uit wat je wilt, het lijkt me nogal vreemd dit (er zit een kring in)

is geen kring, "beide pijltjes wijzen naar de tabel typical toe" (sorrie)

het gaat erom, bij verbruiker wordt een typical gekozen
deze typical heeft een aantal io waaruit gekozen kan worden
de gekozen io worden toegekend aan de verbruiker

krijg het effe niet veel helderder

[Dido]

Eerste reacties:

Wat voor relaties gaat het om? (Zet er pijltjes bij!!)
Zet het eens gestructureerd neer!

Er zit voor zover ik kan zien wel een kring in: (ik zou nu een poging doen te tekenen wat ik begrijp dat er staat, maar dat kan niet meer met code tags!)

Je hebt twee koppeltabellen, fout uitgedrukt betekent dat een veel-op-veel relatie tussen Typicals en IO, en tussen Verbruikers en je veel-op-veel-relatie tussen Typicals en IO!

OK... toch een poging:

code:

          Typicals    IO
         |        |    |
Verbruikers ---Typical_IO

En dat gaat fout...

Zet het eens wat duidelijker neer, en, als je dan zelf niet ziet wat er fout is, post het, dan kijk ik morgen nog eens

[farlane]

Dus:

- Een verbruiker kan maar 1 typical hebben ( 1 op 1) ? Dan is de Verbruikers_IO tabel overbodig want dan kun je met een query Verbruikers -> Typicals -> Typical_IO opvragen welke IO aan een gebruiker vast zit.

- Een gebruiker kan meerdere typicals hebben ( en vice versa <-> veel op veel ) ? Dan moet er een koppeltabel tussen verbruikers en typicals. Ook dan kan de Verbruiker_IO tabel weg.

[cinnamon]

plaatje vernieuwd ter verduidelijking

weet niet zeker of dat integriteit verhaal ook gaat werken, maar de relaties zouden nu iets duidelijker moeten zijn

enneuh T. euh Farlane

werkt niet wat je daar vertelt

een typical heeft een bepaald aantal io
een verbruiker hoeft niet perse alle io, gekoppeld aan de typical te hebben, kan nl minder zijn


(we hebben beurs gemist)

[farlane]

Geef eens een voorbeeld van wat een verbruiker is en het verband met Verbruikers_IO. Dat is me niet helemaal duidelijk.

Beurs was afgelopen za en zo. Bummer.

NB "je vertelt"

[Verwijderd]

OK, na de posts en je tabel bekeken te hebben concludeer ik het volgende (gaarne verbeteren als ik het fout heb) :

Een verbruiker is als het ware van een bepaalde "catagorie", nl typical. Bij iedere catagorie verbruikers horen meerdere soorten IO (en sommige soorten IO horen bij meerdere catagorien verbruikers). De tabellen en relaties tussen verbruikers, typical, IO en typical_IO zijn daarmee verklaard en die kloppen ook wel. Die laatste snap ik echter geen snars van.
Wat wil je nou met verbruiker_IO? Aangeven dat een verbruiker dus meerdere soorten IO kan verbruiken? En dat die een subset moeten zijn van alle records in typical_IO voor zijn typical? Dat doe je dus niet op die manier...
Als je wilt afdwingen dat een verbruiker alleen maar soorten IO kan hebben die bij zijn typical horen : dat kan gewoon niet op deze manier. Nu zou je o.a. een record in de verbruiker_IO tabel kunnen hebben met een id van een typical_IO die niet eens bij zijn eigen typical hoort. Ook kan ik nu in typical_IO twee records aanmaken met dezelfde typical_id EN IO_id. Daarvoor moet je met data validation rules werken. Hoe dat precies in elkaar zit weet ik niet, maar dat doe je in ieder geval NIET met relationships.

De tabel verbruiker_IO moet dus een veel-op-1 relatie hebben met de tabel IO, niet met typical_IO! Dat dat alleen maar een IO mag zijn die bij zijn typical hoort, kun je niet met een relatie afdwingen!

[cinnamon]

een verbruiker is een object van een bepaald type typical
een verbruiker heeft een aantal io welke toegestaan moeten zijn bij dit type typical ( dit hoeven niet alle io van de typical te zijn)

begrijp ik het goed als ik zeg dat er de tabel typical_io goed is, maar dat de tabel verbruikers_io geen relatie moet hebben met typical_io maar met de tabel io

kortom je hebt een verbruiker en kiest daarbij een typical
uit de tabel typical_io krijg je een lijstje met toegestane io

bepaal de io bij de verbruiker en sla deze op in een tabel verbruikers_io met de velden verbruiker_id en io_id
(kan nu even niet makkelijk nieuw relatieplaatje maken)

hierdoor kan volgens mij in de tabel verbruikers_io ook een verbruiker_id/io_id combinatie voorkomen die niet toegestaan is voor de gekozen typical

het voorkomen van dubbele waarden in de typical_io tabel kan volgens mij door een combinatie van beide velden als primaire key in te stellen

het probleem is helemaal niet zo heel erg lastig (lijkt me), krijg het alleen nog niet helder uitgelegd