översikt
kanske inget annat diskussionsämne i databasutveckling, modellering och hanteringskretsar väcker mer uppmärksamhet och ofta het debatt än dataintegritet. Det är förvånande att trots det avstånd Vi har kommit i förståelse, övning och teknik, så många databasguruer (Celko, Codd, Date, Riordan, et al.) varierar så mycket i sina respektive filosofier. Som ett resultat hanterar administratörer och utvecklare ofta integritetsmodellering och därmed integritetsprogrammering av byxans säte. Även SQL Server Books Online definierar dataintegritet i sin ordlista på ett sätt mer förvirrad än en fladdermus i fullt dagsljus.
den här boken är verkligen inte forumet för en diskussion om dataintegritet, och det handlar om så långt jag vill våga diskutera relationsdatabasteori. Men utan att utforska några begrepp och acceptera den enda möjliga definitionen av dataintegritet, kommer du inte att dra nytta av alla verktyg och nya funktioner som SQL Server 2005 stöder med avseende på dataintegritetsmodellering och programmering.
dataintegritet är definitivt inte en praxis, en disciplin, som säkerställer att data som lagras i en databas är korrekt, bara det är det trovärdigt eller troligt. Det finns inget sätt mellan detta liv och hädanefter att SQL Server 2005, eller någon annan RDBMS, kan garantera att data i en databas är korrekt. Få rätt ur din vocab nu. SQL Server 2005 har inget sätt att veta och därmed säkerställa att mitt Riktnummer inte är 209 utan snarare 299, eller att mitt efternamn är Shapiro och inte Schapiro. Jag har till och med hört talas om en tjej som heter Jeffrey. Du måste börja tänka, modellering, och programmering SQL Server i termer av data rimlighet, inte i termer av data är rätt eller fel.
endast om du accepterar denna definition kommer du att kunna använda de verktyg och tekniker som stöds av SQL Server 2005 för att säkerställa integriteten för dina data, och därmed dess värde som en tillgång för ditt företag. Och när du börjar fokusera på integritet i skalära termer och inte korrekthet i absoluta termer, kommer du att ha mycket mer tro på data i din databas, och du kommer att ha råd med det förtroende och respekt det förtjänar. När allt kommer omkring är data som inte är trovärdiga eller trovärdiga en skuld
som jag diskuterade i kapitel 1 orsakade det mänskliga felet min fru extrem sorg när hon, efter att ha bytt sjukförsäkringsbolag, nekades täckning under en tid eftersom efternamnet på hennes läkare, istället för Shapiro, angavs i makens efternamn, till min fru blev dataintegritetsproblemet därmed livshotande. Till sjukförsäkringsbolaget exploderade frågan nästan till ett ansvarsproblem.
vad skulle eller kan orsaka att ett efternamn eller efternamn är felaktigt?
-
hustrun går under hennes flicknamn.
-
en make ger felaktigt en pseudonym.
-
paret skilde sig precis men gick med på att behålla täckningen.
-
ett barn täcks av en styvfar men går fortfarande under efternamnet på sin biologiska far.
-
förnamnet anges i fältet Efternamn.
-
efternamnet skrivs felaktigt (Shapiro blir Ahaoeuei med bara några fingrar).
-
handstilen på ansökningsformuläret är dålig, eller efternamnet utelämnas och datainmataren gör ett felaktigt antagande.
denna lista kan fortsätta och fortsätta. Och jag är säker på att du kan komma med dussintals scenarier som också skulle skapa tvivelaktiga data, inte bara i efternamnsvärden utan också på många andra ställen. Siffror ger till exempel otroliga möjligheter att ange problematiska data i en databas.
men är detta en fråga om integritet? Om vi accepterar att vi programmerar DBMS för att säkerställa att uppgifterna är så trovärdiga som möjligt, så är det. Om vi försöker se till att uppgifterna är korrekta, så är det inte. Varje värde kan i själva verket vara korrekt när det antas vara fel, och det kan i själva verket vara fel när det antas vara korrekt. Det enda du kan göra för att säkerställa att data är trovärdiga är att hjälpa till att säkerställa att det var trovärdigt när det infördes i databasen.
det bästa jag kan tänka mig att göra på datanivån för att säkerställa att ett värde, till exempel makens efternamn, är trovärdigt är att tvinga klienten att gå tillbaka och kontrollera data innan den kan matas in, eller att jämföra data mot kända värden. Det är möjligt att till och med hänvisa posten tillbaka till klienten och begära att den skrivs in av en annan användare, eventuellt en handledare som skulle ta faktokontrollen till nästa nivå. Att be webbsurfare att fylla i ansökningsblanketter via Internet är en bra ide eftersom det skär ut den mellersta datainmatningspersonen, pappersspåret och förseningen och det lägger ansvaret för att säkerställa dataens trovärdighet på klienten, som är mer benägna att se till att hans eller hennes information kan åberopas.
jag tittade nyligen på en skrämmande historia på CNN om en amerikansk apotekare som gav ett barn en dödlig överdos av ett läkemedel som strider mot vad som hade ordinerats korrekt av barnläkaren. Ursäkten var mänskliga misstag, underlåtenhet av handledaren att dubbelkolla recept, fylla hundratals recept om dagen varför, i himlens namn, i denna dag och ålder, är apotekare fortfarande använder skrivmaskiner och ordbehandlare för att ge instruktioner om dosering och administrering av farliga droger? En databas borde ha använts för att kontrollera att dosen inte överskred säkert nivåer för det föreskrivna läkemedlet. Inget datorprogram kontrollerade dosen, och så skickade en mamma sitt barn till sängs och han vaknade aldrig. Nu, när vi köper droger, kontrollerar vi etiketten och undrar ”kan vi lita på våra liv till dessa uppgifter?”
självklart är ämnet för mänskliga fel utanför ramen för denna bok, annat än att diskutera vilka möjliga medel vi kan ha för att förhindra att människor kommer in i tvivelaktiga data i en databas. Joe Celko berörde ämnet i sin underbara bok, Joe Celkos Data & databaser: begrepp i praktiken (New York: Morgan Kaufmann, 1999). I ett avsnitt med titeln” modeller kontra verklighet, ” han talar om fel i modeller, beskriver typ i och typ II felnivåer. Ett typ i-fel accepterar som falskt något som är sant, och ett typ II-fel accepterar som sant något som det är falskt.
jag håller med utan tvekan om att ämnet för fel i modeller är mycket viktigt för databasfolk att förstå. Generationer av människor har utplånats på grund av detta problem. Afrika söder om Sahara, där jag tillbringade min barndom, kommer att utplånas på grund av AIDS. Detta kunde ha förhindrats, men befolkningen där tror fortfarande i stort sett att AIDS inte överförs sexuellt och att publiciteten bara är ”västerländsk propaganda.”Bedrägeriet är faktiskt självförstärkande eller självuppfyllande, eftersom miljontals afrikaner fortfarande har oskyddat sex.
Ja, Vi kan använda snygga programmeringstrick och systemfunktioner som triggers och lagrade procedurer för att minska sannolikheten för osannolika data; vi kan till och med bygga mer avancerad mänsklig integritetskontroll i klientapplikationerna. Hur kan vi undvika problem som den som just beskrivits och fortfarande programmera SQL Server 2005 så klokt som möjligt? För att komma fram till en möjlig lösning, Låt oss först utforska integrity assurance-funktionerna och funktionerna i SQL Server 2005. Efter denna diskussion kan vi åtgärda efternamnets integritetsfråga och erbjuda mitt sjukförsäkringsbolag några förslag innan de blir stämda.