Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Mgr inż. Piotr Greniewski

Podobne prezentacje


Prezentacja na temat: "Mgr inż. Piotr Greniewski"— Zapis prezentacji:

1 Mgr inż. Piotr Greniewski
Bazy Danych Mgr inż. Piotr Greniewski

2 Bazy danych - Materiały
Od podstaw - Bazy danych i PostgreSQL Richard Stones, Neil Matthew wydawnictwo: Helion 2002 r. Podstawy SQL – Ćwiczenia praktyczne Arkadiusz Jakubowski Wydawnictwo: Helion 2001 r. Copyright by Piotr Greniewski

3 Programowanie z wykorzystaniem danych
Niemal wszystkie bardziej złożone aplikacje komputerowe przetwarzają duże ilości danych Większość z nich została stworzona aby przetwarzać dane a nie wykonywać obliczenia 80% wykonywanych przez programistów prac wiąże się ze strukturami przechowywanymi w bazie danych Bazy stanowią ważną podstawę wielu aplikacji Copyright by Piotr Greniewski

4 Programowanie z wykorzystaniem danych
Dane mogą przybierać dowolne formy i rozmiary Sposób w jaki się z nimi obchodzimy zależy od ich natury Dane stałe (dane nie ulegające zmianie w programie np. liczba pi itp..) Dane zmienne (dane zmieniające się w czasie np. kursy walut) Copyright by Piotr Greniewski

5 Programowanie z wykorzystaniem danych
Piszemy program przeliczający waluty krajów członkowskich Eurolandu na EURO Kursy wymiany są stałe (6 miejsc po przecinku z dnia wymiany) Lista krajów ulegać będzie zmianie ponieważ dochodzić będą nowe kraje W związku z tym przy każdym nowym kraju trzeba będzie kompilować program Copyright by Piotr Greniewski

6 Plik danych waluta => EURO
Dużo lepszą metodą będzie skorzystanie przez aplikację z pliku zawierającego: Nazwę waluty Jej symbol Kurs wymiany Francja FRF Niemcy DEM Włochy ITL Belgia BEF Copyright by Piotr Greniewski

7 Kartotekowe bazy danych
Pliki jednorodne lub kartoteki bardzo pożyteczne do zapamiętywania danych w programach. Wygodne w użyciu jeśli nie są przesadnie rozbudowane. Mogą służyć do przechowywania haseł i danych sterujących. Plik jednorodny składa się z kilku elementów informacji (atrybutów). Razem tworzących strukturę, która stanowi rekord. Każdy wiersz reprezentuje pojedynczy rekord Rolą całego pliku jest przechowywanie powiązanych ze sobą rekordów. Copyright by Piotr Greniewski

8 Kartotekowe bazy danych
Rozszerzamy naszą aplikację tak aby zawierała informację o: języku, liczbie ludności i obszarze. W pliku jednorodnym w każdym wierszu znajduje się jeden rekord. Wszystkie rekordy są zestawami pewnej liczby atrybutów. Każdy pojedynczy atrybut zawsze znajduje się w tym samym miejscu (np. symbol waluty zawsze będzie drugim atrybutem). Dane możemy przeszukiwać wg. kolumn, gdy kolumny zawierają informacje tego samego typu. Copyright by Piotr Greniewski

9 Kartotekowe bazy danych
Aby dodać język używany w określonym kraju musimy dodać nową kolumnę. Pojawia się problem, gdy w kraju jest więcej niż jeden oficjalny język. Francja FRF francuski Niemcy DEM niemiecki Włochy ITL włoski Belgia BEF ??? Copyright by Piotr Greniewski

10 Kartotekowe bazy danych
Problem ten określa się terminem powtarzających się grup. Poprawny element w rekordzie powtarza się (Belgia – języki flamandzki i francuski) Pliki jednorodne nie umożliwiają rozwiązania tego problemu, ponieważ niemożliwe jest określenie gdzie kończą się zapisy o językach i zaczyna się reszta rekordu. Jedynym sposobem jest dodanie struktury do pliku ale to już nie będzie plik jednorodny. Copyright by Piotr Greniewski

11 Strukturalne pliki tekstowe
Zbudujemy aplikację opisującą filmy: rok produkcji, reżyser, gatunek oraz obsada [2001: Odyseja kosmiczna] Rok=1968 Reżyser=Stanley Kubrick Gatunek=fantastyka Obsada=Keir Dullea Obsada=Leonard Rossister [Władca Pierścieni] Copyright by Piotr Greniewski

12 Strukturalne pliki tekstowe
Rozwiązaliśmy problem powtarzających się grup przez wprowadzenie pewnych znaczników wskazujących typ każdego elementu w rekordzie. Dalsze problemy z tym zapisem danych Jak sprawdzać poprawność danych? Jak posortować listę wg. filmów danego reżysera? Jak rozszerzać funkcjonalność bazy: np. Kto pożyczył dany film z wypożyczalni? Ile filmów wyprodukowano w 1968 r. Copyright by Piotr Greniewski

13 Co to jest baza danych? Baza danych jest to jest to duży zbiór danych o określonej strukturze, która umożliwia ich szybkie wyszukiwanie i wydobywanie. (www.m-w.com - słownik online Merriama Webstera) Copyright by Piotr Greniewski

14 Co to jest DBMS? System zarządzania bazą danych (DBMS – Data Base Management System) to: zbiór bibliotek aplikacji narzędzi Zwalniają one programistę aplikacji z konieczności pamiętania o szczegółach przechowywania i zarządzania danymi. Dostarczają funkcji wyszukiwania i aktualizacji rekordów. Copyright by Piotr Greniewski

15 Rodzaje baz danych W latach 60–tych i 70-tych opracowywano bazy danych, rozwiązujące problem powtarzających się grup na kilka różnych sposobów. Efektem tych metod było opracowanie mechanizmu, który można określić terminem modelu baz danych. Badania firmy IBM zaowocowały opracowaniem podstaw tych modeli. Sieciowy model baz danych Hierarchiczny model baz danych Relacyjny model baz danych Copyright by Piotr Greniewski

16 Sieciowy model bazy danych
W sieciowym modelu baz danych wykorzystano pomysł wskaźników wewnątrz bazy danych. Rekordy mogą zawierać odwołania do innych rekordów. Nazwa kraju Symbol Kurs Wskaźnik Język n Język n+1 nil Copyright by Piotr Greniewski

17 Sieciowy model bazy danych
Mamy więc metodę wprowadzenia dowolnej ilości języków obowiązujących w danym państwie. Belgia BEF 40.33 francuski flamandzki nil Copyright by Piotr Greniewski

18 Sieciowy model bazy danych
francuski włoski flamandzki nil nil Włochy ITL Francja FRF 6.55 Niemcy DEM 1.95 Belgia BEF 40.33 Tablica krajów Tablica języków Copyright by Piotr Greniewski

19 Sieciowy model bazy danych
Wskaźniki wewnątrz bazy danych czyli rekordy mogą odwoływać się do innych rekordów Dwa typy rekordów każdy przechowywany w innej tablicy Słowniki do przechowywania często powtarzających się nazw. Odnośniki – tzw. Klucze. Pojęcie „nil” lub „puste” oznaczające koniec listy Copyright by Piotr Greniewski

20 Sieciowy model bazy danych
Zalety – wszystkie rekordy jednego typu, powiązane z określonym rekordem innego typu, można znaleźć bardzo szybko idąc według wskaźników od rekordu początkowego. Wady - bardzo ciężko wydobyć informację typu w jakich krajach mówi się po francusku? Copyright by Piotr Greniewski

21 Sieciowy model bazy danych
Tego typu operację można przyspieszyć poprzez stosowanie innych powiązanych list. Powoduje to powstanie nadmiernie złożonej struktury. Pisanie aplikacji dla tego typu baz danych jest bardzo złożone. Copyright by Piotr Greniewski

22 Hierarchiczny model baz danych
W systemie IMS firmy IBM z końca lat 60-tych przedstawiono hierarchiczny model bazy danych. W modelu tym rozwiązanie problemu powtarzalnych grup opiera się na stosowaniu rekordów danych, które są złożone z kolekcji innych rekordów. Copyright by Piotr Greniewski

23 Hierarchiczny model baz danych
Model ten można porównać do zestawienia materiałowego, (BOM – ang. Bill of Material), które zastosowano w celu pokazania złożoności produktu. Samochód składa się z: nadwozia, podwozia, silnika i czterech kół. Silnik jest złożony z: cylindrów, głowicy i wału korbowego Itd. Copyright by Piotr Greniewski

24 Hierarchiczny model baz danych
Głowica Wał korb. Cylindry Silnik Nadwozie Samochód Podwozie 4 Koła Copyright by Piotr Greniewski

25 Hierarchiczny model baz danych
Hierarchiczny model bazy danych wykorzystuje się do dziś. Stosując ten model można zoptymalizować przechowywanie danych i uczynić operację poszukiwania odpowiedzi jeszcze bardziej wydajną. Np. pytając jaki samochód zawiera określoną część? Copyright by Piotr Greniewski

26 Relacyjny model bazy danych
W 1970 r. publikacja E.F. Codda „Relacyjny model danych dla dużych, współdzielonych banków danych” stała się początkiem nowego podejścia do przechowywania danych. Dokument ten przedstawił ideę relacji pokazał sposób wykorzystania tabel do reprezentowania faktów, które są powiązane z obiektami świata rzeczywistego. Relacyjny model bazy danych kładzie duży większy nacisk niż inne modele na integralność danych. Copyright by Piotr Greniewski

27 Relacyjny model bazy danych
RDBMS (ang. Relational Data Base Management) System jest zdefiniowany przez kilka ważnych reguł: rekordy w tabeli określa się terminem krotka (ang. tuple). Krotka to uporządkowana grupa elementów lub atrybutów z których każda posiada zdefiniowany typ, wszystkie krotki w tabeli, mają ten sam wzorzec tzn. posiadają tą samą liczbę komponentów o identycznych typach, w dowolnej tabeli złożonej z krotek nie może być duplikatów, czyli nie mogą wystąpić identyczne wiersze (rekordy), każdy atrybut w rekordzie musi być niepodzielny, Copyright by Piotr Greniewski

28 Relacyjny model bazy danych
RDBMS ciąg dalszy ... atrybut służący do rozróżniania rekordów, które niczym innym się nie różnią nazywa się kluczem, jako klucz może być stosowana kombinacja więcej niż jednego atrybutu, atrybut czyniący rekord unikalnym nazywa się kluczem podstawowym, w relacyjnej bazie danych każda relacja (tabela) musi posiadać klucz podstawowy, reguła integralności odwołań (ang. referential integrity) czyli dążenie do sytuacji, kiedy wszystkie rekordy w bazie danych zawsze mają sens. Copyright by Piotr Greniewski

29 Relacyjny model bazy danych
Wszystkie krotki w tabeli, mają ten sam wzorzec tzn. posiadają tą samą liczbę komponentów o identycznych typach. {Francja, FRF, 6.56} {Belgia, BEF, 40.51} Każda z krotek posiada trzy atrybuty: nazwę kraju (łańcuch znaków) walutę (łańcuch znaków) kurs (liczba zmiennoprzecinkowa) W relacyjnej bazie danych wszystkie rekordy z tej samej tabeli muszą mieć taki sam format. Copyright by Piotr Greniewski

30 Relacyjny model bazy danych
Łatwo sprawdzić ilość i poprawność atrybutów. {Niemcy, DEM } - za mało atrybutów {Szwajcaria, CHF, 1.25, francuski, niemiecki, włoski} za dużo atrybutów { , ITL, Włochy} - niepoprawne typy atrybutów (zła kolejność) Copyright by Piotr Greniewski

31 Relacyjny model bazy danych
Atrybuty muszą pochodzić z tego samego zbioru wartości lub z tej samej dziedziny. - łańcuchy znaków - ‘Francja’ - liczby całkowite – 1234 - liczby zmiennoprzecinkowe – - data – 12 stycznia 2003 - wartości logiczne – true lub false - ... i wiele innych typów... Copyright by Piotr Greniewski

32 Relacyjny model bazy danych
Ostatnią regułą która określa strukturę relacyjnej bazy danych jest integralność odwołań . Jest to dążenie do sytuacji w której wszystkie rekordy w bazie danych mają sens. Programista bazy danych musi uważać aby stworzony przez niego kod nie łamał integralności bazy!!!. Np. mamy tabelę klientów i powiązaną z nią tabelę zamówień. Jeśli usuniemy z tabeli konkretnego klienta, to musimy usunąć związane z nim zamówienia. Jeśli tego nie uczynimy w bazie pozostaną zamówienia nie przypisane do klienta. Copyright by Piotr Greniewski

33 Języki zapytań Relacyjne bazy danych oferują sposoby dodawania i aktualizacji danych, ale ich potęga leży w możliwościach wyszukiwania danych w formie zapytań. Stworzony przez Codda model relacyjny wykorzystuje fakt, że relacje definiują zbiory a zbiory można przetwarzać matematycznie. Zasugerował on że zapytanie może korzystać gałęzi logiki teoretycznej zwanej teorią predykatów. Copyright by Piotr Greniewski

34 Języki zapytań Implementacje języków zapytań: QUEL w bazie Ingres
QBE (Query by example) SQL (Standard Query Language – Standardowy język zapytań) opracowany przez firmę IBM Copyright by Piotr Greniewski

35 Język zapytań SQL Język SQL składa się z trzech rodzajów poleceń:
Język manipulowania danymi (DML) Język definicji danych (DDL) Język sterowania danymi (DCL) Copyright by Piotr Greniewski

36 Język manipulowania danymi (DML)
Język zapytań SQL Język manipulowania danymi (DML) Jest to część SQL, z której korzystamy w 90% przypadków. Składa się z poleceń wstawiania, usuwania i aktualizacji oraz co najważniejsze wybierania danych z bazy. Copyright by Piotr Greniewski

37 Język definicji danych (DDL)
Język zapytań SQL Język definicji danych (DDL) Zawiera polecenia tworzenia tabel oraz polecenia mające wpływ na inne aspekty dotyczące struktury bazy danych Copyright by Piotr Greniewski

38 Język sterowania danymi (DCL)
Język zapytań SQL Język sterowania danymi (DCL) Jest to zbiór poleceń służący do określania uprawnień, jak na przykład definiowania praw dostępu do danych. Wielu użytkowników baz danych nigdy nie skorzysta z tych poleceń, ponieważ wykorzystuje się je w środowiskach większych firm gdzie pracuje jeden lub kilku administratorów bazy danych. Zarządzanie uprawnieniami to zazwyczaj jedno z ich zadań. Copyright by Piotr Greniewski

39 Języki SQL PostgreSQL Microsoft SQL Serwer Oracle SQl MySQL
wiele innych ... Copyright by Piotr Greniewski

40 Definicja tablicy w SQL
CREATE TABLE Student ( Student_id serial, Nazwisko char(50) not null, Imię char(50) not null, Imię_ojca char(10), Wpisowe numeric(7.2) ); Copyright by Piotr Greniewski

41 Wypełnienie tabeli danymi
INSERT INTO Student(Nazwisko,Imię,Imię_ojca,wpisowe) Values(‘Kowalski’,’Jan’,’Maciej’,350.00); Values(‘Malinowski’,’Krzysztof’,’Stefan’,350.00); Copyright by Piotr Greniewski

42 Dostęp do danych SELECT * FROM Student WHERE Nazwisko = ‘Kowalski’;
Kowalski Jan Marek Kowalski Stefan Jan 3 Kowalski Zenon Jan Copyright by Piotr Greniewski

43 Dostęp do danych w języku PostgreSQL
Skorzystać z aplikacji wiersza poleceń w celu wykonania instrukcji SQL. Wstawić kod SQL bezpośrednio do aplikacji (za pomocą wbudowanego SQL). Wykorzystać wywołanie funkcji (API) w celu przygotowania i wykonania instrukcji SQL, skanowania zbioru wyników oraz wykonania aktualizacji z poziomu większości popularnych języków programowania. Uzyskać dostęp do bazy za pomocą sterownika np. ODBC (otwarte połączenie z bazą danych), bądź standardowej biblioteki jak DBI języka Perl. Copyright by Piotr Greniewski

44 Systemy zarządzania bazą danych (DBMS)
System zarządzania bazą danych (DBMS) to zestaw programów umożliwiających skonstruowanie bazy danych i aplikacji które z nich korzystają Funkcje jakie spełnia DBMS obejmują: tworzenie bazy danych, funkcje tworzenia zapytań i aktualizowania danych, wielozadaniowość, utrzymywanie dzienników systemowych, zarządzanie bezpieczeństwem bazy danych, utrzymanie integralności odwołań. Copyright by Piotr Greniewski

45 Tworzenie bazy danych Niektóre systemy zarządzają jednym wielkim plikiem i tworzą w nim co najmniej jedną bazę danych. Inne posiadają możliwość korzystania z plików pochodzących z wielu systemów operacyjnych, albo korzystają z danych zapisanych bezpośrednio w obrębie partycji dysku. Użytkownicy nie muszą przejmować się niskopoziomowymi strukturami tych plików, a system DBMS dostarcza dostęp potrzebny użytkownikom i programistom. Copyright by Piotr Greniewski

46 Funkcje tworzenia zapytań i aktualizowania danych
Systemy DBMS zawierają metody tworzenia zapytań o dane, które spełniają określone kryteria, jak np. wszystkie zamówienia złożone przez określonego klienta, których jeszcze nie zrealizowano. Przed powszechnym wprowadzeniem standardu SQL sposób tworzenia tych zapytań był inny dla różnych systemów. Copyright by Piotr Greniewski

47 Wielozadaniowość Jeżeli baza danych jest wykorzystywana przez kilka aplikacji lub o dostęp do niej w tym samym czasie rywalizuje kilku użytkowników system DBMS zapewnia przetwarzanie każdego żądania użytkownika bez ujemnego wpływu na możliwości korzystania z bazy przez kogoś innego. Oznacza to że użytkownik musi oczekiwać w kolejce gdy ktoś inny modyfikuje ten rekord który użytkownik chce zapisać Copyright by Piotr Greniewski

48 Utrzymywanie dzienników systemowych
System DBMS przechowuje dzienniki wszystkich zmian danych dokonanych w ciągu pewnego okresu czasu. Funkcję tę można wykorzystać do śledzenia błędów. Jej ważną cechą jest możliwość rekonstrukcji danych w przypadku awarii systemu. Zazwyczaj utrzymywanie dzienników systemowych wykorzystuje się do tworzenia rejestru transakcji oraz kopii zapasowej danych. Copyright by Piotr Greniewski

49 Zarządzanie bezpieczeństwem bazy danych
DBMS zapewnia kontrolę dostępu do danych. Dzięki temu zapewnia bezpieczny dostęp do danych (odczyt, zapis, edycja, kasowanie) jak też modyfikacji struktury danych (atrybuty, tabele, indeksy). Dla konkretnej bazy danych definiuje się hierarchię użytkowników – począwszy od super użytkownika, któremu wolno wykonywać dowolne zmiany w systemie, poprzez użytkowników mogących dodawać i usuwać dane aż do takich użytkowników którzy mogą je czytać. System DBMS zawiera mechanizmy dodawania i usuwania użytkowników oraz określania funkcji systemu które są dla nich dozwolone. Copyright by Piotr Greniewski

50 Utrzymanie integralności odwołań
Wiele systemów DBMS zawiera mechanizmy utrzymania integralności odwołań które decydują o poprawności danych. System zarządzania bazą danych zgłasza błąd jeśli aktualizacja złamie zasady modelu relacyjnego Copyright by Piotr Greniewski

51 Co to jest PostgreSQL? PostgreSQL jest to system zarządzania bazą danych, który implementuje relacyjny model bazy danych i obsługuje język zapytań SQL. System obsługuje prawie wszystkie platformy systemowe: UNIX (np. SCO) Linux (np. Red Hat) Windows NT Windows 2003 Server Windows ME (stacja robocza!!!) inne Copyright by Piotr Greniewski

52 Co to jest PostgreSQL? Zalety PostgreSQL:
jego główną zaletą, oprócz jakości jest to że jest darmowy i oferuje dostęp do kodu źródłowego; zawiera niemal wszystkie funkcje, które można odnaleźć w innych bazach danych, zarówno komercyjnych, jak i Open Source; posiada również kilka funkcji dodatkowych, właściwych tylko dla niego. Copyright by Piotr Greniewski

53 Co to jest PostgreSQL? Funkcje PostgreSQL obejmują: transakcje;
zagnieżdżanie zapytań; perspektywy; integralność odwołań dla kluczy zewnętrznych; zaawansowane mechanizmy blokowania; typy definiowane przez użytkownika; dziedziczenie; reguły; kontrolę współzawodnictwa dla wielu wierszy. Copyright by Piotr Greniewski

54 Architektura PostgreSQL
Tak jak komercyjne bazy danych pracuje w środowisku klient-serwer. Sercem instalacji PostgrSQL jest proces bazy danych zwany czasami silnikiem (ang. engine ) Aplikacje, które chcą uzyskać dostęp do danych muszą wykonywać operacje przez proces bazy danych. Nie mają dostępu do danych bezpośrednio nawet gdy pracują na tym samym komputerze co proces serwera. Rozdzielenie klienta od serwera umożliwia dystrybucję aplikacji (UNIX, Windows, ...) Copyright by Piotr Greniewski

55 Architektura PostgreSQL
SERWER KLIENT POSTMASTER BAZA DANYCH UNIX Połączenie Linux KLIENT Połączenie POSTMASTER KLIENT ODBC Windows Dostęp POSTMASTER Copyright by Piotr Greniewski Wielu klientów Wiele operacji dostępu jednocześnie

56 Podstawy relacyjnych baz danych
Arkusze kalkulacyjne. Czym wyróżniają się bazy danych? Dane w bazie danych. Prosty projekt bazy danych z wieloma tabelami. Definiowanie relacji między tabelami. Projektowanie tabel – kilka podstawowych zasad Wersja demonstracyjna bazy danych. Proste typy danych. Copyright by Piotr Greniewski

57 Arkusze kalkulacyjne Powszechne wykorzystywane narzędzie do przechowywania przeglądania danych: Wydajny sposób do zdefiniowania zbioru danych; Łatwość interpretacji danych Funkcje sortowania po kolumnach itp... Dobre narzędzie pod warunkiem, że danych nie jest zbyt dużo; Copyright by Piotr Greniewski

58 Arkusze kalkulacyjne Wiersz Kolumna Pani Anna Kowalska Tamka 13 m. 1
Pan Jan Zieliński Miła 15 m. 23 Ewa Wysocka Solec 6 m. 56 Wiersz Kolumna Copyright by Piotr Greniewski

59 Czym wyróżniają się bazy danych?
Duże podobieństwo między relacyjną bazą danych danych a arkuszem kalkulacyjnym. Baza może służyć do przechowywania bardziej złożonych danych niż arkusz. Daje możliwość dostępu wielu użytkownikom jednocześnie. Baza danych składa się z tabel. Copyright by Piotr Greniewski

60 Czym wyróżniają się bazy danych?
Rozpoczynając pracę nad projektem prostej tabeli musimy odpowiedzieć na następujące pytania: Ile kolumn potrzeba do przechowywania atrybutów związanych z każdym z elementów? Jakiego typu dane będzie reprezentować każdy z atrybutów (kolumna)? Jak rozróżniać wiersze (rekordy)? Copyright by Piotr Greniewski

61 Podstawowe typy danych
Numeryczne typy danych SMALLINT – liczby całkowite małe z przedziału ( , ); INT – liczby całkowite z przedziału ( , ); NUMERIC (p,s) – liczby rzeczywiste, gdzie p oznacza całkowitą liczbę cyfr, a s oznacza liczbę cyfr po przecinku; Copyright by Piotr Greniewski

62 Podstawowe typy danych
Tworzenie tabeli – CREATE TABLE dla wartości numerycznych CREATE TABLE test ( mala_calkowita SMALLINT, liczba_calkowita INT, liczba_rzeczywista NUMERIC (5,2) ); Copyright by Piotr Greniewski

63 Podstawowe typy danych
Znakowe typy danych: CHAR – pojedynczy znak; CHAR(n) – ciąg złożony dokładnie z n znaków, które są uzupełniane spacjami; VARCHAR(n) – ciąg znaków o długości do n znaków. Ciąg nie jest uzupełniany spacjami. TEXT Nieograniczony ciąg znaków podobny do VARCHAR, ale bez konieczności definiowania maksimum. Copyright by Piotr Greniewski

64 Podstawowe typy danych
Tworzenie tabeli – CREATE TABLE dla znakowych typów danych CREATE TABLE test ( znak CHAR, cztery_znaki CHAR(4), znaki_do_128 VARCHAR(128) ); Copyright by Piotr Greniewski

65 Podstawowe typy danych
Typy danych daty i czasu: DATE – przechowuje informacje o dacie; TIME – przechowuje informacje o czasie. Copyright by Piotr Greniewski

66 Podstawowe typy danych
Kasowanie tabeli – DROP TABLE nazwa_tabeli – jeśli tabela nie jest już potrzebna można ją skasować. Należy to robić z dużą ostrożnością. DROP TABLE test; Copyright by Piotr Greniewski

67 Tworzenie tabel nr imię nazwisko stanowisko telefon 001 Jan Kowalski
Sprzedawca 002 Anna Kamińska 003 Krzysztof Adamski Kierownik 004 Piotr Michalski Mechanik 005 Marzena Kownacka Kasjer 006 Alicja Makowiecka 007 Wojciech Bagielski Copyright by Piotr Greniewski

68 Tworzenie tabel Tworzenie tabeli polega na definiowaniu jej kolumn. Dla każdej kolumny należy określić nazwę, typ danych i długość oraz to czy jest dozwolone pozostawienie wartości pustej (NULL) CREATE TABLE pracownicy ( id_pracow CHAR(3) NOT NULL, imie VARCHAR(18) NOT NULL, nazwisko VARCHAR(24) NOT NULL, stanowisko VARCHAR(12) NOT NULL, dzial VARCHAR(12) NOT NULL, data_urodz DATE, telefon_domowy CHAR(12) ); Copyright by Piotr Greniewski

69 Projektowanie tabel Podstawowe zasady projektowania tabel w bazach danych: Podział danych na kolumny; Określenie unikalnego sposobu identyfikacji każdego wiersza; Usunięcie powtarzających się informacji; Stosowanie właściwych nazw. Copyright by Piotr Greniewski

70 Projektowanie tabel Podział danych na kolumny
W każdej kolumnie powinien znaleźć się jeden rodzaj informacji (lub atrybut). Jeżeli w kolumnie umieścimy cały adres wraz z kodem pocztowym to trudno będzie nam posortować dane po kodzie pocztowym znajdującym się gdzieś pomiędzy 14 a 20 znakiem. Dostęp do danych jest bardzo utrudniony. Kościuszki 3/5 m Warszawa Dobra 4 m Warszawa Kasprowicza Warszawa Copyright by Piotr Greniewski

71 Projektowanie tabel Określenie unikalnego sposobu identyfikacji każdego wiersza Każdy wiersz w tabeli musi być unikalny. Aby to zapewnić stosujemy klucz podstawowy. W zasadzie nie musi nim być pojedyncza – może to być para lub nawet kombinacja kilku kolumn, która jednoznacznie identyfikuje wiersz. Musimy zapewnić sposób który ze 100% pewnością spowoduje unikalność rekordów. Unikalny klucz 1 Kowalski Jan 2 3 Kwiatkowski Marian Copyright by Piotr Greniewski

72 Projektowanie tabel Usunięcie powtarzających się informacji (powtarzających się grup) – relacja jeden do wielu; Id_klienta Nazwa Miasto telefon 1 ABC S.A. Warszawa 2 XYZ S.A. Toruń Id_zamówienia Id_klienta Towar Ilość kg 1 Jabłka 10 2 Gruszki 6 Copyright by Piotr Greniewski

73 Projektowanie tabel Stosowanie właściwych nazw.
Większość projektantów posiada własne zasady nazywania tabel i kolumn w bazie danych. Nie należy mieszać liczby pojedynczej i mnogiej. Tabele i kolumny powinny mieć krótkie i treściwe nazwy, a nazwy w obrębie bazy danych powinny być spójne. Jeżeli kolumna jednej tabeli jest kluczem obcym innej tabeli to powinny posiadać takie same nazwy. Osiągnięcie tego celu bywa trudne. Copyright by Piotr Greniewski

74 Instrukcje języka SQL - podstawy
Bazy danych Instrukcje języka SQL - podstawy

75 Zapytania SQL - Struktura polecenia SELECT
SELECT – opisuje nazwy kolumn, wyrażenia arytmetyczne, funkcje FROM – nazwy tabel lub widoków WHERE – warunek (wybieranie wierszy) GROUP BY - nazwy kolumn HAVING - warunek (grupowanie wybieranych wierszy) ORDER BY – nazwy kolumn lub pozycje kolumn Każde polecenie SELECT musi posiadać klauzulę SELECT oraz FROM, pozostałe klauzule są opcjonalne. Copyright by Piotr Greniewski

76 Zapytania SQL - Wybieranie wszystkich kolumn
Poniższe polecenie SELECT wybiera wszystkie kolumny i wiersze z tablicy pracownicy. Wybieranie wszystkich kolumn i wierszy ma sene tylko w przypadku małych tabel. SELECT * FROM pracownicy; 3.1 Copyright by Piotr Greniewski

77 Zapytania SQL - Wybieranie określonych kolumn
Poniższe polecenie SELECT wyświetla kolumny: imię, nazwisko i dział dla wszystkich wierszy z tablicy pracownicy. SELECT imie, nazwisko, dzial FROM pracownicy; 3.2 Copyright by Piotr Greniewski

78 Zapytania SQL - Wybieranie z jednoczesnym porządkowaniem
Poniższe polecenie SELECT wyświetla kolumny: imię, nazwisko, dział i jednocześnie porządkuje wg. kolumny nazwisko. Klauzula ORDER BY nazwa_kolumny może posiadać za sobą słowa kluczowe: ASC – sortowanie rosnąco (wartość domyślna) DESC – sortowanie malejąco SELECT imie, nazwisko, dzial FROM pracownicy ORDER BY nazwisko ASC; 3.3 Copyright by Piotr Greniewski

79 Zapytania SQL - Wybieranie nie powtarzających się wierszy
Słowo kluczowe DISTINCT zapewnia, że wynik zwrócony z zapytania zawierać będzie tylko nie powtarzające się wiersze. Wszystkie powtarzające się wartości nie zostaną wyświetlone. Słowo kluczowe DISTINCT musi występować zaraz po słowie SELECT i może być użyte tylko raz. Słowo DISTINCT eliminuje wiersze, które posiadają duplikaty we wszystkich kolumnach wyspecyfikowanych w wyrażeniu SELECT SELECT DISTINCT stanowisko FROM pracownicy; 3.4 Copyright by Piotr Greniewski

80 Zapytania SQL - Wybieranie określonych wierszy
Dla wybrania określonych wierszy z tabeli stosuje się klauzulę WHERE, która określa kryteria wyboru wierszy. W klauzuli WHERE podajemy warunek, który musi być spełniony dla szukanych wierszy. SELECT imie, nazwisko, stanowisko, dzial FROM pracownicy WHERE stanowisko=‘sprzedawca’; Copyright by Piotr Greniewski

81 Zapytania SQL - Operatory logiczne
W klauzuli WHERE dla kolumn numerycznych możemy używać następujących warunków: Operator Znaczenie cena = 100 cena równa 100 cena <> 100 cena nie równa cena > 100 cena większa niż 100 cena >= 100 cena większa równa niż 100 cena < 100 cena mniejsza niż 100 cena <= 100 cena mniejsza równa niż 100 Copyright by Piotr Greniewski

82 Zapytania SQL - Operatory AND oraz OR
W klauzuli WHERE możemy używać następujące operatory logiczne: AND – iloczyn logiczny; OR – suma logiczna; NOT – zaprzeczenie. Można łączyć je w dowolnie złożone wyrażenia logiczne. SELECT imie, nazwisko, stanowisko, dzial FROM pracownicy WHERE stanowisko=‘sprzedawca’ OR dzial=‘techniczny’; Copyright by Piotr Greniewski

83 Zapytania SQL - Predykat IN
W klauzuli WHERE możemy użyć predykatu IN. Pozwala on porównać wartość do wartości ze zbioru. Wartości mogą być typu numerycznego, znakowego, typu daty lub czasu.Wartości typu znakowego, daty i czasu muszą być otoczone apostrofem. SELECT imie, nazwisko, stanowisko, dzial FROM pracownicy WHERE stanowisko IN (‘sprzedawca’,’kierownik’); Copyright by Piotr Greniewski

84 Zapytania SQL - Predykat BETWEEN ... AND
W klauzuli WHERE możemy użyć tego predykatu. Pozwala on sprawdzić, czy dana wartość zawiera się między dwoma wskazanymi wartościami. Zapytanie zwróci dane o samochodach, których pojemność silnika zawiera się pomiędzy 1100 a 1800. SELECT marka, typ, rok_prod, kolor, poj_silnika FROM samochody WHERE poj_silnika BETWEEN 1100 AND 1800; Copyright by Piotr Greniewski

85 Zapytania SQL - Wybieranie wartości NULL
Wybieranie wierszy z tabeli, w których jedno z pól posiada wartość pustą (null), polega na zastosowaniu predykatu NULL W przykładzie wybieramy wszystkich klientów, którzy nie posiadają karty kredytowej . Oprócz badania warunku na NULL można badać IS NOT NULL. SELECT imie, nazwisko, ulica, miasto FROM klienci WHERE nr_karty_kredyt IS NULL; Copyright by Piotr Greniewski

86 Zapytania SQL - Wyszukiwanie częściowe – predykat LIKE
Przykład wyszukuje klientów których nazwiska zaczynają się od litery K. (LIKE ‘K%’) Drugi znak nazwiska O (LIKE ‘_O%’) SELECT imie, nazwisko, ulica, miasto FROM klienci WHERE nazwisko LIKE ‘K%’ Copyright by Piotr Greniewski

87 Zapytania SQL - Podsumowanie
Do wybierania danych z tabeli służy polecenie SELECT. Można wybierać wszystkie i określone kolumny tabeli. Można wybierać wszystkie i określone wiersze. Można wybierać dane i jednocześnie je uporządkować. W zapytaniu SELECT można użyć słów kluczowych: DISTINC – w celu wyszukania nie powtarzających się wierszy; LIKE – w celu określenia wartości dla warunku; IN – w celu wskazania zbioru wartości dla warunku; BETWEEN – w celu wskazania zakresu wartości dla warunku. Copyright by Piotr Greniewski

88 Wybieranie wartości z wielu tabel - Podstawy
Zajmiemy się wyszukiwaniem danych z wielu tabel. W naszej przykładowej bazie wypaut, dla każdego numeru miejsca (miejsca pracy pracownika) w tabeli pracownicy istnieje jeden wiersz w tabeli miejsca. Postgres odczytuje numer miejsca z tabeli pracownicy a następnie przeszukuje tabelę miejsca w celu znalezienia odpowiadającego temu numerowi wiersza który zawiera dokładny adres miejsca pracy: adres, telefon, itd.. Copyright by Piotr Greniewski

89 Wybieranie wartości z wielu tabel - Podstawy
Pracownicy Nazwisko Imię Nr_miejsca Kowalski Jan 1 Gajos Anna 2 Zalewska 3 Miejsca Nr_miejsca Ulica Nr Miasto Kod 1 Dobra 5 Poznań 12-234 2 Anna 21 Wrocław 34-678 Copyright by Piotr Greniewski

90 Wybieranie wartości z wielu tabel - Podstawy
W SQL połączenie dwóch tabel wygląda następująco: SELECT pracownicy.nazwisko, pracownicy.stanowisko, pracownicy.dzial, miejsca.miasto, miejsca.ulica FROM pracownicy, miejsca WHERE pracownicy.nr_m=miejsca.nr_m ORDER BY pracownicy.nazwisko; Copyright by Piotr Greniewski

91 Wybieranie wartości z wielu tabel - Podstawy
Wybieranie danych z wielu tabel nazywa się złączeniem (ang. join). Aby złączyć dwie lub więcej tabel: W klauzuli SELECT musimy wyspecyfikować kolumny, które chcemy zawrzeć w zapytaniu; W klauzuli FROM określamy nazwy złączanych tabel; W klauzuli WHERE określamy warunki złączenia. Copyright by Piotr Greniewski

92 Wybieranie wartości z wielu tabel - Podstawy
SQL posiada dwa typy składni zapytania złączającego. Jeden już poznaliśmy. Należy pamiętać, że przy złączaniu 2 tabel klauzula WHERE musi posiadać jeden warunek złączenia. Przy trzech tabelach klauzula WHERE musi zawierać minimum dwa warunki złączenia. Copyright by Piotr Greniewski

93 Wybieranie wartości z wielu tabel - Podstawy
W przykładzie złączamy 3 tabele. Dwa pierwsze warunki dotyczą złączenia, trzeci dotyczy wyboru wierszy. SELECT w.nr_w, p.nazwisko, p.stanowisko, p.dzial, m .miasto, m.ulica FROM pracownicy p, miejsca m,wypozyczenia w WHERE p.nr_m=m.nr_m AND p.nr_p= w.prac_wyp AND m.miasto = ‘WARSZAWA’ ORDER BY p.nazwisko; 1 warunek 2 warunek 3 warunek Copyright by Piotr Greniewski

94 Wybieranie wartości z wielu tabel - Predykat JOIN ... ON
Inny typ złączenia polega na zastosowaniu konstrukcji JOIN ... ON. Kiedy używamy słowa JOIN w klauzuli FROM, to warunki złączenia muszą być wyspecyfikowane po klauzuli ON. W klauzuli WHERE można określić dodatkowe warunki. SELECT pracownicy.nazwisko, pracownicy.stanowisko, pracownicy.dzial, miejsca.miasto, miejsca.ulica FROM pracownicy JOIN miejsca ON pracownicy.nr_miejsca=miejsca.nr_miejsca WHERE pracownicy.stanowisko=‘sprzedawca’ ORDER BY pracownicy.nazwisko; Copyright by Piotr Greniewski

95 Wybieranie wartości z wielu tabel - Stosowanie aliasów w zapytaniach
Aliasy definiuje się w celu skrócenia nazwy tabeli. W przykładzie alias p wskazuje tabelę pracownicy, alias m opisuje tabelę miejsca. Wynik wykonania tego zapytania będzie taki sam jak bez aliasów. SELECT p.nazwisko, p.stanowisko, p.dzial, m.miasto, m.ulica FROM pracownicy p, miejsca m WHERE p.nr_m=m .nr_m AND p.stanowisko=‘sprzedawca’ ORDER BY p.nazwisko; Copyright by Piotr Greniewski

96 Wybieranie wartości z wielu tabel - Podsumowanie
Dane mogą być wybierane z jednej lub wielu tabel. W zapytaniu wybierającym dane z dwóch lub więcej tabel można użyć predykatu JOIN. Jeżeli w zapytaniu, które wybiera dane z przynajmniej dwóch tabel, nie zostanie wyspecyfikowany warunek złączenia po słowie kluczowym WHERE lub ON, to zwrócony wynik będzie przedstawiał iloczyn kartezjański. W zapytaniach można używać aliasów zamiast tabel. Copyright by Piotr Greniewski

97 Funkcje skalarne i arytmetyczne - Wybieranie wyliczonych wartości
Wybieranie wyliczonych wartości. W zapytaniu SQL możemy używać następujących operatorów arytmetycznych w celu obliczenia wartości: Operator Znaczenie + dodawanie - odejmowanie * mnożenie / dzielenie Copyright by Piotr Greniewski

98 Funkcje skalarne i arytmetyczne - Wybieranie wyliczonych wartości
Operatorów tych możemy użyć do budowy bardziej rozbudowanych wyrażeń matematycznych, włącznie z użyciem nawiasów w celu zaznaczenia kolejności wykonywania działań. Wynik poniższego zapytania zawiera obliczoną kolumnę, która jest sumą kolumn pensja+dodatek. Dla pracowników, którzy w polu dodatek mają wartość null - dodatkowa kolumna nie zostanie wyliczona. Wartości null nie mogą brać udziału w wyliczeniach. SELECT p.imie, p.nazwisko, p.pensja, p.dodatek, p.pensja + p.dodatek FROM pracownicy p, WHERE p.pensja > 1100 ORDER BY p.nazwisko; Copyright by Piotr Greniewski

99 Funkcje skalarne i arytmetyczne - Nazywanie wyliczonej kolumny
Kolumnę wynikową możemy nazwać. W poniższym zapytaniu po słowie kluczowym AS podana jest nazwa kolumny. SELECT p.imie, p.nazwisko, p.pensja, p.dodatek, p.pensja + p.dodatek AS Do_wyplaty FROM pracownicy p, WHERE p.pensja > 1100 ORDER BY p.nazwisko; 5.2 Copyright by Piotr Greniewski

100 Funkcje skalarne i arytmetyczne - Funkcja COALESCE
Funkcja COALESCE jest funkcją operującą na wartości null. Jeśli wartość 1-go argumentu <> null funkcja zwraca tę wartość, w przeciwnym razie funkcja zwraca 2-gi argument. SELECT p.imie, p.nazwisko, p.pensja, COALESCE (p.dodatek,0) AS Dodatek, p.pensja + COALESCE (p.dodatek,0) AS ”Do wypłaty” FROM pracownicy p, WHERE p.pensja > 1100 ORDER BY p.nazwisko; 5.3 Copyright by Piotr Greniewski

101 Funkcje skalarne i arytmetyczne - Funkcje daty
Funkcja COALESCE została użyta w celu zastąpienia wszystkich wystąpień wartości null na ciąg ,,nie posiada’’. Wyświetleni będą wszyscy klienci. Dla tych którzy nie posiadają karty kredytowej w polu nr_karty będzie wpisany cią „nie posiada”. SELECT k.imie, k.nazwisko COALESCE (k.nr_karty_kredyt,’nie posiada’) AS nr_karty FROM klienci k; 5.4 Copyright by Piotr Greniewski

102 Funkcje skalarne i arytmetyczne - Wybieranie podłańcucha
Jeżeli zachodzi potrzeba wyboru części stringu możemy zastosować funkcję SUBSTRING (s FROM n FOR m). Wybiera ona z łańcucha s m znaków, począwszy od pozycji n. W naszym przykładzie 4-ry znaki od 3-go miejsca z kolumny nazwisko. SELECT SUBSTRING (k.nazwisko FROM 3 FOR 4), k.nazwisko FROM klienci k; 5.14 Copyright by Piotr Greniewski

103 Funkcje skalarne i arytmetyczne - Łączenie łańcuchów
W celu połączenia w jeden dwóch łańcuchów znaków należy wykorzystać znak konkatenacji ‘||’ SELECT k.imie || ‘ ‘ || k.nazwisko AS Klient, ‘ul. ‘ || k.ulica || ‘ ‘ || k.numer AS Ulica, k.kod || ‘ ‘ || k.miasto AS Miasto FROM klienci k ORDER BY k.nazwisko 5.16 Copyright by Piotr Greniewski

104 Funkcje skalarne i arytmetyczne - Wyrażenie CASE
Wyrażenie CASE pozwala na wybranie pewnej wartości w zależności od wartości w innej kolumnie. W przykładzie sprawdzamy czy klient pochodzi z Warszawy, jeśli tak to wpisywana jest wartość „Klient oddziału macierzystego”, w przeciwnym razie jest to Klient z przedstawicielstwa”. SELECT k.imie, k.nazwisko, k.miasto , CASE k.miasto WHEN ‘Warszawa’ THEN ‘Klient oddziału macierzystego’ ELSE ‘Klient z przedstawicielstwa’ END FROM klienci k ORDER BY k.nazwisko 5.17 Copyright by Piotr Greniewski

105 Funkcje skalarne i arytmetyczne - Podsumowanie
Funkcje arytmetyczne mogą być używane w klauzuli SELECT oraz WHERE. Kolumny wyliczone mogą być nazwane przez zastosowanie klauzuli AS. Funkcje skalarne mogą być używane do zmiany reprezentacji danych. Funkcje skalarne mogą być używane do wydobycia lat, miesięcy oraz dni z różnych formatów daty. Wyrażenie CASE pozwala na wybór wartości dla kolumny w zależności od zdefiniowanego warunku. Copyright by Piotr Greniewski

106 Funkcje kolumnowe i grupujące - Funkcje kolumnowe
Istnieją następujące funkcje kolumnowe, które mogą być używane w klauzulach SELECT i HAVING: SUM – funkcja oblicza sumę wartości w określonych kolumnach; AVG – oblicza średnią wartość w kolumnie; MIN- znajduje minimalną wartość w kolumnie; MAX – znajduje maksymalną wartość w kolumnie; COUNT – służy do zliczania wystąpień pewnej wartości w wierszach. Copyright by Piotr Greniewski

107 Funkcje kolumnowe i grupujące - Funkcje kolumnowe
Zapytanie wyświetlające całkowitą sumę pensji wszystkich pracowników, średnią pensję, minimalną i maksymalną pensję oraz ilość pracowników. SELECT SUM (p.pensja) AS Pensja, AVG (p.pensja) AS Srednia, MIN (p.pensja) AS Pensja_min, MAX (p.pensja) AS Pensja_max COUNT (*) AS Ilosc FROM pracownicy p; 6.1 Copyright by Piotr Greniewski

108 Funkcje kolumnowe i grupujące - Funkcje kolumnowe
Funkcja COUNT może być używana do zliczania wierszy zawierających powtarzającą się wartość. Zapytanie zlicza liczbę działów i stanowisk w firmie. SELECT COUNT ( DISTINC p.dzial ) AS ilosc_dzialow, COUNT ( DISTINC p.stanowisko) AS ilosc_stanowisk FROM pracownicy p; 6.2 Copyright by Piotr Greniewski

109 Funkcje kolumnowe i grupujące - Funkcje kolumnowe
Stosowanie funkcji kolumnowych można przeprowadzić również na pewnym podzbiorze wierszy, stosując klauzulę WHERE. SELECT SUM (p.pensja) AS pensja, AVG (p.pensja) AS srednia, MIN (p.pensja) AS pensja_min, MAX (p.pensja) AS pensja_max COUNT (*) AS ilosc FROM pracownicy p WHERE p.dzial = ‘obsluga klienta’; 6.3 Copyright by Piotr Greniewski

110 Funkcje kolumnowe i grupujące - Klauzula GROUP BY
Klauzula GROUP BY grupuje wiersze o tej samej wartości wyszczególnionych kolumn. Funkcje agregujące w klauzuli SELECT operują na każdej grupie osobno. SELECT p.stanowisko, SUM (p.pensja) AS pensja, AVG (p.pensja) AS srednia, MIN (p.pensja) AS pensja_min, MAX (p.pensja) AS pensja_max COUNT (*) AS ilosc FROM pracownicy p GROUP BY p.stanowisko ORDER BY p.stanowisko; 6.5 Copyright by Piotr Greniewski

111 Funkcje kolumnowe i grupujące - Klauzula HAVING
Klauzulę HAVING używamy razem z klauzulą GROUP BY w celu ograniczenia wyświetlanych grup. Warunek szukania musi zawierać funkcję agregującą. Po zgrupowaniu wierszy przez klauzulę GROUP BY, klauzula HAVING wyświetla tylko te wiersze spośród zgrupowanych, które spełniają warunki wyszczególnione w klauzuli HAVING. SELECT p.nazwisko, SUM (w.cena_jedn) FROM pracownicy p, wypozyczenia w WHERE p.nr_pracownika = w.nr_pracownika GROUP BY p.nazwisko HAVING SUM (w.cena_jedn) > 400 ORDER BY p.nazwisko; 6.7 Copyright by Piotr Greniewski

112 Funkcje kolumnowe i grupujące - Podsumowanie
Funkcje kolumnowe mogą być użyte tylko w klauzulach SELECT i HAVING. Klauzula SELECT może zawierać tylko funkcje kolumnowe oraz kolumny wskazywane w klauzuli ORDER BY. Klauzula HAVING może zawierać dowolne funkcje kolumnowe operujące na dowolnych kolumnach tabeli. Te kolumny nie muszą być wyspecyfikowane w klauzuli SELECT. Copyright by Piotr Greniewski

113 Klauzula UNION - Łączenie wielu wyników zapytania
Klauzula UNION łączy dwa lub więcej polecenia SELECT w jedną tabelę wynikową. Klauzule SELECT muszą zwracać tę samą liczbę kolumn. Kolumny pokrywające muszą mieć tę samą szerokość i typ danych. Nazwy kolumn mogą być różne. Klauzula UNION łączy dwa ( lub więcej) zestawy wyników w jeden i jednocześnie usuwa duplikaty. Copyright by Piotr Greniewski

114 Klauzula UNION - Łączenie wielu wyników zapytania
Zapytanie zwraca dane o imieniu i nazwisku wszystkich klientów i pracowników, których nazwiska kończą się na „ski”. Ponieważ duplikaty są usuwane tylko jedna osoba o nazwisku Jan Kowalski będzie na liście. SELECT imie, nazwisko FROM klienci WHERE nazwisko LIKE ‘%ski’ UNION FROM pracownicy WHERE nazwisko LIKE ‘%ski’; 7.2 Copyright by Piotr Greniewski

115 Klauzula UNION - Łączenie wielu wyników zapytania
Klauzula UNION wyświetla wyniki uporządkowane rosnąco. Jeśli chcemy zmienić porządek sortowania musimy klauzulę ORDER BY umieścić na końcu. SELECT imie, nazwisko FROM klienci WHERE nazwisko LIKE ‘%ski’ UNION FROM pracownicy ORDER BY nazwisko DESC; 7.3 Copyright by Piotr Greniewski

116 Klauzula UNION - Klauzula UNION ALL
Różnica pomiędzy klauzulą UNION a UNION ALL polega na tym, że wynik łączenia zapytań klauzulą UNION ALL zawiera powtarzające się wiersze. Klauzula UNION ALL działa szybciej niż UNION. SELECT imie, nazwisko FROM klienci WHERE nazwisko LIKE ‘%ski’ UNION ALL FROM pracownicy ORDER BY nazwisko DESC; 7.3 Copyright by Piotr Greniewski

117 Klauzula UNION - Podsumowanie
Wyniki zapytania SELECT z tą samą liczbą kolumn, będących tego samego typu danych, mogą być łączone przy pomocy klauzuli UNION. Klauzula UNION sortuje dane wynikowe i usuwa duplikaty. Klauzula UNION ALL działa szybciej niż UNION. Użyj klauzuli UNION ALL gdy jesteś pewien, że łączone wyniki nie zawierają duplikatów Copyright by Piotr Greniewski

118 Pod-zapytania - Używanie pod-zapytań
Chcemy wyszukać pracowników, którzy otrzymują wynagrodzenie w kwocie wyższej niż średnia. Sprawdzamy najpierw jaka jest średnia pensja w naszym przedsiębiorstwie. SELECT AVG (p.pensja) FROM pracownicy p; Wynik wynosi 1530; 8.1 Teraz szukamy pracowników zarabiających powyżej średniej. SELECT p.imie, p.nazwisko, p.dzial, p.stanowisko FROM pracownicy p; WHERE p.pensja > 1530; 8.1 Copyright by Piotr Greniewski

119 Pod-zapytania - Używanie pod-zapytań
Można to zrobić przy użyciu jednego pod-zapytania SELECT p.imie, p.nazwisko, p.dzial, p.stanowisko FROM pracownicy p WHERE p.pensja > (SELECT AVG (p.pensja) FROM pracownicy p); 8.1 Copyright by Piotr Greniewski

120 Pod-zapytania - Używanie słowa kluczowego NOT IN
Słowo kluczowe NOT IN pozwala na zidentyfikowanie wszystkich elementów w zbiorze A, które nie występują w zbiorze B. Tomasz Adamczak Warszawa Paweł Fiodorowicz Anna Kowalska Wrocław Piotr Malczyk ZBIÓR A A NOT IN B Paweł Fiodorowicz Warszawa Piotr Malczyk NOT IN Tomasz Adamczak Warszawa Aniela Dalgiewicz Wrocław Krzysztof Dobrowolski Anna Kowalska ZBIÓR B Copyright by Piotr Greniewski

121 Pod-zapytania - Używanie słowa kluczowego NOT IN
Poniższe zapytanie wyświetla listę samochodów, których do tej pory nie wypożyczył żaden klient. Zapytanie wybiera te samochody, które nie znajdują się w tabeli wypożyczenia. SELECT s.nr_samochodu, s.marka, s.typ FROM samochody s WHERE s.nr_samochodu NOT IN ( SELECT w.nr_samochodu FROM wypozyczenia w); 8.3 Copyright by Piotr Greniewski

122 Pod-zapytania - Używanie słowa kluczowego ALL
Zapytanie będzie wykonywane w dwóch krokach. Najpierw wykonywane jest pod-zapytanie, które znajduje średnią pensję w każdym dziale. Następnie każda pensja pracownika, porównywana jest z listą średnich pensji. Wyświetleni zostaną pracownicy, których pensja jest wyższa od wszystkich średnich pensji obliczonych w pod-zapytaniu. SELECT p.imie, p.nazwisko, p.dzial, p.stanowisko, p.pensja FROM pracownicy p WHERE p.pensja > ALL ( SELECT AVG (p.pensja) FROM pracownicy p GROUP BY p.dzial); 8.3 Copyright by Piotr Greniewski

123 Instrukcje języka SQL - zaawansowane
Bazy Danych Instrukcje języka SQL - zaawansowane

124 UPDATE - aktualizacja danych w tabeli
Składnia: UPDATE nazwa_tabeli SET nazwa_kolumny=wartość WHERE warunek Przykład: UPDATE klienci SET miasto=‘Warszawa’, kod=’04-899’ WHERE nazwa=‘ACTION S.A.’ Copyright by Piotr Greniewski

125 DELETE FROM - usuwanie wierszy z tabeli
Składnia: DELETE FROM nazwa_tabeli WHERE warunek Przykład DELETE FROM klienci WHERE nazwa=‘ACTION S.A.’ Copyright by Piotr Greniewski

126 TRUNCATE - usuwanie wszystkich wierszy
Instrukcja DELETE działa na pojedynczych wierszach. Aby usunąć wszystkie wiersze z tabeli należy użyć instrukcję TRUNCATE TRUNCATE TABLE klient Copyright by Piotr Greniewski

127 CREATE DATABASE — tworzenie nowej bazy
Składnia: CREATE DATABASE nazwa [ WITH [ LOCATION = ’ścieżka’ ] [ TEMPLATE = template ] [ ENCODING = kodowanie ] ] Przykład: CREATE DATABASE klienci; Copyright by Piotr Greniewski

128 DROP DATABASE – usunięcie bazy danych
Składnia: DROP DATABASE nazwa Przykład: DROP DATABASE klienci; Copyright by Piotr Greniewski

129 VACUUM – porządkowanie bazy i analiza
Składnia: VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ] Przykład: VACUUM VERBOSE ANALYZE baza; Copyright by Piotr Greniewski

130 CREATE USER – definiowanie nowego użytkownika
Składnia: CREATE USER nazwa [ [ WITH ] opcje [ ... ] ] Gdzie opcje: SYSID uid | [ ENCRYPTED | UNENCRYPTED ] PASSWORD ’password’ | CREATEDB | NOCREATEDB | CREATEUSER | NOCREATEUSER | IN GROUP groupname [, ...] | VALID UNTIL ’abstime’ Copyright by Piotr Greniewski

131 CREATE USER – definiowanie nowego użytkownika
Przykład: CREATE USER Jan; CREATE USER Jan WITH PASSWORD ’jw8s0F4’; CREATE USER Jan WITH PASSWORD ’jw8s0F4’ VALID UNTIL ’Jan ’; CREATE USER Jan WITH PASSWORD ’jw8s0F4’ CREATEDB; Copyright by Piotr Greniewski

132 DROP USER – kasowanie użytkownika
Składnia: DROP USER nazwa Przykład: DROP USER Jan; Copyright by Piotr Greniewski

133 ALTER USER – zmiana uprawnień użytkownika
Składnia: ALTER USER username [ [ WITH ] option [ ... ] ] gdzie option: [ ENCRYPTED | UNENCRYPTED ] PASSWORD ’password’ | CREATEDB | NOCREATEDB | CREATEUSER | NOCREATEUSER | VALID UNTIL ’abstime’ Przykład: ALTER USER Kowalski WITH PASSWORD ’hu8jmn3’; ALTER USER Nowak CREATEUSER CREATEDB; Copyright by Piotr Greniewski

134 GRANT – nadawanie uprawnień
Składnia: GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,...] | ALL PRIVILEGES] } ON [ TABLE ] objectname [, ...] TO { username | GROUP groupname | PUBLIC } [, ...] Przykład: GRANT SELECT ON klienci TO student; GRANT ALL PRIVILEGES ON klienci TO student; Copyright by Piotr Greniewski

135 REVOKE – odbieranie uprawnień
Składnia: REVOKE { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,...] | ALL ] } ON [ TABLE ] object [, ...] FROM { username | GROUP groupname | PUBLIC } [, ...] Przykład: REVOKE SELECT ON klienci FROM student; REVOKE ALL PRIVILEGES ON klienci FROM student; Copyright by Piotr Greniewski

136 CREATE GROUP – tworzenie grupy
Składnia: CREATE GROUP name [ [ WITH ] option [ ... ] ] option: SYSID gid | USER username [, ...] Przykład: CREATE GROUP marketing WITH USER Kowalski, Kwiatkowski; Copyright by Piotr Greniewski

137 DROP GROUP – kasowanie grupy
Składnia: DROP GROUP name Przykład: DROP GROUP marketing; Copyright by Piotr Greniewski

138 ALTER GROUP – Zmiana grupy
Składnia: ALTER GROUP name ADD USER username [, ... ] ALTER GROUP name DROP USER username [, ... ] Przykład: ALTER GROUP marketing ADD USER Nowak,Jackowski; ALTER GROUP marketing DROP USER Nowak,Jackowski; Copyright by Piotr Greniewski

139 Kolumna oid Kolumna oid – kiedy wprowadzamy dane baza odpowiada na dwoma liczbami: ukrytym zazwyczaj numerem referencyjnym (oid), który PostgreSQL zapisuje dla każdego wiersza w kolumnie liczbą wprowadzanych wierszy Numer oid czyni wiersz unikalnym ale w poprawnie zaprojektowanej bazie danych nie ma potrzeby go używać. Przykład: SELECT oid, imie, nazwisko FROM klienci; Copyright by Piotr Greniewski

140 CREATE SEQUENCE - tworzenie sekwencji
Składnia: CREATE [ TEMPORARY | TEMP ] SEQUENCE seqname [ INCREMENT increment ] [ MINVALUE minvalue ] [ MAXVALUE maxvalue ] [ START start ] [ CACHE cache ] [ CYCLE ] Przykład: CREATE SEQUENCE kod START 100; SELECT nextval(’kod’); nextval 101 Copyright by Piotr Greniewski

141 CREATE SEQUENCE - tworzenie sekwencji
Sekwencja może być tworzona ręcznie (poprzedni slajd) lub automatycznie. Jeżeli utworzymy w tablicy kolumnę typu serial to PostgreSQL poinformuje nas o automatycznym utworzeniu sekwencji. Definiując tabele klient utworzyliśmy kolumnę klient_id jako serial. PostgreSQL utworzył sekwencję. Definicja pola wygląda następująco; Przykład: CREATE TABLE klienci( klient_id integer NOT NULL DEFAULT nextval(‘klient_id_seq’::text), ... ) numer sekwencji można otrzymać: currval(‘nazwa_sekwencji’) numer następny: nextval(‘nazwa_sekwencji’) można zmienić wartość sekwencji: settval(‘nazwa_sekwencji’) Copyright by Piotr Greniewski

142 CREATE SEQUENCE - tworzenie sekwencji
Wprowadzając dane do tabeli nie należy wypełniać pola z sekwencją. PostgreSQL zrobi to automatycznie wprowadzając dla każdego rekordu nową unikalną wartość. Copyright by Piotr Greniewski

143 DROP SEQUENCE – kasowanie sekwencji
Składnia: DROP SEQUENCE name [, ...] Przykład: DROP SEQUENCE kod; Copyright by Piotr Greniewski

144 CONSTRAINT – ograniczenia dla tabeli
Tworzenie tablic typ kolumny np.: VARCHAR(10) typ ograniczenia np.: NOT NULL Składnia: CREATE [TEMPORARY] TABLE nazwa_tabeli ( {nazwa_kolumny typ [ograniczenia_dla_kolumny], ...} [CONSTRAINT ograniczenie_dla_tabeli] ) [INHERITS (nazwa_istniejącej_tabeli)]; Copyright by Piotr Greniewski

145 CONSTRAINT – ograniczenia dla tabeli
Ograniczenia dla kolumn Ograniczenie Opis NOT NULL W kolumnie nie mogą być zapisywane wartości NULL UNIQUE Zapisywane wartości muszą być różne dla każdego wiersza w tabeli PRIMARY KEY Klucz podstawowy tabeli – może być tylko jeden DEFAULT wartość Umożliwia zdefiniowanie wartości domyślnej w czasie wprowadzania danych CHECK (warunek) Pozwala na sprawdzenie warunku w czasie wprowadzania lub modyfikacji danych REFERENCES Patrz: ograniczenia kluczy obcych Copyright by Piotr Greniewski

146 CONSTRAINT – ograniczenia dla tabeli
Przykład: CREATE TABLE filmy ( kod CHAR (5) CONSTRAINT klucz PRIMARY KEY, tytol VARCHAR(40) NOT NULL, dyst DECIMAL(3) NOT NULL, data_prod DATE, kind CHAR(10) ); CREATE TABLE dystrybutorzy dyst DECIMAL(3) PRIMARY KEY DEFAULT NEXTVAL(’serial’), nazwa VARCHAR(40) NOT NULL CHECK (name <> ”) Copyright by Piotr Greniewski

147 Projekt tabeli – E/R Projekt tabeli (poziom logiczny)
Projekt tabeli (poziom fizyczny) Copyright by Piotr Greniewski

148 Tabela – brak klucza głównego
CREATE TABLE MIEJSCA ( NR_M INTEGER, ULICA VARCHAR(24) NOT NULL, NUMER CHAR(8) NOT NULL, MIASTO VARCHAR(24) NOT NULL, KOD CHAR(6) NOT NULL, TELEFON CHAR(16), UWAGI VARCHAR(40), ); Copyright by Piotr Greniewski

149 Tabela – klucz główny (primary key)
Każda tabela w bazie powinna zawierać klucz główny. Klucz główny to kolumna lub grupa kolumn, która w jednoznaczny sposób identyfikuje wiersz w tabeli. Na przykład dla tabeli MIEJSCA kluczem głównym może być pole NR_M (numer miejsca). Klucz główny zapobiega wstawianiu dwóch identycznych wierszy do tabeli. Copyright by Piotr Greniewski

150 Tabela – klucz główny (primary key)
CREATE TABLE MIEJSCA ( NR_M INTEGER PRIMARY KEY, ULICA VARCHAR(24) NOT NULL, NUMER CHAR(8) NOT NULL, MIASTO VARCHAR(24) NOT NULL, KOD CHAR(6) NOT NULL, TELEFON CHAR(16), UWAGI VARCHAR(40), ); Copyright by Piotr Greniewski

151 Tabela – wprowadzanie danych
INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1000,'LEWARTOWSKIEGO', '12', 'WARSZAWA', '10-100', ' '); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1001,ALEJE LIPOWE', '3', 'WROCLAW', '32-134', ' '); VALUES (1002,'KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', ' '); VALUES (1003,'LOTNICZA', '9', 'POZNAN', '22-200', ' '); Copyright by Piotr Greniewski

152 Tabela – sekwencje Sekwencja to generator kolejnych liczb, związany z bieżącą bazą danych umożliwiający zarządzanie indeksami w tabeli. Po utworzeniu sekwencji używamy funkcji nextval, currval i setval do obsługi sekwencji. CREATE SEQUENCE NR_M START 1000; numer sekwencji można otrzymać: currval(‘nazwa_sekwencji’) numer następny: nextval(‘nazwa_sekwencji’) można zmienić wartość sekwencji: settval(‘nazwa_sekwencji’) Copyright by Piotr Greniewski

153 Tabela – sekwencje CREATE TABLE MIEJSCA (
NR_M INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL('NR_M'), ULICA VARCHAR(24) NOT NULL, NUMER CHAR(8) NOT NULL, MIASTO VARCHAR(24) NOT NULL, KOD CHAR(6) NOT NULL, TELEFON CHAR(16), UWAGI VARCHAR(40), ); Copyright by Piotr Greniewski

154 Tabela – wprowadzanie danych z sekwencjami
INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('LEWARTOWSKIEGO', '12', 'WARSZAWA', '10-100', ' '); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('ALEJE LIPOWE', '3', 'WROCLAW', '32-134', ' '); VALUES ('KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', ' '); VALUES ('LOTNICZA', '9', 'POZNAN', '22-200', ' '); Copyright by Piotr Greniewski

155 Tabela – równoważne definicje
CREATE TABLE MIEJSCA ( NR_M INTEGER PRIMARY KEY, ULICA VARCHAR(24) NOT NULL, NUMER CHAR(8) NOT NULL, MIASTO VARCHAR(24) NOT NULL, ); NR_M INTEGER, MIASTO VARCHAR(24) NOT NULL, CONSTRAINT PRIMARY KEY NR_M Copyright by Piotr Greniewski

156 Tabela – równoważne definicje
W powyższym przykładzie definicje tworzenia tabeli są w zasadzie identyczne. Wynika to z faktu, że tzw. ograniczenia ( CONSTRAINTS ) mogą dotyczyć kolumn (pierwsza definicja) albo całej tabeli (druga definicja) Ograniczenia będą omówione w późniejszej części wykładu. Copyright by Piotr Greniewski

157 Tabela – klucz obcy (foreign key)
Klucz obcy to jedna lub więcej kolumn tabeli odwołujących się do klucza głównego w innej tabeli. Klucze obce są wykorzystywane do utrzymywania integralności referencyjnej w bazie danych. Tworząc klucz obcy, definiujemy związek między tabelą klucza głównego i tabelą klucza obcego. Związek taki powstaje podczas złączenia kolumn takich samych typów danych z każdej tabeli. Złączanie tabel przez odpowiednie kolumny chroni dane z tabeli klucza obcego przed osieroceniem jakie mogłoby nastąpić w wyniku usunięcia odpowiadających im danych z tabeli klucza głównego Copyright by Piotr Greniewski

158 Tabela – klucz obcy (foreign key)
NR_M_FK jest nazwą związku (relationship) pomiędzy tabelami Copyright by Piotr Greniewski

159 Tabela – klucz obcy (foreign key)
CREATE TABLE PRACOWNICY ( NR_P INTEGER NOT NULL DEFAULT NEXTVAL('NR_P'), IMIE VARCHAR(20) NOT NULL, NAZWISKO VARCHAR(20) NOT NULL, DATA_ZATR DATE NOT NULL, DZIAL VARCHAR(20) NOT NULL, STANOWISKO VARCHAR(20) NOT NULL, PENSJA DECIMAL(8,2), DODATEK DECIMAL(8,2), NR_M VARCHAR(4), TELEFON CHAR(16), CONSTRAINT NR_P_PK PRIMARY KEY (NR_P) CONSTRAINT NR_M_FK FOREIGN KEY (NR_M) REFERENCES MIEJSCA(NR_M) ); Copyright by Piotr Greniewski

160 CREATE TABLE – równoważna definicja
Przykład: CREATE TABLE dystrybutorzy ( dystr DECIMAL(3), nazwa VARCHAR(40), PRIMARY KEY(dystr) ); dystr DECIMAL(3) PRIMARY KEY, nazwa VARCHAR(40) Copyright by Piotr Greniewski

161 CONSTRAINT – ograniczenia dla tabeli
Funkcja Opis UNIQUE (lista_kolumn) Zapisywane wartości muszą być różne dla każdego wiersza każdej kolumny w tabeli PRIMARY KEY(lista_kolumn) Klucz podstawowy tabeli – może być tylko jeden CHECK (warunek) Pozwala na sprawdzenie warunku w czasie wprowadzania lub modyfikacji danych REFERENCES Patrz: ograniczenia kluczy obcych Copyright by Piotr Greniewski

162 ALTER TABLE – uaktualnianie struktury tabel
Uaktualnianie struktury tabeli posiadającej dane. Kolumny dodane do tabeli będą posiadały wartości null Składnia: ALTER TABLE nazwa_tabeli ADD COLUMN nazwa_kolumny typ_kolumny RENAME COLUMN stara_nazwa TO nowa_nazwa ALTER TABLE nazwa_tabeli RENAME TO nowa_nazwa_tabeli Przykład: ALTER TABLE test_const ADD COLUMN data_urodzin DATE; ALTER TABLE test_const RENAME COLUMN data_urodzin TO urodziny; ALTER TABLE test_const RENAME TO testowa; Copyright by Piotr Greniewski

163 DROP TABLE – kasowanie tabel
Składnia: DROP TABLE nazwa_tabeli; Przykład: DROP TABLE klienci; Copyright by Piotr Greniewski

164 CREATE TEMP TABLE – tabele tymczasowe
Tabele tymczasowe. Jeżeli instrukcja SELECT jest bardzo złożona to lepiej wyniki częściowe przechowywać w tzw. tabelach tymczasowych. Tabele te nikną z końcem sesji. Tabele tymczasowe można wyświetlać z poziomu psql poleceniem \dt Przykład: CREATE TEMPORARY TABLE pomocnicza ( ...); CREATE TEMP TABLE pomocnicza (...); Copyright by Piotr Greniewski

165 INSERT INTO – wprowadź dane do tablicy
Składnia: INSERT INTO table [ ( column [, ...] ) ] { DEFAULT VALUES | VALUES ( expression [, ...] ) | SELECT query } Przykład: INSERT INTO klienci (klient_id, nazwa,miasto,kod,ulica, nr ) VALUES (1001, ’ACTION S.A.’, ‘Warszawa ‘,’34-256’,’ Jana Kazimierza’,122); Copyright by Piotr Greniewski

166 COPY FROM (TO) – kopiuj dane do (z) tablicy
Składnia: COPY [ BINARY ] table [ WITH OIDS ] FROM { ’filename’ | stdin } [ [USING] DELIMITERS ’delimiter’ ] [ WITH NULL AS ’null string’ ] TO { ’filename’ | stdout } Copyright by Piotr Greniewski

167 COPY FROM (TO) – kopiuj dane do (z) tablicy
Przykład: COPY kraje TO stdout USING DELIMITERS ’|’; COPY kraje FROM ’/usr1/proj/bray/sql/dane’; plik dane zawiera: AF AFGHANISTAN AL ALBANIA DZ ALGERIA ZM ZAMBIA ZW ZIMBABWE \. Copyright by Piotr Greniewski

168 CREATE – tworzenie tabeli jako rezultatu zapytania
Składnia: CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name [ (column_name [, ...] ) ] AS query Przykład: CREATE TABLE klienci_warszawa AS SELECT klient_id, nazwa, kod, ulica, numer FROM klienci WHERE miasto=‘Warszawa’ Copyright by Piotr Greniewski

169 CREATE VIEW – tworzenie perspektyw
Perspektywa to inaczej iluzja tabeli. Może zawierać kolumny z jednej lub kilku tabel. Tworzenie perspektywy polega na nazwaniu instrukcji SELECT Składnia: CREATE VIEW nazwa_perspektywy AS instrukcja_select; Przykład: CREATE VIEW cena AS SELECT id_towaru, opis, cena FROM towary; Copyright by Piotr Greniewski

170 DROP VIEW – kasowanie perspektyw
Składnia: DROP VIEW nazwa_perspektywy; Przykład: DROP VIEW cena; Copyright by Piotr Greniewski

171 CREATE INDEX – tworzenie indeksu
Składnia: CREATE [ UNIQUE ] INDEX index_name ON table [ USING acc_method ] ( column [ ops_name ] [, ...] ) [ WHERE predicate ] [ USING acc_method ] ( func_name( column [, ... ]) [ ops_name ] ) Przykład: CREATE UNIQUE INDEX tytol_idx ON filmy (tytol); Copyright by Piotr Greniewski

172 DROP INDEX – kasowanie indeksu
Składnia: DROP INDEX index_name [, ...] Przykład: DROP INDEX tytol_idx; Copyright by Piotr Greniewski

173 Ograniczenia kluczy obcych
ELEMENT_ID INTEGER OPIS VARCHAR(64) KOSZT INTEGER CENA INTEGER ELEMENT KOD_ID VARCHAR(13) ELEMENT_ID INTEGER KOD_KRESKOWY ELEMENT_ID – ELEMENT_ID ILOŚĆ INTEGER ZAPAS INFO_ID INTEGER ILOŚĆ INTEGER LINIA_ZLECENIA INFO_ID INTEGER KLIENT_ID VARCHAR(64) DATA_DOSTAWY DATE DATA_WYSYLKI DATE INFO_ZLECENIA KLIENT_ID INTEGER NAZWA VARCHAR(32) ADRES VARCHAR(32) MIASTO VARCHAR(32) KLIENT KLIENT_ID – KLIENT_ID INFO_ID – INFO_ID Copyright by Piotr Greniewski

174 Ograniczenia kluczy obcych
Wprowadzamy pojęcie klucza obcego (ang. foreign key). Przykładem klucz obcego jest pole KLIENT_ID w tablicy INFO_ZLECENIA. Pod pojęciem klucza obcego rozumiemy fakt, że pole KLIENT_ID nie jest w tej tablicy kluczem podstawowym to jednak kolumna w tabeli KLIENT z którą pole to wiążę pojedynczy wiersz jest unikalna. Odwrotny związek nie zachodzi. W tabeli KLIENT nie ma unikalnych kluczy żadnej innej tabeli. Możemy stwierdzić że tabela KLIENT nie zawiera kluczy obcych. Istnieje możliwość że tabela zawiera więcej niż jeden klucz obcy. W tabeli LINIA_ZLECENIA pola INFO_ID i ELEMENT_ID są kluczami obcymi. Copyright by Piotr Greniewski

175 Ograniczenia kluczy obcych
Pole ELEMENT_ID jest kluczem podstawowym w tabeli ELEMENTY i kluczem obcym w tabeli ZAPAS. Pojedyncza kolumna może być zarówno kluczem podstawowym jak i obcym co implikuje relację jeden do jednego pomiędzy wierszami w obu tabelach. W naszym przykładzie relacje te mają kluczowe znaczenie. Jeżeli w tabeli INFO_ZLECENIA istnieje wiersz w którym pole KLIENT_ID nie odpowiada polu KLIENT_ID w tabeli KLIENT, to powstaje duży problem. Posiadamy zamówienie natomiast nie wiemy który klient go złożył. Taki związek kluczy obcych można zadeklarować jako ograniczenie dla kolumn i tabel. Robi się to podczas tworzenia tabeli jako część instrukcji CREATE TABLE za pomocą ograniczenia REFERENCES Copyright by Piotr Greniewski

176 Klucze obce jako ograniczenia dla kolumn
Deklaracja kolumny jako klucza obcego w innej tabeli. Nazwa ograniczenia jest opcjonalna. Warto ją definiować bo może być pomocna w diagnozowaniu błędów Składnia: [CONSTRAINT nazwa_dowolna istniejąca_nazwa_kolumny typ] REFERENCE nazwa_tabeli_zewnętrznej(kolumna_w_tabeli_zewnętrznej) Copyright by Piotr Greniewski

177 Klucze obce jako ograniczenia dla kolumn
Deklaracja kolumny jako klucza obcego w innej tabeli Wprowadziliśmy info_pk jako nazwę ograniczenia Przykład: CREATE TABLE info_zlecenia ( info_id serial, klient_id integer not null REFERENCE klient(klient_id), data_dostawy date not null, data_wysylki date, CONSTRAINT info_pk PRIMARY KEY(info_id) ) Copyright by Piotr Greniewski

178 Klucze obce jako ograniczenia dla tabel
Możemy deklarować klucze obce jako ograniczenia dla kolumn ale lepiej jest deklarować je na poziomie tabel wraz z ograniczeniem PRIMARY KEY. Ograniczeń dla kolumn nie można zastosować jeśli w powiązaniu bierze udział wiele kolumn z bieżącej tabeli. Składnia: [CONSTRAINT nazwa_dowolna ] FOREIGN KEY (lista_kolumn) REFERENCE nazwa_tabeli_zewnętrznej (lista_kolumn_w tabeli_zewnętrznej) Copyright by Piotr Greniewski

179 Klucze obce jako ograniczenia dla tabel
Przykład: CREATE TABLE info_zlecenia ( info_id serial, klient_id integer not null, data_dostawy date not null, data_wysylki date, CONSTRAINT info_pk PRIMARY KEY(info_id), CONSTRAINT klient_fk FOREIGN KEY(klient_id) REFERENCES klient(klient_id) ) Copyright by Piotr Greniewski

180 Klucze obce jako ograniczenia dla tabel
Przykład: CREATE TABLE linia_zlecenia ( info_id serial, element_id integer not null, zapas integer not null, CONSTRAINT linia_pk PRIMARY KEY(info_id), REFERENCES info_zlecenia(info-id), CONSTRAINT element_id_pk FOREIGN KEY(element_id) REFERENCES element(element_id) ) Copyright by Piotr Greniewski

181 Klucze obce jako ograniczenia dla tabel
W związku z ograniczeniami tabele należy wypełniać (i kasować) w odpowiedniej kolejności. Ograniczenia sugerują następującą kolejność: klienci element info_zlecenia linia_zlecenia zapas kod_kreskowy Copyright by Piotr Greniewski

182 Klucze obce jako ograniczenia dla tabel
Może się zdarzyć, że wystąpi potrzeba uaktualnienia kolumny klient_id w tablicy info_zlecenia. Próby aktualizacji skończą się niepowodzeniem. Istnieją dwa sposoby na rozwiązanie tego problemu; zastosowanie predykatu DEFERRABLE powoduje, że przy zastosowaniu transakcji Postgre SQL pozwoli wykonać tą czynność wewnątrz transakcji. zastosowanie predykatu ON DELETE CASCADE oraz SET NULL. Są to tzw. reguły dla kluczy obcych dotyczące obsługi uaktualnienia bądź kasowania. Copyright by Piotr Greniewski

183 Opcje ograniczeń dla kluczy obcych – I metoda
zastosowanie predykatu DEFERRABLE powoduje, że przy zastosowaniu transakcji Postgre SQL pozwoli na naruszenie kluczy obcych ale tylko wewnątrz transakcji.. CREATE TABLE info_zlecenia ( info_id serial, klient_id integer not null, data_dostawy date not null, data_wysylki date, CONSTRAINT info_pk PRIMARY KEY(info_id), CONSTRAINT klient_fk FOREIGN KEY(klient_id) REFERENCES klient(klient_id) DEFERRABLE ) Copyright by Piotr Greniewski

184 Opcje ograniczeń dla kluczy obcych – II metoda
Aby można było kasować rekordy z tablicy klienci stosujemy predykat ON DELETE CASCADE powodujący w przypadku usunięcia rekordu z tablicy klienci automatyczne usunięcie rekordów z tablicy info_zlecenia. Należy postępować jednak bardzo uważnie. I lepiej wykonywać to programowo CREATE TABLE info_zlecenia ( info_id serial, klient_id integer not null, data_dostawy date not null, data_wysylki date, CONSTRAINT info_pk PRIMARY KEY(info_id), CONSTRAINT klient_fk FOREIGN KEY(klient_id) REFERENCES klient(klient_id) ON DELETE CASCADE ) Copyright by Piotr Greniewski

185 Operacje manipulowania danymi
Specjalne typy danych unikalne dla PostgreSQL Box – prostokątna ramka cidr lub inet – Adres internetowy np.: Line – Zbiór punktów Point – geometryczna para liczb Lseg – Odcinek linii polygon – zamknięty kształt geometryczny Copyright by Piotr Greniewski

186 Operacje manipulowania danymi
Tworzenie własnych typów – istnieje instrukcja CREATE TYPE służąca do tworzenia własnych typów. Ponieważ jest to z poza SQL standard więc stosowanie kłopotliwe. Typy tablicowe – z poza SQL standard instrukcja CREATE TABLE test( refcode CHAR(5), dni_pracujące[] ) Copyright by Piotr Greniewski

187 Operacje manipulowania danymi
Typy tablicowe – z poza SQL standard instrukcja CREATE TABLE praca ( refcode CHAR(5), dni_pracujące[ ] ); INSERT INTO praca VALUES( ‘val01’, ‘{0,1,0,1,1,0,0}; SELECT * FROM praca; SELECT dni_pracujące[2] FROM praca; Copyright by Piotr Greniewski

188 Operacje manipulowania danymi
Konwersje pomiędzy typami CAST (nazwa_kolumny AS definicja_typu) lub nazwa_kolumny :: definicja_typu SELECT CAST (data_zakupu AS CHAR(10) ) FROM zakupy; SELECT data_zakupu :: CHAR(10) Copyright by Piotr Greniewski

189 Operacje manipulowania danymi
Funkcja Opis lenght(nazwa_kolumny) Zwraca długość ciągu znaków trim(nazwa_kolumny) Usuwa wiodące i kończące spacje strpos(nazwa_kolumny,ciąg_znaków) Zwraca pozycję ciągu znaków w kolumnie substr(nazwa_kolumny,pozycja,długość) Zwraca ciąg znaków o długości długość, począwszy od pozycji pozycja round(nazwa_kolumny, dokładność) Zwraca liczbę z ilością cyfr po przecinku dokładność abs(liczba) Zwraca wartość bezwzględną liczby Copyright by Piotr Greniewski

190 Operacje manipulowania danymi
Cztery magiczne zmienne: CURRENT_DATE – CURRENT_TIME – 22:10:12 CURRENT_TIMESTAMP – :10:12 CURRENT_USER - postgres Copyright by Piotr Greniewski

191 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 Copyright by Piotr Greniewski

192 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. Copyright by Piotr Greniewski

193 Co to są transakcje? W języku PostgreSQL zmiany te 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. Copyright by Piotr Greniewski

194 Co to są transakcje? 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ąć. Copyright by Piotr Greniewski

195 Co to są transakcje? 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. Copyright by Piotr Greniewski

196 Trzeba uważać aby nie wpaść w pewną pułapkę?
KLIENT 1 KLIENT 2 Wolne miejsce Czy są wolne miejsca? 1 Oferuje miejsce Pytanie o kartę kredytową lub konto Podaje numer karty Podaje numer konta Autoryzacja Przypisanie miejsca Obciążenie karty Zmniejszenie liczby wolnych miejsc -1 Copyright by Piotr Greniewski

197 Trzeba uważać aby nie wpaść w pewną pułapkę?
Złe rozwiązania: Pozwalamy tylko jednemu klientowi korzystać w jednej chwili z aplikacji co powoduje słabą wydajność. Piszemy aplikację z techniką semaforową. Semafor ochrania dekrementacje zmiennej liczba biletów. Jak to rozwiązać??? Copyright by Piotr Greniewski

198 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) Copyright by Piotr Greniewski

199 Reguły ACID Niepodzielna (Atomic). 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ójna (Consistent). Po wykonaniu transakcji system musi być spójny. Jeżeli w komendach SQL są ograniczenia to powinny być sprawdzone na końcu transakcji. Mowa o przykładzie ze słowem kluczowym DEFERRABLE ze slajdu nr 169 Copyright by Piotr Greniewski

200 Reguły ACID Odizolowana (Isolated). Każda transakcja wykonująca się w bazie danych musi być niezależna od innych transakcji, niezależnie od tego ile ich się wykonuje. Izolacja sprawia niestety kłopoty z wydajnością bazy danych Trwała (Durable). Po wykonaniu transakcji musi ona zostać utrwalona. Np. po pomyślnym wykonaniu transakcji przelania pieniędzy z konta na konto, muszą one pozostać na tych kontach nawet gdy nastąpi awaria komputera. W PostgreSQL i innych RBD, wykonywane jest to za pomocą dziennika transakcji. Copyright by Piotr Greniewski

201 Reguły ACID Dziennik transakcji 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). W bazie danych nie ma transakcji, które trwały w czasie awarii serwera. Transakcja jest utrwalana bez udziału użytkownika Copyright by Piotr Greniewski

202 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 Copyright by Piotr Greniewski

203 Transakcje z pojedynczym użytkownikiem
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 Copyright by Piotr Greniewski

204 Transakcje z pojedynczym użytkownikiem
Ograniczenia transakcji W PostgreSQL tak jak w innych bazach nie wolno zagnieżdzać transakcji Zaleca się aby transakcje były niewielkie. PostgreSQL musi 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 Copyright by Piotr Greniewski

205 Transakcje z pojedynczym użytkownikiem
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 Copyright by Piotr Greniewski

206 Transakcje z wieloma użytkownikami
Co oznacza że transakcje są izolowane? Poziomy izolacji ANSI. 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. Copyright by Piotr Greniewski

207 Transakcje z wieloma użytkownikami
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ć. Zazwyczaj RBD domyślnie implementuje co najmniej jeden z tych poziomów, oraz pozwala użytkownikom na zdefiniowanie przynajmniej jednego poziomu izolacji. Wprowadzimy teraz dodatkowe pojęcia pomocne w zrozumieniu poziomów izolacji. Copyright by Piotr Greniewski

208 Transakcje z wieloma użytkownikami
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ę. Transakcja zaś nie zatwierdziła jeszcze swoich działań. PostgreSQL nigdy nie umożliwia operacji brudnego odczytu. 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. Copyright by Piotr Greniewski

209 Transakcje z wieloma użytkownikami
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ę nawy 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. Copyright by Piotr Greniewski

210 Poziomy izolacji ANSI Widmo możliwy niemożliwy
Definicja poziomu izolacji ANSI /ISO Brudny odczyt Odczyt nie dający się powtórzyć Widmo READ UNCOMMITTED odczyt nie zatwierdzony możliwy READ COMMITTED odczyt zatwierdzony niemożliwy REPETABLE READ odczyt dający się powtórzyć SERIALIZABLE odczyt uszeregowany Copyright by Piotr Greniewski

211 Tryb auto zatwierdzania
PostgreSQL działa domyślnie w trybie auto zatwierdzania ( chained ) lub inaczej trybem niejawnych transakcji. Każda instrukcja SQL która może modyfikować dane działa tak jakby była kompletną transakcją. Pierwsze próby można było wykonywać nie używając BEGIN i COMMIT. W PostgreSQL wartością domyślną izolacji transakcji jest READ COMMITTED (odczyt zatwierdzony) Copyright by Piotr Greniewski

212 Blokady Wiele baz danych 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. Copyright by Piotr Greniewski

213 Zakleszczenia Sesja 1 Sesja 2 Aktualizacja wiersza 14
Copyright by Piotr Greniewski

214 Jawne blokady Blokowanie wierszy – fraza FOR UPDATE Blokowanie tabel
SELECT * FROM item WHERE cena>25 FOR UPDATE Blokowanie tabel LOCK [ TABLE ] nazwa; Copyright by Piotr Greniewski

215 Projekt bazy danych zrozumienie problemu
na czym polega dobry projekt baz danych? etapy projektowania baz danych projekt logiczny przekształcenie w projekt fizyczny postacie normalne popularne wzorce projektowe Copyright by Piotr Greniewski

216 Zrozumienie problemu Pierwszym krokiem projektanta baz danych jest zrozumienie problemu. Musimy umieć odpowiedzieć na pytania: czy planowany system ma zastąpić istniejący? czy mamy dobry punkt wyjścia? ??? Copyright by Piotr Greniewski

217 Zrozumienie problemu Drugim krokiem jest rozmowa z przyszłym użytkownikiem.Aby rozmowa z klientem była wydajna należy: przeprowadzać rozmowę jednocześnie z max osobami poinformować wcześniej osoby o temacie rozmowy aby mogły się przygotować musimy mieć pomocnika do robienia notatek aby samemu skoncentrować się na rozmowie sesje rozmów powinny być krótkie i konkretne najpóźniej następnego dnia powinno się wśród wszystkich uczestników spotkania rozprowadzić szczegółową notatkę ze spotkania celem ewentualnej weryfikacji rozbieżności. Copyright by Piotr Greniewski

218 Na czym polega dobry projekt bazy danych
Zdolność przechowywania potrzebnych danych Zdolność obsługi wymaganych związków Zdolność rozwiązywania problemu Zdolność do narzucania integralności danych Zdolność narzucania wydajności w przetwarzaniu danych Zdolność uwzględniania przyszłych zmian Copyright by Piotr Greniewski

219 Etapy projektowania bazy danych
Zbieranie informacji Projekt logiczny określenie obiektów przekształcenie obiektów w tabele określenie relacji oraz krotności naszkicowanie diagramów związków encji Copyright by Piotr Greniewski

220 Związki zero lub jeden dokładnie jeden zero lub wiele jeden lub wiele
TABELA zero lub jeden TABELA dokładnie jeden TABELA zero lub wiele TABELA jeden lub wiele Copyright by Piotr Greniewski

221 Związki pomiędzy tabelami
Tabela A Tabela B dla każdego wiersza w tabeli A musi istnieć dokładnie jeden wiersz w tabeli B dla każdego wiersza w tabeli B może istnieć zero, jeden lub wiele wierszy w tabeli A Copyright by Piotr Greniewski

222 Etapy projektowania bazy danych c.d.
Przekształcenie w model fizyczny ustalenie kluczy głównych zdefiniowanie kluczy zewnętrznych zdefiniowanie typów danych pełne definicje tabel sprawdzenie projektu Copyright by Piotr Greniewski

223 Geneza relacyjnych baz danych
Pochodzący z Wielkiej Brytanii Edgar F. Codd studiował na Oxford University i uzyskał dyplomy na wydziałach matematyki i chemii. W 1948 roku przeniósł się do USA. Jako matematyk-programista rozpoczął pracę w IBM. Uczestniczył w projektach wielu ważnych produktów firmy, w tym przy opracowaniu pierwszego komercyjnego komputera IBM 701 i maszyny Stretch, której rozwiązania technologiczne legły u podstaw wszystkich komputerów mainframe IBM. Copyright by Piotr Greniewski

224 Geneza relacyjnych baz danych
Niezwykłość relacyjnego modelu danych polega na tym, że swoje powstanie zawdzięcza głównie jednej osobie – dr E. F. Coddowi. W 1970 r. dr E. F. Codd opublikował pracę, która położyła fundament pod najbardziej popularny ze współczesnych modeli danych. Od 1968 do 1988 r. dr Codd opublikował ponad 30 prac na temat relacyjnego modelu danych. Dr Codd traktował swoje prace wydane przed r. jako pierwszą wersję relacyjnego modelu danych. Copyright by Piotr Greniewski

225 Geneza relacyjnych baz danych
Na początku 1979 r. na konferencji Australian Computer Society w miejscowości Hobert w Tasmanii Codd przedstawił pracę pod tytułem Extending the relational database model to capture more meaning. Rozszerzoną wersję relacyjnego modelu danych, którą sformułował w swojej pracy, Codd nazwał RM/T (T od Tasmania). Edgar F. Codd do końca życia zajmował się teoretycznymi podstawami informatyki. Jest między innymi twórcą - opatentowanego wspólnie z żoną Sharon Weinberg - systemu Enterprise Delta, relacyjnego modelu zarządzania regułami biznesowymi Copyright by Piotr Greniewski

226 Geneza relacyjnych baz danych
Edgar F. Codd zmarł w 2003 r., był pionierem i twórcą teoretycznych podstaw baz danych. Jego relacyjny model baz danych stanowi obecnie podstawę rozwoju jednej z najważniejszych branż przemysłu informatycznego, której wartość jest szacowana na ponad 7 miliardów dolarów rocznie. Obsługa kont bankowych, kart kredytowych, sprzedaż towarów przez Internet, systemów rezerwacji biletów i innych form operacji transakcyjnych opiera się na opracowanym przez Edgara F. Codda, wysoce abstrakcyjnym i złożonym modelu matematycznym. Copyright by Piotr Greniewski

227 Cele relacyjnych baz danych
Wcześniejsze modele danych traktowały dane w niezdyscyplinowany sposób. Model relacyjny, przy użyciu ścisłych narzędzi matematycznych, zwłaszcza teorii zbiorów, wprowadza zdyscyplinowany sposób posługiwania się danymi. Dr Codd oczekiwał, że w wyniku stosowania ścisłych metod zostaną osiągnięte dwie podstawowe korzyści: po pierwsze, zostanie poprawiony możliwy do uzyskania poziom niezależności między programami a danymi. po drugie, wzrośnie wydajność tworzenia oprogramowania. Copyright by Piotr Greniewski

228 Definicja danych Baza danych jest faktycznie zbiorem struktur danych służących do organizowania i przechowywania danych. W każdym modelu danych i w konsekwencji w każdym DBMS (System Zarządzania Bazą Danych) musimy mieć do dyspozycji zbiór reguł określających wykorzystanie takich struktur danych w aplikacjach baz danych. Tworząc definicję danych używamy wewnętrznych struktur danych modelu danych z myślą o konkretnym zadaniu. Copyright by Piotr Greniewski

229 Relacja – schemat i dziedzina
Schematem relacji nazywamy zbiór R = {A 1 ,, A 2 , ..., A n } gdzie A 1, A 2 , ..., A n są atrybutami ( nazwami kolumn ). Każdemu atrybutowi przyporządkowana jest dziedzina DOM ( A) czyli dopuszczalny zbiór wartości. Dziedziną relacji o schemacie R = {A 1 , A 2 , ..., A n } nazywamy sumę dziedzin wszystkich atrybutów relacji DOM ( R) = DOM ( A 1)  DOM ( A 2)   DOM ( A n) Copyright by Piotr Greniewski

230 Relacja- schemat, dziedzina i odwzorowanie
Relacja o schemacie R = {A 1 , A 2, ... , A n } jest to skończony zbiór r = { t 1, t2 , ... , t m } odwzorowań t i : R  DOM ( R) takich, że dla każdego j , 1<= j <= n , t i ( A j )   DOM ( A j) Każde takie odwzorowanie nazywa się krotką ( lub wierszem ). Krotka odpowiada wierszowi w tabeli. Copyright by Piotr Greniewski

231 Relacja - przykład R = {dzień, dyżurny } – R to schemat relacji gdzie dzień i dyżurny to atrybuty ( nazwy kolumn) DOM(dzień)= {pon, wto, śro,czw, pt} – to pierwsza dziedzina związana z atrybutem dzień DOM(dyżurny)= {Kwiatkowski, Nowak} – to druga dziedzina związana z atrybutem dyżurny DOM(R)=DOM(dzień)  DOM(dyżurny) – to jest dziedzina relacji dla odwzorowania r = {t 1, t2 , t3 , t4 , t5 , t6 , t7 , t8 , t9 , t10 } wartość m = 10 bo istnieje max. dziesięć par {dzień,dyżurny} np. dla m=1 odwzorowanie t1 : R  DOM ( R) t 1={pon, Kwiatkowski} spełnia warunek bo dla j=1 t 1 ( A1)   DOM ( A 1) i dla j=2 t 1 ( A2 )   DOM ( A 2) Copyright by Piotr Greniewski

232 Relacja Jest tylko jedna struktura danych w relacyjnym modelu danych - relacja. W związku z tym, że pojęcie relacji jest matematyczną konstrukcją, relacja jest tabelą, dla której jest spełniony następujący zbiór zasad: Każda relacja w bazie danych ma jednoznaczną nazwę. Według dr Codda dwuwymiarowa tabela jest matematycznym zbiorem, a matematyczne zbiory muszą być nazywane jednoznacznie. Każda  kolumna w relacji ma jednoznaczną nazwę w ramach jednej relacji. Każda kolumna relacji jest również zbiorem i dlatego powinna być jednoznacznie nazwana. Wszystkie wartości w kolumnie muszą być tego samego typu. (wynika to z punktu 2) Copyright by Piotr Greniewski

233 Relacja zbiór zasad c.d.:
Porządek kolumn w relacji nie jest istotny. Schemat relacji - lista nazw jej kolumn - jest również matematycznym zbiorem. Elementy zbioru nie są uporządkowane. Każdy wiersz w relacji musi być różny. Innymi słowy, powtórzenia wierszy nie są dozwolone w relacji. Porządek wierszy nie jest istotny. Skoro zawartość relacji jest zbiorem, to nie powinno być określonego porządku wierszy relacji. Każde pole leżące na przecięciu kolumny i wiersza w relacji powinno zawierać wartość atomową. To znaczy, zbiór wartości nie jest dozwolony na jednym polu relacji. Copyright by Piotr Greniewski

234 Klucz główny ( primary key)
Każda relacja musi mieć klucz główny. Dzięki temu możemy zapewnić, aby wiersze nie powtarzały się w relacji. Klucz główny to jedna lub więcej kolumn tabeli, w których wartości jednoznacznie identyfikują każdy wiersz w tabeli. W każdej relacji może istnieć wiele kluczy kandydujących. Klucz kandydujący to kolumna lub zbiór kolumn, które mogą występować jako jednoznaczny identyfikator wierszy w tabeli. Copyright by Piotr Greniewski

235 Klucz główny ( primary key)
Klucz główny jest wybierany ze zbioru kluczy kandydujących. Każdy klucz kandydujący, a więc także każdy klucz główny, musi mieć dwie właściwości: musi być jednoznaczny i nie może mieć wartości null. Każdy klucz kandydujący musi być jednoznacznym identyfikatorem. Dlatego nie może być żadnych powtarzających się układów wartości w kolumnach kluczy kandydującego lub głównego. Wartość klucza głównego musi być określona dla każdego wiersza w tabeli. Copyright by Piotr Greniewski

236 Klucz obcy ( foreign key)
Klucze obce są sposobem łączenia danych przechowywanych w różnych tabelach. Klucz obcy jest kolumną lub grupą kolumn tabeli, która czerpie swoje wartości z tej samej dziedziny co klucz główny tabeli powiązanej z nią w bazie danych Copyright by Piotr Greniewski

237 Dziedzina Podstawową jednostką danych w relacyjnym modelu danych jest element danych. Mówimy. że takie elementy danych są nierozkładalne lub atomowe. Zbiór takich elementów danych tego samego typu nazywamy dziedziną. Dziedzinami są więc zbiory wartości, z których pochodzą elementy pojawiające się w kolumnach tabeli. Copyright by Piotr Greniewski

238 Wartość null Pojęcie wartości null nie jest jednak do końca akceptowane. Dr Codd utrzymuje, że wprowadzenie wartości null do systemu relacyjnego zmienia konwencjonalną logikę dwuwartościową (prawda, fałsz) na logikę trójwartościową (prawda, fałsz, nieznane). W logice dwuwartościowej jeżeli zdanie 1 jest prawdziwe i zdanie 2 jest prawdziwe, to ich połączenie spójnikiem “i" jest również prawdziwe. Copyright by Piotr Greniewski

239 Wartość null W logice trójwartościowej, jeśli zdanie 1 jest prawdziwe, a zdanie 2 ma wartość nieznaną, to ich połączenie spójnikiem “i” ma wartość nieznaną. Wprowadza to dodatkowe komplikacje przy przetwarzaniu zapytań w systemach relacyjnych. Niektórzy twierdzą, że jest to niepotrzebne Copyright by Piotr Greniewski

240 Operowanie danymi Operowanie danymi to następna część modelu danych. Rozważmy cztery jego aspekty: Jak wstawiać dane do relacji? Jak usuwać dane z relacji? Jak poprawiać dane w relacji? Jak wyszukiwać dane w relacji? Copyright by Piotr Greniewski

241 Operowanie danymi Kiedy dr Codd na początku zaproponował relacyjny model danych, najwięcej uwagi skupił na ostatnim aspekcie operowania danymi - wyszukiwaniu danych. Wyszukiwanie w relacyjnym modelu danych jest wykonywane przy użyciu zbioru operatorów znanych jako algebra relacyjna Copyright by Piotr Greniewski

242 Algebra relacyjna Algebra relacyjna jest zbiorem ośmiu operatorów. Każdy operator bierze jedną lub więcej relacji jako argument i produkuje jedną relację jako wynik. Trzema głównymi operatorami algebry relacyjnej są: selekcja (ograniczenie), rzut (projekcja), złączenie. Copyright by Piotr Greniewski

243 Algebra relacyjna Dzięki tym trzem operatorom możemy wykonać większość operacji na danych wymaganych od systemu relacyjnego. Istnieją również dodatkowe operatory: iloczyn, suma, przecięcie, różnica, iloraz Copyright by Piotr Greniewski

244 Algebra relacyjna Selekcja - Selekcja jest operatorem, który bierze jedną relację jako swój argument i produkuje w wyniku jedną relację. Selekcja może być uważana za “poziomą maszynę do cięcia", gdyż wydobywa z wejściowej relacji wiersze, które pasują do podanego warunku, i przekazuje je do relacji wynikowej. Rzut - Operator rzutu bierze jedną relację jako swój argument i produkuje jedną relację wynikową. Rzut jest “pionową maszyną do cięcia” Copyright by Piotr Greniewski

245 Algebra relacyjna Suma - Suma jest operatorem, który bierze dwie zgodne relacje jako swoje argumenty i produkuje jedną relację wynikową. Zgodne, czyli tabele mają te same kolumny określone na tych samych dziedzinach (uwzględnia wszystkie wiersze z obu tabel w tabeli wynikowej). Przecięcie - Przecięcie ma działanie przeciwne działaniu sumy(uwzględnia w tabeli wynikowej tylko wiersze wspólne dla obu tabel). Copyright by Piotr Greniewski

246 Algebra relacyjna Różnica - W wypadku tego operatora istotna jest kolejność określania argumentów. Produkuje on te wiersze, które są w pierwszej tabeli i jednocześnie nie będące w tabeli drugiej. Copyright by Piotr Greniewski

247 Operacje dynamiczne na relacjach
Istnieją trzy podstawowe operacje dynamiczne potrzebne do wspomagania działań wyszukiwania: wstawianie (INSERT), usuwanie (DELETE), modyfikowanie (UPDATE). Podczas modyfikacji trzeba uważać, żeby nie naruszyć żadnych więzów integralności określonych w schemacie relacji. Copyright by Piotr Greniewski

248 Integralność danych Mówimy, że baza danych ma właściwość integralności, kiedy istnieje odpowiedniość między faktami przechowywanymi w bazie danych a światem rzeczywistym modelowanym przez tą bazę. Tą właśnie integralność zapewniają reguły integralności, które można podzielić na dwa rodzaje: integralność encji oraz integralność referencyjną. Integralność encji dotyczy kluczy głównych. Mówi ona, że każda tabela musi mieć klucz główny i że kolumna lub kolumny wybrane jako klucz główny powinny być jednoznaczne i nie zawierać wartości null. Wynika stąd, że w tabeli są zabronione powtórzenia wierszy. Copyright by Piotr Greniewski

249 Integralność danych Integralność referencyjna dotyczy kluczy obcych. Mówi ona, że wartość klucza obcego może się znajdować tylko w jednym z dwóch stanów. Wartość klucza obcego odwołuje się do wartości klucza głównego w tabeli w bazie danych. Czasami wartość klucza obcego może być null, co oznacza że nie ma związku między reprezentowanymi obiektami w bazie danych albo że ten związek jest nieznany. Utrzymywanie integralności referencyjnej oprócz określenia czy klucz obcy jest null, czy nie obejmuje również określenie więzów propagacji. Mówią one co powinno się stać z powiązaną tabelą, gdy modyfikujemy wiersz lub wiersze w tabeli docelowej. Copyright by Piotr Greniewski

250 Integralność danych Są trzy możliwości, które określają co się będzie działo z docelowymi i powiązanymi krotkami dla każdego związku między tabelami w naszej bazie: Ograniczone usuwanie (Restricted). Podejście ostrożne – nie dopuszcza do usuwania rekordu nadrzędnego, jeśli istnieją rekordy podrzędne. Kaskadowe usuwanie (Cascades). Podejście ufne – przy usuwaniu rekordu nadrzędnego usuwa także rekordy podrzędne. Izolowane usuwanie (Isolated). Podejście wyważone – usuwa jedynie rekord nadrzędny. Copyright by Piotr Greniewski

251 Zatwierdzanie zmian w bazie danych
Instrukcje INSERT, DELETE, UPDATE nie dokonują same trwałych zmian w bazie danych. Aby zmiany wprowadzone przez nie utrwalić, należy wykonać instrukcję COMMIT. Można również zrezygnować z wprowadzania zmian do bazy danych, wycofując je za pomocą instrukcji ROLLBACK. W PostgreSQL domyślnie jest włączona opcja auto-zatwierdzania więc nie trzeba przy pojedynczych instrukcjach wykonywać COMMIT. Copyright by Piotr Greniewski

252 Reguły dotyczące przedstawiania relacji jako tabel
Dr Codd definiując model relacyjny podał 12 reguł dotyczących przedstawiania relacji jako tabeli: Reguła zerowa. Aby można było uznać dany system za system zarządzania relacyjnych baz danych, musi on wykorzystywać (wyłącznie) relacyjne mechanizmy do zarządzania bazą danych. Reguła informacyjna. Jest to po prostu wymaganie, aby wszystkie informacje zawarte w bazie danych były przedstawiane w jeden i tylko jeden sposób, mianowicie za pomocą wartości umieszczanych w kolumnach w obrąbie wierszy tabel. SQL stosuje tę regułę. Copyright by Piotr Greniewski

253 Reguły dotyczące przedstawiania relacji jako tabel
Reguła gwarantowanego dostępu: te reguła jest zasadniczo powtórzeniem zasadniczego wymagania dotyczącego kluczy podstawowych. Stanowi ona, że każda poszczególna wartość skalarna w bazie danych musi mieć zapewnioną możliwość logicznego adresowania, wykorzystując nazwę zawierającej ją tabeli, nazwę zawierającej ją kolumny oraz wartość klucza podstawowego zawierającego ją wiersza. SQL spełnia tę regułę w przypadku tabel posiadających klucz podstawowy, ale w ogóle nie wymaga, aby tabele posiadały ten klucz. Copyright by Piotr Greniewski

254 Reguły dotyczące przedstawiania relacji jako tabel
Uporządkowana obsługa wartości NULL: wymaga się, aby DBMS (System zarządzania bazami danych) obsługiwał reprezentację brakujących informacji oraz informacji nieadekwatnych, tzn. odmiennych od wszystkich wartości prawidłowych, niezależnie od typu danych. Przyjmuje się, że DBMS musi obsługiwać taką reprezentację w uporządkowany sposób. W SQL-u występuje wartość NULL, która jest wykorzystywana zarówno dla wartości brakujących, jak i dla wartości nieadekwatnych zamiast dwóch oddzielnych symboli, czego chciał dr Codd Copyright by Piotr Greniewski

255 Reguły dotyczące przedstawiania relacji jako tabel
Aktywny katalog dostępny na bieżąco, oparty na modelu relacyjnym: wymaga się, aby system obsługiwał wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych użytkowników, używających ich zwykłego języka zapytań. SQL spełnia ten wymóg. Copyright by Piotr Greniewski

256 Reguły dotyczące przedstawiania relacji jako tabel
Reguła dotycząca pod-języka obsługi danych o pełnych możliwościach: system musi obsługiwać przynajmniej jeden język relacyjny, który: (a) charakteryzuje się liniową składnią; (b) może być używany zarówno w trybie interaktywnym, jak i w obrębie programów aplikacyjnych; (c) obsługuje operacje definiowania danych (łącznie z definiowaniem perspektyw), operacje manipulowania danymi (aktualizację i wyszukiwanie), ograniczenia związane z bezpieczeństwem i integralnością oraz operacje zarządzania transakcjami (rozpoczynanie, zapis zmian i ponowny przebieg). SQL jest całkiem niezły pod tym względem, ponieważ wszystkie zdefiniowane przez Codda operacje można napisać w DML (ang. Data Manipulation Language). Copyright by Piotr Greniewski

257 Reguły dotyczące przedstawiania relacji jako tabel
Reguła aktualizacji perspektyw: wszystkie perspektywy, które teoretycznie dają się aktualizować, muszą być aktualizowane przez system. Pod tym względem SQL jest słabo wyposażony; postanowiono o standaryzacji najbezpieczniejszego przypadku. Aktualizowanie perspektyw jest bardzo złożonym zagadnieniem. Polecenia wstawiania, aktualizacji oraz usuwania w języku wysokiego poziomu: wymaga się, aby system obsługiwał operatory INSERT, UPDATE oraz DELETE dotyczące całych zbiorów. SQL spełnia ten wymóg Copyright by Piotr Greniewski

258 Reguły dotyczące przedstawiania relacji jako tabel
Fizyczna niezależność danych: Każdy istniejący produkt wykazuje pewną fizyczną zależność, ale SQL jest pod tym względem lepszy od większości innych języków programowania. Logiczna niezależność danych: to także jest oczywiste. Ten aspekt jest całkiem dobrze realizowany w SQL-u. Niezależność integralnościowa: ograniczenia integralnościowe muszą być specyfikowane pojedynczo z programu aplikacyjnego i przechowywane w katalogu. Musi istnieć możliwość dokonywania stosownej zmiany takiego ograniczenia bez zbędnego oddziaływania na istniejące aplikacje. SQL-92 spełnia ten wymóg. Copyright by Piotr Greniewski

259 Reguły dotyczące przedstawiania relacji jako tabel
Niezależność dystrybucyjna: istniejące aplikacje powinny działać bez zakłóceń: kiedy następuje wprowadzenie rozproszonej wersji DBMS oraz kiedy istniejące dane rozproszone są ponownie dystrybuowane w obrębie systemu. Obecny etap to dopiero początek pracy z rozproszonymi wersjami SQL-a, jest zatem nieco zbyt wcześnie, aby można było ocenić, czy SQL spełnia to kryterium. Copyright by Piotr Greniewski

260 Reguły dotyczące przedstawiania relacji jako tabel
Reguła nie prowadzenia "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). W tym przypadku SQL-92 jest dobry . Copyright by Piotr Greniewski

261 Normalizacja Co to jest proces normalizacji? Normalizując bazę danych usuwamy z niej nadmiarowość (zwaną redundancją). Nadmiarowość w bazie danych bywa szkodliwa. Jej istnienie powoduje niepotrzebny wzrost objętości danych. Stanowi też przyczynę kłopotów z utrzymaniem spójności bazy danych, prowadząc do tzw. anomalii. Przykład: Tabela "Zakupy" ma przedstawiać: informacje o nazwie i kodzie klienta dokonującego zakupów, informacje o nazwie i kodzie oraz o ilości kupowanego towaru. Copyright by Piotr Greniewski

262 Normalizacja Tabela "Zakupy" przed normalizacją (w 1NF)
Tabela ta ma charakter jedynie przykładowy i brakuje w niej wielu istotnych pól, które powinny znaleźć się w praktycznym rozwiązaniu tego zagadnienia. Copyright by Piotr Greniewski

263 Normalizacja Nadmiarowość w tym przykładzie jest oczywista. Niepotrzebnie występują pary powtórzeń: kod towaru - nazwa towaru kod klienta - nazwa klienta Dodatkowe trudności wystąpią podczas prób aktualizacji - jeżeli firma Nowak zmieni nazwę na Nowak S.A., trzeba będzie skorygować wszystkie rekordy, w których wystąpiła nazwa firmy. Nie wspominając już o tzw. anomaliach brzegowych: co np. z polami "kod klienta" i "nazwa klienta", jeżeli danego towaru nikt jeszcze nie zamówił? Copyright by Piotr Greniewski

264 Normalizacja Jeżeli jednak założymy, że kodowi towaru lub klienta przypisana jest tylko jedna nazwa, wówczas wystarczy pamiętać w tej tabeli jedynie kod towaru i kod klienta, natomiast pełną nazwę klienta (i odpowiednio - towaru) należy przechowywać w osobnych tabelach. Dodatkową korzyść ze znormalizowania tej tabeli odczujemy, gdy przyjdzie nam np. zmienić nazwę klienta z Nowak na Nowak S.A. - po znormalizowaniu zrobimy to tylko w 1 miejscu, przed - trzeba by poprawiać każde wystąpienie klienta Nowak w tabeli zamówień. Copyright by Piotr Greniewski

265 Normalizacja Tabele "Klienci" oraz "Towary" powstałe po normalizacji
Copyright by Piotr Greniewski

266 Normalizacja Tabela "Zakupy" po normalizacji została "odchudzona" o nadmiarowe nazwy towarów oraz klientów Copyright by Piotr Greniewski

267 Normalizacja Pomiędzy tak powstałymi tabelami danych obowiązują teraz związki ( relationship), które przedstawia poniższy schemat Copyright by Piotr Greniewski

268 Normalizacja Po wprowadzeniu tych modyfikacji znikają wszystkie problemy, o których mówiliśmy przedstawiając tabelę nieznormalizowaną. Wróćmy na chwilę do teorii. Zdefiniowanych zostało 5 postaci normalnych (ang. Normal Form, w skrócie NF); każda kolejna postać oznacza mniejszą nadmiarowość, jest więc - można powiedzieć - doskonalsza. Warto zaznaczyć, że o ile 1NF jest wręcz naturalna w relacyjnych bazach danych i uzyskiwana jest na mocy definicji relacyjnej bazy danych, 2NF i 3NF również nie przysparzają kłopotów w realizacji, o tyle normalizacja do 4NF i 5NF wymaga pewnego wysiłku umysłowego. Copyright by Piotr Greniewski

269 Normalizacja Wygodnie jest nawet posłużyć się pewnymi metodami algorytmicznymi wykrywającymi i usuwającymi nadmiarowość na tym poziomie. Projektanci baz danych najczęściej kończą proces normalizacji na 3NF, ufając swemu intuicyjnemu przeświadczeniu, że wszystko jest już "w porządku". Copyright by Piotr Greniewski

270 Ostrożnie z normalizacją!!! – wada pierwsza - czas
Podstawową wadą normalizacji jest wydłużenie czasu wyszukiwania. Wróćmy do poprzedniego przykładu: załóżmy, że baza jest już znormalizowana i chcemy sporządzić raport zawierający informacje o numerze i nazwie towaru oraz kodzie i nazwie kontrahenta. Gdyby baza miała postać sprzed normalizacji, zagadnienie sprowadziłoby się tylko do wydrukowania pól tej tabeli; po normalizacji musimy przeszukać dwie dodatkowe bazy danych w celu odszukania nazwy towaru i nazwy kontrahenta. Problem ten jest błahy w przypadku małych baz danych, przy dużych bazach o wysokim stopniu normalizacji staje się prawdziwą zmorą. Copyright by Piotr Greniewski

271 Ostrożnie z normalizacją!!! – wada pierwsza - czas
Weźmy przykład z dziedziny księgowości: w programach typu księga handlowa tworzony jest tzw. plan kont. Pełna księgowość charakteryzuje się tym, że istnieją tzw. konta syntetyczne. Konto syntetyczne może mieć wiele kont analitycznych, ale konto analityczne może mieć tylko jedno konto syntetyczne. Jest to więc typowy związek "jeden do wielu". Mówiąc inaczej możemy stwierdzić, że atrybut "konto syntetyczne" jest zależny funkcjonalnie od atrybutu "konto analityczne". Stąd już tylko krok do uzyskania drugiej postaci normalnej. Copyright by Piotr Greniewski

272 Ostrożnie z normalizacją!!! – wada pierwsza - czas
Kierując się zasadami normalizacji powinniśmy w pojedynczych zapisach księgowych dotyczących danego konta analitycznego, wyeliminować atrybut opisujący konto syntetyczne. Cóż jednak dalej? Często trzeba przecież sporządzać wydruk księgowań w porządku chronologicznym, gdzie każda linia tego wydruku powinna zawierać informacje o koncie syntetycznym i analitycznym. Jeżeli dokonaliśmy normalizacji opisanej powyżej, przed wydrukiem każdego rekordu trzeba będzie przeszukiwać plik zawierający plan kont, by odnaleźć numer konta syntetycznego. Jeżeli wydruk będzie się składał np. z zapisów, zaś plan kont będzie zawierał 500 pozycji, może to znacznie zwolnić działanie programu. Copyright by Piotr Greniewski

273 Ostrożnie z normalizacją!!! – wada pierwsza - czas
Po przeanalizowaniu tych uwarunkowań wielu programistów zrezygnuje z normalizacji takiej relacji - umieszczając w pojedynczym zapisie księgowy numery obydwu kont. Podobny problem występuje w przypadku programów magazynowych - ilość danego towaru w magazynie można wyliczyć, sumując jego stan początkowy oraz transakcje zakupu, a następnie odejmując wszystkie transakcje sprzedaży. Copyright by Piotr Greniewski

274 Ostrożnie z normalizacją!!! – Wada pierwsza - czas
Zgodnie z zasadami normalizacji oznaczałoby to, że nie trzeba pamiętać aktualnej ilości towaru na magazynie. W praktyce zaś tego typu uproszczenie powodowałoby konieczność każdorazowego przeglądania wszystkich dokumentów magazynowych, by obliczyć stan danego towaru. Do podobnych wniosków dochodzili wszyscy twórcy znanych mi programów magazynowych, wprowadzając dodatkowe pole (np. "stan aktualny") w rekordzie opisującym dany towar. Copyright by Piotr Greniewski

275 Wada druga - matematyka a rzeczywistość
We wszystkich publikacjach opisujących proces normalizacji, jedna z podstawowych uwag mówi, że nie należy przechowywać w bazie danych wartości, które można wyliczyć. Jeżeli zatem w bazie danych mamy informacje, że Jan Kowalski zarobił 200 zł i z tej kwoty zapłacił 20 proc. podatku, to zwykle nie zapamiętujemy, ile dostał do ręki, bo to przecież kwota brutto odjąć 20 proc. z tej kwoty. Copyright by Piotr Greniewski

276 Wada druga - matematyka a rzeczywistość
Każdy, kto pisał program związany w jakiś sposób z podatkiem VAT (magazyn , księgowość itp.), mając na uwadze powyższe zalecenie stwierdzał, że wystarczy pamiętać jedynie kwotę netto i stawkę podatku (0,7 lub 22 procent), zaś brutto i kwotę VAT można będzie w dowolnym momencie wyliczyć. Jakież było jego zdziwienie, gdy po zaksięgowaniu maksimum 10 pierwszych faktur, okazywało się, że nie zawsze równa się 4: w matematyce co prawda przyjęto zaokrąglenie "od pięciu w górę", jednak pan na stacji benzynowej (bez wspomagania komputerowego w dodatku) wypisujący rachunek za paliwo może o tym wiedzieć. Copyright by Piotr Greniewski

277 Wada druga - matematyka a rzeczywistość
Trzeba więc księgować faktyczną kwotę z rachunku lub faktury, co sprowadza się do konieczności dodania tych dwóch pól, które z taką satysfakcją zaoszczędziliśmy O tym, że przedstawiony sposób rozumowania programisty jest typowy można się przekonać analizując strukturę plików bazy danych różnych programów finansowych - pola opisujące kwotę VAT i brutto (lub netto, jeżeli liczy się "od brutta") znajdują się z reguły pod koniec rekordu, co świadczy o ich późniejszym "dopisaniu". Copyright by Piotr Greniewski

278 Wada trzecia - nadmiarowość na osi czasu
Nadmiarowość występuje np. w sytuacji opisanej dalej. W pewnym zakładzie każdy z pracowników otrzymywał tzw. dodatek stażowy obliczany wg schematu stawka zasadnicza * liczba przepracowanych lat / 100 Copyright by Piotr Greniewski

279 Wada trzecia - nadmiarowość na osi czasu
Wyrażenie było nieskomplikowane, programista zdecydował się więc skorzystać z zależności funkcyjnych i nie zapamiętywać w bazie danych kwoty dodatku stażowego. Po roku jednak zmienił się algorytm obliczania tego dodatku: (stawka zasadnicza + dodatek za szkodliwość) * liczba przepracowanych lat / 100 Copyright by Piotr Greniewski

280 Wada trzecia - nadmiarowość na osi czasu
Jak można się domyślać, gdyby po zmianie algorytmu ktoś próbował wydrukować płace za poprzedni rok, pojawiłyby się niezgodności. Programista miał do wyboru: skomplikować algorytm obliczania płac, umieszczając w nim uwarunkowanie od daty i ryzykując, że za rok będzie musiał dokonać kolejnej modyfikacji, albo dodać w bazie nowe pole, zawierające kwotę dodatku stażowego. Copyright by Piotr Greniewski

281 Opis normalizacji Normalizacja to proces organizacji danych w bazie danych. Polega on na tworzeniu tabel i ustanawianiu pomiędzy nimi powiązań według reguł obowiązujących zarówno przy ochronie danych, jak i uelastycznianiu bazy danych przez eliminowanie powtarzających się i niespójnych zależności. Powtarzające się dane niepotrzebnie zajmują miejsce na dysku i są przyczyną powstawania problemów z obsługą. Jeśli konieczna jest zmiana danych istniejących w więcej niż jednej lokalizacji, musi być ona przeprowadzona we wszystkich lokalizacjach w ten sam sposób. Implementacja zmiany adresu klienta jest o wiele łatwiejsza, jeśli dane są przechowywane tylko w tabeli Klienci i w żadnym innym miejscu bazy danych. Copyright by Piotr Greniewski

282 Opis normalizacji Co to jest „niespójna zależność” ? O ile przeglądanie tabeli Klienci w poszukiwaniu adresu konkretnego klienta można nazwać zachowaniem intuicyjnym, to poszukiwanie w tej tabeli pensji, której wypłaty wymaga pracownik od klienta, nie ma żadnego sensu. Pensja pracownika jest związana z pracownikiem lub zależy od pracownika i dlatego powinna być przeniesiona do tabeli Pracownicy. Niespójne zależności mogą utrudniać dostęp do danych, ponieważ ścieżka ich odnajdywania może zostać utracona lub uszkodzona Copyright by Piotr Greniewski

283 Opis normalizacji Istnieje kilka reguł normalizacji baz danych.
Każda reguła nosi nazwę „postać normalna”. Jeśli przestrzegana jest pierwsza reguła, o postaci bazy danych mówi się, że jest „pierwszą postacią normalną”. Jeśli przestrzegane są pierwsze trzy reguły, postać bazy danych przyjmuje się za „trzecią postać normalną”. Chociaż możliwe są inne poziomy normalizacji, trzecia postać normalna uważana jest za najwyższy poziom wymagany przez większość aplikacji Copyright by Piotr Greniewski

284 Opis normalizacji Jak to bywa z wieloma formalnymi regułami i specyfikacjami, rzeczywistość nie zawsze pozwala na ich dokładne odwzorowanie. Ogólnie, do odnalezienia niedogodności normalizacja wymaga dodatkowych tabel i dla niektórych osób jest to uciążliwe. Przed podjęciem decyzji o złamaniu jednej z pierwszych trzech reguł normalizacji należy upewnić się, że projekt aplikacji przewiduje występowanie problemów, takich jak powtarzające się dane lub niespójne zależności. Copyright by Piotr Greniewski

285 Pierwsza postać normalna - 1NF
W poszczególnych tabelach wyeliminuj powtarzające się grupy. Dla każdego zestawu danych pokrewnych utwórz oddzielną tabelę. Dla każdego zestawu danych pokrewnych określ klucz podstawowy. Copyright by Piotr Greniewski

286 Pierwsza postać normalna - 1NF
Do przechowywania podobnych danych w jednej tabeli nie należy używać wielu pól. Na przykład rekord służący do śledzenia pozycji inwentarzowej, która może pochodzić z dwóch różnych źródeł, może zawierać pola Kod sprzedawcy 1 oraz Kod sprzedawcy 2. Co się zdarzy po dodaniu trzeciego sprzedawcy? Dodawanie pola nie dostarcza odpowiedzi. Copyright by Piotr Greniewski

287 Pierwsza postać normalna - 1NF
Wymaga to modyfikacji programu i tabel oraz nie umożliwia obsługi zmieniającej się dynamicznie liczby sprzedawców. Zamiast tego należy umieścić wszystkie informacje o sprzedawcach w oddzielnej tabeli o nazwie Sprzedawcy, a następnie połączyć magazyn ze sprzedawcami za pomocą klucza z numerem pozycji, albo sprzedawców z magazynem za pomocą klucza z kodem sprzedawcy Copyright by Piotr Greniewski

288 Druga postać normalna – 2NF
Utwórz oddzielne tabele dla zestawów wartości, odnoszących się do wielu rekordów. Ustal powiązania tabel za pomocą klucza obcego Copyright by Piotr Greniewski

289 Druga postać normalna – 2NF
Rekordy nie powinny zależeć od niczego innego niż klucz podstawowy tabeli (w razie potrzeby może to być klucz złożony). Rozważmy, na przykład, adres klienta w systemie księgowym. Obecność adresu konieczna jest w tabeli Klienci, ale również w tabelach Zamówienia, Wysyłka, Faktury, Należności i Inkaso. Zamiast przechowywać adres w postaci wpisu w każdej tabeli, przechowuje się go w jednym miejscu: albo w tabeli Klienci, albo w oddzielnej tabeli Adresy. Copyright by Piotr Greniewski

290 Trzecia postać normalna – 3NF
Wyeliminuj pola, które nie zależą od klucza. Copyright by Piotr Greniewski

291 Trzecia postać normalna – 3NF
Wartości rekordu, które nie są częścią jego klucza, nie należą do tabeli. Zazwyczaj, jeśli zawartość grupy pól odnosi się do więcej niż jednego rekordu tabeli, należy rozważyć umieszczenie tych pól w oddzielnej tabeli. Na przykład w tabeli Rekrutacja pracowników może znajdować się nazwa i adres uczelni, którą ukończył kandydat. Do korespondencji seryjnej potrzebna jest jednak kompletna lista uczelni. Jeśli informacje o uczelniach przechowywane są w tabeli Kandydaci, nie ma możliwości wyświetlenia listy uczelni bez aktualnych kandydatów. Utwórz oddzielną tabelę Uczelnie i połącz ją z tabelą Kandydaci za pomocą klucza z kodem uczelni. Copyright by Piotr Greniewski

292 Trzecia postać normalna – 3NF
Wyjątek: Stosowanie reguł trzeciej postaci normalnej, chociaż teoretycznie wskazane, nie zawsze jest praktyczne. Chcąc wyeliminować wszystkie możliwe wewnętrzne zależności pomiędzy polami tabeli Klienci, należy utworzyć oddzielne tabele dla miast, kodów pocztowych, przedstawicieli handlowych, klas klienta i innych czynników, które mogą być zduplikowane w wielu rekordach. Normalizacja oznacza teoretycznie poprawę wydajności. Jednak wiele mniejszych tabel może spowodować spadek wydajności lub brak możliwości otwarcia pliku i przekroczenie pojemności pamięci. Copyright by Piotr Greniewski

293 Trzecia postać normalna – 3NF
Bardziej realne może okazać się zastosowanie trzeciej postaci normalnej tylko do często zmienianych danych. Pozostawiając niektóre pola zależne, zmień projekt aplikacji tak, aby po zmianie dowolnego pola wymagała od użytkownika sprawdzenia wszystkich pól pokrewnych. Copyright by Piotr Greniewski

294 Inne postacie normalne
Istnieje czwarta postać normalna, zwana również postacią normalną Boyce'a-Codda (BCNF) oraz piąta postać normalna, ale są one rzadko wykorzystywane w praktyce. Zlekceważenie tych reguł może skutkować mniej doskonałym projektem bazy danych, ale nie powinno ono wpływać na funkcjonalność. Copyright by Piotr Greniewski

295 Normalizowanie tabeli przykładowej
W poniższych krokach przedstawiono proces normalizacji fikcyjnej tabeli student. Mamy tabelę student w postaci nieznormalizowanej Tabela student Nr_Studenta Opiekun Pokój Klasa_1 Klasa_2 Klasa_3 1022 Nowak 412 101-07 143-01 159-02 4123 Kowalski 216 201-01 211-02 214-01 Copyright by Piotr Greniewski

296 Normalizowanie tabeli przykładowej
Pierwsza postać normalna: brak powtarzających się grup Tabele powinny mieć tylko dwa wymiary. Ponieważ jeden student ma kilka klas, klasy powinny znajdować się w oddzielnej tabeli. Występowanie pól Klasa_1, Klasa_2 i Klasa_3 w powyższych rekordach jest oznaką problemów podczas projektowania Copyright by Piotr Greniewski

297 Normalizowanie tabeli przykładowej
Arkusze kalkulacyjne często wykorzystują trzeci wymiar, ale tabele nie powinny. Innym podejściem do problemu jest związek (relationship) jeden-do-wielu, w którym nie należy strony jeden i strony wielu umieszczać w tej samej tabeli. Zamiast tego, należy utworzyć inną tabelę w pierwszej postaci normalnej, eliminując powtarzające się grupy (Nr_Klasy), tak jak to przedstawiono poniżej: Copyright by Piotr Greniewski

298 Normalizowanie tabeli przykładowej
Tabela student w 1NF Tabela student Nr_Studenta (PK) Opiekun Pokój Nr_Klasy 1022 Nowak 412 101-07 143-01 159-02 4123 Kowalski 216 201-01 211-02 214-01 Copyright by Piotr Greniewski

299 Normalizowanie tabeli przykładowej
Druga postać normalna: eliminowanie powtarzających się danych W powyższej tabeli dla każdego pola Nr_Studenta istnieje wiele wartości w polach Nr_Klasy. Pole Nr_Klasy nie jest czynnościowo zależne od pola Nr_Studenta (klucz podstawowy), dlatego ta relacja nie znajduje się w drugiej postaci normalnej. Drugą postać normalną przedstawiono na następujących dwóch tabelach: studenci i rejestracja Copyright by Piotr Greniewski

300 Normalizowanie tabeli przykładowej
Tabele student i rejestracja w 2NF Tabela student Nr_Studenta (PK) Opiekun Pokój 1022 Nowak 412 4123 Kowalski 216 Tabela rejestracja Nr_Studenta Nr_Klasy (PK) 1022 101-07 143-01 159-02 4123 201-01 211-02 214-01 Copyright by Piotr Greniewski

301 Normalizowanie tabeli przykładowej
Trzecia postać normalna: eliminowanie danych, które nie zależą od klucza W ostatnim przykładzie pole Pokój (numer pokoju opiekuna) jest czynnościowo zależne od atrybutu Opiekun. Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Studenci do tabeli Wydział, tak jak to przedstawiono poniżej: Copyright by Piotr Greniewski

302 Normalizowanie tabeli przykładowej
Tabele student, rejestracja i wydział w 3NF Tabela wydział Opiekun Pokój Wydział (PK) Nowak 412 40 Kowalski 216 41 Tabela rejestracja Nr_Studenta (FK) Nr_Klasy(PK) 1022 101-07 143-01 159-02 4123 201-01 211-02 214-01 Tabela student Nr_Studenta (PK) Wydział (FK) 1022 40 4123 41 Copyright by Piotr Greniewski


Pobierz ppt "Mgr inż. Piotr Greniewski"

Podobne prezentacje


Reklamy Google