TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO Biologiczne Aplikacje Baz Danych dr inż. Anna Leśniewska alesniewska@cs.put.poznan.pl
REPETYTORIUM Schemat bazy danych zbiór schematów relacji Relacja (tabela) dwuwymiarowa tabela będąca implementacją encji. Kolumny tabeli są atrybutami. Wiersze tabeli to krotki - reprezentują wystąpienia encji Klucz podstawowy (główny) (identyfikator): atrybut lub zbiór atrybutów wybrany spośród kluczy potencjalnych do identyfikacji krotek relacji. Klucz obcy: atrybut lub zbiór atrybutów relacji, który jest kluczem podstawowym w innej relacji. Klucz obcy służy do logicznego powiązania krotek dwóch relacji.
TRANSFORMACJA Transformacja modelu ER jest konieczna, ponieważ jak pamiętamy jest on modelem abstrakcyjnym, niezależnym od implementacji. Transformujemy do modelu relacyjnego, który jest modelem implementacyjnym baz danych. Transformacji podlegają wszystkie obiekty modelu ER, czyli encje z atrybutami, związki i hierarchie encji.
TRANSFORMACJA DO SCHEMATU RELACYJNEGO - SCENARIUSZ 1. Transformacja encji Dla każdej encji, która nie tworzy hierarchii encji, utwórz relację odwzorowując atrybuty encji na nazwy kolumn relacji. Utwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. Hierarchie encji transformuj zgodnie z odpowiednimi regułami # Id_pracownika * Imię * Nazwisko o Adres_ulica o Adres_miasto
TRANSFORMACJA ENCJI # Id_pracownika * Imię * Nazwisko o Adres_ulica o Adres_miasto PRACOWNICY ( id_pracownika PRIMARY KEY, imię NOT NULL, nazwisko NOT NULL, adres_ulica NULL, adres_miast NULL ) Reguły transformacji encji: Nazwę encji wyrażoną w liczbie mnogiej przenosimy jako nazwę relacji. Atrybuty encji przenosimy jako nazwy kolumn (atrybuty) relacji. Unikalny identyfikator encji przenosimy jako klucz podstawowy relacji. Obligatoryjność atrybutu encji przenosimy jako ograniczenie NOT NULL atrybutu relacji. Opcjonalność atrybutu encji przenosimy jako własność NULL atrybutu relacji.
TRANSFORMACJA ZWIĄZKÓW Reguły transformacji związków: Związek binarny 1:1 transformuje się do klucza obcego we wskazanej tabeli. Związek unarny 1:1 transformuje się do klucza obcego w tej samej tabeli. Związek binarny 1:M transformuje się do klucza obcego w tabeli po stronie "wiele". Związek binarny M:N transformuje się do tabeli. Związek unarny M:N transformuje się do tabeli.
ZWIĄZEK BINARNY Związek binarny 1:1 obligatoryjny lub opcjonalny Jednostronnie bądź obustronnie # Id_pracownika * Imię * Nazwisko o Adres_ulica o Adres_miasto DZIAŁ # Id_działu *Nazwa o Adres
TRANSFORMACJA ZWIĄZKÓW 1:1 ZWIĄZEK DWUSTRONNIE OPCJONALNY Zasady transformacji: Tworzymy klucz obcy w relacji o mniejszej liczbie krotek, na podstawie klucza podstawowego drugiej relacji. Na atrybuty klucza obcego nakładamy ograniczenie referencyjne.
TRANSFORMACJA ZWIĄZKÓW 1:1 ZWIĄZEK DWUSTRONNIE OPCJONALNY # Id_pracownika * Imię * Nazwisko o Adres_ulica zarządza jest kierowany przez DZIAŁ # Id_działu * Nazwa o Adres Zasady transformacji: Tworzymy klucz obcy w relacji o mniejszej liczbie krotek, na podstawie klucza podstawowego drugiej relacji. Która tabela będzie miała mniejszą liczbę krotek?
TRANSFORMACJA ZWIĄZKÓW 1:1 ZWIĄZEK DWUSTRONNIE OPCJONALNY # Id_pracownika * Imię * Nazwisko o Adres_ulica PRACOWNICY ( Id_P PRIMARY KEY... DZIAŁY ( Id_D PRIMARY KEY... zarządza Id_Kierownika FOREIGN KEY NULL REFERENCE Pracownicy (Id_P)) jest kierowany przez DZIAŁ # Id_działu * Nazwa o Adres Uzasadnienie: Tylko np. 10% pracowników pełni funkcje kierownicze
ZWIĄZEK DWUSTRONNIE OPCJONALNY Pracownik # IdPracownika * Nazwisko * Etat * Pensja wykorzystuje wykorzystywany przez Komputer # NrInwentarzowy * Biuro Pracownicy Komputery IdPracownika PRIMARY KEY Nazwisko NOT NULL Etat NOT NULL Pensja NOT NULL NrInwentarzowy FOREIGN KEY NrInwentarzowy PRIMARY KEY Biuro NOT NULL IdPracownika FOREIGN KEY IdPracownika NULL REFERENCES Pracownicy(IdPracownika) NrInwentarzowy NULL REFERENCES Komputery(NrInwentarzowy)
Transformacja związków 1:1 związek dwustronnie opcjonalny 1. Pracownicy IdPracownika PRIMARY KEY... NrInwentarzowy FOREIGN KEY Komputery NrInwentarzowy PRIMARY KEY Biuro NOT NULL IdPracownika FOREIGN KEY 2. Pracownicy IdPracownika PRIMARY KEY... Komputery NrInwentarzowy PRIMARY KEY Biuro NOT NULL IdPracownika FOREIGN KEY 3. Pracownicy IdPracownika PRIMARY KEY... NrInwentarzowy FOREIGN KEY Komputery NrInwentarzowy PRIMARY KEY Biuro NOT NULL
# id_pracownika * imię * nazwisko TRANSFORMACJA ZWIĄZKÓW 1:N zatrudniony na zajmowane przez PRACOWNICY ( Id_pracownika PRIMARY KEY Imię NOT NULL Nazwisko NOT NULL Stanowisko FOREIGN KEY NOT NULL REFERENCE Stanowiska(Nazwa) ) STANOWISKA ( Nazwa PRIMARY KEY Płaca_min NOT NULL Płaca_max NULL STANOWISKO # nazwa * płaca_min o płaca_max Zasady transformacji: Tworzymy klucz obcy w relacji po stronie "wiele" na podstawie klucza podstawowego relacji po stronie "jeden". Na atrybuty klucza obcego nakładamy ograniczenie referencyjne. Obligatoryjność związku po stronie "wiele" przenosimy jako ograniczenie NOT NULL atrybutów klucza obcego. Opcjonalność związku po stronie "wiele" przenosimy jako własność NULL atrybutów klucza obcego
TRANSFORMACJA ZWIĄZKÓW M:N Zasady transformacji: Związek M:N przenosimy jako nową relację Tworzymy klucze obce na podstawie kluczy podstawowych dwóch pozostałych relacji. Na atrybuty jednego i drugiego klucza obcego nakładamy dwa ograniczenia referencyjne. Wszystkie atrybuty relacji tworzą klucz podstawowy.
TRANSFORMACJA ZWIĄZKÓW M:N # id_pracownika * imię * nazwisko bierze udział w realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz Relacja systemowa (związku) stanowiąca implementację związku M:N PRACOWNICY ( Id_pracownika PRIMARY KEY Imię NOT NULL Nazwisko NOT NULL ) PROJEKTY ( Nazwa_projektu PRIMARY KEY Data_rozpocz NOT NULL Data_zakoncz NULL ) UDZIAŁY_W_PROJEKTACH ( Id_pracownika REFERENCE Pracownicy(id_pracownika), Nazwa_projektu REFERENCE Projekty(Nazwa_projektu), PRIMARY KEY (Id_pracownika, Nazwa_projektu) )
TRANSFORMACJA ZWIĄZKÓW M:N # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz A co w przypadku gdybyśmy chcieli przechowywać informację o liczbie godzin tygodniowo przepracowanych przez pracownika nad określonym projektem?
TRANSFORMACJA ZWIĄZKÓW M:N # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz Jest to przypadek atrybutu charakteryzującego związek!
TRANSFORMACJA ZWIĄZKÓW M:N # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz PRACOWNICY ( Id_pracownika PRIMARY KEY Imię NOT NULL Nazwisko NOT NULL ) PROJEKTY ( Nazwa_projektu PRIMARY KEY Data_rozpocz NOT NULL Data_zakoncz NULL ) UDZIAŁY_W_PROJEKTACH ( Id_pracownika REFERENCE Pracownicy(id_pracownika), Nazwa_projektu REFERENCE Projekty(Nazwa_projektu), Godziny NULL PRIMARY KEY (Id_pracownika, Nazwa_projektu) ) Atrybut związku
Ćwiczenie 1 Lecznica zwierząt Chcemy pamiętać w systemie podstawowe informacje o pacjentach lecznicy zwierząt, przy czym dla danego gatunku (np. pies) trzeba pamiętać rasę pacjenta (np. seter irlandzki). Lecznica zatrudnia lekarzy weterynarii. Lekarze w ramach swoich obowiązków przyjmują określonych pacjentów (wizyty). Wizyty mogą mieć różny charakter, tj. w ich trakcie mogą być wykonywane badania, zabiegi i operacje. Oczywiście za wizyty lecznica pobiera określone płatności. Chcemy wiedzieć jacy lekarze jakich pacjentów przyjmowali w ramach wizyt oraz jakie badania, zabiegi lub operacje tym pacjentom były wykonywane i przez kogo. O wszystkich wymienionych tutaj elementach tej dziedziny rzeczywistości, będziemy chcieli przechowywać odpowiednie informacje w projektowanej bazie danych. Zadanie: Dokonaj transformacji opracowanego modelu ER do postaci schematu relacyjnej bazy danych.
TRANSFORMACJA ZWIĄZKÓW REKURENCYJNYCH # id_prac * imię * nazwisko... kieruje podlega PRACOWNICY ( Id_pracownika PRIMARY KEY..., id_szefa REFERENCE Pracownicy(id_pracownika) ) Zasady transformacji: Zasady transformacji związków rekurencyjnych analogicznie jak w przypadku związków 1:1, 1:N oraz M:N.
TRANSFORMACJA ZWIĄZKÓW REKURENCYJNYCH zastępuje Lek # IdLeku * Nazwa jest zastępowany Leki IdLeku PRIMARY KEY Nazwa NOT NULL Zastępniki IdLeku1 IdLeku2 IdLeku1 NOT NULL REFERENCES Leki(IdLeku) IdLeku2 NOT NULL REFERENCES Leki(IdLeku) PRIMARY KEY (IdLeku1, IdLeku2)
TRANSFORMACJA HIERARCHII ENCJI DO TRZECH RELACJI # id_prac atrybuty_wspólne KRAJOWY ZAGRANICZNY atr_specyf_kraj atr_specyf_zagr PRACOWNICY ( Id_pracownika PRIMARY KEY atrybuty_wspólne, typ_prac NOT NULL ) PRACOWNICY_KRAJ ( Id_pracownika PRIMARY KEY atr_specyf_kraj ) PRACOWNICY_ZAGR ( Id_pracownika PRIMARY KEY atr_specyf_zagr ) Zasady transformacji: Tworzymy jedną relację zawierająca atrybuty wspólne i atrybut określający typ specjalizacji Dla każdej specjalizacji tworzymy relację zawierającą jej atrybuty specyficzne i klucz podstawowy dziedziczony z generalizacji.
TRANSFORMACJA HIERARCHII ENCJI DO DWÓCH RELACJI # id_prac atrybuty_wspólne KRAJOWY atr_specyf_kraj ZAGRANICZNY atr_specyf_zagr PRACOWNICY_KRAJ ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_kraj ) PRACOWNICY_ZAGR ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_zagr ) Zasady transformacji: Dla każdej specjalizacji tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji.
TRANSFORMACJA HIERARCHII ENCJI DO JEDNEJ RELACJI # id_prac atrybuty_wspólne KRAJOWY atr_specyf_kraj ZAGRANICZNY atr_specyf_zagr PRACOWNICY ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_kraj NULL atr_specyf_zagr NULL typ_prac NOT NULL) Zasady transformacji: Tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne wszystkich specjalizacji i atrybut określający typ specjalizacji. Wszystkim atrybutom specyficznym poszczególnych specjalizacji nadajemy własność NULL.
TRANSFORMACJA HIERARCHII ENCJI ZWIĄZKI WYŁĄCZNE (ŁUK) Rachunek bankowy # Numer * Rodzaj * Saldo * Data Osoba fizyczna # NIP * Nazwisko Osoba prawna # REGON * Nazwa Rachunki_Bankowe Numer PRIMARY KEY Rodzaj NOT NULL Saldo NOT NULL Data NOT NULL NIP NULL REFERENCES OsobyFizyczne(NIP) REGON NULL REFERENCES OsobyPrawne(REGON)