Capitolul 12: integritatea datelor

Prezentare generală

poate că niciun alt subiect de discuție în cercurile de dezvoltare, modelare și gestionare a bazelor de date nu atrage mai multă atenție și adesea dezbateri aprinse decât cea a integrității datelor. Este uimitor faptul că, în ciuda distanței pe care am ajuns-o în înțelegere, practică și tehnologie, atât de mulți guru ai bazelor de date (Celko, Codd, Date, Riordan și colab.) variază atât de mult în filozofiile lor respective. Drept urmare, administratorii și dezvoltatorii se ocupă adesea de modelarea integrității și, prin urmare, de programarea integrității de către scaunul pantalonilor lor. Chiar și SQL Server Books Online definește integritatea datelor în glosarul său într-un mod mai confuz decât un liliac în plină zi.

această carte nu este cu siguranță forumul pentru o discuție despre integritatea datelor, iar acest lucru este în măsura în care vreau să mă aventurez în discutarea teoriei bazelor de date relaționale. Dar fără a explora unele concepte și a accepta singura definiție fezabilă a integrității datelor, nu veți beneficia de toate instrumentele și noile caracteristici pe care SQL Server 2005 le acceptă în ceea ce privește modelarea și programarea integrității datelor.

integritatea datelor cu siguranță nu este o practică, o disciplină, care asigură că datele stocate într-o bază de date sunt corecte, doar că este credibil sau plauzibil. Nu există nici o cale între această viață și în continuare că SQL Server 2005, sau orice alt RDBMS, poate garanta că datele într-o bază de date este corectă. Ia corectă din vocabularul acum. SQL Server 2005 nu are nici o modalitate de a ști și de a se asigura că codul meu de zonă nu este 209, ci mai degrabă 299, sau că numele meu de familie este Shapiro și nu Schapiro. Am auzit chiar de o fată pe nume Jeffrey. Trebuie să începeți să gândiți, să modelați și să programați SQL Server în termeni de plauzibilitate a datelor, nu în termeni de date corecte sau greșite.

numai dacă acceptați această definiție, veți putea utiliza instrumentele și tehnicile acceptate de SQL Server 2005 pentru a asigura integritatea datelor dvs. și, prin urmare, valoarea lor ca activ pentru întreprinderea dvs. Și după ce începeți să vă concentrați pe integritate în termeni scalari și nu pe corectitudine în termeni absoluți, veți avea mult mai multă încredere în datele din baza dvs. de date și veți putea să-i acordați încrederea și respectul pe care îl merită. La urma urmei, datele care nu sunt plauzibile sau credibile reprezintă o răspundere

după cum am discutat în Capitolul 1, eroarea umană i-a provocat soției mele o durere extremă atunci când, după schimbarea companiilor de asigurări medicale, i s-a refuzat acoperirea de ceva timp, deoarece numele de familie al medicului ei, în loc de Shapiro, a fost introdus în câmpul de nume al soțului, soției mele, problema integrității datelor a devenit astfel una care pune viața în pericol. Pentru compania de asigurări medicale, problema aproape a explodat într-o problemă de răspundere.

ce ar putea sau ar putea face ca un nume de familie sau un nume de familie să fie incorect?

1. soția are numele ei de fată.

2. un soț oferă în mod eronat un pseudonim.

3. cuplul tocmai a divorțat, dar a fost de acord să mențină acoperirea.

4. un copil este acoperit de un tată vitreg, dar încă merge de numele de familie al tatălui său biologic.

5. prenumele este introdus în câmpul Nume de familie.

6. numele de familie este tastat incorect (Shapiro devine Ahaoeei cu doar câteva alunecări ale degetului).

7. scrisul de mână de pe formularul de cerere este slab sau numele de familie este omis și persoana de introducere a datelor face o presupunere greșită.

această listă ar putea continua. Și sunt sigur că ați putea veni cu zeci de scenarii care ar crea, de asemenea, date discutabile, nu numai în valorile de nume, ci și în multe alte locuri. Numerele, de exemplu, prezintă oportunități incredibile de a introduce date problematice într-o bază de date.

dar este aceasta o chestiune de integritate? Dacă acceptăm că programăm SGBD-ul pentru a ne asigura că datele sunt cât se poate de credibile, atunci este. Dacă încercăm să ne asigurăm că datele sunt corecte, atunci nu este. Orice valoare poate fi de fapt corectă atunci când se presupune că este greșită și poate fi de fapt greșită atunci când se presupune că este corectă. Singurul lucru pe care îl puteți face pentru a vă asigura că datele sunt credibile este să vă asigurați că au fost credibile atunci când au fost introduse în baza de date.

cel mai bun lucru pe care mă pot gândi să-l fac la nivelul de date pentru a mă asigura că o valoare, cum ar fi numele de familie al soțului, este credibilă este să forțez clientul să se întoarcă și să verifice datele înainte de a putea fi introduse sau să compare datele cu valori cunoscute. Este posibil să se refere chiar înregistrarea înapoi la client și să solicite să fie introduse de către un alt utilizator, eventual, un supraveghetor care ar lua verificarea fapt la nivelul următor. Solicitarea surferilor Web de a completa formularele de cerere pe Internet este o idee bună, deoarece elimină persoana de introducere a datelor din mijloc, traseul de hârtie și întârzierea și pune sarcina de a asigura plauzibilitatea datelor asupra clientului, care este mai probabil să se asigure că informațiile sale pot fi invocate.

am urmărit recent o poveste îngrozitoare pe CNN despre un farmacist American care i-a dat unui copil o supradoză fatală a unui medicament contrar a ceea ce fusese prescris corect de medicul pediatru. Scuza a fost eroarea umană, eșecul supraveghetorului de a verifica rețetele, de a umple sute de rețete pe zi de ce, în numele cerului, în această zi și vârstă, farmaciștii folosesc încă mașini de scris și procesoare de text pentru a oferi instrucțiuni despre dozarea și administrarea medicamentelor periculoase? Ar fi trebuit utilizată o bază de date pentru a verifica dacă doza nu a depășit nivelurile sigure pentru medicamentul prescris. Niciun program de calculator nu a verificat doza, așa că o mamă și-a trimis copilul la culcare și nu s-a trezit niciodată. Acum, ori de câte ori cumpărăm medicamente, verificăm eticheta și ne întrebăm „putem avea încredere în viața noastră în aceste date?”

evident, subiectul erorii umane este dincolo de scopul acestei cărți, în afară de a discuta ce mijloace posibile am putea avea de a împiedica oamenii să introducă date discutabile într-o bază de date. Joe Celko a atins subiectul în cartea sa minunată, datele lui Joe Celko & baze de date: concepte în practică (New York: Morgan Kaufmann, 1999). Într-o secțiune intitulată „modele Versus realitate”, el vorbește despre erori în modele, descriind nivelurile de eroare de tip I și de tip II. O eroare de tip I acceptă ca fals ceva ce este adevărat, iar o eroare de tip II acceptă ca adevărat ceva ce este fals.

sunt de acord fără echivoc că subiectul erorilor în modele este foarte important pentru ca oamenii din Baza de date să înțeleagă. Generații de oameni au fost distruse din cauza acestei probleme. Africa Subsahariană, unde mi-am petrecut copilăria, va fi distrusă din cauza SIDA. Acest lucru ar fi putut fi prevenit, dar populația de acolo încă mai crede, în general, că SIDA nu este transmisă sexual și că publicitatea este doar „propagandă Occidentală.”Frauda este, de fapt, auto-perpetuantă sau auto-împlinită, deoarece milioane de africani au încă relații sexuale neprotejate.

Da, putem folosi trucuri de programare fanteziste și caracteristici de sistem, cum ar fi declanșatoare și proceduri stocate pentru a diminua probabilitatea unor date neplauzibile; putem chiar să construim o verificare mai avansată a integrității umane în aplicațiile client. Cum putem evita probleme precum cea descrisă și încă programăm SQL Server 2005 cât mai înțelept posibil? Pentru a ajunge la o posibilă Soluție, să explorăm mai întâi caracteristicile și funcțiile de asigurare a integrității SQL Server 2005. După această discuție, putem remedia problema integrității numelui de familie și putem oferi companiei mele de asigurări medicale câteva idei înainte de a fi dați în judecată.