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å alternativer

• database 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 microsoft

• oppgaver - hva skal vi få de til å gjøre
  Ansvarlig: Kai

• Organisere: 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)

  • Datamodellering er en “egen greie“, ikke bare fasilitering av applikasjonsutvikling

    • Beskriver forretningsregler/en del av verden bedriften befatter seg med – på “kanonisk” form

      • Også til fremtidig bruk vi ikke aner noe om nå

• 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