DFDG er meget datatung. Modellering af data er derfor meget vigtig. Dette afsnit beskriver generelle retningslinjer for modellering af databasetabeller. Det primære fokus er tabeller hvor der er tæt på en 1:1 til entiteter i domænemodellen, dvs. fokus er ikke på styretabeller.
NB! Hvis du ikke arbejder med DFDG Classic bør du formodentlig se på /wiki/spaces/CITY/pages/1654718588 og /wiki/spaces/CITY/pages/1654587579 siderne i stedet for denne.
| Table of Contents |
|---|
Navngivning af databasetabeller og kolonner
Der anvendes engelske navne, med CamelCase. Tabeller bør placeres i Schema som følger opdelingen i Byggeblokke/domæner. Se også under History tabeller, hvor der tilføjes History til navnet.
Navngivningen af kolonner bør følge domænemodellens elementer og attributter (fra C# koden). Navnene oversættes til engelsk og CamelCase anvendes.
Fact- og historik-tabeller i DFDG Classic (Revisionslog)
(Ift. ny forretningsapplikationer / siloer er dette beskrevet i /wiki/spaces/CITY/pages/1654718588 )
Generelt skal alle ændringer til data som indgår i sagsbehandling gemmes, så det er muligt at finde tilbage til tidligere versioner af data. Dette for alle tabeller der indeholder sagsrelaterede data. Systemtabeller og andre styringstabeller kan typisk undvære historiktabeller så længe registreringer logges. Se mere om historik og logning:
Det anbefales at der opereres med to typer tabeller:
Fact-tabeller,
History-tabeller, navngives som <Onlinetabelnavn> + History
Til alle Fact-tabeller oprettes en History tabel, hvori alle inserts, update og delete operationer registreres, samtidig med at den resulterende record ligger tilbage i Fact-tabellen samt i History-tabellen. Ved sletning fjernes recorden fra Fact-tabellen. Fact-tabellen indeholder på den måde alt der endte med at blive til noget.
Kolonner i Fact-tabellen
Tabellen indeholder følgende ekstra data udover de data som findes i online tabellen:
Kolonnenavn | Type | Detaljer | Forekomst | Beskrivelse |
|---|---|---|---|---|
EntitetIdentifier | GUID (Primary key) | 1 | Entitet er entitetsnavnet | |
Alle kolonner fra entitet | EntitetType | 1 | ||
Metadata-felter | 1 | Se liste af metadata-felter nedenfor |
Kolonner i History-tabellen
Tabellen indeholder følgende ekstra data udover de data som findes i online tabellen:
Kolonnenavn | Type | Detaljer | Forekomst | Beskrivelse |
|---|---|---|---|---|
EntitetHistoryIdentifier | GUID (Primary key) | 1 | Entitet er entitetsnavnet | |
Alle kolonner fra entitet | EntitetType | 1 | ||
Metadata-felter | 1 | Se liste af metadata-felter nedenfor | ||
Operation | tinyint | 1 | 1=Created, 2=Update, 3=Delete, ved Delete sættes LastUpdatedByxxx felterne i den originale struktur. |
Read operationer logges ikke i revisionsloggen, men logges i stedet i systemloggen i logfil, se:
...
Kolonnenavn | Type | Detaljer | Forekomst | Beskrivelse |
|---|---|---|---|---|
EntitetIdentifier | GUID (samme key som i online tabel) | 1 | Entitet er entitetsnavnet | |
ActiveOrganisationTypeIdentifier | OrganisationTypeIdentifierType Base: Byte | 1 | Den myndighed som der er registreret på vegne af (v/ AA: som brugeren har impersonated). Det er den ansvarlige myndighed | |
ActiveOrganisationCode | String | Length: 1-20 | 1 | Koden som identificerer organisationen. Det kan være Jobcenternummer, et CVR nummer, en a-kassekode eller en kommunekode. Det er den ansvarlige myndighed |
UserFullName | UserFullNameType Base: String | Length: 1-140 | 1 | Brugers fulde navn, ved systemkald angives systemets og jobbets navn her. |
RequestUserTypeIdentifier | Base: Byte | 1 | Kodeliste med brugertyperne:
| |
UserIdentifier | UserIdentifierType Base: String | Length: 1-255 | 1 | Unik identifikation af brugeren, f.eks. en GUID, et medarbejder ID, system ID, bruger ID, certifikat ID, cpr-nummer, email (hvis den er unik) o.l. Afhængigt af RequestUserTypeIdentifier udfyldes feltet med:
|
UserEmail | EmailAddressIdentifierType String (E-mail) | Length: 2-256 Pattern: ([^>\(\)\[\]\\,;:@\s]{0,191}@[^>\(\)\[\]\\,;:@\s]{1,64}) | 0-1 | Brugerens e-mail adresse |
UserOrganisationTypeIdentifier | OrganisationTypeIdentifierType Base: Byte | 1 | Kodeliste som identificerer typen af organisationen som brugeren hører til. Dette er en kodeliste, dog som integer af historiske årsager. | |
UserOrganisationCode | String | Length: 1-20 | 1 | Koden som identificerer organisationen som brugeren hører til. Det kan være et Jobcenternummer, CVR nummer, en a-kassekode eller en kommunekode. |
CreatedDateTime | Erstattes af DFDGRegistrationDateTime | |||
UpdatedDateTime | Erstattes af DFDGRegistrationDateTime | |||
RegistrationDateTime | Udgår! (Eksternt registreringstidspunkt) | |||
DFDGRegistrationDateTime | DateTime | 1 | Registreringstidspunkt i DFDG | |
CorrectionComment | String | Length: 0-1500 | 0-1 |
...
Ved konvertering fra CreatedDateTime+UpdatedDateTime til DFDGRegistrationDateTime bruges CreatedDateTime som datagrundlag for DFDGRegistrationDateTime for create metoder og UpdatedDateTime for update metoder.
ID'er (nøgler og fremmednøgler)
Generelt anvendes GUID'er som ID i tabeller. For tabeller, der er normaliseret ud i flere tabeller, hvor undertabeller blot anvendes som lister i hovedentiteten, kan det være en fordel at anvende integer ID'er istedet for GUID'er. Integer ID'er må dog ikke eksponeres via webservices.
Tabeller der indeholder persondata (CPR-nummer eller PersonId)
...
På nye tabeller med persondata skal der anvendes PersonId istedet for CPR-nummer, ved ændring af eksisterende tabeller med CPR-nummer bør der omlæsse til PersonId.
Index'es
Lav et effektivt clustered index, f.eks. ved at inkludere CPR-nummer/PersonId i indexet.
Lav altid et clustered index. Tabeller uden clustered index kaldes Heaps.
...
Når man har oprettet database strukturen, og kørt Scaffold-DbContext, så:
check om entiteterne giver mening!!!
Mange til mange relationer
Når man laver mange til mange relationer, bør den tabel, som relationen gemmes i KUN indeholde foreign-key til de to tabeller, som har relationen. Og disse to foreign keys, skal udgøre relationtabellens primary key. Hvis relationstabellen har sin egen primary key, som ikke er de to foregn keys, så genererer scaffolderen en entitet til relationen og gør c# entiteterne mere komplekse, at arbejde med. Der er ingen grund til at der oprettes entiteter (i C#) til relationer, medmindre man specifikt har behov for det. EFCore kan sagtens finde ud af det, hvis relationen er sat korrekt op. Nedenstående eksempel, anviser hvordan man kan sikre at
...
| View file | ||
|---|---|---|
|
Dokumentation
Alle tabeller og kolonner dokumenteres via Extended Properties, MS_Description.
Teknologi og udviklernoter
Versionsstyring
Modellen for databasen og de enkelte tabeller skal versionsstyres på lige fod med koden. Dette kan på Microsoft SQL og .NET platformen med fordel foregå ved et af følgende tekniske tiltag:
Scripting, hvor scripts versionsstyres
Entity Framework Migrations, hvor strukturen ligger i koden med mulighed for at opgradere
...