ullman012 (2)

o I DZIEDZINA SYSTEMÓW RAZ DANYCH

urządzania zapytaniami musi określić dla tego zapytania plan, którego wywianie doprowadzi do utworzenia poprawnej odpowiedzi. Im mniej jest kro-ów w trakcie tworzenia odpowiedzi, tym plan jest lepszy. W zasadzie kosz->wne są te operacje, które prowadzą do kopiowania bloków dysku do parnię-i lub kopiowania stron pamięci operacyjnej na dysk, angażujące moduł zasądzania pamięcią. V. tego powodu wdarto przy określaniu kosztu planu zapy-tnia brać pod uwagę tylko operacje przesyłania danych miedzy pamięciami peracyjną a pomocniczą.

Utworzenie odpowiedzi wymaga przeszukania relacji Klienci w celu Znalezienia numeru polisy należącej do Anny Nowak (zakładamy, że w bazie ystępuje tylko jedna klientka o takim nazw isku, jednak w' praktyce może ich yć więcej). Potem trzeba przeszukać relację Konta i odnaleźć wszystkie konta właściwym numerze polisy, a następnie wydrukować bilanse z tych kont.

Prosty, ale kosztowny plan polega na przejrzeniu wszystkich krotek Yierszy) relacji Klienci, aż do odnalezienia tej, zawierającej nazwisko nna Nowak. Średni koszt takiej operacji wymaga przejrzenia połowy krotek mim napotkamy właściwą. Ponieważ bank ma wielu klientów, więc tabela iienci zajmuje dużo bloków dysku i koszt będzie wysoki. A odnalezienie Limeru polisy Anny Nowak nie kończy zadania. Teraz trzeba przeglądać rolki relacji Kon-.a i wybrać te wszystkie, w których występuje znaleziony przednio numer polisy. W typowym banku jest wicie kont. a zatem relacja onta również musi zajmować wiele bloków dysku. Sprawdzenie ich szystkich musi też. być kosztowne.

Jeżeli jednak został założony indeks dla relacji Klienci na atrybucie izwiska, to istnieje lepszy plan. Zamiast przeszukiwać całą relację Klienci corzystamy z indeksu, który wskaże blok, zawierający krotkę właściwą dla nny Nowak. Jak już wspomniano w p. 1.2.1, odnalezienie w łaściwego bloku i pomocą typowego indeksu, zbudowanego jako B-drzewo, wymaga przej-:enia trzech bloków indeksu’. Jeszcze jeden dostęp do dysku pozwala otrzy-ać krotkę odpow jadającą Annie Nowak.

Oczywiście nadal pozostaje do zrobienia drugi krok: znalezienie kont odpowiednim numerem polisy w relacji Konto. Zazwyczaj wymaga to wie-•krotnego dostępu do dysku. Jeśli jednak dla relacji Konta założono indeks t atrybucie numer polisy, to możemy według tego indeksu przeszukiwać tylko bloki, w których występują poszukiwane krotki, zawierające odnaleziony przednio numer polisy. Trzeba wówczas wykonać 2 lub 3 operacje dyskowe, •zcglądając indeks, podobnie jak w przypadku indeksowanego dostępu do laeji KI i enci. Jeśli wszystkie potrzebne krotki są w różnych blokach dysku,

' trzeba dostać się do każdego z tych bloków-. Ale prawdopodobnie jedna oso-

w rzeczywistości ponieważ kaz.de przeszukania B-drzcwa wymaga przejrzenia korze¹ a, więc ten blok przeważnie jesi na slałc w pamięci operacyjnej, zajmując jedną stronę pa-lęci. Siad tez tak naprawdę skorzystanie z lego rodzaju indeksu wymaga zazwyczaj tylko kóch operacji dostępu do dysku.

ba nic ma zbyt wielu kont, więc całe działanie sprowadzi się pewnie do niewielu operacji dyskowych. Jeśli zostały założone oba indeksy, to można utworzyć odpowiedź na zapytanie, angażując w to od 6 do 10 operacji dostępu. Jeśli któryś z nich, albo żaden, nie istnieje i musimy korzystać z gorszych planów zapytań, to operacji dostępu do dysku może być potrzebnych setki, a nawet tysiące, ponieważ trzeba sprawdzać wówczas całą, obszerną relac ję.

□

Na podstawie przykładu 1.2 można odnieść wrażenie, żc optymalizacja zapytań polega wyłącznie na korzystaniu z indeksów, o ile takie istnieją. Jednak w rzeczywistości takie procedury są dużo bardziej złożone. Skomplikowane zapytanie umożliwia na przykład zmianę kolejności wykonywania operacji, co z kolei stwarza możliwość utworzenia wielu planów wykonania takiego zapytania, ich liczba może rosnąć w stosunku do wielkości zapytania nawet wykładniczo. Często mamy do wy boru dw^ra indeksy i trzeba wybrać który ś z nich. Rozwiązania na temat implementacji lego ważnego elementu DBMS są jednak już poza zakresem naszej książki

1.2.4. Moduł zarządzania transakcjami

Jak już wspomnieliśmy w podrozdziale 1.1, DBMS musi wykonanie niektórych operacji na bazie danych objąć specjalnymi gwarancjami. Stwierdziliśmy wówczas, że wynik pewnych operacji nie może zaginąć, nawet u przypadku awarii systemu. Typowy DBMS stwarza użytkownikowi sposobność łączenia jednego lub więcej zapytań, bądź modyfikacji, w transakcję, która stanowi nieformalną grupę operacji przeznaczonych do wykonania razem w jednym ciągu, jako duża operacja jednostkowa.

Często system baz danych umożliwia jednoczesne przetwarzanie transakcji, na przykład coś się może dziać jednocześnie na wielu bankomatach. Poprawność i kompletność przeprowadzenia wszystkich transakcji gwarantuje w systemie DBMS moduł zarządzania transakcjami. „Poprawność” przeprowadzenia transakcji bardziej szczegółowo opisują poniższe właściwości, inicjały ich angielskich nazw tworzą słowo AC1D. A oto te właściwości: ¹

1

   Niepodzielność (atomicity). Żądamy, aby albo cała transakcja została przeprowadzona, albo wcale - żaden z jej elementów- nie zostanie uwzględniony. Na przykład podjęcie pieniędzy z bankomatu i powiązany z tym zapis wypłaty na koncie klienta muszą stanowić jedną niepodzielną transakcję. Nie można zaakceptować wypłaty pieniędzy i niczapisania tego faktu na koncie klienta, nie można również zgodzić się na to. by zapisać wypłatę, a nie wypłacić pieniędzy.

•    Spójność (consistency). Baza danych musi stwarzać warunki spójności, dane muszą zaspakajać nasze oczekiwania. Na przykład jeden