Tabele i niepowtarzalność

Kiedy tworzysz aplikacje bazy danych, każda tabela przedstawia odrębną jednostkę lub pro­ces występujący w rzeczywistym świecie. Będziesz tworzył tabele kontrolujące lu­dzi, wydarzenia, transakcje finansowe i przedmioty (np. produkty). Zgodnie z teorią rela­cyjną, musisz przechowywać wszystkie dane w tabelach (zasada 1.) oraz, że tabela skła­da się z unikatowych wierszy i kolumn (zasada 2.). Sposobem na zapewnienie uni­kal­ności każdej z zasad jest ustawienie klucza głównego dla każdego wiersza.

Klucz główny to pole lub grupa pól (mówimy wtedy o wielopolowym kluczu głów­nym), które jest unikatowym identyfikatorem tego wiersza. Klucz główny musi być uni­ka­to­wy. W przeciwnym bowiem wypadku dochodziłoby do naruszenia zasady 2. Ac­cess poz­­wala Ci uczynić pole kluczem głównym, poprzez nadanie mu wartości Klucz w wi­do­ku Projekt tabeli. Access sprawdzi wówczas, czy dane w tym polu są unikatowe i nie wy­stępują w nim duplikaty. Czasami, gdy przestrzegamy reguł handlowych, podanie uni­katowej wartości dla każdego wiersza może być trudne. Podczas projektowania systemu zarządzającego kontaktami, jako klucz możesz wybrać Naz­wisko, Telefon lub e-mail (pola takie powszechnie nazywane są „polami-kan­dy­da­ta­mi”). Ogólna zasada projektowania baz danych głosi, że klucz powinien być jak naj­prost­szy, unikatowy i jak najrzadziej zmieniany. Nazwisko może się zmieniać na skutek zawar­cia małżeństwa, rozwodu itp. Numery telefonów i adresy e-mail zmieniają się cią­gle. Dobrym kluczem byłby numer PESEL, ale co, gdy dana osoba nie jest obywatelem pol­skim? W tej sytuacji Access umożliwia Ci utworzenie pola Autonumerowanie, które sta­nie się polem klucza podstawowego. Autonumerowanie jest samogenerującą się war­toś­cią liczbową, która będzie wzrastać z każdym nowym rekordem. Istnieją dwa typy Autonumerowania:

• Wartości całkowite;

• Id replikacji lub GUID (używany w replikacji).

Istnieje kilka sposobów na manipulowanie Autonumerowaniem w apa­ra­cie Jet, co nie było możliwe we wcześniejszych wersjach Accessa. Mo­żesz teraz ustawić wartość, o jaką Autonumerowanie będzie przyrastać, a także sprawić, by było odliczane wstecz. Więcej szczegółów na ten te­mat znajdziesz w rozdziale 5. Mimo iż wartość, o jaką Autonume­ro­wa­nie przyrasta, może być kontrolowana, pamiętaj, że Autonumerowanie nie oznacza numeru rekordu.

Klucze obce i domeny

Klucz główny staje się bardzo ważny, gdy chcesz go użyć w innej tabeli. Można przechowywać wartość klucza głównego jednej tabeli, aby przedstawiać rekordy w innej tabeli. Wówczas mówimy o kluczu obcym, który bę­dzie podstawą opisanych w następnej części relacji. Przedstawiona na rysunku 3.2 ta­be­la trelContactInfo przechowuje dwa obce klucze: ContactID i ContactTypeID. ContactID to klucz główny tabeli tblContact, a ContactTypeID to klucz główny tabeli tlkpContactType.Gdy używasz kluczy obcych, będą się one zawsze znajdować w tej samej domenie. Do­me­ny są to zbiory wartości, z których pobierane są kolumny. Dobrym przykładem jest Stu­dentID. Jego domeną są wszystkie dostępne w systemie numery PESEL.

Relacje

Gdy definiujesz klucze główne i klucze obce, masz do czynienia z relacjami. Przez re­la­cje rozumiemy zasady obsługiwane na poziomie silnika bazy danych (patrz: Zasada 4. dr Codda). Access wyróżnia trzy różne typy relacji:

• relacja jeden-do-jednego;

• relacja jeden-do-wielu;

• relacja wiele-do-wielu.

Aby tworzyć relacje w Accessie, naciśnij znajdujący się w na pasku narzędzi przycisk Relacje lub wybierz Narzędzia⇒Relacje, aby otworzyć okno Relacje.

Relacja jeden-do-jednego

Dwie tabele łączy relacja jeden-do-jednego, gdy każdemu wierszowi z jednej tabeli przy­porządkowany jest co najwyżej jeden wiersz z drugiej tabeli.Ten typ relacji jest naj­rza­dziej spotykany, ponieważ w większości przypadków możesz powiązane informacje umiesz­czać w jednej tabeli. Jednakże, ze względów bezpieczeństwa, możesz zde­cy­do­wać, iż należy informacje rozdzielić na dwie tabele. Również skomplikowane transakcje finansowe zawierają wiele relacji jeden-do-jednego.

Relacja jeden-do-wielu

Najpopularniejszy typ relacji, relacja jeden-do-wielu, występuje wtedy, gdy tabela ma wie­le (lub nie ma w ogóle) powiązanych rekordów w drugiej tabeli. Czasami tabela po stronie „jeden” nazywana jest tabelą odnośnika. Za­zwy­czaj, tabele odnośnika zawierają informacje, które będą przekazywane do innych tabel (na przykład, nazwy województw lub kody pocztowe). Podczas adaptowania konwencji na­zewnictwa dobrze jest dla tabeli odnośnika użyć przedrostka tlkp.

Relacja wiele-do-wielu

O relacji wiele-do-wielu mówimy wówczas, gdy każdemu wierszowi z jednej tabeli od­po­wiada wiele wierszy w drugiej tabeli, a każdemu wierszowi z drugiej tabeli od­po­wia­da wiele wierszy w pierwszej. Jedynym sposobem na przedstawienie w Accessie relacji wie­le-do-wielu jest użycie tabeli „łączącej”, w której jako klucze obce znajdują się klu­cze główne obu tabel.

Podarkusze danych

Jedną z nowych opcji Accessa 2000 są podarkusze danych - nowy sposób przeglądania po­wiązanych danych w widoku arkusza danych. Podarkusze danych, są „poszerzonym” widokiem powiązanych danych. Podarkusze danych automa­tycz­nie odczytują relacje w bazie i wyświetlają powiązane tabele. Nie zawsze jest to naj­lep­szy sposób na przeglądanie powiązanych danych, tak jak to ma miejsce w przypadku przed­stawionej na rysunku 3.6 relacji wiele-do-wielu.

Aby zoptymalizować widok podarkuszy danych, możesz utworzyć kwerendę, która po­łą­czy dane z powiązanych tabel tak, by wyświetlone były opisy, a nie klucze obce. Nas­tęp­nie otwórz tabelę w widoku Projekt i spójrz na właściwości tabeli. W polu Nazwa podarkusza danych wybierz nazwę utworzonej kwerendy. Być może bę­dziesz również musiał ustawić właściwości podrzędnego i nadrzędnego pola łączącego, je­śli Access nie rozpozna ich automatycznie.
Zaawansowane kwerendy

• Kwerendy w Accesie 2000.

• Użycie kwerend.

• Właściwości kwerendy.

• Kwerendy podsumowujące.

• Użycie kwerend krzyżowych.

• Użycie kwerend parametrycznych.

• Kwerendy przekazujące.

• Kwerendy definiujące dane.

• Optymalizowanie kwerend.

Kwerendy są elementami napędowymi baz danych Accessa. Występują w kilku for­mach i rodzajach. Mogą być zapisywane w bazie (jak tabele) lub działać tylko w pa­mię­ci kom­putera. Do ich tworzenia można używać poleceń SQL lub graficznego interfejsu użyt­kownika nazywanego tabelą QBE. Kwerenda może zarówno przedstawiać dane w ta­kiej postaci, w jakiej występują w bazie, jak również przed wyświetleniem gru­po­wać je i przeliczać. Kwerenda Accessa może już przed uruchomieniem wiedzieć, co po­win­na wykonać lub zadawać użytkownikowi dodatkowe pytania. Kwerendy potrafią tak­że aktualizować dane, tworzyć i usuwać rekordy, a nawet zmieniać strukturę bazy. Kwe­rendy w Accessie mogą pracować z danymi przechowywanymi w plikach typu MDB, innych, przyłączonych do Accessa źródłach danych, a nawet bazach danych typu kli­ent-serwer (np. Oracle i Microsoft SQL Server). Są one najszybszym i naj­pew­niej­szym sposobem efektywnej interakcji z danymi w relacyjnej bazie danych.

Rozdział ten poświęcony jest zaawansowanym odmianom tego potężnego narzędzia.

Kwerendy w Accesie 2000

Dokładna konstrukcja bazy danych w połączeniu z możliwościami, jakie dają kwe­ren­dy, umożliwiają zaspokojenie części najprostszych, codziennych potrzeb w zarządzaniu da­ny­mi. Jednocześnie mogą pomóc w rozwiązaniu najbardziej złożonych problemów, gdyż relacyjna struktura pozwala na logiczne grupowanie danych. Dzięki temu, po­mię­dzy powiązanymi obiektami można tworzyć użyteczne połączenia. W relacyjnej bazie da­nych masz wgląd w te dane, których w danym momencie potrzebujesz.Weźmy za przykład rachunek telefoniczny. Raz w miesiącu operator sieci telefonicznej przy­syła Ci rachunek za swoje usługi, a jeśli sobie tego zażyczysz - szczegółowy wy­kaz rozmów. Wykaz ten zawiera wszystkie informacje o przeprowadzonych w po­przed­nim mie­siącu rozmowach telefonicznych: datę, godzinę, numer telefonu osoby, do któ­rej dzwo­niłeś, czas trwania rozmowy, ilość naliczonych impulsów oraz całkowity koszt roz­mowy. To bardzo dużo informacji, jednakże na podstawie samego wykazu trudno jest odpowiedzieć na najbardziej nawet podstawowe pytania. Dużo wygodniej byłoby móc połączyć go z książką adresową. Gdyby to było możliwe, mógłbyś dokładnie stwier­dzić, do kogo dzwoniłeś, kiedy to było i ile Cię ta rozmowa kosztowała. Mógłbyś wów­czas obliczyć, ile pieniędzy wydałeś na rozmowy z pracownikami danego klienta i na jaką kwotę należy poszczególnych klientów obciążyć.

Mogłoby się wydawać, że takiej obróbki danych można dokonać przy użyciu innych na­rzę­dzi niż relacyjna baza danych. Jednakże z prawidłowo zaprojektowaną bazą danych ob­rób­ka ta będzie banalnie łatwa, wiarygodna i szybka.

Użycie kwerendy

Podobnie jak w przypadku wszystkich innych obiektów baz danych Accessa możesz sto­sować nazwy o długości nie przekraczającej 255 znaków. Również wszystkie kon­wen­cje nazewnictwa używane w przypadku pozostałych obiektów mają zastosowanie do kwerend. Okno Właściwości zawiera także informacje o typie danej kwerendy. Mo­żesz tam również znaleźć jej opis. Jest to bardzo ważna właściwość. Staranny projektant baz danych powinien z niej korzystać tak często, jak tylko to możliwe. Porządny opis umoż­liwi Ci stwierdzenie, jaką czynność dana kwerenda miała wykonać. Również inni pro­gramiści docenią wagę opisu, gdy przyjdzie im pracować z utworzoną przez Ciebie kwe­rendą. Okno Właściwości zawiera także datę utworzenia kwerendy oraz datę os­tat­niej modyfikacji, automatycznie aktualizowaną przez Access. Zgodnie z domyślnym usta­wieniem właścicielem kwerendy jest osoba, która ją utworzyła. Ma to znaczenie dla za­bezpieczeń bazy (temat ten został szczegółowo omówiony w rozdziale 23., „Bez­pie­czeń­stwo”). Na dole okna znajdują się dwa pola wyboru. Zaznaczenie pola Ukryty spo­wo­duje, iż obiekt ten nie będzie widoczny dla użytkowników w głównym oknie bazy danych. Dzięki temu będziesz mógł zapobiec przypadkowym zmianom tego obiektu.

Pole wyboru Replikowalny informuje, czy dany obiekt jest elementem schematu re­pli­ka­cji, który przygotowałeś dla bazy danych. Mówimy, że obiekt jest replikowalny, gdy po­przez operację replikacji jest modyfikowany przez inny obiekt, najczęściej bardziej aktual­ną wersję samego siebie.

	Innym sposobem na ukrycie kwerendy przed uczestnikami jest umie­szcze­nie na początku jej nazwy liter USYS (np. USYS_myquery). Aby prze­glądać takie obiekty, musisz w menu Narzędzia otworzyć okno dia­lo­gowe Opcje i zaznaczyć pole wyboru Obiekty systemowe.
	Microsoft również ukrywa różne obiekty, używając do tego celu przed­rost­ka MSYS. Nie możesz dopuścić, by użytkownicy uzyskali dostęp do tych tabel systemowych, bo ich zmiana może doprowadzić do usz­ko­dzenia bazy. Również programiści powinni unikać używania ich, gdyż Microsoft nie gwarantuje umieszczenia ich w kolejnej wersji. Upew­nij się, że tabele systemowe są ukryte, zanim przekażesz bazę do rąk użytkowników.

Właściwości kwerendy

Ponieważ zachowanie kwerendy zależy bezpośrednio od ustawień właściwości, waż­nym jest zrozumienie, czym te właściwości są i jak funkcjonują. Tak więc, zanim przej­dzie­my do zaawansowanych opcji kwerend, przyjrzyjmy się podstawowym kwerendom i okreś­le­niom, jakich będziemy używać podczas projektowania bardziej zaawanso­wa­nych kwerend.

52

Część I ♦ Projektowanie bazy danych

4

Rozdział 3. ♦ Projekt bazy danych i normalizacja

---