Rozdział 12: integralność danych

przegląd

być może żaden inny temat dyskusji w środowiskach tworzenia, modelowania i zarządzania bazami danych nie zwraca większej uwagi i często gorącej debaty niż kwestia integralności danych. Zdumiewające jest to, że pomimo odległości, jaką osiągnęliśmy w zrozumieniu, praktyce i technologii, tak wielu guru baz danych (Celko, Codd, Date, Riordan i in.) tak bardzo różnią się w swoich filozofiach. W rezultacie administratorzy i programiści często zajmują się modelowaniem integralności, a tym samym programowaniem integralności przez siedzenie swoich spodni. Nawet SQL Server Books Online definiuje integralność danych w swoim słowniku w sposób bardziej zdezorientowany niż nietoperz w biały dzień.

ta książka z pewnością nie jest forum do dyskusji o integralności danych, a to jest o tyle, o ile chcę zaryzykować omówienie teorii relacyjnych baz danych. Ale bez zbadania niektórych pojęć i zaakceptowania jedynej możliwej definicji integralności danych, nie skorzystasz ze wszystkich narzędzi i nowych funkcji, które SQL Server 2005 obsługuje w odniesieniu do modelowania i programowania integralności danych.

integralność danych zdecydowanie nie jest praktyką, dyscypliną, która zapewnia, że dane przechowywane w bazie danych są poprawne, tylko to jest wiarygodne lub wiarygodne. Nie ma możliwości, aby SQL Server 2005, ani żaden inny RDBMS, mógł zagwarantować, że dane w bazie danych są poprawne. Popraw swoje słownictwo. SQL Server 2005 nie ma możliwości poznania, a tym samym zapewnienia, że mój Kod Kierunkowy to nie 209, ale raczej 299, lub że moje nazwisko to Shapiro, a nie Schapiro. Słyszałem nawet o dziewczynie o imieniu Jeffrey. Musisz zacząć myśleć, modelować i programować SQL Server pod względem wiarygodności danych, a nie pod względem poprawności lub błędu danych.

tylko jeśli zaakceptujesz tę definicję, będziesz mógł korzystać z narzędzi i technik obsługiwanych przez SQL Server 2005 w celu zapewnienia integralności danych, a tym samym ich wartości jako aktywów dla Twojego przedsiębiorstwa. A kiedy zaczniesz skupiać się na integralności w kategoriach skalarnych, a nie na poprawności w kategoriach absolutnych, będziesz miał o wiele większą wiarę w dane w swojej bazie danych i będziesz mógł sobie pozwolić na zaufanie i szacunek, na jakie zasługuje. W końcu dane, które nie są wiarygodne lub wiarygodne, to odpowiedzialność

jak omówiłem w rozdziale 1, błąd ludzki spowodował moją żonę skrajny żal, gdy po zmianie firm ubezpieczeniowych medycznych odmówiono jej pokrycia przez jakiś czas, ponieważ nazwisko jej lekarza, zamiast Shapiro, zostało wpisane w pole nazwiska małżonka, do mojej żony, problem integralności danych stał się w ten sposób zagrażający życiu. Dla firmy ubezpieczeniowej, problem prawie eksplodował w problem odpowiedzialności.

co mogłoby lub mogłoby spowodować nieprawidłowe nazwisko lub nazwisko?

1. żona nosi panieńskie nazwisko.

2. małżonek błędnie podaje pseudonim.

3. para właśnie się rozwiodła, ale zgodziła się utrzymać pokrycie.

4. dziecko jest objęte przez ojczyma, ale nadal nosi nazwisko swojego biologicznego ojca.

5. imię jest wprowadzane do pola nazwisko.

6. nazwisko jest wpisane nieprawidłowo(Shapiro staje się Ahaoeuei z zaledwie kilku poślizgów palca).

7. pismo na formularzu zgłoszeniowym jest słabe lub nazwisko jest pominięte, a osoba wprowadzająca dane dokonuje błędnego założenia.

ta lista może trwać i trwać. I jestem pewien, że można by wymyślić dziesiątki scenariuszy, które stworzyłyby również wątpliwe dane, nie tylko w wartościach nazwiska, ale także w wielu innych miejscach. Na przykład liczby dają niesamowite możliwości wprowadzania problematycznych danych do bazy danych.

ale czy to kwestia uczciwości? Jeśli zaakceptujemy, że programujemy DBMS, aby zapewnić, że dane są tak wiarygodne, jak to możliwe, to tak jest. Jeśli staramy się zapewnić, że dane są poprawne, to tak nie jest. Każda wartość może w rzeczywistości być poprawna, gdy zakłada się, że jest błędna, i może w rzeczywistości być błędna, gdy zakłada się, że jest poprawna. Jedyną rzeczą, którą możesz zrobić, aby upewnić się, że dane są wiarygodne, jest pomoc w upewnieniu się, że były wiarygodne, gdy zostały wprowadzone do bazy danych.

najlepsze, co mogę zrobić w warstwie danych, aby upewnić się, że wartość, taka jak nazwisko małżonka, jest wiarygodna, to zmusić klienta do powrotu i sprawdzenia danych przed ich wprowadzeniem lub porównania danych ze znanymi wartościami. Możliwe jest nawet odesłanie rekordu z powrotem do klienta i poproszenie go o wprowadzenie przez innego użytkownika, ewentualnie przełożonego, który przeniesie sprawdzanie faktów na wyższy poziom. Poproszenie internautów o wypełnienie formularzy zgłoszeniowych przez Internet jest dobrym pomysłem, ponieważ wycina środkową osobę wprowadzającą dane, ślad papierowy i opóźnienie, a także nakłada obowiązek zapewnienia wiarygodności danych na klienta, który jest bardziej skłonny zapewnić, że jego Informacje mogą być zaufane.

ostatnio oglądałem przerażającą historię w CNN o amerykańskim farmaceucie, który dał dziecku śmiertelne przedawkowanie leku wbrew temu, co zostało prawidłowo przepisane przez pediatrę. Wymówką był ludzki błąd, brak kontroli recept przez przełożonego, wypełnianie setek recept dziennie dlaczego, na Boga, w dzisiejszych czasach, farmaceuci nadal używają maszyn do pisania i edytorów tekstu, aby dostarczać instrukcje dotyczące dawkowania i podawania niebezpiecznych leków? Baza danych powinna być wykorzystana do sprawdzenia, czy dawka nie przekracza bezpiecznie poziomów przepisanego leku. Żaden program komputerowy nie sprawdzał dawki, więc matka wysłała dziecko do łóżka i nigdy się nie obudził. Teraz, kiedy kupujemy leki, sprawdzamy etykietę i zastanawiamy się ” czy możemy zaufać naszym życiu tym danym?”

oczywiście temat ludzkiego błędu wykracza poza zakres tej książki, poza omówieniem możliwych środków zapobiegania wprowadzaniu przez ludzi wątpliwych danych do bazy danych. Joe Celko poruszył ten temat w swojej wspaniałej książce Joe Celko ’ s Data & Databases: Concepts in Practice (Nowy Jork: Morgan Kaufmann, 1999). W części zatytułowanej „modele kontra rzeczywistość” opowiada o błędach w modelach, opisując poziomy błędów typu I i typu II. Błąd typu I akceptuje jako fałszywe coś, co jest prawdą, a błąd typu II akceptuje jako prawdziwe coś, co jest fałszywe.

zgadzam się bez dwóch zdań, że temat błędów w modelach jest bardzo ważny dla ludzi z bazy danych. Pokolenia ludzi zostały wymazane z powodu tego problemu. Afryka Subsaharyjska, gdzie spędziłem dzieciństwo, zostanie zniszczona z powodu AIDS. Można było temu zapobiec, ale tamtejsza ludność nadal uważa, że AIDS nie jest przenoszone drogą płciową, a reklama jest po prostu ” zachodnią propagandą.”Oszustwo jest w rzeczywistości samowystarczalne lub samospełniające się, ponieważ miliony Afrykańczyków nadal uprawiają seks bez zabezpieczenia.

Tak, możemy używać fantazyjnych sztuczek programistycznych i funkcji systemowych, takich jak wyzwalacze i procedury składowane, aby zmniejszyć prawdopodobieństwo niewiarygodnych danych; możemy nawet zbudować bardziej zaawansowane sprawdzanie integralności ludzkiej w aplikacjach klienckich. Jak uniknąć problemów takich jak ten opisany i nadal programować SQL Server 2005 tak mądrze, jak to tylko możliwe? Aby znaleźć możliwe rozwiązanie, zbadajmy najpierw funkcje i funkcje zapewnienia integralności SQL Server 2005. Po tej dyskusji, możemy rozwiązać problem integralności nazwiska i zaoferować mojej firmie ubezpieczeniowej kilka pomysłów, zanim zostaną pozwani.