POLITECHNIKA LUBELSKA

WYDZIAŁ ELEKTROTECHNIKI I INFORMATYKI

INSTYTUT PODSTAW ELEKTROTECHNIKI
I ELEKTROTECHNOLOGII

STUDIA PODYPLOMOWE

“INFORMATYKA TECHNICZNA”

Wykorzystywanie możliwości MS Access
do zaprojektowania relacyjnej bazy danych
Archidiecezji Lubelskiej

Wykonawca: Promotor:

mgr inż. Jarosław Diatczyk

Lublin 2006

Spis treści

1. Wstęp 3

2. Projekt logiczny relacyjnej bazy danych 4
   - określenie zagadnienia 4
   - definicja celu 4
   - założenia wstępne 4

3. Struktury danych 5

- ostateczna lista tabel 5

- listy pól tabel 6

- specyfikacja atrybutów pól 7

4. Relacje 10
   - tabela krzyżowa 10
   - implementacyjny diagram związków encji 10

5. Integralność bazy danych 12
   - reguła integralności danych 12
   - reguła integralności relacji 13
   - reguła integralności wymagająca wprowadzenia tabeli walidacji 14
   - aplikacyjna reguła integralności 14

6. Diagramy i specyfikacje perspektyw 15

7. Projekt fizyczny 19

8. Implementacja 20

9. Kwerendy 21

10. Formularze 22

11. Użytkowanie bazy danych 23

12. Podsumowanie 24

13. Bibliografia 25

1. Wstęp

Bazą danych nazywamy każdy zbiór danych przechowywany przez długi czas. W informatyce za bazę danych należy uznać zbiór danych zorganizowany przez system zarządzania bazą danych. Pół wieku temu to jest u początków baz danych systemy zarządzania bazami danych sprowadzały się do zwykłych systemów plików. Rozwiązanie takie dawało możliwość gromadzenia bardzo dużych ilości danych zabezpieczając je przed zniszczeniem i niepowołanym dostępem. Uzyskanie informacji i dostęp do tak usystematyzowanych danych był jednak ograniczony przez konieczność znajomości lokalizacji żądanych danych i brak sterowania jednoczesnym dostępem do bazy danych więcej niż jednego użytkownika [1].

Przełomowy w rozwoju systemów zarządzania bazami danych okazał się rok 1970, kiedy E.F. Codd opublikował pracę, która położyła fundament pod najbardziej popularny z modeli danych [5]. Odtąd wewnątrz bazy danych mogła powstawać złożona struktura danych [1]. Dane stanowiące strukturalny zbiór są przechowywane w oddzielnych tabelach, zamiast umieszczania ich w jednym wielkim magazynie [4]. Dostęp do danych poprzez zastosowanie różnorodnych zapytań w dodatku bez konieczności posiadania wiedzy na temat wewnętrznej struktury bazy danych stał się natychmiastowy. W odróżnieniu od wcześniejszych baz danych pojawiła się możliwość pełnego dostępu do danych dla wielu użytkowników jednocześnie [6].
Celem pracy jest wykonanie projektu relacyjnej bazy danych gromadzącej dane wykorzystywane do prowadzenia statystyk kościelnych. Pracę (wykonanie projektu) można podzielić na dwa zasadnicze etapy. Pierwszy etap polega na skonstruowaniu projektu logicznego uwzględniającego cel, jakiemu ma służyć baza danych. Projekt logiczny określa struktury danych, powiązania między tabelami i perspektywy danych. Drugi etap polega na zaprojektowaniu aplikacji obsługującej bazę danych. Projektowanie aplikacji sprowadza się do określenia wymaganych formularzy, kwerend i raportów. 2. Projekt logiczny relacyjnej bazy danych.

Logiczne projektowanie bazy danych ma na celu skonstruowanie modelu reguł działalności stosowanych przez podmiot - przyszłego użytkownika bazy danych. Projektowania logicznego nie można uzależniać od przyszłej implementacji [6]. Tylko w takim przypadku możliwa jest do przeprowadzenia pełna analiza zadań, jakie ma spełniać tworzona baza danych. Zatem proces tworzenia bazy danych rozpoczynamy od określenia zagadnienia np.:

Archidiecezja Lubelska gromadzi dane dotyczące frekwencji na Mszach św i przystępujących do Komunii w poszczególnych parafiach należących do określonych dekanatów Archidiecezji Lubelskiej. Dane gromadzi się uwzględniając godziny Mszy św. i podział na płeć. Gromadzone są także dane dotyczące liczby mieszkańców i wiernych danej parafii.

Następnie formułujemy definicję celu [5]. Powinna ona być krótka, zwięzła, zrozumiała i bez zbędnych szczegółów. W przypadku naszej bazy będzie to:

Celem bazy danych Archidiecezji Lubelskiej jest wykorzystanie danych do prowadzenia statystyk kościelnych.

Kolejny krok to sprecyzowanie założeń wstępnych, czyli zadań, jakie ma spełniać baza danych [5]. Założenia wstępne określające, jakie dane ma przechowywać baza danych muszą być przedstawione w sposób zwięzły, zrozumiały, ponadto każde z założeń może definiować tylko jedno zadanie np.:

• Nazwy dekanatów.

• Nazwy miejscowości - siedziby parafii.

• Kategorię danej miejscowości (miasto/wieś).

• Nazwy parafii.

• Liczbę mieszkańców parafii.

• Liczbę wiernych w parafii.

• Datę obowiązywania.

• Liczbę kobiet uczestniczących w danej Mszy św.

• Liczbę mężczyzn uczestniczących w danej Mszy św.

• Liczbę kobiet przyjmujących Komunię podczas danej Mszy św.

• Liczbę mężczyzn przyjmujących Komunię podczas danej Mszy św.

• Godziny rozpoczęcia poszczególnych Mszy św.

3. Struktury danych

Dokonując analizy założeń wstępnych rozpoczynamy kolejny etap tworzenia relacyjnej bazy danych. Definiowanie listy tabel polega na ulokowaniu poszczególnych zadań, czyli określonych danych we właściwej grupie i utworzenie dla nich właściwych tabel [6]. Tworzone tabele mogą być następującego typu:

• dane - zawierające tematy zawarte w założeniach wstępnych,

• połączenia - występują gdy między tabelami zachodzą relacje wiele do wielu,

• podzbiór - szczegółowy opis tematu jako dodatkowe pole tematu tabeli danych,

• walidacja - zapewnia integralność danych.

Początkowo każda pozycja na liście tabel to tabela danych. Tabele innego typu mogą się pojawiać jako przekształcenie tabel danych lub tworzenie nowych dopiero po zdefiniowaniu relacji, wprowadzeniu reguł integralności danych i przyporządkowaniu poszczególnym polom zadań. Sprecyzowanie listy tabel zależne jest w głównej mierze od przyjętych założeń wstępnych, ale także od inwencji projektanta. Baza danych tworzona dla potrzeb prowadzenia statystyk kościelnych może składać się z następujących tabel:

Nazwa

MSZE

Typ

Dane

Opis

Liczba kobiet, liczba mężczyzn uczestniczących we Mszy oraz liczba kobiet i liczba mężczyzn przyjmujących Komunię o określonej godzinie i w danej parafii. Informacja o uczestniczących we Mszy i przystępujących do Komunii jest podstawowym celem przeprowadzania liczenia wiernych w kościołach.

PARAFIE

Dane

Pełna nazwa parafii, nazwa miejscowości i kategoria miejscowości będącej siedzibą parafii.

WIERNI

Dane

Liczebność mieszkańców i wiernych z terenu parafii według stanu na dany rok. Informacja o liczebności parafii w danym roku jest konieczna dla określenia procentowego wskaźnika uczestniczących we Mszy. Informacja o liczebności wiernych w parafiach jest konieczna do uzyskania informacji o liczebności wiernych na poziomie dekanatów i diecezji. Liczebność mieszkańców i wiernych w kolejnych latach ulega zmianom.

Nazwa Typ Opis

DEKANATY

Walidacja

Pełne nazwy dekanatów występujących na terenie Archidiecezji Lubelskiej. Spis dekanatów jest konieczny dla prawidłowego określenia przynależności parafii i stosowania nazw dekanatów zgodnie ze strukturą organizacyjną Archidiecezji Lubelskiej.

Do zdefiniowania relacji konieczne jest wybranie ze zbioru kluczy kandydujących klucza głównego i połączenie go z kluczem obcym w kolejnej tabeli. Kluczem kandydującym określamy kolumnę lub zbiór kolumn mogących występować jako jednoznaczny identyfikator wierszy tabeli. Kluczem głównym określamy jedną lub więcej kolumn tabeli, w której wartość jednoznacznie identyfikuje każdy z wierszy tabeli, może to być także kolumna dodana. Klucze obce umożliwiają łączenie danych z różnych tabel. Wartości, jakie czerpie klucz obcy muszą pochodzić z tej samej dziedziny, co klucz główny. Po wybraniu lub utworzeniu kluczy głównych i obcych przystępujemy do określenia ostatecznej listy pól tabel. Dla naszej bazy danych będą to:

• Tabela MSZE: ID_mszy (klucz podstawowy), ID_parafii (klucz obcy), Godzina_mszy, Frekwencja_k, Frekwencja_m, Komunia_k, Komunia_m.
  

• Tabela PARAFIE: ID_parafii (klucz podstawowy), Dekanat (klucz obcy), Nazwa_parafii, Miejscowość, Kategoria_miejscowości.
  

• Tabela WIERNI: ID_wiernych (klucz podstawowy), ID_parafii (klucz obcy), Liczba_mieszkańców, Liczba_katolików, Data_obowiązywania.
  

• Tabela DEKANATY: ID_dekanatu (klucz podstawowy), Nazwa_dekanatu.

Poprawne utworzenie tabel i wskazanie właściwych kolumn jako klucze główne i obce zapewnia integralność bazy danych na poziomie tabel. Niemniej ważna jest także integralność na poziomie pól. Specyfikacja atrybutów pól daje gwarancję spójności i wiarygodności danych oraz przyśpiesza wykonanie projektu fizycznego. W projekcie bazy danych specyfikację atrybutów pól najkorzystniej przedstawić w formie tabelarycznej dzieląc wartości atrybutów pól na część dotyczącą atrybutów fizycznych oraz na część dotyczącą atrybutów logicznych. Dla zobrazowania przynajmniej części możliwych do wystąpienia kombinacji atrybutów pól warto przedstawić niektóre z pól występujących w naszej bazie danych, specyfikacja atrybutów wybranych pól będzie następująca:

Pole:	ID_mszy	Tabela:	MSZE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	autonumerowanie	Klucz:	podstawowy
Nowe wartości:	przyrostowy	Unikalność:	tak
		Wartość wymagana:	tak
		Wartości zerowe:	zabronione
		Źródło wartości:	system
		Wartość domyślna:	autoinkrementacja

Tab. 1 Specyfikacja atrybutów pola ID_mszy w tabeli MSZE.

Zatem pole dodane ID_mszy w tabeli MSZE zawiera dane typu „autonumer”, jest kluczem podstawowym, wartość tego pola jest unikalna, wymagana i nie może przyjmować wartości „null” (brak wartości), natomiast źródłem wartości tego pola jest system obsługujący bazę danych.

Pole:	ID_parafii	Tabela	MSZE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	liczba	Klucz:	Obcy
Miejsca dziesiętne:	0	Unikalność:	nie
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik

Tab. 2 Specyfikacja atrybutów ID_parafii w tabeli MSZE.

Pole dodane ID_parafii w tabeli MSZE zawiera dane typu „liczba”, jest kluczem obcym, wartość tego pola nie jest unikalna, ale jest wymagana i nie może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik.

Pole:	Godzina_mszy	Tabela:	MSZE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	godzina	Klucz:	brak
Maska wprowadzania:	00:00	Unikalność:	nie
		Wartość wymagana:	nie
		Wartości zerowe:	tak
		Źródło wartości:	użytkownik

Tab. 3 Specyfikacja atrybutów pola Godzina_mszy w tabeli MSZE.

Pole Godzina_mszy w tabeli MSZE zawiera dane typu „godzina”, nie jest kluczem, wartość tego pola nie jest unikalna, nie jest wymagana i może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik.

Pole:	Frekwencja_k	Tabela:	MSZE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	liczba	Klucz:	brak
Miejsca dziesiętne:	0	Unikalność:	nie
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik

Tab. 4 Specyfikacja atrybutów pola Frekwencja_k w tabeli MSZE.

Pole Frekwencja_k w tabeli MSZE zawiera dane typu „liczba”, nie jest kluczem, wartość tego pola nie jest unikalna, ale jest wymagana i nie może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik.

Pole:	Kategoria_ miejscowości	Tabela:	PAREFIE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	Pole wyboru	Klucz:	brak
Format wyświetlania:	tak/nie	Unikalność:	nie
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik
		Wartość domyślna:	„nie”

Tab. 5 Specyfikacja atrybutów pola Kategoria_miejscowości w tabeli PARAFIE.

Pole Kategoria_miejscowości w tabeli PARAFIE zawiera dane typu „pole wyboru”, nie jest kluczem, wartość tego pola nie jest unikalna, ale jest wymagana i nie może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik a wartością domyślną jest „nie”.

Pole:	Dekanat	Tabela:	PAREFIE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	tekst	Klucz:	Obcy
Długość:	60	Unikalność:	nie
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik

Tab. 6 Specyfikacja atrybutów pola Dekanat w tabeli PARAFIE.

Pole Dekanat w tabeli PARAFIE zawiera dane typu „tekst”, jest kluczem obcym, wartość tego pola jest unikalna, wymagana i nie może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik.

Pole:	Nazwa_ dekanatu	Tabela:	DEKANATY
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	tekst	Klucz:	brak
Długość:	60	Unikalność:	tak
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik

Tab. 7 Specyfikacja atrybutów pola ID_mszy w tabeli DEKANATY.

Pole Dekanat w tabeli DEKANATY dane typu „tekst”, jest kluczem obcym, wartość tego pola jest unikalna, wymagana i nie może przyjmować wartości „null”, natomiast źródłem wartości tego pola jest użytkownik.

Pozostałe pola tabeli MSZE i kolejnych tabel przyjmują odpowiednio atrybuty wyszczególnione w dotychczas przedstawionych polach.

4. Relacje

W relacyjnym modelu danych jest tylko jedna struktura danych, jest nią relacja [5]. Przykładowy rozkład relacji przedstawia poniższa tabela, tak zwana tabela krzyżowa:

	MSZE	PARAFIE	WIERNI	DEKANATY
MSZE		1:W
PARAFIE			1:W	1:W
WIERNI
DEKANATY

Tab. 8 Tabela krzyżowa.

W związku z tym, że pojęcie relacji jest konstrukcją matematyczną relacja jest tabelą, dla której muszą być spełnione następujące zasady:

• każda relacja w bazie danych ma jednoznaczną nazwę

• każda kolumna ma jednoznaczną nazwę w ramach jednej relacji

• wszystkie wartości w kolumnie muszą być tego samego typu, są zdefiniowane na tej samej dziedzinie

• każdy wiersz w relacji musi być różny, powtórzenia nie są dozwolone

• każde pole leżące na przecięciu kolumna/wiersz w relacji powinno zawierać wartość atomową, zbiór wartości nie jest dozwolony na jednym polu relacji

• porządek kolumn nie jest istotny

• porządek wierszy nie jest istotny[5]

W implementacyjnym diagramie związków encji przedstawione są szczegółowo cechy relacji:

• reguły usuwania (restrykcyjna -„R”, kaskadowa -„C”)

• typy uczestnictwa (obowiązkowe, opcjonalne)

• stopień uczestnictwa tabel (np. (1,N) gdzie N to ∞ lub inne konfiguracje liczb)

Prezentację związków występujących w bazie danych obrazuje rys. 1.

(1,20)

(1,1) (1,N) (R) (1,1)

(R) (1,1)

(1,20)

(R)

KP - klucz podstawowy

KO - klucz obcy

(1,1), (1,N) - stopień uczestnictwa

(R) - restrykcyjna reguła usuwania

II - uczestnictwo obowiązkowe

Rys. 1. Diagram związków encji.

Relacyjna baza danych przechowuje dane w oddzielnych tabelach, zamiast umieszczać je wszystkie w jednym wielkim magazynie. To zwiększa jej szybkość i elastyczność[4]. Schemat logiczny tej bazy wyraża sam diagram [6]

5. Integralność bazy danych

Wynikiem klasycznej analizy danych jest logiczny projekt bazy danych zawierających specyfikację odpowiednich plików i zbiór wewnętrznych więzów integralności [6]. Analiza danych może ujawnić potrzebę ponownego zdefiniowania reguł integralności.

Definiowanie reguł dotyczących pól. W przykładowej bazie danych zastrzeżenie zostało wniesione do atrybutów logicznych pola Godzina_mszy w tabeli MSZE:

Pole:	Godzina_mszy	Tabela:	MSZE
Atrybuty	fizyczne:	Atrybuty	logiczne:
Typ danych:	godzina	Klucz:	brak
Maska wprowadzania:	00:00	Unikalność:	nie
		Wartość wymagana:	tak
		Wartości zerowe:	nie
		Źródło wartości:	użytkownik
		Wartość domyślna	12:00

Tab. 9 Specyfikacja atrybutów pola Godzina_mszy w tabeli MSZE - po zdefiniowaniu reguł integralności.

Treść: Każda Msza musi mieć przypisaną godzinę
Ograniczenie: Pole "Godzina_mszy" musi posiadać odpowiednią wartość niezerową
Typ v bazodanowy □ aplikacyjny	Kategoria v związana z polem □ związana z relacją	Czynności grożące naruszeniem v wprowadzenie □ modyfikacja v usuwanie
Modyfikowane struktury
Nazwy pól Godzina_mszy		Nazwy tabel
Modyfikowane atrybuty pola
Atrybuty fizyczne □ typ danych □ długość □ format wyświetlania		Atrybuty logiczne □ unikalność v wartość wymagana v wartości zerowe □ źródło wartości □ wartość domyślna □ zakres wartości
Modyfikowane cechy relacji
□ reguła usuwania	□ typ uczestnictwa	□ stopień uczestnictwa
Podjęte czynności
Atrybut "wartość wymagana" został ustawiony na "tak", "wartości zerowe" na "zabronione"

Tab. 10 Specyfikacja reguł integralności.

Reguła bazodanowa oddziałująca na relacje. Bezpośrednią konsekwencją reguły integralności encji jest fakt, że w tabeli są zabronione powtórzenia wierszy (dla kluczy głównych) [6]. Wzajemne powiązania między tabelami wymuszają na projektancie wzmożoną uwagę. Cała misternie tworzona konstrukcja może się łatwo zawalić, jeżeli jej relacje będą źle zdefiniowane i operacje na danych w jednej tabeli spowodują powstanie niespójnych wpisów w innej tabeli [7]. W przykładowej bazie danych nie pojawiły się tego typu problemy, niemniej jednak, aby uzyskać integralność na poziomie tabel należy zmodyfikować pewne cechy relacji:

Treść: W każdej parafii musi odbywać się co najmniej 1 i inie więcej niż 25 Mszy.
Ograniczenie: Rekordowi w tabeli „PARAFIE” musi odpowiadać od 1 do 25 rekordów w tabeli „MSZE”. Uczestnictwo tabeli “PARAFIE” musi być obowiązkowe.
Typ v bazodanowy □ aplikacyjny		Kategoria □ związana z polem v związana z relacją			Czynności grożące naruszeniem v wprowadzenie □ modyfikacja v usuwanie
Modyfikowane struktury
Nazwy pól			Nazwy tabel „MSZE”, „PARAFIE”
Modyfikowane atrybuty pola
Atrybuty fizyczne □ typ danych □ długość □ format wyświetlania			Atrybuty logiczne □ unikalność □ wartość wymagana □ wartości zerowe □ źródło wartości □ wartość domyślna □ zakres wartości
Modyfikowane cechy relacji
v reguła usuwania	v typ uczestnictwa			v stopień uczestnictwa
Podjęte czynności
Typ uczestnictwa tabeli „MSZE” w relacji „PARAFIE” ustawiony na obowiązkowy. Stopień uczestnictwa tabeli „MSZE” w relacji z tabelą „PARAFIE” ustawiony na (1,25). Dodana restrykcyjna reguła usuwania dla tabeli „PARAFIE”.

Tab. 11 Specyfikacja reguł integralności.

Reguła integralności wymagająca wprowadzenia tabeli walidacji. Przy ustalaniu atrybutów reguł poprawności często okazuje się, że wartość pola może mieścić się w pewnym wąskim zakresie. Zbiór taki zwykle będzie się składał ze stałej liczby rzadko zmieniających się danych [7].

Treść: Każdej Parafii musi być przypisany dekanat.
Ograniczenie: Dopuszczalne wartości pola ”dekanat” w tabeli “PARAFIE” muszą być ograniczone do istniejących wartości pola “ID_dekanatu” tabeli.
Typ v bazodanowy □ aplikacyjny		Kategoria □ związana z polem v związana z relacją			Czynności grożące naruszeniem v wprowadzenie v modyfikacja □ usuwanie
Modyfikowane struktury
Nazwy pól “Dekanat”			Nazwy tabel „PARAFIE”, “DEKANATY”
Modyfikowane atrybuty pola
Atrybuty fizyczne □ typ danych □ długość □ format wyświetlania			Atrybuty logiczne □ unikalność □ wartość wymagana □ wartości zerowe □ źródło wartości □ wartość domyślna □ zakres wartości
Modyfikowane cechy relacji
v reguła usuwania	v typ uczestnictwa			v stopień uczestnictwa
Podjęte czynności
Zakres wartości pola “Dekanat” w tabeli “PARAFIE” ograniczony do każdej wartości pola “ID_dekanatu” w tabeli “DEKANATY”. Wprowadzono relację JDW pomiędzy tabelami “DEKANATY” i “PARAFIE”: typ uczestnictwa tabeli “DEKANATY” obowiązkowy, tabeli “PARAFIE” opcjonalny, stopień uczestnictwa tabeli “PARAFIE” (1,1), stopień uczestnictwa tabeli “DEKANATY” (1,20), restrykcyjna reguła usuwania dla tabeli “DEKANATY”.

Tab. 12 Specyfikacja reguł integralności.

Wprowadzenie aplikacyjnej reguły bazodanowej sprowadza się do zdefiniowania zachowania bazy danych w przypadku wystąpienia czynnika zewnętrznego niemożliwego do uwzględnienia w wewnętrznej jej strukturze. Może to być, np.:

„Blokowanie możliwości wprowadzenia tylko jednego rekordu Godzina_mszy dla Parafii, w których występują tzw. kaplice dojazdowe”.

6. Diagramy i specyfikacje perspektyw.

Perspektywy w rzeczywistości nie istnieją, są tworami wirtualnymi powstałymi na chwilę w pamięci komputera na podstawie danych z rzeczywistych tabel bazy po zadaniu odpowiedniego zapytania [7]. Projektowanie perspektyw musi się opierać na zgromadzonych informacjach dotyczących planowanego wykorzystania bazy danych. Perspektywy można podzielić na kilka kategorii [2]:

• perspektywy danych

• perspektywy agregacji

• perspektywy walidacji

Perspektywy danych wykorzystywane są do przeglądania i modyfikowania danych. Pola perspektywy mogą pochodzić z jednej tabeli lub kilku tabel połączonych relacją, a nawet z innych perspektyw. Atrybuty pól są zachowane. Przykładowa perspektywa danych:

(1,N) (1,1)

(R)

Rys. 2 Diagram perspektywy danych.

Liczba mieszkańców parafii w danej miejscowości
Miejscowość	Nazwa_parafii	Liczba_wiernych
Lublin	Św. Mikołaja	5526
Lublin	Bł. Bpa Gorala	7750
Lublin	Św. Agnieszki	5100

Tab. 13 Liczba mieszkańców parafii

Tabela PARAFIE powiązana jest relacją 1 do N z tabelą WIERNI. W celu wygenerowania Liczby mieszkańców parafii w danej miejscowości została zdefiniowana perspektywa danych zawierająca pole Miejscowość i Nazwa_parafii z tabeli bazowej PARAFIE i pole Liczba_wiernych z tabeli bazowej WIERNI.

Perspektywy agregujące zawierają jedno lub więcej pól wyliczonych, stanowiących wynik agregacji danych oraz jedno lub więcej pól mających za zadanie grupowanie pól agregowanych. Przykładem zastosowania perspektywy tego typu jest wyliczenie procentowego udziału katolików wśród ogółu mieszkańców danej parafii:

(1,N) (1,1)

(R)

Rys. 3 Diagram perspektywy agregującej

Udział katolików (procentowy udział katolików wśród wszystkich mieszkańców parafii)
Nazwa_parafii	%_katolików
Św. Mikołaja	94,5
Bł. Bpa Władysława Gorala	80,0
Św. Agnieszki	90,2

Tab. 14 Udział katolików

Perspektywa Udział_katolików wykorzystująca pola tabel bazowych PARAFIE i WIERNI posiada pole identyfikujące Nazwa_parafii i pole wyliczone funkcją DIV i ILOCZYN %_katolików. W momencie wywoływania perspektywy wartości pola wyliczonego zostają obliczane na podstawie aktualnych wartości danych w tabeli bazowej WIERNI.

Perspektywa walidacji służy do tego samego celu, co tabela walidacji. Najczęściej służą do ograniczenia użytkownikom dostępu do określonych danych.

(1,20) (1,1)

(R)

Rys. 4 Diagram perspektywy walidacji

Parafie dekanatu 00001
ID_dekanatu	Nazwa_parafii
00001	Babin
00001	Bełżyce
00001	Chodel

Tab. 15 Parafie dekanatu 00001

Perspektywa Parafie dekanatu 00001 wykorzystująca pola tabel bazowych DEKANATY i PARAFIE. W momencie wywoływania perspektywy wartości pola prezentowane są na podstawie aktualnych wartości danych w tabelach bazowych DEKANATY i PARAFIE.

Na tym etapie należy podjąć decyzję, co do wyboru odpowiedniego systemu zarządzania bazą danych (SZBD). Wybór SZBD może mieć różny wpływ na jej wydajność.[5] Pierwszym komercyjnym systemem zarządzania relacyjną bazą danych wprowadzonym na rynek był produkt firmy ORACLE®, miało to miejsce w 1977 roku [3]. Spośród szeregu dostępnych SZBD do realizacji projektu fizycznego wybrana została aplikacja ACCESS będąca składnikiem pakietu Microsoft Office. Jej walorami są: ogólna dostępność, przejrzystość działania i intuicyjna obsługa. Funkcjonalność zwiększa zastosowanie języka zapytań SQL, który można uznać za część aplikacji Access [3].

7. Projekt fizyczny

W aplikacji MS ACCESS tworzenie bazy danych rozpoczynamy od ustalenia jej nazwy i określenia fizycznej lokalizacji. W pustej bazie należy utworzyć tabele zawierające zaprojektowane pola - budowanie tabel. Tabele można utworzyć na szereg różnych sposobów [2]. Po wykonaniu tej czynności w bazie danych pojawią się pierwsze obiekty:

Rys. 5 Tworzenie tabeli w widoku projekt

Rys. 6 Widok tabel aktywnej bazy danych

8. Implementacja

Przede wszystkim implementacja polega na stworzeniu struktur przechowywania i związanych z nim mechanizmów dostępu do danych [2]. Rys 7 przedstawia okno dialogowe tworzenia relacji. Natomiast diagram relacji pokazany na rys. 8 pozwala całościowo zaprezentować strukturę relacyjnej bazy danych.

Rys. 7 Edytowanie relacji

Rys. 8 Diagram relacji

9. Kwerendy

Od SZBD oczekujemy udostępniania użytkownikowi możliwości zapytań o dane, oraz aktualizowania danych, za pomocą odpowiedniego języka nazywanego językiem zapytań lub językiem operowania danymi. Istotą relacyjnego modelu bazy danych jest możliwość błyskawicznego uzyskania żądanej informacji. Wystarczy tylko sformułować odpowiednie zapytanie za pośrednictwem narzędzi udostępnionych przez system zarządzania bazą danych [1]. Zadaniem kwerend jest przetwarzanie danych w przydatne informacje [7]. Rysunek 9 przedstawia przykład udostępniający informację o procentowym udziale przystępujących do Komunii w poszczególnych parafiach z przyporządkowaniem ich do miejscowości i dekanatów, ponadto informacje zostały usystematyzowane poprzez sortowanie według jednej z wartości.

Rys. 9 Kwerenda wybierająca

10. Formularze

Formularze mogą mieć dowolny wygląd. Zawiera on między innymi przyciski poleceń służące do otwierania innych formularzy lub rozpoczynania innych zautomatyzowanych czynności. Formularz może zawierać pola wyboru, do wypełnienia i przyciski nawigacji.

Rys. 10 Formularz bazy danych

11. Użytkowanie bazy danych

Wszystkie potrzeby użytkownika względem dostępu do informacji można zaspokoić przez poprawne zaprojektowane raportów. Daje to prosty i szybki dostęp do żądanych informacji. Raport jest podsumowaniem informacji zawartych w jednej lub więcej liczbie tabel czy kwerend. System zarządzania bazą danych sporządza czytelną i estetyczną prezentację potrzebnych informacji. Rys. 11 przedstawia jeden z raportów dostępnych dla użytkownika.

Rys. 11 Widok raportu gotowego do wydruku.

12. Podsumowanie

Wykonanie logicznego projektu bazy danych umożliwiła szczegółowa analiza realizowanych zadań i potrzeb przyszłego jej użytkownika. Baza danych Archidiecezji Lubelskiej gromadzi dane dotyczące frekwencji wiernych na Mszach świętych i liczebności przystępujących do Komunii. Ponadto gromadzone są dane dotyczące liczebności parafii i kategorii miejscowości ich siedziby. W projekcie znalazło odzwierciedlenie każde istotne pole działania użytkownika bazy danych. Gromadzone dane służą do prowadzenia statystyk kościelnych, wyliczania udziałów procentowych frekwencji i korzystania z sakramentów, zliczania danych wszystkich parafii w obrębie danego dekanatu, danego miasta i całej diecezji. Podsumowaniem informacji uzyskiwanych z danych w MS Access są raporty. Prezentują one usystematyzowane zestawienia żądanych informacji w formie czytelnych i estetycznych tabel bądź kolumn.

Projekt został wykonany w oparciu o model relacyjny bazy danych. Ograniczenia sprzętowe ze względu na niewielki rozmiar bazy danych nie były uwzględniane. Implementacja, czyli stworzenie struktur przechowywania i związanych z nim mechanizmów dostępu do danych został oparty na projekcie logicznym. Poprawność struktury bazy jest zapewniona dzięki uwzględnieniu wszelkich reguł integralności.

Utworzenie bazy danych w MS Access polegało na zadaniu kolejnych poleceń w oknie panelu sterowania. Do utworzenia tabel, kwerend i formularzy skorzystano z funkcji „widok projektu” odpowiedniej zakładki aplikacji dla każdego z elementów. Atrybuty poszczególnych pól zostały określone przy użyciu arkusz „właściwości pola” dostępnego w panelu okna projektu. Definiowanie relacji użyto jednego z poleceń dostępnych w menu narzędzia. Do przeprowadzenia implementacji w poleceniu relacje wykorzystano przyciski „pokaż tabele” i „edytowanie relacji”

Za pomocą MS Access zostały zrealizowane zakładane cele. Baza danych gromadzi niezbędne dane, a zastosowanie przejrzystego formularza umożliwia sprawne ich wprowadzania. Na podstawie zgromadzonych danych łatwo jest uzyskać potrzebne informacje.

13. Bibliografia:

1. Jefrey D. Ullman, Jennifer Widon: Podstawowy wykład systemów baz danych, WNT, Warszawa 1999

2. Ken Bluttman: 100 sposobów na Access, Helion, Gliwice 2005

3. Lech Banakowski: Bazy danych. Tworzenie aplikacji, Akademicka Oficyna Wydawnicza PLJ, Warszawa 1998

4. MSQL Press: MySQL opis języka, Helion, Gliwice 2005

5. Paul Beynon-Davis: Systemy baz danych, WNT, Warszawa 2003

6. Paul Beynon-Davis: Systemy baz danych, WNT, Warszawa 1998

7. Tomasz Nabiałem: ABC Accessa, Wydawnictwo „Edition 2000”, Kraków 2004

1

DEKANATY

------------------------

ID_dekanatu KP

Nazwa_dekanatu

PARAFIE

-----------------------------

ID_parafii KP

Dekanat KO

Nazwa_parafii

Miejscowość

Kategoria_miejscowości

MSZE

------------------------

ID_mszy KP

ID_parafii KO

Godzina_mszy

Frekwencja_k

Frekwencja_m

Komunia_k

Komunia_m

WIERNI

------------------------

ID_wiernych KP

ID_parafii KO

Liczba_mieszkańców

Liczba_katolików

Data_obowiązywania

DEKANATY

-------------------------

ID_dekanatu KP

Nazwa_dekanatu .

WIERNI

------------------------

ID_wiernych KP

ID_parafii KO

Liczba_mieszkańców

Liczba_katolików

Data_obowiązywania

PARAFIE

-----------------------------

ID_parafii KP

ID_dekanatu KO

Nazwa_parafii

Miejscowość

Kategoria_miejscowości

PARAFIE

-----------------------------

ID_parafii KP

ID_dekanatu KO

Nazwa_parafii

Miejscowość

Kategoria_miejscowości

WIERNI

------------------------

ID_wiernych KP

ID_parafii KO

Liczba_mieszkańców

Liczba_katolików

Data_obowiązywania

__________________________

Liczba_katolików_parafii

---------------------------------------

Miejscowość

Nazwa_parafii

Liczba_mieszkańców

__________________________

__________________________

Udział_katolików

---------------------------------------

Nazwa_parafii

%_katolików

__________________________

PARAFIE

-----------------------------

ID_parafii KP

ID_dekanatu KO

Nazwa_parafii

Miejscowość

Kategoria_miejscowości

Parafie miejskie

---------------------------------------

ID_dekanatu

Nazwa_parafii

---