Flette inn fra ymse kilder

• Hente fra diskusjon (2024-02-27)

• Hente fra eksempeldata (2024-04-23)

• Hente fra prinsipper for datamodellering

Lage intro

• Rekapitulere prinsipper

Lage case

Starte med enkelt IMDB-case

...

Entiteter

• Film

• Kritikk (antall stjerner)

• Regissør

• Distributør

...

Metodikk – valg

• Prosa?

• UML?

Innhold

...

N:M-kobling

...

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/

• https://www.enterprisedb.com/blog/performance-comparison-major-PostgreSQL-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

• Subtyping/roller

• Entiteter – Person

  • Produsent

  • Skuespiller

Metodikk

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

...

• 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