Bazy danych 1. Pojecia˛ podstawoweth- · Pojecia˛ podstawowe P. F. Góra 2017/18. ......
-
Upload
truongngoc -
Category
Documents
-
view
232 -
download
0
Transcript of Bazy danych 1. Pojecia˛ podstawoweth- · Pojecia˛ podstawowe P. F. Góra 2017/18. ......
Bazy danych
1. Pojecia podstawowe
P. F. Górahttp://th-www.if.uj.edu.pl/zfs/gora/
2017/18
Baza danych:Duza kolekcja danych, odpowiednio
zorganizowana w celu szybkiegoprzeszukiwania i dostepu do informacji,uzyskiwanego przy pomocy komputera.
Copyright c© 2010-17 P. F. Góra 1–2
Patron?
Sw. Izydor z Sewilli (VI wiek), patron Internetu, stworzył pierwszy katalog
Copyright c© 2010-17 P. F. Góra 1–3
Bazy danych sa wszechobecne!
• uzytkownicy∗
• projektanci/programisci aplikacji bazodanowych†
• projektanci/programisci baz danych, administratorzy baz danych
• projektanci/programisci systemów bazodanowych (DataBase ManagementSystem, DBMS)
Cel wykładu:Projektowanie i programowanie baz danych
∗Widza tylko front–end†Błednie nazywanych “bazami danych”
Copyright c© 2010-17 P. F. Góra 1–4
Architektura klient-serwer
lasagna code:aplikacja bazodanowa
system operacyjny → l ↖klient ? business logic
siec → l ↙serwer
Czy logike biznesowa umieszczac “po stronie serwera” czy “po stronieaplikacji”?
Copyright c© 2010-17 P. F. Góra 1–5
Architektura klient-serwer (cd)
• sytemy wielodostepne, heterogeniczne
• najbardziej kosztowna operacja: przesyłanie danych
• wiele operacji wykonywanych “po stronie serwera”
• Logika biznesowa raczej “po stronie serwera”
• struktura bazy (schemat) i wiezy umieszczone bezposrednio w bazie, niew aplikacji
Copyright c© 2010-17 P. F. Góra 1–6
Schemat i instancja
Baza danych to, w pewnym sensie, abstrakcyjny model systemu o okreslonymschemacie.
Schemat bazy danych zawiera informacje o tableach (lub innych obiektach)w bazie, kolumnach, typach danych, indeksach, wzajemnych powiazaniach po-miedzy tabelami, a takze o uzytkownikach, ich uprawnieniach itd itd.
Konkretne wystapienie bazy danych, wraz konkretna (chwilowa!) zawartosciadanych, nazywa sie instancja.
Kazda instancja musi byc fizycznie zlokalizowana na jakims sprzecie. Co zrobic,gdy zaczyna brakowac miejsca, mocy obliczeniowej i innych zasobów?Copyright c© 2010-17 P. F. Góra 1–7
Skalowanie
Gdy brakuje zasobów, skalujemy nasz system bazodanowy: rozbudowujemyserwer lub dodajemy nowe serwery.
Copyright c© 2010-17 P. F. Góra 1–8
Skalowanie pionowe
Skalowanie pionowe (vertical scaling, scaling up) polega na dokładaniu zasobów(pamieci, przestrzeni dyskowej, procesorów, portów komunikacyjnych etc) doistniejacego serwera.
Copyright c© 2010-17 P. F. Góra 1–9
Skalowanie pionoweZalety Wady
mniejsze zuzycie mocy awaria unieruchamia cała bazemniejszy koszt chłodzenia ograniczenia fizycznemniejsza zajetosc serwerowni prawo malejacych przychodówmniejsze koszta licencyjne duze serwery sa bardzo drogienie wymaga dodatkowego sprzetu
sieciowegonie ma spowolnien w celu zapewnienia
spójnosci danych
Copyright c© 2010-17 P. F. Góra 1–10
Prawo Amdahla
Jesli mamy jeden procesor, dołozenie drugiego da nam wiekszy zysk, niz doło-zenie setnego procesora do 99 istniejacych.
Niech α oznacza czesc operacji, które musza byc wykonywane sekwencyjnie.1−α jest czescia operacji, która mozna zrównoleglic. Wówczas jesli mamy Pprocesorów, prawo Amdahla głosi, ze osiagniemy przyspieszenie równe
S =1
α+ 1−αP
Copyright c© 2010-17 P. F. Góra 1–11
Przypadki graniczne: α = 0 (wszystko da sie zrównoleglic): S = P .Dla α > 0
limP→∞
S =1
α
Prawo Amdahla jest szczególnym przypadkiem prawa malejacych przychodów(the law of diminishing returns). W pewnym momencie zwiekszanie zasobówjedynego serwera przestaje sie opłacac.
Copyright c© 2010-17 P. F. Góra 1–12
Skalowanie poziome
Skalowanie poziome (horizontal scaling, scaling out) polega na dokładaniu ser-werów, które przechowuja kopie bazy danych i obsługuja czesc ruchu.
Copyright c© 2010-17 P. F. Góra 1–13
Skalowanie poziomeZalety Wady
awaria jednego serwera wieksze zuzycie mocynie unieruchamia całej bazy wiekszy koszt chłodzenia
łatwiej dokładac serwery wieksza zajetosc serwerowniłatwiej usuwac serwery wieksze opłaty licencyjnena ogół tansze od skalowania pionowego wymagane wiecej sprzetu sieciowego
(duze serwery sa bardzo drorgie) nierównomierne obciazenie serwerów(fragmentacja)
spowolnienia dla zapewnieniaspójnosci danych
Copyright c© 2010-17 P. F. Góra 1–14
W praktyce decyzja o wyborze skalowania bywa trudna. Zalezy od charakteru bazy, liczby klien-tów jednoczesnie komunikujacych sie z baza, a nawet od (typowej) zawartosci bazy (instancjibazy), posiadanego budzetu itp.
Zródło: http://www.practicingsafetechs.com/TechsV1/Scaling/index.html
Copyright c© 2010-17 P. F. Góra 1–15
Zasadniczy podział
Bazdy danych↙ ↘
relacyjne NoSQLNot only SQL
• Bazy relacyjne — ∼ 80% rynku
• Bazy NoSQL — najwieksze firmy technologiczne (Amazon, Facebook) ,plus ∼ 95% aplikacji wytwarzanych przez niczego nieswiadomych progra-mistów /
Copyright c© 2010-17 P. F. Góra 1–16
Relacyjne bazy danych
• Oparte o mocne matematyczne podstawy
• Wymagaja dobrego (kosztownego, czasochłonnego, przemyslanego) zapro-jektowania
• Instytucje rzadowe, banki, duze firmy (tradycyjne)
• Chronia przed wieloma błedami
• Zapewniaja bezpieczenstwo danych
• Zapewniaja stała spójnosc danych pomiedzy serwerami
• . . . i generuja wynikajace z tego opóznienia
• Mozliwy bardzo długi czas zycia
• Kłopot, gdy dane nie pasuja do schematu
• Moga obsługiwac setki, a nawet tysiace jednoczesnych uzytkowników
Copyright c© 2010-17 P. F. Góra 1–17
Bazy NoSQL• Luzniejsze, gorzej zdefiniowane podstawy• Nie wymagaja dokładnego projektowania• Najwieksze firmy nowych technologii plus wiekszosc małych firm nowych
technologii• Wieksza odpowiedzialnosc spoczywa na programiscie• Mnóstwo oprogramowania “samo” generuje takie bazy• Nie musza zapewniac stałej spójnosci danych pomiedzy serwerami• . . . zapewniajac lepsza dostepnosc, kosztem niejednoznacznych odczytów• Typowo raczej krótki czas zycia• Znacznie bardziej elastyczne przy zróznicowanych danych• Pomyslane do obsługiwania dziesiatek i setek tysiecy jednoczesnych uzyt-
kownikówCopyright c© 2010-17 P. F. Góra 1–18
Cykl zycia projektu informatycznego
Analiza↓
Modelowanie↓
Implementacja↓
Wdrozenie↓
Utrzymanie
Copyright c© 2010-17 P. F. Góra 1–19
Baza danych jako model rzeczywistosci
Baza danych jest modelem rzeczywistosci —ma odpowiadac potrzebom uzytkownika, nie
wyobrazeniom projektanta
Złamanie tej zasady to typowy (i bolesny) bład popełniany przy projektowaniubaz danych.
Uzyskanie informacji od klienta czego im naprawde trzeba bywa nie ladawyzwaniem /
Copyright c© 2010-17 P. F. Góra 1–20
W Dolinie Krzemowej panuje systemowy brak
odpowiedzialnosci. Zakorzeniony jest w chorobliwej
wsród programistów pewnosci, ze rozumieja co jest
najlepsze dla swiata, podczas gdy w rzeczywistosci sa
naiwni i nie maja nawet pojecia, jaki jest
skomplikowany.
Zeynep Tufekçi
Copyright c© 2010-17 P. F. Góra 1–21
Programming is Forgetting
Zródło: Allison Parrish, Programming is Forgetting
Copyright c© 2010-17 P. F. Góra 1–22
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 kazdego innego oprogramo-wania) łaczy sie z odrzucaniem wielu informacji o swiecie zewnetrznym. Czescz nich bardzo trudno zdigitalizowac. Jakas czesc — ta mozliwa do digitalizacjilub nie — kiedys mogłaby sie przydac. I co wtedy?
Baza danych jest modelem jakiegos fragmentu rzeczywistosci.
Copyright c© 2010-17 P. F. Góra 1–23
Everything should be made as simple as possible, but not simpler.
Albert Einstein
Copyright c© 2010-17 P. F. Góra 1–24
Modelowanie danych — diagramy zwiazków encji (ER)
Zbiór encji (entity set) — abstrakcyjna klasa reprezentujaca jakis fragment rze-czywistosci: osoba, pracownik, klient, pojazd, ksiazka. Encje maja swoje atry-buty (wszystkie encje z danego zbioru takie same), na przykład imie, nazwi-sko, PESEL. Zazwyczaj oczekuje sie, ze istnieje atrybut pozwalajacy na jedno-znaczna identyfikacje encji w zbiorze; w podanym przykładzie byłby to PESEL.
Encje moga wchodzic w zwiazki (relationship), łaczace elementy jednego zbioruencji z elementami innego (niekiedy tego samego!) zbioru encji. Teoretyczniezwiazki encji moga byc wieloargumentowe, a nawet posiadac własne atrybuty.Takie przypadki eliminujemy, wprowadzajac “sztuczne” zwiazki dwuargumen-towe i/lub dodatkowe zbiory encji (w modelu relacyjnym oznacza to wprowadza-nie tabel pomostowych), tak wiec ograniczmy sie do bezatrybutowych zwiazkówbinarnych.Copyright c© 2010-17 P. F. Góra 1–25
Przykład
Encje, ich atrybuty i zwiazek
Zwiazek: Zbiór par uporzadkowanych, podzbiór iloczynukartezjanskiego zbiorów.
Copyright c© 2010-17 P. F. Góra 1–26
Rodzaje zwiazków miedzy danymi
Zwiazek wiele do wielu — jeden operator moze obsługiwac wiele maszyn,jedna maszyna moze byc obsługiwana przez wielu operatorów.
Copyright c© 2010-17 P. F. Góra 1–27
Niech beda dane zbiory A = {x1, x2, x3, x4}, B = {y1, y2, y3, y4, y5}.
Wiele do wieluA Bx1 y2x1 y3x2 y1x2 y2x2 y5x3 y1x4 y2x4 y5x3 y6
Element y4 nigdzie sie nie pojawia (nie wszystkie elementy zbiorów muszawchodzic we wskazany zwiazek).Copyright c© 2010-17 P. F. Góra 1–28
Ostatni wiersz wskazuje na nieporawna, nie nalezaca do iloczynu kartezjan-skiego pare (x3, y6). W bazach danych, jesli explicite tego nie zabronimy, tegotypu zwiazki mozna definiowac (a co sie stanie, gdy taki faktycznie wystapi, za-lezy od kontekstu).
Copyright c© 2010-17 P. F. Góra 1–29
Zwiazki wiele do jednego, jeden do wielu
Jedna maszyna moze byc obsługiwana tylko przez jednego operatora, alejeden operator moze obsługiwac wiele maszyn
Jeden operator moze obsługiwac wiele maszyn, ale jedna maszyna moze bycobsługiwana przez wielu operatorów
Copyright c© 2010-17 P. F. Góra 1–30
Zwiazek jeden do jednego
Jedna maszyna moze byc obsługiwana tylko przez jednego operatora, a jedenoperator moze obsługiwac tylko jedna maszyne. W pewnym sensie mozna
utozsamic operatora z obsługiwana przez niego maszyna.
Copyright c© 2010-17 P. F. Góra 1–31
Jeden do jednegoA Bx1 y3x2 y1x4 y2
Elementy w zadnej kolumnie nie powtarzaja sie. Nie wszystkie elementy muszawystapic. Ale gdyby element x3 wystapił, musiałby sie łaczyc z y4 albo y5.
Copyright c© 2010-17 P. F. Góra 1–32
Integralnosc referencyjna
Integralnosc referencyjna (referential integrity) to szczególny, wystepujacy wy-łacznie w kontekstach bazodanowych, typ zwiazku wiele-do-jednego, w którymwskazywany element musi istniec. Uniemozliwia to wystapienie takiej sytuacji,jaka była omawiana na stronie 29. Ze wzgledu na swój ograniczajacy charakter,ten zwiazek zazwyczaj nazywany jest wiezem integralnosci referencyjnej .
Copyright c© 2010-17 P. F. Góra 1–33
Przykład
W bazie danych przychodni medycznej zapisywane sa informacje o badaniachzleconych przez zatrudnionych tam lekarzy. Zwiazek integralnosci referencyjnej
mówi, ze w bazie nie da sie zapisac informacji o badaniu zleconym przez nieist-niejacego (nie zatrudnionego tam) lekarza.
Copyright c© 2010-17 P. F. Góra 1–34