Workshop-format
Case?
“Grunnmur” eller GraphQL (presentasjonslag), eller begge deler
Hvor tett på basen? Eller mer abstrakt på “logisk” datanivå?
Quiz, s.u. - passe på ikke for mye forlesning, passe mye overkommelig interaktivt med deltakerne
Hvem lager den mest effektive sqlen?
Fra prosess til applikasjon - lite prosjekt men vise veien og hvordan vi tenker.
Er testdata/kode for generering av testdata en del av databasekoden som må lages?
Hvordan tester man databasekode/triggere?
Lyntale
Hva er datamodellering, og hvorfor driver vi med det?
Dataintegritet/-kvalitet
Begrepsavklaring
Diskutere/kommunisere hvordan en del av verden “ser ut“
Ytelse
Forskjellige typer/varianter av datamodellering
Database
Normalisert – “vanlige“ systemer (“operational systems“/”OLTP”)
Rettet mot
Hyppige, mindre oppdateringer i parallell
Enkel rapportering
Notasjoner
Entity-Relationship (“kråkeføtter“)
NIAM/ORM (utgangspunkt for FS og SODA)
Nivåer
Konseptuell
Logisk
Fysisk
Stjerne – datavarehus/analyse (“OLAP“)
Rettet mot
Tunge spørringer
Batch-oppdateringer
Begreper
Faktatabeller
Dimensjonstabeller
Dokumentdatabaser
Graf-databaser (Facebook, …)
Tekstbasert
XML, JSON…
GraphQL
…
Perspektiver på datamodellering
Dataintegritet
Gjenbrukbarhet
Ytelse
Enkelt å utvikle mot
Enkelt å forstå for forretningssiden
Enkelt å utvide
Top-down/bottom-up
Datamodellering er en egen greie – ikke bare fasilitering av utvikling
Historikk
To systemer som har overlevd i 30 år
Prinsipper
Generelle
Normalisering (atomiske verdier, én ting på ett sted)
Unngå sykler
Våre
Naturlige nøkler
Forretningsregler for dataintegritet i databasen
Deklarativt (constraints) der man kan
Vedlikeholde integritet (stoppe ugyldige oppdateringer)
Imperativt (triggere) der man må
Vedlikeholde integritet som ikke kan uttrykkes deklarativt
Trigge andre endringer (kan også gjelde tekniske ting som logging o.l.)
Generalisering/abstraksjon (semantiske forretningsregler i data fremfor i kode)
Kodetabeller (istf. f.eks. ENUMs)
Momenter fra seksjonsmøte
🔄 Prinsipper vi har landet på i Studieadministrasjon og hvorfor
Normalisering for datakvalitet, gjenbrukbarhet og utvidbarhet
🔄 GraphQL-biten er mer applikasjonsnært, hvordan endrer dette hvordan vi tenker?
🔄 Det samme gjelder kanskje stjerne-modellering for datavarehus
Hvordan setter man dette opp i en base
Hvordan setter man opp søk
Andre krav til systemet
Hva med ytelse?
Relasjonelle databaser og dokumentdatabaser
Finne en case for workshop
Modellerer man underveis så blir rekkefølgen man utvikler applikasjonene i førende for den resulterende modellen
Man tenker ikke bredt nok fra begynnelsen av
Tror ikke navnestandarder er viktige (skjønner man først etter noen år)
To forskjellige måter å tenke på, gjør det vanskelig å samarbeide
Vanskelig å lage en solid grunnmur når man er omringet av ivrige snekkere som vil hamre!
Applikasjonsutviklere tenker “hva har jeg bruk for akkurat nå”
Databaseutviklere tenker “hva kommer vi til å få bruk for om 5 år”
Utvidbarhet er helt nødvendig for å lykkes
Vi må forsøke å rive ned siloene/leir-tankegangen, ved å involvere applikasjonsutviklerne på et tidligere stadium.
Hva med ytelse?
Quiz! Gjett ytelsen!
“Joins er dyrt!” – Alle utviklere som ikke stoler på databasen sin.
Tips og triks for forbedring av ytelse.
Hva med historikk og audit
Modellere eksplisitt eller finnes det “verktøystøtte”
Hva med logger og køer?
Fordeler og ulemper med å bruke tabeller i databasen
Databasen er et utviklingsverktøy
Fremmed måte å tenke på for mange
Man kan likevel gjøre moderne utvikling/devops osv
Hva med forretningslogikk?
Hva bør vi legge hvor?
Relasjonelle databaser er gode på å datakvalitet og datasikkerhet
Det kommer alltid til å skje ad-hoc SQL
For fagsystem → datakvalitet über alles
Hva med testdata?
Kan man bruke databaseskjemaet til å generere testdata?
CHECK-constraints kan bidra til å
Bruk av data til å generere kode
Bruke katalog-tabellene i databasen
Egne katalog-tabeller som beriker dette ytterligere