Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Bazy Danych Mgr inż. Piotr Greniewski Copyright by Piotr Greniewski 2 Bazy danych - Materiały Od podstaw - Bazy danych i PostgreSQL Richard Stones, Neil.

Podobne prezentacje


Prezentacja na temat: "Bazy Danych Mgr inż. Piotr Greniewski Copyright by Piotr Greniewski 2 Bazy danych - Materiały Od podstaw - Bazy danych i PostgreSQL Richard Stones, Neil."— Zapis prezentacji:

1

2 Bazy Danych Mgr inż. Piotr Greniewski

3 Copyright by 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.

4 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

5 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)

6 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

7 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 6.55 Niemcy DEM 1.95 Włochy ITL Belgia BEF 40.33

8 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.

9 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.

10 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 6.55 francuski Niemcy DEM 1.95 niemiecki Włochy ITL włoski Belgia BEF ???

11 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.

12 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]

13 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.

14 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)www.m-w.com

15 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.

16 Copyright by Piotr Greniewski 15 Rodzaje baz danych Sieciowy model baz danych Hierarchiczny model baz danych Relacyjny model 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.

17 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 krajuSymbolKurs Wskaźnik Język n Język n+1nil

18 Copyright by Piotr Greniewski 17 Sieciowy model bazy danych BelgiaBEF40.33 francuski flamandzkinil Mamy więc metodę wprowadzenia dowolnej ilości języków obowiązujących w danym państwie.

19 Copyright by Piotr Greniewski 18 Sieciowy model bazy danych WłochyITL FrancjaFRF6.55 NiemcyDEM1.95 BelgiaBEF40.33 francuski włoski flamandzki nil Tablica krajówTablica języków nil

20 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

21 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?

22 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.

23 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.

24 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.

25 Copyright by Piotr Greniewski 24 Hierarchiczny model baz danych GłowicaWał korb.Cylindry SilnikNadwozie Samochód Podwozie4 Koła

26 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ęść?

27 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.

28 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,

29 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.

30 Copyright by Piotr Greniewski 29 Relacyjny model bazy danych {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. ten sam wzorzec Wszystkie krotki w tabeli, mają ten sam wzorzec tzn. posiadają tą samą liczbę komponentów o identycznych typach.

31 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ść)

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

33 Copyright by Piotr Greniewski 32 Relacyjny model bazy danych integralność odwołań 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.

34 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.

35 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

36 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)

37 Copyright by Piotr Greniewski 36 Język zapytań SQL 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. Język manipulowania danymi (DML)

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

39 Copyright by Piotr Greniewski 38 Język zapytań SQL 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ń. Język sterowania danymi (DCL)

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

41 Copyright by Piotr Greniewski 40 Definicja tablicy w SQL CREATE TABLE Student ( Student_idserial, Nazwiskochar(50)not null, Imięchar(50)not null, Imię_ojcachar(10), Wpisowenumeric(7.2) );

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

43 Copyright by Piotr Greniewski 42 Dostęp do danych SELECT * FROM Student WHERE Nazwisko = Kowalski; KowalskiJanMarek KowalskiStefanJan KowalskiZenonJan350.00

44 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.

45 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ń.

46 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.

47 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.

48 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ć

49 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.

50 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.

51 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

52 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

53 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.

54 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.

55 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,...)

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

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

58 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;

59 Copyright by Piotr Greniewski 58 Arkusze kalkulacyjne PaniAnnaKowalskaTamka 13 m PanJanZielińskiMiła 15 m PaniEwaWysockaSolec 6 m Wiersz Kolumna

60 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.

61 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)?

62 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;

63 Copyright by Piotr Greniewski 62 Podstawowe typy danych Tworzenie tabeli – CREATE TABLE dla wartości numerycznych CREATE TABLE test ( mala_calkowitaSMALLINT, liczba_calkowitaINT, liczba_rzeczywistaNUMERIC (5,2) );

64 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.

65 Copyright by Piotr Greniewski 64 Podstawowe typy danych Tworzenie tabeli – CREATE TABLE dla znakowych typów danych CREATE TABLE test ( znakCHAR, cztery_znakiCHAR(4), znaki_do_128VARCHAR(128) );

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

67 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;

68 Copyright by Piotr Greniewski 67 Tworzenie tabel nrimięnazwiskostanowiskotelefon 001JanKowalskiSprzedawca AnnaKamińskaSprzedawca KrzysztofAdamskiKierownik PiotrMichalskiMechanik MarzenaKownackaKasjer AlicjaMakowieckaSprzedawca WojciechBagielskiSprzedawca

69 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_pracowCHAR(3) NOT NULL, imieVARCHAR(18)NOT NULL, nazwiskoVARCHAR(24)NOT NULL, stanowiskoVARCHAR(12)NOT NULL, dzialVARCHAR(12)NOT NULL, data_urodzDATE, telefon_domowyCHAR(12) );

70 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.

71 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

72 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. 1KowalskiJan KowalskiJan KwiatkowskiMarian Unikalny klucz

73 Copyright by Piotr Greniewski 72 Projektowanie tabel Usunięcie powtarzających się informacji (powtarzających się grup) – relacja jeden do wielu; Id_klientaNazwaMiastotelefon 1ABC S.A.Warszawa XYZ S.A.Toruń Id_zamówieniaId_klientaTowarIlość kg 11Jabłka10 21Gruszki6

74 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.

75 Bazy danych Instrukcje języka SQL - podstawy

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

77 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

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

79 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

80 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

81 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;

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

83 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;

84 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);

85 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 SELECT marka, typ, rok_prod, kolor, poj_silnika FROM samochody WHERE poj_silnika BETWEEN 1100 AND 1800;

86 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;

87 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%

88 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.

89 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..

90 Copyright by Piotr Greniewski 89 Wybieranie wartości z wielu tabel - Podstawy NazwiskoImięNr_miejsca KowalskiJan1 GajosAnna2 ZalewskaAnna3 Nr_miejscaUlicaNrMiastoKod 1Dobra5Poznań Anna21Wrocław Pracownicy Miejsc a

91 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;

92 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.

93 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.

94 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 ANDp.nr_p= w.prac_wyp ANDm.miasto = WARSZAWA ORDER BY p.nazwisko; 1 warunek 2 warunek 3 warunek

95 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;

96 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 ANDp.stanowisko=sprzedawca ORDER BY p.nazwisko;

97 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.

98 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: OperatorZnaczenie +dodawanie -odejmowanie *mnożenie /dzielenie

99 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;

100 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

101 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

102 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

103 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

104 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 || SELECTk.imie || || k.nazwisko AS Klient, ul. || k.ulica || || k.numer AS Ulica, k.kod || || k.miasto AS Miasto FROMklienci k ORDER BY k.nazwisko 5.16

105 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 FROMklienci k ORDER BY k.nazwisko 5.17

106 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.

107 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.

108 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

109 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

110 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

111 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

112 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

113 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.

114 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.

115 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 SELECT imie, nazwisko FROM pracownicy WHERE nazwisko LIKE %ski; 7.2

116 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 SELECT imie, nazwisko FROM pracownicy WHERE nazwisko LIKE %ski ORDER BY nazwisko DESC; 7.3

117 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 SELECT imie, nazwisko FROM pracownicy WHERE nazwisko LIKE %ski ORDER BY nazwisko DESC; 7.3

118 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

119 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

120 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

121 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. TomaszAdamczakWarszawa PawełFiodorowiczWarszawa AnnaKowalskaWrocław PiotrMalczykWarszawa TomaszAdamczakWarszawa AnielaDalgiewiczWrocław KrzysztofDobrowolskiWrocław AnnaKowalskaWrocław NOT IN ZBIÓR A ZBIÓR B PawełFiodorowiczWarszawa PiotrMalczykWarszawa A NOT IN B

122 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

123 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

124 Bazy Danych Instrukcje języka SQL - zaawansowane

125 Copyright by Piotr Greniewski 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= WHERE nazwa=ACTION S.A.

126 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.

127 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

128 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;

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

130 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;

131 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

132 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;

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

134 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;

135 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;

136 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;

137 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;

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

139 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;

140 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;

141 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

142 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)

143 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ść.

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

145 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)];

146 Copyright by Piotr Greniewski 145 CONSTRAINT – ograniczenia dla tabeli OgraniczenieOpis 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 Ograniczenia dla kolumn

147 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 <> ) );

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

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

150 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.

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

152 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', ' '); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1002,'KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', ' '); INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1003,'LOTNICZA', '9', 'POZNAN', '22-200', ' ');

153 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)

154 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), );

155 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', ' '); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', ' '); INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('LOTNICZA', '9', 'POZNAN', '22-200', ' ');

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

157 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.

158 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

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

160 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) CONSTRAINTNR_M_FK FOREIGN KEY (NR_M) REFERENCES MIEJSCA(NR_M) );

161 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) ); CREATE TABLE dystrybutorzy ( dystr DECIMAL(3) PRIMARY KEY, nazwa VARCHAR(40) );

162 Copyright by Piotr Greniewski 161 CONSTRAINT – ograniczenia dla tabeli FunkcjaOpis 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 Ograniczenia dla tabel

163 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 ALTER TABLE nazwa_tabeli 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;

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

165 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 (...);

166 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);

167 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 ] COPY [ BINARY ] table [ WITH OIDS ] TO { filename | stdout } [ [USING] DELIMITERS delimiter ] [ WITH NULL AS null string ]

168 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 \.

169 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

170 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;

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

172 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 ] CREATE [ UNIQUE ] INDEX index_name ON table [ USING acc_method ] ( func_name( column [,... ]) [ ops_name ] ) [ WHERE predicate ] Przykład: CREATE UNIQUE INDEX tytol_idx ON filmy (tytol);

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

174 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 ELEMENT_ID INTEGER ILOŚĆ INTEGER ZAPAS ELEMENT_ID – ELEMENT_ID INFO_ID INTEGER ELEMENT_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 ELEMENT_ID – ELEMENT_ID INFO_ID – INFO_ID

175 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.

176 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

177 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)

178 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_idserial, klient_idinteger not null REFERENCE klient(klient_id), data_dostawydate not null, data_wysylkidate, CONSTRAINTinfo_pk PRIMARY KEY(info_id) )

179 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)

180 Copyright by Piotr Greniewski 179 Klucze obce jako ograniczenia dla tabel Przykład: CREATE TABLE info_zlecenia ( info_idserial, klient_idinteger not null, data_dostawydate not null, data_wysylkidate, CONSTRAINTinfo_pk PRIMARY KEY(info_id), CONSTRAINTklient_fk FOREIGN KEY(klient_id) REFERENCESklient(klient_id) )

181 Copyright by Piotr Greniewski 180 Klucze obce jako ograniczenia dla tabel Przykład: CREATE TABLE linia_zlecenia ( info_idserial, element_idinteger not null, zapasinteger not null, CONSTRAINTlinia_pk PRIMARY KEY(info_id), REFERENCESinfo_zlecenia(info-id), CONSTRAINTelement_id_pk FOREIGN KEY(element_id) REFERENCESelement(element_id) )

182 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

183 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.

184 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_idserial, klient_idinteger not null, data_dostawydate not null, data_wysylkidate, CONSTRAINTinfo_pk PRIMARY KEY(info_id), CONSTRAINTklient_fk FOREIGN KEY(klient_id) REFERENCESklient(klient_id) DEFERRABLE )

185 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_idserial, klient_idinteger not null, data_dostawydate not null, data_wysylkidate, CONSTRAINTinfo_pk PRIMARY KEY(info_id), CONSTRAINTklient_fk FOREIGN KEY(klient_id) REFERENCESklient(klient_id) ON DELETE CASCADE )

186 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

187 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[] )

188 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;

189 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) FROM zakupy;

190 Copyright by Piotr Greniewski 189 Operacje manipulowania danymi FunkcjaOpis 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

191 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

192 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

193 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.

194 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.

195 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ąć.

196 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.

197 Copyright by Piotr Greniewski 196 Trzeba uważać aby nie wpaść w pewną pułapkę? KLIENT 1KLIENT 2Wolne miejsce Czy są wolne miejsca?1 1 Oferuje miejsce1 1 Pytanie o kartę kredytową lub konto1 1 Podaje numer kartyPodaje numer konta1 Autoryzacja1 1 Przypisanie miejsca1 1 Obciążenie karty1 1 Zmniejszenie liczby wolnych miejsc0

198 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ć???

199 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)

200 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

201 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.

202 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

203 Copyright by Piotr Greniewski 202 Transakcje z pojedynczym użytkownikiem 6 BEGIN WORK1 Wykonaj kod SQL;2 Wykonaj kod SQL;3 Wykonaj kod SQL;4 ROLLBACK WORK5 Gdy stwierdzamy, że nie chcemy zakończenia wykonania transakcji to wykonujemy ROLLBACK WORK

204 Copyright by Piotr Greniewski 203 Transakcje z pojedynczym użytkownikiem 6 BEGIN WORK1 Wykonaj kod SQL;2 Wykonaj kod SQL;3 Wykonaj kod SQL;4 COMMIT WORK5 Gdy stwierdzamy, że chcemy zakończenia wykonania transakcji to wykonujemy COMMIT WORK

205 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

206 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

207 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.

208 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.

209 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.

210 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.

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

212 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)

213 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.

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

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

216 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

217 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? ???

218 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.

219 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

220 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

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

222 Copyright by Piotr Greniewski 221 Związki pomiędzy tabelami 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 Tabela ATabela B

223 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

224 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.

225 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 1979 r. jako pierwszą wersję relacyjnego modelu danych.

226 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

227 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.

228 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.

229 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.

230 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 )

231 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, t 2,..., 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.

232 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, t 2, t 3, t 4, t 5, t 6, t 7, t 8, t 9, t 10 } wartość m = 10 bo istnieje max. dziesięć par {dzień,dyżurny} np. dla m=1 odwzorowanie t 1 : R DOM ( R) t 1 ={pon, Kwiatkowski} spełnia warunek bo dla j=1 t 1 ( A 1 ) DOM ( A 1 ) i dla j=2 t 1 ( A 2 ) DOM ( A 2 )

233 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: 1.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. 2.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. 3.Wszystkie wartości w kolumnie muszą być tego samego typu. (wynika to z punktu 2)

234 Copyright by Piotr Greniewski 233 Relacja zbiór zasad c.d.: 4.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. 5.Każdy wiersz w relacji musi być różny. Innymi słowy, powtórzenia wierszy nie są dozwolone w relacji. 6.Porządek wierszy nie jest istotny. Skoro zawartość relacji jest zbiorem, to nie powinno być określonego porządku wierszy relacji. 7.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.

235 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.

236 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.

237 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

238 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.

239 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.

240 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

241 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?

242 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

243 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.

244 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

245 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

246 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).

247 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.

248 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.

249 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.

250 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.

251 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.

252 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.

253 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: I.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. II.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łę.

254 Copyright by Piotr Greniewski 253 Reguły dotyczące przedstawiania relacji jako tabel III.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.

255 Copyright by Piotr Greniewski 254 Reguły dotyczące przedstawiania relacji jako tabel IV.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

256 Copyright by Piotr Greniewski 255 Reguły dotyczące przedstawiania relacji jako tabel V.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.

257 Copyright by Piotr Greniewski 256 Reguły dotyczące przedstawiania relacji jako tabel VI.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).

258 Copyright by Piotr Greniewski 257 Reguły dotyczące przedstawiania relacji jako tabel VII.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. VIII. 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

259 Copyright by Piotr Greniewski 258 Reguły dotyczące przedstawiania relacji jako tabel IX.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. X.Logiczna niezależność danych: to także jest oczywiste. Ten aspekt jest całkiem dobrze realizowany w SQL-u. XI.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.

260 Copyright by Piotr Greniewski 259 Reguły dotyczące przedstawiania relacji jako tabel XI.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.

261 Copyright by Piotr Greniewski 260 Reguły dotyczące przedstawiania relacji jako tabel XII.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.

262 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.

263 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.

264 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ł?

265 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ń.

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

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

268 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

269 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.

270 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".

271 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ą.

272 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.

273 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.

274 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.

275 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.

276 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.

277 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ć.

278 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".

279 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

280 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

281 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.

282 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.

283 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

284 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

285 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.

286 Copyright by Piotr Greniewski 285 Pierwsza postać normalna - 1NF Pierwsza postać normalna: 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.

287 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.

288 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

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

290 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.

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

292 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.

293 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.

294 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.

295 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ść.

296 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_StudentaOpiekunPokójKlasa_1Klasa_2Klasa_3 1022Nowak Kowalski

297 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

298 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:

299 Copyright by Piotr Greniewski 298 Normalizowanie tabeli przykładowej Tabela student w 1NF Tabela student Nr_Studenta (PK)OpiekunPokójNr_Klasy 1022Nowak Nowak Nowak Kowalski Kowalski Kowalski

300 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

301 Copyright by Piotr Greniewski 300 Normalizowanie tabeli przykładowej Tabele student i rejestracja w 2NF Tabela student Nr_Studenta (PK)OpiekunPokój 1022Nowak Kowalski216 Tabela rejestracja Nr_StudentaNr_Klasy (PK)

302 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:

303 Copyright by Piotr Greniewski 302 Normalizowanie tabeli przykładowej Tabele student, rejestracja i wydział w 3NF Tabela wydział OpiekunPokójWydział (PK) Nowak41240 Kowalski21641 Tabela student Nr_Studenta (PK)Wydział (FK) Tabela rejestracja Nr_Studenta (FK)Nr_Klasy(PK)


Pobierz ppt "Bazy Danych Mgr inż. Piotr Greniewski Copyright by Piotr Greniewski 2 Bazy danych - Materiały Od podstaw - Bazy danych i PostgreSQL Richard Stones, Neil."

Podobne prezentacje


Reklamy Google