Nul (SQL) - Null (SQL)

Het Griekse omega- teken (ω) in kleine letters wordt gebruikt om Null in databasetheorie weer te geven .

Null of NULL is een speciale markering die in Structured Query Language wordt gebruikt om aan te geven dat een gegevenswaarde niet bestaat in de database . Geïntroduceerd door de maker van het relationele databasemodel, EF Codd , dient SQL Null om te voldoen aan de eis dat alle echte relationele databasebeheersystemen ( RDMS ) een weergave ondersteunen van "ontbrekende informatie en niet-toepasbare informatie". Codd introduceerde ook het gebruik van het Griekse omega- symbool (ω) in kleine letters om Null in databasetheorie weer te geven . In SQL NULLwordt een gereserveerd woord gebruikt om deze markering te identificeren.

Een null moet niet worden verward met een waarde van 0. Een null-waarde duidt op het ontbreken van een waarde, wat niet hetzelfde is als een waarde van nul. Denk bijvoorbeeld aan de vraag "Hoeveel boeken bezit Adam?" Het antwoord kan "nul" zijn (we weten dat hij er geen bezit ) of "null" (we weten niet hoeveel hij er bezit). In een databasetabel zou de kolom met dit antwoord beginnen zonder waarde (gemarkeerd met Null), en zou niet worden bijgewerkt met de waarde "nul" totdat we hebben vastgesteld dat Adam geen boeken bezit.

SQL null is een status, geen waarde. Dit gebruik verschilt nogal van de meeste programmeertalen, waarbij de nulwaarde van een verwijzing betekent dat deze niet naar een object verwijst .

Geschiedenis

EF Codd noemde nulwaarden als een methode om ontbrekende gegevens in het relationele model weer te geven in een artikel uit 1975 in het FDT Bulletin van ACM - SIGMOD . Codd's paper dat het meest wordt geciteerd in verband met de semantiek van Null (zoals aangenomen in SQL) is zijn paper uit 1979 in de ACM Transactions on Database Systems , waarin hij ook zijn Relational Model/Tasmania introduceerde , hoewel veel van de andere voorstellen van de laatste papier zijn duister gebleven. Paragraaf 2.3 van zijn artikel uit 1979 beschrijft de semantiek van Null-propagatie in rekenkundige bewerkingen, evenals vergelijkingen waarbij een ternaire (driewaardige) logica wordt gebruikt bij het vergelijken met nullen; het beschrijft ook de behandeling van Nulls op andere set-operaties (de laatste kwestie is nog steeds controversieel). In databasetheoretische kringen wordt het oorspronkelijke voorstel van Codd (1975, 1979) nu "Codd-tabellen" genoemd. Codd versterkte later zijn eis dat alle RDBMS'en Null ondersteunen om ontbrekende gegevens aan te geven in een tweedelig artikel uit 1985 dat in het tijdschrift ComputerWorld is gepubliceerd.

De SQL-standaard uit 1986 nam het voorstel van Codd over na een implementatieprototype in IBM System R . Hoewel Don Chamberlin nulls (naast dubbele rijen) als een van de meest controversiële kenmerken van SQL erkende, verdedigde hij het ontwerp van Nulls in SQL met een beroep op de pragmatische argumenten dat het de goedkoopste vorm van systeemondersteuning was voor ontbrekende informatie, waardoor de programmeur veel dubbele controles op applicatieniveau (zie semipredicaatprobleem ) terwijl ze tegelijkertijd de databaseontwerper de mogelijkheid bieden om geen Nulls te gebruiken als ze dat willen; bijvoorbeeld om bekende anomalieën te vermijden (besproken in de semantieksectie van dit artikel). Chamberlin voerde ook aan dat praktische ervaring met Nulls niet alleen een aantal ontbrekende waarde-functionaliteit biedt, maar ook heeft geleid tot andere taalfuncties die afhankelijk zijn van Nulls, zoals bepaalde groeperingsconstructies en outer joins. Ten slotte voerde hij aan dat in de praktijk Nulls uiteindelijk ook worden gebruikt als een snelle manier om een ​​bestaand schema te patchen wanneer het verder moet evolueren dan de oorspronkelijke bedoeling, niet om te coderen voor ontbrekende, maar eerder voor niet-toepasbare informatie; bijvoorbeeld een database die snel elektrische auto's moet ondersteunen met een kolom van mijlen per gallon.

Codd gaf in zijn boek The Relational Model for Database Management, Version 2 uit 1990 , aan dat de enkele Null die door de SQL-standaard werd opgelegd, ontoereikend was en vervangen moest worden door twee afzonderlijke Null-type markeringen om de reden aan te geven waarom gegevens ontbreken. In het boek van Codd worden deze twee nulmarkeringen aangeduid als 'A-Values' en 'I-Values', die respectievelijk 'Missing But Applicable' en 'Missing But Inapplicable' vertegenwoordigen. Volgens de aanbeveling van Codd zou het logische systeem van SQL moeten worden uitgebreid om een ​​logisch systeem met vier waarden te kunnen bevatten. Vanwege deze extra complexiteit heeft het idee van meerdere nulls met verschillende definities geen brede acceptatie gekregen in het domein van databasebeoefenaars. Het blijft echter een actief onderzoeksgebied, met tal van artikelen die nog steeds worden gepubliceerd.

Uitdagingen

Null is het middelpunt van controverse en een bron van discussie geweest vanwege de bijbehorende driewaardige logica (3VL), speciale vereisten voor het gebruik ervan in SQL-joins en de speciale behandeling die vereist is door aggregatiefuncties en SQL-groeperingsoperatoren. Informatica-hoogleraar Ron van der Meyden vatte de verschillende problemen samen als: "De inconsistenties in de SQL-standaard zorgen ervoor dat het niet mogelijk is om intuïtieve logische semantiek toe te schrijven aan de behandeling van nullen in SQL." Hoewel er verschillende voorstellen zijn gedaan om deze problemen op te lossen, heeft de complexiteit van de alternatieven een brede acceptatie verhinderd.

Null propagatie

rekenkundige bewerkingen

Omdat Null geen gegevenswaarde is, maar een markering voor een afwezige waarde, geeft het gebruik van wiskundige operatoren op Null een onbekend resultaat, dat wordt weergegeven door Null. In het volgende voorbeeld resulteert vermenigvuldiging van 10 met Null in Null:

10 * NULL          -- Result is NULL

Dit kan tot onverwachte resultaten leiden. Wanneer bijvoorbeeld een poging wordt gedaan om Null door nul te delen, kunnen platforms Null retourneren in plaats van een verwachte "gegevensuitzondering - deling door nul" te genereren. Hoewel dit gedrag niet wordt gedefinieerd door de ISO SQL-standaard, behandelen veel DBMS-leveranciers deze bewerking op dezelfde manier. De platforms Oracle, PostgreSQL, MySQL Server en Microsoft SQL Server retourneren bijvoorbeeld allemaal een Null-resultaat voor het volgende:

NULL / 0

String aaneenschakeling

Bewerkingen voor het samenvoegen van tekenreeksen , die gebruikelijk zijn in SQL, resulteren ook in Null wanneer een van de operanden Null is. Het volgende voorbeeld toont het Null-resultaat dat wordt geretourneerd door Null te gebruiken met de SQL- ||tekenreeksaaneenschakelingsoperator.

'Fish ' || NULL || 'Chips'   -- Result is NULL

Dit geldt niet voor alle database-implementaties. In een Oracle RDBMS worden bijvoorbeeld NULL en de lege string als hetzelfde beschouwd en daarom 'Fish' || NULL || 'Chips' resulteert in 'Fish Chips'.

Vergelijkingen met NULL en de driewaardige logica (3VL)

Aangezien Null geen lid is van een gegevensdomein , wordt het niet beschouwd als een "waarde", maar eerder als een markering (of tijdelijke aanduiding) die de ongedefinieerde waarde aangeeft . Hierdoor kunnen vergelijkingen met Null nooit resulteren in True of False, maar altijd in een derde logisch resultaat, Unknown. Het logische resultaat van de onderstaande uitdrukking, die de waarde 10 vergelijkt met Null, is Onbekend:

SELECT 10 = NULL       -- Results in Unknown

Bepaalde bewerkingen op Null kunnen echter waarden retourneren als de afwezige waarde niet relevant is voor de uitkomst van de bewerking. Beschouw het volgende voorbeeld:

SELECT NULL OR TRUE   -- Results in True

In dit geval is het feit dat de waarde aan de linkerkant van OR onkenbaar is niet relevant, omdat de uitkomst van de OR-bewerking True zou zijn, ongeacht de waarde aan de linkerkant.

SQL implementeert drie logische resultaten, dus SQL-implementaties moeten voorzien in een gespecialiseerde driewaardige logica (3VL) . De regels voor SQL-driewaardige logica worden weergegeven in de onderstaande tabellen ( p en q vertegenwoordigen logische toestanden)" De waarheidstabellen die SQL gebruikt voor AND, OR en NIET komen overeen met een algemeen fragment van de Kleene en Łukasiewicz driewaardige logica ( die verschillen in hun definitie van implicatie, maar SQL definieert een dergelijke bewerking niet).

Effect van Unknown in WHERE-clausules

Driewaardige SQL-logica wordt aangetroffen in Data Manipulation Language (DML) in vergelijkingspredikaten van DML-instructies en -query's. De WHEREclausule zorgt ervoor dat de DML-instructie alleen werkt op die rijen waarvoor het predikaat True evalueert. Rijen waarvoor het predikaat False of Unknown evalueert, worden niet opgevolgd door INSERT, UPDATE, of DELETEDML-instructies en worden verwijderd door SELECTquery's. Het interpreteren van Onbekend en Onwaar als hetzelfde logische resultaat is een veelvoorkomende fout die optreedt bij het omgaan met Nulls. Het volgende eenvoudige voorbeeld demonstreert deze drogreden:

SELECT *
FROM t
WHERE i = NULL;

De bovenstaande voorbeeldquery retourneert logischerwijs altijd nul rijen omdat de vergelijking van de i- kolom met Null altijd Onbekend retourneert, zelfs voor die rijen waarin i Null is. Het resultaat Onbekend zorgt ervoor dat de SELECTinstructie elke rij summier weggooit. (In de praktijk zullen sommige SQL-tools echter rijen ophalen met behulp van een vergelijking met Null.)

Null-specifieke en 3VL-specifieke vergelijkingspredikaten

Standaard SQL-vergelijkingsoperatoren retourneren altijd Onbekend wanneer iets wordt vergeleken met Null, dus de SQL-standaard voorziet in twee speciale Null-specifieke vergelijkingspredikaten. De IS NULLen IS NOT NULLpredikaten (die gebruik achtervoegsel proef syntax) of gegevens is, of niet, Null.

De SQL-standaard bevat de optionele functie F571 "Truth value tests" die drie extra logische unaire operators introduceert (zes in feite, als we hun negatie tellen, die deel uitmaakt van hun syntaxis), ook met gebruik van postfix-notatie. Ze hebben de volgende waarheidstabellen:

De functie F571 staat loodrecht op de aanwezigheid van het booleaanse datatype in SQL (wordt later in dit artikel besproken) en ondanks syntactische overeenkomsten introduceert F571 geen booleaanse of driewaardige letterlijke waarden in de taal. De functie F571 was daadwerkelijk aanwezig in SQL92 , ruim voordat het booleaanse datatype in 1999 in de standaard werd geïntroduceerd. De functie F571 wordt echter door weinig systemen geïmplementeerd; PostgreSQL is een van degenen die het implementeren.

De toevoeging van IS UNKNOWN aan de andere operators van SQL's driewaardige logica maakt de SQL driewaardige logica functioneel compleet , wat betekent dat de logische operators (in combinatie) elke denkbare driewaardige logische functie kunnen uitdrukken.

Op systemen die de functie F571 niet ondersteunen, is het mogelijk om IS UNKNOWN p te emuleren door elk argument te doorlopen dat de uitdrukking p Onbekend zou kunnen maken en die argumenten te testen met IS NULL of andere NULL-specifieke functies, hoewel dit meer kan zijn moeizaam.

Wet van de uitgesloten vierde (in WHERE-clausules)

In SQL's driewaardige logica evalueert de wet van het uitgesloten midden , p OR NOT p , niet langer waar voor alle p . Om precies te zijn, in SQL's driewaardige logica p OR NOT is p precies onbekend wanneer p onbekend is en anders waar. Omdat directe vergelijkingen met Null resulteren in de onbekende logische waarde, is de volgende query:

SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 );

is niet equivalent in SQL met

SELECT * FROM stuff;

als de kolom x Nulls bevat; in dat geval zou de tweede query enkele rijen retourneren, de eerste niet, namelijk alle waarin x Null is. In de klassieke tweewaardige logica zou de wet van het uitgesloten midden de vereenvoudiging van het predikaat WHERE mogelijk maken, in feite de eliminatie ervan. Pogingen om de wet van het uitgesloten midden toe te passen op de 3VL van SQL is in feite een valse tweedeling . De tweede query is eigenlijk gelijk aan:

SELECT * FROM stuff;
-- is (because of 3VL) equivalent to:
SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 ) OR x IS NULL;

Om de eerste instructie in SQL correct te vereenvoudigen, moeten we dus alle rijen retourneren waarin x niet null is.

SELECT * FROM stuff WHERE x IS NOT NULL;

Met het oog op het bovenstaande, merk op dat voor de WHERE-clausule van SQL een tautologie kan worden geschreven die vergelijkbaar is met de wet van uitgesloten midden. Ervan uitgaande dat de operator IS UNKNOWN aanwezig is, is p OR (NIET p ) OR ( p IS UNKNOWN) waar voor elk predikaat p . Onder logici wordt dit de wet van de uitgesloten vierde genoemd .

Er zijn enkele SQL-expressies waarin het minder duidelijk is waar het valse dilemma zich voordoet, bijvoorbeeld:

SELECT 'ok' WHERE 1 NOT IN (SELECT CAST (NULL AS INTEGER))
UNION
SELECT 'ok' WHERE 1 IN (SELECT CAST (NULL AS INTEGER));

produceert geen rijen omdat dit INvertaalt naar een herhaalde versie van gelijkheid over de argumentenset en 1<>NULL is onbekend, net zoals een 1=NULL onbekend is. (De CAST in dit voorbeeld is alleen nodig in sommige SQL-implementaties zoals PostgreSQL, die het anders zou weigeren met een typecontrolefout. In veel systemen werkt SELECT NULL in de subquery.) Het ontbrekende geval hierboven is natuurlijk:

SELECT 'ok' WHERE (1 IN (SELECT CAST (NULL AS INTEGER))) IS UNKNOWN;

Effect van Null en Unknown in andere constructies

Doet mee

Joins evalueren met behulp van dezelfde vergelijkingsregels als voor WHERE-clausules. Daarom moet u voorzichtig zijn bij het gebruik van nullable-kolommen in SQL-joincriteria. In het bijzonder is een tabel die nulls bevat niet gelijk aan een natuurlijke self-join van zichzelf, wat betekent dat terwijl dit waar is voor elke relatie R in relationele algebra , een SQL self-join alle rijen met een Null waar dan ook uitsluit. Een voorbeeld van dit gedrag wordt gegeven in de sectie die de ontbrekende waarde-semantiek van Nulls analyseert. ${\displaystyle R\vlinderdas R=R}$

De SQL- COALESCEfunctie of CASEexpressies kunnen worden gebruikt om "simuleren" Null gelijkheid mee te doen criteria, en de IS NULLen IS NOT NULLpredikaten kunnen worden gebruikt in de criteria als goed. Het volgende predikaat test op gelijkheid van de waarden A en B en behandelt nulwaarden als gelijk.

(A = B) OR (A IS NULL AND B IS NULL)

CASE-uitdrukkingen

SQL biedt twee soorten voorwaardelijke expressies . De ene wordt "simple CASE" genoemd en werkt als een switch-instructie . De andere wordt in de standaard een "searched CASE" genoemd en werkt als een if...elseif .

De eenvoudige CASEexpressies gebruiken impliciete vergelijkingen van gelijkheid die werken onder dezelfde regels als de DML- WHEREclausuleregels voor Null. Een eenvoudige CASEexpressie kan dus niet rechtstreeks controleren op het bestaan ​​van Null. Een controle op Null in een eenvoudige CASEuitdrukking resulteert altijd in Onbekend, zoals in het volgende:

SELECT CASE i WHEN NULL THEN 'Is Null'  -- This will never be returned
              WHEN    0 THEN 'Is Zero'  -- This will be returned when i = 0
              WHEN    1 THEN 'Is One'   -- This will be returned when i = 1
              END
FROM t;

Omdat de uitdrukking i = NULLnaar Onbekend evalueert, ongeacht de waarde die kolom i bevat (zelfs als deze Null bevat), wordt de tekenreeks 'Is Null'nooit geretourneerd.

Aan de andere kant kan een "gezochte" CASEuitdrukking predikaten zoals IS NULLen IS NOT NULLin zijn voorwaarden gebruiken. Het volgende voorbeeld laat zien hoe u een gezochte CASEexpressie gebruikt om correct op Null te controleren:

SELECT CASE WHEN i IS NULL THEN 'Null Result'  -- This will be returned when i is NULL
            WHEN     i = 0 THEN 'Zero'         -- This will be returned when i = 0
            WHEN     i = 1 THEN 'One'          -- This will be returned when i = 1
            END
FROM t;

In de gezochte CASEexpressie wordt de tekenreeks 'Null Result'geretourneerd voor alle rijen waarin i Null is.

Oracle's dialect van SQL biedt een ingebouwde functie DECODEdie kan worden gebruikt in plaats van de eenvoudige CASE-expressies en beschouwt twee nulls als gelijk.

SELECT DECODE(i, NULL, 'Null Result', 0, 'Zero', 1, 'One') FROM t;

Ten slotte retourneren al deze constructies een NULL als er geen overeenkomst wordt gevonden; ze hebben een standaardclausule ELSE NULL.

IF-verklaringen in procedurele uitbreidingen

SQL/PSM (SQL Persistent Stored Modules) definieert procedurele uitbreidingen voor SQL, zoals de IFinstructie. De grote SQL-leveranciers hebben in het verleden echter hun eigen propriëtaire procedurele extensies opgenomen. Procedurele extensies voor looping en vergelijkingen werken onder nulvergelijkingsregels die vergelijkbaar zijn met die voor DML-instructies en -query's. Het volgende codefragment, in ISO SQL-standaardformaat, demonstreert het gebruik van Null 3VL in een IFinstructie.

IF i = NULL THEN
      SELECT 'Result is True'
ELSEIF NOT(i = NULL) THEN
      SELECT 'Result is False'
ELSE
      SELECT 'Result is Unknown';

De IFinstructie voert alleen acties uit voor die vergelijkingen die als True worden geëvalueerd. Voor instructies die worden geëvalueerd als False of Unknown, geeft de IFinstructie de controle door aan de ELSEIFclausule en ten slotte aan de ELSEclausule. Het resultaat van de bovenstaande code zal altijd het bericht zijn, 'Result is Unknown'aangezien de vergelijkingen met Null altijd op Onbekend uitkomen.

Analyse van SQL Null-semantiek met ontbrekende waarden

Het baanbrekende werk van T. Imieliński en W. Lipski Jr. (1984) verschafte een kader voor het evalueren van de beoogde semantiek van verschillende voorstellen voor het implementeren van ontbrekende semantiek, dat wordt aangeduid als Imieliński-Lipski Algebra's . Deze sectie volgt ruwweg hoofdstuk 19 van het "Alice" leerboek. Een soortgelijke presentatie verschijnt in de recensie van Ron van der Meyden, §10.4.

In selecties en projecties: zwakke weergave

Constructen die ontbrekende informatie vertegenwoordigen, zoals Codd-tabellen, zijn eigenlijk bedoeld om een ​​reeks relaties weer te geven, één voor elke mogelijke instantie van hun parameters; in het geval van Codd-tabellen betekent dit vervanging van Nulls door een concrete waarde. Bijvoorbeeld,

Van een constructie (zoals een Codd-tabel) wordt gezegd dat het een sterk representatiesysteem is (van ontbrekende informatie) als een antwoord op een vraag op de constructie kan worden gespecificeerd om een ​​antwoord te verkrijgen voor een overeenkomstige vraag over de relaties die het vertegenwoordigt, wat worden gezien als modellen van het construct. Om precies te zijn, als q een vraagformule is in de relationele algebra (van "zuivere" relaties) en als q de opheffing is naar een constructie die bedoeld is om ontbrekende informatie weer te geven, heeft een sterke representatie de eigenschap dat voor elke vraag q en (tabel) construct T , q heft alle antwoorden op het construct op, dwz:

${\displaystyle \mathop {\mathrm {Modellen} } ({\bar {q}}(T))=\{q(R)\,|R\in \mathop {\mathrm {Modellen} } (T)\ }}$

(Het bovenstaande geldt voor query's die een willekeurig aantal tabellen als argumenten gebruiken, maar de beperking tot één tabel is voldoende voor deze discussie.) Het is duidelijk dat Codd-tabellen deze sterke eigenschap niet hebben als selecties en projecties worden beschouwd als onderdeel van de querytaal. Bijvoorbeeld alle antwoorden op:

SELECT * FROM Emp WHERE Age = 22;

moet de mogelijkheid bevatten dat er een relatie als EmpH22 bestaat. Codd-tabellen kunnen echter niet de disjunctie "resultaat met mogelijk 0 of 1 rijen" weergeven. Een apparaat, meestal van theoretisch belang, voorwaardelijke tabel (of c-tabel) genoemd, kan echter zo'n antwoord vertegenwoordigen:

waarbij de voorwaardekolom wordt geïnterpreteerd als de rij niet bestaat als de voorwaarde onwaar is. Het blijkt dat, omdat de formules in de conditiekolom van een c-tabel willekeurige propositielogische formules kunnen zijn, een algoritme voor het probleem of een c-tabel een concrete relatie vertegenwoordigt een co-NP-volledige complexiteit heeft, dus van weinig belang is. praktische waarde.

Een zwakkere notie van representatie is daarom wenselijk. Imielinski en Lipski introduceerden het begrip zwakke representatie , wat in wezen toestaat dat (opgeheven) queries over een constructie een representatie alleen voor zekere informatie retourneren , dat wil zeggen als deze geldig is voor alle " mogelijke wereld "-instanties (modellen) van de constructie. Concreet is een construct een zwak representatiesysteem als

${\ Displaystyle \ bigcap \ mathop {\ mathrm {Modellen} } ({\ bar {q}} (T)) = \ bigcap \ {q (R) \, | R \ in \ mathop {\ mathrm {Modellen} } (T)\}}$

De rechterkant van de bovenstaande vergelijking is de zekere informatie, dwz informatie die zeker uit de database kan worden gehaald, ongeacht welke waarden worden gebruikt om nulwaarden in de database te vervangen. In het voorbeeld dat we hierboven hebben bekeken, is het gemakkelijk te zien dat het snijpunt van alle mogelijke modellen (dwz de zekere informatie) van de selectie van de query eigenlijk leeg is, omdat bijvoorbeeld de (niet-opgenomen) query geen rijen retourneert voor de relatie EmpH37. Meer in het algemeen werd door Imielinski en Lipski aangetoond dat Codd-tabellen een zwak representatiesysteem zijn als de zoektaal beperkt is tot projecties, selecties (en hernoemen van kolommen). Zodra we echter joins of unions aan de zoektaal toevoegen, gaat zelfs deze zwakke eigenschap verloren, zoals blijkt uit de volgende sectie. WHERE Age = 22

Als joins of vakbonden worden overwogen: zelfs geen zwakke vertegenwoordiging

Beschouw de volgende vraag over dezelfde Codd-tabel Emp uit de vorige sectie:

SELECT Name FROM Emp WHERE Age = 22
UNION
SELECT Name FROM Emp WHERE Age <> 22;

Welke concrete waarde men ook zou kiezen voor de NULLleeftijd van Harriet, de bovenstaande query zal de volledige kolom met namen van elk model van Emp retourneren , maar wanneer de (opgeheven) query op Emp zelf wordt uitgevoerd , zal Harriet altijd ontbreken, dwz we hebben :

Dus wanneer vakbonden worden toegevoegd aan de zoektaal, zijn Codd-tabellen niet eens een zwak representatiesysteem van ontbrekende informatie, wat betekent dat zoekopdrachten erover niet eens alle zekere informatie rapporteren . Het is belangrijk om hier op te merken dat de semantiek van UNION op Nulls, die in een later gedeelte wordt besproken, niet eens een rol speelde in deze vraag. Het "vergeetachtige" karakter van de twee subquery's was alles wat nodig was om te garanderen dat bepaalde informatie niet werd gerapporteerd toen de bovenstaande query werd uitgevoerd op de Codd-tabel Emp.

Voor natuurlijke joins is het voorbeeld dat nodig is om aan te tonen dat bepaalde informatie niet wordt gerapporteerd door een zoekopdracht, iets gecompliceerder. Denk aan de tafel

en de vraag

SELECT F1, F3 FROM
  (SELECT F1, F2 FROM J) AS F12
  NATURAL JOIN
  (SELECT F2, F3 FROM J) AS F23;

De intuïtie voor wat hierboven gebeurt, is dat de Codd-tabellen die de projecties in de subquery's vertegenwoordigen uit het oog verliezen dat de Nulls in de kolommen F12.F2 en F23.F2 in feite kopieën zijn van de originelen in tabel J. Deze observatie suggereert dat een relatief eenvoudige verbetering van Codd-tabellen (die in dit voorbeeld correct werken) zou zijn om Skolem-constanten te gebruiken (wat betekent Skolem-functies die ook constante functies zijn ), zeg ω ₁₂ en ω _{22 in} plaats van een enkel NULL-symbool. Een dergelijke benadering, v-tabellen of Naïeve tabellen genoemd, is rekenkundig minder duur dan de hierboven besproken c-tabellen. Het is echter nog steeds geen volledige oplossing voor onvolledige informatie in die zin dat v-tabellen slechts een zwakke weergave zijn voor query's die geen ontkenningen gebruiken bij selectie (en ook geen setverschil gebruiken). Het eerste voorbeeld dat in deze sectie wordt overwogen, is het gebruik van een negatieve selectieclausule , dus het is ook een voorbeeld waarbij v-tables-query's geen zekere informatie zouden rapporteren. WHERE Age <> 22

Beperkingen en externe sleutels controleren

De primaire plaats waar driewaardige SQL-logica de SQL Data Definition Language (DDL) kruist , is in de vorm van controlebeperkingen . Een controlebeperking die op een kolom is geplaatst, werkt onder een iets andere set regels dan die voor de DML- WHEREclausule. Hoewel een DML- WHEREclausule voor een rij moet worden geëvalueerd als True, mag een controlebeperking niet worden geëvalueerd als False. (Vanuit een logisch perspectief zijn de aangegeven waarden Waar en Onbekend.) Dit betekent dat een controlebeperking zal slagen als het resultaat van de controle Waar of Onbekend is. De volgende voorbeeldtabel met een controlebeperking verbiedt het invoegen van gehele getallen in kolom i , maar staat toe dat Null wordt ingevoegd, aangezien het resultaat van de controle altijd zal resulteren in Onbekend voor nullwaarden.

CREATE TABLE t (
     i INTEGER,
     CONSTRAINT ck_i CHECK ( i < 0 AND i = 0 AND i > 0 ) );

Vanwege de verandering in toegewezen waarden ten opzichte van de WHERE- clausule, is vanuit een logisch perspectief de wet van uitgesloten midden een tautologie voor CHECK- beperkingen, wat betekent dat het altijd lukt. Bovendien, ervan uitgaande dat nulls moeten worden geïnterpreteerd als bestaande maar onbekende waarden, maken sommige pathologische CONTROLES zoals die hierboven het invoegen van nulls mogelijk die nooit kunnen worden vervangen door een niet-nulwaarde. CHECK (p OR NOT p)

Om een ​​kolom te beperken om Nulls te weigeren, kan de NOT NULLbeperking worden toegepast, zoals in het onderstaande voorbeeld. De NOT NULLbeperking is semantisch equivalent aan een controlevoorwaarde met een IS NOT NULLpredikaat.

CREATE TABLE t ( i INTEGER NOT NULL );

Standaard slagen controlebeperkingen voor externe sleutels als een van de velden in dergelijke sleutels Null is. Bijvoorbeeld de tafel

CREATE TABLE Books
( title VARCHAR(100),
  author_last VARCHAR(20),
  author_first VARCHAR(20),
FOREIGN KEY (author_last, author_first)
  REFERENCES Authors(last_name, first_name));

zou het invoegen van rijen toestaan ​​waar author_last of author_first zijn, NULLongeacht hoe de tabel Authors is gedefinieerd of wat deze bevat. Om precies te zijn, een null in een van deze velden zou elke waarde in de andere toestaan, zelfs als die niet wordt gevonden in de tabel Auteurs. Als Authors bijvoorbeeld alleen zou bevatten ('Doe', 'John'), ('Smith', NULL)zou dit voldoen aan de externe sleutelbeperking. SQL-92 heeft twee extra opties toegevoegd om de overeenkomsten in dergelijke gevallen te verkleinen. Als het MATCH PARTIALwordt toegevoegd na de REFERENCESdeclaratie, moet elke niet-null overeenkomen met de externe sleutel, bijvoorbeeld ('Doe', NULL)zou nog steeds overeenkomen, maar ('Smith', NULL)zou niet. Ten slotte, als MATCH FULLwordt toegevoegd, ('Smith', NULL)zou het ook niet overeenkomen met de beperking, maar (NULL, NULL)er nog steeds mee overeenkomen.

buitenste joins

Voorbeeld SQL outer join- query met Null-plaatsaanduidingen in de resultatenset. De nulmarkeringen worden weergegeven door het woord NULLin plaats van gegevens in de resultaten. Resultaten zijn afkomstig van Microsoft SQL Server , zoals weergegeven in SQL Server Management Studio.

SQL outer joins , inclusief left outer joins, rechter outer joins en volledige outer joins, produceren automatisch Nulls als tijdelijke aanduidingen voor ontbrekende waarden in gerelateerde tabellen. Voor linker outer joins worden bijvoorbeeld Nulls geproduceerd in plaats van rijen die ontbreken in de tabel die aan de rechterkant van de LEFT OUTER JOINoperator wordt weergegeven. In het volgende eenvoudige voorbeeld worden twee tabellen gebruikt om de productie van Null-placeholders in een left outer join te demonstreren.

De eerste tabel ( Werknemer ) bevat ID-nummers en namen van werknemers, terwijl de tweede tabel ( PhoneNumber ) gerelateerde ID-nummers en telefoonnummers van werknemers bevat , zoals hieronder weergegeven.

De volgende voorbeeld-SQL-query voert een left outer join uit op deze twee tabellen.

SELECT e.ID, e.LastName, e.FirstName, pn.Number
FROM Employee e
LEFT OUTER JOIN PhoneNumber pn
ON e.ID = pn.ID;

De resultatenset die door deze query wordt gegenereerd, laat zien hoe SQL Null gebruikt als tijdelijke aanduiding voor waarden die ontbreken in de rechtertabel ( PhoneNumber ), zoals hieronder wordt weergegeven.

Geaggregeerde functies

SQL definieert aggregatiefuncties om aggregatieberekeningen voor gegevens aan de serverzijde te vereenvoudigen. Met uitzondering van de COUNT(*)functie voeren alle geaggregeerde functies een Null-eliminatiestap uit, zodat Nulls niet worden meegenomen in het uiteindelijke resultaat van de berekening.

Merk op dat de eliminatie van Null niet gelijk staat aan het vervangen van Null door nul. In de volgende tabel geeft AVG(i)(het gemiddelde van de waarden van i) bijvoorbeeld een ander resultaat dan dat van AVG(j):

Hier AVG(i)is 200 (het gemiddelde van 150, 200 en 250), terwijl het AVG(j)150 is (het gemiddelde van 150, 200, 250 en 0). Een bekende bijwerking hiervan is dat in SQL AVG(z)equivalent is met niet SUM(z)/COUNT(*)maar SUM(z)/COUNT(z).

De uitvoer van een aggregatiefunctie kan ook Null zijn. Hier is een voorbeeld:

SELECT COUNT(*), MIN(e.Wage), MAX(e.Wage)
FROM Employee e
WHERE e.LastName LIKE '%Jones%';

Deze zoekopdracht levert altijd precies één rij op, waarbij het aantal werknemers wordt geteld wiens achternaam "Jones" bevat, en het minimum- en maximumloon voor die werknemers wordt weergegeven. Maar wat gebeurt er als geen van de medewerkers aan de gestelde criteria voldoet? Het berekenen van de minimum- of maximumwaarde van een lege set is onmogelijk, dus die resultaten moeten NULL zijn, wat aangeeft dat er geen antwoord is. Dit is geen onbekende waarde, het is een Null die de afwezigheid van een waarde vertegenwoordigt. Het resultaat zou zijn:

Wanneer twee nulls gelijk zijn: groeperen, sorteren en enkele setbewerkingen

Omdat SQL:2003 alle Null-markeringen definieert als ongelijk aan elkaar, was er een speciale definitie nodig om Nulls te groeperen bij het uitvoeren van bepaalde bewerkingen. SQL definieert "elke twee waarden die gelijk zijn aan elkaar, of twee Nulls", als "niet onderscheiden". Met deze definitie van niet onderscheiden kan SQL nulls groeperen en sorteren wanneer de GROUP BYclausule (en andere trefwoorden die groepering uitvoeren) worden gebruikt.

Andere SQL-bewerkingen, -clausules en trefwoorden gebruiken "niet onderscheiden" in hun behandeling van nulls. Deze omvatten het volgende:

• PARTITION BY clausule van rangschikking en vensterfuncties zoals ROW_NUMBER
• UNION, INTERSECT, en EXCEPToperator, die NULL's als hetzelfde behandelen voor rijvergelijkings-/eliminatiedoeleinden
• DISTINCTtrefwoord gebruikt in SELECTzoekopdrachten

Het principe dat Nulls niet aan elkaar gelijk zijn (maar eerder dat het resultaat Unknown is) wordt effectief geschonden in de SQL-specificatie voor de UNIONoperator, die nulls wel met elkaar identificeert. Bijgevolg kunnen sommige set-bewerkingen in SQL, zoals unie of verschil, resultaten opleveren die geen zekere informatie vertegenwoordigen, in tegenstelling tot bewerkingen die expliciete vergelijkingen met NULL met zich meebrengen (bijvoorbeeld die in een WHEREhierboven besproken clausule). In het voorstel van Codd uit 1979 (dat in wezen werd overgenomen door SQL92) wordt deze semantische inconsistentie gerationaliseerd door te stellen dat het verwijderen van duplicaten in set-operaties gebeurt "op een lager detailniveau dan het testen van gelijkheid bij de evaluatie van ophaaloperaties".

De SQL-standaard definieert niet expliciet een standaardsorteervolgorde voor Nulls. In plaats daarvan kunnen op conforme systemen Nulls voor of na alle gegevenswaarden worden gesorteerd door respectievelijk de NULLS FIRSTof NULLS LASTclausules van de ORDER BYlijst te gebruiken. Niet alle DBMS-leveranciers implementeren deze functionaliteit echter. Leveranciers die deze functionaliteit niet implementeren, kunnen verschillende behandelingen specificeren voor Null-sortering in het DBMS.

Effect op indexbewerking

Sommige SQL-producten indexeren geen sleutels die NULL's bevatten. Bijvoorbeeld, PostgreSQL versies eerder dan 8.3 niet, met de documentatie voor een B-tree index waarin staat dat

B-trees kunnen gelijkheids- en bereikquery's afhandelen op gegevens die in een bepaalde volgorde kunnen worden gesorteerd. In het bijzonder zal de PostgreSQL-queryplanner het gebruik van een B-tree-index overwegen wanneer een geïndexeerde kolom betrokken is bij een vergelijking met een van deze operatoren: < ≤ = ≥ >

Constructen die equivalent zijn aan combinaties van deze operatoren, zoals BETWEEN en IN, kunnen ook worden geïmplementeerd met een B-tree index-zoekopdracht. (Maar merk op dat IS NULL niet gelijk is aan = en niet indexeerbaar is.)

In gevallen waarin de index uniciteit afdwingt, worden NULL's uitgesloten van de index en wordt uniciteit niet afgedwongen tussen NULL's. Nogmaals, citerend uit de PostgreSQL- documentatie:

Wanneer een index uniek wordt verklaard, zijn meerdere tabelrijen met gelijke geïndexeerde waarden niet toegestaan. Nulls worden niet als gelijk beschouwd. Een unieke index met meerdere kolommen verwerpt alleen gevallen waarin alle geïndexeerde kolommen in twee rijen gelijk zijn.

Dit komt overeen met het door SQL:2003 gedefinieerde gedrag van scalaire null-vergelijkingen.

Een andere methode om nulls te indexeren, houdt in dat ze als niet-onderscheiden worden behandeld in overeenstemming met het door SQL:2003 gedefinieerde gedrag. In de documentatie van Microsoft SQL Server staat bijvoorbeeld het volgende:

Voor indexeringsdoeleinden vergelijken NULL's als gelijk. Daarom kan er geen unieke index of UNIQUE-beperking worden gemaakt als de sleutels NULL zijn in meer dan één rij. Selecteer kolommen die zijn gedefinieerd als NOT NULL wanneer kolommen voor een unieke index of unieke beperking worden gekozen.

Beide indexeringsstrategieën zijn consistent met het door SQL:2003 gedefinieerde gedrag van Nulls. Omdat indexeringsmethodologieën niet expliciet worden gedefinieerd door de SQL:2003-standaard, worden indexeringsstrategieën voor Nulls volledig overgelaten aan de leveranciers om te ontwerpen en te implementeren.

Null-verwerkingsfuncties

SQL definieert twee functies om expliciet om te gaan met Nulls: NULLIFen COALESCE. Beide functies zijn afkortingen voor gezochte CASEuitdrukkingen .

NULLIF

De NULLIFfunctie accepteert twee parameters. Als de eerste parameter gelijk is aan de tweede parameter, NULLIFwordt Null geretourneerd. Anders wordt de waarde van de eerste parameter geretourneerd.

NULLIF(value1, value2)

Dus, NULLIFis een afkorting voor de volgende CASEuitdrukking:

CASE WHEN value1 = value2 THEN NULL ELSE value1 END

COALESCE

De COALESCEfunctie accepteert een lijst met parameters en retourneert de eerste niet-Null-waarde uit de lijst:

COALESCE(value1, value2, value3, ...)

COALESCEwordt gedefinieerd als een afkorting voor de volgende SQL- CASEexpressie:

CASE WHEN value1 IS NOT NULL THEN value1
     WHEN value2 IS NOT NULL THEN value2
     WHEN value3 IS NOT NULL THEN value3
     ...
     END

Sommige SQL DBMS'en implementeren leverancierspecifieke functies die vergelijkbaar zijn met COALESCE. Sommige systemen (bijv. Transact-SQL ) implementeren een ISNULLfunctie of andere vergelijkbare functies die functioneel vergelijkbaar zijn met COALESCE. (Zie Isfuncties voor meer informatie over de ISfuncties in Transact-SQL.)

NVL

De Oracle- NVLfunctie accepteert twee parameters. Het retourneert de eerste niet-NULL-parameter of NULL als alle parameters NULL zijn.

Een COALESCEuitdrukking kan als volgt worden omgezet in een equivalente NVLuitdrukking:

COALESCE ( val1, ... , val{n} )

verandert in:

NVL( val1 , NVL( val2 , NVL( val3 , … , NVL ( val{n-1} , val{n} ) … )))

Een use case van deze functie is om in een expressie een NULL te vervangen door een waarde zoals NVL(SALARY, 0)waarin staat: 'if SALARYis NULL, vervang het door de waarde 0'.

Er is echter één opvallende uitzondering. In de meeste implementaties COALESCEevalueert het de parameters totdat het de eerste niet-NULL-waarde bereikt, terwijl NVLalle parameters worden geëvalueerd. Dit is om meerdere redenen belangrijk. Een parameter na de eerste niet-NULL-parameter kan een functie zijn die rekenkundig duur of ongeldig kan zijn of onverwachte neveneffecten kan veroorzaken.

Gegevens typen van Null en Unknown

De NULL letterlijke tekst is niet getypt in SQL, wat betekent dat deze niet wordt aangeduid als een geheel getal, teken of een ander specifiek gegevenstype . Hierdoor is het soms verplicht (of wenselijk) om Nulls expliciet om te zetten naar een specifiek datatype. Als overbelaste functies bijvoorbeeld worden ondersteund door het RDBMS, kan SQL mogelijk niet automatisch naar de juiste functie worden omgezet zonder de gegevenstypen van alle parameters te kennen, inclusief die waarvoor Null wordt doorgegeven.

Conversie van de NULLletterlijke naar een Null van een specifiek type is mogelijk met behulp van de CASTin SQL-92 geïntroduceerde . Bijvoorbeeld:

CAST (NULL AS INTEGER)

staat voor een afwezige waarde van het type INTEGER.

Het daadwerkelijke typen van Unknown (al dan niet verschillend van NULL zelf) varieert tussen SQL-implementaties. Bijvoorbeeld het volgende:

SELECT 'ok' WHERE (NULL <> 1) IS NULL;

parseert en wordt succesvol uitgevoerd in sommige omgevingen (bijv. SQLite of PostgreSQL ) die een NULL-boolean verenigen met Unknown, maar in andere niet kunnen parseren (bijv. in SQL Server Compact ). MySQL gedraagt ​​zich in dit opzicht op dezelfde manier als PostgreSQL (met de kleine uitzondering dat MySQL TRUE en FALSE beschouwt als niet verschillend van de gewone gehele getallen 1 en 0). PostgreSQL implementeert bovendien een IS UNKNOWNpredikaat, dat kan worden gebruikt om te testen of een logische uitkomst met drie waarden onbekend is, hoewel dit slechts syntactische suiker is.

BOOLEAN-gegevenstype

De ISO SQL:1999- standaard introduceerde het BOOLEAN-gegevenstype in SQL, maar het is nog steeds slechts een optionele, niet-kernfunctie, gecodeerd T031.

Wanneer beperkt door een NOT NULLbeperking, werkt de SQL BOOLEAN zoals het Booleaanse type uit andere talen. Onbeperkt echter kan het BOOLEAN-datatype, ondanks zijn naam, de waarheidswaarden TRUE, FALSE en UNKNOWN bevatten, die allemaal worden gedefinieerd als booleaanse letterlijke waarden volgens de standaard. De norm stelt ook dat NULL en UNKNOWN "door elkaar kunnen worden gebruikt om precies hetzelfde te betekenen".

Het Booleaanse type is onderwerp van kritiek geweest, vooral vanwege het verplichte gedrag van de UNKNOWN letterlijke, die nooit gelijk is aan zichzelf vanwege de identificatie met NULL.

Zoals hierboven besproken, wordt in de PostgreSQL- implementatie van SQL Null gebruikt om alle UNKNOWN-resultaten weer te geven, inclusief de UNKNOWN BOOLEAN. PostgreSQL implementeert de UNKNOWN-lettertaal niet (hoewel het wel de IS UNKNOWN-operator implementeert, wat een orthogonale functie is). De meeste andere grote leveranciers ondersteunen het Booleaanse type (zoals gedefinieerd in T031) niet vanaf 2012. Het procedurele deel van Oracle's PL /SQL ondersteunt BOOLEAN echter variabelen; deze kunnen ook worden toegewezen aan NULL en de waarde wordt beschouwd als hetzelfde als UNKNOWN.

Controverse

Veelgemaakte fouten

Misverstand van hoe Null werkt, is de oorzaak van een groot aantal fouten in SQL-code, zowel in ISO-standaard SQL-instructies als in de specifieke SQL-dialecten die worden ondersteund door real-world databasebeheersystemen. Deze fouten zijn meestal het gevolg van verwarring tussen Null en 0 (nul) of een lege tekenreeks (een tekenreekswaarde met een lengte van nul, weergegeven in SQL als ''). Null wordt echter door de SQL-standaard gedefinieerd als verschillend van zowel een lege tekenreeks als de numerieke waarde 0. Terwijl Null de afwezigheid van een waarde aangeeft, vertegenwoordigen de lege tekenreeks en de numerieke nul beide de werkelijke waarden.

Een klassieke fout is de poging om de operator equals te gebruiken =in combinatie met het sleutelwoord NULLom rijen met Nulls te vinden. Volgens de SQL-standaard is dit een ongeldige syntaxis en zal dit leiden tot een foutmelding of een uitzondering. Maar de meeste implementaties accepteren de syntaxis en evalueren dergelijke expressies naar UNKNOWN. Het gevolg is dat er geen rijen worden gevonden – ongeacht of er rijen met Nulls bestaan ​​of niet. De voorgestelde manier om rijen op te halen met Nulls is het gebruik van het predikaat in IS NULLplaats van = NULL.

SELECT *
FROM sometable
WHERE num = NULL;  -- Should be "WHERE num IS NULL"

In een verwant, maar subtieler voorbeeld kan een WHEREclausule of voorwaardelijke instructie de waarde van een kolom vergelijken met een constante. Er wordt vaak ten onrechte aangenomen dat een ontbrekende waarde "kleiner dan" of "niet gelijk aan" een constante zou zijn als dat veld Null bevat, maar in feite retourneren dergelijke uitdrukkingen Onbekend. Een voorbeeld staat hieronder:

SELECT *
FROM sometable
WHERE num <> 1;  -- Rows where num is NULL will not be returned,
                 -- contrary to many users' expectations.

Deze verwarring ontstaat omdat de Wet van Identiteit beperkt is in de logica van SQL. Bij het omgaan met gelijkheidsvergelijkingen met behulp van de NULLletterlijke of de UNKNOWNwaarheidswaarde, zal SQL altijd terugkeren UNKNOWNals het resultaat van de expressie. Dit is een partiële equivalentierelatie en maakt SQL tot een voorbeeld van een niet-reflexieve logica .

Evenzo worden nulls vaak verward met lege strings. Overweeg de LENGTHfunctie, die het aantal tekens in een tekenreeks retourneert. Wanneer een Null wordt doorgegeven aan deze functie, retourneert de functie Null. Dit kan tot onverwachte resultaten leiden als gebruikers niet goed thuis zijn in logica met drie waarden. Een voorbeeld staat hieronder:

SELECT *
FROM sometable
WHERE LENGTH(string) < 20; -- Rows where string is NULL will not be returned.

Dit wordt gecompliceerd door het feit dat in sommige database-interfaceprogramma's (of zelfs database-implementaties zoals die van Oracle), NULL wordt gerapporteerd als een lege tekenreeks en dat lege tekenreeksen onjuist kunnen worden opgeslagen als NULL.

kritieken

De ISO SQL-implementatie van Null is onderwerp van kritiek, discussie en oproepen tot verandering. In The Relational Model for Database Management: Version 2 , suggereerde Codd dat de SQL-implementatie van Null gebrekkig was en zou moeten worden vervangen door twee verschillende Null-type markeringen. De markeringen die hij voorstelde, zouden staan ​​voor "Missing but Applicable" en "Missing but Inapplicable" , respectievelijk bekend als A-waarden en I-waarden . De aanbeveling van Codd zou, indien aanvaard, de implementatie van een vierwaardige logica in SQL hebben vereist. Anderen hebben voorgesteld om extra Null-type markeringen toe te voegen aan de aanbeveling van Codd om nog meer redenen aan te geven dat een gegevenswaarde mogelijk "ontbreekt", waardoor de complexiteit van het logische systeem van SQL toeneemt. Op verschillende momenten zijn er ook voorstellen gedaan om meerdere door de gebruiker gedefinieerde Null-markeringen in SQL te implementeren. Vanwege de complexiteit van de Null-verwerking en logische systemen die nodig zijn om meerdere Null-markeringen te ondersteunen, heeft geen van deze voorstellen brede acceptatie gekregen.

Chris Date en Hugh Darwen , auteurs van The Third Manifesto , hebben gesuggereerd dat de SQL Null-implementatie inherent gebrekkig is en volledig moet worden geëlimineerd, wijzend op inconsistenties en gebreken in de implementatie van SQL Null-handling (met name in geaggregeerde functies) als bewijs dat het hele concept van Null is gebrekkig en zou uit het relationele model moeten worden verwijderd. Anderen, zoals auteur Fabian Pascal , hebben verklaard dat "hoe de functieberekening ontbrekende waarden moet behandelen, niet wordt bepaald door het relationele model."

Aanname van een gesloten wereld

Een ander conflictpunt met betrekking tot Nulls is dat ze het gesloten-wereldaannamemodel van relationele databases schenden door er een open-wereldaanname in te introduceren . De aanname van de gesloten wereld, die betrekking heeft op databases, stelt dat "Alles wat door de database wordt vermeld, expliciet of impliciet, is waar; al het andere is onwaar." Deze visie gaat ervan uit dat de kennis van de wereld die is opgeslagen in een database compleet is. Nulls werken echter onder de aanname van een open wereld, waarbij sommige items die in de database zijn opgeslagen als onbekend worden beschouwd, waardoor de opgeslagen kennis van de database over de wereld onvolledig is.

Zie ook

• SQL
• NULL-waarden in: Wikibook SQL
• Zelfstudie D
• ternaire logica
• Data Manipulatie Taal
• De 12 regels van Codd
• Beperking controleren
• Relationeel model/Tasmanië
• Relationeel databasebeheersysteem
• Deelnemen (SQL)
• Het derde manifest

Referenties

Verder lezen

• EF Cod. Relaties begrijpen (aflevering #7). FDT-bulletin van ACM-SIGMOD, 7 (3-4): 23-28, 1975.
• Codd, EF (1979). "Het relationele model van de database uitbreiden om meer betekenis vast te leggen". ACM-transacties op databasesystemen . 4 (4): 397-434. CiteSeerX  10.1.1.508.5701 . doi : 10.1145/320107.320109 . Vooral §2.3.
• Datum, CJ (2000). Het relationele databasemodel: een retrospectieve beoordeling en analyse: een historisch verslag en beoordeling van de bijdrage van EF Codd op het gebied van databasetechnologie . Addison Wesley Longman . ISBN 978-0-201-61294-3.
• Klein, Hans-Joachim (1994). "Hoe SQL-query's te wijzigen om zeker te zijn van antwoorden" . ACM SIGMOD-record . 23 (3): 14–20. doi : 10.1145/187436.187445 .
• Claude Rubinson, Nulls , driewaardige logica en ambiguïteit in SQL: kritiek op datums, SIGMOD Record, december 2007 (Vol. 36, No. 4)
• John Grant, Null-waarden in SQL . SIGMOD-record, september 2008 (Vol. 37, nr. 3)
• Waraporn, Narongrit en Kriengkrai Porkaew. " Null semantiek voor subquery's en atomaire predikaten ". IAENG International Journal of Computer Science 35,3 (2008): 305-313.
• Bernhard Thalheim, Klaus-Dieter Schewe (2011). "NULL 'Waarde' algebra's en logica" . Grenzen in kunstmatige intelligentie en toepassingen . 225 (Informatiemodellering en kennisbanken XXII). doi : 10.3233/978-1-60750-690-4-354 .CS1 maint: gebruikt auteursparameter ( link )
• Enrico Franconi en Sergio Tessaris, On the Logic of SQL Nulls , Proceedings of the 6th Alberto Mendelzon International Workshop on Foundations of Data Management, Ouro Preto, Brazilië, 27-30 juni 2012. pp. 114-128

Externe links

• Oracle NULL's
• Het derde manifest
• Implicaties van NULL's bij het rangschikken van gegevens
• Java-bugrapport over jdbc maakt geen onderscheid tussen null en lege string, die Sun sloot als "geen bug"