docProjektowanie relacyjnych baz danych – model związków encji
download 
Reklamacja Transkrypt
Projektowanie relacyjnych baz danych – model związków encji
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 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 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 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 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 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 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 Przykład: związki name addr name Bars Beers Sells license Frequents license = beer, full, none name manf Likes Drinkers Bary sprzedają różne marki piwa Klienci lubią różne marki piwa Klienci odwiedzają różne bary addr Bazy danych – wykład 8 8 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 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 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 Przykład: związek trójargumentowy name license addr name Bars manf Beers Preferences Drinkers name addr Bazy danych – wykład 8 12 Przykładowy zbiór związków Bar Joe’s Bar Sue’s Bar Sue’s Bar Joe’s Bar Joe’s Bar Joe’s Bar Sue’s Bar Drinker Ann Ann Ann Bob Bob Cal Cal Bazy danych – wykład 8 Beer Miller Bud Pete’s Ale Bud Miller Miller Bud Lite 13 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 Ilustracja graficzna związku wiele-do-wielu wiele-do-wielu Bazy danych – wykład 8 15 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 Ilustracja graficzna związku wiele-do-jednego wiele-do-jednego Bazy danych – wykład 8 17 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 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 Ilustracja graficzna związku jeden-do jednego jeden-do-jednego Bazy danych – wykład 8 20 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 Przykład: związek wiele-do-jednego Drinkers Beers Likes Favorite Uwaga: w dwóch różnych związkach uczestniczy ten sam zbiór encji Bazy danych – wykład 8 22 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 Na diagramie Manfs Bestseller Marka piwa jest najlepiej sprzedającą się dla 0 lub jednego producenta Bazy danych – wykład 8 Beers Producent ma dokładnie jedną najlepiej sprzedającą się markę piwa 24 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 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 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 Przykład: usuwanie atrybutu ze związku Bars Sells Prices price Bazy danych – wykład 8 Beers 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 28 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 Przykład: role Zbiór związków Husband Bob Joe … Married husband Wife Ann Sue … wife Drinkers Bazy danych – wykład 8 30 Przykład: role Zbiór związków Buddies 1 2 Buddy1 Bob Joe Ann Joe … Buddy2 Ann Sue Bob Moe … Drinkers Bazy danych – wykład 8 31 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 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 Przykład: podklasa name Beers manf isa color Ales Bazy danych – wykład 8 34 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 Przykład: reprezentanci encji name Beers manf isa color Pete’s Ale Ales Bazy danych – wykład 8 36 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 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 Przykład: name jest kluczem dla Beers name Beers manf isa color Ales Bazy danych – wykład 8 39 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 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 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 Słabe zbiory encji na diagramach E/R name number Players name 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 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 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 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 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 Przykład: dobry projekt name Beers name ManfBy addr Manfs Adres każdego producenta (manufacturer) reprezentowany jest tylko raz Bazy danych – wykład 8 48 Przykład: zły projekt name Beers name ManfBy addr Manfs manf Producent piwa jest tu reprezentowany na dwa sposoby: jako atrybut i jako powiązana encja Bazy danych – wykład 8 49 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 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 Przykład: dobry projekt name Beers name ManfBy addr 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 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 Przykład: zły projekt name Beers name 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 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 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 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 Zbiór encji relacja name manf Beers Relacja: Beers(name, manf) Bazy danych – wykład 8 58 Związek encji relacja name husband addr Drinkers 1 name Likes manf Beers 2 Buddies Favorite wife Married Bazy danych – wykład 8 Likes(drinker, beer) Favorite(drinker, beer) Buddies(name1, name2) Married(husband, wife) 59 Łą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 Łą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 Sally 123 Maple Sally 123 Maple beer Bud Miller redundancja Bazy danych – wykład 8 61 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 Przykład: słąby zbiór encji relacja name billTo Logins name 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 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 Przykład: podklasa relacja name Beers manf isa color Ales Bazy danych – wykład 8 65 Podejście zorientowane obiektowo name manf Bud Anheuser-Busch Beers name Summerbrew manf Pete’s Ales color dark Wygodne dla zapytań typu: „znajdź kolory wszystkich piw Ale produkowanych przez browar Pete’s.” Bazy danych – wykład 8 66 Styl E/R name manf Bud Anheuser-Busch Summerbrew Pete’s Beers name Summerbrew color dark Ales Wygodne dla zapytań typu “znajdź piwa (łącznie z Ale) produkowane przez browar Pete’s.” Bazy danych – wykład 8 67 Użycie NULL name manf Bud Anheuser-Busch Summerbrew Pete’s Beers color NULL dark Zaoszczędza pamięć, chyba że występuje wiele atrybutów, które najczęściej mają pseudowartość NULL Bazy danych – wykład 8 68
