Internet Undervisning Læring

Kategori: Web-udvikling

  • Databaser – Grundlæggende introduktion

    Databaser – Grundlæggende introduktion

    Databasens historie

    Den moderne database har rødder tilbage i 1960erne takket være bl.a. IBM. I 1970 udgav Edgar “Ted” Codd, der også var ansat ved IBM, en artikel der beskriver en relationel database1. Han lagde senere navn til en af normal-formerne2. 
IBM var dog langsomme til at implementere den relationelle database, og lavede således det ikke-relationelle sprog SEQUEL, der var så godt at det allerede inden udgivelse blev kopieret og brugt i Oracle Database3 af Larry Ellison4 og navnet blev skiftet til SQL.
    SQL blev en ANSI standard i 1986 og ISO i 1987, og selv om der i dag findes mange mere eller mindre proprietære implementeringer er det grundlæggende sprog universelt mellem mange database systemer.

    SQL

    Langt de fleste relational database management systemer (RDMS), som er hvad de fleste forbinder med betegnelsen database, bruger sproget SQL (structured query language) til at behandle og manipulere data.
    I SQL er tabeller og forespørgsels-resultater lister over rækker: den samme række kan forekomme flere gange, og rækkefølgen af rækker kan anvendes i forespørgsler (f.eks. ved LIMIT).

    SQL er opdelt i flere elementer:

    • Klausuler (clauses), der er konstituerende bestanddele af erklæringer og forespørgsler – i nogle tilfælde valgfri.
    • Udtryk (expressions), der kan producere enten skalar værdier, eller tabeller, der består af kolonner og rækker af data.
    • Prædikater (predicates), der angiver betingelser, der kan evalueres til SQL tre-værdi logik (3VL) (sandt / falsk / ukendt)5 eller Boolske værdier6, som anvendes til at begrænse virkningerne af erklæringer og forespørgsler, eller til at ændre programmets flow.
    • Forespørgsler (queries), henter og sender data baseret på specifikke kriterier. Dette kan betegnes som essensen af SQL.
    • Udsagn (statements), som kan have en vedvarende effekt på skemaer (schema, samling af database objekter, typisk tabeller) og data, eller som kan kontrollere transaktioner, programmets flow, forbindelser, sessioner, eller diagnostik.
    • SQL-sætninger benytter semikolon (“;”) terminatoren. Selv om det ikke kræves på alle platforme, det er defineret som en standard del af SQL-grammatik.
    • Ubetydelige mellemrum er generelt ignoreret i SQL-sætninger og forespørgsler, hvilket gør det let at formatere SQL kode læsbart.

    Queries

    Eksempel på en simpel SELECT fra tabellen sound.
    Eksempel på en simpel SELECT fra tabellen sound.

    I SQL anvendes queries til SELECT, INSERT, UPDATE og DELETE data fra en database. Længden af en query kan variere efter hvor mange tabeller man arbejder med.

    I SQL er der mange reserverede ord, flere af dem kan ikke anvendes som tabel navne f.eks. kan man ikke kalde en tabel for “table”, “drop” eller “delete”. Reserverede ord er typisk angivet med blå tekst i en query og det vil være en fordel at undgå disse reserverede ord som tabel- og kolonne navne.

    Man kan kombinere informationer fra flere tabeller ved hjælp af Join.

    SELECT statement med brug af JOIN hvor de to tabeller kombineres hvis WHERE klausulen er opfyldt.
    SELECT statement med brug af JOIN hvor de to tabeller kombineres hvis WHERE klausulen er opfyldt.
    Indsættelse af informationer i tabellen Answers
    Indsættelse af informationer i tabellen Answers

    Joins

    Visuel representation af SQL Joins
    Visuel representation af SQL Joins

    I SQL bruges JOIN til at sætte en eller flere tabeller sammen i et resultat sæt. Der findes forskellige slags joins, der sætter tabellerne sammen på forskellige måder.

    Inner join kombinere to tabeller og tilslutter dem sammen baseret på kolonnerne i tabellen. Ved brug af inner join angiver man hvilke kolonner man ønsker at sætte sammen og under hvilken tilstand (condition). INNER delen i INNER JOIN er valgfrit i de fleste database systemer, da inner joins er standard, fordi det er det meste benyttede. Det vil sige man kan nøjes med at bruge JOIN som kommando 7.

    Ved inner join sættes alle værdier, der passer sammen, sammen, men ved Outer join kombineres alle værdier, uanset om de passer sammen eller ej.

    Den mest grundlæggende form for join er et Cross join, fordi der ikke bruges ON til at sammensætte tabellerne. I stedet for bliver alle rækker fra tabellen der er nævnt i join’et inkluderet i resultat sættet. 8.

    Første række i tabel1 kombineres med alle rækker i tabel2, derefter anden række i tabel1, og sådan fortsættes der gennem alle rækker i tabel1.

    Left join og Right join fungerer grundlæggende ligesom Inner join, men ved Left join returneres alle rækker fra venstre tabel og de matchende rækker fra højre tabel. Omvendt ved Right Join, hvor denne returnere alle rækker fra højre tabel og de matchende rækker fra venstre tabel. 9.

    Normalformer

    Normalisering, brug af normal-former, er systematisk opsætning af data i en database og beskriver afhængighederne og relationerne indholdet imellem.
    Ved at normalisere fjerner vi overflødig data og sikrer at der kun er relateret data i en tabel, hvilket både sparer plads og gør database-strukturen mere overskuelig. Samtidig kan adgangen til data bedre begrænses da den er delt op i mere specifikke tabeller, hvilket kan øge sikkerheden 10.

    Historien bag normalformerne

    Edgar F. Codd, der også “opfandt” relationsmodellen, introducerede Den Første Normal Form i 1970 og anden og tredje form i 1971.
I 1977 føjede Ronald Fagin en Fjerde og en Femte Normal Form til.
    Den nyeste tilføjelse af den Sjette Normal Form fra 2002 af C.J. Date, Hugh Darwen og Nikos Lorentzos
    Der er andre former ud over disse, f.eks. den tidligere nævnte Boyce Codd Normal Form.

    Første normalform

    Den første normalform definere at der ikke må være forskellig data i samme felt, hvilket betyder at informationen deles i tabeller efter relation.
Ligeledes fjernes gentagne grupper fra individuelle tabeller, hvor hvert sæt af relateret data har en primær-nøgle.

    Anden normalform

    Her fjernes den redundante data, således sættes værdisæt, der kan bruges til flere poster, i særskilte tabeller.

    Tredje normalform

    Det der ikke beskriver primærnøglen fjernes nu eller flyttes til andre tabeller.
    Esssensen af de første tre normalformer er altså at dataen i tabellen skal beskrive nøglen.
    I web-udvikling plejer man normalt kun at gå op i at opfylde de første tre normal-former, da det er de mest essentielle, og de følgende former leder til strukturer der ikke nødvendigvis er optimale til denne brug. Dette ledte til den klassiske huskeregel inspireret af den amerikanske ed ved domstolene: “The data should depend on the key (1NF), the whole key (2NF) and nothing but the key (3NF) (so help me Codd)”.

    Fjerde normalform

    Her må en tabel ikke have flere en-til-mange og mange-til-en relationer, der ikke direkte hænger sammen og en værdi må ikke have flere afhængigheder. Dette resulterer i en del ekstra tabeller.

    Nøglen hører til et id, hvor navnet på nøglen typisk består af id og tabelnavnet.
    For at dokumenter vores database som vi har lavet i forbindelse med vores semesterprojekt, har vi lavet et
E/R diagram i MySQL Workbench. Dette er et visuelt værktøj der tillader datamodellering 11. Vores diagram er lavet som et fysisk diagram, der viser tabellernes struktur og deres relationer. Diagrammet repræsenterer nøgler, tabel navne og kolonne navne med dertilhørende data typer. Desuden involveres normaliserings processen (se forrige spalte).
    For at optimere vores database laves denne så den følger 3. normalform. Det vil sige at den kun indeholder data, der beskrive primær-nøglen, al data i tabellen omhandler nøglen.

    Femte normalform

    Alle ikke-trivielle joins skal relatere til primær-nøglen, hvilket betyder at det nogle gange sparer resurser at dele ellers relateret data op. Alle tabeller skal altså kunne bruge * relationer, ellers skal det rykkes ud i ekstra tabeller 12.

    Sjette normalform

    Den sjette normalform er ret radikal da der ikke må være nogen trivielle join afhængigheder overhovedet. Data deles altså op i flere tabeller hvis den ikke internt relaterer til hinanden.
    Den bruges i store datavarehuse og resulterer i rigtig mange tabeller 13, hvoraf de fleste droppes undervejs.
    Der er som nævnt i starten af dette afsnit mange flere normal-former, men disse seks er de mest anerkendte.

    E/R diagram

    Et E/R diagram (entity relationship diagram) er en visuel gengivelse af databasens struktur og hvordan elementerne relaterer til hinanden. Diagrammet illustrerer de forskellige tabeller i databasen, bestående af rækker af kolonner med en dertilhørende primær-nøgle. Primær-nøglen sikrer unik data, da den garanterer at hvert datapunkt har en unik værdi 14, og den indekserer også databasen så den yder bedre.

    ER diagram
    ER diagrammet viser tabellerne i vores database, hvilke kolonner der er i tabellerne og data typen tilhørende kolonnen.

    En tabel i vores diagram er ”Users” og en kolonne i denne tabel er ”Firstname”. Disse kolonner har fået tilføjet forskellige slags data typer. Data typer beskriver hvilke slags data der opbevares. Eksempler på data typer kan være tal, tegn eller datoer. Valg af korrekt datatype sørger for at værdier, der indsættes i databasen, giver mening og det sparer desuden plads (Wilton & Colby, side 18). De tilføjede data typer i vores diagram er ”VARCHAR(45)”, en tekst-streng på maks 45 tegn, ”INT” typen heltal, og ”BOOLEAN” typen true/false.

    Diagrammet viser desuden relationen imellem tabellerne. I vores diagram ses flere en-en relationer og en relation bestående af en-mange eller en-en relation. Disse relationer viser hvor mange gange en forekomst (instance) i en tabel kan være forbundet med forekomsten (instance) i en relaterede tabel.

    Det er værd at bemærke at idUsers (INT) er den værdi brugeren angiver som brugernavn i app’en, som han får tilsendt per brev fra sygehuset, hvor de andre id værdier er sat som AutoIncrement – at den automatisk sættes ind og øges med 1 for hvert nyt indlæg/række i tabellen.

    Den gule nøgle viser at den række er sat til at være Primary Key.

    Firkanterne viser forskellige information om de enkelte rækkers status: en hvid firkant viser at den ikke behøves være udfyldt, den blå at den skal være udfyldt (Not Null) og den røde at det er Foreign Keys, en værdi der er en primær-nøgle i en anden tabel.

    Litteraturliste

    1.  Wilton side 7 ↩
    2. Boyce–Codd normal formen ↩
    3. Oracle Database ↩
    4. Larry Ellison ↩
    5.  Three-valued logic ↩
    6.  Boolsk Algebra ↩
    7.  Wilton & Colby, kapitel 3 og 7 ↩
    8.  Wilton & Colby, kap. 7 ↩
    9.  SQL Joins ↩
    10. The Database Normalization Process ↩
    11. MySQL Enterprise Edition, Workbench ↩
    12. Join dependency ↩
    13. Sixth normal form ↩
    14. Churcher, kap. 7 ↩
  • MVC – Det grundlæggende

    MVC – Det grundlæggende

    Da artiklen her er rettet mod voksne i stil med dem der går på en erhvervsudannelse eller lignende er tonen i den tilpasset den målgruppe ud fra mine egne erfaringer dermed.

    Artiklen er også kun tænkt som en kort introduktion til emnet, der findes langt mere uddybende tekster på engelsk.

    Introduktion

    MVC, forkortelsen for Model View Controller men i daglig tale kalder alle jeg kender det blot MVC, er et designmønster for software tilbage fra 1970erne. Modellen blev oprindeligt brugt til at designe software med et grafisk interface ud fra, men er i dag blevet utroligt populær til web applikationer også – omend man kan diskutere om den bruges i den oprindelige udformning, især da der er forskellige måder at fordele ansvaret mellem klienten og serveren1.

    Teorien

    MVC deler software applikationen op i tre forbundne dele, så den interne repræsentation af data adskilles fra det der modtages fra og vises til brugeren.

    Det er vigtigt at have i mente at MVC ikke er et framework i sig selv, omend der er mange frameworks der benytter tankegangen, det er “blot” et mønster til strukturel opbygning og dermed udvikling af software.

    Modellen
    Her taler vi desværre ikke om en veldrejet undertøjs-model for Victorias Secrets men den kode som lagrer data, der er hentet i henhold til kommandoer fra controlleren og vises i view’et. Modellen udfører altså det arbejde der gør at hjemmesiden/softwaren reelt har en funktion og ser ikke bare pæn ud.

    Viewet
    Her er der igen ikke tale om et billede af den førnævnte model men den kode der skaber en output præsentation for brugeren baseret på ændringer i modellen. Den grafiske overfalde på hjemmesiden eller softwaren som gør den lækker at bruge. Det er vigtigt at notere at view ikke er templates men klasser og metoder.

    Controlleren
    Controlleren kan sende kommandoer til modellen, opdatere modellens tilstand (f.eks at redigere et dokument). Det kan også sende kommandoer til dens tilhørende view for at ændre visningen af modellen (fx ved at scrolle gennem et dokument). Det er her man definerer de grundlæggende funktioner i ens hjemmeside / software som database forbindelse.

    MVC definerer altså en struktur for den måde man opbygger sin software på, hvor man lægger de forskellige funktioner i ens kode, hvilket gør den mere overskuelig både for en selv og for andre. På den måde er den også en objekt orienteret tankegang, da man netop definerer objekter i de forskellige “lag” som man så henviser til og benytter de andre steder.

    Ting der bruger MVC

    Siden jeg har mest erfaring med webudvikling er eksemplerne være baseret på dette felt

    Der er som nævnt i introduktionen mange frameworks der benytter MVC tankegangen, dette er blot et udpluk af nogle af de mest populære:

    • Ruby on Rails, eller bare Rails, er et web applikations framework skrevet i Ruby. Det følger MVC standarden da det har en standard strukturer for database, webtjeneste og web-sider.

    • Django er et web applikations framework skrevet i Python hvis formål er at lette skabelsen af komplekse, database drevne hjemmesider. Django følger MVC standarden da de består af en objekt-relational mapper (ORM), der medierer mellem datamodeller (defineret som Python klasser) og en relationel database (“Model”); et system til behandling af HTTP-forespørgsler med et web-templating-system (“View”) og en regular-expression-baseret URL afsender (“Controller”).

    • Express.js er et node.js web applikationsserver framework, der er designet til hjemmesider og hybrid webapplikationer. Det er de facto standard server rammer for node.js, og den er en del af MEAN software stakken (MongoDB,  Express, AngularJS og det hele kører på NodeJS) til dynamiske hjemmesider og webapplikationer.

    Fælles for disse er at de alle kan kaldes for en slags tynde klienter, da brugeren sender enten hyperlinks eller form input til webserveren, hvor controlleren er, og får en komplet hjemmeside igen, modellen er altså kun på serveren.

    Nyere frameworks lader dele af modellen køre på brugerens computer, nu hvor teknologierne er mere modne, et meget udbredt eksempel er Angular.js

    Angular.js læser HTML-siden, der har indlejret ekstra attributter. Angular fortolker disse attributter som regler der binder input eller output dele af siden til en model, der er repræsenteret ved standard JavaScript variabler. Værdierne af disse JavaScript variabler kan indstilles manuelt i koden, eller hentes fra statiske eller dynamiske JSON ressourcer. Ved hjælp af dette flytter Angular traditionelle server-side-tjenester, såsom visnings-afhængige controllere, til klient-side web-applikationerne og reducerer derved en stor del af byrden på serveren.

    MVC tankegangen er også benyttet i flere udviklings værktøjer og miljøer til apps til mobil-telefoner, et eksempel herpå er Appcelerator.

    Er det MVC af navn eller af gavn

    Der er udover eksemplerne ovenfor en række web framework systemer, bl.a. i PHP, som jeg dog har set en del debat om man kan kalde rigtig MVC da det kan diskuteres hvor dybdegående de opfylder modellen. Denne debat vil dog mere høre hjemme i vurderinger af de enkelte frameworks frem for i en generel introduktion til MVC.

    Mange web frameworks regner f.eks. også View delen som mere eller mindre separeret, ekstern theming og ikke som en definition af variablerne, der bestemmer selve grund-opbygningen af siden.

    Tilfældet Appcelerator

    Dette indlæg udspringer oprindeligt af en bachelor-opgave, hvori der blev benyttet programmet Appcelerator til at lave mobil-apps, så derfor har jeg en udvidet sektion om netop dette programs vinkel på MVC.

    Appcelerator (tidligere Titanium) benytter i sin Alloy del MVC strukturen. Man er ikke tvunget til at følge en MVC struktur i Appcelerator Studio, og så alligevel, for hvis man bruger klassisk kodning kan man kode ret frit2, men hvis man bruger Alloy benyttes der en struktur baseret på MVC tanken3.

    Det er vigtigt at huske at hver “side” i ens app har et separat sæt filer i hver mappe, men der er et universelt fil-sæt kaldet app.respektivt-filnavn-efter-mappen der dækker det hele som standard. Man kan dog føje ekstra funktiones-filer til models og controllers og så kalde dem. Mange laver dog også flere sider i deres app som views frem for separate sider, hvilket passer godt ind i denne struktur.

    I models mappen ligger de filer, der behandler den data, vi har fået gennem variabler defineret i controlleren.
    XML-filerne4 i views mappen definerer strukturen på udseendet, hvilket igen er en funktionel beskrivelse per MVC standarden, medens man skriver hvordan udseendet reelt ser ud i TSS-filerne5 i styles mappen, altså theming som nogle web udviklere kalder for view delen6.
    controllers mappen indeholder de funktioner, der giver den overordnede app, og de specifkke sider derunder som beskrevet ovenfor, den funktionalitet der ønskes. Det defineres her og bliver så eventuelt bearbejdes af modellerne7 og fremvises i view’et, der danner den brugerflade brugeren af app’en ser. Når brugeren så klikker på en knap eller på anden måde interagerer fanger kode i controlleren så dette og forløbet starter på ny.

    Litteratur

    • Leff, Avraham; Rayfield, James T. (2001). Web-Application Development Using the Model/View/ Controller Design Pattern. IEEE Enterprise Distributed Object Computing Conference. Side 118– 127.
    • Sounders, Aaron (2015). Building Crossplatform apps Using Titanium, Alloy, and Appcelerator Cloud Services. Wiley. Side 43-81
    1.  Leff, Rayfield ↩
    2.  Alle objekter skal defineres i en variabel, men strukturen er ikke fast ↩
    3. Sounders ↩
    4.  Appcelerator bruger en tilpasset variant af XML til dette ↩
    5.  TSS (Titanium StyleSheet) er et sprog, der er en adaption af CSS (Cascading StyleSheets) med få ændringer ↩
    6.  Derfor kaldes denne opbygning af nogen for MCT (mode controller theming), men normalt regnes det bare for en variation over MVC mønsteret ↩
    7.  Det er ikke et krav at man har noget i model-mappen, hvilket gør at Appcelerator kun bruger CV delen af modellen, hvilket udviklingsmiljøet ikke har nogen problemer med ↩
  • Unavngivet indlæg 62

    I efteråret 2013 underviste jeg i webudvikling, primært HTML og CSS, på Syddansk Erhvervsskole, og i den anledning lavede jeg nogle slideshows som jeg brugte i undervisningen. Jeg tænkte at andre undervisere på lignende kurser/uddannelser eller bare folk der ikke selv kan kode lige så godt kan få glæde af dem, så de kommer op i den næste tid.

    Her er den første:

    Download the PDF file .