Optionen zum Entfernen von NULL-fähigen Spalten aus einem DB-Modell (um die dreiwertige Logik von SQL zu vermeiden)?

Question

Vor einiger Zeit habe ich das Buch SQL and Relational Theory by C. J. Date gelesen. Der Autor ist dafür bekannt, dass er die dreiwertige Logik von SQL (3VL) kritisiert. ¹⁾

Der Autor macht einige Stärken, warum 3VL in SQL sollte vermieden werden, er ist jedoch nicht skizzieren, wie ein Datenbankmodell aussehen würde, wenn Nullable-Spalten nicht erlaubt waren. Ich habe ein wenig darüber nachgedacht und habe folgende Lösungen gefunden. Wenn ich andere Gestaltungsmöglichkeiten verpasst habe, würde ich gerne von ihnen hören!

¹⁾ Datum Kritik an der SQL der 3VL wiederum wurde auch kritisiert: siehe this paper by Claude Rubinson (enthält die ursprüngliche Kritik von C. J. Date).

---

Beispieltabelle

Als Beispiel nehmen die folgende Tabelle, in der wir eine NULL festlegbare Spalte (DateOfBirth):

# +-------------------------------------------+ 
# |     People     | 
# +------------+--------------+---------------+ 
# | PersonID | Name  | DateOfBirth | 
# +============+--------------+---------------+ 
# | 1   | Banana Man | NULL   | 
# +------------+--------------+---------------+ 

---

Option 1: Emuliert NULL durch ein Flag und einen Standardwert:

Anstatt die Spalte auf Null zu setzen, wird jeder Standardwert angegeben (z. 1900-01-01). Eine zusätzliche Spalte BOOLEAN gibt an, ob der Wert in DateOfBirth einfach ignoriert werden soll oder ob er tatsächlich Daten enthält.

# +------------------------------------------------------------------+ 
# |        People'        | 
# +------------+--------------+----------------------+---------------+ 
# | PersonID | Name  | IsDateOfBirthKnown | DateOfBirth | 
# +============+--------------+----------------------+---------------+ 
# | 1   | Banana Man | FALSE    | 1900-01-01 | 
# +------------+--------------+----------------------+---------------+ 

---

Option 2: eine Spalte von -zulässige in eine separate Tabelle zum Drehen:

Die nullable Spalte durch eine neue Tabelle ersetzt (DatesOfBirth). Wenn ein Datensatz für diese Spalte keine Daten hat, wird es keinen Eintrag in der neuen Tabelle sein:

# +---------------------------+ 1 0..1 +----------------------------+ 
# |   People'   | <-------> |   DatesOfBirth  | 
# +------------+--------------+   +------------+---------------+ 
# | PersonID | Name  |   | PersonID | DateOfBirth | 
# +============+--------------+   +============+---------------+ 
# | 1   | Banana Man | 
# +------------+--------------+ 

Während dies wie die bessere Lösung scheint, würde dies möglicherweise in vielen Tabellen führt, die sein müssen beigetreten für eine einzelne Abfrage. Da OUTER JOIN s nicht erlaubt sind (weil sie NULL in die Ergebnismenge einführen würden), könnten möglicherweise alle notwendigen Daten nicht mehr wie bisher mit nur einer einzigen Abfrage abgerufen werden.

---

Frage: Gibt es noch andere Möglichkeiten zur Beseitigung von NULL (und wenn ja, was sind sie)?

Answer 1

Ich sah Date Kollege Hugh Darwen dieses Thema in einer ausgezeichneten Präsentation "Umgang mit fehlenden Informationen ohne Verwendung von NULL" zu diskutieren, die auf the Third Manifesto website verfügbar ist.

Seine Lösung ist eine Variante Ihres zweiten Ansatzes. Es ist sechste Normalform, mit Tischen sowohl Geburtsdatum zu halten und Kennungen, wo es unbekannt ist:

# +-----------------------------+ 1 0..1 +----------------------------+ 
# |   People'    | <-------> |   DatesOfBirth  | 
# +------------+----------------+   +------------+---------------+ 
# | PersonID | Name   |   | PersonID | DateOfBirth | 
# +============+----------------+   +============+---------------+ 
# | 1   | Banana Man |   ! 2   | 20-MAY-1991 | 
# | 2   | Satsuma Girl |   +------------+---------------+ 
# +------------+----------------+ 
#         1 0..1 +------------+ 
#         <-------> | DobUnknown | 
#           +------------+ 
#           | PersonID | 
#           +============+ 
#           | 1   | 
#           +------------+ 

von Menschen wählen dann alle drei Tabellen erfordert Beitritt, einschließlich vorformulierten die unbekannten Geburtsdaten anzuzeigen.

Natürlich ist dies etwas theoretisch. Der Zustand von SQL ist in diesen Tagen noch nicht ausreichend fortgeschritten, um all dies zu bewältigen. Hughs Vortrag deckt diese Mängel ab. Eine Sache, die er erwähnt, ist nicht ganz richtig: Einige Varianten von SQL unterstützen mehrere Zuweisungen - zum Beispiel Oracle's INSERT ALL syntax.

Answer 2

ich es nicht gelesen haben, aber es gibt einen Artikel namens Wie fehlende Informationen Griff mit S-by-C auf der der Third Manifesto Website, die von Hugh Darwen und C. J. Datum laufen gelassen. Dies ist nicht von C.J.Datum, aber ich nehme an, dass, da es einer der Artikel auf dieser Website ist, es wahrscheinlich seinen Meinungen ähnlich ist.

Answer 3

Eine Alternative kann das entity-attribute-value Modell:

entity attribute value 
1  name   Banana Man 
1  birthdate 1968-06-20 

Wenn das Geburtsdatum unbekannt ist, würde man nur die entsprechende Zeile weglassen.

Answer 4

Option 3: Onus auf dem Aufzeichnungs Schriftsteller:

CREATE TABLE Person 
(
    PersonId int PRIMARY KEY IDENTITY(1,1), 
    Name nvarchar(100) NOT NULL, 
    DateOfBirth datetime NOT NULL 
) 

Warum ein Modell contort null Darstellung zu ermöglichen, wenn es Ihr Ziel, sie zu beseitigen ist?

Answer 5

Sie können auch null in der Ausgabe mit COALESCE entfernen.

SELECT personid /*primary key, will never be null here*/ 
     , COALESCE(name, 'no name') as name 
     , COALESCE(birthdate,'no date') as birthdate 
FROM people 

Nicht alle Datenbanken unterstützen COALESCE, aber fast alle haben eine Ersatzoption namens
IFNULL(arg1, arg2) oder etwas simular, die die gleiche (aber nur für zwei Argumente) tun wird.

Answer 6

Ich empfehle Sie für Ihre Option 2. Ich bin ziemlich sicher, Chris Date würde auch, weil im Wesentlichen was Sie tun, ist normalisieren 6NF, die höchstmögliche Normalform, die Date was jointly responsible for introducing. Ich zweite Sekunde die empfohlene Darwen's paper auf die Behandlung fehlender Informationen.

Da OUTER JOIN wird nicht zugelassen werden (weil sie würde NULL einführen in die Ergebnismenge), alle notwendigen Daten könnten möglicherweise nicht mehr mit nur einer einzigen Abfrage wie zuvor abgeholt werden.

... dies ist nicht der Fall, aber ich stimme zu, dass das Problem der äußeren Verbindung nicht explizit in der Darwen-Papier erwähnt wird; Es war die eine Sache, die mich fehlte. Die ausdrückliche Antwort kann in einem anderen Buch des Datums gefunden werden ...

Beachten Sie zuerst, dass Datum und Darwens wirklich relationale Sprache Tutorial D nur einen Join-Typ hat, der die natürliche Verbindung ist. Die Begründung ist, dass nur ein Join-Typ tatsächlich benötigt wird.

Das Datum Buch, das ich erwähnt ist die ausgezeichnete SQL and Relational Theory: How to Write Accurate SQL Code:

4,6: Eine Bemerkung zu Outer Join: „Relational gesprochen, [Outer Join ist] eine Art Schrotflinte Ehe: Es zwingt Tabellen in ein Art der Union-ja, ich meine Union, nicht Join-auch wenn die fraglichen Tabellen entsprechen den üblichen Anforderungen für die Union ... Es tut dies, in Wirkung, durch Auffüllen einer oder beider Tabellen mit Nullen vor die Union tun, damit sie den üblichen Anforderungen schließlich entsprechen, aber es gibt n o Grund, warum die Polsterung nicht mit richtigen Werten erfolgen statt nulls

Arbeiten mit dem Beispiel und den Standardwert ‚1900-01-01‘ als ‚padding‘, die Alternative zu Outer-Joins könnte wie folgt aussehen Darwen Papier proses zwei explizite Tabellen, sagen BirthDate und BirthDateKnown, aber die SQL würde nicht viel anders wie sein

SELECT p.PersonID, p.Name, b.DateOfBirth 
    FROM Person AS p 
     INNER JOIN BirthDate AS b 
      ON p.PersonID = b.PersonID 
UNION 
SELECT p.PersonID, p.Name, '1900-01-01' AS DateOfBirth 
    FROM Person AS p 
WHERE NOT EXISTS (
        SELECT * 
        FROM BirthDate AS b 
        WHERE p.PersonID = b.PersonID 
       ); 

: eine Semi-Verbindung zu BirthDateKnown anstelle des Semi-Unterschieds zu BirthDate oben.

Beachten Sie die oben genannten Verwendungen JOIN und INNER JOIN nur, weil Standard-SQL-92 NATURAL JOIN und UNION CORRESPONDING sind im wirklichen Leben SQL Produkte nicht weitgehend umgesetzt (kann nicht ein Zitat finden, aber IIRC Darwen war weitgehend verantwortlich für die beiden letztgenannten es in der Herstellung Standard).

Weitere beachten Sie die oben genannte Syntax sieht nur langatmig, weil SQL im Allgemeinen langatmig ist. In der reinen relationalen Algebra ist es eher wie (Pseudocode):

Person JOIN BirthDate UNION Person NOT MATCHING BirthDate ADD '1900-01-01' AS DateOfBirth; 

Answer 7

Eine Möglichkeit ist ausdrücklich option types, analog zu Haskells Maybe Funktors zu verwenden.

Leider haben viele existierende SQL-Implementierungen schlechte Unterstützung für benutzerdefinierte algebraische Datentypen und noch schlechtere Unterstützung für benutzerdefinierte Typkonstruktoren, die Sie wirklich sauber ausführen müssen.

Dies stellt eine Art von "null" nur für die Attribute wieder her, für die Sie explizit danach fragen, aber ohne nulls dumme dreiwertige Logik. Nothing == Nothing ist True, nicht unknown oder null.

Unterstützung für benutzerdefinierte algebraische Typen hilft auch, wenn es ein paar Gründe für die fehlenden Informationen sind zum Beispiel eine Datenbank Äquivalent des folgenden Haskell Typ eine gute Lösung für die offensichtliche Anwendung wäre:

data EmploymentStatus = Employed EmployerID | Unemployed | Unknown 

(natürlich unterstützt eine Datenbank diese müssten auch die mehr kompliziert als üblich Fremdschlüssel zu unterstützen, die mit ihm kommt.)

Kurz dieser, ich mit APC ‚s und onedaywhen‘ s Antworten stimmen über 6NF.