Null (SQL) - Null (SQL)

A görög kisbetűs omega (ω) karaktert használják a Null ábrázolására az adatbázis -elméletben .

A Null vagy a NULL egy speciális jelölő, amelyet a strukturált lekérdezési nyelvben használnak annak jelzésére, hogy nincs adatérték az adatbázisban . A relációs adatbázis -modell létrehozója, az EF Codd által bevezetett SQL Null teljesíti azt a követelményt, hogy minden valódi relációs adatbázis -kezelő rendszer ( RDMS ) támogassa a "hiányzó információk és nem alkalmazható információk" ábrázolását. Codd bevezette a kisbetűs görög omega (ω) szimbólum használatát a Null ábrázolásához az adatbázis -elméletben . SQL, NULLegy fenntartott szó azonosítására ezt a jelzőt.

A nullát nem szabad összetéveszteni a 0 értékkel. A null érték egy érték hiányát jelzi, ami nem azonos a nulla értékkel. Gondoljunk például arra a kérdésre, hogy "Hány könyve van Ádámnak?" A válasz lehet "nulla" (tudjuk , hogy nincs tulajdonosa ) vagy "null" ( nem tudjuk , hány tulajdonosa van). Egy adatbázistáblában ezt a választ közlő oszlop érték nélkül kezdődik (Null jelzéssel), és nem frissül a „nulla” értékkel, amíg meg nem állapítjuk, hogy Ádámnak nincs könyve.

Az SQL null állapot, nem érték. Ez a használat egészen más, mint a legtöbb programozási nyelv, ahol a hivatkozás null értéke azt jelenti, hogy nem mutat egyetlen objektumra sem .

Történelem

EF Codd megemlítette a null -okat a hiányzó adatok ábrázolásának módszereként a relációs modellben egy 1975 -ös dokumentumban az ACM - SIGMOD FDT Bulletin -ben . Codd papírja, amelyet leggyakrabban a Null szemantikájával kapcsolatban idéznek (az SQL -ben elfogadva), az 1979 -ben megjelent tanulmánya az ACM Transactions on Database Systems rendszerben , amelyben bemutatta Relational Model/Tasmania című könyvét is , bár a többi javaslat nagy része az utóbbi papír homályban maradt. 1979-es dolgozatának 2.3. Szakasza részletezi a nullszaporítás szemantikáját az aritmetikai műveletekben, valamint az összehasonlításokat, amelyek háromszoros (háromértékű) logikát alkalmaznak a nullokhoz képest; részletezi a Nulls kezelését más halmazműveleteken is (ez utóbbi kérdés ma is vitatott). Az adatbázis elmélet körökben, az eredeti javaslat a Codd (1975, 1979) most nevezik „Codd táblázatok”. Codd később megerősítette azt a követelményét, hogy minden RDBMS-nek támogatnia kell a Null-ot, hogy jelezze a hiányzó adatokat a ComputerWorld magazinban megjelent 1985-ös kétrészes cikkben .

Az 1986 -os SQL szabvány alapvetően Codd javaslatát fogadta el az IBM System R implementációs prototípusa után . Bár Don Chamberlin a nullákat (az ismétlődő sorok mellett) az SQL egyik legvitatottabb jellemzőjének ismerte fel, megvédte a Nulls in SQL tervezését, hivatkozva a pragmatikus érvekre, miszerint ez volt a legolcsóbb rendszertámogatási forma a hiányzó információkért, megmentve a programozót a sok párhuzamos alkalmazásszintű ellenőrzés (lásd félpredikátusi probléma ), ugyanakkor lehetőséget biztosít az adatbázis-tervezőnek, hogy ne használja a Null-okat, ha akarják; például a jól ismert anomáliák elkerülése érdekében ( e cikk szemantikai részében tárgyaljuk ). Chamberlin azzal érvelt, hogy a Nulls gyakorlati tapasztalatai mellett néhány hiányzó értékű funkcionalitást is biztosít, ami más nyelvi jellemzőket is eredményezett, amelyek a Null-okra támaszkodnak, például bizonyos csoportosítási konstrukciókat és külső illesztéseket. Végezetül azzal érvelt, hogy a gyakorlatban a Nullokat is gyors módszerekként használják a meglévő séma javítására, amikor az eredeti szándékán túl kell fejlődnie, és nem a hiányzó, hanem inkább nem alkalmazható információkat kódolja; például egy adatbázis, amelynek gyorsan támogatnia kell az elektromos autókat, miközben mérföld / gallon oszlopuk van.

Codd 1990-ben megjelent The Relational Model for Database Management 2. verziójában megjelent könyvében jelezte, hogy az SQL szabvány által előírt egyetlen Null nem megfelelő, és két különálló Null-típusú jelzővel kell helyettesíteni az adatok hiányának okát. Codd könyvében ezt a két Null típusú jelzőt „A-értékeknek” és „I-értékeknek” nevezik, amelyek „hiányzó, de alkalmazható” és „hiányzó, de nem alkalmazható” kifejezéseket jelentenek. Codd ajánlása megkövetelte volna, hogy az SQL logikai rendszerét kibővítsék egy négyértékű logikai rendszerrel. E további bonyolultság miatt a többféle definíciójú Null ötlete nem nyert széles körű elfogadást az adatbázis -gyakorlók területén. Ez azonban továbbra is aktív kutatási terület, számos publikáció még mindig megjelenik.

Kihívások

A Null a viták középpontjába került és vitaforrás a kapcsolódó háromértékű logika (3VL), az SQL-összekapcsolásokban való használatára vonatkozó különleges követelmények , valamint az összesített függvények és az SQL-csoportosító operátorok által megkövetelt különleges kezelés miatt. Ron van der Meyden számítástechnikai professzor a következőket foglalta össze: "Az SQL szabvány következetlenségei azt jelentik, hogy nem lehet intuitív logikai szemantikát tulajdonítani a nullok kezelésének az SQL -ben." Bár számos javaslat született e problémák megoldására, az alternatívák összetettsége megakadályozta széles körű elfogadásukat.

Nullterjedés

Aritmetikai műveletek

Mivel a Null nem adatérték, hanem egy hiányzó érték jelölője, a Null matematikai operátorai használata ismeretlen eredményt ad, amelyet Null képvisel. A következő példában a 10 -et megszorozva Null -tal Null eredményt kapunk:

10 * NULL          -- Result is NULL

Ez váratlan eredményekhez vezethet. Például, amikor megkísérlik a nullát elosztani nullával, a platformok visszaadhatják a nullát, ahelyett, hogy a várt "adatkivételt - osztást nullával" dobnák. Bár ezt a viselkedést nem határozza meg az ISO SQL szabvány, sok DBMS -gyártó hasonlóan kezeli ezt a műveletet. Például az Oracle, a PostgreSQL, a MySQL Server és a Microsoft SQL Server platformok Null eredményt adnak vissza a következőkre:

NULL / 0

Karakterlánc -összefűzés

Az SQL -ben gyakori karakterlánc -összefűzési műveletek szintén Null -ot eredményeznek, ha az egyik operandus Null. A következő példa bemutatja a Null eredményt, amelyet a Null és az SQL ||karakterlánc -összefűzési operátor használatával adtak vissza .

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

Ez nem minden adatbázis -megvalósításra igaz. Például egy Oracle RDBMS -ben a NULL és az üres karakterlánc ugyanazt jelenti, ezért „Fish” || NULL || A „Chips” eredménye a „Fish Chips”.

Összehasonlítások a NULL és a háromértékű logikával (3VL)

Mivel a Null nem tagja egyetlen adattartománynak sem , ezért nem minősül "értéknek", hanem inkább jelölőnek (vagy helyőrzőnek), amely a nem definiált értéket jelzi . Emiatt a Null -al való összehasonlítás soha nem eredményezhet igazot vagy hamisat, hanem mindig egy harmadik logikai eredményt, az Ismeretlenet. Az alábbi kifejezés logikai eredménye, amely összehasonlítja a 10 értéket a Null értékkel, ismeretlen:

SELECT 10 = NULL       -- Results in Unknown

Bizonyos Null műveletek azonban visszaadhatnak értékeket, ha a hiányzó érték nem releváns a művelet eredményéhez. Tekintsük a következő példát:

SELECT NULL OR TRUE   -- Results in True

Ebben az esetben az a tény, hogy a VAGY bal oldalán található érték nem ismerhető, nem releváns, mert a VAGY művelet eredménye igaz lesz a bal oldali értéktől függetlenül.

Az SQL három logikai eredményt valósít meg, ezért az SQL implementációknak speciális háromértékű logikát (3VL) kell biztosítaniuk . Az SQL háromértékű logikáját szabályozó szabályokat az alábbi táblázatok mutatják be ( p és q logikai állapotokat jelentenek) "Az SQL által használt igazságtáblázatok az AND, OR, és NEM megfelelnek a Kleene és Łukasiewicz háromértékű logika közös töredékének ( amelyek az implikáció meghatározásában különböznek, azonban az SQL nem határoz meg ilyen műveletet).

Ismeretlen WHERE záradékok hatása

Az SQL háromértékű logikával találkozik az adatmanipulációs nyelvben (DML) a DML-utasítások és lekérdezések predikátumainak összehasonlítása során. A WHEREzáradék hatására a DML utasítás csak azokon a sorokon hat, amelyekre a predikátum igaznak minősül. Sor, amelyek az állítmány értékeli, hogy vagy hamis, vagy ismert nem járt által INSERT, UPDATEvagy DELETEDML utasításokat, és kezelnek SELECTlekérdezések. Az ismeretlen és hamis azonos logikai eredményként való értelmezése gyakori hiba, amely a Nullok kezelése során merült fel. Az alábbi egyszerű példa bizonyítja ezt a tévedést:

SELECT *
FROM t
WHERE i = NULL;

A fenti példa lekérdezés logikailag mindig nulla sort ad vissza, mert az i oszlop és a Null összehasonlítása mindig Ismeretlenet ad vissza, még azoknál a soroknál is, ahol i Null. Az Ismeretlen eredmény hatására az SELECTutasítás összesítően elvet minden sort. (A gyakorlatban azonban néhány SQL -eszköz a Null -tal való összehasonlítással lekéri a sorokat.)

Nullspecifikus és 3VL-specifikus összehasonlítás predikátumokat tartalmaz

Az alapvető SQL összehasonlító operátorok mindig ismeretlen értéket adnak vissza, ha bármit összehasonlítanak a Null értékkel, így az SQL szabvány két speciális Null-specifikus összehasonlító predikátumot biztosít. Az IS NULLés IS NOT NULLpredikátumok (amelyek postfix szintaxist használnak ) tesztelik, hogy az adatok Null értékűek -e vagy sem.

Az SQL szabvány tartalmazza az F571 "Igazságérték -tesztek" opcionális funkciót, amely három további logikai unárius operátort vezet be (valójában hatot, ha számoljuk a tagadásukat, ami a szintaxisuk része), szintén postfix jelöléssel. A következő igazságtáblázatokkal rendelkeznek:

Az F571 funkció merőleges a jelenléte a logikai adattípus az SQL (lásd később ebben a cikkben), és annak ellenére, hogy a szintaktikai hasonlóság, F571 nem vezet logikai vagy három-értékű literálok a nyelvet. Az F571 szolgáltatás valóban jelen volt az SQL92 -ben , jóval azelőtt, hogy 1999 -ben bevezette a boolean adattípust a szabványba. Az F571 funkciót azonban kevés rendszer valósítja meg; A PostgreSQL az egyik megvalósító.

Az IS UNKNOWN hozzáadása az SQL háromértékű logikájának többi operátorához az SQL háromértékű logikáját funkcionálisan teljessé teszi , ami azt jelenti, hogy logikai operátorai bármilyen elképzelhető háromértékű logikai függvényt kifejezhetnek (kombinálva).

Azon rendszereken, amelyek nem támogatják az F571 funkciót, lehetséges az IS ISMERETLEN p emulálása minden olyan argumentum áttekintésével, amely a p kifejezést ismeretlenné teheti, és tesztelheti ezeket az argumentumokat az IS NULL vagy más NULL-specifikus függvényekkel, bár ez lehet több nehézkes.

A kizárt negyedik törvény (a WHERE záradékokban)

Az SQL háromértékű logikájában a kizárt közép , p OR NOT p törvénye már nem igaz minden p-re . Pontosabban, az SQL háromértékű logikájában a p OR NOT p ismeretlen pontosan akkor, ha p ismeretlen és egyébként igaz. Mivel a Null közvetlen összehasonlítása az ismeretlen logikai értéket eredményezi, a következő lekérdezés

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

SQL -ben nem egyenértékű a következővel

SELECT * FROM stuff;

ha az x oszlop Nullokat tartalmaz; ebben az esetben a második lekérdezés visszaad néhány sort, az első nem adja vissza, nevezetesen mindazokat, amelyekben x Null. A klasszikus kétértékű logikában a kirekesztett közép törvénye lehetővé tenné a WHERE záradék predikátum egyszerűsítését, valójában annak megszüntetését. Ha a kizárott közép törvényét kívánja alkalmazni az SQL 3VL -jére, az valójában hamis kettősség . A második lekérdezés valójában egyenértékű a következővel:

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

Így az SQL első utasításának helyes egyszerűsítéséhez minden olyan sort vissza kell adnunk, amelyben x nem null.

SELECT * FROM stuff WHERE x IS NOT NULL;

Figyelembe véve a fentieket, vegye figyelembe, hogy az SQL WHERE záradékához a kizárott közép törvényéhez hasonló tautológia írható. Feltéve, hogy az IS ISMERETLEN operátor jelen van, p VAGY (NOT p ) VAGY ( p IS ISMERETLEN) igaz minden predikátumra p . A logikusok körében ezt nevezik a kirekesztett negyedik törvénynek .

Vannak olyan SQL kifejezések, amelyekben kevésbé nyilvánvaló, hogy a hamis dilemma hol fordul elő, például:

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

nem hoz létre sorokat, mert INaz argumentumkészlet feletti egyenlőség iterált változatát jelenti, és az 1 <> NULL ismeretlen, ahogy az 1 = NULL az ismeretlen. (Ebben a példában a CAST csak néhány SQL -implementációban szükséges, mint például a PostgreSQL, amely egyébként típusellenőrzési hibával utasítaná el. Sok rendszerben a sima SELECT NULL működik az allekérdezésben.) A fenti hiányzó eset természetesen:

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

Null és ismeretlen hatása más konstrukciókban

Csatlakozik

Az egyesítések ugyanazokat az összehasonlítási szabályokat használják, mint a WHERE záradékok. Ezért óvatosan kell eljárni, ha az SQL csatlakozási feltételekben nullázható oszlopokat használ. Különösen a nullákat tartalmazó táblázat nem egyenlő önmagának természetes ön-összekapcsolásával, ami azt jelenti, hogy míg a relációs algebrában minden R relációra igaz , az SQL ön-összekapcsolás kizár minden olyan nullát tartalmazó sort, amely bárhol található. Erre a viselkedésre mutat példát a Nulls hiányzó értékű szemantikáját elemző szakasz. ${\ displaystyle R \ bowtie R = R}$

Az SQL COALESCEfüggvény vagy CASEkifejezések felhasználhatók a null egyenlőség "szimulálására" a csatlakozási feltételekben, és a IS NULLés IS NOT NULLpredikátumok az egyesítési feltételekben is. A következő predikátum teszteli az A és B értékek egyenlőségét, és a nullákat egyenlőnek tekinti.

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

CASE kifejezések

Az SQL kétféle feltételes kifejezést biztosít . Az egyiket "egyszerű CASE" -nak hívják, és úgy működik, mint egy kapcsoló utasítás . A másikat "keresett esetnek" nevezik a szabványban, és úgy működik, mint egy if ... elseif .

Az egyszerű CASEkifejezések implicit egyenlőségi összehasonlításokat használnak, amelyek ugyanazok a szabályok szerint működnek, mint a DML WHEREzáradék Nullra vonatkozó szabályai. Így egy egyszerű CASEkifejezés nem ellenőrizheti közvetlenül a Null létezését. Egy egyszerű CASEkifejezésben a Null ellenőrzése mindig Ismeretlen eredményt eredményez, például a következőkben:

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;

Mivel a kifejezés i = NULLIsmeretlen értékre áll, függetlenül attól, hogy az i oszlop milyen értéket tartalmaz (még akkor is, ha Null értéket tartalmaz), a karakterlánc 'Is Null'soha nem kerül visszaadásra.

Másrészt a "keresett" CASEkifejezés használhat olyan predikátumokat, mint IS NULLés IS NOT NULLa feltételei. A következő példa bemutatja, hogyan használhatja a keresett CASEkifejezést a Null megfelelő ellenőrzésére:

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;

A keresett CASEkifejezésben a karakterlánc 'Null Result'minden sorhoz visszatér, amelyben i Null.

Az Oracle SQL dialektusa beépített függvényt biztosít, DECODEamely használható az egyszerű CASE kifejezések helyett, és két nullát egyenlőnek tekint.

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

Végül ezek a konstrukciók NULL értéket adnak vissza, ha nem találnak egyezést; van egy alapértelmezett ELSE NULLzáradékuk.

IF nyilatkozatok az eljárási kiterjesztésekben

Az SQL/PSM (SQL Persistent Stored Modules) meghatározza az SQL eljárási kiterjesztéseit, például az IFutasítást. A nagy SQL -gyártók azonban történelmileg beépítették saját, saját eljárási kiterjesztéseiket. A ciklusok és összehasonlítások eljárási kiterjesztései a DML utasításokhoz és lekérdezésekhez hasonló Null összehasonlítási szabályok szerint működnek. A következő kódrészlet ISO SQL szabványos formátumban a Null 3VL használatát mutatja be egy IFutasításban.

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

Az IFutasítás csak azoknál az összehasonlításoknál hajt végre műveleteket, amelyek igaznak minősülnek. Azon állítások esetében, amelyek értéke hamis vagy ismeretlen, az IFutasítás átadja az irányítást a ELSEIFzáradéknak, végül pedig a ELSEzáradéknak. A fenti kód eredménye mindig az üzenet lesz, 'Result is Unknown'mivel a Null -al való összehasonlítás mindig ismeretlen értékű.

Az SQL Null hiányzó értékű szemantikájának elemzése

T. Imieliński és W. Lipski Jr. (1984) úttörő munkája keretet adott a hiányzó értékű szemantika megvalósítására irányuló különböző javaslatok szándékolt szemantikájának értékeléséhez, amelyet Imieliński-Lipski Algebras néven emlegetnek . Ez a rész nagyjából követi az "Alice" tankönyv 19. fejezetét. Hasonló előadás jelenik meg Ron van der Meyden recenziójában, 10.4.

Válogatásokban és előrejelzésekben: gyenge reprezentáció

A hiányzó információkat reprezentáló konstrukciók, mint például a Codd táblák, valójában relációk halmazát hivatottak képviselni, egy -egy a paramétereik minden lehetséges példányosítására; a Codd táblák esetében ez azt jelenti, hogy a Nullokat valamilyen konkrét értékkel kell kicserélni. Például,

Egy konstrukcióról (például egy Codd tábláról) azt mondják, hogy erős képviseleti rendszer (a hiányzó információkból), ha a konstrukción végrehajtott lekérdezésre adott bármely válasz specifikálható, hogy választ kapjon az általa képviselt relációkra vonatkozó bármely megfelelő lekérdezésre. a konstrukció modelljeinek tekintik . Pontosabban, ha q egy lekérdezési képlet a "tiszta" relációk relációs algebrai állapotában, és ha q a hiányzó információk ábrázolására szolgáló konstrukcióra emeli, akkor az erős ábrázolás rendelkezik azzal a tulajdonsággal, hogy minden q és (táblázat) lekérdezéshez A konstrukció T , q feloldja az összes választ a konstrukcióra, azaz:

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

(A fentieknek érvényesnek kell lenniük az olyan lekérdezések esetén, amelyek tetszőleges számú táblát vesznek fel argumentumként, de az egy táblázatra való korlátozás elegendő ehhez a vitához.) Nyilvánvaló, hogy a Codd táblák nem rendelkeznek ezzel az erős tulajdonsággal, ha a kiválasztásokat és előrejelzéseket a lekérdezési nyelv részének tekintik. Például az összes válasz

SELECT * FROM Emp WHERE Age = 22;

tartalmaznia kell annak lehetőségét, hogy létezik egy olyan kapcsolat, mint az EmpH22. A Codd táblák azonban nem képviselhetik a diszjunkciós "eredményt, esetleg 0 vagy 1 sorral". Egy többnyire elméleti jellegű eszköz, amelyet feltételes táblának (vagy c-táblának) neveznek , azonban ilyen választ adhat:

ahol a feltétel oszlopot úgy értelmezik, hogy a sor nem létezik, ha a feltétel hamis. Kiderül, hogy mivel a c-tábla feltételes oszlopában található képletek tetszőleges propozíciós logikai képletek lehetnek, egy olyan algoritmus, amely arra a problémára vonatkozik, hogy a c-tábla valamilyen konkrét összefüggést képvisel -e, komplex NP- komplexitású, tehát kevés gyakorlati értéke.

Ezért kívánatos a képviselet gyengébb fogalma. Imielinski és Lipski bevezették a gyenge ábrázolás fogalmát , amely lényegében lehetővé teszi (feloldott) lekérdezéseket egy konstrukció felett, hogy csak egy biztos információért adja vissza az ábrázolást , azaz ha érvényes a konstrukció minden " lehetséges világ " példányára (modelljére). Konkrétan egy konstrukció gyenge ábrázolási rendszer, ha

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

A fenti egyenlet jobb oldala a biztos információ, azaz olyan információ, amely minden bizonnyal kinyerhető az adatbázisból, függetlenül attól, hogy milyen értékeket használnak a Nulls helyett az adatbázisban. A fenti példában könnyen belátható, hogy a lekérdezés kiválasztásának minden lehetséges modellje (azaz a biztos információ) metszéspontja valójában üres, mert például a (felemelt) lekérdezés nem ad vissza sorokat az EmpH37 relációhoz. Általánosabban Imielinski és Lipski kimutatta, hogy a Codd táblák gyenge ábrázolási rendszer, ha a lekérdezés nyelve a vetületekre, a kijelölésekre (és az oszlopok átnevezésére) korlátozódik. Azonban amint a lekérdezési nyelvhez csatlakozásokat vagy egyesítéseket adunk, még ez a gyenge tulajdonság is elvész, amint azt a következő szakasz is bizonyítja. WHERE Age = 22

Ha figyelembe vesszük a csatlakozásokat vagy a szakszervezeteket: még a gyenge képviselet sem

Tekintsük a következő lekérdezést ugyanazon Codd tábla Emp az előző részben:

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

Bármilyen konkrét értéket is választana NULLHarriet korára, a fenti lekérdezés visszaadja az Emp bármely modelljének teljes oszlopát , de amikor a (felemelt) lekérdezést magára az Emp -re futtatja , Harriet mindig hiányzik, azaz :

Így amikor szakszervezeteket adnak hozzá a lekérdezési nyelvhez, a Codd táblák nem is a hiányzó információk gyenge ábrázolási rendszerei, vagyis a rájuk vonatkozó lekérdezések nem is jelentenek minden biztos információt. Fontos megjegyezni, hogy az UNION szeméttan a nullákról, amelyet egy későbbi részben tárgyalunk, ebben a lekérdezésben még csak szóba sem került. A két allekérdezés "feledékeny" jellege volt az egyetlen, amellyel garantálni lehetett, hogy bizonyos biztos információkat nem jelentettek be, amikor a fenti lekérdezést a Codd tábla Emp.

A természetes összekapcsolások esetében az a példa, amely bizonyítja, hogy bizonyos információkat bizonyos jelentések nem jelenthetnek be, kissé bonyolultabb. Tekintsük az asztalt

és a lekérdezés

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

A fenti történések intuíciója az, hogy az allekérdezésben lévő előrejelzéseket reprezentáló Codd táblázatok elveszik a nyomát annak a ténynek, hogy az F12. F2 és F23.F2 oszlopban található Nullok valójában a J táblázat eredeti példányainak másolatai. Ez a megfigyelés arra utal, hogy a Codd táblák viszonylag egyszerű továbbfejlesztése (ami ebben a példában helyesen működik) az lenne, ha a Skolem állandókat (vagyis a Skolem függvényeket, amelyek szintén állandó függvények ) használnánk, mondjuk ω ₁₂ és ω ₂₂ egyetlen NULL szimbólum helyett. Egy ilyen megközelítés, az úgynevezett v-táblák vagy Naive táblák, számítási szempontból olcsóbb, mint a fentebb tárgyalt c-táblázatok. Mindazonáltal még mindig nem teljes megoldás a hiányos információkra abban az értelemben, hogy a v-táblák csak gyenge ábrázolást jelentenek azoknál a lekérdezéseknél, amelyek nem használnak tagadást a kiválasztásban (és nem használnak halmazkülönbséget sem). Az első példa, amelyet ebben a szakaszban vizsgálunk, negatív kiválasztási záradékot használ , tehát ez is egy olyan példa, ahol a v-tables lekérdezések nem jelentenek biztos információkat. WHERE Age <> 22

Ellenőrizze a korlátozásokat és az idegen kulcsokat

Az elsődleges hely, ahol az SQL háromértékű logikája metszi az SQL Data Definition Language (DDL) nyelvet , ellenőrzési korlátozások formájában van . Az oszlopra helyezett ellenőrzési kényszer kissé eltérő szabályrendszer alapján működik, mint a DML WHEREzáradék. Míg a DML WHEREzáradéknak igaznak kell lennie egy sorra, az ellenőrzési kényszer nem értékelheti hamisnak. (Logikai szempontból a kijelölt értékek Igaz és Ismeretlen.) Ez azt jelenti, hogy az ellenőrzési kényszer sikeres lesz, ha az ellenőrzés eredménye igaz vagy Ismeretlen. A következő példatáblázat ellenőrzési kényszerrel megtiltja, hogy egész számok kerüljenek az i oszlopba , de lehetővé teszi a Null beszúrását, mivel az ellenőrzés eredménye mindig Ismeretlen lesz a nullákhoz.

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

Mivel a WHERE záradékhoz képest megváltoztak a kijelölt értékek , logikai szempontból a kizárt közép törvénye a CHECK korlátozások tautológiája , vagyis mindig sikerül. Továbbá, feltételezve, hogy a nullákat létező, de ismeretlen értékként kell értelmezni, néhány kóros ELLENŐRZÉS lehetővé teszi a nullák beszúrását, amelyeket soha nem lehet helyettesíteni semmilyen nem-null értékkel. CHECK (p OR NOT p)

Annak érdekében, hogy egy oszlopot kényszerítse a Nulls elutasítására, a NOT NULLkorlátozás alkalmazható, amint az alábbi példában látható. A NOT NULLmegkötés szemantikailag egyenértékű egy predikátummal ellátott ellenőrzési kényszerrelIS NOT NULL .

CREATE TABLE t ( i INTEGER NOT NULL );

Alapértelmezés szerint az idegen kulcsokra vonatkozó ellenőrzési korlátozások sikeresek, ha az ilyen kulcsok bármelyik mezője Null. Például az asztal

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));

lehetővé tenné azoknak a soroknak a beszúrását, ahol a szerző_utolsó vagy a szerző_első, NULLfüggetlenül attól, hogy a Szerzők táblázat hogyan van definiálva vagy mit tartalmaz. Pontosabban, ezeknek a mezőknek a nullája bármilyen értéket engedélyezne a másikban, még akkor is, ha ez nem található a Szerzők táblázatban. Például, ha a Szerzők csak tartalmaznak ('Doe', 'John'), akkor ('Smith', NULL)teljesíti az idegen kulcsra vonatkozó korlátozást. Az SQL-92 két további opciót adott hozzá a mérkőzések szűkítéséhez ilyen esetekben. Ha MATCH PARTIALa REFERENCESnyilatkozat után hozzáadjuk, akkor minden nem-nullnak meg kell egyeznie az idegen kulccsal, pl. ('Doe', NULL)Még mindig egyezne, de ('Smith', NULL)nem. Végül, ha MATCH FULLhozzáadjuk, akkor ('Smith', NULL)sem felelne meg a megkötésnek, de (NULL, NULL)mégis megfelelne.

Külső csatlakozások

Példa SQL külső összekapcsolási lekérdezésre Null helyőrzőkkel az eredményhalmazban. A Null jelölőket NULLaz eredmények helyett az adatok helyett a szó jelöli . Az eredmények a Microsoft SQL Server -től származnak , ahogy az SQL Server Management Studio mutatja.

Az SQL külső összekapcsolásai , beleértve a bal külső illesztéseket, a jobb oldali külső összekapcsolásokat és a teljes külső összekapcsolásokat, automatikusan Nullokat állítanak elő helyőrzőként a kapcsolódó táblázatokban hiányzó értékekhez. A bal oldali külső illesztéseknél például nullákat kell létrehozni a LEFT OUTER JOINkezelő jobb oldalán megjelenő táblázatból hiányzó sorok helyett . A következő egyszerű példa két táblázat segítségével mutatja be a Null helyőrző előállítását egy bal külső csatlakozásban.

Az első táblázat ( Munkavállaló ) tartalmazza a munkavállalói azonosító számokat és neveket, míg a második táblázat ( Telefonszám ) a kapcsolódó munkavállalói azonosító számokat és telefonszámokat tartalmazza , amint az alább látható.

Az alábbi minta SQL lekérdezés bal külső illesztést hajt végre ezen a két táblán.

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

A lekérdezés által generált eredményhalmaz bemutatja, hogy az SQL hogyan használja a Null-t helyőrzőként a jobb oldali ( Telefonszám ) táblázatból hiányzó értékekhez , amint az alább látható.

Összesített függvények

Az SQL összesítési függvényeket határoz meg, hogy egyszerűsítse az adatok szerveroldali összesítési számításait. A COUNT(*)függvény kivételével minden összesített függvény Null-eliminációs lépést hajt végre, így a Nullok nem vesznek részt a számítás végeredményében.

Ne feledje, hogy a Null megszüntetése nem egyenlő azzal, hogy a Null -ot nullával helyettesíti. Például a következő táblázatban AVG(i)(értékeinek átlaga i) más eredményt ad, mint AVG(j):

Itt AVG(i)200 (150, 200 és 250 átlag), míg AVG(j)150 (150, 200, 250 és 0 átlag). Ennek jól ismert mellékhatása, hogy az SQL-ben AVG(z)egyenértékű a not SUM(z)/COUNT(*)de-vel SUM(z)/COUNT(z).

Az összesített függvény kimenete is lehet Null. Íme egy példa:

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

Ez a lekérdezés mindig pontosan egy sort ad ki, számolva azon munkavállalók számát, akiknek vezetékneve "Jones" -ot tartalmaz, és megadja az ezen alkalmazottak minimális és maximális bérét. Mi történik azonban, ha egyik alkalmazott sem felel meg a megadott kritériumoknak? Az üres halmaz minimális vagy maximális értékének kiszámítása lehetetlen, ezért ezeknek az eredményeknek NULL -nak kell lenniük, ami azt jelzi, hogy nincs válasz. Ez nem Ismeretlen érték, hanem Null, amely az érték hiányát jelzi. Az eredmény a következő lenne:

Ha két nulla egyenlő: csoportosítás, rendezés és néhány beállított művelet

Mivel az SQL: 2003 az összes Null -jelzőt egymással egyenlőtlenként határozza meg, speciális definícióra volt szükség ahhoz, hogy egyes műveletek végrehajtása során a Null -csoportokat csoportosítsa. Az SQL "bármely két egymással egyenlő értéket vagy bármely két nullát" nem különállóként definiál. Ez a nem különálló definíció lehetővé teszi az SQL számára a nullák csoportosítását és rendezését a GROUP BYzáradék (és más csoportosítást végző kulcsszavak) használatakor.

Más SQL műveletek, záradékok és kulcsszavak a "nem különböznek" kifejezést használják a Nullok kezelésére. Ezek a következők:

• PARTITION BY záradék rangsorolási és ablakos funkciók, mint például ROW_NUMBER
• UNION, INTERSECTés EXCEPToperátor, amelyek a NULL -eket azonosnak tekintik a sorok összehasonlítása/megszüntetése céljából
• DISTINCTkulcsszó a SELECTlekérdezésekben

Az elvet, miszerint a nullák nem egyenlők egymással (hanem inkább azt, hogy az eredmény ismeretlen), ténylegesen megsértik az UNIONoperátor SQL -specifikációjában , amely azonosítja a nullákat egymással. Következésképpen, néhány SQL -művelet, például az unió vagy a differencia, olyan eredményeket hozhat, amelyek nem reprezentálják a megbízható információkat, ellentétben a NULL -lel kifejezett összehasonlítással (pl WHERE. A fent tárgyalt záradékkal). Codd 1979 -es javaslatában (amelyet alapvetően az SQL92 fogadott el) ezt a szemantikai következetlenséget racionalizálják azzal az érvvel, hogy a halmazműveletekben az ismétlődések eltávolítása "alacsonyabb részletességi szinten történik, mint a visszakeresési műveletek értékelése során az egyenlőségi tesztelés".

Az SQL szabvány nem határoz meg kifejezetten alapértelmezett rendezési sorrendet a Nulls számára. Ehelyett a megfelelõ rendszereken a nullákat az összes adatérték elõtt vagy után rendezheti a lista NULLS FIRSTvagy NULLS LASTzáradékaival ORDER BY. Nem minden DBMS -gyártó hajtja végre ezt a funkciót. Azok a szállítók, akik nem valósítják meg ezt a funkciót, különböző kezelési módokat adhatnak meg a Null rendezéshez a DBMS -ben.

Hatás az index működésére

Egyes SQL -termékek nem indexelik a NULL -t tartalmazó kulcsokat. Például a 8.3 előtti PostgreSQL verziók nem, de a B-fa index dokumentációja ezt kijelenti

A B-fák képesek egyenlőség- és tartománylekérdezéseket kezelni olyan adatokra, amelyek bizonyos sorrendbe rendezhetők. A PostgreSQL lekérdezéstervező különösen fontolóra veszi a B-fa index használatát, amikor egy indexelt oszlop szerepel az összehasonlításban az alábbi operátorok egyikével: <≤ = ≥>

Ezen operátorok kombinációival egyenértékű konstrukciók, mint például a BETWEEN és IN, B-fa indexkereséssel is megvalósíthatók. (De vegye figyelembe, hogy az IS NULL nem egyenlő a = értékkel, és nem indexelhető.)

Azokban az esetekben, amikor az index kikényszeríti az egyediséget, a NULL -ek kizárásra kerülnek az indexből, és az egyediség nem érvényesül a NULL -ek között. Ismét idézve a PostgreSQL dokumentációjából:

Ha egy indexet egyedinek nyilvánítanak, nem megengedett több, azonos indexű értékű táblázat. A nullákat nem tekintik egyenlőnek. A több oszlopos egyedi index csak azokat az eseteket utasítja el, amikor az összes indexelt oszlop két sorban egyenlő.

Ez összhangban van a skaláris Null összehasonlítások SQL: 2003 által meghatározott viselkedésével.

Egy másik módszer a nullák indexelésére magában foglalja, hogy azokat az SQL: 2003-ban meghatározott viselkedésnek megfelelően nem különállóként kezeljük . Például a Microsoft SQL Server dokumentációja a következőket írja ki:

Indexelés céljából a NULL -ek egyenlők. Ezért nem hozható létre egyedi index vagy UNIQUE korlátozás, ha a kulcsok NULL értékűek egynél több sorban. Válassza ki a NULL értékű oszlopokat, ha egyedi indexhez vagy egyedi korlátozáshoz tartozó oszlopokat választ.

Mindkét indexelési stratégia összhangban van a Nulls SQL: 2003 által meghatározott viselkedésével. Mivel az indexelési módszereket nem határozza meg kifejezetten az SQL: 2003 szabvány, a Nulls indexelési stratégiái teljes mértékben a szállítókra vannak bízva, hogy megtervezzék és megvalósítsák.

Nullkezelési funkciók

Az SQL két függvényt határoz meg a Nulls kifejezett kezelésére: NULLIFés COALESCE. Mindkét függvény a keresett CASEkifejezések rövidítése .

NULLIF

A NULLIFfüggvény két paramétert fogad el. Ha az első paraméter megegyezik a második paraméterrel, NULLIFakkor a Null értéket adja vissza. Ellenkező esetben az első paraméter értéke kerül visszaadásra.

NULLIF(value1, value2)

Tehát NULLIFa következő CASEkifejezés rövidítése :

CASE WHEN value1 = value2 THEN NULL ELSE value1 END

EGYESÜL

A COALESCEfüggvény elfogadja a paraméterek listáját, és visszaadja az első nem null értéket a listából:

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

COALESCEa következő SQL CASEkifejezés rövidítése :

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

Néhány SQL DBMS a gyártókhoz hasonló funkciókat valósít meg COALESCE. Egyes rendszerek (pl. Transact-SQL ) megvalósítanak egy ISNULLfunkciót, vagy más hasonló funkciókat, amelyek funkcionálisan hasonlóak COALESCE. (A Transact-SQL Isfunkcióival kapcsolatban lásd a ISfüggvényeket.)

NVL

Az Oracle NVLfüggvény két paramétert fogad el. Visszaadja az első nem NULL paramétert, vagy NULL, ha minden paraméter NULL.

Egy COALESCEkifejezés ekvivalens NVLkifejezéssé alakítható át a következőképpen:

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

alakul:

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

Ennek a függvénynek az az esete, hogy egy kifejezésben a NULL értéket lecseréli egy olyan értékre, mint amilyen: NVL(SALARY, 0)„ha SALARYNULL, akkor cserélje ki a 0 értékkel”.

Van azonban egy figyelemre méltó kivétel. A legtöbb megvalósításban COALESCEértékeli a paramétereit, amíg el nem éri az első nem NULL NVLparamétert , míg kiértékeli az összes paramétert. Ez több okból is fontos. Az első nem NULL paraméter utáni paraméter lehet egy függvény, amely lehet számításilag drága, érvénytelen, vagy váratlan mellékhatásokat okozhat.

Null és ismeretlen adattípusok

A NULL literal nincs tipizálva az SQL -ben, ami azt jelenti, hogy nincs egész számként, karakterként vagy más specifikus adattípusként kijelölve . Emiatt néha kötelező (vagy kívánatos), hogy a Nullokat kifejezetten meghatározott adattípusokká alakítsák át. Például, ha az RDBMS támogatja a túlterhelt függvényeket , előfordulhat, hogy az SQL nem tudja automatikusan feloldani a megfelelő függvényt anélkül, hogy ismerné az összes paraméter adattípusát, beleértve azokat is, amelyeknél a Null át van adva.

Az SQL-92-ben bevezetett program NULLsegítségével a literálból egy adott típusú Null- re konvertálható . Például: CAST

CAST (NULL AS INTEGER)

az INTEGER típusú hiányzó értéket jelenti.

Az Ismeretlen tényleges gépelése (külön -külön vagy sem a NULL -tól) eltérő az SQL implementációk között. Például a következő

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

elemzi és sikeresen végrehajtja bizonyos környezetekben (pl. SQLite vagy PostgreSQL ), amelyek egyesítik a NULL logikai értéket az Ismeretlennel, de másokban nem tudják elemezni (pl. SQL Server Compact esetén ). A MySQL e tekintetben a PostgreSQL -hez hasonlóan viselkedik (azzal a kisebb kivétellel, hogy a MySQL az IGAZ és a HAMIS értékeket nem különbözteti meg az 1 -es és 0 -as szokásos egész számoktól). A PostgreSQL ezenkívül egy IS UNKNOWNpredikátumot is megvalósít , amellyel tesztelhető, hogy a háromértékű logikai eredmény ismeretlen-e, bár ez csak szintaktikai cukor.

BOOLEAN adattípus

Az ISO SQL: 1999 szabvány bevezette a BOOLEAN adattípust az SQL-be, de ez még mindig csak egy opcionális, nem magos, T031 kódolású szolgáltatás.

Korlátozás NOT NULLesetén az SQL BOOLEAN úgy működik, mint más nyelvek logikai típusa . Korlátlanul azonban a BOOLEAN adattípus - annak ellenére, hogy a neve - tartalmazhatja az TRUE, FALSE és UNKNOWN igazságértékeket, amelyek mindegyike logikai literálként van definiálva a szabvány szerint. A szabvány azt is állítja, hogy a NULL és az ISMERETLEN "felcserélhető módon pontosan ugyanazt jelenti".

A Boole -típust sok kritika érte, különösen az UNKNOWN literal kötelezett viselkedése miatt, amely soha nem egyenlő önmagával a NULL -lel való azonosulás miatt.

Amint azt fentebb tárgyaltuk, az SQL PostgreSQL implementációjában a Null az összes ISMERETLEN eredmény megjelenítésére szolgál, beleértve az UNKNOWN BOOLEAN -t is. A PostgreSQL nem valósítja meg az UNKNOWN literal -t (bár az IS UNKNOWN operátort valósítja meg, ami ortogonális tulajdonság.) A legtöbb más nagy gyártó nem támogatja a Boole -típust (a T031 -ben meghatározottak szerint) 2012 -től. Az Oracle PL eljárási része /SQL támogatja a BOOLEAN változókat; ezekhez NULL is hozzárendelhető, és az érték azonos az UNKNOWN értékkel.

Vita

Gyakori hibák

A Null működésének félreértése számos hiba oka az SQL kódban, mind az ISO szabványos SQL utasításokban, mind a valós adatbázis-kezelő rendszerek által támogatott specifikus SQL nyelvjárásokban. Ezek a hibák általában a Null és a 0 (nulla), vagy egy üres karakterlánc (egy nulla hosszúságú karakterláncérték, SQL -ben ábrázolt) összetévesztésének következményei ''. A null értéket azonban az SQL szabvány úgy határozza meg, hogy eltér mind az üres karakterlánctól, mind a számértéktől 0. Míg a Null érték hiányát jelzi, az üres karakterlánc és a numerikus nulla egyaránt a tényleges értékeket jelöli.

Klasszikus hiba az a kísérlet, hogy az egyenlő operátort =a kulcsszóval NULLegyütt használják a Nulls sorok megkeresésére. Az SQL szabvány szerint ez érvénytelen szintaxis, és hibaüzenethez vagy kivételhez vezet. De a legtöbb megvalósítás elfogadja a szintaxist, és értékeli az ilyen kifejezéseket UNKNOWN. Ennek következménye, hogy nem találhatók sorok - függetlenül attól, hogy léteznek -e nullákkal rendelkező sorok vagy sem. A Nulls sorok lekérésének javasolt módja a predikátum használata IS NULLhelyett = NULL.

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

Egy kapcsolódó, de finomabb példában a WHEREzáradék vagy a feltételes utasítás összehasonlíthatja az oszlop értékét egy állandóval. Gyakran tévesen feltételezik, hogy egy hiányzó érték "kisebb" vagy "nem egyenlő" állandóval, ha a mező Null értéket tartalmaz, de valójában az ilyen kifejezések Ismeretlen értéket adnak vissza. Az alábbiakban egy példa látható:

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

Ezek a zavarok azért merülnek fel, mert az identitás törvénye korlátozott az SQL logikájában. Amikor egyenlőség-összehasonlításokkal foglalkozunk a NULLliterál vagy az UNKNOWNigazság-érték használatával, az SQL mindig visszatér UNKNOWNa kifejezés eredményeként. Ez egy részleges ekvivalencia reláció, és az SQL-t egy nem reflexív logika példájává teszi .

Hasonlóképpen, a nullákat gyakran összetévesztik az üres karakterláncokkal. Tekintsük a LENGTHfüggvényt, amely a karakterlánc karaktereinek számát adja vissza. Ha egy Null értéket ad át ebbe a függvénybe, a függvény Null értéket ad vissza. Ez váratlan eredményekhez vezethet, ha a felhasználók nem ismerik jól a 3 értékű logikát. Az alábbiakban egy példa látható:

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

Ezt bonyolítja az a tény, hogy egyes adatbázis -interfészprogramokban (vagy akár adatbázis -implementációkban, például az Oracle -ben) a NULL üres karakterláncként kerül jelentésre, és az üres karakterláncok hibásan tárolhatók NULL -ként.

Kritikák

A Null ISO SQL implementációja kritika, vita tárgya és változtatásra szólít fel. Az Adatbázis-kezelés relációs modellje: 2. verzióban Codd azt javasolta, hogy a Null SQL-implementációja hibás, és azt két különálló Null-típusú markerrel kell helyettesíteni. Az általa javasolt jelölők a "Hiányzó, de alkalmazható" és a "Hiányzó, de nem alkalmazható" szavak , azaz A-értékek és I-értékek . A Codd ajánlása, ha elfogadják, egy négyértékű logika megvalósítását igényelte volna az SQL-ben. Mások azt javasolták, hogy további Null típusú jelölőket vegyenek fel a Codd ajánlásába, hogy még több okot jelezzenek arra vonatkozóan, hogy egy adatérték "hiányzik", ami növeli az SQL logikai rendszerének összetettségét. Különböző időpontokban javaslatokat terjesztettek elő több felhasználó által definiált Null jelölő implementálására az SQL-ben. A több Null-marker támogatásához szükséges Null-kezelési és logikai rendszerek összetettsége miatt e javaslatok egyike sem kapott széles körű elfogadást.

Chris Date és Hugh Darwen , a Harmadik kiáltvány szerzői azt javasolták, hogy az SQL Null megvalósítása eredendően hibás, és azt teljesen ki kell küszöbölni, bizonyítékként arra, hogy következetlenségek és hibák vannak az SQL Null-kezelés megvalósításában (különösen az összesített funkciókban). a Null teljes fogalma hibás, és el kell távolítani a relációs modellből. Mások, például a szerző, Fabian Pascal , kijelentették, hogy "a függvényszámítás hogyan kezeli a hiányzó értékeket, nem a relációs modell határozza meg".

Zárt világ feltételezése

A Nullokat érintő konfliktus másik pontja az, hogy megsértik a relációs adatbázisok zárt világ feltételezési modelljét azáltal, hogy nyitott világ feltételezést vezetnek be. A zárt világ feltételezése, ahogy az adatbázisokra vonatkozik, kijelenti, hogy "Minden, amit az adatbázis kimondottan vagy implicit módon állít, igaz; minden más hamis." Ez a nézet azt feltételezi, hogy az adatbázisban tárolt világ ismerete teljes. A nullák azonban a nyitott világ feltételezése szerint működnek, amelyben az adatbázisban tárolt egyes elemeket ismeretlennek tekintik, így az adatbázis tárolt világismerete hiányos.

Lásd még

• SQL
• NULL -ok: Wikibook SQL
• Oktatóanyag D.
• Háromszoros logika
• Adatkezelési nyelv
• Codd 12 szabálya
• Ellenőrizze a korlátozást
• Relációs modell/Tasmánia
• Relációs adatbázis -kezelő rendszer
• Csatlakozás (SQL)
• A harmadik kiáltvány

Hivatkozások

További irodalom

• EF Codd. A kapcsolatok megértése (7. részlet). FDT Bulletin of ACM-SIGMOD, 7 (3-4): 23–28, 1975.
• Codd, EF (1979). "Az adatbázis relációs modelljének kibővítése, hogy több értelmet nyerjen". ACM Transactions on Database Systems . 4 (4): 397–434. CiteSeerX  10.1.1.508.5701 . doi : 10.1145/320107.320109 . Különösen a 2.3.
• Dátum, CJ (2000). The Database Relational Model: A Retrospective Review and Analysis: A Historical Assessment and Assessment of EF Codd's Contribution to the Field of Database Technology . Addison Wesley Longman . ISBN 978-0-201-61294-3.
• Klein, Hans-Joachim (1994). "Hogyan lehet módosítani az SQL lekérdezéseket a biztos válaszok biztosítása érdekében" . ACM SIGMOD rekord . 23. (3): 14–20. doi : 10.1145/187436.187445 .
• Claude Rubinson, Nulls, Three-Value Logic, and Ambiguity in SQL: Critiquing Date's Critique , SIGMOD Record, 2007. december (36. évfolyam, 4. szám)
• John Grant, Nullértékek az SQL -ben . SIGMOD Record, 2008. szeptember (37. kötet, 3. sz.)
• Waraporn, Narongrit és Kriengkrai Porkaew. " Null szemantika allekérdezésekhez és atomi predikátumokhoz ". IAENG International Journal of Computer Science 35.3 (2008): 305-313.
• Bernhard Thalheim, Klaus-Dieter Schewe (2011). "NULL" érték "algebras és logika . Határok a mesterséges intelligenciában és az alkalmazásokban . 225 (Információs modellezés és tudásbázisok XXII). doi : 10.3233/978-1-60750-690-4-354 .CS1 maint: szerzők paramétert használ ( link )
• Enrico Franconi és Sergio Tessaris, Az SQL Nulls logikájáról , Proceedings of the 6. Alberto Mendelzon International Workshop on Foundations of Data Management, Ouro Preto, Brazília, 2012. június 27–30., 114–128.

Külső linkek

• Oracle NULL -ok
• A harmadik kiáltvány
• A NULL -ek hatása az adatok szekvenálására
• Java hibajelentés arról, hogy a jdbc nem különbözteti meg a null és üres karakterláncokat, amelyeket a Sun "nem hibaként" zárt be