Microsoft Access relacyjna (?) baza danych

Transkrypt

1 Microsoft Access relacyjna (?) baza danych 1. Informacje ogólne Microsoft Access jest prawdziwie zaawansowanym i profesjonalnym programem baz danych, dostępny równieŝ dla niedoświadczonych uŝytkowników. Microsoft Access nie jest, jak często się mylnie uwaŝa, bazą danych, lecz systemem zarządzającym bazą danych (DBMS Database Managment System), za pomocą którego moŝna tworzyć i administrować bazy danych. Access naleŝy przy tym do systemów zarządzania relacyjnymi bazami danych. Oznacza to, Ŝe poszczególne tabele mogą być ze sobą powiązane. Za pomocą programu Microsoft Access moŝna zarządzać wszystkimi niezbędnymi informacjami uŝywając jednego pliku bazy danych. W pliku takim moŝna dzielić dane na odrębne części zwane tabelami. Za pomocą formularzy elektronicznych moŝna oglądać, dodawać i aktualizować dane w tabelach; za pomocą kwerend moŝna znajdować i pobierać tylko te dane, które są rzeczywiście aktualnie niezbędne; za pomocą raportów moŝna analizować i drukować dane w określonym przez siebie układzie. Pomimo tego Ŝe wszystkie obiekty bazy danych znajdują się w jednym pliku istnieje moŝliwość importowania/eksportowania pojedynczych tabel. Najlepiej jest przechowywać dane tworząc po jednej tabeli dla kaŝdego typu informacji, które mają być analizowane. Dane z róŝnych tabel moŝna później łączyć razem w kwerendach, formularzach lub raportach naleŝy w tym celu zdefiniować relacje między tabelami. Architektura pakietu Access - program główny: łączy funkcje: o programu dla projektanta o interakcyjnego narzędzia do operowania danymi o interpretera wykonującego gotowe aplikacje runtime i generator dyskietek instalacyjnych (w pakiecie Access Developer's Kit) W MS Access istnieje moŝliwość korzystania z serwerów SQL przez ODBC (Open Database Connectivity) oraz moŝliwość udostępniania własnych danych przez ODBC ( np. dla Visual Basica, Visual C++). Programowanie w Visual Basic for Application jest niezwykle proste co nierzadko zachęca projektantów do tworzenia za pomocą Accessa małych systemów baz danych: do uŝytku prywatnego lub dla małych biur. Strona 1 z 52

2 2. Obiekty bazy danych MS Access 1.Tabele Tabela jest zbiorem danych dotyczących określonego tematu, jak produkty i dostawcy. UŜywanie oddzielnych tabel dla kaŝdego tematu eliminuje duplikowanie danych co czyni przechowywanie danych bardziej efektywnym i eliminuje błędy wprowadzania danych. Tabele organizują dane w kolumnach (zwanych polami) i w wierszach (zwanych rekordami). 2. Formularze Formularzy moŝna uŝywać w wielu zastosowaniach. Większość informacji zawartych pochodzi z odpowiedniego źródła rekordów. Pozostałe informacje przechowywane są w projekcie formularza. Za pomocą formularzy moŝna wpisywać dane, przeglądać wpisane informacje, drukować zawartość bazy i sterować działaniem programu. NiezaleŜnie od wyglądu i przeznaczenia formularze maja wspólna cechę - słuŝą uporządkowaniu i ujednoliceniu danych wprowadzanych przez wypełniającego formularz. Z drugiej strony osoba wypełniająca formularz równieŝ ma ułatwioną pracę - nie musi bowiem wprowadzać informacji bezpośrednio do tabeli i obserwować gęstwiny kolumn i rekordów. Strona 2 z 52

3 3. Kwerendy Termin ten powstał z angielskiego słowa query. Jego polskim odpowiednikiem jest zapytanie. Za pomocą kwerend moŝna wydawać Accessowi polecenia przeszukania bazy danych i udzielenia odpowiedzi na zadane pytanie. Kwerend moŝna uŝywać do wyświetlania, zmiany i analizy danych. MoŜna ich teŝ uŝywać jako źródła rekordów dla formularzy i raportów. Większość informacji zawartych w raporcie pochodzi z odpowiedniego źródła rekordów: tabeli, kwerendy lub wyraŝenia SQL. Pozostałe informacje są przechowywane w projekcie raportu. 4.Raporty Raport jest wygodnym sposobem prezentacji danych w postaci wydrukowanej. UŜytkownik ma pełną kontrolę nad rozmiarem i wyglądem wszystkich elementów raportu, dzięki czemu moŝe wyświetlać dane w Ŝądany sposób. Strona 3 z 52

4 5. Makra Makro jest akcją lub zestawem akcji, z których kaŝda wykonuje określoną operację, taką jak otwarcie formularza lub wydrukowanie raportu. Makra pomagają zautomatyzować często wykonywane zadania. MoŜna na przykład uruchamiać makro drukujące raport, gdy uŝytkownik klika przycisk polecenia. Makropolecenia umoŝliwiają pisanie prostych programów, pozwalających na uproszczenie i zautomatyzowanie pracy z bazą danych. 6. Moduły Moduł jest zbiorem deklaracji i procedur języka Visual Basic for Applications przechowywanych razem jako jedna całość. Moduły maja takie samo przeznaczenie, jak Makropolecenia, cechują je jednak duŝo większe moŝliwości. Są stosowane tam, gdzie makropolecenia nie wystarczają. Istnieją dwa podstawowe typy modułów: moduły klasy i moduły standardowe. KaŜda procedura w module moŝe być procedurą typu Function lub procedurą typu Sub. Moduły klasy Moduły formularzy i moduły raportów są modułami klasy związanymi z określonym formularzem lub raportem. Moduły formularza i raportu często zawierają procedury zdarzeń, które są uruchamiane w odpowiedzi na zdarzenie formularza lub raportu. Procedur zdarzeń moŝna uŝywać do sterowania działaniem formularzy i raportów oraz ich odpowiedziami na akcje uŝytkownika, takie jak np. kliknięcie przycisku polecenia. Moduły standardowe Moduły standardowe zawierają ogólne procedury, które nie są związane z Ŝadnym innym obiektem, oraz często uŝywane procedury, które moŝna uruchamiać z dowolnego miejsca w bazie danych Strona 4 z 52

5 3. Projektowanie bazy danych Zanim wykorzystamy programu Microsoft Access do budowania tabel, formularzy i innych obiektów, które złoŝą się na bazę danych, naleŝy poświęć trochę czasu na zaprojektowanie bazy danych. Dobry projekt jest podstawą utworzenia bazy danych, która pozwoli na szybkie, dokładne i skuteczne wykonywanie zamierzonych celów. Oto podstawowe kroki w projektowaniu bazy danych: 1. Określenie celu, któremu ma słuŝyć baza danych Pierwszym krokiem projektowania bazy danych programu Microsoft Access jest określenie celu, któremu ma słuŝyć baza i sposobu jej uŝywania. Konieczne jest określenie jakich informacji ma dostarczyć baza danych. Na tej podstawie moŝna określić, jakie zagadnienia będą analizowane w bazie danych (tabele) i jakie informacje mają określać kaŝde zagadnienie (pola w tabelach). 2. Określenie tabel, które znajdą się w bazie danych Określenie tabel moŝe być najtrudniejszym etapem procesu projektowania bazy danych. Powodem tego jest fakt, Ŝe wyniki, których ma dostarczyć baza danych - raporty gotowe do wydrukowania, formularze przeznaczone do wykorzystania, pytania, na które trzeba odpowiedzieć - nie zawsze zawierają bezpośrednie wskazówki o strukturze tworzących je tabel. Projektując tabele naleŝy mieć na uwadze przedstawione poniŝej podstawowe zasady projektowania: - Ta sama informacja nie powinna być wielokrotnie wprowadzona do jednej lub kilku tabel. JeŜeli informacja jest przechowywana tylko w jednej tabeli, moŝna ją uaktualnić zmieniając dane tylko w jednym miejscu. Tak jest łatwiej, a ponadto unika się wystąpienia niezgodności danych zapisanych w róŝnych miejscach. Na przykład, dobrze jest zapisać numer telefonu i adres klienta tylko raz, w jednej tabeli. - KaŜda tabela powinna zawierać informacje tylko na jeden temat. JeŜeli tabela zawiera dane na temat jednego zagadnienia moŝna przetwarzać je niezaleŝnie od danych dotyczących innych zagadnień. Na przykład, adresy klientów będą przechowywane w innej tabeli niŝ zamówienia. W ten sposób moŝna usunąć jakieś zamówienie, zachowując dane o kliencie. 3. Określenie pól, które znajdą się w tabelach KaŜda tabela zawiera informacje na temat jednego zagadnienia, a kaŝde pole w tabeli zawiera jedną daną dotyczącą tego zagadnienia, któremu poświęcona jest tabela. Na przykład, tabela poświęcona klientom moŝe zawierać pola z nazwą firmy, adresem, miastem, krajem i numerem telefonu. Zabierając się do projektowania pól w tabelach dobrze jest pamiętać o następujących wskazówkach: - NaleŜy powiązać kaŝde pole bezpośrednio z zagadnieniem, którego dotyczy tabela. - Nie naleŝy wprowadzać danych pośrednich lub obliczonych (danych, które są wynikiem wyraŝenia). Strona 5 z 52

6 - NaleŜy uwzględnić wszystkie potrzebne informacje. - Informacje naleŝy przechowywać w moŝliwie najmniejszych jednostkach logicznych (na przykład Imię oraz Nazwisko, a nie Dane personalne). 4. Przypisanie polom jednoznacznych wartości Aby program Microsoft Access mógł powiązać informacje przechowywane w róŝnych tabelach na przykład, aby powiązać klienta ze wszystkimi jego zamówieniami kaŝda tabela w bazie danych musi zawierać pole lub zbiór pól, które jednoznacznie określają kaŝdy rekord. Takie pole lub zbiór pól nazywany jest kluczem podstawowym. 5. Określenie relacji między tabelami Po podzieleniu danych na tabele i zdefiniowaniu pól kluczy podstawowych trzeba wprowadzić do programu Microsoft Access informacje na temat sposobu poprawnego łączenia powiązanych danych w logiczną całość. W tym celu definiuje się relacje między tabelami. 6. Wprowadzenie danych i utworzenie innych obiektów bazy danych Kiedy okaŝe się, Ŝe struktura tabel spełnia opisane powyŝej kryteria, moŝna wprowadzić wszystkie dane do tabel i utworzyć dowolne kwerendy, formularze, raporty, makra i moduły. 7. Zastosowanie narzędzi analizy programu Microsoft Access Program Microsoft Access jest wyposaŝony w dwa narzędzia, które pomagają udoskonalić projekt bazy danych. Kreator analizy tabel potrafi sprawdzić projekt przeglądając jednorazowo jedną tabelę, zaproponować nową strukturę tabeli i - jeśli to ma sens - zamienić tabelę w kilka tabel połączonych relacjami. Analizator wydajności potrafi przeprowadzić analizę całej bazy danych, sformułować zalecenia i propozycje dotyczące wprowadzenia ulepszeń. Analizator wydajności moŝe teŝ wprowadzić te zalecenia i propozycje. Strona 6 z 52

7 4. Projekt bazy danych i normalizacja W trakcie tworzenia aplikacji w Accessie powinieneś przez cały czas pamiętać, Ŝe kaŝda z tworzonych przez Ciebie aplikacji jest bazą danych. Aby tworzyć szybsze i bardziej wydajne aplikacje, musisz poznać i zrozumieć pojęcie normalizacji baz danych Relacyjne systemy zarządzania bazami danych (RDBMS) W ksiąŝkach i czasopismach wielokrotnie moŝna spotkać się z pojęciem relacyjne systemy zarządzania bazami danych (ang. Relational Database Management Systems RDBMS). Co Access ma wspólnego z modelem RDBMS. Model ten został stworzony w 1970 roku przez pracownika firmy IBM, dr E.F. Codda. Celem ustalonych w modelu RDBMS zasad było uniezaleŝnienie funkcjonowania interfejsów od zmian dokonywanych w modelu danych. Produkty RDBMS uŝywają wspólnych elementów danych, takich jak np. ID, aby połączyć wiersze w dwóch róŝnych tabelach, między którymi zachodziła relacja, a takŝe uŝywają tych pól w sprzęŝeniu. Istnieje 13 zasad, które produkt musi spełnić, aby moŝna go było nazwać Relacyjnym Systemem Zarządzania Bazami Danych. Niektórzy z krytyków Accessa twierdzą, Ŝe nie spełnia on tych wymagań, jednakŝe nie jest błędem zaliczenie Accessa do grupy projektów RDBMS. Oto 13 zasad relacyjnych i ich zastosowanie w Accessie. Zasada dr Codda Zasada 0. Nazwa zasady Opis Komentarz dotyczący Accessa Zasada tworzenia KaŜdy program typu RDBMS musi być w stanie zarządzać bazami danych jedynie za pomocą swoich zdolności relacyjnych. Jeśli system działa na zasadach operowania danymi rekord-po-rekordzie, nie moŝemy go nazywać systemem w pełni relacyjnym Access był pierwszą na rynku, działającą w systemie Windows bazą danych, która przestrzegała tej zasady. Access, w przeciwieństwie do niektórych systemów, nie stosuje numeracji rekordów Zasada 1. Informacja Wszystkie dane w relacyjnej bazie przedstawiane są jako wartości w tabelach. Dane nie mogą być przechowywane w Ŝaden inny sposób Access przechowuje dane jako tabele, w aparacie baz danych Jet 1 Zasada 2. Zasada 3. Gwarantowany dostęp Brakujące informacje Poprzez uŝycie kombinacji wartości klucza podstawowego, nazwy tabeli i nazwy kolumny, musi istnieć dostęp do dowolnej partii danych Program musi obsługiwać wartości Null. Wartości te przedstawiają brakujące lub bezuŝyteczne informacje Access przestrzega tej zasady poprzez uŝycie kluczy głównych. Jeśli sam nie utworzysz w tabeli klucza głównego, Access zaŝąda, abyś to zrobił Access obsługuje wartości Null dla brakujących informacji. Jednocześnie pozwala uniknąć wprowadzania wartości Null poprzez uŝycie pól wymaganych. Zasada 4. Katalog systemu Opis bazy danych lub katalog na poziomie logicznym jako wartości tabelaryczne. Język relacyjny (SQL) powinien móc działać na projekcie bazy danych w taki sam sposób, w jaki działa na danych przechowywanych w strukturze Katalog ten umieszczony jest w aparacie bazy danych Microsoft Jet. Do stworzenia zapytania dotyczącego katalogu systemu moŝesz uŝyć obiektu Active Data o nazwie OpenSchema. SQL DDL daje Ci moŝliwość tworzenia tabel, indeksów itp. Zasada 5. Kompletny język Program typu RDBMS musi obsługiwać jasno określony język do operowania danymi (SQL), który w pełni obsługuje definiowanie i operowanie danymi, określanie widoku, ograniczenia integralności, ograniczenia transakcyjne i autoryzację Access (Jet) w pełni obsługuje SQL dla operowania danymi, określania widoków (kwerendy wybierające) i ograniczeń integralności (Okno Relacje i komenda UTWÓRZ OGRANICZENIE) 1 Silnik Jet zarządza bazą danych zawartą w pliku MDB (Accessa). Gdy uruchamiamy plik typu MDB poprzez obiekty DAO lub ADO, równieŝ uŝywamy do tego silnika Microsoft Jet. Przechowuje on tabele, indeksy i kwerendy, które uruchamia poprzez wbudowany mechanizm zapytań. Jet jest rozbudowaną, wyposaŝoną w kompletny zestaw funkcji, wielowątkową, relacyjną bazą danych. Strona 7 z 52

8 Zasada dr Codda Zasada 6. Zasada 7. Zasada 8. Zasada 9. Zasada 10. Zasada 11. Nazwa zasady Opis Komentarz dotyczący Accessa Uaktualnianie widoków Ustawianie poziomu uaktualnień Fizyczna niezaleŝność danych Logiczna niezaleŝność danych NiezaleŜność integralności NiezaleŜność podziału Wszystkie widoki mogą być systemowo uaktualnione. W prawdziwym programie typu RDBMS, większość (ale nie wszystkie) widoków moŝe być uaktualniana Program typu RDBMS musi nie tylko potrafić pobierać zestawy danych. Musi takŝe potrafić wstawiać, aktualizować i usuwać dane jako zestaw relacyjny Dane i aplikacja muszą być od siebie fizycznie niezaleŝne. Odpowiedni program typu RDBMS lub optymalizator powinny móc śledzić fizyczne zmiany w danych. Przykładowo, aplikacje RDBMS nie powinny ulegać modyfikacji na skutek dodania bądź usunięcia z tabeli indeksu Gdy to tylko moŝliwe, aplikacja powinna być niezaleŝna od zmian dokonywanych w tabelach podstawowych. Przykładowo, gdy tabele są łączone w widok, nie powinny następować zmiany w kodzie Integralność danych musi być definiowalna w języku relacyjnym i przechowywana w katalogu. Ograniczenia w integralności danych mogą być wbudowane w aplikację, jednakŝe podejście to jest obce dla modelu relacyjnego. W modelu relacyjnym integralność powinna być naturalną cechą projektu bazy danych. Zdolności programu typu RDBMS nie będą ograniczone dzięki umieszczeniu jego komponentów w osobnych bazach danych. Zasada 12. Brak podwersji Jeśli program RDBMS posiada język typu jeden rekord jednocześnie, język ten nie moŝe być uŝywany do omijania zasad integralności lub ograniczeń języka relacyjnego. Dlatego teŝ nie wystarczy, by zasady relacyjne zarządzały programem typu RDBMS, ale muszą być prawami nadrzędnymi. Access był pierwszą bazą danych, umoŝliwiającą uŝycie kwerend aktualizujących Access spełnia to wymaganie poprzez uŝycie kwerend funkcjonalnych Access umoŝliwia Ci modyfikowanie obiektów bazy danych, bez konieczności dokonywania zmian w reszcie aplikacji. Jet zawiera takŝe logiczny aparat przechowywania Gdy tworzysz w Accessie kwerendę, moŝesz ją z łatwością połączyć z formularzem lub raportem, jakby to była tabela Mimo iŝ Microsoft nie umieścił w dokumentacji informacji na temat przechowywania integralności przez aparat Jet, moŝesz tworzyć zasady integralności poprzez SQL. Jet przechowuje te informacje w projekcie bazy danych jako część katalogu. PoniewaŜ silnik Jet przechowuje swoje zasady integralności danych na poziomie aparatu, pozostałe jego komponenty nie mają wpływu na zasady integralności. Access umoŝliwia Ci uŝycie obiektów DAO 2 i ADO 3, aby operować jednym rekordem jednocześnie poprzez aktualizowalne zestawy rekordów. Dzięki tym narzędziom do operowania danymi nie moŝesz naruszyć zasad integralności. Relacyjne systemy zarządzania bazami danych przewaŝają w kilku punktach nad innymi systemami, w szczególności w procesie projektowania. Programy typu RDBMS korzystają z teorii projektowania relacyjnego, aby tworzyć własne modele projektowe baz danych. 2 Obiekty Data Access (DAO) dostarczają standardowego sposobu dostępu do danych dla Jet. szczegóły w rozdziale Historia dostępu do baz danych 3 Obiekty ActiveX Data (ADO) to model obiektowy, którego moŝna uŝywać w celu pobierania danych z baz OLE. Strona 8 z 52

9 4.2. Teoria projektowania relacyjnego Teoria projektowania relacyjnego, opracowana przez dr Codda w celu rozbudowania zasad relacyjnych, składa się z następujących kategorii: 1 Tabele i niepowtarzalność. 2 Klucze obce i domeny. 3 Relacje. 4 Normalizacja danych. 5 Zasady integralności. Korzystając z teorii projektowania relacyjnego uzyskujesz zalety płynące z lat poszukiwań najlepszego sposobu zarządzania danymi. Niektóre z nich, jakie otrzymasz w wyniku normalizacji bazy danych, to: Pewność integralności danych. Skuteczność przechowywania danych. MoŜliwość rozwoju bazy danych. Zachowanie bazy danych jest przewidywalne, gdyŝ jest ona zgodna z wielokrotnie przetestowanymi zasadami. PoniewaŜ przestrzegasz tych zasad, inni projektanci baz danych mogą duŝo łatwiej zrozumieć Twój projekt. Okno Relacje staje się samo w sobie dokumentem. Zmiany w schemacie bazy danych są łatwe we wdroŝeniu Tabele i niepowtarzalność Kiedy tworzymy aplikacje bazy danych, kaŝda tabela przedstawia odrębną jednostkę lub proces występujący w rzeczywistym świecie. Tworzymy tabele kontrolujące ludzi, wydarzenia, transakcje finansowe i przedmioty (np. produkty). Zgodnie z teorią relacyjną, musimy przechowywać wszystkie dane w tabelach (zasada 1.) oraz, Ŝe tabela składa się z unikatowych wierszy i kolumn (zasada 2.). Sposobem na zapewnienie unikalnoś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łównym), które jest unikatowym identyfikatorem tego wiersza. Klucz główny musi być unikatowy. W przeciwnym bowiem wypadku dochodziłoby do naruszenia zasady 2. Access pozwala uczynić pole kluczem głównym, poprzez nadanie mu wartości Klucz w widoku Projekt tabeli. Access sprawdzi wówczas, czy dane w tym polu są unikatowe i nie występują w nim duplikaty. Czasami, gdy przestrzegamy reguł handlowych, podanie unikatowej wartości dla kaŝdego wiersza moŝe być trudne. Przykładowo, moŝemy utworzyć system zarządzający kontaktami. Podczas projektowania systemu zarządzającego kontaktami, jako klucz moŝemy wybrać Nazwisko, Telefon lub (pola takie powszechnie nazywane są polami-kandydatami ). Ogólna zasada projektowania baz danych głosi, Ŝe klucz powinien być jak najprostszy, unikatowy i jak najrzadziej zmieniany. Nazwisko moŝe się zmieniać na skutek zawarcia małŝeństwa, rozwodu itp. Numery telefonów i adresy zmieniają się ciągle. Dobrym kluczem byłby numer PESEL, ale co, gdy dana osoba nie jest obywatelem polskim? W tej sytuacji Access umoŝliwia Ci utworzenie pola autonumerowanie, które stanie się polem klucza podstawowego. Strona 9 z 52

10 Klucze obce i domeny Klucz główny staje się bardzo waŝny, gdy chcesz go uŝyć w innej tabeli. 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 poniŝej tabela przechowuje dwa obce klucze: ContactID i ContactTypeID. ContactID to klucz główny jednej tabeli, a ContactTypeID to klucz główny drugiej tabeli. Gdy uŝywasz kluczy obcych, będą się one zawsze znajdować w tej samej domenie. Domeny są to zbiory wartości, z których pobierane są kolumny. Dobrym przykładem jest StudentID. Jego domeną są wszystkie dostępne w systemie numery PESEL Relacje w bazie danych Po zaprojektowaniu róŝnych tabel dla poszczególnych tematów bazy danych, potrzebny jest sposób na powiązanie zawartych w nich informacji. Pierwszym krokiem w tym procesie jest zdefiniowanie relacji pomiędzy tabelami. Gdy się to zrobi, moŝna tworzyć kwerendy, formularze i raporty pozwalające wyświetlać za jednym razem informacje z róŝnych tabel. Gdy definiujemy klucze główne i klucze obce, mamy do czynienia z relacjami. Przez relacje rozumiemy zasady obsługiwane na poziomie silnika bazy danych (patrz: Zasada 4. dr Codda). Dzięki relacjom bazę danych moŝna podzielić na małe tabele. Istnienie logicznego związku pomiędzy nimi zapewnia, Ŝe po podziale moŝna uzyskać te same informacje, które znajdowały się w bazie złoŝonej z jednej tabeli. 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, naciskamy znajdujący się w na pasku narzędzi przycisk Relacje lub wybieramy Narzędzia Relacje, aby otworzyć okno Relacje. Zanim jednak omówimy typy relacji naleŝy wprowadzić sobie pojęcie encji. Encja to model, reprezentacja wyobraŝonego lub rzeczywistego obiektu stosowana przy modelowaniu danych podczas analizy informatycznej. MoŜe posiadać atrybuty i operacje. Powinna mieć nazwę w liczbie pojedynczej. Przykłady: Strona 10 z 52

11 OSOBA (atrybuty: imię - ciąg znaków, nazwisko - ciąg znaków) POJAZD (atrybuty: liczba kół - liczba całkowita, czy moŝe latać - wartość logiczna) Encja moŝe być równie dobrze obiektem fizycznym jak czytelnik lub ksiąŝka, jak teŝ zdarzeniem lub pojęciem, jak wypoŝyczenie ksiąŝki czy tez zamówienie na jej wypoŝyczenie. Relacja jeden-do-jednego Charakteryzuje się tym,ŝe dla kaŝdej instancji jednej z dwóch encji istnieje dokładnie jedna instancja drugiej encji pozostająca z nią w równowaŝnym związku np. czek i opłata ( opłata jest realizowana za pomocą jednego czeku i za pomocą jednego czeku moŝna zrealizować tylko jedną opłatę).ten typ relacji spotyka się rzadko, poniewaŝ większość informacji powiązanych w ten sposób byłoby zawartych w jednej tabeli. Relacji jeden-do-jednego moŝna uŝywać do podziału tabeli z wieloma polami, do odizolowania części tabeli ze względów bezpieczeństwa, albo do przechowania informacji odnoszącej się tylko do podzbioru tabeli głównej. Na przykład, moŝna by utworzyć tabelę do wyszukiwania pracowników uczestniczących w rozgrywkach piłkarskich. Dwie tabele łączy relacja jeden-do-jednego, gdy kaŝdemu wierszowi z jednej tabeli przyporządkowany jest co najwyŝej jeden wiersz z drugiej tabeli. Relacja jeden-do-wielu Charakteryzuje się tym,ŝe dla kaŝdej instancji jednej encji istnieje wiele instancji drugiej encji pozostającej z nią w rozwaŝanym związku. Relacja jeden-do-wielu jest realizowana poprzez utworzenie atrybutu w encji po stronie wiele aby umieścić w nim klucz encji znajdującej się po stronie jeden. Tak utworzony atrybut encji po stronie wiele nosi nazwę klucza obcego poniewaŝ jest on głównym kluczem w innej tabeli. Relacja jeden-do-wielu jest najbardziej powszechnym typem relacji. Najpopularniejszy typ relacji, relacja jeden-do-wielu, występuje wtedy, gdy tabela ma wiele (lub nie ma w ogóle) powiązanych rekordów w drugiej tabeli. Czasami tabela po stronie jeden nazywana jest tabelą odnośnika. Zazwyczaj, tabele odnośnika zawierają informacje, które będą przekazywane do innych tabel (na przykład, nazwy województw lub kody pocztowe). Relacja wiele-do-wielu W relacji wiele-do-wielu, rekord w tabeli A moŝe mieć wiele dopasowanych do niego rekordów z tabeli B i tak samo rekord w tabeli B moŝe mieć wiele dopasowanych do niego rekordów z tabeli A. Jest to moŝliwe tylko przez zdefiniowanie trzeciej tabeli (nazywanej tabelą łącza), której klucz podstawowy składa się z dwóch pól - kluczy obcych z tabel A i B. Relacja wiele-do-wielu jest definiowana jako dwie relacje jeden-do-wielu z trzecią tabelą. Na przykład, tabele "Zamówienia" i "Produkty" są powiązane relacją wiele-do-wielu zdefiniowaną przez utworzenie dwóch relacji jeden-do-wielu z tabelą "Opisy zamówień". Strona 11 z 52

12 O relacji wiele-do-wielu mówimy wówczas, gdy kaŝdemu wierszowi z jednej tabeli odpowiada wiele wierszy w drugiej tabeli, a kaŝdemu wierszowi z drugiej tabeli odpowiada wiele wierszy w pierwszej. Jedynym sposobem na przedstawienie w Accessie relacji wiele-do-wielu jest uŝycie tabeli łączącej, w której jako klucze obce znajdują się klucze główne obu tabel Normalizacja danych Zgodnie z zestawem zasad dr Codda proces projektowania bazy danych nazywany jest normalizacją danych. Dr Codd wyróŝnia sześć poziomów normalizacji. Skoncentrujemy się tutaj na trzech z nich, gdyŝ mają one największy wpływ na decyzje dotyczące projektu bazy: 1. Pierwsza postać normalna. 2. Druga postać normalna. 3. Trzecia postać normalna. Pierwsza postać normalna W pierwszej postaci normalnej wszystkie kolumny w tabeli muszą posiadać wartości atomowe. Innymi słowy, kaŝde pole moŝe zawierać tylko jedną wartość, a nie listę wartości lub powtarzającą się grupę danych. Wiele kartotekowych baz danych przechowuje dane w ten sposób, co znacznie utrudnia ich przeszukiwanie. Rysunek 1 (poniŝej) przedstawia przykład tabeli, która nie jest w pierwszej postaci normalnej, poniewaŝ w kolumnie ContactInfo przechowywana jest tablica wartości (telefon, fax, ). Strona 12 z 52

13 Rys 1. Natomiast rysunek 2 jest przykładem tabeli w pierwszej postaci normalnej. Rys 2. Druga postać normalna Mimo iŝ tabela przedstawiona na rysunku powyŝej jest w pierwszej postaci normalnej, nie jest jednak w drugiej postaci normalnej. Mówimy, Ŝe tabela jest w drugiej postaci normalnej, gdy jest w pierwszej postaci normalnej i jednocześnie kaŝde z jej pól nie będących polem klucza głównego jest w pełni zaleŝne od całego klucza głównego. Innymi słowy, część informacji moŝe być przechowywana w innej tabeli i pobierana z niej poprzez odnośnik. Spójrz na tabelę na rysunku powyŝej. Klucz główny składa się z ContactID, ContactInfoID i ContactInfo. Czy kolumna ContactName zaleŝy od części klucza: ContactInfoID i ContactInfo? Nie, gdyŝ jest zaleŝna od pola ContactID. Aby przekształcić tę tabelę do drugiej postaci normalnej, naleŝy informacje o kliencie umieścić w osobnej tabeli odnośnika i utworzyć pomiędzy tabelami przedstawioną na rysunku poniŝej relację jeden-do-wielu. Tabele te są teraz w drugiej postaci normalnej. Strona 13 z 52

14 Rys 3. Trzecia postać normalna Mimo iŝ tabele na rysunku powyŝej są w pierwszej i drugiej postaci normalnej, nie są jednak w trzeciej postaci normalnej. Z tabelą w trzeciej postaci normalnej mamy do czynienia, gdy wszystkie pola, nie będące polami klucza głównego, są wzajemnie zaleŝne. Dobrym przykładem zaleŝności jest pole obliczeniowe (korzystniej jest nie przechowywać pól obliczeniowych, tylko wyświetlać wyniki obliczeń jako część kwerendy). Na rysunku powyŝej druga tabela przechowuje pola ContactInfoID i ContactType (opis). Jeśli wartość pola ContactType poznajemy dzięki polu ContactInfoID, tabela nie jest w trzeciej postaci normalnej. Aby otrzymać trzecią postać normalną, naleŝy wyodrębnić z ContactInfo trzecią tabelę i utwórz między tabelami ContactInfo i ContactDetails relację jeden-do-wielu, tak jak na rysunku poniŝej. Strona 14 z 52

15 Rys 4. Korzyści z normalizacji W poprzednim przykładzie, wiele zyskaliśmy, normalizując początkową, przedstawioną na rysunku 1 tabelę. Tabela początkowa zawierała sposoby porozumiewania się w tablicy wartości, co prawie całkowicie uniemoŝliwiało przeszukiwanie zawartości pola Faks. Dodatkowo, gdy zmieniał się numer telefonu kontaktu lub zachodziła potrzeba dodania nowego sposobu porozumiewania się, jak na przykład adres , edycja danych była utrudniona i łatwo było o błędy. Pierwsza postać normalna znacznie poprawiła sytuację i zwiększyła elastyczność w kontrolowaniu numerów telefonów, faksów i adresów naszych kontaktów. W przedstawionej na rysunku 2 tabeli, która jest w pierwszej, lecz nie jest w drugiej postaci normalnej, zarządzanie danymi dotyczącymi kontaktów jest utrudnione, gdyŝ informacje wielokrotnie się powtarzają. Jeśli masz w bazie 10 numerów telefonów i przechowujesz to samo nazwisko 10 razy, to jest to nie tylko strata przestrzeni dyskowej, ale równieŝ problem, gdy zachodzi potrzeba uaktualnienia wszystkich 10 wpisów, gdy dana osoba zmieniła nazwisko. Utrzymanie spójności w tym przypadku moŝe kosztować duŝo wysiłku. Strona 15 z 52

16 Tabele na rysunku 3, mimo iŝ są w pierwszej i drugiej postaci normalnej (wszystkie kolumny zaleŝą od całego klucza), nie są w trzeciej postaci normalnej. Przenosząc dane i uzyskując trzecią postać normalną, uzyskujesz większą elastyczność modelu danych, gdyŝ teraz moŝemy zarządzać typami kontaktów w osobnej tabeli Zasady integralności danych Podczas normalizowania danych powinniśmy równieŝ uwzględnić zasady integralności danych. Większość z zastosowanych zasad będzie zaleŝeć od zdefiniowanych relacji. Podczas określania relacji moŝemy dodatkowo ustawić kaskadowe aktualizowanie i usuwanie rekordów. Ustawienie aktualizowania kaskadowego rekordów daje nam pewność, Ŝe gdy aktualizujemy wartość klucza podstawowego tabeli jeden, zmiana ta odniesie skutek w tabelach wielu. Przykładowo, powiedzmy, Ŝe mamy tabelę odnośnika dla Stanów Zjednoczonych. W tabeli tej znajduje się miasto Nowy Jork, z kluczem podstawowym NY i opisem Nowego Jorku. Wyobraźmy sobie, Ŝe miasto to odłączyło się i stworzyło swój własny stan (to nie jest fikcja, prawie do tego doszło w roku 1789!). Gdy zmienimy wartości NY na NY1 (lub coś bardziej opisowego), wartości NY we wszystkich podrzędnych tabelach zostaną zmienione na NY1. Jeśli aktualizowanie kaskadowe nie było włączone, musielibyśmy dodać rekord NY1 do tabeli odnośnika, zaktualizować wszystkie rekordy w podrzędnej tabeli, a następnie usunąć z tabeli odnośnika rekord NY. Włączenie usuwania kaskadowego daje nam pewność, Ŝe gdy usuwamy rekord z tabeli jeden, usuwamy równieŝ wszystkie rekordy z tabeli wielu. Ma to swoje dobre i złe strony. Jeśli usuwamy jednego z klientów, a usuwanie kaskadowe było włączone, usunięte zostaną wszystkie faktury po stronie wielu. W przeciwnym wypadku, usunięcie rekordu z tabeli jeden nie będzie wykonane, dopóki nie usuniemy wszystkich rekordów z tabeli wielu Strona 16 z 52

17 5. Typy danych pól w tabeli Komputer nie jest w stanie odczytać niczego z kontekstu. Gdy adresujemy list, napiszemy na kopercie przecinek zamiast kropki; list i tak dotrze do adresata listonosz domyśli się, kto ma być jego odbiorcą. Gdyby komputery były listonoszami (tak, jak ma to miejsce w przypadku poczty elektronicznej), wszystkie listy zaadresowane z błędem wracałyby do nadawcy. KaŜda informacja ma określony typ. Opis wydatku jest tekstem. Konto, które obciąŝa wydatek, jest liczbą itd. Aby zapoznać się z opisem pól, naleŝy otworzyć tabelę w trybie projektowania. W kolumnie Typ danych właściwości pól. TYP DANYCH Autonumerowanie Data/Godzina Hiperłącze Kreator odnośników Liczba Nota Obiekt OLE TAK / NIE Tekst Waluta OPIS Unikatowa liczba kolejna (zwiększana o l) lub liczba losowa, przypisywana przez program Microsoft Access przy dodawaniu nowego rekordu do tabeli. Pola Autonumerowanie nie moŝna aktualizować. Do zapisu uŝywane są 4 bajty Pole moŝe zawierać wartości daty i godziny. Akceptowane są daty z przedziału od 100 do Do zapisu uŝywanych jest 8 bajtów Pole maŝe zawierać tekst lub kombinacje tekstu i liczb. Przechowywane są one jako tekst, a uŝywane jako adres hiperłącza. Adres hiperłącza maŝe składać się z trzech części: tekstu - wyświetlanego w polu lub w formancie, adresu - ścieŝki dostępu do pliku (w formacie UNC) lub strony (adres URL), podadresu miejsca w pliku lub na stronie, etykietki ekranowej tekstu wyświetlanego jako etykietka. KaŜda z trzech części hiperłącza moŝe zawierać do znaków Tworzy pole, które pozwala wybrać wartość z innej tabeli. Wybór tej opcji powoduje uruchomienie Kreatora odnośników. Po zakończeniu pracy z Kreatorem program Microsoft Access ustawia typ danych na podstawie wartości określonych w Kreatorze. Do zapisu uŝywane są 4 bajty Dane numeryczne uŝywane w obliczeniach matematycznych. Pole moŝe zawierać liczbę zapisaną przy uŝyciu l, 2. 4 lub 8 bajtów Pole moŝe zawierać długi tekst lub kombinacje tekstu i liczb. Długość ciągu znaków - od 0 do Obiekt (arkusz kalkulacyjny programu Microsoft Excel, dokument programu Microsoft Word. grafika, dźwięk lub inne dane binarne) dołączony lub osadzony w tabeli programu Microsoft Access. Rozmiar obiektu ograniczony jest do l gigabajta. Ograniczeniem jest teŝ dostępne miejsce na dysku. Wartości Tak i Nie oraz pola zawierające tylko jedna z dwóch wartości (Tak i Nie, Prawda/F olsz lub WI/Wy/). Do zapisu uŝywany jest l bit Pole moŝe zawierać kombinacje tekstu i liczb lub liczby nie wymagające obliczeń, np. numery telefonów. Długość ciągu znaków - od 0 do 255 Pole moŝe zawierać wartości walutowe i dane numeryczne. Są one uŝywane w obliczeniach matematycznych dokonywanych na danych z dokładnością do czterech miejsc po przecinku. Wyniki obliczeń mają dokładność do 15 cyfr po lewej stronie separatora dziesiętnego i do 4 cyfr po prawej stronie separatora. Do zapisu uŝywanych jest 8 bajtów Strona 17 z 52

18 Typ Liczba słuŝy do przechowywania liczb. Microsoft Access umoŝliwia wybranie jednej z kilku notacji. MoŜna je wybierać z listy Rozmiar pola. Deklarując sposób zapisu liczb, trzeba wziąć pod uwagę zakres ich wartości i dokładność zapisu. PoniŜej opisane zostały najczęściej uŝywane podtypy liczb. Bajt Liczby naturalne od 0 do 255 Liczba całkowita liczby całkowite od do Liczba całkowita długa Liczby całkowite od do Podwójna precyzja Pojedyncza precyzja Liczby rzeczywiste o 10 cyfrach znaczących. Wartości od -1, E308 do 1, E308 Liczby rzeczywiste o 6 cyfrach znaczących. Wartości od -3,402823E38 do 3,402823E38 Domyślnym podtypem jest Podwójna precyzja. JeŜeli wiemy, ze w danym polu będą występować tylko liczby całkowite o wartości mniejszej niŝ 255, warto uŝyć podtypu Bajt. Zmniejszenie rozmiarów deklarowanych podtypów powoduje zredukowanie rozmiarów bazy danych i zwiększenie szybkości działania. Wybrane podtypy daty i godziny Data ogólna Data długa Dala średnia Dala krótka Godzina długa Ustawienie domyślne. Jeśli wartością jest tylko data, nie jest wyświetlana godzina. Jeśli wartością jest tylko godzina - nie jest wyświetlana data. Ustawienie jest połączeniem ustawień Data krótka i Godzina długa Odpowiada ustawieniu Dala długa w oknie dialogowym Właściwości ustawień regionalnych w Panelu sterowania systemu Windows. Data jest zapisywana w formacie..dzien-miesiac-rok". np.: 19-cze-94 Odpowiada ustawieniu Data krótka w oknie dialogowym Właściwości ustawień regionalnych w Panelu sterowania systemu Windows. Odpowiada ustawieniu na karcie Godzina w oknie dialogowym Właściwości ustawień regionalnych w Panelu sterowania systemu Windows. Godzina średnia Czas jest zapisywany w cyklu 12. godzinnym, np.: 05:34 Godzina krótka Czas jest zapisywany w cyklu 24- godzinnym, np.: 17:34 Strona 18 z 52

19 6. Historia dostępu do danych Access jest zaawansowanym interfejsem uŝytkownika dla silnika baz danych Microsoft Jet 4.0. NiezaleŜnie od tego, czy jesteśmy tego świadomi, Jet zarządza bazą danych zawartą w pliku MDB. Gdy uruchamiamy plik typu MDB poprzez obiekty DAO lub ADO, równieŝ uŝywamy do tego silnika Microsoft Jet. Przechowuje on tabele, indeksy i kwerendy, które uruchamia poprzez wbudowany mechanizm zapytań. Jet jest rozbudowaną, wyposaŝoną w kompletny zestaw funkcji, wielowątkową, relacyjną bazą danych. Dzisiaj Microsoft Jet uŝywany jest jako aparat bazy danych w ponad 30 produktach firmy Microsoft. MoŜna wśród nich wymienić (oprócz, rzecz jasna, Accessa) takie programy, jak Project, Money, Team Manager, a nawet edukacyjne gry dla dzieci. Jet całkowicie zdominował rynek domowych baz danych, gdyŝ kaŝda jego edycja zawiera coraz nowocześniejsze technologie. Cofnijmy się teraz odrobinę, aby prześledzić historię Microsoft Jet. Jet 1.0 Historia Microsoft Jet rozpoczyna się ponad dziesięć lat temu, kiedy to w firmie Microsoft rozpoczęto wdraŝanie projektu Access. Gdy w 1992 roku Access 1.0 trafił na półki sklepowe, razem z nim na rynek domowych baz danych wszedł Jet 1.0. Zawierał on wiele bardzo potrzebnych opcji domowych baz danych, jak definiowanie danych, kwerendy, zabezpieczenia i indeksowanie. Jet był jednocześnie produktem pionierskim, gdyŝ zawierał wiele nowych opcji, jak na przykład: kwerendy aktualizujące, heterogeniczne sprzęŝenia danych i moŝliwość tworzenia kwerendy w oparciu o inną kwerendę. Opcje te umoŝliwiły programowi Microsoft Access osiągnąć pozycję najpopularniejszej domowej bazy danych. Jet 1.1 Sukces Accessa był zaskoczeniem dla wszystkich, łącznie z firmą Microsoft. W maju 1993 roku wydano Access 1.1 oraz Visual Basic 3.0, a razem z nimi Jet 1.1. Ta edycja umoŝliwiała programistom korzystanie z wielu nowych opcji: poprawionej, zgodnej ze standardem ODBC komunikacji i nowych sterowników ODBC. Od tej pory zaprzestano tworzenia kodu programu poprzez interfejs API ODBC, a dostęp do danych ODBC stał się moŝliwy dla kaŝdego. Jet 1.1 umoŝliwił równieŝ swoim uŝytkownikom łatwe dołączanie zewnętrznych danych, zwłaszcza w nowym formacie Microsoft FoxPro. Poprawiono biblioteki obiektów DAO, a maksymalny rozmiar bazy Jet wzrósł ze 128 MB do 1,1 GB. Jet 2.0 Jet 2.0 został wprowadzony na rynek w kwietniu 1994 roku wraz z bardzo popularnym Accessem 2.0. Dzięki takim opcjom jak wymuszanie reguł poprawności na poziomie silnika bazy, czy integralności referencyjnej Jet 2.0 stał się nowoczesnym aparatem baz danych. Aby zwiększyć jego wydajność, dodano równieŝ zapoŝyczoną z FOX-a technologię Rushmore oraz poprawiono funkcjonowanie SQL i obiektów DAO. Jet 2.0 był równieŝ, bardziej niŝ poprzednie wersje, zgodny z ANSI. Jet 2.5 W październiku 1994 roku firma Microsoft wypuściła na rynek pakiet Service Pack do Accessa 2.0 oraz pakiet sterowników ODBC Desktop Drivers Pack 2.0. Były to równieŝ narodziny Jet 2.5. W tej wersji do konstruowania wyraŝeń Jet uŝywał juŝ VBA, a wsparcie dla źródeł danych ODBC uległo znacznej poprawie. Ulepszono takŝe obsługę aplikacji przeznaczonych dla wielu uŝytkowników. Jet 3.0 Gdy pod koniec 1995 roku Microsoft wypuścił na rynek Access 95, silnik Jet został wprowadzony w 32- bitowe środowisko. Jet stał się zatem 32-bitowym silnikiem baz danych, posiadającym zdolność Strona 19 z 52

20 replikacji danych, a takŝe ulepszone opcje ODBC i DAO. Jet 3.0 był bardzo szybkim silnikiem baz danych. Jet 3.5 Wraz z wprowadzeniem na rynek w styczniu 1997 roku pakietu Office 97 oddano do rąk uŝytkowników Jet 3.5. Był on juŝ w pełni 32-bitowym silnikiem baz danych, którego największym ulepszeniem był znaczny wzrost wydajności. Jet 3.5 zawierał takŝe nowe zdolności buforowania danych, poprawione blokowanie stron, ulepszenia w pracy kwerend, ODBCDirect oraz programowe anulowanie poleceń zapisu na dysk. Replikacja została rozszerzona o repliki częściowe, a wsparcie danych zewnętrznych o obsługę danych HTML i Exchange. Jet 3.51 Wypuszczenie na rynek w połowie 1997 roku Jet 3.51, będącego kontynuacją Jet 3.5, prawie nie zostało zauwaŝone. Nowy Jet zawierał ulepszoną metodę defragmentowania i naprawiania plików typu MDB. Opcja naprawiania została włączona w znacznie poprawiony proces defragmentowania. W Jet 3.51 poprawiono błędy dotyczące niskopoziomowej obsługi wielu uŝytkowników, jednakŝe najwaŝniejsze w nim było narzędzie do defragmentowania i naprawy JetCOMP.exe, korzystające z nowej opcji defragmentującej. Jet 4.0 W czerwcu 1999 roku, wraz z pakietem Office 2000, Microsoft wypuścił na rynek Jet 4.0. Edycja ta była tym, na co czekali wszyscy programiści. Jet 4.0 zawiera więcej funkcji niŝ wszystkie poprzednie wersje razem wzięte. Większość z nich została dodana dzięki uwzględnieniu zgromadzonych przez lata próśb i uwag programistów. Wersja 4.0 to bardzo rozbudowany program, zawierający tak zaawansowane opcje, jak: nowy wbudowany dostawca baz danych OLE; blokowanie na poziomie rekordów; pełna obsługa Unicode; ulepszone typy danych; poprawione funkcje Autonumerowania; przeszukiwalne pola typu Memo; poprawki trybu przeznaczonego dla wielu uŝytkowników; ulepszenia w replikacji; nowa składnia SQL (bardziej zgodna z ANSI 92). Strona 20 z 52