Database + Film Film: https://vimeo.com/183223676 Portfolier: Benjamin: http://benjaminheiden.dk/projekter/projekt-8/ Alexander: http://alexklug.dk/videoogdatabase Simone: René: http://www.simonet.dk/ http://slack.dk/portfolio/3-semester/ projekt-1-video-database/ SQL Mateen: http://www.matweb.dk/ Meta: Metaemilie.dk
Indholdsfortegnelse 2. Indledning 3. Planlægning 4. 5. 6. 7. SCRUM Database/ER-Diagram ER-Diagram/Normalisering Dramaturgi 8. 9. 10. 11. 12. 13. 14. Ide & Koncept Storyboard Filmtekniske Virkemidler Animation Videoredigering Konklusion Bilag
Indledning I vores første projekt database + video har vi skulle lave et ER-diagram for en database, sammen med 1-3 nf (normal form) og en video der forklarer hvordan en database fungerer til en målgruppe som er andre multimediedesignere. Den skal være letforståelig og publikum skal ikke miste fokus eller interesse. Vores læringsmål for dette projekt var at finde ud af hvad en ER-model indeholder samt at planlægge et større projekt med project backlog og daglige SCRUM møder. I video delen skulle vi lære om dramaturgi, lave et storyboard og enten have 3D eller animation med. Vi valgte at lave animation, da vi hurtigt kom i gang med en idé. Vi delte video delen og database delen op imellem os da det var to større projekter for sig selv, samlet i en opgave. Da database delen var hurtigere at lave var vi alle med om at filme. De daglige SCRUM møder har gjort at vi har holdt os opmærksomme på de opgaver vi har stillet os. Og at vores tidsplan ikke er blevet overskredet Igennem vores rapport dokumenterer vi hvordan vi er kommet frem til vores endelige film og det arbejde vi hver især har udført igennem dette projekt.
Planlægning I dette projekt benyttede vi os af projektstyringsværktøjer i Excel. Der var både et Burn Down kort, en planlægningsdel og en Sprint Backlog Burndown, hvor tidsrammen var sat vha. trepunktsestimering. Det fungerer således, at man skriver selve opgaverne, man skal lave, ind under planlægningsdelen. Derefter kalkulerer man med antal personer, som arbejder på opgaven, samt estimerer hvor lang tid man forventer, at det vil tage ud fra trepunktsestimering en teknik til at beregne sig frem den mest sandsynlige arbejdstid. Vi skulle lave to Product Backlogs, en over planlægningsarbejdet samt databasen, og en over videoen. Vi startede med at brainstorme alt det, vi kunne komme i tanke om mht. til opgaven. Der var mange ting vi skulle huske, lige fra at tegne de figurer, vi skulle animere, til at finde værdierne der skulle ind i attributtabellen. Da vi fik til opgave at dele vores projektplan op i to sprints, en over videoen og en over databasen, valgte vi at dele os op på de to opgaver, således at vi var to på databasedelen og fire på videodelen. Dels fordi at det er svært at sidde 6 mand om en database, men også for at vi godt kunne se, at databasedelen hurtigt var overstået. Som man kan se på projektplanen, havde vi delt hvert sprint op i 9 dage, men det viste sig hurtigt, at database + planlægningssprintet kun tog 4 dage. Derefter arbejdede vi alle sammen på videodelen. der skulle laves derhjemme. Derfor havde den person, der var syg, svært ved at lave noget. Det skabte også en del fnidder i gruppen hvorvidt skulle personen ud af gruppen eller blive. Set i bakspejlet var denne konflikt meget unødvendig, men samtidig også meget lærerig. Der kom også som næsten altid i et projekt uforudsete forhindringer, så det gjorde, at vi i gruppen måtte arbejde lidt ekstra end de 4 timer, vi havde sat på som daglige arbejdstimer. Men med lidt mere slid end forventet nåede vi også i mål. Vores optimistiske værdier viste sig dog at holde godt stik på mange af tingene, og vi blev hurtigt færdige med databasen. De baggrunde og figurer (animationer), vi skulle tegne, gik også som smurt, men mere kompliceret blev det, da vi skulle filme, fordi at kameraet ikke helt ville fungere som vi havde håbet. Bl.a. tog det en del længere tid at filme scene 4, hvor vi skulle zoome ind på skuespillerens øje, fordi at kameraet mistede hele tiden fokus, når vi prøvede at bevæge det. Det endte også med, at vi måtte lave om på det, da teknikken simpelthen ikke var til at lave den oprindelige idé.
SCRUM Som en del af opgaven var det også påkrævet, at vi holdte daglige SCRUM-møder. Det brugte vi 30 minutter på om dagen. Det var ikke alle dage hvor vi mødtes, men så havde vi i gruppen indbyrdes aftalt, hvad vi skulle lave til næste møde. Selvom vi ikke mødtes, skrev vi altid til hinanden på vores gruppe-chat på Facebook hvor langt vi var, og hvor mange timer vi havde igen. Så stod en i gruppen for at opdatere Backloggen dagligt, typisk når alle havde skrevet ved en 21 tiden. SCRUM-møderne var rigtig gode for gruppen, fordi vi hele tiden havde overblik over hvor langt vi var i processen. Havde den ene problemer, kunne vi hurtigt hjælpe til, i stedet for at der måske var gået et par dage, for vi snakkede om projektet. Selvom nogle var syge, var vi gode til hele tiden at vide, hvor langt vi hver især var med vores opgaver, takket være de daglige samtaler, hvor vi hele tiden kunne opdatere hinanden. Se Bilag 1-2
For at bygge en database, som opfylder alle de bruger-definerede krav der er nævnt fra virksomhedens side, skal vi først opdele alle oplysninger i kategorier eller tabeller med beskrivelsen af forskellige attributter i. Derefter organiserer man de tabeller i en datamodel, som hedder ER-diagram for at hjælpe til at øge samhørigheden i mellem data i tabellerne. Denne proces hedder normalisering af data og bruges til at reducere og fjerne data redundans. Dette gøres for at undgå at have samme oplysninger flere forskellige steder i databasen. Der kan være flere normaliseringer eller normal forms (NF): 1. NF, 2. NF og 3. NF, som viser data optimerings niveauet. Jo større er et nummer foran NF, jo mere optimeret er det tilsvarende data skema. Det er altid bedst at normalisere ER-diagrammet således at det svarer til 3. NF, og det gør vi i dette projekt. ER-Diagram Når man laver et ER-diagram, er det for at planlægge og optimere sin databasestruktur bedst muligt. Oplysningerne opdeles i forskellige tabeller, hvor man definerer hvilken datatype man bruger til de forskellige rækker. Der findes flere forskellige datatyper, som fx INT (Integers, som bruges til tal), VARCHAR (bruges til tekst) og ENUM (bruges i situationer, hvor man får præsenteret forskellige valgmuligheder). Dette er kun nogle få eksempler ud af mange forskellige datatyper. I ER-diagrammet kigger man på hvilke relationer der er imellem de forskellige tabeller, og hvilken slags relation det er. Der findes 2 forskellige relationer. Identifying relation og Non-Identifying relation. Identifying relation er hvis en række i en child tabel afhænger af en række i parent tabellen. Dvs. at hvis child tabellen indeholder data fra parent tabellen, kan rækken i child tabellen ikke eksistere, hvis der ikke er data i parent tabellen. Non-Identifying relation er hvor den Primary key fra parent tabellen ikke er nødvendig for at rækken i child tabellen eksisterer. Det vil sige, at det er tilladt at have NULL som værdi i rækken. Udover de 2 forskellige relationer kigger man på om det er en 1 til 1 (1:1), 1 til mange (1:n) eller mange til mange (n:m) relation. Forskellen på disse er at 1 til 1 relation bruges, når man har værdier i 2 tabeller, og man kan sige at der kan være 1 i den ene tabel, og ligeledes kun være 1 i den anden tabel.
F.eks. kan man lave 2 tabeller. 1 der indeholder mænd, og 1 der indeholder koner i ægteskab. Her kan man sige at der kan være 1 mand der har 1 kone, og man kan kun have 1 kone med 1 mand (i Danmark). 1 til mange relation bruges, når man har værdier i 2 tabeller, hvor der kun kan være 1 i den ene, men i den anden kan der være mange. Eksempelvis man kan kun have 1 kunde på en ordre, men 1 kunde kan have mange ordrer. Mange til mange relation bruges, når man har værdier i 2 tabeller, hvor der kan være flere i begge tabeller. F.eks. kan man have 1 ordre med mange produkter i. Man kan samtidig have 1 produkt i mange ordrer. Desuden bruges Primary og Foreign keys i tabellerne og til relationerne. Primary key repræsenterer den mest vitale række i tabellen og bruges til unikt at identificere hver record i en database tabel. En primary key skal indeholde unikke værdier. Dvs. der ingen duplikerede værdier må være i rækken. Desuden kan en Primary key ikke indeholde NULL værdier. Der kan maximalt være 1 Primary key i en tabel, og de fleste tabeller bør have en Primary key. Foreign keys bruges til at lave krydsreferencer i mellem relateret data i forskellige tabeller og desuden at forhindre handlinger, som kan ødelægge links imellem disse forskellige tabeller. Desuden forhindrer en Foreign key, at der bliver oprettet invalid data i en Foreign key række, fordi det skal være en værdi opbevaret i tabellen, som Foreign key peger på. En Foreign key i en tabel, peger på en Primary key i en anden tabel. Konceptuel ER-Diagram & Normalisering af ER-Diagram Vi har fået forelagt det konceptuelle ER-Diagram fra virksomheden til dette projekt, så dette har været ret nemt for gruppen at gå ud fra, og starte vores database. Nedenstående billede er af det konceptuelle ER-Diagram, som virksomheden har lavet. Billed 1
Efter diverse diskussioner og samtaler i gruppen, har vi fundet ud af hvorledes vi kunne normalisere databasen på den bedst mulige måde, og har gået igennem forskellige normal former, for at få det bedste resultat. Som tidligere nævnt, bruges normalisering af ER-Diagrammer, til at undgå redundans i databasen, dvs. at der ikke må optræde den samme data flere steder i databasen. Man kan se på nedenstående billede 2, hvorledes vores database ser ud efter normalisering til 3. normal form. Attribut tabel I en attribut tabel viser man de samme oplysninger som i ER-diagrammet, dog uden de forskellige relationer. Man bruger en attribut tabel til at planlægge, hvordan ens database struktur skal være, og hvilke datatyper man bruger i opbygningen af de forskellige tabeller. Dette sørger for at man får et overblik, og kan lette ens arbejde med databasen en del. Desuden bruges attribut tabeller til at lette forklaringen af databasens indhold til andre, uden at man reelt skal bruge adgang til databasen. Dette bruges især i virksomheder, til dokumentering og er en let måde til både at planlægge opdateringer og vedligeholde ens database på. Vi har lavet en attribut tabel, som viser de tabeller, som bruges i vores database, og indholdet i tabellerne. Vi har i fællesskab udarbejdet og diskuteret hvorledes vi kunne normalisere vores database, og hvilke forskellige datatyper der passer bedst til de forskellige attributter i tabellerne. Som man kan se på Bilag 1 (Attribut Tabel), har vi valgt at have følgende kolonner: Entity (som beskriver hvilke tabeller vi har i databasen), Se bilag 3
Dramaturgi Dramaturgi er kort fortalt opførelsen af en historie/ ide og hvordan den sættes godt sammen. Den bliver herefter nedskrevet til et manuskript, sådan at skuespillerne kan formidle den videre. Dramaturgi bruges indenfor både film og teater. Det vigtigste indenfor dramaturgi er handlingen, der får historien til at skride frem. Tema, konflikter og til allersidst løsningen der binder hele historien sammen. Indenfor dramaturgi er der flere forskellige former for analysemodeller til hjælp ved opbygning af ens historie/ storyboard. Der er tre akts modellen, 8 plot punkts modellen, Beretter modellen, Aktantmodellen og Kontraktmodellen. Vi har valgt at bruge tre akts modellen da vi fandt at den kunne bygge videre på de idéer vi allerede havde fundet. Tre akts modellen går ud på at der er tre betydningsfulde punkter i historien der ændrer historiens drejning, indtil der til sidst er en forløsning i slutningen. Den bygger ovenpå kontraktmodellen, som også passer til vores historie. Vores karakter starter med at sidde hjemme afslappet, da der pludselig starter en konflikt, hun skal gemme sine oplysninger. Men ved ikke hvorfor. Herefter kommer hun ud på et eventyr i en fantasi verden, der forklarer hende hvordan en database fungerer. Til sidst ender hun hjemme og har forstået det hele. Konflikten er blevet løst.
Vi fik til opgave at skulle lave en video med animation, eller en video med 3D grafik, som omhandlede databaser. Til det vil vi prøve at finde på et koncept/tema, som vi ville holde os til. Vores brainstorm udfoldede sig til alt fra hacking, shopping og rummet. Men det endte med at vi valgte et lufthavnstema, da det efter nogle idéudvækslinger gav mest mening for os. Vi vil prøve at holde den røde tråd igennem hele videoen, og det føler vi at vi har fået gjort. Både at det er en flybillet som bliver bestilt i videoen, og at animationen så foregår i en lufthavn med security, og et fly(sql) som flyver op i skyen(databasen), og ud kommer så billetten som er bestilt.
Storyboard Meningen med vores video, er at vise en person, som bliver nervøs/bange for hvad der sker med de oplysninger som hun kommer til at lægge ud i en database, og hvordan de faktisk kommer der til. Personen vil gerne bestille en flybillet igennem et flyselskab, men ser til sidst i formen, at man kan trykke Gem oplysninger, og her bliver personen både bange, bekymret og nervøs for hvad der så sker med de oplysninger. Det ender med at personen besvimmer, også kommer personen til at drømme. Når personen drømmer er hun så i en lufthavn, hvor der står en HTML-mand, som skal indikere at være formen med inputfelter, som skal udfyldes. Når de bliver udfyldt, så går HTML-manden igennem et JavaScript-securitycheck, ligesom hvis man normalt skulle ud at flyve. Her vil den så lyse rød og fortælle at der er noget galt med formen, da der mangler et @ i e-mailen. Det får personen rettet, og HTML-manden vil igen prøve at passere JavaScript-securitycheck. Denne gang bliver der grønt lys, og HTML-manden får lov at gå igennem. Efter det, finde HTML-manden en pilothat, denne pilothat gør ham til en PHP-mand i stedet for. Han bliver forvandlet fra HTML til PHP. Dette gør at han nu er i stand til at flyve et SQL-fly, hvilket er det de næste scener går ud på. Her ser man PHP-manden tage flyet og flyve op i skyen som i dette tilfælde er vores database. Skyen viser at information blev uploadet med succes, og ud kommer den flybillet som vores person der drømmer skulle til at bestille. Desuden kommer der nu en rulletrappe direkte fra jorden og op til skyen, så personen næste gang bare kan tage den vej, istedet for at skulle igennem hele security-checket igen næste gang. Denne trappe vil dog kun komme hvis brugeren klikker på Gem oplysninger -knappen. Til sidst ender det så med at personen vågner, og det går der op for hende hvad det er som der sker med den information hun sender, og hvorfor gem oplysninger -knappen er der. Bilag 4-6
Filmtekniske virkemidler Nær vi brugte det til at vise vores hovedperson foran skrivebordet i de første par scener. Her får seeren en forståelse af hun er nervøs over at skulle lægge sine personfølsomme data op på nettet. Zoom øjet kommer i centrum igennem et zoom fra distance. En forstærkende effekt til at få seeren til at forstå hendes angst for personfølsom data. Fra freesounds.org: Tastaturklik, Museklik, Heartbeat lyd, Gyserlyd, Harpelyd, Lufthavnsbaggrundsstøj, Alarm, Mystisk Computerlyd, Udendørsbaggrundsstøj med fugle Jetmotor starter. Jetmotor stabilt igang. biplyd i fly (fasten your seatbelts lyd). Boblelyd.Printerlyd.Bombefalder lyd. Jeapardylyd (Tik tok tik tok). Toghornlyd Aha (Haha-lyd) Fra Youtube: La cucaraca sang Lyd Dette er udpluk af lyde fra vores film. Lydene har en stor rolle i forhold til vores forståelse af budskabet. Vi har lagt vægt på at bruge lyde som folk genkender fra en typisk lufthavns tur. Dette er for at få en bedre forståelse af det budskab vi vil frem med nemlig, databaser.
Animation Vi har udviklet de fleste figurer igennem Adobe Illustrator. Dette program er især godt til at arbejde med simple figure der skal sendes rundt og klippes ind i filmen. Vi lavede hertil alle et udkast af en ideér til animation vi fremlagde hermed vores idé til Lene der godkendte det efter nogle små rettelser. Selve animationen er blevet lavet i after effects og til sidst sat sammen med resten af filmen i premiere pro. Vores animation er lavet i en enkelt udgave for ikke at gøre det for svært for os selv at skulle animere det senere hen. Det giver også en afslappethed omkring vores film der gør den lettere at forstå og følge med i. Videoredigering Adobe Premiere Pro: Til sammensætning og klipning af videoen har vi gjort brug af Adobe Premiere Pro. Adobe Illustrator: Alle figuerne i videoen er lavet i Adobe Illustrator Adobe After Effect: Effekter så som da personen i videoen udfylder en form og animationerne i videoen er skabt i Adobe After Effects. Først blev alle klippende sat sammen i kronologisk rækkefølge i forhold til vores storyboard. Derefter fandt vi passende lyde til scenerne både fra Freesound.org og Youtube.
Konklusion Under dette projekt har vi i gruppen både haft gode og dårlige oplevelser. Heldigvis har der været rigtigt mange gode oplevelser, som vi har lært en masse af. Dette har især været i planlægningsdelen af projektet, hvor alle gruppemedlemmerne tog ansvar for de forskellige opgaver der var i dette projekt. Alle har været godt involveret i størstedelen af projektet, selvom der, som nævnt tidligere, har været 3 større dele i projektet. Vi har været gode til at fordele de forskellige opgaver, således at der ikke var en stor arbejdsbyrde på en enkelt eller 2 gruppemedlemmer. Vi har desuden været god til at planlægge projektet fra start af, og har næsten dagligt holdt møder, hvor der blev gennemgået, hvor langt vi var nået med vores opgaver, og hvilke opgaver der skulle laves til næste møde. Der har været en god rollefordeling i gruppen, hvor folk har været hurtige til at finde ind i de forskellige roller man får i en gruppe. Vi har været et par stykker, som har gået forrest mht. planlægning og at holde styr på opgaverne i gruppen, hvor der har været andre der har taget større ansvar for det kreative (animationer, videofilmning osv.), der har været nogen der har haft ansvaret for den tekniske del (database) og endeligt har der været helt andre der har taget ansvar for rapport delen af projektet. Der har desværre også været udfordringer i gruppen med sygdom, fremmøde til tiden og lignende, som i nogen situationer har været så kritiske at der har været møder i gruppen, om hvorvidt vi skulle fortsætte med vores gruppestruktur eller hvad der skulle ske. Vi fandt heldigvis hurtigt ud af dette, og kunne snakke frit med hinanden, samtidig med at der ikke har været bad feelings blandt gruppemedlemmerne. En anden ting vi har lært meget af, har været tidsfordelingen på opgaverne, hvor de forskellige arbejdstimer der blev beregnet fra starten af, har været redigeret flere gange undervejs (især også fordi vi havde problemerne med sygdom og lignende). Her har vi blandt andet lært at man hellere skal sætte lidt ekstra tid af til de forskellige opgaver, da der hurtigt kan ske uforudsete ting, som forlænger de enkelte opgaver. Alt i alt synes vi i gruppen at vi har haft et meget lærerigt forløb, med flere aspekter, som vi alle har fået rigtigt meget ud af.
Bilag 1
Bilag 2
Bilag 3
Bilag 4
Bilag 5
Bilag 6