Bazy danych 1. Pojęcia podstawowe

Transkrypt

1 Bazy danych 1. Pojęcia podstawowe P. F. Góra /18

2 Baza danych: Duża kolekcja danych, odpowiednio zorganizowana w celu szybkiego przeszukiwania i dostępu do informacji, uzyskiwanego przy pomocy komputera. Copyright c P. F. Góra 1 2

3 Patron? Św. Izydor z Sewilli (VI wiek), patron Internetu, stworzył pierwszy katalog Copyright c P. F. Góra 1 3

4 Bazy danych sa wszechobecne! użytkownicy projektanci/programiści aplikacji bazodanowych projektanci/programiści baz danych, administratorzy baz danych projektanci/programiści systemów bazodanowych (DataBase Management System, DBMS) Cel wykładu: Projektowanie i programowanie baz danych Widza tylko front end Błędnie nazywanych bazami danych Copyright c P. F. Góra 1 4

5 Architektura klient-serwer lasagna code: aplikacja bazodanowa system operacyjny klient? business logic sieć serwer Czy logikę biznesowa umieszczać po stronie serwera czy po stronie aplikacji? Copyright c P. F. Góra 1 5

6 Architektura klient-serwer (cd) sytemy wielodostępne, heterogeniczne najbardziej kosztowna operacja: przesyłanie danych wiele operacji wykonywanych po stronie serwera Logika biznesowa raczej po stronie serwera struktura bazy (schemat) i więzy umieszczone bezpośrednio w bazie, nie w aplikacji Copyright c P. F. Góra 1 6

7 Schemat i instancja Baza danych to, w pewnym sensie, abstrakcyjny model systemu o określonym schemacie. Schemat bazy danych zawiera informację o tableach (lub innych obiektach) w bazie, kolumnach, typach danych, indeksach, wzajemnych powiazaniach pomiędzy tabelami, a także o użytkownikach, ich uprawnieniach itd itd. Konkretne wystapienie bazy danych, wraz konkretna (chwilowa!) zawartościa danych, nazywa się instancja. Każda instancja musi być fizycznie zlokalizowana na jakimś sprzęcie. Co zrobić, gdy zaczyna brakować miejsca, mocy obliczeniowej i innych zasobów? Copyright c P. F. Góra 1 7

8 Skalowanie Gdy brakuje zasobów, skalujemy nasz system bazodanowy: rozbudowujemy serwer lub dodajemy nowe serwery. Copyright c P. F. Góra 1 8

9 Skalowanie pionowe Skalowanie pionowe (vertical scaling, scaling up) polega na dokładaniu zasobów (pamięci, przestrzeni dyskowej, procesorów, portów komunikacyjnych etc) do istniejacego serwera. Copyright c P. F. Góra 1 9

10 Skalowanie pionowe Zalety Wady mniejsze zużycie mocy awaria unieruchamia cała bazę mniejszy koszt chłodzenia ograniczenia fizyczne mniejsza zajętość serwerowni prawo malejacych przychodów mniejsze koszta licencyjne duże serwery sa bardzo drogie nie wymaga dodatkowego sprzętu sieciowego nie ma spowolnień w celu zapewnienia spójności danych Copyright c P. F. Góra 1 10

11 Prawo Amdahla Jeśli mamy jeden procesor, dołożenie drugiego da nam większy zysk, niż dołożenie setnego procesora do 99 istniejacych. Niech α oznacza część operacji, które musza być wykonywane sekwencyjnie. 1 α jest częścia operacji, która można zrównoleglić. Wówczas jeśli mamy P procesorów, prawo Amdahla głosi, że osiagniemy przyspieszenie równe S = 1 α + 1 α P Copyright c P. F. Góra 1 11

12 Przypadki graniczne: α = 0 (wszystko da się zrównoleglić): S = P. Dla α > 0 lim P S = 1 α Prawo Amdahla jest szczególnym przypadkiem prawa malejacych przychodów (the law of diminishing returns). W pewnym momencie zwiększanie zasobów jedynego serwera przestaje się opłacać. Copyright c P. F. Góra 1 12

13 Skalowanie poziome Skalowanie poziome (horizontal scaling, scaling out) polega na dokładaniu serwerów, które przechowuja kopie bazy danych i obsługuja część ruchu. Copyright c P. F. Góra 1 13

14 Skalowanie poziome Zalety Wady awaria jednego serwera większe zużycie mocy nie unieruchamia całej bazy większy koszt chłodzenia łatwiej dokładać serwery większa zajętość serwerowni łatwiej usuwać serwery większe opłaty licencyjne na ogół tańsze od skalowania pionowego wymagane więcej sprzętu sieciowego (duże serwery sa bardzo drorgie) nierównomierne obciażenie serwerów (fragmentacja) spowolnienia dla zapewnienia spójności danych Copyright c P. F. Góra 1 14

15 W praktyce decyzja o wyborze skalowania bywa trudna. Zależy od charakteru bazy, liczby klientów jednocześnie komunikujacych się z baza, a nawet od (typowej) zawartości bazy (instancji bazy), posiadanego budżetu itp. Źródło: Copyright c P. F. Góra 1 15

16 Zasadniczy podział Bazy relacyjne 80% rynku Bazdy danych relacyjne NoSQL Not only SQL Bazy NoSQL największe firmy technologiczne (Amazon, Facebook) plus 95% aplikacji wytwarzanych przez niczego nieświadomych programistów Copyright c P. F. Góra 1 16

17 Relacyjne bazy danych Oparte o mocne matematyczne podstawy Wymagaja dobrego (kosztownego, czasochłonnego, przemyślanego) zaprojektowania Instytucje rzadowe, banki, duże firmy (tradycyjne) Chronia przed wieloma błędami Zapewniaja bezpieczeństwo danych Zapewniaja stała spójność danych pomiędzy serwerami... i generuja wynikajace z tego opóźnienia Możliwy bardzo długi czas życia Kłopot, gdy dane nie pasuja do schematu Moga obsługiwać setki, a nawet tysiace jednoczesnych użytkowników Copyright c P. F. Góra 1 17

18 Bazy NoSQL Luźniejsze, gorzej zdefiniowane podstawy Nie wymagaja dokładnego projektowania Największe firmy nowych technologii plus większość małych firm nowych technologii Większa odpowiedzialność spoczywa na programiście Mnóstwo oprogramowania samo generuje takie bazy Nie musza zapewniać stałej spójności danych pomiędzy serwerami... zapewniajac lepsza dostępność, kosztem niejednoznacznych odczytów Typowo raczej krótki czas życia Znacznie bardziej elastyczne przy zróżnicowanych danych Pomyślane do obsługiwania dziesiatek i setek tysięcy jednoczesnych użytkowników Copyright c P. F. Góra 1 18

19 Cykl życia projektu informatycznego Analiza Modelowanie Implementacja Wdrożenie Utrzymanie Copyright c P. F. Góra 1 19

20 Baza danych jako model rzeczywistości Baza danych jest modelem rzeczywistości ma odpowiadać potrzebom użytkownika, nie wyobrażeniom projektanta Złamanie tej zasady to typowy (i bolesny) bład popełniany przy projektowaniu baz danych. Uzyskanie informacji od klienta czego im naprawdę trzeba bywa nie lada wyzwaniem Copyright c P. F. Góra 1 20

21 W Dolinie Krzemowej panuje systemowy brak odpowiedzialności. Zakorzeniony jest w chorobliwej wśród programistów pewności, że rozumieja co jest najlepsze dla świata, podczas gdy w rzeczywistości sa naiwni i nie maja nawet pojęcia, jaki jest skomplikowany. Zeynep Tűfekçi Copyright c P. F. Góra 1 21

22 Programming is Forgetting Źródło: Allison Parrish, Programming is Forgetting Copyright c P. F. Góra 1 22

23 Przykład mysql> CREATE TABLE Studenci -> (NrStudenta SMALLINT UNSIGNED NOT NUll AUTO_INCREMENT PRIMARY KEY, -> Imie VARCHAR(20), -> Nazwisko VARCHAR(20) NOT NULL, -> Uwagi VARCHAR(30), -> Grupa CHAR(2) NOT NULL); Query OK, 0 rows affected (0.06 sec) Projektowanie bazy danych (a w pewnym sensie każdego innego oprogramowania) łaczy się z odrzucaniem wielu informacji o świecie zewnętrznym. Część z nich bardzo trudno zdigitalizować. Jakaś część ta możliwa do digitalizacji lub nie kiedyś mogłaby się przydać. I co wtedy? Baza danych jest modelem jakiegoś fragmentu rzeczywistości. Copyright c P. F. Góra 1 23

24 Everything should be made as simple as possible, but not simpler. Albert Einstein Copyright c P. F. Góra 1 24

25 Modelowanie danych diagramy zwiazków encji (ER) Zbiór encji (entity set) abstrakcyjna klasa reprezentujaca jakiś fragment rzeczywistości: osoba, pracownik, klient, pojazd, ksiażka. Encje maja swoje atrybuty (wszystkie encje z danego zbioru takie same), na przykład imię, nazwisko, PESEL. Zazwyczaj oczekuje się, że istnieje atrybut pozwalajacy na jednoznaczna identyfikację encji w zbiorze; w podanym przykładzie byłby to PESEL. Encje moga wchodzić w zwiazki (relationship), łacz ace elementy jednego zbioru encji z elementami innego (niekiedy tego samego!) zbioru encji. Teoretycznie zwiazki encji moga być wieloargumentowe, a nawet posiadać własne atrybuty. Takie przypadki eliminujemy, wprowadzajac sztuczne zwiazki dwuargumentowe i/lub dodatkowe zbiory encji (w modelu relacyjnym oznacza to wprowadzanie tabel pomostowych), tak więc ograniczmy się do bezatrybutowych zwiazków binarnych. Copyright c P. F. Góra 1 25

26 Przykład Encje, ich atrybuty i zwiazek Zwiazek: Zbiór par uporzadkowanych, podzbiór iloczynu kartezjańskiego zbiorów. Copyright c P. F. Góra 1 26

27 Rodzaje zwiazków między danymi Zwiazek wiele do wielu jeden operator może obsługiwać wiele maszyn, jedna maszyna może być obsługiwana przez wielu operatorów. Copyright c P. F. Góra 1 27

28 Niech będa dane zbiory A = {x 1, x 2, x 3, x 4 }, B = {y 1, y 2, y 3, y 4, y 5 }. Wiele do wielu A B x 1 y 2 x 1 y 3 x 2 y 1 x 2 y 2 x 2 y 5 x 3 y 1 x 4 y 2 x 4 y 5 x 3 y 6 Element y 4 nigdzie się nie pojawia (nie wszystkie elementy zbiorów musza wchodzić we wskazany zwiazek). Copyright c P. F. Góra 1 28

29 Ostatni wiersz wskazuje na nieporawna, nie należac a do iloczynu kartezjańskiego parę (x 3, y 6 ). W bazach danych, jeśli explicite tego nie zabronimy, tego typu zwiazki można definiować (a co się stanie, gdy taki faktycznie wystapi, zależy od kontekstu). Copyright c P. F. Góra 1 29

30 Zwiazki wiele do jednego, jeden do wielu Jedna maszyna może być obsługiwana tylko przez jednego operatora, ale jeden operator może obsługiwać wiele maszyn Jeden operator może obsługiwać wiele maszyn, ale jedna maszyna może być obsługiwana przez wielu operatorów Copyright c P. F. Góra 1 30

31 Zwiazek jeden do jednego Jedna maszyna może być obsługiwana tylko przez jednego operatora, a jeden operator może obsługiwać tylko jedna maszynę. W pewnym sensie można utożsamić operatora z obsługiwana przez niego maszyna. Copyright c P. F. Góra 1 31

32 Jeden do jednego A B x 1 y 3 x 2 y 1 x 4 y 2 Elementy w żadnej kolumnie nie powtarzaja się. Nie wszystkie elementy musza wystapić. Ale gdyby element x 3 wystapił, musiałby się łaczyć z y 4 albo y 5. Copyright c P. F. Góra 1 32

33 Integralność referencyjna Integralność referencyjna (referential integrity) to szczególny, występujacy wyłacznie w kontekstach bazodanowych, typ zwiazku wiele-do-jednego, w którym wskazywany element musi istnieć. Uniemożliwia to wystapienie takiej sytuacji, jaka była omawiana na stronie 29. Ze względu na swój ograniczajacy charakter, ten zwiazek zazwyczaj nazywany jest więzem integralności referencyjnej. Copyright c P. F. Góra 1 33

34 Przykład W bazie danych przychodni medycznej zapisywane sa informacje o badaniach zleconych przez zatrudnionych tam lekarzy. Zwiazek integralności referencyjnej mówi, że w bazie nie da się zapisać informacji o badaniu zleconym przez nieistniejacego (nie zatrudnionego tam) lekarza. Copyright c P. F. Góra 1 34