Bazy danych wykład trzeci Przekształcenie modelu ER na model relacyjny Konrad Zdanowski Uniwersytet Kardynała Stefana Wyszyńskiego, Warszawa trzeci Przekształcenie modelu ER na model relacyjny 1 / 19
Przekształcanie modelu ER na projekt relacyjny Każda encja przekształcana jest na relację o tym samym zbiorze atrybutów. Każdy zwiazek przekształcany jest na relację o atrybutach będacych kluczami wchodzacych w zwiazek encji. Potencjalne problemy: słabe encje, zwiazki typu jest, niektóre relacje warto połaczyć w jedna (np. relację dla encji i jej zwiazku typu wiele do jeden). trzeci Przekształcenie modelu ER na model relacyjny 2 / 19
Przekształcanie modelu ER na projekt relacyjny Przekształcajac projekt ER na projekt relacyjny chcemy: uniknać nadmiernego wykorzystania pamięci, uniknać powtarzania tej samej informacji w wielu miejscach. Spełnienie powyższych wskazań jest możliwe dzięki odpowiedniemu zdefiniowaniu więzów w projekcie ER. trzeci Przekształcenie modelu ER na model relacyjny 3 / 19
Reprezentowanie encji Encję przekształcamy na relację o tych samych atrybutach. Przykład. adres nazwisko telefon imie Osoba id Osoba(id, imie, nazwisko, adres, telefon) Atrybut id jest kluczem relacji Osoba. trzeci Przekształcenie modelu ER na model relacyjny 4 / 19
Reprezentowanie zwiazków Zwiazek przekształcamy na relację, której atrybutami sa klucze encji, które wchodza w zwiazek i atrybuty relacji. Przykład. Niech id będzie kluczem relacji osoba a marka, nr_nadwozia kluczem relacji samochod. osoba posiada samochod data_zakupu trzeci Przekształcenie modelu ER na model relacyjny 5 / 19
Reprezentowanie zwiazków osoba posiada samochod data_zakupu posiada(wlasciciel_id, marka, nr_nadwozia, data_zakupu). Kluczem relacji posiada jest zbiór (wlasciciel_id, marka, nr_nadwozia). trzeci Przekształcenie modelu ER na model relacyjny 6 / 19
Reprezentowanie zwiazków Sposób w jaki reprezentujemy zwiazek zależy od typu zwiazku. Zwiazki typu wiele do wiele (M:N) reprezentujemy jako oddzielne relacje (jak w poprzednim przykładzie). Zwiazki funkcyjne typu jeden do jeden (1:1) lub wiele do jeden (M:1) reprezentujemy jako pola w relacji dla encji będacej po stronie dla której istnieje zależność funkcyjna lub po stronie wiele. trzeci Przekształcenie modelu ER na model relacyjny 7 / 19
Reprezentowanie zwiazków 1:M jednostronnie obowiazkowych fabryka wyprodukowala samochod data_produkcji Powyższy zwiazek reprezentujemy przez dodanie atrybutów klucza relacji fabryka do relacji samochod i atrybutów zwiazku. samochod(marka, nr_nadwozia, kolor, fabryka_id, data_produkcji). Klucz fabryka_id jest kluczem obcym w relacji samochod (NOT NULL). trzeci Przekształcenie modelu ER na model relacyjny 8 / 19
Reprezentowanie zwiazków 1:M opcjonalnych Zwiazki opcjonalne typu jeden do wiele możemy reprezentować podobnie jak zwiazki obowiazkowe. Różnica w reprezentacji polega na tym, że pozycja będaca kluczem obcym może być równa NULL. Jeśli wiemy, że zwiazek taki zachodzi rzadko, możemy rozważyć stworzenie oddzielnej tabeli jak w przypadku zwiazku typu (M:N) aby oszczędzić miejsce (lecz ewentualny zysk zależy od własności modelowanego świata poza tym spowolniamy odczyt danych). trzeci Przekształcenie modelu ER na model relacyjny 9 / 19
Zwiazki opcjonalne typu 1:1 Zwiazki takie możemy reprezentować przez dodanie klucza obcego do jednej z tabel. W uzasadnionych przypadkach możemy rozważyć dodanie klucza obcego do obu tabel (jeśli wiemy, że przyśpieszy to wyszukiwanie w BD). trzeci Przekształcenie modelu ER na model relacyjny 10 / 19
Przykład. mezczyzna poslubil kobieta Trzy sposoby na reprezentowanie zwiazku poslubil. 1 mezczyzna(id,..., zona_id), kobieta(id,..., maz_id), 2 mezczyzna(id,..., zona_id), kobieta(id,...), 3 mezczyzna(id,...), zona(id,..., maz_id). Klucze obce w relacjach moga być równe NULL. Reprezentowanie zwiazku w pierwszy ze sposobów może prowadzić do problemów z niespójnościa danych lecz ułatwia wyszukiwanie. trzeci Przekształcenie modelu ER na model relacyjny 11 / 19
Zwiazki unarne typu wiele do jeden Zwiazki unarne (pomiędzy ta sama encja) reprezentujemy przez dodanie pola w relacji dla tej encji. Pole to będzie kluczem obcym dla danej relacji. trzeci Przekształcenie modelu ER na model relacyjny 12 / 19
Przykład. kieruje podlega pracownik pracuje_dla Zwiazek reprezentujemy jako pracownik(id,..., kierownik_id). Zauważmy, że w tym przypadku klucz obcy jest pobrany z tej samej relacji pracownik. trzeci Przekształcenie modelu ER na model relacyjny 13 / 19
Zwiazki unarne typu wiele do wiele Zwiazki takie reprezentujemy jako oddzielne relacje. trzeci Przekształcenie modelu ER na model relacyjny 14 / 19
Ogólne zasady reprezentowania zwiazków Zwiazki typu wiele do jeden (M:1) reprezentujemy jako klucze obce w relacji występujacej po stronie wiele. Zwiazki obowiazkowe reprezentujemy przez warunek NOT NULL nałożony na klucz obcy. Zwiazki typu wiele do wiele reprezentujemy przez oddzielna tabele. trzeci Przekształcenie modelu ER na model relacyjny 15 / 19
Podklasy encji filmy rezyser ISA kreskowki musicale rysownik kompozytor trzeci Przekształcenie modelu ER na model relacyjny 16 / 19
Podklasy encji Podlasy encji możemy reprezentować: 1 jako jedna relację, w której pewne pola moga być puste (NULL) i dodatkowym atrybutem określajacym rodzaj elementu, 2 jako oddzielne relacje dla każdej podklasy zawierajace wszystkie atrybuty wspólne, 3 jako oddzielna relację z atrybutami wspólnymi i relacje zawierajace atrybuty podklas, w której klucze obce wskazuja na element tabeli wspólnej. trzeci Przekształcenie modelu ER na model relacyjny 17 / 19
Słabe encje gatunek nalezy rodzaj nazwa nazwa Relacja stworzona dla słabego zbioru encji musi zawierać wszystkie klucze relacji dla pomocniczych zbiorów encji. Klucze te wchodza (jako klucz obcy) w skład klucza tej relacji. Nie musimy reprezentować pomocniczego zwiazku jako relacji. Atrybuty tego zwiazku możemy umieścić w relacji stworzonej dla słabej encji. trzeci Przekształcenie modelu ER na model relacyjny 18 / 19
Słabe encje gatunek nalezy rodzaj nazwa nazwa Słaba encję gatunek reprezentujemy jako relację gatunek(nazwa_gatunkowa, nazwa_rodzajowa,...). Atrybut nazwa_rodzajowa wchodzi w skład klucza relacji. Nie może być równy NULL. trzeci Przekształcenie modelu ER na model relacyjny 19 / 19