#295 13. Kontrola integralnoci 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, okrelić wymagania informacyjne organizacji, zdefiniować wszystkie wymagane tabele, przypisać każdej z tabel klucz podstawowy, okrelić atrybuty wszystkich pól, zdefiniować relacje miedzy tabelami, okrelić i wprowadzić odpowiednie reguły integralnoci, 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ę integralnoci danych, które będzie przechowywać nowo utworzona baza. #296 Dlaczego warto skontrolować integralnoć danych Prawdopodobnie zastanawiasz się, po co jeszcze jedna kontrola jakoci bazy, skoro trzymałe się cile 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żliwociš przeoczenia jakiej wady na wczeniejszych etapach procesu projektowania. Spokój ducha, jaki uzyskasz upewniajšc się, że zaprojektowana przez Ciebie baza spełnia wszystkie wymogi poprawnoci i efektywnoci, wart jest więc tego, ostatniego już, wysiłku. ====================== Pamiętaj: Wkładasz mieci - wyjmujesz mieci. ======================== Poprawianie integralnoci danych Kontrola integralnoci danych staje się prosta, jeli zastosujesz podejcie modułowe. Innymi słowy, rozpatruj osobno każdy składnik ogólnej integralnoci: integralnoć na poziomie tabel, pól i relacji, oraz reguły integralnoci. Jeli postępowałe zgodnie z procedurami opisanymi we wczeniejszych 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 integralnoci 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 wielowartociowych. 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 poprawnoci. Jeli 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 integralnoci na poziomie pól, sprawd, czy: każde pole spełnia kryteria pola doskonałego, dla każdego pola okrelono zestaw atrybutów. W przypadku wystšpienia problemów, zajrzyj do rozdziału 9. Na poziomie relacji Aby upewnić się o integralnoci na poziomie relacji, przyjrzyj się każdej relacji z osobna i sprawd, czy: została ona poprawnie zdefiniowana, okrelono odpowiedniš regułę usuwania, poprawnie okrelono typ uczestnictwa każdej z tabel w tej relacji, poprawnie okrelono stopień uczestnictwa każdej z tabel w tej relacji. Jeli natrafisz na problemy, skorzystaj z technik opisanych w rozdziale 10. Na poziomie reguł integralnoci Upewnienie się co do poprawnoci tych reguł polega na sprawdzeniu, czy: każda reguła narzuca logiczne ograniczenie, każdš regułę zaklasyfikowano do odpowiedniej kategorii, odnone atrybuty pól lub cechy relacji zostały odpowiednio zmodyfikowane, zdefiniowano właciwe tabele walidacji, dla każdej reguły integralnoci wypełniono odpowiedni formularz cech. W przypadku wystšpienia problemów, zajrzyj do rozdziału 11. Na poziomie perspektyw Pomimo iż perspektywy nie sš bezporednio zwišzane z integralnociš danych, powiniene je skontrolować. Analizujšc każdš perspektywę zwracaj uwagę, czy: bazuje na właciwych tabelach, przypisano do niej właciwe 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ł integralnoci, 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 umiecić 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 okrelajš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 integralnoci, 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. Jeli 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 przemylanej decyzji. Wglšd #299 w dokumentację umożliwi uniknięcie negatywnego wpływu takich zmian na produkt końcowy. I wreszcie koniec! Po zweryfikowaniu integralnoci 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 integralnoci 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 integralnoci 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ęlimy wymienieniem Twoich dokonań na wczeniejszych etapach procesu projektowania. Następnie przeszlimy do wyjanienia, dlaczego warto przeprowadzić jeszcze jednš kontrolę integralnoci danych, po czym powiedzielimy, na co warto zwracać uwagę w trakcie tej kontroli. Na zakończenie opisalimy rolę, jakš pełni dokumentacja gotowej bazy.
sliwak