Trodde IT1 skulle være "walk in the park", mangler jeg logisk sans?

[Mangelfull]

Hallo.

 

Jeg har tidligere hatt fag som fysikk og kjemi med strålende resultater, og nå tar jeg IT1(vgs nivå). Har sittet timesvis med databaseoppgaver og prøver å forstå logikken bak disse. Men hver gang jeg gjør en oppgave, har jeg gjort den feil, enten fordi jeg ikke har forstått konteksten eller fordi oppgaven spurte om noe annet.

 

Læreren sa det er mange som får femmere og seksere, må bare være jeg som er logisk-tilbakestående da? Er en av veldig få som møter opp etter timen (leksehjelp)...

 

Jeg prøver i all hovedsak å forstå konseptet om hvordan databaser fungerer. Hvordan kan man bli flink i dette?

 

Eksempler:

 

Fasit

 

- Lurer på hvordan himmellegme kan være fremmednøkkel her? Jeg ville tenkt meg at Planet og måne respektivt ville vært fremmednøkler, men her er det tydeligvis bare en fremmednøkkel som jeg er usikker på hvor peker.

 

 

 

Endret 23. mars 2019 av Mangelfull

[cuadro]

En fremmednøkkel peker på en nøkkel i en annen tabell, eller, den er en nøkkel i en annen tabell.

 

Når du utfører en observasjon, så er den enten av en måne, eller en planet. Navnet på denne planeten eller månen, er da himmellegemet du observerer.

[Mangelfull]

En fremmednøkkel peker på en nøkkel i en annen tabell, eller, den er en nøkkel i en annen tabell.

 

Når du utfører en observasjon, så er den enten av en måne, eller en planet. Navnet på denne planeten eller månen, er da himmellegemet du observerer.

Men her peker himmellegeme-nøkkelen på to tabeller? En fremmednøkkel kan jo bare peke på en primær nøkkel i en annen tabell?

Eller er det slik at dersom det observeres en måne vil nøkkelen peke mot primærnøkkelen i månetabellen , eller dersom det observeres en planet vil nøkkelen peke mot primærnøkkelen i planet-tabellen?

Endret 23. mars 2019 av Mangelfull

[cuadro]

Du skjønte det selv.

 

Fremmednøkkelen "himmellegeme" er et tekstfelt som må samsvare med et tekstfelt i enten måne-tabellen eller planet-tabellen.

[MrL]

Vel, jeg kan ihvertfall si at jeg aldri hadde laget en tabell med himmellegeme på den måten, det blir jo bare rot. Mest sannsynlig hadde jeg bare hatt 2 observasjontabeller, en for Måne og en for Planeter. Videre hadde jeg aldri brukt et navn som unik nøkkel, men heller et unikt nummer.

 

Jeg slet også veldig med å forstå databaser, og det er kanskje rart med det - men definisjonene som "Fremmednøkkel" og "En til mange relasjoner" osv forverret egentlig bare alt for meg, og det er i grunn bare ord. Når jeg begynte å se på databaser uten å se på koblinger og ord, forsto jeg det. 

 

Glem alle datatyper, koblinger - og se alle tabeller som ren tekst. For det er det en tabellene egentlig er, det er ingenting som reelt kobler de sammen - det er bare selvstendige tabeller med tekst.

 

Det vi gjør er å ha en rad med referanse til riktig sted. Jeg kan kalle den raden "PlanetID", "MåneID" eller hva jeg vil - det spiller ingen rolle. Tallet som står der blir bare et sidetall i en bok, og jeg må vite hvilken bok jeg skal slå opp den siden i. Derfor velger jeg kanskje "PlanetID" hvis det er planettabellen(Eller kall den en bok) jeg skal slå opp i. Da forsto jeg hvor enkelt det egentlig er. Derfor er nettopp himmellegeme et dårlig måte å gjøre det på her, fordi du vet ikke hvilken bok/tabell du skal slå opp i. Dette høres kanskje rart ut, og jeg vet ikke om det i det hele tatt ga mening - men jeg har faktisk noen jeg kjenner har også opplevd det samme, sett på det på samme måte - uten at vi helt kanskje klarer å forklare det hvorfor vi forsto det da. Men jeg vil ihvertfall anbefale deg å prøve å gjøre det samme, så kanskje du forstår databaser bedre. 

Endret 23. mars 2019 av MrL

[nightowl]

Klønete fasit, så godt mulig læreren selv ikke har skjønt alt og derfor bedriver vranglære. Er pensumbok og eller lærer dårlig på å lære bort må man finne seg noe bedre. Hadde det vært meg ville jeg valgt en engelsk lærebok via Amazon, hvor man da velger og vraker mellom de som er mest anbefalt.

[Mangelfull]

Vel, jeg kan ihvertfall si at jeg aldri hadde laget en tabell med himmellegeme på den måten, det blir jo bare rot. Mest sannsynlig hadde jeg bare hatt 2 observasjontabeller, en for Måne og en for Planeter. Videre hadde jeg aldri brukt et navn som unik nøkkel, men heller et unikt nummer.

 

Jeg slet også veldig med å forstå databaser, og det er kanskje rart med det - men definisjonene som "Fremmednøkkel" og "En til mange relasjoner" osv forverret egentlig bare alt for meg, og det er i grunn bare ord. Når jeg begynte å se på databaser uten å se på koblinger og ord, forsto jeg det. 

 

Glem alle datatyper, koblinger - og se alle tabeller som ren tekst. For det er det en tabellene egentlig er, det er ingenting som reelt kobler de sammen - det er bare selvstendige tabeller med tekst.

 

Det vi gjør er å ha en rad med referanse til riktig sted. Jeg kan kalle den raden "PlanetID", "MåneID" eller hva jeg vil - det spiller ingen rolle. Tallet som står der blir bare et sidetall i en bok, og jeg må vite hvilken bok jeg skal slå opp den siden i. Derfor velger jeg kanskje "PlanetID" hvis det er planettabellen(Eller kall den en bok) jeg skal slå opp i. Da forsto jeg hvor enkelt det egentlig er. Derfor er nettopp himmellegeme et dårlig måte å gjøre det på her, fordi du vet ikke hvilken bok/tabell du skal slå opp i. Dette høres kanskje rart ut, og jeg vet ikke om det i det hele tatt ga mening - men jeg har faktisk noen jeg kjenner har også opplevd det samme, sett på det på samme måte - uten at vi helt kanskje klarer å forklare det hvorfor vi forsto det da. Men jeg vil ihvertfall anbefale deg å prøve å gjøre det samme, så kanskje du forstår databaser bedre. 

Det var slik jeg gjorde det

Lette å tenke praktisk, slik du sier.

 

Klønete fasit, så godt mulig læreren selv ikke har skjønt alt og derfor bedriver vranglære. Er pensumbok og eller lærer dårlig på å lære bort må man finne seg noe bedre. Hadde det vært meg ville jeg valgt en engelsk lærebok via Amazon, hvor man da velger og vraker mellom de som er mest anbefalt.

Lærer ikke så mye i timen, så jeg har tydd til nettet. Så litt på ulike bøker, er det noen du anbefaler spessielt?

 

Her er en annen oppgave. Hvordan får de "priser" i midten?

Oppgave

Fasit:

 

 

 

Endret 23. mars 2019 av Mangelfull

[nightowl]

Lærer ikke så mye i timen, så jeg har tydd til nettet. Så litt på ulike bøker, er det noen du anbefaler spessielt?

 

Nei, husker ikke navnet på noen, er en stund siden sist.

 

EDIT: Min 2-minutters løsning:

Læreren din gjør det unødig komplisert syns jeg, da dette er innføringskurs. Mye ID-er overalt som ikke trengs. Til og med hele tabeller som gir unødig kompleksitet.

Endret 23. mars 2019 av nightowl

[Mangelfull]

Nei, husker ikke navnet på noen, er en stund siden sist.

 

EDIT: Min 2-minutters løsning:

Læreren din gjør det unødig komplisert syns jeg, da dette er innføringskurs. Mye ID-er overalt som ikke trengs. Til og med hele tabeller som gir unødig kompleksitet.

Det er sånn jeg også gjorde det. Men når jeg ser fasiten blir jeg utrolig skuffet, og det føles ut som om jeg ikke har kontroll over stoffet.

Nesten alle oppgavene er sånn.

[nightowl]

Kan ikke kalles fasit, men i stedet løsningsforslag. Er flere måter å gjøre det på.

[Visum]

Husk at det er ingen "fasit" når det gjelder modellering av databaser. I stedet snakker vi om løsningsforslag, da det er mange måter å løse problemet på. 

 

Les mer om normalisering av databaser. Første og andre normalform bør oppfylles.

[Mangelfull]

Kan ikke kalles fasit, men i stedet løsningsforslag. Er flere måter å gjøre det på.

Er snart halvveis i en utrolig bra engelsk lærebok jeg leser(257 sider), som jeg fant på amazon. Den har lært meg mye  om databaser hittil og jeg begynner å få en forståelse for hvordan databaser fungerer, enn et bare skolebokeksempel uten noen særlig ide om hvorfor ting er slik de er.

 

Før forstod jeg ikke hvorfor vi hadde en til mange forhold, mange til mange, og hvilke problemer det kan skape dersom en får feil forhold. For eksempel, hvis en person tilhører en fotballklubb og det er 1-M (Person (1) ---> Klubb(M) )forhold. Da vil man bare kunne lagre nåværende data, det vil si, dersom spilleren endrer lag vil tidligere data gå tapt. Men for å lagre historisk data må vi ha en ny kolonne og et mange til mange forhold.

 

En lettelse å forstå !

Endret 24. mars 2019 av Mangelfull

[cuadro]

Da ser du kanskje en svakhet ved nightowls 2-minutters løsningsforslag over. Husk å håndter mange-til-mange-relasjoner riktig.

 

https://fmhelp.filemaker.com/help/17/fmp/en/index.html#page/FMP_Help/many-to-many-relationships.html

[nightowl]

*snip*

 

Med kvalitetslæremateriell blir læring morsomt i stedet for frustrerende. Bra jobba. 

[Mangelfull]

Da ser du kanskje en svakhet ved nightowls 2-minutters løsningsforslag over. Husk å håndter mange-til-mange-relasjoner riktig.

 

https://fmhelp.filemaker.com/help/17/fmp/en/index.html#page/FMP_Help/many-to-many-relationships.html

Har ikke sett på den enda. Men da jeg gjorde den ga jeg opp, og la min lit til Nightowls pga mangledene kunnskaper.

Skal se på den senere

 

Med kvalitetslæremateriell blir læring morsomt i stedet for frustrerende. Bra jobba. 

Visste ikke før hvordan man skulle strukturere tabellene, og her får jeg vite at en ikke kan strukturere de i alle retninger. Altså slik jeg gjorde før.

 

Jeg er sånn som må forstå hele bilde før jeg starter på noe.

 

 

Endret 24. mars 2019 av Mangelfull