Luku 12: tietojen eheys

yleiskatsaus

ehkä mikään muu keskustelunaihe tietokantojen kehittämisessä, mallintamisessa ja johtamisessa ei herätä enemmän huomiota ja usein kiivasta keskustelua kuin tietojen eheys. On hämmästyttävää, että vaikka etäisyys olemme tulleet ymmärrystä, käytäntö, ja teknologia, niin monet tietokanta gurut (Celko, Codd, Date, Riordan, et al.) vaihtelevat niin suuresti eri filosofioissaan. Tämän vuoksi ylläpitäjät ja Kehittäjät hoitavat usein integriteettimallinnuksen ja sitä kautta eheysohjelmoinnin housujen istuimen mukaan. Jopa SQL Server Books Online määrittelee tiedon eheyden sanastossaan hieman sekavammalla tavalla kuin lepakko kirkkaassa päivänvalossa.

tämä kirja ei todellakaan ole foorumi keskustelulle tietojen eheydestä, ja tämä on suunnilleen niin pitkälle kuin haluan uskaltaa keskustella relaatiotietokantateoriasta. Mutta tutkimatta joitakin käsitteitä ja hyväksymättä ainoaa mahdollista tiedon eheyden määritelmää, et hyödy kaikista työkaluista ja uusista ominaisuuksista, joita SQL Server 2005 tukee tietojen eheyden mallinnuksen ja ohjelmoinnin osalta.

tietojen eheys ei todellakaan ole käytäntö, tieteenala, jolla varmistetaan, että tietokantaan tallennetut tiedot ovat oikeita, vain että ne ovat uskottavia tai uskottavia. Ei ole mitään keinoa tämän elämän ja tuonpuoleisen välillä, että SQL Server 2005, tai mikään muu RDBMS, voi taata, että tietokannassa olevat tiedot ovat oikein. Puhukaa kunnolla. SQL Server 2005: llä ei ole mitään keinoa tietää ja varmistaa, että suuntanumeroni ei ole 209 vaan 299 tai että sukunimeni on Shapiro eikä Schapiro. Olen jopa kuullut tytöstä nimeltä Jeffrey. Sinun täytyy alkaa ajatella, mallinnus, ja ohjelmointi SQL Server kannalta tietojen uskottavuus, ei kannalta tiedot ovat oikeita tai vääriä.

vain jos hyväksyt tämän määritelmän, voit käyttää SQL Server 2005: n tukemia työkaluja ja tekniikoita varmistaaksesi tietojesi eheyden ja siten niiden arvon yrityksellesi. Ja kun alat keskittyä eheyteen skalaarisesti eikä oikeellisuuteen absoluuttisesti, sinulla on paljon enemmän uskoa tietokantasi tietoihin, ja sinulla on varaa siihen luottamus ja kunnioitus, jonka se ansaitsee. Loppujen lopuksi tiedot, jotka eivät ole uskottavia tai uskottavia, ovat vastuu

kuten käsittelin luvussa 1, inhimillinen virhe aiheutti vaimolleni äärimmäistä surua, kun muutettuaan sairausvakuutusyhtiöitä, häneltä evättiin kattavuus jonkin aikaa, koska hänen lääkärinsä sukunimi, Shapiron sijaan, oli merkitty puolison sukunimikenttään, vaimolleni, tietojen eheysongelmasta tuli siten hengenvaarallinen. Sairasvakuutusyhtiölle asia melkein räjähti vastuuongelmaksi.

mikä aiheuttaisi tai voisi aiheuttaa sukunimen tai sukunimen virheellisyyden?

1. vaimo käyttää tyttönimeään.

2. puoliso antaa vahingossa salanimen.

3. pari erosi juuri, mutta suostui jatkamaan uutisointia.

4. lapsi kuuluu isäpuolen piiriin, mutta kulkee silti biologisen isänsä sukunimellä.

5. etunimi merkitään sukunimikenttään.

6. sukunimi kirjoitetaan väärin (Shapirosta tulee Ahaoeuei vain muutamalla sormen lipsahduksella).

7. hakulomakkeen käsiala on huono tai sukunimi on jätetty pois ja ilmoittaja tekee väärän olettamuksen.

tämä lista voi jatkua loputtomiin. Ja varmasti voisi keksiä kymmeniä skenaarioita, jotka loisivat kyseenalaista dataa paitsi sukunimiarvoissa myös monessa muussa paikassa. Esimerkiksi numerot tarjoavat uskomattomia mahdollisuuksia syöttää ongelmallisia tietoja tietokantaan.

mutta onko tässä kysymys nuhteettomuudesta? Jos hyväksymme, että ohjelmoimme DBMS: t sen varmistamiseksi, että tiedot ovat mahdollisimman uskottavia, niin se on. Jos yritämme varmistaa, että tiedot ovat oikein, niin se ei ole. Mikä tahansa arvo voi itse asiassa olla oikea, kun sen oletetaan olevan väärä, ja se voi itse asiassa olla väärä, kun sen oletetaan olevan oikea. Ainoa asia, jonka voit tehdä varmistaaksesi, että tiedot ovat uskottavia, on auttaa varmistamaan, että ne olivat uskottavia, kun ne syötettiin tietokantaan.

paras, mitä voin kuvitella tekeväni datatasolla varmistaakseni, että jokin arvo, kuten puolison sukunimi, on pakottaa asiakas menemään takaisin ja tarkistamaan tiedot ennen kuin ne voidaan syöttää, tai vertaamaan tietoja tunnettuihin arvoihin. On mahdollista jopa palauttaa tietue takaisin asiakkaalle ja pyytää sitä syötettäväksi toiselle käyttäjälle, mahdollisesti esimiehelle, joka veisi faktantarkistuksen seuraavalle tasolle. Pyytämällä Web surfers täyttää hakemuslomakkeita Internetissä on hyvä idea, koska se leikkaa pois keskellä tietojen syöttö henkilö, paperijäljet, ja viive ja se asettaa taakka varmistaa tietojen uskottavuus asiakkaalle, joka on todennäköisemmin varmistaa, että hänen tietonsa voidaan luottaa.

katsoin äskettäin CNN: llä kauhistuttavan tarinan amerikkalaisesta farmaseutista, joka antoi lapselle kuolettavan yliannostuksen lääkettä vastoin lastenlääkärin oikein määräämää lääkettä. Tekosyynä oli inhimillinen erehdys, esimiehen epäonnistuminen reseptien tuplatarkastuksessa, satojen reseptien täyttäminen päivässä miksi, taivaan tähden, vielä tänä päivänä farmaseutit käyttävät kirjoituskoneita ja tekstinkäsittelykoneita antaakseen ohjeita vaarallisten lääkkeiden annostelusta ja annostelusta? Tietokannasta olisi pitänyt tarkistaa, että annos ei ylittänyt määrättyä lääkettä turvallisesti. Mikään tietokoneohjelma ei tarkistanut annostusta, joten äiti lähetti lapsensa nukkumaan, eikä tämä koskaan herännyt. Nyt, aina kun ostamme huumeita, tarkistamme etiketin ja mietimme ” voimmeko luottaa elämämme näihin tietoihin?”

ilmeisesti inhimillisen erehdyksen aihe on tämän kirjan ulottumattomissa, muuta kuin keskustella siitä, mitä mahdollisia keinoja meillä voisi olla estääksemme ihmisiä syöttämästä kyseenalaista tietoa tietokantaan. Joe Celko käsitteli aihetta ihmeellisessä kirjassaan Joe Celkon Data & Databases: Concepts in Practice (New York: Morgan Kaufmann, 1999). Jaksossa ”mallit vastaan todellisuus” hän puhuu mallien virheistä kuvaten tyypin I ja tyypin II virhetasoja. Tyypin I virhe on hyväksyä epätosi jotain, joka on totta, ja tyypin II virhe on hyväksyä todeksi jotain, että se epätosi.

olen yhtymättä samaa mieltä siitä, että mallien virheiden aihe on erittäin tärkeä tietokantaihmisten ymmärrettäväksi. Tämän ongelman vuoksi on tuhottu sukupolvia. Saharan eteläpuolinen Afrikka, jossa vietin lapsuuteni, tulee häviämään aidsin takia. Tämä olisi voitu estää, mutta sikäläiset ihmiset uskovat yhä yleisesti, että AIDS ei tartu sukupuoliteitse ja että julkisuus on vain ”länsimaista propagandaa.”Petos on itse asiassa itsensä ylläpitämistä tai itsensä toteuttamista, koska miljoonat afrikkalaiset harrastavat yhä suojaamatonta seksiä.

Kyllä, voimme käyttää hienoja ohjelmointitemppuja ja järjestelmän ominaisuuksia, kuten laukaisimia ja tallennettuja menettelyjä, vähentääksemme epäuskottavien tietojen todennäköisyyttä; voimme jopa rakentaa kehittyneempiä ihmisen eheyden tarkistuksia asiakassovelluksiin. Miten voimme välttää ongelmia, kuten juuri kuvattu ja silti ohjelmoida SQL Server 2005 mahdollisimman viisaasti? Mahdollisen ratkaisun löytämiseksi tutkitaan ensin SQL Server 2005: n integrity assurance-ominaisuuksia ja toimintoja. Tämän keskustelun jälkeen voimme korjata sukunimen eheysongelman-ja tarjota vakuutusyhtiölleni ideoita, ennen kuin heidät haastetaan oikeuteen.