hoofdstuk 12: Data Integrity

overzicht

misschien geen ander onderwerp van discussie in database ontwikkeling, modellering en management kringen trekt meer aandacht, en vaak verhitte discussie, dan dat van data integrity. Het is verbazingwekkend dat, ondanks de afstand die we zijn gekomen in begrip, praktijk en technologie, zo veel database goeroes (Celko, Codd, Date, Riordan, et al.) zo sterk variëren in hun respectieve filosofieën. Als gevolg hiervan behandelen beheerders en ontwikkelaars vaak integriteitsmodellering en dus integriteitsprogrammering door de zitplaats van hun broek. Zelfs SQL Server Books Online definieert data-integriteit in zijn woordenlijst op een manier meer verward dan een vleermuis op klaarlichte dag.

dit boek is zeker niet het forum voor een discussie over data-integriteit, en dit is ongeveer alles wat ik wil wagen in het bespreken van relationele database theorie. Maar zonder het verkennen van een aantal concepten en het accepteren van de enige haalbare definitie van data-integriteit, zult u niet profiteren van alle tools en nieuwe functies die SQL Server 2005 ondersteunt met betrekking tot data-integriteit modellering en programmering.

integriteit van gegevens is zeker geen praktijk, een discipline, die ervoor zorgt dat gegevens die in een database zijn opgeslagen correct zijn, alleen is dat geloofwaardig of plausibel. Er is geen enkele manier tussen dit leven en het hiernamaals dat SQL Server 2005, of enige andere RDBMS, kan garanderen dat de gegevens in een database correct zijn. Ga nu uit je woorden. SQL Server 2005 heeft geen manier om te weten en er dus voor te zorgen dat mijn netnummer niet 209 maar 299 is, of dat mijn achternaam Shapiro is en niet Schapiro. Ik heb zelfs gehoord van een meisje genaamd Jeffrey. Je moet beginnen te denken, modelleren en programmeren SQL Server in termen van data plausibiliteit, niet in termen van gegevens goed of fout.

alleen als u deze definitie accepteert, kunt u de tools en technieken gebruiken die door SQL Server 2005 worden ondersteund om de integriteit van uw gegevens en dus de waarde ervan als een asset voor uw onderneming te waarborgen. En nadat je begint te focussen op integriteit in scalaire termen en niet correctheid in absolute termen, zul je veel meer vertrouwen hebben in de gegevens in je database, en je zult in staat zijn om het vertrouwen en respect te veroorloven dat het verdient. Gegevens die niet plausibel of geloofwaardig zijn, zijn immers een aansprakelijkheid

zoals ik al zei in Hoofdstuk 1, menselijke fouten veroorzaakten mijn vrouw extreem verdriet toen, na het veranderen van medische verzekeringsmaatschappij, haar enige tijd de dekking werd ontzegd omdat de achternaam van haar arts, in plaats van Shapiro, werd ingevoerd in het veld Achternaam van de echtgenoot, aan mijn vrouw, de data-integriteit probleem werd dus een levensbedreigende. Voor de medische verzekeringsmaatschappij explodeerde het probleem bijna tot een aansprakelijkheidsprobleem.

wat zou er de oorzaak van kunnen zijn dat een achternaam of achternaam onjuist is?

  1. de vrouw heeft haar meisjesnaam.

  2. een echtgenoot geeft ten onrechte een pseudoniem.

  3. het echtpaar is net gescheiden, maar ging akkoord om de dekking te behouden.

  4. een kind wordt gedekt door een stiefvader, maar heeft nog steeds de achternaam van zijn of haar biologische vader.

  5. de voornaam wordt ingevoerd in het veld Achternaam.

  6. de achternaam wordt verkeerd getypt (Shapiro wordt Ahaoeuei met slechts een paar vingerknipjes).

  7. het handschrift op het aanvraagformulier is slecht, of de achternaam wordt weggelaten en de gegevensinvoer persoon maakt een verkeerde veronderstelling.

deze lijst kan maar doorgaan. En ik weet zeker dat je met tientallen scenario ‘ s zou kunnen komen die ook twijfelachtige gegevens zouden creëren, niet alleen in achternaam waarden, maar ook op vele andere plaatsen. Cijfers bieden bijvoorbeeld ongelooflijke mogelijkheden om problematische gegevens in een database in te voeren.

maar is dit een kwestie van integriteit? Als we accepteren dat we het DBMS programmeren om ervoor te zorgen dat de gegevens zo geloofwaardig mogelijk zijn, dan is dat zo. Als we proberen ervoor te zorgen dat de gegevens correct zijn, dan is dat niet zo. Elke waarde kan in feite correct zijn wanneer wordt aangenomen dat het verkeerd is, en het kan in feite verkeerd zijn wanneer wordt aangenomen dat het correct is. Het enige wat je kunt doen om ervoor te zorgen dat gegevens geloofwaardig zijn, is ervoor te zorgen dat ze geloofwaardig waren toen ze in de database werden ingevoerd.

het beste wat ik kan bedenken om te doen op de data-laag om ervoor te zorgen dat een waarde, zoals de achternaam van de echtgenoot, geloofwaardig is, is om de cliënt te dwingen om terug te gaan en de gegevens te controleren voordat ze kunnen worden ingevoerd, of om de gegevens te vergelijken met bekende waarden. Het is zelfs mogelijk om het record terug te verwijzen naar de client en te verzoeken om het door een andere gebruiker te worden ingevoerd, mogelijk een supervisor die de facts checking naar het volgende niveau zou brengen. Vragen Web surfers in te vullen aanvraagformulieren via het Internet is een goed idee, omdat het snijdt de middelste gegevensinvoer persoon, de papieren spoor, en vertraging en het zet de verantwoordelijkheid van het waarborgen van de gegevens plausibiliteit op de klant, die is meer kans om ervoor te zorgen dat zijn of haar informatie kan worden vertrouwd op.Ik heb onlangs een afschuwelijk verhaal op CNN gezien over een Amerikaanse apotheker die een kind een fatale overdosis gaf van een geneesmiddel dat in strijd was met wat correct was voorgeschreven door de kinderarts. Het excuus was een menselijke fout, het falen van de supervisor om de recepten dubbel te controleren, het vullen van honderden recepten per dag waarom, in hemelsnaam, in deze tijd, gebruiken apothekers nog steeds typemachines en tekstverwerkers om instructies te geven over dosering en toediening van gevaarlijke drugs? Een database zou moeten worden gebruikt om te controleren dat de dosering veilig niveaus voor het voorgeschreven medicijn niet overschrijdt. Geen enkel computerprogramma controleerde de dosering, en dus stuurde een moeder haar kind naar bed en hij werd nooit meer wakker. Wanneer we drugs kopen, controleren we het etiket en vragen we ons af: “kunnen we onze levens vertrouwen op deze gegevens?”

het onderwerp menselijke fouten valt uiteraard buiten het bestek van dit boek, behalve het bespreken van de mogelijke middelen die we zouden kunnen hebben om te voorkomen dat mensen twijfelachtige gegevens in een database invoeren. Joe Celko heeft dit onderwerp behandeld in zijn prachtige boek, Joe Celko ‘ s Data & Databases: Concepts in Practice (New York: Morgan Kaufmann, 1999). In een sectie getiteld “modellen Versus realiteit,” hij praat over fouten in modellen, het beschrijven van type I en type II fout niveaus. Een Type I-fout is iets accepteren dat waar is, en een Type II-fout is iets accepteren dat het onwaar is.

ik ben het er zonder twijfel mee eens dat het onderwerp van fouten in modellen zeer belangrijk is voor databasemensen om te begrijpen. Generaties mensen zijn weggevaagd door dit probleem. Afrika bezuiden de Sahara, waar ik mijn jeugd doorbracht, zal uitgeroeid worden door AIDS. Dit had voorkomen kunnen worden, maar de bevolking daar gelooft nog steeds, over het algemeen, dat AIDS niet seksueel wordt overgedragen en dat de publiciteit gewoon “westerse propaganda” is.”De fraude is in feite zelfbestendig of zelfvervullend, omdat miljoenen Afrikanen nog steeds onbeschermde seks hebben.

Ja, we kunnen gebruik maken van fancy programmeertrucs en systeemfuncties zoals triggers en opgeslagen procedures om de kans op onwaarschijnlijke gegevens te verminderen; we kunnen zelfs meer geavanceerde menselijke integriteit controleren in de client-toepassingen. Hoe kunnen we voorkomen dat problemen zoals de zojuist beschreven en nog steeds programma SQL Server 2005 zo verstandig mogelijk? Om tot een mogelijke oplossing te komen, laten we eerst de functies en functies van integrity assurance van SQL Server 2005 verkennen. Na deze discussie, kunnen we de achternaam integriteit probleem herstellen en bieden mijn medische verzekeringsmaatschappij een aantal ideeën voordat ze worden aangeklaagd.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.