2024-05-06: Pre-workshop Hell-Tech
Presentasjon
Følgende .h2-overskrifter representerer powerpoint-slides som skal brukes i workshoppen.
Velkomstslide (1 min)
Agenda
Intro til datamodellering (noe skal kanskje => lyntale?)
Modellering vs implementasjon
Raske iterasjoner
Visuelt paradigme som gjør det enkelt å involvere ikke-tekniske
Målet er i første omgang å lære så mye som mulig så fort som mulig
Man må forvente radikale endringer i modellene etterhvert som man lærer
Man øker først detaljnivået etterhvert som strukturene stabiliserer seg
Jo mindre stabilt, jo dyrere er det å detaljere (for ikke å snakke om programmere)
Man bruker tankeeksperiment underveis for å teste hypoteser
Kan lage fysiske prototyper dersom nødvendig (først og fremst som innspill til logisk modell)
Ta gjerne utgangspunkt i prosessene som modellen skal underbygge
Notasjon
“Kråkeføtter“
Heltrukne relasjoner er identifiserende
Stiplede relasjoner er rene referanser
Vi opererer ikke med mange-til-mange relasjoner i denne sammenheng
Relasjoner har en eier (i én-enden) og et medlem (i mange-enden)
Eier kan være påkrevet (tverrgående strek) eller valgfri
Er mye bra å hente fra https://cmpct.info/~calvin/Papers/Data and Reality.pdf her knyttet til det mer filosofiske aspektet om hva datamodellering dreier seg om.
Det relasjonelle paradigmet
Flat (ikke nøstet) struktur
DRY (normalisering – “én ting på ett sted“)
Hvordan informasjonen henger sammen, uavhengig av applikasjoner
Optimaliserer for integritet, konsistens og gjenbruk
Verdi- vs. objektsemantikk (naturlige vs. kunstige nøkler)
Relasjonsmodellen er laget for det første
Analogt med funksjonell vs. objektorientert programmering
En tabell er en funksjon fra nøkkel til verdier
Kraftig spørrespråk som kan transformere data på vei ut av databasen
Vanlige feiloppfatninger
Dårlig ytelse
Databasen må beskyttes fra kompliserte spørringer pga skaleringsproblematikk
Det er dyrt å joine (må denormalisere for å få det til å gå rundt)
Kompleksitet
"Det er for vanskelig å tenke prinsipielt – må konsentrere oss om det vi trenger nå"
Object-relational mismatch gjør det unødvendig komplisert å utvikle mot
“Big design up front“
Bruker altfor mye tid i starten uten å få gjort noe fornuftig
Lenker
https://aws.amazon.com/blogs/aws/a-decade-of-ever-increasing-provisioned-iops-for-amazon-ebs/
PostgreSQL Performance Improvements - Part 1: Tracking PostgreSQL Performance Across Versions
Case: Filmstjerner i sikte
Starte med enkelt IMDB-case (i prosa)
Innhold
Kodetabeller
N:M-koblingsbokser
Kardinalitet, identifiserende/referanser
Rolle (flere relasjoner til samme entitet)
Introdusere tillegg etterhvert
Innhold
Hva er forskjellen på subtyping og roller?
Alt-i-ett (roller krever denormalisering)
Bladnoder (subtyping krever triggerlogikk)
Alle noder (subtyping krever triggerlogikk)
Konseptuelt => logisk nivå
Lage ferdige alternative case – samme modell med:
Naturlige nøkler
Kunstige nøkler
Konsekvenser
Konsistens/integritet
Spørremønstre
Godbiter hvis tid?
Hvordan modellere matematiske strukturer
Tre
Kjede (1:1 egenrelasjon)
Matrise
Like akser
Forskjellige akser
Flere enn 2 dimensjoner
Hvordan modellere vekk NULL-verdier
Dummyverdier
1:1-normalisering
Forvaltning over tid
Out of scope
Kontinuerlige endringer
Notater
Flette inn fra ymse kilder
Hente fra diskusjon (2024-02-27)
Hente fra eksempeldata (2024-04-23)
Hente fra prinsipper for datamodellering