Kapitel 14. Arkitektur i programmer og databaser

Susanne Sulten og Arne Appeltit går på restaurant “Mad & Mæt”. Under måltidet betjener en høflig og velklædt tjener dem. De afgiver en ordre, og tjeneren går ud med ordren i køkkenet. Susanne og Arne har ikke adgang til køkkenet. Når dagen er slut, rydder de op i køkkenet, og “Mæt & Mad” lukker og slukker. Madopskrifter og lager af mad gemmer restauranten et sikkert sted, så det er klart til dagen efter.

99% af alle apps og programmer fungerer på næsten samme måde. De er opdelt i 3 ret adskilte lag:

• Frontend eller præsentationslaget.
• Backend eller forretningslaget
• Databasen eller datalaget

Brugerne ser programmet i frontend eller præsentationslaget. Det svarer til det område, hvor kunderne kommer i restauranten. Det skal være så præsentabelt og indbydende som muligt

Når hjemmesidens brugere klikker på noget, så aktiverer klikket kodning i backend eller forretningslaget. Det svarer til, at tjeneren modtager bestilling på mad og afleverer den ude i køkkenet. Vi vil ikke have brugerne ind i backend, og vi vil heller ikke have restaurantens gæster ud i køkkenet

Vi kan godt gemme ting midlertidigt i både frontend og backend i f.eks. variable og cookies.

Men udgangspunktet er, at når vi slukker programmet, så slukker vi også for hukommelsen, og variablene slettes. Heldigvis har vi datalaget eller databasen. Her kan vi gemme oplysninger, f.eks. om kunder. Vi kan hente oplysningerne frem igen, selvom programmet har været slukket i et stykke tid. I restauranten gemmer vi opskrifter på nettet og har madvarer på frost, hvor de kan være gemt i lang tid

I figuren kan du se, hvordan lagene arbejder sammen. Frontend snakker med backend, der om nødvendigt henter ting ud af databasen og viser det til brugeren i frontend. Den stiplede linje viser, at vi kun vil have kunderne ind i frontend-området.

Hvis vi sætter det op i en tabel, ser det sådan ud. Jeg har tilladt mig at skrive nogle af de kodesprog på, som anvendes i laget.

LAG	BRUGES TIL	KODESPROG	HVIS DET VAR EN RESTAURANT
Frontend	Præsentationslag, ses af brugerne	Kun html, php og javaScript. Ingen andre sprog kan tolkes direkte i en browser	Kundeområdet
Backend	Forretningslogikken. Styre programmet og afvikler ordrer fra brugerne i frontend. Ingen adgang for kunder	Mest php og C# til hjemmesider, men også sprog som java, asp, vb.net m.fl.	Køkkenet, hvor retterne laves,
Database	Gemmer data, så de også er der efter, at programmet er slukket. Vi gemmer næsten alle data i tabeller lidt som i Excel	MySQL, hvis man skriver PHP. Ellers SQL ved C#	Det, vi gemmer, når personalet lukker restauranten. Madvarer, opskrifter mv.

Link til toppen af siden.

14.1 Et eksempel: Facebook

Et kik på Facebooks forside kan hurtigt forklare, hvad jeg mener.

Når vi ser Facebook, genkender vi hurtigt de mørkeblå og hvide farver. Det, vi ser, er selvfølgelig frontend. Hvis vi kikker op i højre hjørne, kan jeg logge ind med mit brugernavn og password. Hvis jeg indtaster brugernavn og password, overføres det indtastede til backend. Backend spørger videre ned i databasen, som jo har en oversigt over alle brugernavne og password på alle profiler i hele verden. Hvis jeg taster rigtigt, bliver jeg logget ind på min profil, ellers ikke.

Alt hvad jeg skaber på Facebook, fra tekst over billeder, videoer, likes …, alt bliver gemt i databasen. Hvis du begynder at tænke lidt over, hvor meget lagerplads Facebook har brug for, så er svaret: “Meget”.

Hvis du kan se et program/en app, så er der et frontend lag. Hvis du kan udføre noget i frontend, så har vi et backend lag. Hvis programmet kan huske noget fra sidst, du brugte programmet, så har programmet en database.

Link til toppen af siden.

14.2 Databaser

Hvad er en database? Det kan siges meget simpelt: En database er intet andet end en tabel.

Tabellen kan være opbygget på mange indviklede måder, og man kan dele tabellen op, hvis man vil. Men i bund og grund er en database bare en tabel og intet andet.

Link til toppen af siden.

Et eksempel: Niels Ny skifter skole

Niels Ny skifter til i en HHX klasse midt i skoleåret. Det er en ret stor klasse. Fagene, især informatik, er super interessante, lærerne er gode, de andre elever er flinke og han bliver allerede den første dag inviteret med til en klassefest.

Niels er dårlig til ansigter, så han skriver elevernes navne ned. Han har talt med 2 af eleverne: Lene og Lone

NAVN	HÅRFARVE	ØVRIGT
Lene	Rød	LIlle, går i modetøj tøj, dyrker fitness
Lone	Brun	Høj, kan lide at gå på café, griner meget

Har Niels Ny en database? Stort JA, Niels Ny har en lille men fuldt gyldig database.

Link til toppen af siden.

14.3 Normalisering

Niels Ny’s database er udmærket, og den fungerer fint for ham. I hvert fald indtil han har flere Lener og Loner på listen og ikke kan kende forskel.

For at vi kan arbejde professionelt med databaser, er vi nødt til gøre nogle ting ved dem. Denne proces kalder man for “normalisering. Jeg vil kort beskrive de vigtigste her. Bemærk, at du skal gøre dem i rækkefølge, og du må ikke starte på trin 2, før trin 1 er færdig. Du må heller ikke starte på trin 3, før trin 2 er færdig osv. Det kan vises sådan her:

Link til toppen af siden.

Trin 1. Primærnøgler og opdeling

Primærnøgler er et godt sted at starte vores normalisering. Her er en lille kundedatabase.

Vi har 2 kunder, “Kim Kunde” der tilfældigvis hedder det samme. Den ene er alletiders kunde, men den anden skylder os rigtigt mange penge. Vi vil kontakte den dårlige kunde og bede ham om at betale det, han skylder. Men vi skulle jo nødig tage fat i den forkerte.

De hedder det samme, og de kan teoretisk også have samme adresse, postnummer, telefonnummer osv. Så hvad gør vi her? Svaret er: Vi må finde på noget unikt, så vi kan identificere dem hver for sig.

Den danske stat bruger cpr-numre for at identificere danskerne. Men den mulighed har vi ikke altid, så vi tilføjer et kundenummer for hver kunde til vores tabel. Det er sådan set ligegyldigt, hvilke numre eller for den sags skyld bogstaver de enkelte kunder har. Bare hvert enkelt nummer er unikt. Et sådant unikt felt for hver kunde i tabellen kalder man en primærnøgle eller et ID. Jeg tilføjer feltet og sætter det forreste, for er praktisk at have primærnøglen forrest.

Alle registreringer i en database skal altid have en primærnøgle, dvs. noget unikt. Ellers kan vi ikke identificere vores registrering, og så bryder vores database sammen. Hvis vi ikke kan finde noget unikt i det, vi i forvejen har registreret, så må vi selv tilføje noget.

Link til toppen af siden.

Trin 2. Del dine data op

Det er en god ide at dele data op i tabellen. Jo bedre en opdeling, jo nemmere kan vi f.eks. finde og sortere data. Min kundedatabase nedenfor er i forvejen ganske fornuftigt opdelt.

Det ville dog være rart, hvis jeg kunne adskille navnet i fornavn og efternavn. Nyttigt, hvis jeg skal sende en pæn besked til en kunde, så vil jeg gerne kunne nøjes med at hente kundens fornavn fra databasen. Jeg ville også gerne kunne sorter kunder efter først efternavn, så fornavn

Man kan diskutere, om adressen då også skal deles op i vej og vejnummer. I praksis er det nok kun folk, som arbejder med alle adresser i et område, f.eks. postvæsen, elektricitetsforsyning m.v., der har sådan en opdeling.

Link til toppen af siden.

Redundans

Redundans betyder “overflødig”. Så hvis Bo Boss siger til Arne Arbejder, at han er “redundant”, så mister Arne nok sit job.

I databaser kan nogle registreringer være overflødige. Hvis vi kan undgå overflødige registreringer. vil vores database fylder mindre, og at den vil være er lettere at vedligeholde. Når vi arbejder med små databaser som i eksemplerne her, så betyder det ikke så meget. Men databaser kan sagtens runde 100.000 registreringer eller flere og så har det stor betydning. Tænk på, hvor mange registrering der er f.eks. på Netflix’ kundekatalog eller det danske CPR register eller hvis vi skal registrere alle bogføringer i en virksomhed.

Jagten på redundans går ud på at finde et felt, som ikke er uafhængigt. Dvs. et felt, hvor det på en eller anden måde er bestemt på forhånd, hvad der skal stå.

• Det første felt er kundenummer. Hvis vi ser bort fra, at alle felterne skal have et unikt indhold, så kan vi her skrive, hvad vi har lyst til
• Det samme gælder fornavn, efternavn, adresse og postnummer. Folks fornavn er uafhængigt af deres efternavn. Rikke Rabat kunne lige så godt hedde Rikke Rasmussen eller Rikke Ling-Hu-Chan. Adressen og postnummeret er også uafhængige felter
• Feltet by er ikke uafhængigt. Feltet er helt og holdent styret af feltet postnummer. Hvis postnummeret er “6000”, SKAL der stå “Kolding” i feltet by. Der kan ikke stå andet. 6000 Slagelse giver ikke mening, lige så lidt som “4200 Kolding” giver mening

Link til toppen af siden.

Når vi har fundet et afhængigt felt, skal vi dele tabellen op

Vi har nu fundet et felt, “by” der er afhængigt. I tabellen optræder Kolding 3 steder og Fredericia 2 steder. Det kan vi skære ned til, at begge byer kun forekommer 1 gang. Det ser sådan ud:

Nu står byerne Kolding og Fredericia kun nævnt 1 gang.

Overholder den nye tabel så reglerne for tabeller? Den skal jo have en primærnøgle. Det har den, feltet postnummer er unikt og kan fungere som primærnøgle. Samtidig har vi bevaret feltet i den gamle tabel. Når feltet findes i 2 tabeller, så kan vi bruge det ene felt til at slå op i den anden tabel.

• Når feltet er et unikt felt, der bruges til identifikation, kalder vi det for “primærnøgle”
• Hvis feltet er unikt, og vi samtidig bruger det til at slå op i en anden tabel, kalder vi det for en “fremmednøgle”. Feltet postnummer i den gamle tabel er en fremmednøgle.

Faktaboks: Byer skifter navne Det sker, at byer ændrer stavemøden. Tit er det for at søge byens rødder, eller måske for at gøre byen lettere at markedsføre i udlandet. Åbenrå er skiftet til Aabenraa, Grenå til Grenaa, Århus til Aarhus, Ålborg til Aalborg og Åkirkeby til Aakirkeby for at nævne nogle. Da f.eks. Århus skiftede til Aarhus, skulle man i databaserne kun ændre byens navn et sted, fordi man selvfølgelig har lavet opsplitningen som vist ovenfor. Der er nok 50.000 mennesker eller flere, der havde postadresse 8000 Århus C.

Link til toppen af siden.

14.4 Datatyper

Alle tabeller kan deles op efter tabelnavn, primærnøgle, felter og poster.

Betegnelse	Forklaring
Tabelnavn	Giver sig selv: Navnet på tabellen. Giv tabellen et sigende navn
Primærnøgle	Et felt, som er unikt for hver række. Svarer til et ID. Hvis der ikke er et unikt felt i rækken, må vi selv finde på et. Eksempel: Læger har cpr-nummeret på patienterne, det kan bruges som primærnøgle. Til gengæld skal vi selv finde på noget unikt, f.eks. et kundenummer, hvis vi vil registrere kunder
Felter	Betegnelsen for data: F.eks. Kundenummer, Fornavn, Efternavn.
Poster	En hel vandret række med komplette oplysninger. Her de komplette oplysninger om hver enkelt kunde

Datatyper

Du har allerede mødt datatyper. Når du programmerer, f.eks. i App Lab, er der forskel på nedenstående:

• 1 eller “1”
• resultat eller “resultat”

Hvis tekst eller tal er i anførselstegn som f.eks. “1”, så opfattes det som tekst. Hvis tallet 1 skrives uden anførselstegn, så er det et tal. Det vil sige, at hvis man skriver i programmet 1 + 1, så vil programmet kunne regne ud, at det giver 2. Hvis man skriver “1” + “1”, så vil det nærmere give “11”, hvis ellers programmet forstår det.

Tilsvarende: Skriver man resultat i et program, vil programmet opfatte resultat som en variabel. Skriver man i stedet “resultat”, så vil programmet opfatte det som tekst. Derfor giver følgende kode god mening, og koden vil skrive 2 på skærmen.

var resultat;
resultat = 1 + 1;
udskriv resultat;

Mens koden her vil give fejl eller skrive “11”

var resultat;
"resultat" = "1" + "1";
udskriv resultat;

Koden her vil bare skrive “resultat” og den fejl har de fleste prøvet at begå:

var resultat;
resultat = 1 + 1;
udskriv "resultat";

Vi har indtil videre 2 datatyper: Tal og tekst, og det er vigtigt at skelne: Tal er noget vi kan beregne med, mens vi ikke kan beregne med tekst. Skal et telefonnummer så være tal eller tekst? Klart tekst, det giver ingen mening at lægge 2 telefonnumre sammen.

Her er en leverandørdatabase, som er lavet i Access. Access er et databaseprogram, der hører med i den udvidede Officepakke. Du kender i forvejen Word, Excel og sikkert OneNote fra Microsofts Officepakke.

Alle databaser har som minimum datatyperne tekst, tal, ja/nej felt. Access har så nogle ekstra datatyper som det ses nedenfor. Et “OLE-objekt” er en fil, f.eks. et Word-dokument eller et billede.

Link til toppen af siden.

14.5 Flade kontra relationelle databaser

• Hvis en database kun består af 1 tabel, så har vi en flad database
• Hvis en database består af 2 eller flere forbundne tabeller, så har vi en relationsdatabase

Relationsdatabaser er den mest almindelige databaseform. Hvis du arbejder i f.eks. et ERP system, kan du være sikker på, at der ligger en relationsdatabase bag.

Link til toppen af siden.

14.6 Hvad er en relation

Når vi laver opsplitninger af databasetabeller, laver vi en relation. Der findes 3 former for relationer :

RELATION	FORKLARING
1-til-1	1 person “A” er gift med 1 anden person “B”, og “B” kan også kun være gift med en “A”
1-til-mange	1 person kan have postadresse på 1 postnummer, men 1 postnummer kan godt have mange personer tilknyttet
mange-til-mange	1 vare kan købes af mange kunder, og 1 kunde kan købe mange varer

Link til toppen af siden.

Relationer

• Når vi har en 1-til-1 relation, splitter vi ikke tabellen op.
• Når vi har en 1-til-mange relation, så splitter vi tabellen op som vist
• Når vi har en mange-til-mange relation, er vi nødt til både at splitte tabellen op, men også at lave en mellemtabel

Store databaser kan være virkeligt komplicerede. For ikke at miste overblikket bruger vi E-R diagrammer til at illustrere dem. I E-R diagrammer viser vi tabeller som kasser og relationer som diamanter.

Link til toppen af siden.

1-til-1 relation

1-til-mange relation

Mange-til-mange relation

Hvis du skal tegne rutediagrammer, E-R diagrammer og lignende, så anbefaler jeg dig at bruge www.draw.io

Link til toppen af siden.

Kapitel 15. Kodning i databaser: SQL

Vi kan kun 4 ting med en database. Vi kalder det for CRUD:

• Create: Vi kan skabe nyt indhold i databasen
• Read: Vi kan læse indhold fra databasen
• Update: Vi kan opdatere indhold i databasen
• Delete: Vi kan slette indhold i databasen

Til alt kontakt med databaser bruger vi SQL kode. SQL står for “Structured Query Language”. SQL er et simpelt sprog, som lægger tæt op ad menneskesprog. Næsten uanset hvad du gør med en database, så er der SQL involveret. SQL findes sjovt nok i forskellige “dialekter”, f.eks. MySQL og MS-SQL. “MS” står for “Microsoft”, men kernen i sproget er ens for alle. Lige som der er navneord på både dansk, tysk, engelsk, spansk, russisk, indonesisk, wolof og hvilke sprog vi ellers kan komme på.

Link til toppen af siden.

15.1 Eksempler på SQL kode

Vores 2 tabeller fra før kalder vi nu “Kunder” og “PostnummerBy”:

Her er nogle eksempler på SQL kode

ØNSKE	SQL KODE
Hent alle data fra tabellen Kunder	SELECT * FROM Kunder;
Hent alle data i felterne FORNAVN og EFTERNAVN. Efternavnet skal stå først	SELECT EFTERNAVN, FORNAVN FROM Kunder;
Hent alle data i felterne FORNAVN og EFTERNAVN. Efternavnet skal stå først, og der skal sorteres efter efternavn	SELECT EFTERNAVN, FORNAVN FROM Kunder ORDER BY EFTERNAVN;
Hent alle oplysninger om kunder, der hedder “Kim”	SELECT * FROM Kunder WHERE FORNAVN = ‘Kim’;
Hent alle oplysninger fra begge tabeller	SELECT * FROM Kunder INNER JOIN Customers ON Orders.Postnummer=PostnummerBy.Postnummer;

Hvis man skal arbejde med kode, så er W3schools et fantastisk sted at starte. De skriver om mange sprog, de skriver simpelt, og man kan prøve det af. Selvfølgelig har de også noget om SQL. Hvis du vil vide mere om SQL, så hop ind på https://www.w3schools.com. Vi vil senere vende tilbage til W3schools, når vi skal kode html og css.

Link til toppen af siden.

15.2 Hackning vha. SQL injections

Du ved nu, at man bruger SQL til at hente informationer ud af databaser med. Du ved også, at man kun kan 4 ting med en database: Create, Read, Update og Delete (CRUD).

SQL kommandoen “DROP DATABASE testDB” vil slette hele databasen “testDB”.

Formularer og søgefelter giver brugeren adgang til at arbejde med databasen. Hvis en bruger er ondsindet, kan brugeren forsøge at slette databasen ved at sætte SQL kode ind i et felt. Her har jeg sat kode ind i søgefeltet på hjemmesiden her:

Hvis man ikke passer på, så vil en bruger kunne slette min database på den her måde. Det kaldes SQLInjections, og det er en helt almindelig form for hackning.

Link til toppen af siden.

15.3 Opsummering på databaser

Det meste af det, som du skal kunne omkring databaser, har jeg opsummeret i videoen her. Det gælder emner som:

• Entiteter og relationer
• Normalisering
• Primærnøgler og fremmednøgler
• Redundans
• Relationer
• Basis SQL kode

Her er en video, der opsummerer databaser. Jeg gennemgår alt databaseteori helt forfra. Fra hvad en database er, og til hvordan man kommer frem til en funktionsdygtig database. Jeg gennemgår entiteter, relationer, normalisering, primær- og fremmednøgler, redundans samt relationer. Til sidst viser jeg dig lidt SQL kode, som man bruger til at kommunikere med databasen med.

Link til toppen af siden.