#67 CZĘŚĆ II Proces projektowania #69 4. Opis koncepcyjny Nie udaję, że rozumiem wszechświat -jest on o wiele większy ode mnie Thomas Carlyle ====================================== Zrozumienie sposobu funkcjonowania relacyjnej bazy danych nie tylko nie jest tak trudne, jak zrozumienie wszechświata; ale jest nawet o wiele łatwiejsze. Należy jednak przykładać wagę do całościowego ogarnięcia procesu projektowania oraz etapów, z których się on składa. Celem tego rozdziału jest prezentacja podstaw tego procesu. Na potrzeby niniejszego opisu podzieliliśmy wszystkie techniki związane z projektowaniem baz danych na siedem faz, z których każda będzie omawiana osobno. Prezentacja ta powinna dać dobre wyobrażenie o całości procesu projektowania i sądzę, że przyczyni się również do lepszego zrozumienia każdej z technik opisywanych w rozdziałach 5-13. Uwaga: Baza danych może być projektowana przez pojedynczą osobę lub przez całą grupę. Od tego momentu terminem „twórca bazy danych" będziemy określać każdą osobę zaangażowaną w projektowanie bazy. Dlaczego należy przejść przez całość procesu projektowania Przede wszystkim chciałbym mocno podkreślić wagę przechodzenia przez wszystkie etapy procesu projektowania. Wielu ludzi pyta mnie, czy rzeczywiście trzeba angażować się po kolei we wszystkie jego fazy. Moją odpowiedzią jest zawsze zdecydowane „tak!". Wówczas zadają mi pytanie, czy jest to konieczne nawet dla osoby projektującej „prostą" bazę danych. („Prosty" jest jednym z najniebezpieczniejszych słów w słowniku twórcy bazy danych. Mc nigdy nie jest „proste"). Ponownie #70 odpowiadam: „Tak! Jest to konieczne!". Typ, wielkość czy funkcja bazy danych jest bez znaczenia dla procesu projektowania, który zawsze powinien być przeprowadzony od początku do końca. Jak już pokazaliśmy - a pokażemy to jeszcze nieraz - bez ścisłego trzymania się reguł dobrego projektowania tworzenie bazy danych jest bardzo złym pomysłem. Wiele problemów związanych z istniejącymi bazami danych jest bezpośrednią konsekwencją złego projektu logicznego. Częściowe zastosowanie właściwych zasad jest warte tyle samo, co niestosowanie ich w ogóle. Niekompletny projekt to zły projekt. Tylko spełnienie wszystkich wymagań związanych z tworzeniem poprawnego projektu bazy gwarantuje jej sprawną strukturę i dokładność przechowywanych w niej danych. Należy zdać sobie sprawę z tego, iż stopień strukturalnej integralności bazy danych oraz integralności samych danych w niej przechowywanych jest prostą pochodną stopnia zaangażowania w tworzenie projektu. Im mniej czasu spędzisz na projektowaniu struktury bazy, tym większe ryzyko wystąpienia problemów w trakcie jej eksploatacji. Ścisłe trzymanie się reguł projektowania nie wyeliminuje wszystkich trudności, z jakimi możesz się zetknąć; z pewnością jednak znacznie ograniczy ich ilość. Co więcej, zaimplementowanie dobrze obmyślonej bazy danych w programie SZRBD jest prostsze niż implementacja złego projektu. Bazy danych nie są trudne w tworzeniu; trzeba im po prostu poświęcić nieco czasu. Nawet jeśli wydaje Ci się, że dany etap trwa zbyt długo, nie idź na skróty - bądź cierpliwy i pamiętaj, co powiedział kiedyś pewien mądry człowiek: "Nigdy nie ma czasu na zrobienie czegoś porządnie, ale zawsze jest czas na zrobienie tego od nowa". Formułowanie definicji celu i założeń wstępnych Pierwszą fazą tworzenia projektu bazy danych jest sformułowanie definicji celu oraz założeń wstępnych. Definicja celu mówi, po co projektujemy bazę danych, oraz stanowi punkt odniesienia dla jej twórcy. Każda baza danych jest konstruowana w jakimś celu - czy to do rozwiązania konkretnego problemu, czy do codziennej obsługi jakiejś organizacji lub firmy, czy też jako część systemu informacyjnego. Określając cel, jakiemu ma służyć Twoja baza, ułatwisz sobie stworzenie właściwego projektu i umożliwisz przechowywanie w gotowej bazie właściwych danych. Oprócz definicji celu na tym etapie należy również sformułować założenia wstępne. Są to wymagania, jakie powinny spełniać dane przechowywane w bazie. Warunki te powinny uzupełniać definicję celu i pomagać w tworzeniu poszczególnych elementów bazy danych. #71 Istnieją dwie oddzielne grupy ludzi, którzy mają wpływ na definicje celu i założeń wstępnych. Pierwsza z nich, składająca się z twórcy bazy danych, właściciela lub dyrektora organizacji, której baza ta ma służyć, oraz członków kierownictwa tejże organizacji, jest odpowiedzialna za definicje celu. Druga, złożona z twórcy bazy, kierownictwa organizacji oraz przyszłych użytkowników bazy, powinna zająć się sformułowaniem założeń wstępnych. Analiza istniejącej bazy danych Drugą fazą procesu projektowania jest analiza istniejącej bazy danych, jeśli takowa istnieje. W zależności od organizacji, będzie to zazwyczaj baza spadkowa lub baza tradycyjna. Stara baza danych, użytkowana od wielu lat, to baza spadkowa (czasem nazywana bazą odziedziczoną). Z kolei baza tradycyjna to luźny zbiór formularzy, teczek, notatek i tym podobnych. Niezależnie od typu i stanu istniejącej bazy danych, dokładne przyjrzenie się jej strukturze udzieli cennych informacji na temat sposobu wykorzystywania danych przez organizację. Co więcej, analiza ta pozwoli na zrozumienie sposobu, w jaki dane są gromadzone i prezentowane użytkownikom. Jako twórca nowej bazy danych powinieneś przyjrzeć się roli pełnionej przez papier w gromadzeniu danych (formularze) oraz ich prezentacji (raporty). Analogicznie, jeśli organizacja wykorzystuje już jakieś oprogramowanie komputerowe, należy przestudiować jego działanie oraz metody przetwarzania przez nie danych. Kolejnym elementem analizy jest przeprowadzenie wywiadów z użytkownikami i kierownictwem w celu ustalenia sposobu, w jaki istniejąca baza jest wykorzystywana w codziennym funkcjonowaniu danej organizacji. Jako projektant powinieneś spytać użytkowników o sposoby korzystania z obecnej bazy oraz o ich aktualne wymagania informacyjne. Następnie powinieneś przeprowadzić dyskusję z członkami kierownictwa i określić, do jakich informacji mają obecnie dostęp oraz jakie są ogólne potrzeby informacyjne ich organizacji. Teraz jesteś już gotowy do utworzenia listy pól i usług, jakie będą musiały być udostępniane przez bazę danych. Lista ta powinna zawierać podstawowe wymagania informacyjne analizowanej organizacji i stanowić punkt wyjścia do stworzenia projektu logicznego bazy. Można oczekiwać, że jej zawartość będzie się stopniowo powiększać w miarę konstruowania tego projektu. Po sporządzeniu listy usług, należy ją przedstawić użytkownikom i kierownictwu do ewentualnej korekty. Pamiętaj o uważnym rozpatrywaniu wszelkich sugestii dotyczących jej modyfikacji. Jeśli uważasz daną propozycję za rozsądną i dobrze umotywowaną, wówczas wprowadzasz odpowiednie poprawki, uaktualniasz swoją listę i przechodzisz do następnego etapu. #72 Tworzenie struktur danych Tworzenie struktur danych jest trzecim etapem procesu projektowania bazy. Należy zdefiniować tabele i pola, wskazać pola kluczowe oraz określić atrybuty każdego z pól. Tabele są pierwszą strukturą, jaką powinieneś się zająć. Tematy, którym mają one być poświęcone, wynikają z założeń wstępnych, zdefiniowanych w pierwszej fazie procesu projektowania, oraz z wymagań informacyjnych, ustalonych w fazie drugiej. Po ustaleniu odpowiednich tematów, należy dla każdego z nich utworzyć tabele, a następnie przypisać wszystkie pola z listy sporządzonej pod koniec ostatniego etapu do odpowiednich tabel. Po zakończeniu tej czynności trzeba przeanalizować każdą tabele i upewnić się, że reprezentuje ona tylko jeden temat i nie zawiera powtarzających się pól. Trzeba teraz przyjrzeć się każdemu polu z osobna. Jeśli stwierdzisz, że któreś z nich jest wielowartościowe lub segmentowe, trzeba je rozbić tak, aby wszystkie pola w tabeli zawierały pojedyncze wartości. Pole nie reprezentujące tematu danej tabeli powinno zostać przesunięte do innej, bardziej odpowiedniej tabeli lub zostać usunięte z bazy. Na koniec należy zdefiniować klucze podstawowe, które będą jednoznacznie identyfikować każdy rekord w poszczególnych tabelach. Ostatnim krokiem tego etapu jest definiowanie atrybutów dla każdego pola w bazie danych. Należy powtórnie przeprowadzić rozmowy z pracownikami i kierownictwem organizacji w celu ustalenia odpowiednich atrybutów dla poszczególnych pól. Powinieneś też przedyskutować z użytkownikami wszystkie te cechy nowej bazy, które nie są im jeszcze znane. Po zakończeniu tej procedury trzeba zdefiniować i udokumentować atrybuty każdego pola. Następnie powinieneś zwrócić się do pracowników i kierownictwa z prośbą o zgłoszenie ewentualnych poprawek. Po ich wprowadzeniu baza będzie gotowa do następnej fazy. Definiowanie relacji W czwartej fazie procesu projektowania należy zdefiniować relacje między poszczególnymi tabelami. Znowu więc trzeba przeprowadzić rozmowy z użytkownikami bazy, określić istniejące relacje, ustalić ich cechy oraz zagwarantować integralność na poziomie relacji. Współpraca użytkowników przy określaniu relacji jest niesłychanie pomocna, ponieważ najprawdopodobniej nie są Ci znane wszystkie aspekty funkcjonowania danej organizacji. Większość jej pracowników ma jednak dobre wyobrażenie o danych, na których operuje, i może z łatwością wskazać ewentualne relacje. Kiedy relacje zostaną już ustalone, należy określić ich cechy. W zależności od typu danej relacji wchodzące w jej skład tabele trzeba połączyć, korzystając albo #73 z klucza podstawowego, albo z tabeli łączącej. Następnie powinieneś zdefiniować typ i stopień uczestnictwa tabel w poszczególnych relacjach; w większości przypadków cechy te będą w prosty sposób wynikać z rodzaju danych przechowywanych w każdej z tych tabel, czasami jednak trzeba będzie odwołać się do reguł integralności. Wprowadzanie reguł integralności Wprowadzanie reguł inte...
sliwak