ZASADY PROJEKTOWANIA BAZ DANYCH

Transkrypt

1 LEKCJA 1: PODSTAWOWE ZAGADNIENIA PRACY Z BAZĄ DANYCH ACCESS ZASADY PROJEKTOWANIA BAZ DANYCH Reguła 1 Reguła 2 Reguła 3 Nigdy nie twórz pól, których wartości można wyznaczyć na podstawie zawartości innych. Jeżeli na przykład posiadasz tabelę opisującą stan magazynu, zawierającą takie pola jak IloscDostepna oraz Koszt, nie trudź się tworzeniem pola wyznaczającego wartość netto danego towaru w magazynie, gdyż można ją wyznaczyć jako iloczyn tych dwóch pól. Powód jest następujący - za każdym razem, gdy zmieni się stan magazynu lub cena towaru, trzeba by przeliczać i edytować wartość w takim polu. Gdy chcesz wyznaczyć wartość netto towaru w magazynie - lub wykonać dowolne inne obliczenia na innych polach - możesz to zrealizować w formularzu, raporcie lub kwerendzie. W ten sposób zoba czysz lub wydrukujesz odpowiedni rezultat, bez marnowania miejsca, potrzebnego do przechowywania dodatkowego pola w tabeli. Co więcej, nigdy nie powinna zaistnieć sytuacja, w której zmiana w jednym polu będzie wymagała zmiany w innym. Zbyt łatwo można taką zależność przeoczyć. Nigdy nie twórz powtarzających się pól. Powtarzające się pola to takie, które po prostu zawierają informacje tego samego typu. Załóżmy na przykład, że klub, do którego należysz, chce gromadzić informacje o dzieciach członków. Jak myślisz, ile trzeba będzie utworzyć pól dla imion dzieci? Dzieckol, Dziecko2, Dziecko3 i tak dalej? Czy zajmujemy się tutaj planowaniem rodziny, czy prawidłowej bazy danych? Jeżeli istnieją pola, w których powtarzane są informację takiego samego typu - na przykład imiona dzieci - trzeba projektowaną tabelę rozbić na dwie, połączone relacją. Nigdy nie twórz pól o tej samej wartości w każdym rekordzie. Załóżmy na przykład, że działalność twojej firmy ogranicza się do terenu Polski. Czyż więc potrzebne jest pole Państwo? Nie! Ponieważ wszyscy klienci mieszkają w Polsce. Nie musisz też obawiać się braku takiej informacji w adresie - możesz na stałe umieścić odpowiedni tekst na formularzu lub w raporcie. 1

2 Reguła 4 Każdy rekord musi być unikatowy. Nigdy nie powinno dojść do sytuacji, w której zawartości dwóch różnych rekordów byłyby identyczne. Jeżeli w tabeli istnieją dwa dokładnie takie same rekordy, coś jest nie w porządku. Załóżmy na przykład, że zbierasz zdjęcia swoich ulubionych piłkarzy, przy czym posiadasz kilka duplikatów. Postaw sobie pytanie, czy są one w taki samym stanie. Jeżeli nie, musisz utworzyć pole Stan, w którym będziesz odnotowywać jakość każdego ze zdjęć. Jeżeli istnieją identyczne kopie takich samych zdjęć, musisz utworzyć pole o nazwie Kopie lub Ilość. Nie zapisuj tej samej informacji dwukrotnie - po prostu użyj pola, które pozwoli ci stwierdzić, że posiadasz dwa takie same obiekty. Reguły normalizacji Na proces normalizacji składa się wiele reguł, przedstawimy jedynie najważniejsze. Stosowanie pozostałych w większości przypadków nie będzie konieczne. Po ich przyswojeniu sobie cały projekt bazy danych będziemy mogli wykonać samodzielnie. Oto one: wszystkie pola powinny być atomowe, tj. powinny przechowywać dane, które nie mogą być dalej dzielone, wszystkie pola muszą odwoływać się do pola klucza podstawowego lub obcego (klucz podstawowy zawiera wartość unikatową dla każdego rekordu; pojęcie klucza obcego zostanie omówione przy okazji relacji wszystkie pola muszą być niezależne względem siebie - w jednej tabeli nie mogą występować między nimi żadne ukryte zależności. tej samej informacji nie wprowadzaj do jednej lub kilku tabel (problem z uaktualnianiem) każda tabela powinna zawierać informacje tylko na jeden temat Planowanie struktury bazy danych Pierwszym krokiem procesu projektowania bazy jest zastanowienie się nad jej przeznaczeniem. Jakiego rodzaju informacje będziemy w niej przechowywać? Kto będzie z nich korzystał? Jak chcielibyśmy prezentować dane uzyskiwane z bazy? Odpowiedzi na te pytania udzielimy po dokładnym przyjrzeniu się danym mającym znaleźć się w bazie oraz bieżącemu procesowi ich przechowywania. Jeśli z 2

3 powstającej aplikacji będą korzystać także inni użytkownicy, warto ich zapytać, jakie operacje obecnie wykonują na danych i czego oczekiwaliby od nowego programu. Ciekawostka: Pamiętajmy, ze może być wykorzystywany przez nie więcej niż 255 użytkowmków, a wielkość bazy nie może przekraczać 1GB PODSTAWOWE POJĘCIA Przed zajęciem się normalizacją upewnijmy się, że znamy kilka podstawowych pojęć z teorii baz danych: pojęcie baza danych tabela pole rekord obiekt formularz zapytanie raport zbiór rekordów wyjaśnienie zbiór powiązanych ze sobą danych odnoszących się do określone dziedziny lub zgromadzonych we wspólnym celu oraz narzędzia umożliwiające ope rację na nich. Baza danych w ie może na przykład obsługiwać dane zapasu towarów i zamówień określonej firmy, zbiór powiązanych danych przechowywanych w wierszach i kolumnach, na przykład tabela adresów klientów komórka tabeli, najmniejsza jednostka danych w całej bazie. Pole przechowuj pojedynczą wartość, na przykład nazwę, numer telefonu czy kod pocztowy klienta, wiersz tabeli. Składa się z pól i zawiera dane tworzące pojedynczą jednostkę Rekord może na przykład przechowywać wszystkie dane określonego klienta, pojedynczy składnik a, na przykład tabela, formularz, zapytanie czy raport obiekt a wyświetlający w nietabelarycznej postaci informację prze chowywaną w tabelach obiekt służący do zapamiętania pytań dotyczących przechowywanych danych obiekt przechowujący informacje o określonym sposobie wyświetlania lut drukowania danych grupa rekordów spełniających określone warunki 3

4 TYPY PÓL typ Tekst Nota Liczba Data/Godzina Walutowy Autonumerowanie Tak/Nie Obiekt OLE wyjaśnienie jest stosowany w polach, na których nie będą przeprowadzane obliczenia lub które nie pasują do żadnej innej kategorii; pola tego typu mogą mieć maksymalnie 255 znaków alfanumerycznych skorzystaj z tego typu, jeżeli przewidujesz, że w polu będą wpisywane teksty dłuższe niż 255 znaków; pola tego typu są jak gdyby miniedytorem tekstu, w którym można przetwarzać jednocześnie do znaków (64 kb) twórz pola tego typu, gdy będziesz na nich wykonywać jakieś obliczenia (liczby całkowite lub ułamkowe); dla pól, w których przechowywane są wartości kwotowe, przeznaczony jest inny typ. Typ liczbowy posiada wiele podtypów (całkowite, pojedyńcza precyzja, podwójna precyzja) różniących się zakresem przyjmowanych liczb jak sama nazwa wskazuje, w polu tego typu możesz przechowywać dane związane z czasem; na datach również można wykonywać różnego rodzaju obliczenia, na przykład można wyznaczyć liczbę dni pomiędzy dwoma datami (za pomocą odpowiednich funkcji) kategoria pól podobna do typu Liczba, lecz posiadająca stałą liczbę miejsc dziesiętnych oraz opatrzona symbolem waluty ($, zł) skorzystaj z tego typu, jeżeli chcesz automatycznie numerować rekordy w tabeli; w poprzednich wersjach programu typ ten nazywany był typem licznikowym typ ten jest stosowany w polach, które mogą przybierać wartość Tak lub Nie. Mogą to być na przykład pola o nazwach Zapłacono? Przeprowadzono kontrolę? Pole tego typu pojawi się w postaci pola wyboru. Gdy pole jest zaznaczone, oznacza to wartość Tak, w przeciwnym razie pole przybiera wartość Nie. OLE (Object Linking and Embedding czyli Łączenie i Osadzanie Obiektów) stosowany do przechowywania obrazów, plików dźwiękowych i wykresów. 4

5 Hiperłącze Kreator odnośników wykorzystywany do przechowywania tekstu będącego hiperłączem do witryny sieci WWW. Zawartością pól tego typu są adresy internetowe. za pomocą tej opcji możesz wybrać wartości pola pochodzące z innej tabeli lub utworzyć listę zawierającą elementy do wyboru. ZASADY NAZEWNICTWA Zasady nazewnictwa to reguły, które należy stosować podczas nazywania obiektów aplikacji. Można wybrać istniejącą konwencję lub utworzyć własną, należy jednak przyjąć jedną i konsekwentnie ją stosować. Dobra nazwa powinna wskazywać cel oraz klasę obiektu. Reguły te stosuje się aby szybciej i bardziej konsekwentnie identyfikować obiekty. Jak łatwo zauważyć, wielu programistów używa następującej formy: klasanazwaobiektu np. tblmojatabela, frmmojformularz gdzie klasa to przedrostek identyfikujący typ obiektu, a NazwaObiektu określa cel lub jego zadanie. Argument klasa pisany jest małymi literami, a Nazwaobiektu ma zawsze pierwszą literę lub inicjały pisane wielką. Historia i logika zasad nazewnictwa Ta metoda pochodzi ze standardowej konwencji nazwanej konwencją węgierską, wprowadzonej przez Charlesa Simonyi. Przedyskutowanie całego tematu dotyczącego jej zasad zajęłoby zbyt wiele czasu, dlatego szczegółowo omówimy zasady nazewnictwa obiekt-poziom. Aby zastosować tę metodę, trzeba znać klasę i cel obiektu. Pierwsze jest dość oczywiste - chodzi o nazwanie tabeli, formularza, raportu, formantu, itd. Cel obiektu może być trochę bardziej skomplikowany, ponieważ nad tym składnikiem użytkownik ma praktyczną i twórczą kontrolę. Innymi słowy, można by nazwać raport o sprzedaży rptkrólik, ale nikt nie wiedziałby, co to jest. Jedyną wskazówką byłby składnik rpt, który wskazywałby, że jest to raport. Reszty można by się tylko domyślać. Być może lepszą nazwą byłoby rptsprzedaż. pozwala korzystać z identycznych nazw, jeśli tylko te obiekty należą do innej klasy. Nazywając obiekty warto też pamiętać o tym by nie stosować spacji ani polskich liter w nazwach obuiektów oraz pól. Zamiast spacji należy stosować podkreślnik: tbl_moja_tabela 5

6 tabela pokazująca powszechnie przyjęte przedrostki używane w nazwach obiektów Obiekt Tabela Kwerenda Formularz Raport Makro Bajt Liczba całkowita Liczba całkowita długa Pojedyncza precyzja Podwójna precyzja Tekst Autonumerowanie Waluta Data/Godzina Memo Tak/Nie Moduł Pole wyboru Pole kombi Moduł klasy Przycisk polecenia Etykieta Pole listy Pole tekstowe Przycisk opcji Podformularz/podraport Przedrostek tbl kwr frm rpt mcr byt int ing sng dbl str cur dtm mem ysn bas chk cbo cls cmd lbl lst txt opt sub 6

7 PRZYKŁADOWY PROJEKT TABELI ACCESS 7