Bazy danych Projektowanie i implementacja relacyjnych baz danych

Transkrypt

1 Bazy danych Projektowanie i implementacja relacyjnych baz danych Marcin Szpyrka Katedra Informatyki Stosowanej AGH w Krakowie 2016/17 Literatura 1. Jeffrey D. Ullman, Jennifer Widom: Podstawowy kurs systemów baz danych, Helion, Gliwice, Thomas Connolly, Carolyn Begg: Systemy baz danych, tom 1 i 2, Wydawnictwo RM, Warszawa, Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom: Systemy baz danych. Pełny wykład, WNT, Warszawa, Chris J. Date: Relacyjne bazy danych dla praktyków, Wydawnictwo Helion, Gliwice, Bill Karwin: Antywzorce języka SQL, Wydawnictwo Helion, Gliwice, Joe Celko: SQL zaawansowane techniki programowania, Wydawnictwo Naukowe PWN, Warszawa, Sharon Allen: Modelowanie danych, Wydawnictwo Helion, Gliwice, dokumentacja systemu PostgreSQL. 9. Antoni Ligęza: Materiały do wykładów z baz danych, Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 2/99

2 Cykl życia aplikacji baz danych 1. Planowanie metod realizacji faz cyklu życia: identyfikacja celów i planów, ocena aktualnego systemu, określenie standardów dokumentowania itp. 2. Określenie zakresu i granic aplikacji bazy danych oraz głównych perspektyw użytkowników. Perspektywa użytkownika definiuje, jakie są oczekiwania wobec aplikacji z punktu widzenia konkretnego stanowiska pracy lub pewnego obszaru zastosowań. 3. Zbieranie i analiza wymagań pochodzących od użytkowników i wynikających z obszarów zastosowań w efekcie powstaje specyfikacja wymagań. Wymagania dotyczące perspektyw mogą być połączone w jeden zbiór wymagań (perspektywę) lub dla każdej z nich można budować niezależny model danych (modele są łączone w późniejszej fazie). 4. Projektowanie konceptualne, logiczne i fizyczne bazy danych, a także projektowanie interfejsów użytkowników i programów użytkowych, które będą przetwarzać bazę danych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 3/99 Modelowanie danych Model danych stanowi szkic bazy danych, a nie bazę jako taką. Stanowi jeden z wielu elementów składających się na projekt aplikacji. Różne modele stanowią różne punkty widzenia tego samego systemu. Przy projektowaniu dużych systemów bazodanowych stosuje się trzy modele: koncepcyjny, logiczny i fizyczny. Model koncepcyjny służy do dokumentowania wysokopoziomowych idei i jest niezależny od wszelkich aspektów fizycznych takich jak stosowany model danych (relacyjny, obiektowy), SZBD, platforma sprzętowa itp. Model logiczny jest modelem opartym na specyficznym modelu danych (relacyjny, obiektowy), ale niezależnym od konkretnego SZBD, platformy sprzętowej itp. Model fizyczny stanowi faktyczny projekt bazy danych i stanowi podstawę implementacji systemu. Uwzględnia on relacje występujące w systemie, więzy integralności, indeksy itp. Na wykładzie skupiamy się wyłącznie na projektowaniu relacyjnych baz danych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 4/99

3 Model związków encji encje i atrybuty Projekt wysokopoziomowy będzie reprezentowany na wykładzie za pomocą diagramu klas języka UML. Pomimo, że używana będzie notacja UML, to poszczególne elementy będą nazywane i interpretowane z użyciem terminologii baz danych. Encja jest obiektem abstrakcyjnym. Kolekcja podobnych encji tworzy zbiór encji. Encja i zbiór encji są analogią do obiektu i klasy w programowaniu obiektowym, przy czym encje nie mają metod. Wystąpienie encji jest unikalnym i rozpoznawalnym obiektem ze zbioru encji. Atrybut jest własnością (cechą) encji, należących do danego zbioru encji. Zakładamy, że atrybuty są typów prostych, np. ciąg znaków, liczba całkowita, data itp. Zbiór encji reprezentujemy jako klasę (bez metod). Symbol # wskazuje atrybut kluczowy. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 5/99 Związki Związek jest zbiorem powiązań pomiędzy uczestniczącymi w tym związku zbiorami encji. Wystąpienie związku jest unikalnym i identyfikowalnym powiązaniem zachodzącym pomiędzy pojedynczymi wystąpieniami encji z uczestniczących w związku zbiorów encji. Związki reprezentujemy za pomocą asocjacji. Pudełka Zawiera Czekoladki alpi bitt m12 m01 b7 b6 b5 b4 b2 Sieć semantyczna przedstawiająca przykłady wystąpień związków Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 6/99

4 Stopień związku Uczestnicy związku są to zbiory encji biorące udział w danym związku. Stopień związku oznacza liczbę uczestników związku. Związek binarny jest to związek o stopniu 2. Związek złożony jest to związek o stopniu większym niż 2. Do reprezentowania takiego związku na diagramie UML, konieczne jest użycie łącznika w kształcie rombu (z przypisaną etykietą). Dowolny związek złożony można zastąpić zbiorem związków binarnych (wprowadzając dodatkowy łączący zbiór encji, np. zbiór encji Kontrakty w powyższym przypadku). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 7/99 Role w związkach Pomiędzy dwoma zbiorami encji może występować więcej niż jeden związek. Dany zbiór encji może występować w różnych związkach w różnych rolach. Związkom mogą być przypisane nazwy ról, wskazujące, jakie role odgrywają poszczególne zbiory encji w tych związkach. Związek binarny, w którym ten sam zbiór encji występuje dwukrotnie nazywamy rekurencyjnym (unarnym). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 8/99

5 Silne i słabe zbiory encji Silny zbiór encji to zbiór encji, którego istnienie nie jest zależne od innych zbiorów encji. Cechą charakterystyczną silnego zbioru encji jest jednoznaczna identyfikacja każdego wystąpienia encji przez atrybut(y) klucza głównego tego zbioru. Słaby zbiór encji to zbiór encji, którego istnienie zależy od innych zbiorów encji. Cechą charakterystyczną słabego zbioru encji jest brak jednoznacznej identyfikacji każdego wystąpienia encji za pomocą atrybutów przypisanych wyłącznie temu zbiorowi encji. Słabe zbiory encji nazywane są też encjami podrzędnymi, a silne zbiory encji encjami nadrzędnymi. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 9/99 Atrybuty w związkach Dla dowolnego związku można określić jeden lub więcej atrybutów. W języku UML reprezentujemy je za pomocą klasy asocjacji, która dołączona jest do asocjacji (związku). Klasa asocjacji może mieć własną nazwę, ale jej atrybuty uważamy za atrybuty odpowiedniego związku. Wśród tych atrybutów nie określa się klucza. Obecność przynajmniej jednego atrybutu przypisanego do związku może oznaczać, że za tym związkiem kryje się niezidentyfikowany zbiór encji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 10/99

6 Krotność związku Krotność jest to liczba lub zakres możliwych wystąpień encji z jednego zbioru, które mogą być w danym związku z pojedynczym wystąpieniem innej powiązanej encji. Krotność opisuje dwa oddzielne więzy nazywane licznością i uczestnictwem. Liczność opisuje maksymalną liczbę możliwych wystąpień związku dla encji uczestniczącej w tym związku. Uczestnictwo określa, czy w pewnym związku biorą udział wszystkie, czy tylko niektóre wystąpienia encji. liczność Jedno biuro jest zarządzane przez jednego pracownika Jeden pracownik zarządza jednym biurem zwiazek 1-1 uczestnictwo Wszystkie biura są zarządzane Nie każdy pracownik zarządza biurem Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 11/99 Krotność związku (2) Krotność oznaczamy etykietą postaci m..n, przy czym symbol * użyty w miejsce n oznacza nieskończoność (brak ograniczenia górnego). zwiazek 1-n Każda nieruchomość do wynajęcia jest nadzorowana przez zero lub jednego pracownika Każdy pracownik nadzoruje zero lub więcej nieruchomości do wynajęcia zwiazek n-n Każda nieruchomość do wynajęcia jest ogłaszana w zero lub więcej gazet Każdy gazeta ogłasza jedna lub więcej nieruchomości do wynajęcia Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 12/99

7 Pułapka wachlarzowa Pułapka wachlarzowa występuje w sytuacji, gdy model przedstawia związek pomiędzy pewnymi zbiorami encji, ale wynikające z tego ścieżki pomiędzy wystąpieniami encji nie są jednoznaczne. Pułapka wachlarzowa może wystąpić, gdy co najmniej dwa związki typu 1-n wychodzą z tej samej encji. Personel Ma Oddziały Prowadzi Biura SG37 SA9 SL21 D1 D2 B003 B007 B005 Nie ma możliwości odpowiedzi na pytanie W jakim biurze pracuje pracownik o numerze SG37? Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 13/99 Pułapka wachlarzowa poprawiony projekt Pułapka zostaje wyeliminowana po zmianie struktury diagramu związków encji. Oddziały Prowadzi Biura Ma Personel D1 D2 B003 B007 B005 SG37 SA9 SL21 Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 14/99

8 Pułapka szczelinowa Pułapka szczelinowa występuje, gdy model sugeruje istnienie związku pomiędzy zbiorami encji, ale nie istnieją ścieżki łączące pewne wystąpienia tych encji. Pułapka szczelinowa może wystąpić, gdy w modelu znajduje się co najmniej jeden związek o minimalnej krotności zero, który jest elementem ścieżki pomiędzy powiązanymi encjami. Biura Ma Personel Nadzoruje Nieruchomości B003 SG37 PG36 B007 SA9 PA14 B005 SL21 PL94 Nie ma możliwości odpowiedzi na pytanie W jakim biurze jest dostępna nieruchomość o numerze PA14?, bo nie została przypisana ona żadnemu pracownikowi. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 15/99 Pułapka szczelinowa poprawiony projekt Pułapka zostaje wyeliminowana po dodaniu nowego związku. Biura Ma Personel Nadzoruje Nieruchomości B003 B007 B005 SG37 SA9 SL21 PG36 PA14 PL94 Oferuje Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 16/99

9 Hierarchia zbiorów encji Podklasa jest wyróżnioną podgrupą wystąpień ze zbioru encji, która powinna być oddzielnie reprezentowana w modelu danych. Nadklasa jest zbiorem encji, który ma co najmniej jedną wyróżnioną podklasę. Hierarchia typów jest strukturą zależności nadklasa-podklasa podklasa może być nadklasą dla kolejnych podklas. uczestnictwo rozłaczność Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 17/99 Własności związków nadklasa-podklasa Każda encja w podklasie jest też identyczną encją w nadklasie, ale pełni w niej inną rolę. Nie każda encja z nadklasy musi być elementem podklasy. Podklasy tej samej nadklasy mogą być rozłączne lub mogą się częściowo pokrywać. Atrybuty nadklas są dziedziczone przez wspólne podklasy, które mogą mieć swoje własne dodatkowe atrybuty. Podklasa może mieć więcej niż jedną nadklasę wystąpienie encji takiej podklasy musi być jednocześnie wystąpieniem encji wszystkich powiązanych z podklasą nadklas. Na związek nadklasa-podklasa możemy nałożyć więzy opisujące uczestnictwo Czy każdy element nadklasy musi być elementem pewnej podklasy (obowiazkowe), czy nie (opcjonalne)? ) i rozłączność Czy element nadklasy może należeć do jednej (Lub), czy do wielu podklas (I)?. Związki nadklasa-podklasa pozwalają uniknąć kilkakrotnego opisywania podobnych obiektów, pozwalają zaznaczyć związki, które zachodzą tylko dla pewnych podklas oraz wnoszą informacje semantyczne do projektu, np. dyrektor jest elementem personelu. Dla jednej encji można określić kilka specjalizacji (grup podklas) bazujących na odmiennych wyróżniających je statystykach. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 18/99

10 Konceptualny model danych Na konceptualny model danych składają się: zbiory encji, typy związków, atrybuty i dziedziny atrybutów, klucze i klucze główne i więzy integralności. 1. Określenie występujących zbiorów encji (słownik danych). 2. Ustalenie typów związków: budowa diagramu związków encji, ustalenie krotności związków, sprawdzenie czy występują pułapki wachlarzowe lub szczelinowe, sprawdzenie, czy każdy zbiór encji występuje w przynajmniej jednym związku. 3. Określenie atrybutów odpowiadających poszczególnym zbiorom encji i związkom. 4. Określenie dziedzin poszczególnych atrybutów (słownik danych). 5. Ustalenie kluczy (słownik danych) i wybór klucza głównego. Na tym etapie następuje ustalenie, które zbiory encji są silne, a które słabe. 6. Zastosowanie zaawansowanych metod modelowania (opcjonalnie) nadklasy, podklasy. 7. Sprawdzenie występowania i usunięcie redundancji: sprawdzenie, czy te same obiekty ze świata rzeczywistego nie są reprezentowane wielokrotnie przez różne encje; usunięcie redundantnych związków, które dostarczają informacji, które można uzyskać w oparciu o inny związek. 8. Sprawdzenie, czy uzyskany model umożliwia realizację wszystkich planowanych transakcji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 19/99 Usuwanie cech niekompatybilnych z modelem relacyjnym (1) Podstawą tworzenia logicznego modelu danych jest konceptualny model danych. W przypadku projektowania relacyjnych baz danych z modelu należy usunąć cechy niekompatybilne z modelem relacyjnym: 1. Usuwanie binarnych związków typu wiele do wielu. Tworzymy pośredni słaby zbiór encji i zamieniamy związek wiele do wielu na dwa związki jeden do wielu, w których występuje nowy zbiór encji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 20/99

11 Usuwanie cech niekompatybilnych z modelem relacyjnym (2) 2. Usuwanie rekurencyjnych związków typu wiele do wielu. Podobnie jak poprzednio tworzymy pośredni słaby zbiór encji i zamieniamy związek wiele do wielu na dwa związki jeden do wielu. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 21/99 Usuwanie cech niekompatybilnych z modelem relacyjnym (3) 3. Usuwanie związków złożonych. Tworzymy pośredni słaby zbiór encji i zamieniamy związek złożony na odpowiednią liczbę związków binarnych jeden do wielu, w których występuje nowy zbiór encji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 22/99

12 Wyznaczanie relacji dla logicznego modelu danych (1) Dla każdego silnego zbioru encji tworzymy relację o tej samej nazwie oraz z tym samym zbiorem atrybutów. Dla każdego słabego zbioru encji tworzymy relację o tej samej nazwie oraz z tym samym zbiorem atrybutów na tym etapie relacja ta nie zawiera jeszcze klucza głównego, bo klucz główny słabej encji jest częściowo lub całkowicie wyznaczany na podstawie encji nadrzędnych. W każdym binarnym związku typu jeden do wielu zbiór encji występujący po stronie jeden jest nadrzędny, a po stronie wiele podrzędny. Związek taki jest reprezentowany przez umieszczenie atrybutów klucza głównego nadrzędnego zbioru encji w relacji utworzonej dla podrzędnego zbioru encji. Atrybuty te stanowią klucz obcy relacji podrzędnej. Jeżeli ze związkiem połączona jest klasa asocjacji, to jej atrybuty również umieszczamy w relacji utworzonej dla podrzędnego zbioru encji. Personel: {idpracownika, imie, nazwisko, stanowisko, pensja, idbiura} Biura: {idbiura, adres, telefon} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 23/99 Wyznaczanie relacji dla logicznego modelu danych (2) Binarne związki jeden do jednego: Jeżeli po obu stronach związku występuje obowiązkowe uczestnictwo, to oba zbiory encji łączymy w jedną relację i wybieramy klucz jednego z nich jako klucz główny tworzonej relacji. Do relacji dodajemy także atrybuty ewentualnej klasy asocjacji. Jeżeli tylko po jednej stronie związku występuje obowiązkowe uczestnictwo, to ten zbiór encji jest zbiorem podrzędnym. Ze związkiem takim postępujemy analogicznie jak w przypadku związku jeden do wielu. Jeżeli po obu stronach związku występuje opcjonalne uczestnictwo, to dowolnie wybieramy, która z encji jest nadrzędna i postępujemy jak poprzednio mogą istnieć inne przesłanki wskazujące, która encja powinna być nadrzędna. Rekurencyjne związki jeden do jednego: Jeżeli po obu stronach związku występuje obowiązkowe uczestnictwo, to tworzymy jedną relację z dwoma kopiami klucza głównego (jedna z nich jest kluczem obcym konieczna jest zmiana nazwy). Jeżeli tylko po jednej stronie związku występuje obowiązkowe uczestnictwo, to postępujemy jak wyżej lub tworzymy tworzymy dodatkową relację reprezentującą związek, która zawiera dwie kopie klucza głównego (obie w roli klucza obcego). Jeżeli po obu stronach związku występuje opcjonalne uczestnictwo, to tworzymy dodatkową relację jak opisano powyżej. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 24/99

13 Wyznaczanie relacji dla logicznego modelu danych (3) Związki nadklasa-podklasa: W każdym takim związku nadklasa jest nadrzędnym, a podklasa podrzędnym zbiorem encji. Metoda wyznaczenia relacji zależy od wielu czynników, np. więzów uczestnictwa i rozłączności. Uczestnictwo Rozłaczność Relacje Obowiązkowe I Jedna relacja (z jednym lub większą liczbą dyskryminatorów wyznaczających typ każdej krotki). Opcjonalne I Dwie relacje: jedna reprezentuje nadklasę, a druga podklasę (z jednym lub większą liczbą dyskryminatorów) Obowiązkowe Lub Wiele relacji: jedna relacja dla każdej kombinacji nadklasa-podklasa. Opcjonalne Lub Wiele relacji: jedna reprezentuje nadklasę i osobne relacje dla każdej z podklas. Dyskryminator jest dodatkowym atrybutem, który pozwala określić zakres znaczeniowy każdej z krotek relacji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 25/99 Wyznaczanie relacji dla logicznego modelu danych (4) Obowiązkowe, I Właściciele: {idwłaściciela, adres, telefon, imię, nazwisko, nazwa, typ, nazwiskoreprezentanta, pwłaściciel, iwłaściciel} Uwaga: Użycie dwóch dyskryminatorów nie jest konieczne, można użyć jeden lub zrezygnować z nich i przynależność do podklasy ustalać na podstawie tego, które atrybuty unikalne dla poszczególnych klas przyjmują wartości null. Opcjonalne, I Właściciele: {idwłaściciela, adres, telefon} WłaścicieleSzczegóły: {idwłaściciela, imię, nazwisko, nazwa, typ, nazwiskoreprezentanta, pwłaściciel, iwłaściciel} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 26/99

14 Wyznaczanie relacji dla logicznego modelu danych (5) Obowiązkowe, Lub WłaścicielePrywatni: {idwłaściciela, adres, telefon, imię, nazwisko} WłaścicieleInstytucjonalni: {idwłaściciela, adres, telefon, nazwa, typ, nazwiskoreprezentanta} Opcjonalne, Lub Właściciele: {idwłaściciela, adres, telefon} WłaścicielePrywatni: {idwłaściciela, imię, nazwisko} WłaścicieleInstytucjonalni: {idwłaściciela, nazwa, typ, nazwiskoreprezentanta} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 27/99 Logiczny model danych Na logiczny model danych składają się: diagram związków encji, schematy relacji oraz dokumentacja pomocnicza (w szczególności słownik danych). 1. Usunięcie własności niekompatybilnych z modelem relacyjnym. 2. Wyznaczenie relacji dla logicznego modelu danych. 3. Normalizacja relacji. 4. Sprawdzenie, czy uzyskany model umożliwia realizację wszystkich planowanych transakcji. 5. Określenie więzów integralności (słownik danych): wymagana obecność danych, więzy dziedzin atrybutów (np. dla atrybutu płeć dopuszczalne wartości to K i M), integralność referencyjna i więzy ogólne (reguły biznesowe, np. ograniczenie do 100 liczby zarządzanych nieruchomości). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 28/99

15 Przykład Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 29/99 Przykład relacje uzyskane z przekształcenia zbiorów encji Czekoladki: {idczekoladki, nazwa, czekolada, orzechy, nadzienie, opis, koszt, masa} Zawartość: {sztuk} Pudełka: {idpudełka, nazwa, opis, cena, stan} Artykuły: {sztuk} Zamówienia: {idzamówienia, datarealizacji} Klienci: {idklienta, nazwa, ulica, miejscowość, kod, telefon} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 30/99

16 Przykład relacje uzyskane z przekształcenia związków Czekoladki: {idczekoladki, nazwa, czekolada, orzechy, nadzienie, opis, koszt, masa} Zawartość: {sztuk, idczekoladki, idpudełka} Pudełka: {idpudełka, nazwa, opis, cena, stan} Artykuły: {sztuk, idpudełka, idzamówienia} Zamówienia: {idzamówienia, datarealizacji, idklienta} Klienci: {idklienta, nazwa, ulica, miejscowość, kod, telefon} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 31/99 Przykład fizyczny projekt relacji Czekoladki Atrybuty: idczekoladki łańcuch o stałej długości (3 znaki), składający się z jednej litery i dwóch cyfr; nazwa łańcuch o zmiennej długości, maksymalnie 30 znaków, not null, unique; czekolada łańcuch o zmiennej długości, maksymalnie 15 znaków; orzechy łańcuch o zmiennej długości, maksymalnie 15 znaków; nadzienie łańcuch o zmiennej długości, maksymalnie 15 znaków; opis łańcuch o zmiennej długości, maksymalnie 100 znaków, not null; koszt wartość walutowa z przedziału , not null; masa liczba całkowita dodatnia, not null. Klucze: klucz główny: idczekoladki klucz alternatywny: nazwa Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 32/99

17 Cele normalizacji (1) Normalizacja relacji ma na celu takie jej przekształcenie, by nie posiadała ona cech niepożądanych. wypozyczenia sygnatura imie nazwisko adres ( /1, Jan, Nowak, ul. Wiosenna 23/ Kraków ) Konsekwencje umieszczenia w jednej relacji informacji o sygnaturze książki i danych czytelnika, który aktualnie ją wypożyczył. Adres składający się z kilku części nie został podzielony w związku z tym nie jest możliwe sprawdzenie ilu czytelników mieszka w Krakowie. Jeden czytelnik może wypożyczyć wiele książek, w związku z tym występuje redundancja danych. Zmiana jednej z informacji o prowadzącym (np. adresu) powoduje konieczność zmiany wszystkich krotek zawierających te dane w celu zachowania integralności. Nie jest możliwe wprowadzenie informacji o czytelniku, który aktualnie nie wypożyczył żadnej książki. Usunięcie informacji o wypożyczeniu książki może spowodować również usunięcie wszelkich informacji o osobie, która ją wypożyczyła. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 33/99 Cele normalizacji (2) wypozyczenia sygnatura idczytelnika PK(sygnatura,idczytelnika) FK n 1 czytelnicy idczytelnika PK imie nazwisko miejscowosc kod ulica nrdomu Własności zmodyfikowanej struktury: Adres jest zdekomponowany na części składowe, w związku z czym możliwe jest wyszukiwanie danych np. według miejscowości zamieszkania czytelnika. Zmiana informacji o czytelniku (np. adresu) nie powoduje konieczności zmian danych w relacji wypożyczenia. Zmiana ta odbywa się tylko w jednym miejscu. Możliwe jest wprowadzenie informacji o osobie, która nie ma aktualnie wypożyczonych książek. Usunięcie informacji o wypożyczeniu nie powoduje usunięcia informacji o osobie, która daną książkę wypożyczyła. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 34/99

18 Dekompozycja uwagi Uzyskiwanie kolejnych postaci normalnych wiąże się zazwyczaj z dekompozycją relacji (w sensie zmiennej relacyjnej czyli niezależnie od aktualnej wartości) na relacje o mniejszej liczbie atrybutów. Przykładowo relacja o schemacie {A, B, C, D} może zostać zdekomponowana na dwie relacje np. o schematach {A, B} i {B, C, D} lub {A, C, D} i {A, B, D} itd. Projektowanie relacyjnej bazy danych sprowadza się do problemu dekompozycji. Można rozpocząć od uniwersalnej relacji zawierającej wszystkie atrybuty i zdekomponować ją na relacje tak, by relacje wynikowe nie wykazywały żadnych anomalii. Procedura dekompozycji opiera się na rzeczywistych ograniczeniach danych występujących w świecie, który odzwierciedla baza danych. Ograniczenia te są wyrażane w postaci zależności funkcyjnych. Dekompozycja relacji wiąże się zawsze z dwoma problemami: Czy należy rzeczywiście dekomponować relację? i Jakie problemy (jeśli w ogóle) przyniesie dekompozycja? Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 35/99 Dekompozycja stratna przykład lp nazwisko status miasto 1 Kowalski 20 Warszawa 2 Nowak 30 Wrocław 3 Kwiatkowski 30 Wrocław 4 Wiśniewski 20 Warszawa 5 Adamski 30 Kraków lp nazwisko status 1 Kowalski 20 2 Nowak 30 3 Kwiatkowski 30 4 Wiśniewski 20 5 Adamski 30 Złączenie naturalne: lp nazwisko status miasto 1 Kowalski 20 Warszawa 2 Nowak 30 Wrocław 2 Nowak 30 Kraków 3 Kwiatkowski 30 Wrocław 3 Kwiatkowski 30 Kraków 4 Wiśniewski 20 Warszawa 5 Adamski 30 Wrocław 5 Adamski 30 Kraków status miasto 20 Warszawa 30 Wrocław 30 Kraków Podana dekompozycja jest stratna, bo ponowne złączenie relacji nie prowadzi do relacji wyjściowej. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 36/99

19 Dekompozycja bezstratna przykład lp nazwisko status miasto 1 Kowalski 20 Warszawa 2 Nowak 30 Wrocław 3 Kwiatkowski 30 Wrocław 4 Wiśniewski 20 Warszawa 5 Adamski 30 Kraków lp nazwisko miasto 1 Kowalski Warszawa 2 Nowak Wrocław 3 Kwiatkowski Wrocław 4 Wiśniewski Warszawa 5 Adamski Kraków miasto status Warszawa 20 Wrocław 30 Kraków 30 Złączenie naturalne: lp nazwisko miasto status 1 Kowalski Warszawa 20 2 Nowak Wrocław 30 3 Kwiatkowski Wrocław 30 4 Wiśniewski Warszawa 20 5 Adamski Kraków 30 Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 37/99 Zależności funkcyjne (1) Niech dany będzie zbiór atrybutów H = {A 1, A 2,..., A m } i niech X, Y H. Istnieje zależność funkcyjna (X wyznacza funkcyjnie Y) X Y wtedy i tylko wtedy, gdy dla dowolnej relacji R o schemacie H, dla dowolnych krotek t 1, t 2 R zachodzi: π X (t 1 ) = π X (t 2 ) π Y (t 1 ) = π Y (t 2 ) (1) Zależność funkcyjna między X i Y oznacza, że każdemu zestawowi wartości atrybutów X odpowiada dokładnie jeden zestaw wartości atrybutów Y. Powyższy zapis stosujemy również, gdy zamiast zbioru rozważamy pojedyncze atrybuty. Mogą istnieć np. zależności X A i, A i A j. Bardziej precyzyjny zapis to: X {A i }, {A i } {A j }. Zależność funkcyjna między zbiorami atrybutami X i Y nie jest związana z przypadkowym układem ich wartości, ale wynika z charakteru zależności między tymi atrybutami w modelowanej rzeczywistości. Zależność funkcyjna jest ograniczeniem związanym z wartościami atrybutów. Istnienia zależności funkcyjnych nie dowodzi się można je zaobserwować lub założyć. Zależności funkcyjne wynikają ze schematu relacji a nie relacji jako takiej (nie zależą od konkretnych danych). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 38/99

20 Zależności funkcyjne przykład Rozważmy relację R opisującą rozkład zajęć uczelni o schemacie {D, H, S, G, P, C} gdzie: D dzień, H godzina, S sala, G grupa studencka, P prowadzący zajęcia, C przedmiot/kurs. W powyższym schemacie istnieją zależności funkcyjne, np.: {D, H, S} {G, P, C}, {D, H, G} {S, P, C}, {D, H, P} {S, G, C}. W konkretnym systemie mogą też istnieć inne zależności, np. {D, H, C} {S, G, P}, P C. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 39/99 Zależności funkcyjne (2) Zależność funkcyjną X Y nazywamy trywialną, jeżeli Y X. Zależność funkcyjną X Y nazywamy prostą, jeżeli Y jest zbiorem jednoelementowym. Jeżeli H = {A 1, A 2,..., A m } jest schematem relacji R i X H jest kluczem, to X H. Aksjomaty Armstronga: A1 zwrotność: Y X X Y A2 rozszerzanie: X Y X Z Y Z A3 przechodniość: X Y Y Z X Z Twierdzenia wynikajace z aksjomatów: reguła sumowania: X Y X Z X Y Z reguła pseudoprzechodniości: (X Y) (Y W Z) X W Z reguła rozkładania: (X Y) (Z Y) X Z Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 40/99

21 Domknięciem zbioru zależności funkcyjnych Domknięciem zbioru zależności funkcyjnych F nazywamy zbiór wszystkich zależności funkcyjnych wynikających logicznie z zależności ze zbioru F i oznaczamy F +. Dwa zbiory F, G zależności funkcyjnych są równoważne wtedy i tylko wtedy, gdy F + = G +. Zbiór zależności funkcyjnych F pokrywa zbiór zależności funkcyjnych G wtedy i tylko wtedy, gdy G + F +. Aby sprawdzić czy zbiory F, G zależności funkcyjnych są równoważne, należy sprawdzić, czy każda zależność ze zbioru F należy do G + i czy każda zależność ze zbioru G należy do F +. Zbiory F, G są równoważne wtedy i tylko wtedy, gdy F pokrywa G i G pokrywa F. Aksjomaty Armstronga stanowią pełny zbiór reguł i pozwalają wygenerować dla zbioru zależności funkcyjnych F jego dopełnienie F +. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 41/99 Domknięciem zbioru zależności funkcyjnych przykład Niech dana będzie relacja R o schemacie H = {A, B, C} i zbiór zależności funkcyjnych F = {A B, B C}. Wybrane zależności ze zbioru F + : A B B C A C A B A C A {B, C} A C {A, B} {B, C} {A, B, C} {A, B} C C i wiele więcej Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 42/99

22 Minimalny zbiór zależności funkcyjnych Zbiór zależności funkcyjnych F jest minimalny, jeśli: (1) Prawa strona każdej zależności w F składa się z dokładnie jednego atrybutu. (2) Dla każdej zależności X A F, F + (F {X A}) +. (3) Dla każdej zależności X A F i Y X, F + (F {X A} {Y A}) + Minimalizacja zbioru zależności funkcyjnych F (1) Jeżeli istnieje zależność funkcyjna w zbiorze F, która wynika z innych zależności w F, to ją usuwamy z F. (2) Niech X A F, Y X, card(x) = card(y) + 1. Jeżeli zależność Y A F +, to w zbiorze F zastępujemy X A przez Y A. (3) Powtarzamy powyższe kroki, dopóki można wykonywać jakieś zmiany w F. {A B, B A} zbiór minimalny; {A B, B C, A C} można usunąć A C; {A B, B C, {A, D} C} można usunąć {A, D} C; {A B, B C, {A, C} B} można usunąć {A, C} B. Minimalnym pokryciem zbioru zależności F nazywamy zbiór zależności F c, który jest jednocześnie minimalny i równoważny F. (Nie jest wyznaczony jednoznaczne.) Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 43/99 Klucze Niech dany będzie zbiór atrybutów H = {A 1,..., A n } i zbiór zależności funkcyjnych F. Nadkluczem relacji R o schemacie H i zbiorze zależności funkcyjnych F nazywamy dowolny zbiór atrybutów X H taki, że X H F + (2) Kluczem relacji R o schemacie H i zbiorze zależności funkcyjnych F nazywamy dowolny minimalny nadklucz relacji R, tzn. dowolny zbiór atrybutów X H taki, że X H F + (3) Y X : Y X (Y H F + ) (4) Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 44/99

23 Domknięcie tranzytywne zbioru atrybutów Niech dana będzie relacja R o schemacie H = {A 1,..., A n } i zbiór zależności funkcyjnych F. Domknięciem tranzytywnym zbioru atrybutów X H względem zbioru zależności funkcyjnych F nazywamy zbiór X + = {A H : X A F + } (5) Algorytm generacji domknięcia tranzytywnego (1) X 0 = X. (2) X i+1 = X i {A H : Y Z F taka że Y X i A Z}. (3) Jeżeli X i+1 = X i to stop; X + = X i. Twierdzenia Niech X, Y H. X Y F + Y X + X jest nadkluczem relacji o schemacie R wtedy i tylko wtedy, gdy X + = H. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 45/99 Domknięcie tranzytywne zbioru atrybutów przykład Dane: H = {A, B, C, D, E}, F = {A B, B C, {C, D} E} Pytanie 1: A E? Pytanie 2: Czy {A, D} jest kluczem relacji R o schemacie H? Wyznaczamy A + : 1) A 0 = {A}, 2) A B A 1 = {A, B}, 3) B C A 2 = {A, B, C}, 4) A + = {A, B, C}. E / A + zatem A E Niech X = {A, D}. Wyznaczamy X + : 1) X 0 = {A, D}, 2) A B X 1 = {A, B, D}, 3) B C X 2 = {A, B, C, D}, 4) {C, D} E X 3 = {A, B, C, D, E}, 5) X + = {A, B, C, D, E}. X + = H zatem {A, D} jest nadkluczem. Ponieważ A + = {A, B, C} = H i D + = {D} = H, to {A, D} jest kluczem. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 46/99

24 Dekompozycja (rozkład) relacji Niech dany będzie zbiór atrybutów H = {A 1,..., A n } i niech X, Y H. Dekompozycją (rozkładem) relacji R o schemacie H na dwie relacje R 1 i R 2 o schematach odpowiednio X i Y nazywamy zastąpienie relacji R relacjami R 1 oraz R 2 takimi, że R 1 = π X (R) R 2 = π Y (R) X Y = H (6) Potencjalne problemy z dekompozycja: Wykonywanie niektórych zapytań może być bardziej kosztowne. Może powstać sytuacja w której nie jest możliwe odzyskanie oryginalnej relacji na podstawie relacji zdekomponowanych. Sprawdzanie niektórych zależności może wymagać łączenia zdekomponowanych relacji. Należy szukać kompromisu między podanymi problemami, a nadmiarowością w bazie danych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 47/99 Dekompozycja bezstratna Dekompozycja relacji R (zmiennej relacyjnej R) o schemacie H na dwie relacje R 1 i R 2 o schematach odpowiednio X i Y jest bezstratna (zachowuje informacje) wtw, gdy dla każdej relacji R (w sensie wartości) spełniającej zależności ze zbioru F zachodzi R = π X (R) π Y (R) (7) UWAGA: Definicje te można rozszerzyć na dekompozycję na wiele relacji. Tw. Dekompozycja relacji R na relacje R 1 i R 2 jest bezstratna, jeżeli co najmniej jedna z podanych zależności funkcyjnych należy do F +. H 1 H 2 H 1 (8) H 1 H 2 H 2 (9) Oznacza to, że część wspólna H 1 H 2 jest nadkluczem H 1 lub H 2. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 48/99

25 Dekompozycja bezstratna przykład z dwoma relacjami Przykład 1 H = {A, B, C}, H 1 = {A, B}, H 2 = {A, C}, F = {A B}. H 1 H 2 = {A}. Sprawdzamy więc czy A {A, B} F + lub A {A, C} F +. Ponieważ A B F, A A F + więc A {A, B} F +, a zatem dekompozycja jest bezstratna. Przykład 2 H = {A, B, C}, H 1 = {A, B}, H 2 = {B, C}, F = {A B}. H 1 H 2 = {B}. Sprawdzamy więc czy B {A, B} F + lub B {B, C} F +. B + = {B}, więc żadna z rozważanych zależności nie należy do F +, zatem dekompozycja jest stratna. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 49/99 Ogólny algorytm sprawdzania bezstratności dekompozycji Niech dany będzie zbiór atrybutów H = {A 1,..., A n } i niech F będzie zbiorem zależności funkcyjnych. Rozważamy dekompozycję relacji R o schemacie H na k relacji R i o schematach H i. Konstruujemy macierz S zawierającą k wierszy o etykietach R i i n kolumn o etykietach A j. (1) Dla każdego atrybutu A j H i każdej relacji R i, jeżeli A j H i, to umieszczamy znak w komórce S(i, j). (2) Dla każdej zależności funkcyjnej X Y F (X, Y H), dla każdych dwóch wierszy macierzy S, które mają znaki dla wszystkich kolumn ze zbioru X, jeżeli którykolwiek z wierszy ma znak w jakiejś kolumnie ze zbioru Y, to wstawiamy znak również w drugim z rozważanych wierszy dla tej kolumny. Jeżeli istnieje wiersz macierzy S zawierający znaki we wszystkich swoich komórkach, to dekompozycja jest bezstratna, w przeciwnym przypadku dekompozycja jest stratna. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 50/99

26 Ogólny algorytm sprawdzania bezstratności dekompozycji przykład H = {A, B, C, D, E, F} H 1 = {A, B} H 2 = {C, D, E} H 3 = {A, C, F} F = {{A} {B}, {C} {D, E}, {A, C} {F}} krok (1) krok (2) A B C D E F H 1 H 2 H 3 Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 51/99 Rzut zbioru zależności funkcyjnych na zbiór atrybutów Niech dany będzie zbiór atrybutów H = {A 1,..., A n } i niech F będzie zbiorem zależności funkcyjnych. Rzutem F na zbiór atrybutów Z (π Z (F)) nazywamy zminimalizowany zbiór zależności funkcyjnych {X Y F + : X Y Z}. Wyznaczanie rzutu zbioru zależności funkcyjnych F na zbiór atrybutów Z H (1) Przyjmujemy początkowo, że π Z (F) =. (2) Dla każdego zbioru X 2 Z wyznaczamy X + (ze względu na F). Dodajemy do π Z (F) wszystkie nietrywialne zależności X A F +, takie że A X + Z. (3) Minimalizujemy zbiór π Z (F). Przykład: H = {A, B, C, D}, F = {A B, B C, C D}, Z = {A, C, D} A + = H, stąd dodajemy do π Z (F) zależności A C i A D, nie ma sensu analizowanie nadzbiorów {A}; C + = {C, D}, stąd dodajemy do π Z (F) zależność C D; D + = {D}; {C, D} + = {C, D}. Po minimalizacji π Z (F) = {A C, C D} Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 52/99

27 Dekompozycja zachowująca zależności funkcyjne Dekompozycja relacji R (zmiennej relacyjnej R) o schemacie H na dwie relacje R 1 i R 2 o schematach odpowiednio X i Y zachowuje zależności funkcyjne wtw, gdy F + = (π X (F) π Y (F)) + (10) Analogicznie definiuje się tę własność dla rozkładu na wiele relacji. W praktyce oznacza to, że jeżeli dekompozycja zachowuje zależności funkcyjne, to w przypadku aktualizacji danych w bazie wystarczy sprawdzić indywidualne relacje czy zachowują swoje zbiory zależności funkcyjnych F i = π Hi (F) bez potrzeby rozważania złożenia tych relacji jako całości (zależności dla całości też będą zachowane). UWAGA: Jeżeli dekompozycja zachowuje zależności funkcyjne, to nie oznacza to, że zachowuje również informację i na odwrót. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 53/99 Zachowanie zależności funkcyjnych przykład H = {A, B, C, D}, F = {A B, {B, C} D, A D, D A}. {A} + = {A, B, D} {B} + = {B} {C} + = {C} {D} + = {A, B, D} {A, B} + = {A, B, D} {A, C} + = H {A, D} + = {A, B, D} {B, C} + = H {B, D} + = {A, B, D} {C, D} + = H Zatem nietrywialne zależności w F +, to A B, A D, A {A, B}, A {A, D}, A {B, D}, A {A, B, D}, D A, D B itd. Rozważmy dekompozycję na schematy H 1 = {A, B}, H 2 = {A, C, D}. π H1 (F) = {A B} π H2 (F) = {A D, D A} Każdą z zależności ze zbioru π H1 (F) π H2 (F) można wyprowadzić z F. Sprawdzamy, czy każdą z zależności z F da się wyprowadzić z π H1 (F) π H2 (F). Do sprawdzenia zostaje tylko zależność {B, C} D. Ponieważ {B, C} + = {B, C} (przy obliczeniach bierzemy pod uwagę zależności funkcyjne z π H1 (F) π H2 (F)), to nie da się wyprowadzić {B, C} D z π H1 (F) π H2 (F). Dekompozycja nie zachowuje zależności funkcyjnych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 54/99

28 Pierwsza postać normalna 1NF Relacja jest w pierwszej postaci normalnej (1NF) wtedy i tylko wtedy gdy wszystkie atrybuty przyjmują wartości elementarne (atomiczne). Relacja w pierwszej postaci normalnej, to regularna tablica prostokątna, w której na przecięciu każdego wiersza i kolumny znajduje się wartość atomiczna. Pierwsza postać normalna jest konieczna, aby tabelę można było nazwać relacją. Większość systemów baz danych nie ma możliwości zbudowania tabel nie będących w pierwszej postaci normalnej. Ważne pytania: Co to jest wartość atomiczna? Czy jest nią: data, napis, lista liczb itd.? Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 55/99 BCNF Niech dana będzie relacja R o schemacie H = {A 1,..., A n } i zbiór zależności funkcyjnych F. Relacja R jest w postaci normalnej Boyce a Codda (BCNF) wtw, gdy dla każdej nietrywialnej, prostej zależności funkcyjnej X A F + X jest nadkluczem (X H, A H). The Key, the whole Key, and nothing but the Key. Jeżeli schemat relacji znajduje się w postaci normalnej Boyce a Codda, to nie ma w nim redundancji. BCNF oznacza, że lewa strona każdej nietrywialnej zależności funkcyjnej zawiera klucz. Dowolna dwuatrybutowa relacja jest w BCNF. Dowolną relację R o schemacie H można sprowadzić do BCNF stosując dekompozycję bezstratną, ale niekoniecznie zachowującą zależności funkcyjne. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 56/99

29 3NF Relacja R jest w trzeciej postaci normalnej (3NF) wtw, gdy dla każdej nietrywialnej, prostej zależności funkcyjnej X A F + X jest nadkluczem lub A należy do pewnego klucza relacji R (X H, A H). 3NF oznacza, że każdy atrybut niekluczowy (informacyjny) zależy wyłącznie od klucza. Innymi słowy, atrybuty informacyjne są wzajemnie niezależne. BCNF jest nieco bardziej restrykcyjną wersją 3NF. W BCNF wszystkie atrybuty (również kluczowe) muszą spełniać ten warunek. Ten dodatkowy wymóg ma znaczenie, gdy relacja zawiera wiele kluczy. Jeżeli relacja jest w BCNF, to jest również w 3NF. Jeżeli relacja jest w 3NF, to możliwe jest występowanie pewnych redundancji. Postać normalna 3NF jest kompromisem używanym wtedy, gdy nie można uzyskać BCNF. W praktyce próbujemy uzyskać BCNF, ale ważniejsze jest zachowanie zależności, więc, jeśli przejście do BCNF nie zachowuje zależności, wybieramy 3NF. Dowolną relację R o schemacie H można sprowadzić do 3NF stosując dekompozycję bezstratną i zachowującą zależności funkcyjne. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 57/99 BCNF i 3NF przykład (1) H = {M, U, K} (miasto, ulica, kod) F = {{M, U} K, K M} Relacja o schemacie H ma dwa klucze {M, U} i {K, U}, bo: M + = {M} U + = {U} K + = {K, M} {K, U} + = H {M, U} + = H {K, M} + = {K, M} Ze względu na zależność K M schemat nie jest w BCNF (bo {K} nie jest nadkluczem). Ponadto, tego schematu nie można rozłożyć z zachowaniem zależności funkcyjnych. Schemat jest w 3NF. W tym przypadku zależność K M nie przeszkadza, bo M wchodzi w skład jednego z kluczy. (Oczywiście sprawdzamy wszystkie zależności postaci X A F +.) Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 58/99

30 BCNF i 3NF przykład (2) H = {A, B, C, D} F = {{A, B} C, B D, {B, C} A} Relacja o schemacie H ma dwa klucze {A, B} i {B, C}, bo: A + = {A} B + = {B, D} C + = {C} D + = {D} {A, B} + = H {A, C} + = {A, C} {A, D} + = {A, D} {B, C} + = H {B, D} + = {B, D} {C, D} + = {C, D} {A, C, D} + = {A, C, D} D nie jest atrybutem kluczowym, zatem ze względu na zależność funkcyjną B D relacja o schemacie H nie jest w 3NF. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 59/99 2NF Niech X H, A H i niech A będzie atrybutem niekluczowym. Trzecią postać normalną naruszają dwa rodzaje zależności: Zależność częściowa zależność X A, gdy X jest właściwym podzbiorem pewnego klucza. Zależność przechodnia zależność X A, gdy X nie jest ani podzbiorem, ani nadzbiorem żadnego klucza (K X A). Niech dana będzie relacja R o schemacie H = {A 1,..., A n } i zbiór zależności funkcyjnych F. Relacja R jest w drugiej postaci normalnej (2NF) wtw, gdy zbiór F + nie zawiera zależności częściowych. Spełnienie wymogów 2NF oznacza w praktyce, że każda relacja przechowuje dane dotyczące tylko jednej klasy obiektów. Wszystkie atrybuty niekluczowe (informacyjne) muszą zawierać informacje o elementach tej jednej klasy obiektów. Jeżeli tak nie jest, to atrybuty takie powinny być przeniesione do właściwych relacji. Relacja R jest trzeciej postaci normalnej, jeśli jest w drugiej postaci normalnej i nie zawiera zależności przechodnich. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 60/99

31 2NF przykład (1) H = {D, A, T, C} (dostawca, adres, towar, cena) F = {D A, {D, T} C} Relacja o schemacie H ma jeden klucz {D, T}, bo: D + = {D, A} A + = {A} T + = {T} C + = {C} {D, A} + = {D, A} {D, T} + = H {D, C} + = {D, A, C} {A, T} + = {A, T} {A, C} + = {A, C} {T, C} + = {T, C} {D, A, C} + = {D, A, C} {A, T, C} + = {A, T, C} Zbiór {D} jest podzbiorem właściwym klucza, więc D A jest zależnością częściową. Relacja o schemacie H nie jest w 2NF. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 61/99 2NF przykład (2) H = {S, T, D, K} (sklep, towar, dział, kierownik) F = {{T, S} D, {S, D} K} Relacja o schemacie H ma jeden klucz {T, S}, bo: S + = {S}, T + = {T}, D + = {D}, K + = {K} {S, T} + = H {S, D} + = {S, D, K} {S, K} + = {S, K} {T, D} + = {T, D} {T, K} + = {T, K} {D, K} + = {D, K} {S, D, K} + = {S, D, K} {T, D, K} + = {T, D, K} Możliwe zależności częściowe, które psułyby 2NF to: S A lub T A, gdzie A H. Nie ma takich zależności funkcyjnych w F +, więc relacja o schemacie H jest w 2NF. Zależność {S, D} K jest zależnością przejściową, bo zbiór {S, D} nie jest ani podzbiorem, ani nadzbiorem klucza. Relacja o schemacie H nie jest w 3NF. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 62/99

32 Algorytm przejścia do BCNF Jeśli relacja R o schemacie H = {A 1,..., A n } nie jest w postaci normalnej Boyce a-codda, to istnieje zależność funkcyjna postaci X A F +, gdzie X nie jest nadkluczem i A / X. Rozkładamy schemat H na H 1 = X {A} oraz H 2 = H {A}. H = {M, U, K} (miasto, ulica, kod) F = {{M, U} K, K M} Rozkładamy schemat H względem zależności funkcyjnej K M (czyli X = K i A = M). Stąd: H 1 = {M, K}, F 1 = {K M} H 2 = {K, U}, F 2 = (bo jedyne nietrywialne zależności funkcyjne w zbiorze F +, to te ze zbioru F) Relacji o schemacie H nie można rozłożyć z zachowaniem zależności funkcyjnych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 63/99 Przejście do BCNF przykład H = {W, M, E, Z, T} (wykładowca, moduł, ECTS, zdawalność, termin) F = {W Z, M E, {W, M} T} Atrybuty W i M nie występują w żadnej regule po prawej stronie, więc muszą należeć do klucza. Jednocześnie {W, M} + = H, więc para {W, M} jest jedynym kluczem. Bezpośrednio w F mamy dwie reguły niespełniające warunku BCNF. W Z: H 1 = {W, Z} H 2 = {W, M, E, T} F 1 = π H1 (F) = {W Z}, bo W + = {W, Z}, Z + = {Z} F 2 = π H2 (F) = F c ({M E, {W, M} T, {M, T} E, {M, Z} E,... }) = {M E, {W, M} T} Relacja R 1 (schemat H 1 ) jest w BCNF. Kluczem relacji R 2 jest zbiór {W, M}. Relacja nie jest w BCNF. M E: H 21 = {M, E} H 22 = {W, M, T} F 21 = π H21 (F 2 ) = {M E} F 22 = π H22 (F 2 ) = {{W, M} T} Wszystkie relacje (R 1, R 21, R 22 ) są w BCNF. Wszystkie zależności są zachowane. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 64/99

33 Algorytm przejścia do 3NF (1) Dla każdej zależności funkcyjnej w minimalnym pokryciu z jej atrybutów tworzymy schemat relacji. Jeżeli jeden schemat jest podzbiorem drugiego, to bierzemy pod uwagę tylko większy. (2) Łączymy ze sobą małe schematy mające ten sam klucz. (3) W jednym ze schematów relacji powinien wystąpić klucz. Jeśli nie występuje, dodajemy dodatkowy schemat złożony z atrybutów klucza. (4) Atrybuty nie występujące w zależnościach z F wchodzą w skład klucza. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 65/99 Przejście do 3NF przykłady Przykład 1 H = {M, U, K} (miasto, ulica, kod) F = {{M, U} K, K M} Minimalnym pokryciem dla F jest F. Stąd otrzymujemy jeden schemat {M, U, K}. Przykład 2 H = {A, B, C, D} F = {A B, C D} Jedynym kluczem jest {A, C}. Stąd baza danych powinna zawierać relacje o schematach {A, B}, {C, D} i {A, C}. Przykład 3 H = {A, B, C} F = {A B} Jedynym kluczem jest {A, C}. Stąd baza danych powinna zawierać relacje o schematach {A, B} i {A, C}. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 66/99

34 Zależności wielowartościowe (1) Aktor Ulica Miasto Tytuł Rok Carrie Fisher 123 Maple St. Hollywood Gwiezdne wojny 1977 Carrie Fisher 5 locust Ln. Malibu Gwiezdne wojny 1977 Carrie Fisher 123 Maple St. Hollywood Imperium kontratakuje 1980 Carrie Fisher 5 locust Ln. Malibu Imperium kontratakuje 1980 Carrie Fisher 123 Maple St. Hollywood Powrót Jedi 1983 Carrie Fisher 5 locust Ln. Malibu Powrót Jedi 1983 Jeżeli założymy, że jedna gwiazda filmowa może mieć kilka adresów i ulice w różnych miastach mogą się powtarzać, to w powyższej relacji nie ma żadnych nietrywialnych zależności funkcyjnych (F = ). Jedynym kluczem jest H. Zatem ta relacja jest w BCNF, ale są redundancje! Przyczyną występowania takich sytuacji (zależności wielowartościowych) w relacji R może być występowanie w niej dwóch niezależnych związków typu jeden do wielu. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 67/99 Zależności wielowartościowe (2) Niech H będzie schematem relacji, niech X, Y H i niech Z = H (X Y). Dla relacji R o schemacie H zachodzi zależność wielowartościowa X Y (X wyznacza wieloznacznie Y), gdy dla każdych dwóch krotek t, s R, takich że π X (t) = π X (s), istnieje krotka u R taka, że: π X (u) = π X (t) = π X (s) π Y (u) = π Y (t) π Z (u) = π Z (s) (11) X Y Z π X (t) π Y (t) π Z (t) π X (u) π Y (u) π Z (u) Zależność wielowartościowa X Y gwarantuje istnienie krotki u. Jeżeli X Y, to również X Z. π X (s) π Y (s) π Z (s) Nie jest to zależność funkcyjna, bo jednemu zestawowi wartości atrybutów z X odpowiada wiele zestawów wartości atrybutów z Y. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 68/99

35 4NF Niech H będzie schematem relacji, niech X, Y H i niech Z = H (X Y). Zależności między atrybutami można interpretować jako reguły: X Y: jeśli (x, y, z) R i (x, y, z ) R, to y = y (x to podkrotka związana z atrybutami z X itd.) X Y: jeśli (x, y, z) R i (x, y, z ) R, to również (x, y, z ) R i (x, y, z) R. Jeśli zachodzi X Y, to także X Y. Niech dana będzie relacja R o schemacie H = {A 1,..., A n } i zbiór zależności funkcyjnych F. Relacja R jest w czwartej postaci normalnej (4NF) wtw, gdy dla każdej zależności wielowartościowej X Y, jeśli X Y = oraz X Y H, to X zawiera klucz. Jeśli F nie zawiera zależności wielowartościowych, to 4NF pokrywa się z BCNF. Algorytm Dla każdej zależności wielowartościowej X Y, jeśli X Y =, X Y H oraz X nie jest nadkluczem, dokonujemy rozkładu H na X Y i H Y. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 69/99 Przejście do 4NF przykład H = {A, U, M, T, R} (aktor, ulica, miasto, tytuł, rok) F =, klucz: H zależności wielowartościowe: A {U, M}, A {T, R} A {U, M}: H 1 = {A, U, M} H 2 = {A, T, R} Aktor Ulica Miasto Carrie Fisher 123 Maple St. Hollywood Carrie Fisher 5 locust Ln. Malibu Aktor Tytuł Rok Carrie Fisher Gwiezdne wojny 1977 Carrie Fisher Imperium kontratakuje 1980 Carrie Fisher Powrót Jedi 1983 Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 70/99

36 PostgreSQL typy numeryczne Typy całkowite: smallint, integer, bigint. Typy te różnią się liczbą bajtów wykorzystywanych do zapisywania wartości (odpowiednio 2, 4 i 8), a przez to zakresem dopuszczalnych wartości. Próba przypisania wartości spoza zakresu powoduje błąd. Najczęściej wykorzystywany jest typ integer. Typ stałoprzecinkowy: numeric(precision, scale); precision określa łączną liczbę cyfr znaczących w liczbie, zaś scale liczbę cyfr po przecinku. Typ ten jest rekomendowany do przechowywania wartości walutowych. Typ ten jest zdecydowanie wolniejszy w obliczeniach w porównaniu do typów zmiennoprzecinkowych. Typ zmiennoprzecinkowy: real, double precision. Typ real ma zakres co najmniej od 1E-37 do 1E+37 z dokładnością do 6 miejsc po przecinku. Wykorzystanie typów zmiennoprzecinkowych niesie ze sobą wszystkie problemy z tym związane. Wartości specjalne: Infinity, -Infinity, NaN PostgreSQL pozwala stosować typ float(p), gdzie p (zakres 1 53) oznacza minimalną precyzję (w zapisie binarnym). Serial: Jest to typ całkowity wykorzystywany do automatycznego generowania wartości. Dostępna jest również wersja bigserial. Money: Typ do przechowywania walut (problemy z konwersją, patrz dokumentacja, np.: select 1234::text::money;). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 71/99 Typy tekstowe i typ logiczny Typ znakowy: char. Przechowuje dokładnie 1 znak i zajmuje 1 bajt pamięci. Typy tekstowe o ograniczonej długości: char(n), varchar(n). Oba typy przechowują tekst o maksymalnej długości n znaków. W przypadku typu char(n) długość przechowywanego tekstu jest stała, tzn. teksty krótsze są uzupełniane spacjami. W obu przypadkach, próba wstawienia wartości dłuższej niż n powoduje błąd. Typ tekstowy o nieograniczonej długości: text. Typ ten pozwala przechowywać teksty o długości do 1 GB. Nie jest on częścią standardu języka SQL. Typ logiczny: boolean. Typ ten zawiera trzy wartości: null, true, false. Jako wartość prawda traktowane są następujące napisy: true, t, true, y, yes, 1, przy czym jako kompatybilna ze standardem języka SQL preferowana jest wartość true. Analogicznie, jako wartość fałsz traktowane są napisy: false, f, false, n, no, 0. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 72/99

37 Typy do przechowywania daty i czasu Data: date. Typ przechowuje datę z dokładnością do 1 dnia. Zakres od 4713 p.n.e do n.e. Czas: time[(p)]. Typ przechowuje wyłącznie czas. Opcjonalnie można zadać dokładność (od 0 do 6) przechowywania ułamkowych części sekundy. Jeżeli chcemy przechowywać czas łącznie z informacją o strefie czasowej należy skorzystać z typu time[(p)] with time zone. Data i czas: timestamp[(p)]. Jeżeli chcemy przechowywać czas i datę łącznie z informacją o strefie czasowej należy skorzystać z typu timestamp[(p)] with time zone. Przedział czasowy: interval[(p)]. Przy wprowadzaniu wartości związanych z datą lub czasem może zajść konieczność posługiwania się operatorem rzutowania, np.: string ::date string ::timestamp Wartości specjalne: now, today, tomorrow, yesterday (trzy ostatnie jako czas przyjmują północ). Funkcje SQLa: current_date, current_time, current_timestamp, localtime, localtimestamp. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 73/99 Czas i daty W PostgreSQL można wybrać jeden z czterech stylów wyświetlania daty i czasu: ISO (domyślnie) :37:16-08 SQL 12/17/ :37:16.00 CET POSTGRES Wed Dec 17 07:37: CET German :37:16.00 CET Przy wyborze stylu SQL lub POSTGRES można określić kolejność wyświetlania dnia i miesiąca (domyślnie miesiąc wyświetlany jest przed dniem). Sposób wyświetlania daty ustawiany jest za pomocą polecenia set datestyle: set datestyle to SQL, DMY ; Ustawienie parametru określającego kolejność występowania poszczególnych fragmentów daty, wpływa również na sposób interpretacji wprowadzanych danych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 74/99

38 Typy wyliczeniowe create type pora_roku as enum ( wiosna, lato, jesien, zima ); create table sezony ( rok integer, pora pora_roku, primary key(rok, pora)); insert into sezony values(2012, wiosna ); insert into sezony values(2012, lato ); insert into sezony values(2012, jesion ); -- BŁĄD: nieprawidłowa wartość wejścia dla -- enumeracji pora_roku: "jesion" Typy wyliczeniowe mogą być stosowane podobnie jak inne predefiniowane typy danych. Wartości w typie wyliczeniowym są uporządkowane zgodnie z kolejnością ich umieszczenia w definicji typu. Wartości z dwóch typów wyliczeniowych można porównywać tylko po zastosowaniu jawnej konwersji (np. na typ tekstowy). Przy definiowaniu wartości w typie wyliczeniowym ma znaczenie wielkość liter. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 75/99 Domeny Domeny umożliwiają definiowanie dziedzin (typów danych) dla tabel. Dziedziny takie zawsze oparte są na wbudowanym typie danych, ale mogą zawierać dodatkowe ograniczenia, które zawężają zbiór dopuszczalnych wartości. create domain pora_roku as varchar(6) check(value in ( wiosna, lato, jesień, zima )); create table c ( rok integer, pora pora_roku ); insert into c values(2010, wiosna ); -- INSERT 0 1 insert into c values(2010, wioska ); -- ERROR: value for domain pora_roku violates -- check constraint "pora_roku_check" create domain kod_pocztowy as varchar(6) default check(value ~ ^[0-9]{2}\-[0-9]{3}$ ); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 76/99

39 Typy złożone create type complex as ( re real, im real ); create table zespolone ( nazwa varchar(10) primary key, liczba complex ); insert into zespolone values( i,(0,1)); insert into zespolone values( 1,(1,0)); insert into zespolone values( 0,(0,0)); select nazwa, (liczba).re from zespolone; select * from zespolone where (liczba).re = 0; Typy złożone definiowane są podobnie jak tabele, ale nie można używać żadnych ograniczeń. Dla każdej tabeli tworzony jest automatycznie odpowiadający jej typ złożony (ograniczenia użyte przy definicji tabeli nie są brane pod uwagę). Przy odwoływaniu się do pola typu złożonego, nazwa typu jest umieszczana w nawiasie, jeżeli prowadziłoby to do dwuznaczności z interpretacji (w powyższych zapytania brak nawiasów sugerowałby, że liczba jest nazwą tabeli). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 77/99 Tabele słownikowe Alternatywą dla typu wyliczeniowego może być tabela słownikowa. W najprostszym przypadku tabela zawiera tylko jedną kolumnę i po jednym rekordzie dla każdej dopuszczalnej wartości. Najczęściej tabela taka zawiera dodatkowe kolumny, np. wymuszające właściwe sortowanie danych. create table pora_roku ( nazwa varchar(6) primary key ); create table pora_roku ( id integer primary key, nazwa varchar(6) ); insert into pora_roku values (1, wiosna ),... Tabele słownikowe pozwalają między innymi na łatwe uzyskiwanie zbioru dopuszczalnych wartości, łatwe aktualizowanie ich zawartości, ułatwiają przenośność między różnymi systemami baz danych. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 78/99

40 Tworzenie tabel create [temporary] table nazwa\_tabeli ({nazwa_kolumny typ [ograniczenia_dla_kolumny] [,...] } [constraint ograniczenia_dla_tabeli]) [inherits (nazwa_istniejącej_tabeli)] Opcjonalne ograniczenia dla kolumny pozwalają określić dla niej dodatkowe reguły poprawności. Ograniczenia dla tabeli umożliwiają zapisanie dodatkowych reguł, które muszą spełniać wszystkie dane w tabeli. Klauzula inherits umożliwia dziedziczenie kolumn z już istniejących tabel. Tworzona tabela zawiera wszystkie kolumny, które znajdują się w tabelach wymienionych po słowie kluczowym inherits, jako uzupełnienie tych kolumn, które wymieniono bezpośrednio. Jeżeli przy tworzeniu tabeli zamiast create table użyjemy create temporary table, to powstanie tabela tymczasowa, która z końcem sesji i zakończeniem połączenia z bazą danych zostanie automatycznie usunięta. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 79/99 Ograniczenia dla kolumn not null w kolumnie nie mogą być zapisywane wartości null; unique wartości zapisywane w kolumnie muszą być różne dla każdego wiersza w tabeli; primary key klucz podstawowy (w zasadzie jest to połączenie zawężeń not null oraz unique). Tworząc złożony klucz podstawowy, należy wykorzystać ograniczenia na poziomie tabeli; default wartość zdefiniowanie wartości domyślnej; check (warunek) warunek sprawdzany w czasie wprowadzania lub aktualizacji danych; references ograniczenia kluczy obcych. create table kompozycje ( idkompozycji varchar(4) primary key, nazwa varchar(20) unique not null, opis varchar(80), cena numeric(7,2) check(cena >= 40.00), stan integer default 2 ); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 80/99

41 Ograniczenia dla kolumn uwagi Przy klauzuli default można podać nie tylko nazwę, ale również wyrażenie, np. wywołanie funkcji: idzamowienia integer default nextval( zamowienia_seq ), Ograniczenie może mieć przypisaną nazwę. Podejście takie pozwala na łatwą modyfikację ograniczenia lub jego usunięcie z bazy danych. cena numeric(7,2) constraint cena_minimalna check(cena >= 40.00), Ograniczenie unique może mieć przypisaną nazwę: nazwa varchar(20) constraint unikatowe_nazwy unique, nazwa varchar(20) constraint unikatowe_nazwy unique not null, W tym drugim przypadku not null nie jest częścią ograniczenia. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 81/99 Baza danych Cukiernia czekoladki idczekoladki: char(3) PK 1 nazwa: varchar(30) czekolada: varchar(15) orzechy: varchar(15) nadzienie: varchar(15) opis: varchar(100) koszt: numeric(7,2) masa: integer zamowienia idzamowienia: integer PK idklienta: integer FK datarealizacji: date 1 n zawartosc idpudelka: char(4) FK n n idczekoladki: char(3) FK sztuk: integer PK(idpudelka, idczekoladki) artykuly n idzamowienia: integer FK idpudelka: char(4) FK n sztuk: integer PK(idzamowienia, idpudelka) 1 pudelka idpudelka: char(4) PK nazwa: varchar(40) opis: varchar(150) cena: numeric(7,2) stan: integer klienci 1 idklienta: integer PK nazwa: varchar(130) ulica: varchar(30) miejscowosc: varchar(15) kod: char(6) telefon: varchar(20) Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 82/99

42 Tworzenie tabel przykłady create table druzyny ( iddruzyny varchar(5) primary key, nazwa varchar(40) not null, miasto varchar(30) not null ); create table czekoladki ( idczekoladki char(3) primary key, nazwa varchar(30) not null, czekolada varchar(15), orzechy varchar(15), nadzienie varchar(15), opis varchar(100) not null, koszt numeric(7,2) not null, masa integer not null ); create table pudelka ( idpudelka char(4) primary key, nazwa varchar(40) not null, opis varchar(150), cena numeric(7,2) not null, stan integer not null ); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 83/99 Ograniczenia dla tabeli unique (lista kolumn) wartość musi być unikalna dla każdego wiersza; primary key (lista kolumn) klucz główny; check (warunek) warunek sprawdzany podczas wprowadzania lub aktualizacji danych. references ograniczenia kluczy obcych. create table pracownicy ( iddzialu char(4), numer integer, pensja numeric(7,2), premia numeric(7,2), primary key (iddzialu, numer), constraint premia_pensja check (premia <= pensja) ); Nadawanie nazwy dla ograniczenia (w tym przypadku premia_pensja) jest opcjonalne, ale ułatwia ewentualną modyfikację ograniczenia. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 84/99

43 Klucze obce definiowane na poziomie kolumny Odwołania klucz obcy klucz można definiować na poziomie kolumny tylko wtedy, gdy powiązane klucze są kluczami prostymi. W najkrótszej wersji stosowane jest domyślne powiązanie z kluczem głównym. create table zawartosc ( idpudelka char(4) not null references pudelka, idczekoladki char(3) not null references czekoladki, sztuk integer not null, primary key (idpudelka, idczekoladki) ); create table zamowienia ( idzamowienia integer primary key, idklienta integer not null references klienci, datarealizacji date not null ); create table artykuly ( idzamowienia integer not null references zamowienia, idpudelka char(4) not null references pudelka, sztuk integer not null, primary key (idzamowienia, idpudelka) ); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 85/99 Klucze obce definiowane na poziomie tabeli Odwołania klucz obcy klucz definiowane na poziomie tabeli pozwalają łączyć ze sobą klucze złożone. create table punktujace ( numer smallint not null, iddruzyny varchar(5) not null references druzyny, idmeczu smallint not null references mecze, punkty smallint not null, primary key (numer, iddruzyny, idmeczu), foreign key (numer, iddruzyny) references siatkarki ); Zarówno klucz główny, jak i obcy mogą mieć nazwy nadane przez programistę (w miejsce nazw generowanych przez system zarządzania bazą danych): constraint klucz_glowny primary key (numer, iddruzyny, idmeczu), constraint klucz_obcy foreign key (numer, iddruzyny) references siatkarki Dodanie przy definiowaniu klucza obcego słowa deferrable powoduje opóźnienie sprawdzania zgodności do zakończenia wykonywania transakcji. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 86/99

44 Klucze obce zgodność referencyjna W przypadku zdefiniowania zależności między dwoma kluczami, usunięcie lub modyfikacja wartości (klucza) w tabeli nadrzędnej ma wpływ na tabelę podrzędną. Definiując powiązanie można określić, jak system zarządzania bazą danych ma się w takiej sytuacji zachować. Odpowiednie reguły ograniczeń dla kluczy obcych dodaje się na końcu definicji ograniczenia: references tabela [(kolumna)] [on delete akcja] [on update akcja] Akcje: restrict zapobiega usunięciu/modyfikacji rekordu z tabeli nadrzędnej, jeżeli istnieje odwołanie do tego rekordu; no action (akcja domyślna) zgłoszenie błędu, przy próbie usunięcia/modyfikacji rekordu z tabeli nadrzędnej, jeżeli istnieje odwołanie do tego rekordu; w przeciwieństwie do poprzedniej akcji sprawdzanie może być odroczone do końca transakcji; cascade kaskadowe usuwanie/modyfikacja rekordów w tabeli podrzędnej; set null ustawia wartość klucza obcego na null; set default ustawia wartość klucza obcego na wartość domyślną. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 87/99 Manipulowanie tabelami (1) Dodawanie kolumn kolumny dodane do tabeli z danymi będą zawierały null lub wartości domyślne dla istniejących wierszy. alter table nazwa_tabeli add column nazwa_kolumny typ_kolumny; alter table nazwa_tabeli add column nazwa_kolumny typ_kolumny check (...); Poza nazwą i typem kolumny można dodawać wszystkie elementy (ograniczenia) stosowane w instrukcji create table. Usuwanie kolumny przy usuwaniu kolumny można wymusić usunięcie kaskadowe innych kolumn powiązanych z daną. alter table nazwa_tabeli drop column nazwa_kolumny [cascade]; Zmiana nazwy kolumny: alter table nazwa_tabeli rename column stara_nazwa_kolumny to nowa_nazwa_kolumny; Zmiana nazwy tabeli: alter table stara_nazwa_tabeli rename to nowa_nazwa_tabeli; Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 88/99

45 Manipulowanie tabelami (2) Dodawanie ograniczenia dodawane ograniczenie jest natychmiast sprawdzane, więc znajdujące się w tabeli dane muszą je spełniać. alter table nazwa_tabeli add check (warunek); alter table nazwa_tabeli add constraint nazwa ograniczenia unique (nazwy_kolumn); alter table nazwa_tabeli alter column nazwa_kolumny set not null; alter table nazwa_tabeli add foreign key (nazwy_kolumn) references nazwa_tabeli_2; Usunięcie ograniczenia: alter table nazwa_tabeli drop constraint nazwa_ograniczenia [cascade]; alter table nazwa_tabeli alter column nazwa_kolumny drop not null; Zmiana wartości domyślnej: alter table nazwa_tabeli alter column nazwa_kolumny set default wartość alter table nazwa_tabeli alter column nazwa_kolumny drop default; Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 89/99 Manipulowanie tabelami (3) Zmiana typu kolumny operacja ta powiedzie się tylko wówczas, gdy każda znajdująca się w danej kolumnie wartość może zostać przekonwertowana na nowy typ, za pomocą konwersji niejawnych; możliwe jest również dodanie klauzuli using, która określa, jak ma zostać przeprowadzona konwersja. alter table nazwa_tabeli alter column nazwa_kolumny type nowy_typ; Usunięcie tabeli: drop table [if exists] nazwa_tabeli [,...] [cascade restrict] Usunięcie tabeli powoduje automatyczne usunięcie indeksów, reguł, wyzwalaczy i ograniczeń powiązanych z usuwaną tabelą. Jeżeli istnieje odwołanie do usuwanej tabeli (powiązanie), to usunięcie jej wymaga użycia opcji cascade. Spowoduje to usunięcie definicji klucza obcego (odwołania) w tabeli podrzędnej. Użycie klauzuli if exists zapobiega wypisywaniu komunikatów o błędach, jeśli tabela nie istnieje. Opcja refuse zapobiega usunięciu tabeli, jeśli istnieją do niej odwołania. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 90/99

46 Sekwencje Sekwencje są nazwanymi licznikami definiowanymi przez użytkowników baz danych. Po utworzeniu sekwencji może on zostać ustawiona jako wartość domyślna dla wybranej tabeli. W efekcie, przy wstawianu rekordów, pole takie będzie miało przypisywane kolejne wartości pobierane z takiej sekwencji. currval( seq ) zwraca wartość wygenerowaną przy ostatnim użyciu nextval dla wskazanej sekwencji; lastval() zwraca wartość wygenerowaną przy ostatnim użyciu nextval dla dowolnej sekwencji; nextval( seq ) wyznacza i zwraca nową wartość dla wskazanej sekwencji; setval( seq, val) ustawia bieżącą wartość dla wskazanej sekwencji (val liczba typu bigint); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 91/99 Sekwencje przykład create sequence seq1; create table a ( lp integer primary key default nextval( seq1 ), znak char ); insert into a(znak) values( a ); insert into a(znak) values( b ); select setval( seq1, 7); insert into a(znak) values( c ); test=# select * from a; lp znak a 2 b 8 c (3 rows) Domyślnie wartości dostarczane przez sekwencje zaczynają się od 1 i są to kolejne liczby naturalne. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 92/99

47 Definiowanie sekwencji przykłady create sequence seq1; create temporary sequence seq2; create sequence seq3 increment by 2; create sequence seq4 increment by 2 start with 10; create sequence seq5 minvalue 1 maxvalue 3; -- nie można wstawić więcej niż 3 rekordy create sequence seq6 minvalue 1 maxvalue 3 cycle; -- UWAGA na klucz główny create sequence seq7 increment by -1 maxvalue 5 start with 5; create table a ( lp integer primary key, znak char ); create sequence seq8 increment by -1 maxvalue 5 start with 5 owned by a.lp; -- usunięcie tabeli usunie automatycznie sekwencję alter table a alter column lp set default nextval( seq8 ); Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 93/99 Sekwencje uwagi Użycie typu serial powoduje automatyczne zdefiniowanie dla danej kolumny sekwencji. Ma ona nazwę tabela_kolumna_seq. Dodatkowo automatycznie definiowany jest unikatowy indeks dla danego pola. Sekwencje są usuwane z użyciem polecenia drop sequence. Sekwencje można modyfikować stosując polecenie alter sequence. Ma ono składnię bardzo podobną do polecenia create sequence. Listę sekwencji w bazie danych można wyświetlić stosując polecenie \ds. create table b ( lp serial primary key, znak char ); alter sequence b_lp_seq rename to seq2; alter sequence seq2 increment by 3; Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 94/99

48 Widoki Widok (perspektywa) jest wirtualną tabelą zdefiniowaną przez zapytanie SQL. Nazwa widoku (podobnie jak tabeli) musi być unikatowa w ramach danego schematu danych. Z widoku, podobnie jak ze zwykłej tabeli, można pobierać dane, ale nie zawsze można aktualizować dane w oparciu o widok, np. PostgreSQL nie pozwala na modyfikacje danych w widoku. Widok nie istnieje w bazie danych dopóki nie zostanie wywołany (różni to widoki np. od tabel tymczasowych). Widoki pozwalają m.in. na: rzutowanie lub ograniczenie pojedynczej tabeli, dodanie pól obliczeniowych, rozszerzenie danych z jednej tabeli o dane z tabel z nią powiązanych (np. wyświetlanie dodatkowo nazwy oprócz identyfikatora), spłaszczenie związków jeden-do-wielu i wiele-do-wielu. Widok może być oparty na innych widokach, ale niedopuszczalne są zależności cykliczne. SQL create view name [ ( column_name [,...] ) ] as query; Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 95/99 Widoki przykłady create view zawodniczki as select imie, nazwisko, pozycja from siatkarki; select * from zawodniczki; create view rozgrywki as select idmeczu, gospodarze, d1.nazwa as gospodarze_nazwa, goscie, d2.nazwa as goscie_nazwa, termin from druzyny d1 join mecze on d1.iddruzyny = gospodarze join druzyny d2 on d2.iddruzyny = goscie; select idmeczu, gospodarze_nazwa, s.gospodarze, goscie_nazwa, s.goscie from statystyki s join rozgrywki using(idmeczu) order by termin; create view terminarz as select idmeczu, termin, gospodarze_nazwa, goscie_nazwa from rozgrywki order by termin; Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 96/99

49 Indeksy Indeks zdefiniowany na atrybucie A jest strukturą danych (najczęściej B-drzewo), która przyśpiesza wyszukiwanie krotek o ustalonych wartościach atrybutu A. SQL create index nazwa on tabela (atrybut); create index nazwa on tabela (atrybut1,atrybut2,...); Uwaga: Istnienie indeksu na atrybucie może znacznie przyśpieszyć wykonywanie zapytań, w których występuje wartość lub zakres wartości tego atrybutu. Z drugiej strony każdy indeks zdefiniowany na atrybutach danej relacji sprawia, że wstawianie danych, usuwanie i aktualizacja są bardziej złożone i czasochłonne. Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 97/99 Indeksy uwagi Korzyści z istnienia indeksu uzyskujemy tylko wtedy, gdy wykonujemy zapytania używające tego indeksu. PostgreSQL automatycznie tworzy indeks dla klucza głównego. Indeksowanie długich łańcuchów znaków jest nieporównanie bardziej kosztowne, niż indeksowanie mniejszych typów danych. Indeksy złożone są zazwyczaj rzadko używane. W ich definicji ważna jest kolejność atrybutów zaczynamy od najczęściej stosowanych w kryteriach wyszukiwania, kryteriach złączania lub porządku sortowania. Indeks zdefiniowany dla atrybutów nazwisko i imię w żaden sposób nie ułatwi przeszukiwania danych według samych imion (według nazwisk tak) lub sortowania typu order by imie, nazwisko. Indeks zdefiniowany dla pola typu data nie ułatwia wyszukiwania według części daty (np. miesiąca). Marcin Szpyrka Bazy danych Projektowanie i implementacja relacyjnych baz danych 98/99