Denne side beskriver obligatoriske principper for modellering og strukturering af databaser i STAR City.

Retningslinjerne gælder for:

• Nye forretningsdomæner

• Nye tabeller i eksisterende forretningsdomæner

• Omlægning af eksisterende datamodeller

Formålet er at sikre:

• Entydig identifikation af forretningsobjekter

• Konsistent historik og revisionsspor

• Klar adskillelse mellem tekniske og forretningsmæssige nøgler

• Ensartet praksis på tværs af udviklingsteams

Gældende dokumentation for metadata og historik findes i:

• https://starwiki.atlassian.net/wiki/spaces/CITY/pages/1654718588

• https://starwiki.atlassian.net/wiki/spaces/FYS/pages/1561461816

Denne side beskriver de databaserelaterede principper, som skal anvendes i STAR City.

Alle forretningsdata, der indgår i sagsbehandling, skal kunne rekonstrueres historisk.

Der arbejdes med to typer tabeller:

1. Fact-tabeller

2. Historik-tabeller (navngives: <FactTabelNavn>History)

For hver Fact-tabel skal der oprettes en tilhørende Historik-tabel.

Fact-tabellen indeholder:

• Den aktuelle (gældende) version af entiteten

• Den tekniske primærnøgle (int)

• Forretningsmæssig identifikation (ExternalIdentifier)

• Aktuel versionsidentifikation (ExternalVersionIdentifier)

• Obligatoriske metadatafelter jf. Star.Foundation

Fact-tabellen indeholder altid den seneste gældende version.

Ved sletning fjernes rækken fra Fact-tabellen.

En Fact-tabel kan indeholde flere forekomster for samme borger (PersonId), fx flere kontaktgruppeforløb.

Historik-tabellen indeholder:

• Alle tidligere versioner

• Indsættelser, opdateringer og sletninger

• Samme datamodel som Fact-tabellen

• Metadata inkl. operationstype

Hver ændring skal resultere i:

• Opdatering af Fact-tabellen

• Indsættelse af ny række i Historik-tabellen

Read-operationer logges ikke i revisionshistorikken, men i systemlog jf. gældende logningsprincipper.

Metadatafelter beskrives centralt i: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/1654718588

Dette er en normativ og gældende standard for STAR City.

• Primærnøgler i databasen skal være interne integers

• Fremmednøgler skal være interne integers

• Interne nøgler må aldrig eksponeres via API’er

Hver forretningsentitet skal have:

• Er entitetens forretningsmæssige unikke nøgle

• Er immutable

• Er globalt unik

• Eksponeres i API’er

• Anvendes REST-mæssigt til at pege på en entydig entitet

ExternalIdentifier ændres aldrig i entitetens levetid.

• Identificerer en konkret version af entiteten

• Genereres ved enhver ændring

• Opdateres ved:

  • Create

  • Update

  • Forretningsmæssig korrektion

• Eksponeres efter behov (fx ved historiske opslag)

ExternalVersionIdentifier muliggør opslag på:

“Hvordan så entiteten ud på et givent tidspunkt?”

Denne adskillelse er obligatorisk og må ikke fraviges.

CPR-nummer må ikke anvendes som primær identifikation i databaser.

PersonId er den eneste tilladte tekniske identifikation af en borger i databasen.

Brugen af PersonId er ikke valgfri.

Følgende gælder:

• PersonId skal anvendes i alle tabeller, hvor der refereres til en borger.

• PersonId skal anvendes som foreign key ved relation til borger.

• CPR-nummer må ikke anvendes som nøgle eller reference i nye tabeller.

• CPR må kun anvendes som oplysning, hvor det er forretningsmæssigt nødvendigt og reguleret.

Hvert forretningsdomæne har et PersonId, som entydigt peger på en borger inden for domænet.

PersonId:

• Er stabilt inden for domænet

• Er uafhængigt af CPR-nummer

• Ændres ikke ved CPR-skift

• Må ikke eksponeres ukontrolleret

Eksisterende tabeller med CPR-nummer skal ved ændringer eller videreudvikling omlægges til PersonId.

Der må ikke oprettes nye løsninger, der baserer relationer på CPR-nummer.

• Engelske navne

• CamelCase

• Placering i korrekt schema iht. byggeblok/domæne

• Historiktabeller navngives: <FactNavn>History

• Følger domænemodellens attributter

• Engelske navne

• CamelCase

• Metadatafelter følger Star.Foundation standard

• Alle tabeller skal have et clustered index

• Heaps må ikke anvendes, medmindre der foreligger særlig begrundelse

• Foreign keys skal som udgangspunkt have index

• Undtagelse: reference til små kodelistetabeller

Vurdering skal baseres på:

• Forventet datamængde

• Query-mønstre

• Performanceanalyse

For at sikre korrekt og konsistent indeksering skal følgende anvendes:

• Der skal foretages systematisk kontrol af foreign keys uden tilhørende index.

• Der skal foretages analyse af potentielle indexkandidater baseret på SQL Servers indbyggede statistik.

Til dette formål skal det fælles STAR-script anvendes:

Scriptet identificerer:

• Foreign keys uden tilhørende index

• Potentielle indexkandidater baseret på brugeradfærd og query-omkostninger

Ved vurdering af foreslåede indexkandidater skal der særligt ses på:

• AvgUserImpact

• AvgTotalUserCost

• IndexAdvantage

Det er ikke et krav, at alle foreslåede indexkandidater implementeres.
Der skal foretages en konkret arkitekturmæssig vurdering baseret på:

• Datamængde

• Query-mønstre

• Samlet performancepåvirkning

Foreign keys til små kodelistetabeller skal som udgangspunkt ikke indekseres.

Relationstabeller skal:

• Kun indeholde de to foreign keys

• Have composite primary key bestående af disse

• Ikke have egen surrogate key

Der må ikke genereres unødvendige entiteter i domænemodellen.

Alle tabeller og kolonner skal dokumenteres via:

• Extended Properties (MS_Description)

Databasemodellen skal versionsstyres på linje med applikationskode.

SQL Server Query Store skal være aktiveret på alle databaser i STAR City.

Formål:

• Overvågning af performance

• Identifikation af regressionsproblemer

• Analyse af eksekveringsplaner

Open