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

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

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

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

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

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 1936.27 Belgia BEF 40.33 Copyright by Piotr Greniewski

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

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

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 1936.27 włoski Belgia BEF 40.33 ??? Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 {1936.27, ITL, Włochy} - niepoprawne typy atrybutów (zła kolejność) Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Arkusze kalkulacyjne Wiersz Kolumna Pani Anna Kowalska Tamka 13 m. 1 826-32-11 Pan Jan Zieliński Miła 15 m. 23 826-22-90 Ewa Wysocka Solec 6 m. 56 826-98-09 Wiersz Kolumna Copyright by Piotr Greniewski

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

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

Podstawowe typy danych Numeryczne typy danych SMALLINT – liczby całkowite małe z przedziału (-32 768,+32 767); INT – liczby całkowite z przedziału (-2 147 483 648,+2 147 483 647); NUMERIC (p,s) – liczby rzeczywiste, gdzie p oznacza całkowitą liczbę cyfr, a s oznacza liczbę cyfr po przecinku; Copyright by Piotr Greniewski

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

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

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

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

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

Tworzenie tabel nr imię nazwisko stanowisko telefon 001 Jan Kowalski Sprzedawca 826-78-90 002 Anna Kamińska 826-78-91 003 Krzysztof Adamski Kierownik 826-79-00 004 Piotr Michalski Mechanik 826-79-90 005 Marzena Kownacka Kasjer 826-79-21 006 Alicja Makowiecka 826-78-22 007 Wojciech Bagielski 826-78-23 Copyright by Piotr Greniewski

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

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

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. 28 00-567 Warszawa Dobra 4 m. 12 00-786 Warszawa Kasprowicza 2 00-799 Warszawa Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 1 2004’; CREATE USER Jan WITH PASSWORD ’jw8s0F4’ CREATEDB; Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tabela – wprowadzanie danych INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1000,'LEWARTOWSKIEGO', '12', 'WARSZAWA', '10-100', '228-277-097'); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES (1001,ALEJE LIPOWE', '3', 'WROCLAW', '32-134', '388-299-086'); VALUES (1002,'KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', '222-312-498'); VALUES (1003,'LOTNICZA', '9', 'POZNAN', '22-200', '778-512-044'); Copyright by Piotr Greniewski

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

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

Tabela – wprowadzanie danych z sekwencjami INSERT INTO MIEJSCA(NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('LEWARTOWSKIEGO', '12', 'WARSZAWA', '10-100', '228-277-097'); INSERT INTO MIEJSCA (NR_M,ULICA,NUMER,MIASTO,KOD,TELEFON) VALUES ('ALEJE LIPOWE', '3', 'WROCLAW', '32-134', '388-299-086'); VALUES ('KOCHANOWSKIEGO', '8', 'KRAKOW', '91-200', '222-312-498'); VALUES ('LOTNICZA', '9', 'POZNAN', '22-200', '778-512-044'); Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Transakcje i blokady co to są transakcje? reguły ACID transakcje z pojedynczym użytkownikiem ograniczenia transakcji transakcje z wieloma użytkownikami poziomy izolacji ANSI tryby związany i niezwiązany blokowanie zakleszczanie i jawne blokady Copyright by Piotr Greniewski

Co to są transakcje? Przykład zastosowania: musimy wykonać kilka komend SQL zmieniających dane w tablicach. Jak to zrobić aby komendy wykonał się poprawnie do końca albo wcale? Transakcja jest logiczną jednostką działań, której nie można podzielić. Logiczna jednostka działań to zbiór logicznych zmian w bazie danych, które należy wykonać wszystkie albo nie wykonywać żadnej. Copyright by Piotr Greniewski

Co to są transakcje? W języku PostgreSQL zmiany te są kontrolowane przez trzy kluczowe frazy: Fraza BEGIN WORK rozpoczyna transakcję; COMMIT WORK informuje, że wszystkie elementy transakcji są kompletne i powinny zostać zatwierdzone na stałe oraz stać się dostępne dla wszystkich transakcji; ROLLBACK WORK mówi, że należy porzucić transakcję, a wszystkie zmiany danych dokonane przez transakcję SQL mają być anulowane. Baza danych, z punktu widzenia użytkowników, powinna się znajdować w takim stanie, jakby nie były wykonywane żadne zmiany. Copyright by Piotr Greniewski

Co to są transakcje? Standard ANSI/SQL nie definiuje frazy SQL BEGIN WORK, transakcje w tym standardzie powinny wykonywać się automatycznie. Fraza ta jednak jest wymagana prawie we wszystkich implementacjach baz danych. Słowo WORK we frazie COMMIT WORK, ROLLBACK WORK można pominąć. Copyright by Piotr Greniewski

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

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

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

Reguły ACID ACID to mnemonik służący do opisania transakcji, jaka powinna być: Niepodzielna (Atomic) Spójna (Consistent) Odizolowana (Isolated) Trwała (Durable) Copyright by Piotr Greniewski

Reguły ACID Niepodzielna (Atomic). Transakcja, mimo że jest zbiorem odwołań, musi być wykonywana jako pojedyncza jednostka. Transakcja musi wykonywać się w jednym momencie i nie może dzielić się na podzbiory. Spójna (Consistent). Po wykonaniu transakcji system musi być spójny. Jeżeli w komendach SQL są ograniczenia to powinny być sprawdzone na końcu transakcji. Mowa o przykładzie ze słowem kluczowym DEFERRABLE ze slajdu nr 169 Copyright by Piotr Greniewski

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

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

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

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

Transakcje z pojedynczym użytkownikiem Ograniczenia transakcji W PostgreSQL tak jak w innych bazach nie wolno zagnieżdzać transakcji Zaleca się aby transakcje były niewielkie. PostgreSQL musi wykonać wiele działań aby upewnić się, że transakcje wielu użytkowników są rozdzielone. Te elementy, które biorą udział w transakcjach, muszą być zablokowane Transakcja, której wykonanie trwa długo i obejmuje wiele tabel, uniemożliwia innym użytkownikom korzystanie z danych, do czasu zakończenia lub anulowania transakcji Copyright by Piotr Greniewski

Transakcje z pojedynczym użytkownikiem Ograniczenia transakcji c.d. Należy unikać transakcji w czasie dialogu z użytkownikiem. Należy najpierw pobrać potrzebne dane a dopiero potem uruchamiać transakcję. Instrukcja COMMIT WORK trwa zazwyczaj szybko. Dużo dłużej trwa ROLLBACK WORK Copyright by Piotr Greniewski

Transakcje z wieloma użytkownikami Co oznacza że transakcje są izolowane? Poziomy izolacji ANSI. Samo osiągnięcie izolacji nie jest trudne. Zezwolenie na pojedyncze połączenie z bazą danych, z zaledwie jedną transakcją wykonywaną w danym czasie zapewnia izolację pomiędzy różnymi transakcjami. Osiągnięcie bardziej praktycznej izolacji, bez znacznego obniżenia wydajności powoduje uniemożliwienie uzyskania dostępu do bazy danych przez wielu użytkowników. Copyright by Piotr Greniewski

Transakcje z wieloma użytkownikami Osiągnięcie prawdziwej izolacji bez obniżenia wydajności bazy jest bardzo trudne dlatego standard SQL ANSI definiuje różne poziomy izolacji , które baza danych może implementować. Zazwyczaj RBD domyślnie implementuje co najmniej jeden z tych poziomów, oraz pozwala użytkownikom na zdefiniowanie przynajmniej jednego poziomu izolacji. Wprowadzimy teraz dodatkowe pojęcia pomocne w zrozumieniu poziomów izolacji. Copyright by Piotr Greniewski

Transakcje z wieloma użytkownikami Standard SQL ANSI definiuje poziomy izolacji w odniesieniu do niepożądanych zjawisk, które mogą się zdarzyć w czasie interakcji transakcji dla wielodostępnych baz danych; Niepożądane zjawiska: Brudny odczyt – ma miejsce wtedy, gdy pewne instrukcje SQL wewnątrz transakcji, odczytują dane, które zostały zmienione przez inną transakcję. Transakcja zaś nie zatwierdziła jeszcze swoich działań. PostgreSQL nigdy nie umożliwia operacji brudnego odczytu. Odczyty nie dające się powtórzyć – Podobne do brudnego odczytu. Zjawisko zachodzi wtedy, gdy transakcja odczytuje zbiór danych, następnie czyta dane ponownie i okazuje się, że dane nie są identyczne. Copyright by Piotr Greniewski

Transakcje z wieloma użytkownikami Niepożądane zjawiska c.d.: Odczyty widmo – problem podobny do odczytów nie dających się powtórzyć, ale mający miejsce wtedy gdy w tabeli znajdzie się nowy wiersz. Gdy inna transakcja aktualizuje tabelę nawy wiersz powinien być dodany a tak się nie staje. Utracone aktualizacje - Zachodzi wtedy gdy do bazy zapisywane są dwie różne zmiany i druga aktualizacja powoduje, że pierwsza zostaje utracona. Copyright by Piotr Greniewski

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

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

Blokady Wiele baz danych implementuje transakcje, a w szczególności izolację różnych transakcji użytkownika za pomocą blokad, które ograniczają dostęp do danych innym użytkownikom. Istnieją dwa typy blokad: blokada współdzielona (ang. shared lock), która pozwala innym użytkownikom odczytywać dane , ale nie zezwala na ich aktualizację. blokada wyłączna, która nie zezwala innym transakcjom nawet na odczyt danych. Copyright by Piotr Greniewski

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

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

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

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

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. 2 - 3 osobami poinformować wcześniej osoby o temacie rozmowy aby mogły się przygotować musimy mieć pomocnika do robienia notatek aby samemu skoncentrować się na rozmowie sesje rozmów powinny być krótkie i konkretne najpóźniej następnego dnia powinno się wśród wszystkich uczestników spotkania rozprowadzić szczegółową notatkę ze spotkania celem ewentualnej weryfikacji rozbieżności. Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reguły dotyczące przedstawiania relacji jako tabel Reguła nie prowadzenia "działalności wywrotowej": jeśli system jest wyposażony w interfejs niskiego poziomu (operacje na pojedynczych rekordach), nie może być użyty do prowadzenia działalności wywrotowej (np. omijania zabezpieczeń relacyjnych lub ograniczeń integralnościowych). W tym przypadku SQL-92 jest dobry . Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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 10000 zapisów, zaś plan kont będzie zawierał 500 pozycji, może to znacznie zwolnić działanie programu. Copyright by Piotr Greniewski

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

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

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

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 2 + 2 równa się 4: w matematyce co prawda przyjęto zaokrąglenie "od pięciu w górę", jednak pan na stacji benzynowej (bez wspomagania komputerowego w dodatku) wypisujący rachunek za paliwo może o tym wiedzieć. Copyright by Piotr Greniewski

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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