Formy SQL-a

1. Systemy przetwarzania danych masowych (problemy, podstawowe funkcje, sposoby
realizacji)
2. Wielowarstwowe modelowanie danych (modele: konceptualny, logiczny i fizyczny)
3. Definicje i pojęcia relacyjnego modelu danych
4. Projektowanie struktury relacyjnego modelu bazy danych: metody intuicyjne i formalne (formy
normalne)
5. Przegląd problemów zachowania integralności bazy danych i elementy praktycznego jej
definiowania (kontrola danych i transakcji)
6. Języki relacyjnych baz danych;
o algebra relacji i operowanie na danych,
o rola języków proceduralnych i deklaratywnych,
o podstawowe elementy języków QBE,
o geneza SQL,
7. SQL; podstawowe konstrukcje, standardy
8. Architektura funkcjonalna Systemów Zarządzania Bazami Danych (model funkcjonalny SZBD
ANSI/SPARC i jego rozszerzenia),
9. "ludzie baz danych" i ich rola
10. Realizacja implementacji aplikacji systemów baz danych (języki i narzędzia wspomagania
tworzenia aplikacji)
11. Firmowe Systemy Zarządzania Bazami Danych (ich klasyfikacja i zakresy stosowania)
12. Podstawy tworzenia aplikacji systemów baz danych - cykl życia systemu
13. Różne metodyki realizacji SBD i uwarunkowania ich zastosowania
14. Narzędzia i techniki realizacji SBD (języki, generatory, CASEy, środowiska)
15. Przegląd architektur systemów baz danych; scentralizowane (aż do mainfraim), rozproszenie
przetwarzania (rodzaje klient/serwer; od dwupoziomowych do wielopoziomowych i systemów
sieciowych), rozproszenie danych (systemy rozproszone, rozproszone transakcje, repliki bd)
16. Nierelacyjne modele baz danych (hierarchiczne, sieciowe/codasylowe, obiektowe)
17. Warunki bezpieczeństwa systemów baz danych
18. Hurtownie danych, składnice i podstawy realizacji serwerów OLAP
19. Bazy wiedzy i systemy decyzyjne (systemy ekspertowe - podstawy ich funkcji i realizacji)
20. Zarządzanie dużymi projektami informatycznymi; obszary zarządzania, metody organizacji
zespołu i zarządzanie poprzez jakość (CMM)
21. Aspekty prawne w realizacji i eksploatacji systemów baz danych
1.Systemy przetwarzania danych masowych (problemy, podstawowe funkcje, sposoby
realizacji)
Podstawowe funkcje systemu :
1. Wprowadzanie danych
2. Przechowywanie danych
3. Produkcja wyjść:
a) wyszukiwanie informacji
b) przetwarzanie informacji
4. Zawiązywanie wyjść
- dostępność
- upoważnienie dostępności
- kontrola poprawności danych i ich integralność
- wielodostęp
2.Wielowarstwowe modelowanie danych (modele: konceptualny, logiczny i fizyczny)
Model konceptualny – jest to analiza i opis świata rzeczywistego pod kątem realizacji celu.
Funkcje użytkowe- działania jakie są realizowane na danych
Dane :
- wybór zakresu interesujących nas danych
- logiczne odwzorowanie danych, zależności między danymi
Model logiczny – opisuje klasy i obiekty projektowanego systemu przy użyciu dwóch języków :
DDL –Date Description Language (Język Definicji Danych- Język Opisu Danych(JDD-JOD)).
DML – Date Manipulation Language ( Język Manipulacji Danych – JMD), za pomocą którego
opisane są funkcje użytkowe
Model ten zawiera :
Strukturę danych – model logiczny struktury; schemat bazy danych
Dodatkowe warunki integralności danych; uprawnienia użytkowników ; prespektywy
Model fizyczny –
SZBD – System Zarządzania Bazą Danych - jest to zestaw programów umożliwiających tworzenie i
eksploatację bazy danych. System zarządzania bazą danych jest oprogramowaniem ogólnego
przeznaczenia. System bazy danych składa się z bazy danych , systemu zarządzania bazą danych i
ewentualnie z zestawu aplikacji wspomagających pracę poszczególnych grup użytkowników.
3.Definicje i pojęcia relacyjnego modelu danych
Model danych w relacyjnych bazach danych składa się z 3 podstawowych elementów :
- relacyjnych struktur danych
- operatorów relacyjnych umożliwiających tworzenie , przeszukiwanie i modyfikację bazy
danych
- więzów integralności jawnie lub niejawnie określających wartości danych
Podstawową strukturą danych jest relacja będąca podzbiorem iloczynu kartezjańskiego dwóch
wybranych zbiorów reprezentujących dopuszczalne wartości. W bazach danych relacja przedstawiana
jest w postaci tabeli. Relacja jest zbiorem krotek posiadających taką samą strukturę, lecz różne
wartości. Każda krotka odpowiada jednemu wierszowi tablicy i posiada co najmniej jeden atrybut
odpowiadający pojedynczej kolumnie tablicy. Każda relacja ( tablica) posiada następujące własności:
- każda relacja w bazie danych ma jednoznaczną nazwę
- każda kolumna w relacji ma jednoznaczną nazwę w ramach jednej relacji
- wszystkie wartości w kolumnie muszą być tego samego typu
- porządek kolumn w relacji nie jest istotny
- każdy wiersz w relacji musi być różny
- porządek wierszy nie jest istotny




Wszystkie wartości danych są typów prostych
Wszystkie dane w relacyjnej bazie zapisywane są w dwuwymiarowej tablicy relacji
Po wprowadzeniu danych można porównać wartości z różnych kolumn
Operacje definiowane są logicznie
Własności relacyjnej bazy danych
- relacyjna baza danych widziana jest przez użytkowników jako zbiór relacji (tabel)
- użytkownik widzi dane w postaci wierszy i kolumn
- operatory relacyjne służą do dzielenia i łączenia relacji
- powiązania między danymi realizowane są za pomocą wartości danych
- język do wybierania danych – nieproceduralny
- zapewniona jest niezależność danych
Operatory relacji :
- Selekcja – operacja pobierania i wyświetlania danych z relacji, w wyniku której otrzymuje się
wiersze spełniające warunek logiczny
- Projekcja – operacja wybierania pewnych kolumn z relacji
- Iloczyn kartezjański – wynik połączenia wierszy z dwóch zbiorów danych
- Złączenie – wynik połączenia danych z dwóch zbiorów
- Suma zbiorów – wszystkie wiersze z obu zbiorów
- Iloczyn zbiorów – wspólne wiersze obu zbiorów
- Różnica zbiorów – tylko takie wiersze, które występują w jednym ze zbiorów
Definicje :
 Wiersze w tablicy (która reprezentuje relacje) muszą być rozróżnialne (nie możemy operować
na ich kolejności.
Musimy wybrać takie atrybuty które jednoznacznie określają dany wiersz. Zestaw takich atrybutów
nazywamy kluczem. W szczególnych przypadkach jest to 1 atrybut. Musi on jednoznacznie
określać wiersz (Inaczej jest to podzbiór atrybutów jednoznacznie nie identyfikujący wiersza).
Klucz właściwy to taki klucz z którego nie można usunąć żadnego atrybutu gdyż przestanie być
kluczem (mieć właściwości klucza) czyli jednoznacznie identyfikować wiesz.
Klucz który zawiera informacje, które możemy usunąć (jakiś atrybut) i będzie dalej kluczem
nazywamy nadkluczem.
! Zawsze dążymy do tego aby klucz był jak najkrótszy ale jednoznacznie identyfikował wiersz.
Z kluczy właściwych wybieram jeden klucz główny, który jest specjalnie traktowany, indeksowany,
według niego będziemy szybko wyszukiwać wiersze.

Klucz nazywamy kluczem prostym, jeżeli zbiór atrybutów wchodzących w jego skład jest
zbiorem jednoelementowym; w przeciwnym wypadku mamy do czynienia z kluczem
złożonym. Najczęściej w relacji można wyróżnić wiele kluczy, które nazywamy kluczami
potencjalnymi. Jeden (wybrany) klucz spośród kluczy potencjalnych nazywamy kluczem
głównym , natomiast pozostałe kluczami drugorzędnymi.
Klucz główny – jedna lub więcej kolumn tabeli, w których wartości jednoznacznie identyfikują
każdy wiersz tabeli;
W każdej relacji może istnieć wiele kluczy kandydujących;
Klucz główny wybierany jest ze zbioru kluczy kandydujących;
Każdy klucz kandydujący i główny musi być jednoznaczny i nie może zawierać wartości null
Dążymy do tego aby klucz główny był:
 Jak najkrótszy (ze względu na to że powtarza się w różnych tabelach oraz ze względu na
szybkość przetwarzania.)
 Niezmienny w czasie pracy systemu (nie zmieniał się), gdyż jest podstawą odwzorowania
związków logicznych, zmiany w kluczach głównych są bardzo skomplikowane. W dużych
systemach klucze powtarzają się mnóstwo razy co wymusza mnóstwo zmian.




Klucz obcy – kolumna stanowi klucz obcy tabel , jeżeli występują w niej jedynie wartości
klucza podstawowego innej tabeli;
Jest to sposób łączenia danych przechowywanych w różnych tabelach;
Klucz obcy – kolumna lub grupa kolumn tabeli.
Atrybut relacji nazywamy podstawowym, jeżeli należy do dowolnego z kluczy tej relacji
Atrybut nazywamy wtórnym, jeżeli nie należy do żadnego z kluczy tej relacji.
Związki :
- reguły definiowania związków : liczebność , opcjonalność
- liczebność : związek 1:1 , 1:M, N:M
4. Projektowanie struktury relacyjnego modelu bazy danych: metody intuicyjne i formalne
(formy normalne)
Normalizacja relacji ma na celu takie jej przekształcenie, by nie posiadała ona cech niepożądanych.
Jako główną cechę niepożądaną wymienić należy redundancję ( powtarzanie się) danych. Inne cechy
niepożądane związane są z możliwościami operowania na bazie danych.
Normalizacja:
 Podejście intuicyjne,
 Podejście formalne,
Schemat spełnia Formę Normalną, jeżeli jego wszystkie tabele spełniają warunki Formy
Normalnej.
Jeżeli jakaś tabela spełnia warunki I Formy Normalnej, to jest w Formie Normalnej I.
Tabela jest w N Formie Normalnej, jeżeli jest w formie N-1 i spełnia dodatkowo warunki N
Formy Normalnej.
1. I Forma Normalna.
Tabela jest w I Formie Normalnej, gdy wielkość atrybutów są typami atomowymi (z dopuszczalnego
prze SZBD zakresu.
(Typy atomowe – z punktu widzenia SZBD, są widziane jako całość.
2. II Forma Normalna.
Znalezienie zależności funkcjonalnych pomiędzy atrybutami w tabeli. Y jest w zależności
funkcjonalnej do X, gdy wartość atrybutu X wyznacza wartość Y. X
Y
Tabela jest w II Formie Normalnej, jeżeli jest w I Formie Normalnej, oraz jeżeli każdy atrybut zwykły
jest w pełni funkcjonalnie zależny od klucza głównego.
Pełna zależność – to znaczy atrybut zależy od wszystkich atrybutów klucza głównego.
3. III Forma Normalna.
Tabela jest w III Formie Normalnej, jeżeli jest w II Formie Normalnej, oraz jeżeli spełnia warunek że
żaden atrybut zwykły nie zależy funkcjonalnie przechodnio (inaczej zależność tranzytywna) od klucza
głównego.
Inaczej, że każdy atrybut zależy wyłącznie od klucza głównego.
Zależność funkcjonalna przechodnia - X
Y
Z.
Forma Normalna BoyceCood.
Tabela jest w Formie Normalnej BoyceCodd’a , jeżeli tablica jest w III Formie Normalnej i każda
zależność funkcjonalna atrybutu zwykłego zależy nie tylko od klucza właściwego.
4. IV Forma Normalna.
Tablica jest w IV Formie Normalnej jeżeli jest w III Formie Normalnej, i występuje w niej co najwyżej
jedna wielowartościowa zależność funkcjonalna.
Wielowartościowe zależności funkcjonalne – występują gdy więcej niż 1 wiersza tej tablicy występują
te same wartości atrybutu niezależnie od pozostałych atrybutów.
5. V Forma Normalna.
Tablica jest w V Formie Normalnej jeżeli jest w IV Formie Normalnej, oraz może w niej występować co
najwyżej jedna wielowartościowa zależność funkcjonalna przechodnia.
Formy Normalne w niewielkich projektach w których jesteśmy w stanie objąć sens danych nie
są nam konieczne, poradzimy sobie bez nich. Gorzej natomiast przy dużych (dużych czyli złożonych)
projektach, realizowanych przez grupy osób.
5.Przegląd problemów zachowania integralności bazy danych i elementy praktycznego jej
definiowania (kontrola danych i transakcji)
Transakcja jest sekwencją instrukcji po wykonaniu której spójna baza danych nadal zachowuje swą
spójność ( zgodność z modelowaną rzeczywistością). Transakcja jest operacją atomową tzn. system
zarządzania bazą danych może wykonać wszystkie instrukcje wchodzące w skład transakcji albo
żadnej.
Zarządzanie transakcjami
Model transakcji ACID
• Atomicity – niepodzielność
• Consistency – zachowanie spójności (po zakończeniu transakcji)
• Isolation – izolacja (semantyczna) transakcji działających w tym samym czasie
• Durability – trwałość i odporność wyników transakcji np. na awarię
Realizacja w relacyjnych b.d.
• Obsługa przetwarzania transakcyjnego
– z reguły wbudowana w DBMS
– możliwe współdziałanie w zewnętrznymi monitorami transakcyjnymi
• Instrukcje SQL
– COMMIT – zatwierdzenie
– ROLLBACK – wycofanie
Częściowe wycofywanie transakcji
• Punkty kontrolne (savepoints) i wycofanie do nich (ROLLBACK TO SAVEPOINT)
• Niejawne punkty kontrolne w niektórych implementacjach SQL
• Transakcje zagnieżdżone (nested transactions)
Transakcje autonomiczne
• Całkowicie niezależne od transakcji głównej: osobno zatwierdzane lub odrzucane
• Typowe zastosowanie: audyt, zapis dzienników operacji itp.
Problemy wielodostępu
Problemy związane z wielodostępem
• Brudne odczyty (dirty reads)
• Niepowtarzalność odczytu, fantomy i niespójna analiza
• Utracone modyfikacje
• Niespójny odczyt w ramach zapytania
• Niespójny odczyt w ramach transakcji
• Konflikty między DML i DDL
Rozwiązania
• Izolacja transakcji może zapobiegać
– brudnym odczytom
– niepowtarzalności odczytu, fantomom i niespójnej analizie
– niespójności odczytu
• Blokady mogą zapobiegać
– utraconym modyfikacjom
– konfliktom DML-DDL
Izolacja transakcji
Poziomy izolacji
• Określają, które z problemów wielodostępu są automatycznie eliminowane przez system
zarządzania transakcjami
• Poziomy izolacji w SQL
– read uncommited
– read commited
– repeatable read
– serializable
* transakcja nie widzi żadnych zmian wprowadzonych przez transakcje współbieżne
* transakcja może modyfikować dane tylko jeśli nie zostały zmodyfikowane przez zatwierdzone
współbieżne transakcje
• Transakcje read only
– transakcje tak zadeklarowane nie mogą modyfikować danych
– w Oracle są one izolowane na poziomie serializable
Metody izolacji transakcji
Blokady
• Działanie
– odczyt powoduje założenie blokady
dzielonej
• Zalety
– stosunkowo proste w realizacji
– nie wymaga dodatkowych zasobów
• Wady
– odczyty konkurują z zapisami
– przy zapisie konieczna konwersja blokady
– grozi pojawianiem się nie zablokowanych fantomów, gdyż w chwili zakładania blokady wiersze te
jeszcze nie istniały
Wersjowanie
• Działanie
– każdy zapis powoduje powstanie dwóch wersji zmienianych danych
* dla zapisującej transakcji
* dla „reszty świata”
• Zalety
– odczyty nie konkurują z zapisami
• Wady
– wymaga dodatkowych zasobów (problemy przy długich transakcjach)
– trudniejsze w realizacji
Szeregowalność
Szeregowalność (serializability)
• Wynik działania współbieżnych transakcji jest taki, jak gdyby były one wykonane sekwencyjnie
• W wyniku działania transakcji szeregowalnych stan bazy pozostaje spójny
Zarządzanie współbieżnością
• Optymistyczne
– wykrywanie konfliktów
– w wypadku ich wykrycia – odrzucenie transakcji
• Pesymistyczne
– zapobieganie problemom, np. za pomocą blokad
Dwufazowe blokowanie (two-phase locking, 2PL )
• Zapewnia szeregowalność transakcji
• Zasada: żadna blokada nie może być zdjęta przed założeniem wszystkich blokad transakcji
• Typowa realizacja:
– faza wzrostu: transakcja zakłada kolejne blokady, nie zdejmując żadnej
– faza zatwierdzania: blokady są zdejmowane przez zakończenie transakcji (COMMIT lub
ROLLBACK)
Blokady (locks)
Ziarnistość (granularity) blokad
• Poziom tabeli
• Poziom wiersza albo strony
Poziomy blokowania
• Określają siłę (restryktywność) blokad
• Tzw. macierz kompatybilności definiuje wzajemne oddziaływanie blokad różnych poziomów
• Poziomy blokad wierszy
– dzielone (shared)
– wyłączne (exclusive)
– aktualizujące, przyrostowe itd.
• Poziomy blokad tabel
– row share, row exclusive, share, share row exclusive, exclusive
Obiekty blokowane
• Dane (automatycznie lub „ręcznie”)
• Słownik (automatycznie)
Wytyczne dla blokowania
• Blokady powinny eliminować problemy związane z wielodostępem, których nie usunięto innymi
metodami
• Blokady powinny w najmniejszym możliwym stopniu ograniczać wielodostęp
– możliwie najmniejszy zasięg i najmniejsza restryktywność
– odczyty nie czekają na zapisy i odwrotnie
6.Języki relacyjnych baz danych; algebra relacji i operowanie na danych,
rola języków proceduralnych i deklaratywnych,
Zdania języka:
1. Języki definiowania danych - Definiowanie bazy danych (DDL):
 Tabel Bazy Danych,
 Związków logicznych,
 View – perspektywy, (upraszcza zadawanie pytań, zwiększa .?. danych - wady;
opóźnienie, problemy przy dodawaniu rekordów, większość SZBD może nie
zezwalać na aktualizację poprzez widoki).
 Więzy integralnościowe,

Definicja uprawnień (często wyodrębniony jako oddzielny język definiowania
uprawnień – DAL).
2. Języki manipulacji danych (DML):
 Dopisywanie wiersza do tablicy,
 Usuwanie wiersza z tablicy,
 Aktualizacja danych,
 Wyszukiwanie danych. !
3. Inne:
 Definiowanie transakcji.
Formalne podstawy języków – Codd.
JDD – języki deklaratywne.
JMD – języki algorytmiczne lub deklaratywne.
Języki:
1. Języki oparte na algebrze relacji (algorytmiczne),
2. Języki (różne) budowane w oparciu o rachunek relacyjny (deklaratywne).
2.1. w oparciu o dziedziny,
2.2. w oparciu o wiersze,
3. Języki transformacji (zawierają część języków 1, 2.1, 2.2 – np. SQL – deklaratywny),
4. Języki oparte na reprezentacji graficznej (QBE - Query Be Example, inaczej QBF Query By Form). (deklaratywne, oparte o 2.1).
5. Języki czwartej generacji – 4 GL – języki wybigające nad DDL i DML, do pisania
aplikacji, realizujące znacznie więcej funkcji.
1. Języki oparte na algebrze relacji.
Element algebry relacji istotne przy definiowaniu języków:
R1 = f (R) – działania 1 argumentowe.
- Operacja selekcji:
R1 warunek (R)
Można spotkać się z symbolem
ta)
R
R1
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
- Operacja rzutu:
Wiersze spełniające
warunek
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
lista atrybutów) (R)
a1
a2
a3
a4
a5
a6
a1
a3
a5
 ( a1, a3, a5 ) (R)
Jest operacją, która daje tabelę pochodną do R w której pozostają kolumny znajdujące się na liście
atrybutów. Ilość wierszy zostanie zredukowana jeżeli pojawią się takie same wiersze.
- Suma:
a1
A
A
A
A
a2
A
A
A
A
a3
A
A
A
A
a4
A
A
A
A
U
a1
B
B
B
a2
B
B
B
a3
B
B
B
a4
B
B
B
U
a1
A
A
A
A
B
B
B
a2
A
A
A
A
B
B
B
a3
A
A
A
A
B
B
B
a4
A
A
A
A
B
B
B
Suma jest tablicą wynikową, zawierającą wiersze z obydwu tabel, tabele muszą posiadać taki sam
zestaw atrybutów.
- Rożnica:
Aa1
C
A
X
S
a2
C
A
X
S
a3
C
A
X
S
a4
C
A
X
S
_
a1
C
Z
X
H
a2
C
Z
X
H
a3
C
Z
X
H
a4
C
Z
X
H
-
a1
A
S
Z
H
a2
A
S
Z
H
a3
A
S
Z
H
a4
A
S
Z
H
Różnica jest tablicą wynikową, zawierającą wiersze które nie są identyczne , wszystkie trzy tabele
muszą posiadać taki sam zestaw atrybutów.
- Przekrój (Iloczyn):
a1
C
A
X
S
a2
C
A
X
S
a3
C
A
X
S
a4
C
A
X
S
a1
C
Z
X
H
a2
C
Z
X
H
a3
C
Z
X
H
a4
C
Z
X
H

a1
C
X
a2
C
X
a3
C
X
a4
C
X
Różnica jest tablicą wynikową, zawierającą wiersze które występują w tabeli A i B , wszystkie trzy
tabele muszą posiadać taki sam zestaw atrybutów.
Język będziemy definiować w oparciu o te operacje, czyli operacje; selekcji, rzutu, sumy,
różnicy, przekroju.
W ten sposób język może:
- wyszukiwać,
- dodawać wiersz (wiersze),
- usuwać wiersz (wiersze),
- aktualizować wiersz.
Ale nie wiemy jak połączyć tabele z różnymi atrybutami ?
- Iloczyn Kartezjański:
a1
C
A
X
a2
C
A
X
a3
C
A
X
X
b1
Z
H
b2
Z
H
X
a1
C
C
A
A
X
X
a2
C
C
A
A
X
X
a3
C
C
A
A
X
X
b1
Z
H
Z
H
Z
H
b2
Z
H
Z
H
Z
H
Iloczyn kartezjański jest tablicą wynikową, zawierającą kombinacje wierszy z obu tabel (A i B).
Iloczyn + Selekcja – nazywany jest złączeniem naturalnym.
Język algorytmiczny musi posiadać umiejętność generowania algorytmów.
7.Geneza SQL,
SQL (ang. Structured Query Language) to strukturalny język (informatyka) zapytań używany do
tworzenia, modyfikowania baz danych oraz do umieszczania i pobierania danych z baz danych.
Język SQL jest językiem deklaratywnym. Decyzję o sposobie przechowywania i pobrania danych
pozostawia się systemowi zarządzania bazą danych DBMS.
8.SQL; podstawowe konstrukcje, standardy
Standardy SQL
W 1986 roku SQL stał się oficjalnym standardem, wspieranym przez Międzynarodową Organizację
Normalizacyjną (ISO) i jej członka, Amerykański Narodowy Instytut Normalizacji (ANSI). Wczesne
wersje specyfikacji (SQL86 i SQL89) były w dużej mierze jedynie określeniem wspólnej płaszczyzny
łączącej różne istniejące wówczas produkty i pozostawiały wiele swobody twórcom implementacji. Z
czasem jednak systemy komputerowe uległy integracji i rynek zaczął domagać się aplikacji oraz ich
funkcji faktycznie współpracujących z wieloma różnymi bazami danych. Pojawiła się potrzeba
określenia standardu ściślejszego. Mógł on jednocześnie obejmować nowe elementy, nieujęte do tej
pory w języku. Tak powstał SQL92, obowiązujący w produktach komercyjnych do dziś.
Formy SQL-a
Z technicznego punktu widzenia, SQL jest podjęzykiem danych. Oznacza to, że jest on
wykorzystywany wyłącznie do komunikacji z bazą danych. Nie posiada on cech pozwalających na
tworzenie kompletnych programów. Jego wykorzystanie może być trojakie i z tego względu wyróżnia
się trzy formy SQL-a:
1. SQL interakcyjny lub autonomiczny wykorzystywany jest przez użytkowników w celu
bezpośredniego pobierania lub wprowadzania informacji do bazy. Przykładem może być
zapytanie prowadzące do uzyskania zestawienia aktywności kont w miesiącu. Wynik jest
wówczas przekazywany na ekran, z ewentualną opcją jego przekierowania do pliku lub
drukarki.
2. Statyczny kod SQL (Static SQL) nie ulega zmianom i pisany jest wraz z całą aplikacją,
podczas której pracy jest wykorzystywany. Nie ulega zmianom w sensie zachowania
niezmiennej treści instrukcji, które jednak zawierać mogą odwołania do zmiennych lub
parametrów przekazujących wartości z lub do aplikacji. Statyczny SQL występuje w dwóch
odmianach.
1. Embedded SQL (Osadzony SQL) oznacza włączenie kodu SQL do kodu źródłowego
innego języka. Większość aplikacji pisana jest w takich językach jak C++ czy Java,
jedynie odwołania do bazy danych realizowane są w SQL. W tej odmianie
statycznego SQL-a do przenoszenia wartości wykorzystywane są zmienne.
2. Język modułów. W tym podejściu moduły SQL łączone są z modułami kodu w innym
języku. Moduły kodu SQL przenoszą wartości do i z parametrów, podobnie jak to się
dzieje przy wywoływaniu podprogramów w większości języków proceduralnych. Jest
to pierwotne podejście, zaproponowane w standardzie SQL. Embedded SQL został
do oficjalnej specyfikacji włączony nieco później.
3. Dynamiczny kod SQL (Dynamic SQL) generowany jest w trakcie pracy aplikacji.
Wykorzystuje się go w miejsce podejścia statycznego, jeżeli w chwili pisania aplikacji nie jest
możliwe określenie treści potrzebnych zapytań - powstaje ona w oparciu o decyzje
użytkownika. Tę formę SQL generują przede wszystkim takie narzędzia jak graficzne języki
zapytań. Utworzenie odpowiedniego zapytania jest tu odpowiedzią na działania użytkownika.
Wymagania tych trzech form różnią się i znajduje to odbicie w wykorzystywanych przez nie
konstrukcjach językowych. Zarówno statyczny, jak i dynamiczny SQL uzupełniają formę autonomiczną
cechami odpowiednimi tylko w określonych sytuacjach. Większość języka pozostaje jednak dla
wszystkich form identyczna.
Składnia SQL
Użycie SQL, zgodnie z jego nazwą, polega na zadawaniu zapytań do bazy danych. Zapytania można
zaliczyć do jednego z dwóch głównych podzbiorów:


SQL DML (ang. Data Manipulation Language, czyli Język Manipulacji Danymi),
SQL DDL (ang. Data Definition Language, czyli Język Definicji Danych).
Instrukcje SQL w obrębie zapytań tradycyjnie zapisywane są wielkimi literami, jednak nie jest to
wymóg. Każde zapytanie w SQL-u musi kończyć się znakiem ";" (średnik).
Dodatkowo, niektóre interpretery SQL (np. psql w przypadku PostgreSQL), używają swoich własnych
instrukcji, spoza standardu SQL, które służą np. do połączenia się z bazą, wyświetlenia dokumentacji,
itp.
DML
DML służy do operacji na danych - do ich umieszczania w bazie, kasowania, przeglądania, zmiany.
Najważniejsze polecenia z tego zbioru to:




SELECT - pobranie z bazy danych,
INSERT - umieszczenie danych w bazie,
UPDATE - zmiana danych,
DELETE - usunięcie danych z bazy.
Dane tekstowe podawane muszą być zawsze w formie ograniczonej znakami pojedynczego
cudzysłowu (').
DDL
Dzięki DDL natomiast, można operować na strukturach, w których te dane są przechowywane - czyli
np. dodawać, zmieniać i kasować tabele lub bazy. Najważeniejsze polecenia tej grupy to:



CREATE (np. CREATE TABLE, CREATE DATABASE, ...) - utworzenie struktury (bazy, tabeli,
indeksu, itp.),
DROP (np. DROP TABLE, DROP DATABASE, ...) - całkowite usunięcie struktury,
ALTER (np. ALTER TABLE ADD COLUMN ...) - zmiana struktury (dodanie kolumny do tabeli,
zmiana typu danych w kolumnie tabeli).
9.Architektura funkcjonalna Systemów Zarządzania Bazami Danych (model funkcjonalny SZBD
ANSI/SPARC i jego rozszerzenia),
"ludzie baz danych" i ich rola
- Grupa SPARK – opracowała architekture systemów baz danych.
- Założenie istnienia 3 modeli danych:
n - modeli
Model
zewnętrzny
danych
nX
1X
Model logiczny
danych
- hierarchiczny,
- sieciowy,
- relacyjny,
- obiektowy,
- dedukcyjny
Użytkownik
1X
Model fizyczny
danych
Model zewnętrzny obejmuje wybraną część danych, zależną od potrzeb grup użytkowników.
Rysunek 7
Założenie na jednym komputerze, w dzisiejszych czasach architektura realizowana jest na wielu
komputerach co znacznie komplikuje sytuacje.
Podstawowa koncepcja realizowania Baz Danych w architekturze kijent – serwer.
Rysunek 8
Największa rewolucja w koncepcji Systemów Baz Danych ostatnich lat. (wydzielamy funkcjie
użytkowe).
Pozwala to tworzyć funkcje użytkowe na różne platformy, jest to take dużo tańsze rozwiązanie.
Systemy Zarządzania Baz Danych
- Historia SZBD.
- Obecne SZBD:
- Oracle,
- DB/2, (IBM)
- INFORMIX (narzędzia 4GL)
- SYBASE (Sun) – dużo mniejsza
poprzednich.
IBM wykupił INFORMIX, wydano
narzędzia do migracji na DB/2
sprzedaż od
Kilka lat temu istniały jeszcze:
- Progres,
- Ingres
Systemy te dorównywały czołówce, ale były tańsze i przeznaczone na mniejsze maszyny
Wraz z rozwojem komputerów PC pojawiły się SZBD na nie:
- początek to dBase (jeszcze nie SZBD),
- Microsoft Access,
- FoxPro,
- Clipper,
- Paradox (Borland).
Systemy te zaczeły dynamicznie się rozwijać znajdująć ogromny rynek.
W wyniku ostrej konkurencji Borland wykupił Clippera (Paradox), a Microsoft wykupił Fox Pro.
Powstały nowe linie produktów Interbese (Borland) i MS SQL Server (Microsoft).
Powstał jeszcze jeden system (który jest kością niezgody) istniejący obecnie jako open source
(na bazie Ingresu) PostgreSQL i mniejszy MySQL.
W odpowiedzi wielu producentów dużych systemów utworzyło mniejsze wersje swoich
systemów które mogłyby konkurować z mniejszymi systemami (potem przejście na duży
system).
10.Realizacja implementacji aplikacji systemów baz danych (języki i narzędzia wspomagania
tworzenia aplikacji)
Typy narzędzi do tworzenia aplikacji
Tradycyjne programowanie 3GL
• Języki: C, C++, Cobol, Java itp.
• Cechy
– niemal nieograniczone możliwości
– trudne – bardzo mała wydajność
– programy bardzo trudne do utrzymania
RAD (Rapid Application Development)
• Narzędzia: Visual Basic, Delphi, JBuilder
itp.
• Cechy
– duże możliwości
– znacznie większa wydajność
– dość trudne w użyciu – typowe działania
wymagają programowania
– programy dość trudne do utrzymania –
duża swoboda programisty
Specjalizowane narzędzia 4GL
• Cechy 4GL dla aplikacji z bazami danych
– programowanie zdarzeniowe
(event-driven)
– programowanie wizualne
– zintegrowane graficzne środowisko
projektowo-programistyczne
– konstrukcje wysokiego poziomu do
realizacji typowych zadań, np. interakcji
z użytkownikiem i bazą danych
– silne wykorzystanie możliwości DBMS
– typowe funkcjonalności aplikacji
wbudowane w narzędzie
• Narzędzia 4GL: Oracle Forms+Reports,
Powerbuilder itp.
• Cechy użycia 4GL
– duża wydajność programisty
– łatwe w użyciu – typowe funkcje
realizowane domyślnie
– łatwe utrzymanie – mało programowania, dość mała swoboda
programisty
- trudne uzyskanie nietypowego działania
Generatory aplikacji
• Generowanie aplikacji na podstawie
specyfikacji
• Narzędzia: systemy CASE,
np. Oracle Designer
• Aplikacja generowana w 3GL lub 4GL,
niekiedy wymaga niewielkich poprawek
• Cechy
– bardzo duża wydajność pracy
– powtarzalność wyników
– stosunkowo łatwe utrzymanie
– bardzo trudne uzyskanie nietypowego działania
– narzędzia obszerne i trudne do opanowania
11.Firmowe Systemy Zarządzania Bazami Danych (ich klasyfikacja i zakresy stosowania)
12. Podstawy tworzenia aplikacji systemów baz danych - cykl życia systemu
Systemy informacyjne z bazami danych
• Zwykle bardzo złożone
– złożone funkcjonalnie
– technicznie bardzo skomplikowane
• Tworzone na indywidualne zamówienie
– często o niepowtarzalnej funkcjonalności
• Bez możliwości długiego i masowego testowania
• Przeznaczone do długoletniej eksploatacji
• Silnie zmieniające się w czasie eksploatacji
• Często przeznaczone do użycia w skali korporacyjnej (enterprise)
• Silnie powiązane z innymi istniejącymi wcześniej i równoległe systemami
– ładowanie wcześniej istniejących danych
– współdziałanie
– stare technologie (legacy systems)
Ogólne cechy dużych systemów
• Każdy system jest częścią większego systemu
• W każdym systemie da się wydzielić podsystemy
• Systemy z reguły rosną z czasem
• Większa specjalizacja powoduje większe trudności w przystosowaniu
Pożądane cechy s.i.
• Podatność na zmiany
– łatwość wprowadzania zmian
– niski koszt zmian (w tym testów regresyjnych)
– niskie ryzyko zmian
• Stabilność technologii
– technologia w miarę szeroko znana i wykorzystywana
– stabilna pozycja rynkowa dostawców
– duże szanse wsparcia w okresie wielu lat
– technologia rozwijająca się
• Otwartość
– zdolność do współdziałania (interfejsy, bramki itp.)
– internacjonalizacja
– rozszerzalność
• Przenośność
– sprzęt
– systemy operacyjne
– architektury
• Skalowalność
– upsizing, downsizing
– VLDB
Cykle życia s. i.
Model kaskadowy (waterfall )
• Założenia formułowane na początku
• Długi czas realizacji
• Duże ryzyko inwestora
Model przyrostowo-spiralny
• Podział na podsystemy (wspólna faza planowania)
• Realizacja kolejnych podsystemów
• Akceptacje w każdym cyklu
• Modyfikacje poprzednich podsystemów
• Krótszy czas realizacji
• Mniejsze ryzyko inwestora
13. Różne metodyki realizacji SBD i uwarunkowania ich zastosowania
Strukturalne
• Dane i procesy modelowane osobno
• Wykorzystują tylko proste typy danych
• Dobrze dostosowane do modelu relacyjnego danych
• Podstawowe techniki
– diagramy związków encji (ERD)
– hierarchie funkcji (FHD)
– diagramy przepływu danych (DFD)
– modele macierzowe
Obiektowe
• Dane i procesy są modelowane łącznie
• Wykorzystują złożone typy danych
• Dostosowane do obiektowego modelu danych
• W przypadku realizacji opartej na relacyjnej b.d. wynikowy obiektowy model danych musi być
odpowiednio przekształcony
• Podstawowe techniki
– diagramy klas UML
– przypadki użycia i modele dynamiczne UML
14. Narzędzia i techniki realizacji SBD (języki, generatory, CASEy, środowiska)
Narzędzia CASE (Computer Aided Software Engineering)
• Zintegrowane pakiety oprogramowania realizującego zbior technik projektowania
• Dostosowane do konkretnej metodyki lub rodzaju metodyk
• Zwykle wyposażone w repozytorium
Typy narzędzi CASE
• Upper CASE
– wspomaganie wczesnych faz projektu – planowanie, analiza
• Lower CASE
– wspomaganie faz projektowania i wykonania
– ścisła integracja z konkretnym środowiskiem implementacyjnym
– generatory kodu, wspołdziałanie z narzędziami RAD (Rapid Application
Development)
Repozytorium
• Składnica informacji projektowej
• Powinno zawierać całość informacji o przebiegu projektu
– dokumenty
– decyzje
– opisy, uzasadnienia i komentarze
– modele
– wyniki
• Pożądane jest, by umożliwiało wersjowanie
Języki
- definiowania danych – DATA DEFINITION LANGUAGE (DDL)
- manipulowania danymi – DATA MANIPULATING LANGUAGE (DML)
- sterowania danymi – DATA CONTROL LANGUAGE (DCL)
- zapytań – QUERY LANGUAGE
Generatory
T-SQL, EMS MySQL Data Generator
Środowiska
DB2, Oracle, MySQL, MS SQL Server, PostgreSQL, SQLite, MS Access, SAP DB
Techniki
• Określają sposób wykonania konkretnych zadań projektowych
• Dostarczają modeli formalnych
• Zwykle mogą być zastosowane „ręcznie” lub z użyciem odpowiednich narzędzi
15. Przegląd architektur systemów baz danych; scentralizowane (aż do mainfraim),
rozproszenie przetwarzania (rodzaje klient/serwer; od dwupoziomowych do wielopoziomowych
i systemów sieciowych), rozproszenie danych (systemy rozproszone, rozproszone transakcje,
repliki bd)
• Systemy scentralizowane
- Przestarzały
- Klienci – duże korporacje, duża moc obliczeniowa wykorzystywana przez grupy terminalowe
- Przetwarzanie wsadowe
- Zastąpiony przez architekturę klient - serwer w latach 80-tych
- Systemy typu mainframe - Systemy typu mainframe (duża maszyna obliczeniowa) były
popularnym i historycznie pierwszym rozwiązaniem w zakresie implementacji systemów baz
danych. W rozwiązaniu tym rolę pierwszoplanową odgrywał główny komputer, do którego
podłączano szereg terminali
• Architektura klient-serwer
- Dwa lub więcej procesów współdziałających w rolach podrzędny-nadrzędny
- Klient wysyła zapytanie, które jest obsługiwane przez proces serwera
- Podział na model dwu- i trzywarstwowy
• Model dwuwarstwowy
- Wyróżniamy dwa procesy: klienta i bazy danych
- Procesy realizowane na odrębnych maszynach
- Proces klienta obsługuje aplikacje i prezentacje, proces serwera zarządza regułami i danymi
• Model trzywarstwowy
-Stosowany w przypadku skomplikowanych problemów decyzyjnych i obszernych zagadnień
przetwarzania transakcyjnego
- Trzy warstwy: serwer bazy danych, serwery aplikacyjne, serwery prezentacji
- Dane oddzielone są zarówno od reguł zarządzających nimi, od warstwy aplikacji, jak również
od procesu klienta realizującego warstwę prezentacji
• Architektury rozproszone
- Rozłożenie danych poprzez ich fragmentaryzację (podział) lub replikację (powielenie)
- Z punktu widzenia użytkownika traktowana jest jako spójna całość
- Trzy rodzaje przezroczystości: geograficzna, fragmentaryzacji, replikacji
- Typy rozproszonych baz danych (podział wg Beynona-Davies’a):
- System typu klient-serwer
- Jednorodna rozproszona baza danych
- Niejednorodna rozproszona baza danych
- Federacyjny system baz danych
- Kryteria wyboru:
• Równoległość
• Niezależność
• Elastyczność
• Dostępność
• Koszt/efektywność
• Bezpieczeństwo
• Architektury równoległe
- Zawiera wiele procesorów i dysków połączonych szybkim dedykowanym łączem sieciowym
- Ziarnistość systemów
- Miary wydajności:
– przepustowość – ilość zadań, które mogą być ukończone w jednostce czasu
– czas odpowiedzi – czas potrzebny na ukończenie pojedynczego zadania
- Rodzaje połączeń: magistrala, krata, hipersześcian
- Dzielona pamięć
- Dzielone zasoby masowe
- Architektura typu share nothing
- Architektura hybrydowa (hierarchiczna)
• Replikowane bazy danych
- Mechanizm ten pozwala na zwiększenie bezpieczeństwa poprzez przechowywanie
pełnoprawnej kopii struktury bazy danych na różnych serwerach
- Używa mechanizmu architektury rozproszonej
- Zwiększa wydajność i niezawodność
- Replikacja migawkowa
– nie monitoruje modyfikacji danych
– stosowana gdy dane są rzadko modyfikowane
- Replikacja transakcyjna
– wykorzystuje logi z transakcji
– stosowana gdy wymagane jest szybkie dostarczenie zmodyfikowanych
danych
- Replikacja scalana
– replikacja dwukierunkowa
– umożliwia wykonywanie zmian danych zarówno on-line jak i off-line
• Przestrzenne bazy danych
- Przestrzenne typy danych (SDT):
– wartości w SDT zawierają informacje przestrzenne oraz nie-przestrzenne
– pojedyncze obiekty:
• punkt – położenie, bezwymiarowe
• linia – połączenie
• region – obszar w przestrzeni dwuwymiarowej
– kolekcje obiektów:
• partycja – kolekcja regionów
• sieć – graf (punkty to wierzchołki, linie to krawędzie)
- Architektura rozszerzalna
- Główna idea: traktowanie przestrzennych typów danych jak wszystkich innych
- Przechowywanie przestrzennych typów danych jako obiektów
- Stosowanie przeładowywania operatorów
- Zastosowanie w elektronice, budownictwie, CAD, robotyce oraz systemy informacji
geograficznej (GIS)
• Drzewiaste bazy danych „LeftHand”
- Innowacyjne podejście do architektury bazodanowej
- Łączy wysoką dostępność, skalowalność i niezawodność z prostotą administracji i
użytkowania
- Skalowalność – dodanie kolejnego modułu – jak wpięcie urządzenia do sieci Ethernet
- Moduły – klastry, macierze dyskowe; dodawane bez potrzeby rekonfiguracji
• Rozwiązania gridowe
- Różnorodne maszyny liczące połączone w sieć (internet), oprogramowane w sposób
umożliwiający współdzielenie zasobów
- Sposób na zagospodarowanie niewykorzystanych zasobów: mocy obliczeniowej, zasobów
dyskowych, połączeń sieciowych
- Współdzielenie zasobów poprzez systemy plików (AFS, NFS, DFS, GPFS)
– bardziej zaawansowane – automatyczna duplikacja danych
- Computational grid
– łączenie zasobów poprzez wykorzystanie dostępnej aktualnie mocy obliczeniowej w
danym punkcie struktury
- Data Grid
– łączenie zasobów, bezpieczny i łatwy dostęp do rozproszonych, heterogenicznych
zbiorów danych (tysiące zbiorów, jako jedna heterogeniczna baza danych).
Wykorzystuje dane, pamięć oraz zasoby sieciowe ulokowane w różnych domenach
administracyjnych respektując globalną i lokalną politykę użytkowania danych
- Zadania/problemy:
– wyszukiwanie (jak znaleźć właściwe dane w środowisku rozproszonym)
– transfer – jak przenieść duże zasoby poprzez łącza sieciowe
– niezależność – jak łączyć różnorodne zbiory danych (DB2, Oracle, inne obiektowo
zorientowane bazy danych)
– bezpieczeństwo (mechanizm delegatów)
– zagwarantowanie prostoty użytkowania
- TOPOLOGIE
- IntraGrid – pewna liczba komputerów, dzielących wspólną domenę oraz dane
przeznaczone do użytku wewnętrznego w sieci prywatnej
– single security provider
– duża przepustowość sieci prywatnej
– wspólne środowisko
– praktycznie stała liczba dostępnych zasobów
- ExtraGrid – połączenie dwóch lub więcej sieci IntraGrid w jedną funkcjonalną całość
– wymaga więcej niż jednego security provider (większa złożoność
zarządzania)
– duża liczba, różnorodność zrzeszonych organizacji
– odmienna struktura komunikacji poszczególnych fragmentów
– zmienna liczba, wielkość zasobów
- Automatyczny dobór najlepszego urządzenia do składowania danych na podstawie
wzorca w zależności od rodzaju zadania
- Równomierne wykorzystanie mocy obliczeniowych (loadbalancing)
- Automatyczna lokalizacja i reakcja na awarie części składowych gridu
- Współdzielenie bazy danych z uaktualnianiem opóźnionym (np. poza okresem
największego ruchu w sieci) – odpowiednie narzędzia aktualizacji i synchronizacji
danych
– minimalizacja jednoczesnej liczby wpisów uaktualniających – zmniejszenie ilości
zadań oczekujących na dostęp do danych
- Metody zapobiegania wzajemnemu oczekiwaniu podzadań na udostępnienie
zasobów:
– nałożenie maksymalnego czasu oczekiwania (po jego upływie – operacja
anulowana i ponowne rozpoczęcie)
– rezerwacja zasobów w ustalonym porządku przed wykonaniem operacji (jeśli
nie można zarezerwować wszystkich potrzebnych, należy zwolnić
dotychczasowe i później spróbować ponownie)
– oprogramowanie wykrywające zastój (przed dodaniem nowego zadania,
liczony jest średni czas oczekiwania istniejącej kolejki. Jeśli dodanie
spowoduje zastój, zadanie jest usuwane i ponawia próbę po określonym czasie)
- OGRANICZENIA
- Problem skalowalności niektórych zadań na wiele jednostek/procesorów
- Czas dostępu do tej samej bazy danych
- Bezpieczeństwo danych
• Rozwiązania klastrowe
- Zastąpienie komputerów typu mainframe (stosowanych ze względu na efektywne I/O) –
skalowalność, dostępność, koszty
- Rozproszone bazy danych typu Oracle Parallel Server (OPS) – przetwarzanie wykonywane
przez aplikację rozproszone między kilka węzłów, pracujących na wspólnych danych
(protokoły uzgadniania danych)
- Zastosowania:
– dedykowane do przechowywania bardzo dużych ilości danych
– Szybki dostęp do danych przez wielu klientów równocześnie (banki, produkcyjne
bazy danych) – najczęściej Oracle Enterprise lub IBM DB/2
- Tanie komputery klasy PC, spięte siecią typu GigaNet lub Myrinet
- Hot-swapping, skalowalność i modyfikacja online
- Efektywność przy zastosowaniu niewielkiej ilości dużych maszyn typu SMP, a ostatnio server
blades (niższe zużycie energii, większe wykorzystanie zasobów)
SKŁADOWANIE DANYCH
- Osobny klaster do składowania danych
- Elementy klastra:
– duża pamięć operacyjna
– pewna liczba lokalnych dysków
- Klaster pełni więc rolę wirtualnego urządzenia dyskowego
- Zastąpienie drogich rozwiązań sprzętowych typu RAID, programowymi o
porównywalnej wydajności
16. Nierelacyjne modele baz danych (hierarchiczne, sieciowe/codasylowe, obiektowe)
Hierarchiczny model danych
Ogólnie: model danych, w którym dopuszczalnymi strukturami danych są hierarchie (drzewa). Np. na
czubku hierarchii są zapisy Dział, poniżej zapisy Pracownik i Klient, poniżej zapisu Klient zapisy
Zamówienie, poniżej zapisów Zamówienie zapisy PozycjaZamówienia. Model hierarchiczny był
pierwszym modelem danych i wiąże się go prawie wyłącznie z systemem IMS firmy IBM. Językiem
manipulacji danymi w tym systemie jest język DL/1, oparty o koncepcję nawigowania od zapisów
znajdujących się w górze hierarchii do zapisów podrzędnych. Dla modelowania koncepcyjnego model
hierarchiczny posiada zasadnicze wady, w szczególności utrudnia reprezentowanie związków
semantycznych wiele-do-wielu, oraz zmusza do często sztucznego i zbędnego nawigowania poprzez
zapisy pośrednie.
Sieciowy model danych
Sieciowy model danych w ogólnym zarysie niewiele odbiega od hierarchicznego. W miejsce związku
nadrzędny-podrzędny pomiędzy rekordami wprowadza się w nim tzw. typ kolekcji (set), który jest
złożonym typem danych pola zawierającym odniesienia do innych rekordów określonego typu. Tzn.
określenie typu kolekcji polega na podaniu typu rekordu-,,właściciela'' i typu rekordów-elementów
kolekcji (oraz ew. klucza porządkowania elementów). Operowanie danymi ma też charakter
proceduralny: typowe operacje to wyszukiwanie rekordu na podstawie zawartości pól i/lub
przynależności do danego wystąpienia typu kolekcji, i dokonywanie modyfikacji bieżącego rekordu.
Warunki integralności danych, poza oczywistymi już więzami dotyczącymi zgodności zawartości pól
rekordu z określeniem typu rekordu i unikalności pól kluczowych, mogą być formułowane w terminach
wymogu przynależności rekordu do jakiegoś wystąpienia określonego typu kolekcji.
Obiektowa baza danych
to baza danych, która przechowuje obiekty w odróżnieniu od wierszy lub krotek przechowywanych w
relacyjnej bazie danych. Ponieważ dane przechowywane są w postaci obiektów, mogą być
odczytywane tylko przy pomocy metod udostępnianych przez te obiekty.
Obiekty przechowywane w takiej bazie danych są widoczne jako obiekty języka programowania. Ta
właściwość nazywana jest transparentną persystencją (ang. transparent persistence).
W połączeniu z obiektowymi językami programowania, obiektowe bazy danych działają szybciej od
baz relacyjnych, ponieważ nie ma potrzeby przemapowywania rekordów przechowywanych w
tabelach na obiekty (ang. impedance mismatch).
Obiektowe bazy danych rozszerzają obiektowe języki programowania o funkcjonalność zarządzania
wielowątkowością, obiektowy język zapytań, funkcje odzyskiwania danych.
17. Warunki bezpieczeństwa systemów baz danych
Istnieje uzasadniona konieczność ochrony danych zarówno przed osobami, które nie powinny mieć do
nich dostępu (istnieją specjalne ustawy chroniące dane osobowe) jak i przed wypadkami losowymi, w
których dane mogą ulec zniszczeniu. Można wyróżnić kilka przypadków podczas których istnieje
zagrożenie utraty danych:
- błąd działania transakcji aktualizującej obiekty – jeśli tylko część danych zostanie zapisana to może
powstać niespójność
- błąd pracy systemu operacyjnego komputera lub systemu zarządzania bazą danych
spadek napięcia
- błędy sprzętowe, czyli uszkodzenia niektórych elementów komputera (np. pamięci dyskowej)
- błędy powstałe w bazie ze względu na uruchamianie błędnych, wadliwie skonstruowanych transakcji
Błędy tego typu powstają najczęściej w środowiskach wielodostępnych czyli takich w których wielu
użytkowników ma jednoczesny dostęp do danych. Utrzymanie spójności BD jest jednym z
podstawowych zagadnień bezpieczeństwa danych i należy do obowiązków administratora.
Podstawowe elementy ochrony BD:
kopie bezpieczeństwa – jest to podstawowa metoda ochrony ważnych danych, ale jest kosztowna ze
względu na ilość zapisywanych nośników. W czasie tworzenia kopi nie powinny być uruchamiane
żadne transakcje. W przypadku BD o szybko zmieniających się wartościach często zabezpiecza się
tylko fragmenty danych.
dziennik transakcji.
W dzienniku transakcji przechowywane są informacje o wszystkich transakcjach, które miały miejsce
od czasu utworzenia ostatniej kopii bezpieczeństwa. Zwykle zapisuje się w nim informacje takie jak:
unikalny identyfikator transakcji
adresy wszystkich obiektów aktualizowanych przez transakcję
stan obiektu przed i po modyfikacji
informacje dotyczące przebiegu transakcji (np. czasy rozpoczęcia i zakończenia)
Aby ułatwić ewentualne odzyskiwanie danych transakcje zwykle najpierw zapisują zmiany w dzienniku
a dopiero potem do właściwej bazy danych. Ułatwia to odzyskanie danych w przypadku awarii.
Transakcja
Operacja
Dziennik transakcji
Aktualizacji
(LOG FILE)
Zmiany zapisywane
dopiero po
zatwierdzeniu
Baza
Danych
transakcji
Przywracanie niespójności BD sprowadza się albo do cofania zmian dokonanych przez
aktywne (czyli nie zatwierdzone) w momencie awarii transakcje (roll-back) albo do powtórnego
zapisania zmian dokonanych przez transakcje, które zdążyły się zakończyć i były zatwierdzone przed
awarią (roll-forward).
Do przywracania spójności wykorzystuje się tzw punkty kontroli prazy systemu (check points),
które są przechowywane w dzienniku transakcji. Są to informacje o tych stanach działania systemu do
których możemy wrócić mając pewność, że w tym momencie stan bazy był spójny i poprawny.
W przypadku awarii niekrytycznej (soft crash) dzięki punktom kontrolnym poprawności pracy
systemu musimy określić, które transakcje muszą być cofnięte (lista UNDO), a które ponownie
zatwierdzone (lista REDO). Ostatecznie transakcje z listy transakcji do cofnięcia powinny być usunięte
z dziennika a następnie uruchomione ponownie. Rezultaty transakcji z listy REDO są powtórnie
zapisywane do właściwej bazy danych.
Istnieją także awarie krytyczne. W takich przypadkach prawdopodobnie konieczne będzie
odtworzenie całej bazy z ostatniej kopii bezpieczeństwa i ponowne zapisanie efektów transakcji , które
były zatwierdzone do momentu katastrofy.
18. Hurtownie danych, składnice i podstawy realizacji serwerów OLAP
Hurtownia danych (data warehouse, magazyn danych)
Cechy hurtowni
• Zorientowana tematycznie (subject oriented)
• Zintegrowana (integrated)
• Trwała (nonvolatile)
• Przechowująca historię (time variant)
Hurtownie i składnice danych
Hurtownia danych (data warehouse)
• Niezależna od zastosowania
• Scentralizowana
• Zawiera historię
• Dane mało zagregowane
• Dane mało zdenormalizowane
• Wiele źródeł danych:
dane operacyjne i zewnętrzne
Składnice danych
(data marts, tematyczne h.d.)
• Specyficzne dla zastosowania
• Przeznaczone dla określonych użytkowników
• Dane silnie zagregowane
• Dane silnie zdenormalizowane
• Dane w różnych składnicach powtarzają się
• Niewiele źródeł danych
(albo jedno: centralna hurtownia)
Zadania OLAP
• Prezentacja wielowymiarowych widoków
danych
• Interaktywne zapytania i analizy
• Obliczanie agregatów
• Analiza statystyczna, analiza trendów,
prognozowanie, modelowanie
• Wykresy
• Duża szybkość działania
Wymagania wobec analitycznej b.d.
• Efektywne przetwarzanie analityczne
wielkiej ilości danych
• Efektywne przetwarzanie wielowymiarowe
Narzędzia OLAP
• Arkusze kalkulacyjne, np. Excel
• Narzędzia do budowy aplikacji
analitycznych, np. Business Objects, Oracle
Discoverer, Oracle Express
• Gotowe rozwiązania dla typowych
problemów, np. Oracle Sales Analyzer
19. Bazy wiedzy i systemy decyzyjne (systemy ekspertowe - podstawy ich funkcji i realizacji)
jest to program, lub zestaw programów komputerowych wspomagający korzystanie z wiedzy i
ułatwiający podejmowanie decyzji. Systemy ekspertowe mogą wspomagać bądź zastępować ludzkich
ekspertów w danej dziedzinie, mogą dostarczać rad, zaleceń i diagnoz dotyczących problemów tej
dziedziny.
Szkielety systemów ekspertowych
Klasycznym językiem używanym przy tworzeniu systemów eksperckich jest Prolog. Obecnie zamiast
tworzyć je od podstaw, używa się gotowych szkieletów systemów ekspertowych (ang. expert system
shell). Szkielet taki to właściwie gotowy system ekspertowy pozbawiony wiedzy.
Budowa systemu ekspertowego
Większość systemów ekspertowych jest zbudowana według następującego schematu:
Składniki systemu ekspertowego to:
Szkielet systemu składający się z
- Interfejsu użytkownika. Użytkownik korzysta z systemu komunikując się z nim za pomocą interfejsu
użytkownika. Sprowadza się to najczęściej do zadawania pytań, udzielania informacji systemowi, oraz
odbierania od systemu odpowiedzi i wyjaśnień.
- Edytora bazy wiedzy. Dzięki wbudowanemu edytorami możliwa jest modyfikacja wiedzy zawartej w
systemie, co pozwala na rozbudowę systemu.
- Mechanizmu wnioskowania. Jest to najważniejszy składnik systemu ekspertowego, jego zadaniem
jest wyciąganie wniosków z przesłanek i pytań wprowadzanych przez użytkownika i generowanie
odpowiedzi.
- Mechanizmu wyjaśniającego. Mechanizm ten umożliwia wyjaśnienie na życzenie użytkownika
dlaczego system udzielił takiej, a nie innej odpowiedzi, albo dlaczego system zadał użytkownikowi
określone pytanie.
- Baza wiedzy. Jest to drugi pod względem ważności składnik systemu. W bazie wiedzy zawarta jest
wyekstrachowana od ludzkich ekspertów wiedza dotycząca określonej dziedziny. Wiedza ta zwykle
zapisana jest za pomocą wybranego sposobu reprezentacji wiedzy, na przykład za pomocą reguł lub
ram.
- Baza danych zmiennych. Jest to pomocnicza baza danych w której przechowywane są wnioski
uzyskane przez system podczas jego działania. Baza ta umożliwia odtworzenie sposobu
wnioskowania systemu i przedstawienie go użytkownikowi za pomocą mechanizmu wyjaśniającego.
Ekstrakcją wiedzy od ekspertów zajmują się na ogół inżynierowie wiedzy. Jest to zwykle długi i
żmudny proces, ponieważ wiedza stosowana przez ludzkich ekspertów jest zwykle wiedzą praktyczną
i intuicyjną.
20. Zarządzanie dużymi projektami informatycznymi; obszary zarządzania, metody organizacji
zespołu i zarządzanie poprzez jakość (CMM)
Capability Maturity Model for Software (ang.) - stworzony przez Software Engineering Institute (SEI)
model służący ocenie procesu wytwórczego służącego do produkcji oprogramowania. CMM ocenia
praktyki stosowane podczas produkcji. Model ocenia proces w skali pięciostopniowej - od
chaotycznego (nic nie jest sterowane ani kontrolowane), aż do ścisłego, zdyscyplinowanego procesu
uwzględniającego wszystkie potrzebne aspekty.
Poziomy CMM
- Initial - oprogramowanie tworzone chaotycznie, bez żadnych formalnych procedur, ewentualnie z
takimi, które są szczątkowe - nie określają procesu.
- Repeatable - stosowane są podstawowe techniki śledzenia projektu - śledzi się koszt, harmonogram
oraz funkcjonalność. Stosuje się techniki pozwalające na powtarzanie udanych projektów na
podstawie informacji zapisanych przy okazji poprzednich.
- Defined - proces wytwórczy jest opisany, wszystkie wykonywane czynności są udokumentowane w
postaci procedur lub instrukcji.
- Managed - podczas projektów stosuje się szczegółowe metryki dotyczące samego procesu, oraz
jakości produktu.
- Optimizing - stosuje się praktyki mające na celu ciągłe poprawianie procesu wytwórczego
oprogramowania - poprzez monitorowanie procesu pod względem możliwości usprawnień, oraz
poprzez ich wprowadzanie.
21. QBE
Wdrożenie rozwiązań IT jest pojęciem na tyle pojemnym, iż niesie ze sobą szerokie spektrum
zagadnień natury prawnej. Przybliżenie ich pozwoli na zrozumienie niektórych z zagadnień
wyłaniających się podczas realizacji kontraktów.
Każde wdrożenie wymaga uwzględnienia interesów zamawiającego i możliwości (technicznych,
organizacyjnych, ekonomicznych) uczynienia im zadość przez realizującego zamówienie. Zawarcie
umowy musi być poprzedzone wynegocjowaniem podstawowych kwestii odnoszących się do
oczekiwań obu stron. Trudno spodziewać się jednak, że w ten sposób unikniemy wszystkich
ewentualnych trudności. Złożoność technologii, względy kompatybilności, rosnące oczekiwania
klienta, to tylko niektóre z pojawiających się wyzwań. Kompletność przedmiotu umowy wdrożeniowej
nie jest powiązana jedynie z "wprowadzeniem" na rzecz zamawiającego konkretnych rozwiązań
technicznych. Uwzględnić trzeba ponadto kwestię obrotu prawami autorskimi w kontekście wdrożenia
- udzielenie licencji, usługi serwisowe, doradcze czy też przeszkolenie pracowników pod kątem
wdrażanych technologii. Głównym przedmiotem umowy będzie jednak z zasady obrót
oprogramowaniem komputerowym - bądź dostępnym już na rynku, bądź kreowanym dopiero,
stosownie do potrzeb zamawiającego. Sam kontrakt przybierze postać jednego dokumentu,
ewentualnie kilku - w tym załączników technicznych.
Charakter umowy wdrożeniowej
Wszystko to sprawia, że kontrakty wdrożeniowe, jako konglomerat zróżnicowanych potrzeb i aspektów
prawnych, nie znajdują swojego wiernego odpowiednika w "modelach" umów wyszczególnionych w
polskim kodeksie cywilnym. Porozumienie dotyczące planowanego wdrożenia należy więc do kategorii
"umów nienazwanych". Od stron zależy, na jakie aspekty położony zostanie nacisk w zawieranym
kontrakcie, co może odbić się w przyszłości na pozycji (i odpowiedzialności prawnej) zamawiającego i
realizującego wdrożenie. Dla "trzonu" umowy wdrożeniowej najodpowiedniejsze mogą być zasady
właściwe dla umów dotyczących świadczenia usług bądź umów o dzieło. Wśród kontraktów
wdrożeniowych na czoło wybijają się te, które są opierane na zasadach właściwych dla umów o
dzieło. Rozróżnienie to niesie ze sobą istotne konsekwencje praktyczne.
W przypadku umowy o dzieło istotne jest osiągnięcie określonego rezultatu. Rezultat taki to
przykładowo przekazanie rozwiązań programistycznych odpowiednio skonfigurowanych serwerów.
Newralgiczną kwestią jest możliwość odstąpienia od umowy wdrożeniowej. Przykładem takiej sytuacji
będzie bierna postawa zamawiającego w chwili, gdy od podjęcia przez niego określonych czynności
uzależnione będzie poprawne zrealizowanie przedmiotu kontraktu. Współdziałanie takie może
przejawiać się w dostarczeniu specyfikacji sprzętu, dla którego jest realizowane wdrożenie. Kodeks
cywilny zakłada, że przypadek braku aktywności zamawiającego daje podstawę do wyznaczenia
zamawiającemu odpowiedniego terminu do podjęcia działań, a po jego upływie możliwe będzie
odstąpienie od umowy.
Wynagrodzenie realizującego wdrożenie zostanie w takim wypadku obniżone, stosownie do
poczynionych dotychczas nakładów. Zamawiający będzie mógł jednak żądać efektów nieukończonej
pracy. Nic nie stoi jednak na przeszkodzie, aby reguły w tym zakresie wyznaczyć w odmienny sposób.
Przy wdrożeniach należy skupić się na ocenie, jak dalece wadliwość realizowanego rozwiązania IT
może wpływać na prawa stron umowy. Chodzi przede wszystkim o to, czy każdy błąd stwierdzony
przez zamawiającego uprawnia go do odstąpienia od umowy. Zrównoważenie interesów stron
wymagałoby zawarcia klauzul poświęconych następstwom "błędów krytycznych" przedkładanego
zamawiającemu systemu (np. bezzwłoczne odstąpienie od umowy, zastrzeżenie kary umownej,
ewentualnie czas, w którym uchybienie powinno być usunięte). Jeśli traktować umowy wdrożeniowe
jako umowy o świadczenie usług, to pojawia się możliwość wypowiedzenia kontraktu przez każdą ze
stron w dowolnym czasie. Nawet jeśli kontrakt ograniczy maksymalnie swobodę firm w tym względzie,
to i tak każda z nich będzie mogła wypowiedzieć umowę, powołując się na "ważne powody". Na
marginesie zaznaczyć trzeba, że przy transgranicznych kontraktach wdrożeniowych warto zadbać o
sprecyzowanie siedziby sądu, który będzie rozstrzygać ewentualne spory.
Dysponowanie prawami autorskimi w kontekście umów wdrożeniowych
Kolejnym pytaniem jest to, jak uporać się z kwestią praw własności intelektualnej w przypadku umów
wdrożeniowych. Chodzi o prawa, jakie uzyskujemy do oprogramowania przekazywanego przy
realizacji wdrożenia. Generalnie w grę wchodzą dwie sytuacje: przenoszenie majątkowych praw
autorskich do aplikacji bądź udzielenie licencji, czyli jedynie zezwolenia na korzystanie w określony
sposób z chronionego prawem autorskim utworu. Pierwsza z sytuacji jest najbardziej atrakcyjna dla
zamawiającego, choć w praktyce będzie zdarzać się relatywnie rzadko. Przeniesienie majątkowych
praw do programów uniezależnia zamawiającego od dalszej współpracy z realizującym wdrożenie, np.
przy jego uaktualnieniu, zmodyfikowaniu oprogramowania. Zwłaszcza że w przypadku aplikacji prawo
do wprowadzania wszelkich modyfikacji, tłumaczenia kodu usytuowano pośród autorskich uprawnień
majątkowych.
Warunkiem koniecznym skuteczności przeniesienia majątkowych uprawnień jest jednak zawarcie
umowy w formie pisemnej. Przepisy prawa autorskiego przewidują, iż forma pisemna umowy jest
niezbędna pod rygorem nieważności. W praktyce jedynie ustne porozumienie w tej kwestii doprowadzi
do zawarcia umowy licencyjnej niewyłącznej (czyli korzystania z programu, które nie wyłącza
udzielania licencji przez producenta programu na rzecz innych firm). Bardziej rozpowszechnioną
metodą jest udzielanie jedynie licencji w zakresie aplikacji przekazywanych w toku wdrożenia IT. W
zależności od wysokości opłat z tytułu kontraktu wdrożeniowego można zawrzeć w nim klauzulę
licencji wyłącznej bądź niewyłącznej. Biorąc pod uwagę konkurencję na rynku, zwłaszcza pierwsza z
umów licencyjnych jest pożądana. Ciekawą kwestią jest to, czy pozyskujący w ramach zawarcia
umowy wdrożeniowej prawa do korzystania z oprogramowania, może je następnie przenieść na inne
podmioty (np. przy zmianie profilu działalności przedsiębiorstwa). Zasygnalizować trzeba w tym
miejscu problem wyczerpania prawa. Gdy uprawniony z tytułu praw autorskich przenosi własność
nośnika programu na inny podmiot (np. w ramach zobowiązań wynikających z wdrożenia), traci on
kontrolę nad dalszym obrotem nim.
Klauzule dotyczące serwisowania
Wprowadzenie rozwiązania w firmie nie kończy definitywnie tematu poprawnego działania nowych
technologii. Trzeba zdawać sobie sprawę z ewentualnej potrzeby uaktualniania programów, eliminacji
dostrzeżonych błędów. W przypadku zawarcia w umowie wdrożeniowej klauzul przekazujących
jedynie licencje na rzecz zamawiającego wdrożenie, samodzielne wykonywanie takich działań nie
będzie możliwe. Atrakcyjne jest więc porozumienie stron dotyczące serwisowania wdrożonego
projektu. Uwzględnienie takiej klauzuli w głównym kontrakcie pozwoli na zaoszczędzenie kosztów
związanych z późniejszymi negocjacjami. Zabezpiecza to w pewien sposób interesy zamawiającego,
którego pozycja jest inna w chwili zawierania umowy wdrożeniowej, a inna gdy przedsięwzięcie
zostało już zrealizowane i odebrane. Dla osiągnięcia klarownej sytuacji należy szczegółowo uwypuklić
zakres serwisowania, terminy podejmowania działań przez firmę obsługującą implementowany
system, a także czas trwania tego typu usług. Od stron zależy, jak określone zostanie wynagrodzenie
związane z zamieszczeniem klauzuli serwisowej (jednorazowa opłata, zryczałtowane wynagrodzenie
miesięczne, wynagrodzenie jedynie za rzeczywiście świadczone usługi).
Odbiór projektu
Zastanawiającym jest to, czy dążyć do odbioru poszczególnych etapów wdrożenia, czy też poprzestać
na końcowym odbiorze. Z punktu widzenia zamawiającego pierwsze rozwiązanie jest bardziej
korzystne. Ułatwia "wychwycenie" niepokojących kierunków prac wdrożeniowych. Nieterminowość
przy realizacji poszczególnych etapów pracy rodzi możliwość obniżenia wynagrodzenia, a w skrajnych
przypadkach jawi się jako podstawa odstąpienia od umowy. Kwestie te powinny rozstrzygać
szczegółowe postanowienia umowne. Z drugiej strony naraża to także realizującego wdrożenie na
zmianę zdania przez klienta, który dojdzie do wniosku, że chciałby położyć nacisk na inne elementy
(odmienną technologię, większe wymagania sprzętowe). Jednocześnie akceptacja kolejnych
fragmentów projektu wdrożeniowego może być powiązana z kolejnymi ratami, które uzupełnią zaliczkę
przekazaną przy zawarciu umowy.
Ograniczenie się do odbioru finalnej wersji wdrożenia, rzecz jasna, nie usuwa ewentualnych
zastrzeżeń co do jakości wykonanej pracy. Należy pamiętać o tym, że nawet jeśli prace nie zostały
wykonane w sposób 100% satysfakcjonujący klienta, nie eliminuje to całkowicie obowiązku zapłaty
należności pieniężnej. Zamawiający może po prostu odmówić odbioru zrealizowanego projektu. Warto
dodać, że o ile będziemy stosowali przepisy dotyczące umów o dzieło do kontraktów wdrożeniowych,
możliwe jest odstąpienie w każdej chwili przez zamawiającego od umowy, jeśli zapłaci on umówione
wynagrodzenie, pomniejszone o środki, które zaoszczędził realizujący wdrożenie. W nietypowych
sytuacjach skorzystanie z tej możliwości pozwoli uchronić się od dalszych kosztów.
Charakter odbioru projektu to przede wszystkim sporządzenie odpowiedniego protokołu. Może on być
poprzedzony stosownymi testami, przeprowadzonymi przez zamawiającego. Nawet gdy realizacja
zostanie przyjęta bez zastrzeżeń, nie eliminuje to możliwości późniejszego stwierdzenia wad i żądania
ich usunięcia.
QBE (Query By Example)
Zasada działania
• System wyświetla pustą tabelkę-formularz, odpowiadającą strukturze wybranych tabel
• Użytkownik wpisuje wartości „wzorcowe”
– stałe
– warunki z użyciem operatorów, stałych i tzw. łączników
• Złączenia określa się przez
– automatyczne wczytanie więzów foreign key
– użycie łączników dla kolumn-kluczy
– graficzne określenie powiązań
• System wypełnia formularz wierszami pasującymi do wzorca