#295
13. Kontrola integralności danych
Kiedy wyeliminujemy to, co niemożliwe, wówczas to, co pozostaje, jakkolwiek mało prawdopodobne, musi być prawdą
Sherlock Holmes "Znak czworga"
===============================
Przystępujemy do ostatniego etapu procesu projektowania bazy danych. Jego poprzednie fazy pokazały, jak:
zdobyć wiedze o zaletach relacyjnego modelu logicznego i o jego przewagach nad pozostałymi modelami,
sformułować definicje celu dla tworzonej bazy,
sformułować założenia wstępne dla tworzonej bazy,
dokonać pełnej analizy istniejącej bazy,
określić wymagania informacyjne organizacji,
zdefiniować wszystkie wymagane tabele,
przypisać każdej z tabel klucz podstawowy,
określić atrybuty wszystkich pól,
zdefiniować relacje miedzy tabelami,
określić i wprowadzić odpowiednie reguły integralności,
zdefiniować wymagane perspektywy,
zagwarantować ogólną integralność danych.
Z technicznego punktu widzenia stworzony przez Ciebie projekt można uznać za kompletny. W praktyce jednak dobrze jest jeszcze raz przyjrzeć się integralności danych, które będzie przechowywać nowo utworzona baza.
#296
Dlaczego warto skontrolować integralność danych
Prawdopodobnie zastanawiasz się, po co jeszcze jedna kontrola jakości bazy, skoro trzymałeś się ściśle wszelkich zaleceń projektowych, na każdym etapie zwracając uwagę na integralność danych. Powód jest prosty: chcemy upewnić się, że wprowadzona przez Ciebie tak dużym nakładem pracy integralność jest absolutnie niepodważalna. Każda drobna usterka czy luka w przepisach może mieć katastrofalne skutki. Choć jest to mało prawdopodobne, musimy liczyć się z możliwością przeoczenia jakiejś wady na wcześniejszych etapach procesu projektowania. Spokój ducha, jaki uzyskasz upewniając się, że zaprojektowana przez Ciebie baza spełnia wszystkie wymogi poprawności i efektywności, wart jest więc tego, ostatniego już, wysiłku.
======================
Pamiętaj: Wkładasz śmieci - wyjmujesz śmieci.
========================
Poprawianie integralności danych
Kontrola integralności danych staje się prosta, jeśli zastosujesz podejście modułowe. Innymi słowy, rozpatruj osobno każdy składnik ogólnej integralności: integralność na poziomie tabel, pól i relacji, oraz reguły integralności. Jeśli postępowałeś zgodnie z procedurami opisanymi we wcześniejszych rozdziałach, wówczas prawdopodobnie nie będziesz miał żadnych problemów. Poniżej znajdują się listy aspektów, na które powinieneś zwracać uwagę, analizując kolejne elementy bazy danych.
Na poziomie tabel
Aby upewnić się w sprawie integralności na poziomie tabel, przyjrzyj się każdej tabeli z osobna i sprawdź, czy spełnia ona następujące kryteria:
Nie zawiera pól zwielokrotnionych.
Nie zawiera pól wyliczonych.
Nie zawiera pól wielowartościowych.
Nie zawiera pól segmentowych.
Nie zawiera zdublowanych rekordów.
Każdy rekord jest identyfikowany przez pewną wartość klucza podstawowego.
Każdy klucz podstawowy spełnia kryteria poprawności.
Jeśli napotkasz problemy, możesz sobie z nimi poradzić, korzystając z technik opisanych w rozdziałach 6, 7 i 8.
#297
Na poziomie pól
Aby upewnić się o integralności na poziomie pól, sprawdź, czy:
każde pole spełnia kryteria pola doskonałego,
dla każdego pola określono zestaw atrybutów.
W przypadku wystąpienia problemów, zajrzyj do rozdziału 9.
Na poziomie relacji
Aby upewnić się o integralności na poziomie relacji, przyjrzyj się każdej relacji z osobna i sprawdź, czy:
została ona poprawnie zdefiniowana,
określono odpowiednią regułę usuwania,
poprawnie określono typ uczestnictwa każdej z tabel w tej relacji,
poprawnie określono stopień uczestnictwa każdej z tabel w tej relacji. Jeśli natrafisz na problemy, skorzystaj z technik opisanych w rozdziale 10.
Na poziomie reguł integralności
Upewnienie się co do poprawności tych reguł polega na sprawdzeniu, czy:
każda reguła narzuca logiczne ograniczenie,
każdą regułę zaklasyfikowano do odpowiedniej kategorii,
odnośne atrybuty pól lub cechy relacji zostały odpowiednio zmodyfikowane,
zdefiniowano właściwe tabele walidacji,
dla każdej reguły integralności wypełniono odpowiedni formularz cech. W przypadku wystąpienia problemów, zajrzyj do rozdziału 11.
Na poziomie perspektyw
Pomimo iż perspektywy nie są bezpośrednio związane z integralnością danych, powinieneś je skontrolować. Analizując każdą perspektywę zwracaj uwagę, czy:
bazuje na właściwych tabelach,
przypisano do niej właściwe pola z tabel bazowych,
każde pole wyliczone udziela istotnych informacji lub poprawia czytelność danych,
każdy filtr zwraca pożądane rekordy,
sporządzono odpowiedni diagram perspektywy,
wypełniono formularz specyfikacji perspektywy.
#298
Po zakończeniu tego procesu możesz być pewien, że struktura bazy danych jest poprawna, przechowywane w niej dane - spójne, a informacje dostarczane przez twoją bazę - precyzyjne.
Jak przygotować dokumentację bazy
W trakcie projektowania bazy danych zgromadziłeś dużą liczbę list, formularzy i diagramów opisujących różne aspekty jej struktury. Czas teraz na ich odpowiednie posortowanie i utworzenie pojedynczego pakietu dokumentacji, o ile to możliwe
wykorzystując do tego celu segregator. (Można też posłużyć się komputerem). Dokumentacja bazy danych powinna składać się z następujących materiałów:
ostatecznej listy tabel,
formularzy atrybutów pól,
listy pól wyliczonych,
diagramów struktur tabel,
diagramów relacji,
formularzy specyfikacji reguł integralności,
diagramów perspektyw,
formularzy specyfikacji perspektyw.
Dwa dodatkowe elementy, którymi możesz uzupełnić dokumentację, to notatki sporządzone na różnych etapach tworzenia projektu oraz przykładowe formularze i raporty zgromadzone podczas analizy istniejącej bazy. Należy je umieścić na końcu, w charakterze załączników.
Przedstawione wyżej dokumenty tworzą razem pełną dokumentację projektu logicznego bazy danych. Dokumentacja ta jest istotna z trzech powodów:
1. Stanowi kompletny opis struktury bazy. Dokumentacja opisuje wszystkie elementy projektu logicznego bazy danych. Czytając dokumentację można znaleźć odpowiedź na praktycznie dowolne pytanie związane z tą bazą.
2. Stanowi zbiór instrukcji określających sposób implementacji bazy danych. Dokumentacja pełni rolę podobną do szkiców architekta: mówi, jak należy zbudować opisywaną przezeń bazę. Ponadto zawiera opis integralności, jaką należy wprowadzić w fazie implementacji. Ze względu na niezależność projektu logicznego od systemów SZRBD, osoby implementujące ten projekt bazy mają wolną rękę w sprawach wprowadzania opisywanych przezeń struktur do komputera.
3. Jeśli w fazie implementacji konieczne okaże się wprowadzenie zmian do projektu logicznego, wówczas z dokumentacji będzie można wywnioskować, jaki wpływ wprowadzane modyfikacje wywrą na strukturze bazy. Każda zmiana w projekcie logicznym bazy danych powinna być wynikiem przemyślanej decyzji. Wgląd
#299
w dokumentację umożliwi uniknięcie negatywnego wpływu takich zmian na produkt końcowy.
I wreszcie koniec!
Po zweryfikowaniu integralności danych i sporządzeniu odpowiedniej dokumentacji możesz uznać proces projektowania bazy danych za zakończony. Stworzona przez Ciebie struktura jest poprawna i efektywna oraz umożliwia bezproblemową implementację. Czas na następnego klienta i na następny projekt!
STUDIUM PRZYPADKU - ZAKOŃCZENIE
To Twoje ostatnie spotkanie z Mike'em i jego pracownikami. Twoim celem jest dokonanie ostatecznej kontroli integralności bazy. Pomimo iż jesteś pewien, że nie natrafisz na żadne problemy, powinieneś jeszcze raz zweryfikować poszczególne elementy składowe utworzonego projektu.
W trakcie spotkania analizujesz po kolei poszczególne struktury bazy sprawdzając, czy spełniają one warunki nakładane nań przez zasady projektowania. Następnie rozpatrujesz oddzielnie każdy poziom integralności danych i upewniasz się, że integralność ta została zachowana. Na koniec wręczasz dokumentację ukończonej bazy Mikę'owi i ogłaszasz, że praca dobiegła końca. Mikę wyraża swoje uznanie oraz obiecuje, że Twój czek nadejdzie w ciągu tygodnia. Żegnasz się z Mike'em i pracownikami jego firmy i kierujesz się ku nowym horyzontom. Patrząc jak odchodzisz, Mikę zastanawia się nad czymś i po chwili wymyka mu się jeszcze jedno zdanie:
"Gdybym mógł Cię teraz zatrudnić do zaimpłementowania mojej bazy...".
Podsumowanie
Rozdział ten rozpoczęliśmy wymienieniem Twoich dokonań na wcześniejszych etapach procesu projektowania. Następnie przeszliśmy do wyjaśnienia, dlaczego warto przeprowadzić jeszcze jedną kontrolę integralności danych, po czym powiedzieliśmy, na co warto zwracać uwagę w trakcie tej kontroli. Na zakończenie opisaliśmy rolę, jaką pełni dokumentacja gotowej bazy.
Wyszukiwarka
Podobne podstrony:
13 Wydajność i integralność bazy danychABC zasad kontroli przetwarzania danych osobowychMechanizmy integracdji danych 2pojęcie integralności danychIntegracja danych część 1notatki z zajęc ?zy danych2 18 3 1313 Analiza danych w podgrupachnotatki z zajęc ?za danych2 11 3 13gsw?ntra integracji spolecznej 1313 SKALA KONTROLI DZIAŁANIA J Kuhla (ACS 90)Podstawowe zalozenia i kontrowersje wokol integracji PL z UE13 Kompresja danych05 replikacja danych między kontrolerami domenyidY74notatki z zajęc ?za danych2 4 3 132009 11 Audyt i kontrola danych osobowychwięcej podobnych podstron