Hvad skal man gøre med nulværdier, når man modellerer og normaliserer?

SQL behandler NULL specielt i henhold til dens version af 3VL (3-værdi logik). Normalisering &anden relationel teori gør det ikke. Vi kan dog oversætte SQL designs til relationelle designs og tilbage. (Antag ingen duplikerede rækker her.)

Normalisering sker med relationer og er defineret i form af operatører, der ikke behandler NULL specielt. Udtrykket "normalisering" har to mest almindelige forskellige betydninger:at sætte en tabel i "1NF" og i "højere NF'er (normale former)". NULL påvirker ikke "normalisering til 1NF". "Normalisering til højere NF'er" erstatter en tabel med mindre tabeller, der naturligt slutter sig tilbage til den. Med henblik på normalisering kan du behandle NULL som en værdi, der er tilladt i domænet af en nullbar kolonne ud over værdierne for dens SQL-type. Hvis vores SQL-tabeller ikke har nogen NULL'er, så kan vi fortolke dem som relationer &SQL join osv. som join osv. Men hvis du dekomponerer hvor en nullbar kolonne blev delt mellem komponenter, så indse at for at rekonstruere originalen i SQL skal du SQL join på kolonner med samme navn er lig eller begge NULL . Og du vil ikke have sådanne CK'er (kandidatnøgler) i en SQL-database. Du kan f.eks. ikke erklære det som en SQL PK (primær nøgle), fordi det betyder UNIK IKKE NULL. F.eks. tillader en UNIK begrænsning, der involverer en nullbar kolonne, flere rækker, der har en NULL i den kolonne, selvom rækkerne har de samme værdier i hver kolonne. F.eks. bevirker NULL'er i SQL FK'er, at de bliver opfyldt (på forskellige måder pr. MATCH-tilstand), så de ikke svigter fra ikke at blive vist i den refererede tabel. (Men DBMS'er adskiller sig idiosynkratisk fra standard SQL.)

Desværre kan nedbrydning føre til en tabel med alle CK'er, der indeholder NULL, så vi ikke har noget at erklære som SQL PK eller UNIQUE NOT NULL. Den eneste sikre løsning er at konvertere til et NULL-frit design. Efter derefter normalisering vil vi måske genindføre en vis nulstilling i komponenterne.

I praksis formår vi at designe tabeller, så der altid er et sæt NULL-frie kolonner, som vi kan erklære som CK, via SQL PK eller UNIQUE NOT NULL. Så kan vi slippe af med en nullbar kolonne ved at droppe den fra tabellen og tilføje en tabel med den kolonne og kolonnerne i nogle NULL-frie CK:Hvis kolonnen ikke er NULL for en række i det gamle design, så en række med dens CK underrække og kolonne værdi går i den tilføjede tabel; ellers er den NULL i det gamle design, og der er ingen tilsvarende række i den tilføjede tabel. (Den originale tabel er en naturlig venstresammenføjning af de nye.) Vi skal selvfølgelig også ændre forespørgsler fra det gamle design til det nye design.

Vi kan altid undgå NULLs via et design, der tilføjer en boolesk kolonne for hver gammel nullbar kolonne og har den gamle kolonne NOT NULL. Den nye kolonne siger for en række, om den gamle kolonne var NULL i det gamle design, og når den er sand, har den gamle kolonne være en værdi, som vi vælger til det formål for den type i hele databasen. Selvfølgelig skal vi også ændre forespørgsler fra det gamle design til det nye design.

Om du vil undgå NULL er et separat spørgsmål. Din database kan på en eller anden måde være "bedre" eller "værre" for din applikation med begge design. Ideen bag at undgå NULL er, at det komplicerer betydningen af ​​forespørgsler, og derfor komplicerer forespørgsler på en pervers måde sammenlignet med komplikationen af ​​flere joins fra mere NULL-frie tabeller. (Denne perversitet styres typisk ved at fjerne NULL'er i forespørgselsudtryk så tæt på, hvor de vises som muligt.)

PS Mange SQL-udtryk, inklusive PK &FK, adskiller sig fra de relationelle udtryk. SQL PK betyder noget mere som supernøgle; SQL FK betyder noget mere som fremmed supernøgle; men det giver ikke engang mening at tale om en "supernøgle" i SQL: