DATABASE - MIN MUSIKSAMLING

Transkript

1 DATABASE - MIN MUSIKSAMLING I dette forløb skulle vi lære om databaser, som bruger sproget SQL. SQL står for Structured Query Language. Det bruges til at vise og manipulere data, gemt i en database. I vores klasse skulle vi egentlig lave en database, baseret på et E/R diagram, over en svømmehal, deres svømmehold, instruktørerne og deltagerne. Men jeg har fået lov til at lave det, med henblik på min musiksamling. Først skal det lige siges, hvad et E/R diagram er. E/R DIAGRAM E/R diagram står for Entitets/Relations Diagram, og er en måde at få et visuelt overblik over, hvordan en samling data, som passende kunne laves til en database, relaterer til hinanden, og hvordan det hele skal struktureres. Det fungerer nærmest som et avanceret mindmap, hvor man også får et overblik over situationen. I et E/R diagram, er der flere forskellige "symboler", som betyder forskellige ting. Denne tabel viser hvad de forskellige symboler: Symbol Eksempel Betydning Rektangel Ellipse Ellipse med understregning Dobbelt ellipse Rombe Linje Attribut Entitet En basal enhed Attribut en egenskab ved entiteten Primærnøgle en unik egenskab, for en entitet Flerværdi attribut som kan indeholde flere end én værdi Relation hvordan de forskellige entiteter spiller sammen Linje Forbinder de forskellige symboler Entitet - En overordnet enhed. Holdene, instruktørerne og deltagerne, i svømmehalen. Attribut - En egenskab ved disse entiteter. Det kunne være deltagernes navne. Primærnøgle - En unik egenskab, for hver entitet. Det kunne være deltagernes CPR-nummer. Flerværdi - En attribut der kan indeholde flere værdier. Relation - Hvordan de forskellige enheder spiller sammen med hinanden. Fx går deltagerne på et, eller flere, hold. Linje - Forbinder de forskellige symboler, i diagrammet, så man kan finde hoved og hale i det hele.

2 Men nu er det jo ikke svømmehallen det skal handle om. I hvert fald ikke her! Her skal det handle om min musiksamling. Først har vi mit E/R diagram, som beskriver min musiksamling, og det forskellige ting, som ligger inde under: Når dette diagram skal "oversættes" til data, og en database, kan vi se følgende: Da data opbevares i tabeller, ville det være smart at lave en tabel, for hver entitet, i diagrammet. Hver attribut kunne så få hver deres kolonne i tabellen. Så får vi også alle de oplysninger fra vores E/R diagram med. Eller, næsten i hvert fald. For der er lige det med relationerne. Når man skal "oversætte" til en database, kan man ikke rigtig kode en relation ind i databasen. Man kan til gengæld bruge det, så man selv kan overskue en større mængde data. Min database kommer derfor til at have 3 forskellige tabeller, som hver indeholder forskellige data. Men de relaterer alle til hinanden, dog ikke på et kodeplan. I hvert fald ikke endnu. De tre tabeller, kan ses i min database, som kan findes ude i venstre side, af hjemmesiden. For at kunne relatere dataen til hinanden, skal vi se på tabellerne og diagrammet sammen. Vi kan se i tabellerne, at der er en kolonne, der hedder Bands i alle tabeller. Det samme gælder for E/R diagrammet. Dette er en ting tabellerne har til fælles, noget der får dem til at relatere til hinanden. Men den ordentlige måde, hvorpå de forskellige tabeller kan spille sammen, er ved hjælp af SQL Queries.

3 QUERIES Queries er koder, der viser bestemte data. Det kunne fx være, at jeg ville vise alle bands, der havde et "a" i deres navn. Dette kan gøres med et query. I databasen har jeg vedlagt en del queries (som herfra vil blive omtalt, som forespørgsler). Disse kan bruges til at vise bestemt data. De har titel efter, hvilken data de viser, som "gennemsnitlig antal sange", der viser det gennemsnitlige antal sange på bandsenes plader. Denne forespørgsel ser sådan ud: SELECT Band, AVG( Antal_sange) AS Antal Sange FROM albums GROUP BY Band Dette ville printe en tabel, som ser sådan ud: gennemsnitlige antal sange Band Antal Sange Paramore 10 Coldplay 11 Linkin Park 13 Red Hot Chili Peppers 15 Jack Johnson 14 Foo Fighters 12

4 BRUGERGRÆNSEFLADE Men hvad er data, hvis det ikke kan vises? - Derfor skal der også laves en brugergrænseflade. Til dette formål, har jeg lavet en skitse over et meget simpelt interface, hvor man enten kan vælge en forespørgsel, eller lave sin egen. Jeg har brugt følgende principper, da jeg lavede denne brugergrænseflade: Keep it simple, stupid. Det var det. Jeg arbejder ud fra den filosofi, at simple ting, er nemmere at forstå, end komplicerede ting, og er ofte bedre, end komplicerede ting. Derfor er der kun få elementer på brugergrænsefladen: Nogle få tekstfelter, der fungerer som overskrifter En liste over forespørgsler Et tomt indtastningsfelt, hvor man kan indtaste sin egen forespørgsel 2 knapper, som eksekverer forespørgslen, og hiver dataen ud af tabellerne. Et resultatområde, hvor dataen kommer ud En guide, til hvordan man skal forstå dette interface, hvis det ikke er simpelt nok.

5 Dette burde være nok til, at brugeren forstår interfacet rigtigt. Tekstfelterne giver en overskrift med instrukser, mens guiden går mere i dybden, hvis det er nødvendigt. Samtidig med dette, er guiden altid ved hånden, da den ligger tæt på de andre elementer. TRE-LAGSMODELLEN Databaser består af tre lag: Data laget Logik laget Præsentations laget Disse tre lag har hver deres funktion i databaser, og spiller sammen derefter. Datalaget er hvor alt data er, altså tabellerne der indeholder værdierne. Præsentationslaget er der hvor dataen bliver vist. Logiklaget er det lag, der binder de to andre lag sammen. Det er laget hvor dataen bliver trukket ud af tabellerne i datalaget, og gjort klar, så præsentationslaget kan vise det. Et eksempel kunne være min database, med den forespørgsel der er blevet beskrevet i afsnittet Querries : Datalaget består af data fra albums tabellen, mens logiklaget er selve forespørgslen. Forespørgslen bearbejder så dataen, mens præsentationslaget nu viser, den bearbejdede data, i form af en overskuelig tabel. HVILKE FASER INDGÅR, I UDVIKLINGEN, AF ET NYT PRODUKT Der indgår følgende faser i udviklingen af nye produkter: Planlægning Kravspecifikation Design Implementering Afprøvning Først planlægger man, hvad produktet skal kunne, det kunne være et spil. Derefter går man i gang med, at finde ud af hvad kravene for produktet skal være, det kunne være, at det skulle kunne køres på flere styresystemer. Herefter designer man sit produkt, der kunne være at skitsere sit spil, og lave et storyboard. Så implementerer man det, altså koder spillet. Til sidst afprøver man spillet, for at se om der er fejl eller mangler. Hvis sidste fase afslører fejl eller mangler ved produktet, kigger man på trin 2-4 igen, indtil problemet er løst, hvorved man går videre til fase 5 igen. Dette fortsætter indtil produktet er færdigudviklet. Det kan dog diskuteres, om produkter nogensinde bliver færdigudviklet, eller om de bare er i konstant udvikling.