I foråret 2018 underviste jeg et hold i “Database” på AkademiUdannelse i IT efteruddannelsen. Det var et daghold, det vil sige fire lektioner af syv timer. Dette er materialet fra den sidste af disse.
Der er nogle småting, men I får det på samme måde som mine studerende fik, modsat dem får i dog ikke min tale med der rettede op på de mangler der er i slidesne, men det kan I forhåbentlig selv dække ind for.
I foråret 2018 underviste jeg et hold i “Database” på AkademiUdannelse i IT efteruddannelsen. Det var et daghold, det vil sige fire lektioner af syv timer.
Der er nogle småting, men I får det på samme måde som mine studerende fik, modsat dem får i dog ikke min tale med der rettede op på de mangler der er i slidesne, men det kan I forhåbentlig selv dække ind for.
I foråret 2018 underviste jeg et hold i “Database” på AkademiUdannelse i IT efteruddannelsen. Det var et daghold, det vil sige fire lektioner af syv timer.
Der er nogle småting, men I får det på samme måde som mine studerende fik, modsat dem får i dog ikke min tale med der rettede op på de mangler der er i slidesne, men det kan I forhåbentlig selv dække ind for.
I foråret 2018 underviste jeg et hold i “Database” på AkademiUdannelse i IT efteruddannelsen. Det var et daghold, det vil sige fire lektioner af syv timer.
Der er nogle småting, som bogtitel, hvor jeg bare har kopieret en skabelon fra tidligere men ikke fået skrevet kilde korrekt ind. I får det dog på samme måde som mine studerende fik, modsat dem får i dog ikke min tale med der rettede op på de mangler der er i slidesne, men det kan I forhåbentlig selv dække ind for.
Jeg talte godt nok for nogen tid siden om at lave en side med opgaver, men jeg er stadig ikke tilfreds med den eller konceptet, så der kommer nok nogle quizzer til mine nuværende hold her på siden i den næste tid – for flere af de store quiz tjenester jeg indimellem har brugt er blevet mere lukkede på det sidste, så må jeg jo styre det selv.
Denne quiz er ment som en hurtig start genopfriskning af basale SQL kommandoer og begreber. Den er langt fra fyldest gørende, men vi kommer meget videre rundt i min undervisning i database på bachelor/diplom i software udvikling og der vil sandsynligvis også komme mere komplekse quizzer.
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.
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:
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.
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.
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.
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.
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.
Her fjernes den redundante data, således sættes værdisæt, der kan bruges til flere poster, i særskilte tabeller.
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)”.
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.
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.
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.
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.
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.
