Bazy danych 2. dr inż. Tadeusz Jeleniewski

Transkrypt

1 Cel - wiedza: Nabycie wiedzy o profesjonalnych metodach i narzędziach projektowania systemów baz danych oraz projektowania aplikacji "bazodanowych" ze szczególnym uwzględnieniem systemów klient/serwer. Cel - umiejętności: Opanowanie wybranej, współczesnej metodyki projektowania baz danych realizacja złożonego, wieloetapowego projektu systemu bazy danych. Nabycie umiejętności posługiwania się profesjonalnym narzędziem do modelowania danych oraz tworzenia aplikacji klienckich oraz dokumentacji. Sposób sprawdzenia: W zakresie wiedzy egzamin z zakresu zagadnień omawianych na wykładzie wraz z elementami z zakresu przedmiotu Bazy danych 1. W zakresie umiejętności wykonanie i udokumentowanie projektu systemu bazy danych. Testowanie umiejętności posługiwania się narzędziami wspomagającymi projektowanie i implementację systemu Bazy danych 2 W1 1

2 Literatura Connoly Th., Begg C. Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania. Wydawnictwo RM, Warszawa, 2004 Celko J. SQL zaawansowane techniki programowania, wyd. Mikom, Warszawa 1999 Beynon Davies P. - Systemy baz danych. WN T, Warszawa 1998 Garcia-Molina H., Ullman J. D., Widom J. Implementacja systemów baz danych WN-T, Warszawa, 2003 Muller R.J. Bazy danych język UML w modelowaniu danych. Wyd. MIKOM, Warszawa 2000 Allen Sh., Modelowanie danych. Wyd. Helion, Bazy danych 2 W1 2

3 Rozproszone systemy baz danych, architektura klient/serwer jako 1 szczególny przypadek rozproszenia 2 Analiza procesowa środowiska systemu, modelowanie reguł przetwarzania i związków encji 3 Model konceptualny i fizyczny bazy danych - wykorzystanie narzędzi CASE (Computer Aided System Engineering), generowanie schematu bazy 4 Mechanizmy dostępu do baz danych, sterowniki ODBC, technologia ADO (Active Data Objects), dostawcy danych 5 Model połączeniowy 6 Model bezpołączeniowy Bazy danych 2 W1 3

4 Wykład 1 rozproszone bazy danych ogólna koncepcja architektury klient serwer procesy tworzenia aplikacji klient serwer trudności przy projektowaniu aplikacji klient serwer Bazy danych 2 W1 4

5 Rozproszony system baz danych - system, w którym występuje rozłożenie danych przez ich fragmentaryzację (podział) lub replikację (powielenie) do różnych konfiguracji sprzętowych i programistycznych. Konfiguracje te są rozmieszczone na ogół w różnych geograficznie miejscach. Rozproszone systemy baz danych są przeciwieństwem systemów lokalnych, tzn. takich, gdzie zarówno dane jak i oprogramowanie SZBD są zlokalizowane w jednym miejscu, np. w tym samym komputerze. Rozproszenie danych - ich fragmentaryzacja lub replikacja dotyczy informacji przechowywanych w systemie. O rozproszeniu można mówić też w odniesieniu do funkcji. Do systemów rozproszonych zalicza się również bazy danych typu klient serwer. W większości tego typu systemów mamy do czynienia z rozproszeniem funkcji, a nie danych Bazy danych 2 W1 5

6 Rozproszoną bazę danych powinny charakteryzować trzy rodzaje "przezroczystości": Przezroczystość geograficzna użytkownicy nie muszą wiedzieć, w którym dokładnie miejscu są przechowywane dane. Przezroczystość fragmentaryzacji użytkownicy nie muszą wiedzieć, w jaki sposób dane są podzielone. Przezroczystość replikacji użytkownicy nie muszą wiedzieć, w jaki sposób dane są powielane Bazy danych 2 W1 6

7 Cele tworzenia rozproszonej bazy danych to: 1. Lokalna autonomia 2. Brak uzależnienia od centralnego miejsca 3. Działanie ciągłe 4. Niezależność od lokalizacji 5. Niezależność od fragmentacji 6. Niezależność od replikacji 7. Rozproszone przetwarzanie zapytania 8. Rozproszone zarządzanie transakcjami 9. Niezależność sprzętowa 10. Niezależność od systemu operacyjnego 11. Niezależność od sieci 12. Niezależność od DBMS Bazy danych 2 W1 7

8 1. Lokalna autonomia Węzły w systemie rozproszonym powinny być autonomiczne. Wszystkie operacje dokonywane w danym miejscu są kontrolowane z tego miejsca. Poprawne działania w węźle X nie powinny zależeć od poprawnego działania innego węzła Y. W przeciwnym razie "zamknięcie" węzła Y z powodu awarii mogłoby spowodować wstrzymanie działania węzła X, chociaż miejsce to jest w zupełnym porządku. Byłaby to oczywiście sytuacja niepożądana. Lokalna autonomia oznacza także, że dane lokalne są zarządzane lokalnie, ich właściciel jest lokalny i lokalnie można je przetworzyć. Wszystkie dane "naprawdę" należą do pewnej lokalnej bazy danych, nawet jeżeli jest ona dostępna z innych, odległych miejsc. Aspekty takie jak bezpieczeństwo, integralność oraz reprezentacja w pamięci trwałej danych lokalnych pozostają pod kontrolą lokalnego węzła Bazy danych 2 W1 8

9 2. Uniezależnienie od centralnego węzła Z lokalnej autonomii wynika, że wszystkie miejsca muszą być traktowane jednakowo. Nie może być zatem żadnego uzależnienia od centralnego, "głównego" miejsca, realizującego centralne usługi np. scentralizowane przetwarzanie żądań, centralne zarządzanie transakcjami czy centralne nadawanie nazw takiego, że cały system zależy od niego. Drugi cel jest więc wnioskiem wynikającym z pierwszego (jeżeli pierwszy będzie osiągnięty, to drugi z tego wyniknie) Bazy danych 2 W1 9

10 3. Działanie ciągłe Systemy rozproszone mają na ogół zwiększoną w porównaniu z systemami "skupionymi" niezawodność i dostępność: Niezawodność prawdopodobieństwo tego, że system działa pomyślnie w dowolnej chwili, jest lepsza, ponieważ systemy rozproszone nie są systemami typu "wszystko albo nic". Mogą one działać (w ograniczonym zakresie), nawet jeśli jakiś pojedynczy składnik (węzeł) ulegnie awarii. Dostępność czyli prawdopodobieństwo tego, że system działa pomyślnie w sposób ciągły przez określony czas, jest także lepsza, częściowo z tego samego powodu, a częściowo dlatego, że istnieje możliwość replikacji powielenia części danych Bazy danych 2 W1 10

11 4. Niezależność od lokalizacji Zasadnicza idea niezależności od lokalizacji (zwanej też przezroczystością lokalizacji) polega na tym, że użytkownicy nie wiedzą, gdzie dane są przechowywane fizycznie, natomiast powinni móc zachowywać się tak jakby wszystkie dane były przechowywane na ich lokalnym stanowisku. Niezależność od lokalizacji jest pożądana, ponieważ upraszcza czynności programów użytkownika i prace z terminalem. W szczególności, umożliwia migrację danych z miejsca na miejsce, nie naruszając tych programów ani czynności terminalowych. Przenoszalność taka umożliwia przesyłanie danych w sieci w odpowiedzi na zmieniające się wymagania wydajności Bazy danych 2 W1 11

12 5. Niezależność od fragmentacji System rozproszony umożliwia fragmentację danych, jeżeli można podzielić daną relację pamiętaną na kawałki czy fragmenty", w celu przechowywania w pamięci fizycznej. Fragmentacja jest wskazana ze względu na wydajność. Dane można przechowywać w tych miejscach, w których są one najczęściej używane. Dzięki temu większość operacji ma charakter lokalny, a ruch w sieci zmniejsza się. 6. Niezależność od replikacji System umożliwia replikację danych, jeżeli zapamiętana relacja lub ogólnie jej fragment może być reprezentowana w wielu różnych kopiach, inaczej replikach, przechowywanych w wielu różnych miejscach Bazy danych 2 W1 12

13 7. Rozproszone przetwarzanie zapytania Załóżmy, że warunki pewnego zapytania spełnia n dostawców. Niech użytkownik systemu znajduje się w miejscu A, zaś dane w węźle B. W systemach rozproszonych optymalizacja wykonania zapytania jest jeszcze ważniejsza niż w scentralizowanych. Wiąże się to z natężeniem ruchu w sieci. W zapytaniach może być wiele wariantów przesyłania danych potrzebnych do wykonania żądania. Bardzo ważne jest zatem znalezienie właściwej strategii. Przykładowo żądanie wykonania sumy relacji Rx przechowywanej w miejscu X i relacji Ry przechowywanej w miejscu Y można zrealizować, przesyłając Rx do Y lub Ry do X bądź też wysyłając obie relacje do trzeciego miejsca Z lub jeszcze inaczej Bazy danych 2 W1 13

14 8. Rozproszone zarządzanie transakcjami Zarządzanie obejmuje kontrolę odtwarzania i kontrolę współbieżności. Każda z nich wymaga specjalnego podejścia w środowisku rozproszonym. W systemie rozproszonym pojedyncza transakcja może wymagać wykonania programu użytkowego w wielu miejscach jednocześnie, w szczególności w wielu miejscach może mieć miejsce aktualizacja. Taka transakcja składa się z kilku agentów, czyli procesów prowadzonych w ramach danej transakcji w określonym miejscu. System musi "wiedzieć", czy dwa takie procesy są częścią tej samej transakcji. Nie można na przykład pozwolić na to, aby dwóch agentów z tej samej transakcji założyło na siebie wzajemną blokadę. Jeśli chcemy zagwarantować, aby dana transakcja w systemie rozproszonym była atomowa (wszystko albo nic), system musi sprawić, żeby wszystkie pojedyncze procesy związane z tą transakcją jednocześnie wykonywały albo jej zatwierdzenie, albo wycofanie. Można to osiągnąć, stosując protokół dwufazowego zatwierdzania. Jeśli chodzi o kontrolę współbieżności, to w większości systemów rozproszonych wykorzystuje się metody blokowania Bazy danych 2 W1 14

15 9. Niezależność sprzętowa Rzeczywiste instalacje komputerowe zwykle zawierają wiele typów maszyn komputery IBM, DEC, HP, PC i różne stacje robocze. Istnieje zatem potrzeba zintegrowania danych przechowywanych w tych wszystkich systemach w jeden obraz. Pożądana jest możliwość korzystania z tego samego DBMS na różnych platformach sprzętowych i zmuszenia ich do partnerskiej współpracy w jednym systemie rozproszonym. 10. Niezależność od systemu operacyjnego Dobrze by było nie tylko móc stosować ten sam DBMS na różnych platformach sprzętowych, ale także w środowiskach rozmaitych systemów operacyjnych. Dotyczy to również różnych systemów operacyjnych na tym samym sprzęcie, np. korzystania z wersji Windows, UNIX-owej i PC/DOS tego samego systemu rozproszonego Bazy danych 2 W1 15

16 11. Niezależność od sieci System powinien wspierać różnorodne węzły, z różnorodnym sprzętem i rozmaitymi systemami operacyjnymi. Współdziałać z różnymi sieciami komputerowymi. 12. Niezależność od SZBD W systemach rozproszonych zrezygnowano z postulatu ścisłej homogeniczności. W rzeczywistości potrzebne jest tylko to, aby instancje SZBD w różnych miejscach umożliwiały korzystanie z tego samego interfejsu. Nie muszą one być kopiami tego samego oprogramowania. Na przykład, jeśli zarówno INGRES jak i ORACLE wspierają oficjalny standard języka SQL, można sobie wyobrazić, że miejsce z INGRESEM komunikuje się z miejscem z bazą ORACLE w środowisku rozproszonym. System rozproszony może być zatem do pewnego stopnia heterogeniczny. Instalacje komputerowe w rzeczywistym świecie nie tylko składają się z różnych maszyn stosujących wiele różnych systemów operacyjnych, ale także bardzo często używają różnych SZBD. Idealny system rozproszony powinien gwarantować niezależność od SZBD Bazy danych 2 W1 16

17 Typy rozproszonych baz danych 1. System typu klient serwer 2. Jednorodna rozproszona baza danych 3. Niejednorodna rozproszona baza danych 4. Federacyjny system baz danych Bazy danych 2 W1 17

18 Ad 1. Najtańsza rozproszona baza danych. W tych systemach rozproszeniu podlegają nie dane a funkcje realizowane przez system. Termin ten odnosi się do lokalnych sieci komputerowych. Co najmniej jeden z komputerów pełni rolę serwera (usługodawcy). Na nim zlokalizowana jest baza danych wraz z oprogramowaniem udostępniającym dane. Pozostałe komputery w sieci to klienci Na nich pracują programy użytkowe, które korzystają z bazy danych. Wykorzystuje się dwa rodzaje serwerów serwery plików lub serwery SQL. W pierwszym przypadku zapytanie klienta wyrażone w języku SQL stanowi dla serwera zapotrzebowanie na odpowiednie pliki niezbędne do wykonania zapytania. W drugim przypadku zapytanie SQL-owe klient wysyła do serwera. Serwer wykonuje zapytanie i w odpowiedzi zwraca klientowi tylko dane wynikowe Bazy danych 2 W1 18

19 Ad 2 Systemy rozproszone mogą zawierać wiele serwerów i działają zwykle na odległych połączeniach. W jednorodnej rozproszonej bazie danych dane są rozłożone pomiędzy dwa lub więcej systemów. Każdy z nich wykorzystuje ten sam rodzaj SZBD i działa na sprzęcie tego samego rodzaju. Ad 3 W niejednorodnym rozproszonym systemie bazy danych konfiguracje sprzętowe i oprogramowanie są różne. Podstawowym sposobem zapewniających uzyskiwanie połączeń jest stosowanie bram (gateway) Ad 4 Federacyjny system bazy danych składa się z pewnej liczby względnie niezależnych autonomicznych baz danych. Często jednak zachodzi potrzeba zebrania niektórych lub wszystkich niezależnych baz w celu wykonania wspólnego zadania Bazy danych 2 W1 19

20 O d d z i a ł O d d z i a ł L A N L A N l o k a l n a b a z a d a n y c h s e r w e r l o k a l n y s e r w e r l o k a l n y l o k a l n a b a z a d a n y c h O d d z i a ł c e n t r a l a p r z e d s i ę b i o r s t w a W A N L A N L A N l o k a l n a b a z a d a n y c h s e r w e r l o k a l n y s e r w e r b a z y d a n y c h s e r w e r l o k a l n y l o k a l n a b a z a d a n y c h c e n t r a l n a b a z a d a n y c h Przykładowa konfiguracja klient serwer w przedsiębiorstwie z oddziałami Bazy danych 2 W1 20

21 Architektura klient serwer [wg Muller R.J.] Bazy danych 2 W1 21

22 System klient -serwer w sieci WWW [wg R.J.Muller] Bazy danych 2 W1 22

23 Partycjonowanie aplikacji klient serwer [R.J.Muller] Bazy danych 2 W1 23

24 Inny przykład architektury rozproszonej [R.J.Muller] Bazy danych 2 W1 24

25 Systemy bazy danych o architekturze klient-serwer (zwane dalej w uproszczeniu systemami klient serwer) są szczególnym przypadkiem systemów rozproszonych, takim że. (a) pewne ich miejsca są miejscami klientów, a inne miejscami serwerów, (b) wszystkie dane znajdują się w miejscach serwerów, (c) wszystkie aplikacje są wykonywane w miejscach klientów oraz widać połączenia (nie ma pełnej niezależności od lokalizacji). [Date, Wprowadzenie do systemów baz danych] Bazy danych 2 W1 25

26 Możliwe są następujące warianty współpracy klienta z serwerem [Date]: 1. Kilku klientów korzysta z tego samego serwera. 2. Pojedynczy klient ma dostęp do kilku serwerów. Są tu dwie możliwości: Klient może mieć dostęp tylko do jednego serwera jednocześnie - każde zapytanie skierowane do bazy wędruje tylko do jednego serwera. Nie można, za pomocą jednego zapytania, zebrać danych z dwóch lub więcej serwerów. W takim przypadku, użytkownik musi wiedzieć, który serwer przechowuje określone dane. Klient może mieć jednoczesny dostęp do wielu serwerów. Pojedyncze zapytanie może zbierać dane z kilku serwerów. Z punktu widzenia użytkownika, zachowują się one jak jeden serwer. Użytkownik nie musi wiedzieć, w jaki sposób dane są rozdzielone pomiędzy serwery Bazy danych 2 W1 26

27 B a z a d a n yc h Z a rz ą d z a n ie d a n ym i Z a rzą d z a n ie re g u ła m i K lie n t O p ro g ra m o w a n ie łą c zą c e K o m u n ik a c ja O p ro g ra m o w a n ie łą c zą c e K o m u n ik a c ja S e r w e r L o g ik a a p lik a c ji L o g ik a p re ze n ta c ji Bazy danych 2 W1 27

28 Części konwencjonalnej aplikacji klient - serwer: 1. Zarządzanie danymi (transakcje, współbieżność, przechowywanie danych, zabezpieczenia). 2. Zarządzanie regułami (wewnętrzne i dodatkowe warunki spójności danych). 3. Logika aplikacji (funkcje, które przekształcają dane i zgłaszają zapotrzebowanie na usługi do serwerów i do innego oprogramowania w węźle klienta. 4. Zarządzanie i logika prezentacji (funkcje, które przyjmują dane i zapotrzebowania od użytkownika oraz przedstawiają dane użytkownikowi; oprogramowanie prezentacji przekształca dane wejściowe użytkownika w postać wymaganą przez serwer oraz przekształca komunikaty z serwera w postać wymaganą przez użytkownika) Bazy danych 2 W1 28

29 Analiza Polega na dokładnym przeanalizowaniu przeznaczenia i funkcji aplikacji. - Rozpoczyna się od sformułowania aplikacji i funkcji, jaką ma w spełniać w środowisku. - Następnie należy określić jakie funkcje musi realizować lub udostępniać użytkownikowi, aby spełniła swoje przeznaczenie. Funkcje definiuje się w kategoriach wymagań operacyjnych, technicznych i funkcjonalnych. - Wymagania operacyjne obejmują procesy, jakie aplikacja ma zrealizować w zadanym przedziale czasu. - Wymagania funkcjonalne określają obecność w programie procedur generujących i prezentujących określone formularze do wprowadzania danych i wyświetlania wyników. Dotyczą one również odpowiednich reguł przetwarzania danych przez projektowaną aplikację Bazy danych 2 W1 29

30 Wymagania techniczne to np. konieczność działania aplikacji pod kontrolą odpowiedniego sieciowego systemu operacyjnego lub konieczność komunikowania się klientów z serwerem za pośrednictwem odpowiedniego protokołu. Definicja głównych funkcji jest punktem wyjścia w modelowaniu procesów. Polega ono na sporządzeniu opisu reguł przetwarzania zasobów i strumieni danych, dzięki którym aplikacja może spełnić stawiane jej wymagania Bazy danych 2 W1 30

31 Projekt Przekształcenie wyników analizy w projekt. Reguły przetwarzania ustalone w pierwszym etapie są przekształcane w logiczne elementy projektu aplikacji i bazy danych. Punkt ciężkości przenosi się z pytania "Co aplikacja ma robić? na "W jaki sposób ma to realizować? Określa się elementy składowe aplikacji i bazy danych, niezbędne do zaimplementowania modelu reguł przetwarzania, który powstał w fazie analizy. Metody przekształcenia modelu w definicję elementów aplikacji i bazy danych obejmują logiczne modelowanie danych oraz diagramy związków i encji. Ostatecznym wynikiem tego etapu są oddzielne projekty każdej z warstw aplikacji w modelu klient serwer Bazy danych 2 W1 31

32 Budowa Coraz częściej stosuje się narzędzia wizualne klasy RAD (Rapid Application Developement), które uwalniają (poza sytuacjami wyjątkowymi) projektanta od żmudnego pisania kodu całego programu. Określenie budowa aplikacji bardziej odpowiada rzeczywistości. Określenie budowa obejmuje w tym przypadku zarówno pisane kodu jak i półautomatyczne generowanie aplikacji. W fazie budowy aplikacji projekt logiczny przekształca się w obiekty fizyczne. Elementy logicznego projektu bazy danych zostają zamienione na rzeczywiste obiekty bazy danych. Projekt aplikacji przygotowany w poprzedniej fazie zmienia się w formularze, kod i inne obiekty programowe. Ostatnie dwa etapy testowanie i instalacja rozpoczynają się już po powstaniu aplikacji. Często wynikiem ich jest powrót do jednego z trzech pierwszych etapów w celu poprawienia wykrytych błędów Bazy danych 2 W1 32

33 Przy projektowaniu wydajnego systemu klient serwer należy zwrócić uwagę na to aby: 1. Umieścić jak najwięcej logiki, w szczególności związanej z prezentacją na komputerze klienta. Pozwala to przyspieszyć współdziałanie z użytkownikiem i zmniejszyć obciążenie serwera. 2. Umieścić sprawdzanie niektórych reguł poprawności na komputerze klienta. Dotyczy to w szczególności reguł poprawności wprowadzanych danych. 3. Zminimalizować ruch w sieci przez ograniczenie liczby i rozmiaru żądań usług serwera. 4. Umieścić sprawdzanie podstawowych reguł poprawności na serwerze, zwłaszcza tych, które są istotne dla całej organizacji lub obszaru jej działania Bazy danych 2 W1 33