plik


ÿþAccess 2007 PL. Seria praktyk Autor: Andrew Unsworth T³umaczenie: Rados³aw Meryk ISBN: 978-83-246-2060-9 Tytu³ orygina³u: Access 2007 in Easy Steps (In Easy Steps) Format: 180x235, stron: 200 Poznaj praktyczne mo¿liwoSci programu Access 2007! " Jak w³aSciwie zaprojektowaæ bazê danych? " Jak korzystaæ z szablonów? " Jak tworzyæ tabele i definiowaæ relacje miêdzy nimi? Wbrew pozorom nie trzeba byæ specjalist¹, ¿eby korzystaæ z Accessa! Jest to program wyj¹tkowo przyjazny dla u¿ytkownika, umo¿liwiaj¹cy tworzenie baz danych i zarz¹dzanie nimi bez potrzeby dog³êbnego poznawania jêzyka SQL oraz skomplikowanych Srodowisk serwerowych. Aplikacja pozwala na zapisywanie danych z wykorzystaniem formularzy, kierowanie zapytañ do bazy, a tak¿e dzielenie danych ze wspó³pracownikami za poSrednictwem sieci komputerowej. Ksi¹¿ka  Access 2007 PL. Seria praktyk zawiera zwiêz³y i czytelny opis wszystkich najwa¿niejszych funkcji tego programu, a tak¿e konkretne przyk³ady i jasne instrukcje zastosowania narzêdzi Accessa. Kolorowe strony pozwalaj¹ na szybkie odnalezienie interesuj¹cych Ciê zagadnieñ. Dziêki temu podrêcznikowi poznasz podstawowe zasady tworzenia dobrego projektu bazy danych oraz jej zaawansowane mo¿liwoSci. Nauczysz siê tworzyæ tabele, formularze i raporty, a tak¿e korzystaæ z kluczy podstawowych i obcych. Bez problemu zbudujesz tak¹ bazê danych, która pozwoli Ci sprawnie zarz¹dzaæ informacjami. " Personalizacja Accessa 2007 " Projektowanie baz danych " Relacyjne bazy danych " Klucze podstawowe i obce " Tworzenie tabel " Korzystanie z typów danych " Definiowanie relacji " Kwerendy " Korzystanie z SQL " Tworzenie i dostrajanie formularzy " Tworzenie raportów " Wspó³dzielenie Accessa Naucz siê korzystaæ z Accessa  zachwyc¹ Ciê jego mo¿liwoSci! Spis tre[ci Zaczynamy 7 1 Czym jest Access 2007? 8 Ekran pocztkowy 9 Pasek narzdzi Szybki dostp 10 Korzystanie z Przycisku pakietu Office 12 Personalizacja Accessa 2007 15 Konwersja starszych baz danych 16 Korzystanie z serwisu Office Online 18 Szkolenia online 19 Pobieranie nowych materiaBów 20 Pobieranie nowych szablonów 21 Korzystanie z szablonów 22 Korzystanie ze wst|ki 24 Korzystanie z Okienka nawigacji 25 Korzystanie z systemu pomocy 26 Projektowanie baz danych 27 2 Relacyjne bazy danych 28 Typy relacji 30 Projekt bazy danych 32 Zanim uruchomisz Accessa 33 Projektowanie tabel 34 Klucze podstawowe i obce 35 Doskonalenie projektu 36 Tworzenie tabel 37 3 Okno tabeli 38 Korzystanie z szablonów tabel 39 Korzystanie z widoku arkusza danych 40 Dodawanie i usuwanie pól 41 Typy danych w widoku arkusza danych 43 Korzystanie z widoku projektu 44 Tworzenie tabeli 45 Wstawianie wiersza w widoku projektu 46 Usuwanie pola w widoku projektu 47 Okre[lanie klucza podstawowego 48 Korzystanie z typów danych 49 Korzystanie z zaBczników 51 Okre[lanie wBa[ciwo[ci pól 52 Korzystanie z reguB weryfikacji poprawno[ci danych 53 Tworzenie masek wprowadzania 54 Ustawianie domy[lnej warto[ci 55 Korzystanie z indeksów 56 Tworzenie kolumny odno[nika 58 Definiowanie relacji 61 4 Okno Relacje 62 Dodawanie tabel 63 Definiowanie relacji 64 Wizy integralno[ci 66 Okre[lanie wBa[ciwo[ci sprz|enia 68 Sprz|enia lewo- i prawostronne 70 Praca z danymi 71 5 Wprowadzanie danych 72 Wstawianie wierszy 73 Korzystanie ze Schowka 74 Kopiowanie i wklejanie danych 75 Kopiowanie danych bezpo[rednio z Excela 76 Kopiowanie danych do Excela 77 Importowanie danych z Excela 78 Importowanie danych z Accessa 83 PoBczenia z bazami danych Accessa 85 Zarzdzanie zadaniami importowania 87 Zbieranie danych za po[rednictwem poczty elektronicznej 88 Filtrowanie danych 94 Podsumowania kolumn 96 Sprawdzanie pisowni danych 97 Formatowanie danych 98 Kwerendy 101 6 Czym jest kwerenda? 102 Korzystanie z kreatora kwerend 103 Widok projektu kwerendy 106 Dodawanie kryteriów do kwerend 108 Kwerendy tworzone na podstawie wielu tabel 109 61 Definiowanie kryteriów dla liczb 110 Definiowanie kryteriów dla danych tekstowych 111 62 Definiowanie kwerend tworzcych tabele 112 63 Definiowanie kwerend doBczajcych 114 64 Definiowanie kwerend aktualizujcych 115 66 Definiowanie kwerend usuwajcych dane 116 68 70 Korzystanie z SQL 117 7 71 PosBugiwanie si jzykiem SQL 118 Trzy odmiany jzyka SQL 119 Otwieranie okna SQL 120 72 Korzystanie z klauzuli SELECT 121 73 Korzystanie z klauzuli WHERE 122 74 Funkcje agregacji jzyka SQL 123 75 Tworzenie kwerend skBadajcych 124 76 77 78 83 Tworzenie formularzy 125 85 8 87 Czym jest formularz? 126 88 Anatomia formularza 127 94 Wykorzystanie formularzy do wprowadzania danych 128 96 Filtrowanie formularzy 130 97 Zastosowanie szczegóBowego filtra 131 98 Korzystanie z kreatora formularzy 132 Tworzenie prostego formularza 135 U|ywanie dzielonych formularzy 136 Korzystanie z formularzy zawierajcych wiele elementów 139 Wyszukiwanie rekordów 140 Dostrajanie formularzy 141 9 Korzystanie z widoku projektu 142 Korzystanie z widoku ukBadu 143 Korzystanie z narzdzia Lista pól 144 Dodawanie nagBówków i stopek 145 Dodawanie formantów do formularza 146 Dostrajanie formantów 147 Zmiana wBa[ciwo[ci formantów 148 Tworzenie formantów wyliczanych 149 Zmiana kolejno[ci dostpu 150 Tworzenie formularzy z zakBadkami 151 Wykorzystanie przycisków 154 Tworzenie modalnych okien dialogowych 156 U|ywanie makr 160 Tworzenie raportów 161 10 Korzystanie z kreatora raportów 162 Tworzenie prostego raportu 166 Korzystanie z widoku projektu raportu 167 Dodawanie pól do raportu 168 Dodawanie formantów do raportu 169 Dodawanie nagBówków i stopek 170 Sortowanie i grupowanie danych 171 Drukowanie etykiet 172 Ustawianie niestandardowych rozmiarów etykiet 175 Korzystanie z podgldu wydruku 176 Drukowanie raportów 177 WysyBanie raportów poczt elektroniczn 178 WspóBdzielenie Accessa 179 11 Ochrona baz danych za pomoc haseB 180 Tworzenie baz danych ACCDE 182 Wykonywanie kopii zapasowych baz danych Accessa 183 PodziaB bazy danych 184 Interakcje z programem SharePoint 186 Skorowidz 187 Projektowanie 2 baz danych PrawidBowy projekt jest 28 Relacyjne bazy danych kluczem do sukcesu 30 Typy relacji i przydatno[ci bazy 32 Projekt bazy danych danych. Troch czasu po[wiconego na projekt 33 Zanim uruchomisz Accessa w odpowiednim momencie 34 Projektowanie tabel pozwoli unikn 35 Klucze podstawowe i obce poprawiania bBdów na 36 Doskonalenie projektu pózniejszym etapie. Relacyjne bazy danych Jest zupeBnie naturalne, |e w zetkniciu z niemiB perspektyw nauki nowego pakietu programowego wikszo[ osób gBo[no krzyczy i w [lepej panice szuka najbli|szego wyj[cia. Dotyczy to równie| nowicjuszy w [wie- cie relacyjnych baz danych. Wcale jednak nie musi tak by. Mówic prosto, relacyjna baza danych jest kolekcj tabel zawierajcych informacje powizane ze sob za pomoc wspólnych pól w taki sposób, aby mo|na byBo z nich korzysta bardziej efektywnie. Pojcie  relacyjna odnosi si do sposobu modelowania danych. To dziki tej wBa[ciwo[ci osign wiksz efektywno[. Wiele nieporozumieD wynika z ró|nej interpretacji poj. Powodem tego stanu w du|ym stopniu jest liberalne stosowanie w bran|y |argonu. Wikszo[ terminów jest u|ywana zamiennie. W niniejszym rozdziale omówimy ró|ne pojcia wystpujce w mode- lu relacyjnym oraz przedstawimy plan dziaBaD przy projektowaniu baz danych, tak by podzieli prac na mniejsze, Batwiejsze do przeBkni- cia  kski . Co to jest relacja? Pomimo technicznie brzmicej nazwy relacja nie jest niczym innym, jak tabel danych, podobn do zaprezentowanej na poni|szym zrzucie ekranu. Aby bazy danych Accessa mogBy by u|ywane wydajniej, zawieraj wicej ni| jedn tabel. Jak si przekonamy pózniej, aby baz danych mo|na byBo uzna za relacyjn, musi ona zawiera co najmniej dwie tabele. W niniejszej ksi|ce zamiast pojcia  relacja bdzie u|ywane mniej sformalizowane pojcie  tabela . W relacyjnej bazie danych tabela opiera si na okre[lonym podmiocie (jednostce). Zazwyczaj dotyczy ona konkretnego obiektu, na przykBad samochodu, i zawiera dane specyficzne dla tego obiektu. Na przykBad, w bankowej bazie danych mo|e by tabela Klient zawierajca dane klientów tego banku. Projektowanie baz danych 28 dokoDczenie... Inn tabel, jaka mo|e znalez si w bankowej bazie danych, jest Ra- chunek  tabela zawierajca informacje o typie rachunku posiadanego przez okre[lonego klienta wraz z bie|cym saldem. Tabela zawiera kolumny, których bardziej formalna nazwa to pola, oraz wiersze  bardziej oficjalnie nazywane rekordami. Logiczne zwizki wystpujce pomidzy tabelami s okre[lane terminem relacje. Pola Pole to techniczna nazwa kolumny. SBu|y ono do opisania specyficzne- go rodzaju danych. Na przykBad pole PBe, którego definicj zaprezento- wano poni|ej, przedstawia pBe klienta. W tabeli Samochód mogBoby si znalez pole Kolor opisujce kolor samochodu. Chocia| niektórzy mog skBania si do okre[lania pola terminem kolumna, mo|e to powodo- wa mylenie pól z innymi obiektami. W niniejszej ksi|ce bdziemy u|ywali pojcia pole. Rekordy Rekord nieformalnie okre[lany jest jako wiersz i zawiera wBa[ciwe dane zapisane w tabeli. O ile pole opisuje rodzaj danych w tabeli, na przykBad pBe klienta, o tyle rekord informuje, czy wybrany klient jest m|czyzn, czy kobiet. Je[li tabel uznamy za opis obiektu, na przykBad samochodu, to wiersze tabeli bd prezentowaBy egzemplarze poszczególnych samochodów. 29 Typy relacji Bez relacji baza danych nie byBaby relacyjna. To wydaje si oczywiste. Czym jednak dokBadnie s relacje? I dlaczego s one tak wa|ne? Relacja jest logicznym poBczeniem pomidzy tabelami. PoBczenie tworzy si pomidzy polem w jednej tabeli a polem w innej tabeli. Dla przykBadu, poni|ej zaprezentowano dwie tabele: OddziaB i Rachunek. W jednym oddziale banku jest wiele rachunków klientów. Wi|c pole NumerOddziaBu w tabeli OddziaB z polem NumerOddziaBu w tabeli Rachu- nek, tworzy si pomidzy tymi tabelami relacj jeden do wielu. Pomidzy tabelami mo|na zdefiniowa trzy ró|ne typy relacji:  jeden do jednego ,  jeden do wielu oraz  wiele do wielu . Ka|d z nich pokrótce opisano poni|ej. Jeden do wielu O tym typie relacji wspomniano w poprzednim punkcie. Korzysta si z niej w przypadku, gdy rekordowi jednej z tabel, okre[lanej terminem rodzic (w poprzednim przykBadzie t rol speBniaBa tabela OddziaB), odpowiada wicej ni| jeden rekord w innej tabeli, znanej jako dziecko (w przykBadzie  tabela Rachunek). Jeden do jednego Relacja tego typu wystpuje w przypadku, gdy istnieje bezpo[rednie powizanie pomidzy rekordem w jednej tabeli a rekordem w innej. PrzykBadowo, na pocztku nastpnej strony zaprezentowano dwie tabele: Klient i Adres. Zgodnie z logik reguB biznesu, powizan z t relacj, wybrany klient mo|e w danym momencie mie tylko jeden adres. Z tego wzgldu ka|demu rekordowi w tabeli Klient odpowiada dokBadnie jeden rekord w tabeli Adres. Projektowanie baz danych 30 dokoDczenie... Pomidzy powy|szymi tabelami zachodzi relacja jeden do jednego. Wiele do wielu W relacji wiele do wielu rekord w jednej tabeli mo|e mie wiele odpo- wiedników w drugiej tabeli, i na odwrót. W celu zamodelowania tego typu relacji w Accessie nale|y utworzy trzeci tabel, zwan tabel Bczc. PeBni ona rol po[rednika, który pozwala na zredukowanie relacji wiele do wielu do dwóch relacji jeden do wielu. PrzykBad zasto- sowania tabeli Bczcej zaprezentowano poni|ej. Na poni|szej ilustracji pokazano relacje wystpujce w typowej bazie danych. 31 Projekt bazy danych Dobry projekt bazy danych ma kluczowe znaczenie dla utworzenia bazy danych pozwalajcej na dokBadne i wydajne przechowywanie i po- bieranie informacji. Na szcz[cie, nauczenie si podstawowych zasad projektowania baz danych i stosowanie ich do wBasnych baz danych nie jest trudne. W niniejszym podrozdziale omówimy zagadnienia, które s niezbdne do samodzielnego projektowania baz danych, gdy| kompletny opis wszystkich zasad projektowania baz danych z powodzeniem zajBby oddzieln ksi|k. Korzy[ci wynikajce z dobrego projektu baz danych Istnieje wiele powodów, dla których warto po[wici troch czasu na uwa|ne zaplanowanie i przygotowanie projektu nowej bazy danych. Pozwala to nie tylko skoncentrowa si na problemie, który próbujemy rozwiza, lecz tak|e zmniejszy liczb bBdów popeBnianych podczas pracy z baz danych. Tym samym oszczdza to wielu kBopotów. Napra- wa zle zaprojektowanej bazy danych mo|e zaj wiele cennego czasu. Z kolei dobry projekt baz danych mo|e przyczyni si do: zmniejszenia ilo[ci redundantnych danych; zmniejszenia rozmiaru plików bazy danych; zwikszenia wydajno[ci bazy danych Accessa; zapewnienia dokBadno[ci danych zapisanych w bazie. Dlaczego warto d|y do zmniejszenia ilo[ci redundantnych danych? Cho niektórzy nie przywizuj do redundancji zbyt wielkiej wagi, nale|y za wszelk cen d|y do tego, by redundantnych danych byBo jak najmniej. Redundantne dane to informacje, które albo wystpuj w innej tabeli, albo takie, które Access mo|e obliczy, zatem w ogóle nie ma potrzeby zapisywania ich w bazie. Na przykBad, w tabeli mo|e wystpowa pole przeznaczone na dat urodzenia klienta oraz pole na jego wiek. W tym przypadku pole dla wieku jest zbdne, poniewa| wiek klienta mo|na obliczy, odejmujc dat urodzenia klienta od daty bie|cej. Nieco wikszy rozmiar pliku nie wydaje si spraw szczególnie szkodli- w. Istotnie, je[li w bazie danych nie ma zbyt wielu informacji, nie jest to trudno[. Jednak wraz ze zwikszeniem objto[ci danych zapisanych w bazie wzrasta ilo[ czasu, jakiego Access potrzebuje na wykonanie zapytania lub wygenerowanie raportu. Projektowanie baz danych 32 Zanim uruchomisz Accessa Cykl |ycia projektu bazy danych Ka|dy projekt wymaga planu. Tworzenie bazy danych Accessa nie jest pod tym wzgldem wyjtkowe. Dlatego wBa[nie je[li nikt nie straszy terminami, projektanci baz danych stosuj si do cyklu |ycia projektu bazy danych. Cykl taki przebiega nastpujco: identyfikacja wymagaD; projekt baz danych; utworzenie bazy danych w Accessie; utworzenie formularzy i raportów; testowanie. W tym rozdziale przyjrzymy si pierwszym trzem etapom cyklu |ycia projektu, poniewa| te elementy maj najwikszy wpByw na dokBadno[ i wydajno[ bazy danych. Podczas pracy z niniejsz ksi|k wyrobisz sobie wBasny pogld na to, w jaki sposób powinny dziaBa formularze oraz jakie kwerendy nale|y zdefiniowa. Identyfikacja wymagaD Pierwsz czynno[ci, jak nale|y wykona w ramach projektowania bazy danych, jest zidentyfikowanie jej wymagaD. Sprowadza si to do zadania sobie nastpujcego pytania:  Jakie czynno[ci powinna wyko- nywa baza danych? . Na pierwszy rzut oka pytanie mo|e wydawa si oczywiste, jednak znane s przypadki niepowodzeD wielu projektów komputerowych spowodowanych tym, |e projektanci nie wiedzieli, co bd tworzy. Przed przystpieniem do projektowania bazy danych nale|y zapyta jej przyszBych u|ytkowników, czego od niej oczekuj. Trzeba si dowie- dzie, jakich kwerend bd potrzebowa oraz jakie bd drukowa raporty. W tym procesie zidentyfikuje si wymagania u|ytkowe  szcze- góBowe potrzeby docelowych u|ytkowników bazy danych. Nale|y zanotowa uzyskane odpowiedzi i stworzy uporzdkowany zapis tego, jakie czynno[ci powinna wykonywa gotowa baza danych. Pracujc nad kolejnymi etapami cyklu |ycia projektu, trzeba wraca do tych wyma- gaD i sprawdza, czy projekt idzie we wBa[ciwym kierunku. 33 Projektowanie tabel Tabele jako podmioty Projektant bazy danych próbuje spojrze na pewien aspekt |ycia i zamodelowa go w sposób zgodny z Accessem. PrzykBadowo, projekt bazy danych dla ksigarni modeluje podmioty z |ycia, takie jak klienci ksigarni oraz jej sprzedawcy, a tak|e transakcje zawierane pomidzy Wskazówka nimi (np. zakup ksi|ki lub przyjcie zwrotu). Poniewa| tabele czsto Aby zwizualizowa proces projektowania, wyobraz sobie, |e ogldasz modeluj rzeczywiste film na temat fragmentu |ycia, o którym chcesz zapisa dane  na obiekty lub pojcia, przykBad o ksigarni  a nastpnie zatrzymujesz go. Zwró uwag, jacy nazwy tabel zawsze aktorzy bior udziaB w scenie oraz jakie dane o nich warto zapisa. powinny by rzeczowni- kami, na przykBad Klient Klient ma imi i adres  to bd pocztkowe dane w bazie. Dane te lub Samochód. mo|na wykorzysta do informowania klientów o specjalnych ofertach oraz aktualnych stanach magazynowych. Takie same dane nale|y zapi- sa o sprzedawcach pracujcych w ksigarni, tak by mo|na byBo wysBa do nich przelew. Warto równie| zapisa informacje o ksi|kach w sprzeda|y  na przy- kBad cen, tytuB i autora. Wyobraz sobie scen, któr chcesz zamodelowa. Zapisz nazwiska akto- rów oraz obiekty, które pojawiaj si w ujciu. Nazwa tabeli powinna odpowiada nazwie modelowanego podmiotu  na przykBad Klient. Dane dotyczce podmiotu, na przykBad Nazwisko oraz PBe, bd polami projektowanej tabeli. Projektowanie baz danych 34 Klucze podstawowe i obce Wybór kluczy podstawowych i obcych Jak opisano na stronie 30., tabele s powizane ze sob za pomoc Nie zapomnij wspólnych pól. W jaki sposób wybiera si te pola? W polu bdcym kluczem W ka|dej tabeli musi by pole, które w unikatowy sposób identyfikuje podstawowym nie mo|e indywidualne rekordy. Na przykBad, gdyby[my chcieli zidentyfikowa by warto[ci null. Ka|dy ka|dy rekord w tabeli Samochód, mogliby[my wykorzysta pole Numer- rekord tabeli w tym polu Rejestracyjny, poniewa| numer rejestracyjny jest unikatowym identy- musi zawiera jak[ warto[. fikatorem ka|dego pojazdu. Z kolei gdyby[my chcieli oznaczy ka|dy rekord w tabeli Pracownik, mogliby[my u|y pola NumerNIP, poniewa| numer NIP w swoisty sposób identyfikuje ka|d osob. Pole, które w unikatowy sposób identyfikuje indywidualne rekordy w ta- Strze| si beli, okre[la si terminem klucz podstawowy. Przyjrzyjmy si polom, Klucz podstawowy mo|e jakie wybrali[my dla naszych tabel, i zobaczmy, które z nich mo|e peBni si skBada z dwóch rol klucza podstawowego. W tabeli mo|e by tylko jedno pole peBnice lub wicej pól, które funkcj klucza podstawowego. Je|eli w tabeli znajduje si wicej takich po poBczeniu ze sob pól, prawdopodobnie trzeba bdzie podzieli tabel na dwie lub wicej. w unikatowy sposób W dalszej cz[ci niniejszego rozdziaBu wyja[nimy dlaczego. identyfikuj poszczególne rekordy w tabeli. Taki spo- sób definiowania kluczy podstawowych nie jest jednak dobrym pomy- sBem i nale|y go unika. Jedynym wyjtkiem od tej reguBy jest sytuacja, w której trzeba utworzy tabel Bczc w celu za- modelowania relacji wiele do wielu. Definiowanie relacji pomidzy dwoma tabelami polega na utworzeniu Nie zapomnij Bcza pomidzy kluczem podstawowym a kluczem obcym. Klucz obcy to pole w tabeli, które dokBadnie pasuje do klucza podstawowego Klucz obcy w tabeli nie innej tabeli. Na przykBad, gdyby[my chcieli zdefiniowa relacj po- musi mie takiej samej nazwy jak klucz podsta- midzy wspomnian wcze[niej tabel Samochód a inn tabel o nazwie wowy, z którym tworzy SamochodySprzedane, zawierajc rekordy wszystkich samochodów relacj. sprzedanych w okre[lonej placówce, w tej drugiej tabeli nale|aBoby umie[ci pole NumerRejestracyjny, które peBniBoby rol klucza obcego. Utworzenie relacji na podstawie dwóch pól NumerRejestracyjny pozwa- la na powizanie informacji w obu tabelach w logiczny sposób, majcy sens w rzeczywisto[ci. 35 Doskonalenie projektu Normalizacja Nie zapomnij Ostatni cz[ci procesu projektowania tabel jest normalizacja. Jest to proces stopniowego udoskonalania tabel w celu ochrony integralno- Je[li wydajno[ projekto- wanej bazy danych nie [ci i szczegóBowo[ci danych, które s w nich zapisane. Proces norma- jest szczególnie istotna lizacji umo|liwia równie| zaoszczdzenie miejsca na dysku, poniewa| albo je[li baza zawiera zmniejsza ryzyko redundancji danych (danych bezcelowo powtórzonych niewiele liczb bdz tabel, w innym miejscu). Normalizacja obejmuje restrukturyzacj projektu do normalizowanie tabel pierwszej, nastpnie drugiej, a na koniec trzeciej postaci normalnej. do postaci normalnych wy|szych ni| pierwsza nie Pierwsza posta normalna (1NF) jest konieczne. Wykonanie tej czynno[ci jest jednak W tej postaci pole mo|e zawiera tylko jedn warto[. Na przykBad, zalecane. adres nale|y podzieli na indywidualne pola. Nie wolno umieszcza caBego adresu w jednym polu. Druga posta normalna (2NF) Nie zapomnij Ka|de pole w tabeli musi w caBo[ci zale|e od klucza podstawowe- Je[li tabele nie speBniaj go. Na przykBad, w tabeli danych o pracownikach, w której kluczem reguB drugiej i trzeciej podstawowym jest NumerNIP oraz która zawiera dwa pola  Nazwisko postaci normalnej, nale|y i OddziaB, pole Nazwisko caBkowicie zale|y od pola NumerNIP. Jest tak je podzieli na dwie lub dlatego, |e pola Nazwisko i NumerNIP s ze sob nierozerwalnie zwi- wicej tabel speBniajcych postacie normalne. zane. Z kolei pole OddziaB nie jest bezpo[rednio zwizane z polem Nu- merNIP. Pracownik mo|e pracowa w dowolnym oddziale, ale zawsze bdzie miaB tylko jeden numer NIP. Trzecia posta normalna (3NF) W trzeciej postaci normalnej |adne z pól niebdcych kluczem pod- stawowym nie mo|e zale|e od innego pola, które nie jest kluczem podstawowym. Definiowanie reguB biznesu Decydowanie o tym, jakie tabele bd umieszczone w bazie danych oraz w jaki sposób bd ze sob powizane, to tylko jedna z cz[ci pro- jektu. W celu jak najwierniejszego zamodelowania scenariuszy z |ycia nale|y przeanalizowa reguBy, które nimi rzdz. ReguBy biznesu lub inaczej logika biznesowa to czsto nigdzie niezapisane i niepotwier- dzone zasady postpowania, którymi kierujemy si na co dzieD w pracy. Poza projektowaniem bazy danych nikt ich szczegóBowo nie analizuje, poniewa| niejednokrotnie wynikaj one ze zdrowego rozsdku. Na przykBad, jedna z reguB biznesu w banku brzmi:  limit debetu powi- nien wynosi 0,00 PLN lub mniej albo  numer rachunku musi skBada si z n cyfr . Nale|y zanotowa reguBy biznesu istotne dla bazy danych, tak by mo|- na byBo je zaimplementowa i zapewni ich przestrzeganie. Projektowanie baz danych 36

Wyszukiwarka

Podobne podstrony:
Access 07 PL Seria praktyk?27sp
Access 2007 PL Seria praktyk
Access 07 PL cwiczenia praktyczne cwac27
Access 10 PL cwiczenia praktyczne cwac10
Access 07 PL Formuly raporty kwerendy Rozwiazania w biznesie?27fo
Access 03 PL cwiczenia praktyczne Wydanie II cwa232
Excel 07 PL cwiczenia praktyczne cwex27
Office 2010 PL Seria praktyk of21sp
Word 07 PL cwiczenia praktyczne cwwo27
VBA dla Excela 07 PL? praktycznych przykladow vbae27

więcej podobnych podstron