12. fejezet: adatintegritás

áttekintés

az adatbázis-fejlesztési, modellezési és kezelési körökben talán egyetlen más téma sem hív fel nagyobb figyelmet és gyakran heves vitát, mint az adatintegritás. Megdöbbentő, hogy a megértés, a gyakorlat és a technológia terén elért távolság ellenére olyan sok adatbázis-Guru (Celko, Codd, Date, Riordan, et al.) olyan széles körben változnak a saját filozófiájukban. Ennek eredményeként a rendszergazdák és a fejlesztők gyakran kezelik az integritás modellezését és így az integritás programozását a nadrágjuk ülésén. Még az SQL Server Books Online is zavaros módon határozza meg az adatok integritását a szószedetében, mint egy denevér fényes nappal.

ez a könyv biztosan nem az adatok integritásának megvitatásának fóruma, és ez körülbelül olyan, amennyire a relációs adatbázis-elmélet megvitatására Szeretnék vállalkozni. De anélkül, hogy feltárnánk néhány fogalmat, és elfogadnánk az adatintegritás egyetlen megvalósítható meghatározását, nem élvezheti az összes olyan eszközt és új funkciót, amelyet az SQL Server 2005 támogat az adatintegritás modellezés és programozás tekintetében.

az adatok integritása határozottan nem olyan gyakorlat, fegyelem, amely biztosítja, hogy az adatbázisban tárolt adatok helyesek legyenek, csak ez hihető vagy hihető. Az SQL Server 2005 vagy bármely más RDBMS nem tudja garantálni, hogy az adatbázisban lévő adatok helyesek. Get helyes ki a vocab most. Az SQL Server 2005 nem tudja tudni, és így biztosítja, hogy a körzetszámom nem 209, hanem 299, vagy hogy a vezetéknevem Shapiro és nem Schapiro. Még egy Jeffrey nevű lányról is hallottam. El kell kezdeni az SQL Server gondolkodását, modellezését és programozását az adatok hitelessége szempontjából, nem pedig az adatok helyes vagy helytelen szempontjából.

csak akkor használhatja az SQL Server 2005 által támogatott eszközöket és technikákat, ha elfogadja ezt a meghatározást, hogy biztosítsa az adatok sértetlenségét, és ezáltal értékét a vállalat számára. És miután elkezdesz a skaláris értelemben vett integritásra összpontosítani, és nem az abszolút értelemben vett korrektségre, sokkal jobban bízol az adatbázisban lévő adatokban, és megengedheted magadnak a bizalmat és tiszteletet, amit megérdemel. Végtére is, az adatok, amelyek nem hihető vagy hihető a felelősség

ahogy azt az 1. fejezetben tárgyaltam, az emberi hiba okozta a feleségem rendkívüli bánatát, amikor az egészségügyi biztosítótársaságok megváltoztatása után egy ideig megtagadták a fedezetet, mert az orvos vezetékneve, Shapiro helyett, a házastárs vezetékneve mezőbe került, a feleségemnek, az adatok integritásának kérdése így életveszélyessé vált. Az egészségbiztosító társaság számára a kérdés szinte felelősségi problémává robbant.

mi okozhatja vagy okozhatja a vezetéknév vagy vezetéknév hibáját?

1. a feleség leánykori nevén megy.

2. a házastárs tévesen álnevet ad.

3. a pár éppen elvált, de megállapodtak abban, hogy fenntartják a lefedettséget.

4. a gyermeket mostohaapja fedezi, de még mindig biológiai apja vezetéknevén jár.

5. az utónév a vezetéknév mezőbe kerül.

6. a vezetéknév helytelenül van beírva (Shapiro csak néhány ujjcsúszással válik Ahaoeei-vé).

7. a jelentkezési lapon szereplő kézírás gyenge, vagy a vezetéknév hiányzik, és az adatbeviteli személy téves feltételezést tesz.

ez a lista folytatódhat. És biztos vagyok benne, hogy tucatnyi olyan forgatókönyvvel tudna előállni, amelyek megkérdőjelezhető adatokat is létrehoznának, nemcsak a vezetéknév értékeiben, hanem sok más helyen is. A számok például hihetetlen lehetőségeket kínálnak a problémás adatok adatbázisba történő bevitelére.

de vajon ez feddhetetlenség kérdése? Ha elfogadjuk, hogy a DBMS-t úgy programozzuk, hogy az adatok a lehető leghihetőbbek legyenek, akkor az. Ha megpróbáljuk biztosítani, hogy az adatok helyesek legyenek, akkor nem az. Bármely érték valóban helyes lehet, ha feltételezzük, hogy helytelen, és valójában téves is lehet, ha feltételezzük, hogy helyes. Az egyetlen dolog, amit tehetünk, hogy segítsen biztosítani, hogy az adatok hihető, hogy segítsen biztosítani, hogy hihető volt, amikor bevitték az adatbázisba.

a legjobb, amit az adatszintnél el tudok képzelni annak biztosítása érdekében, hogy egy érték, például a házastárs vezetékneve hihető legyen, az az, hogy arra kényszerítem az Ügyfelet, hogy menjen vissza és ellenőrizze az adatokat, mielőtt be lehetne írni, vagy hasonlítsa össze az adatokat az ismert értékekkel. Lehetőség van arra is, hogy a rekordot visszautalja az ügyfélnek, és kérje, hogy egy másik felhasználó, esetleg egy felügyelő adja meg, aki a tényellenőrzést a következő szintre emeli. A webes szörfösök kérése, hogy töltsék ki a jelentkezési lapokat az Interneten keresztül, jó ötlet, mert kivágja a középső adatbeviteli személyt, a papírnyomot és a késleltetést, és az adatok hitelességének biztosítását az ügyfélre hárítja, aki nagyobb valószínűséggel biztosítja, hogy információira támaszkodhasson.

nemrég néztem egy szörnyű történetet a CNN-en egy amerikai gyógyszerészről, aki egy gyermeknek halálos túladagolást adott egy gyógyszernek, ellentétben azzal, amit a gyermekorvos helyesen írt fel. A kifogás emberi hiba volt, a felügyelő elmulasztása a receptek kettős ellenőrzésében, napi több száz recept kitöltése miért, az ég nevében, manapság a gyógyszerészek még mindig írógépeket és szövegszerkesztőket használnak a veszélyes gyógyszerek adagolására és beadására? Adatbázist kellett volna használni annak ellenőrzésére, hogy az adagolás nem haladta-e meg az előírt gyógyszer biztonságos szintjét. Egyetlen számítógépes program sem ellenőrizte az adagot, ezért egy anya ágyba küldte gyermekét, aki soha nem ébredt fel. Most, amikor drogokat vásárolunk, ellenőrizzük a címkét, és azon gondolkodunk ,hogy ” bízhatunk-e az életünkben ezekre az adatokra?”

nyilvánvaló, hogy az emberi tévedés témája túlmutat e könyv hatókörén, azon kívül, hogy megvitassuk, milyen lehetséges eszközökkel akadályozhatjuk meg az embereket abban, hogy megkérdőjelezhető adatokat vigyenek be egy adatbázisba. Joe Celko csodálatos könyvében érintette a témát, Joe Celko adatai & adatbázisok: fogalmak a gyakorlatban (New York: Morgan Kaufmann, 1999). A “modellek a valósággal szemben” című részben a modellek hibáiról beszél, leírva az I. és II.típusú hibaszinteket. Az I. típusú hiba azt jelenti, hogy hamisnak fogadunk el valamit, ami igaz, a II.típusú hiba pedig azt, hogy igaznak fogadunk el valamit, ami hamis.

egyetértés nélkül egyetértek azzal, hogy a modellek hibáinak témája nagyon fontos az adatbázisok számára, hogy megértsék. Emberek generációit irtották ki e probléma miatt. A szubszaharai Afrikát, ahol gyerekkoromat töltöttem, ki fogják irtani az AIDS miatt. Ezt meg lehetett volna előzni, de az ottani lakosság még mindig úgy véli, nagyjából, hogy az AIDS nem szexuális úton terjed, és hogy a nyilvánosság csak “nyugati propaganda.”A csalás valójában önfenntartó vagy önmegvalósító, mert afrikaiak milliói még mindig védtelen szexet folytatnak.

Igen, használhatunk divatos programozási trükköket és rendszerfunkciókat, például triggereket és tárolt eljárásokat, hogy csökkentsük a valószínűtlen adatok valószínűségét; még fejlettebb emberi integritás-ellenőrzést is építhetünk az ügyfélalkalmazásokba. Hogyan kerülhetjük el a fent leírtakhoz hasonló problémákat, és mégis a lehető legokosabban programozhatjuk az SQL Server 2005-öt? A lehetséges megoldáshoz először vizsgáljuk meg az SQL Server 2005 integritásbiztosító funkcióit és funkcióit. A megbeszélés után orvosolhatjuk a vezetéknév integritásának kérdését, és felajánlhatunk néhány ötletet az egészségbiztosítómnak, mielőtt beperelik őket.