BD Druk Compressed

BD.1 – Systemy z bazami danych BD.
1 – Systemy z bazami danych

Baza danych Baza danych
System zarzπdzania bazπ danych
PojÍcie bazy danych System zarzπdzania bazπ danych (DBMS)
Czym jest baza danych
I PamiÍÊ trwa≥a danych (persistent data)
Database Management System
I Okreúlona struktura danych i regu≥y integralnoúci
I Program lub zbiór programów dzia≥ajπcy na serwerze
Cele uøytkowania b.d. I Poúredniczy (koniecznie!) w dostÍpie do danych w bazie
I NiezawodnoúÊ zapisu I model danych
I IntegralnoúÊ danych I s≥ownik danych
I jÍzyk opisu danych
I SprawnoúÊ zapytaÒ
I Izoluje programy od reprezentacji fizycznej danych
I Wygodne interfejsy
I WielodostÍp
I Zabezpieczenia dostÍpu
T.Traczyk IAiIS PW Bazy danych 2/16 T.Traczyk IAiIS PW Bazy danych 3/16
BD.1 – Systemy z bazami danych BD.1 – Systemy z bazami danych
Baza danych Systemy informacyjne z bazami danych
System zarzπdzania bazπ danych
Rola DBMS Systemy informacyjne z bazami danych
I Mechanizmy dostÍpu do danych
I jÍzyki zapytaÒ i manipulacji danymi
I optymalizacja dostÍpu I Wspó≥czesne profesjonalne systemy informacyjne z regu≥y
I Ochrona danych wykorzystujπ bazy danych
I otrzymujemy „w pakiecie” wiele waønych cech zapewnianych
I autoryzacja dostÍpu
I ochrona spójnoúci przez DBMS
I samodzielne zrealizowanie wiÍkszoúci tych cech by≥oby bardzo trudne
I mechanizmy odtwarzania po awarii
i kosztowne
I WielodostÍp
I W wiÍkszoúci zastosowaÒ uøywane sπ bazy relacyjne
I zarzπdzanie transakcjami
(RDBMS = Relational DBMS )
I DostÍp przez sieÊ
I róøne architektury i interfejsy dostÍpu
I mechanizmy dla rozproszonych b.d.
Systemy informacyjne z bazami danych G≥ówne typy s.i. z bazami danych
Sk≥adniki systemów informacyjnych z bazami danych G≥ówne typy s.i. z bazami danych
Baza danych
I DBMS
I Metadane (s≥ownik)
I struktura danych I Systemy transakcyjne – OLTP
I regu≥y integralnoúci
I Systemy analityczne – OLAP
I prawa dostÍpu
I Systemy zarzπdzania treúciπ – CMS (Content Management Systems)
I Dane
I Systemy wspierania projektowania – CAD, CAE, CAM, CASE
I JÍzyki dostÍpu do danych
I Systemy informacji przestrzennej – GIS
Aplikacja
I Warstwa sieciowa
I årodowiska wykonania aplikacji
(DBMS, runtime, serwery aplikacyjne, kontenery itp.)
I Modu≥y aplikacji
G≥ówne typy s.i. z bazami danych G≥ówne typy s.i. z bazami danych
OLTP i OLAP OLTP i OLAP
Systemy transakcyjne Systemy analityczne
(OLTP – On Line Transaction Processing ) (OLAP – On Line Analytical Processing )
I G≥ówne zadanie: gromadzenie danych I G≥ówne zadanie: analiza danych do celów wspomagania decyzji
I Typowe úrodowisko: operacyjne bazy danych I Typowe úrodowisko: hurtownie danych
I Typowe dzia≥ania I Typowe dzia≥ania
I niewielka liczba wielkich „transakcji” odczytujπcych dane
I wielka liczba niewielkich transakcji modyfikujπcych dane
I operacje odczytu – g≥ównie interaktywne
I operacje zapisu i odczytu – interaktywne i wsadowe
I operacje zapisu – jedynie wsadowe
I G≥ówne problemy
I G≥ówne problemy
I wielodostÍp
I wielka iloúÊ danych (VLDB – Very Large Databases)
I koniecznoúÊ sta≥ego utrzymania spójnoúci danych
I analiza wielowymiarowa
I maksymalizacja úredniej wydajnoúci
I Tradycyjna domena relacyjnych baz danych I Nowoczesne RDBMS zawierajπ mechanizmy wspomagajπce VLDB
i przetwarzanie analityczne
Klasyfikacja baz danych Architektury systemów z bazami danych
Klasyfikacja baz danych Architektury s.i. z bazami danych
Ze wzglÍdu na model danych Architektura terminalowa
I Hierarchiczne – dane w postaci drzewa lub lasu I Terminale bez øadnej inteligencji
I Sieciowe – dane w postaci grafu I Ca≥e przetwarzanie w bazie centralnej
I Relacyjne – dane w postaci tabel (relacji) I Architektura spotykana g≥ównie w úrodowisku mainframe, obecnie
I Relacyjno-obiektowe – dane obiektowe w strukturach relacyjnych rzadko stosowana
I XML-owe – dane w postaci dokumentów XML Architektura wielokomputerowa ze wspó≥dzieleniem plików
I NoSQL – róøne struktury specjalizowane I Pe≥ne przetwarzanie na kaødym
I Obiektowe – dane w postaci kolekcji powiπzanych obiektów z komputerów
I Wspó≥dzielenie plików z danymi
Za wzglÍdu na cel uøytkowania b.d. I Model „dane do zapytania”
I Operacyjne – OLTP
I Architektura ta nie powinna byÊ
I Analityczne – OLAP stosowana w systemach
I Specjalne: przestrzenne, temporalne, bazy wiedzy itd. profesjonalnych
Architektury systemów z bazami danych Architektury systemów z bazami danych
Architektura klient-serwer Architektura klient-serwer
Architektura klient-serwer I Zalety
I bezpieczeÒstwo serwera
I minimalizacja ruchu w sieci
I model „zapytanie do danych”
I Podzia≥ zadaÒ I moøliwoúÊ przetwarzania danych bezpoúrednio na serwerze
I serwer I odciπøenie centralnego komputera od obs≥ugi interfejsu (waøne dla
I DBMS + dane GUI)
I realizacja zapytaÒ I moøliwoúÊ budowy sporych systemów bez uøycia wielkich
I realizacja ograniczeÒ
I przetwarzanie danych komputerów
I klient I Wady
I obs≥uga prezentacji (GUI) I konieczne administrowanie wieloma PC
I wykonywanie logiki aplikacji I trudne administrowanie aplikacjami (np. zmiany wersji)
I przetwarzanie danych I zmiany oprogramowania klientów, wymuszajπce czÍstπ wymianÍ
I Do niedawna najpopularniejsza sprzÍtu
architektura, nadal powszechnie I problemy z bezpieczeÒstwem (lokalne kopie danych, wirusy)
stosowana I brak kontroli nad dzia≥aniami pracowników
I trudna kontrola licencji
I bardzo duøe koszty eksploatacji PC
Architektury systemów z bazami danych Architektury systemów z bazami danych
Architektura wielowarstwowa Architektura wielowarstwowa
Architektura wielowarstwowa
I Architektura powszechnie stosowana w systemach inter-
I Podzia≥ zadaÒ
I serwer danych
i intranetowych
I jak w architekturze klient-serwer I Wypiera architekturÍ klient-serwer w zastosowaniach korporacyjnych
I serwer aplikacyjny (lub wiele serwerów) I Zalety
I logika aplikacji I wiÍkszoúÊ zalet architektury klient-serwer
I przetwarzanie danych I bezpieczeÒstwo aplikacji (centralizacja)
I funkcje serwera HTTP (opcjonalnie)
I ≥atwoúÊ administrowania aplikacjami
I serwer HTTP (opcjonalny) I brak koniecznoúci administrowania konfiguracjπ klientów
I nas≥uchiwanie øπdaÒ HTTP
I przekazywanie ich do odpowiedniego I Wady
serwera aplikacyjnego I potrzebny silny sprzÍt na serwery aplikacyjne
I przesy≥anie odpowiedzi I trudniejsze technologie
I klient I dla cienkiego klienta – ograniczenia w funkcjonalnoúci interfejsu
I obs≥uga prezentacji uøytkownika
I wykorzystanie przeglπdarki HTML – cienki I wiÍkszy ruch sieciowy
klient
I wykonywanie czÍúci logiki aplikacji (aplety)
– gruby klient
BD.1 – Systemy z bazami danych
Podsumowanie
Podsumowanie
I O bazie danych moøna mówiÊ wtedy, gdy dane sπ zapisane w sposób
trwa≥y, w zdefiniowanych wczeúniej strukturach i z okreúlonymi
regu≥ami integralnoúci
I Ww. oraz inne potrzebne cechy zapewnia system zarzπdzania bazπ
danych (DBMS)
I Uøycie bazy danych daje „w pakiecie” wiele w≥aúciwoúci kluczowych
dla bezpiecznych i wydajnych s.i.
I DostÍp do danych w bazie danych jest moøliwy wy≥πcznie za
poúrednictwem DBMS
I Znaczna wiÍkszoúÊ uøytkowanych obecnie b.d. to bazy relacyjne
I Najwaøniejsze typy s.i. z b.d. to systemy OLTP i OLAP – o nich
bÍdzie ten wyk≥ad
I Wspó≥czeúnie s.i. z b.d. zwykle budowane sπ w architekturze
wielowarstwowej, w eksploatacji sπ teø systemy w architekturze
klient-serwer
T.Traczyk IAiIS PW Bazy danych 16/16
BD.2 – Relacyjny model danych BD.2 – Relacyjny model danych
Relacyjny model danych Relacyjny model danych
Podstawy modelu relacyjnego Podstawy modelu relacyjnego
Podstawy relacyjnego modelu danych
Rozwiπzanie
I Model relacyjny bazy danych zaproponowa≥ E.F. Codd, matematyk I WiedzÍ o úwiecie moøna zawrzeÊ w atrybutach prostych typów,
z IBM, w roku 1970 odpowiednio zorganizowanych w tzw. relacje
I WiÍkszoúÊ wspó≥czeúnie projektowanych i uøytkowanych baz danych I Schemat relacji to zbiór nazw atrybutów: S = {A1 , . . . , An }
to bazy relacyjne I Wartoúci atrybutów naleøπ do dziedzin: D1 , . . . , Dn
I Ten model baz danych dominuje od lat 80-tych i nie zanosi siÍ na I Podstawowπ strukturπ jest relacja
zmianÍ tej sytuacji I relacja R na schemacie S jest to podzbiór iloczynu kartezjaÒskiego
dziedzin atrybutów: R ⇢ D1 ⇥ . . . ⇥ Dn
Cele modelu relacyjnego I relacja jest zbiorem krotek: R = {k1 , . . . , kn }
I ModelowaÊ úwiat za pomocπ moøliwie prostych struktur danych I Relacyjna baza danych jest zbiorem trwale zapisanych relacji
I tylko proste typy danych: liczby, napisy, daty itp. z okreúlonymi regu≥ami integralnoúci
I proste i jednolite struktury I dla kaødej z relacji
I StworzyÊ model dajπcy siÍ opisaÊ i badaÊ w sposób formalny I dla zaleønoúci miÍdzy relacjami
T. Traczyk IAiIS PW Bazy danych 2/32 T. Traczyk IAiIS PW Bazy danych 3/32
Podstawy modelu relacyjnego Podstawy modelu relacyjnego
Tabele relacyjne Przyk≥ad: tabele relacyjne
I Dane opisujπce przedmioty i nauczycieli1
I Z praktycznego punktu widzenia relacja odpowiada tabeli
I atrybuty odpowiadajπ kolumnom tej tabeli PRZEDMIOTY
I krotki odpowiadajπ wierszom KOD_PRZEDMIOTU TYTUL OPIS
BD Bazy danych Wykład obejmuje...
I Cechy tabeli relacyjnej
I ... ... ...
liczba i nazwy oraz kolejnoúÊ kolumn ustalone
I typ danych dla kaødej z kolumn ustalony NAUCZYCIELE
I liczba wierszy zmienna
I kolejnoúÊ wierszy nieustalona! NAZWISKO IMIE STOPIEN_ DATA_
I NAUKOWY URODZENIA
wiersze nie majπ numerów ani adresów
I Zatem: Kowalski Jan mgr 1972-01-23
relacja = tabela Wiśniewski Józef dr inż. 1958-11-03
relacja =
6 zwiπzek (referencyjny) ... ... ... ...
1 Brak spacji oraz ma≥ych i polskich liter w nazwach nie jest przypadkowy
Podstawy modelu relacyjnego ToøsamoúÊ danych – klucze
OpcjonalnoúÊ kolumn ToøsamoúÊ danych
I Dopuszcza siÍ wystÍpowanie w dziedzinie elementu NULL, Identyfikacja wierszy w tabeli relacyjnej
oznaczajπcego brak informacji I Wiersze nie majπ numerów ani adresów
I dane nieznane I Do rozróønienia wierszy moøna zatem uøyÊ wy≥πcznie wartoúci
I dane nieistniejπce (nieadekwatne)
wpisanych w kolumnach
I Dopuszczalne sπ zatem „puste komórki” w tabelach (w tzw.
kolumnach opcjonalnych) Klucz relacji
I Tzw. kolumny obowiπzkowe: nie mogπ zawieraÊ wartoúci NULL I Klucz relacji jest to zbiór atrybutów, które jednoznacznie wyznaczajπ
krotkÍ
ToøsamoúÊ danych – klucze ToøsamoúÊ danych – klucze
Klucz
Klucz g≥ówny (primary key )
I Wyróøniony klucz w≥aúciwy
I Klucz tabeli relacyjnej to kolumna lub zbiór kolumn, których wartoúci
jednoznacznie wyznaczajπ wiersz – zestaw wartoúci siÍ nie powtarza I Okreúla toøsamoúÊ wiersza
I Klucz prosty zawiera jednπ kolumnÍ, klucz z≥oøony – wiele kolumn I Musi byÊ
I z≥oøony z kolumn obowiπzkowych
I Kaødy nadzbiór klucza jest kluczem I niezmienny
I Klucz w≥aúciwy: po wyjÍciu dowolnej kolumny przestaje byÊ kluczem I niezbyt d≥ugi (w sensie liczby bajtów)
I Klucze wykrywa siÍ analizujπc opisywany úwiat, a nie dostÍpne dane! I ≥atwy do wyznaczenia
I Do rozróønienia (identyfikacji) wierszy uøyÊ moøna wy≥πcznie kluczy I Kaøda tabela relacyjna powinna mieÊ klucz g≥ówny2
2 Nie dotyczy niektórych tabel „technicznych”
ToøsamoúÊ danych – klucze Zwiπzki referencyjne
Przyk≥ad: klucze g≥ówne
I Dane opisujπce przedmioty
Zwiπzki miÍdzy tabelami
I kluczami sπ kod przedmiotu i nazwa
I dobrym kluczem g≥ównym jest kod przedmiotu Jak powiπzaÊ dane w dwóch tabelach
I Dane opisujπce wyk≥adowców I Wiersze nie majπ numerów ani adresów
I kluczem nie jest nazwisko+imiona I nie moøna zastosowaÊ wskaüników
I kluczem zapewne jest nazwisko+imiona+data urodzenia, ale nie I powiπzanie musi wykorzystywaÊ klucze (najlepiej g≥ówne)
spe≥nia cech klucza g≥ównego
I naleøy dodaÊ tzw. sztuczny klucz g≥ówny
I Klucze obce (foreign keys)
PRZEDMIOTY I kolumny dodane do tabel w celu realizacji zwiπzków
# KOD_PRZEDMIOTU TYTUL OPIS
I zawierajπ one wartoúci kluczy g≥ównych z tabel powiπzanych
BD Bazy danych Wykład obejmuje...
I muszπ mieÊ typy zgodne z odpowiednimi kolumnami kluczy g≥ównych
... ... ...
I mogπ mieÊ inne nazwy, ale wygodnie jest, jeúli nazwy sπ zgodne
NAUCZYCIELE I jeúli klucz g≥ówny jest z≥oøony, to odpowiedni klucz obcy musi byÊ
# ID_ STOPIEN_ DATA_
NAUCZYCIELA
NAZWISKO IMIE
NAUKOWY URODZENIA z≥oøony analogicznie
1 Kowalski Jan mgr 1972-01-23
2 Wiśniewski Józef dr inż. 1958-11-03 I Uwaga: klucz obcy zwykle nie jest kluczem (!)
... ... ... ... ...
Zwiπzki referencyjne Zwiπzki referencyjne
Zwiπzki jeden do wielu (1 n)
I Klucze obce w naturalny sposób realizujπ zwiπzki 1 n
I odes≥anie inwersyjne – klucz obcy jest w tabeli po stronie „wiele”
Zwiπzki jeden do jednego (1 1)
zwiπzku
I W poprawnie zaprojektowanych strukturach relacyjnych wystÍpujπ
NAUCZYCIELE jedynie wyjπtkowo
# ID_
NAUCZYCIELA
NAZWISKO IMIE
STOPIEN_
NAUKOWY
DATA_
URODZENIA
I np. w przypadku podzia≥u danych na wyraünie odseparowane
1 Kowalski Jan mgr 1972-01-23 podsystemy lub w rozproszonej bazie danych
2 Wiśniewski Józef dr inż. 1958-11-03 I najczÍúciej jednak úwiadczπ o niepotrzebnym podzieleniu danych na
... ... ... ... ... dwie tabele
I Realizacja
I klucz obcy jak dla 1 n
I dodatkowe ograniczenie wymuszajπce unikalnoúÊ (niepowtarzalnoúÊ)
PRZEDMIOTY
wartoúci klucza obcego (czyli klucz obcy bÍdπcy rzeczywiúcie
# KOD_PRZEDMIOTU TYTUL OPIS ID_NAUCZYCIELA
kluczem)
BD Bazy danych Wykład 2
obejmuje...
XML Język XML Wykład 2
porusza...
... ... ... ...
Zwiπzki referencyjne Zwiπzki referencyjne
Przyk≥ad: zwiπzek n m
NAUCZYCIELE
# ID_ STOPIEN_ DATA_
NAZWISKO IMIE
Zwiπzki wiele do wielu (n m) NAUCZYCIELA NAUKOWY URODZENIA
1 Kowalski Jan mgr 1972-01-23
I Nie dadzπ siÍ zrealizowaÊ bezpoúrednio 2 Wiśniewski Józef dr inż. 1958-11-03
I Realizuje siÍ tworzπc dodatkowπ tabelÍ, tzw. tabelÍ intersekcji ... ... ... ... ...
I wiersze odpowiadajπ powiπzanym parom wierszy zwiπzanych tabel PROWADZENIE_CWICZEN
I kolumny sπ to klucze obce wskazujπce na klucze g≥ówne obu # KOD_PRZEDMIOTU # ID_NAUCZYCIELA
BD 1
zwiπzanych tabel XML 1
I klucz g≥ówny zawiera wszystkie kolumny obu kluczy obcych BD 2
I Niekiedy w tabeli intersekcji tworzy siÍ dodatkowe kolumny XML 2
I np. odpowiadajπce tzw. atrybutom asocjacyjnym, które opisujπ sam ... ...
zwiπzek, a nie zwiπzane dane PRZEDMIOTY
# KOD_PRZEDMIOTU TYTUL OPIS ID_NAUCZYCIELA
BD Bazy danych Wykład 2
obejmuje...
XML Język XML Wykład 2
porusza...
... ... ... ...
Operacje na tabelach relacyjnych Operacje na tabelach relacyjnych
Z≥πczenie
Operacje na tabelach relacyjnych Z≥πczenie
I Operacja na dwóch relacjach – po≥πczenie wierszy dwóch tabel
I Selekcja (restrykcja) – wybranie jedynie niektórych krotek (wierszy), I wynikowe wiersze sπ konkatenacjπ (sklejeniem) wierszy tabel
spe≥niajπcych pewien warunek wyjúciowych
I ≥πczone sπ te wiersze, które razem spe≥niajπ tzw. warunek z≥πczenia
I Projekcja (rzut) – wybranie jedynie niektórych atrybutów (kolumn)
I Operacje mnogoúciowe: suma, przeciÍcie (iloczyn), róønica I Rodzaje z≥πczeÒ
I na krotkach relacji o takim samym schemacie I równoúciowe – warunek równoúciowy
I traktujπce krotki (wiersze) jak elementy zbiorów I naturalne – równoúciowe i nazwy atrybutów zgodne
I Z≥πczenie I iloczyn kartezjaÒski – bez warunku (z warunkiem zawsze
prawdziwym) – na ogó≥ niepoøπdany
I Z≥πczenia sprawiajπ problemy wydajnoúciowe
Operacje na tabelach relacyjnych Redundancja i normalizacja
Z≥πczenie Redundancja i anomalie
Redundancja i anomalie
Przyk≥ad: z≥πczenie
PRZEDMIOTY
NAUCZYCIELE # KOD_PRZEDMIOTU TYTUL OPIS ID_NAUCZYCIELA
# ID_
NAUCZYCIELA
NAZWISKO IMIE
STOPIEN_
NAUKOWY
DATA_
URODZENIA
BD Bazy danych Wykład obejmuje... 2 Redundancja
2 Wiśniewski
... ...
Józef
...
dr inż.
...
1958-11-03
...
XML Język XML Wykład porusza... 2 I Jest to powtarzanie siÍ informacji
I W bazach danych jest groüna
... ... ... ...
I prowadzi do ryzyka anomalii aktualizacji
ID_
NAUCZYCIELA
NAZWISKO IMIE
STOPIEN_
NAUKOWY
DATA_
URODZENIA
KOD_
PRZEDMIOTU
TYTUL OPIS
ID_
NAUCZYCIELA2
I powoduje marnowanie miejsca
I Typowe przyczyny wystÍpowania redundancji
Wykład
2 Wiśniewski Józef dr inż. 1958-11-03 BD Bazy danych 2
obejmuje...
Wykład
2 Wiśniewski Józef dr inż. 1958-11-03 XML Język XML
porusza...
2
I b≥Ídne po≥πczenie danych w jednej tabeli
... ... ... ... ... ... ... ... ...
I przechowywanie agregatów (wyników obliczeÒ)
Redundancja i normalizacja Redundancja i normalizacja
Redundancja i anomalie Redundancja i anomalie
Przyk≥ad: anomalie aktualizacji
# ID PRACOWNIKA NAZWISKO IMIE STANOWISKO PENSUM
Anomalie aktualizacji 1 Kowalski Jan Asystent 240
I Niekorzystne zjawiska wystÍpujπce przy manipulowaniu danymi 2 Wiúniewska Józefina Asystent 240
... ... ... ... ...
I Mogπ prowadziÊ do utraty spójnoúci danych
I np. do „rozjechania” siÍ redundantnych kopii danych I Pensum dla danego stanowiska jest okreúlone jednoznacznie
I Sπ niebezpieczne w systemach OLTP I B≥Ídnie po≥πczono dane nauczycieli i stanowisk
I duøo „ma≥ych” aktualizacji
I Redundancja: pary wartoúci stanowisko – pensum powtarzajπ siÍ
I w warunkach wielodostÍpu
I WystÍpujπ anomalie aktualizacji
I W strukturach redundantnych by przeciwdzia≥aÊ anomaliom trzeba
I wstawiania: nie moøna zdefiniowaÊ stanowiska i pensum nie
programowo utrzymywaÊ spójnoúÊ redundantnych danych, co jest przypisujπc jednoczeúnie pracownika (wstawienie NULL-i nie jest
trudne i obniøa wydajnoúÊ manipulacji danymi moøliwe ze wzglÍdu na klucz g≥ówny)
I usuwania: usuniÍcie ostatniego pracownika zatrudnionego na danym
stanowisku spowoduje znikniÍcie definicji stanowiska
I modyfikacji: nieostroøne zmodyfikowanie pensum tylko jednego
pracownika prowadziÊ moøe do niespójnoúci danych
Postacie normalne Postacie normalne
Normalizacja schematów relacyjnych Pierwsza postaÊ normalna
Relacja jest w 1NF gdy wszystkie jej atrybuty sπ atomowe, tj.
przechowujπ pojedynczπ informacjÍ
Jak zapobiec anomaliom I nie sπ strukturami – muszπ byÊ prostych typów
I Naleøy projektowaÊ struktury nie zawierajπce redundancji I nie sπ kolekcjami – kaøda krotka (wiersz) przechowuje informacje
I W unikaniu redundancji pomaga znajomoúÊ tzw. postaci normalnych o jednym obiekcie
I W praktyce I nie sπ uniami (rekordami z wariantami) – dane majπ zawsze to samo
I dπøy siÍ do tworzenia od razu poprawnych struktur znaczenie
I postaci normalnych uøywa siÍ co najwyøej do sprawdzenia
poprawnoúci I AtomowoúÊ atrybutów jest koniecznym warunkiem moøliwoúci
skutecznego zastosowania rachunku relacyjnego
I a zatem i sensownego oraz wydajnego dzia≥ania jÍzyka zapytaÒ!
Przyk≥ad: jawne z≥amanie 1NF
1060-GI000-ISP-2009 Przyk≥ad: zakamuflowane z≥amanie 1NF
I Niepoprawnie po≥πczono # NR UCZNIA # NR SEMESTRU OCENA 1 OCENA 2 ... OCENA 20
I identyfikator przedmiotu: 1060...2009
I informacjÍ o rodzaju studiów: ISP
I Wszystkie atrybuty sπ prostych typów
I informacjÍ o kierunku i specjalnoúci studiów: GI000 I Ale logicznie tabela ≥amie 1NF: kolumny OCENA 1, OCENA 2,. . . ≥πcznie
I Konsekwencje stanowiπ w istocie kolumnÍ z≥oøonπ (tablicÍ zanurzonπ w tabeli)
I kod jest niepotrzebnie d≥ugi I Tabela taka nie da siÍ efektywnie odpytywaÊ za pomocπ relacyjnych
I informacje o kierunku i rodzaju studiów sπ niepotrzebnie jÍzyków zapytaÒ
ograniczajπce: potrzebne sπ tu zwiπzki 1 n I Naleøy jπ zorganizowaÊ inaczej: „w dó≥” a nie „w poprzek”
I jeúli specjalnoúci brak konieczna „zaúlepka”: 000
I jeúli przypisanie przedmiotu np. do specjalnoúci zmieni siÍ, kod # NR UCZNIA # NR SEMESTRU # NR OCENY OCENA
(niezmienny!) bÍdzie zawieraÊ mylπce informacje!
I Rozwiπzanie poprawne to np. 1060-2009
I 1060 jest kodem przestrzeni nazw, zapobiegajπcym konfliktom
Zaleønoúci funkcyjne Druga postaÊ normalna
Relacja jest w 2NF gdy kaødy atrybut niekluczowy (nie naleøπcy do
øadnego klucza w≥aúciwego) jest zaleøny funkcyjnie od ca≥ego klucza
Zbiór atrybutów Y jest zaleøny funkcyjnie od zbioru X gdy z kaødπ w≥aúciwego
konfiguracjπ wartoúci atrybutów z X jest zwiπzana co najwyøej jedna Przyk≥ad: z≥amanie 2NF
konfiguracja wartoúci z Y # ID NAUCZYCIELA # KOD PRZEDMIOTU TYTUL OPIS
I Kaødy atrybut i ca≥y schemat zaleøπ funkcyjnie od klucza 1 BD Bazy danych Wyk≥ad obejmuje...
1 XML JÍzyk XML Wyk≥ad poúwiÍcony jest...
2 BD Bazy danych Wyk≥ad obejmuje...
Przyk≥ad 2 XML JÍzyk XML Wyk≥ad poúwiÍcony jest...
ID PRACOWNIKA NAZWISKO IMIE ... ... ... ...
I ImiÍ i nazwisko zaleøπ funkcyjnie od id pracownika I B≥Ídnie po≥πczono realizacjÍ zwiπzku n m z danymi przedmiotów:
anomalie sπ spowodowane powtarzaniem danych przedmiotu
I Id nie zaleøy funkcyjnie od imienia ani nazwiska
I Tabela ≥amie 2NF: dane przedmiotu nie zaleøπ od ca≥ego klucza
I ImiÍ nie zaleøy funkcyjnie od nazwiska
ID NAUCZYCIELA+KOD PRZEDMIOTU, ale tylko od jego czÍúci
I Problem rozwiπzuje zaprojektowanie dwóch tabel:
# ID NAUCZYCIELA # KOD PRZEDMIOTU # KOD PRZEDMIOTU TYTUL OPIS
Trzecia postaÊ normalna Trzecia postaÊ normalna, c.d.
Relacja jest w 3NF gdy kaødy atrybut niekluczowy jest bezpoúrednio
(nieprzechodnio) zaleøny funkcyjnie od ca≥ego klucza w≥aúciwego
Przyk≥ad: z≥amanie 3NF
# ID PRACOWNIKA NAZWISKO IMIE STANOWISKO PENSUM I 3NF jest zazwyczaj wystarczajπca dla usuniÍcia praktycznie waønych
1 Kowalski Jan Asystent 240
2 Wiúniewska Józefina Asystent 240 anomalii
... ... ... ... ... I Kaødy schemat moøna doprowadziÊ do 3NF zachowujπc:
I zaleønoúci
I B≥Ídnie po≥πczono dane nauczycieli z danymi stanowisk: anomalie sπ
I odwracalnoúÊ rozk≥adu
spowodowane powtarzaniem siÍ pensum przypisanego do stanowiska
I Postacie normalne wyøsze od 3NF nie majπ tej cechy
I Tabela ≥amie 3NF: pensum zaleøy od klucza Id nauczyciela
w sposób niebezpoúredni (czyli tranzytywny) – za poúrednictwem
stanowiska
I Problem rozwiπzuje zaprojektowanie dwóch tabel:
# ID NAUCZYCIELA NAZWISKO IMIE STANOWISKO # STANOWISKO PENSUM
Normalizacja3 – podsumowanie PrzysiÍga relacyjna
Zwiπzki miÍdzy postaciami normalnymi:
. . . 4NF ) BCNF ) 3NF ) 2NF ) 1NF
Zalecenie projektowe
Struktury relacyjne w systemach transakcyjnych (OLTP) powinny byÊ
przynajmniej w 3NF The key, the whole key,
OdstÍpstwa and nothing but the key.
I OdstÍpstwa od ww. zalecenia wynikaÊ mogπ jedynie z powaønych So help me Codd.
problemów wydajnoúciowych
I W kaødym wypadku projekt struktury powinien najpierw byÊ
znormalizowany, a dopiero po podjÍciu úwiadomej decyzji
o odstÍpstwie od normalizacji moøe byÊ denormalizowany
I Normalizacja jest tym bardziej konieczna, im waøniejszπ rolÍ
w systemie pe≥niπ operacje DML
3 Normalizacja nie oznacza tu czynnoúci projektowej, lecz poøπdany stan projektu
BD.2 – Relacyjny model danych
Podsumowanie
Podsumowanie
I Relacyjny model danych jest modelem prostym, uniwersalnym
i o dobrych podstawach teoretycznych
I Model ten jest dominujπcy, zw≥aszcza w zastosowaniach biznesowych
I Tabela relacyjna (relacja) ma ustalone kolumny (nazwy, typy danych),
ale zmiennπ liczbÍ i nieustalonπ kolejnoúÊ wierszy
I NULL oznacza wartoúÊ nieznanπ albo nieistniejπcπ – skutki sπ róøne!
I Operacje relacyjne w wyniku dajπ tabele relacyjne;
operacja z≥πczenia sprawia problemy wydajnoúciowe
I Wiersze w tabeli relacyjnej nie majπ adresów ani numerów,
do identyfikacji wiersza moøna uøywaÊ wy≥πcznie kluczy
I Kaøda tabela powinna mieÊ klucz g≥ówny spe≥niajπcy wymagania
I Redundancja jest groüna gdyø prowadzi do anomalii modyfikacji
I Postacie normalne zapewniajπ eliminacjÍ róønych rodzajów redundancji;
w systemach OLTP kaøda tabela powinna byÊ przynajmniej w 3NF
T. Traczyk IAiIS PW Bazy danych 32/32
BD.3 – JÍzyk SQL BD.3 – JÍzyk SQL
Czym jest SQL Czym jest SQL
DostÍp do danych Wprowadzenie do SQL
DostÍp do danych JÍzyk SQL
Metody dostÍpu do danych Znaczenie jÍzyka SQL (Structured Query Language)
I Zwracajπce struktury I JÍzyk zapytaÒ – deklaratywny dostÍp do danych
I wynikiem jest struktura tego samego typu, co istniejπce w bazie (np. I Sk≥adnia dosyÊ ≥atwa i naturalna (choÊ daleka od doskona≥oúci)
tabela) I Moøny protektor (IBM)
I wymaga podania warunków, które musi spe≥niaÊ wynik
I Standardowy jÍzyk dostÍpu do danych
I algorytm jest wypracowywany przez optymalizator zapytaÒ w DBMS
I jÍzyki nieproceduralne (deklaratywne): SQL I dla wszystkich liczπcych siÍ RDBMS
I normy ANSI i ISO
I Nawigacyjne I wiele dialektów s≥abo zgodnych z normami
I rekord po rekordzie I Szczególnie przydatny
I zwykle rekord = wiersz tabeli
I I w systemach klient-serwer i wielowarstwowych: zasada „zapytanie do
wymaga zaprogramowania algorytmu dostÍpu
I wspó≥czeúnie uøywa siÍ po≥πczenia SQL i jÍzyków proceduralnych danych”
I w systemach heterogenicznych: wspólny model operowania na
(np. C/C++ z zanurzonym SQL, Java z JDBC)
danych relacyjnych
Czym jest SQL Czym jest SQL
Wprowadzenie do SQL Wprowadzenie do SQL
årodowiska wykonania jÍzyka SQL
CzÍúci jÍzyka SQL
I Konsole SQL
I DQL (Data Query Language)
I do wyszukiwania danych I Programy typu QBA (Query By Example)
I zdania SELECT I Programy analityczne
I DML (Data Manipulation Language) I Aplikacje w jÍzykach 4GL
I do modyfikacji danych I Zanurzony SQL (embedded SQL): specjalne konstrukcje odczytujπce
I zdania INSERT, UPDATE, DELETE
wynik zapytania wiersz po wierszu
I DDL (Data Definition Language)
I ODBC: interfejs typu API, takøe do oprogramowania biurowego (np.
I do tworzenia i modyfikacji struktur danych
I zdania CREATE, DROP, ALTER i inne
Excel)
I JDBC: interfejs typu API do programów w jÍzyku Java
Zapytania SQL w przyk≥adach Zapytania SQL w przyk≥adach
Zdanie SELECT
SQL w przyk≥adach Zdanie SELECT
Przyk≥adowa struktura danych do zapytaÒ Odczyt ca≥ej tabeli
I W zapytaniu zamiast nazw kolumn uøywa siÍ gwiazdki
I Dane wyk≥adowców i przedmiotów
I zwiπzek 1 n I KolejnoúÊ zwróconych wierszy jest losowa
I zwiπzek rekurencyjny oznaczajπcy SELECT * FROM przedmioty
hierarchiÍ KOD_PR NAZWA ID_WYKL LICZBA_GODZ
------ ----------------------------------- ------- -----------
OTW Ogólna teoria wszystkiego 1 4
STNR Szczególna teoria niektórych rzeczy 1 3
WDPZ Wprowadzenie do podstaw zarysu 2 2
TPUP Teoretyczne podstawy umiejÍtnoúci 5 2
praktycznych
SELECT * FROM wykladowcy
ID_WYKLADOWCY NAZWISKO IMIONA TYTUL DATA_ZAT ID_PRZELOZONEGO
------------- ---------- ------------ -------- -------- ---------------
1 ABACKI Adam prof. 87/09/02
2 BABACKI Bogdan dr 93/09/04 1
3 CABACKI Czes≥aw mgr 95/09/02 2
4 DABACKI Dominik dr 94/12/04 1
5 EBACKI Eugeniusz mgr 96/04/17 2
Zdanie SELECT Zdanie SELECT
Projekcja i sortowanie
I Kolumny wymienia siÍ w klauzuli SELECT (!) Projekcja i selekcja
I Klauzula ORDER BY wymusza kolejnoúÊ wierszy I Klauzula WHERE wybiera wiersze spe≥niajπce warunek
select kod_przedmiotu, nazwa SELECT kod_przedmiotu, nazwa
from przedmioty FROM przedmioty
order by kod_przedmiotu WHERE liczba_godzin=2
KOD_PR NAZWA KOD_PR NAZWA
------ ----------------------------------------------------- ------ --------------------------------------------------
OTW Ogólna teoria wszystkiego WDPZ Wprowadzenie do podstaw zarysu
STNR Szczególna teoria niektórych rzeczy TPUP Teoretyczne podstawy umiejÍtnoúci praktycznych
TPUP Teoretyczne podstawy umiejÍtnoúci praktycznych
WDPZ Wprowadzenie do podstaw zarysu
Z≥πczenia Z≥πczenia
Z≥πczenie wyraøone przez WHERE
Z≥πczenie wyraøone przez JOIN
I Z≥πczenie moøna wyraziÊ zwyk≥ym warunkiem WHERE
I Z≥πczenie moøna teø wyraziÊ specjalnπ konstrukcjπ JOIN
I PominiÍcie warunku daje iloczyn kartezjaÒski wierszy!
I Jest to czytelniejsze i moøe byÊ ≥atwiejsze do optymalizacji
I Uøyto aliasów kolumn i tabel
SELECT nazwisko as Prowadzπcy, nazwa as Przedmiot
SELECT nazwisko as prowadzπcy, nazwa as przedmiot
FROM wykladowcy w JOIN przedmioty p ON w.id_wykladowcy=p.id_wykladowcy
FROM wykladowcy w, przedmioty p
ORDER BY nazwisko, nazwa
WHERE w.id_wykladowcy = p.id_wykladowcy
ORDER BY nazwisko, nazwa PROWADZ•CY PRZEDMIOT
--------------- ----------------------------------------------
PROWADZ•CY PRZEDMIOT ABACKI Ogólna teoria wszystkiego
--------------- ---------------------------------------------- ABACKI Szczególna teoria niektórych rzeczy
ABACKI Ogólna teoria wszystkiego BABACKI Wprowadzenie do podstaw zarysu
ABACKI Szczególna teoria niektórych rzeczy EBACKI Teoretyczne podstawy umiejÍtnoúci praktycznych
BABACKI Wprowadzenie do podstaw zarysu
EBACKI Teoretyczne podstawy umiejÍtnoúci praktycznych
Z≥πczenie naturalne
I Z≥πczenie naturalne (równoúciowe, takie same nazwy kolumn) moøna
wyraziÊ konstrukcjπ NATURAL JOIN Z≥πczenie zewnÍtrzne
I Bywa to zdradliwe: nazwy kolumn mogπ siÍ dopasowaÊ przez
I Zwyk≥e z≥πczenie
przypadek
I jest podzbiorem iloczynu kartezjaÒskiego wierszy
SELECT nazwisko as prowadzπcy, nazwa as przedmiot
FROM wykladowcy NATURAL JOIN przedmioty I zawiera zatem tylko takie pary, gdzie w obu tabelach istnia≥y
ORDER BY nazwisko, nazwa „pasujπce” wiersze
PROWADZ•CY
---------------
PRZEDMIOT
----------------------------------------------
I CzÍsto chcemy innego dzia≥ania
ABACKI
ABACKI
Ogólna teoria wszystkiego
Szczególna teoria niektórych rzeczy
I wszystkie wiersze z jednej tabeli
BABACKI
EBACKI
Wprowadzenie do podstaw zarysu
Teoretyczne podstawy umiejÍtnoúci praktycznych I dopasowane wiersze z drugiej, a jeúli ich nie ma, to „puste miejsce”
I tak dzia≥a tzw. z≥πczenie zewnÍtrzne (outer join)
I Mniej zdradliwa jest konstrukcja, gdzie nazwy porównywanych
kolumn wymienia siÍ jawnie
FROM wykladowcy JOIN przedmioty USING (id_wykladowcy)
Z≥πczenie zewnÍtrzne wyraøone przez WHERE
I Znak (+) oznacza z≥πczenie zewnÍtrzne: umieszcza siÍ go po Z≥πczenie zewnÍtrzne wyraøone przez JOIN
stronie, która ma byÊ uzupe≥niona „pustym miejscem” I Z≥πczenie zewnÍtrzne moøna takøe wyraziÊ przez JOIN
I „Puste miejsce” sπ to wartoúci NULL I S≥owa LEFT | RIGHT oznaczajπ, po której stronie ma byÊ
SELECT nazwisko as Prowadzπcy, nazwa as Przedmiot uzupe≥nianie „pustym miejscem”
FROM wykladowcy w, przedmioty p
WHERE w.id_wykladowcy = p.id_wykladowcy (+)
FROM wykladowcy w LEFT JOIN przedmioty p
ON w.id_wykladowcy=p.id_wykladowcy
PROWADZ•CY PRZEDMIOT ORDER BY nazwisko, nazwa
-------------- ----------------------------------------------
ABACKI Ogólna teoria wszystkiego lub
ABACKI Szczególna teoria niektórych rzeczy SELECT nazwisko as Prowadzπcy, nazwa as Przedmiot
BABACKI Wprowadzenie do podstaw zarysu
CABACKI FROM wykladowcy NATURAL LEFT JOIN przedmioty
DABACKI ORDER BY nazwisko, nazwa
EBACKI Teoretyczne podstawy umiejÍtnoúci praktycznych
Z≥πczenia Klauzula DISTINCT
Poszukiwanie „niedopasowanych” wierszy
I Aby znaleüÊ „niedopasowane” wiersze trzeba wykonaÊ z≥πczenie Wyszukanie niejednakowych wierszy
zewnÍtrzne I Klauzula DISTINCT eliminuje z wyniku zapytania powtórzone wiersze
I Z jego wyniku trzeba wybraÊ tylko te wiersze, gdzie po jednej stronie
I Przydaje siÍ, gdy
wystπpi≥y wartoúci NULL I chcemy znaleüÊ wszystkie wystÍpujπce wartoúci jakiejú danej
Zapytanie zwracajπce nazwiska wyk≥adowców, którzy nie prowadzπ I bez wzglÍdu na liczbÍ wystπpieÒ
øadnego przedmiotu:
SELECT DISTINCT id_wykladowcy
SELECT nazwisko as Prowadzπcy FROM przedmioty
FROM wykladowcy w LEFT JOIN przedmioty p
ON w.id_wykladowcy=p.id_wykladowcy ID_WYKLADOWCY
WHERE p.kod_przedmiotu IS NULL -------------
1
ORDER BY nazwisko 2
PROWADZ•CY 5
-------------------------
CABACKI
DABACKI
Funkcje grupujπce Funkcje grupujπce
Zapytania z funkcjami grupujπcymi Agregacja niejednakowych wartoúci
I Funkcje grupujπce (agregujπce) SELECT COUNT(DISTINCT id_wykladowcy) FROM przedmioty
I COUNT(*) – zlicza wszystkie wiersze COUNT(DISTINCT ID_WYKLADOWCY)
I COUNT(kolumna) – pomija wartoúci NULL -----------------------------
3
I MIN, MAX – znajdujπ najmniejszπ/najwiÍkszπ wartoúÊ
I SUM – sumuje
I AVG – oblicza úredniπ arytmetycznπ
I Zliczanie a z≥πczenie zewnÍtrzne
VARIANCE, STDDEV – obliczajπ wariancjÍ i odchylenie standardowe
I Klauzula GROUP BY wyznacza sposób grupowania I W wyniku zliczenia pojawiajπ siÍ zera
I Musi w niej siÍ znaleüÊ ca≥a zawartoúÊ klauzuli SELECT oprócz SELECT w.id_wykladowcy, nazwisko, COUNT(kod_przedmiotu)
elementów uøywajπcych funkcji grupujπcych FROM wykladowcy w LEFT JOIN przedmioty p
ON w.id_wykladowcy = p.id_wykladowcy
SELECT w.id_wykladowcy, nazwisko, COUNT(kod_przedmiotu) GROUP BY w.id_wykladowcy, nazwisko
FROM wykladowcy w JOIN przedmioty p ON w.id_wykladowcy=p.id_wykladowcy ID_WYKLADOWCY NAZWISKO COUNT(KOD_PRZEDMIOTU)
GROUP BY w.id_wykladowcy, nazwisko ------------- ------------------------- --------------------
1 ABACKI 2
ID_WYKLADOWCY NAZWISKO COUNT(KOD_PRZEDMIOTU) 2 BABACKI 1
------------- ------------------------- -------------------- 3 CABACKI 0
1 ABACKI 2 4 DABACKI 0
2 BABACKI 1 5 EBACKI 1
5 EBACKI 1
Funkcje grupujπce Operatory mnogoúciowe
Operatory mnogoúciowe
I Dzia≥ajπ na wynikach dwóch zapytaÒ dajπcych wyniki o takiej samej
Warunek na wynik agregacji
strukturze
I Klauzule WHERE i JOIN wybierajπ wiersze przed agregacjπ I liczba kolumn zwracanych przez oba zapytania musi byÊ równa
I Klauzula HAVING wybiera wyniki agregacji I ich typy muszπ byÊ odpowiednio takie same
I nazwy i d≥ugoúci kolumn mogπ siÍ róøniÊ
Zapytanie zwracajπce dane tylko takich wyk≥adowców, którzy prowadzπ I DostÍpne operatory
co najmniej dwa przedmioty: I UNION – suma teoriomnogoúciowa
SELECT w.id_wykladowcy, nazwisko, COUNT(kod_przedmiotu) I UNION ALL – suma w sensie wielozbioru
FROM wykladowcy w, przedmioty p I MINUS – róønica teoriomnogoúciowa
WHERE w.id_wykladowcy = p.id_wykladowcy I INTERSECT – iloczyn teoriomnogoúciowy (przeciÍcie)
GROUP BY w.id_wykladowcy, nazwisko
HAVING COUNT(kod_przedmiotu) >= 2 SELECT nazwa as has≥o FROM przedmioty
ID_WYKLADOWCY NAZWISKO COUNT(KOD_PRZEDMIOTU) UNION HAS£O
----------------------------------------------
------------- ------------------------- -------------------- SELECT nazwisko FROM wykladowcy Abacki
1 ABACKI 2 ORDER BY has≥o Babacki
Cabacki
Dabacki
Ebacki
Ogólna teoria wszystkiego
Szczególna teoria niektórych rzeczy
Teoretyczne podstawy umiejÍtnoúci praktycznych
Wprowadzenie do podstaw zarysu
Zapytania z≥oøone Zapytania z≥oøone
Zapytania z≥oøone
Porównania z wynikiem podzapytania
I Operatory pozwalajπce dokonywaÊ porównaÒ z wynikiem
podzapytania
I operatory porównaÒ (podzapytanie musi zwracaÊ dok≥adnie 1 wiersz)
I [NOT] IN
I [NOT] EXISTS
I Zapytania z≥oøone zawierajπ podzapytania I operator porównania ANY
I w klauzuli WHERE I operator porównania ALL
I w klauzuli FROM lub SELECT
Poniøsze zapytanie pozwala znaleüÊ dane wyk≥adowców, którzy prowadzπ
I Mogπ byÊ z≥oøone wielokrotnie wyk≥ady majπce w nazwie s≥owo „teoria”
SELECT tytul, nazwisko FROM wykladowcy
WHERE id_wykladowcy IN
(SELECT id_wykladowcy FROM przedmioty WHERE nazwa LIKE ’%teoria%’)
TYTUL NAZWISKO
-------------------- ---------------
prof. ABACKI
Zapytania z≥oøone Zapytania z≥oøone
Zapytania z≥oøone z funkcjami grupujπcymi
Zapytania z≥oøone z odwo≥aniem skorelowanym
I Znajdowanie danych zwiπzanych z maksimum/minimum
I Moøna uøyÊ wartoúci z zapytania g≥ównego w warunku podzapytania
I nie da siÍ tego zrobiÊ prostym zapytaniem
I Typowe jest uøycie odwo≥ania skorelowanego w po≥πczeniu I trzeba uøyÊ definicji maksimum/minimum, wykorzystujπc operator
z operatorem EXISTS ALL
Zapytanie zwracajπce nazwiska tych wyk≥adowców, którzy prowadzπ I Konstrukcja tego zapytania, choÊ typowa dla SQL, nie jest ≥atwa do
jakieú wyk≥ady (w klauzuli SELECT uøyto NULL jako zaúlepki, bo interesuje wymyúlenia!
nas tylko czy sπ wiersze): Zapytanie znajduje nazwisko takiego wyk≥adowcy, który prowadzi
SELECT nazwisko FROM wykladowcy w najwiÍcej wyk≥adów, i liczbÍ prowadzonych przez niego wyk≥adów:
WHERE EXISTS
(SELECT NULL FROM przedmioty p SELECT w.id_wykladowcy, nazwisko, COUNT(*)
WHERE w.id_wykladowcy = p.id_wykladowcy) FROM wykladowcy w JOIN przedmioty p ON w.id_wykladowcy=p.id_wykladowcy
GROUP BY w.id_wykladowcy, nazwisko
NAZWISKO HAVING COUNT(*) >= ALL
-------------- (SELECT COUNT(*) FROM przedmioty GROUP BY id_wykladowcy)
ABACKI
BABACKI ID_WYKLADOWCY NAZWISKO COUNT(*)
EBACKI ------------- --------------- ---------
1 ABACKI 2
Zapytania SQL w przyk≥adach Inne elementy zapytaÒ SQL
Zapytania z≥oøone Wyraøenia w SQL
Podzapytania w klauzuli FROM Wyraøenia w SQL
I Pozwalajπ na „zagnieødøanie” zapytaÒ Wyraøenia
I Znacznie u≥atwiajπ pisanie z≥oøonych zapytaÒ I Z≥oøone ze sta≥ych, kolumn, operatorów, wywo≥aÒ funkcji
I Konwersje sπ niejawne - zaleca siÍ wykonywanie jawnych konwersji
Wyliczenie obciπøenia godzinowego i liczby przedmiotów prowadzonych
przez wyk≥adowców:
Sta≥e
SELECT w.id_wykladowcy, nazwisko, obciazenie, liczba_przedmiotow
FROM wykladowcy w, I Liczbowe – wprost
(SELECT id_wykladowcy, SUM(liczba_godzin) AS obciazenie I Znakowe – w ’...’
FROM przedmioty GROUP BY id_wykladowcy I Daty – w formacie domyúlnym lub przez funkcje konwersji
) o, I NULL
(SELECT id_wykladowcy, COUNT(*) AS liczba_przedmiotow
FROM przedmioty GROUP BY id_wykladowcy
Operatory
) l
WHERE w.id_wykladowcy = o.id_wykladowcy I Arytmetyczne: + - * /
AND w.id_wykladowcy = l.id_wykladowcy I Logiczne: NOT, AND, OR
ORDER BY nazwisko; I Konkatenacja wartoúci znakowych: ||
ID_WYKLADOWCY NAZWISKO OBCIAZENIE LICZBA_PRZEDMIOTOW I Porównania: =, != ^= <>, >, <, >=, <=
------------- ------------------------- ---------- ------------------ I BETWEEN x AND y
1 ABACKI 7 2 I LIKE – znaki specjalne: %
2 BABACKI 2 1 I IN, IN, ANY, ALL, EXISTS
5 EBACKI 2 1
I IS NULL, IS NOT NULL
Inne elementy zapytaÒ SQL Inne elementy zapytaÒ SQL
Wyraøenia w SQL NULL
WartoúÊ NULL
Funkcje wbudowane
I Róøne w kaødym z DBMS Znaczenie wartoúci NULL
I Typowe rodzaje I Interpretacja wartoúci NULL
I agregujπce I wartoúÊ nieznana
I znakowe I wartoúÊ nieadekwatna/nieistniejπca
I matematyczne I Uøycie NULL
I data/czas I interpretacja NULL w warunkach
I konwersje I w zapytaniu warunek o wartoúci NULL jest uwaøany za niespe≥niony
I w wiÍzach kontrolnych warunek o wartoúci NULL jest uwaøany za
spe≥niony
Funkcje uøytkownika
I NULL w indeksach: wartoúci zerowe mogπ nie byÊ uwzglÍdnione
I DostÍpne w lepszych DBMS w indeksach
I Pisane w specjalnym wbudowanym jÍzyku I w przypadkach wπtpliwych naleøy uøywaÊ funkcji zastÍpujπcej NULL
I By móc byÊ uøyte w SQL muszπ spe≥niaÊ szereg warunków, m.in. nie wartoúciπ zastÍpczπ, np. NVL
powodowaÊ efektów ubocznych I Do reprezentowania wartoúci nieznanej lub nieadekwatnej naleøy
zawsze uøywaÊ NULL
Inne elementy zapytaÒ SQL DML
NULL
DML (Data Manipulation Language)
NULL w wyraøeniach
I Wyraøenie którego operand ma wartoúÊ NULL takøe przyjmuje
wartoúÊ NULL I Typy zdaÒ
I Wyjπtki I UPDATE – zmiana wierszy
I funkcje agregujπce (wiersze z wartoúciπ NULL sπ pomijane) I INSERT – dodawanie wierszy
I wyraøenia logiczne: NULL or TRUE, NULL and FALSE I DELETE – usuwanie wierszy
I Do wykrywania wartoúci NULL I S≥uøπ one do zmieniania zawartoúci tabel
I uøywaÊ operatorów IS NULL, IS NOT NULL
I nie uøywaÊ porównaÒ
DML DML
Transakcje w SQL UPDATE
Zdania UPDATE
Transakcje I S≥uøπ do modyfikacji danych w juø istniejπcych wierszach tabel
I W profesjonalnych DBMS modyfikacje danych przebiegajπ wy≥πcznie I Zdania UPDATE bez klauzuli WHERE powodujπ zmianÍ wszystkich
w trybie transakcji wierszy w tabeli!
I Transakcje zapewniajπ:
Zmiana z podstawieniem sta≥ych
I niepodzielnoúÊ zestawu operacji: „albo wszystko, albo nic”
UPDATE przedmioty
I wielodostÍp: izolacjÍ, rozstrzyganie konfliktów SET id_wykladowcy=4, liczba_godzin=2
I bezpieczeÒstwo: spójnoúÊ danych po transakcji, trwa≥oúÊ zapisu WHERE kod_przedmiotu=’STNR’
I Transakcje sπ niezbÍdne do bezpiecznego przetwarzania danych
Zmiana z uøyciem podzapytaÒ
w warunkach wielodostÍpu
Poniøsze zdanie zmienia wyk≥adowcÍ na Dabackiego dla przedmiotu
I Sterowanie transakcjami w SQL
o nazwie zaczynajπcej siÍ od „Szczególna”:
I poczπtek automatycznie – niejawnie
I koniec jawnie: COMMIT – zatwierdzenie, ROLLBACK – odrzucenie UPDATE przedmioty
SET id_wykladowcy =
(SELECT id_wykladowcy FROM wykladowcy WHERE nazwisko=’DABACKI’)
WHERE kod_przedmiotu =
(SELECT kod_przedmiotu FROM przedmioty WHERE nazwa LIKE ’Szczególna%’)
DML DML
INSERT DELETE
Zdania INSERT Zdania DELETE
I S≥uøπ do dodawania nowych wierszy do tabeli
I Trzeba jawnie okreúliÊ wartoúci dla wszystkich takich kolumn, które
I nie mogπ zawieraÊ wartoúci NULL I S≥uøπ do usuwania wierszy
I i nie majπ zdefiniowanych wartoúci domyúlnych
I Zdanie DELETE bez klauzuli WHERE powoduje usuniÍcie wszystkich
Wstawienie wiersza wype≥nionego podanymi wartoúciami wierszy tabeli!
INSERT INTO wykladowcy (id_wykladowcy, nazwisko, imiona)
VALUES (6, ’FABACKI’, ’Felicjan’) Kasowanie z uøyciem operatora IN
I ListÍ wype≥nianych kolumn moøna pominπÊ, jeúli wstawia siÍ DELETE FROM wykladowcy
wartoúci do wszystkich kolumn i to w kolejnoúci zgodnej z definicjπ WHERE id_wykladowcy IN (3, 4)
tabeli
Kasowanie z uøyciem podzapytania
DELETE FROM przedmioty
Wstawianie wierszy na podstawie podzapytania WHERE id_wykladowcy IN
INSERT INTO wykladowcy (id_wykladowcy, nazwisko, imiona) (SELECT id_wykladowcy FROM wykladowcy
SELECT id_wykladowcy, nazwisko, imiona FROM nowi_wykladowcy WHERE nazwisko IN (’ABACKI’,’BABACKI’)
I Podzapytania tu nie ujmuje siÍ w nawiasy )
I Kolumny zwrócone przez podzapytanie muszπ byÊ zgodne co do
typu z kolumnami wype≥nianymi
DDL Podsumowanie
DDL (Data Definition Language) Podsumowanie
I Pozwala tworzyÊ, zmieniaÊ i usuwaÊ struktury danych: tabele, wiÍzy, I SQL jest dominujπcym – praktycznie jedynym – jÍzykiem dostÍpu do
indeksy, perspektywy i in. danych relacyjnych
I Bardzo zróønicowane szczegó≥y w róønych DBMS: silnie zaleøne od I Sk≥ada siÍ z trzech czÍúci: DQL – zapytania, DML – modyfikacja
moøliwoúci danego DBMS danych, DDL – modyfikacja struktur
I Zwykle generuje siÍ narzÍdziem i co najwyøej poprawia „rÍcznie” I Sk≥adnia SQL jest stosunkowo prosta, ale jÍzyk ma sporo
niedoskona≥oúci; szczególnie k≥opotliwe sπ grupowania i agregacje
Definiowanie tabel w SQL I W zdaniach SQL moøna uøywaÊ zagnieødøonych podzapytaÒ
I Tworzenie tabel I Moøna teø uøywaÊ funkcji wbudowanych oraz funkcji uøytkownika
CREATE TABLE tabela (kolumna1 typ1 [NOT NULL], ...)
I Przetwarzanie w profesjonalnych RDBMS odbywa siÍ w trybie
I Dodawanie kolumn transakcyjnym, SQL zawiera wiÍc instrukcje do zatwierdzania
ALTER TABLE tabela ADD (kolumna1 typ1 [NOT NULL], ...) i odrzucania transakcji
I Usuwanie tabel I Sk≥adnia DDL jest bardzo silnie zaleøna od konkretnej implementacji
DROP TABLE tabela i moøliwoúci danego RDBMS
BD.4 – Wprowadzenie do projektowania BD.4 – Wprowadzenie do projektowania
Cele i etapy procesu projektowania Cele i etapy procesu projektowania
Cele projektowania Etapy i metodyki projektowania
Cele projektowania Etapy projektowania
I Analiza – modelowanie danych
I Projektowanie wstÍpne: wybór architektury, narzÍdzi, DBMS itp.
I Cel projektowania: stworzenie projektu struktur danych gotowego do I Stworzenie projektu struktur
implementacji I przekszta≥cenie modelu ERD lub UML
albo
Oczekiwania co do projektu I stworzenie projektu od zera
I Struktura danych musi zapewniÊ I Udoskonalanie projektu (np. rozwaøenie denormalizacji) –
I realizacjÍ wymagaÒ projektowanie jest procesem iteracyjnym!
I moøliwoúÊ przysz≥ej rozbudowy I Przekszta≥cenie projektu w skrypty SQL DDL
I elastycznoúÊ (w rozsπdnym zakresie)
I Uruchomienie
I Jednπ z najwaøniejszych cech projektu musi byÊ podatnoúÊ na I instalacja bazy danych, struktur i aplikacji
zmiany I import danych
I testy
I kopie rezerwowe (backup)
I Równolegle: projektowanie, programowanie i testowanie aplikacji
Cele i etapy procesu projektowania Cele i etapy procesu projektowania
Etapy i metodyki projektowania Etapy i metodyki projektowania
Rodzaje metodyk projektowania s.i. Dokumentowanie procesu projektowego
Metodyki strukturalne
I Dane i procesy modelowane w zasadzie osobno
I Tylko proste typy danych
Kaødy projekt systemu informacyjnego musi byÊ starannie i szczegó≥owo
I Podstawowe techniki dokumentowany.
I diagramy zwiπzków encji (ERD)
I hierarchie funkcji (FHD) I Pe≥ne dokumentowanie procesu projektowego jest niezbÍdnym
I diagramy przep≥ywu danych (DFD) warunkiem ≥atwego utrzymania i rozwijania wynikowego systemu
informacyjnego
Metodyki obiektowe I W szczególnoúci dokumentacja zawieraÊ musi opisy i uzasadnienia
I Dane i procesy modelowane ≥πcznie wszelkich rozwiπzaÒ nietypowych
I Im bardziej z≥oøony jest system, tym dok≥adniejszπ powinien mieÊ
I Z≥oøone typy danych (struktury, kolekcje)
dokumentacjÍ projektowπ
I Podstawowe techniki
I diagramy klas UML
I przypadki uøycia i modele dynamiczne UML
Analiza wymagaÒ w projektowaniu s.i. Analiza wymagaÒ w projektowaniu s.i.
Analiza wymagaÒ Modelowanie danych
Analiza wymagaÒ Modelowanie danych
Po co modelowaÊ dane?
Cele analizy wymagaÒ
I Model danych
I Precyzyjne okreúlenie zakresu projektu systemu informacyjnego I dostarcza wiedzy o dziedzinie problemowej
I Zebranie wymagaÒ co do systemu I zwykle jest tworzony na etapie analizy wymagaÒ dla s.i.
I uúciúlenie oczekiwaÒ uøytkownika I powinien byÊ podstawπ projektowania struktur danych s.i.
I sformu≥owanie wymagaÒ I moøe s≥uøyÊ do weryfikacji modeli funkcjonalnych
I wykrycie niedoskona≥oúci w organizacji i zaproponowanie zmian I zawiera
I modele graficzne – diagramy
I Zapisanie wymagaÒ w odpowiedni sposób
I tekstowe (ale teø sformalizowane) uzupe≥nienia modeli graficznych
I sformalizowany i usystematyzowany
I czytelny i jednoznaczny I W stosunku do modeli funkcjonalnych/procesowych model danych
I minimalnie nadmiarowy
I g≥Íbiej siÍga do „istoty rzeczy”
I Uzgodnienie wymagaÒ z odbiorcami I jest mniej zaleøny od doraünych potrzeb
I formalne ustalenie zadaÒ i odpowiedzialnoúci stron I jest trwalszy – mniej zmienny
I jest bardziej sformalizowany
Projekt kaødego niebanalnego systemu informacyjnego powinien
I w wiÍkszym stopniu wp≥ywa na jakoúÊ przysz≥ego s.i.
zawieraÊ fazÍ analizy.
Dobrze zrobiony model danych jest trwa≥ym fundamentem s.i.
Analiza wymagaÒ w projektowaniu s.i. Analiza wymagaÒ w projektowaniu s.i.
Modelowanie danych Diagramy zwiπzków encji (ERD)
Zalecenia co do modelowania danych Diagramy zwiπzków encji
Za≥oøenia Entity Relationship Diagrams (ERD)
I Model danych powinien byÊ formu≥owany w sposób moøliwie I Modeluje siÍ uøywajπc tylko atrybutów prostych typów
uniwersalny (application neutral), a nie úciúle zaleøny od bieøπco I Atrybuty organizuje siÍ w tzw. encje i ≥πczy je zwiπzkami
rozpatrywanego zastosowania1 I Nie modeluje siÍ funkcjonalnoúci
I Modelujπc strukturÍ danych naleøy staraÊ siÍ oddaÊ ich istotÍ, a nie I Istniejπ specjalne oznaczenia dla unikalnych identyfikatorów
jedynie punkt widzenia zwiπzany z jednym specyficznym I Notacja dobrze dostosowana do relacyjnego modelu danych
zastosowaniem (choÊ sama jeszcze nie jest modelem relacyjnym)
I Naleøy staraÊ siÍ przewidywaÊ inne moøliwe zastosowania dla danych
Skutki
(ale bez przesady)
I Ograniczona si≥a wyrazu – na wiele typowych zjawisk nie ma notacji
I Bieøπce zamierzenia co do funkcjonalnoúci systemu powinny
I Brak naturalnej reprezentacji obiektów z≥oøonych:
determinowaÊ zakres modelowanych danych, ale nie powinny
prowadziÊ do nadmiernego uproszczenia ich struktury np. zaleønoúci ca≥oúÊ/czÍúÊ wymagajπ co najmniej dwóch encji
I KoniecznoúÊ uzupe≥niania opisami tekstowymi
I Bardzo ≥atwe przejúcie do modelu relacyjnego – zwykle
1 Jest to zalecenie bardzo konserwatywne
zautomatyzowane
Analiza wymagaÒ w projektowaniu s.i. Projektowanie wstÍpne
Modele klas UML Wybór DBMS
Modelowanie danych w UML – modele klas Wybór DBMS
Za≥oøenia modelu klas I Czynniki które trzeba wziπÊ pod uwagÍ
I Sposób modelowania obiektów powinien byÊ „naturalny”, tj. jak I istniejπce instalacje DBMS
najbardziej zbliøony do ludzkiego postrzegania tych obiektów I kwalifikacje pracowników (np. DBA)
I Typowe problemy powinny mieÊ specjalnπ notacjÍ I kompatybilnoúÊ z planowanymi systemami
I Obiekty, które postrzegamy jako z≥oøone, powinny byÊ modelowane jako I krytycznoúÊ planowanych systemów dla dzia≥ania organizacji
z≥oøone I budøet
I Notacja dla modelu pojÍciowego i projektu (i specyfikacji, i implementacji) I Poøπdane cechy produktu DBMS
powinna byÊ ta sama – sπ to tylko róøne perspektywy widzenia modelu I mocna pozycja rynkowa
I Us≥ugi úwiadczone przez obiekty i operacje wykonywalne na nich mogπ I wsparcie techniczne producenta (p≥atne!)
(powinny) byÊ modelowane razem z danymi I wszechstronnoúÊ
I dostosowanie do róønych zadaÒ
I Notacja dostosowana do obiektowego modelu danych I opcje
I rozszerzalnoúÊ
Skutki
I przenoúnoúÊ
I Znacznie wiÍksza si≥a wyrazu od modeli strukturalnych (ERD) I skalowalnoúÊ
I Brak specjalnych oznaczeÒ dla UID I wykorzystanie wielu procesorów
I Nietrywialne (a czasem trudne) przejúcie do modelu relacyjnego I moøliwoúÊ budowania klastrów i gridów
Projektowanie wstÍpne Projektowanie wstÍpne
Przeglπd waøniejszych RDBMS Przeglπd waøniejszych RDBMS
DBMS typu open-source
I Wspólne cechy
Komercyjne RDBMS I brak wsparcia technicznego lub wsparcie ograniczone
I Oracle I nie nadajπ siÍ do budowy systemów mission critical
I wszechstronny i przenoúny I technicznie co najmniej kilka lat za wiodπcymi produktami
I dominujπca pozycja rynkowa komercyjnymi
I doúÊ ≥atwo o specjalistów
I alternatywπ dla rozwiπzaÒ open-source mogπ byÊ darmowe wersje
I IBM DB2 systemów komercyjnych (“express editions”)
I wszechstronny i przenoúny, ale szczególnie polecany ze sprzÍtem IBM
I dobra pozycja rynkowa
I w Polsce doúÊ trudno o specjalistów
I MySQL / MariaDb
I odpowiedni jako zaplecze dla dynamicznych stron WWW oraz
I Microsoft SQL Server
prostych systemów CMS (Joomla itp.)
I dobra pozycja rynkowa I ryzykowny do zastosowaÒ w systemach transakcyjnych
I mniej przenoúny – tylko Windows
I doúÊ ≥atwo o specjalistów
I PostgreSQL
I doúÊ wszechstronny i przenoúny
I dobre rozwiπzania techniczne
I odpowiedni do budowy systemów mniejszych i niekrytycznych
Projektowanie struktur relacyjnych Projektowanie struktur relacyjnych
WiÍzy integralnoúci
Podstawowe elementy projektu struktur relacyjnych Deklaratywne wiÍzy integralnoúci
I Typowe ograniczenia definiowane w sposób deklaratywny
(bez programowania)
I Tabele relacyjne I ma≥o podatne na b≥Ídy
I wiÍzy integralnoúci I zoptymalizowane – ma≥o obciπøajπ operacje DML
I indeksy I statyczne – dotyczπ wszystkich wierszy w tabeli
I wyzwalacze (triggers) I Rodzaje wiÍzów
I Procedury i funkcje sk≥adowane I klucz g≥ówny (primary key ) – wyznacza toøsamoúÊ wierszy
I pisane w specjalnym jÍzyku: PL/SQL (Oracle, DB2), SQL-PL I klucze unikalne (unique keys) – przeciwdzia≥ajπ b≥Ídnemu
(DB2), Transact-SQL (MS-SQL Server), PL/pgSQL (PostgreSQL) zduplikowaniu danych
I wykonywane w DBMS – bez przesy≥ania danych poza b.d. I klucze obce (foreign keys) – zapewniajπ integralnoúÊ referencyjnπ
I wiÍzy kontrolne (check constraints) – wymuszajπ proste „regu≥y
I Sekwencje – do generowania unikalnych liczb (np. na klucze
biznesu”: dopuszczalne wartoúci, wyraøenia regularne, porównania
sztuczne)
w ramach wiersza itp.
I Perspektywy (views)
Regu≥y integralnoúci, które moøna wymusiÊ deklaratywnie, naleøy w≥aúnie
tak realizowaÊ.
Indeksy Indeksy
Indeksy WewnÍtrzna budowa indeksu
I Przyspieszajπ wyszukiwanie i sortowanie I Indeks w postaci drzewa zrównowaøonego (balanced tree, B-tree)
I Mogπ wymuszaÊ unikalnoúÊ kluczy (unique index) I Wyszukiwanie w takim indeksie polega na nawigacji po drzewie od
I Wyszukiwanie jest szybkie, gdyø nie trzeba czytaÊ ca≥ego indeksu „korzenia” do odpowiedniego liúcia
I W przypadku zmian danych indeksy sπ automatycznie I Wykorzystanie: tylko 1 indeks B-tree na 1 tabelÍ w 1 zapytaniu
przebudowywane przez DBMS
I Nie sπ „za darmo”: zajmujπ miejsce na dyskach i spowalniajπ
operacje DML
I Zastosowanie w systemach OLTP
I cel: optymalizacja z≥πczeÒ
I indeksy na klucze g≥ówne i obce
W systemach OLTP powinny istnieÊ indeksy umoøliwiajπce szybkie
wyszukiwanie i sortowanie wg wszystkich kluczy g≥ównych i obcych.
Programowanie proceduralne w b.d. Programowanie proceduralne w b.d.
Wyzwalacze Perspektywy
I Procedury sk≥adowane wykonywane automatycznie przez DBMS
I nie ma moøliwoúci ominiÍcia
I Wywo≥ywane przez okreúlone zdarzenia I Zapytania nazwane i zapamiÍtane w s≥owniku b.d.
I zdania DML (INSERT, UPDATE, DELETE) – przed lub po zdarzeniu I Udajπ tabele, nie wp≥ywajπc na wydajnoúÊ zapytaÒ
I zdarzenia systemowe, np. connect, startup, shutdown
I Moøna przez nie takøe zapisywaÊ dane
I Bywajπ doúÊ trudne w programowaniu i niewdziÍczne I warunkiem jest jednoznacznoúÊ odwzorowania zmian na prawdziwe
w uruchamianiu – powinny byÊ moøliwie proste tabele
I Przyk≥adowe zastosowania wyzwalaczy I G≥ówne zastosowania
I wstawianie wartoúci domyúlnych (np. pobrania z sekwencji) I u≥atwianie zapytaÒ – prezentacja „widoków” na dane
I wymuszanie z≥oøonych lub nietypowych regu≥ integralnoúci (business I izolacja podsystemów
rules) I zabezpieczenia dostÍpu – udostÍpnienie „przefiltrowanych” danych
I wymuszanie spójnoúci w strukturach zdenormalizowanych
I wstawianie wyników obliczeÒ
I úledzenie zmian w b.d. (nietypowy audyt)
I nietypowe zabezpieczenia dostÍpu
Podsumowanie Podsumowanie
Podsumowanie Podsumowanie, c.d.
I Kluczowπ cechπ projektu bazy danych jest podatnoúÊ na zmiany, by I Jeúli nie ma silnych przeciwwskazaÒ biznesowych, struktury danych
zaprojektowany s.i. bÍdzie móg≥ byÊ uøytkowany d≥ugie lata projektuje siÍ dla konkretnego DBMS, a nawet dla konkretnej jego
I W projektowaniu struktur relacyjnych nadal chÍtnie uøywa siÍ wersji
modelowania ERD, gdyø przejúcie od takich modeli do struktur I Wybierajπc DBMS naleøy bardzo powaønie braÊ pod uwagÍ pozycjÍ
relacyjnych jest proste i moøe byÊ zautomatyzowane rynkowπ producenta
I Ze wzglÍdu na przewidywanπ d≥ugowiecznoúÊ tworzonego s.i. I Projekt struktur relacyjnych oprócz tabel zawiera inne niezbÍdne
staranna dokumentacja jest szczególnie waøna elementy: wiÍzy integralnoúci, indeksy itd.
I Powaøniejsze projekty s.i. powinny zaczynaÊ siÍ fazπ analizy I WiÍzy integralnoúci naleøy w miarÍ moøliwoúci realizowaÊ
wymagaÒ deklaratywnie
I JakoúÊ modelu danych ma zasadnicze znaczenie dla jakoúci I Waøne regu≥y biznesu, których nie moøna zrealizowaÊ deklaratywnie,
tworzonego s.i. wymusza siÍ wyzwalaczami
I Model danych powinien byÊ tworzony tak, by jego uøycie nie by≥o I W≥aúciwe zaprojektowanie indeksów wp≥ywa w sposób decydujπcy na
ograniczone do aktualnych zastosowaÒ – powinien odpowiadaÊ wydajnoúÊ b.d.
istocie modelowanych rzeczy
BD.5 – Przeglπd typowych wzorców projektowych BD.5 – Przeglπd typowych wzorców projektowych
Konstrukcje podstawowe Konstrukcje podstawowe
Agregacja i kompozycja Agregacja i kompozycja
Agregacja i kompozycja
I Zastosowania Publikacja Publikacja PUBLIKACJA I Zwiπzek 1 n obowiπzkowy po
nrPublikacji: Integer
I ca≥oúÊ – czÍúÊ (kompozycja, jeúli czÍúÊ nie
# * NR PUBLIKACJI
nrPublikacji: Integer
tytuł: String
tytuł: String
typPublikacji: TypPublikacji
* stronie czÍúci
* TYP PUBLIKACJI
moøe istnieÊ bez ca≥oúci lub byÊ przeniesiona typPublikacji: TypPublikacji liczbaStron: Integer
o LICZBA STRON I UID czÍúci: zwiπzek + atrybut
jednostka wydawnicza
liczbaStron: Integer
do innej ca≥oúci) 1
I struktura dokumentu: nag≥ówek – pozycje jednostka wydawnicza (najczÍúciej sequence in parent)
zawiera
1
I Dla silnej agregacji
I Reprezentacja w aplikacjach zawiera fragment
I struktura master-detail: nag≥ówek (1 rekord
0..* (kompozycji) – zwiπzek
Rozdział
nietransferowalny po stronie
nadrzÍdny) + tabelka (rekordy podrzÍdne) fragment nrRozdziału: Integer #*
I w raportach niekiedy zwiπzek ca≥oúÊ-czÍúÊ 0..* tytuł: String U*
czÍúci
Rozdział I W aplikacjach dane
wyraøany przez wciÍcia
nrRozdziału: Integer
tytuł: String przedstawiane w postaci
struktur master-detail
Agregacja i kompozycja Klasyfikacja
PUBLIKACJA
PUBLIKACJE Klasyfikacja
P * NR_PUBLIKACJI NUMBER (5)
# * NR PUBLIKACJI * TYTUL VARCHAR2 (200 CHAR)
*
* TYP PUBLIKACJI
* TYP_PUBLIKACJI
LICZBA_STRON
CHAR (1 CHAR)
NUMBER (4)
I Klasyfikacja sztywna PUBLIKACJA
o LICZBA STRON PUB_PK (NR_PUBLIKACJI)
PUB_CHK TYP_PUBLIKACJI in ('M', 'D', 'H', 'P')
I zbiór wartoúci #
*
NR PUBLIKACJI
TYTUŁ
I nie zmienia siÍ * TYP PUBLIKACJI
I zmiana wymaga ingerencji
o LICZBA STRON
projektanta/programisty
PF * NR_PUBLIKACJI
ROZDZIALY
NUMBER (5)
I atrybut z dyskretnym zbiorem
P * NR_ROZDZIALU NUMBER (3) wartoúci dopuszczalnych
#* U * TYTUL VARCHAR2 (200) I przyk≥ady: tak-nie, p≥eÊ, dni
U* ROZ_PK (NR_PUBLIKACJI, NR_ROZDZIALU)
ROZ_UK (TYTUL, NR_PUBLIKACJI) tygodnia, nazwy miesiÍcy PUBLIKACJA
# NR PUBLIKACJI
jest typu
TYP PUBLIKACJI
# KOD TYPU PUBLIKACJI
I Klasyfikacja elastyczna
* TYTUŁ * NAZWA
o LICZBA STRON
I W tabeli podrzÍdnej klucz obcy na poczπtku klucza g≥ównego – nie wymaga
obejmuje
dodatkowego indeksu (za≥oøono øe projekt jest dla Oracle – klucz g≥ówny
I zbiór wartoúci zmienny, zmiany
indeksowany jest automatycznie) moøe wprowadzaÊ uøytkownik
I encja odpowiadajπca s≥ownikowi
I Silna agregacja: klucz obcy niezmienny (wymaga wyzwalacza), z klauzulπ wartoúci
ON DELETE CASCADE I zwiπzek 1 n opcjonalny po
I Dodatkowy klucz unikalny z wtórnego UID, inna kolejnoúÊ dla zwiÍkszenia stronie klasyfikacji
korzyúci z indeksu I Reprezentacja w aplikacjach:
w postaci list wartoúci
Klasyfikacja Klasyfikacja
Klasyfikacja elastyczna / podglπd (lookup)
PUBLIKACJA TYP PUBLIKACJI
Klasyfikacja sztywna # * NR PUBLIKACJI
*
# * KOD TYPU PUBLIKACJI
U * NAZWA
o LICZBA STRON
PUBLIKACJE
PUBLIKACJA
# * NR PUBLIKACJI * TYTUL VARCHAR2 (200 CHAR)
* * TYP_PUBLIKACJI CHAR (1 CHAR) PUBLIKACJE
* TYP PUBLIKACJI LICZBA_STRON NUMBER (4) TYPY_PUBLIKACJI
o LICZBA STRON PUB_PK (NR_PUBLIKACJI) F * KOD_TYPU_PUBLIKACJI VARCHAR2 (4 CHAR) P * KOD_TYPU_PUBLIKACJI VARCHAR2 (4 CHAR)
* TYTUL VARCHAR2 (200 CHAR) U * NAZWA VARCHAR2 (40)
PUB_CHK TYP_PUBLIKACJI in ('M', 'D', 'H', 'P')
LICZBA_STRON NUMBER (4) TYPP_PK (KOD_TYPU_PUBLIKACJI)
PUB_PK (NR_PUBLIKACJI) TYPP_UK (NAZWA)
PUB_TYPP_FK_IDX (KOD_TYPU_PUBLIKACJI)
ROZDZIALY
PF * NR_PUBLIKACJI NUMBER (5) I Klucz obcy obowiπzkowy = klasyfikacja przymusowa
P * NR_ROZDZIALU NUMBER (3)
#* U * TYTUL VARCHAR2 (200) I Klasyfikacja moøe byÊ niezmienna – zwiπzek nietransferowalny, lub zmienna –
U* ROZ_PK (NR_PUBLIKACJI, NR_ROZDZIALU)
ROZ_UK (TYTUL, NR_PUBLIKACJI) transferowalny
I W obu przypadkach klucz obcy z dzia≥aniem restrict, nie z kaskadπ kasowania!
I Klasyfikacja sztywna zrealizowana wiÍzami check
I Zmieniona kolejnoúÊ kolumn: obowiπzkowe i o sta≥ej d≥ugoúci najpierw
I Konieczny indeks (nieunikalny!) na klucz obcy
Konstrukcje ze s≥ownikiem pomocniczym – tzw. podglπd (lookup) – stosuje siÍ nie
tylko do klasyfikacji
åledzenie zmiennoúci åledzenie zmiennoúci
åledzenie zmiennoúci åledzenie zmiennoúci
PUBLIKACJA
# * NR PUBLIKACJI
I Do úledzenia zmiennoúci atrybutu PUBLIKACJA
U*
tworzy siÍ dodatkowπ encjÍ # * NR PUBLIKACJI
U*
I Nie naleøy uøywaÊ konstrukcji typu:
wartoúÊ1, wartoúÊ2, wartoúÊ3,. . .
WYDANIE
# * NR WYDANIA
* ROK WYDANIA
o LICZBA STRON
WYDANIE
# * NR WYDANIA
* ROK WYDANIA I Dodatkowy klucz unikalny na tytu≥ publikacji – zmiana logiki ze wzglÍdu na
o LICZBA STRON
istnienie wydaÒ
I W tabeli podrzÍdnej klucz obcy na poczπtku klucza g≥ównego – nie wymaga
dodatkowego indeksu
I Silna agregacja: klucz obcy niezmienny (wymaga wyzwalacza), z klauzulπ
ON DELETE CASCADE
Lista Zwiπzki wiele do wielu
Lista Zwiπzki wiele do wielu (n m)
ZADANIA
P * ID_ZADANIA NUMBER (4)
U * LP NUMBER (6)
* TYTUL VARCHAR2 (100 CHAR)
OPIS VARCHAR2 (1000 CHAR)
ZAD_PK (ID_ZADANIA) I Mogπ wystÍpowaÊ Przyk≥ad
ZAD_UK (LP)
w modelach pojÍciowych
I W modelach
TYP OBIEKTU
# * KOD TYPU OBIEKTU #*
U * NAZWA U * NAZWA
I Pozycje listy oznacza siÍ numerami porzπdkowymi implementacyjnych warto * CZY_OPCJONALNA
* TYP DANYCH
(ew. z duøym krokiem) rozbiÊ na parÍ zwiπzków
I Rozwiπzanie alternatywne (rzadko stosowane): 1 n i sensownie nazwaÊ
zwiπzek rekurencyjny 1 1, obustronnie opcjonalny powsta≥π dodatkowπ encjÍ
I Klucz sztuczny ID ZADANIA – generowany z krokiem 1, niezmienny
I Numer sekwencyjny LP oznaczajπcy kolejnoúÊ – generowany z duøym
krokiem, np. co 1000, unikalny, ale moøliwy do zmiany
(przestawienie kolejnoúci)
Zwiπzki wiele do wielu Drzewo
Drzewo – hierarchia
TYP OBIEKTU
# * KOD TYPU OBIEKTU #*
U * NAZWA U * NAZWA
* CZY_OPCJONALNA
* TYP DANYCH
DEFINICJE_WLASCIWOSCI
P * KOD_WLASCIWOSCI VARCHAR2 (8 CHAR)
TYPY_OBIEKTOW U * NAZWA VARCHAR2 (40)
P * KOD_TYPU_OBIEKTU VARCHAR2 (8 CHAR) * CZY_OPCJONALNA NUMBER (1)
U * NAZWA VARCHAR2 (40) * TYP_DANYCH CHAR (1 CHAR)
TOB_PK (KOD_TYPU_OBIEKTU)
TOB_UK (NAZWA)
DWLA_PK (KOD_WLASCIWOSCI)
DWLA_UK (NAZWA) I Stosowane np. do opisu hierarchii Przyk≥ad
s≥uøbowej
I Modelowane jako tzw. zwiπzek
WLTOB_TOB_FK WLTOB_DWLA_FK
PRACOWNIK
# * ID PRACOWNIKA
WLASCIWOSCI_TYPU_OBIEKTU rekurencyjny 1 n * NAZWISKO
*
I Zwiπzek rekurencyjny
PF * KOD_TYPU_OBIEKTU VARCHAR2 (8 CHAR) U o PESEL
PF * KOD_WLASCIWOSCI VARCHAR2 (8 CHAR)
WLTOB_PK (KOD_TYPU_OBIEKTU, KOD_WLASCIWOSCI)
WLTOB_DWLA_FK_IDX (KOD_WLASCIWOSCI)
I zwiπzek miÍdzy encjπ a niπ samπ
I Zmiana nazwy tabeli intersekcji na mówiπcπ o znaczeniu tych danych I oczywiúcie zwykle wiπøe róøne
I Klucz g≥ówny w tabeli intersekcji sk≥ada siÍ z dwóch kluczy obcych instancje tej encji
I musi byÊ obustronnie opcjonalny
I Ten klucz obcy, który nie jest na poczπtku g≥ównego, musi mieÊ indeks
nieunikalny
I Realizacja danej binarnej CZY OPCJONALNA jako liczby z ograniczeniem
CHECK CZY OPCJONALNA in (0, 1) i wartoúciπ domyúlnπ 0
Konstrukcje podstawowe Konstrukcje trudniejsze
Drzewo Graf i atrybuty asocjacyjne
Hierarchia i zwiπzek/klucz obcy rekurencyjny Graf i atrybuty asocjacyjne
Graf
PRACOWNIK
P * ID_PRACOWNIKA
PRACOWNICY
NUMBER (5)
I Modelowanie grafu przez tzw. asocjacjÍ
# * ID PRACOWNIKA
Materiał
* NAZWISKO VARCHAR2 (20 CHAR)
* NAZWISKO
*
U
F
* IMIE
PESEL
ID_PRACOWNIKA_PRZELOZONEGO
VARCHAR2 (15 CHAR)

CHAR (11 CHAR)
NUMBER (5)
zwrotnπ oraz ograniczenie {dag} – graf {dag}
ktm
U o PESEL PRAC_PK (ID_PRACOWNIKA)
PRAC_UK (PESEL) acykliczny skierowany (directed acyclic graph) nazwa
I Do wyraøenia wag ≥uków (krawÍdzi) potrzebny
PRAC_PRAC_FK_IDX (ID_PRACOWNIKA_PRZELOZONEGO)
zawiera
PRAC_PRAC_FK
jest tzw. atrybut asocjacyjny: charakteryzujπcy
asocjacjÍ, a nie któryú z jej koÒców
I Kolumny klucza obcego rekurencyjnego muszπ byÊ sensownie
nazwane Klasy asocjacyjne
I Klucz obcy rekurencyjny teø musi mieÊ indeks nieunikalny I Sπ przeznaczone do umieszczania atrybutów Składnik
ilość
asocjacyjnych
I Pokazano teø klucz unikalny na kolumnie nieobowiπzkowej I Mogπ mieÊ operacje, pozostawaÊ w innych
asocjacjach itd.
Konstrukcje trudniejsze Konstrukcje trudniejsze
Graf i atrybuty asocjacyjne Specjalizacja i generalizacja
Specjalizacja i generalizacja
I Generalizacja (uogólnienie) pozwala modelowaÊ wspólne atrybuty
I Typowa reprezentacja grafu klas
Materiał # * KTM
skierowanego: dwie encje I Specjalizacja (dziedziczenie) pozwala wywodziÊ typy specjalizowane
ktm
{dag}
* NAZWA (wÍz≥y + ≥uki z wagami) z ogólniejszych
nazwa
zawiera I Atrybuty asocjacyjne muszπ byÊ I atrybuty klasy nadrzÍdnej sπ dziedziczone przez klasÍ potomnπ
umieszczone w osobnej encji
UML – dziedziczenie Osoba
zawiera jest zawarty nazwisko
I Ten graf jest stosowany do I Moøna wskazaÊ tzw. klasy abstrakcyjne imiona
Składnik
ilość
*
opisu zaleønoúci sk≥adnik- (kursywa) – nie mogπ mieÊ wystπpieÒ
-produkt; iloúÊ jest atrybutem I Moøna oznaczyÊ {overlapping,
asocjacyjnym I czy klasy potomne sπ roz≥πczne incomplete}
(disjoint / overlapping )
I czy pokazany zbiór klas potomnych jest Student Pracownik
pe≥ny czy nie (complete / incomplete) nrAlbumu stanowisko
podlega
Konstrukcje trudniejsze Konstrukcje trudniejsze
Specjalizacja i generalizacja Specjalizacja i generalizacja
ERD – nadtypy i podtypy Nadtypy i podtypy
OSOBA Reprezentacja nadtypu
# * ID OSOBY OSOBY
* NAZWISKO
P * ID_OSOBY NUMBER (5)
* IMIE OSOBA * NAZWISKO VARCHAR2 (20 CHAR)
STUDENT PRACOWNIK # * ID OSOBY * IMIE VARCHAR2 (15 CHAR)
* NAZWISKO U NR_ALBUMU VARCHAR2 (12 CHAR)
U * NR ALBUMU o
* IMIE TYTUL_NAUKOWY VARCHAR2 (30 BYTE)
F ID_PRZELOZONEGO NUMBER (5)
STUDENT PRACOWNIK
OSO_PK (ID_OSOBY)
podlega U * NR ALBUMU o STUD_UK (NR_ALBUMU)
PRAC_PRAC_FK_IDX (ID_PRZELOZONEGO)
podlega
I Umoøliwiajπ modelowanie podobne do dziedziczenia (atrybutów) PRAC_PRAC_FK
I czÍúÊ atrybutów wspólna
I podtypy i nadtyp mogπ byÊ w róønych zwiπzkach
I £atwe operacje na wszystkich podtypach ≥πcznie
I W ujÍciu „ortodoksyjnym” podtypy wykluczajπ siÍ (odpowiednik I £atwe umoøliwienie istnienie instancji nadtypu
disjoint) I To jest najczÍúciej stosowana reprezentacja nadtypów-podtypów
I CzÍsto ten sam zapis stosuje siÍ do wyraøania sytuacji, gdy
I podtypy nie wykluczajπ siÍ I Wszystkie atrybuty podtypów stajπ siÍ kolumnami opcjonalnymi
I mogπ istnieÊ instancje nadtypu, nie naleøπce do podtypów I Klucze obce sπ realizowane i indeksowane jak zwykle
Konstrukcje trudniejsze Podsumowanie
Specjalizacja i generalizacja
Reprezentacja podtypu Podsumowanie
I WiÍkszoúÊ projektów struktur baz danych moøna z≥oøyÊ z typowych
STUDENCI PRACOWNICY
P * ID_OSOBY NUMBER (5) P * ID_OSOBY NUMBER (5) konstrukcji – wzorców projektowych
I
U * NR_ALBUMU VARCHAR2 (12 CHAR) * NAZWISKO VARCHAR2 (20 CHAR)
* NAZWISKO VARCHAR2 (20 CHAR) * IMIE VARCHAR2 (15 CHAR) NajczÍúciej spotykanπ konstrukcjπ jest ca≥oúÊ-czÍúÊ, czyli agregacja
* IMIE VARCHAR2 (15 CHAR)
OSO_PK (ID_OSOBY) F
TYTUL_NAUKOWY
ID_PRZELOZONEGO
VARCHAR2 (30 BYTE)
NUMBER (5) lub kompozycja
STUD_UK (NR_ALBUMU) OSO_PK (ID_OSOBY) I Jeúli zbiór wartoúci jakiegoú atrybutu jest okreúlony i sta≥y, stosuje
PRAC_PRAC_FK_IDX (ID_PRZELOZONEGO)
siÍ ograniczenie wartoúci, np. ograniczenie check w bazie relacyjnej
I Jeúli zbiór wartoúci jakiegoú atrybutu jest okreúlony ale zmienny,
PRAC_PRAC_FK
stosuje siÍ s≥ownik dozwolonych wartoúci i zwiπzek / klucz obcy
I Zwiπzki wiele do wielu realizuje siÍ tworzπc dodatkowπ tabelÍ
I OpcjonalnoúÊ atrybutów okreúlona w ERD jest zachowana intersekcji
I Moøna dodaÊ tabelÍ odpowiadajπcπ samemu nadtypowi (OSOBY), I HierarchiÍ realizuje siÍ przez zwiπzek rekurencyjny / rekurencyjny
jeúli nadtyp ma móc mieÊ instancje nie naleøπce do øadnego klucz obcy
z podtypów I Specjalizacja czyli dziedziczenie w ERD reprezentowana jest przez
I Operacje na wszystkich danych nadtypu trudne – dlatego ta podtypy, natomiast w bazie relacyjnej nie ma bezpoúredniego
reprezentacja jest rzadziej stosowana odwzorowania; zwykle jest realizowana przez po≥πczenie kolumn
wszystkich podtypów w jednej tabeli
BD.6 – Hurtownie danych, OLAP BD.6 – Hurtownie danych, OLAP
Systemy przetwarzania analitycznego Systemy przetwarzania analitycznego
Systemy przetwarzania analitycznego
Typowe zastosowania danych analitycznych
I OLAP (On Line Analytical Processing )
Cele przetwarzania analitycznego I interaktywne analizowanie trendów i zaleønoúci
I ChÍÊ wykorzystania zgromadzonych danych w procesie decyzyjnym I weryfikacja hipotez
I g≥ównie analiza wielowymiarowa
I Potrzeba tworzenia analiz obejmujπcych ca≥oúÊ dzia≥aÒ organizacji
I Eksploracja danych (data mining )
Poøπdane cechy I pozyskiwanie z danych nowych, nieznanych przedtem informacji
I Scalenie danych z róønych üróde≥ i zaleønoúci
I Duøa wydajnoúÊ analizy I Systemy informowania kierownictwa (EIS – Executive Information
(moøliwe analizy interaktywne) Systems)
I prezentacja informacji syntetycznych, do zarzπdzania strategicznego
I Przechowywanie i udostÍpnianie historii (np. do porównaÒ) I interaktywna, z duøym udzia≥em grafiki
Hurtownie danych Hurtownie danych
Operacyjne i zbiorcze bazy danych Hurtownie i sk≥adnice danych
Operacyjne i zbiorcze bazy danych Hurtownia danych
(data warehouse, magazyn danych)
Dane operacyjne Zbiorcza baza danych
I Rozproszone – hurtownia danych
I Heterogeniczne I Scentralizowana baza danych
I W niew≥aúciwym uk≥adzie I Oddzielona od baz
operacyjnych Cechy hurtowni (wg. Inmona)
I Trudne do wydajnej analizy I Zorientowana tematycznie (subject oriented)
I Scala informacjÍ z wielu üróde≥
I Bez historii (dane aktualne) I Zintegrowana (integrated)
I Utrzymuje wielkπ iloúÊ
I Zwykle niezbyt wielkie I Trwa≥a (nonvolatile)
informacji (GB..TB)
(MB..GB)
I Gromadzi dane historyczne I Przechowujπca historiÍ (time variant)
I Transakcyjne
I Dostosowana do przetwarzania
I Zwykle znormalizowane
analitycznego
I Nie nadajπ siÍ do celów
I Agreguje informacjÍ
analitycznych
– zdenormalizowana
Hurtownie i sk≥adnice danych Hurtownie i sk≥adnice danych
Hurtownie i sk≥adnice danych Architektura systemu analitycznego
Klient
Hurtownia danych Sk≥adnice danych
(data warehouse) (data marts, tematyczne h.d.) Hurtownia
I Niezaleøna od zastosowania I Specyficzne dla zastosowania danych
Składnica
Klient
danych
I Scentralizowana I Przeznaczone dla okreúlonych
I Zawiera historiÍ uøytkowników
I Dane ma≥o zagregowane I Dane silnie zagregowane Transformacja Klient
I Dane ma≥o zdenormalizowane I Dane silnie zdenormalizowane Składnica
danych
I Wiele üróde≥ danych: I Dane w róønych sk≥adnicach
dane operacyjne i zewnÍtrzne powtarzajπ siÍ Ekstrakcja Ekstrakcja
I Niewiele üróde≥ danych
(albo jedno: centralna
hurtownia) OLTP OLTP
System z centralnπ hurtowniπ i sk≥adnicami danych
Dane w hurtowni Dane w hurtowni
Dane w hurtowni
I Elementarne (kopie üród≥owych) Cykl øycia danych w hurtowni
I Historyczne I Zasilanie danymi
I Agregaty I wsadowo
I róøne stopnie agregacji I przyrostowo
I Metadane I Agregacja
I opisujπ np. I tworzenie zmaterializowanych agregatów
I strukturÍ i znaczenie danych I Archiwizacja
I zastosowane agregacje I „przeniesienie” do historii
I üród≥a danych (i/lub transformacjÍ)
I I zwijanie (rolling aggregates)
historiÍ ≥adowania danych
I uwzglÍdniajπ zmiennoúÊ I Usuwanie danych – tylko wyjπtkowo
I wykorzystywane m.in. do
I sterowania procesami zasilania
I zarzπdzania zmianami
Hurtownie danych Analiza wielowymiarowa
Dane w hurtowni Dane wielowymiarowe
Proces ETL Analiza wielowymiarowa
(Extraction – Transformation – Loading ) Dane wielowymiarowe
I Wymiary
I dyskretne
I hierarchiczne
I przyk≥ady: czas, produkt, sprzedawca
I Fakty
I Ekstrakcja z baz operacyjnych I zawierajπ miary
I Transport I przyk≥ady miar: wielkoúÊ sprzedaøy, wartoúÊ sprzedaøy, % reklamacji
I Transformacja: Produkt
czyszczenie, konwersja, scalanie Sprzedawca
I £adowanie do hurtowni
Sprzedaż
Czas
Analiza wielowymiarowa Analiza wielowymiarowa
Dane wielowymiarowe Operacje wielowymiarowe
Operacje wielowymiarowe
Hierarchiczne struktury wymiarów
I Obracanie (pivoting )
Region
Cena I zmiana perspektywy oglπdania danych
I Selekcja
Region Kolor
Oddział Rodzaj
Oddział Rodzaj I wybór interesujπcych elementów wymiarów
Staż
I Wycinanie (slice and dice)
Sprzedawca Produkt
Sprzedawca Produkt
I selekcja elementów wybranych wymiarów (wyciÍcie „plastra”)
Sprzedaż
Sprzedaż
I zmniejszenie liczby wymiarów
Płeć I projekcja danych w pozosta≥ych wymiarach (z agregacjπ)
Klient Dzień
Zawód
Klient
Dzień I Zwijanie (roll-up) i rozwijanie (drill-down)
Rynek Miesiąc Rynek I nawigacja po hierarchii wymiaru
I z agregacjπ/dezagregacjπ
Miesiąc
Tydzień
Kwartał
I Ranking
Kraj Kraj Kwartał
I uszeregowanie elementów wymiaru wg wzrostu/spadku agregatu
Rok
Rok
miary
Analiza wielowymiarowa OLAP
Operacje wielowymiarowe
Przyk≥ad: tabela przestawna (pivot table) OLAP (On-line Analytical Processing )
Dane üród≥owe Projekcja Zadania OLAP
Liczba Semestr (Wszystkie) I Prezentacja wielowymiarowych widoków danych
I Interaktywne zapytania i analizy
Semestr Przedmiot Wariant Kierunek chętnych
04L BD3 A SI 12 Liczba chętnych Kierunek
I Obliczanie agregatów
04L BD3 A WD 60 Przedmiot Wariant SI WD Suma
04L BD3 B SI 59
BD3 A 38 169 207
04L BD3 B WD 6
I Analiza statystyczna, analiza trendów, prognozowanie, modelowanie
04L KBD3 A SI 15 B 183 32 215
04L KBD3 A WD 20 KBD3 A 42 76 118
I Wykresy
04L KBD3 B SI 44 B 100 20 120
04L KBD3 B WD 4 Suma 363 297 660
04Z BD3 A SI 7
04Z
...
BD3 A WD 50
UsuniÍto wymiar Semestr (z agregacjπ) I Duøa szybkoúÊ dzia≥ania
Trzy wymiary: Semestr,
Przedmiot/Wariant, Kierunek Zwijanie Wymagania wobec analitycznej b.d.
Semestr 04L
I Efektywne przetwarzanie analityczne wielkiej iloúci danych
Wycinanie Liczba chętnych Kierunek
I Efektywne przetwarzanie wielowymiarowe
Semestr 04L Przedmiot Wariant SI WD Suma
Liczba chętnych Kierunek
BD3 71 66 137
NarzÍdzia OLAP
I Arkusze kalkulacyjne, np. Excel
KBD3 59 24 83
Przedmiot Wariant SI WD Suma
72
Suma 130 90 220
BD3 A 12 60
KBD3
B
A
59
15
6
20
65
35
Wymiar Przedmiot/Wariant zwiniÍto I NarzÍdzia do budowy aplikacji analitycznych,
do 1. poziomu hierarchii
np. Business Objects, SAS
B 44 4 48
Suma 130 90 220
WyciÍto plaster ’04L’ z wymiaru Semestr I Gotowe rozwiπzania dla typowych problemów, np. sales analyzers
Projektowanie struktur relacyjnych dla OLAP Projektowanie struktur relacyjnych dla OLAP
Problemy w projektowaniu struktur hurtowni danych Projektowanie struktur relacyjnych dla OLAP
Problemy modelowania Specyfika projektowania hurtowni danych
I TrudnoúÊ ustalenia celu „biznesowego” hurtowni I Hurtownia danych z za≥oøenia jest zorientowana tematycznie, na
konkretny zakres analiz biznesowych
Problemy zmiennoúci
I Zmiany w schematach baz operacyjnych I Ze wzglÍdu na wielkie wolumeny danych i rodzaj dominujπcego
przetwarzania danych (analiza wielowymiarowa) z góry przewiduje
I Ewolucja schematu hurtowni
siÍ trudnoúci wydajnoúciowe i trzeba im z góry zaradziÊ
I Ewolucja s≥owników
I Rutynowo stosuje siÍ denormalizacjÍ, która w duøej mierze
Problemy wydajnoúci (materializacja agregatów) musi byÊ dostosowana do
I VLDB przewidywanych analiz
I Analiza wielowymiarowa – zapytania gwiaüdziste I Skutkuje to koniecznoúciπ úciúlejszego dostosowania decyzji
projektowych do przewidywanych zastosowaÒ danych
Projektujπc struktury hurtowni danych naleøy korzystaÊ z dostÍpnych
w uøytym DBMS úrodków technicznych dedykowanych dla VLDB i baz Projektujπc struktury relacyjne do celów analitycznych naleøy úmia≥o
analitycznych. stosowaÊ denormalizacjÍ.
Struktura gwiazdy
Struktura p≥atka úniegu Denormalizacja wymiarów – struktura gwiazdy
D
*
I Ze wzglÍdu na wielkie wolumeny danych wielokrotne z≥πczenia
z faktami w systemie ROLAP mogπ byÊ niewydajne
* Nazwa
D PRODUKT
I Kaødπ hierarchiÍ wymiarów zwija siÍ wiÍc do jednej tabeli – znacznie
ogranicza to liczbÍ z≥πczeÒ
* Kod produktu
* Nazwa
D REGION D SPRZEDAWCA F
I Powsta≥a struktura nazywa siÍ gwiazdπ
* Kod regionu * Kod sprzedawcy *
* Nazwa * Nazwa *
I Wyjúciowy model ROLAP to struktura p≥atka úniegu
D PRODUKT
# * Id produktu
*
I W centrum struktury sπ tzw. fakty (F)
*
* Kod produktu
* Nazwa produktu
I tu zapisuje siÍ dane elementarne odpowiadajπce pojedynczym
zdarzeniom D SPRZEDAWCA F
I kaøde zdarzenie (np. sprzedaø) ma swojπ miarÍ liczbowπ, np. wartoúÊ
#* Id sprzedawcy #*
* Kod regionu *
* Nazwa regionu
* Kod sprzedawcy
w pieniπdzu * Nazwa sprzedawcy
I ze wzglÍdu na przechowywanie historii, tych danych jest bardzo duøo
I Fakty zaleøne sπ od wymiarów (D), które mogπ tworzyÊ hierarchie Projektujπc struktury relacyjne do celów analitycznych rutynowo
I tych danych jest ma≥o stosuje siÍ denormalizacjÍ.
Struktura gwiazdy Struktura gwiazdy
Unikalne identyfikatory w strukturze gwiazdy Wymiar czasu
D
#*
D PRODUKT
* Czy roboczy
# * Id produktu *
* *
*
* *
* Kod produktu *
* Nazwa produktu * Rok
D SPRZEDAWCA F D PRODUKT
#* Id sprzedawcy #* # * Id produktu
D SPRZEDAWCA F * Kod regionu * *
* Nazwa regionu *
#* Id sprzedawcy #* * Kod sprzedawcy * Kod produktu
* Kod regionu * * Nazwa sprzedawcy * Nazwa produktu
* Nazwa regionu
* Kod sprzedawcy
* Nazwa sprzedawcy
I Niemal zawsze jeden z wymiarów stanowi czas zdarzenia
I W wymiarach wprowadzamy sztuczne identyfikatory I CzÍsto takøe czas modeluje siÍ jako osobnπ tabelÍ wymiaru
I u≥atwi to zarzπdzanie zmiennoúciπ wymiarów I w zaleønoúci od potrzeb dotyczπcych raportowania
I W faktach unikalny identyfikator moøe byÊ I gdy potrzebne sπ dodatkowe informacje (np. dni úwiπteczne)
I z≥oøeniem zwiπzków z wymiarami – schemat gwiaüdzisty w úcis≥ym I gdy wymiar czasu ma stanowiÊ hierarchiÍ rozga≥Ízionπ
sensie (np. dni–miesiπce–lata oraz dni–tygodnie)
I z≥oøeniem zwiπzków z wymiarami i atrybutów faktów – tzw. schemat I Struktura dotyczπca wymiaru czasu rzadko ma ziarnistoúÊ granicznπ
wielogwiaüdzisty (sekundy?), czÍúciej dotyczy jedynie dat, a wtedy
I czas musi pozostaÊ jako atrybut (identyfikujπcy) faktów albo
I zwykle jedynie miary nie wchodzπ w sk≥ad identyfikatora I fakty muszπ byÊ od razu zdenormalizowane do sum dziennych
Implementacja relacyjna struktury gwiaüdzistej Implementacja relacyjna struktury gwiaüdzistej
Implementacja relacyjna struktury gwiaüdzistej
D Dzien_sprzedazy
WiÍzy w strukturze hurtowni

P *
*
*
*
Data_sprzedazy
Czy_roboczy
Czy_swiateczny
Dzien_tygodnia
DATE
CHAR (1 CHAR)
CHAR (1 CHAR)
NUMBER (1)
I Klucze g≥ówne sπ zrealizowane jak w OLTP

I Poniewaø spójnoúÊ referencyjnπ zapewnia proces ETL, wiÍzy foreign
* Tydzien_w_roku NUMBER (2)
* Miesiac NUMBER (2)
* Kwartal NUMBER (1)
* Rok NUMBER (4)
key mogπ nie byÊ aktywne – znacznie przyspiesza to proces
DS_PK (Data_sprzedazy)
D
P * Id_sprzedawcy
Sprzedawca
NUMBER (6)
F
PF * Data_sprzedazy DATE
Sprzedaz D
P * Id_produktu
Produkt
NUMBER (6)
≥adowania danych
I WiÍzy foreign key w tabeli faktów mogπ zatem
* Kod_regionu CHAR (3 CHAR) P * Czas_sprzedazy DATE * Kod_grupy_produktow CHAR (4 CHAR)
* Nazwa_regionu VARCHAR2 (100 BYTE) PF * Id_produktu NUMBER (6) * Nazwa_grupy_produktow VARCHAR2 (100 CHAR)
* Kod_sprzedawcy CHAR (4 CHAR) PF * Id_sprzedawcy NUMBER (6) * Kod_produktu VARCHAR2 (12 CHAR)
* Nazwa_sprzedawcy VARCHAR2 (100 BYTE) * Wartosc NUMBER (6,2) * Nazwa_produktu VARCHAR2 (100 CHAR)
SPC_ PK (Id_sprzedawcy)
SPZ_SPC_FK_IDX (Id_sprzedawcy)
PR_PK (Id_produktu)
I nie byÊ w ogóle ustanowione
I byÊ ustanowione z klauzulπ RELY DISABLE NOVALIDATE1 – wówczas
SPZ_PR_FK_IDX (Id_produktu)
I sπ brane pod uwagÍ przy tzw. przepisywaniu zapytaÒ,
I sπ widoczne w s≥owniku danych, mogπ wiÍc byÊ uøyte przez narzÍdzia
do budowy zapytaÒ
I Przekszta≥cenie na strukturÍ tabel i kolumn jak w OLTP I ale nie sπ sprawdzane – nie obciπøajπ wydajnoúci ≥adowania danych
I WiÍzy i indeksy projektowane specyficznie dla struktury
wielowymiarowej – dalej
1 Oracle
årodki techniczne dla w ROLAP årodki techniczne dla w ROLAP
Indeksy bitowe i z≥πczeniowe
Indeksowanie w strukturze gwiaüdzistej Indeksy bitowe (Bitmap indexes)
I Klucz indeksowania zawiera niewiele róønych wartoúci o dowolnej
czÍstoúci
I W zapytaniach wiele warunków równoúciowych
I Indeks bitowy to binarna macierz rzadka
ROLAP = Relational OLAP I Macierz tÍ przechowuje siÍ na dysku w postaci skompresowanej
I Operatory logiczne na warunkach równoúciowych realizuje siÍ jako
I Klucze g≥ówne sπ indeksowane jak w OLTP operacje logiczne na bitach odpowiednich kolumn macierzy indeksów
I Klucze obce takøe powinny byÊ indeksowane, ale uøyÊ do tego bitowych
moøna specjalnych typów indeksów – zaleønie od uøytego DBMS –
np. indeksów bitowych i/lub indeksów z≥πczeniowych
# Id ... Oczy Płeć N P Z K M N&K
... ... N K 1 0 0 1 0 1
... ... N M 1 0 0 0 1 0
... ... P M 0 1 0 0 1 ! 0
... ... P K 0 1 0 1 0 0
... ... Z M 0 0 1 0 1 0
årodki techniczne dla w ROLAP årodki techniczne dla w ROLAP
Indeksy bitowe i z≥πczeniowe Indeksy bitowe i z≥πczeniowe
Indeksy z≥πczeniowe (Join indexes)
I Indeksuje siÍ tabelÍ faktów wartoúciami z tabeli wymiarów, np.
Cechy indeksów bitowych CREATE BITMAP INDEX sprzedaz towar idx
I Zastosowanie w zasadzie wy≥πcznie w bazach analitycznych: ON sprzedaz(towary.nazwa)
indeksowanie tabel faktów po wymiarach FROM sprzedaz, towary
WHERE sprzedaz.id towaru = towary.id towaru
I Zalety
I Przeznaczone do uøycia w bazach analitycznych (struktury
I niewielkie rozmiary indeksów na dysku — szybki odczyt
gwiaüdziste)
I wykorzystanie wielu indeksów do tej samej tabeli w jednym zapytaniu
I dobre dzia≥anie przy niskiej selektywnoúci klucza indeksowania I Indeksuje siÍ tabelÍ faktów wartoúciami z tabeli wymiarów
I Wady I Stosowane, gdy wyszukania dotyczπ deskryptora, a nie identyfikatora
I bardzo spowalniajπ DML wymiaru
I nie przyspieszajπ sortowania
I zwykle nie nadajπ siÍ do warunków zakresowych
årodki techniczne dla w ROLAP Podsumowanie
Optymalizacja zapytaÒ w ROLAP
Optymalizacja zapytaÒ w ROLAP Podsumowanie
I Przetwarzanie analityczne, s≥uøπce do wspomagania decyzji, powinno mieÊ
inne cechy niø przetwarzanie transakcyjne
I Dlatego do takiego przetwarzania potrzebne sπ osobne, inaczej
skonstruowane systemy informacyjne
I Optymalizacja zapytaÒ gwiaüdzistych I W zbiorczej bazie danych dane pochodzπ z wielu üróde≥ i sπ
I stosowane do zapytaÒ do tabeli faktów ze z≥πczeniami do wymiarów przechowywane w uk≥adzie sprzyjajπcym efektywnym analizom
I automatyczne przepisywanie zapytaÒ – unikniÍcie „prawdziwego” I Dane do hurtowni danych ≥adowane sπ wsadowo i przyrostowo przez
z≥πczenia: proces ETL, który je scala i sprawdza, i nie ulegajπ dalszym zmianom
I podzapytanie do tabeli faktów z uøyciem indeksów bitowych lub
I Nie ma zatem niebezpieczeÒstwa anomalii modyfikacji, moøna wiÍc úmia≥o
z≥πczeniowych (bez z≥πczenia!)
I po≥πczenie (semi-join) wyniku tego podzapytania z tabelami stosowaÊ denormalizacjÍ
wymiarów (ma≥ymi) I Podstawowym rodzajem analiz w hurtowniach sπ analizy wielowymiarowe
I CzÍsta w hurtowniach struktura gwiazdy jest dostosowana do takich analiz
I Zarzπdzanie zasobami DBMS – przeciwdzia≥anie runaway queries I Projektowanie hurtowni nie jest ≥atwe g≥ównie ze wzglÍdu na trudnoúÊ
sformu≥owania celu biznesowego hurtowni
I Od strony technicznej trudne jest budowanie procesów ETL
I By zapewniÊ dostatecznπ wydajnoúÊ analiz w hurtowni trzeba stosowaÊ
specjalne úrodki techniczne dedykowane dla baz analitycznych oraz VLDB
BD.7 – VLDB; nierelacyjne bazy danych BD.7 – VLDB; nierelacyjne bazy danych
VLDB VLDB
Kompresja i specjalne sposoby zapisu tabel
VLDB årodki techniczne wspomagajπce VLDB (przyk≥ady)
I VLDB – Very Large Database Kompresja tabel
I Dzia≥anie
I Granica p≥ynna i zmienia siÍ – obecnie od wielu TB
I „odzysk” miejsca po wartoúciach pustych (NULL, 0 itp.)
I prawdziwa kompresja (ca≥ych tabel lub wybranych partycji)
Problemy z VLDB
I Problemy z wydajnoúciπ zapytaÒ I Zastosowanie g≥ównie w bazach analitycznych
I K≥opotliwe operacje administracyjne, np. backup I Zalety: zmniejsza uøycie przestrzeni dyskowej i pamiÍci operacyjnej
I Duøe przyrosty danych – pogorszenie zachowania systemów I Wady: zwiÍksza uøycie CPU, wyraünie spowalnia operacje DML
I Koszty sprzÍtu: pamiÍci dyskowej, szybkich serwerów, urzπdzeÒ do I Kompresja wskazana, gdy w tabeli jest duøo wartoúci pustych
backupów i powtórzeÒ (np. liczne powtórzenia d≥ugich kluczy obcych)
I Kompresja niewskazana, gdy przewiduje siÍ duøo operacji DML
VLDB VLDB
Partycjonowanie danych Partycjonowanie danych
Partycjonowanie danych
I PartycjonowaÊ moøna Wykorzystanie partycjonowania danych
I poszczególne tabele i ich indeksy I Optymalizator zapytaÒ moøe umieÊ
I ca≥π bazÍ danych (partycje tabel przypisuje siÍ do partycji bazy)
I zidentyfikowaÊ potrzebne partycje, np. na podstawie warunków
I Podzia≥ na partycje zwykle zaleøy od wartoúci wybranych kolumn w zapytaniu
I podzia≥ zakresowy, np. wg zakresów dat I wykonaÊ eliminacjÍ zbÍdnych partycji (partition pruning ) – pozwala
I podzia≥ wg listy (enumeratywny) to wykonaÊ efektywnie nawet full scan
I podzia≥ automatyczny: funkcja mieszajπca (hash function) I wykorzystywaÊ partycje w realizacji z≥πczeÒ (partition-wise joins)
I partycjonowanie dwupoziomowe I Partycjonowanie upraszcza takøe operacje administracyjne
I Celem podzia≥u jest uzyskanie partycji (np. backup)
I o rozsπdnych rozmiarach
I o podobnej wielkoúci
I zawierajπcych dane, które zwykle bÍdπ uøywane razem
VLDB VLDB
Partycjonowanie danych Partycjonowanie danych
Partycjonowanie danych – przyk≥ady
Partycjonowanie danych – zalety i wady
CREATE TABLE sprzedaz ...
PARTITION BY RANGE(data sprzedazy) I Zalety
( I przezroczyste dla aplikacji
PARTITION sp2005 VALUES LESS THAN (TO_DATE(2006, ’YYYYY’)), I zapewnia znakomitπ skalowalnoúÊ
PARTITION sp2006 VALUES LESS THAN (TO_DATE(2007, ’YYYYY’)), I wydajnoúÊ wielu zapytaÒ niemal uniezaleøniona od przyrostu danych
PARTITION sp rest VALUES LESS THAN (MAXVALUE)
) – zalecane dla danych intensywnie przyrastajπcych
I operacje administracyjne wykonywane na kaødej partycji osobno
CREATE TABLE sprzedaz ... I moøliwe zrównoleglenie operacji na partycjach tej samej tabeli
PARTITION BY LIST(id koloru) I Wady
PARTITION sp1 VALUES (’zielony’, ’niebieski’),
PARTITION sp2 VALUES (’czerwony’, ’øó≥ty’), I doúÊ trudne poprawne zaprojektowanie (partycjonowanie powinno
PARTITION sp0 VALUES (DEFAULT) byÊ uwzglÍdnione juø w czasie projektowania struktur danych)
I spory dodatkowy koszt licencji
CREATE TABLE sprzedaz ...
PARTITION BY HASH(id sprzedazy)
PARTITIONS 4 STORE IN (sp1, sp2, sp3, sp4)
Obiektowy model danych Obiektowy model danych
Podstawy modelu obiektowego Podstawy modelu obiektowego
Obiektowy model danych Obiektowy model danych, c.d.
I Cechy podstawowe
I obiekt w bazie reprezentuje obiekt w úwiecie zewnÍtrznym I Zalety modelu
I typ obiektowy (klasa) I doúÊ naturalna reprezentacja úwiata – zgodna z ludzkim sposobem
I z≥oøony typ danych (moøe zawieraÊ inne typy obiektowe lub ich myúlenia
kolekcje) I model bardziej dostosowany do natury opisywanej rzeczywistoúci
I procedury (metody) i operatory do manipulowania tymi danymi I ≥atwoúÊ dzia≥ania na z≥oøonych obiektach (i lepsza wydajnoúÊ)
I toøsamoúÊ obiektu – niezaleøna od wartoúci danych
I duøa podatnoúÊ na zmiany
I dziedziczenie (inheritance)
I strukturalne – potomek dziedziczy strukturÍ danych I Znaczenie praktyczne
I behawioralne – potomek dziedziczy metody i operatory I wielkie znaczenie w rozwoju jÍzyków programowania
I Cechy dodatkowe I obiektowe bazy danych nie przyjÍ≥y siÍ – raczej tylko
I enkapsulacja – wnÍtrze obiektu dostÍpne jedynie w sposób w nim w zastosowaniach naukowych lub eksperymentalnych
I wiÍksze szanse ma ewolucja baz relacyjnych w kierunku
zdefiniowany (zwykle nie stosowana w obiektowych b.d.)
I polimorfizm – tak samo nazwane metody i operatory dzia≥ajπ obiektowo-relacyjnych
swoiúcie w zaleønoúci od klasy obiektu
Obiektowe bazy danych Obiektowe bazy danych
Motywacja dla obiektowych b.d. Obiektowe bazy danych (OODBMS – Object-oriented DBMS)
I S≥aboúci modelu relacyjnego
I problemy z reprezentacjπ z≥oøonych typów (przyk≥ad: GIS) Idea
I nienaturalna reprezentacja danych (przyk≥ad: podtypy) I Baza danych jest sk≥adnicπ trwa≥ych obiektów
I brak toøsamoúci obiektów
I I Obiekty te majπ cechy w≥aúciwe dla paradygmatu programowania
s≥aba wydajnoúÊ dla z≥oøonych struktur
I ma≥a podatnoúÊ na zmiany – sztywny system kluczy
obiektowego
g≥ównych-obcych I z≥oøone typy danych (takøe kolekcje) i metody
I wbudowanπ trwa≥π identyfikacjÍ obiektów
I Zalety obiektowej b.d.
I dziedziczenie
I bezpoúrednia reprezentacja obiektów z obiektowego jÍzyka
I Model bazy danych zgodny z modelem danych obiektowych jÍzyków
programowania
I lepsza wydajnoúÊ dla z≥oøonych struktur programowania
I znaczna podatnoúÊ na zmiany – trwa≥e identyfikatory I powinno to przezwyciÍøyÊ tzw. „niezgodnoúÊ impedancji” miÍdzy
I Potencjalne zastosowania dla OODBMS b.d. a jÍzykiem programowania
I multimedia i hipertekst
I SQL zastπpiony obiektowym jÍzykiem zapytaÒ, np. OQL
I systemy inform. przestrzennej (GIS) I Z≥πczenia zastπpione przez tzw. wyraøenia úcieøkowe, np.
I wspomaganie projektowania (CAD) SELECT p.nazwisko, p.przelozony.nazwisko as szef FROM pracownicy p
I zarzπdzanie sieciami
Obiektowe bazy danych Relacyjno-obiektowe bazy danych
Relacyjno-obiektowe bazy danych
Realizacje
I Standardy wypracowane przez organizacje OMG (Object I Idea relacyjno-obiektowej b.d.
Management Group) i ODMG (Object Data Management Group) – I Struktury relacyjne sπ nadal podstawπ budowy b.d.
bardzo porzπdne, ale zwykle doúÊ stare (poczπtek wieku) I W tabelach relacyjnych moøna umieszczaÊ z≥oøone obiekty
I Te obiekty majπ cechy w≥aúciwe dla OODBMS
I Wiele produktów: Gemstone, O2, Objectivity/DB, Jasmine; Caché,
I SQL jest rozszerzony o moøliwoúÊ dzia≥ania na takich obiektach
Db4o, Versant Object Database, ObjectStore itd.
I Zalety relacyjno-obiektowej b.d
I Bez znaczenia przemys≥owego, wiÍkszoúÊ producentów juø nie istnieje
I Pe≥na kompatybilnoúÊ z rozwiπzaniami relacyjnymi
I MoøliwoúÊ wykorzystania czÍúci zalet obiektowoúci w po≥πczeniu
Mimo nieustajπcego uznania ze strony úrodowisk naukowych, model ten
z zaletami bazy relacyjnej
nie uzyska≥ nigdy znaczπcej roli praktycznej I Ewolucyjne przejúcie do obiektowoúci
Obiektowy model danych Bazy NoSQL
Relacyjno-obiektowe bazy danych
Bazy NoSQL (Not only SQL)
Przyk≥ad: Oracle RODBMS
I Co zrealizowano? I Wspólne okreúlenie róønych pomys≥ów majπcych zastπpiÊ relacyjne
I MoøliwoúÊ definiowania z≥oøonych typów danych bazy danych1
I WewnÍtrznπ identyfikacjÍ obiektów (OID – object identifiers) I Motywacja
i referencje obiektowe I potrzeba przechowywania nie tylko danych strukturalnych
I MoøliwoúÊ wyposaøenia obiektów w metody I poøπdana rezygnacja ze z≥πczeÒ
I Przeciπøanie operatorów I ponoÊ koniecznoúÊ rezygnacji z niektórych postulatów ACID
I Dziedziczenie I dπøenie do ≥atwej i taniej skalowalnoúci, g≥ównie przez tzw.
I Czego nie zrealizowano? rozbudowÍ poziomπ, tj. powiÍkszanie liczby serwerów
I Hermetyzacja I Zastosowania
I Obiekty w bazie danych I us≥ugi internetowe: serwisy spo≥ecznoúciowe, wyszukiwarki itp.
I Tabele obiektów (row objects) I us≥ugi dzierøawione (hosted services)
I Kolumny typu obiektowego w tabelach relacyjnych (column objects) I Big Data
I Perspektywy obiektowe (object views)
I Specjalne tzw. metody porównujπce, umoøliwiajπce porównywanie I Temat modny: dziesiπtki produktów, ale wiÍkszoúÊ bez
i sortowanie obiektów ugruntowanej pozycji
1 Niektóre üród≥a do baz NoSQL zaliczajπ takøe bazy XML-owe
Bazy NoSQL Bazy NoSQL
Rodzaje baz NoSQL
Cechy baz NoSQL
Bazy klucz-wartoúÊ (key-value)
I Istotne zalety I Zasada dzia≥ania
I moøliwoúÊ przechowywania danych bez z góry okreúlonej struktury I tabela zawierajπca pary klucz-wartoúÊ (w niektórych rozwiπzaniach
– rezygnacja ze úcis≥ych schematów danych wartoúÊ moøe byÊ tablicπ lub listπ)
I ≥atwe i tanie skalowanie I bardzo szybkie dzia≥anie
I niskie koszty (liczne produkty darmowe)
I Produkty: Redis (VMWare), Riak, BerkeleyDB, Oracle NoSQL
I Wπtpliwe przewagi
I przetwarzanie wielkich wolumenów danych Bazy kolumnowe (Wide Column Stores)
I brak z≥πczeÒ, transakcji itp. I Zasada dzia≥ania
I unikanie pojedynczego punktu awarii I rozbudowane tabele klucz-wartoúÊ: klucz sk≥ada siÍ z wielu kolumn
I Wady prowadzπcych do jednej wartoúci
I technologie ma≥o znane i s≥abo sprawdzone I „rodzina kolumn” (Google): zbiór wierszy z wielu takich tabel
I wiÍkszoúÊ produktów oferowana przez ma≥o znanych dostawców o jednakowych wartoúciach w poczπtkowych kolumnach klucza
I brak ustandaryzowanych interfejsów i jÍzyków dostÍpu do danych – symuluje to tabele o zmiennej strukturze
I tworzenie zapytaÒ zwykle jedynie niskopoziomowo I takie struktury moøna bardzo efektywnie kompresowaÊ
I Produkty: Apache Cassandra (uøywana w Facebooku), HBase,
Hypertable, Bigtable (Google)
Bazy NoSQL Bazy NoSQL
XML-owe bazy danych (Native XML databases)
Bazy dokumentowe I Zasada dzia≥ania
I Stary pomys≥ pod nowπ nazwπ I dokumenty XML sπ g≥ównym typem obiektów w bazie
I istnieje formalny model dokumentu XML
I Zasada dzia≥ania I zwykle istnieje jakiú rodzaj kolekcji dokumentów
I przechowywanie dokumentów I moøliwe jest wyszukiwanie za pomocπ specjalnego XML-owego
I róøne formaty, np. tekst, JSON (tekstowy format zapisu z≥oøonych jÍzyka zapytaÒ, np. XPath lub XQuery
obiektów zwiπzany z jÍzykiem JavaScript), XML I istniejπ interfejsy do jÍzyków programowania, np. XQJ (XQuery API
I organizowanie dokumentów za pomocπ: kolekcji, znaczników (tags), for Java)
metadanych, hierarchii katalogów itp.
I Produkty (liczne): MarkLogic, Tamino (Software AG), Sedna XML
I Produkty: Lotus Notes (IBM), MongoDB, Apache CouchDB, Database, BaseX, eXist-DB, Apache Xindice, X-Hive/DB
RavenDB, FleetDB (MIT)
I Ze wzglÍdu na szybkie pojawienie siÍ wsparcia dla XML w g≥ównych
RDBMS, produkty te nie zdoby≥y znaczπcej pozycji
Bazy NoSQL Podsumowanie
Bazy grafowe Podsumowanie
I Zasada dzia≥ania I Wielkie bazy danych (VLDB) wymagajπ specjalnych úrodków
I wyspecjalizowane do przechowywania grafów technicznych, by zapewniÊ odpowiedniπ wydajnoúÊ dzia≥ania i wydolnoúÊ
I wÍz≥y i ≥uki tych grafów zwykle mogπ mieÊ wiele w≥aúciwoúci operacji administracyjnych
I szybkie wyszukiwanie w grafie, np. szukanie najkrótszej úcieøki I Niektóre úrodki techniczne, jak np. partycjonowanie, majπ zastosowanie
I Produkty: Neo4J, OrientDB, DEX, InfoGrid uniwersalne, inne, jak kompresja tabel, nadajπ siÍ tylko do zastosowaÒ
gdzie nie ma wielu modyfikacji danych, g≥ównie do baz analitycznych
I Obiektowy model danych, powszechnie stosowany w programowaniu,
Bazy RDF
mimo wielu istotnych zalet w bazach danych siÍ nie przyjπ≥
I Zasada dzia≥ania I Model relacyjno-obiektowy, mogπcy stanowiÊ ewolucyjne przejúcie do
I RDF (Resource Description Framework) to stworzony przez W3C obiektowoúci, ma wprawdzie implementacje w powszechnie uøywanych
uniwersalny model metadanych do opisu zasobów (internetowych) DBMS, ale jego uøycie nie jest popularne
I bazuje na tzw. trójkach RDF: podmiot – predykat (orzeczenie) – I NoSQL nie jest to nazwa jakiejú konkretnej technologii, ale termin
obiekt (dope≥nienie), np. Adam – jest mÍøem – Ewy marketingowy oznaczajπcy bardzo róøne rozwiπzania nierelacyjne
I odpowiada to modelowi grafu skierowanego: podmioty i obiekty sπ I Wúród rozwiπzaÒ NoSQL sπ i bardzo stare, i ca≥kiem nowatorskie
wÍz≥ami, predykaty – ≥ukami I Bazy NoSQL mogπ stanowiÊ dobrπ, niekiedy taniπ, alternatywÍ dla baz
I baza danych przechowuje informacjÍ w RDF i umoøliwia zapytania, relacyjnych w specyficznych i nietypowych zastosowaniach
np. w jÍzyku SPARQL (W3C) lub RDQL I Bazy te nie sπ jednak uniwersalne, na ogó≥ nie majπ ugruntowanej pozycji
rynkowej, pewnych dostawców zapewniajπcych wsparcie techniczne itp.
I Produkty: Jena, Sesame, AllegroGraph, 4Store I Dlatego w typowych zastosowaniach ciπgle dominujπ bazy relacyjne

BD Druk Compressed

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BD Druk Compressed

Uploaded by

Copyright:

Available Formats

BD.1 – Systemy z bazami danych BD.

1 – Systemy z bazami danych

VARCHAR2 (15 CHAR)

WiÍzy w strukturze hurtowni

I Klucze g≥ówne sπ zrealizowane jak w OLTP

You might also like