BAZY DANYCH model relacyjny Opracował: dr inż. Piotr Suchomski
Relacyjny model danych Relacyjny model danych posiada trzy podstawowe składowe: relacyjne struktury danych operatory algebry relacyjnej, które umożliwiają tworzenie, przeszukiwanie i modyfikowanie danych ograniczenia (więzy) integralnościowe jawnie lub niejawnie określającymi możliwe/dopuszczalne wartości danych.
Relacja Podstawową strukturą danych modelu relacyjnego jest relacja, będąca podzbiorem iloczynu kartezjańskiego wybranych domen i przedstawiana w postaci dwuwymiarowej tabeli. W tym ujęciu pojęcia relacji (ang. relation) i tabeli (ang. table) są synonimami. Pojęcie relacji używane jest na poziomie teorii baz relacyjnych i modelu konceptualnego, a pojęcie tabeli na poziomie realizacji fizycznej.
Relacja Relacja (bazodanowa) jest to dowolny podzbiór produktu kartezjańskiego skończonej liczby dziedzin prostych. Dziedzina jest prosta, jeili jej elementy są nierozkładalne (atomowe). Niech D 1, D 2,,D n są to dziedziny proste, 0<n<, D 1 x D 2 x x D n to produkt kartezjański tych dziedzin prostych: zbiór wszystkich krotek (d 1, d 2,,d n ) takich, że d 1 D 1, d 2 D 2,, d n D n, Wartość n określa stopień relacji
Relacja Poszczególne pozycje krotek relacji nazywamy atrybutami relacji. Atrybuty relacji muszą być atomowe. Spełnienie tego wymogu jest warunkiem aby relacja była w pierwszej postaci normalnej (1NF).
Właściwości relacji wszystkie jej krotki są różne, wszystkie jej atrybuty są różne, kolejność krotek nie ma znaczenia i w ogólności nie jest ona znana, kolejność atrybutów nie ma znaczenia, wartości atrybutów są niepodzielne (atomowe), tj. nie mogą być zbiorem wartości.
Schemat relacji Nazwa relacji oraz zbiór jej atrybutów, umieszczonych wnawiasie, nazywany jest schematem relacji. Atrybuty w schemacie relacji nie są listami ale zbiorami. Jednak dla porządku ustala się standardowy porządek atrybutów i jest on wiążący w całym projekcie. Pracownik(nr_ewid, imie, nazwisko, stanowisko, dział) Samochód(nr_rej, marka, poj_silnika) Projekt relacyjnej bazy danych może składać się z jednego lub kilku schematów relacji. Zbiór schematów relacji nazywany jest schematem relacyjnej bazy danych.
Instancja relacji Relacja nie jest tworem statycznym, gdyż zmienia się w czasie. Zmiany te dotyczą poszczególnych krotek. Mogą pojawiać się nowe krotki, inne mogą być usuwane lub modyfikowane są wartości poszczególnych atrybutów. Stan relacji w danej chwili nazywany jest instancją relacji. W relacji zmianie może ulec również jej schemat, jednak takie operacje są bardzo kosztowne i zdarzają się rzadko.
Intensja i ekstansja relacji Z punktu widzenia semantyki (znaczenia) rozróżnia się dwa pojęcia - pojęcie intensji relacji oraz ekstensji relacji. Intensja relacji odpowiada znaczeniu relacji - predykat związany z relacją stanowi element jej intensji. Na intensję relacji mogą poza tym składać się inne jej własności. Ekstensja relacji jest zbiorem krotek spełniających własności, które stanowią intensję relacji. Własności te nazywa się warunkami integralności.
Intensja a ekstensja relacji Dla relacji R(PRZEDMIOT, DZIEŃ, GODZINA, SALA, WYKŁADOWCA): - intensję relacji wyrażają następujące warunki integralności: 1. predykat związany z relacją R mówi o tym, że wykładowca w prowadzi zajęcia z przedmiotu p w dniu d, o godzinie g, w sali s ; 2. dziedzina atrybutu GODZINA jest zbiorem liczb całkowitych z przedziału <7, 24>; 3. dany wykładowca moŝe znajdować się o określonej godzinie tylko w jednej sali. - ekstensję relacji R stanowi zbiór krotek spełniających własności (1), (2), (3).
Definicja zależności funkcyjnej Jeżeli dwie krotki relacji R są zgodne dla atrybutów A 1 A 2 A n, to muszą być również zgodne w pewnym innym atrybucie B. Zależność tą można zapisać: A 1 A 2 A n -> B, A 1 A 2 A n określają funkcyjnie B Jeśli zbiór atrybutów A 1,A 2,,A n określa więcej niż jeden atrybut B to można skrótowo zapisać: A 1 A 2 A n -> B 1 B 2 B m
Zależność funkcyjna
Klucze relacji Atrybut lub zbiór atrybutów {A1, A2,..., An} tworzy klucz relacji jeśli: wszystkie pozostałe atrybuty relacji są funkcyjnie zależne od tych atrybutów (nie może się zdarzyć aby dwie różne krotki relacji R były zgodne dla wszystkich atrybutów A1, A2,..., An) Nie istnieje taki podzbiór właściwy zbioru {A1, A2,..., An}, od którego pozostałe atrybuty relacji R są zależne funkcyjnie, tzn. klucz musi być minimalny Klucze w diagramach E/R nie spełniają drugiego wymagania
Nadklucze Nadklucz zbiór atrybutów, który zawiera klucz. Każdy klucz jest nadkluczem.
Wykrywanie kluczy w relacji Reguła 1 Jeśli relacja pochodzi z przekształcenia zbioru encji, to jej kluczem są atrybuty kluczowe tego zbioru encji Reguła 2 (dotyczy związków binarnych) Jeśli związek jest typu wiele do wiele, to klucze obu zbiorów encji objętych związkiem tworzą zbiór atrybutów klucza R jeśli związek ze zbioru encji E1 do zbioru encji E2 jest typu wiele do jeden, to atrybuty klucza E1 stają się kluczem R, ale atrybuty klucza E2 nie wchodzą do klucza relacji R. Jeśli związek jest typu jeden do jeden, to atrybuty klucza któregokolwiek ze zbiorów mogą być kluczem R. W tej sytuacji nie ma tylko jednego klucza.
Klucze relacji - notacja Klucze główne: Książki(ISBN, tytuł, autor, rok) Klienci(NIP, Nazwisko, adres, status) Książki(ISBN, tytuł, autor, rok) Klucze obce: Książki(ISBN, tytuł, autor, rok, id_wyd REF Wydawnictwo) Wydawnictwo(ident, nazwa, miasto) Klucz obcy Klucz obcy może wchodzić w skład klucza głównego.
Relacje a zbiory encji Reprezentacja zbiorów encji Każdy zbiór encji zamieniany jest na relację, której klucz główny jest równy kluczowi zbioru encji. Reprezentacja związków Związki 1:1 reprezentowane są przez klucz obcy wstawiany do jednej z relacji. Związki 1:n reprezentowane są przez klucz obcy wstawiany do relacji po stronie n. Związki n:m reprezentowane są przez dodatkową relację, której klucz główny powstaje ze złożenia kluczy głównych związanych zbiorów encji.
Relacje a zbiory encji Związek może być reprezentowany przez oddzielną relację również w przypadku związków 1:1 i 1:n co zapewni większą elastyczność i zapewni symetrię, natomiast wadą jest to, że powstaje dodatkowa relacja.
Relacje a zbiory encji - przykład Data PESEL PES_M PES_K PESEL Mężczyźni Małżeństwo Kobiety Schemat relacyjnej bazy danych: Mężczyźni(PESEL, imię, nazwisko, ) Kobiety(PESEL, imię, nazwisko, ) Małżeństwo(PES_M REF Mężczyźni, PES_K REF Kobiety, Data)
Anomalie aktualizacji Anomalie pojawiają się wtedy gdy do jednej relacji próbujemy włączyć zbyt wiele danych. Podstawową anomalią jest redundancja danych. W wielu krotkach pojawiają się te same dane. Problem modyfikacji relacji obarczonej anomalią polega na tym, że zmieniana wartość atrybutu musi być zmieniona we wszystkich krotkach relacji, w których ta wartość występuje. Problem usuwania danych. Wraz z usuwaną krotką można usuną dane, które mogą być przydatne. Istnieje również zagrożenie spójności i integralności danych.
Dekompozycja relacji Właściwym sposobem eliminacji anomalii jest dekompozycja relacji. Polega ona na podziale atrybutów relacji R na dwa nowe schematy relacji. Reguła dekompozycji dotyczy również krotek relacji R (podział danych do nowych relacji), dzięki operacji rzutowania krotek R.
Dekompozycja relacji Relację R o schemacie R(A 1,A 2, A n ) dekomponujemy między 2 relacje S i T o schematach S(B 1,B 2, B n ) i T(C 1,C 2, C n ) według następujących reguł: {A 1,A 2,,A n } = {B 1,B 2, B n } {C 1,C 2,,C n }, Krotki relacji S powstają przez rzutowanie wszystkich krotek relacji R na zbiór atrybutów {B 1,B 2,,B m }. Oznacza to, że z każdej krotki t z bieżącej instancji relacji R pobieramy wartości atrybutów B 1,B 2,,B m, i tworzymy w ten sposób krotkę relacji S, należącą do jej bieżącej instancji. Ponieważ relacje są zbiorami, więc taką samą krotkę S można uzyskać z rzutowania różnych krotek relacji R. W takich przypadkach w S umieszcza się tylko jedną kopię każdej krotki.
Dekompozycja relacji W podobny sposób z rzutowania krotek bieżącej instancji relacji R na zbiór atrybutów {C 1,C 2,,C k } otrzymuje się krotki relacji T.
Normalizacja PARTICIPANTS(IDENT, NAME, CITY, INHAB, COURSE, GRADE) Student o identyfikatorze IDENT i nazwisku NAME, pochodzący z miasta CITY, o liczbie mieszkańców INHAB, ukończył kurs COURSE, z oceną GRADE.
Normalizacja Tablica PARTICIPANTS wykazuje wiele anomalii ze względu na redundancję danych. Chcąc zmienić liczbę mieszkańców trzeba to zrobić w wielu wierszach (aby zachować integralność) Usuwając rekord danych o kursancie Rodin usuwane są również dane o liczbie mieszkańców miasta Aberdeen. Chcąc dodać informacje o innym kursie, który ukończył kursant trzeba też dodać dane, które w bazie już istnieją. Celem normalizacji jest usunięcie redundancji tak, by każda informacja była przechowywana w bazie tylko raz.
Zależności funkcyjne cd. Zbiór atrybutów B jest w pełni funkcyjnie zależny od zbioru atrybutów A w schemacie R, jeżeli A B i nie istnieje podzbiór A A taki, że A B. Zbiór atrybutów B jest częściowo funkcyjnie zależny od zbioru atrybutów A w schemacie R, jeżeli A B i istnieje podzbiór A A taki, że A B.
Druga postać normalna Relacja jest w 2NF jeżeli jest w pierwszej postaci normalnej (1NF) każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od klucza głównego. Relacja PARTICIPANT nie jest w 2NF gdyż zawiera niepełne zależności funkcyjne: IDENT->NAME IDENT->CITY IDENT->INHAB
Druga postać normalna cd. Relację PARTICIPANT można sprowadzić do 2NF dokonując dekompozycji (projekcji) na dwie relacje: PART_COURSE(IDENT REF PART_DATA, COURSE,GRADE) PART_DATA(IDENT, NAME, CITY, INHAB)
Druga postać normalna Relacja PART_DATA nadal posiada redundancję. Jeśli kliku studentów pochodzi z tego samego miasta to w bazie powtarzać się będą dane dotyczące liczby mieszkańców. Powodem tego jest to, że atrybut INHAB zależy funkcyjnie od atrybutu niekluczowego CITY.
Zależności funkcyjne cd. Zbiór atrybutów B jest przechodnio funkcyjnie zależny od zbioru atrybutów A w schemacie relacji R, jeżeli A B i istnieje zbiór atrybutów C, nie będący podzbiorem żadnego klucza schematu relacji R taki, że zachodzi A C i C B. Zależność funkcyjna A B jest zależnością przechodnią jeżeli istnieje podzbiór atrybutów taki, że zachodzi A C, C B i nie zachodzi C A lub B C.
Trzecia postać normalna Relacja jest w trzeciej postaci normalnej (3NF) jeśli: Jest w 2NF, Żaden atrybut niekluczowy nie zależy przechodnio od klucza głównego. Relację PART_DATA można sprowadzić do 3NF przez dekompozycję na dwie relacje: PART_ID(IDENT, NAME, CITY REF CITIES) CITIES(CITY, INHAB)
Trzecia postać normalna
Postać normalna Boyce a Codda Wyznacznik to atrybut relacji (może być złożony), od którego w pełni funkcjonalnie zależy inny atrybut tej relacji. Relacja jest w normalnej Boyce a Codda (BCNF) wtedy i tylko wtedy, gdy każdy wyznacznik jest kluczem kandydującym. Postać BCNF jest silniejsza niż 2NF i 3NF.
Zależności wielowartościowe Niech istnieje relacja R i jej atrybuty A, B, C. Pomiędzy atrybutami A i B zachodzi zależność wielowartościowa (A->->B) wtedy i tylko wtedy, gdy dla każdej wartości A istnieje zbiór możliwych wartości B i ten zbiór nie zależy od C
Zależności wielowartościowe Obie tablice są w 3NF (klucz główny składa się ze wszystkich atrybutów).ale: W obu tablicach istnieje redundancja danych SSN->->LANGUAGE (bo znajomość języków nie zależy od uprawianych sportów), SSN->->SPORT (bo uprawiane sporty nie zależą od znanych języków)
Czwarta postać normalna Relacja jest w czwartej postaci normalnej (4NF) jeśli jest w 3NF oraz nie zawiera dwóch lub więcej zależności wielowartościowych. Relację PERSONS można sprowadzić do 4NF przez dekompozycję na dwie relacje: PER_LAN(SSN, LANGUAGE) PER_SPORT(SSN, SPORT)
Normalizacja - podsumowanie Dobrze zaprojektowana relacja składa się klucza głównego (prosty lub złożony) i z pewnej liczby niezależnych od siebie atrybutów, które tylko zależą od całego klucza głównego. W każdym przypadku normalizacja relacji wymaga jej dekompozycję na kilka innych relacji drogą projekcji.
Reguły Codd a Edgar Frank Codd znany brytyjski informatyk, zasłużony w rozwoju teorii relacyjnych baz danych. Opublikował 12 reguł (właściwie 13), których stopień spełnienia określa poziom relacyjności bazy danych.
12 reguł Codd a 0. 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. 1. Reguła informacyjna. 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
12 reguł Codd a 2. Reguła gwarantowanego dostępu: ta reguła jest zasadniczo powtórzeniem 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
12 reguł Codd a 3. Uporządkowana obsługa wartości NULL: wymaga się, aby DBMS 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.
12 reguł Codd a 4. 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ń.
12 reguł Codd a 5. 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).
12 reguł Codd a 6. Reguła aktualizacji perspektyw: wszystkie perspektywy, które teoretycznie dają się aktualizować, muszą być aktualizowane przez system. 7. 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.
12 reguł Codd a 8. Fizyczna niezależność danych. Programy za pomocą których manipuluje się bazą danych są niezależne od tego jak baza danych jest fizycznie zorganizowana 9. Logiczna niezależność danych. Programy, za pomocą których BD jest przetwarzana są niezależne od tego jak baza danych jest zorganizowana wewnętrznie. 10. Zasady, które artykułują semantyczny stopień integralności, powinny być możliwe do opisania wewnątrz języka zapytań DBMS. Możliwe powinno być również zmagazynowanie ich wewnątrz katalogu systemu BD i narzucanie przez sam system BD
12 reguł Codd a 11. Relacyjna BD powinna działać tak samo, niezależnie od tego, czy pracuje na pojedynczej maszynie czy jest udostępniana sieciowo. 12. 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).