Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er siste del av bloggserien om JOIN, og vi skal nå se på CROSS JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN og del 3 om RIGHT OUTER JOIN. Del 4 handlet om FULL OUTER JOIN.

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, altså uten ordet JOIN i spørringen. 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. Dette er det samme som INNER JOIN (se bloggserien del 1) vil gjøre dersom man ikke har en seleksjon eller seleksjonen alltid resulterer til TRUE.

Eksempel på CROSS JOIN

For å illustrere dette bedre lager jeg to nye tabeller. En av disse tabellene er cross_test_1 som har kun én kolonne/attributt; numb. Denne tabellen inneholder følgende data: 1, 2, 3. Jeg har også en annen tabell med navn cross_test_2 som inneholder akkurat samme data.

Vi tester det ut:

Vi kan oppnå samme resultat med INNER JOIN (dersom seleksjonen mangler eller alltid resulterer i TRUE):

Noen ord helt til slutt

Da er artikkel-serien om forening i SQL over. Jeg vil takke for følget og håper dere har dratt nytte av disse innleggene. SQL er gøy, eller hva?

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 4 av bloggserien om JOIN, og vi skal nå se på FULL OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN og del 3 om RIGHT OUTER JOIN. Her er tabellene vi bruker i denne bloggserien:

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

Nå er det slik at hverken JavaDB eller MySQL støtter FULL OUTER JOIN, så jeg vil ikke få vist eksempel på resultat her. Resultatet ville i vårt eksempel være veldig likt RIGHT JOIN (fra del 3) bare med en ekstra tuppel, nemlig den uten registrert postnummer.

I siste del skal vi se på CROSS JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 3 kommentarer. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 3 av bloggserien om JOIN, og vi skal nå se på RIGHT OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN. Før vi går i gang må vi gjenoppfriske tabellene vi bruker i denne bloggserien:

RIGHT [OUTER] JOIN

RIGHT OUTER JOIN er i praksis veldig lik LEFT OUTER JOIN. Eneste forskjellen på disse er hvilken side vi vil favorisere. I en LEFT JOIN er det person som blir favorisert. Dersom vi derimot bruker RIGHT JOIN, på samme spørring, 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

Vi vil nå hente ut alle postnummer og personer som er knyttet til disse.

Som vi ser er det mange steder som ikke har noen personer knyttet til seg og verdiene vises med NULL. Som nevnt tidligere vil det komme flere tupler med samme postnummer dersom vi har flere personer knyttet til det samme nummeret. For å illustrere dette legger vil til en person til fra Eide (6490).

Dersom vi kjører forrige spørring igjen vil vi få ut dette:

I del 4 skal vi gå gjennom FULL OUTER JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 2 av bloggserien om JOIN, og vi skal nå se på LEFT OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN, mens RIGHT OUTER JOIN, FULL OUTER JOIN og CROSS JOIN kommer senere.

Du bør lese del 1 om du ikke har gjort det tidligere. Vi gjenoppfrisker kort tabellene som er utgangspunktet vårt i denne bloggserien:

LEFT [OUTER] JOIN

Nå beveger vi 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

Nå vil vi kun hente ut en komplett liste av alle personer vi har i databasen, uavhengig om de har registrert postnummer eller ei.

Klikk for større versjon

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. Her vil vi altså i motsetning til INNER JOIN også hente ut personene uten registrert postnummer.

Følg med i neste del hvor vi går gjennom RIGHT OUTER JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Som ingeniørstudent og tidligere veileder i både «LO171D Programmering i Java» og «LC238D Datamodellering og databaser» har jeg erfart at foreninger i SQL kan være noe vanskelig å forstå seg på. I den sammenheng kompilerte jeg en lengre tekst som konkret beskriver forskjellige måter å forene tabeller på etter SQL-standarden. Artikkelen er nå delt opp i en bloggserie på 5 deler. Først en introduksjon hvor vi tar opp INNER JOIN og NATURAL JOIN, og så mer avanserte foreningstyper i henhold til denne bloggplanen:

• del 2: LEFT OUTER JOIN
• del 3: RIGHT OUTER JOIN
• del 4: FULL OUTER JOIN
• del 5: CROSS JOIN (noen kjappe ord)

Noen ord om foreninger (JOIN)

En forening, eller JOIN som det heter i SQL, er en rasjonell operator på lik linje med utvelgelse av kolonner (projeksjon) eller rader (seleksjon) som skal vises. Det er en operasjon på relasjonsdatabaser som brukes til å koble sammen to eller flere tabeller i en database – gjennom en felles kolonne. Ofte vil det være primærnøkkelen og fremmednøkkelen som blir brukt som bindeledd, men det er også mulig å forene tabeller med bruk av andre felt.

I denne bloggserien kommer jeg til å bruke en rød tråd av eksempler. Det betyr at jeg tar utgangspunkt i de samme tabellene gjennom alle innleggene. Disse tabellene ser slik ut (på rasjonell form):

   postal_no(zip, place);
   person (pid, name, surname, address, zip*);

Vi vet at understrekede attributter er primærnøkler og de som er merket med en asteriks (*) er fremmednøkler. Zip-feltet i tabellen person er valgfritt (NULL). Vi har her sammenhengen en-til-mange.

Tabellen postal_no inneholder informasjon over alle postnummer i Norge og ser slik ut:

Tabellen person inneholder forskjellige personer:

INNER JOIN

INNER JOIN er nok en av de foreningene 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

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. Vi skal se mer på dette i eksempelet under.

I SQL vil INNER som regel være et valgfritt nøkkelord. Man kan med andre ord sløyfe det og kun skrive JOIN. Mange mener videre at det er god praksis å ha med nøkkelordet for å lettere tolke spørringene når man leser de.

Eksempel på [INNER] JOIN

Dersom vi nå vil sende ut et brev til personene vi har i databasen vår må vi hente ut en liste av personer med registrert adresse. Som vi vet er zip et NULL felt i tabellen person, så det er ikke alle personer som har registrert adresse til seg. Vi bruker INNER JOIN med seleksjon for å vise til hvilke felt som skal brukes til å knytte dataene sammen.

Klikk for større versjon

Vi kan også skrive dette på en alternativ måte.

Klikk for større versjon

Hva som vil skje dersom man ikke bruker seleksjon her vil vi få vite mer om i blogginnlegget «del 5: CROSS JOIN».

Om vi husker fra utlistingen av personer ovenfor vet vi at det er 3 innlegg i denne tabellen, mens her er det 2. 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. Merk videre at vi får skrevet ut kolonnen zip to ganger. Dette er en gang for postal_no og en gang for person.

NATURAL JOIN

NATURAL JOIN er i all basis det samme som en INNER JOIN. Eneste forskjellen er at vi fjerner duplikatkolonner. Som påpekt i slutten av forrige avsnitt vil vi få frem zip-kolonnen to ganger med bruk av INNER JOIN (uten projeksjon). NATURAL JOIN vil skrive ut kun en kolonne for alle par av kolonner med samme navn.

Eksempel på NATURAL JOIN

Klikk for større versjon

Vi ser her at ZIP kommer kun ut som en kolonne. Desverre støtter ikke JavaDB NATURAL JOIN. Så da må man supplementere med en projeksjon:

Klikk for større versjon

Se bort i fra USING() her. Den er brukt for å korte ned SQL-spørringen. USING() kan bli brukt siden begge attributtene har samme navn i disse tabellene. Så det blir en slags snarvei for ON field = field2

Følg med på neste del når vi tar for oss LEFT OUTER JOIN. Bruker du SQL i praksis? Hva synes du om foreninger? Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)