[ Pobierz całość w formacie PDF ]
rz dnej, to znaczy, e relacja cz ca te encje jest relacj identyfikuj c (ang. identi-
fying relation). Wynika to z tego, e unikatowy atrybut encji zale nej wymaga zastoso-
wania wyj tkowego atrybutu encji nadrz dnej, aby jednoznacznie zidentyfikowa
odpowiedni egzemplarz encji. Je eli takie wymaganie nie istnieje, to relacja jest
definiowana jako nieidentyfikuj ca (ang. non-identifying relation).
W przypadku relacji identyfikuj cej klucz g ówny encji nadrz dnej jest faktycznie
jednym z atrybutów sk adaj cych si na klucz g ówny encji zale nej. Oznacza to,
e klucz obcy encji zale nej jest cz ci lub nawet ca o ci jej klucza g ównego.
W przypadku relacji nieidentyfikuj cej klucz g ówny encji nadrz dnej jest tylko
niekluczowym atrybutem encji zale nej.
Zaledwie niewielka cz relacji to relacje identyfikuj ce, poniewa wi kszo
encji zale nych mo e by referowanych ca kowicie niezale nie od encji nadrz dnej.
W relacjach typu wiele-do-wielu s jednak cz sto stosowane relacje identyfikuj ce,
jako e dodatkowa encja wi e z sob klucze g ówne encji nadrz dnej i zale nej. Na
przyk ad encja Szkoly_Dyrektorzy z prezentowanego wcze niej rysunku 2.6. zawiera
w ca o ci klucze g ówne encji Szkoly (SzkolyID) i Dyrektorzy (DyrektorzyID).
RELACJE 53
Prosz zauwa y , e jest to typowe w przypadku relacji typu wiele-do-wielu. Klucz
g ówny tabeli cznikowej zawsze sk ada si z kluczy g ównych dwóch pozosta ych
tabel. Dzi ki temu, e klucze g ówne tabeli nadrz dnej i zale nej s od razu widoczne
w tabeli cznikowej, mo emy bez wahania powiedzie , e jest to relacja identyfi-
kuj ca.
Relacje nieidentyfikuj ce s zdecydowanie bardziej rozpowszechnione. Mo na
je rozpozna po tym, e atrybuty klucza g ównego encji nadrz dnej s w encji za-
le nej atrybutami niekluczowymi. Je eli nie istnieje jaki wa ny powód do tworzenia
relacji identyfikuj cej, to wi kszo tworzonych w modelu relacji b dzie relacjami
nieidentyfikuj cymi.
Relacje opcjonalne i obowi zkowe
Ka da relacja w bazie danych musi zosta okre lona jako opcjonalna lub obowi z-
kowa. O relacjach obowi zkowych mo na my le jak o relacjach typu musi mie ,
podczas gdy relacje opcjonalne mo na okre la jako relacje mo e mie . Na przyk ad
je eli mamy encj Pracownik oraz encj Biuro, to ka dy pracownik musi mie swoje
biuro. Relacja cz ca te dwie encje opisuje biuro danego pracownika. W takiej sytu-
acji jest tworzona relacja nieidentyfikuj ca, a poniewa w encji Pracownik nie mo emy
wpisa warto ci NULL do klucza obcego identyfikuj cego biuro, okazuje si , e jest to
równie relacja obowi zkowa. Wskazuje ona, e ka dy pracownik ma przynajmniej
jedno biuro, a nawet je eli musi pracowa w innych biurach, to jedno z nich trak-
towane jest jako przypisane do niego.
Teraz zajmijmy si sytuacj , w której samochody s przypisywane do pracowników
firmy. Mo na j odzwierciedli w modelu danych, cz c z sob encje Pracownik
i Samochód. Jak mo na si domy li , pracownik mo e mie samochód, cho wcale
nie musi, co odpowiada definicji relacji opcjonalnej.
Liczno
W przypadku ka dej z opisywanych relacji podawali my jedynie jej ogólny rodzaj:
jeden-do-jednego, jeden-do-wielu lub wiele-do-wielu. Opis takiej relacji zawiera
liczb rekordów w encji nadrz dnej, wi zanych z pewn liczb rekordów w encji
zale nej. Chc c dok adniej wymodelowa faktyczn relacj cz c te dane, musimy
poda nieco wi cej informacji opisuj cych te zale no ci niezb dne jest okre lenie
liczno ci (ang. cardinality) danej relacji.
W przypadku relacji jeden-do-jednego jej liczno jest ju z góry narzucona.
Jednoznacznie stwierdzamy, e na ka dy rekord w encji nadrz dnej mo e przypada
dok adnie jeden rekord w encji zale nej. W sposób bardziej opisowy mo na powie-
dzie , e na ka dy rekord w encji nadrz dnej przypada zero lub jeden rekord w encji
zale nej. Je eli jednak chcemy zaznaczy , e w obu encjach zawsze musi by do-
k adnie jeden rekord, to opis liczno ci relacji powinien brzmie : na ka dy rekord
w encji nadrz dnej przypada dok adnie jeden rekord w encji zale nej. Liczno
[ Pobierz całość w formacie PDF ]