Workshop-format
Hva må være på plass for å gjennomføre workshop:
verktøy (er det mulig å bruke sql developer i nettleser?)
dbeaver?
Ansvarlig: Geir tester sqldeveloper. Kai gjør et søk på alternativerdatabase med data
Vi kan finne en filmdatabase på nett kanskje
https://www.w3resource.com/sql-exercises/movie-database-exercise/joins-exercises-on-movie-database.php#google_vignette
- Finne eksempeldatabase og se om det er mulig å bruke den i vårt valgte verktøy (Geir)
- trekke ut modellen i valgt verktøy (Kai)
- lage en pakke som folk kan installere (Daniel)
en for mac, unix og microsoftoppgaver - hva skal vi få de til å gjøre
Ansvarlig: KaiOrganisere: Kalle inn til møter - lage dokumentasjon.
Ansvarlig: Kari
“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
Tap av dette kan bli vanvittig dyrt, og kanskje ikke en gang mulig, å rette opp i ettertid
Begrepsavklaring
Kommunikasjon ml. utviklere/arkitekter/ikke-teknikere om hvordan en del av verden “ser ut“
Ytelse (det er en myte at normaliserte modeller gir dårlig 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
Man klarer ikke forutsi alle bruksområder for dataene i fremtiden
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