Plan wykładu Bazy danych Wykład 9: Przechodzenie od diagramów E/R do modelu relacyjnego. Definiowanie perspektyw. Diagramy E/R - powtórzenie Relacyjne bazy danych Od diagramów E/R do relacji SQL - perspektywy Małgorzata Krętowska Wydział Informatyki Politechnika Białostocka 2 Diagramy ER Podstawowe elementy ERD zbiory encji encje atrybuty związki Reprezentacja danych: dwuwymiarowa tabela, zwana relacją : Atrybuty Krotki Liczności Klucze Podklasy Zbiory słabych encji Tytuł Rok Czas Rodzaj Żurek 2003 95 Kolor Kingsajz 1987 100 Kolor Seksmisja 1985 110 Kolor 3 4 Schemat relacji - nazwa relacji oraz jej zbiór atrybutów Film (,, czas, rodzaj) W modelu relacyjnym projekt składa się z jednego lub kilku schematów relacji. Zbiór schematów relacji jest określany schematem relacyjnym bazy danych lub schematem bazy danych. Krotki - wiersze relacji, poza wierszem nagłówka, zawierającym atrybuty relacji W krotce każdy atrybut ma swój odpowiednik w postaci składowej krotki : (Gwiezdne wojny, 1977, 124, kolor) Jedna krotka nie może wystąpić w relacji więcej niż jeden raz. Dziedziny -pewien określony typ elementarny, powiązany z każdym atrybutem relacji W modelu relacyjnym każda składowa każdej relacji musi mieć określony typ atomowy (elementarny) np. typ całkowity, znakowy. Wartość atrybutu nie może być ani rekordem, ani listą, ani zbiorem... : Film (,, czas, rodzaj) 5 6
Równoważne sposoby reprezentowania relacji Formalny zapis krotki Instancje Schematy i krotki relacji są zbiorami, stąd porządek w jakim je przedstawimy nie ma znaczenia. Tytuł Rok Czas Rodzaj Żurek 2003 95 Kolor Kingsajz 1987 100 Kolor Seksmisja 1985 110 Kolor Krotka - funkcja przeprowadzająca atrybuty ze schematu relacji do ich zbiorów wartości - do składowych tych krotek: -> Żurek -> 2003 czas -> 95 rodzaj -> Kolor (Żurek, 2003, 95, kolor) Rodzaj Tytuł Rok Czas Kolor Żurek 2003 95 Kolor Kingsajz 1987 100 Kolor Seksmisja 1985 110 Instancja relacji - zbiór krotek danej relacji Instancja bieżąca - zbiór krotek, które są w relacji teraz (Kolor, Żurek, 2003, 95) 7 8 Proces modelowania i implementacji bazy danych Od diagramów ERD do relacji Analiza informacji, które będą zawarte w bazie danych Diagram E/R System zarządzania relacyjną bazą danych Schemat bazy danych (Model relacyjny) Zbiory encji przekształcamy w relację z takim samym zbiorem atrybutów Związki z diagramów encji przyjmują postać relacji. Relacja danego związku R ma następujące atrybuty: dla każdego zbioru encji uczestniczącego w R umieszczamy w schemacie relacji odpowiadającej R klucze tych zbiorów jako atrybuty tej relacji jeśli związek ma własny klucz, to też dołączamy jego atrybuty do zbioru atrybutów relacji Uwaga: w przypadku powtarzania się nazw atrybutów należy zmienić ich nazwy 9 10 Związki wieloargumentowe Złożenie relacji Kontrakty Aktorzy Dopuszcza się możliwość złożenia dwóch relacji: relacji związanej z danym zbiorem encji E z relacją powstałą ze związku R wiele do jeden z E do innego zbioru encji. Studio producenta Studio aktora nazwa Studia Posiada Studia Tabela kontrakty: Klucz dla zbioru :, Klucz dla zbioru Aktorzy: nazwiskoaktora Klucz dla Studia producenta: studioproducenta Klucz dla Studia aktora: studioaktora czas rodzaj (,, czas, rodzaj) Studia (nazwa, adres) Posiada (,, nazwa) adres (,, czas, rodzaj, nazwast) Studia (nazwa, adres) 11 12
Zbiory słabych encji Relacja odpowiadająca słabemu zbiorowi encji E powinna zawierać wszystkie atrybuty, które wchodzą w skład klucza tego zbioru (tj. atrybuty ze zbioru słabego, jak też atrybuty z innych wspomagających zbiorów encji) oraz pozostałe atrybuty zbioru słabego. nazwisko Piłkarze wiek numer gra nazwa Drużyny Związki oznaczone podwójnym rombem nie tworzą oddzielnych relacji. Piłkarze (numer, nazwisko,nazwadrużyny, wiek) Drużyny (nazwadrużyny) Gra (numer, nazwadrużyny, nazwadrużyny1) Wskazują na jedną nazwę Gra jest częścią relacji Piłkarze 13 14 Trzy podejścia: Reprezentacja związków w modelu relacyjnym - podejście zorientowane obiektowo czas rodzaj zorientowane obiektowo - każda krotka należy tylko do jednej klasy; tworzenie relacji dla każdej klasy biorąc pod uwagę wszystkie jej atrybuty styl E/R - relacje są tworzone dla każdej podklasy; zawierają atrybuty kluczowe i te atrybuty, które sa powiązane z podklasą Wykorzystując NULL - należy utworzyć tylko jedną relacje; encje przyjmują wartości NULL dla tych atrybutów, które nie wchodzą w skład danego zbioru encji 15 (czas,,, rodzaj) (,, czas, rodzaj, ) (,, czas, rodzaj) -(,, czas, rodzaj, ) Dubbinguje (nazwiskoaktora,, ) Czy możemy łączyć relacje? 16 - styl E/R - wykorzystanie NULL czas rodzaj czas rodzaj (czas,,, rodzaj) (,, ) (, ) Dubbinguje (nazwiskoaktora,, ) Czy potrzebna jest relacja? Film(,, długość, rodzaj, ) (Bolek i Lolek, 1985, 10, Kolor, NULL) Dubbinguje (,, nazwiskoaktora) 17 18
Porównanie metod Tworzenie perspektyw Zapytania: Koszt zapytań związanych z wieloma relacjami jest duży, stąd podejście wykorzystujące NULL jest lepsze. Podejscie zorientowane obiektowo jest lepsze dla zapytań typu jaka jest wykorzystywana w kreskówkach trwających dłużej niż 150 minut Styl E/R jest lepszy dla zapytań typu jakie filmy z u 1999 trwały dłużej niż 150 minut Preferuje się schematy z możliwie małą liczbą relacji (E/R - 1 relacja na 1 zbiór encji; o-o - mając korzeń i n podklas otrzymujemy 2 n klas) Minimalizacja zajętości dysku: najlepsza metoda o-o; metoda NULL - w zależności od liczby elementów brakujących może być lepsza lub gorsza od metody E/R. CREATE [ OR REPLACE] VIEW nazwa_perspektywy [(kolumna1, kolumna2,...)] SELECT... Kolumna1 kolumna2... - to nazwy kolumn perspektywy, które muszą odpowiadać pozycjom z listy SELECT... Jeżeli perspektywa o takiej nazwie już istnieje, a chcemy tylko zmienić treść jej zapytania, musimy wcześniej usunąć poprzednią perspektywę lub użyć opcji OR REPLACE; w definicji perspektywy nie może wystąpić klauzula ORDER BY 19 20 Utworzyć perspektywą D10EMP zawierającą niektóre dane o pracownikach zatrudnionych w departamencie 10. Tworzenie perspektywy zawierającej funkcje grupowe i wybierającej dane z dwóch tabel: CREATE VIEW D10PRACOWNIK select id_pracownika, nazwisko, pensja where nr_departamentu=10; Odwołanie się do perspektywy jest analogiczne jak odwołanie się do zwykłej tabeli: select * from d10 pracownik order by nazwisko; CREATE VIEW dept_summary (nazwa, minpensja, maxpensja, avgpensjal) as select nazwa, min(pensja), max(pensja), avg(pensja), departament where pracownik.nr_departamentu=departament.nr_departamentu group by nazwa; nazwy kolumn w perspektywach można definiować również za pomocą aliasów w zapytaniu SELECT 21 22 Operacje DML na perspektywach Ograniczenie dostępu Perspektywy mogą służyć nie tylko do wybierania wartości, ale również do ich modyfikacji opcja WITH CHECK OPTION - pozwala na modyfikację danych przez perspektywę,ale tylko w ograniczonym zakresie. Można dodawać i modyfikować tylko takie wiersze, które następnie będą wybrane przez tą perspektywę. CREATE VIEW D10pracownik select id_pracownika, nazwisko, pensja where nr_departamentu=10; CREATE VIEW D10pracownik select id_pracownika, nazwisko, pensja where nr_departamentu=10 with check option; Aby ograniczyć użytkownikowi dostęp do jego danych pracowniczych i tylko w godzinach urzędowania firmy, można napć: CREATE VIEW pracownik_szczegoly select id_pracownika, nazwisko, stanowisko, nr_departamentu where nazwisko=user and to_char(sysdate, hh24 ) between 9 and 17 and to_char(sysdate, d ) between 2 and 6 with check option; 23 24
Ograniczenia operacji DML Usuwanie perspektywy Operacja DELETE nie jest dozwolona, jeżeli perspektywa zawiera jedno z: złączenie tabel funkcje grupowe klauzulę GROUP BY kwalifikator DISTINCT pseudokolumnę ROWNUM skorelowane podzapytanie Operacji UPDATE nie jest dozwolona, gdy: nie jest dozwolona operacja DELETE perspektywa zawiera kolumnę wyrażoną za pomocą wyrażenia (np. Sal*2) DROP VIEW nazwa_perspektywy rozkaz ten powoduje usunięcie definicji perspektywy z bazy danych nie narusza wierszy i kolumn bo są one trzymane w tabelach, na których perspektywa była oparta pozostawienie innych perspektyw i aplikacji bazujących na usuniętej perspektywie powoduje błąd perspektywa może być usunięta przez swojego właściciela lub administratora Operacja INSERT nie jest dozwolona, gdy: kolumna obowiązkowa ( NOT NULL) nie jest wybierana przez perspektywę. 25 26 Perspektywy w zapytaniach Dla każdego departamentu podać nazwiska tych pracowników, którzy zarabiają mniej niż średnia wartość pensji w ich departamencie. Tworzymy perspektywę: Create view avg_pensja as select nr_departamentu, avg(pensja) srednia group by nr_departamentu; Zapytanie główne: select nazwisko, avg_pensja where pracownik.nr_departamentu=avg_pensja.nr_departamentu and pensja<srednia; 27