...
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
Det relasjonelle paradigmet
Optimaliserer for integritet, konsistens og gjenbruk
DRY (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“)
Handler om hvordan 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 ikke-nøkkelverdier
Kraftig spørrespråk som kan transformere data på vei ut av databasen
Vanlige feiloppfatninger
Dårlig ytelse
Det er dyrt å joine
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
...
Entiteter
...
Film
...
(i prosa)
Regissør
Distributør
Metodikk – valg
Prosa?
UML?
InnholdInnhold
Kodetabeller
N:M-koblingKodetabellkoblingsbokser
Kardinalitet, identifiserende/referanser
Rolle (flere relasjoner til samme entitet)
Introdusere tillegg etterhvert
Subtyping/roller
Entiteter – Person
Produsent
Skuespiller
MetodikkHva er forskjellen på subtyping og roller?
Alt-i-ett (roller krever denormalisering)
Bladnoder (subtyping krever triggerlogikk)
Alle noder (subtyping krever triggerlogikk)
Innhold
Konseptuelt => logisk nivå
...