Oversikt
kanskje ingen andre tema for diskusjon i database utvikling, modellering og ledelse sirkler trekker mer oppmerksomhet, og ofte opphetet debatt, enn dataintegritet. Det er forbløffende at, til tross for avstanden vi har kommet i forståelse, praksis og teknologi, så mange databaseguruer (Celko, Codd, Date, Riordan, et al.) varierer så mye i sine respektive filosofier. Som et resultat håndterer administratorer og utviklere ofte integritetsmodellering og dermed integritetsprogrammering ved setet på buksene sine. SELV SQL Server Books online definerer dataintegritet i sin ordliste på en måte mer forvirret enn en flaggermus i bred dagslys.
denne boken er absolutt ikke forumet for en diskusjon om dataintegritet, og dette handler om så langt jeg vil våge å diskutere relasjonsdatabaseteori. Men uten å utforske noen konsepter og akseptere den eneste mulige definisjonen av dataintegritet, vil DU ikke dra nytte av alle verktøyene og de nye funksjonene SOM SQL Server 2005 støtter med hensyn til dataintegritetsmodellering og programmering.
dataintegritet er definitivt ikke en praksis, en disiplin, som sikrer at data lagret i en database er riktig, bare det er troverdig eller plausibel. DET er ingen vei mellom dette livet og det etterfølgende SOM SQL Server 2005, ELLER andre RDBMS, kan garantere at data i en database er riktig. Få riktig ut av vocab nå. SQL Server 2005 har ingen måte å vite og dermed sikre at retningsnummeret mitt ikke er 209, men heller 299, eller at etternavnet Mitt Er Shapiro og Ikke Schapiro. Jeg har selv hørt om en jente som heter Jeffrey. DU må begynne å tenke, modellere OG programmere SQL Server når det gjelder data plausibilitet, ikke når det gjelder data som er rett eller galt.
bare hvis du godtar denne definisjonen, kan du bruke verktøyene og teknikkene som STØTTES AV SQL Server 2005 for å sikre integriteten til dataene, og dermed verdien som en ressurs for bedriften. Og etter at du begynner å fokusere på integritet i skalære termer og ikke korrekthet i absolutte termer, vil du ha mye mer tro på dataene i databasen din, og du vil ha råd til den tilliten og respekten den fortjener. Tross alt, data som ikke er plausible eller troverdige er et ansvar
som jeg diskuterte i Kapittel 1, forårsaket menneskelig feil min kone ekstrem sorg da hun, etter å ha endret sykeforsikringsselskaper, ble nektet dekning for en stund fordi etternavnet til legen hennes, i stedet For Shapiro, ble oppgitt i ektefellens etternavn, til min kone, ble dataintegritetsproblemet dermed en livstruende. Til medisinsk forsikringsselskap eksploderte problemet nesten til et ansvarsproblem.
hva ville eller kunne føre til at et etternavn eller etternavn var feil?
-
kona går under hennes pikenavn.
-
en ektefelle gir feilaktig et pseudonym.
-
paret bare fikk skilt, men ble enige om å opprettholde dekningen.
-
Et barn er dekket av en stefar, men fortsatt går etter etternavnet til hans eller hennes biologiske far.
-
fornavnet legges inn i etternavn-feltet.
-
etternavnet er skrevet feil (Shapiro blir Ahaoeuei med bare noen få slips på fingeren).
-
håndskriften på søknadsskjemaet er dårlig, eller etternavnet utelates og dataregistreringspersonen gjør en feil antagelse.
denne listen kan gå av og på. Og jeg er sikker på at du kan komme opp med dusinvis av scenarier som også vil skape tvilsomme data, ikke bare i etternavn, men også på mange andre steder. Tall, for eksempel, presenterer utrolige muligheter til å legge inn problematiske data i en database.
men er dette et spørsmål om integritet? Hvis vi aksepterer at vi programmerer DBMS for å sikre at dataene er så troverdige som mulig, så er det. Hvis vi prøver å sikre at dataene er riktige, så er det ikke. Enhver verdi kan faktisk være riktig når den antas å være feil, og det kan faktisk være feil når den antas å være riktig. Det eneste du kan gjøre for å sikre at data er troverdig er å bidra til å sikre at det var troverdig når det ble lagt inn i databasen.
det beste jeg kan tenke på å gjøre på datanivået for å sikre at en verdi, for eksempel ektefellens etternavn, er troverdig, er å tvinge klienten til å gå tilbake og sjekke dataene før de kan legges inn, eller å sammenligne dataene mot kjente verdier. Det er mulig å til og med henvise posten tilbake til klienten og be om at den skal legges inn av en annen bruker, muligens en veileder som vil ta faktakontrollen til neste nivå. Spør web surfere å fylle ut søknadsskjemaer over Internett er en god ide fordi det kutter ut midten dataregistrering person, papir spor, og forsinkelse, og det setter tyngende å sikre data plausibilitet på klienten, som er mer sannsynlig å sikre at hans eller hennes informasjon kan stoles på.
jeg så nylig en forferdelig historie PÅ CNN om En Amerikansk apotek som ga et barn en dødelig overdose av et stoff i strid med det som hadde blitt riktig foreskrevet av barnelege. Unnskyldningen var menneskelig feil, supervisorens manglende evne til å dobbeltsjekke resepter, fylle hundrevis av resepter om dagen Hvorfor, i himmelens navn, i dag og alder, bruker farmasøyter fortsatt skrivemaskiner og tekstbehandlere for å gi instruksjoner om dosering og administrasjon av farlige stoffer? En database skal ha blitt brukt til å kontrollere at dosen ikke overstige trygt nivåer for stoffet foreskrevet. Ingen dataprogram sjekket doseringen, så en mor sendte barnet sitt til sengs, og han våknet aldri. Nå, når vi kjøper narkotika, sjekker vi etiketten og lurer på «kan vi stole på våre liv til disse dataene?»
åpenbart er emnet for menneskelig feil utenfor omfanget av denne boken, annet enn å diskutere hvilke mulige midler vi kan ha for å hindre mennesker i å legge inn tvilsomme data i en database. Joe Celko berørte emnet I Sin fantastiske bok, Joe Celko ‘ S Data & Databaser: Konsepter I Praksis (New York: Morgan Kaufmann, 1999). I en seksjon med tittelen «Modeller Versus Virkelighet» snakker han om feil i modeller, som beskriver type I og TYPE II feilnivåer. En type i-feil er å akseptere som falsk noe som er sant, OG En TYPE II-feil er å akseptere som sant noe som det er falskt.
jeg er enig uten tvetydighet at emnet for feil i modeller er svært viktig for databasefolk å forstå. Generasjoner av mennesker har blitt utryddet på grunn av dette problemet. Afrika Sør For Sahara, hvor jeg tilbrakte barndommen min, kommer til å bli utryddet på GRUNN AV AIDS. Dette kunne vært forhindret, men befolkningen der fortsatt mener, av og store, AT AIDS ikke er seksuelt overført, og at publisitet er bare » Vestlig propaganda.»Svindelen er faktisk selvoppfyllende eller selvoppfyllende, fordi millioner Av Afrikanere fortsatt har ubeskyttet sex.
ja, vi kan bruke fancy programmeringstriks og systemfunksjoner som utløsere og lagrede prosedyrer for å redusere sannsynligheten for usannsynlige data; vi kan til og med bygge mer avansert menneskelig integritet som sjekker inn i klientprogrammene. Hvordan kan vi unngå problemer som den nettopp beskrevne OG fortsatt programmere SQL Server 2005 så klokt som mulig? For å komme frem til en mulig løsning, la oss først utforske integrity assurance funksjoner OG funksjoner I SQL Server 2005. Etter denne diskusjonen, vi kan oppreise etternavn integritet problemet og tilby min medisinsk forsikringsselskap noen ideer før de blir saksøkt.