[Access]3 Kollommen naar 1 ?

[Verwijderd]

Ik zit dus met een vraag, ik ben bezig met een filmdatabase en nu heb ik 3 kollommen in 1 tabel die het Genre samenvat. genreid, genreid2 en genreid3.
Ik wil dus op genre kunnen zoeken, dit gaat wel goed zoals je ziet in het plaatje dmv relaties maar nu wil ik zegmaar ook dat genreid2 en genreid3 hierbij gevoegt worden. Omdat ik anders 3 van deze tabellen moet maken. Dat kan wel maar is niet overzichtelijk en ook niet mooi. Weet iemand hoe dit is op te lossen?
Het doel is dus dat ik in een formulier als genre bijvoorbeeld Actie kies.
Dat hij dan van genreid , genreid2 en genreid3 alle Actie films pakt.

[Verwijderd]

Je database structuur is niet goed. Haal de genre-informatie uit de film tabel, en voeg een nieuwe tabel toe die films aan genres koppelt. Die tabel bestaat uit niets anders dan een filmnummer en een genreid.

[Verwijderd]

Jah oke maar nu dus weer het probleem , ik heb meerdere genreid's. Hoe ga je dan tewerk?

[henkleerssen]

Verwijderd schreef op 24 oktober 2004 @ 14:12:
Je database structuur is niet goed. Haal de genre-informatie uit de film tabel, en voeg een nieuwe tabel toe die films aan genres koppelt. Die tabel bestaat uit niets anders dan een filmnummer en een genreid.

precies.. kun je bereiken met een crosstab query

[Verwijderd]

Verwijderd schreef op 24 oktober 2004 @ 14:23:
Jah oke maar nu dus weer het probleem , ik heb meerdere genreid's. Hoe ga je dan tewerk?

Cheatah geeft het probleem wel degelijk aan. Maar de oplossing ligt blijkbaar zo ver van de huidige toestand af dat het niet als oplossing herkend wordt.

Eerst normaliseren want queries werken alleen op genormaliseerde structuren.

[Verwijderd]

henkleerssen schreef op 24 oktober 2004 @ 14:26:
[...]

precies.. kun je bereiken met een crosstab query

met een kruisquery moet je toch 3 , ik heb alleen filmnr en genreid nu

[Verwijderd]

Misschien is de database niet helemaal mooi genormaliseerd maar je krijgt er heus wel de gevraagde informatie uit...als dit is wat je bedoelt tenminste:

code:

SELECT distinct  f.*
FROM Films f, genre g
WHERE f.genreid =(select genreid from genre where genre = 'Actie' and g.genreid = f.genreid) 
 or f.genreid2 =(select genreid from genre where genre = 'Actie' and g.genreid = f.genreid2) 
 or f.genreid3  =(select genreid from genre where genre = 'Actie' and g.genreid = f.genreid3);

Ik ga er dan wel vanuit dat er tabel "Films" en een tabel "genre" is.

[ Voor 11% gewijzigd door Verwijderd op 24-10-2004 15:13 ]

[Blizard]

Verwijderd schreef op 24 oktober 2004 @ 14:44:
[...]
met een kruisquery moet je toch 3 , ik heb alleen filmnr en genreid nu

Is eigenlijk een van de basisprincipes van relationele databases dacht ik.
Je hebt een veel op veel relatie (film heeft meerdere genres, maar een genre kan je toekennen aan meerdere films).

Dan maak je dus een derde tabel zoals hierboven al aangehaald werd.

Tabel1 = Film (prim key : filmID)
Tabel2 = GenrePerFilm (prim key : filmID, genreID)
Tabel3 = Genre (prim key : genreID)

Zo kan je op een eenvoudige wijze zoveel genres als je wil toekennen aan een film met een eenvoudige query. (mocht dit niet lukken laat je het gewoon ff weten)

[Verwijderd]

Blizard schreef op 24 oktober 2004 @ 15:46:
[...]

Is eigenlijk een van de basisprincipes van relationele databases dacht ik.
Je hebt een veel op veel relatie (film heeft meerdere genres, maar een genre kan je toekennen aan meerdere films).

Dan maak je dus een derde tabel zoals hierboven al aangehaald werd.

Tabel1 = Film (prim key : filmID)
Tabel2 = GenrePerFilm (prim key : filmID, genreID)
Tabel3 = Genre (prim key : genreID)

Zo kan je op een eenvoudige wijze zoveel genres als je wil toekennen aan een film met een eenvoudige query. (mocht dit niet lukken laat je het gewoon ff weten)

ik heb nu exact dezelfde tabellen als je hier aangeeft , ( nagemaakt ) en het werkt goed zolang het 1 genre is zodra het er 2 zijn kom ik er niet uit.
Wil je me uitleggen hoe die query eruit ziet?

[Verwijderd]

Je moet een kruistabel query maken:

[Blizard]

Kruistabel ? Voor dit probleem ?

Plaats ff je mail in je profile, dan stuur ik je een voorbeeldje van de database.
Of moet ik ze hier beter ff plaatsen ?!

[Verwijderd]

Blizard schreef op 24 oktober 2004 @ 19:29:
Kruistabel ? Voor dit probleem ?

Plaats ff je mail in je profile, dan stuur ik je een voorbeeldje van de database.
Of moet ik ze hier beter ff plaatsen ?!

m dat lwil ik wel graag ,uuhm

[e-mail]

bvd.:)

[ Voor 4% gewijzigd door Verwijderd op 25-10-2004 09:37 ]

[gorgi_19]

Blizard schreef op 24 oktober 2004 @ 19:29:
Of moet ik ze hier beter ff plaatsen ?!

Bij voorkeur graag publiek; dan kan de rest er ook over meediscussieren

[Verwijderd]

Dat viel weer niet mee. Met een kruistabel in MS-Access lukt het me via 3 queries. Waar is Oracle als je 'm nodig hebt . De kunst is lege genres mee te nemen en tegelijk de filtering op genre beperkt te houden tot 1 query.

De kruistabel-oplossing is de query prima als kale query te runnen. De aanpak heeft wel als nadeel dat het aantal Genres tot 256 beperkt is. Dit is namelijk de maximale breedte van de ADO-recordset.
Een andere aanpak zonder kruistabel is hier te vinden:
[rml][ MySQL/SQL] Selectie uit koppeltabel op meerdere specifiek *[/rml]
Deze komt op hetzelfde neer, is sneller en netter, maar kost wat meer programmeerwerk om in te bedden.

Mijn voorbeeld is met leveranciers en producten. Vertaling naar films en genres:
Leverancier --> Film
Product --> Genre

Stap 1: Bak een tabel van alle mogelijke categorieen: Cross Join.



Stap 2: Maak een overlap tussen alle categorieen en de vastgelegde categorieen in de tussentabel: Kruistabel met een Outer Join. Ik doe er ook direct een vertaalslag ID --> Naam bij.



Stap 3: Selectie uit de leverancier-tabel. De selectie hier: Alle leveranciers die wel bier verkopen maar beslist geen bronwater.

Deze query is te voorzien van parameters, maar dat maakt 'm wel gevoelig voor verandering in Genres. Gelukkig veranderen categorieen niet zo vaak .

[Creepy]

Verwijderd schreef op 24 oktober 2004 @ 23:35:
De kruistabel-oplossing is de query prima als kale query te runnen. De aanpak heeft wel als nadeel dat het aantal Genres tot 256 beperkt is. Dit is namelijk de maximale breedte van de ADO-recordset.

Eeeh... wat je hier zegt snap ik helemaal niks van?

Met een kruistabel maakt het aantal genres of het aantal films helemaal niet uit. Met behulp van 1 (of 2) joins kan je perfect met 1 query de genres aan films koppelen en andersom. (dus bijv. alle films van 1 genre opvragen).

Dus simpel gezegd:

films: ID, titel
genre: ID, Omschrijving
films_genre: filmID, genreID

En dan met een query ala:

code:

select * from films f
left join films_genre on filmid = f.id
where genre_id = 6

is de info perfect op te halen.

[Verwijderd]

Bij een kruistabel wordt een 2D-weergave gemaakt van een query. 1 as wordt daarbij omgezet in kolomkoppen. Hierop zit dan het maximum van 256 items. In mijn kruistabel zijn dit de genres.

De query is iets lastiger dan alleen maar films van 1 genre selecteren. Bv films die perse in 2 genres genres moeten vallen, of in tenminste 1 uit een lijstje van 5.

[Creepy]

Verwijderd schreef op 25 oktober 2004 @ 00:08:
Bij een kruistabel wordt een 2D-weergave gemaakt van een query. 1 as wordt daarbij omgezet in kolomkoppen. Hierop zit dan het maximum van 256 items. In mijn kruistabel zijn dit de genres.

De query is iets lastiger dan alleen maar films van 1 genre selecteren. Bv films die perse in 2 genres genres moeten vallen, of in tenminste 1 uit een lijstje van 5.

Ah. Ik ging er even vanuit dat een kruistabel hetzelfde zou zijn als een koppeltabel .

Ach. een minumum aantal is met count en having ook wel op te lossen. En films uit een lijste van 5 kan met IN en een subquery ook nog wel

[Blizard]

Verwijderd schreef op 24 oktober 2004 @ 22:21:
[...]
m dat lwil ik wel graag ,uuhm
[e-mail]
bvd.:)

Is op komst via mail (doe maar niet je email hier zo zetten ... vervang de @ door _at_ ofzo, maakt het al iets moeilijker voor de spammers).


Dit is wat ik ervan zou maken ? Iemand mee eens/oneens ? (nog een "tip" als je databases maakt,gebruik multipliciteit)

[jAnO!]

Blizard schreef op 25 oktober 2004 @ 09:24:
(nog een "tip" als je databases maakt,gebruik multipliciteit)

Ja gooi Acces uit het raam.

Zit hier toevallig net even "snel databaseje maken van flatfile, om snel te kunnen zoeken" te spelen met Acces, en in 10 minuten heb ik al 2 keer gehuild.
Wat een drama!

[Blizard]

jAnO! schreef op 25 oktober 2004 @ 10:23:
[...]


Ja gooi Acces uit het raam.

Zit hier toevallig net even "snel databaseje maken van flatfile, om snel te kunnen zoeken" te spelen met Acces, en in 10 minuten heb ik al 2 keer gehuild.
Wat een drama!

Kan je je probleem dan iets beter toelichten ?

[jAnO!]

Blizard schreef op 25 oktober 2004 @ 10:34:
[...]

Kan je je probleem dan iets beter toelichten ?

ja hoor:

!= werkt niet, is not werkt niet...
je moet kolomnamen prefixen etc.

grr!

(het gaat nu wel weer, heb de boel aangemaakt in oracle, 5 min verder weer blij..)

[Blizard]

jAnO! schreef op 25 oktober 2004 @ 10:44:
!= werkt niet, is not werkt niet...
je moet kolomnamen prefixen etc.

(het gaat nu wel weer, heb de boel aangemaakt in oracle, 5 min verder weer blij..)

Not Like "*age*" << geen films die age bevatten vb ?!
Prefixen kan toch ook in je voordeel spelen ?
En niet iedereen heeft thuis ff Oracle draaien (en lijkt me ook een beetje overkill voor een thuis-film-database )

[jAnO!]

me != TS

Voor een filmdatabase met één user is acces waarschijnlijk wel geschikt, maar als je over meerdere gebruikers gaat praten ...

[Creepy]

Blizard schreef op 25 oktober 2004 @ 09:24:
[...]
[afbeelding]
Dit is wat ik ervan zou maken ? Iemand mee eens/oneens ? (nog een "tip" als je databases maakt,gebruik multipliciteit)

Ik zou bij de koppeltabel als primary key het genreID & filmID nemen. Dan heb je ook geen los ID veld meer nodig, aangezien je die toch nooit zal gebruiken.

[pjotrk]

jAnO! schreef op 25 oktober 2004 @ 10:44:
[...]
ja hoor:
!= werkt niet, is not werkt niet...
je moet kolomnamen prefixen etc.

grr!

(het gaat nu wel weer, heb de boel aangemaakt in oracle, 5 min verder weer blij..)

uhmmz, != is in SQL altijd al <> geweest voorzover ik me kan herinneren

[Blizard]

Creepy schreef op 25 oktober 2004 @ 11:50:
Ik zou bij de koppeltabel als primary key het genreID & filmID nemen. Dan heb je ook geen los ID veld meer nodig, aangezien je die toch nooit zal gebruiken.

Er zijn mensen die inderdaad jouw mening volgen, heb al boeken gezien waar ze toch nog een uniek ID erbij plaatsen. Is een beetje persoonlijke mening lijkt me ? Ik denk dat het voor mensen die weinig met databases werken iets "normaler" overkomt wanneer er in die tabel óók nog een (automatisch aangemaakt) uniek-id staat.

-offtopic-
inderdaad, oracle etc heeft niet echt meer met het topic te maken Heeft de TS nu eigenlijk een antwoord gekregen op z'n vraag ?

[Verwijderd]

Creepy schreef op 25 oktober 2004 @ 11:50:
[...]

Ik zou bij de koppeltabel als primary key het genreID & filmID nemen. Dan heb je ook geen los ID veld meer nodig, aangezien je die toch nooit zal gebruiken.

ik heb het nu exact zoals Blizard, als je het losse id veld weghaalt kan je toch niet meerdere genres meer meegeven ?
Maar oke nu heb ik dit wel leuk maar nu wil ik het graag ook in het forumlier dat ik een nieuwe film aanmaak kan kiezen uit die films. Is dat makkelijk te realiseren ? zoals hieronder zegmaar maar dat ut dan ook werkt ? haha hier werkt het namelijk ff niet nog .

[ Voor 13% gewijzigd door Verwijderd op 25-10-2004 23:21 ]

[pjotrk]

Ik zou het persoonlijk ook doen zoals Creepy aangeeft, een extra kolom toevoegen aan een koppeltabel zou ik alleen doen als je wil dat een film meerdere malen eenzelfde genre kan hebben (wat mij in dit geval niet wenselijk lijkt).

De genres toevoegen aan de film moet wel eenvoudig te doen zijn. Wat werkt er nog niet aan dan (waar zit het probleem)?.

[Verwijderd]

nou dat het nog niet in het formulier draait . Wel al als query's

[Verwijderd]

Verwijderd schreef op 25 oktober 2004 @ 22:13:
[...]
ik heb het nu exact zoals Blizard ... haha hier werkt het namelijk ff niet nog .

Ik denk dat, alvorens je weer los gaat met MS-Access, het handig is dat je je eerst verdiept in normalisatie van gegevens. Volgens mij ontgaat je de discussie.

Kijk ook eens in een Access-boek bij subformulieren. Subforms zijn geknipt om een veel-op-veel relatie weer te geven.

[Verwijderd]

Och jah wat stom jah komt ik heb vorig jaar wel een applicatie met dit alles gemaakt maar ik ben verkeerd gegaan met normalisatie en sommige dingen kom ik niet meer op. Maar volgens mij moet het nu wel lukken met die subformulieren dat heb ik eerder gedaan. danku