# DFU 01 ## Intro --- ## Gennemgang af faget ---- ### Studieordningen #### Viden * Den studerende har viden om: * forskellige databasetyper og de bagvedliggende modeller * et konkret databasesystems lagerorganisering og forespørgselsafvikling * et konkret databasesystems optimeringsmuligheder – herunder fordele og ulemper * databasespecifikke sikkerhedsproblemer og deres løsninger * begreber og problemstillinger vedrørende skalering og datakompleksitet * de særlige problemstillinger, som mange samtidige transaktioner rejser, herunder også i forbindelse med distribuerede databaser * principper for at tilgå data fra applikationer ---- ### Studieordningen #### Færdigheder * Den studerende kan: * analysere anvendelsesdomænet med henblik på valg af databasetype * transformere logiske datamodeller til fysiske i forskellige databasetyper * gennemføre optimeringen af databaser * håndtere samtidige transaktioner i et konkret databasesystem * anvende de faciliteter og programmeringsmuligheder, der stilles til rådighed af et moderne DBMS * anvende tidssvarende værktøjer til at tilgå data ---- ### Studieordningen #### Kompetencer * Den studerende kan: * sætte sig ind i forskellige databaseteknologier * facilitere samarbejde med henblik på dataunderstøttelse af forretningsmæssige mål ---- ### Faget i overskrifter * ER Diagrammer * Normalisering * "Advanced Queries" * ACID, BASE * Aggregation & Data Warehouse * Backup & Replication * Memory database + Key/Value storage * Document Databases ---- ### Eksamen * Mundtlig prøve på baggrund af forberedte spørgsmål * Prøven er individuel * Prøvens varighed; 30 min, heraf: * 10 min. præsentation * 15 min. eksamination * 5 min. votering * Bedømmelse efter 7-trinsskalen * Intern bedømmelse * Aflevering: bekræftigelse på deltagelse * Der opnåes 10 ECTS ved gennemførsel * Ikke bestået; re-eksamen efter ordinær regler --- ## Opsætning og runtime ---- ### Database repo Gennemgang af database repo, [https://github.com/ucldk/databases](https://github.com/ucldk/databases) > !NOTE: > Det er ikke et krav at køre database gennem Docker, skal kun ses som en hjælp til jer --- ## Relationelle Databaser ---- ### Sammenligning af relationelle DBMS' - PostgreSQL - Microsoft SQL Server - MySQL / MariaDB ---- ### Introduktion - Relationelle databaser = mest brugte type databaser - Forskelle i: - Licens og pris - Funktioner og standardkompatibilitet - Performance og skalerbarhed - Ecosystem og værktøjer ---- ###
Kort
historik - **PostgreSQL**: Open Source (1989, Berkeley), stærk standardkompatibilitet - **MS SQL Server**: Proprietær (1989, Microsoft), enterprise-orienteret - **MySQL**: Open source (1995, Sun/Oracle), udbredt i webmiljøer - **MariaDB**: Fork af MySQL (2009, community-ledet) ---- ### Licens og pris - **PostgreSQL**: Open source, gratis permissiv licens - **MS SQL Server**: Proprietær, licensbaseret, gratis Express edition - **MySQL**: Open source (GPL), Oracle styrer udviklingen + enterprise support - **MariaDB**: Open source (GPL), community + enterprise support ---- ### Standardkompatibilitet - PostgreSQL: Tættest på SQL-standard (ACID, avancerede datatyper, CTE, vinduesfunktioner) - MS SQL Server: God, men med mange vendor-specifikke udvidelser (T-SQL) - MySQL/MariaDB: Mere pragmatisk end strengt standardorienteret, tidligere kendt for svagere ACID-overholdelse (afhænger af engine: InnoDB vs MyISAM) ---- ### Funktioner - PostgreSQL - JSONB, GIS, avancerede datatyper - Extensibility: egne funktioner, operators - MS SQL Server - Integration med Microsoft stack (Azure, .NET) - Stærke BI-værktøjer [SSRS, SSIS, SSASS](https://medium.com/@pwmrangana/what-why-ssis-ssas-ssrs-d86ea9d739ad) - MySQL/MariaDB - Simpelt setup, udbredt i webapps - MariaDB tilføjer flere features (Cassandra-engine, tidsserier, collation improvements) ---- ### Performance og skalerbarhed - **PostgreSQL**: Skalerbar, stabil, stærk i OLTP & OLAP - **MS SQL Server**: Enterprise performance, clustering, in-memory OLTP - **MySQL/MariaDB**: Hurtig til læse-intensive workloads, mindre stærk til komplekse queries ---- ### Ecosystem & værktøjer - **PostgreSQL**: pgAdmin, stærkt open source community - **MS SQL Server**: SSMS + Azure Data Studio, Azure Integration - **MySQL/MariaDB**: MySQL Workbench + phpMyAdmin + mange andre ---- ### Anvendelsesområder - **PostgreSQL**: Kompleks dataanalyse, fintech, GIS, enterprise open source - **MS SQL Server**: Store virksomheder, enterprise apps, Windows-ecosystem - **MySQL/MariaDB**: Webapps, CMS (WordPress, Joomla, Drupal), startups ---- ### Comparison | Faktor | PostgreSQL | MS SQL Server | MySQL/MariaDB | | :----- | :--------: | :-----------: | :-----------: | | Licens | Open Source | Proprietær (gratis Express) | Open Source | | OS Support | Linux, Windows, macOS | Windows & Linux (macOS via Docker) | Linux, Windows, macOS | | SQL-standard | Meget høj | Høj (T-SQL-udvidelser) | Middel | | JSON | Ja (native JSON/JSONB) | Ja (funktioner; tekstlagring) | Ja (JSON-type/alias) | | Udvidelser | Mange extensions | Begrænset (CLR, features) | Færre; MariaDB flere | | Performance | Allround OLTP/OLAP | Enterprise-tunet, in-memory | Hurtig til web/læsninger | | Typisk brug | Kompleks data, GIS, fintech | Enterprise/BI, .NET/Windows | Webapps, CMS, startups | --- # Quiz tid 30 min. Udelad at bruge internet/AI osv. – quizzen bruges til at placere jeres grundviden. --- ## Joins ---- ### Hvilket join er dette? Hvornår bruges det?  ---- ### Inner Join - **Definition**: Returnerer kun de rækker hvor der er et match i begge tabeller - **Brugssituation**: Når du kun vil have de data, der findes i begge tabeller - **Eksempel**: Find kunder, der har lagt ordrer  ---- ### Hvilket join er dette? Hvornår bruges det?  ---- ### Left Join (inclusive) - **Definition**: Returnerer alle rækker fra venstre tabel, samt matchende rækker fra højre tabel - **Brugssituation**: Når du vil have alle rækker fra venstre tabel, også selvom der ikke er tilknyttede data i højre tabel - **Eksempel**: Find alle kunder, også dem uden ordrer  ---- ### Hvilket join er dette? Hvornår bruges det?  ---- ### Left Join (exclusive) - **Definition**: Kun rækker i venstre tabel uden match i højre - **Brugssituation**: Når du vil finde forskelle mellem tabeller - **Eksempel**: Find kunder uden ordrer  ---- ### Hvilket join er dette? Hvornår bruges det?  ---- ### Full Join - **Definition**: Returnerer alle rækker fra begge tabeller – med NULL hvor der ikke findes match - **Brugssituation**: Når du vil se alle data, både de matchende og de ikke-matchende - **Eksempel**: Sammenlign to lister over kunder fra forskellige systemer  ---- ### Hvilket join er dette? Hvornår bruges det?  ---- ### Outer Join - **Definition**: præciseringen af at man tager alle rækker fra en side (eller begge) - **Brugssituation**: Når du vil finde rækker der ikke er joinede - **Eksempel**: Hente brugere der ikke har ordrer og ordrer der ikke har brugere  ---- ### Right Join   --- ## Keys (nøgletyper i databaser) ---- ### Hvilke nøgler kender I? ---- ### Primary Key (PK) - **Definition**: En kolonne, der unikt identificerer rækken - **Egenskaber**: - Skal være unik - Må ikke være `null` - Kun én primær nøgle pr. tabel - **Brug**: Identifikation af posteringer (fx `customerId`) ---- ### Foreign Key (FK) - **Definition**: En kolonne i én tabel, der refererer til en Primary Key (eller Unique Key) i en anden tabel - **Egenskaber**: - Sikrer referentiel integritet - Kan tillade `null`, afhængig af design - **Brug**: Relationer mellem tabeller ---- ### Composite Key - **Definition**: En primær- eller kandidatnøgle, der består af flere kolonner sammen - **Brug**: Når ingen enkelt kolonne er unik alene (fx `(StudentID, CourseID)` i en Enrollments-tabel) ---- ### Candidate Key - **Definition**: En kolonne eller kombination af kolonner, der kunne være en primærnøgle - **Egenskaber**: - En tabel kan have flere candidate keys - Én vælges som Primary Key - **Brug**: Designfase til at vælge bedste nøgle (fx både `email` og `customerNumber`) ---- ### Unique Key - **Definition**: En constraint, der sikrer at en kolonne (eller kombination) har unikke værdier - **Egenskaber**: - En tabel kan have flere unikke keys - **Brug**: Typisk candidate keys, der ikke er valgt som PK ---- ### Surrogate Key - **Definition**: En kunstigt oprettet nøgle (auto-increment eller UUID), uden funktionel betydning for databasen - **Brug**: Forenkler relationer og undgår afhængighed af naturlige nøgler (fx CustomerID i stedet for CPR-nummer)