08. Klucze.txt

(35 KB) Pobierz
#170
8. Klucze

Fakt, sam w sobie, jest niczym. Fakt jest użyteczny jedynie dla przekazu, którego jest częciš, lub dla dowodu, któremu ma służyć
Claude Bernard
======================================

W poprzednich rozdziałach okrelilimy wszystkie tematy, jakie powinny zostać zawarte w bazie danych, oraz przypisalimy każdej z tabel odpowiednie pola, definiujšc tym samym jej strukturę. Ponadto poddalimy struktury tabel procesowi kontrolnemu w celu potwierdzenia ich poprawnoci. Kolejny etap procesu projektowania bazy danych polega na przypisaniu każdej tabeli odpowiednich kluczy. Jak wkrótce się dowiesz, istniejš różne rodzaje kluczy, z których każdy pełni ważnš rolę w strukturze relacyjnej bazy danych. Na obecnym etapie procesu projektowania zajmiemy się zdefiniowaniem wszystkich rodzajów kluczy - z wyjštkiem jednego; ten ostatni zostanie dodany podczas tworzenia relacji między tabelami.

Dlaczego klucze sš ważne

Klucze pełniš ważnš funkcję w strukturze bazy danych z następujšcych powodów:
       Umożliwiajš identyfikację każdego rekordu w tabeli. Pamiętaj, że tabele reprezentujš konkretne tematy, czyli obiekty (osoby, miejsca lub przedmioty) bšd zdarzenia (co, co ma miejsce w okrelonym czasie). Definicję tę można rozszerzyć stwierdzajšc, że tabela reprezentuje pewien zbiór podobnych do siebie obiektów lub zdarzeń. Każdy rekord opisuje pojedynczy element tego zbioru. Potrzebny jest nam więc mechanizm, który umożliwiałby jednoznacznš identyfikację dowolnego elementu. Takim włanie mechanizmem sš klucze.
       Umożliwiajš wprowadzanie i egzekwowanie różnych rodzajów integralnoci danych. Klucze sš podstawowym składnikiem integralnoci na poziomie tabel oraz na poziomie relacji. Ich obecnoć gwarantuje, że każda tabela będzie składać się z unikatowych rekordów, a pola łšczšce dwie tabele zawsze będš posiadać identyczne wartoci.
#172
      Umożliwiajš definiowanie relacji. Jak dowiesz się z rozdziału 10, do połšczenia dwóch odrębnych tabel wykorzystuje się klucze.
Właciwe zdefiniowanie kluczy w każdej z tabel zagwarantuje poprawnoć ich struktur, umożliwi ograniczenie iloci nadmiarowych danych do minimum oraz zapewni stabilnoć relacji między tabelami.

Definiowanie kluczy

Twoje zadanie polega teraz na zdefiniowaniu odpowiednich kluczy w projektowanej bazie danych. Funkcja, jakš dany klucz pełni w tabeli, jest zdeterminowana przez jego typ. Istniejš trzy podstawowe typy kluczy: kandydujšcy, podstawowy oraz obcy. W tym rozdziale zajmiemy się opisywaniem dwóch pierwszych typów. Klucze obce będš szerzej omawiane w rozdziale 10.

Klucze kandydujšce

Pierwszym rodzajem kluczy, jakim się zajmiemy, sš klucze kandydujšce. Każda tabela powinna posiadać przynajmniej jeden taki klucz. Ze zbioru dostępnych kluczy kandydujšcych wybierzemy póniej jeden klucz podstawowy. Ogólnie rzecz bioršc, klucz kandydujšcy to pole lub zestaw pól, które jednoznacznie identyfikujš pojedynczš instancję tematu danej tabeli. Aby które pole mogło zostać oznaczone jako klucz kandydujšcy, musi spełniać wszystkie poniższe kryteria:

Cechy klucza kandydujšcego

      Musi jednoznacznie identyfikować każdy rekord w tabeli, do której należy. Pamiętaj, że rekord reprezentuje pojedynczš instancję tematu zawierajšcej go tabeli. Ten warunek umożliwia odwołanie się do interesujšcego nas rekordu oraz gwarantuje, że tabela nie będzie zawierać rekordów zwielokrotnionych.
      Musi zawierać unikatowe wartoci. Wybierajšc pole, którego wartoć nie powtarza się w żadnych dwóch rekordach, gwarantujesz unikatowoć każdego rekordu
, w ramach tabeli. Pamiętaj, że w przypadku klucza składajšcego się z większej liczby pól, żadne z nich samo w sobie nie musi zawierać unikatowych wartoci - to połšczenie wartoci tych pól powinno być niepowtarzalne.
      Nie może zawierać wartoci zerowej. Jeli wartoć klucza kandydujšcego w którym z rekordów jest równa Null, wówczas nie ma sposobu na odwołanie się do tego rekordu. Pamiętaj, że wartoć zerowa w rzeczywistoci oznacza brak wartoci.
      Nie może być polem segmentowym. Widziałe już, na czym polegajš problemy zwišzane z takimi polami, więc prawdopodobnie zdajesz sobie sprawę, że użycie tego rodzaju pola w charakterze klucza kandydujšcego byłoby złym pomysłem.
#173
       Składa się z minimalnej liczby pól niezbędnej do uzyskania niepowtarzalnoci. Klucz kandydujšcy może się składać z kilku odrębnych pól (traktowanych łšcznie), jeżeli każde z nich przyczynia się do niepowtarzalnoci wartoci klucza. Pamiętaj jednak, że złożone klucze kandydujšce mogš być trudne do ogarnięcia i majš tendencje do sprawiania problemów w przeprowadzaniu operacji na danych. Staraj się wiec ograniczać iloć pól do minimum.
      Jego wartoć nie może być w żadnym stopniu opcjonalna. Klucz kandydujšcy musi zawsze posiadać wartoć i zasada ta dotyczy każdego ze składajšcych się nań pól.
      Musi bezporednio okrelać wartoć każdego pola w tabeli. Każde pole w analizowanej tabeli powinno być funkcyjnie zależne od wartoci klucza kandydujšcego.
      Jego wartoć powinno modyfikować się jedynie w wyjštkowych przypadkach. Jeżeli nie masz po temu bardzo ważnych powodów, nie powiniene nigdy zmieniać raz ustalonej wartoci klucza kandydujšcego. Nie przemylana zmiana wartoci klucza może zaburzyć jego zgodnoć z poprzednimi kryteriami.
Definiowanie kluczy kandydujšcych jest stosunkowo proste: poszukaj pola lub zbioru pól, które spełniajš przedstawione wyżej kryteria. Możliwe, że znajdziesz więcej niż jeden klucz kandydujšcy. Czasem dobrze jest wpisać do tabeli przykładowe dane (tak jak robiłe to w poprzednim rozdziale).
Spróbuj okrelić, które pola w tabeli na rysunku 8.1 spełniajš kryteria klucza kandydujšcego. Pamiętaj, że każdy klucz musi spełniać wszystkie podane warunki.

Pracownicy

Numer polisy ubezp. Imię prac. Nazwisko prac. Adres miejski prac. Miasto prac. Stan prac.	Kod pocztowy prac. Telefon domowy prac.

456-91-9938	Kendra	Bonnicksen	1204BryantRoad	Seattle	WA	98157	363-9948
386-11-2231	Katherine	Erlich	101 C Street, m. 32	Bellevue	WA	98046	322-6992
501-48-0039	Timothy	Ennis	7402 Kingman Drive	Redmond	WA	98115	527-4992
116-93-1299	Shannon	McLain	41 41 Lakę City Way	Seattle	WA	98136	336-5992
478-02-1129	Susan	McLain	2100MineolaAvenue	Seattle	WA	98115	572-9948
655-92-5583	Estela	Pundt	101 C Street, m. 32	Bellevue	WA	98046	322-6992
601-22-1734	Timothy	Sherman	66NE120th	Bothell	WA	98216	522-3232

Rysunek 8.1. Znajd klucze kandydujšce w tabeli Pracownicy"

Przeglšdajšc tabelę, odkrywasz pięć potencjalnych kluczy kandydujšcych: Numer polisy ubezp.", Nazwisko prac.", Imię prac." oraz Nazwisko prac.", Kod pocztowy prac." i Telefon domowy prac.". Dalsza analiza prowadzi jednak do odrzucenia niektórych propozycji. Pamiętaj, że jeli które pole (lub zbiór pól) nie spełnia
#174
chociaż jednego kryterium klucza kandydujšcego, zostaje ono automatycznie zdyskwalifikowane.
Po dokładniejszej analizie wycišgasz następujšce wnioski:
       Numer polisy ubezp." zostaje przyjęty. Pole to odpowiada wszystkim kryteriom klucza kandydujšcego.
       Nazwisko prac." zostaje odrzucone ze względu na powtarzajšce się wartoci. Jak wiesz, wartoci klucza kandydujšcego muszš być unikatowe. W tym przypadku zachodzi możliwoć wielokrotnego wystšpienia tego samego nazwiska.
       Imię pracownika" i Nazwisko pracownika" zostajš przyjęte. Jeli wartoci obu tych pól potraktujemy jako jednš całoć, wówczas umożliwiajš one jednoznacznš identyfikację każdego rekordu w tabeli. Pomimo iż zarówno imię, jak i nazwisko mogš się powtarzać, jednoczesne powtórzenie obu tych wartoci jest mało prawdopodobne.
       Kod pocztowy prac." zostaje odrzucony ze względu na powtarzajšce się wartoci. Wartoci tego pola z pewnociš będš się powtarzać, ponieważ wielu pracowników może mieć identyczny kod pocztowy.
       Telefon domowy prac." zostaje odrzucony ze względu na możliwoć wystšpienia powtarzajšcych się wartoci. Pole to byłoby dobrym kluczem kandydujšcym, gdyby nie fakt, że organizacja może zatrudniać kilka osób z tej samej rodziny, a pracownicy dzielšcy ze sobš mieszkanie majš ten sam numer telefonu, co da się zauważyć oglšdajšc przykładowe dane.
Można więc stwierdzić, że tabela Pracownicy" zawiera dwa klucze kandydujšce: Numer polisy ubezp." oraz połšczenie pól Imię prac." i Nazwisko prac.".
Aby oznaczyć pola składajšce się na klucze kandydujšce, wpisz obok ich nazw litery KK". Jeli dany klucz składa się z dwóch lub większej iloci pól, wówczas okrela się go mianem złożonego klucza kandydujšcego. W takim wypadku obok nazw składajšcych się nań pól dopisz ZKK". Jeli dana tabela zawiera więcej niż jeden złożony klucz kandydujšcy, oznacz każdy z nich odpowiedniš cyfrš: ZKKl", ZKK2" itp. Spróbujmy teraz oznaczyć klucze kandydujšce w tabeli Pracownicy". Efekt tej procedury widać na rysunku 8.2.
Przyjrzyjmy się teraz tabeli na rysunku 8.3 i spróbujmy odszukać w niej klucze kandydujšce. Na pierwszy rzut oka wydaje się, że tabela ta zawiera cztery potencjalne klucze kandydujšce: Nazwa częci", Model", połšczenie Nazwy częci" i Modelu" oraz połšczenie Producenta" i Nazwy częci". Wnikliwa analiza prowadzi jednak do następujšcych wniosków:
175
Struktury tabel

Pracownicy	KK
Numer polisy ubezp.
Imię prac.		ZKK.
Nazwisko prac.	ZKK
Adres miejski prac.
Miasto prac.
Stan prac.
Kod pocztowy prac.
Telefon domowy prac.

Rysunek 8.2. Oznaczanie kluczy kandydujšcych w tabeli Pracownicy"

Częci

Nazwa częci	Model	Producent	Cena detaliczna
Rama Shimka XT	XT-113	Shimka Inc.	199.95
Uchwyty hamulcowe Faust	BU45	Faust USA	53.73
Pompka MiniMite		MiniMite	35.00
Bagażnik Hobo		Hobo Bike Co.	59.00
Pedały Diablo	Mtn-A26	Diablo Sports	129.50
Siodełko Shimka	SP-100		37.95
Uchwyty hamulcowe Faust	BL/60...
Zgłoś jeśli naruszono regulamin