Kapitel 12: Datenintegrität

Übersicht

Vielleicht zieht kein anderes Diskussionsthema in Kreisen der Datenbankentwicklung, -modellierung und -verwaltung mehr Aufmerksamkeit und oft hitzige Debatten auf sich als das der Datenintegrität. Es ist erstaunlich, dass trotz der Entfernung, die wir in Verständnis, Praxis und Technologie gekommen sind, so viele Datenbank-Gurus (Celko, Codd, Date, Riordan, et al.) unterscheiden sich so stark in ihren jeweiligen Philosophien. Infolgedessen handhaben Administratoren und Entwickler Integritätsmodellierung und damit Integritätsprogrammierung häufig aus der Hose. Sogar SQL Server Books Online definiert die Datenintegrität in seinem Glossar verwirrter als eine Fledermaus am helllichten Tag.

Dieses Buch ist sicherlich nicht das Forum für eine Diskussion über Datenintegrität, und dies ist ungefähr so weit, wie ich es wagen möchte, die relationale Datenbanktheorie zu diskutieren. Aber ohne einige Konzepte zu untersuchen und die einzig mögliche Definition der Datenintegrität zu akzeptieren, werden Sie nicht von allen Tools und neuen Features profitieren, die SQL Server 2005 in Bezug auf die Modellierung und Programmierung der Datenintegrität unterstützt.

Datenintegrität ist definitiv keine Praxis, keine Disziplin, die sicherstellt, dass in einer Datenbank gespeicherte Daten korrekt sind, nur dass sie glaubwürdig oder plausibel sind. Es gibt keine Möglichkeit zwischen diesem Leben und dem Jenseits, dass SQL Server 2005 oder ein anderes RDBMS garantieren kann, dass Daten in einer Datenbank korrekt sind. Holen Sie sich jetzt richtig aus Ihrem Vokabular. SQL Server 2005 hat keine Möglichkeit zu wissen und somit sicherzustellen, dass meine Vorwahl nicht 209, sondern 299 ist oder dass mein Nachname Shapiro und nicht Schapiro ist. Ich habe sogar von einem Mädchen namens Jeffrey gehört. Sie müssen SQL Server in Bezug auf Datenplausibilität denken, modellieren und programmieren, nicht in Bezug auf Daten, die richtig oder falsch sind.

Nur wenn Sie diese Definition akzeptieren, können Sie die von SQL Server 2005 unterstützten Tools und Techniken verwenden, um die Integrität Ihrer Daten und damit deren Wert als Vermögenswert für Ihr Unternehmen sicherzustellen. Und nachdem Sie sich auf Integrität in skalaren Begriffen und nicht auf absolute Korrektheit konzentriert haben, werden Sie viel mehr Vertrauen in die Daten in Ihrer Datenbank haben, und Sie werden sich das Vertrauen und den Respekt leisten können, den sie verdienen. Schließlich sind Daten, die nicht plausibel oder glaubwürdig sind, eine Haftung

Wie ich in Kapitel 1 besprochen habe, verursachte menschliches Versagen meiner Frau extremen Kummer, als ihr nach dem Wechsel der Krankenkassen für einige Zeit die Deckung verweigert wurde, weil der Nachname ihres Arztes anstelle von Shapiro in das Nachnamenfeld des Ehepartners für meine Frau eingegeben wurde. Für die Krankenkasse explodierte das Problem fast zu einem Haftungsproblem.

Was würde oder könnte dazu führen, dass ein Nachname oder Nachname falsch ist?

1. Die Frau trägt ihren Mädchennamen.

2. Ein Ehepartner gibt fälschlicherweise ein Pseudonym an.

3. Das Paar wurde gerade geschieden, stimmte aber zu, die Berichterstattung aufrechtzuerhalten.

4. Ein Kind wird von einem Stiefvater gedeckt, trägt aber immer noch den Nachnamen seines leiblichen Vaters.

5. Der Vorname wird in das Feld Nachname eingegeben.

6. Der Nachname wird falsch eingegeben (Shapiro wird mit nur wenigen Fingerbewegungen zu Ahaoeuei).

7. Die Handschrift auf dem Antragsformular ist schlecht, oder der Nachname wird weggelassen und die Dateneingabe Person macht eine falsche Annahme.

Diese Liste könnte weiter und weiter gehen. Und ich bin mir sicher, dass Sie Dutzende von Szenarien entwickeln könnten, die auch fragwürdige Daten erzeugen würden, nicht nur in Nachnamenwerten, sondern auch an vielen anderen Stellen. Zahlen zum Beispiel bieten unglaubliche Möglichkeiten, problematische Daten in eine Datenbank einzugeben.

Aber ist das eine Frage der Integrität? Wenn wir akzeptieren, dass wir das DBMS so programmieren, dass die Daten so glaubwürdig wie möglich sind, dann ist es das. Wenn wir versuchen sicherzustellen, dass die Daten korrekt sind, ist dies nicht der Fall. Jeder Wert kann tatsächlich korrekt sein, wenn angenommen wird, dass er falsch ist, und er kann tatsächlich falsch sein, wenn angenommen wird, dass er korrekt ist. Das einzige, was Sie tun können, um sicherzustellen, dass Daten glaubwürdig sind, ist sicherzustellen, dass sie glaubwürdig waren, als sie in die Datenbank eingegeben wurden.

Das Beste, was ich mir auf der Datenebene vorstellen kann, um sicherzustellen, dass ein Wert wie der Nachname des Ehepartners glaubwürdig ist, besteht darin, den Kunden zu zwingen, die Daten zurückzugehen und zu überprüfen, bevor sie eingegeben werden können, oder die Daten mit bekannten Werten zu vergleichen. Es ist sogar möglich, den Datensatz an den Client zurückzuverweisen und die Eingabe durch einen anderen Benutzer anzufordern, möglicherweise einen Supervisor, der die Faktenprüfung auf die nächste Stufe hebt. Es ist eine gute Idee, Websurfer zu bitten, Antragsformulare über das Internet auszufüllen, da dadurch die mittlere Dateneingabeperson, die Papierspur und die Verzögerung entfallen Und der Kunde die Plausibilität der Daten sicherstellen muss, Wer ist wahrscheinlicher, um sicherzustellen, dass sich seine Informationen verlassen können.

Ich habe kürzlich auf CNN eine schreckliche Geschichte über einen amerikanischen Apotheker gesehen, der einem Kind eine tödliche Überdosis eines Medikaments gab, das dem entsprach, was der Kinderarzt korrekt verschrieben hatte. Die Entschuldigung war menschliches Versagen, Versagen des Vorgesetzten, die Rezepte zu überprüfen, Täglich Hunderte von Rezepten ausfüllen Warum, im Namen des Himmels, In der heutigen Zeit, Verwenden Apotheker immer noch Schreibmaschinen und Textverarbeitungsprogramme, um Anweisungen zur Dosierung und Verabreichung gefährlicher Drogen zu geben? Eine Datenbank hätte verwendet werden sollen, um zu überprüfen, ob die Dosierung die für das verschriebene Medikament festgelegten Werte nicht überschritten hat. Kein Computerprogramm überprüfte die Dosierung, und so schickte eine Mutter ihr Kind ins Bett und er wachte nie auf. Wann immer wir Medikamente kaufen, überprüfen wir das Etikett und fragen uns: „Können wir diesen Daten unser Leben anvertrauen?“

Offensichtlich geht das Thema menschliches Versagen über den Rahmen dieses Buches hinaus, außer zu diskutieren, welche möglichen Mittel wir haben könnten, um Menschen daran zu hindern, fragwürdige Daten in eine Datenbank einzugeben. Joe Celko berührte das Thema in seinem wunderbaren Buch Joe Celkos Data & Databases: Concepts in Practice (New York: Morgan Kaufmann, 1999). In einem Abschnitt mit dem Titel „Modelle versus Realität“ spricht er über Fehler in Modellen und beschreibt die Fehlerstufen Typ I und Typ II. Ein Fehler vom Typ I akzeptiert etwas, das wahr ist, als falsch, und ein Fehler vom Typ II akzeptiert etwas, das falsch ist, als wahr.

Ich stimme ohne Zweideutigkeit zu, dass das Thema Fehler in Modellen für Datenbankleute sehr wichtig ist, um es zu verstehen. Generationen von Menschen wurden wegen dieses Problems ausgelöscht. Afrika südlich der Sahara, wo ich meine Kindheit verbracht habe, wird wegen AIDS ausgelöscht werden. Dies hätte verhindert werden können, aber die Bevölkerung dort glaubt immer noch im Großen und Ganzen, dass AIDS nicht sexuell übertragen wird und dass die Werbung nur „westliche Propaganda“ ist.“ Der Betrug ist in der Tat selbsterhaltend oder selbsterfüllend, weil Millionen von Afrikanern immer noch ungeschützten Sex haben.

Ja, wir können ausgefallene Programmiertricks und Systemfunktionen wie Trigger und gespeicherte Prozeduren verwenden, um die Wahrscheinlichkeit unplausibler Daten zu verringern. Wie können wir Probleme wie das gerade beschriebene vermeiden und trotzdem SQL Server 2005 so klug wie möglich programmieren? Um zu einer möglichen Lösung zu gelangen, lassen Sie uns zunächst die Integritätssicherungsfeatures und -funktionen von SQL Server 2005 untersuchen. Nach dieser Diskussion können wir das Problem der Integrität des Nachnamens beheben und meiner Krankenkasse einige Ideen anbieten, bevor sie verklagt wird.