itfag | Teknologi. Data. Læring. Deling.

CAT | Data og teknologi

mar/11

20

Studenter kan lage egne undersøkelser

Mange studenter har behov for å lage en spørreundersøkelse. Dette kan gjøres i læringsplattformen it´s learning: Lag et prosjektrom og du har da mulighet til å lage en undersøkelse som du kan sende til hvem du måtte ønske. Her er en liten videosnutt som viser hvordan det gjøres. Det er mange fordeler: raskt å lage en undersøkelse, den ser nogenlunde profesjonell ut, og ikke minst en god oppsummering av resultater (med mulighet til å eksportere til Excel og SPSS om en trenger mer avanserte analysemuligheter).

Håper videoen blir til nytte. Den kan ses i fullskjerm (er spilt inn i HD 720p). Egner dette seg til for eksempel prosjektarbeid? Har du erfaring med å lage undersøkelser? Er det nyttig?

Dette innlegget har Comments off. Gjerne bidra :-)

mar/11

16

Fremtiden: A day made of glass

Spennende video, høyst severdig… (takk til Tore Mallaug for tipset)

Hva tror du om fremtidens informasjonssystemer? Hvilken kompetanse trenger vi fremover? Kan dagens studier være nyttige for fremtidens systemer?

Dette innlegget har 2 kommentarer. Gjerne bidra :-)

mar/11

11

Hvordan presentere med iPad 1?

Av: Svend Andreas Horgen

Kan iPad brukes til produksjon? Effektivt arbeid? Læring? Tirsdag denne uken holdt jeg foredrag om god bruk av iPad på et frokostseminar i regi av NFF. Det var ca 25 deltakere. Her kan du først se presentasjonen (laget og fremført bare med iPad), og deretter lese noen forslag til hvordan en kan presentere noe med iPad på prosjektor (relevant for de som ikke har iPad 2).

Med den nye iPad 2 er det speiling av skjermen slik at du ser nøyaktig det samme på en prosjektor som på iPad 2. Det samme gjelder dessverre ikke på iPad 1. Der er det slik at det er opp til hver enkelt app å sende output til ekstern skjerm. Mange apper har ikke slik funksjonalitet, mens noen har det. Dette bidrar til å begrense nytteverdien til iPad som presentasjonsverktøy.

Hvordan løse dette problemet når du skal bruke iPad aktivt i for eksempel undervisning eller en foredragssituasjon? Det fins flere løsninger

Muntlig presentasjon: iPad kan holdes opp eller vises «over bordet». Dette fungerer ikke særlig bra med mer enn 2-3 deltakere

Presentasjonsprogrammer på iPad: Et presentasjonsprogram ala Keynote viser gjeldende lysark i fullskjerm på prosjektor. På iPad-skjermen kan den som presenterer for eksempel se forrige og neste lysark, en klokke etc. Det fins også andre apper som kan brukes til å presentere: Expedition og Mercury er eksempler på apper som viser nettleseren på prosjektor. Tankekart-appen iThoughts HD fungerer utmerket på prosjektor.

Dokumentscanner: En dokumentscanner som er koblet til en prosjektor gir god kvalitet. Da må iPad ligge i ro under scanneren, og alt du gjør projiseres på et lerret. Se videoen under og du ser at kvaliteten blir ganske bra

Med en dokumentscanner ser du faktisk også hendene til den som presenterer. Per Borgesen og jeg brukte denne teknikken under et foredrag vi holdt for Biblioteket ved Høgskolen i Sør-Trøndelag 4. mars. Slike scannere er ikke særlig utbredt, men jeg synes den fungerte utmerket fordi med hendene får du en ekstra følelse av realisme over det som vises.

Kreativ vri med Ustream og iPhone 4: Under presentasjonen på det ovennevnte frokostseminaret forsøkte jeg å være kreativ, siden de ikke hadde en dokumentscanner i NKI-lokalene (vi var hos NKI). Det fungerte bare halvveis bra, men kan være verdt å prøve:

  • Jeg satte opp iPhone 4 på et stativ av typen Gorilla Pod, og filmet iPad-en.
  • iPhone-appen «Broadcaster» fungerer opp mot den nettbaserte tjenesten «Ustream», og sender bilder rett ut på Internett. Alt du trenger er en gratis brukerkonto på Ustream.
  • Strømmen som sendes til Ustream kan så hentes tilbake igjen med en PC/Mac som er koblet til prosjektor. Ustream viser nemlig «live streaming» fra http://ustream.tv.

Ulempen er at det blir en forsinkelse på ca 5 sekunder fra du gjør noe, til bildet er tilbake og vises på prosjektoren. I tillegg er kvaliteten dårlig og det er ofte hakking i bildet (kanskje fordi en bruker samme nett til å laste opp som ned?)

Har du andre forslag eller erfaringer? Vil iPad 2 fungere med VGA, eller kun HDMI? Hvordan er det med andre nettbrett – har de like sære løsninger på dette området? Legg gjerne igjen en kommentar.

Dette innlegget har Comments off. Gjerne bidra :-)

Av: Svend Andreas Horgen, høgskolelektor og faglærer i blant annet PHP og Ajax

Blogginnlegget Layout med CSS, flere kolonner (del 1) presenterte designet på en webside laget i PhotoShop. Deretter analyserte vi i del 2 hvilke grunnelementer websiden er bygget opp av. Nå i siste del (3) skal vi arbeide oss fram til en fullstendig kode som fungerer (tilnærmet) likt i alle nettlesere. Det kan være lurt å gjenoppfriske det som ble sagt i disse to forutgående innleggene. Vil du gå rett på, så ser målet som vi prøver å realisere med CSS-kode, slik ut:

I forrige blogginnlegg brukte vi en div-boks for hovedinnholdet, og satte venstremargen til å starte på en pikselverdi som var litt mer til venstre enn den totale bredden på menu-div-en.

Et smart triks, og egentlig veldig logisk om en tenker firkantede bokser. Men – det blir feil. Menyen slutter for tidlig. Den skal gå helt ned like langt som innholds-diven er. Det er umulig å beregne høyden på forhånd (fordi innholdet på hver webside som bruker dette designet varierer i lengde). Hva gjør en da?

Svaret er å tenke innpakning. Ordet «to wrap» på engelsk betyr å pakke inn, og i dataverdenen sier vi gjerne at en «wrapper» er noe som er kledd utenpå noe. Hva er vitsen med det? Se først hvordan wrapperen ser ut:

Denne kan vi realisere med HTML-kode:

<body>
	<div id="header">
		Toppseksjon her
	</div> 

	<div id="wrapper-main-menu">
		<div id="menu">
		 - home <br /> 
		 - about <br /> 
		 - partners <br /> 
		 - bla bla <br />
		 - menu item <br />
		 - contact
		</div> 
		
		<div id="content">
			Innhold her: Lorem ipsum 
                       dolor sit amet... og så videre... 
		</div>
	</div>
</body>

En praksis som viser seg å være brukbar her, er å ikke tenke at meny-diven får farge, men at wrapperen får en bakgrunnsfarge! Ta følgende figur i betraktning

Smart! Hvordan realisere dette med CSS-kode? Trikset er bruken av background repeat-y i wrapperen #wrapper-main-menu. Den nye koden er uthevet i fet skrift.

#header {
	height: 100px; 
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 	
}

#content {
	margin-left: 175px; 
	padding-left: 30px;	
	padding-bottom: 20px; 
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 
}

#menu {
	float: left; 
	width: 161px; 
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 
}

#wrapper-main-menu {
	float: left; 
	margin-top:-10px;
	background:#FFF url("bitmaps/leftcolor_bg.png") 
                repeat-y top left; 
}

Her bruker vi bakgrunnsbildet «leftcolor_bg.png» til å fylle bakgrunnen i wrapper-diven. Bildet er 161 piksler i bredden (med vilje). Dermed blir menyen tilsynelatende 161 piksler bred. Dette passer godt med teksten vi har plassert i menu-diven som aldri kommer utenfor boksen sin (også den er 161 piksler). Det må ikke være match mellom tallene her, men det blir i hvertfall riktig om det er det.

Setter vi nå sammen HTML og CSS-koden, så ser vi at det stemmer så langt. border-style: dotted; er bare et triks for å se hvor div-boksene faktisk befinner seg, og skal slettes i den endelige løsningen. Bruk av repeat-y sikrer at bildet ikke bare vises én gang, men repeteres i vertikal retning (gjennom hele div-en). Hadde vi brukt repeat-x ville bildet blitt repetert i horisontal retning, og det ville vært feil her.

Nå er vi snart i mål. Se tilbake på originalfiguren, og du identifiserer følgende struktur:

Det blå i menyen er nå på plass. Hvordan få et tilsvarende rødt område ute til høyre? Merk at den røde er litt anderledes – den går helt fra toppen og til bunnen, mens den blå starter under headeren. La oss bruke samme triks som tidligere med å pakke inn div-ene i en wrapper. Det vi nå trenger er en ytre wrapper som faktisk pakker inn hele websiden, og så sette rød bakgrunn til høyre i denne wrapperen, og repetere bakgrunnen nedover i hele wrapper-diven. HTML-koden er nå ferdig, og ser slik ut (nye ting markert i fet skrift)

<body>

<div id="wrapper">

	<div id="header">
		Toppseksjon her
	</div> 

	<div id="wrapper-main-menu">
		<div id="menu">
		 - home <br /> 
		 - about <br /> 
		 - partners <br /> 
		 - bla bla <br />
		 - menu item <br />
		 - contact
		</div> 
		
		<div id="content">
			Innhold her: Lorem ipsum 
                       dolor sit amet... og så videre... 
		</div> <!-- end concent -->

	</div> <!-- end wrapper-main-menu -->
	
	<div id="nofloat"></div> 
	
</div> <!-- end wrapper -->

</body>

Den ytre wrapperen er grei, men hvorfor en div med id="nofloat"? Som du ser i CSS-koden har vi definert en ny regel som heter «nofloat» øverst. Det den gjør, er å kansellere float-egenskapen. Hvis ikke vil også wrapperen flyte. Hele CSS-koden er nå slik (nye ting i fet skrift):

/* Clear float */
#nofloat {
	clear: both; 
}


#wrapper{  					
	width:100%;
	background:#FFF url("bitmaps/rightcolor_bg.jpg") 
          repeat-y top right;	
	margin: 0px; 
}

#header {
	margin-right: 161px;
	height: 100px; 			
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 	
}

#content {
	margin-left: 175px; 
	padding-left: 30px;	
	padding-bottom: 20px; 
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 
}

#menu {
	float: left; 
	width: 161px; 
	border-style: dotted; 
	border-width: 2px; 
	border-color: blue; 
}

#wrapper-main-menu {
	float: left; 
	margin-top:-10px;
	margin-right: 200px; 	
	background:#FFF url("bitmaps/leftcolor_bg.png") 
           repeat-y top left; 
}

Igjen bruker vi trikset med å la et rødt bakgrunnsbilde repeteres i y-retning, denne gangen helt til høyre i hoved-wrapperen. Dermed skapes illusjonen om at vi har en rødfarget høyre kolonne («rightcolor_bg.jpg» er et rødt bilde på 161 piksler i bredden).

Husk at innholdet på siden ikke skal nå lengre bort enn ytterkanten av #wrapper-main-menu. Derfor er margin-right: 200px; valgt til nettopp 200. 200 er større enn bredden i høyre kolonne (rød bakgrunn har bredde 161 piksler). Slik blir det litt luft mellom teksten i hovedområdet og den røde kolonnen. Dette er både genialt og litt vrient på en gang. Det er en del baller å holde styr på, og det er lurt å utvikle gradvis med prøv og feil. Samtidig er det en logikk bak, og det er lurt å prøve å sette seg skikkelig inn i tankesettet og virkemåten til boksmodellen i CSS.

Er vi ferdige da? Nesten. Det gjenstår litt finpuss. Slik ser det ut nå i nettleseren Safari for Mac:

Hvis vi fjerner alle border-reglene vi har brukt som hjelp for å tydeliggjøre boksene, ser det enda bedre ut. I tillegg må bakgrunnen i toppen farges grå, og logoen skal tilsynelatende gå ned i hovedområdet. Men – også her kan en trikse det til med hendige bakgrunnsbilder og repeat-x-egenskapen. Du kan prøve selv på dette.

Håper dette var nyttig. Fins det andre, alternative måter å løse dette på? Eller har du spørsmål? Føl fri til å legge igjen en kommentar (ingen spørsmål er dumme).

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

mar/11

9

iThoughts HD for iPad

Mange studenter, lærere og andre har iPad (eller andre nettbrett). Vi starter nå en bloggserie med video av nyttige apper til iPad, myntet på både bruk i undervisning/læring, og for den som vil bruke iPad til mer enn bare konsumering av innhold. iPad er på ingen måte perfekt, men et steg inn i fremtiden og kan brukes til mye produktivt og nyttig arbeid.

iThoughts HD er en (meget god) tankekart-app for iPad. Tankekart kan brukes til mye. I denne videoen kan du se hvordan appen virker og få noen hint om hvorfor tankekart er smart, og hvordan du kan utnytte avanserte muligheter (se gjerne i HD, ingen lyd).
iThoughts HD egner seg spesielt godt i en studiesituasjon og til profesjonelt bruk som arbeidsverktøy.

Skal lage en del flere slike videoer fremover. Er dette god nok kvalitet til at det er nyttig? Har du forslag til apper som bør gjennomgås?

Dette innlegget har 13 kommentarer. Gjerne bidra :-)

Av: Svend Andreas Horgen, høgskolelektor og faglærer i Webprogrammering i PHP

Blir du av og til oppgitt over at tilsynelatende profesjonelle nettsteder slurver med sikkereheten? Her er et godt eksempel på regelrett slurv, og en utfordring til deg om å si hvorfor dette er slurv.

Flytoget er for meg noe av det beste Norge har å by på innen kommunikasjon. Websidene deres er brukervennlige. Informasjonen er lett tilgjengelig, en kan betale superraskt fysisk og få kvittering tilsendt på e-post om en registrerer e-posten sin på websidene deres. En kan til og med se all historikk om sine kjøp, og alt er tilsynelatende toppers. Flytoget oser sikkerhet, trygghet og effektivitet for de reisende. Bortsett fra en ting, etter min mening en alvorlig brist som gjør at en kan spørre seg om sikkerheten er der i det hele tatt?

De har nemlig slurvet veldig når det gjelder «glemt passord»-funksjonaliteten. Dette gjelder ikke bare Flytogets websider. Altfor mange seriøse nettsteder har slurvet her. Eller evt. aldri tenkt over problematikken?

Scenario:

  • Du vil logge inn og få oversikt over alle kjøpene dine
  • Du har glemt passordet (mange gjør vel det). Passordet ditt er «1234dummy» men det har du glemt bort akkurat nå.
  • Du trykker derfor «glemt passord», skriver inn e-postadressen din og får denne e-posten umiddelbart:

Her er vi ved kjernen. Kommentarfeltet er åpent. Du som er interessert i teknologi, programmering og sikkerhet, bør umiddelbart kjenne at nakkehårene reiser seg. Så jeg spør: Hva er feil her, og hvordan kan det løses? Hvorfor er dette så alvorlig? Det er mange grunner og momenter å ta opp her, så start brainstormingen!

PS til Flytoget om de leser dette: Ha meg unnskyldt – dere er fantastiske på alt annet enn «glemt passord» og dette blogginnlegget er ikke ment brukt for å spre negativ reklame om dere. Dere kan jo vri dette til positiv reklame om dere vil 😉

Dette innlegget har 11 kommentarer. Gjerne bidra :-)

mar/11

1

System for å samle inn bloggadresser

Av: Svend Andreas Horgen, høgskolelektor og faglærer i Webprogrammering i PHP

I forrige uke skrev jeg et blogginnlegg hvor jeg bad om innspill til hvordan en effektivt kunne samle inn bloggadresser fra for eksempel 20 studenter. Det kom mange kommentarer og gode tips (6 personer kommenterte på bloggen og en del andre på Twitter).

Idéene var gode, men selv om Etherpad, Google Docs og andre løsninger kan fungere veldig bra, så fikk jeg lyst til å programmere en løsning som gjør dette supereffektivt og så lavterskel som mulig for lærere. Problemet er bare at jeg ikke har tid. Hmmmmm, men i faget Webprogrammering i PHP skal jo studentene nå i vår løse en prosjektoppgave hvor de programmerer et webbasert system opp mot en underliggende database… Vi prøver å lage oppgaver som kan brukes i praksis, siden det er mer motiverende enn fiktive oppgaver. Tidligere semestre har prosjektoppgaven vært knyttet til ymse forskningsprosjekter. Denne gangen blir prosjektoppgaven altså knyttet til undervisningen vår.

Derfor lagde jeg i dag oppgaven slik: Lag et system for effektiv innsamling og administrasjon av bloggadresser i ulike fag. Her er en oppsummering av kravene til funksjonalitet i oppgaveteksten:

  • Systemet skal være webbasert og må ha en underliggende database hvor alle bloggadresser lagres.
  • Læreren skal kunne lage en ny lenke for et fag/semester. Denne lenken kan spres til studentene for eksempel gjennom it´s learning.
  • Studentene registrerer sitt navn, bloggens adresse, bloggens RSS-adresse, en beskrivelse av innholdet i bloggen og antatt frekvens for oppdatering.
  • Det kreves ingen innlogging for å registrere en ny blogg.
  • Med en gang en ny blogg er registrert, kan hvem som helst (som har lenken) se blogginformasjonen i bloggoversikten. Alle lenker er selvsagt klikkbare.
  • Det skal være mulig å velge hvor mye eller lite informasjon en vil se: Studentenes navn, adressen til bloggen, RSS-lenken, beskrivelsen og så videre.
  • Killer feature: Det skal være mulig å eksportere listen av bloggadresser som en OPML-fil. Dermed kan denne importeres rett inn i for eksempel Google Reader!

I tillegg er det lagt inn noen ekstra utfordringer til de ivrigste PHP-studentene, som er programmeringsteknisk mer vriene å løse.

Du tenker kanskje at dette var da mer tungvindt enn for eksempel Google Docs eller Etherpad. Nja, var det nå det? Tenk over de ekstra gevinstene. Et ferdig system gjør det superenkelt å sette i gang med blogging i et fag for en faglærer og lett å bruke for studentene. I rekkefølge skjer følgende:

  1. Læreren lager en ny lenke (et område) i systemet som er unik for denne studentgruppen (tar 20 sekunder)
  2. Læreren limer lenken inn i it´s learning slik at studentene kan bruke systemet (tar 20 sekunder)
  3. Studentene får beskjed (gjennom øvingsoppgaver) om å lage sin egen blogg og registrere adressen sin. Det tar ikke lang tid å registrere sin egen blogg (om en vet hvordan en finner tak i for eksempel RSS-lenken)

Deretter er det bare å besøke bloggene en vil til enhver tid. Enda bedre er muligheten for å importere rett inn i for eksempel Google Reader – dette er ikke mulig med mindre en har programmert systemet selv, og her er fordelen med å programmere selv helt tydelig. Jeg vil si terskelen bær være meget lav.

Jeg gleder meg til å både se de programmeringstekniske løsningene som studentene i faget Webprogrammering i PHP kommer opp med fremover, og jeg gleder meg til å teste ut systemet i de nettbaserte fagene IKT og læring og Enterprise 2.0 – Profesjonell bruk av nettet til høsten.

Har du forslag til andre nyttige ting som kunne vært med i oppgaven?

Dette innlegget har Comments off. Gjerne bidra :-)

feb/11

28

Den usynlige mannen << av Martin Bekkelund

Dette er en kopi av en bloggpost som Martin Bekkelund har publisert på sin blogg, og det handler om Datalagringsdirektivet.

Fordi teknologien er usynlig, abstrakt, komplisert og utformet av mennesker, er det få som reflekterer over at teknologi kan være noe negativt, til tross for at intensjonene kanskje er gode.

Det er mandag morgen, og du skal på jobb. Idet du kommer ut døra treffer du en velkledd mann i sort dress, hvit skjorte og et tynt, sort slips. Du ser på ham og han ser på deg gjennom et par store, mørke solbriller. I den venstre hånden holder han en notisblokk, i den høyre en penn. Han noterer noe på notisblokken og stikker den i lommen.

Når du går nedover veien legger du merke til at mannen følger etter deg, mens han stadig noterer på notisblokken.

Etter en stund har du fått nok og bestemmer deg for å konfrontere mannen med hans oppførsel. Hvorfor følger han etter deg? Og hva er det han noterer i notisblokken sin? Mannen gir deg et ignorant tusenmetersblikk gjennom de mørke solbrillene. Han svarer ikke.

Det du ikke vet er at mannen er fra politiet, og er et ledd i myndighetenes nye satsing for å forhindre terror og alvorlig kriminalitet. De skal overvåke alle mennesker, uansett om de har gjort noe galt eller ei, for å sikre seg beviser i tilfelle du skulle gjøre noe galt.

For oss som bor i et fritt samfunn hvor rettssikkerheten står sterkt høres dette helt usannsynlig ut. Vi ville aldri akseptert menn som følger etter og overvåker oss.

Problemet er at mannen allerede eksisterer. Men det er en liten forskjell på mannen beskrevet i denne historien og mannen som allerede eksisterer. Han er usynlig, og finnes foreløpig kun i EU. Mannen som overvåker oss er ikke en mann av kjøtt og blod, men en usynlig robot som samler inn informasjon om hvordan vi bruker våre elektroniske hjelpemidler. Hver gang du ringer noen er han der og noterer seg hvem du ringer, når du ringer og hvor du befinner deg når samtalen tas. Det samme når du sender SMS, e-post eller bruker internett. Og med en smarttelefon i lomma blir vi gjenstand for kontinuerlig overvåking.

Menn i mørke dresser og solbriller som overvåker oss i gatene er selvfølgelig uakseptabelt. Hvorfor skulle det være mer akseptabelt med samme overvåking bare fordi mannen er usynlig? Det er derfor du skal si nei til Datalagringsdirektivet som Arbeiderpartiet ønsker å innføre i disse dager.

Denne teksten er å anse som Public Domain. Hvis du misliker den overvåkingen Arbeiderpartiet legger opp til med Datalagringsdirektivet kan du kopiere denne teksten, publisere den på din egen blogg og oppfordre andre til å gjøre det samme.

Dette innlegget har Comments off. Gjerne bidra :-)

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 :-)

feb/11

23

Sosiale medier i vinden

Stadig flere bruker sosiale medier profesjonelt. Mange studenter ved Avdeling for Informatikk og e-Læring ved Høgskolen i Sør-Trøndelag gjennomfører bacheloroppgaver nå i vår. Det er flere som skriver om sosiale medier. En av studentgruppene holder for tiden på med en undersøkelse om mer profesjonell bruk av sosiale medier, hvor du kan bidra.

Hvordan bruker du sosiale medier? Anbefaler på det sterkeste at du går til studentgruppens blogg, ser videoen de har laget (som for øvrig er knallbra) og i tillegg fyller ut undersøkelsen. Hvorfor bruke tid på dette? Fordi:

  • Studentene trenger tilbakemelding for å kunne gjøre en god bacheloroppgave
  • Du kan få noen nye innfallsvinkler på sosiale medier gjennom å se på spørsmålene som stilles
  • Videoen er som sagt i seg selv verdt et besøk

Dette innlegget har Comments off. 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 :-)

feb/11

7

Hvorfor backup – Yesterdata

Du har mange viktige data. Backup er viktig. Tar du backup? Hvis ikke, så syng denne sangen (tekst under videoen)

(Melodi: «Yesterday», The Beatles)

Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.

Suddenly,
There´s not half the files there used to be,
And there´s a milestone hanging over me
The system crashed so suddenly.

I pushed something wrong
What it was I could not say.
Now all my data´s gone
and I long for yesterday-ay-ay-ay.

Yesterday,
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.

Dette innlegget har 1 kommentar. 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:

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 :-)

<< Latest posts

Older posts >>

Theme Design by devolux.nh2.me