Bazy danych

2010-11-29
PLAN WYKŁADU
Modelowanie logiczne
Transformacja ERD w model relacyjny
 Odwzorowanie encji
 Odwzorowanie związków
 Odwzorowanie specjalizacji i generalizacji


BAZY DANYCH
Wykład 7
dr inż. Agnieszka Bołtuć
GŁÓWNE ETAPY PROJEKTOWANIA BAZY
MODELOWANIE LOGICZNE
DANYCH
świat
rzeczywisty

Schemat koncepcyjny jest przekształcany z
wyskopoziomowego modelu danych w
implementacyjny model danych,

Ten krok nazywany jest też projektowaniem
logicznym lub odwzorowaniem modelu danych,

Wynikiem modelowania logicznego jest schemat
bazy zgodny z modelem implementacyjnym
wykorzystywanym w danych SZBD.
zbieranie
i analiza wymagań
analiza
funkcjonalna
projekt
aplikacji
implementacja
transakcji
projekt
koncepcyjny
(pojęciowy)
projekt
logiczny
niezależne od SZBD
zależne od SZBD
projekt
fizyczny
1
2010-11-29
ERD - FIRMA
TRANSFORMACJA ERD DO MODELU
RELACYJNEGO
encje − > tabele
własności −> kolumny
 związki −> klucze obce lub tabele
 hierarchia encji −> jedna lub wiele tabel


ODWZOROWANIE ENCJI
Encja
Relacja
Prosty atrybut encji
Atrybut relacji
 Typ danych atrybutu encji
Typ danych atrybutu
relacji dla konkretnego SZBD
 Identyfikator encji
Klucz główny relacji
 Obowiązkowość atrybutu encji
Ograniczenie
atrybutu relacji NOT NULL
 Inne ograniczenia atrybutów encji
Ograniczenia
atrybutów relacji

ODWZOROWANIE ENCJI
PRACOWNICY
DZIAŁY
PESEL PRIMARY KEY,
Imię,
DrugieImię NULL,
Nazwisko NOT NULL,
DataUrodzenia NOT NULL,
Adres,
Płeć NULL,
Pensja
Numer PRIMARY KEY,
Nazwa NULL

PROJEKTY
Numer PRIMARY KEY,
Nazwa NULL,
Lokalizacja NOT NULL
2
2010-11-29
ODWZOROWANIE SŁABYCH ENCJI
Słaba encja
Relacja
Proste atrybuty encji
Atrybuty relacji
 Identyfikator encji właścicielskiej
Klucz obcy
relacji
 Klucz główny relacji
Kombinacja identyfikatora
encji właścicielskiej i identyfikatora częściowego
encji słabej (jeśli taki istnieje)
 Jeśli istnieje słaba encja E1 której właścicielem jest
inna słaba encja E2, to najpierw odwzorowana
powinna być encja właścicielska E2
ODWZOROWANIE SŁABYCH ENCJI


ODWZOROWANIE ZWIĄZKÓW
Związek binarny 1:1 transformuje się do klucza
obcego we wskazanej tabeli.
 Związek unarny 1:1 oraz 1:N 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.
CZŁONKOWIE_RODZINY
PESEL,
Imię,
DataUrodzenia,
Płeć,
StopieńPokrewieństwa,
PRIMARY KEY (PESEL, Imię)
PESEL REFERENCES pracownicy(PESEL)
ON DELETE CASCADE,
ON UPDATE CASCADE
ZWIĄZEK BINARNY 1:1

Wybieramy jedną z relacji i dołączamy do zbioru jej
atrybutów klucz obcy wskazujący na klucz główny
drugiej relacji (najlepiej jeśli relacja do której
dołączamy klucz obcy jest po stronie wymaganej
jeśli chodzi o udział w związku lub jeśli związek jest
obustronnie opcjonalny to transformuje się do
klucza obcego w tabeli o mniejszym rozmiarze),

Ograniczenie integralnościowe jest definiowane dla
atrybutu klucza obcego. Klucz ten nie może
przyjmować wartości pustych jeśli związek był
wymagany, może jeśli związek był opcjonalny.

3
2010-11-29
ZWIĄZEK BINARNY 1:1
ZWIĄZEK BINARNY 1:1
PRACOWNICY
DZIAŁY
PESEL PRIMARY KEY,
Imię,
DrugieImię NULL,
Nazwisko NOT NULL,
DataUrodzenia NOT NULL,
Adres,
Płeć NULL,
Pensja
Numer PRIMARY KEY,
Nazwa NULL,
Data_przejecia_kier,
PESEL_kier NOT NULL REFERENCES
pracownicy(PESEL)
Odwzorowanie związku ZARZĄDZA
ZWIĄZEK BINARNY 1:N
Klucz obcy dodawany do relacji po stronie liczności
N,
 Ograniczenia referencyjne definiowane dla klucza
obcego,
 Jeśli po stronie liczności N związek był
obowiązkowy to klucz obcy ma ograniczenie NOT
NULL, jeśli opcjonalny to NULL,
 Opcjonalność lub obowiązkowość związku po
stronie o liczności 1 nie jest odwzorowywana w
modelu relacyjnym.

Inne możliwości:

Umieszczenie klucza obcego w relacji która w
związku jest po stronie opcjonalnej – klucz
posiadałby wiele wartości pustych,

Scalenie dwóch encji w jedną relację – tylko jeśli
związek po obu stronach był wymagany,

Umieszczenie kluczy obcych w obu tabelach –
utrudnienia w utrzymywaniu spójności.
ZWIĄZEK BINARNY 1:N
PRACOWNICY
DZIAŁY
PESEL PRIMARY KEY,
Imię,
DrugieImię NULL,
Nazwisko NOT NULL,
DataUrodzenia NOT NULL,
Adres,
Płeć NULL,
Pensja,
NrDziału NOT NULL REFERENCES
działy (numer)
Numer PRIMARY KEY,
Nazwa NULL,
Odwzorowanie związku PRACUJE_W
4
2010-11-29
ZWIĄZEK BINARNY 1:N
ZWIĄZEK BINARNY M:N
Reprezentowany przez nową relację,
Nazwa powstaje przez połączenie nazw encji
uczestniczących w związku,
 Wprowadzamy klucze obce wskazujące na klucze
główne obu relacji reprezentujących encje biorące
udział w związku,
 Wprowadzone klucze obce tworzą klucz główny
relacji.

PROJEKTY
DZIAŁY
Numer PRIMARY KEY,
Nazwa NULL,
Lokalizacja NOT NULL,
NrDziału NOT NULL REFERENCES
działy(numer)
Numer PRIMARY KEY,
Nazwa NULL

Odwzorowanie związku KONTROLUJE
ZWIĄZEK BINARNY M:N
ZWIĄZEK UNARNY
Dotyczy rekursywnego powiązania różnych
instancji tej samej encji,
 Związek unarny 1:1 lub 1:N obustronnie opcjonalny
transformuje się do klucza obcego w tej samej
tabeli,
 Związek unarny M:N obustronnie opcjonalny jest
transformowany do tabeli.

PRACOWNICYPROJEKTY
NrProj REFERENCES projekty(numer),
PESELPr REFERENCES pracownicy (PESEL),
Godziny,
PRIMARY KEY (NrProj,PESELPr)
5
2010-11-29
ZWIĄZEK UNARNY 1:N
LEKI
ZWIĄZEK UNARNY M:N
Id_leku PRIMARY KEY,
Nazwa NOT NULL
PRACOWNICY
PESEL PRIMARY KEY,
Imię,
DrugieImię NULL,
Nazwisko NOT NULL,
DataUrodzenia NOT NULL,
Adres,
Płeć NULL,
Pensja,
NrDziału NOT NULL REFERENCES działy (numer),
PESELSzefa NULL REFERENCES Pracownicy (PESEL)
Nazwa
Id_leku
ZASTĘPNIKI
zastępnik
zastępowany
Zastępuje
M
ZWIĄZEK TERNARNY (I INNE N-SKŁADNIKOWE)
Związki ternarne i inne n-składnikowe (gdzie n>2)
odwzorowuje się w nową relację,
 Jako klucze obce do relacji wprowadzamy klucze
główne relacji powstałych przez transformacje encji
uczestniczących w związku,
 Klucze obce zazwyczaj tworzą klucz główny tabeli.

Id_leku REFERENCES leki(id_leku),
Id_zastęnika REFERENCES leki
(id_leku),
PRIMARY KEY (Id_leku, id_zastepnika)
Lek
N
ZWIĄZEK TERNARNY
DOSTAWCY
NazwaD PRIMARY KEY,
…
CZĘŚCI
DOSTARCZA
NazwaC REFERENCES części (nazwaC),
NazwaP REFERENCES projekty (nazwaP),
NazwaD REFERENCES dostawcy (nazwaD),
Ilość,
PRIMARY KEY (nazwaD, nazwaC, nazwaP)
NazwaC PRIMARY KEY,
…
PROJEKTY
NazwaP PRIMARY KEY,
…
6
2010-11-29
ODWZOROWANIE ATRYBUTÓW
ODWZOROWANIE ATRYBUTÓW
WIELOWARTOŚCIOWYCH
WIELOWARTOŚCIOWYCH
Dla każdego atrybutu wielowartościowego należy
stworzyć relację, która będzie zawierała atrybuty
odpowiadające wielowartościowemu oraz klucz
obcy wskazujący na odwzorowywaną encję,
 Klucz główny nowej relacji stanowi kombinacja
atrybutu odwzorowywanego oraz klucza obcego,
 Jeśli atrybut wielowartościowy jest zarazem
złożonym to do relacji wprowadzamy tylko atrybuty
proste i analizujemy atrybuty proste w celu
wyznaczenia klucza głównego.

BAZA FIRMA
Dimię
Nazwisko
PESEL
DataUr
Adres
Płeć
Pensja
Działy
Nazwa
Numer
NumerD,
Lokalizacja,
PRIMARY KEY (NumerD, Lokalizacja)
ODWZOROWANIE SPECJALIZACJI
Pracownicy
Imię
LOKALIZACJE_DZIAŁÓW
PESELSzefa
DataRozpKier
PESELSzefa
Nrdziału

Każdą specjalizację z m podencjami (S1,S2,…,Sm)
oraz nadencją C z atrybutami (k,c1,c2,…cn)
odwzorowujemy w relacje stosując kilka możliwych
metod:
Lokalizacje_działów
NumerD
Lokalizacja

do jednej relacji: z jednym atrybutem typu i z
wieloma atrybutami typów,

do wielu relacji: wyłącznie dla podencji, dla
nadencji i podencji.
Projekty
Nazwa
Numer
Lokalizacja
NumerD
PracownicyProjekty
PESEL
Nr_proj
Godziny
Członkowie_Rodziny
PESEL
Imię
Płeć
DataUr
Stopień_pokrewieństwa
7
2010-11-29
JEDNA RELACJA Z JEDNYM ATRYBUTEM TYPU
Tworzona jest jedna relacja reprezentująca
jednocześnie nadecję i podencje,
 Encja nadklasy będzie miała wartości puste we
wszystkich lokalnych atrybutach podencji,
 Nie jest zalecana, gdy podencje mają wiele
atrybutów lokalnych, gdy niewiele atrybutów
lokalnych to lepsza niż pozostałe,
 Stosowana szczególnie do rozłącznych podencji,
 Polega na dołączeniu pojedynczego atrybutu
określającego typ,
JEDNA RELACJA Z JEDNYM ATRYBUTEM TYPU

PESEL
Nazwisko
Adres
PRACOWNIK
Pracownik
d
Naukowy
Stopień
Techniczny
PESEL PRIMARY KEY,
Nazwisko,
Adres,
Stopień,
Uprawnienia,
Typ_pracownika
Uprawnienia
JEDNA RELACJA Z WIELOMA ATRYBUTAMI
JEDNA RELACJA Z WIELOMA ATRYBUTAMI
TYPÓW
TYPÓW
Tworzona jest jedna relacja reprezentująca
jednocześnie nadecję i podencje,
 Stworzona z myślą o odwzorowywaniu częściowo
pokrywających się podencji,
 Dołączamy m logicznych pól typów, po jednej dla
każdej podencji, które przechowują wartości {tak,
nie},gdzie wartośc tak oznacza że dana krotka jest
egzemplarzem podencji.

PRACOWNIK
PESEL PRIMARY KEY,
Nazwisko,
Adres,
Stopień,
Uprawnienia,
Jest_naukowym,
Jest_technicznym
8
2010-11-29
W IELE RELACJI DLA NADENCJI I PODENCJI
Tworzona jest relacja dla nadencji i jej atrybutów
oraz po jednej relacji dla każdej podencji,
 Każda relacja stworzona z podencji zawiera
atrybuty lokalne oraz klucz główny nadencji, który
staje się kluczem głównym podencji,
 Może być stosowana bez względu na ograniczenia
czy więzy.
W IELE RELACJI DLA NADENCJI I PODENCJI

PRACOWNIK
NAUKOWY
PESEL PRIMARY KEY,
Nazwisko,
Adres,
PESEL_n REFERENCES naukowy(PESEL),
PESEL_t REFERENCES techniczny(PESEL)
PESEL PRIMARY KEY,
Stopień
TECHNICZNY
PESEL PRIMARY KEY,
Uprawnienia
W IELE RELACJI WYŁĄCZNIE DLA PODENCJI
Tworzone są relacje po jednej dla wszystskich
podencji,
 Każda relacja stworzona z podencji zawiera
atrybuty wspólne oraz lokalne i klucz główny
nadencji, który staje się kluczem głównym każdej
podencji,
 Sprawdza się gdy podencje są całkowite – każda
nadencja należy przynajmniej do jednej z jej
podencji oraz gdy spełniony jest warunek
rozłączności.
W IELE RELACJI WYŁĄCZNIE DLA PODENCJI

NAUKOWY
TECHNICZNY
PESEL PRIMARY KEY,
Nazwisko,
Adres,
Stopień
PESEL PRIMARY KEY,
Nazwisko,
Adres,
Uprawnienia
9
2010-11-29
PODSUMOWANIE ODWZOROWANIA
Model ER
Model relacyjny
Encja
Relacja
Związek 1:1 i 1:N
Klucz obcy
Związek M:N
Relacja z dwoma kluczami
obcymi
Związek n-składnikowy
Relacja z n kluczami obcymi
Atrybut prosty
Atrybut
Atrybut złożony
Zbiór atrybutów prostych
Atrybut wielowartościowy
Relacja i klucz obcy
Zbiór wartości
Dziedzina
Atrybut klucza
Klucz główny
Specjalizacja (nadencje, podencje)
Jedna relacja lub wiele relacji
W YKŁAD PRZYGOTOWANO NA PODSTAWIE
R. Elmasri, S. B. Navathe, Wprowadzenie do
systemów baz danych, Helion, 2005,
 C. J. Date, Wprowadzenie do systemów baz
danych, WNT, Warszawa, 2000,
 http://wazniak.mimuw.edu.pl/index.php?title=Bazy_
danych.

10