Bazy danych 1. Pojecia˛ podstawoweth- · Pojecia˛ podstawowe P. F. Góra 2017/18. ......

34
Bazy danych 1. Poj˛ ecia podstawowe P. F. Góra http://th-www.if.uj.edu.pl/zfs/gora/ 2017/18

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