Denne artikkelen baserer seg mest på SQL-standarden (Oracle), men kommer også til å komme med innstikk dersom forskjellige metoder ikke fungerer i MySQL, da jeg går ut i fra at denne dialekten er den mest brukte her på forumet, men tror ikke det skal bli noe problem.
Noen ord om forening (JOIN)
En forening, eller JOIN som det heter på engelsk, er en rasjonell operator på lik linje som utvelgelse av kolonner eller rader som skal vises. Det er en operasjon på relasjons-databaser som brukes til å koble sammen to eller flere tabeller i en database - igjennom en felles kolonne. Dersom man bruker MySQL og InnoDB vil det som regel være primærnøkkelen og fremmednøkkelen som blir brukt som bindeledd.
Et lite eksempel på hva man kan oppnå med forening.
Jeg har to tabeller. Den ene inneholder personer i et register, den andre inneholder postnummer og poststed. Det jeg vil oppnå er å liste ut alle personer med tilhørende poststed. Tabellene ser slik ut (bruker relasjonell form).
person (person_id, name, zip_code*); postal (zip_code, post_place);
De som er understreket er primærnøkler og * markerer en fremmednøkkel. Dette er hva vi kaller en en-til-mange relasjon. For å hente ut ønsket info kan jeg bruke denne spørringen.
SELECT t1.name, t2.post_place FROM person t1 INNER JOIN postal t2 ON t1.zip_code = t2.zip_code;
Nå som vi har fått unna et kjapt eksempel kan vi gå over til hvilke forskjellige foreningsmetoder vi har og når vi vil bruke de.
De jeg kommer til å gjennomgå er
- INNER JOIN og NATURAL JOIN
- LEFT OUTER JOIN
- RIGHT OUTER JOIN
- FULL OUTER JOIN
- CROSS JOIN (noen kjappe ord)
INNER JOIN
INNER JOIN, med LEFT/RIGHT JOIN, er nok den foreningen som kommer til å bli brukt mest. Det er noe som kalles equijoin, og betyr rett og slett at man henter ut informasjonen bundet sammen av to felles verdier i en kolonne/attributt. Kodene ovenfor er et eksempel på denne typen forening.
Det som gjør INNER JOIN forskjellig fra noen OUTER JOIN (som LEFT/RIGHT) er at vi henter kun ut de radene (også kalt «tupler») som har verdier i begge de kolonnene som vi forener om. Om vi viderefører eksemplet ovenfor vil dette si at kun personer med poststed og kun poststedene med personer i seg blir hentet ut. Vi får ikke listet ut alle poststedene som ikke er bebodd av noen medlemmer i person-tabellen vår, og vi får heller ikke listet ut personer som ikke har noe poststed registrert.
Eksempel på INNER JOIN finner har jeg allerede skrevet i toppen av artikkelen.
NATURAL JOIN
NATURAL JOIN er i all basis det samme som en INNER JOIN. Eneste forskjellen er at vi fjerner duplikatkolonner. Vi ser at både postal- og person-tabellene inneholder zip_code kolonnen. Dersom vi henter ut alle felt med en vanlig INNER JOIN vil begge disse hentes ut. Det er naturlig at vi ikke trenger denne informasjonen to ganger. Det er sløsing med dataplass/minnebruk. Dersom vi bruker projeksjon (en relasjonell operator som tillater oss å velge hvilke kolonner vi vil ha ut - f.eks SELECT field1, field2 [...]), er det ikke nødvendig med NATURAL JOIN.
Eksempel på NATURAL JOIN
SELECT * FROM person t1 NATURAL JOIN postal t2 ON t1.zip_code = t2.zip_code;
LEFT OUTER JOIN
Nå har vi beveget oss ut på ytterforening. I motsetning til INNER JOIN vil en LEFT OUTER JOIN favorisere en side av tabellene. Det er fortsatt en såkalt «equijoin». Relatert til det eksemplet vi har brukt tidligere vil det bety at vi kan hente ut alle postkodene uavhengig av om de har personer registrert til seg eller ikke - eller motsatt; alle personer uavhengig om de har registrert postkode.
Her er OUTER et valgfritt nøkkelord i spørringen. LEFT JOIN er såvidt jeg vet det samme som LEFT OUTER JOIN.
Eksempel på LEFT [OUTER] JOIN
Jeg vil hente ut alle personer og dersom de har registrert poststed vil jeg også vise disse.
SELECT t1.name, t2.post_place FROM person t1 LEFT JOIN postal t2 ON t1.zip_code = t2.zip_code;
Du ser her at tabellen person er den tabellen som står etter FROM-nøkkelordet. Dette gjør den til en venstrestilt tabell, og det er den vi favoriserer ved å bruke LEFT JOIN.
RIGHT OUTER JOIN
RIGHT OUTER JOIN er i praksis veldig lik LEFT OUTER JOIN. Eneste forskjellen på disse er hvilken side vi vil favorisere. Vi ser av forrige punkt om LEFT JOIN er det person som blir favorisert. Dersom jeg bruker RIGHT JOIN er det postal-tabellen som blir hovedtabellen. Resultatet vil være en tabell over alle postkoder og tilhørende personer som er registrert. Siden vi ikke grupperer vil vi få flere resultater av samme postkode, da «tuplene» er av forskjellige kombinasjoner (forskjellige personer til samme postkode).
Eksempel på RIGHT [OUTER] JOIN
Jeg vil hente ut alle postkoder og dersom de har registrert personer vil jeg også vise alle disse.
SELECT t1.name, t2.post_place FROM person t1 RIGHT JOIN postal t2 ON t1.zip_code = t2.zip_code;
FULL OUTER JOIN
Siden dette også er en OUTER JOIN kan vi kanskje se for oss hva vi kommer til å få. Dette er en ytterforening som ikke favoriserer noen side. Den kommer til å vise poststeder med og uten personer og personer med og uten poststed.
Eksempel på FULL OUTER JOIN
SELECT t1.name, t2.post_place FROM person t1 FULL OUTER JOIN postal t2 ON t1.zip_code = t2.zip_code;
CROSS JOIN
Denne foreningen er litt anderledes enn de vi har sett på til nå. På norsk kalles dette gjerne kryssprodukt eller kartesisk produkt. Her har vi en forening uten noe nøkkelord som JOIN. Vi bruker rett og slett flere tabeller adskilt av komma etter FROM. Uten noe seleksjon (i praksis WHERE-nøkkelordet) vil dette gi alle mulige kombinasjoner av de to tabellene sammenlagt.
Eksempel på CROSS JOIN
Jeg har en tabell med navn tabell1 som har kun én kolonne; tall. Denne tabellen inneholder følgende data: 1, 2, 3. Jeg har også en tabell til med navn tabell2 som inneholder akkurat samme data.
Dersom jeg da kjører følgende spørring:
SELECT * FROM tabell1, tabell2;
Vil resultatet være følgende:
[ tall | tall ]
[ 1 | 1 ]
[ 1 | 2 ]
[ 1 | 3 ]
[ 2 | 1 ]
[ 2 | 2 ]
[ 2 | 3 ]
[ 3 | 1 ]
[ 3 | 2 ]
[ 3 | 3 ]
Referanser
Jeg er særdeles dårlig på norske uttrykk når det gjelder programmering og lignende. Derfor har jeg fått hjelp av boka [i]Databaser[/i] som er skrevet av Kjell Toft Hansen og Tore Mallaug.