90 2. MODELOWANIE BAV. DANYCH
się coś jako bazę danych, to by utworzyć efektywny klucz w ważnej klasie, często wychodzi się poza obszar rzeczywistości. Na przykład firmy zazwyczaj nadają swoim pracownikom identyfikatory, które są bardzo starannie wybierane w celu uzyskania jednoznaczności. Jedynym tego powodem jest tu konieczność odróżniania pracowników w bazie danych, nawet jeśli jest kilku pracowników o takim samym nazwisku. A zatem atrybut utworzony z identyfikatora pracownika może być dobrym kluczem w bazie.
W firmach w USA każdy pracownik ma przydzielony również identyfikator ubezpieczenia społecznego. Jeśli w bazie danych występuje atrybut zawierający ten identyfikator, to może on służyć jako klucz pracownika. Nie ma nic złego w tym, że wśród atrybutów jest kilka wyborów' klucza w danej klasie, jak to jest w przypadku klasy pracowników- mających zarówno identyfikator pracownika, jak i numer ubezpieczenia społecznego.
Koncepcja tworzenia specjalnego atrybutu, który' pełni funkcje klucza, jest dość popularna. Oprócz identyfikatorów pracowniczych stosuje się na przykład identyfikatory' studentów, po to by można ich było odróżniać na uczelni. Istnieją także numery prawa jazdy kierowców oraz numery' rejestracyjne pojazdów, po to by można było identyfikować pojazdy oraz. kierowców; jest to potrzebne zwłaszcza w wydziałach komunikacji. Czytelnicy z pewnością potrafią podać jeszcze dużo innych przykładów- atrybutów', który ch głównym celem jest pełnienie funkcji klucza.
□
W języku ODL, aby zadeklarować, że dany atrybut lub zbiór atrybutów stanowi klucz, stosujemy słowo kluczowe key albo keys (wszystko jedno które), po którym wypisuje się listę atrybutów tworzących klucz. Jeśli klucz tworzy więcej atrybutów niż jeden, to ich lista musi być ujęta w nawiasy okrągłe. Deklaracja klucza musi wystąpić zaraz po deklaracji intcrfacc, przed otwierającym nawiasem klamrowym, jakimkolwiek atrybutem czy związkiem. Sama deklaracja jest ujęta w naw iasy okrągłe.
PRZYKŁAD 2.25
W klasie Film kluczem ma być para atrybutów tytuł i rok. Aby zadeklarować ten fakt, wiersz 1 z rys. 2.6 zastępujemy przez:
interfaco Film
(key (tytuł, rok))
{
zamiast słowa kluczowego key może wystąpić słowo keys, mimo że deklarujemy tylko jeden klucz.
Analogicznie, jeśli kluczem klasy Gwiazda jest nazwisko, to przed pierwszym otwierającym nawiasem klamrowym, w wierszu 8 z rys. 2.6 dopisujemy:
{key nazwisko)
□
Kluczy może być wiele i mogą powstawać z różnych zbiorów atrybutów. Wówczas po słowie kluczowym key(s) umieszcza się opisy tych kluczy oddzielane przecinkami. Definiując klucze złożone z więcej niż jednego atrybutu, trzeba jak zwykle ujmować te atrybuty w nawiasy, po to by odróżnić, który atry but jest po prostu kluczem, a który tylko elementem klucza.
PRZYKŁAD 2.26
Jako przykład sytuacji, w której warto mieć więcej niż jeden klucz, rozpatrzymy klasę Pracownik, jednak nie przedstawimy tutaj jej pełnego zestawu atrybutów i związków. Rozważmy dwa atrybuty tej klasy: pracID - identyfikator pracownika w firmie oraz usNu numer ubezpieczenia społecznego. Deklaracja faktu, że każdy z tych atrybutów jest samodzielnym kluczem, przedstawia się następująco:
(key pracID, usMu)
Ponieważ nie ma nawiasów wokół listy atrybutów, więc każdy z dwóch atrybutów w deklaracji jest potraktowany w języku ODL {pracID, usNujjako samodzielny klucz. Gdyby parę tych atrybutów ująć w nawias, to lista zostałaby potraktowana jako jeden klucz złożony z dwóch atrybutów. Z zapisu:
{key (pracID, usNu))
wynika, że dwaj różni pracownicy nie mogą mieć jednocześnie takich samych i identyfikatora i numeru ubezpieczenia społecznego, ale któryś z tych atrybutów może się powtórzyć u dwóch pracowników.
□
Pojęcie klucza w przypadku zbioru encji jest dokładnie takie samo jak w przypadku klas, ponieważ zbiór encji jest odpowiednikiem klasy. Jeśli jakiś zbiór atrybutów tworzy klucz dla zbioru encji, to w dwóch różnych encjach nie mogą występować takie same wartości wszystkich tych atrybutów. W diagramach związków encji atrybuty tworzące klucz zbioru encji oznacza