Normale formularer er ikke kun til databaser

Du kan også anvende lignende regler på dataobjektyper.

Du har sandsynligvis lært udtrykket Normal form i sammenhæng med at definere skemaer for relationsdatabaser. Databasens normalisering stræber efter at reducere dataredundans i tabelrækker og kolonner. Derfor er der mindre sandsynlighed for, at data anomalier forekommer.

Hvad er en dataanomali?

Antag, at vi havde denne situation:

Tabel A indeholder værdier for egenskaberne X, Y, Z for en række identificeret ved id for x ; dette er påstande om x. Lad os sige, at Y i række x hævdes at være værdien 3.

Tabel B indeholder også de samme påstande om, hvorfor Y for x

Tabel A fortælles senere, ”Fakta er ændret. Y er nu 4 ”

Tabel B bliver senere spurgt og siger, at Y stadig er 3.

Nu hævder A og B to forskellige fakta om Y, afhængigt af hvilken tabel du forespørger om.

Det er en dataanomali: to forskellige påstande om en kendsgerning. Og fakta betyder noget i computersystemer.

Hvad og hvad med normale former

Jeg bruger udtrykket type til at betegne metadataene for et objekt. Dette kunne implementeres ved hjælp af en klassedefinition, mixin, træk, stempel eller hvilken mekanisme din præference og dit valgte sprog understøtter. Jeg vil også fokusere på dataobjekter , såsom POJO'er, PODO'er, JSON og lignende enkle objekter.

Angivet uformelt er de første tre normale former beskrevet som følger:

Første normale form (1NF): Ingen gentagne elementer eller grupper af elementer

Anden normal form (2NF): Alle ikke-nøgleattributter er afhængige af alle nøgler

Tredje normal form (3NF): Ingen afhængighed af ikke-nøgle attributter

Det er ret tør læsning. Men at anvende disse principper på objekttypedefinitioner er faktisk ret intuitivt. Når du først har internaliseret disse regler, tænker du ikke engang bevidst om dem igen.

Objekter er også relationelle

Relationelle databaser understøtter foreninger gennem primære og udenlandske nøglebegrænsninger. Hierarkier er implicitte, hvis de overhovedet findes. Foreninger er løsere end hierarkier og taksonomier, men også sværere at tænke på.

I et hierarki har du forældre-barn-forhold. Der er ofte et hierarki af datatyper også (klasse-underklasse), som også er modelleret. Forhold i et objektindeslutningshierarki er mere begrænset, generelt envejs (forælder til barn), men også lettere at forstå end en mere generel (og fleksibel) tilknytning.

1NF: Ingen gentagne elementer eller grupper af elementer

Sig, at vi har følgende kontaktoplysninger:

Hvor er de gentagne elementer?

  1. Navneegenskaber: dette kan betragtes som et en-til-mange forhold, hvor antallet af navne er ubestemt (såsom britisk royalty). I praksis er dog første, sidste og muligvis mellemnavn tilstrækkeligt til de fleste applikationsdomæner, så der er ikke noget reelt behov for at normalisere disse felter.
  2. telefoner: Gentagelsen af ​​telefonattributter ligner et potentielt problem: er to telefoner nok? Og hvad hvis yderligere oplysninger senere er knyttet til telefonnummeret, f.eks. Ledig tid?
  3. adresselinjer: igen, er to nok? I nogle lande kan gadeadresser være fire linjer lange, men det er grænsen. Da de er enkle strenge, er det ingen tragedie, hvis en eller to adresselinjer tilføjes senere.

Her er en mulig model med kontakt- og telefontyper:

2NF: Alle ikke-nøgleattributter er afhængige af alle nøgler

Hvad betyder dette på almindelig engelsk? I en database betyder det, at alle kolonner i en række skal være direkte afhængige af eventuelle kandidatnøgler i den række.

Så lad os se på Kontakt igen:

Her er nøglen en genereret id-værdi, undertiden omtalt som en surrogatnøgle. Er adresseattributterne afhængige af kontakt-id? Godt…

Det hele afhænger af domænet.

De seks adresseegenskaber er bestemt ikke attributter for kontakten, men snarere midler til at identificere en fysisk placering. Det er muligt, at en kontakt kan have mange adresser, og måske har en adresse mange kontakter.

Bør dette modelleres som et mange-til-mange forhold med en ContactAddress-objekttype, der har et kontakt-id og et adresse-id? Det afhænger af, hvad der er vigtigt for dit applikationsdomæne. Nogle applikationer behandler muligvis Kontakter som stærke enheder uafhængigt af Adresse, men Adresser som svage enheder, afhængigt af en Kontakt for eksistens. I så fald kan en kontakt have mange adresser, og hver adresse henviser til en kontakt som denne:

Der er en mulig datainomali: Hvis du ændrer adressen for en kontakt, ændrer du ikke den samme adresse for alle kontakter. Hvis Kontakt er din primære kilde til reference, kan det være den ønskede adfærd: din kontakt flytter (til en anden organisation, siger), og de resterende kontakter forbliver på plads.

3NF: Ingen afhængighed af ikke-nøgle attributter

Når du ser på Adresse igen, kan du måske se de to afhængige felter, region og land. Et land har måske ikke regioner, men en region har et land: du vil ikke blande dem sammen.

En måde at sikre, at regionen hører til det rigtige land, er at oprette en identifikator for hvert (land, region) par, hvorefter adressen henviser til identifikatoren snarere end til region og land uafhængigt:

Et ord om genererede identifikatorer

Efter min mening er genererede identifikatorer en implementeringsdetalje og er virkelig kun nødvendige af klientkode, når man ændrer eller sletter en back-end-post (såsom en række i en database), men aldrig som en del af en skrivebeskyttet forespørgsel. De skal heller ikke ses af brugeren af ​​systemet, fordi de er meningsløse.

Tabel pr. Type, tabel pr. Typehierarki

Den pæne ting ved normaliserede objekttyper er, at de let kortlægges til relationsdatabasetabeller. For en relationel databaseimplementering spejler tabeller objekttyperne (tabel pr. Type) eller indeholder i det mindste information for flere typer afledt af en basistype (tabel pr. Typehierarki). Dette lyder måske som om jeg går ind for Object-Relational Mapping, men nej ... Jeg siger bare, at det er gavnligt at have din logiske model til at dele de samme egenskaber som den fysiske model i en konceptuelniveau. Implementering er et helt andet emne.

Referencer

Der er rigelige ressourcer til normalisering af relationsdatabaseskemaer:

Databasens normalisering: Første, anden og tredje normale formular - Andrew Rollins

Jeg læste en god forklaring på første, anden og tredje normale form for et par uger siden. For dem der ved hvilken database ...

www.andrewrollins.com

Database anden normal form forklaret på enkel engelsk

Det andet indlæg fokuserede på den første normale form, dens definition og eksempler for at hamre den hjem. Nu er det tid til ...

www.essentialsql.com

Hvad er anden normal form (2NF)? - Definition fra Techopedia

Anden normal form 2NF-definition - Anden normal form (2NF) er det andet trin i normalisering af en database. 2NF bygger ...

www.techopedia.com

Database tredje normale form forklaret på enkel engelsk

Det tredje indlæg fokuserede på den anden normale form, dens definition og eksempler for at hamre den hjem. Når et bord er i ...

www.essentialsql.com

Da jeg undersøgte dette indlæg, stødte jeg også på en noget anden holdning til, hvordan man anvender normaliseringsregler på objekttyper.

Introduktion til klassens normalisering

www.agiledata.org