Kapitel 12: dataintegritet

oversigt

måske trækker intet andet diskussionsemne i databaseudvikling, modellering og styringskredse mere opmærksomhed og ofte opvarmet debat end dataintegritet. Det er forbløffende, at, på trods af den afstand, vi er kommet i forståelse, praksis, og teknologi, så mange database guruer (Celko, Codd, Dato, Riordan, et al.) varierer så vidt i deres respektive filosofier. Som et resultat håndterer administratorer og udviklere ofte integritetsmodellering og dermed integritetsprogrammering ved sædet på deres bukser. Online definerer dataintegritet i sin ordliste på en måde mere forvirret end en flagermus i bred dagslys.

denne bog er bestemt ikke forum for en diskussion af dataintegritet, og det handler om, så vidt jeg vil vove mig med at diskutere relationsdatabaseteori. Men uden at udforske nogle koncepter og acceptere den eneste mulige definition af dataintegritet, vil du ikke drage fordel af alle de værktøjer og nye funktioner, som Microsoft Server 2005 understøtter med hensyn til dataintegritetsmodellering og programmering.

dataintegritet er bestemt ikke en praksis, en disciplin, der sikrer, at data, der er gemt i en database, er korrekte, kun det er troværdigt eller plausibelt. Der er ingen måde mellem dette liv og det efterfølgende, at eller andre RDBM ‘ er kan garantere, at data i en database er korrekte. Få korrekt ud af dit ordforråd nu. Server 2005 har ingen måde at vide og dermed sikre, at mit områdenummer ikke er 209, men snarere 299, eller at mit efternavn er Shapiro og ikke Schapiro. Jeg har endda hørt om en pige ved navn Jeffrey. Du er nødt til at begynde at tænke, modellere og programmere din server med hensyn til data plausibilitet, ikke med hensyn til data, der er rigtige eller forkerte.

kun hvis du accepterer denne definition, vil du være i stand til at bruge de værktøjer og teknikker, der understøttes af Server 2005 for at sikre integriteten af dine data og dermed dens værdi som et aktiv for din virksomhed. Og når du begynder at fokusere på integritet i skalære termer og ikke korrekthed i absolutte termer, vil du have meget mere tro på dataene i din database, og du vil have råd til den tillid og respekt, den fortjener. Når alt kommer til alt er data, der ikke er plausible eller troværdige, et ansvar

som jeg diskuterede i kapitel 1, forårsagede menneskelig fejl min kone ekstrem sorg, da hun efter at have skiftet medicinske forsikringsselskaber blev nægtet dækning i nogen tid, fordi efternavnet på hendes læge i stedet for Shapiro blev indtastet i ægtefællens efternavnefelt, til min kone blev dataintegritetsproblemet således livstruende. For det medicinske forsikringsselskab eksploderede problemet næsten til et ansvarsproblem.

hvad ville eller kunne få et efternavn eller efternavn til at være forkert?

1. hustruen går under hendes pigenavn.

2. en ægtefælle giver fejlagtigt et pseudonym.

3. parret blev lige skilt, men blev enige om at opretholde dækningen.

4. et barn er dækket af en stedfar, men går stadig under efternavnet på hans eller hendes biologiske far.

5. fornavnet indtastes i feltet Efternavn.

6. efternavnet er skrevet forkert (Shapiro bliver Ahaoeuei med blot et par glider af fingeren).

7. håndskriften på ansøgningsskemaet er dårlig, eller efternavnet udelades, og dataindtastningspersonen antager en forkert antagelse.

denne liste kan blive ved og ved. Og jeg er sikker på, at du kunne komme med snesevis af scenarier, der også ville skabe tvivlsomme data, ikke kun i efternavnsværdier, men også mange andre steder. Tal giver for eksempel utrolige muligheder for at indtaste problematiske data i en database.

men er dette et spørgsmål om integritet? Hvis vi accepterer, at vi programmerer DBMS for at sikre, at dataene er så troværdige som muligt, så er det. Hvis vi forsøger at sikre, at dataene er korrekte, så er det ikke. Enhver værdi kan faktisk være korrekt, når det antages at være forkert, og det kan faktisk være forkert, når det antages at være korrekt. Det eneste, du kan gøre for at sikre, at data er troværdige, er at hjælpe med at sikre, at de var troværdige, da de blev indtastet i databasen.

det bedste, jeg kan tænke på at gøre på dataniveauet for at sikre, at en værdi, såsom ægtefællens efternavn, er troværdig, er at tvinge klienten til at gå tilbage og kontrollere dataene, før de kan indtastes, eller at sammenligne dataene med kendte værdier. Det er muligt endda at henvise posten tilbage til klienten og anmode om, at den indtastes af en anden bruger, muligvis en vejleder, der tager faktakontrollen til det næste niveau. Det er en god ide at bede internetsurfere om at udfylde ansøgningsskemaer over internettet, fordi det skærer den midterste dataindtastningsperson ud, papirsporet og forsinkelsen, og det lægger ansvaret for at sikre data plausibiliteten på klienten, der er mere tilbøjelige til at sikre, at hans eller hendes oplysninger kan påberåbes.

jeg så for nylig en forfærdelig historie på CNN om en amerikansk farmaceut, der gav et barn en dødelig overdosis af et lægemiddel i modsætning til det, der var korrekt ordineret af børnelægen. Undskyldningen var menneskelig fejl, svigt af vejlederen til at dobbelttjekke recepter, udfylde hundredvis af recepter om dagen hvorfor, i himlens navn, i denne dag og alder, apotekere stadig bruger skrivemaskiner og tekstbehandlere til at give instruktioner om dosering og administration af farlige stoffer? En database skulle have været brugt til at kontrollere, at doseringen ikke oversteg sikkert niveauer for det ordinerede lægemiddel. Intet computerprogram kontrollerede doseringen, og så sendte en mor sit barn i seng, og han vågnede aldrig. Nu, når vi køber stoffer, kontrollerer vi etiketten og spekulerer på “kan vi stole på vores liv til disse data?”

naturligvis er emnet for menneskelig fejl uden for denne Bogs anvendelsesområde, bortset fra at diskutere, hvilke mulige midler vi måtte have til at forhindre mennesker i at indtaste tvivlsomme data i en database. Joe Celko berørte emnet i sin fantastiske bog, Joe Celkos Data & databaser: koncepter i praksis (Morgan Kaufmann, 1999). I et afsnit med titlen” modeller Versus virkelighed ” taler han om fejl i modeller, der beskriver type I og type II fejlniveauer. En type i-fejl accepterer som falsk noget, der er sandt, og en type II-fejl accepterer som sandt noget, som det er falsk.

jeg er enig uden tvivl om, at emnet for fejl i modeller er meget vigtigt for databasefolk at forstå. Generationer af mennesker er blevet udslettet på grund af dette problem. Afrika syd for Sahara, hvor jeg tilbragte min barndom, vil blive udslettet på grund af AIDS. Dette kunne have været forhindret, men befolkningen der mener stadig, i det store og hele, at AIDS ikke overføres seksuelt, og at reklamen kun er “vestlig propaganda.”Bedrageriet er faktisk selvforsynende eller selvopfyldende, fordi millioner af afrikanere stadig har ubeskyttet køn.

Ja, Vi kan bruge smarte programmeringstricks og systemfunktioner såsom udløsere og lagrede procedurer for at mindske sandsynligheden for usandsynlige data; vi kan endda opbygge mere avanceret menneskelig integritet, der kontrollerer klientapplikationerne. Hvordan kan vi undgå problemer som den netop beskrevne og stadig programmere Server 2005 så klogt som muligt? For at nå frem til en mulig løsning, lad os først undersøge integritetssikringsfunktionerne og funktionerne i Server 2005. Efter denne diskussion, vi kan rette op på efternavnet integritetsproblem og tilbyde mit medicinske forsikringsselskab nogle ideer, før de bliver sagsøgt.