encji W modelu związków

PODSTAWY
BAZ DANYCH
5. Modelowanie danych
2009/2010 - Notatki do wykładu "Podstawy baz danych"
1
Etapy tworzenia systemu informatycznego
Etapy tworzenia systemu informatycznego - (według CASE*Method)
(CASE – Computer Aided Systems Engineering )
Analiza wymagań
Transformacja modeli pojęciowych
do implementacyjnych
Implementowanie
bazy danych i aplikacji
Analiza
Modele konceptualne opisujące
wymagania odnośnie:
- danych,
- funkcjonalności aplikacji.
Np. ER
Projektowanie
Implementacja
Modele implementacyjne
bazy danych i aplikacji
np. relacyjny, obiektowy.
Dokumentacja
Wdrażanie
Utrzymanie
2009/2010 - Notatki do wykładu "Podstawy baz danych"
2
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
3
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
4
Modelowanie encji
Encje
Wystąpienie encji
Student
Nazwisko
Imię
Data_urodzenia
Płeć
Adres
Telefon
Student
Kowalski
Jan
1990/04/12
M
…
Wydział
Nazwa_wydziału
Adres
Telefon
Wydział
Księgowość
Warszawa …
601987665
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).
2009/2010 - Notatki do wykładu "Podstawy baz danych"
5
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
2009/2010 - Notatki do wykładu "Podstawy baz danych"
Identyfikator encji
Atrybuty z wartościami
wymagalnymi
Atrybut z wartością
opcjonalną
6
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
7
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
2009/2010 - Notatki do wykładu "Podstawy baz danych"
8
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
9
Modelowanie związków (asocjacji)
Przykład. Osoba może posiadać wiele kont. Jedno konto musi
należeć tylko do jednej osoby.
Np.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
10
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
muszą dotyczyć
musi posiadać
Inne_dane
Związek trudny (w zasadzie niemożliwy) w realizacji.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
11
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.
może należeć do
Osoba
Samochód
może posiadać
Przykład.
Np. Związek binarny 1:M. Pracownik może otrzymać wiele
wypłat. Wypłata musi dotyczyć tylko jednego pracownika.
2008/2009
- Notatki
do wykładu
"Podstawy
2009/2010 - Notatki
do wykładu
"Podstawy
baz danych"
baz danych"
12
12
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:
2009/2010 - Notatki do wykładu "Podstawy baz danych"
13
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. związki są niepoprawne.
Poniższe
Każdy pracownik musi być
przełożonym.
Każdy pracownik musi być
podwładnym.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
Każdy pracownik musi
być przełożonym i
jednocześnie
podwładnym.
14
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
15
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
16
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
17
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
18
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
19
Modelowanie związków (asocjacji)
2009/2010 - Notatki do wykładu "Podstawy baz danych"
20
Modelowanie związków (asocjacji) i atrybutów encji
2009/2010 - Notatki do wykładu "Podstawy baz danych"
21
PODSTAWY
BAZ DANYCH
6. Transformacja modelu ER do
modelu relacyjnego
2009/2010 - Notatki do wykładu "Podstawy baz danych"
22
Transformacja modelu ER
Przykład. Transformacja modelu ER do tabel w bazie danych
Oracle.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
23
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
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
24
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
25
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,
Transformacja wymagalności związków po
id_w NUMBER(4) NOT NULL,
stronie encji Zatrudnienie.
id_s NUMBER(2) NOT NULL,
od DATE NOT NULL,
do DATE,
pensja NUMBER(8) NOT NULL,
FOREIGN KEY (id_w) REFERENCES Wydzialy (id_w), Transformacja
FOREIGN KEY (id_os) REFERENCES Osoby (id_os),
związków
FOREIGN KEY (id_s) REFERENCES stanowiska (id_s)
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
26
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
Transformacja wymagalności
( id_w NUMBER(4) NOT NULL,
związków po stronie encji Kierownik
id_os NUMBER(4) NOT NULL,
od DATE NOT NULL,
do DATE,
FOREIGN KEY (id_w) REFERENCES Wydzialy (id_w), Transformacj
a związków
FOREIGN KEY (id_os) REFERENCES Osoby (id_os)
);
Uwaga. Związek transformuje się do atrybutów z warunkiem
FOREGIN KEY.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
27
Transformacja encji ze związkami
Przykład. Związki binarne 1:M postaci
nie są odwzorowywane w modelu relacyjnym.
Np.
2008/2009
- Notatki
do wykładu
"Podstawy
2009/2010 - Notatki
do wykładu
"Podstawy
baz danych"
baz danych"
28
28
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)
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
29
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)
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
30
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
31
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
(id_przedmiotu),
PRIMARY KEY (id_studenta, id_przedmiotu)
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
32
Transformacja encji ze związkami
Przykład. Encja Pracownik ze związkiem unarnym postaci:
jestNp.
transformowana na tabelę Pracownicy.
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)
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
33
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),
);
2009/2010 - Notatki do wykładu "Podstawy baz danych"
34
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.
2009/2010 - Notatki do wykładu "Podstawy baz danych"
35