Projektowanie relacyjnych baz danych model związków encji (Entity-Relationship, ER)

Transkrypt

1 BAZY DANYCH wykład 8 Projektowanie relacyjnych baz danych model związków encji (Entity-Relationship, ER) Dr hab. Sławomir Zadrożny, prof. PR

2 Modelowanie E/R Umożliwia projektowanie schematu bazy danych Tworzone projekty mają charakter graficzny i nazywane są diagramami E/R Bazy danych wykład 8 2

3 Kontekst dla modelowania E/R Projektowanie baz danych jest złożonym zadaniem Zleceniodawca często nie ma jasnej wizji co powinno się znaleźć w bazie danych Określenie i formalne opisanie najważniejszych obiektów, które mają być reprezentowane w bazie danych stanowi dobry sposób na stworzenie roboczej wersji bazy danych Bazy danych wykład 8 3

4 Zbiory encji Encja (entity) = coś ( thing ), obiekt Zbiór encji = zbiór podobnych encji Podobnie jak klasa w językach obiektowych Atrybut = własność (encji należących do) zbioru encji Bazy danych wykład 8 4

5 Diagramy E/R Oznaczenia stosowane w diagramach: Zbiór encji = prostokąt Atrybut = owal, połączony linią z prostokątem reprezentującym stosowny zbiór encji Bazy danych wykład 8 5

6 Przykład diagramu name manf Beers Zbiór encji Beers ma dwa atrybuty, name i manf (manufacturer). Każda encja ze zbioru Beers ma określone wartości tych dwóch atrybutów, np. (Bud, Anheuser-Busch) Bazy danych wykład 8 6

7 Związki (relationships) Związek łączy dwa lub większą liczbę zbiorów encji Jest oznaczony jako romb, połączony liniami z każdym z uczestniczących zbiorów encji Bazy danych wykład 8 7

8 Przykład: związki name addr name manf Bars Sells Beers Bary sprzedają różne marki piwa license Frequents Likes Klienci lubią różne marki piwa license = beer, full, none name Drinkers addr Klienci odwiedzają różne bary Bazy danych wykład 8 8

9 Zbiór związków Bieżącą wartością zbioru encji jest zbiór wszystkich encji należących do niego Przykład: zbiór wszystkich barów w naszej bazie danych Wartością związku jest zbiór związków, zbiór krotek odwołujących się do każdego z powiązanych zbiorów encji Bazy danych wykład 8 9

10 Przykład: zbiór związków Dla związku Sells, zbiór związków może mieć postać: Bar Joe s Bar Joe s Bar Sue s Bar Sue s Bar Sue s Bar Beer Bud Miller Bud Pete s Ale Bud Lite Bazy danych wykład 8 10

11 Związki wieloargumentowe Występują powiązania łączące więcej niż dwa zbiory encji Przykład. Przypuśćmy, że klienci lubią pić pewne marki piwa tylko w pewnych barach Trzy wcześniej wymienione związki binarne Likes, Sells, i Frequents nie pozwalają nam tego wyrazić Potrzebny jest związek trójargumentowy! Bazy danych wykład 8 11

12 Przykład: związek trójargumentowy name addr name manf license Bars Beers Preferences Drinkers name addr Bazy danych wykład 8 12

13 Przykładowy zbiór związków Bar Drinker Beer Joe s Bar Ann Miller Sue s Bar Ann Bud Sue s Bar Ann Pete s Ale Joe s Bar Bob Bud Joe s Bar Bob Miller Joe s Bar Cal Miller Sue s Bar Cal Bud Lite Bazy danych wykład 8 13

14 Związki wiele-do-wielu Skupmy uwagę na binarnych związkach, takich jak Sells łączący zbiory encji Bars i Beers W przypadku związków wiele-do-wielu, encja z każdego ze zbiorów może być powiązana z wieloma encjami drugiego ze zbiorów na przykład bar (Bars) sprzedaje (Sells) wiele marek piwa (Beers) i zarazem każda marka piwa jest sprzedawana przez wiele barów. Bazy danych wykład 8 14

15 Ilustracja graficzna związku wiele-do-wielu wiele-do-wielu Bazy danych wykład 8 15

16 Związki wiele-do-jednego Niektóre binarne związki mają postać związków wiele-do-jednego z jednego zbioru encji do drugiego Każda encja pierwszego zbioru encji jest powiązana z co najwyżej jedną encją drugiego zbioru encji Ale jedna encja drugiego zbioru może być powiązana z wieloma encjami pierwszego zbioru (może też nie być powiązana z żadną) Bazy danych wykład 8 16

17 Ilustracja graficzna związku wiele-do-jednego wiele-do-jednego Bazy danych wykład 8 17

18 Przykład: związek wiele-do-jednego Związek Favorite, łączący Drinkers i Beers ma charakter wiele-do-jednego Klient ma co najwyżej jedną ulubioną markę piwa Ale jedna marka piwa może być ulubioną wielu klientów (lub żadnego) Bazy danych wykład 8 18

19 Związki jeden-do-jednego W związkach typu jeden-do-jednego, każda encja każdego ze zbiorów encji jest powiązana z co najwyżej jedną encją z drugiego zbioru Przykład: związek Best-seller łączący zbiory encji Manfs (producent) i Beers. Marka piwa nie może być produkowana przez więcej niż jednego producenta i żaden producent nie ma dwóch najlepiej sprzedających się marek Bazy danych wykład 8 19

20 Ilustracja graficzna związku jeden-do jednego jeden-do-jednego Bazy danych wykład 8 20

21 Oznaczanie typu (liczebności) związku na diagramie Związki wiele-do-jednego oznaczamy strzałką na końcu linii prowadzącej do strony jeden od rombu reprezentującego związek Uwaga: Ten typ związku ma charakter zależności funkcyjnej Związki jeden-do-jednego oznaczamy strzałkami na końcach obydwu linii wychodzących z rombu reprezentującego związek Zaokrąglona strzałka oznacza dokładnie jeden, to znaczy każda encja z pierwszego zbioru encji jest powiązana z dokładnie jedną encją zbioru drugiego (czyli, musi być powiązana z jakąś encją z drugiego zbioru) Bazy danych wykład 8 21

22 Przykład: związek wiele-do-jednego Drinkers Likes Beers Favorite Uwaga: w dwóch różnych związkach uczestniczy ten sam zbiór encji Bazy danych wykład 8 22

23 Przykład: związek jeden-do-jednego Rozważmy związek Best-seller łączący Manfs i Beers Niektóre marki piwa nie są najlepiej sprzedającymi się markami żadnego z producentów, a więc zaokrąglona strzałka prowadząca do Manfs byłaby niepoprawna Ale każdy producent musi mieć najlepiej sprzedającą się markę piwa Bazy danych wykład 8 23

24 Na diagramie Manfs Bestseller Beers Marka piwa jest najlepiej sprzedającą się dla 0 lub jednego producenta Producent ma dokładnie jedną najlepiej sprzedającą się markę piwa Bazy danych wykład 8 24

25 Atrybuty związków Czasami może być wygodne przypisać związkowi pewien atrybut Można interpretować taki atrybut jako własność krotek w zbiorze związku Bazy danych wykład 8 25

26 Przykład: atrybut związku Bars Sells Beers price Price jest własnością pary (bar, beer), a nie którejś z tych encji indywidualnie Bazy danych wykład 8 26

27 Równoważne diagramy bez atrybutów związków Można pozbyć się atrybutów związków postępując następująco: Utworzyć zbiór encji reprezentujący wartości atrybutu Uczynić ten zbiór encji uczestnikiem rozważanego związku Bazy danych wykład 8 27

28 Przykład: usuwanie atrybutu ze związku Bars Sells Beers Prices price Strzałka wychodząca z wieloargumentowego związku oznacza, że pozostałe encje uczestniczące w związku jednoznacznie wyznaczają encję ze wskazywanego przez strzałkę zbioru encji Bazy danych wykład 8 28

29 Role zbiorów encji w związku Może się zdarzyć, że dany zbiór encji uczestniczy wielokrotnie w danym związku Wtedy oznacza się linię łączącą związek z poszczególnymi wystąpieniami danego związku encji etykietami nazywanymi rolami. Bazy danych wykład 8 29

30 Przykład: role Zbiór związków Married Husband Bob Joe Wife Ann Sue husband Drinkers wife Bazy danych wykład 8 30

31 Przykład: role Zbiór związków Buddies 1 2 Drinkers Buddy1 Buddy2 Bob Ann Joe Sue Ann Bob Joe Moe Bazy danych wykład 8 31

32 Podklasy Podklasa = specjalny przypadek zbioru encji = mniej encji = więcej własności Przykład: Piwa typu Ale stanowią rodzaj piwa Nie każde piwo to Ale, ale niektóre są Ale. Załóżmy, że piwa Ale, poza wszystkimi własnościami (atrybutami i powiązaniami) piw mają dodatkowy atrybut color. Bazy danych wykład 8 32

33 Podklasy na diagramach E/R Przyjmijmy, że podklasy tworzą drzewo tzn., dany zbiór encji może być podklasą tylko jednego zbioru encji (nie ma wielokrotnego dziedziczenia ang. multiple inheritance) Trójkąty z napisem Isa łączą ze sobą dwa zbiory encji i są skierowane od podklasy do nadklasy Bazy danych wykład 8 33

34 Przykład: podklasa name Beers manf isa color Ales Bazy danych wykład 8 34

35 Podklasy w E/R i OOP W programowaniu zorientowanym obiektowo (OOP), obiekty należą tylko do jednej klasy. W E/R encje mają reprezentantów we wszystkich podklasach, do których należą. Zasada: jeśli encja e jest reprezentowana w podklasie, to jest również reprezentowana w nadklasie i wszystkich jej nadklasach Bazy danych wykład 8 35

36 Przykład: reprezentanci encji name Beers manf isa Pete s Ale color Ales Bazy danych wykład 8 36

37 Klucze Klucz to taki zbiór atrybutów danego zbioru encji, że nie mogą istnieć dwie różne encje w tym zbiorze, któe mają identyczne wartości wszystkich atrybutów składających się na klucz. Dwie encje mogą mieć identyczne wartości niektórych atrybutów składających się na klucz, ale nie wszystkich Należy określić klucz dla każdego zbioru encji Bazy danych wykład 8 37

38 Klucze na diagramach E/R Atrybuty składające się na klucz są podkreślane Jeśli na diagramie występuje hierarchia (drzewo) zbiorów encji określona przez relację Isa, to tylko zbiór encji będący korzeniem tego drzewa ma określony klucz, który spełnia rolę klucza dla wszystkich zbiorów encji w drzewie. Bazy danych wykład 8 38

39 Przykład: name jest kluczem dla Beers name Beers manf isa color Ales Bazy danych wykład 8 39

40 Przykład: klucz wieloatrybutowy dept number hours room Courses Należy zwrócić uwagę, że hours i room mogą również służyć jako klucz, ale należy wybrać tylko jeden klucz Bazy danych wykład 8 40

41 Słabe zbiory encji ang. Weak Entity Sets Niekiedy, aby jednoznacznie zidentyfikować encje w danym zbiorze encji trzeba odwołać się do innego zbioru encji. Zbiór encji E nazywamy słabym jeśli w celu jednoznacznej identyfikacji jego encji musimy odwołać się do jednego z powiązań wiele-dojednego, w którym E uczestniczy i użyć klucza powiązanego zbioru encji jako części klucza E. Bazy danych wykład 8 41

42 Przykład: słaby zbiór encji name jest prawie kluczem w zbiorze encji reprezentującym piłkarzy, ale może być dwóch piłkarzy o tym samym nazwisku number na pewno nie jest kluczem, ponieważ piłkarze w dwóch różnych zespołach mogą mieć ten sam numer number wraz z nazwą zespołu (name), powiązanego z piłkarzem w ramach związku Plays-on, powinien już jednoznacznie identyfikować piłkarza Bazy danych wykład 8 42

43 Słabe zbiory encji na diagramach E/R name number name Players Playson Teams Uwaga: związek musi mieć liczebność dokładnie jeden ponieważ każdy piłkarz musi być powiązany z dokładnie jednym zespołem, żeby móc określić jego klucz Romb z podwójnym obrysem oznacza związek wspierający wiele-do-jednego Prostokąt z podwójnym obrysem oznacza słaby zbiór encji Bazy danych wykład 8 43

44 Słabe zbiory encji Słaby zbiór encji musi mieć jeden lub więcej związków wiele-do-jednego z innymi zbiorami encji Nie każdy z tych związków wiele-dojednego musi być związkiem wspierającym Związki wspierające muszą mieć liczebność dokładnie jeden : musi być gwarantowane istnienie (wystąpienie) encji po stronie jeden związku wspierającego Bazy danych wykład 8 44

45 Słabe zbiory encji Klucz słabego związku encji stanowią jego własne podkreślone atrybuty wraz z kluczami zbiorów encji powiązanych związkiem wspierającym np., number (piłkarza) wraz z name (jego zespołu) stanowi klucz dla słabego związku encji Players Bazy danych wykład 8 45

46 Zasady projektowania 1. Unikanie redundancji 2. Ograniczać użycie słabych zbiorów encji 3. Nie należy używać zbioru encji, jeśli wystarczy użyć atrybutu. Bazy danych wykład 8 46

47 Unikanie redundancji Redundancja = reprezentacja tego samego na dwa lub więcej różnych sposobów Wiąże się ze stratą zasobów i stwarza ryzyko wystąpienia niespójności Dwie reprezentacje tego samego faktu stają się niespójne jeśli zmienimy jedną i zapomnimy zmienić drugą Najlepszym przykładem są wcześniej omawiane anomalie związane z zachodzeniem zależności funkcyjnych Bazy danych wykład 8 47

48 Przykład: dobry projekt name name addr Beers ManfBy Manfs Adres każdego producenta (manufacturer) reprezentowany jest tylko raz Bazy danych wykład 8 48

49 Przykład: zły projekt name name addr Beers ManfBy Manfs manf Producent piwa jest tu reprezentowany na dwa sposoby: jako atrybut i jako powiązana encja Bazy danych wykład 8 49

50 Przykład: zły projekt name manf manfaddr Beers Adres producenta powtarzany jest przy każdym piwie przez niego produkowanym możliwe wystąpienie niespójności danych. Jednocześnie, jeśli w danej chwili nie ma informacji o piwach produkowanych przez danego producenta, to nie można reprezentować informacji o jego adresie Bazy danych wykład 8 50

51 Zbiory encji a atrybuty Zbiór encji powinien spełniać przynajmniej jeden z następujących warunków: reprezentuje coś więcej niż tylko nazwę czegoś ma przynajmniej jeden niekluczowy atrybut lub stanowi stronę wiele w związku wiele-dojednego lub wiele-do wielu Bazy danych wykład 8 51

52 Przykład: dobry projekt name name addr Beers ManfBy Manfs dla reprezentacji producentów warto użyć zbioru encji Manfs ponieważ występuje tu niekluczowy atrybut addr dla reprezentacji piw warto użyć zbioru encji Beers ponieważ stanowi stronę wiele w związku wiele-dojednego ManfBy Bazy danych wykład 8 52

53 Przykład: dobry projekt name manf Beers Nie warto reprezentować producentów z użyciem zbioru encji, ponieważ nie przechowuje się o nich żadnej informacji poza nazwą (kluczem) Bazy danych wykład 8 53

54 Przykład: zły projekt name name Beers ManfBy Manfs Producenci nie spełniają żadnego z dwóch warunków uzasadniających modelowanie z życiem zbioru encji: mają tylko jeden atrybut (kluczowy) i nie występują po stronie wiele żadnego ze związków Bazy danych wykład 8 54

55 Ograniczać użycie słabych zbiorów encji Początkujący projektanci mają skłonność do tworzenia kluczy odwołujących się do innych zbiorów encji, z którym dany zbiór encji jest związany W praktyce zazwyczaj tworzy się unikalne (sztuczne) identyfikatory dla zbiorów encji Przykłady: numer PESEL, NIP, numer VIN samochodu itp. Bazy danych wykład 8 55

56 Kiedy słaby zbiór encji jest potrzebny? Zazwyczaj wtedy kiedy nie ma powszechnie akceptowanej instytucji, która mogłaby nadawać unikalne identyfikatory Przykład: jest mało prawdopodobne, żeby ustalono powszechne porozumienie co do jednoznacznej identyfikacji piłkarzy wszystkich klubów na całym świecie Bazy danych wykład 8 56

57 Od diagramów E/R do relacji Zbiór encji relacja atrybuty atrybuty związki encji relacje, których atrybutami są wyłącznie: klucze powiązanych zbiorów encji atrybuty samych związków encji Bazy danych wykład 8 57

58 Zbiór encji relacja name manf Beers Relacja: Beers(name, manf) Bazy danych wykład 8 58

59 Związek encji relacja name addr name manf husband Drinkers 1 2 Likes Beers Buddies Married wife Favorite Likes(drinker, beer) Favorite(drinker, beer) Buddies(name1, name2) Married(husband, wife) Bazy danych wykład 8 59

60 Łączenie relacji Dopuszczalne jest łączenie tak uzyskanych relacji: 1. relacji odpowiadającej zbiorowi encji E 2. relacji odpowiadającej związkowi wiele-dojednego, w którym zbiór encji E jest po stronie wiele Przykład: Drinkers(name, addr) i Favorite(drinker, beer) łączy się tworząc Drinker1(name, addr, favbeer) Bazy danych wykład 8 60

61 Łączenie relacji i związki wiele-do-wielu Łączenie relacji Drinkers z relacją Likes byłoby błedem, gdyż prowadzi to do redundancji: name addr beer Sally 123 Maple Bud Sally 123 Maple Miller redundancja Bazy danych wykład 8 61

62 Handling Weak Entity Sets Relacja dla słabego związku encji musi zawierać atrybuty składające się na klucz tego związku (również te atrybuty należące do innych zbiorów encji), jak również swoje własne, niekluczowe, atrybuty Związek wspierający jest redundantny i nie tworzy się dla niego osobnej relacji (chyba, że posiada własne atrybuty!) Bazy danych wykład 8 62

63 Przykład: słąby zbiór encji relacja name name billto Logins At Hosts location Hosts(hostName, location) Logins(loginName, hostname, billto) At(loginName, hostname, hostname2) związek At jest reprezentowany przez Logins muszą być identyczne Bazy danych wykład 8 63

64 Podklasy: trzy podejścia 1. zorientowane obiektowo : jedna relacja dla każdej podklasy, ze wszystkimi własnymi i odziedziczonymi atrybutami 2. użycie NULL : jedna relacja; encje przyjmują (pseudo)wartość NULL dla atrybutów, które do nich nie należą 3. styl E/R : jedna relacja dla każdej podklasy: atrybuty kluczowe atrybuty danej podklasy Bazy danych wykład 8 64

65 Przykład: podklasa relacja name Beers manf isa color Ales Bazy danych wykład 8 65

66 Podejście zorientowane obiektowo name Bud manf Anheuser-Busch Beers name manf color Summerbrew Pete s dark Ales Wygodne dla zapytań typu: znajdź kolory wszystkich piw Ale produkowanych przez browar Pete s. Bazy danych wykład 8 66

67 Styl E/R name manf Bud Anheuser-Busch Summerbrew Pete s Beers name color Summerbrew dark Ales Wygodne dla zapytań typu znajdź piwa (łącznie z Ale) produkowane przez browar Pete s. Bazy danych wykład 8 67

68 Użycie NULL name manf color Bud Anheuser-Busch NULL Summerbrew Pete s dark Beers Zaoszczędza pamięć, chyba że występuje wiele atrybutów, które najczęściej mają pseudowartość NULL Bazy danych wykład 8 68