Wyklad z baz danych



Pobieranie 213,04 Kb.
Strona1/3
Data22.02.2018
Rozmiar213,04 Kb.
  1   2   3

WYKLAD Z BAZ DANYCH
WYKLAD I
Bazy danych:

- dane;


- obsluga danych – funkcje uzytkowe (biznesowe).
Istota budowy modeli i architektury bazy danych – II. (na ktorej czesci wykladow z baz bedzie ten temat)

Interfejsy baz danych – II.

Systemy zarzadzajace bazami danych – III.

Zaawansowane techniki.


OLTP – OnLine Transaction Processing; odwzorowywanie w systemie na biezaco procesow dziejacych sie w czasie rzeczywistym (systemy doprowadzone do perfekcji).
OLAP – OnLine Analitical Processing; analiza danych z hurtownii danych.
DM – Data Mining; eksploracja baz danych.
Bazy wiedzy

OLTP

. H + OLAP DM W

.

.

SE



SE – systemy ekspertowe - systemy wspomagania decyzji.

WYKLAD II

Systemy przetwarzania danych masowych.

Najwazniejszy jest cel realizowany przez system.

Systemu czasu rzeczywistego zbieraja i przetwarzaja dane, wysylaja sygnaly na biezaco.
CEL! – fragment swiata rzeczywistego.

3. – cel Inny system

Obiekty,

Zdarzenia, Strumien danych wejsciowych 1. 4.

Transakcje Uzytkownik

2.


Legenda:)

1. Obsluga wejscia danych;

2. Przechowywanie danych ;

3. Wyszukiwanie danych dla celu, przetwarzanie danych dla celu;

4. Wygenerowanie wyjsc.
Wczytanie danych do bazy danych i sprawdzenie ich poprawnosci:

- sprawdzenie typu danej, zakresu, wartosci;

- sprawdzenie, czy zwiazki zachodzace miedzy wprowadzanymi danymi sa poprawne;

- sprawdzenie, czy nowe dane pasuja do juz istniejacych


IDENTYFIKACJA -> OPIS

WYKLAD III

Oprogramowanie musi zadbac o:

1. dostepnosc systemu;

2. ochrone danych przed nieupowaznionym dostepem;

3. integralnosc danych;

4. organizacje efektywnego wielodostepu (system operacyjny juz to robi, ale my mamy zrobic to lepiej).


ad. 1. Dostepnosc systemu:

* Na poziomie sprzetowym:

* musimy zadbac o dobry (i drogi;)) sprzet, tak aby w kazdej chwili system byl dostepny dla uzytkownikow – np. musimy zadbac o wystarczajaca pamiec, na ktorej trzymamy bazy danych

* musimy tez zabezpieczyc sie przed utrata waznych zbiorow danych (dobry dysk;))

* mirroring – podwojny zapis (na dwoch dyskach);

* macierze dyskowe – przyspieszenie mirroringu.

* Na poziomie oprogramowania:

* robienie kopii bezpieczenstwa danych – zrzuty plikow;

* od momentu zrobienia kopii kazda operacja jest zapisywania w historii (logu) zadan;

* a co w momencie, gdy system pracuje 24h/dobe i 7 dni w tygodniu??

* dodatkowy uzytkownik robi kopie i sprawdza co dobe (?) dane;

* skomplikowane podgladanie – niedobowe.


ad. 2. Ochrona danych przed nieupowaznionym dostepem:

Przydzielanie specjalnych rol – uprawnien, podzielenie uzytkownikow na grupy o roznych uprawnienaich, oprogramowanie bedzie znac i pilowac tych uprawnien.


ad. 3. Integralnosc danych:

Zgodnosc danych (zarowno miedzy soba, jak i z rzeczywistoscia); restrykcyjne zachowanie systemu – system nie moze pozwolic na niekompletne dane (musi pilnowac, zeby byl komplet danych), np. jesli usuwamy nazwisko osoby z bazy danych to musimy tez zadbac, aby system usuwal tez wszystkie inne dane zwiazane z ta osoba.


ad. 4. Wielodostep:

Najczesniej zdarza sie na poziomie pliku. Jak sie juz dostaniemy do plikow, to zaczynami sami kiontrolowac wielodostep.


Pomysl na tworzenie baz danych (skladanie go z gotowych kanalow (?))

Mamy kilka sposobow przechowywania danych. Jesli mamy juz dane do przechowania, to musimy sie zastawnowic, jak chcemy je przechowac w naszej bazie danych. Dane przechowujemy w standardowym elemencie przechowywania danych.

A co z ochrona danych przed nieupowaznionym dostepem??

Mamy okreslony jezyk opisu danych, dopisujemy wiec do danej uprawnienia – kto i jak ma dostep do danego obiektu standardowego.

Dane mamy opisane w standardzie logicznym; opisujemy w nim uprawnienia i warunki integralnosciowe.

Mamy wiec system elementow standardowych, model logiczny, potrzebujemy do tego jeszcze programu, ktory by zarzadzal tymi danymi. Jest to system zarzadzania baza danych. Piszemy go raz, kazdy uzytkownik, ktory bedzie robil swoj system w oparciu o ten standard, bedzie musial korzystac z tego programu.


SZDB – trzeba go kupic;)

Musimy tez stworzyc opis do tego standardu.

Opis danych w konwencji logicznych standardow. (?)

Model logiczny (wg. standardu):

- standardowe mozliwosci ochcrony przed nieupowaznionym dostepem;

- warunki integralnosciowe (zdefiniowac).


Opisy funkcji uzytkowych (nie wiemy, jak bedzie wygladala wewnetrzna struktura pliku);
Komunikacja z baza danych:

- algorytmiczna;

- deklaratywna.
Standardy systemow zarzadzania baza danych:

- hierarchiczny SZBD – polega na utworzeniu hierarchi z elementow bazy danych; niestety nie wszystkie elementy da sie uporzadkowac w hierarchii, wiec trzeba bylo „kombinowac” ;)

- sieciowy SZBD – zauwazono, ze dane moga miec zwiazki miedzy soba, zwiazki te mozna przedstawic jako siec – „kazdy z kazdym”; z biegiem czasu kazdy modyfikowal ten model i cos do niego dopisywal i po kilku latach okazalo sie, ze kazdy model sieciowy jest zupelnie inny;

srodowisko „bazodanowcow” zazadalo ustandaryzowania roznych modeli – konferencja CODASYL (Conference on Data Systems Languages);

- relacyjny SZBD – relacyjny model bazy danych zostal zgloszony przez Edgara Codda – obecnie wiekszosc systemow jest w nim tworzonych (ok. 80%);

- obiektowy SZBD – stworzzony przez informatykow, nawiazuje do nowych technologii funkcji uzytkowych (technologie obiektowe);

- dedukcyjny SZBD – baza danych + wiedza; mozliwosc uzyskania danych za pomoca dedukcji, nie musza byc one zapisane bezposrednio.
WYKLAD IV

W kazdym miejscu, w ktorym algorytm naszej funkcji uzytkowej musi wykonac jakies dzialanie na bazie danych, odwoluje sie do logicznego modelu bazy danych.


Temporalne bazy danych – w szczegolny sposob traktuja dane datowane (liczy sie czas:))
Geneza powstania modelu relacyjnego bazy danych.

Podejscie hierarchiczne i sieciowe opieralo sie na „inzynierskiej intuicji programisty”, na tym, jak on sobie wyobraza prace na modelu logicznym bazy. Zaczely powstawac coraz wieksze systemy, trzeba bylo stworzyc formalny opis (matematyczny) i opis ogolnie zrozumialy.

Idee relacyjnej bazy danych wymyslil Edgar Codd, pracujacy dla IBM i zawarl je w „A Relational Model of Data for Large Shared Data Banks” - formalizm logiczny. Na poczatku pomysl ten napotykal na same trudnosci. Codd nie mogl przekonac IBM co do niego. Projekt uznano za nierealny. W koncu jednak IBM pod wplywem konkurencji i klientow rozpoczal implementacje realycjnego systemu baz danych (System R).
Definicja relacyjnego modelu bazy danych.

n є N – zbior wszystkich wartosci, np. nazwisk;

i є I – zbior wszystkich wartosci atrybutu, np. „imie”.
Tworzymy iloczyn kartezjanski {NxI} -> {n, i} - kazdy z kazdym.

R – relacja.

Wiec mamy R (relacje) i {n, i} (podzbior {NxI}) – odwzorowanie rzeczywistosci.

Schemat relacji = nazwa relacji + zbior atrybutow, np. Osoba (nazwisko, imie, adres, wiek)

Algebra relacji – do operowania na danych reprezentowanych w postaci relacji.
Nie mozemy wpisywac dwa razy takiej samej kombinacji (ograniczenie na model logiczny danych), nalezy tak dodawac relacje, zeby nie wystapily identyczne elementy.
Relacje mozemy przedstawic jako tablice.




























Kolumny maja atrybuty.

Zamiast rekordow danych mamy wiersze tablicy.

Mozna powiedziec, ze nasz model relacyjny sklada sie z tabel (moze byc jedna lub kilka tabel – relacji w jednym schemacie relacyjnym)
Nie moze byc dwoch wierszy z takimi samymi wartosciami.

Dla okreslonych pol mozemy definiowac zakres dopuszczalnych wartosci (np. dla pola nazwisko nie dopuszczamy znakow specjalnych oprocz ‘-‘).


Relacja:

- nazwa relacji

- atrybuty odpowiadajace kolumnom (nazwy kolumn) – zbior dopuszczalnych wartosci

- „encje” (inaczej tez „krotki”) – wiersze naszej tablicy.


Operacja usuwania.

Podawanie wszystkich atrybutow byloby dosyc meczace, nalezalo skonstruowac latwiejszy mechanizm usuwania – identyfikowanie wierszy na podstawie kluczy.



Klucz jest to podzbior atrybutow, ktorych kombinacja jednoznacznie wskazuje na wiersz tabeli (nie moze byc to numer wiersza).

Klucz wlasciwy – podzbior atrybutow, ktory jest kluczem i nie da sie skrocic, tak aby to co zostalo tez bylo kluczem.

Kluczy wlasciwych moze byc kilka, sposrod nich wybieramy jeden – bedzie to nasz klucz glowny, za jego pomoca bedziemy mogli wyszukiwac najszybciej (np. w bazie studentow uczelni bedzie to numer indeksu).



Cechy klucza glownego:

- jednoznaczna identyfikacja (np. nick w bazie danych uzytkownikow forum, numer indeksu na uczelni);

- niezmiennosc wartosci klucza w trakcie uzywania systemu;

- mozliwie najkrotszy, najlepiej zbior jednoelementoiwy;

- czasami mozemy stworzyc go sobie sami - w miare potrzeb (np. wprowadzenie numeru PESEL do jednoznacznej identyfikacji osob); powszechny jest identyfikator systemowy ID – nadawany przez system jako kolejna liczba naturalna w celu identyfikacji (zmiana rzeczywistosci – dodajemy do bazy nowy atrybut nie majacy nic wspolnego z rzeczywistoscia).

WYKLAD V
Mamy sytuacje taka, ze chcemy wpisac nowy wiersz do naszej tablicy, ale nie posiadamy wszystkich danych. Mozemy zrobic dwie rzeczy:

- mozemy zostawic puste miejsce, ale tablica jest relacja i nie wystepuja w niej „wolne miejsca”;

- zamiast tego definiujemy po prostu wartosc „nie wiem”, taka zeby byla ona wlasciwa dla wszystkich pol w tablicy – NULL, dla kazdego rodzaju danych bedzie on interpretowany inaczej (albo np. jesli mamy dodatnie integery w tablicy to mozemy jako „nie wiem” podawac wartosc ujemna).



Nr

Data

Nazwa

(hurtowni)



Adres

(hurtowni)



Osoby

Telefon

Nr poz.

Zamow.


Tytul

Autor

1


Autor

2


Wyda-

nie


Rok

Sztuk

Cena

7

...

...

...

imie/nazwisko

...

1

Potop

Sienkiewicz

NULL

14

2004

25

30

35

...

...

...

...

...

2

Fizyka

...

...

3

2003

50

50

41

...

...

...

...

...

3

Bazy danych

Valenta

Zygmunt

4

2005

100

135

NULL
















NULL
















NULL

73

Nie moze byc kilka wartosci w jednym polu.

Niektore pola przydaloby sie podzielic, np. pole adres nie jest polem atomowym, tylko polem zlozonym.

Niektore dane trzeba powtorzyc wiele razy, np. nazwe hurtowni trzeba wpisywac zawsze, jesli tylko ksiazka pochodzi z tej hurtowni (czyli duzo razy to samo) – niepotrzebnie.

Kluczem glownym bedzie nr zamowienia (1 kolumna) i nr poz.
Anomalie:

- anomalia przy aktualizacji danych – jesli zmienilo by sie cos w danej, ktora mamy wpisana wiele razy to w kazdym polu nalezaloby dokonac aktualizacji, trudno zmienic cos w 1000 roznych miejsc;

- anomalia przy zapisie – klucze glowne nie moga byc nigdy NULLami (ostatnia linijka);

- anomalia przy kasacji danych – np. chcemy zrezygnowac z jakiegos zamowienia, czyli teoretycznie musielibysmy usunac wiersz, ale my chcemy tylko zaznaczyc, ze nie ma tego zamowienia i zachowac wszystkie dane.


Aby pozbyc sie tych anomalii musimy dokonac dekompozycji tablicy, czyli musimy podzielic ja na odrebne czesci: hurtownie, ksiazki, opis zamowienia.

Bedziemy mieli trzy takie tablice, zamiast jednej duzej:

Opis zamowienia – atrybuty: nr zam., data, nr poz., sztuk, cena.

Ksiazki – atrybuty: tytul, autor1, autor2, autor3, wydawnictwo, wydanie, rok wydania.

Hurtownie – atrybuty: nazwa, adres, osoba, telefon.

Zauwazmy jednak, ze tablice te sa niezalezne od siebie, a nasza pierwotna tablica byla zalezna, wiec musimy stworzyc zwiazek logiczny miedzy tymi nowymi tablicami.

Wprowadzamy tzw. klucze obce do tabelki Opis zamowienia – klucze obce, czyli klucze z innych tablic (Ksiazki i Hurtownie), w naszym przypadku bedzie to adres + nazwa hurtowni dla tabeli Hurtownie i tytul + autor + wydanie + wydawnictwo dla tabeli Ksiazki. Po wprowadzeniu tych kluczy do tableki Opis zamolwienia mozemy zauwazyc, ze tabela zrobila sie z powrotem zbyt dluga i pozostal problem anomalii przy aktualizacji. Optymalizacja -> wprowadzimy nowe, krotkie klucze: dla hurtowni moze byc to NIP, a dla ksiazek – ISBN. Te wartosci mozemy wprowadzic jako klucze obce do Opisu zamowienia – tabelka sie skroci.

Nastepnie wyszukujemy w naszych tablicach kollejnych anomalii, ktore mozna by bylo wykluczyc. W tym celu oddzielamy te czesci tabeli, w ktorych czesto powtarzaja sie wartosci (np. w dalszym kroku oddzielilismy do nowej tabeli tytul i autorow ksiazki z tabeli Ksiazki, pozniej zrobilismy jeszcze osobna tabele dla autorow) i tworzymy z nich nowe tabele, wprowadzajac zwiazki logiczne za pomoca kluczy obcych. Czyli w praktyce rozbijamy glowna tabele na coraz mniejsze, tak aby jak najmniej elementow sie powtarzalo i wprowadzamy zaleznosci miedzy nimi za pomoca kluczy.



WYKLAD VI

Do naszej bazy danych przydalby sie jezyk deklaratywny, czyli taki, w ktorym podajemy tylko co chcemy osiagnac, bez precyzowania w jaki sposob chcemy to osiagnac.

W jezyku deklaratywnym: chce samochod ;)

W jezyku algorytmicznym: musze przestac sie obijac, pracowac tu, tam zainwestowac, wybrac kase, isc na promocje i kupic samochod ;)


Normalizacja schematu bazy danych – baza danych jest znormalizowana wtedy, kiedy wszystkie tablice sa znormalizowane.

Proces normalizacji bazy danych – mozna tylko dzielic tablice na mniejsze i sprawdzac, czy sa one znormalizowane.

Tablica znormalizowana – spelnia warunki form normalnych (warunki normalizacji).
Schemat normalizacji III forma normalna zalatwia wiekszosc

I forma normalna – w1FN (warunek I formy normalnej) problemow zwiazanych z baza; schemat

II forma normalna – IFN + w2FN musi byc doprowadzony do III formy

III forma normalna – IIFN + w3FN poniewaz programy do zarzadzania bazami

--------------------------------------------------- danych zakladaja, ze baza jest

BCNF (Boyce Codd Normal Form) doprowadzona do III formy.

---------------------------------------------------

IV forma normalna – IIIFN + w4FN IV i V forma zdecydowanie pomagaja w

V forma normalna – IVFN + w5FN zarzadzaniu baza, ale nie sa wymagane


Codd i Boyce doszli do wniosku, ze czasami mozna rozpatrywac jeszcze warunek, ktory by byl mocniejszy niz trzeci, ale nie bylby czwartym.

WYKLAD VII
Kazda forma normalna ma swoj specyficzny warunek. Oprocz tego, zeby schemat spelnial dana forme, musi spelniac jeszcze wszystkie poprzednie formy.
I forma normalna

Warunek: atrybuty tabeli musza byc wielkosciami atomowymi.

Miara atomowosci – zalezy od naszych potrzeb.

Zeby doprowadzic do I formy normalnej sprawdzamy atrybut po atrybucie, czy jest on atomowy. W razie potrzeby rozbijamy wieloatomowe pola tak, by spelnialy warunek atomowsci.


Przyklad:

Czy pole adres jest polem atomowym czy nie?

Jesli wiemy, ze w czasie operowania na bazie zawsze bedziemy potrzebowali calego adresu, to pole adres mozemy uznac za atomowe. Jesli jednak dopuszczamy mozliwosc, ze bedziemy potrzebowali tylko samej miejscowosci, to wtedy pole adres nie jest juz atomowe i nie spelnia I formy normalnej. Nalezy wiec rozbic pole adres, np. na pola ulica, miejscowosc, kod pocztowy (czyli na pola atomowe).
II forma normalna

Tablica musi byc w I formie normalnej i spelniac dodatkowy warunek.

Nowe pojecia:

Zaleznosc funkcjonalna pomiedzy atrybutami:

x -----> y

y jest funkcjonalnie zalezny od x,jezeli wartosc atrybutu x zawsze wyznacza ta sama wartosc atrybutu y (z wartoscia x zawsze wystepuje ta sama wartosc y).

x wyznacza logicznie wartosc y.



Atrybut zwykly:

Atrybut zwykly tablicy to taki atrybut, ktory nie wchodzi w sklad klucza.


II forma normalna = I FN + warunek.

Warunek: kazdy atrybut zwykly jest w pelni funkcjonalnie zalezny od kluczy tej tablicy (potencjalnych, a w szczegolnosci od klucza glownego), czyli zalezy od calego klucza a nie tylko od jakiejs jego czesci.

Przyklad:

Tabela zamowien:



Nr zamowienia

Data zamowienia

....

....

Nr pozycji
















Klucz glowyny jest zlozony z 2 atrybutow: nr zamowienia i nr pozycji.

Data zamowienia jest zalezna od nru zamowienia.

Czy jest w pelni funkcjonalnie zalezna?

Nie jest bo ne jest zalezna od nru pozycji.

Przyklad:

Tabela pracownikow naukowych AGH:)



Pesel

Imie

Nazwisko

Jednostka uczelni

Pensja

Stanowisko



















Co bedzie kluczem glownym przy zalozeniu ze kazdy pracownik gdzies pracuje?

Kluczem bedzie pesel i jednostka (bo sam pesel nie wystarcza bo pracownik moze pracowac w paru jednostkach).

Czy atrybut zwykly nazwisko zalezy od klucza?

Nie zalezy od calego, bo nie zalezy od jednostki, jest funkcjonalnie zalezny tylko od pesela.

Czyli nie nalezy do II formy.

Ale np. atrybut pensja jest w pelni funkcjonalnie zalezny od calego klucza.

Jesli mielibysmy zalozenie, ze pracownik moze pracowac tylko w jednej jednostce, wiec tylko pesel bylby kluczem i nazwisko byloby w pelni funkcjonalnie zalezne od pesela, czyli od calego klucza, to tablica nalezalaby do II formy normalnej.
III forma normalna

Tablica musi byc w II formie normalnej i spelniac dodatkowy warunek.

Nowe pojecia:

Zaleznosc funkcjonalna przechodnia:

x------->y------->z

z jest przechodnio funkcjonalnie zalezne od x, jezeli z jest funkcjonalnie zalezne od y, a y jest funkcjonalnie zalezne od x.

Przyklad:



ISBN

ID utworu

Tytul

Autor













Kluczem jest ISBN.

ID jest funkcjonalnie zalezny od ISBN.

Tytul jest funkcjonalnie zalezny od ID utworu.

Tytul jest funkcjonalnie zalezny od ISBN.

Autor nie jest funkcjonalnie zalezny od tytulu, ale jest funkcjonalnie zalezny od ID.

Czyli autor jest funkcjonalnie zalezny od ISBN.

Czyli autor jest przechodnio zalezny od tytulu.
III forma normalna = II FN + warunek.

Warunek: zaden atrybut zwykly nie zalezy funkcjonalnie przechodnio od innych atrybutow zwyklych, czyli kazdy atrybut zwykly zalezy funkcjonalnie tylko od klucza, a nie od innych atrybutow zwyklych.

Do III formy normalnej musimy tabele doprowadzic zawsze, bo przy zarzadzaniu baza jest zaloznie, ze jest doprowadzona d III formy.

IV i V forma w schematach baz danych wystepuja o wiele rzadziej.



  1   2   3


©operacji.org 2017
wyślij wiadomość

    Strona główna