[ Pobierz całość w formacie PDF ]

nazywane są po angielsku "inner joins". W języku polskim nazywa się to terminem "łączenie" lub "złączenie"
wewnętrzne (tabel). Jest to jeden z rodzajów łączeń tabel w kwerendzie, nazywany też czasami "equijoin" -
uwzględniane są rekordy zawierające pola o równej zawartości. Kwerenda listująca klasy i ich gospodarzy nie
uwzględni klasy, której nie przypisany będzie gospodarz (klasa ta zostanie pominięta). Po to, by kwerenda
uwzględniała takie przypadki czyli wypisywała także nazwy tych klas, które nie mają gospodarzy, trzeba
zastosować inny rodzaj łączenia tabel tzw. łączenia zewnętrzne ('outer joins").
Strona 29 z 44
O kluczach
Klucze w naszych tabelach są na swój sposób uporządkowane: wiekszość uczniów należących do jednej
klasy ma jako klucze kolejne liczby naturalne. Oczywiście nie jest wymóg, a jedynie odzwierciedlenie sposobu
wprowadzania rekordów do tabel kursu przez jego autorów (ułatwiało to przygotowanie kursu). Jeśli pewne
rekordy zostaną z tabeli usunięte, powstaną w tych estetycznych sekwencjach kolejnych liczb dziury, ale nie
wpłynie to w niczym na działanie systemu. W rekordzie wstawianym do tabeli musi być klucz nowy, a
przynajmniej różny od innych (może to być np. klucz pozostały po usuniętym rekordzie). Przy 30 czy nawet 300
uczniach określenie nowego klucza 'na oko' jest dość łatwe. Gdy rekordów w tabeli będzie kilka albo
kilkadziesiąt tysięcy, sprawa się komplikuje. Co więcej, to jest kurs, z tabelami przykładowymi, niewielkimi, w
dodatku niezmienianymi. W realnych komercyjnych bazach danych tabele mają tysiące rekordów, które
wprowadza się lub aktualizuje nieustannie i nieustannie też się je usuwa, albo w ogóle, albo odpowiednio je
archiwizując i wszystko to realizowane jest bez udziału człowieka. Na ogół zatem przydzielanie kluczy
wstawianym rekordom automatyzuje się (innego wyjścia zresztą praktycznie nie ma) - RDBMS sam generuje
unikalny klucz i o jego wartości informuje użytkownika wstawiającego rekord do tabeli - można tej wartości
użyć potem przy tworzeniu relacji (jak to jest realizowane, powiemy w jednym z następnych tematów). Zauważ:
jakkolwiek w kwerendach podaje się nazwę pola zawierającego klucz, nigdzie, tj. w żadnej kwerendzie, nie
podaje się jego wartości explicite Istotna jest nie sama konkretna wartość klucza, ale zgodność wartości kluczy
(obcego i podstawowego).
Klucze nie muszą być i nie zawsze są liczbami naturalnymi. Jeśli klucz ma np. jednoznacznie
identyfikować osobę, to teoretycznie jako klucza można by użyć kodu PESEL, który jak wiadomo, dla każdego
Polaka jest inny. Ale taki klucz miałby wady:
musiałby być wprowadzany do bazy przez użytkownika (nie automatycznie), a to jest zawsze okazja do
popełnienia błędu,
klucz PESEL (11 znaków) wprowadzany do tabel zrelacjonowanych jako klucz obcy zajmowałby więcej
miejsca niż klucz liczbowy,
czas wykonywania kwerend z porównywaniem takich kluczy zwiększyłby się (porównywanie ciągów znaków
trwa dłużej niż porównywanie liczb całkowitych), co mogłoby być znaczące, jeśli baza znajdowałaby się na
serwerze w Sieci, do którego mogłoby być wiele odwołań jednocześnie.
Mogą być też klucze łączone: rekord identyfikowany jest nie przez jedno pole, ale przez dwa -
jakkolwiek żadne z nich nie jest unikalne i może się powtarzać, wspólnie tworzą sekwencję niepowtarzającą się.
W naszej przykładowej bazie danych ten sposób identyfikowania rekordów można by teoretycznie zastosować
wobec klas. Np. nazwa klasy 'Olimpijska' (w klasie są laureaci olimpiad szkolnych) mogłaby się powtarzać, ale
na danym poziomie byłaby zawsze tylko jedna klasa o takiej nazwie - klasa byłaby zatem identyfikowana
jednoznacznie przez parę pól Nazwa i Poziom. Tworząc taki klucz można by zrezygnować z wprowadzania do
tabeli Klasy pola Id. Ale to zysk pozorny. Takie rozwiązanie byłoby dość kłopotliwe w praktyce - w każdym
rekordzie ucznia trzeba by przechowywać nazwę i poziom klasy, do której jest przypisany, a każda zmiana w
tych wartościach wymagałyby zmian we wszystkich rekordach uczniów z tej klasy (komplikowałyby się również
kwerendy).
O nazwach kluczy:
Dwa klucze występujące w tabeli Uczniowie, a także Klasy (klucz podstawowy i klucz obcy), muszą być inaczej
nazwane (nazwy kolumn w tabeli muszą być różne). Na klucz klasy w rekordzie ucznia można było użyć nazwy
Klasa, ale jest zbyt ogólne (niewiadomo byłoby, jak opisana jest klasa, przez nazwę czy przez klucz) - Klasa_Id
sugeruje, że jest to klucz i informuje, z jaką tabelą rekord ucznia jest związany. Podobnie pole gospodarza w
rekordzie Klasy można było nazwać Gospodarz, ale - z punktu widzenia relacji - to mało informujące. Uczeń_Id
określa i charakter pola, i tabelę, z której klucz pochodzi.
Jest to jedna z konwencji nazewniczych, jakie się stosuje. Ma wady: np. w rekordzie klasy nie wiadomo, po co
faktycznie jest Uczeń_Id (bardziej informująca byłaby nazwa Gospodarz_Uczeń_Id, ale z kolei jest zbyt długa).
Można też zastanawiać się, czy na klucze obce powinna być używana nazwa pojedyncza czy mnoga (Uczeń_Id
czy Uczniowie_Id, Klasa_Id czy Klasy_Id) albo czy Id nie powinno być w nazwie pola na pierwszym miejscu
(Id_Uczeń, Id_Klasa). Konwencje mogą być oczywiście różne - podstawowym wymogiem jest konsekwencja: jak
się już jakąś konwencję przyjmie, należy się jej trzymać.
Strona 30 z 44
Zalety modelu relacyjnego
Dzięki kluczom i relacjom:
Zaleta ogólna: opis zasad, na których jest oparta struktura bazy danych, jest prosty i klarowny i da sie ująć w
dwóch czy trzech zdaniach. To w istocie jedna z największych, jeśli nie największa zaleta modelu relacyjnego
(zwłaszcza w konfrontacji z innymi wcześniej stosowanymi modelami baz danych jak hierarchiczny czy
sieciowy, patrz słownik), chociaż niezbyt często artykułowana. Wszystkie relacje są opisane w ten sam sposób i
odnosi się to do wszystkich tabel, także systemowych, związanych z samym działaniem systemu RDBMS. Baza
danych może być bardzo duża i złożona, ale każdy związek między tabelami jest opisany tak samo. [ Pobierz całość w formacie PDF ]