PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Transkrypt

1 PODSTAWY BAZ DANYCH 5. Modelowanie danych 1

2 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań Analiza Modele konceptualne opisujące wymagania odnośnie: - danych, - funkcjonalności aplikacji. Np. ER Transformacja modeli pojęciowych do implementacyjnych Projektowanie Modele implementacyjne bazy danych i aplikacji np. relacyjny, obiektowy. Implementowanie bazy danych i aplikacji Implementacja Dokumentacja Wdrażanie Utrzymanie 2

3 Model związków - encji W modelu związków - encji (entity-relationship model - ER) występują: obiekty świata rzeczywistego reprezentowane są za pomocą encji (entities); powiązania między obiektami świata rzeczywistego reprezentowane są za pomocą związków (relationships) pomiędzy encjami. Będziemy używali notacja modelu ER według Barker (Oracle). Model związków - encji zawiera: encje, atrybuty encji, związki pomiędzy encjami, hierarchia generalizacji. 3

4 Modelowanie encji Encja Reprezentuje zbiór obiektów opisany tymi samymi cechami (atrybutami, własnościami). Informacje o tych obiektach będą przechowywane w bazie danych. Konkretny obiekt świata rzeczywistego jest reprezentowany jako wystąpienie encji. Przy modelowaniu encji należy przestrzegać następujących zasad: Każda encja posiada unikalną nazwę. Każda encja posiada zbiór atrybutów. Encje mogą wchodzić w związki z innymi encjami. Dowolna rzecz lub obiekt może być reprezentowany tylko przez jedną encję. Nazwa encji powinna być rzeczownikiem w liczbie pojedynczej. 4

5 Modelowanie encji Encje Student Nazwisko Imię Data_urodzenia Płeć Adres Telefon Wydział Nazwa_wydziału Adres Telefon Wystąpienie encji Student Kowalski Jan 1990/04/12 M Wydział Księgowość Warszawa Atrybutami encji mogą być: Atrybuty identyfikujące jednoznacznie encję. Związki z innymi encjami. Inne własności encji. Atrybuty z wartościami wymagalnymi. Atrybuty z wartościami opcjonalnymi (nie wymagalne). 5

6 Modelowanie encji Definicja atrybutu encji powinna zawierać: Nazwę. Dziedzinę. Typ danych i maksymalny rozmiar. Zakres dopuszczalnych wartości. Opcjonalność. Przykład. Student # Pesel * Nazwisko * Imię * Data_urodzenia * Płeć * Adres o Telefon Identyfikator encji Atrybuty z wartościami wymagalnymi Atrybut z wartością opcjonalną 6

7 Modelowanie związków (asocjacji) Kolejnym obiektem modelu ER jest związek, zwany również asocjacją, który reprezentuje powiązania pomiędzy obiektami świata rzeczywistego np. - Student może posiadać stypendium - Pracownik musi posiadać pensję Związek z każdego końca posiada krótki opis ułatwiający interpretację związku. 7

8 Modelowanie związków (asocjacji) Cechy związku Cechy związku Stopień związku unarny (binarny rekursywny - łączy encję samą z sobą), binarny (łączy dwie encje), ternarny (łączy trzy encje), n-arny (łączy n encji). Typ asocjacji (kardynalność) jeden-do-jeden (1:1), jeden-do-wiele (1:M), wiele-do-wiele (M:N). Istnienie (klasa przynależności) opcjonalny obowiązkowy 8

9 Modelowanie związków (asocjacji) Cechy związku Typ asocjacji, zwany kardynalnością związku, określa ile wystąpień jednej encji może być powiązanych z iloma wystąpieniami innej encji. Wyróżnia się związki 1:1, 1:M, M:N. Istnienie, zwane również klasą przynależności związku określa, czy związek jest opcjonalny, czy obowiązkowy. 9

10 Modelowanie związków (asocjacji) Przykład. Osoba może posiadać wiele kont. Jedno konto musi należeć tylko do jednej osoby. Np. 10

11 Modelowanie związków (asocjacji) Związek binarny 1-1 Przykład. Związek binarny 1:1. Pracownik może kierować tylko jednym wydziałem i wydział musi mieć tylko jednego kierownika. Nie każdy pracownik musi być kierownikiem. Wydział musi mieć kierownika. Np. Przykład. Związek binarny 1:1. Osoba musi posiadać inne_dane. Inne_dane muszą dotyczyć tylko jednej osoby. Osoba musi posiadać muszą dotyczyć Inne_dane Związek trudny (w zasadzie niemożliwy) w realizacji. 11

12 Modelowanie związków (asocjacji) Związek binarny Przykład. Związek binarny 1:1. Osoba może posiadać tylko jeden samochód. Samochód może należeć tylko do jednej osoby. Osoba może posiadać może należeć do Samochód Np. Przykład. Związek binarny 1:M. Pracownik może otrzymać wiele wypłat. Wypłata musi dotyczyć tylko jednego pracownika. 2008/ Notatki do wykładu "Podstawy baz danych" 12 12

13 Modelowanie związków (asocjacji) Związek binarny M-N Przykład. Związek binarny M:N. Student może zapisać się na wiele przedmiotów. Na przedmiot może zapisać się wielu studentów. Może być student, który nie zapisał się na żaden przedmiot i przedmiot, na który nie zapisał się żaden student. Takie powiązanie jest poprawne ale nie jest obsługiwane. Np. Można ten problem rozwiązać tworząc model: 13

14 Modelowanie związków (asocjacji) Związki unarne Przykład. Związki unarne. Pracownik może być przełożonym wielu pracowników. Nie każdy pracownik musi mieć przełożonego. Np. Poniższe związki są niepoprawne. Każdy pracownik musi być przełożonym. Każdy pracownik musi być podwładnym. Każdy pracownik musi być przełożonym i jednocześnie podwładnym. 14

15 Modelowanie związków (asocjacji) Związki wyłączne Związki wyłączne (exclusive relationships) - konkretne wystąpienie encji może w danym momencie wchodzić tylko w jeden ze związków. Przykład. Związek wyłączny. Faktura musi być wystawiona dla osoby lub dla firmy. Faktura nie może być wystawiona jednocześnie na firmę i osobę. Np. 15

16 Modelowanie związków (asocjacji) Związek n-arny Przykład. Związek n-arny. Student może otrzymać ocenę z przedmiotu od wykładowcy. Np. 16

17 Modelowanie związków (asocjacji) - Hierarchia generalizacji Przykład. Hierarchia generalizacji. Klient może otrzymać wiele faktur. Faktura musi być wystawiona tylko dla jednego klienta. Klientem może być osoba_fizyczna lub osoba_prawna. Np. 17

18 Modelowanie związków (asocjacji) - Hierarchia generalizacji Przykład. Hierarchia generalizacji. Osoba może być studentem lub pracownikiem. Student może posiadać oceny. Osoba może posiadać adres. Np. 18

19 Modelowanie związków (asocjacji) Słabe encje W modelu ER występuje pojęcie słabej encji (weak entity). Jest to encja nie posiadająca własnego identyfikatora. Wystąpienie tej encji może wystąpić tylko w połączeniu z encjami z nią związanymi. Kreseczka przy wielu oznacza, że związek wchodzi w identyfikator encji Oceny. 19

20 Modelowanie związków (asocjacji) 20

21 Modelowanie związków (asocjacji) i atrybutów encji 21

22 PODSTAWY BAZ DANYCH 6. Transformacja modelu ER do modelu relacyjnego 22

23 Transformacja modelu ER Przykład. Transformacja modelu ER do tabel w bazie danych Oracle. 23

24 Transformacja prostych encji Przykład. Transformacja prostych encji Osoba, Wydzial, Stanowisko do tabel w bazie danych Oracle. CREATE TABLE Osoby ( id_os NUMBER(4) PRIMARY KEY, nazwisko VARCHAR2(15) NOT NULL, imie1 VARCHAR2(15) NOT NULL, imie2 VARCHAR2(15), d_ur DATE NOT NULL, plec CHAR(1) NOT NULL CHECK (plec IN ('M','K')) ); CREATE TABLE Wydzialy ( id_w NUMBER(4) PRIMARY KEY, nazwa VARCHAR2(15) NOT NULL UNIQUE ); CREATE TABLE stanowiska ( id_s NUMBER(2) PRIMARY KEY, stanowisko VARCHAR2(10) NOT NULL UNIQUE ); 24

25 Transformacja związków Transformacja 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 dodatkowej tabeli. Związek unarny M:N transformuje się do dodatkowej tabeli. 25

26 Transformacja encji ze związkami Przykład. Transformacja encji Zatrudnienia ze związkami typu 1:M z encjami Osoba, Wydzial i Stanowisko do tabel w bazie danych Oracle. Związki są wymagalne po stronie encji Zatrudnienie i nie wymagalne po stronie encji Osoba, Wydzial i Stanowisko. CREATE TABLE Zatrudnienia ( id_z NUMBER(4) PRIMARY KEY, id_os NUMBER(4) NOT NULL, id_w NUMBER(4) NOT NULL, id_s NUMBER(2) NOT NULL, od DATE NOT NULL, do DATE, pensja NUMBER(8) NOT NULL, ); Transformacja wymagalności związków po stronie encji Zatrudnienie. FOREIGN KEY (id_w) REFERENCES Wydzialy (id_w), FOREIGN KEY (id_os) REFERENCES Osoby (id_os), FOREIGN KEY (id_s) REFERENCES stanowiska (id_s) Transformacja związków 26

27 Transformacja encji ze związkami Przykład. Transformacja encji Kierownik ze związkami typu 1:M z encjami Osoba, Wydzial do tabel w bazie danych Oracle. Związki są wymagalne po stronie encji Kierownik i nie wymagalne po stronie encji Osoba, Wydzial. CREATE TABLE Kierownicy ( id_w NUMBER(4) NOT NULL, id_os NUMBER(4) NOT NULL, od DATE NOT NULL, do DATE, FOREIGN KEY (id_w) REFERENCES Wydzialy (id_w), FOREIGN KEY (id_os) REFERENCES Osoby (id_os) ); Transformacja wymagalności związków po stronie encji Kierownik Transformacj a związków Uwaga. Związek transformuje się do atrybutów z warunkiem FOREGIN KEY. 27

28 Transformacja encji ze związkami Przykład. Związki binarne 1:M postaci nie są odwzorowywane w modelu relacyjnym. Np. 2008/ Notatki do wykładu "Podstawy baz danych" 28 28

29 Transformacja encji ze związkami Przykład. Transformacja związku 1:1 obustronnie opcjonalnego. CREATE TABLE Pracownicy ( id_p NUMBER(4) PRIMARY KEY, nazwisko VARCHAR2(20) NOT NULL, imie VARCHAR2(20) NOT NULL, nr_inwentarzowy NUMBER(4), FOREIGN KEY (nr_inwentarzowy) REFERENCES Samochody (nr_inwentarzowy) ); CREATE TABLE Samochody ( nr_inwentarzowy NUMBER(4) PRIMARY KEY, nr_rejestracyjny VARCHAR2(20) NOT NULL, id_pracownika NUMBER(4), FOREIGN KEY (id_pracownika) REFERENCES Pracownicy (id_pracownika) ); 29

30 Transformacja encji ze związkami Przykład. Transformacja związku 1:1 jednostronnie opcjonalnego. CREATE TABLE Pracownicy ( id_p NUMBER(4) PRIMARY KEY, nazwisko VARCHAR2(20) NOT NULL, imie VARCHAR2(20) NOT NULL, ); CREATE TABLE Samochody ( nr_inwentarzowy NUMBER(4) PRIMARY KEY, nr_rejestracyjny VARCHAR2(20) NOT NULL, id_pracownika NUMBER(4) NOT NULL UNIQUE, FOREIGN KEY (id_pracownika) REFERENCES Pracownicy (id_pracownika) ); 30

31 Transformacja encji ze związkami Przykład. Związek binarny M:N obustronnie opcjonalny postaci jest transformowany na tabelę Studenci i Przedmioty a związek jest transformowany do tabeli Zapisy. Np. 31

32 Transformacja encji ze związkami CREATE TABLE Studenci ( id_studenta NUMBER(4) PRIMARY KEY, nazwisko VARCHAR2(20) NOT NULL, imie VARCHAR2(20) NOT NULL, ); CREATE TABLE Przedmioty ( id_przedmiotu NUMBER(4) PRIMARY KEY, ); nazwa VARCHAR2(20) NOT NULL, Np. CREATE TABLE Zapisy ( id_studenta NUMBER(4) NOT NULL, id_przedmiotu NUMBER(4) NOT NULL, FOREIGN KEY (id_studenta) REFERENCES Studenci (id_studenta), FOREIGN KEY (id_przedmiotu) REFERENCES Przedmioty PRIMARY KEY (id_studenta, id_przedmiotu) ); (id_przedmiotu), 32

33 Transformacja encji ze związkami Przykład. Encja Pracownik ze związkiem unarnym postaci: jest transformowana na tabelę Pracownicy. Np. CREATE TABLE Pracownicy ( id_pracownika NUMBER(4) PRIMARY KEY, nazwisko VARCHAR2(20) NOT NULL, imie VARCHAR2(20) NOT NULL, id_szefa NUMBER(4), FOREIGN KEY (id_szefa) REFERENCES Pracownicy (id_pracownika) ); 33

34 Transformacja encji ze związkami Przykład. Encja Faktura ze związkami wyłącznymi postaci jest transformowana na tabelę Faktury. CREATE TABLE Faktury ( numer NUMBER(4) PRIMARY KEY, data DATE NOT NULL, kwota NUMBER(8,2) NOT NULL, pesel VARCHAR2(11), regon VARCHAR2(11), FOREIGN KEY (pesel) REFERENCES Osoba (pesel), FOREIGN KEY (regon) REFERENCES Firma (regon), ); 34

35 Transformacja encji Przykład. Transformacje hierarchii generalizacji Osoba można zrealizować tworząc dwie tabele Studenci i Pracownicy biorąc do nich atrybuty wspólne i odpowiednio atrybuty z odpowiedniej podencji. Np. 35