#27 CZĘĆ I Projektowanie relacyjnej bazy danych #29 1. Czym jest relacyjna baza danych? Ryba pływa trzy razy - w wodzie, w male i w winie - Przysłowie polskie Typy baz danych Użytkowane dzi bazy danych można podzielić, ze względu na sposób zarzšdzania nimi, na dwa rodzaje: operacyjne bazy danych i analityczne bazy danych. Bazy operacyjne znajdujš zastosowanie w codziennym funkcjonowaniu różnorodnych organizacji, instytucji i firm. Sš wykorzystywane tam, gdzie zachodzi potrzeba gromadzenia, przechowywania i modyfikowania danych. Ten typ bazy przechowuje dane dynamiczne, czyli takie, które ulegajš cišgłym zmianom i odzwierciedlajš aktualny stan jakiego obiektu. Przykładami baz operacyjnych sš bazy inwentaryzacyjne, bazy obsługi zamówień, bazy informacji o pacjentach czy bazy prenumeratorów czasopism. Analityczne bazy danych sš wykorzystywane do przechowywania danych historycznych i informacji zwišzanych z pewnymi wydarzeniami. Kiedy dana firma lub organizacja chce przeanalizować tendencje rynkowe, uzyskać dostęp do długoterminowych danych statystycznych lub poczynić prognozy na przyszłoć, sięga do analitycznej bazy danych. Dane w bazie analitycznej sš statyczne, co oznacza, że bardzo rzadko (jeli w ogóle) ulegajš zmianom i zawsze odzwierciedlajš stan obiektów z pewnego ustalonego momentu (nie stan obecny). Przykłady analitycznych baz danych to bazy testów chemicznych, próbek geologicznych czy danych pomiarowych. Wczesne modele baz danych Zanim pojawił się relacyjny model logiczny, do przechowywania i modyfikowania danych wykorzystywano dwa wczeniejsze modele: model hierarchiczny i model sieciowy. #30 ================================ Uwaga: Pomimo iż szczegółowy opis tych dwóch modeli wykracza poza zakres materiału tej ksišżki, chciałbym pokrótce omówić każdy z nich. W moim omówieniu zawarłem informacje o zakładanej przez dany model strukturze danych i metodach dostępu do nich, sposobie reprezentowania relacji między tabelami oraz o wadach i zaletach tego modelu. ================================= Hierarchiczny model logiczny W hierarchicznym modelu bazy danych (czasem okrelanego skrótem HMBD) dane majš strukturę, którš można najprociej opisać jako odwrócone drzewo. Jedna z tabel pełni rolę korzenia" drzewa, a pozostałe majš postać gałęzi" bioršcych swój poczštek w korzeniu. Rysunek 1.1 ukazuje diagram struktury HMBD. [porednicy]-->[muzycy]-->[terminarz] druga -->od [porednicy]-->[klienci]-->[umowy] druga -->od [klienci]-->[rozliczenia] Rysunek 1.1. Diagram modelu hierarchicznego Baza danych poredników. W przykładzie z rysunku 1.1 każdy porednik pracuje dla kilku muzyków i ma pewnš liczbę klientów, którzy zamawiajš u niego obsługę muzycznš różnych imprez. Klient zawiera umowę z danym muzykiem przez porednika i u tego włanie porednika uiszcza należnoć za usługę. Relacje w HMBD sš reprezentowane w kategoriach ojciec/syn. Oznacza to że tabela-ojciec może być powišzana z wieloma tabelami-synami, lecz pojedynczy syn może mieć tylko jednego ojca. Tabele te mogš być powišzane jawnie, przez wskaniki, lub przez fizycznš organizację rekordów wewnštrz tabel. Aby uzyskać dostęp do danych w modelu hierarchicznym, użytkownik zaczyna od korzenia i przedziera się przez całe drzewo danych, aż do interesujšcego go miejsca. Oznacza to jednak, że użytkownik musi dobrze znać strukturę bazy danych. Jednš z zalet tego rodzaju bazy jest to, że potrzebne dane można szybko przywołać, ponieważ poszczególne tabele sš ze sobš bezporednio powišzane. Innš zaletš #31 jest to, że majš one automatycznie wbudowanš integralnoć odwołań. Oznacza to, że rekord w tabeli-synu musi być powišzany z istniejšcym rekordem w tabeli-ojcu. Jeli jeden z rekordów w tabeli-ojcu zostanie skasowany, wówczas skasowaniu ulegnš również wszystkie powišzane z nim rekordy w tabelach-synach. Jeżeli jednak musimy zapisać w tabeli-synu rekord, który nie byłby powišzany z żadnym z rekordów w tabeli-ojcu, wówczas powstaje problem. W przykładzie z rysunku 1.1 nie możemy dopisać do tabeli muzyków nowej osoby, dopóki nie przypiszemy jej porednika w tabeli poredników. Często jednak występuje sytuacja, w której muzyk zapisuje się do agencji poredniczšcej zanim zostanie mu przydzielony konkretny porednik. Taki scenariusz jest trudny do spełnienia w modelu HMBD. Można jednak nagišć zasady, nie łamišc ich jednak, jeli wpiszemy do tabeli poredników sztuczne" dane. Takie rozwišzanie nie jest jednak optymalne. Nadmiarowe dane stanowiš kolejny problem modelu HMBD, ponieważ model ten jest niezdolny do obsługi złożonych relacji. W przykładzie z rysunku 1.1 między klientami i muzykami istnieje relacja wiele-do-wielu: jeden muzyk gra dla wielu klientów, a jeden klient może zatrudniać wielu muzyków. Ponieważ taki rodzaj relacji nie może zostać bezporednio wpisany w model HMBD, zachodzi koniecznoć wprowadzenia nadmiarowych danych do tabel terminarzy i umów. Tabela terminarzy będzie zawierać dane o klientach (takich np. jak: imię, nazwisko, adres oraz numer telefonu), informujšce o miejscu występu danego muzyka, lecz dane te pojawiajš się również (a może przede wszystkim) w tabeli klientów. Ponadto tabela terminarzy będzie zawierać dane o muzykach (na przykład: imię, nazwisko, telefon i gatunek muzyki), mówišce nam, którzy muzycy grajš dla danego klienta. Te same dane znajdujš się (poniekšd słusznie) w tabeli muzyków. Ta nadmiarowoć tworzy możliwoć sytuacji, w których pewne dane zostajš wprowadzone w sposób niekonsekwentny, co z kolei zaburza integralnoć bazy. Problem można obejć przez utworzenie osobnej hierarchicznej bazy danych dla muzyków i drugiej - dla poredników. Nowa baza muzyków będzie składać się jedynie z tabeli muzyków, natomiast baza poredników będzie zawierać tabele poredników, klientów, rozliczeń i umów. Tabela terminarzy nie jest już potrzebna, ponieważ można zdefiniować logicznš relację ojciec-syn między tabelš umów w bazie poredników oraz tabelš muzyków w bazie muzyków. Po wprowadzeniu takiej relacji z bazy będzie można wyczytać informacje takie jak: lista muzyków, z którymi zawarł umowy dany klient, czy terminarz występów danego muzyka. Metoda ta spełnia swoje zadanie, jeli jš zastosujemy. Twórca bazy danych musi jednak być pewien koniecznoci uwzględnienia takiej relacji. W tym wypadku była ona doć oczywista, lecz wiele relacji jest znacznie bardziej skomplikowanych i potrzeba ich wprowadzenia może zostać zauważona dopiero w bardzo pónych stadiach procesu projektowania lub też - o zgrozo - po oddaniu bazy do użytku. #32 Baza danych muzyków - [Muzycy]--->logiczna relacja ojciec-syn--->do [umowy] z B.d.p. Baza danych poredników - [Porednicy]--->[klienci]--->(dwie strzałki- pierwsza do)--->[umowy] --->(druga do)--->[rozliczenia] Rysunek 1.2. Wykorzystanie dwóch hierarchicznych baz danych do rozwišzania problemu relacji wiele-do-wielu Hierarchiczny model bazy danych był z powodzeniem stosowany w systemach zapisu tamowego, wykorzystywanych w komputerach typu mainframe do pónych lat siedemdziesištych, i zdobył dużš popularnoć w firmach polegajšcych na tych systemach. A jednak, pomimo tego, iż HMBD zapewniał szybki, bezporedni dostęp do danych i znajdował zastosowanie w rozwišzywaniu wielu problemów, powoli narastała potrzeba wprowadzenia nowego modelu, który nie wymagałby wprowadzania takiej iloci nadmiarowych danych i złożonych relacji. Sieciowy model logiczny Sieciowy model bazy danych (odtšd będziemy go nazywać SMBD) został stworzony głównie w celu rozwišzania problemów zwišzanych z modelem hierarchicznym. Tak jak w HMBD, strukturę SMBD można sobie wyobrazić jako odwrócone drzewo. Różnica polega jednak na tym, że w przypadku SMBD kilka drzew może dzielić ze sobš gałęzie, a każde drzewo stanowi częć ogólnej struktury bazy danych. Na rysunku 1.3 widać diagram modelu sieciowego. Baza danych poredników. W przykładzie z rysunku 1.3 każdy porednik pracuje dla kilku muzyków i ma pewnš liczbę klientów, którzy zamawiajš u niego obsługę muzycznš różnych imprez i uiszczajš opłaty. Każdy muzyk może zawrzeć wiele oddzielnych umów i specjalizować się w wielu różnych gatunkach muzyki. #33 Baza danych poredników (między strzałkami-opis z ksišżki; w nawiasach- opis mój) [porednicy]-->reprezentuje--->[klienci]-->uiszcza-->[rozliczenia] ---> druga strzałka od --->[klienci] do-->zawiera--> [umowy] druga -->od [porednicy]do-->kieruje-->[muzycy]-->wypełnia-->[umowy](wspólna częć) druga -->od [muzycy]do-->gra-->[style muzyczne] Rysunek 1.3. Diagram modelu sieciowego Relacje w SMBD sš definiowane przez kolekcje (ang. set structures). Kolekcja jest niejawnš konstrukcjš łšczšcš dwie tabele przez przypisanie jednej z nich roli właciciela, a drugiej - roli członka. (Stanowiło to znaczny postęp w porównaniu z relacjami ojciec--syn). Kolekcje umożliwiajš wprowadzanie relacji jeden-do-wielu, co oznacza, że w obrębie danej struktury każdy rekord z tabeli-właciciela może być powišzany z dowolnš ilociš rekordów tabeli-członka, lecz pojedynczemu rekordowi w tabeli-członku może odpowiadać tylko jeden rekord w tabeli-włacicielu. Ponadto każdy rekord w tabeli-członku musi być powišzany z istniejšcym rekordem w tabeli-włacicielu. Przykładowo, każdy klient musi mieć przyporzšdkowanego porednika, choć mogš istnieć porednicy nie obsługujšcy żadnych klientów. Rysunek l .4 przedstawia typowš strukturę kolekcji. Między każdymi dwoma tabelami można zdefiniować dowolnš liczbę powišzań (kolekcji), a każda tabela może uczestniczyć w wielu różnych kolekcjach. Przykładowo, na rysunku 1.3 tabela klientów jest powišzana z tabelš opłat przez kolekcję uiszcza oraz z tabelš umów przez kolekcję zawiera. Tabela umów, oprócz tabeli klientów, jest powišzan...
sliwak