Access 2007 PL.

Seria praktyk
Autor: Andrew Unsworth
Tumaczenie: Radosaw Meryk
ISBN: 978-83-246-2060-9
Tytu oryginau: Access 2007 in Easy Steps
(In Easy Steps)
Format: 180x235, stron: 200

Poznaj praktyczne moliwoci programu Access 2007!

Jak waciwie zaprojektowa baz danych?
Jak korzysta z szablonw?
Jak tworzy tabele i definiowa relacje midzy nimi?

Wbrew pozorom nie trzeba by specjalist, eby korzysta z Accessa! Jest to program
wyjtkowo przyjazny dla uytkownika, umoliwiajcy tworzenie baz danych
i zarzdzanie nimi bez potrzeby dogbnego poznawania jzyka SQL oraz
skomplikowanych rodowisk serwerowych. Aplikacja pozwala na zapisywanie danych
z wykorzystaniem formularzy, kierowanie zapyta do bazy, a take dzielenie danych
ze wsppracownikami za porednictwem sieci komputerowej.
Ksika Access 2007 PL. Seria praktyk zawiera zwizy i czytelny opis wszystkich
najwaniejszych funkcji tego programu, a take konkretne przykady i jasne instrukcje
zastosowania narzdzi Accessa. Kolorowe strony pozwalaj na szybkie odnalezienie
interesujcych Ci zagadnie. Dziki temu podrcznikowi poznasz podstawowe zasady
tworzenia dobrego projektu bazy danych oraz jej zaawansowane moliwoci. Nauczysz
si tworzy tabele, formularze i raporty, a take korzysta z kluczy podstawowych
i obcych. Bez problemu zbudujesz tak baz danych, ktra pozwoli Ci sprawnie
zarzdza informacjami.
Personalizacja Accessa 2007
Projektowanie baz danych
Relacyjne bazy danych
Klucze podstawowe i obce
Tworzenie tabel
Korzystanie z typw danych
Definiowanie relacji
Kwerendy
Korzystanie z SQL
Tworzenie i dostrajanie formularzy
Tworzenie raportw
Wspdzielenie Accessa

Naucz si korzysta z Accessa zachwyc Ci jego moliwoci!

Spis treci

Zaczynamy

Projektowanie baz danych

Tworzenie tabel

Czym jest Access 2007?

Ekran pocztkowy
Pasek narzdzi Szybki dostp
Korzystanie z Przycisku pakietu Office
Personalizacja Accessa 2007
Konwersja starszych baz danych
Korzystanie z serwisu Office Online
Szkolenia online
Pobieranie nowych materiaw
Pobieranie nowych szablonw
Korzystanie z szablonw
Korzystanie ze wstki
Korzystanie z Okienka nawigacji
Korzystanie z systemu pomocy

Relacyjne bazy danych

Typy relacji
Projekt bazy danych
Zanim uruchomisz Accessa
Projektowanie tabel
Klucze podstawowe i obce
Doskonalenie projektu

Okno tabeli
Korzystanie z szablonw tabel
Korzystanie z widoku arkusza danych
Dodawanie i usuwanie pl
Typy danych w widoku arkusza danych
Korzystanie z widoku projektu
Tworzenie tabeli
Wstawianie wiersza w widoku projektu
Usuwanie pola w widoku projektu
Okrelanie klucza podstawowego
Korzystanie z typw danych
Korzystanie z zacznikw

7
8
9
10
12
15
16
18
19
20
21
22
24
25
26

27
28
30
32
33
34
35
36

37
38
39
40
41
43
44
45
46
47
48
49
51

Okrelanie waciwoci pl
Korzystanie z regu weryfikacji poprawnoci danych
Tworzenie masek wprowadzania
Ustawianie domylnej wartoci
Korzystanie z indeksw
Tworzenie kolumny odnonika

Definiowanie relacji

Praca z danymi

Okno Relacje
Dodawanie tabel
Definiowanie relacji
Wizy integralnoci
Okrelanie waciwoci sprzenia
Sprzenia lewo- i prawostronne

Wprowadzanie danych
Wstawianie wierszy
Korzystanie ze Schowka
Kopiowanie i wklejanie danych
Kopiowanie danych bezporednio z Excela
Kopiowanie danych do Excela
Importowanie danych z Excela
Importowanie danych z Accessa
Poczenia z bazami danych Accessa
Zarzdzanie zadaniami importowania
Zbieranie danych za porednictwem poczty elektronicznej
Filtrowanie danych
Podsumowania kolumn
Sprawdzanie pisowni danych
Formatowanie danych

52
53
54
55
56
58

61
62
63
64
66
68
70

71
72
73
74
75
76
77
78
83
85
87
88
94
96
97
98

Kwerendy

Korzystanie z SQL

Tworzenie formularzy

Czym jest kwerenda?

Korzystanie z kreatora kwerend
Widok projektu kwerendy
Dodawanie kryteriw do kwerend
Kwerendy tworzone na podstawie wielu tabel
Definiowanie kryteriw dla liczb
Definiowanie kryteriw dla danych tekstowych
Definiowanie kwerend tworzcych tabele
Definiowanie kwerend doczajcych
Definiowanie kwerend aktualizujcych
Definiowanie kwerend usuwajcych dane

Posugiwanie si jzykiem SQL

Trzy odmiany jzyka SQL
Otwieranie okna SQL
Korzystanie z klauzuli SELECT
Korzystanie z klauzuli WHERE
Funkcje agregacji jzyka SQL
Tworzenie kwerend skadajcych

Czym jest formularz?

Anatomia formularza
Wykorzystanie formularzy do wprowadzania danych
Filtrowanie formularzy
Zastosowanie szczegowego filtra
Korzystanie z kreatora formularzy
Tworzenie prostego formularza
Uywanie dzielonych formularzy
Korzystanie z formularzy zawierajcych wiele elementw
Wyszukiwanie rekordw

101
102
103
106
108
109
110
111
112
114
115
116

117
118
119
120
121
122
123
124

125
126
127
128
130
131
132
135
136
139
140

Dostrajanie formularzy
Korzystanie z widoku projektu
Korzystanie z widoku ukadu
Korzystanie z narzdzia Lista pl
Dodawanie nagwkw i stopek
Dodawanie formantw do formularza
Dostrajanie formantw
Zmiana waciwoci formantw
Tworzenie formantw wyliczanych
Zmiana kolejnoci dostpu
Tworzenie formularzy z zakadkami
Wykorzystanie przyciskw
Tworzenie modalnych okien dialogowych
Uywanie makr

10

Tworzenie raportw

11

Wspdzielenie Accessa

Korzystanie z kreatora raportw

Tworzenie prostego raportu
Korzystanie z widoku projektu raportu
Dodawanie pl do raportu
Dodawanie formantw do raportu
Dodawanie nagwkw i stopek
Sortowanie i grupowanie danych
Drukowanie etykiet
Ustawianie niestandardowych rozmiarw etykiet
Korzystanie z podgldu wydruku
Drukowanie raportw
Wysyanie raportw poczt elektroniczn

Ochrona baz danych za pomoc hase

Tworzenie baz danych ACCDE
Wykonywanie kopii zapasowych baz danych Accessa
Podzia bazy danych
Interakcje z programem SharePoint

Skorowidz

141
142
143
144
145
146
147
148
149
150
151
154
156
160

161
162
166
167
168
169
170
171
172
175
176
177
178

179
180
182
183
184
186

187

Projektowanie
baz danych
28 Relacyjne bazy danych

Prawidowy projekt jest

kluczem do sukcesu

30 Typy relacji

danych. Troch czasu

32 Projekt bazy danych

powiconego na projekt

33 Zanim uruchomisz Accessa

w odpowiednim momencie

34 Projektowanie tabel

35 Klucze podstawowe i obce

36 Doskonalenie projektu

i przydatnoci bazy

pozwoli unikn
poprawiania bdw na
pniejszym etapie.

Projektowanie baz danych

Relacyjne bazy danych

Jest zupenie naturalne, e w zetkniciu z niemi perspektyw nauki
nowego pakietu programowego wikszo osb gono krzyczy i w lepej
panice szuka najbliszego wyjcia. Dotyczy to rwnie nowicjuszy w wiecie relacyjnych baz danych. Wcale jednak nie musi tak by. Mwic
prosto, relacyjna baza danych jest kolekcj tabel zawierajcych informacje
powizane ze sob za pomoc wsplnych pl w taki sposb, aby mona
byo z nich korzysta bardziej efektywnie. Pojcie relacyjna odnosi
si do sposobu modelowania danych. To dziki tej waciwoci osign
wiksz efektywno. Wiele nieporozumie wynika z rnej interpretacji
poj. Powodem tego stanu w duym stopniu jest liberalne stosowanie
w brany argonu. Wikszo terminw jest uywana zamiennie.
W niniejszym rozdziale omwimy rne pojcia wystpujce w modelu relacyjnym oraz przedstawimy plan dziaa przy projektowaniu baz
danych, tak by podzieli prac na mniejsze, atwiejsze do przeknicia kski.

28

Co to jest relacja?
Pomimo technicznie brzmicej nazwy relacja nie jest niczym innym,
jak tabel danych, podobn do zaprezentowanej na poniszym zrzucie
ekranu.

Aby bazy danych Accessa mogy by uywane wydajniej, zawieraj

wicej ni jedn tabel. Jak si przekonamy pniej, aby baz danych
mona byo uzna za relacyjn, musi ona zawiera co najmniej dwie
tabele. W niniejszej ksice zamiast pojcia relacja bdzie uywane
mniej sformalizowane pojcie tabela.
W relacyjnej bazie danych tabela opiera si na okrelonym podmiocie
(jednostce). Zazwyczaj dotyczy ona konkretnego obiektu, na przykad
samochodu, i zawiera dane specyficzne dla tego obiektu. Na przykad,
w bankowej bazie danych moe by tabela Klient zawierajca dane
klientw tego banku.

dokoczenie...
Inn tabel, jaka moe znale si w bankowej bazie danych, jest Rachunek tabela zawierajca informacje o typie rachunku posiadanego
przez okrelonego klienta wraz z biecym saldem.
Tabela zawiera kolumny, ktrych bardziej formalna nazwa to pola, oraz
wiersze bardziej oficjalnie nazywane rekordami. Logiczne zwizki
wystpujce pomidzy tabelami s okrelane terminem relacje.

Pola
Pole to techniczna nazwa kolumny. Suy ono do opisania specyficznego rodzaju danych. Na przykad pole Pe, ktrego definicj zaprezentowano poniej, przedstawia pe klienta. W tabeli Samochd mogoby si
znale pole Kolor opisujce kolor samochodu. Chocia niektrzy mog
skania si do okrelania pola terminem kolumna, moe to powodowa mylenie pl z innymi obiektami. W niniejszej ksice bdziemy
uywali pojcia pole.

29

Rekordy
Rekord nieformalnie okrelany jest jako wiersz i zawiera waciwe
dane zapisane w tabeli. O ile pole opisuje rodzaj danych w tabeli,
naprzykad pe klienta, o tyle rekord informuje, czy wybrany klient
jest mczyzn, czy kobiet. Jeli tabel uznamy za opis obiektu, na
przykad samochodu, to wiersze tabeli bd prezentoway egzemplarze
poszczeglnych samochodw.

Projektowanie baz danych

Typy relacji
Bez relacji baza danych nie byaby relacyjna. To wydaje si oczywiste.
Czym jednak dokadnie s relacje? I dlaczego s one tak wane?
Relacja jest logicznym poczeniem pomidzy tabelami. Poczenie
tworzy si pomidzy polem w jednej tabeli a polem w innej tabeli.
Dlaprzykadu, poniej zaprezentowano dwie tabele: Oddzia i Rachunek.

30

W jednym oddziale banku jest wiele rachunkw klientw. Wic pole

NumerOddziau w tabeli Oddzia z polem NumerOddziau w tabeli Rachunek, tworzy si pomidzy tymi tabelami relacj jeden do wielu.
Pomidzy tabelami mona zdefiniowa trzy rne typy relacji: jeden
do jednego, jeden do wielu oraz wiele do wielu. Kad z nich
pokrtce opisano poniej.

Jeden do wielu
O tym typie relacji wspomniano w poprzednim punkcie. Korzysta si
z niej w przypadku, gdy rekordowi jednej z tabel, okrelanej terminem
rodzic (w poprzednim przykadzie t rol speniaa tabela Oddzia),
odpowiada wicej ni jeden rekord w innej tabeli, znanej jako dziecko
(w przykadzie tabela Rachunek).

Jeden do jednego
Relacja tego typu wystpuje w przypadku, gdy istnieje bezporednie
powizanie pomidzy rekordem w jednej tabeli a rekordem w innej.
Przykadowo, na pocztku nastpnej strony zaprezentowano dwie
tabele: Klient i Adres. Zgodnie z logik regu biznesu, powizan z t
relacj, wybrany klient moe w danym momencie mie tylko jeden
adres. Z tego wzgldu kademu rekordowi w tabeli Klient odpowiada
dokadnie jeden rekord w tabeli Adres.

dokoczenie...

Pomidzy powyszymi tabelami zachodzi relacja jeden do jednego.

Wiele do wielu
W relacji wiele do wielu rekord w jednej tabeli moe mie wiele odpowiednikw w drugiej tabeli, i na odwrt. W celu zamodelowania tego
typu relacji w Accessie naley utworzy trzeci tabel, zwan tabel
czc. Peni ona rol porednika, ktry pozwala na zredukowanie
relacji wiele do wielu do dwch relacji jeden do wielu. Przykad zastosowania tabeli czcej zaprezentowano poniej.

31

Na poniszej ilustracji pokazano relacje wystpujce w typowej bazie

danych.

Projektowanie baz danych

Projekt bazy danych

Dobry projekt bazy danych ma kluczowe znaczenie dla utworzenia
bazy danych pozwalajcej na dokadne i wydajne przechowywanie i pobieranie informacji. Na szczcie, nauczenie si podstawowych zasad
projektowania baz danych i stosowanie ich do wasnych baz danych nie
jest trudne.
W niniejszym podrozdziale omwimy zagadnienia, ktre s niezbdne
do samodzielnego projektowania baz danych, gdy kompletny opis
wszystkich zasad projektowania baz danych z powodzeniem zajby
oddzieln ksik.

Korzyci wynikajce z dobrego projektu baz danych

32

Istnieje wiele powodw, dla ktrych warto powici troch czasu na

uwane zaplanowanie i przygotowanie projektu nowej bazy danych.
Pozwala to nie tylko skoncentrowa si na problemie, ktry prbujemy
rozwiza, lecz take zmniejszy liczb bdw popenianych podczas
pracy z baz danych. Tym samym oszczdza to wielu kopotw. Naprawa le zaprojektowanej bazy danych moe zaj wiele cennego czasu.
Z kolei dobry projekt baz danych moe przyczyni si do:

zmniejszenia iloci redundantnych danych;

zmniejszenia rozmiaru plikw bazy danych;

zwikszenia wydajnoci bazy danych Accessa;

zapewnienia dokadnoci danych zapisanych w bazie.

Dlaczego warto dy do zmniejszenia iloci

redundantnych danych?
Cho niektrzy nie przywizuj do redundancji zbyt wielkiej wagi,
naley za wszelk cen dy do tego, by redundantnych danych byo
jak najmniej. Redundantne dane to informacje, ktre albo wystpuj
w innej tabeli, albo takie, ktre Access moe obliczy, zatem w ogle
nie ma potrzeby zapisywania ich w bazie.
Na przykad, w tabeli moe wystpowa pole przeznaczone na dat
urodzenia klienta oraz pole na jego wiek. W tym przypadku pole dla
wieku jest zbdne, poniewa wiek klienta mona obliczy, odejmujc
dat urodzenia klienta od daty biecej.
Nieco wikszy rozmiar pliku nie wydaje si spraw szczeglnie szkodliw. Istotnie, jeli w bazie danych nie ma zbyt wielu informacji, nie jest
to trudno. Jednak wraz ze zwikszeniem objtoci danych zapisanych
w bazie wzrasta ilo czasu, jakiego Access potrzebuje na wykonanie
zapytania lub wygenerowanie raportu.

Zanim uruchomisz Accessa

Cykl ycia projektu bazy danych
Kady projekt wymaga planu. Tworzenie bazy danych Accessa nie jest
pod tym wzgldem wyjtkowe. Dlatego wanie jeli nikt nie straszy
terminami, projektanci baz danych stosuj si do cyklu ycia projektu
bazy danych. Cykl taki przebiega nastpujco:

identyfikacja wymaga;

projekt baz danych;

utworzenie bazy danych w Accessie;

utworzenie formularzy i raportw;

testowanie.

W tym rozdziale przyjrzymy si pierwszym trzem etapom cyklu ycia

projektu, poniewa te elementy maj najwikszy wpyw na dokadno
i wydajno bazy danych. Podczas pracy z niniejsz ksik wyrobisz
sobie wasny pogld na to, w jaki sposb powinny dziaa formularze
oraz jakie kwerendy naley zdefiniowa.

Identyfikacja wymaga

Przed przystpieniem do projektowania bazy danych naley zapyta jej

przyszych uytkownikw, czego od niej oczekuj. Trzeba si dowiedzie, jakich kwerend bd potrzebowa oraz jakie bd drukowa
raporty.
W tym procesie zidentyfikuje si wymagania uytkowe szczegowe potrzeby docelowych uytkownikw bazy danych. Naley
zanotowa uzyskane odpowiedzi i stworzy uporzdkowany zapis tego,
jakie czynnoci powinna wykonywa gotowa baza danych. Pracujc nad
kolejnymi etapami cyklu ycia projektu, trzeba wraca do tych wymaga i sprawdza, czy projekt idzie we waciwym kierunku.

33

Pierwsz czynnoci, jak naley wykona w ramach projektowania

bazy danych, jest zidentyfikowanie jej wymaga. Sprowadza si to do
zadania sobie nastpujcego pytania: Jakie czynnoci powinna wykonywa baza danych?. Na pierwszy rzut oka pytanie moe wydawa si
oczywiste, jednak znane s przypadki niepowodze wielu projektw
komputerowych spowodowanych tym, e projektanci nie wiedzieli,
cobd tworzy.

Projektowanie baz danych

Projektowanie tabel
Tabele jako podmioty

Wskazwka
Poniewa tabele czsto
modeluj rzeczywiste
obiekty lub pojcia,
nazwy tabel zawsze
powinny by rzeczownikami, na przykad Klient
lubSamochd.

Projektant bazy danych prbuje spojrze na pewien aspekt ycia

i zamodelowa go w sposb zgodny z Accessem. Przykadowo, projekt
bazy danych dla ksigarni modeluje podmioty z ycia, takie jak klienci
ksigarni oraz jej sprzedawcy, a take transakcje zawierane pomidzy
nimi (np. zakup ksiki lub przyjcie zwrotu).
Aby zwizualizowa proces projektowania, wyobra sobie, e ogldasz
film na temat fragmentu ycia, o ktrym chcesz zapisa dane na
przykad o ksigarni a nastpnie zatrzymujesz go. Zwr uwag, jacy
aktorzy bior udzia w scenie oraz jakie dane o nich warto zapisa.
Klient ma imi i adres to bd pocztkowe dane w bazie. Dane te
mona wykorzysta do informowania klientw o specjalnych ofertach
oraz aktualnych stanach magazynowych. Takie same dane naley zapisa o sprzedawcach pracujcych w ksigarni, tak by mona byo wysa
do nich przelew.

34

Warto rwnie zapisa informacje o ksikach w sprzeday na przykad cen, tytu i autora.

Wyobra sobie scen, ktr chcesz zamodelowa. Zapisz nazwiska aktorw oraz obiekty, ktre pojawiaj si w ujciu.
Nazwa tabeli powinna odpowiada nazwie modelowanego podmiotu
na przykad Klient. Dane dotyczce podmiotu, na przykad Nazwisko
oraz Pe, bd polami projektowanej tabeli.

Klucze podstawowe i obce

Wybr kluczy podstawowych i obcych
Jak opisano na stronie 30., tabele s powizane ze sob za pomoc
wsplnych pl. W jaki sposb wybiera si te pola?
W kadej tabeli musi by pole, ktre w unikatowy sposb identyfikuje
indywidualne rekordy. Na przykad, gdybymy chcieli zidentyfikowa
kady rekord w tabeli Samochd, moglibymy wykorzysta pole NumerRejestracyjny, poniewa numer rejestracyjny jest unikatowym identyfikatorem kadego pojazdu. Z kolei gdybymy chcieli oznaczy kady
rekord w tabeli Pracownik, moglibymy uy pola NumerNIP, poniewa
numer NIP w swoisty sposb identyfikuje kad osob.
Pole, ktre w unikatowy sposb identyfikuje indywidualne rekordy w tabeli, okrela si terminem klucz podstawowy. Przyjrzyjmy si polom,
jakie wybralimy dla naszych tabel, i zobaczmy, ktre z nich moe peni
rol klucza podstawowego. W tabeli moe by tylko jedno pole penice
funkcj klucza podstawowego. Jeeli w tabeli znajduje si wicej takich
pl, prawdopodobnie trzeba bdzie podzieli tabel na dwie lub wicej.
W dalszej czci niniejszego rozdziau wyjanimy dlaczego.

W polu bdcym kluczem

podstawowym nie moe
by wartoci null. Kady
rekord tabeli w tym polu
musi zawiera jak
warto.

Strze si
Klucz podstawowy moe
si skada z dwch
lub wicej pl, ktre
po poczeniu ze sob
w unikatowy sposb
identyfikuj poszczeglne
rekordy w tabeli. Taki sposb definiowania kluczy
podstawowych nie jest
jednak dobrym pomysem i naley go unika.
Jedynym wyjtkiem od
tej reguy jest sytuacja,
w ktrej trzeba utworzy
tabel czc w celu zamodelowania relacji wiele
do wielu.

Nie zapomnij
Klucz obcy w tabeli nie
musi mie takiej samej
nazwy jak klucz podstawowy, z ktrym tworzy
relacj.

35

Definiowanie relacji pomidzy dwoma tabelami polega na utworzeniu

cza pomidzy kluczem podstawowym a kluczem obcym. Klucz obcy
to pole w tabeli, ktre dokadnie pasuje do klucza podstawowego
innej tabeli. Na przykad, gdybymy chcieli zdefiniowa relacj pomidzy wspomnian wczeniej tabel Samochd a inn tabel o nazwie
SamochodySprzedane, zawierajc rekordy wszystkich samochodw
sprzedanych w okrelonej placwce, w tej drugiej tabeli naleaoby
umieci pole NumerRejestracyjny, ktre penioby rol klucza obcego.
Utworzenie relacji na podstawie dwch pl NumerRejestracyjny pozwala na powizanie informacji w obu tabelach w logiczny sposb, majcy
sens w rzeczywistoci.

Nie zapomnij

Projektowanie baz danych

Doskonalenie projektu
Nie zapomnij
Jeli wydajno projektowanej bazy danych nie
jest szczeglnie istotna
albo jeli baza zawiera
niewiele liczb bd tabel,
normalizowanie tabel
do postaci normalnych
wyszych ni pierwsza nie
jest konieczne. Wykonanie
tej czynnoci jest jednak
zalecane.

36

Nie zapomnij
Jeli tabele nie speniaj
regu drugiej i trzeciej
postaci normalnej, naley
je podzieli na dwie lub
wicej tabel speniajcych
postacie normalne.

Normalizacja
Ostatni czci procesu projektowania tabel jest normalizacja. Jest
to proces stopniowego udoskonalania tabel w celu ochrony integralnoci i szczegowoci danych, ktre s w nich zapisane. Proces normalizacji umoliwia rwnie zaoszczdzenie miejsca na dysku, poniewa
zmniejsza ryzyko redundancji danych (danych bezcelowo powtrzonych
w innym miejscu). Normalizacja obejmuje restrukturyzacj projektu do
pierwszej, nastpnie drugiej, a na koniec trzeciej postaci normalnej.

Pierwsza posta normalna (1NF)

W tej postaci pole moe zawiera tylko jedn warto. Na przykad,
adres naley podzieli na indywidualne pola. Nie wolno umieszcza
caego adresu w jednym polu.

Druga posta normalna (2NF)

Kade pole w tabeli musi w caoci zalee od klucza podstawowego. Na przykad, w tabeli danych o pracownikach, w ktrej kluczem
podstawowym jest NumerNIP oraz ktra zawiera dwa pola Nazwisko
i Oddzia, pole Nazwisko cakowicie zaley od pola NumerNIP. Jest tak
dlatego, e pola Nazwisko i NumerNIP s ze sob nierozerwalnie zwizane. Z kolei pole Oddzia nie jest bezporednio zwizane z polem NumerNIP. Pracownik moe pracowa w dowolnym oddziale, ale zawsze
bdzie mia tylko jeden numer NIP.

Trzecia posta normalna (3NF)

W trzeciej postaci normalnej adne z pl niebdcych kluczem podstawowym nie moe zalee od innego pola, ktre nie jest kluczem
podstawowym.

Definiowanie regu biznesu

Decydowanie o tym, jakie tabele bd umieszczone w bazie danych
oraz w jaki sposb bd ze sob powizane, to tylko jedna z czci projektu. W celu jak najwierniejszego zamodelowania scenariuszy z ycia
naley przeanalizowa reguy, ktre nimi rzdz. Reguy biznesu lub
inaczej logika biznesowa to czsto nigdzie niezapisane i niepotwierdzone zasady postpowania, ktrymi kierujemy si na co dzie w pracy.
Poza projektowaniem bazy danych nikt ich szczegowo nie analizuje,
poniewa niejednokrotnie wynikaj one ze zdrowego rozsdku.
Na przykad, jedna z regu biznesu w banku brzmi: limit debetu powinien wynosi 0,00 PLN lub mniej albo numer rachunku musi skada
si z n cyfr.
Naley zanotowa reguy biznesu istotne dla bazy danych, tak by mona byo je zaimplementowa i zapewni ich przestrzeganie.