Combinewykladybazy

Modele danych
Modele danych
• hierarchiczny
• sieciowy
• relacyjny
• obiektowy
• postrelacyjny
• semantyczny
• NoSQL
– Klucz-wartość
– Dokumentowe
– Rodziny kolumn
– Grafowe
– Obiektowe
• NewSQL
Historia rozwoju BD
1960 1970 1980 1990 2000 2010

Hierarchiczny
Sieciowy
Relacyjny
Semantyczny
Obiektowy
Dedukcyjny
Postrelacyjny
NoSQL
NewSQL
Model hierarchiczny
• Model obejmuje dwie struktury danych
– typy rekordów
– związki nadrzędny – podrzędny
• Każdy element zwany rekordem może uczestniczyć w
roli podrzędnej w co najwyżej jednym powiązaniu
rekordów, w roli nadrzędnej w dowolnej liczbie
powiązań
• Rekord podrzędny nie może istnieć bez rekordu
nadrzędnego
• Podmiotem operacji jest jeden rekord
Więzi w modelu hierarchicznym
KodPojazdu Nazwa Typ

1 Accent kombi
KodPojazdu KodCzęści NazwaCzęści

1 1 silnik V6

1 2 szkrzynia biegów
Model sieciowy
• Model obejmuje dwie struktury danych
– typy rekordów
– typy kolekcji
• Każdy rekord może jednocześnie uczestniczyć w wielu
powiązaniach rekordów
• Rekord taki może równocześnie i wielokrotnie
wystąpić w roli nadrzędnej oraz w roli podrzędnej,
powiązania realizowane są przez rekordy specjalne
zwane łącznikami
• Podmiotem operacji jest jeden rekord
Więzi w modelu sieciowym

1 Accent kombi

1 Getz cupe

1 2 szkrzynia biegów
Modele obiektowy
• Brak sprecyzowanej definicji obiektowych baz danych
• Model opiera się na takich pojęciach jak:
– klasa
– obiekt
– uogólnienie
– abstrakcja
– dziedziczenie
• Obiekty dysponują metodami
Model semantyczny
• Łączy reprezentację faktów i zależności pomiędzy faktami
(lokalnie, bez potrzeby znajomości schematu). W modelu
semantycznym dane są bezpośrednio „osadzone w
kontekście”
• Aktualnie najpowszechnieszy w kontekście autonomicznej
komunikacji pomiędzy serwisami (np. Internet of Things)
Model dedukcyjny
• Oparty na logice formalnej (rodzaj systemu
ekspertowego)
• Wykorzystywane elementy to
– Predykaty (funkcje zdaniowe)
– Argumenty (parametry funkcji zdaniowych)
• Predykaty oraz argumenty tworzą asercję (zdanie),
które może przyjmować wartość „prawda” lub „fałsz”
– Jakiś przedmiot jest jakoś prowadzony -> T/F
– Bazy Danych są wspaniale prowadzone -> True!
• Często oparty jest o język Datalog
Model postrelacyjny
• Model relacyjny rozszerzony o elementy
obiektowości
• Brak ścisłe definicji – za bazy realizujące model
postrelacyjny przyjmuje się implementacje,
które „już nie są relacyjne, ale jeszcze nie są
obiektowe”
Baza klucz wartość
• Najprostsza implementacja NoSQL.
• Tablica asocjacyjna (pary klucz-wartość)
• Riak, Redis, ...
• Przykładowy kod Redis:
$redis = Redis::connection();
$redis->set('company', 'Grupa Tense');
$company= $redis->get('company');
echo $company;
• Różnice w stosunku do wbudowanych tablic asocjacyjnych (std::map)
– Transakcje (ale błąd nie przerywa wykonania!)
– Potrafi przerwać transakcję jeśli nastąpiła zmiana przed wykonaniem
– Jeden serwer – wielu użytkowników
– Replikacja
– TCP/IP
• Stosowane podczas optymalizacji i skalowania
– dane które nie zmieniają się przy każdym odświeżeniu strony jak np. tytuł strony www
– skrypty które długo się wykonują
• Klucz-wartość vs. RDBMS
– Zaleta: szybkie
– Wady: cała reszta
Bazy zorientowane dokumentowo
• Dokumenty to samoopisujące się, hierarchiczne struktury drzewiaste
• Mogą składać się z map, kolekcji i wartości
• Przechowywane dokumenty są do siebie podobne, ale nie muszą być
dokładnie takie same
• Dane w postaci dokument-klucz-wartość.
• Przykładem bazy danych kluczem wartość jest np. MongoDB, RavenDB.
• Zbliżone do semantycznego modelu danych
Bazy kolumnowe
• Podstawową jednostką przechowywania danych jest kolumna.
• Kolumna to para nazwa:wartość, gdzie nazwa jest kluczem
dla wartości.
• Dalej dane są przechowywane w postaci wierszy, do których
jest przypisany klucz. To z kolei rozszerza się na rodzinę
kolumn.
• Przykładem magazynu rodziny kolumn jest np. Apache
Cassandra (Instagram, Twitter).
Bazy grafowe
• Baza danych, która wykorzystuje struktury
grafów z węzłami.
• Można myśleć o
– węźle jako instancji obiektu,
– z krawędziami i własnościami do przedstawiania i
przechowywania danych oraz do obsługi zapytań
semantycznych.
• Neo4J (LinkedIn), FlockDB.
NewSQL
• Systemy RDBMS mają w sobie linie kodu napisane jeszcze w
latach 80-tych
• „… Oracle nie jest skalowalny, bo dźwiga bagaż starego
kodu…"
• NewSQL zachowuje język SQL i relacyjny model jak również
spełnia zasady ACID (atomowość, spójność, izolację, trwałość)
• Oferuje wydajność i skalowalność.
• CocroachDB (zespół ex-Google Spaner)
Carl - członek zespołu (bug-sniffer)

Modelowanie danych
Cele modelowania
Cele modelowania funkcji: Model
Model procesów procesów
 opracowanie szczegółowego modeluDefiniowanie
potrzeb informacyjnych
użytkownika. modelu
procesów
Modyfikacja
Model funkcji
 opracowanie takiego systemuktóry byłby niezależny
modelu, od metod
Cele Wymagania
fizyczny systemu
informatyzacji
realizacji SI (od oprogramowania, syst. oper. itp.).
Model logiczny i
użytkownika
Model procesów
Strategia Specyfikacja Weryfikacja
Definiowanie
informatyzacji wymagań funkcji
modeli
danych
organizacji użytkownika procesów i
Model
systemu danych
Model funkcji
systemu
Definiowanie Modyfikacja
modelu
danych
Model
Model danych danych
Nowe wymagania
Nowe wymagania
STRATEGIA SPECYFIKACJA MODELOWANIE

WYMAGAŃ
Cele modelowania danych
• Dane każdej organizacji podlegają nieustannym zmianom.

• W miarę stabilne pozostają jedynie ich:
• rodzaje
• sposób przechowywania i przetwarzania
• Modelowanie danych jest techniką organizowania i dokumentowania
danych.
• Poprzez uogólnienie ich typów, cech i zależności między nimi można tworzyć
modele danych. Modele danych można opracowywać na różnych poziomach
abstrakcji czy szczegółowości. Najczęściej wyróżnia się:
• podstawowe modele danych, (konceptualne bądź logiczne), są ukierunkowane na
potrzeby użytkownika, opisują dziedzinę przedmiotową, niezależnie od
technicznego sposobu jego wdrożenia.
• wdrożeniowe modele danych dotyczą wdrożenia modelu danych
w konkretnej technologii baz danych.
Cele modelowania danych
• Do głównych celów modelowania danych można zaliczyć:

• Otrzymanie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa,
• Dekompozycja i strukturalizacja problemu,
• Sformalizowanie opisu z wykorzystaniem języka graficznego – jednoznaczność i
czytelność,
• Mechanizm efektywnej komunikacji pomiędzy analitykiem i użytkownikiem,
pomiędzy analitykami systemu, a nawet pomiędzy użytkownikami,
• Poprawa jakości i efektywności projektowania bazy danych,
• Opis danych niezależny od struktur logicznych i fizycznych,
• Niezależność od implementacji pozwala na zastosowanie modelu do integracji
istniejących baz danych,
• Podstawa do zrozumienia procesów realizowanych w przedsiębiorstwie i jego
reorganizacji,
• Możliwość prezentacji potrzeb informacyjnych na różnym poziomie.
Modelowanie koncepcyjne, logiczne i fizyczne
• Wg ANSI (1975):
• Modelowanie koncepcyjne;
• Opis semantyczny (kontekst modelu)
• Wysoki poziom abstrakcji
• Język "domenowy"
• Definiuje dopuszczalne "obiekty"
• Modelowanie logiczne
• Powiązanie pozycji zdefiniowanych w modelu koncpecyjnym z konretną realizacją, zgodną z
wybranym modelem danych
• W praktyce model koncepcyjny często jest tożsamy z logicznym
• Modelowanie fizyczne
• Uwzględnia zagadneinia organizacji danych, wydajność rozproszenie itd
• W prostych przypadkach może być tożsamy z modelem logicznym
Metody modelowania danych
• ERD
• Entity Relationship Diagram – Diagram Związków Encji
• Zgodny z modelem relacyjnym
• Najbardziej rozpowszechniony
• Peter Chen - 1976
• DFD
• Data Flow Diagram – Diagram przepływu danych
• Lata 70’
• Opisują przepływ danych w programie komputerowym, mogą być wykorzystane
do problemów biznesowych (wyparty przez BPMN)
• Alternatywa dla diagramów aktywności – DFD eliminuje kontrolę przepływu ->
pomaga skupić się na danych w stanie czystym
• Modelowanie w NoSQL
• Brak jednoznacznie dedykowanych narzędzi i metod -> szczegóły na odrębnym
wykładzie
Diagram Przepływu Danych
• DFD jest narzędziem modelowania pozwalającym zobrazować system
jako sieć procesów funkcyjnych, połączonych ze sobą “potokami” i
“zbiornikami” danych
Diagram przepływu danych (Data Flow Diagram
– DFD)
kartoteka
zlecenie zleceń
telefoniczne
klient rejestracja przekazanie
zlecenia zadań
e-mail zlecenie
e-mail
skrzynka
odebranie
poczty odczytanie
poczty
obsługa
poczty
Składniki DFD
• Proces (funkcja)
• Przepływ
• Magazyn
• Terminator
Proces (funkcja)
Sprawdź Wyślij
wiarygodność towar
klienta do klienta
Dział
Kosztów
Przepływ
stan zadłużenia -
zamówienie stan zadłużenia - niedopuszczalny
dopuszczalny
korpus
Sprawdź
klienta
kran
Montuj
kran
stan
zadłużenia
Przepływ
wniosek
kredytowy Sprawdź
Klient klienta
Oblicz
nazwisko, płace
godziny
karty pracy
Wydział
wyroby,
godziny Oblicz
robociznę
Terminator
Dział
Klient
kosztów
Dział
kosztów
Klient
Dział
kosztów
Magazyn
Kartoteka materiałów D1 Przewodnik
M5 Magazyn wyrobów
zamówienie
D5 Portfel zamówień
Sprawdź zamówienie
zamówienie zamówienie Opracuj
odmowa plan
potwier- produkcji
dzenie
zamówienie
zamówienie Opracuj
Sprawdź
plan
zamówienie
produkcji
odmowa
potwier-
dzenie
Metoda konstruowania DFD
• Podejście klasyczne, zstępujące (De Marco 1979, Gane i Sarson 1979)
Diagram Proces
Kontekstowy elem. n
Proces
1
Proces
3
Diagram Kontekstowy Proces

2
Proces
4
Proces
elem. 1
Diagram Ogólny "0"

Proces
elem. 2
Diagramy szczegółowe
Metoda konstruowania DFD
• Podejście Yourdona (Yourdon 1989)
Diagram
Kontekstowy Proces Proces
elem. n elem. n
Diagram Kontekstowy
Proces
elem. 1
Proces
elem. 1
Lista zdarzeń
1. .......... Proces
elem. 2
Proces
elem. 2
2. .........
...........
n. .........
Odpowiedzi na zdarzenia Diagramy zrównoważone

Ocena DFD
• Zalety
• Prostota
• Możliwość rozróżnienia przepływów informacji i magazynów informacji
• Układ hierarchiczny
• Wady
• Brak możliwości prezentacji funkcji w strukturze organizacji
• Brak możliwości prezentacji dynamiki systemu
• Brak możliwości prezentacji logiki działań i funkcji
Diagramy ERD
• Diagramy związku encji (Entity Relashinship Diagrams) to metoda

graficznego modelowania struktur danych oraz relacji między nimi
• Przedstawiają strukturę danych opisywanego systemu wraz z
wszystkimi niezbędnymi atrybutami dla jego funkcjonowania.
• Modele danych można opracowywać na różnych poziomach
szczegółowości.
• Modelowanie „z dołu do góry” (normalizacja) – konieczność
zidentyfikowania całości zbioru danych przed projektowaniem
• Modelowanie „z góry do dołu” (modelowanie danych) – zbiór danych
powstaje w trakcie projektowania
• Modelowanie semantyczne
Komponenty diagramu związków encji
Komponent Opis
Rzecz mająca znaczenie, rzeczywista lub

Encja wymyślona, o której informacje należy znać lub
przechowywać.
Element informacji służący do klasyfikowania,

Atrybut identyfikowania, kwalifikowania, określania
ilości lub wyrażania stanu encji.
Znaczący sposób, w jaki mogą być ze sobą

Związek powiązane dwie rzeczy tego samego typu lub
różnych typów.
Przykład prostego diagramu związków encji
KLIENT
* Nazwa FAKTURA
* Adres
o e_mail
Atrybuty Związek Encja

Encja
• Encja (ang. entity) – jest to jednoznacznie identyfikowany składnik

badanej rzeczywistości, o którym informacja jest lub może być
zbierana i przechowywana.
• Przykładami encji są:
• PRACOWNIK,
• KLIENT,
• DOSTAWCA,
• ZAMÓWIENIE,
• MAGAZYN,
• KONTO itp.
• Uwaga: encje zazwyczaj opisuje się za pomocą rzeczowników lub
wyrażeń rzeczownikowych w liczbie pojedynczej
Atrybut
• Atrybut - jest cechą, elementem charakteryzującym encje i związki

w badanej dziedzinie przedmiotowej.
• Zestaw atrybutów, który jednoznacznie opisuje encję, nazywa się
wiązką atrybutów.
• Wiązka powinna składać się, z co najmniej dwóch atrybutów
opisujących daną encję. Szczególną rolę w zakresie atrybutów encji
pełni klucz, zwany identyfikatorem. Pozwala on na jednoznaczne
określenie wystąpienia encji.
• Jeśli używa się jednego atrybutu dla określenia encji, to mamy do
czynienia z kluczem pojedynczym, a jeśli w tym celu używa się więcej
niż jednego atrybutu, to z kluczem złożonym.
Rodzaje atrybutów
Przykład Przeznaczenie
numer zamówienia identyfikacja
opis towaru opis werbalny
typ towaru klasyfikacja
ilość towaru w magazynie określenie ilości
status płatności za zamówienie wyrażenie stanu

Wymagania dla atrybutu
• nazwa atrybutu musi być unikalna w ramach encji;

• atrybut musi być obowiązkowy (tzn., że wartość atrybutu musi być
zawsze określona) lub opcjonalny (tzn., że atrybut nie musi mieć
wartości). Symbolu „*” używa się dla atrybutu obowiązkowego, zaś
symbolu „○” dla opcjonalnego;
• atrybut musi mieć format lub typ;
Przykładowe atrybuty
Encja – STUDENT Wystąpienia encji:
STUDENT Mat/123/04
Jan
# nr albumu Kowalski
* imię 14-05-1990
* nazwisko Dobre Miasto
* data urodzenia
* miejsce urodzenia
Mat/345/04
Anna
Nowak
21-05--1986
Dobre Miasto
Encja – SAMOCHÓD Wystąpienia encji:
OLX 2361
Nissan Almera
SAMOCH ÓD
2000
# nr rejestracyjny 55000
* typ Czerwony
* rok produkcji 1,6 m3
* cena
* kolor OM- 2388
* pojemność silnika Renault
2004
62000
Złoty
1,4 m3
Związek
• Związek stanowi naturalne powiązanie pomiędzy dwoma lub więcej

encjami w badanej dziedzinie przedmiotowej.
• W identyfikowaniu i modelowaniu związków encji bierze się pod
uwagę następujące cechy:
• stopień związku (liczebność związku)
• opcjonalność (uczestnictwo encji).
• Stopień związku
• oznacza stosunek ilościowy między liczebnością wystąpień poszczególnych
encji, uczestniczących w danym związku,
• mówi o tym, ile wystąpień encji jednego rodzaju jest powiązanych z iloma
wystąpieniami encji innego rodzaju
Przykłady związków encji
Stopień
Przykład Znaczenie
związku
Każde wystąpienie encji Dziekan jest powiązane tylko

Dziekan-
1:1 z jednym wystąpieniem encji Wydział. Zatem jeden
Wydział
Dziekan kieruje jednym Wydziałem
Każde wystąpienie encji Wydział powiązane jest

jednym lub wieloma wystąpieniami encji Student, przy
1:m Wydział- czym każde wystąpienie encji Student powiązane jest
1: wiele Student tylko jednym wystąpieniem encji Wydział.
Zatem Wydział posiada wielu Studentów, natomiast
Student studiuje wyłącznie na jednym Wydziale
Każde wystąpienie encji Książka powiązane jest

z wieloma wystąpieniami encji Autor i odwrotnie
m:n każde wystąpienie encji Autor powiązane jest
Książka -
Wiele : z wieloma wystąpieniami encji Książka.
Autor
wiele Jest to sytuacja, gdzie Książka może być napisana
przez jednego lub wielu autorów i jeden Autor jest
podpisany pod jednym lub wieloma tytułami Książek.
Formy zapisu związku
Opcjonalność
• dotyczy zaangażowania encji w związek,

• z uwagi na tę cechę wyróżnia się dwa typy związków:
• wymagane (obowiązkowe) – zachodzi wówczas, jeśli wszystkie wystąpienia
encji muszą uczestniczyć w związku;
• opcjonalne - zachodzi wówczas, jeśli istnieje, co najmniej jedno
wystąpienie encji, które nie uczestniczy w związku.
Cechy związków encji (notacja Martina)
Stopień związku Typ zw iązku

(opcjonalność)
jeden - do - jednego związek

opcjonalny
jeden - do - w ielu
zw iązek
wymagany
(obowiązkowy)
w iele - do - w ielu
Diagramy Związków Encji
• Liczebność (stopień)
• 1:1 Wykładowca
• 1:M
or
• M:N
• Liczebność min/max r1 r2
• Uczestnictwo (opcjonalność) Moduł

• Zawieranie i wykluczanie
Wykładowca
and
r1 r2
Moduł
• Związki rekurencyjne
(jednoargumentowe)
• Związki trójargumentowe –
rozbicie na dwie osobne relacje Pracownik Zarządza
powoduje utratę informacji
• Role
• Atrybuty związków (możliwa
konwersja do nowego zbioru Pracownik
encji)
Wykorzystuje_umiejętność
Agregat Umiejętność
Podklasy w modelu ER
• Wyjątkowe zbiory encji zawierające dodatkowe/specjalizowane

atrybuty/związki
• Zbiory encji łączone są z podklasami związkami „isa”
• Kreskówka is a Film
• Kryminał is a Film
ERD – Modelowanie upływu czasu
Reguły czytania związków encji
musi być jeden lub wiele

Każda Encja 1 lub nazwa związku lub Encja 2
może być jeden I tylko jeden
Przykład:
składa
Klient Zamówienia
jest zlecone
Każdy Klient może złożyć jedno lub wiele Zamówień.

Każde Zamówienie musi być zlecone przez jedngo i tylko jednego Klienta.
Notacja
 tworzenie diagramu związków encji najlepiej rozpocząć od

wskazania encji oraz określić związki między encjami występującymi
w danej dziedzinie przedmiotowej.
 istnieje kilka najbardziej rozpowszechnionych notacji graficznych
diagramu ERD, należą do nich notacje:
 Chena,
 Bachmana,
 Martina,
 Shlaer-Mellora.
 ponieważ w zasadzie notacje te są równoważne i różnią się jedynie
wyglądem symboli graficznych, do opisu wybrano najbardziej
rozpowszechnioną notację Martina.
Typy encji ERD (notacja Martina)
Encja regularna (silna) Istnienie nie jest zależne od

innych zbiorów encji
Encja słaba Może istnieć jedynie w
powiązaniu z encją silną
Obiekt asocjacyjny Przechowuje informacje o związku
dwóch innych encji
Relacja is-a (“X is a Y”) występuje pomiędzy zbiorami
encji, spośród których jeden może
być określony jako specjalizacja
drugiego (wilk jest zwierzęciem)
Diagram ERD z wyróżnionymi typami encji
związane jest dotyczy określa

Pracownik Wypożyczenie Sprzęt Typ
wypożycza rejestruje należy
Silna encja Słaba encja
Klient Określa Preferencje
klientNr (PK) typPreferencji

imięNazwisko maksCzynsz
imię
nazwisko
telNr
Kli nika
organizuje na zwa klin iki

ad res
jest organizowana przez
Sal a Op eracyjna
Ses ja Klin iczna
nu mer sa li
id se sji Le ka rz
na zwa sa li
rod zaj ses ji id le ka rza
na zwi sko
im ie jest miejscem dla
obejmuje
sp ecjal izacja
odby wa sie w
przeprowadzana jest w ramach
dokonuje
Ses ja Opera cyjn a
Kon su ltacja wykonuje
nr ses ji
id kons ultacj i rod zaj ses ji
da ta ko nsu lta cji przeprowadzana jest przez
tre sc
doty czy jest wy kony wana przez zawiera
korzy st a
Pacje nt
nr pacje nta Ope racja
na zwi sko poddawany jest doty czy nr ope racji jest przy dzielona do
im ie da ta ope racji
ad res
Wykład Moduł
1 M
Wykład Moduł
Wykład Moduł
1:1 0:M
Wykład Moduł
Wykład Moduł
Projektowanie logicze danych
• Konceptualny model danych, którego odzwierciedleniem są diagramy

ERD, przekształcany jest w jeden z modeli baz danych:
• relacyjny,
• sieciowy,
• hierarchiczny.
Terminologia relacyjna
Pojęcie Opis
Relacja Jest to podzbiór iloczynu kartezjańskiego reprezentowany przez zbiór
krotek. Reprezentacją relacji jest tablica.
Krotka Oznacza wiersz tablicy. Reprezentacją krotki w tablicy jest rekord.
Atrybut Oznacza kolumnę tablicy (a dokładnie są to różne wystąpienia tego

samego atrybutu). Reprezentacją atrybutu w tablicy jest pole.
Stopień relacji Liczba typów atrybutów w relacji.
Liczebność relacji Liczba krotek w relacji.
Klucz główny Kolumna lub kombinacja kolumn, których wartości jednoznacznie

identyfikują wiersze w tablicy.
Klucz obcy Kolumna lub kombinacja kolumn, których wartości określają klucz
główny innej tablicy.
Dziedzina (atrybutu) Lista dostępnych wartości atrybutu, wszystkie tego samego typu.
Stworzenie relacyjnego modelu danych
 każda encja staje się tablicą, której nazwa jest zazwyczaj nazwą encji
w liczbie mnogiej;
 każdy atrybut staje się komuną, a jego nazwa odpowiednio nazwą tej
kolumny. Natomiast właściwości atrybutu stają się odpowiadającymi
im właściwościami w projekcie danych. Atrybuty obowiązkowe stają
się kolumnami NOT NULL (co oznacza, że nie jest możliwe by wartość
kolumny przyjmowała wartość NULL);
 unikalny identyfikator encji staje się kluczem głównym tabeli;
 każdy związek jest przekształcany w dwa obiekty. Kolumnę klucz
obcego, zgodną z kluczem głównym (lub unikalnym) tabeli, której
dotyczy. Dziedziczy ona typ i rozmiar danego klucz głównego.
Przekształcanie encji
Logiczny m odel danych Relacyjny m odel danych

Encja Tabela
Klient Klienci
Kolumny
Atrybuty
nazwa nazwa
unikalny identyfikator klucz głowny
Klienci
Klient
# id_klient # id_klient
* nazwa * nazwa
* adres * adres
Przekształcanie związków
Zamówienie
Klient
# id_zamówienia
# id_klient
* data zamówienia
* nazwa
…
* adres
Klienci Zamówienia
Not NULL
# id_zamowiania
# id_klient
* data-zamówienia
* nazwa
* id_klienta
* adres
...
Przekształcenie diagramu ERD
Przekształcenie diagramu ERD
Relacyjny model danych
• Podstawą tego modelu stała się praca opublikowana przez E.F. Codda w
1970r.
• W pracy „Relacyjny model logiczny dla dużych banków danych” Codd
zaprezentował założenia relacyjnego modelu baz danych
• W roku 1990 Codd opublikował artykuł „Relacyjny model zarządzania
bazami danych: wersja 2”, rozszerzający poprzednie prace
• RMD oparty jest o algebrę relacji
• Podstawowe elementy modelu to
• relacje
• więzi
Podstawowe pojęcia w bazach danych:
• encja – relacja – klasa – tabela

• zbiór podobnych obiektów opisanych w jednolity sposób
• krotka – obiekt (instancja klasy) – rekord – wiersz
• zestaw wartości atrybutów opisujących jeden obiekt identyfikowany przez wyróżnione
atrybuty lub nazwę
• związek – więź – asocjacja
• związek pomiędzy dwoma encjami (klasami) pokazujący jakie rekordy (obiekty) z jednej
encji odpowiadają rekordom z drugiej i jaki jest charakter tej odpowiedniości
• atrybut – kolumna – pole
• pojedyncza dana wchodząca w skład krotki np. nazwisko studenta, nr ewidencyjny
pracownika, wielkość zapasu czy rodzaj filmu.
KISIM, WIMiIP, AGH

• Podstawową strukturą danych jest relacja będąca podzbiorem iloczynu

kartezjańskiego co najmniej dwóch wybranych zbiorów reprezentujących
dopuszczalne wartości.
• Niech A1 = [a,b,c], A2 =[x,y]
Wtedy A1  A2 = {(a,x), (a,y), (b,x), (b,y), (c,x), (c,y)}
Przykładowe relacje, będące podzbiorami iloczynu kartezjańskiego A1A2 :
X = {(a,x), (b,x), (c,x)}
Y = {(a,x), (a,y), (b,y)}
elementy relacji są nazywane krotkami
• Relacja jest zbiorem krotek posiadających taką samą strukturę, lecz
różne wartości.
• Każda krotka posiada co najmniej jeden atrybut.
KISIM, WIMiIP, AGH

• Każda relacja posiada następujące własności

• krotki są unikalne
• atrybuty są unikalne
• kolejność krotek nie ma znaczenia
• kolejność atrybutów nie ma znaczenia
• wartości atrybutów są atomowe
• Tworzenie modeli relacyjnych nazywane jest modelowaniem związków

encji.
KISIM, WIMiIP, AGH

Postulaty Codda
1. Postulat informacyjny – dane są reprezentowane jedynie poprzez

wartości atrybutów w wierszach tabel,
2. Postulat dostępu – każda wartość w bazie danych jest dostępna
poprzez podanie nazwy tabeli, atrybutu oraz wartości klucza
podstawowego,
3. Postulat dotyczący wartości NULL – dostępna jest specjalna wartość
NULL dla reprezentacji wartości nieokreślonej jak i nieadekwatnej,
inna od wszystkich i podlegająca przetwarzaniu
Postulaty Codda
4. Postulat dotyczący katalogu – wymaga się, aby system obsługiwał

wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych
użytkowników używających języka zapytań,
5. Postulat języka danych – system musi dostarczać pełnego języka
przetwarzania danych, który:
• może być używany w trybie interaktywnym jak i w obrębie programów aplikacyjnych,
• obsługuje operacje definiowania danych,
• obsługuje operacje manipulowania danymi,
• obsługuje ograniczenia związane z bezpieczeństwem i integralnością
• obsługuje operacje zarządzania transakcjami,
Postulaty Codda
6. Postulat modyfikowalności perspektyw – system musi umożliwiać

modyfikowanie perspektyw, o ile jest ono (modyfikowanie)
semantycznie realizowalne,
7. Postulat modyfikowalności danych – system musi umożliwiać operacje
modyfikacji danych, musi obsługiwać operatory INSERT, UPDATE oraz
DELETE,
8. Postulat fizycznej niezależności danych – zmiany fizycznej
reprezentacji danych i organizacji dostępu nie wpływają na aplikacje,
Postulaty Codda
9. Postulat logicznej niezależności danych – zmiany wartości w tabelach

nie wpływają na aplikacje,
10. Postulat niezależności więzów spójności – więzy spójności są
definiowane w bazie i nie zależą od aplikacji,
11. Postulat niezależności dystrybucyjnej – działanie aplikacji nie zależy od
modyfikacji i dystrybucji bazy,
12. Postulat bezpieczeństwa względem operacji niskiego poziomu –
operacje niskiego poziomu nie mogą naruszać modelu relacyjnego i
więzów spójności.
13. Reguła nieprowadzenia "działalności wywrotowej": jeśli system jest
wyposażony w interfejs niskiego poziomu (operacje na pojedynczych
rekordach), nie może być użyty do prowadzenia działalności
wywrotowej (np. omijania zabezpieczeń relacyjnych lub ograniczeń
integralnościowych)
Baza danych - relacja
• Rozważmy relację, której atrybutami są nazwisko, imię, wiek. Relację tę

można zapisać następująco:
• PRAC <nazwisko, imię, wiek>, gdzie PRAC jest nazwą danej relacji.
• A oto trzy krotki relacji PRAC:
• <Kowalski, Jan, 36>
• <Tomaszewski, Wojciech, 40>
• <Wiśniewski, Marek, 50>.
Zasady spełnione dla każdej relacji
• 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,
• Każde pole leżące na przecięciu kolumny/wiersza w relacji powinno
zawierać wartość atomową
Zbiór identyfikujący relacji
zbiór atrybutów
R  A1 , A2 ,...., An 
SR
który jednoznacznie identyfikuje wszystkie krotki w relacji R.
W żadnej relacji o schemacie R nie mogą istnieć dwie krotki t1 i t2 takie, że
t1[S]=t2[S]
Klucz
• Minimalny zbiór identyfikujący

• Taki zbiór atrybutów relacji, których kombinacje wartości jednoznacznie
identyfikują każdą krotkę tej relacji a żaden podzbiór tego zbioru nie
posiada tej własności
• W kluczu nie może zawierać się wartość Null
• Klucz jest kluczem prostym, jeżeli powyżej opisany zbiór jest
jednoelementowy - w przeciwnym razie mówimy o kluczu złożonym
• W ogólności, w relacji można wyróżnić wiele kluczy, które nazywamy
kluczami potencjalnymi. Wybrany klucz spośród kluczy potencjalnych
nazywamy kluczem głównym (Primary Key PK)
Zależność funkcjonalna
• Atrybut B relacji R jest funkcjonalnie zależny od atrybutu A jeżeli

dowolnej wartości a atrybutu A odpowiada nie więcej niż jedna wartość
b atrybutu B
A B
• Niech X i Y będą podzbiorami zbioru atrybutów relacji R
X{A1...AN}, Y{A1...AN}
• podzbiór atrybutów Y zależy funkcyjnie od podzbioru atrybutów X, jeżeli

nie jest możliwe, by relacja R zawierała dwie krotki mające składowe
zgodne tzn. identyczne dla wszystkich atrybutów ze zbioru X i
jednocześnie co najmniej jedną niezgodną składową dla atrybutów ze
zbioru Y
Zbiór atrybutów Y jest w pełni funkcjonalnie zależny od zbioru atrybutów X

w schemacie R, jeżeli:
X Y
i nie istnieje
X  X
'
takie, że
X Y
'
Zbiór atrybutów Y jest w częściowo funkcjonalnie zależny od zbioru

atrybutów X w schemacie R, jeżeli:
X Y
i istnieje
X  X
'
takie, że
X Y
'
• Niech X, Y i Z będą trzema rozłącznymi podzbiorami atrybutów danej

relacji
• Z jest przechodnio funkcjonalnie zależny od X, jeśli Z jest funkcjonalnie
zależny od Y i Y jest funkcjonalnie zależny od X natomiast X nie jest
zależny od Y i Y nie jest zależny od Z
Zależność wielowartościowa
Podzbiór atrybutów Y jest wielowartościowo funkcjonalnie zależny od

podzbioru X w schemacie R, jeżeli dla dowolnej relacji r w schemacie R i
dla dowolnej pary krotek t1 i t2 z relacji r istnieje taka para krotek że:
s1[X]=s2[X]=t1[X]=t2[X] i
s1[Y]= t1[Y] i s1[R-X-Y]=t2[R-X-Y] i
s2 [Y]= t2[Y] i s2 [R-X-Y]=t1[R-X-Y]
X Y R-X-Y
krotka Nazwisko Imię dziecka Znajomość języków
t1 Kot Ania niemiecki
t2 Kot Jaś angielski
s1 Kot Ania angielski
s2 Kot Jaś niemiecki
Słoń Ola niemiecki

t1[X]=t2[X]=s1[X]=s2[X]=(Kot)
s1[Y]= t1[Y]=(Ania) i
s1[R-X-Y]=t2[R-X-Y]=(angielski) i
s2 [Y]= t2[Y]=(Jaś) i
s2 [R-X-Y]=t1[R-X-Y]=(niemiecki)
Trywialna zależność wielowartościowa
• Zależność wielowartościowa X →→ Y w relacji r(R )

nazywamy zależnością trywialną,
jeżeli zbiór Y jest podzbiorem X ,
lub X ∪ Y = R .
• Zależność nazywamy trywialną, gdyż jest ona spełniona dla dowolnej
instancji r schematu R .
KISIM, WIMiIP, AGH

Więzi
• Więź (ang. relationship) to powiązanie pomiędzy parą tabel (relacji).

Istnieje ona wtedy, gdy dwie tabele są połączone przez klucz
podstawowy i klucz obcy. Każda więź jest opisywana przez typ więzi
istniejący między dwoma tabelami, typ uczestnictwa oraz stopień
uczestnictwa tych tabel.
Typy więzi
• jeden-do-jednego (jeżeli pojedynczemu rekordowi z pierwszej tabeli

przyporządkowany jest najwyżej jeden rekord z drugiej tabeli i na
odwrót)
Więź jeden-do-jednego
Typy więzi
• jeden-do-wielu (jeżeli pojedynczemu rekordowi z pierwszej tabeli może

odpowiadać jeden lub więcej rekordów z drugiej, ale pojedynczemu
rekordowi z drugiej tabeli odpowiada najwyżej jeden rekord z tabeli
pierwszej)
Więź jeden-do-wielu
Więzi identyfikujące
• Klucz obcy, który jest składnikiem złożonego klucza głównego w relacji

zależnej określany jest mianem klucza obcego głównego (Primary
Foreign Key) a tak zbudowana więź więziom identyfikującą
Więź jeden-do-wielu (identyfikująca)
Obcy klucz główny (IdPracownika)
Rok Miesiac IdPracownika LiczbaGodzin

2005 01 1 160
2005 01 2 150
2005 02 1 140
2005 02 2 160
Taki wiersz nie może się pojawić
2005 01 1 140
Więź wiele-do-wielu (dane)
IdAgregatu Agregat Data IdPracownika Nazwisko Godziny
1 Piła 10.03.05 1 Kowalski 4

1 Piła 10.03.05 2 Lis 4
2 Tokarka 10.03.05 1 Kowalski 4
2 Tokarka 10.03.05 3 Kot 8
1 Piła 11.03.05 1 Kowalski 8
2 Tokarka 11.03.05 3 Kot 2
2 Tokarka 11.03.05 2 Lis 6

Więź wiele-do-wielu
• Na jednym agregacie mogą pracować różni pracownicy, np. na agregacie

Piła 10. marca pracowało dwóch pracowników
• Jeden pracownik może pracować na wielu agregatach, np. Kowalski
pracował 10. marca na Pile i Tokarce)
Więź wiele-do-wielu
Więź wiele-do-wielu (po rekonstrukcji)
IdAgregatu Data IdPracownika Godziny
1 10.03.05 1 4
1 10.03.05 2 4
2 10.03.05 1 4
2 10.03.05 3 8
1 11.03.05 1 8
2 11.03.05 3 2
2 11.03.05 2 6
Bazy Danych
Projektowanie. Normalizacja.
Piotr Macioł
WIMiIP, KISiM,
pmaciol@agh.edu.pl
B5, pok. 606
Etapy projektowania baz danych:
1. Specyfikacja wymagań użytkownika - określenie zjawisk,

dostępności i użyteczności danych, ich formatu i sposobów
obliczeń, cele, zakres i kontekst systemu
2. Projektowanie konceptualne - projektowanie schematu E–R
bazy. Użycie modelu E–R wpływa również na realizację
pozostałych faz.
3. Specyfikacja wymagań funkcjonalnych - dokładny opis
wymagań klienta i wszystkich przyszłych użytkowników
systemu
4. Projektowanie logiczne i fizyczne
5. Implementacja
KISIM, WIMiIP, AGH 2
Projektowanie bazy danych:
— Projektowanie logicznej struktury bazy:

» Etap I: określenie encji i zdefiniowanie atrybutów opisujących encje
– przyporządkowanie encji do zjawisk
– standaryzacja nazw i formatów
– identyfikacja źródeł danych
» Etap II: określenie związków między encjami

– identyfikacja typu związków (relacji) (1-1, 1-M, N-M)
» Etap III: normalizacja relacji

– obniżenie redundancji i wyeliminowanie anomalii (usuwania, wstawiania i
aktualizacji)
— Projektowanie fizycznej struktury bazy:

» nałożenie struktury logicznej na fizyczne urządzenia

Wybór schematu relacji:
— Projekt bazy danych polega na znalezieniu właściwych schematów relacji
tworzących bazę danych
— Niewłaściwy projekt (niewłaściwe schematy) mogą prowadzić do
» Redundancji (powtarzania informacji).
» Niemożliwości reprezentowania pewnych informacji.
» Anomalii związanych z operowaniem danymi

(głównie modyfikacją danych)
— Cele:
» Unikanie redundancji danych
» Zapewnienie reprezentowania związków między danymi
» Zachowanie warunków integralności (umożliwienie kontroli

warunków integralności podczas modyfikacji danych).
Modelowanie konceptualne:
Model pojęciowy (konceptualny, podstawowy):

— Zapis wymagań w postaci sformalizowanej, abstrahujący od problemów
implementacyjnych („co” a nie „jak”)
— Zawiera
» modele graficzne
» tekstowe (ale też sformalizowane) uzupełnienia modeli graficznych
— Jest ważny, ponieważ:
» reprezentuje istotę wymagań
» nie zależy od zmiennych możliwości implementacji
» jest dobrą podstawą do projektowania systemów mających
funkcjonować przez wiele lat

Wymagania:
— Spełnienie wymagań użytkownika jest naszym celem działania

— Wymagania muszą więc być dokładnie znane
— Poprawne i kompletne sformułowanie wymagań na ogół nie
jest proste
— Należy odróżniać funkcje systemu od mechanizmów, czyli
sposobów implementacji funkcji
— Modelować dane niezależnie od przyszłej implementacji -
modelowanie E/R
— Tworząc model pojęciowy nie można formułować zastrzeżeń
co do realizowalności wymagań
— Zaprojektować dobry schemat - normalizacja
Bazy Danych
Normalizacja.
Piotr Macioł
WIMiIP, KISiM,
pmaciol@agh.edu.pl
B5, pok. 606
Metoda graficzna (diagramy ERD)
— Główną zaletą metody diagramów zależności jest to, że określa mechanizm

przyrostowego projektowania bazy danych.
— Nie jest konieczny pełny zbiór elementów danych, aby móc rozpocząć
proces projektowania.
— Analityk danych może rozpocząć pracę z małym zbiorem elementów
danych mających centralne znaczenie.
— Następnie stopniowo może dodawać nowe elementy danych do
tworzonego diagramu dopóty, dopóki wszystkie zależności nie będą w
pełni udokumentowane.
— Diagram, który dokumentuje zależności (determinowanie) między
elementami danych, nazywa się diagramem zależności lub diagramem
determinowania.
— Zależność funkcyjną między dwoma elementami danych oznaczamy za
pomocą strzałki łączącej determinujący element danych z zależnym
elementem danych.
2
Rozkład odwracalny
— Klasyczna normalizacja jest opisana jako proces rozkładu odwracalnego.

Metoda rozkładu rozpoczyna się od jednej (uniwersalnej) relacji
— Rozkład odwracalny jest więc procesem projektowania, który gwarantuje,
że utworzony zbiór danych będzie wolny od anomalii
— Metoda rozkładu ma jednak kilka wad, sprawia trudności zwłaszcza
wówczas, gdy chcemy ją konsekwentnie stosować w praktyce jako metodę
projektowania bazy danych:
» Wymaga, aby cały zbiór danych był w pełni określony, zanim
rozpocznie się proces.
» Dla dużego zbioru danych proces ten jest:
– a) bardzo czasochłonny,
– b) trudny do zastosowania,
– c) podatny na błędy popełnione przez człowieka.
3
Przykład wad bazy danych:
— Rozważmy schemat relacji:

» pracownik_oddzialu = <nazwa_oddzialu, numer_oddzialu, adres_oddzialu, pesel, imie,
nazwisko, stanowisko, wynagrodzenie>
— Redundancja:
» Dane nazwa_oddzialu, numer_oddzialu, adres_oddzialu są pamiętane dla każdego
pracownika
» Marnowanie miejsca
(przestrzeni potrzebnej dla przechowywania danych)
» Komplikacje (aktualizacja, błąd, usuwanie…)
— Brak możliwości reprezentowania pewnych informacji
» Nie można reprezentować informacji o oddziałach, których powołanie dopiero jest
planowane i nie zatrudniły jeszcze pracowników
» Rozwiązaniem mogło by być zastosowanie wartości NULL, ale takie rozwiązanie także
stwarza pewne problemy
» Nie możemy zaprezentować w prosty sposób wszystkich pracowników z danego
miasta, ponieważ miejscowość nie jest wyodrębnionym atrybutem

Rodzaje anomalii:
— Anomalia dołączania - wadą jest to, że musimy wpisywać wszystko albo

nic,
» np. planuje się powołanie nowego oddziału, nie możemy jednak
zapisać w bazie miejscowości, adresu i nazwy zakupionego budynku,
dopóki nowy oddział nie zatrudni pracowników
— Anomalia aktualizacji - np. oddział firmy został przeniesiony, przez co
musimy aktualizować jego adres dla każdego pracownika, a przez
przypadek omijamy Jana Kowalskiego
— Anomalia usuwania – zamknięto oddział firmy, w związku z czym usunięto z
bazy wszystkie rekordy zawierające jego nazwę, tym samym usunięto
wszystkie dane dotyczące pracowników

Dekompozycja:
— Można zdekomponować schemat relacji – pracownik_oddzialu:

» oddzial = <nazwa_oddzialu, numer_oddzialu, miejscowosc_oddzialu,
adres_oddzialu>
» pracownik = <numer_oddzialu, pesel, imie, nazwisko, stanowisko,
wynagrodzenie>
— Wszystkie atrybuty oryginalnego schematu (R) muszą się pojawić w dekompozycji

(R1, R2):
— R = R1  R2
— W przypadku gdy relacja nie posiada właściwej postaci należy dokonać

dekompozycji relacji R na <R1, R2, ..., Rn>
— Proces „dochodzenia” do „właściwej” postaci określa się mianem normalizacji

„Student lubi piwo…”
L.p. Imię Nazwisko Marka piwa Nazwa piwa Gatunek Alkohol [%]
1. Stefan Żeromski Okocim Palone lager 7
porter
2. Stefan Żeromski Żywiec Porter bałtycki 9,5
3. Stefan Żeromski Cornelius ALE ALE ale 5,8
4. Eliza Orzeszkowa Ciechan Miodowe pilzner 5,7
5. Eliza Orzeszkowa Redd's Cranberry pilzner 4,5
porter
6. Adam Mickiewicz Okocim Porter bałtycki 8,3
7. Friedrich Nietzsche Paulaner Hefe-Weissbier Naturtrüb pszeniczne 5,5
8. Friedrich Nietzsche Ciechan Pszeniczne pszeniczne 5,6
9. Tadeusz Konwicki Żywiec Żywiec Beer pilzner 5,6
10. Rafał Wojaczek Żywiec Żywiec Beer pilzner 5,6
11. Wisława Szymborska Żywiec Żywiec Beer pilzner 5,6
12. Johann Goethe Żywiec Żywiec Beer pilzner 5,6
13. James Joyce Carlsberg Carlsberg lager 5
14. Francis Fitzgerald Haineken Haineken Lager Beer lager 5
Skłodowska-
15. Maria Curie Żywiec Desperados pilzner 6
16. Zofia Nałkowska Łomża Miodowe pilzner 5,7
17. Fiodor Dostojewski Tyskie Gronie pilzner 5,6
18. Fryderyk Chopin Tyskie Gronie pilzner 6,6
KISIM, WIMiIP, AGH 19. Stefan Batory Tyskie Gronie pilzner 7,6 7
STUDENT PIWO
porter
porter
Skłodowska-
STUDENT PIWO GATUNEK PIWO

porter
porter
Skłodowska-
STUDENT PIWO GATUNEK
L.p. Imię Nazwisko Marka piwa Nazwa piwa Alkohol [%] Gatunek
ID_studenta nazwisko nazwa_piwa alk.% gatunek
imie marka_piwa



starsza wersja…

Postacie normalne:
— Pierwsza (1PN)
— Druga (2PN)
— Trzecia (3PN)
— Boyce’a-Codd’a (PNBC)
— Czwarta (4PN)
— Piąta (5PN)

Pierwsza postać normalna
— Relacja jest w pierwszej postaci normalnej, jeśli każda wartość atrybutu w

każdej krotce tej relacji jest wartością elementarną, czyli nierozkładalną.
— Relacja jest w pierwszej postaci normalnej, jeśli nie ma powtarzających się
grup.
» Powtarzająca się grupa danych to podzbiór relacji zawierający co
najmniej dwa atrybuty, posiadająca własny klucz prosty, w którym
istnieją powtarzające się krotki
» Powtarzanie się takich samych krotek wymuszone jest faktem, że
mamy do czynienia z grupą dla której część atrybutów jest strukturą a
nie wartością skalarną

Relacja nie znormalizowana
Pracownik Języki
Jan Kowalski angielski – słabo,

niemiecki - dobrze
Adam Kot rosyjski – bardzo
dobrze
16
Pracownik Znajomość języków
Język Poziom
Jan Kowalski angielski słabo
niemiecki dobrze
Adam Kot rosyjski bardzo

dobrze
17
— Relację "przed normalizacją" zdefiniowano na dwóch dziedzinach:

Pracownik i Znajomość Języków
— Elementami dziedziny Znajomość Języków są również relacje (zdefiniowane
na dziedzinach Język i Poziom)
— Relacja jest z punktu widzenia definicji relacją dwuczłonową, ale nie
wszystkie jej dziedziny są proste (dziedzina prosta to taka, której wszystkie
elementy są atomowe)
18
Relacja znormalizowana
Pracownik Język Poziom
Jan Kowalski angielski słabo
Jan Kowalski niemiecki dobrze
Adam Kot rosyjski bardzo

dobrze
19
Relacja znormalizowana
— Relacja jest relacją trójczłonową, której wszystkie dziedziny są proste, jest

więc znormalizowana
— Powodem tego jest uproszczenie struktury danych, które z kolei powoduje
uproszczenie operatorów w subjęzyku danych
— Uproszczenia te nie ograniczają w niczym możliwości reprezentowania
obiektów
20
Relacja znormalizowana - nieporozumienia
Pracownik Imię dziecka Data ur.

dziecka
Kowalski Ania 01.01.2000
Jaś 15.03.2001
Kot Patrycja 20.10.2001
Filemon 30.07.2003
21
Relacja znormalizowana - nieporozumienia
Praco- Imię Data ur. Imię Data ur.

wnik dziecka dziecka1 dziecka2 dziecka2
1
Kowal- Ania 01.01.2000 Jaś 15.03.2001
ski
Kot Patrycja 20.10.2001 Filemon 30.07.2003
22
Przedmiot Prowadzący Student Ocena
matematyka prof. Lis Jan Kot 2,0

matematyka prof. Lis Ewa Osa 3,0
matematyka prof. Lis Adam Struś 5,0
23
Przedmiot Student Ocena

matematyka Jak Kot 2,0
matematyka Ewa Osa 3,0
matematyka Adam Struś 5,0
Przedmiot Prowadzący
matematyka prof. Lis
24
Anomalie przy usuwaniu, wstawianiu i aktualizacji
Pracownik PESEL Komórka Stanowisko Zadania

organizacyjna
Jan Kowalski 12345678911 Dział Kadr kierownik kierowanie
Jan Kowalski 12345678911 Dział Kadr kierownik nadzór
Jan Kowalski 12345678911 Dział Kadr kierownik analizy
Adam Kot 98977796666 Dział Kadr referent sprawozdania
Adam Kot 98977796666 Dział Kadr referent analizy
Ewa Lis 76281976372 Dział Kadr referent sprawozdania
Ewa Lis 76281976372 Dział Kadr referent analizy
25
Anomalie przy usuwaniu, wstawianiu i aktualizacji
— Reorganizacja polegająca na likwidacji Działu Kadr spowoduje utratę informacji o

wszystkich pracownikach działu
— Wprowadzając informację o nowym zadaniu dla referenta działu kadr musimy ją
wprowadzić dla każdego pracownika na tym stanowisku (anomalia przy
wstawianiu)
— Zmieniając nazwę działu na Dział Personalny musimy zaktualizować wszystkie
rekordy (anomalia przy aktualizacji)
Pracownik PESEL Komórka Stanowisko Zadania

organizacyjna
Jan Kowalski 12345678911 Dział Kadr kierownik kierowanie
Jan Kowalski 12345678911 Dział Kadr kierownik nadzór
Jan Kowalski 12345678911 Dział Kadr kierownik analizy
Adam Kot 98977796666 Dział Kadr referent sprawozdania
Adam Kot 98977796666 Dział Kadr referent analizy
Ewa Lis 76281976372 Dział Kadr referent sprawozdania
Ewa Lis 76281976372 Dział Kadr referent analizy
26
Przykład:

Przykład:
Wartości atrybutów nie są elementarne

Przykład (c.d.):
Klucz potencjalny: <rodzaj_studiow, rok_studiow, rok_akademicki, przedmiot, forma,

termin, student_nr_albumu>
Zależności funkcyjne
Powtarzające się grupy

Klucz główny relacji protokoly:
<id_przedmiot, termin,
nr_albumu>

Zależności funkcyjne i wielowartościowe -
przypomnienie
— Zależność funkcyjna oznacza, że znając wartość jednego atrybutu, zawsze

możemy określić wartość innego. Symbolem stosowanym w teorii relacji
jest strzałka umieszczona pomiędzy dwoma atrybutami, na przykład:
X→Y (X określa Y)
przykład: gdy znamy numer PESEL naszego pracownika, możemy określić jego
nazwisko
— Zależność wielowartościowa oznacza, że znając wartość jednego atrybutu,
możemy zawsze określić wartości zbioru innego atrybutu. W teorii relacji
używa się symbolu zależności wielowartościowej w postaci podwójnej
strzałki, na przykład:
X →→ Y (X określa wiele Y)
przykład: znając numer oddziału możemy określić nazwiska wszystkich
zatrudnionych pracowników

Klucz - przypomnienie
— Kluczem relacji nazywamy taki zbiór atrybutów tej relacji, których

kombinacje wartości jednoznacznie identyfikują każdą krotkę tej relacji a
żaden podzbiór tego zbioru nie posiada tej własności. W kluczu nie może
zawierać się wartość NULL.
— Klucz jest kluczem prostym, jeżeli powyżej opisany zbiór jest

jednoelementowy - w przeciwnym razie mówimy o kluczu złożonym.
— W ogólności, w relacji można wyróżnić wiele kluczy, które nazywamy

kluczami potencjalnymi. Wybrany klucz spośród kluczy potencjalnych
nazywamy kluczem głównym.

Druga i trzecia postać normalna:
— Relacja jest w drugiej postaci normalnej, jeśli jest w 1PN oraz każdy atrybut
tej relacji nie wchodzący w skład żadnego klucza potencjalnego jest w pełni
funkcyjnie zależny od wszystkich kluczy potencjalnych tej relacji.
— Relacja jest w 2PN jeżeli każdy atrybut nie wchodzący w skład klucza zależy
od całości klucza a nie od jego części.
— Relacja będąca w pierwszej postaci normalnej, jest równocześnie w drugiej
postaci normalnej, jeśli wszystkie jej klucze potencjalne są kluczami
prostymi.
— Dana relacja jest w trzeciej postaci normalnej, jeśli jest ona w drugiej
postaci normalnej i każdy jej atrybut nie wchodzący w skład żadnego klucza
potencjalnego nie jest przechodnio funkcyjnie zależny od żadnego klucza
potencjalnego tej relacji.

Druga i trzecia postać normalna:
Inaczej mówiąc, wszystkie niekluczowe kolumny są określane
kluczem, całym kluczem i tylko kluczem,

„…tak nam dopomóż Codd”
The key, the whole key, and nothing but the
key, so help me Codd

Ta relacja nie jest w drugiej postaci normalnej
(prawdopodobnie)
Prowadzący Przedmiot Rodzaj studiów

Kot Bazy Danych Stacjonarne
Kot Bazy Danych Niestacjonarne
Mysz Matematyka Stacjonarne
Sowa Systemy operacyjne Stacjonarne

(prawdopodobnie)

Kot Bazy Danych Niestacjonarne

(prawdopodobnie)

Kangur Bazy Danych Niestacjonarne

Zależność funkcjonalna przechodnia
— Niech X, Y i Z będą trzema rozłącznymi podzbiorami

atrybutów danej relacji
—Z jest przechodnio funkcjonalnie zależny od X, jeśli Z
jest funkcjonalnie zależny od Y i Y jest funkcjonalnie
zależny od X natomiast X nie jest zależny od Y i Y nie
jest zależny od Z

Ta relacja nie jest w trzeciej postaci normalnej
Dana relacja jest w trzeciej postaci normalnej, jeśli jest ona w drugiej postaci
normalnej i każdy jej atrybut nie wchodzący w skład żadnego klucza potencjalnego
nie jest przechodnio funkcyjnie zależny od żadnego klucza potencjalnego tej relacji.
Pracownik PESEL KodPocztowy Miejscowość Województwo
Jan Kowalski 12345678911 32-082 Bolechowice małopolskie
Adam Kot 98977796666 30-150 Kraków małopolskie

Ewa Lis 76281976372 32-082 Bolechowice małopolskie
To jest klucz główny ?

Forma normalna Boyce-Codd’a
— Jest uzupełnieniem trzeciej postaci normalnej i jest

niezbędna w przypadku gdy atrybuty będące
kandydatami na klucze są:
» wielokrotne,
» złożone,
» nakładające się na siebie

Forma normalna Boyce’a-Codd’a
— Relacja jest w postaci Boyce-Codd’a (BCPN) jeżeli dla

każdej nietrywialnej zależności między podzbiorami
relacji zbiór będący wyznacznikiem jest zbiorem
identyfikującym tej relacji
— Zależność X →Y jest trywialna jeżeli Y jest podzbiorem
X
— Definicja BCPN zastępuje definicje, pierwszej, drugiej
i trzeciej formy normalnej dodatkowo je poszerzając

IdStudenta Seminarium Opiekun

1 metalurgia Kowalski
1 inżynieria wiedzy Kozłowski
2 inżynieria wiedzy Janowski
4 informatyka Zając
• opiekun może mieć tylko jedno seminarium, więc kluczem w relacji może być:
podzbiór IdStudenta + Seminarium lub IdStudenta + Opiekun
• Student może chodzić na konkretne seminarium u tylko jednej osoby






• Nie spełniona jest III postać normalna, ponieważ klucz IdStudenta + Opiekun nie
determinują seminarium, która zależy tylko i wyłącznie od opiekuna. Z tego powodu
jako kandydata na klucz główny powinno się wziąć pod uwagę IdStudenta +
Seminarium
• zależność Opiekun  Seminarium jest funkcjonalna i nietrywialna a Opiekun nie jest
zbiorem identyfikującym


— Załóżmy, że chcemy przydzielić nazwiska prowadzących do odpowiednich seminariów przed

rozpoczęciem zapisów studentów na konkretny przedmiot.
— Nie możemy tego zrobić, ponieważ nazwisko studenta jest częścią klucza głównego i z tego
powodu, przy wstawianiu nowego wiersza tabeli trzeba wstawić nazwisko studenta (anomalia
dołączania).
— Również może zaistnieć anomalia w przypadku, gdy wystąpi potrzeba zmiany nazwiska
prowadzącego przedmiot. Wtedy będzie trzeba wstawić nowe nazwisko do wielu wierszy
jednocześnie.
— Aby zaradzić tym problemom należy sprowadzić tabelę do postaci Boyce-Codda. W tym celu
zostaną utworzone 3 tabele:

IdStudenta Opiekun Seminarium Opiekun

1 Kowalski metalurgia Kowalski
1 Kozłowski inżynieria wiedzy Kozłowski
2 Janowski inżynieria wiedzy Janowski
3 Kowalski informatyka Zając
4 Zając
IdStudenta Seminarium
1 metalurgia
1 inżynieria wiedzy
2 inżynieria wiedzy
3 metalurgia
4 informatyka

Czwarta forma normalna
— Relacja jest w czwartej formie normalnej (IV PN) wtedy i tylko wtedy, gdy
jest w trzeciej postaci normalnej i nie zawiera nietrywialnej
wielowartościowej zależności atrybutów
— Podzbiór atrybutów Y jest wielowartościowo funkcjonalnie zależny od
podzbioru X w schemacie R, jeżeli dla dowolnej relacji r w schemacie R i dla
dowolnej pary krotek t1 i t2 z relacji r istnieje taka para krotek że:
s1[X]=s2[X]=t1[X]=t2[X] i
s1[Y]= t1[Y] i s1[R-X-Y]=t2[R-X-Y] i
s2 [Y]= t2[Y] i s2 [R-X-Y]=t1[R-X-Y]

Zależność wielowartościowa - przypomnienie
X Y R-X-Y
krotka Nazwisko Imię Znajomość języków
dziecka
t1 Kot Ania niemiecki
t2 Kot Jaś angielski
s1 Kot Ania angielski
s2 Kot Jaś niemiecki
Słoń Ola niemiecki
Słoń Ola angielski
t1[X]=t2[X]=s1[X]=s2[X]=(Kot)
s1[Y]= t1[Y]=(Ania) i
s1[R-X-Y]=t2[R-X-Y]=(angielski) i
s2 [Y]= t2[Y]=(Jaś) i
s2 [R-X-Y]=t1[R-X-Y]=(niemiecki)

Restauracja Gatunki Obszar dostawy

A1 Pizza Thick Crust Springfield
A1 Pizza Thick Crust Shelbyville
A1 Pizza Thick Crust Capital City
A1 Pizza Stuffed Crust Springfield
A1 Pizza Stuffed Crust Shelbyville
A1 Pizza Stuffed Crust Capital City
Elite Pizza Thin Crust Capital City
Elite Pizza Stuffed Crust Capital City
Vincenzo's Pizza Thick Crust Springfield
Vincenzo's Pizza Thick Crust Shelbyville
Vincenzo's Pizza Thin Crust Springfield
Vincenzo's Pizza Thin Crust Shelbyville
X Y
Tabela spełnia PNBC; klucz (X + Y) -> (z definicji) brak atrybutów niekluczowych (patrz
definicja PNBC), pomimo to pozostają anomalie (np. zmiana obszaru dostawy wymaga
…(?) ). 50
KISIM, WIMiIP, AGH
Restauracja Gatunki
A1 Pizza Thick Crust
A1 Pizza Stuffed Crust
Elite Pizza Thin Crust
Elite Pizza Stuffed Crust
Vincenzo's Pizza Thick Crust
Vincenzo's Pizza Thin Crust
Restauracja Obszar dostawy

A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City
Elite Pizza Capital City
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville

Czwarta postać normalna
— Aby przejść z trzeciej postaci normalnej do czwartej, szukamy tabel, które

zawierają dwie lub więcej niezależnych zależności wielowartościowych.
Zależności wielowartościowe występują na szczęście rzadziej niż zależności
od części klucza lub zależności przechodnie.
52
Piąta postać normalna
— Redukcja redundancji poprzez uwzględnienie dodatkowych zależności

semantycznych („połączone zależności”)
— Tabela jest w 5PN wtedy i tylko wtedy, kiedy każda nietrywialna
„połączona zależność” (joined dependency) jest zależna tylko od kluczy
potencjalnych.
— Relacja jest w piątej formie normalnej (V PN) wtedy i tylko wtedy, gdy jest
w czwartej postaci normalnej i nie istnieje jej rozkład odwracalny na zbiór
mniejszych tabel.

Sprzedawca Marka Typ produktu
Jack Schneider Acme Vacuum Cleaner
Jack Schneider Acme Breadbox
Mary Jones Robusto Pruning Shears
Mary Jones Robusto Vacuum Cleaner
Mary Jones Robusto Breadbox
Mary Jones Robusto Umbrella Stand
Louis Ferguson Robusto Vacuum Cleaner
Louis Ferguson Robusto Telescope
Louis Ferguson Acme Vacuum Cleaner
Louis Ferguson Acme Lava Lamp
Louis Ferguson Nimbus Tie Rack
Tabela jest w 4PN, ponieważ nie jest możliwy podział na relacje (Sprzedawca,
Marka) + (Marka, Typ produktu) ani (Sprzedawca, Typ produktu) + (Sprzedawca,
Marka) ani (Sprzedawca, Typ produktu) + (Marka, Typ produktu)

Ale, jeżeli wiemy więcej …

Ale, jeżeli wiemy więcej …

Np. jeżeli sprzedawca ma w ofercie konkretną markę i konkretny typ, to musi
oferować dany typ dla każdej oferowanej marki
To:

Sprzedawca Typ produktu

Sprzedawca Marka
Vacuum
Jack Schneider Jack Schneider Acme
Cleaner
Mary Jones Robusto
Jack Schneider Breadbox
Louis Ferguson Robusto
Mary Jones Pruning Shears
Louis Ferguson Acme
Vacuum Marka Typ produkty
Mary Jones Louis Ferguson Nimbus
Cleaner
Acme Vacuum Cleaner
Mary Jones Breadbox
Acme Breadbox
Mary Jones Umbrella Stand
Acme Lava Lamp
Louis Ferguson Telescope
Robusto Pruning Shears
Vacuum
Cleaner
Robusto Breadbox
Louis Ferguson Lava Lamp
Robusto Umbrella Stand
Louis Ferguson Tie Rack
Robusto Telescope
Nimbus Tie Rack
Podsumowanie:
— Normalizacja ma na celu takie przekształcenie relacji, by uniknąć

redundancji i anomalii.
— Przekształcenie relacji do kolejnych postaci normalnych wiąże się
najczęściej ze zmniejszeniem ilości pamięci potrzebnej do przechowania
informacji.
— Unikanie powtórzeń pozwala na łatwiejszą i szybszą aktualizację danych.
— Doprowadzenie bazy do wysokiej postaci normalizacji może spowolnić
odczyt w dużych bazach ze względu na skomplikowany schemat danych.
— W większości przypadków po znormalizowaniu bazy danych przychodzi
kolej na rozważenie możliwości wykonania odwrotnej operacji
(denormalizacji), polegającej na połączeniu niektórych znormalizowanych
tabel, a to z myślą o przyspieszeniu dostępu do pewnych danych.

Nr faktury Za okres Nabywca Usługa Strefa Kierunek Liczba W artość Stawka VAT Kwota VAT W artość
czasowa jednostek netto brutto
(czas
połączenia)
od do
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Abonam ent 1 70,00 22,00 15,40 85,40
Arm ii Krajowej 7
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Szczyt Era 25,3 50,60 22,00 11,13 61,73
Arm ii Krajowej 8 krajowe
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Szczyt Plus GSM 30 33,00 22,00 7,26 40,26
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Poza Plus GSM 15 15,00 22,00 3,30 18,30
Arm ii Krajowej 10 krajowe szczytem
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. SMS 20 10,00 22,00 2,20 12,20
Arm ii Krajowej 11
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Razem 186,10 0,00 186,10
Arm ii Krajowej 12
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Abonam ent 1 70,00 22,00 15,40 85,40
Spokojna 5
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Szczyt Era 15 30,00 22,00 6,60 36,60
Spokojna 5 krajowe
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Szczyt Plus GSM 28 30,80 22,00 6,78 37,58
Spokojna 5 krajowe
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Poza Plus GSM 12 12,00 22,00 2,64 14,64
Spokojna 5 krajowe szczytem
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. SMS 15 7,50 22,00 1,65 9,15
Spokojna 5
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Razem 156,30 33,07 183,37
Spokojna 5
59
Nr faktury Za okres Nabywca Usługa Strefa Kierunek Liczba W artość Stawka VAT Kwota VAT W artość
(czas
połączenia)
od do
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Abonam ent 1 70,00 22,00 15,40 85,40
Arm ii Krajowej 7
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Szczyt Era 25,3 50,60 22,00 11,13 61,73
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Szczyt Plus GSM 30 33,00 22,00 7,26 40,26
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Połaczenia Poza Plus GSM 15 15,00 22,00 3,30 18,30
Arm ii Krajowej 10 krajowe szczytem
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. SMS 20 10,00 22,00 2,20 12,20
Arm ii Krajowej 11
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Razem 186,10 0,00 186,10
Arm ii Krajowej 12
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Abonam ent 1 70,00 22,00 15,40 85,40
Spokojna 5
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Szczyt Era 15 30,00 22,00 6,60 36,60
Spokojna 5 krajowe
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Szczyt Plus GSM 28 30,80 22,00 6,78 37,58
Spokojna 5 krajowe
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Połaczenia Poza Plus GSM 12 12,00 22,00 2,64 14,64
Spokojna 5 krajowe szczytem
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. SMS 15 7,50 22,00 1,65 9,15
Spokojna 5
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul. Razem 156,30 33,07 183,37
Spokojna 5
Powtarzająca się grupa danych
60
Nr faktury Za okres Nabywca Usługa Strefa Kierunek Liczba Wartość Stawka VAT Kwota VAT Wartość
(czas
połączenia)
od do
Abonament 1 70,00 22,00 15,40 85,40
Połaczenia Szczyt Era 25,3 50,60 22,00 11,13 61,73
krajowe
Połaczenia Szczyt Plus GSM 30 33,00 22,00 7,26 40,26
Andrzej Macioł, Kraków ul. krajowe
21113332437 1.11.2007 30.11.2007
Armii Krajowej 7
Połaczenia Poza Plus GSM 15 15,00 22,00 3,30 18,30
krajowe szczytem
SMS 20 10,00 22,00 2,20 12,20
Razem 186,10 0,00 186,10
Abonament 1 70,00 22,00 15,40 85,40
Połaczenia Szczyt Era 15 30,00 22,00 6,60 36,60
krajowe
Połaczenia Szczyt Plus GSM 28 30,80 22,00 6,78 37,58
Adam Stawowy, Zabierzów ul. krajowe
21113332442 1.11.2007 30.11.2007
Spokojna 5
Połaczenia Poza Plus GSM 12 12,00 22,00 2,64 14,64
krajowe szczytem
SMS 15 7,50 22,00 1,65 9,15
Razem 156,30 33,07 183,37
Klucz w grupie
61
Nr faktury Za okres Nabywca
od do
21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul.
Arm ii Krajowej 7
21113332442 1.11.2007 30.11.2007 Adam Stawowy, Zabierzów ul.
Spokojna 5
To nie jest pole elementarne
62
to też jest powtarzająca się grupa danych bo za miesiąc będzie tak:
Nr faktury Za okres Identyfikator Nabywca

od do nabywcy Im ię Nazwisko Miejscowość Ulica Nr dom u
21113332437 1.11.2007 30.11.2007 1 Andrzej Macioł Kraków Arm ii Krajowej 7

21113332442 1.11.2007 30.11.2007 2 Adam Stawowy Zabierzów Spokojna 5
21218909871 1.12.2007 31.12.2007 1 Andrzej Macioł Kraków Arm ii Krajowej 8
21218909900 1.12.2007 31.12.2007 2 Adam Stawowy Zabierzów Spokojna 6
63
Nr faktury Za okres Nabywca
od do Imię Nazwisko Miejscowość Ulica Nr domu
21113332437 1.11.2007 30.11.2007

Andrzej Macioł Kraków Armii Krajowej 7
21218909871 1.12.2007 31.12.2007
21113332442 1.11.2007 30.11.2007
Adam Stawowy Zabierzów Spokojna 5
21218909900 1.12.2007 31.12.2007
brak dobrego kandydata na klucz grupy

i dlatego wprowadzamy klucz sztuczny
Nr faktury Za okres Identyfikator Nabywca

od do nabywcy Im ię Nazwisko Miejscowość Ulica Nr dom u
21113332437 1.11.2007 30.11.2007 1

Andrzej Macioł Kraków Arm ii Krajowej 7
21218909871 1.12.2007 31.12.2007 1
21113332442 1.11.2007 30.11.2007 2
Adam Stawowy Zabierzów Spokojna 5
21218909900 1.12.2007 31.12.2007 2
64
Nr faktury Za okres Identyfikator
od do nabywcy wartość netto = liczba jednostek *
21113332437 1.11.2007 30.11.2007 1 cena
1
kwota VAT = wartość netto * stawka
21218909871 1.12.2007 31.12.2007
21113332442 1.11.2007 30.11.2007 2
2
wartość brutto = wartość netto +
21218909900 1.12.2007 31.12.2007
kwota Vat
tego nie
trzeba
pamiętać
65
to też jest powtarzająca się grupa danych, bo tabela może wyglądać
tak:
66
brak dobrego kandydata na klucz grupy i dlatego wprowadzamy
klucz sztuczny i wykonujemy dekompozycję
67
to też jest powtarzająca się grupa danych, w której kluczem jest
rodzaj usługi i dlatego trzeba tablicę zdekomponować:
68
to nie są powtarzające się grupy danych, ale powtarzające się dane,
które warto przechowywać w słownikach:
69
można nie używać sztucznych kluczy ale należy wówczas zadbać o
integralność poprzez zapewnienie kaskadowej aktualizacji:
on update cascade on delete cascade
70
Nr faktury Za okres Identyfikator
od do nabywcy
21113332437 1.11.2007 30.11.2007 1

21218909871 1.12.2007 31.12.2007 1
21113332442 1.11.2007 30.11.2007 2
21218909900 1.12.2007 31.12.2007 2
71
Klucz sztuczny
— Klucz stworzony wyłącznie dla potrzeb więzi w celu zastąpienia złożonego

klucza głównego

Klucz złożony...

...zastąpiony kluczem sztucznym

Klucz złożony...

...zastąpiony kluczem sztucznym

Klucz sztuczny
— Klucz sztuczny może być wykorzystany do kodowania atrybutów

tekstowych (w niektórych przypadkach także liczbowych) o powtarzających
się wartościach, dla których można utworzyć listę
— Użycie klucza sztucznego wymaga stworzenia dodatkowej tabeli (słownika)
pozwalającego na „rozkodowanie” klucza

4/10/2017
MS Access Posługiwanie się bazą danych
— Funkcje bazy danych:

» wyszukiwanie danych
– filtr – doraźnie
– kwerenda – trwale
» modyfikacja (aktualizacja) danych
Budowanie schematu. Tabele i kwerendy.
» dopisywanie danych
» usuwanie danych
— Celem SZBD jakim jest MS Access jest dostarczenie
użytkownikowi wygodnego i łatwego do używania środowiska
Piotr Macioł
WIMiIP, KISiM, (QBE, formularze)
pmaciol@agh.edu.pl
Konsultacje: środa, godz. 10:00-11:30
B5, pok. 606
— Ważnym elementem jest generator raportów
QBE - Query By Example QBE - Query By Example (2)
— Query By Example (QBE) -

przyjazna dla użytkownika
technika tworzenia zapytań — System QBE dokonuje
do bazy danych. konwersji z zapytania
— Technika ta polega na użytkownika do
tworzeniu zapytań poprzez formalnego zapytania
uzupełnianie siatki kolejnymi bazy danych (SQL). Dzięki
polami pobieranymi z tabel temu użytkownik może
lub innych kwerend. wykonywać
— W interfejsie siatki QBE skomplikowane zapytania
znajdują się relacje między Tabele i kwerendy do bazy danych bez
tabelami (tabele i kwerendy znajomości formalnych
Schemat kwerendy
wyglądają w niej tak samo), metod takich jak SQL
polecenia sortowania i Sortowanie i kryteria
grupowania oraz kryteria.
KISIM, WIMiIP, AGH 3 KISIM, WIMiIP, AGH 4
Płaszczyzny bazy danych Tabele i relacje
— Wygodne projektowanie tabel,

— Płaszczyzna projektu – schemat kluczy, właściwości pól
bazy (m.in. tabele, relacje)
— Widok okna relacji zbliżony do
— Interfejs użytkownika –
diagramu E-R - prosta
narzędzia umożliwiające proste implementacja modelu bazy
posługiwanie się bazą danych danych
(formularze, raporty)
— Wyszukiwanie, modyfikacja,
dopisywanie, usuwanie danych –
możliwe w obu płaszczyznach
— Na podstawie mechanizmów
płaszczyzny projektanta możliwe
jest tworzenie płaszczyzny
użytkownika (interfejsu
użytkownika)
1
4/10/2017
Filtry Kwerendy
— Kwerenda (query) – zapytanie.

— Filtry wydobywają podzbiór rekordów z — Rodzaje kwerend wybierających:
tabeli lub innej kwerendy. Zwykle
używamy filtru, aby chwilowo » Kwerendy wybierające: wyszukiwanie określonych
edytować lub przeglądać część danych (prosta, podsumowująca)
rekordów w arkuszu lub danych w » Kwerendy krzyżowe: prezentacja danych w bardziej
formularzu. czytelnej postaci
— Kwerendy funkcjonalne (modyfikacja danych i schematu,
nie zwracają tabel wynikowych)
» Kwerendy aktualizujące: modyfikację danych
» Kwerendy dołączające: dopisywanie nowych
rekordów i kolekcji rekordów
» Kwerendy usuwające: usuwanie określonych
rekordów i kolekcji rekordów
» Kwerendy tworzące tabelę
— Stworzenie mechanizmów pracy z bazą danych należy do
etapu projektowania
Kwerenda wybierająca Kwerenda wybierająca (2)
— Zapewnia powtarzalne wydobywanie podzbioru rekordów z Tworzenie kryteriów wyszukiwania:

— Wpisując konkretne wartości (np. numer albumu studenta) jakie ma
tabeli lub innej kwerendy.
posiadać szukany rekord (grypa rekordów)
— Z kwerendy należy korzystać, gdy chcemy wydobyć dane z
wielu tabel, kontrolować, które pola będą widoczne, lub — Tworząc warunki przy użyciu
operatorów:
przeprowadzać obliczenia na wartościach pól. Żadna z tych
» >10
operacji nie jest dostępna przy użyciu filtru.
» >= #1/10/2003#
» Between #1/10/2005#
And #15/10/2005#
Wybór tabeli (bądź Określenie warunków W wyniku powstaje
wielu tabel) lub wyboru pól i rekordów tabela tymczasowa
» Like ”*chem*”
kwerendy, z której (kryteria, podsumowania (wirtualna) – nie jest » In ("qqq1", "qqq2", "qqq3")
pobierane będą dane etc.) zapisywana w bazie
» Is Null
danych
Kryteria Najwyższe wartości
— Warunki wpisane w tej samej linii kryteriów są połączone — Istnieje możliwość wybrania w prosty sposób pewnej grupy
spójnikiem logicznym "i" (podając liczbę krotek, lub procentowy udział) największych
bądź najmniejszych wartości (zależnie od ustawienia
— Warunki wpisane w różnych liniach są połączone spójnikiem
sortowania)
logicznym "lub"
— można też wpisywać dowolne wyrażenia logiczne, np:
"101107" Or "101109"
2
4/10/2017
Symbole wieloznaczne Operatory
— operator porównywania ciągów znaków:

Symbol Opis Przykład LIKE ”*wyrażeni[ea]”
* dowolna liczba znaków (w tym zero). Może być pr* znajduje wyrazy: produkt,
używany jako pierwszy lub ostatni znak w ciągu. promocja i prawnik — operatory relacji:
? dowolny pojedynczy znak alfabetu. mi?a znajduje wyrazy: mina, misa i
mila <, >, >=, <=, =, <>
[] dowolny pojedynczy znak spośród znaków mi[nl]a znajduje wyrazy: mina i operatory logiczne
umieszczonych w nawiasach kwadratowych. mila, ale nie misa
! dowolny znak inny niż znaki umieszczone w mi[!nl]a znajduje wyrazy: misa i » AND (iloczyn logiczny, koniunkcja)
nawiasach kwadratowych. miła, ale nie mina ani mila
» OR (suma logiczna, alternatywa)
- dowolny znak należący do zakresu. Zakres musi b[a-c]d znajduje ciągi: bad, bbd i
być podany w porządku rosnącym (od A do Z, a bcd » NOT (negacja, występuje z operatorem And, Or)
nie od Z do A).
# dowolny pojedynczy znak numeryczny. 1#3 znajduje liczby: 103, 113 i 123 — operator przynależenia do listy IN
IN (element 1; element2; ....)
Operatory (2) Kwerenda wybierająca z parametrem
— Problem z przewidzeniem różnorodności kryteriów
— operator zawierania się w przedziale — Olbrzymia liczba zdefiniowanych kwerend

BETWEEN ‘dolna_granica’ AND — Problem z dopisanymi w trakcie użytkowania bazy danych
‘górna_granica’ wartościami
— Zamiast wpisywać „konkretnej” wartości
w warunku, zmuszamy użytkownika do podania parametru
— warunek do pól z „datami”
— Parametry mogą brać udział w wyrażeniach
#data#
> #98-01-01#
Kolumny wyliczane Kwerenda podsumowująca
— Oprócz wyboru do relacji wynikowej kolumn z relacji danych, możliwe jest — W ten sposób można obliczyć sumę lub średnią
także zdefiniowanie kolumn, których wartości są wyliczane na podstawie wartości w kolumnie, znaleźć wartość minimalną lub
innych. maksymalną i policzyć liczbę elementów w kolumnie.
— Można pogrupować rekordy tabeli i w każdej grupie

rekordów obliczać funkcje agregującą danego pola lub
wyrażenia
3
4/10/2017
Kwerenda krzyżowa Kwerenda aktualizująca
— Powstaje ono przez skrzyżowanie dwóch kolumn — Istnieje możliwość

pochodzących z tej samej tabeli albo dwóch różnych tabel „hurtowej” zmiany wielu
(kwerend). Oznacza to, że wartości jednej z kolumn tabeli wartości w tabeli za
zostaną użyte jako nagłówki kolumn kwerendy krzyżowej. pomocą kwerendy
aktualizującej. W tym celu
tworzymy kwerendę
wybierającą krotki, które
mają zostać
zaktualizowane i określamy
wyrażenie wprowadzające
Kwerenda prezentuje
zmiany w wierszu
ostatnie terminy Aktualizacja do
kolokwiów
Kwerenda dołączająca Kwerenda usuwająca
— W celu usunięcia krotek z

— Do tabeli można także dopisać nowe krotki lub dołączać krotki relacji tworzymy kwerendę
wybrane za pomocą kwerendy z innych tabel. Schemat relacji wybierającą takie krotki, a
dopisywanej krotki musi się zgadzać ze schematem tabeli. następnie zmieniamy typ Uruchamianie
kwerend
kwerendy na Usuwająca. Z funkcjonalnych
tabeli zostaną usunięte
wszystkie krotki wybrane
przez kwerendę (można je
wcześniej obejrzeć
przełączając widok kwerendy
na Arkusz danych).
— UWAGA: Usunięcie każdej
takiej krotki może pociągnąć
za sobą usunięcie krotek z
innych tabel, jeżeli są one
powiązane związkami.
Interfejs użytkownika
— Interfejs użytkownika zapewnia proste, intuicyjne

posługiwanie się bazą danych. Należy założyć, że użytkownik
nie zna teorii baz danych.
— Podstawowe elementy Interfejsu użytkownika:
» formularze
Interfejs użytkownika. » raporty
Formularze, raporty. — Formularz umożliwia:
» wygodny i przejrzysty dostęp do danych
» ułatwiony wpis danych do tabel
» „jednoczesny” wpis danych do wielu tabel (połączone
formularze, podformularze)
— Formularz pobiera dane z:
» tabeli (tabel)
» kwerendy
4
4/10/2017
Typy formularzy
— Formularz do wprowadzania danych

— Formularz panelu przełączania Nagłówek
— Niestandardowe okno dialogowe
— Wykres Sekcja szczegóły
Lista pól
Przybornik formantów
Formanty Właściwości
— Właściwości formularza i formantów:
— Etykieta – przeznaczona do » Określają wygląd
wyświetlania tekstów informacyjnych
» Zachowanie
— Pole tekstowe – zawiera dane z obiektu
źródłowego lub będące wynikiem » Źródło danych
wyrażenia. » Zachowanie formantu
— Grupa opcji – pozwala na dokonywanie — Np:
wyboru w formularzu. Można do niej
dodawać pole wyboru, przycisk opcji » Źródło rekordów – domyślna tabela,
bądź przycisk przełącznika jako kwerenda lub wyrażenie w języku SQL
elementy umożliwiające wybór.
będące podstawą formularza Zakładki grup
— Pole listy – wyświetla listę wartości, z właściwości
której należy wybrać jedną. Musi mieć » Tytuł – tekst pojawiający się na pasku
określone źródło informacji, z którego tytułu w widoku Formularz,
pobiera wartości. » Widok domyślny – określa wygląd
— Pole kombi – stanowi połączenie pola formularza po jego otwarciu, może to być
tekstowego i pola listy tzn. wartość Formularz pojedynczy, Formularze ciągłe
może być wpisana w polu lub wybrana z lub Arkusz danych,
listy.
— Przycisk polecenia – jest formantem po,
» Dostępne widoki – decyduje o możliwości
kliknięciu którego uruchamiane jest przełączania się pomiędzy widokami.
makropolecenie lub procedura
zdarzenia.
Połączone formularze, podformularze Formularze do tabel łącznikowych
— Umożliwiają dostęp do
danych z dwóch tabel — Cel: proste uzupełnianie
— Dla każdej tabeli osobny tabeli wyniki:
formularz » nr_albumu
— Podformularz w formularzu » ID_kolokwium
głównym
(bez zapamiętywania
— Połączone formularze wartości kluczy)
5
4/10/2017
Formularze do tabel łącznikowych (2) Formularze do tabel łącznikowych (3)
Lista pól, które będą

widoczne.
Przechowywany
będzie klucz!
Formularz panelu przełączania Niestandardowe okno dialogowe
— Ich przeznaczeniem jest umożliwiać przełączanie pomiędzy — Istnieje możliwość zaprojektowania formularza będącego
innymi obiektami (formularzami, raportami) rozbudowanym oknem dialogowym.
— Podstawowy formant: przycisk polecenia — Przykład: parametry wyszukiwania produktu
— Pola tekstowe
odpowiadające
kryteriom
wyszukiwania
— Przycisk polecenia
wywołujący kwerendę
szukaj_produktu
Niestandardowe okno dialogowe (2) Niestandardowe okno dialogowe (3)
Kwerenda
szukaj_produktu
•Like "*" & [Forms]![Wyszukaj]![Producent] & "*"

•Like "*" & [Forms]![Wyszukaj]![Kategoria] & "*"
•<[Forms]![Wyszukaj]![Cena]
•Like "*" & [Forms]![Wyszukaj]![Produkt] & "*" Wynikiem jest grupa
•<[Forms]![Wyszukaj]![Zapasy] rekordów spełniająca kryteria
wyszukiwania z formularza
6
4/10/2017
Interfejs użytkownika
Raport
— umożliwia tworzenie określonych zestawień, podsumowań
dotyczących danych zawartych w bazie
— jest odbiciem chwilowego stanu bazy (fotografia
rzeczywistości)
— najczęściej tworzony są dla potrzeb wydruku lub eksportu do
pliku
Raporty — projektując raport użytkownik ma wpływ na szatę graficzną
raportu, można w nim umieszczać m.in. rysunki, linie, ramki,
wykresy itp.
— można sortować i grupować informacje wg określonych
kryteriów
— można w raporcie wykonać obliczenia na danych włączając w
to sumy częściowe i całkowite.
— Pobiera dane z tabel i kwerend
— Skonstruowany przy użyciu formantów
Widok Projekt Raportu Grupowanie w raporcie
w polu, po którym
grupujemy wartości
Nagłówek, stopka raportu powtarzające są
umieszczamy elementy, które wyświetlane tylko raz
są widoczne na pierwszej i
ostatniej stronie (np. strona
Grupowanie po nazwie
tytułowa)
kategorii oraz nazwie
producenta
Nagłówek, stopka strony

umieszczamy etykiety
i elementy, które mają być
widoczne na każdej stronie
7
4/10/2017
Model relacyjny:
• Baza danych przedstawiona jest w postaci tablic
dla encji, związków i ich atrybutów.
Podstawowe zagadnienia • Tablice, a tym samym cała baza danych, mogą być
interpretowane jako relacje w sensie
algebry relacji matematycznym. Również operacje w bazie danych
– jako operacje na relacjach.
• Podstawą modelu jest algebra relacji opisująca te
operacje i ich własności.
• Algebra relacji stanowi również podstawę języków
DDL i DML w tym SQL.
Relacja (przypomnienie): Model relacyjny danych:

• Dane są zbiory A1, A2, …. An , relacją r nazywamy • A1, A2, …, An oznaczają atrybuty.
dowolny podzbiór A1 x A2 x … x An
• R = (A1, A2, …, An ) jest schematem relacji R.
• Relacja jest zbiorem krotek (a1, a2, …, an), gdzie każde ai
 Ai • Np.
• Np. Customer-schema = (customer-name, customer-street,
customer-name = {Jones, Smith, Curry, Lindsay} customer-city)
customer-street = {Main, North, Park}
customer-city = {Harrison, Rye, Pittsfield} • r(R) oznacza instancję r relacji o schemacie R.
r = {(Jones, Main, Harrison), (Smith, North, Rye),
• Np.
(Curry, North,Rye), (Lindsay, Park, Pittsfield)} customer (Customer-schema)
jest relacją określoną na
customer-name x customer-street x customer-city • t = (a1, a2, …, an), t  r oznacza krotkę relacji r(R).
Model relacyjny danych (c.d.): Kategorie w algebrze relacji:

• Aktualna wartość relacji (instancja relacji) może być • Zwyczajne działania algebry zbiorów: suma,
przedstawiona w formie tabeli, której: przecięcie i różnica
• kolumny odpowiadają atrybutom,
• Operacje zawężenia: selekcja eliminuje pewne
• nagłówek odpowiada schematowi relacji.
wiersze, a rzutowanie pewne kolumny
• Elementy relacji - krotki są reprezentowane przez
wiersze tabeli. • Operacje komponowania krotek z różnych relacji:
customer-name customer-street customer-city np. iloczyn kartezjański
Jones Main Harrison

• Operacje przemianowania nie zmieniające krotek
Smith North Rye ale schemat ich relacji
Curry North Rye
Lindsay Park Pittsfield
customer
1
4/10/2017
Przykłady:
Działania teoriomnogościowe: R: Marka Model Rok
S: Marka Model Rok
samochodu samochodu produkcji samochodu samochodu produkcji
Fiat Uno 1990 Fiat Uno 1990
• RS – suma zbiorów R i S jest zbiorem krotek, z Ford Fiesta 2000 Ford Mondeo 2000
których każda należy do R lub S lub do obu razem; Fiat Panda 1004
jeżeli krotka występuje w obu relacjach to w ich Ford Mondeo 1998
sumie pojawia się tylko raz
Marka Model Rok
RS:
• RS – przecięcie zbiorów R i S jest zbiorem krotek, samochodu samochodu produkcji
Fiat Uno 1990
które należą zarówno do R jak i S Ford Fiesta 2000
• R-S – różnica zbiorów R i S zawiera krotki należące Ford Mondeo 2000
do R i nie należące do S Fiat Panda 1004
Ford Mondeo 1998
• Relacje R i S muszą mieć identyczne schematy R-S : Marka Model Rok
RS : Marka Model Rok
samochodu samochodu produkcji samochodu samochodu produkcji
Ford Fiesta 2000 Fiat Uno 1990
Rzutowanie: Selekcja:
• nie zmieniając schematu relacji R tworzy nową
relację zawierającej podzbiór krotek R spełniających
pewien logiczny warunek
• Tworzy nową relację z relacji R przez usunięcie z niej
pewnych kolumn
 C (R)
 A1, A2,...,An ( R)
• gdzie C to wyrażenie warunkowe na jednym lub
więcej atrybutach
Iloczyn kartezjański: Złączenie naturalne:

• (inaczej produkt) relacji R i S to relacja wszystkich uporządkowanych par krotek, z • polega na połączeniu w pary tych krotek z relacji R i S, które mają
których pierwszy element pary należy do relacji R a drugi do S identyczne wartości dla wszystkich wspólnych atrybutów i jest oznaczane
• Schemat relacji RS jest sumą schematów relacji R i S, w której powtarzające się R S
atrybuty (kolumny) traktowane są jako odrębne elementy schematu, np. R.A i S.A • w rezultacie powstaje relacja, której schemat zawiera atrybuty relacji R i
relacji S, przy czym wspólna część uwzględniana jest tylko raz
Student Język Student Język
Adam Kot angielski Adam Kot matematyka
Student Przedmiot Semestr Ocena
Adam Kot niemiecki Adam Kot fizyka
R: S: Adam Kot Matematyka I 3,0 Przedmiot Semestr Prowadzący
Adam Kot Fizyka II 4,0 Matematyka I Prof. Wilk
R.Student Język S.Student Przedmiot Jan Pies Matematyka I 2,0 Fizyka II Prof. Zając
RS: Adam Kot angielski Adam Kot matematyka Matematyka II Prof. Kos
Adam Kot angielski Adam Kot fizyka Student Przedmiot Semestr Ocena Prowadzący
Adam Kot niemiecki Adam Kot matematyka
Adam Kot Matematyka I 3,0 Prof. Wilk
Adam Kot niemiecki Adam Kot fizyka
Adam Kot Fizyka II 4,0 Prof. Zając
Jan Pies Matematyka I 2,0 Prof. Wilk
2
4/10/2017
Typy złączeń: Złączenie teta

• złączenie wewnętrzne (inner join) – w relacji wynikowej występują wyłącznie
te krotki, które spełniają warunek złączenia
• złączenie lewostronne zewnętrzne (left outer join) – zawiera wszystkie krotki
• polega na złączeniu dwóch relacji R i S w
R uzupełnione krotkami S spełniającymi warunek iloczyn kartezjański i wyborze z niego tych
• złączenie prawostronne zewnętrzne (right outer join) - zawiera wszystkie krotek, które spełniają wyrażenie warunkowe
krotki S uzupełnione krotkami R spełniającymi warunek na parze lub zbiorze par atrybutów z R i S i
• złączenie zewnętrzne pełne (full outer join) – zawiera wszystkie krotki R oraz S jest oznaczane symbolem R ΘR lub R CS,
uzupełnione wartościami typu NULL gdy do danej krotki nie pasuje żadna gdzie Θ lub C to wyrażenia logiczne
krotka z drugiej relacji
• złączenie zewnętrzne typu union - zawiera wszystkie krotki R nie pasujące do
żadnej krotki S uzupełnione krotkami S nie pasującymi do żadnej krotki R
Złączenie teta
R
Równozłączenie
Towar Data_Od Data_do Cena
mąka 1.01.2004 31.01.2004 2,00 • to szczególny przypadek złączenia teta, w

mąka 1.02.2004 31.03.2004 2,10 którym warunek ma charakter równości
mąka 1.04.2004 2,05 wybranych atrybutów obu relacji
S
• powtarzające się kolumny opisujące atrybuty
Towar Data Ilość
mąka 15.03.2004 10
z warunku złączenia są pomijane
R C S
R.Towar Data_Od Data_do Cena S.Towar Data Ilość
mąka 1.02.2004 31.03.2004 2,10 mąka 15.03.2004 10
C= (R.Towar=S.Towar AND Data>=Data_Od

AND Data<=Data_Do )
Złączenie lewostronne
Równozłączenie
zewnętrzne
R S R S
Towar Klient Kontrahent Miasto Towar Klient Kontrahent Miasto
stal Exbud Exbud Kielce stal Exbud Exbud Kielce
PBS Kraków PBS Kraków
cegła PBS cegła PBS
PHS Tarnów PHS Tarnów
złom złom
R R.Klient=S.Kontrahent S R R.Klient=S.Kontrahent S
Towar Klient Miasto Towar Klient Miasto
stal Exbud Kielce stal Exbud Kielce
cegła PBS Kraków cegła PBS Kraków
złom
3
4/10/2017
Złączenie prawostronne
Złączenie zewnętrzne pełne
zewnętrzne
R S R S
Towar Klient Kontrahent Miasto Towar Klient Kontrahent Miasto
stal Exbud Exbud Kielce stal Exbud Exbud Kielce
PBS Kraków PBS Kraków
cegła PBS cegła PBS
PHS Tarnów PHS Tarnów
złom złom
R R.Klient=S.Kontrahent S
R R.Klient=S.Kontrahent S
Towar Klient Miasto
Towar Klient Miasto stal Exbud Kielce
stal Exbud Kielce cegła PBS Kraków
cegła PBS Kraków
złom
PHS Tarnów
PHS Tarnów
Przemianowanie:
Złączenie zewnętrzne typu union
R S
Towar Klient Kontrahent Miasto
stal Exbud
Exbud Kielce • zmienia nazwę relacji i ewentualnie nazwy atrybutów
PBS Kraków (kolumn) w relacji i jest oznaczane
cegła PBS
PHS Tarnów
złom
R S
 S ( A , A ,...A ) ( R)
1 2 n
R.Klient=S.Kontrahent
Towar Klient Miasto
złom
• w tym przypadku relacja R zostanie przemianowana na S a
atrybuty otrzymają nazwy A1, A2,...An
PHS Tarnów
4
4/10/2017
Bazy Danych Języki zapytań
— Interfejsy typu zapytanie przez przykład (ang. Query by

Example - QBE), szablony (formularze, strony WWW)
— Structured Query Language (SQL), języki algebraiczne
— języki predykatowe (o zmiennych atrybutowych i krotkowych)
SQL – Podstawy języka — DATALOG (język zbliżony do PROLOGu
ale nieproceduralny i bez termów)
Piotr Macioł
WIMiIP, KISiM,
pmaciol@agh.edu.pl
B5, pok. 606
Czym jest SQL? SQL – historia
— 1974: Chamberlain, IBM, San Jose – SEQUEL

— Structured Query Language SQL - nieproceduralny język typu Structured English Qery Language
strukturalnego przeznaczony do uzyskiwania dostępu
i operowania danymi (DML) oraz budowy bazy danych (DDL). — koniec lat 70-tych: ORACLE (Relational Software Inc.) – pierwsza
implementacja komercyjna
— Program składa się z poleceń, które mają określoną strukturę
wewnętrzną (dyrektywy wewnętrzne). — 1982: ANSI* – RDL (Relational Data Language)
— SQL w swoich konstrukcjach opiera się na algebrze relacji. — 1983: ISO** – definicja SQL
— Aplikacje sięgają do bazy danych za pomocą SQL w dwóch — 1986: ANSI – pierwszy standard SQL (SQL-86)
trybach: — 1987: ISO – pierwszy standard SQL (ISO 9075)
» Wykonane są w językach (np. C, Cobol, Pascal) — SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008,
rozszerzonych o możliwość łączenia z SQL (embedded SQL)
— SQL:2011 [ISO/IEC 9075:2011] (siódma wersja)
» Korzystają ze specjalnego interfejsu (np. ODBC/JDBC), który
pozwala wysyłać do bazy zapytania sformułowane w SQL. — SQL:2016 - Adds row pattern matching, polymorphic table functions, JSON.
*American National Standards Committee

**International Standards Organisation
Elementy SQL: Osadzony SQL
— DDL (Data Definition Language) – tworzenie, usuwanie i — Standard SQL definiuje również zasady osadzania (embedded)
modyfikacja schematów, kluczy, indeksów, widoków, SQL w językach programowania, takich jak C++, Java itd.
warunków integralności i praw dostępu, a także fizyczną
strukturę pamięci dyskowej (CREATE, DROP, ALTER) — Język, w którym osadzono SQL nazywany jest host language a
struktury SQL dozwolone w tym języku tworzą osadzony SQL.
— DML (Data Manipulation Language) – język zapytań oparty na — <struktura-osadzonego-SQL> wykorzystuje w ogólnym
algebrze relacji obejmujący ponadto polecenia dodające, przypadku pełne możliwości SQL uzupełnione o pewne
usuwające i aktualizujące dane w bazie danych (SELECT, elementy wynikające z osadzenia.
INSERT, DELETE, UPDATE)
— Aktualnie rzadko stosowany -> komunikacja poprzez ODBC lub
— Kontrola transakcji – SQL obejmuje polecenia rozpoczęcia i interfejsy wyższego poziomu
zakończenia transakcji, a także blokowania danych dla
współbieżnych operacji (START TRANSACTION, COMMIT,
ROLLBACK etc.)
1
4/10/2017
Inne Zalety SQL Hierarchia obiektów w SQL
— Języki czwartej generacji - specjalne języki pomagające programistom w

tworzeniu wzorców dla dialogu z użytkownikiem i w formatowaniu danych
dla raportów, dostępne dla większości komercyjnych baz danych (PL/SQL).
— Sesja SQL - dostarcza abstrakcji klienta i serwera (także zdalnego):
SCHEMATY
» klient łączy (connect) się z serwerem SQL nawiązując sesję;
TABELE
» wykonuje serię poleceń;
I PERSPEKTYWY
» rozłącza się od sesji (disconnect);
KOLUMNY
» może zapisać (commit) albo wycofać (rollback) pracę wykonaną w I WIERSZE
sesji.
— Środowisko SQL zawiera kilka komponentów między innymi identyfikator
użytkownika i bazy danych, które pozwalają zidentyfikować którą z kilku
baz danych używa dana sesja.
Schematy Schematy
— Schemat jest nadrzędną jednostką organizacji bazy — Tworzenie schematu

danych CREATE SCHEMA nazwa_schematu
AUTHORIZATION ID_wlasciciela
— Schemat tworzy grupę powiązanych obiektów. Jest
realizowany za pomocą instrukcji: CREATE SCHEMA magazyn AUTHORIZATION dbo
CREATE SCHEMA nazwa_schematu
ciąg instrukcji CREATE TABLE, CREATE VIEW i GRANT
(bez rozdzielających średników); — Określanie używanego schematu
SET SCHEMA nazwa_schematu
SET SCHEMA magazyn
Domeny Typy danych w MySQL (1)
— Standard SQL dopuszcza tworzenie własnych zbiorów — CHAR(n) – skończonej długości łańcuch znakowy, z podaną przez
dopuszczalnych wartości pewnych kolumn w tabelach użytkownika długością n
(dziedzin atrybutów) — VARCHAR(n) – zmiennej długości łańcuch znakowy, z podaną przez
użytkownika maksymalną długością n
CREATE DOMAIN nazwa_domeny AS typ_danych — TEXT – typ znakowy różniący się od CHAR i VARCHAR długością, nie może
posiadać wartości DEFAULT
DEFAULT wartosc_domyslna
CHECK warunek_kontrolny — INT(n), INTEGER(n) – liczba całkowita o podanej długości
— BOOL, BOOLEAN – równoważne typowi TINYINT(1), mogą posiadać
CREATE DOMAIN kontrola AS CHAR(1) wartość 1 lub 0 rozumiane odpowiednio jako TRUE lub FALSE
DEFAULT ‘T’ — DATE - daty zawierające rok (4-cyfrowy), miesiąc i dzień
CHECK(UPPER(VALUE) = ‘T’ OR UPPER(VALUE)=‘N’) (w formacie YYYY-MM-DD)
— TIME - czas w godzinach, minutach i sekundach
— DATETIME – kombinacja DATE i TIME (np.: 9999-12-31 23:59:59)
2
4/10/2017
Typy danych w MySQL (2) Obsługa wartości NULL
— FLOAT – mała liczba rzeczywista, zmiennoprzecinkowa — wartość NULL nie może być umieszczona w kolumnie
— DOUBLE(length, decimal) – duża liczba rzeczywista, zmiennoprzecinkowa
NOT NULL,
— DECIMAL(length, decimal)– liczba typu DOUBLE przechowywana w postaci — porównywanie dwóch kolumn zawierających NULL
łańcucha co pozwala na zastosowanie stałej liczby miejsc po przecinku jest nieskuteczne (wartości NULL można identyfikować
— SERIAL - jest aliasem dla w klauzuli WHERE przy użyciu wyrażeń IS NULL IS NOT
‘BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE’ NULL)
— SERIAL DEFAULT VALUE jako atrybut pola typu integer (od TINYINT do — kolumna zawierająca NULL jest ignorowana podczas
BIGINT) jest aliasem dla NOT NULL AUTO_INCREMENT obliczania wartości agregujących natomiast jest
— Wartości NULL dozwolone są we wszystkich typach. Deklarując atrybut ze uwzględniana w klauzuli GROUP BY
specyfikatorem NOT NULL, zabrania się wpisywania wartości NULL dla tego
atrybutu. — jeżeli w warunku złączenia pojawi się kolumna z
wartościami NULL to złączenie traktowane jest jako
zewnętrzne
Konstrukcja tabeli Przykład:
— Relacja (tabela) w SQL jest definiowana za pomocą polecenia postaci:

CREATE TABLE pracownicy (
CREATE TABLE nazwa_tabeli pesel CHAR(11) NOT NULL,

(A1 D1, A2 D2,..., An Dn,
[warunki-integralności]);
imie VARCHAR(15) NOT NULL,
» Każde Ai jest nazwą atrybutu w schemacie relacji. nazwisko VARCHAR(40) NOT NULL,
» Każde Di określa dziedzinę atrybutu Ai przez podanie typu danych tytul VARCHAR(10),
opisujących atrybut być może ze specyfikatorem NOT NULL
PRIMARY KEY (pesel),
— [warunki-integralności] mogą przyjmować postaci:
CHECK tytul IN (SELECT tytul-nazwa FROM tytuly));
» PRIMARY KEY (A1, ...,An) – definicja klucza zgodnie z zasadami.
» CHECK ( P) gdzie P jest predykatem akceptowalnym w klauzuli WHERE
zapytania SQL. Ograniczenie można zadać poprzez zdefiniowanie warunku logicznego, w tym
także takiego, które sięga do innych tabel lub poprzez standardowego
ograniczenia: NOT NULL lub UNIQUE
Integralność danych w SQL
— Wprowadzenie kluczy podstawowych i obcych

zapewnia automatyczną kontrolę poprawności
struktury danych i operacji przetwarzania danych
— Klucz podstawowy zapewnia unikalność i możliwość
identyfikacji każdego zapisu
— Klucze obce zapewniają integrację referencyjną
głoszącą, że każda niepusta wartość klucza obcego
musi odpowiadać jednej z istniejących wartości
klucza podstawowego
3
4/10/2017
Klucz podstawowy Klucz podstawowy w definicji i zmianie tabeli
— W tablicach rodzicach (parent) jest niezbędny jako łącznik z

CREATE TABLE Towary (
tablicami dziećmi (child)
IdTowaru Int NOT NULL AUTO_INCREMENT,
— Najlepiej rolę tą spełnia klucz, który jest kolumną tożsamości NazwaTowaru Char(50),
(identity) PRIMARY KEY (IdTowaru);
ALTER TABLE Towary DROP PRIMARY KEY;
ALTER TABLE Towary ADD PRIMARY KEY (IdTowaru);
Klucze obce
—W związkach nieidentyfikujących pozwalają na CREATE TABLE Klient (

tworzenie złączeń (nie jest do tego konieczne IdKlienta Int NOT NULL AUTO_INCREMENT,
NazwaKlienta Char(50),
wymuszanie integralności) Adres Char(50),
—W związkach identyfikujących pozwalają na kontrolę PRIMARY KEY (IdKlienta));
unikalności krotek w relacjach dzieciach
— FOREIGN KEY znany jako klucz obcy to pewnego rodzaju CREATE TABLE Zamowienie (
odnośnik łączący tabelę w którym występuje klucz obcy z inną IdZamowienia Int NOT NULL AUTO_INCREMENT,
tabelą. Klucz obcy zapobiega wszelkim operacjom, które DataZamowienia Date,
mogłyby zerwać taką więź między tabelami. NrZamowienia Char(20),
IdKlienta Int,
PRIMARY KEY (IdZamowienia));
Złączenie naturalne Złożony klucz obcy
CREATE TABLE JednostkiMiary (

IdJednostki Int NOT NULL AUTO_INCREMENT,
JednostkaMiary Char(20),
PRIMARY KEY (IdJednostki));
CREATE TABLE Specyfikacja (

IdZamowienia Int NOT NULL,
IdTowaru Int NOT NULL,
IdJednostki Int NOT NULL,
Ilosc Float,
PRIMARY KEY (IdZamowienia,IdTowaru,IdJednostki));
4
4/10/2017
Wymuszanie integralności
— REFERENCES – podaje źródło klucza obcego, tj. tabelę i klucz

podstawowy
— ON DELETE, ON UPDATE – określenie czynności, które należy
podjąć jeśli wartość klucza podstawowego zostanie usunięta
lub ulegnie zmianie:
» SET NULL zastąp wartość klucza obcego przez NULL,
» SET DEFAULT zastąp wartość klucza obcego przez wartość
domyślną,
» CASCADE skasuj lub zmodyfikuj wszystkie wiersze
próba wprowadzenia zawierające zmienianą wartość klucza obcego
identycznego klucza
» NO ACTION (tylko modyfikacja) nie zmieniaj wartości
klucza
» RESTRICT nie dopuść do zmiany
Zabronione usuwanie w MySQL
ALTER TABLE Zamowienie ADD FOREIGN KEY (IdKlienta)

REFERENCES Klient (IdKlienta) ON DELETE RESTRICT
ON UPDATE RESTRICT;
DELETE FROM `klient` WHERE ÌdKlienta` =1 LIMIT 1
#1217 - Cannot delete a parent row: a foreign key

constraint fails
Kaskadowa aktualizacja w MySQL
ALTER TABLE Zamowienie ADD FOREIGN KEY (IdKlienta)

REFERENCES Klient(IdKlienta)
ON DELETE CASCADE ON UPDATE CASCADE;
DELETE FROM `klient` WHERE ÌdKlienta` =1
5
4/10/2017
Porządkowanie kluczy w MySQL
— Zmiana wartości klucza w tabeli rodzicielskiej

powoduje odpowiednie zmiany w tabelach dzieciach
UPDATE `klient` SET ÌdKlienta` = '8‘ WHERE

ÌdKlienta` =10;
Kaskadowa aktualizacja w MS Access Indeksy
— Indeks jest strukturą danych umożliwiającą szybki dostęp do

krotek pewnej tabeli według jednej lub kilku kolumn
— Indeks zawiera kopie wybranych wartości kolumn ze związanej
tabeli uszeregowane, tak by łatwiej było ją przeszukiwać
CREATE [UNIQUE] INDEX nazwa_indeksu

ON nazwa_tabeli (nazwy_kolumn_klucza)
CREATE UNIQUE INDEX symbol_nazwa_towaru
ON towar (symbol_towaru, nazwa_towaru)
Indeksy Modyfikacja schematu bazy (1)

— Polecenie ALTER wykonuje następujące operacje:
— Czas trwania prostego wyszukiwania w tabeli zawierającej » dodaje kolumny i warunki
161 016 rekordy z indeksem i bez indeksu » modyfikuje definicje kolumn jak typy i warunki
» usuwa warunki
— ALTER TABLE nazwa_tabeli ADD Ai Di
jest używane do dodawania atrybutów do istniejącej relacji (tabeli). Ai jest
nazwą atrybutu dodawanego do relacji nazwa_tabeli, a Di jest
specyfikacją typu Ai. Wszystkie krotki relacji uzyskują dla nowego atrybutu
wartość NULL.
— ALTER TABLE nazwa_tabeli DROP Ai
może być użyta do usunięcia atrybutu Ai relacji (tablicy) nazwa_tabeli
— Przykłady:
ALTER TABLE pracownicy ADD (placa DECIMAL(7, 2))
ALTER TABLE pracownicy MODIFY (placa DECIMAL(9, 2))
6
4/10/2017
Modyfikacja schematu bazy (2) Widoki (perspektywy)
— DROP TABLE tabela1, tabela2 — W większości przypadków pokazywanie wszystkich danych bazy wszystkim
Usuwa relacje (tabele) tabela1, tabela2 z bazy danych użytkownikom jest niepożądane. Również różni użytkownicy wymagają
prezentacji danych w różny sposób.
— RENAME TABLE tabela1 TO tabela1
» Np. Klient może być mieć dostęp do informacji o numerze konta
Polecenie służące do zmiany nazwy jednej lub więcej tabel innego klienta, ale nie może zobaczyć stanu tego konta.
— Przykłady: — Relację, która nie jest składową modelu bazy danych, ale jest
prezentowana użytkownikom, nazywa się widokiem (view).
CREATE TABLE new_table (...);
— Dla utworzenia widoku używa się polecenia postaci:
RENAME TABLE old_table TO backup_table,
CREATE VIEW nazwa_widoku AS <podzapytanie>
new_table TO old_table;
gdzie <podzapytanie> jest dowolną konstrukcją select-from-where.
— Po zdefiniowaniu widoku można się do niego odwoływać w zapytaniach jak
RENAME TABLE current_database.table_name
do normalnej relacji.
TO other_database.table_name;
Perspektywy (ang. Views) Po co widoki?
— W bazie zapamiętane zostaną tylko definicje poszczególnych kolumn

— Zapytanie posiadające własną nazwę i przechowywane w widoków, nie zaś wartości. Różni użytkownicy bazy chcą/mogą/powinni
słowniku danych mieć różny dostęp do tych samych danych źródłowych.
— Perspektywy tworzymy po to by:
» zapisać często wykonywane złożone zapytania
» stworzyć logiczne modele dla różnych użytkowników
» zwiększyć bezpieczeństwo danych
Tworzenie perspektyw Wykorzystanie perspektyw
CREATE VIEW PodgladZamowienia SELECT NazwaKlienta, NazwaTowaru, Ilosc, Cena

SELECT Klient.NazwaKlienta, Zamowienie.NrZamowienia, FROM PodgladZamowienia
Zamowienie.datazamowienia, Towar.NazwaTowaru, LiniaZamowienia.Ilosc, WHERE (NazwaKlienta = 'FH Klin SA')
LiniaZamowienia.Cena
FROM Zamowienie INNER JOIN
Klient ON Zamowienie.IdKlienta = Klient.IdKlienta INNER JOIN
LiniaZamowienia ON Zamowienie.IdZamowienia = +--------------+---------------------------+--------+--------+
LiniaZamowienia.IdZamowienia INNER JOIN | Nazwaklienta | NazwaTowaru | Ilosc | cena |
Towar ON LiniaZamowienia.IdTowaru = Towar.IdTowaru +--------------+---------------------------+--------+--------+
| FH Klin SA | Rura zgrz. fi 6,3 gr 0,2 | 20 | 1.50 |
+--------------+---------------------------+--------+--------+
7
4/10/2017
Modyfikowalność perspektyw Modyfikacja danych (1)
— Zgodnie ze standardem SQL-92 można modyfikować wyłącznie — Modyfikacja bazy danych przez ich usunięcie może być zrealizowana w SQL
za pomocą polecenia postaci:
takie perspektywy, które:
DELETE FROM <relacja> WHERE <warunek>
» nie zawierają złączeń, — Można zatem usuwać jedynie całe krotki, dla których prawdziwy jest
<warunek> , oraz jednokrotnie tylko z jednej <relacja> (tabeli).
» są pojedyncze (np. unie nie są dopuszczalne),
— Opuszczenie klauzuli WHERE skutkuje usunięciem danych z całej tabeli.
» nie mogą być oparte na zapytaniu grupującym lub
— Wykonanie DELETE przebiega w dwóch fazach: najpierw realizowany jest
zawierającym słowo DISTINCT, wybór wszystkich krotek, a następnie ich usuwanie.
» nie można modyfikować kolumn wyliczonych Usuń pracowników z wynagrodzeniem równym zero.
DELETE FROM pracownicy
WHERE placa = 0;
— <warunek> może mieć formę dowolną akceptowaną przez klauzulę WHERE
w zapytaniach, w tym może zawierać podzapytania.
Modyfikacja danych (2) Wstawianie wierszy
— Modyfikacja bazy danych przez ich dodanie może być zrealizowana w SQL INSERT INTO Klient
za pomocą poleceń postaci: (NazwaKlienta, Telefon, KodPocztowy, Miejscowosc, Ulica,
NrDomuMieszkania, Email)
INSERT INTO <relacja> VALUES <krotka> VALUES('Nowy klient', '48 12 1234567', '30-333', 'Bolechowice',
INSERT INTO <relacja> VALUES <relacja-wstawiana> 'Jurajska', '20','ala@tlen.pl')
— Można zatem dodawać jedynie całe krotki oraz jednokrotnie tylko do
jednej relacji (tabeli). Zachowany być musi schemat relacji i domeny +-----------+-------------------+---------------+
atrybutów. | IdKlienta | NazwaKlienta | Telefon |
— O ile to jest dopuszczone <krotka> może zawierać wartości NULL. +-----------+-------------------+---------------+
| 3 | STALHANDEL | 48 32 7865748 |
Dodaj nową krotkę do relacji pracownicy z wynagrodzeniem ustawionym na NULL | 2 | Firma Krok Sp zoo | 48 12 6374532 |
INSERT INTO pracownicy (pesel, nazwisko, imie, placa) | 5 | PHPU OSA | 48 12 6372312 |
VALUES (‘99999900000’, ‘Regulski’, ‘Krzysztof’,’104BT’,NULL) | 4 | Rower Polska SA | 48 12 2853364 |
INSERT INTO pracownicy VALUES (‘99999900000’, ‘Regulski’, | 1 | FH Klin SA | 48 12 1273210 |
‘Krzysztof’,’104BT’,NULL) | 6 | Nowy klient | 48 12 1234567 |
+-----------+-------------------+---------------+
— Formę z values stosować można również do widoków.
Modyfikacja danych (3) Tabele tymczasowe
— Modyfikacja bazy danych przez zmianę wartości atrybutów może być — istnieją wyłącznie w trakcie trwania sesji
zrealizowana w SQL za pomocą polecenia postaci:
— obsługuje się je identycznie jak tabele stałe
UPDATE <relacja> SET <modyfikacja> WHERE <warunek>
— są znacznie szybciej obsługiwane niż zapytania czy
— Można modyfikować jeden atrybut krotek, dla których prawdziwy jest perspektywy ale nie są automatycznie modyfikowane
<warunek> oraz jednokrotnie tylko z jednej <relacja> (tabeli).
— w przeciwieństwie do widoków są w pełni modyfikowalne
— <modyfikacja> jest wyrażeniem arytmetycznym (akceptowalnym w
klauzuli SELECT), przypisującym (=) nową wartość atrybutowi.
— Opuszczenie klauzuli WHERE skutkuje modyfikacją całej tabeli.
Podnieś wynagrodzenie Regulskiemu o 30%

UPDATE pracownicy
SET placa=placa*1.3
WHERE nazwisko LIKE ‘Regulski’;
8
4/10/2017
Edycja złożenia
— Edycja złożenia i perspektywy zawierającej elementy

pochodzące z więcej iż jednej tabeli nie jest możliwa wprost
— Można natomiast stworzyć tabelę tymczasową zawierającą
kody i treść atrybutów z połączonych tabel i ją edytować
Tworzenie tabeli tymczasowej w MS SQL Przenoszenie złożenia to tabeli
INSERT INTO #tmp

SELECT dbo.ds_Asortymenty.NazwaAsortymentu,
dbo.ds_SlownikCech.WartoscSlownikowa, dbo.tch_ListaProduktow.Wymiar1,
dbo.tch_ListaProduktow.Wymiar2,
dbo.tch_ListaProduktow.Wymiar3, dbo.ds_SlownikCech.IdSlownikaCech,
CREATE TABLE #tmp ( dbo.tch_ListaProduktow.IdProduktu
NazwaAsortymentu char(255),
WartoscSlownikowa char(255), FROM dbo.tch_ListaProduktow INNER JOIN
dbo.ds_SlownikCech ON dbo.tch_ListaProduktow.CechaTekstowa1 =
IdSlownikaCech bigint; dbo.ds_SlownikCech.IdSlownikaCech INNER JOIN
Wymiar1 float, dbo.ds_Asortymenty ON dbo.tch_ListaProduktow.IdAsortymentu =
Wymiar2 float, dbo.ds_Asortymenty.IdAsortymentu;
wymiar3 float);
Edycja tabeli tymczasowej
— W tabeli możemy zmienić dane posługując się nazwami DECLARE @indeks bigint;
pochodzącymi w systemie z różnych tabel
SELECT @indeks= dbo.ds_SlownikCech.IdSlownikaCech
— Po edycji można odtworzyć tabele źródłowe FROM dbo.ds_SlownikCech
WHERE dbo.ds_SlownikCech.WartoscSlownikowa='eliptyczna';
UPDATE #tmp SET IdSlownikaCech=@indeks, WartoscSlownikowa='eliptyczna'

WHERE NazwaAsortymentu='Rura profilowa' AND
WartoscSlownikowa='kroplowa';
UPDATE dbo.tch_ListaProduktow SET CechaTekstowa1=t.IdSlownikaCech

FROM #tmp t WHERE dbo.tch_ListaProduktow.IdProduktu=t.IdProduktu;
9
4/10/2017
Przyznawanie praw dostępu
— Serwer baz danych może obsługiwać wielu użytkowników

identyfikowanych przez nazwę i hasło
— Nie każdy z użytkowników musi mieć równe prawa
— W momencie utworzenia nowego elementu bazy danych
aktualny użytkownik staje się jego właścicielem
— Właściciel może nadawać i odbierać prawa innym
użytkownikom
Przyznawanie praw dostępu składnia SQL99 Przykład MySQL
GRANT {ALL [PRIVILEGES] } — Aktualny użytkownik, posiadający wszelkie uprawnienia

| SELECT
| INSERT [ nazwa_kolumny [,...n]) ]
przekazuje część uprawnień użytkownikowi andrzej na
| DELETE serwerze localhost
| UPDATE [ nazwa_kolumny [,...n]) ]
| REFERENCES [ nazwa_kolumny [,...n]) ]
— Następnie odbiera mu wszelkie uprawnienia i przekazuje inne
| USAGE } [,...n]
ON { [TABLE] nazwa_tabeli
| DOMAIN nazwa_domeny
| COLLATION nazwa_zestawienia
CHARACTER SET nazwa_zestawu_znaków
| TRANSLATION nazwa_translacji }
TO {nazwa_podmiotu | PUBLIC}
[WITH GRANT OPTION]
Użytkownik ma prawa do edycji danych, nie może jednak zmieniać struktur bazy danych
haslo
GRANT CREATE , DROP , INDEX , ALTER , CREATE REVOKE ALL PRIVILEGES ON * . * FROM 'andrzej'@'localhost';
TEMPORARY TABLES ON * . * TO GRANT SELECT ,
'andrzej'@'localhost' IDENTIFIED BY '*****' WITH INSERT ,
UPDATE ,
MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 DELETE ,
MAX_UPDATES_PER_HOUR 0 ; RELOAD ,
SHUTDOWN ,
PROCESS ,
FILE ,
REFERENCES ,
SHOW DATABASES ,
SUPER ,
GRANT ALL PRIVILEGES ON `sprzedaz` . * TO LOCK TABLES ,
'andrzej'@'localhost' WITH GRANT OPTION ; EXECUTE ,
REPLICATION SLAVE ,
REPLICATION CLIENT ON * . * TO 'andrzej'@ 'localhost' WITH GRANT OPTION
MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 ;
10
4/10/2017
Transakcje
brak uprawnień do tworzenia tabeli

— W systemie baz danych z wieloma użytkownikami transakcja
jest niepodzielną, spójną, izolowaną i trwałą (ACID-atomic,
consistent, isolatable, and durable) procedurą realizującą
dostęp do danych
są uprawnienia do aktualizacji
tabeli — Podczas realizacji transakcji możliwe jest wykorzystanie
zmiennych oraz blokowanie dostępu do danych
— Transakcje mogą być wycofane
Transakcje składnia Transakcje w MS SQL
START (BEGIN) TRANSACTION; — Użycie tabeli w trakcie transakcji blokuje dostęp do tabeli
polecenia — Polecenie ROLLBACK kasuje działania wykonane podczas
transakcji
COMMIT – zatwierdzenie transakcji
— Polecenie COMMIT zatwierdza działania
lub
ROLLBACK – wycofanie transakcji
Transakcje w MySQL
— Potwierdzanie lub wycofywanie transakcji możliwe jest tylko w

przypadku użycia mechanizmu obsługi pamięci InnoDB
BEGIN TRANSACTION;
UPDATE tch_ListaProduktow
SET CechaTekstowa1 = 4
WHERE (IdProduktu = 2944);
ROLLBACK;
BEGIN TRANSACTION;
UPDATE tch_ListaProduktow
SET CechaTekstowa1 = 4
WHERE (IdProduktu = 2944);
COMMIT;
11
4/10/2017
Procedury składowane
CREATE PROCEDURE procedura

— Specyficzny język umożliwiający wykonywanie wielu poleceń @Asortyment char(255),
@Cecha char(255)
SQL oraz wprowadzający dynamikę AS
SELECT dbo.ds_Asortymenty.NazwaAsortymentu, dbo.ds_SlownikCech.WartoscSlownikowa,
dbo.tch_ListaProduktow.Wymiar1,
dbo.tch_ListaProduktow.Wymiar2, dbo.tch_ListaProduktow.Wymiar3,
dbo.ds_SlownikCech.IdSlownikaCech,
dbo.tch_ListaProduktow.IdProduktu
FROM dbo.tch_ListaProduktow INNER JOIN
dbo.ds_SlownikCech ON dbo.tch_ListaProduktow.CechaTekstowa1 =
dbo.ds_SlownikCech.IdSlownikaCech INNER JOIN
dbo.ds_Asortymenty ON dbo.tch_ListaProduktow.IdAsortymentu =
dbo.ds_Asortymenty.IdAsortymentu
WHERE ds_Asortymenty.NazwaAsortymentu=@asortyment AND
dbo.ds_SlownikCech.WartoscSlownikowa=@Cecha
GO
Wyzwalacze w SQL 99
— wyzwalacz (ang. trigger) jest specjalnym rodzajem składowanej procedury,

która jest uruchamiana automatycznie podczas wykonywania instrukcji
modyfikacji danych
— wyzwalacz jest powiązany z konkretną instrukcją modyfikacji danych
(INSERT, UPDATE, DELETE)
— wyzwalacz jest uruchamiany przed modyfikacją, po lub zamiast modyfikacji
Wyzwalacze SQL 99 Wyzwalacze SQL 99
CREATE TRIGGER nazwa_wyzwalacza CREATE TRIGGER dopisanie_rekordu

{ BEFORE | AFTER } { [DELETE] | [NSERT] [UPDATE] [OF kolumna INSTEAD OF INSERT SymbolTowaru, NazwaTowaru ON Towar
[,...n]} REFERENCING
ON nazwa_tabeli OLD AS StaraKrotka
[REFERENCING {OLD [ROW] [AS] nazwa_starej_krotki | NEW [ROW] NEW AS NowaKrotka
[AS] nazwa_nowej_krotki OLD TABLE [AS] nazwa_starej_tabeli | OLD_TABLE Stare
NEW TABLE [AS] nazwa_nowej_tabeli}] WHEN NowaKrotka.NazwaTowaru IN
{FOR EACH {ROW | STATEMENT}] Stare;
[WHEN (warunki)] UPDATE Towar
blok_kodu SET NazwaTowaru = StaraKrotka.NazwaTowaru;
12
4/10/2017
Wyzwalacz w MS SQL Wyzwalacz w MS SQL
USE test
DROP TRIGGER uwaga
GO
CREATE TRIGGER uwaga
ON Przedmioty
AFTER INSERT, UPDATE
AS RAISERROR ('Nie wolno dopisywaæ danych', 16,
10)
GO
Archiwacja w MS SQL Stan wyjściowy
ds-asortymenty
CREATE TRIGGER archiwacja ON ds_asortymenty
FOR DELETE
AS
INSERT INTO ds_asortymenty_arch
SELECT *
FROM deleted
Efekt usuwania Inne narzędzia proceduralne
DELETE FROM ds_asortymenty WHERE IdAsortymentu<4 — języki czwartej generacji 4GL

— graficzne interfejsy użytkownika GUI (Graphical User Interface)
ds-asortymenty
— interfejsy typu QBE (Qery By Example)
— interfejsy języka naturalnego
— osadzony SQL
— interfejsy programów użytkowych API (application
programming interface)
ds_asortymenty_arch
13
4/10/2017
Języki 4GL
/* h-CustSample.p— shows a few things about the Progress 4GL */

— generatory oparte na formularzach DEFINE VARIABLE cMonthList AS CHARACTER NO-UNDO
INIT "JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC".
DEFINE VARIABLE iDays AS INTEGER NO-UNDO. /* used in calcDays proc */
— wysokiego poziomu języki proceduralne /* First display each Customer from New Hampshire: */
FOR EACH Customer WHERE state = "NH" BY City:
DISPLAY CustNum NAME City.
— przykłady: /* Show the Orders unless the Credit Limit is less than
twice the balance. */
IF CreditLimit < 2 * Balance THEN
» PL/SQL firmy ORACLE DISPLAY "Credit Ratio:" CreditLimit / Balance .
ELSE FOR EACH Order OF Customer:
DISPLAY OrderNum LABEL "Order"
» Progress 4GL OrderDate ShipDate FORMAT "99/99/99" WITH CENTERED.
/* Show the month as a three-letter abbreviation, along with the
number of days since the order was shipped. */
IF ShipDate NE ? THEN
DISPLAY ENTRY(MONTH(ShipDate), cMonthList) LABEL "Month".
RUN calcDays (INPUT ShipDate, OUTPUT iDays).
DISPLAY iDays LABEL "Days" FORMAT "ZZZ9".
END.
END.
PROCEDURE calcDays:
/* This calculates the number of days since the Order was shipped. */
DEFINE INPUT PARAMETER pdaShip AS DATE NO-UNDO.
DEFINE OUTPUT PARAMETER piDays AS INTEGER NO-UNDO.
piDays = IF pdaShip = ? THEN 0
ELSE TODAY - pdaShip.
END PROCEDURE.
14
4/10/2017
Bazy Danych Konstrukcja select-from-where
— SQL oparty jest na algebrze relacji z pewnymi modyfikacjami i

rozszerzeniami.
— Typowe zapytanie SQL ma postać:

SELECT A1,A2,..., Ak
SQL – Podstawy języka II: zapytania FROM r1, r2, ..., rm
WHERE P
ri oznaczają relacje w bazie danych.
Ai oznaczają atrybuty tych relacji.
Piotr Macioł
WIMiIP, KISiM, P jest predykatem.
pmaciol@agh.edu.pl
B5, pok. 606
— Wynikiem zapytania SQL jest relacja.

SELECT (1) Przykładowa tabela – dowody wydania Rw
— Klauzula SELECT jest używana do wskazania tych atrybutów

relacji określonych w klauzuli FROM, które są objęte DowodyWydania
zapytaniem. SymbolTo NazwaTowaru Magazyn Od- Data Ilosc J.m.
waru biorca
» Przykład: znajdź nazwy wszystkich oddziałów z relacji oddzialy
S0001 rura fi 0,63 gr 0,2 MWG01 HS 16.04.04 12 mb
SELECT nazwa_oddzialu S0025 rura fi 1,26 gr 0,3 MWG02 PP 12.04.04 80 mb
FROM oddzialy; S0001 rura fi 0,63 gr 0,2 MWG01 PP 12.04.04 15 mb

S1025 złączka MOZ01 ZP 03.04.04 100 szt.
S0025 rura fi 1,26 gr 0,3 MOZ01 ZP 03.04.04 20 mb
— Gwiazdka w klauzuli SELECT oznacza „wszystkie atrybuty relacji”
S0152 rura kw. 2 gr 0,2 MOP02 TT 01.04.04 1 mb
SELECT *
FROM oddzialy;
Przykład zapytania SELECT (2)
— SQL dopuszcza duplikaty zarówno w relacjach jak i rezultatach

SELECT * zapytań.
FROM DowodyWydania
— Dla wymuszenia eliminacji duplikatów wstawia się słowo
WHERE Magazyn = ‘MWG01’
kluczowe DISTINCT po SELECT.
Przykład: znajdź imiona wszystkich pracowników i usuń
SymbolTo NazwaTowaru Magazyn Od- Data Ilosc J.m. duplikaty
waru biorca
SELECT DISTINCT imie
S0001 rura fi 0,63 gr 0,2 MWG01 HS 16.04.04 12 mb FROM pracownicy;
S0001 rura fi 0,63 gr 0,2 MWG01 PP 12.04.04 15 mb
— Słowo kluczowe ALL oznacza, że duplikaty nie będą usuwane
SELECT ALL imie
FROM pracownicy;
1
4/10/2017
SELECT (3) SELECT (4)

— Polecenia SELECT można używać również nie odwołując się do żadnej
— Klauzula SELECT może zawierać wyrażenia arytmetyczne z tabeli w celu obliczania wyrażeń lub pracy na ciągach znaków lub
operatorami +, -, *, / operujące na stałych i atrybutach zmiennych:
krotek — Przykłady:
SELECT 1+1;
SELECT ‘ten napis pojawi sie na ekranie’;
— Zapytanie:
SELECT ‘slowa’, ‘w’, ‘osobnych’, ‘kolumnach’;
SELECT nazwisko, imie, placa + 100 SELECT @liczba1:=8 AS A, @liczba2:=2 AS B,

FROM pracownicy; @wynik:=@liczba1+@liczba2 AS 'WYNIK A+B';
+---+---+-----------+
| A | B | WYNIK A+B |
zwróci relację, w której atrybut placa będzie zwiększony o +---+---+-----------+
100. | 8 | 2 | 10 |
+---+---+-----------+
Klauzula WHERE (1) Klauzula WHERE (2)
— Klauzula WHERE składa się z warunków dotyczących atrybutów relacji z

klauzuli FROM. Umożliwia wyświetlanie wierszy, których kolumny spełniają
określony warunek. Pola objęte klauzurą WHERE nie muszą być na liście +----------------+
+-----------------------+
wyboru. | pracownicy |
+----------------+ | PRACOWNIK |
SELECT nazwisko, imie | pesel | +-----------------------+
FROM pracownicy | imie |
| Okowita Ambrozjowa |
| nazwisko |
WHERE placa > 100; | id_oddzialu | | Fableusz Kosonosy |
+----------------+ | Atanazy Angonilewicz |
— umożliwia łączenie tabel według rożnych kryteriów. zapytanie
| Kosmateusz Buler |
(1)
+----------------+ | Nikczemilian Wikrus |
SELECT CONCAT (pracownicy.imie, ‘ ‘, pracownicy.nazwisko) | oddzialy | | Krowimir Dojny |

+----------------+ | Inwertyk Dosiebski |
AS PRACOWNIK
zapytanie
| id_oddzialu |
FROM pracownicy, oddzialy +-----------------------+
(1)
| nazwa_oddzialu |
WHERE pracownicy.id_oddzialu=oddzialy.id_oddzialu +----------------+
AND oddzialy.nazwa_oddzialu LIKE ‘Betatrex’;
Operatory porównań Przykładowa tabela – towary
— SQL używa logicznych operatorów AND, OR i NOT, =, <, >, >=, <=, <>
— (NOT)BETWEEN .. AND kiedy specyfikuje się, że wartość ma zawierać się w określonym +----------+--------------+---------------------------+
przedziale zamkniętym | IdTowaru | SymbolTowaru | NazwaTowaru |
np..: WHERE cena BETWEEN ‘dolna_granica’ AND ‘górna_granica’ +----------+--------------+---------------------------+
| 1 | RZ001 | Rura zgrz. fi 6,3 gr 0,2 |
— (NOT) IN (e1, .., en) kiedy porównujemy do jednego z elementów zbioru
| 2 | RZ002 | Rura zgrz. fi 12,6 gr 0,2 |
np..: WHERE imie NOT IN (‘Stefan’, ‘Bożena’)
| 3 | RZ003 | Rura zgrz. fi 6,3 gr 0,3 |
— (NOT) LIKE kiedy porównujemy ciągi znaków do wzorca | 4 | RZ004 | Rura zgrz. fi 12,6 gr 0,3 |
Wyrażenia regularne: | 5 | RZ011 | Rura zgrz. kw 4 gr 0,2 |
% - dowolny ciąg znaków | 6 | RZ012 | Rura zgrz. kw 5 gr 0,3 |
| 7 | ZL001 | Złączka 1' |
_ (podkreślenie) - dowolny znak
| 8 | ZL002 | Złączka 2' |
[ck] - znak 'c' lub 'k'
+----------+--------------+---------------------------+
[c-k] - znak z zakresu od 'c' do 'k‘
[^c] - nie 'c'
— IS (NOT) NULL służy do sprawdzania, czy wartość w polu to NULL
2
4/10/2017
Przykład zapytania Łączenie relacji
— Operacje połączenia (JOIN) bierze dwie relacje i zwraca jako wynik inną
SELECT * relacje.
FROM `towar` — Te dodatkowe operacje są zazwyczaj używane jako polecenie podzapytania
WHERE SymbolTowaru LIKE 'R%' w klauzuli FROM.
— Warunki połączenia definiują, które krotki z dwóch relacji pasują i które
+----------+--------------+---------------------------+ atrybuty będą obecne jako wynik połączenia.
| IdTowaru | SymbolTowaru | NazwaTowaru |
+----------+--------------+---------------------------+ — Typ połączenia - definiuje jak będą traktowane takie krotki z
| 1 | RZ001 | Rura zgrz. fi 6,3 gr 0,2 | poszczególnych relacji, które nie pasują do krotek z drugiej relacji.
| 2 | RZ002 | Rura zgrz. fi 12,6 gr 0,2 | tabela1 [NATURAL|LEFT|RIGHT|INNER|OUTER] JOIN tabela2
| 3 | RZ003 | Rura zgrz. fi 6,3 gr 0,3 |
| 4 | RZ004 | Rura zgrz. fi 12,6 gr 0,3 | — Warunki łączenia:
| 5 | RZ011 | Rura zgrz. kw 4 gr 0,2 | NATURAL, ON <warunek_złączenia>, USING <lista_atrybutów>
| 6 | RZ012 | Rura zgrz. kw 5 gr 0,3 | — JOIN w większości przypadków może być zastąpione przez odpowiednie
+----------+--------------+---------------------------+ klauzule FROM i WHERE
Rzutowanie w SQL Warunki selekcji i porządkowanie
SELECT SymbolTowaru, NazwaTowaru

FROM `towar` SELECT NrZamowienia, DataZamowienia
WHERE SymbolTowaru LIKE 'R%' FROM Zamowienie
WHERE NrZamowienia LIKE '____2004' AND
DataZamowienia > '2004-04-04'
+--------------+---------------------------+ ORDER BY DataZamowienia DESC
| SymbolTowaru | NazwaTowaru |
+--------------+---------------------------+
| RZ001 | Rura zgrz. fi 6,3 gr 0,2 | +--------------+---------------------+
| RZ002 | Rura zgrz. fi 12,6 gr 0,2 | | NrZamowienia | DataZamowienia |
| RZ003 | Rura zgrz. fi 6,3 gr 0,3 | +--------------+---------------------+
| RZ004 | Rura zgrz. fi 12,6 gr 0,3 | | 005/2004 | 2004-04-07 00:00:00 |
| RZ011 | Rura zgrz. kw 4 gr 0,2 | | 003/2004 | 2004-04-06 00:00:00 |
| RZ012 | Rura zgrz. kw 5 gr 0,3 | | 004/2004 | 2004-04-06 00:00:00 |
+--------------+---------------------------+ | 002/2004 | 2004-04-05 00:00:00 |
+--------------+---------------------+
Rodzaje złączeń (1) Rodzaje złączeń (2)
Złączenie naturalne (NATURAL)

— złączenie wewnętrzne (INNER JOIN) – w relacji wynikowej występują
— polega na połączeniu w pary tych krotek z relacji R i S, które mają identyczne wyłącznie te krotki, które spełniają warunek złączenia
wartości dla wszystkich wspólnych atrybutów i jest oznaczane R S
— złączenie lewostronne zewnętrzne (LEFT OUTER JOIN) – zawiera
— w rezultacie powstaje relacja, której schemat zawiera atrybuty relacji R i relacji S, wszystkie krotki R uzupełnione krotkami S spełniającymi warunek
przy czym wspólna część uwzględniana jest tylko raz
— złączenie prawostronne zewnętrzne (RIGHT OUTER JOIN) - zawiera
Złączenie teta (ON <warunek_złączenia>) wszystkie krotki S uzupełnione krotkami R spełniającymi warunek
— polega na złączeniu dwóch relacji R i S w iloczyn kartezjański i wyborze z niego tych — złączenie zewnętrzne pełne (FULL OUTER JOIN) – zawiera wszystkie krotki
krotek, które spełniają wyrażenie warunkowe na parze lub zbiorze par atrybutów z R oraz S uzupełnione wartościami typu NULL gdy do danej krotki nie pasuje
R i S i jest oznaczane symbolem R ΘR lub R CS, gdzie Θ lub C to wyrażenia żadna krotka z drugiej relacji
logiczne
— złączenie wewnętrzne typu CROSS – w relacji wynikowej występują
Równozłączenie (USING <lista_atrybutów>) wszystkie krotki będące wynikiem iloczynu kartezjańskiego
— to szczególny przypadek złączenia teta, w którym warunek ma charakter równości — złączenie zewnętrzne typu UNION - zawiera wszystkie krotki R nie pasujące
wybranych atrybutów obu relacji do żadnej krotki S uzupełnione krotkami S nie pasującymi do żadnej krotki
— powtarzające się kolumny opisujące atrybuty z warunku złączenia są pomijane R
3
4/10/2017
Przykład – dane: Przykład:
— Relacja oddzialy:
+----------------+-----------------+
| id_oddzialu | nazwa_oddzialu |
SELECT oddzialy.nazwa_oddzialu, pracownicy.nazwisko
FROM (oddzialy INNER JOIN pracownicy
+----------------+-----------------+ ON oddzialy.id_oddzialu=pracownicy.id_oddzialu);
| L140 | Betatrex | +-----------------+-----------------+
| A4 | Alfatron | | nazwa_oddzialu | nazwisko |
+-----------------+-----------------+
| B340 | Tetrix | | Betatrex | Ambrozjowa |
+----------------+-----------------+ | Betatrex | Kosonosy |
| Alfatron | Angonilewicz |
— Relacja pracownicy: +-----------------+-----------------+
+----------------+-----------------+-----------------+----------------+ SELECT oddzialy.nazwa_oddzialu, pracownicy.nazwisko

| pesel | imie | nazwisko | id_oddzialu | FROM (oddzialy LEFT OUTER JOIN pracownicy
+----------------+-----------------+-----------------+----------------+ ON oddzialy.id_oddzialu=pracownicy.id_oddzialu);
| 75102406713 | Okowita | Ambrozjowa | L140 | +-----------------+-----------------+
| nazwa_oddzialu | nazwisko |
| 54032204567 | Fableusz | Kosonosy | L140 | +-----------------+-----------------+
| 56123099087 | Atanazy | Angonilewicz | A4 | | Betatrex | Ambrozjowa |
| Betatrex | Kosonosy |
+----------------+-----------------+-----------------+----------------+ | Alfatron | Angonilewicz |
| Tetrix | NULL |
+-----------------+-----------------+
Aliasy Sortowanie wyników
— Możliwe jest używanie aliasów nazw kolumn i nazw tabel. — Sortowanie wyników osiąga się dzięki klauzuli ORDER BY.
Umożliwiają one: Sortowanie odbywa się kolejno według wartości atrybutów
wymienionych w klauzuli.
» zmianę nazwy kolumny wyświetlanej
— Dla każdego z atrybutów można podać specyfikator DESC dla
» nadanie nazwy kolumnie będącej wynikiem wyrażenia lub
porządku malejącego lub ASC dla porządku rosnącego.
stałą
Porządek rosnący jest domyślny.
SELECT
@liczba1:=8 AS A, — Ponieważ sortowanie dużej ilości krotek jest kosztowne,
@liczba2:=2 AS B,
@wynik:=@liczba1+@liczba2 AS 'WYNIK A+B'; wskazane jest wykonywanie sortowania tylko wtedy, gdy jest
to niezbędne.
+---+---+-----------+
| A | B | WYNIK A+B |
+---+---+-----------+
| 8 | 2 | 10 |
SELECT nazwisko, imie
+---+---+-----------+ FROM pracownicy
ORDER BY nazwisko DESC, imie DESC;
Operacje teoriomnogościowe Przykładowe dane
— Operacje UNION, INTERSECT oraz EXCEPT odpowiadają kolejno

następującym operatorom algebry relacyjnej: ,  i  przy czym zachodzi:
IdKlienta NazwaKlienta Telefon KodPocztowy
r  s = r – (r – s) 1 FH Klin SA 48 12 1273210 30-121
2 Firma Krok Sp zoo 48 12 6374532 30-321
— Każda z operacji automatycznie eliminuje duplikaty; dla zachowania 3 STALHANDEL 48 32 7865748 34-876
duplikatów stosuje się wersje UNION ALL, INTERSECT ALL oraz EXCEPT 4 Rower Polska SA 48 12 2853364 32-082
ALL.
IdBankuIdKlienta NrKonta
(SELECT nazwa_firmy FROM dostawcy) (SELECT nazwa_firmy FROM dostawcy)
UNION INTERSECT 1 1 12345678901234567892022222
(SELECT nazwa FROM klienci); (SELECT nazwa FROM klienci); 2 1 43527897963543645632726336
3 2 46748329374637843254632546
1 2 78789798979879879877878978
(SELECT nazwa_firmy FROM dostawcy)
EXCEPT
1 3 98087079643906432786443324
(SELECT nazwa FROM klienci); 2 3 67876864376438209876473674
3 4 67686868768348364836483764
4
4/10/2017
Iloczyn kartezjański Złączenie naturalne
NazwaKlienta NrKonta SELECT NazwaKlienta, NrKonta

SELECT NazwaKlienta, NrKonta FH Klin SA 78789798979879879877878978
FH Klin SA 43527897963543645632726336 FROM Klient ,Konto
FROM Klient, Konto FH Klin SA 67686868768348364836483764
FH Klin SA 46748329374637843254632546 WHERE Klient.IdKlienta = Konto.IdKlienta
ORDER BY NazwaKlienta FH Klin SA
FH Klin SA
67876864376438209876473674
12345678901234567892022222
ORDER BY NazwaKlienta
FH Klin SA 98087079643906432786443324
Firma Krok Sp zoo 12345678901234567892022222
Firma Krok Sp zoo 43527897963543645632726336
Firma Krok Sp zoo 46748329374637843254632546 SELECT NazwaKlienta, NrKonta
Firma Krok Sp zoo 78789798979879879877878978
Firma Krok Sp zoo 67876864376438209876473674 FROM Klient JOIN Konto USING (IdKlienta)
Firma Krok Sp zoo
Firma Krok Sp zoo
67686868768348364836483764
98087079643906432786443324
ORDER BY NazwaKlienta
Rower Polska SA 12345678901234567892022222
Rower Polska SA 67876864376438209876473674 NazwaKlienta NrKonta
Rower Polska SA 43527897963543645632726336
Rower Polska SA 46748329374637843254632546 FH Klin SA 12345678901234567892022222
Rower Polska SA 98087079643906432786443324
Rower Polska SA 67686868768348364836483764 FH Klin SA 43527897963543645632726336
Rower Polska SA
STALHANDEL
78789798979879879877878978
46748329374637843254632546
Firma Krok Sp zoo 46748329374637843254632546
STALHANDEL 78789798979879879877878978 Firma Krok Sp zoo 78789798979879879877878978
STALHANDEL 43527897963543645632726336
STALHANDEL 98087079643906432786443324 STALHANDEL 98087079643906432786443324
STALHANDEL 12345678901234567892022222
STALHANDEL 67686868768348364836483764 STALHANDEL 67876864376438209876473674
STALHANDEL 67876864376438209876473674
Rower Polska SA 67686868768348364836483764
Złączenie naturalne – trzy tabele Złączenie naturalne – trzy tabele
SELECT NazwaKlienta, NrKonta, NazwaBanku

FROM Klient JOIN Konto USING (IdKlienta) JOIN
Bank USING (IdBanku) NazwaKlienta NrKonta NazwaBanku
ORDER BY NazwaKlienta, NrKonta FH Klin SA 12345678901234567892022222 Bank BPH
FH Klin SA 43527897963543645632726336 Bank Polski
Firma Krok Sp zoo 46748329374637843254632546 Bank Niemiecki
Firma Krok Sp zoo 78789798979879879877878978 Bank BPH
SELECT NazwaKlienta, NrKonta, NazwaBanku Rower Polska SA 67686868768348364836483764 Bank Niemiecki
FROM Klient, Konto, Bank STALHANDEL 67876864376438209876473674 Bank Polski
WHERE Klient.IdKlienta = Konto.IdKlienta AND STALHANDEL 98087079643906432786443324 Bank BPH
Konto.IdBanku = Bank.IdBanku
ORDER BY NazwaKlienta, NrKonta
Złączenia zewnętrzne – złączenie lewostronne Złączenia zewnętrzne – złączenie lewostronne
SELECT DISTINCT NazwaKlienta, DataZamowienia

FROM Klient LEFT JOIN Zamowienie USING (IdKlienta) SELECT DISTINCT NazwaTowaru, DataZamowienia, Ilosc
FROM Towar LEFT JOIN LiniaZamowienia USING (IdTowaru) LEFT
+-------------------+---------------------+ JOIN Zamowienie USING (IdZamowienia)
| NazwaKlienta | DataZamowienia | ORDER BY NazwaTowaru
+-------------------+---------------------+
| FH Klin SA | 2004-04-04 00:00:00 |
| FH Klin SA | 2004-04-06 00:00:00 |
| Firma Krok Sp zoo | 2004-04-05 00:00:00 |
| STALHANDEL | 2004-04-06 00:00:00 |
| Rower Polska SA | 2004-04-07 00:00:00 |
| PHPU OSA | [NULL] |
+-------------------+---------------------+
5
4/10/2017
Złączenia zewnętrzne – złączenie prawostronne
+---------------------------+---------------------+--------+
| NazwaTowaru | DataZamowienia | Ilosc |
+---------------------------+---------------------+--------+ SELECT NazwaKlienta, NrKonta, NazwaBanku
| Rura zgrz. fi 12,6 gr 0,2 | 2004-04-04 00:00:00 | 12 |
FROM Klient JOIN Konto USING (IdKlienta) RIGHT
| Rura zgrz. fi 12,6 gr 0,2 | 2004-04-07 00:00:00 | 50 |
JOIN Bank Using(IdBanku)
| Rura zgrz. fi 12,6 gr 0,3 | 2004-04-06 00:00:00 | 12 |
| Rura zgrz. fi 6,3 gr 0,2 | 2004-04-04 00:00:00 | 20 | ORDER BY NazwaKlienta, NazwaBanku
| Rura zgrz. fi 6,3 gr 0,2 | 2004-04-06 00:00:00 | 50 |
| Rura zgrz. fi 6,3 gr 0,2 | 2004-04-05 00:00:00 | 100 |
| Rura zgrz. fi 6,3 gr 0,3 | 2004-04-04 00:00:00 | 25 |
| Rura zgrz. fi 6,3 gr 0,3 | 2004-04-06 00:00:00 | 50 | SELECT NazwaKlienta, NrKonta, NazwaBanku
| Rura zgrz. kw 4 gr 0,2 | 2004-04-07 00:00:00 | 30 |
FROM Klient JOIN Konto ON (Klient.IdKlienta =
| Rura zgrz. kw 4 gr 0,2 | 2004-04-05 00:00:00 | 6 |
| Rura zgrz. kw 5 gr 0,3 | [NULL] | [NULL] | Konto.IdKlienta) RIGHT JOIN Bank ON (Konto.IdBanku =
| Zlaczka 1' | 2004-04-06 00:00:00 | 100 | Bank.IdBanku)
| Zlaczka 2' | 2004-04-06 00:00:00 | 50 | ORDER BY NazwaKlienta, NazwaBanku
| Złączka 3/4' | [NULL] | [NULL] |
+---------------------------+---------------------+--------+
Złączenie prawostronne Podzapytania

+-------------------+----------------------------+---------------
| NazwaKlienta | NrKonta | NazwaBanku
+-------------------+----------------------------+---------------
— Wewnątrz klauzul WHERE i HAVING, a także SELECT i FROM,
| FH Klin SA | 12345678901234567892022222 | Bank BPH mogą wystąpić podzapytania, mające taką samą postać jak
| FH Klin SA | [NULL] | Bank Niemiecki zapytania (tylko są ujęte w nawiasy).
| FH Klin SA | [NULL] | Bank Nowy
| FH Klin SA | 43527897963543645632726336 | Bank Polski
| Firma Krok Sp zoo | 78789798979879879877878978 | Bank BPH — W podzapytaniu dostępne są nazwy kolumn wprowadzone w
| Firma Krok Sp zoo | 46748329374637843254632546 | Bank Niemiecki
| Firma Krok Sp zoo | [NULL] | Bank Nowy
głównym zapytaniu.
| Firma Krok Sp zoo | [NULL] | Bank Polski
| PHPU OSA | [NULL] | Bank BPH — Podzapytanie nazywamy zwykłym jeśli nie zawiera odwołań do
| PHPU OSA
| PHPU OSA
| [NULL]
| [NULL]
| Bank Niemiecki
| Bank Nowy
kolumn tabel określonych w głównym zapytaniu.
| PHPU OSA | [NULL] | Bank Polski
| Rower Polska SA | [NULL] | Bank BPH — Podzapytanie nazywamy skorelowanym jeśli zawiera
| Rower Polska SA | 67686868768348364836483764 | Bank Niemiecki odwołania do kolumn tabel określonych w głównym
| Rower Polska SA | [NULL] | Bank Nowy
| Rower Polska SA | [NULL] | Bank Polski zapytaniu.
| STALHANDEL | 98087079643906432786443324 | Bank BPH
| STALHANDEL | [NULL] | Bank Niemiecki — W podzapytaniu zwykłym zbiór wynikowych wierszy nie
| STALHANDEL | [NULL] | Bank Nowy
| STALHANDEL | 67876864376438209876473674 | Bank Polski zmienia się i nie zależy od wierszy w głównym zapytaniu.
|+-------------------+----------------------------+----------------+
Zagnieżdżone podzapytania
— Wypisz osoby, które zarabiają najwięcej ze wszystkich pracowników.

SELECT Towar.NazwaTowaru, LiniaZamowienia.Ilosc
— najpierw liczymy największą pensję za pomocą zapytania: FROM LiniaZamowienia INNER JOIN Towar ON LiniaZamowienia.IdTowaru =
Towar.IdTowaru
SELECT max(pensja) FROM pracownicy; WHERE (LiniaZamowienia.IdZamowienia IN
(SELECT IdZamowienia
— Zapytanie to można z kolei użyć jako podzapytanie (bez średnika) w FROM Zamowienie
warunku WHERE, wtedy kiedy trzeba przyrównać zarobki pracownika do WHERE DataZamowienia = '2004-04-04' AND IdKlienta = (SELECT
maksymalnych zarobków. W efekcie uzyskujemy możliwość wyszukania IdKlienta
pracowników, których zarobki są równe tym maksymalnym. FROM Klient
WHERE NazwaKlienta = 'FH Klin SA')))
SELECT nazwisko, pensja
FROM pracownicy
WHERE pensja = (SELECT max(pensja) FROM pracownicy);
W klauzuli WHERE może być więcej niż jedno podzapytanie.
6
4/10/2017
Zapytanie nieskorelowane Zapytanie nieskorelowane
— wszystkie zapytania wewnętrzne mogą być wykonane przed

realizacją zapytania zewnętrznego SELECT NazwaTowaru, Ilosc
FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie
— tego rodzaju zapytanie jest szybsze od operacji złączenia USING (IdZamowienia) JOIN Klient Using (IdKlienta)
WHERE DataZamowienia = '2004-04-04' AND NazwaKlienta = 'FH Klin
SA'
+---------------------------+--------+
| NazwaTowaru | Ilosc |
+---------------------------+--------+
| Rura zgrz. fi 6,3 gr 0,2 | 20 |
| Rura zgrz. fi 12,6 gr 0,2 | 12 |
| Rura zgrz. fi 6,3 gr 0,3 | 25 |
+---------------------------+--------+
Zapytania zawierające unię Zapytania zawierające unię
SELECT NazwaKlienta, NazwaTowaru, Ilosc

SELECT NazwaKlienta, NazwaTowaru, Ilosc FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie USING
FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie USING (IdZamowienia) JOIN Klient Using (IdKlienta)
(IdZamowienia) JOIN Klient Using (IdKlienta) WHERE NazwaTowaru = 'Rura zgrz. fi 6,3 gr 0,3' OR NazwaTowaru = 'Rura
WHERE NazwaTowaru = 'Rura zgrz. fi 6,3 gr 0,3' zgrz. fi 12,6 gr 0,2'
UNION
SELECT NazwaKlienta, NazwaTowaru, Ilosc
FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie USING
(IdZamowienia) JOIN Klient Using (IdKlienta)
WHERE NazwaTowaru = 'Rura zgrz. fi 12,6 gr 0,2'
+-----------------+---------------------------+--------+
| NazwaKlienta | NazwaTowaru | Ilosc |
+-----------------+---------------------------+--------+
| FH Klin SA | Rura zgrz. fi 6,3 gr 0,3 | 25 |
| STALHANDEL | Rura zgrz. fi 6,3 gr 0,3 | 50 |
| FH Klin SA | Rura zgrz. fi 12,6 gr 0,2 | 12 |
| Rower Polska SA | Rura zgrz. fi 12,6 gr 0,2 | 50 |
+-----------------+---------------------------+--------+
+-----------------+
SELECT NazwaKlienta | NazwaKlienta |
(IdZamowienia) JOIN Klient Using (IdKlienta) +-----------------+
WHERE NazwaTowaru = 'Rura zgrz. fi 6,3 gr 0,3' | FH Klin SA |
UNION | STALHANDEL |
SELECT NazwaKlienta | Rower Polska SA |
(IdZamowienia) JOIN Klient Using (IdKlienta) +-----------------+
WHERE NazwaTowaru = 'Rura zgrz. fi 12,6 gr 0,2'
7
4/10/2017
SELECT NazwaKlienta SELECT DISTINCT NazwaKlienta

FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie USING FROM Towar JOIN LiniaZamowienia USING (IdTowaru) JOIN Zamowienie USING
(IdZamowienia) JOIN Klient Using (IdKlienta) (IdZamowienia) JOIN Klient Using (IdKlienta)
WHERE NazwaTowaru = 'Rura zgrz. fi 6,3 gr 0,3' OR NazwaTowaru = 'Rura WHERE NazwaTowaru = 'Rura zgrz. fi 6,3 gr 0,3' OR NazwaTowaru = 'Rura
zgrz. fi 12,6 gr 0,2' zgrz. fi 12,6 gr 0,2'
+-----------------+ +-----------------+
| NazwaKlienta | | NazwaKlienta |
+-----------------+ +-----------------+
| FH Klin SA | | FH Klin SA |
| FH Klin SA | | STALHANDEL |
| STALHANDEL | | Rower Polska SA |
| Rower Polska SA | +-----------------+
+-----------------+
Funkcje agregujące (1) Funkcje agregujące (2)
— Jeżeli funkcja agregująca ma ignorować duplikaty, stosuje się klauzulę

— Funkcje agregujące SQL operują na zbiorach wartości (np. kolumna relacji) i
DISTINCT.
obliczają pojedynczą wartość. Są to:
AVG - wartość średnia, — Funkcje agregujące mogą być zastosowane do grup krotek. Uzyskuje się to
przez zastosowanie klauzuli GROUP BY i odpowiednie uformowanie klauzuli
MIN - wartość minimalna,
SELECT.
MAX - wartość maksymalna,
SUM – suma, » Znajdź ilość pracowników w każdym oddziale firmy.
SELECT nazwa_oddzialu, COUNT (DISTINCT nazwisko)
COUNT – liczność zbioru.
FROM pracownicy, oddzialy
WHERE pracownicy.id_oddzialu=oddzialy.id_oddzialu
» Znajdź ilość krotek w relacji pracownicy. GROUP BY nazwa_oddzialu
SELECT COUNT (*)
Uwaga: atrybuty z klauzuli SELECT poza funkcją agregującą muszą
FROM pracownicy;
wystąpić w liście GROUP BY.
» Znajdź średnią płacę .

SELECT AVG (placa)
FROM pracownicy;
Funkcje agregujące (3) Zbiór wejściowy
— Funkcje agregujące mogą być użyte do nakładania warunków na grupy krotek.

+---------------------------+------------+--------+--------+
Wówczas stosuje się rozwinięcie klauzuli GROUP BY o postaci: HAVING funkcja | NazwaTowaru | Data | Ilosc | Cena |
agregująca. +---------------------------+------------+--------+--------+
| Rura zgrz. fi 12,6 gr 0,2 | 2004 04 04 | 12 | 1.75 |
» Znajdź nazwy wszystkich oddziałów, gdzie średnia płaca jest większa niż | Rura zgrz. fi 12,6 gr 0,2 | 2004 04 07 | 50 | 1.75 |
1,200zł | Rura zgrz. fi 12,6 gr 0,3 | 2004 04 06 | 12 | 2.05 |
| Rura zgrz. fi 6,3 gr 0,2 | 2004 04 05 | 100 | 1.40 |
| Rura zgrz. fi 6,3 gr 0,2 | 2004 04 04 | 20 | 1.50 |
| Rura zgrz. fi 6,3 gr 0,2 | 2004 04 06 | 50 | 1.50 |
SELECT nazwa_oddzialu, AVG (placa)
| Rura zgrz. fi 6,3 gr 0,3 | 2004 04 04 | 25 | 2.10 |
FROM pracownicy, oddzialy | Rura zgrz. fi 6,3 gr 0,3 | 2004 04 06 | 50 | 2.10 |
| Rura zgrz. kw 4 gr 0,2 | 2004 04 05 | 6 | 2.20 |
WHERE pracownicy.id_oddzialu=oddzialy.id_oddzialu | Rura zgrz. kw 4 gr 0,2 | 2004 04 07 | 30 | 2.20 |
| Rura zgrz. kw 5 gr 0,3 | [NULL] | [NULL] | [NULL] |
GROUP BY nazwa_oddzialu | Zlaczka 1' | 2004 04 06 | 100 | 0.90 |
| Zlaczka 2' | 2004 04 06 | 50 | 1.10 |
HAVING AVG (placa) > 1200; | Złączka 3/4' | [NULL] | [NULL] | [NULL] |
+---------------------------+------------+--------+--------+
Uwaga: warunki z klauzuli HAVING są stosowane po uformowaniu grup.
8
4/10/2017
Funkcja COUNT Pozostałe funkcje
SELECT SUM(Ilosc*LiniaZamowienia.Cena)
SELECT COUNT(*) AS Liczba FROM Towar LEFT JOIN LiniaZamowienia USING (IdTowaru) LEFT JOIN Zamowienie
FROM Towar LEFT JOIN LiniaZamowienia USING (IdTowaru) LEFT JOIN Zamowienie USING (IdZamowienia)
USING (IdZamowienia)
ORDER BY NazwaTowaru 759,8
14
SELECT AVG(LiniaZamowienia.Cena)
FROM Towar LEFT JOIN LiniaZamowienia USING (IdTowaru)
SELECT COUNT(Ilosc) AS Liczba WHERE Towar.IdTowaru=1
FROM Towar LEFT JOIN LiniaZamowienia USING (IdTowaru) LEFT JOIN Zamowienie
USING (IdZamowienia) 1,46667
12 SELECT MAX( DATE_FORMAT(DataZamowienia, '%Y %m %d') ) AS Data

SELECT COUNT(DISTINCT NazwaTowaru) AS Liczba
ORDER BY NazwaTowaru
ORDER BY NazwaTowaru 2004 04 07
9
Zapytania grupujące Zapytania grupujące
SELECT DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data, Towar.NazwaTowaru, SELECT NazwaKLienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data,
SUM(Ilosc) AS Ilosc , SUM(Ilosc*Cena) AS Wartosc SUM(Ilosc*Cena) AS Wartosc
FROM Zamowienie JOIN LiniaZamowienia USING (IdZamowienia) JOIN Towar USING ( FROM Klient JOIN Zamowienie USING (IdKlienta) JOIN LiniaZamowienia USING
IdTowaru) (IdZamowienia)
GROUP BY DataZamowienia GROUP BY NazwaKlienta
ORDER BY DataZamowienia ORDER BY NazwaKLienta, DataZamowienia
+-------------------+------------+---------+
+------------+---------------------------+--------+---------+ | NazwaKLienta | Data | Wartosc |
| Data | NazwaTowaru | Ilosc | Wartosc | +-------------------+------------+---------+
+------------+---------------------------+--------+---------+ | FH Klin SA | 2004 04 04 | 203.1 |
| 2004 04 04 | Rura zgrz. fi 6,3 gr 0,2 | 57 | 103.5 | | Firma Krok Sp zoo | 2004 04 05 | 153.2 |
| 2004 04 05 | Rura zgrz. fi 6,3 gr 0,2 | 106 | 153.2 | | Rower Polska SA | 2004 04 07 | 153.5 |
| 2004 04 06 | Rura zgrz. fi 6,3 gr 0,2 | 262 | 349.6 | | STALHANDEL | 2004 04 06 | 250 |
| 2004 04 07 | Rura zgrz. fi 12,6 gr 0,2 | 80 | 153.5 | +-------------------+------------+---------+
+------------+---------------------------+--------+---------+
Zapytania grupujące Zapytania grupujące - ograniczenia
SELECT NazwaKLienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data, SELECT NazwaKLienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data,
SUM(Ilosc*Cena) AS Wartosc SUM(Ilosc*Cena) AS Wartosc
FROM Klient JOIN Zamowienie USING (IdKlienta) JOIN LiniaZamowienia USING FROM Klient JOIN Zamowienie USING (IdKlienta) JOIN LiniaZamowienia
(IdZamowienia) USING (IdZamowienia)
GROUP BY NazwaKlienta, DataZamowienia WHERE DataZamowienia > '2004-04-04'
ORDER BY NazwaKLienta, DataZamowienia GROUP BY NazwaKlienta, DataZamowienia
ORDER BY NazwaKLienta, DataZamowienia
+-------------------+------------+---------+ +-------------------+------------+---------+
| NazwaKLienta | Data | Wartosc | | NazwaKLienta | Data | Wartosc |
+-------------------+------------+---------+ +-------------------+------------+---------+
| FH Klin SA | 2004 04 04 | 103.5 | | FH Klin SA | 2004 04 06 | 99.6 |
| FH Klin SA | 2004 04 06 | 99.6 | | Firma Krok Sp zoo | 2004 04 05 | 153.2 |
| Firma Krok Sp zoo | 2004 04 05 | 153.2 | | Rower Polska SA | 2004 04 07 | 153.5 |
| Rower Polska SA | 2004 04 07 | 153.5 | | STALHANDEL | 2004 04 06 | 250 |
| STALHANDEL | 2004 04 06 | 250 | +-------------------+------------+---------+
+-------------------+------------+---------+
9
4/10/2017
Zapytania grupujące - ograniczenia Operacje na łańcuchach
SELECT NazwaKLienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data, — konkatenacja łańcuchów

SUM(Ilosc*Cena) AS Wartosc
FROM Klient JOIN Zamowienie USING (IdKlienta) JOIN LiniaZamowienia USING
(IdZamowienia)
GROUP BY NazwaKlienta, DataZamowienia
HAVING Data > '2004 04 04'
SQL-92
ORDER BY NazwaKlienta, DataZamowienia SELECT KodPocztowy || ' ‘ || Miejscowosc)
FROM `klient`
Microsoft SQL Server

+-------------------+------------+---------+
| NazwaKLienta | Data | Wartosc | SELECT SymbolTowaru + ' ' + NazwaTowaru AS NowaNazwa
+-------------------+------------+---------+ FROM Towar
| FH Klin SA | 2004 04 06 | 99.6 |
| Firma Krok Sp zoo | 2004 04 05 | 153.2 |
| Rower Polska SA | 2004 04 07 | 153.5 | MySQL
| STALHANDEL | 2004 04 06 | 250 | SELECT concat(KodPocztowy, ' ', Miejscowosc)
+-------------------+------------+---------+ FROM `klient`
Wybrane funkcje tekstowe
+-------------+-------------+
— UPPER i LOWER konwertują łańcuchy tekstowe na duże lub małe | KodPocztowy | Miejscowosc |
+-------------+-------------+
litery | 30-121 | Kraków |
| 30-321 | Kraków |
| 34-876 | Sosnowiec |
— TRIM (słowo) – usuwa określone znaki z początku lub końca | 32-082 | Zabierzów |
łańcucha znaków. Domyślnie usuwa spacje z obu stron. Ilość | 30-432 | Kraków |
+-------------+-------------+
usuwanych znaków jest ograniczona do jednego.
SELECT SUBSTRING(TRIM(LEADING '3' FROM CONCAT(KodPocztowy, ' ', Miejscowosc))
» TRIM (BOTH znak FROM słowo) FROM 1 FOR 12) AS Miasto
FROM klient
WHERE UPPER(Miejscowosc) = 'KRAKÓW'
» TRIM (LEADING znak FROM słowo)
+--------------+
» TRIM (TRAILING znak FROM słowo) | Miasto |
+--------------+
— SUBSTRING (słowo FROM poz_startowa FOR liczba_znaków) | 0-121 Kraków |
| 0-321 Kraków |
| 0-432 Kraków |
+--------------+
Działania dotyczące czasu Działania dotyczące czasu
SELECT NazwaKlienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS Data1,

CURRENT_DATE AS Data2, TO_DAYS(CURRENT_DATE) - TO_DAYS( DataZamowienia) Dni
SELECT NazwaKlienta, DATE_FORMAT(DataZamowienia, '%Y %m %d') AS DataFaktury,
FROM Zamowienie JOIN Klient USING (IdKlienta)
DATE_FORMAT(DATE_ADD(DataZamowienia, INTERVAL 14 DAY), '%Y %m %d') AS
TerminPlatnosci
FROM Zamowienie JOIN Klient USING (IdKlienta)
+-------------------+------------+------------+--------+
| NazwaKlienta | Data1 | Data2 | Dni |
+-------------------+------------+------------+--------+
+-------------------+------------+-----------------+
| FH Klin SA | 2004 04 04 | 2004-05-03 | 29 |
| NazwaKlienta | DataFaktury| TerminPlatnosci |
| FH Klin SA | 2004 04 06 | 2004-05-03 | 27 | +-------------------+------------+-----------------+
| Firma Krok Sp zoo | 2004 04 05 | 2004-05-03 | 28 | | FH Klin SA | 2004 04 04 | 2004 04 18 |
| STALHANDEL | 2004 04 06 | 2004-05-03 | 27 | | FH Klin SA | 2004 04 06 | 2004 04 20 |
| Rower Polska SA | 2004 04 07 | 2004-05-03 | 26 | | Firma Krok Sp zoo | 2004 04 05 | 2004 04 19 |
+-------------------+------------+------------+--------+ | STALHANDEL | 2004 04 06 | 2004 04 20 |
| Rower Polska SA | 2004 04 07 | 2004 04 21 |
+-------------------+------------+-----------------+
10
4/10/2017
Przykłady zapytań
Pokaż listę pracowników wraz z NAZWAMI

języków, które znają, oznaczając kolumnę z
językami jako JĘZYK
Zapytanie 1 Zapytanie 2
Pokaż listę pracowników wraz z NAZWAMI języków, Znajdź wszystkich pracowników znających język angielski i pokaż stopień jego
które znają, oznaczając kolumnę z językami jako JĘZYK znajomości w kolumnie POZIOM ANGIELSKIEGO. Wyniki poukładaj alfabetycznie (wg
nazwisk).
SELECT pracownik.nazwisko, dictpoziomjezyka.nazwa

AS ‘POZIOM ANGIELSKIEGO’
FROM pracownik,znajomoscjezykow,dictjezyki,dictpoziomjezyka
SELECT pracownik.nazwisko, dictjezyki.nazwa WHERE dictjezyki.id_jezyk=znajomoscjezykow.id_jezyk
AS JĘZYK AND znajomoscjezykow.loginpracownika=pracownik.loginpracownika
FROM ((pracownik LEFT OUTER JOIN znajomoscjezykow USING AND
znajomoscjezykow.id_dictpoziomjezyka=dictpoziomjezyka.id_dictpoziomjezyka
(loginpracownika)) AND znajomoscjezykow.id_jezyk=1
INNER JOIN dictjezyki ON ORDER BY pracownik.nazwisko;
znajomoscjezykow.id_jezyk=dictjezyki.id_jezyk);
Zapytanie 3
Znajdź średnią ocenę plików zawierających w nazwie słowo „opis” i umieść ją w

kolumnie „Średnia ocena”.
select nazwapliku,avg(ocena) as 'Średnia ocena'

from ocena
group by nazwapliku
having nazwapliku like '%opis%';
11
Bazy Danych
Transakcje
Piotr Macioł
WIMiIP, KISiM,
pmaciol@agh.edu.pl
B5, pok. 606
Transakcje i blokady
— co to są transakcje?
— reguły ACID
— transakcje z pojedynczym użytkownikiem
— ograniczenia transakcji
— transakcje z wieloma użytkownikami
— poziomy izolacji ANSI
— tryby związany i niezwiązany
— blokowanie
— zakleszczanie i jawne blokady

Co to są transakcje?
— Przykład zastosowania: musimy wykonać kilka komend SQL

zmieniających dane w tablicach. Jak to zrobić aby komendy
wykonał się poprawnie do końca albo wcale?
— Transakcja jest logiczną jednostką działań, której nie można
podzielić.
— Logiczna jednostka działań to zbiór logicznych zmian w bazie
danych, które należy wykonać wszystkie albo nie wykonywać
żadnej.
— Moduł zarządzania transakcjami (transaction management)
zapewnia pozostawanie bazy w spójnym (poprawnym) stanie
pomimo wystąpienia błędu gdziekolwiek w systemie
(np. przerwa w zasilaniu) lub w samej transakcji.

— Zmiany są kontrolowane przez trzy kluczowe frazy:

» Fraza BEGIN WORK rozpoczyna transakcję;
» COMMIT WORK informuje, że wszystkie elementy
transakcji są kompletne i powinny zostać zatwierdzone na
stałe oraz stać się dostępne dla wszystkich transakcji;
» ROLLBACK WORK mówi, że należy porzucić transakcję, a
wszystkie zmiany danych dokonane przez transakcję SQL
mają być anulowane. Baza danych, z punktu widzenia
użytkowników, powinna się znajdować w takim stanie,
jakby nie były wykonywane żadne zmiany.

— Standard ANSI/SQL nie definiuje frazy SQL

BEGIN WORK, transakcje w tym standardzie powinny
wykonywać się automatycznie. Fraza ta jednak jest wymagana
prawie we wszystkich implementacjach baz danych.
— Słowo WORK we frazie COMMIT WORK,
ROLLBACK WORK można pominąć.
— SQL obejmuje polecenia rozpoczęcia i zakończenia transakcji, a
także blokowania danych dla współbieżnych operacji
(START TRANSACTION, COMMIT, ROLLBACK)

— Dowolna transakcja w bazie danych powinna być

odizolowana od wszystkich pozostałych transakcji, które są
wykonywane w tym samym czasie.
— W idealnej sytuacji każda transakcja zachowuje się tak jakby
posiadała wyłączny dostęp do bazy danych.
— Niestety realia związane z osiągnięciem dobrej wydajności
wymagają kompromisów o których powiemy później.

KLIENT 1 KLIENT 2 Wolne miejsce
Czy są wolne miejsca? 1
Czy są wolne miejsca? 1
Oferuje miejsce 1
Oferuje miejsce 1
Pytanie o kartę kredytową lub konto 1
Pytanie o kartę kredytową lub konto 1
Podaje numer karty Podaje numer konta 1

Autoryzacja 1
Autoryzacja 1
Przypisanie miejsca 1
Przypisanie miejsca 1
Obciążenie karty 1
Obciążenie karty 1
Zmniejszenie liczby wolnych miejsc 0
Zmniejszenie liczby wolnych miejsc -1

Reguły ACID
— ACID to mnemonik służący do opisania transakcji, jaka

powinna być:
» Niepodzielna (Atomic)
» Spójna (Consistent)
» Odizolowana (Isolated)
» Trwała (Durable)

Reguły ACID
— Niepodzielność (Atomicity) – transakcja składa się z sekwencji instrukcji.

Transakcja musi być wykonana w całości, jeśli nastąpi awaria, częściowe
zmiany powinny zostać wycofane.
Transakcja, mimo że jest zbiorem odwołań, musi być wykonywana jako

pojedyncza jednostka. Transakcja musi wykonywać się w jednym momencie i
nie może dzielić się na podzbiory.
— Spójność (Consistency) – baza danych musi być zgodna z rzeczywistością,
co określamy jako spójność. Transakcje modyfikujące należy traktować
jako przejście bazy danych z jednego spójnego stanu w drugi, także spójny.
Reguły spójności określane są przez więzy integralności.
Jeżeli w komendach SQL są WARUNKI INTEGRALNOŚCI to powinny być

sprawdzone na końcu transakcji – słowo kluczowe DEFERRABLE (odroczane)
DEFERRABLE INITIALLY DEFERRED or DEFERRABLE INITIALLY IMMEDIATE

Reguły ACID
— Izolacja (Isolation) – równoczesne wykonywanie transakcji na

tych samych danych przez różnych użytkowników może
prowadzić do zachwiania spójności, dlatego poszczególne
transakcje muszą zostać odizolowane od siebie jest to zadanie
modułu zarządzania współbieżnością (concurrency control
manager). Izolacja sprawia niestety kłopoty z wydajnością bazy danych
— Trwałość (Durability) – po pomyślnym wykonaniu transakcji
zmiany powinny zostać utrwalone tak, aby zostały zachowane
nawet w przypadku awarii sprzętu lub oprogramowania.
Wykonywane jest to za pomocą dziennika transakcji.

Dziennik transakcji
— Dziennik transakcji (log) działa następująco: w czasie

wykonywania transakcji zmiany są zapisywane nie tylko w
bazie danych ale także do pliku dziennika.
— Po zakończeniu transakcji zapisywany jest znacznik, który
informuje, że transakcja została zakończona i dane z dziennika
transakcji zostały zatwierdzone do zapisu na stałe do bazy
danych.
— Gwarantuje to bezpieczeństwo danych nawet w przypadku
awarii bazy. Jeżeli serwer bazy danych przestanie działać w
czasie transakcji to po ponownym jego uruchomieniu
automatycznie jest sprawdzane, czy zakończone transakcje
zostały właściwie odzwierciedlone w bazie danych (poprzez
przeglądanie transakcji w dzienniku transakcji a nie w bazie
danych).
— Jeśli w bazie danych nie ma transakcji, które trwały w czasie
awarii serwera, transakcja jest utrwalana bez udziału
użytkownika

Transakcje z pojedynczym użytkownikiem
6 BEGIN WORK 1
Wykonaj kod SQL; 2

Wykonaj kod SQL; 3
Wykonaj kod SQL; 4
ROLLBACK WORK 5
Gdy stwierdzamy, że nie chcemy zakończenia wykonania transakcji

to wykonujemy ROLLBACK WORK

6 BEGIN WORK 1
Wykonaj kod SQL; 2

Wykonaj kod SQL; 3
Wykonaj kod SQL; 4
COMMIT WORK 5
Gdy stwierdzamy, że chcemy zakończenia wykonania transakcji

to wykonujemy COMMIT WORK

— Ograniczenia transakcji
» Nie wolno zagnieżdżać transakcji
» Zaleca się aby transakcje były niewielkie. Należy wykonać
wiele działań aby upewnić się, że transakcje wielu
użytkowników są rozdzielone. Te elementy, które biorą
udział w transakcjach, muszą być zablokowane
» Transakcja, której wykonanie trwa długo i obejmuje wiele
tabel, uniemożliwia innym użytkownikom korzystanie z
danych, do czasu zakończenia lub anulowania transakcji

— Ograniczenia transakcji c.d.

» Należy unikać transakcji w czasie dialogu z
użytkownikiem. Należy najpierw pobrać potrzebne dane a
dopiero potem uruchamiać transakcję.
» Instrukcja COMMIT WORK trwa zazwyczaj szybko.
» Dużo dłużej trwa ROLLBACK WORK

Transakcje z wieloma użytkownikami
— Co oznacza że transakcje są izolowane?

— Samo osiągnięcie izolacji nie jest trudne. Zezwolenie na
pojedyncze połączenie z bazą danych, z zaledwie jedną
transakcją wykonywaną w danym czasie zapewnia izolację
pomiędzy różnymi transakcjami.
— Osiągnięcie bardziej praktycznej izolacji, bez znacznego
obniżenia wydajności powoduje uniemożliwienie uzyskania
dostępu do bazy danych przez wielu użytkowników.
— Osiągnięcie prawdziwej izolacji bez obniżenia wydajności
bazy jest bardzo trudne dlatego standard SQL ANSI definiuje
różne poziomy izolacji, które baza danych może
implementować.

— Standard SQL ANSI definiuje poziomy izolacji w odniesieniu do

niepożądanych zjawisk, które mogą się zdarzyć w czasie
interakcji transakcji dla wielodostępnych baz danych;
— Niepożądane zjawiska:
» Brudny odczyt – ma miejsce wtedy, gdy pewne instrukcje

SQL wewnątrz transakcji odczytują dane, które zostały
zmienione przez inną transakcję ale nie potwierdzone
jeszcze poleceniem COMMIT
» Odczyty nie dające się powtórzyć – Podobne do brudnego
odczytu. Zjawisko zachodzi wtedy, gdy transakcja
odczytuje zbiór danych, następnie czyta dane ponownie i
okazuje się, że dane nie są identyczne, odczytuje bowiem
zmiany zatwierdzone przez COMMIT

— Niepożądane zjawiska c.d.:

» Odczyty widmo – problem podobny do odczytów nie
dających się powtórzyć, ale mający miejsce wtedy gdy w
tabeli znajdzie się nowy wiersz. Gdy inna transakcja
aktualizuje tabelę nowy wiersz powinien być dodany a tak
się nie staje.
» Utracone aktualizacje - Zachodzi wtedy gdy do bazy
zapisywane są dwie różne zmiany i druga aktualizacja
powoduje, że pierwsza zostaje utracona.

Poziomy izolacji ANSI
Definicja poziomu Brudny odczyt Odczyt nie dający się Widmo

izolacji ANSI /ISO powtórzyć
READ możliwy możliwy możliwy

UNCOMMITTED
odczyt nie
zatwierdzony
READ COMMITTED niemożliwy możliwy możliwy
odczyt zatwierdzony
REPETABLE READ niemożliwy niemożliwy możliwy

odczyt dający się
powtórzyć
SERIALIZABLE niemożliwy niemożliwy niemożliwy
odczyt uszeregowany

Przykład
— Zakładamy, że mamy następującą tablicę tab z danymi:

mysql> CREATE TABLE tab (f INT) TYPE = InnoDB;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO tab values (1),(2),(3),(4),(55);

— Na początek sprawdźmy jaki poziom izolacji transakcji obowiązuje w danej
chwili (jeśli tego nie zmieniliśmy my lub administrator to domyślnym
poziomem izolacji transakcji w MySQL jest REPEATABLE READ).
mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

Repeatable Read
— Zobaczmy, czy polecenie INSERT wykonane w obrębie jednej transakcji i

potwierdzone następnie poleceniem COMMIT jest widoczne z poziomu
drugiej transakcji.
Sesja 1
mysql> BEGIN;
mysql> SELECT * FROM tab;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
+------+
5 rows in set (0.00 sec)

Sesja 2
mysql> BEGIN;
mysql> INSERT INTO tab VALUES(6);
Query OK, 1 row affected (0.00 sec)
mysql> COMMIT;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+
— nie ma znaczenia dla transakcji w sesji 2, że polecenie SELECT zostało wykonane po poleceniu
COMMIT. W obrębie transakcji nowy rekord jest natychmiast ''widzialny'' (równie dobrze
moglibyśmy wykonać SELECT przed wykonaniem polecenia COMMIT).
Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
+------+
mysql> COMMIT;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+

— To właśnie jest idea blokowania typu Repeatable Read.
— Wykonane polecenie SELECT zwraca wynik, który
charakteryzuje się spójnością, a nowe rekordy dodane do
tablicy z poziomu innej transakcji nie są od razu widoczne.
— Aby były widoczne należy bezwzględnie zakończyć transakcję.

Uncommitted Read
— Zobaczmy jak zachowują się transakcje w trybie Uncommitted

Read. Musimy w tym celu zmienić poziom izolacji transakcji z
domyślnego na Uncommitted Read właśnie.
— Aby to uczynić musimy mieć przywilej SUPER.
mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED;

Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+
Sesja 2
mysql> BEGIN;
mysql> INSERT INTO tab VALUES (7),(8);

Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
| 7 |
| 8 |
+------+
— To właśnie jest tzw. dirty read - nowe rekordy nie zostały jeszcze nawet
potwierdzone w drugiej transakcji a już są widoczne z poziomu pierwszej transakcji.
Sesja 2
mysql> ROLLBACK;

— Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+
— Taki poziom izolacji jest niebezpieczny i właściwie łamie zasady ACID.

Używa się takiego trybu pracy transakcji w przypadku, kiedy nie interesuje
nas spójność danych, a jedynie dostęp do najświeższych danych z poziomu
dowolnej transakcji.

Committed Read
— Ponownie trzeba zmienić poziom izolacji i uruchomić dwie nowe (!) sesje.
READ COMMITTED;
Sesja 1
mysql>BEGIN;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+

Sesja 2
mysql> BEGIN;
mysql> INSERT INTO t VALUES (7),(8);
Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+------+

Sesja 2
mysql> COMMIT;
Sesja 1
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
| 7 |
| 8 |
+------+
mysql> COMMIT;

Committed Read c.d.
— Istotną różnicą jest to, że niepotwierdzone poleceniem COMMIT polecenie

INSERT nie wpłynęło na aktualny stan bazy danych widziany z poziomu
drugiej transakcji.
— Dopiero po potwierdzeniu transakcji (po jej zakończeniu) widoczne są
zmiany w tablicach.
— Jest też różnica pomiędzy tym poziomem izolacji (READ COMMITTED) a
omówionym pierwszym domyślnym poziomem izolacji (REPEATABLE
READ).
— W trybie READ COMMITTED zmiany w tablicach widoczne są już wówczas,
gdy transakcja, w której zostały wykonane potwierdzi je poleceniem
COMMIT, nawet wówczas gdy w danej transakcji nie wykonano jeszcze
COMMIT.
— W trybie REPEATABLE READ, zmiany są widoczne dopiero wówczas, gdy w
obu transakcjach wykonane zostaną polecenia potwierdzenia (COMMIT).

Serializable

SERIALIZABLE;
— Tryb SERIALIZABLE posuwa się o krok dalej niż tryb

REPEATABLE READ. W trybie SERIALIZABLE wszystkie
zwyczajne polecenia SELECT są traktowane jakby były
wykonywane z klauzulą LOCK IN SHARE MODE.

Sesja 1
mysql> BEGIN;
mysql> SELECT * FROM tab
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
| 7 |
| 8 |
+------+
Sesja 2
mysql> BEGIN;
mysql> UPDATE tab SET f=88 WHERE f=8;
— Z powodu wykonania polecenia SELECT w sesji 1 polecenie UPDATE wykonywane w
sesji 2 czeka aż po poleceniu SELECT (w sesji 1) nie zostanie wykonane polecenie
COMMIT (tak, jak przy zwykłym LOCK IN SHARE MODE). Dopiero, kiedy w sesji 1
wykonane zostanie polecenie COMMIT kończące transakcję, wówczas zostanie
wykonanie polecenie UPDATE w sesji 2.
Sesja 1
mysql> COMMIT;
Sesja 2
Rows matched: 1 Changed: 1 Warnings: 0
mysql> COMMIT;
mysql> SELECT * FROM tab
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
| 7 |
| 88 |
+------+

Poziomy izolacji ANSI
— Tablice InnoDB wspierają wszystkie cztery poziomy izolacji transakcji. Przy

przenoszeniu kodów SQL na inny system baz danych, należy mieć świadomość, że
nie wszystkie poziomy izolacji są wspierane przez inne systemy baz danych, a co
więcej, w niektórych z nich domyślnym poziomem izolacji jest zupełnie inny poziom
niż w MySQL.
— MySQL - REPEATABLE READ jest domyślnym poziomem izolacji transakcji i nie
powinniśmy tego raczej zmieniać, może się zdarzyć bowiem że będziemy kiedyś
oczekiwać długie godziny, zanim nasze polecenia wykonywane w bazie danych
odniosą trwały skutek.
— MS SQL SERVER - domyślnie READ COMMITTED, poza tym, nie ma żadnych innych
poziomów izolacji.
— Oracle - domyślnie READ COMMITTED, poza tym można wybrać też SERIALIZABLE i
niestandardowy READ ONLY.
— DB2 - domyślnie REPEATABLE READ, poza tym można wybrać też UNCOMMITTED
READ oraz inne niestandardowe poziomy izolacji.
— PostgreSQL - domyślnie READ COMMITTED/REPEATABLE READ, poza tym można
też wybrać SERIALIZABLE.
— SQLite - SERIALIZABLE

Tryb chained i unchained
— W MySQL można wykonywać zmiany w bazie danych bez polecenia BEGIN

WORK czy START TRANSACTION.
— Dzieje się tak, ponieważ MySQL działa domyślnie w trybie
autozatwierdzania (AUTOCOMMIT), zwanym czasem trybem CHAINED, lub
trybem niejawnych transakcji.
— Każda instrukcja zmieniająca dane działa w tym trybie tak, jakby była
kompletną transakcją. Dzięki temu możliwe jest wykonywanie
pojedynczych instrukcji nie zakończonych instrukcjami COMMIT ani
ROLLBACK.
— polecenie BEGIN WORK powoduje, że system przełączy się automatycznie
do trybu, w którym kolejne polecenia będą częścią transakcji zakończonej
przez COMMIT lub ROLLBACK.
— W standardzie SQL przewiduje się, że wszystkie instrukcje są częścią
transakcji. Każda transakcja zaczyna się automatycznie i trwa do instrukcji
COMMIT lub ROLLBACK. Stąd w standardzie nie ma polecenia BEGIN
WORK, chociaż jest bardzo popularne.

Kontrola współbieżności:
— Moduł zarządzania współbieżnością (concurrency control manager) steruje
interakcjami pomiędzy współbieżnymi transakcjami w celu zapewnienia
poprawności i spójności bazy danych.
— Na moment zapisu danych do bazy dane muszą być niedostępne w tym czasie
dla innych użytkowników. Blokady (locks) mogą dotyczyć pliku (relacji), rekordu,
pola. Rezultatem blokowania dostępu do zasobów jest kolejkowanie dostępu.
— Blokady:
» Odczytu – daje dostęp tylko do odczytu i zapobiega ich modyfikacji przez
inne transakcję (gdy stosujemy zapytanie do relacji)
» Zapisu – daje dostęp do danych zarówno do odczytu i zapisu, jednocześnie
uniemożliwia dostęp innym transakcjom do tego elementu danych
» Totalne – blokowanie zapisu do relacji
» Optymistyczne – blokowanie kolejnych rekordów w miarę modyfikowania
— Zakleszczenie (dead lock) – różne transakcje otrzymały dostęp do jednej relacji
dzięki blokadzie optymistycznej, ale blokują sobie wzajemnie dostęp do
poszczególnych rekordów, w efekcie żadna nie może być kontynuowana.

Przykłady:
START TRANSACTION;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
BEGIN TRANSACTION;
UPDATE ListaProduktow
SET Cecha = 4
WHERE IdProduktu = 2944;
ROLLBACK;
LOCK TABLES trans READ, customer WRITE;

UPDATE customer
SET total_value=sum_from_previous_statement
WHERE customer_id=some_id;
UNLOCK TABLES;

Składnia polecenia START TRANSACTION
— Domyślnie, MySQL pracuje z włączoną opcją AUTOCOMMIT (zresztą nie

tylko MySQL). Aby więc możliwe było wykonywanie transakcji należy tą
opcję wyłączyć.
mysql> SET AUTOCOMMIT = 0;
— Należy jednak pamiętać, że tak wyłączona opcja oznacza, że każda operacja
na bazie danych nie zostanie trwale zapisana, dopóty, dopóki nie
wykonamy polecenia COMMIT.
— W praktyce więc transakcja rozpoczyna się nie wykonaniem polecenia
BEGIN ale poleceniem SET AUTOCOMMIT = 0; i podobnie, transakcja
nie powinna się kończyć poleceniem COMMIT ale dodatkowo należy
jeszcze włączyć z powrotem opcję
AUTOCOMMIT: SET AUTOCOMMIT = 1;.
— Dopiero wtedy będziemy mieli wykonaną nasza transakcję i będziemy
mogli wykonywać normalne zmiany w bazie danych bez używania
transakcji.

— Inną możliwością jest rozpoczęcie transakcji poleceniem
START TRANSACTION
— W takim wypadku tryb AUTOCOMMIT zostaje zawieszony automatycznie
na czas wykonywania ciągu operacji i uruchomiony ponownie w momencie
wykonania polecenia COMMIT lub ROLLBACK
Przykład:
mysql> START TRANSACTION;
mysql> SELECT @A:=SUM(pensja) FROM tab1 WHERE type=1;
mysql> UPDATE tab2 SET suma=@A WHERE type=1;
mysql> COMMIT;
— Poleceń BEGIN i BEGIN WORK można używać zamiast polecenia START

TRANSACTION w celu rozpoczęcia transakcji. Polecenie START
TRANSACTION zostało dodane w wersji 4.0.11 MySQLa.

Blokady
— Wiele RDBMS implementuje transakcje, a w szczególności

izolację różnych transakcji użytkownika za pomocą blokad,
które ograniczają dostęp do danych innym użytkownikom.
— Istnieją dwa typy blokad:
» blokada współdzielona (ang. shared lock), która
pozwala innym użytkownikom odczytywać dane,
ale nie zezwala na ich aktualizację.
» blokada wyłączna, która nie zezwala innym
transakcjom nawet na odczyt danych.

Jawne blokady
Blokowanie wierszy – fraza FOR UPDATE
SELECT * FROM item

WHERE cena>25
FOR UPDATE
Blokowanie tabel
LOCK [ TABLE ] nazwa;

Spójne SELECT’y
— Spójrzmy na proces transakcji z poziomu dwóch różnych sesji.
Sesja 1
mysql> BEGIN;
mysql> INSERT INTO tab (f) VALUES (1);
+---+
| f |
+---+
| 1 |
+---+
Sesja 2
Empty set (0.00 sec)
— A zatem wykonując to samo polecenie SELECT z poziomu różnych sesji (jednej, w
czasie której wykonujemy transakcję i drugiej, w czasie której polecenia są
wykonywane "na zewnątrz" transakcji) dostaniemy dwa różne rezultaty.

— Dopiero po wykonaniu COMMIT w sesji pierwszej, wynik będzie taki sam z
poziomu obu sesji.
Sesja 1
mysql> COMMIT; Query OK, 0 rows affected (0.00 sec)
Sesja 2
+---+
| f |
+---+
| 1 |
+---+
— Taką właściwość nazywa się spójnym czytaniem lub spójnym SELECT.

Każdy wykonany SELECT zwraca dane aktualne do ostatnio ZAKOŃCZONEJ
transakcji.

SELECT’y FOR UPDATE
— Może się zdarzyć, że będziemy chcieli przeczytać rekord, w

celu zmiany wartości niektórych z jego pól, mając jednocześnie
pewność, że nikt inny nie będzie chciał w tym samym czasie
wykonać tego samego.
— Na przykład dwóch użytkowników w czasie dwóch różnych
sesji czytają ten sam rekord, w celu wstawienia następnego
rekordu, w którym pewna wartości w pewnym polu będzie
zwiększoną inkrementalnie wartością z pola przeczytanego
właśnie rekordu, albo wartością maksymalną w tym polu
(bieżącą wartością maksymalną).

Sesja 1
mysql> BEGIN;
mysql> SELECT MAX(f) FROM tab;

+--------+
| MAX(f) |
+--------+
| 3 |
+--------+
mysql> INSERT INTO tab(f) VALUES (4);


Sesja 2
mysql> BEGIN;
mysql> SELECT MAX(f) FROM tab;
+--------+
| MAX(f) |
+--------+
| 3 |
+--------+
mysql> COMMIT;

Sesja 1
mysql> COMMIT;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 4 |
+------+
— W wyniku takich działań powstały dwa rekordy z wartością 4, podczas gdy

chcieliśmy mieć jeden rekord z wartością 4 i jeden z wartością 5.

— Aby zabezpieczyć się przed taką sytuacją musimy ograniczyć
dostęp do rekordów tablicy.
— Można to zrobić za pomocą zamknięcia dostępu do tablicy do
czasu, aż transakcja nie zostanie zakończona.
— Służy do tego klauzula FOR UPDATE dodawana do polecenia
SELECT. Jest to więc specjalny SELECT wykonywany z myślą o
tym, aby chwilę później wykonać UPDATE.
— W przykładzie najpierw usuwamy błędne rekordy:

mysql> DELETE FROM tab WHERE f=4;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
+------+
mysql> BEGIN;
mysql> SELECT MAX(f) FROM tab FOR UPDATE;
+--------+
| MAX(f) |
+--------+
| 3 |
+--------+

Sesja 2
— mysql> SELECT MAX(f) FROM tab FOR UPDATE;
Nie ma żadnych wyników. MySQL czeka, aż aktywna transakcja
się zakończy i dopiero wówczas zwróci dane, które będą
aktualne po zakończeniu transakcji w sesji 1.
Sesja 1
— mysql> COMMIT;
Dopiero w w tym momencie wyniki są zwracane do sesji 2.
Należy jeszcze dodać, że jeśli blokowanie trwało zbyt długo,
wówczas MySQL zwróci informację, że został przekroczony
czas oczekiwania.

Sesja 2
— mysql> SELECT MAX(f) FROM tab FOR UPDATE;
+--------+
| MAX(f) |
+--------+
| 4 |
+--------+
mysql> INSERT INTO tab(f) VALUES(5);
mysql> COMMIT;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

SELECT’y w trybie wspólnym
— Kolejnym typem ograniczenia dostępu do danych jest tzw.

LOCK IN SHARE MODE.
— Taki sposób ograniczania danych zapewnia dostęp do
najświeższych danych (wprowadzanych w czasie transakcji) z
zewnątrz transakcji.
— Takie udostępnianie danych blokuje wszystkie zmiany danych
(polecenia UPDATE i DELETE) i jeśli ostatnie zmiany nie były
jeszcze potwierdzone poleceniem COMMIT, powoduje
oczekiwanie na wynik zapytania dopóty, dopóki nie nastąpi
potwierdzenie transakcji w sesji, która rozpoczęła tą
transakcję.

Sesja 1
mysql> BEGIN;
mysql> SELECT MAX(f) FROM tab LOCK IN

SHARE MODE;
+--------+
| MAX(f) |
+--------+
| 5 |
+--------+

— W tym czasie użytkownik w innej sesji próbuje wykonać
UPDATE
Sesja 2
— mysql> UPDATE tab SET f = 55 WHERE f=5;
Jednak polecenie oczekuje dopóty dopóki nie nastąpi

zakończenie transakcji w sesji 1.
Sesja 1
— mysql> COMMIT;

Sesja 2
mysql> UPDATE tab SET f = 55 WHERE f=5;
mysql> UPDATE tab SET f = 55 WHERE f=5;
+------+
| f |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
+------+

Zakleszczenia
Sesja 1 Sesja 2
Aktualizacja wiersza 14
Obie sesje zablokują się i po krótkiej przerwie pojawi się komunikat

ERROR: Dead lock detected
Sesja, w której pojawił się komunikat o zakleszczeniu jest anulowana, natomiast

druga jest kontynuowana.
Jak nie dopuszczać do zakleszczeń?

1) Transakcja powinna dotyczyć pojedynczej aktualizacji
2) Gdy zachodzi potrzeba aktualizacji kilku wierszy w jednej transakcji należy we
wszystkich takich transakcjach przetwarzać wiersze w takiej samej kolejności
3) Zastosować jawną blokadę
Zapobieganie zakleszczeniom - timeout
Gdy transakcja czeka bezczynnie na zwolnienie

blokady dłużej niż ustalony okres oczekiwania
timeout, transakcja zostaje wycofana przez
system.

Zjawisko "zagłodzenia" transakcji
— Nawet jeśli nie będziemy dopuszczać do zakleszczenia,

mogą wystąpić "pechowe" transakcje, które będą
wielokrotnie wybierane do wycofania i w konsekwencji
mogą nigdy nie doczekać się realizacji.
— Przypisz transakcji priorytet, związany z momentem
pierwszej próby jej realizacji (nazywany też znacznikiem
czasowym). Wycofuj transakcję w cyklu, która ma
najniższy priorytet. Z czasem transakcja uzyskuje coraz
wyższy priorytet i w końcu "wygra" z innymi, później
rozpoczętymi transakcjami.

SAVEPOINT
mysql> SAVEPOINT identyfikator

mysql> ROLLBACK TO SAVEPOINT identyfikator
— Wyrażenie SAVEPOINT ustawia pewne miejsce w transakcji o nazwie
identyfikator. Jeśli jakaś transakcja ma już oznaczone w taki sam sposób (za
pomocą tego samego identyfikatora) miejsce, wówczas to miejsce jest
zamazywane przez nowe miejsce.
— Wyrażenie ROLLBACK TO SAVEPOINT cofa transakcję do punktu
oznaczonego przez identyfikator. Identyfikatory, które zostały ustawione
po identyfikatorze, do którego odwołaliśmy się w poleceniu ROLLBACK TO
SAVEPOINT są usuwane.
— Jeśli wyrażenie ROLLBACK TO SAVEPOINT zwraca błąd
ERROR 1181: Got error 153 during ROLLBACK
to oznacza to, że nie istnieje miejsce oznaczone przez identyfikator, do
którego się odnosiliśmy.
— Jeśli użyjemy zwykłego COMMIT lub ROLLBACK, wówczas wszystkie
identyfikatory miejsc zostaną usunięte.

Nie wszystko można cofnąć
— Niektóre polecenia SQL nie mogą być cofnięte, pomimo tego,

że wykonywane będą w transakcji. Należą do nich, generalnie,
wszystkie polecenia języka DDL, czyli takie, za pomocą których
tworzymy lub usuwamy bazy danych, albo tworzymy lub
usuwamy tablice w obrębie bazy.
— Należy tak zaprojektować transakcje, aby nie wykonywać w jej
obrębie takich poleceń. Jeśli w obrębie transakcji użyjemy
polecenia, za pomocą którego utworzymy tablicę, a następnie
użyjemy polecenia, które nie zostanie poprawnie wykonane z
powodu jakiegoś błędu, wówczas trzeba się liczyć z tym, że po
wykonaniu polecenia ROLLBACK nie wszystkie efekty
wykonania różnych poleceń zostaną cofnięte.

Wyrażenia, które wywołują automatycznie COMMIT
— Niektóre polecenia automatycznie kończą transakcję pomimo

tego, że nie wykonamy explicite polecenia COMMIT.
— ALTER TABLE, BEGIN, CREATE INDEX, DROP DATABASE,
DROP INDEX, DROP TABLE, LOAD MASTER DATA, LOCK
TABLES, RENAME TABLE, SET AUTOCOMMIT=1, START
TRANSACTION, TRUNCATE TABLE
— Polecenie UNLOCK TABLES kończy transakcję ze skutkiem

COMMIT nawet jeśli jakieś tablice są w danym momencie
zablokowane.

Bazy danych NoSQL
Zalety relacyjnych baz danych
• Możliwość trwałego składowania danych – po utracie
zasilania i ponownym uruchomieniu serwera, nasze
dane nadal tam się znajdują.
• Relacyjne bazy danych oferują większą elastyczność
niż system plików, kiedy chcemy uzyskać dostęp do
pewnych fragmentów informacji, a nasza baza jest duża
– realizuje się to w miarę szybko.
• Współbieżność
• Transakcyjność - obsługa błędów
• Język SQL – jego dialekty w różnych systemach,
dostarczanych przez każdego z dostawców, są podobne,
a np. mechanizmy transakcji działają prawie tak samo.
Wady
• W bazach transakcyjnych ACID przeszkadza w pracy w
klastrze.
• Model danych w relacyjnych bazach danych jest mniej
elastyczny, niż w przypadku rozwiązania z rodziny
NoSQL.
• Różnice pomiędzy modelem relacyjnym a obiektowym
• Wyraźny podział części ekstensjonalnej i intensjonalnej
• Zmiana struktury istniejącej bazy danych wymaga
dużego wysiłku
• "bagaż starego kodu" - problem software'owy
Charakterystyka baz NoSQL
• NoSQL = Not Only SQL (tak twierdzą entuzjaści,
rzeczywistość jest nieco inna)
• Brak schematu – zbiory danych nie mają określonej
struktury (np. każdy wiersz może wyglądać zupełnie
inaczej – tzn. mieć inne kolumny)
• Architektura Shared Nothing
– węzły są równorzędne i niezależne
– brak maszyn, których uszkodzenie powodowałoby awarię
systemu (no single point of failure)
– Replikacja – dane są zwielokrotnione na wielu węzłach
klastra (replikach)
– Sharding – podział danych na rozłączne partycje
ACID vs BASE
• ACID
– Atomicity (atomowość transakcji) – operacje zawarte
w transakcji wykonają się w całości albo wcale
– Consistency (spójność) – stan bazy danych po
zatwierdzeniu transakcji będzie spójny – tzn. zgodny
ze wszystkimi nałożonymi na niego ograniczeniami
– Isolation (izolacja) – jedna transakcja nie będzie
widziała przejściowego stanu bazy danych
spowodowanego przez niezakończoną inną transakcję
– Durability (trwałość) – kiedy dane zostaną
zatwierdzone przez transakcję będą one utrwalone
ACID vs. BASE
• BASE – Basically Available, Soft state,
Eventually consistent
– Większość danych dostępna przez cały czas
– Dane wystarczająco świeże
– Osiągnięcie spójności odsunięte w czasie, ale
osiągalne
ACID vs BASE
ACID BASE
• Silna spójność • Słaba spójność
• Izolacja • Wysoka dostępność
• Transakcje i • Przybliżone odpowiedzi
zagnieżdżone • Optymistyczne
transakcje podejście do
• Pesymistyczne wielodostępu
podejście do • Szybsze i łatwiejsze
wielodostępu • Brak schematu
• Schemat danych
Twierdzenie CAP (Brewer'a)
Consistency
(spójność) - wszystkie
węzły mają jednakowe
dane
Availability
(dostępność)– każde
żądanie doczeka się
odpowiedzi
C Partition tolerance-
odporność na utratę
części węzłów
A P
Twierdzenie CAP (Brewer'a)
C
Te trzy cechy nie mogą

współistnieć w jednym,
rozproszonym,
systemie przetwarzania danych
– optymalizuje się dwie z nich
A P
Określenie priorytetów baz NoSQL
• Wydajny zapis • N – liczba replik

przechowujących te
• Wydajny odczyt
same dane
• Wysoka spójność
• R – liczba replik, z
których pobierane są
dane podczas żądania
odczytu
• W – liczba replik, do
których zapisywane są
dane podczas żądania
zapisu
Przypadki charakterystyczne
• Wysoka spójność, bardzo szybki odczyt
– R = 1, W = N
• Wysoka spójność, bardzo szybki zapis
– R = N, W = 1
• Niska spójność, bardzo szybki odczyt i zapis
– R = 1, W = 1
• Spójność jest zachowana gdy
– R + W >= N + 1
Bazy NoSQL i CAP
Typy baz danych:

Consitency ■ Relacyjne
■ Grafowe
■ Klucz-wartość
Hbase
MySQL BigTable ■ Dokumentów
PostgreSQL MongoDB
Neo4J ■ ColumnFamilly
Redis
BarkeleyDB
Cassandra
Voldemort
Dynamo
Partition
Availability tolerance
CauchDB
Riak
12
Typy baz danych NoSQL
• Klucz-wartość
• Dokumentowe
• Rodziny kolumn
• Grafowe
• Obiektowe
• Najprostsza implementacja NoSQL.
• Tablica asocjacyjna (pary klucz-wartość)
– Memcached, Redis, BarkeleyDB, DynamoDB, Riak
• Przykładowy kod Redis:
$redis = Redis::connection();
$redis->set('company', 'Grupa Tense');
$company= $redis->get('company');
echo $company;
• Różnice w stosunku do wbudowanych tablic asocjacyjnych (std::map)
– Transakcje (ale błąd nie przerywa wykonania!)
– Potrafi przerwać transakcję jeśli nastąpiła zmiana przed wykonaniem
– Jeden serwer – wielu użytkowników
– Replikacja
– TCP/IP
• Stosowane podczas optymalizacji i skalowania
– dane które nie zmieniają się przy każdym odświeżeniu strony jak np. tytuł
strony www
– skrypty które długo się wykonują
• Klucz-wartość vs. RDBMS
– Zaleta: szybkie
– Wady: cała reszta
REDIS
• Remote Dictionary Server
• Magazyn rekordów klucz-wartość.
• Rezyduje w pamięci RAM
• Zapisywanie danych na dysk:
– RDB – wykonujący snapshot bazy (dobra
wydajność, ale ryzyko utraty danych)
– AOF – tworzący log z informacjami o operacjach
zapisu (gorsza wydajność, ale mniejsze ryzyko
utraty danych – zależna od naszej konfiguracji)
Cechy szczególne
• Wsparcie dla transakcji
• TTL – możliwość zdefiniowania czasu życia rekordu
• Obsługa ciut bardziej rozbudowanych struktur danych (sety)
• Wsparcie dla replikacji
• Wsparcie dla partycjonowania danych
• Obsługa rekordów jako LRU (Least Recently Used -
usuwanie w pierwszej kolejności najrzadziej używanych)
• Wsparcie dla osadzonych skryptów w języku LUA
• Obsługa publish-subscribe (więcej za chwilę)
• Dobra baza bibliotek dla większości popularnych języków
programowania
Dodatkowe struktury danych
• List: sekwencje uporządkowanych wartości z możliwością dodawania na końcu lub
początku listy, ze wsparciem dla operacji POP (pobieranie i usuwanie wartości) oraz
TRIM (usuwanie wartości spoza podanych indeksów)
• Hash: pary klucz-wartość istniejące w ramach wyższego klucza.
• Set: sekwencja nieuporządkowanych, unikalnych wartości.
• Sorted set: sekwencja posortowanych, unikalnych wartości. Każda wartość
sortowana jest za pomocą dodatkowej wartości score.
Typowe zastosowanie
• Cache dla systemów rozproszonych
– TTL,
– Least Recently Used,
– in-memory
• Magazyn sesji w systemach rozproszonych –
szczególnie jeśli mamy REST API na wielu
instancjach i chcemy zapewnić uwspólnioną
obsługę tokenów.
• Rankingi –Sorted SetKolejki
• Skalowalny pub/sub
Przykład - Publish/Subscribe
• Wzorzec ten najprościej porównać do zasady funkcjonowania kanałów IRC.
W realizacji Pub/Sub biorą udział:
– Nadawcy, którzy wysyłają wiadomości
– Odbiorcy, którzy te wiadomości otrzymują
• C#:
– Najpierw: Install-Package StackExchange.Redis
namespace RedisCsSample
{
class Program
{
static void Main(string[] args)
{
var connector = ConnectionMultiplexer.Connect("127.0.0.1:6379");
var sub = connector.GetSubscriber();
sub.Subscribe("chat", (c, m) => Console.WriteLine(m));
while (true)
{
sub.Publish("chat", Console.ReadLine());
}
}
}
}
• Za pomocą ConnectionMultiplexer.Connect(„”) obsługujemy połączenie z Redisem

• Za pomocą metody Subscribe rejestrujemy się jako odbiorca wiadomości. Metoda
ta ma dwa parametry – pierwszy wskazuje nazwę kanału, a drugi metodę, która ma
zostać wykonana po otrzymaniu wiadomości. Metoda ta operuje na dwóch
argumentach: c – kanał, m-wiadomośći
• Metody Publish pozwala na przesłanie wiadomości dla danego kanału.
Kolejny przykład, ServiceStack.Redis
string host = "localhost";
string elementKey = "testKeyRedis";
using (RedisClient redisClient = new RedisClient(host))

{
if (redisClient.Get<string>(elementKey) == null)
{
// adding delay to see the difference
Thread.Sleep(5000);
// save value in cache
redisClient.Set(elementKey, "some cached value");
}
// get value from the cache by key
message = "Item value is: " + redisClient.Get<string>("some cached value");
}
I jeszcze jeden przykład
• Na następnym slajdzie:
• Silne typowanie
• Dwie klasy, Phone i Person
• Każdy telefon ma referencję do właściciela
public class Phone if (phoneFive == null)
{ {
public int Id { get; set; } Thread.Sleep(5000);
public string Model { get; set; } phoneFive = new Phone
public string Manufacturer { get; set; } {
public Person Owner { get; set; } Id = 5,
} Manufacturer = "Motorolla",
Model = "xxxxx",
public class Person Owner = new Person
{ {
public int Id { get; set; } Id = 1,
public string Name { get; set; } Age = 90,
public string Surname { get; set; } Name = "OldOne",
public int Age { get; set; } Profession = "sportsmen",
public string Profession { get; set; } Surname = "OldManSurname"
} }
};
using (RedisClient redisClient = new // adding Entry to the typed entity set
RedisClient(host)) phones.SetEntry(phoneFive.Id.ToString(),
{ phoneFive);
IRedisTypedClient<phone> phones = }
redisClient.As<phone>(); message = "Phone model is " +
Phone phoneFive = phones.GetValue("5"); phoneFive.Manufacturer;
message += "Phone Owner Name is: " +
phoneFive.Owner.Name;
}
Bazy zorientowane dokumentowo
• Dokumenty to samoopisujące się, hierarchiczne struktury drzewiaste
• Mogą składać się z map, kolekcji i wartości
• Przechowywane dokumenty są do siebie podobne, ale nie muszą być
dokładnie takie same
• Dane w postaci dokument-klucz-wartość.
– Przykładem bazy danych kluczem wartość jest np. MongoDB, RavenDB,
CoachDB.
MongoDB
• OpenSource
• Stand alone
• Komercyjne/community
• Cloud
• Start: 2010
• Założenia:
– łatwa skalowalność pozioma
– magazyn danych dla aplikacji internetowych
• W MongoDB
– Brak SQL ( Mongo używa własnego języka zapytań )
– Brak schematu bazy danych
– Wysoka wydajność kosztem złamania zasady ACID
– Brak złączeń
RDBMS MongoDB
– Brak złożonych transakcji
• Izolacja na poziomie jednego dokumentu baza danych baza danych
• Izolacja nie działa w rozproszonym środowisku tabela kolekcja
• Read uncommitted
wiersz dokument
MongoDB
• Dokumentowy model danych
• Zapytania "ad hoc"
• SQL
SELECT * FROM people INNER JOIN people_groups ON people.id =

people_groups.person_id INNER JOIN groups ON people_groups.group_id =
group.id WHERE groups.type = 'news' AND people.age > 20;
• MongoDB Query
db.people.find({'groups': 'news', 'age': {'$gt': 20}});

MongoDB
• Kompromis pomiędzy szybkością a trwałością danych
• W MongoDB klient nie czeka na potwierdzenie skuteczności operacji na
serwerze – wzrost wydajności, konieczność „ręcznej” obsługi błędów
Rodzina kolumn
• Podstawową jednostką przechowywania danych jest
kolumna.
• Kolumna to para nazwa: wartość, gdzie nazwa jest
kluczem dla wartości.
• Dane są przechowywane w postaci wierszy, do których
jest przypisany klucz.
• To z kolei rozszerza się na rodzinę kolumn.
• Przykłady
– Cassandra
– Hbase
– Azure Tables
– BigTable
Cassandra
• Apache.org
• Szybka i skalowalna baza do obsługi dużych ilości (nie)ustrukturyzowanych danych
• Odporność na awarię, liniowa skalowalność oraz szybki czas dostępu do danych
• Architektura typu RING clustering
• Założenie: błędy systemowe jak i awarie sprzętowe mogą i zdarzają się, a
Cassandra jest na nie odporna.
• Posiada wbudowany mechanizm replikacji ze wsparciem dla jednego DC lub
rozproszonego środowiska typu cloud.
• Ponoć speedup N*0,5
• Cassandra Query Language (CQL) lub poprzez dostępne drivery. Podobny do SQL.
• Klient łącząc się do jednego z węzłów Cassandry wykorzystuje go jako Proxy (tzw.
koordynator), który analizując strukturę klastra wskazuje, do którego węzła ma
trafić zapytanie.
• Cassandra nie wspiera złączeń – rozwiązaniem ma być denormalizacja
• Podstawowym protokołem wykorzystywanym do komunikacji pomiędzy węzłami
jest gossip (peer-to-peer).
Cassandra
• Wiersze indeksowane kluczem
• Tabele podzielone na tablety o ciągłych przedziałach kluczy.
• Odczyty z i zapisy do jednego wiersza są atomowe (niezależnie od liczby
kolumn).
• Kolumny są grupowane w tzw. rodziny kolumn, w których ustala się klucze
(de facto indeksy).
• Brak wsparcia transakcji
• Zapis:
– Zapisy do CommitLog.
– CommitLog zapisywany co pewien czas
– Potem zapisy do Memtable.
– Memtable to cache wierszy indeksowanych kluczem; po przepełnieniu…
– Flush - powoduje sortowanie wierszy w Memtable po kluczu i sekwencyjny
zapis. W wyniku powstaje struktura SSTable.
– Odczyt potencjalnie zbiera kawałki danych z wielu SSTable na dysku i
Memtable w RAM.
Cassandra - ograniczenia
• Brak joinów i podzapytań
• Wszystkie dane w pojedynczym tablecie (od tabeli, nie urządzenia) muszą
zmieścić się na pojedynczej maszynie w klastrze.
• Klucze wierszy nie mogą przekraczać 64 KB.
• Maksymalna liczba komórek (wiersze × kolumny) w pojedynczym tablecie
to 2 miliardy.
• Jedna kolumna nie może przekraczać 2GB
Bazy grafowe
• Baza danych, która
wykorzystuje struktury grafów
z węzłami.
• Węzeł – instancja obiektu
• Krawędź – relacja
• Własności – atrybuty
• Przykłady:
– Neo4J
– FlockDB – uproszczona, „wide
but shallow network graphs” –
pierwotnie stworzona do
obsługi Twittera
• Zalety:
– Łatwa realizacja zapytań
rekurencyjnych
Neo4J
• Model danych: property-graph
• Węzeł i relacja posiadają cechy (properties)
• Węzły mają do N etykiet
• Naturalna realizacja M:N
• Język Cypher
dlaczego Neo4j
• pełne wsparcie dla transakcji ACID
• możliwość rozproszenia po wielu serwerach (w
wersji komercyjnej)
• do 34 mld węzłów, 34 mld krawędzi, 68 mld
atrybutów,
• unikanie operacji JOINdynamiczna struktura,
możliwość dodawania i
• usuwania atrybutów z węzła,
dlaczego Neo4j
• generyczne węzły i krawędzie, brak ich typowania,
• indeksowanie w oparciu o Apache Lucene,
• łatwość projektowania (whiteboard-friendliness),
• możliwość osadzania bazy w aplikacji i używania API w języku Java\
• możliwość postawienia samodzielnej instancji i obsługi przez API
RESTowe,
• możliwość wydawania zapytań w językach Gremlin i Cypher,
• graficzna, przeglądarkowa konsola serwera,
• narzędzia wspierające programowanie (biblioteki implementujące
API RESTowe oraz wspierające operowanie danymi, środowisko
Neoclipse),
• importer skryptów SQL,
• wsparcie dla technologii semantycznych (RDF, SPARQL)
dane w Neo4j
• dane w bazie danych przechowywane są w
węzłach i w krawędziach
• każdy węzeł oraz krawędź posiadają atrybuty
opisane przez parę klucz-wartość
• obowiązkowym atrybutem jest id nadawane
przez bazę danych
• krawędzie dodatkowo posiadają obowiązkowy
atrybut type, określający typ relacji
Cypher
• W pierwszej linii: wyszukaj (MATCH)
wszystkich znajomych-znajomych
(friend_of_friend) węzła joe
• Znajomy to osoby które są w odległości 2
relacji znajomości -[:knows*2..2]- od węzła
joe.
• W drugiej linii: węzeł joe to taki, którego imię
to
– Joe –joe.name = ‚Joe’
– nie chcemy, żeby baza zarekomendowała nam
osoby, które Joe już zna AND NOT (joe-
[:knows]-friend_of_friend).
• Zwracamy liczbę wspólnych znajomych (ile
razy dana osoba pojawiła się jako znajomy
znajomego) oraz imię tej osoby
NewSQL
• Jeden z pionierów baz danych, Michael Stonebraker,
główny architekt bazy Ingres, obecnie CTO w VoltDB
problem widzi w "starym SQL". Jego zdaniem systemy
RDBMS mają w sobie linie kodu napisane jeszcze w latach
80-tych. "Oracle nie jest skalowalny, bo dźwiga bagaż
starego kodu".
• Stonebreaker rozwiązanie widzi w "NewSQL" który
zachowuje język SQL i relacyjny model jak również spełnia
zasady ACID (atomowość, spójność, izolację, trwałość) a
przy tym oferuje wydajność i skalowalność. NewSQL
pozbywa się zasobożernej puli buforów - baza pracuje w
podstawowej pamięci serwera czy potrzebę stosowania
zapadek (latching) dzięki pracy bazy w jednym wątku
serwera.
CocroachDB
• Ex-Googlers
• Supports SQL92 (mostly)
• v1.0-rc.1, May, 1st, 2017
MongoDB
JSON - JavaScript Object
Notation.
• „Lekki”, tekstowy format wymiany danych.
• Niezależny od języka programowania i systemu
operacyjnego. JSON wykorzystuje składnię JavaScript
do opisu obiektów, ale mimo to nadal zachowuje
niezależność od języka i platformy.
• Biblioteki parsujące format JSON są dostępne dla
większości języków programowania.
• JSON to format samoopisujący się i łatwy do
zrozumienia. Zbudowany na bazie dwóch struktur:
• kolekcji par klucz-wartość,
• uporządkowanej listy wartości.
JSON vs. XML
{
"dane" : {
"user" : [
{
"imie" : "Jan",
"nazwisko" : "Kowalski"
},
{
"imie" : "Pi otr ",
"nazwisko" : "Nowak"
}
]
}
}
XML
<?xml version="1.0" encoding="utf-8"?>
<dane>
<user>
<imie>jan</imie>
<nazwisko>Kowalski</nazwisko>
</user>
<user>
<imie>Piotr</imie>
<nazwisko>Nowak</nazwisko>
</user>
</dane>
JSON vs. XML
• Podobieństwa:
• format tekstowy (plain text)
• samoopisujący się i czytelny dla użytkownika
hierarchiczny (obiekty wewnątrz innych obiektów)
• Różnice:
• brak znaczników zamykających krótszy
• szybszy zapis i odczyt wykorzystuje tablice
• brak zastrzeżonych słów kluczowych
Kolekcja par nazwa-wartość
• Kolekcja par klucz-wartość jest umieszczana w
nawiasach klamrowych i może zawierać wiele par
nazwa/wartość.
• Nie jest uporządkowana.
• Można ją nazywać obiektem, strukturą, tablicą
hashowaną czy asocjacyjną, słownikem.
{
"imie" : "Piotr", "nazwisko" : "Nowak"
}
Uporządkowana lista wartości
• Uporządkowana lista wartości jest umieszczana w
nawiasach kwadratowych. Może zawierać wiele
wartości.
• Można ją nazywać tablicą, wektorem, listą czy
sekwencją.
"studenci":[
{"imie":"James", "nazwisko":"Bond"},
{"imie":"Jaś", "nazwisko":"Fasola"},
{"imie":"Angus", "nazwisko":"McGyver"}
]
Typy
• Wartości JSON to:
• liczby (integer lub float)
• ciągi znakowe (string w podwójnych cudzysłowach)
wartości logiczne (true lub false)
• tablice (w nawiasach kwadratowych)
• obiekt (w nawiasach klamrowych)
• wartość null
BSON
• Binary JSON - http://bsonspec.org/
• binarna serializacja dokumentów w formacie JSON
• tak samo jak JSON, wspiera zagnieżdżanie dokumentów
i tablic wewnątrz innych dokumentów czy tablic
• zawiera również rozszerzenie pozwalające na
reprezentację danych nie będących formatem JSON,
np. posiada typy Date czy BinData
• jest binarnym formatem wymiany danych
• biblioteki dla BSON istnieją dla większości
współczesnych języków programowania; część
implementacji obsługi BSON jest częścią sterownika do
bazy MongoDB
BSON
• Lekkość - minimalny narzut na zajmowaną
przestrzeń; bardzo ważne dla każdego formatu
reprezentacji danych, szczególnie w
zastosowaniach internetowych.
• Łatwość przeszukiwania/przeglądania - BSON został
zaprojektowany aby dało się go łatwo przeszukiwać;
cecha konieczna dla głównego formatu
przechowywania danych w MongoDB.
• Efektywność - kodowanie/dekodowanie danych
do/z formatu BSON jest bardzo szybkie w
większości języków programowania.
Instancja bazy danych dokumentów
• Każda instancja bazy dokumentów może posiadać wiele baz.

• Każda baza składa się z wielu kolekcji.
• Kolekcje zawierają zbiór dokumentów.
Bazy danych dokumentów
• Bazy danych dokumentów:
• dokumenty są głównym składnikiem,
• format dokumentów: XML, JSON, BSON i inne,
• są do siebie podobne ale mogą się różnić - nie ma
schematu.
• Dokumenty:
• samoopisujące się,
• hierarchiczne struktury drzewiaste,
• mogą składać się z map, kolekcji, wartości skalarnych.
Bazy danych dokumentów
• Bazy danych dokumentów:
• zapewniają elastyczność baz NoSQL,
• pozwalają na zarządzanie bardziej złożonlymi
strukturami niż te w bazach klucz-wartość,
• nie wymagają definiowania wspólnej struktury,
• jest możliwe filtrowanie czy odpytywanie kolekcji
dokumentów (podobnie do bazy relacyjnej),
• inna składnia zapytań niż w bazach relacyjnych ale
podobna funkcjonalność.
Więcej o dokumentach
• Dokumenty:
• różne dokumenty mogą znajdować się w jednej kolekcji,
dokumenty mogą mieć różne nazwy atrybutów,
• brak pustych atrybutów - jak nie ma wartośći to po
prostu nie ma atrybutu,
• możliwość dodawania nowych atrybutów w każdej
chwili.
Baza danych MongoDB
• https://www.mongodb.org/
• open-source,
• baza danych dokumentów,
• nie potrzeba mapowania obiektowo-relacyjnego
(ORM), łatwa w wykorzystaniu i skalowaniu,
• zawiera swój własny język zapytań, obecna wersja
to 3.2.
MongoDB
• OpenSource
• Stand alone
• Komercyjne/community
• Cloud
• Start: 2010
• Założenia:
• łatwa skalowalność pozioma
• magazyn danych dla aplikacji internetowych
RDBMS MongoDB
• W MongoDB
baza danych baza danych
• Brak SQL ( Mongo używa własnego języka zapytań )
tabela kolekcja
• Brak schematu bazy danych
wiersz dokument
• Wysoka wydajność kosztem złamania zasady ACID
• Brak złączeń
• Brak złożonych transakcji
• Izolacja na poziomie jednego dokumentu
• Izolacja nie działa w rozproszonym środowisku
• Read uncommitted
MongoDB
• Dokumentowy model danych
• Zapytania "ad hoc"
• SQL
SELECT * FROM people INNER JOIN people_groups ON people.id =
people_groups.person_id INNER JOIN groups ON people_groups.group_id =
group.id WHERE groups.type = 'news' AND people.age > 20;
• MongoDB Query
db.people.find({'groups': 'news', 'age': {'$gt': 20}});
(Auto-)sharding
• Partycjonowanie horyzontalne – wiersze jednej tabeli przechowywane w
rozproszeniu
• W podstawowej wersji partycjonowania dzielone są indeksy, serwer logiczny jest jeden
• Sharding - każda partycja tworzy shard (odłamek), może być ulokowany na

odrębnym serwerze
• Zalety
• Redukcja wierszy w fizycznych tabelach
• Zmniejszone rozmiary indeksów, szybsze przeszukiwanie i przeindeksowywanie
• Zrównoleglenie sprzętowe
• Separacja geograficzna
• Wady
• Uzależnienie od łączy
• Dodatkowe opóźnienia podczas przeszukiwania angażującego wiele partycji
• Specyficzne zapytania są szybkie, inne bardzo powolne
• Spójność i trwałość w przypadku awarii
• Autosharding - baza danych jest automatycznie i niewidocznie

partycjonowana pomiędzy węzły, umozliwiając skalowanie (scale-out) zapisów
i odczytów bez ingerencji w aplikację
MongoDB - sharding
• Replikacja
• Skalowanie odczytów z bazy danych
• Zbiór replik składa się z jednego głównego serwera oraz kilku
podrzędnych
• Operacje zapisu są możliwe jedynie na głównej maszynie.
• Auto-sharding - skalowanie w poziomie
MongoDB
"grades" : [
"_id" : ObjectId("54c955492b7c8eb21818bd09"), {
"address" : { "date" : ISODate("2014-10-01T00:00:00Z"),
"street" : "2 Avenue", "grade" : "A",
"zipcode" : "10075", "score" : 11
"building" : "1480", },
"coord" : [ -73.9557413, 40.7720266 ] {
}, "date" : ISODate("2014-01-16T00:00:00Z"),
"borough" : "Manhattan", "grade" : "B",
"cuisine" : "Italian", "score" : 17
}
],
"name" : "Vella",
"restaurant_id" : "41704620"
}
MongoDB - zastosowania
• Kompromis pomiędzy szybkością a trwałością danych
• W MongoDB klient nie czeka na potwierdzenie skuteczności operacji na
serwerze – wzrost wydajności, konieczność „ręcznej” obsługi błędów
• Gdzie warto użyć?
• Serwisy internetowe
• Zwykle są to portale społecznościowe, portale informacyjne, serwisy o
globalnym zasięgu, cechujące sie dużą ilością odczytów z bazy w stosunku
do operacji zapisów. MongoDB pozwala na wydajne skalowanie np. na
podstawie położenia geograficznego.
• BigData (Klikmapy, logowanie)
• Analiza bardzo dużej ilość informacji o różnej strukturze. MongoDB świetnie
sprawdza się w tej roli dzięki elastycznym schematom danych oraz
możliwości zapisu danych bez potwierdzania.
MongoDB - zastosowania
• Kiedy unikać?
• Systemy wymagające złożonych transakcji
• System bankowy oparty o MongoDB to zdecydowane nieporozmienie ;)
• Zwykłe aplikacje
• Jeśli schemat jest znany, a ilość zapisów duża
• MongoDB vs. Redis
• Kiedy używać MongoDB
• nie ma pewności co do struktury danych (systemy na początku rozwoju)
• W systemach prototypowych/rozwojowych
• Kiedy używać Redis
• Do przyspieszania istniejących aplikacji (jako cache)
• Raczej nie jako jedyny serwer bazy danych
• Kiedy na prawdę wydajność jest kluczowa
MongoDB - relacje
• Referencje
• Embedded Data
MongDB - CRUD
• Odczyt
• metoda find umożliwia tworzenie zapytań
• bez żadnych parametrów - > cała kolekcja; parametr 1 – warunek, parametr 2 - zawężenie
• find zwraca kursor, który służy do iteracji po wynikach zapytania
• Do wyniku można dodawać modyfikatory (sortowanie, zliczenie)
• Wstawianie
• insert na odpowiedniej kolekcji.
• Obiekt w formacie JSON o dowolnej strukturze.
• Każdy dokument w kolekcji musi mieć unikalne _id; Mongo automatycznie doda klucz
• Próba dodania obiektu z id, które już w bazie istnieje zakończy się niepowodzeniem
MongoDB - CRUD
• Aktualizacja
• Update (kryterium, akcja, opcje)
• MongoDB domyślnie aktualizuje tylko jeden dokument
• Usuwanie
• Remove(kryterium)
• bez parametrów usuwa zawartość całej kolekcji
MongDB - grupowanie
• Pipelines
• Map/Reduce
• Single Purpose Aggregtion
Pipelines
• Dokumenty przechodzą stopniowo przez kolejne stadia obróbki
• $project - wybranie tylko określonych pól z dokumentów
• $match - filtruje dokumenty wedle określonego kryterium
• $group- dokonuje grupowania elementów, jest to faktyczne miejsce agregowania wyników
• $sort - sortowanie dokumentów według zdefiniowanych pól
• $skip - pomija n dokumentów z listy
• $limit - określa maksymalną liczbę dokumentów, które mają zostać przetworzone
• $unwind - używane gdy chcemy zastąpić dokument zawierający tablicę wartości, zbiorem dokumentów, które w
polu reprezentującym rozwijaną tablicę będą posiadały kolejne elementy wcześniejszej tablicy
db.students.aggregate({
$unwind: "$scores" db.students.aggregate({
}, { $project: {
$group: { name: 1,
_id: "$name", _id: 0
scores_sum: { $sum: "$scores.score"} }
} }, {
}, { $sort: {
$sort: { scores_sum: -1 } name: 1
}, { }
$limit: 10 })
})
Map/Reduce
• Map - funkcja stosowana jest do wszystkich dokumentów spełniających
warunki wyszukiwania. Jej głównym zadanie jest wyemitowanie par
(klucz, wartość)
• pary (klucz, wartość) eksportujemy przy użyciu funkcji emit(key,value)
• funkcja map nie przyjmuje żadnych parametrów
• funkcja map jest wywoływana na instancji dokumentu, więc mamy
możliwość dostęp do self
• Reduce - w przypadku, gdy w fazie mapowania zostaną wyemitowane
pary o tym samym kluczu, wartości elementów o wspólnym kluczu
poddawane są fazie redukowania - ma ona na celu skondensowanie
kilku wartości do jednej
Map/Reduce
• Operacje realizowane są podczas dwóch kroków:
• Krok "map" - węzeł nadzorczy (master node) pobiera dane z wejścia i dzieli
je na mniejsze podproblemy, po czym przesyła je do węzłów roboczych
(worker nodes). Każdy z węzłów roboczych może albo dokonać kolejnego
podziału na podproblemy, albo przetworzyć problem i zwrócić odpowiedź
do głównego programu.
• Krok "reduce" - główny program bierze odpowiedzi na wszystkie
podproblemy i łączy je w jeden wynik - odpowiedź na główny problem.
• Główną zaletą MapReduce jest umożliwienie łatwego rozproszenia
operacji. Zakładając, że każda z operacji "map" jest niezależna od
pozostałych, może być ona realizowana na osobnym serwerze.
Map/Reduce
var map = function () { db.students1.mapReduce( map, reduce,
for (i = 0; i < 4; i++){ { out: { reduce: "result" }});
emit(this.scores[i].type, this.scores[i].scor
e) db.students2.mapReduce( map, reduce,
} { out: { reduce: "result" }});
};
var reduce = function(key, values) {

return Array.sum(values)
};
db.students.mapReduce(map, reduce,
{out: "sc_sum"})
Map/Reduce na wielu kolekcjach
Suma wszystkich uzyskanych punktów

danego typu
Single Purpose Aggregation
MongoDB ułatwia użytkownikom stosowanie kilku często używanych funkcji
agregacyjnych:
• count - zwraca ilość dokumentów spełniających warunek podany jako argument
funkcji db.students.count({ name :/G/ })
• distinct - zwraca wszystkie unikalne wartości dla określonego pola, dokumentów

spełniających zadane warunki
db.students.distinct("name")
• group - grupuje dokumenty według zadanego pola (lub pól). Zwraca tablicę
dokumentów z obliczonymi rezultatami dla każdej z grup
db.grades.group({
key: {
student_id: 1
},
reduce: function (current, result) {
result.score += current.score
},
initial: {
score: 0
}
})
Embedded czy reference?
• Typ zapytania:
• jakiego typu zapytania będą wykonywane?
• Jeśli dokument nadrzędny niemal zawsze wymaga dostępu do dokumentów podrzędnych ->
osadzony
• Cykl życia danych:
• czy istnienie dokumentów podrzędnych ma sens po skasowaniu dokumentu nadrzędnego?
• Jeśli nie -> osadzony
• Przechowywanie informacji o czasie:
• jeśli przechowujesz informacje „ważne jedynie przez chwilę” (snapshot) -> osadzony
• Przykład: do raportu, aktualne dane z produkcji konkretnego wyrobu
• Ścieżka dostępu:
• jeśli często wymagany jest dostęp do dokumentów podrzędnych, pomijając dane z dokumentu
nadrzędnego -> referencje
• Rozmiar:
• dokument w MongoDB może zajmować maksymalnie 16MB.
• Jeśli ryzyko przekroczenia -> referencje
• Preferowany jest wariant osadzony. Płaski raczej jeśli wymuszony ostatnimi dwoma
kryteriami
MongoDB - porady
• Ile się da w jednym dokumencie
• Głowna zaleta MongoDB to eliminacja złączeń
• Można pobrać część dokumentu
• Nie ma potrzeby normalizacji
• Dane, które mogą być wielokrotnie wykorzystywane do
innych kolekcji
• Zwiększenie spójności danych
• Rozmiar dokumentu
• 16MB (brzmi kiepsko?)
• 30 milinonów tweetnięć
• 250 000 typowych postów StackOverflow
• 20 obrazów z Flickera

Combinewykladybazy

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Combinewykladybazy

Diunggah oleh

Hak Cipta:

Format Tersedia

Modele danych

1960 1970 1980 1990 2000 2010

KodPojazdu Nazwa Typ

KodPojazdu KodCzęści NazwaCzęści

KodPojazdu KodCzęści NazwaCzęści

KodPojazdu Nazwa Typ

KodPojazdu Nazwa Typ

KodPojazdu KodCzęści NazwaCzęści

Carl - członek zespołu (bug-sniffer)

STRATEGIA SPECYFIKACJA MODELOWANIE

• Dane każdej organizacji podlegają nieustannym zmianom.

• Do głównych celów modelowania danych można zaliczyć:

Kartoteka materiałów D1 Przewodnik

Diagram Kontekstowy Proces

Diagram Ogólny "0"

Odpowiedzi na zdarzenia Diagramy zrównoważone

• Diagramy związku encji (Entity Relashinship Diagrams) to metoda

Rzecz mająca znaczenie, rzeczywista lub

Element informacji służący do klasyfikowania,

Znaczący sposób, w jaki mogą być ze sobą

Atrybuty Związek Encja

• Encja (ang. entity) – jest to jednoznacznie identyfikowany składnik

• Atrybut - jest cechą, elementem charakteryzującym encje i związki

numer zamówienia identyfikacja

opis towaru opis werbalny

typ towaru klasyfikacja

ilość towaru w magazynie określenie ilości

status płatności za zamówienie wyrażenie stanu

• nazwa atrybutu musi być unikalna w ramach encji;

Encja – STUDENT Wystąpienia encji:

Encja – SAMOCHÓD Wystąpienia encji:

• Związek stanowi naturalne powiązanie pomiędzy dwoma lub więcej

Każde wystąpienie encji Dziekan jest powiązane tylko

Każde wystąpienie encji Wydział powiązane jest

Każde wystąpienie encji Książka powiązane jest

• dotyczy zaangażowania encji w związek,

Stopień związku Typ zw iązku

jeden - do - jednego związek

• Uczestnictwo (opcjonalność) Moduł

• Wyjątkowe zbiory encji zawierające dodatkowe/specjalizowane

musi być jeden lub wiele

Każdy Klient może złożyć jedno lub wiele Zamówień.

 tworzenie diagramu związków encji najlepiej rozpocząć od

Encja regularna (silna) Istnienie nie jest zależne od

związane jest dotyczy określa

wypożycza rejestruje należy

Silna encja Słaba encja

Klient Określa Preferencje

klientNr (PK) typPreferencji

organizuje na zwa klin iki

doty czy jest wy kony wana przez zawiera

• Konceptualny model danych, którego odzwierciedleniem są diagramy

Atrybut Oznacza kolumnę tablicy (a dokładnie są to różne wystąpienia tego

Klucz główny Kolumna lub kombinacja kolumn, których wartości jednoznacznie

Logiczny m odel danych Relacyjny m odel danych

• encja – relacja – klasa – tabela

KISIM, WIMiIP, AGH

• Podstawową strukturą danych jest relacja będąca podzbiorem iloczynu

KISIM, WIMiIP, AGH

• Każda relacja posiada następujące własności

• Tworzenie modeli relacyjnych nazywane jest modelowaniem związków

KISIM, WIMiIP, AGH

1. Postulat informacyjny – dane są reprezentowane jedynie poprzez