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?

• Forskjellige typer/varianter av datamodellering

  • Database

    • Normalisert – “vanlige“ systemer (“operational systems“/”OLTP”)

      • Notasjoner

        • Entity-Relationship (“kråkeføtter“)

        • NIAM/ORM (utgangspunkt for FS og SODA)

      • Nivåer

        • Konseptuell

        • Logisk

        • Fysisk

    • Stjerne – datavarehus/analyse (“OLAP“)

    • Dokument

  • Tekstbasert

    • XML, JSON…

    • GraphQL

    • …

• Perspektiver på datamodellering

  • Dataintegritet

  • Ytelse

  • Enkelt å utvikle mot

  • Enkelt å forstå for forretningssiden

  • Top-down/bottom-up

• Historikk

  • To systemer som har overlevd i 30 år

• Prinsipper

  • Generelle

    • Normalisering (“én ting på ett sted“)

    • Unngå sykler

  • Våre

    • Generalisering/abstraksjon (forretningsregler i data fremfor i kode)

    • Naturlige nøkler

    • Datanære forretningsregler i databasen

    • 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