inf55, 1


Przykład bazy danych jako elementu systemu informatycznego

Bazy danych są jednym z najważniejszych elementów współczesnego systemu informatycznego. A systemy relacyjnych baz danych są obecnie najczęściej używanymi systemami baz danych. Rozwiązały one wiele problemów występujących wcześniej w bazach nierelacyjnych. Nierelacyjne bazy danych wymagały od programistów i administratorów szczegółowej wiedzy na temat rozmieszczenia danych i struktury bazy. Utrudniało to bardzo rozbudowę i modyfikację aplikacji.

Natomiast relacyjne bazy danych pozwalają na pracę z danymi na wyższym poziomie. Wszystkie operacje na danych są wykonywane za pomocą programu SZBD-systemu zarządzania bazą danych ( database management system-DMBS). Odpowiada on na instrukcje wyrażone w języku wysokiego poziomu. Chociaż niektóre produkty dostępne na rynku mają własny język, za standard we wszystkich znaczących systemach uznano SQL

Typowy system relacyjnych baz danych składa się nie tylko z SZBD. SZBD jest często nazywany „tyłem bazy danych” (back end) lub „mechanizmem” (engine). W odpowiedzi na instrukcje SQL-a wyszukuje on lub modyfikuje dane, a także odpowiada za ich przechowywanie. Systemy relacyjnych baz danych mają także wbudowane narzędzia nazywane „frontem bazy danych” (front end). Ułatwiają one komunikację z tyłem bazy danych oraz zawierają różne udogodnienia w wyszukiwaniu danych np. formularze, generatory raportów, graficzne języki zapytań, systemy hipertekstu.

Wszystkie te wyżej wymienione narzędzia wymagają SZBD do wykonania różnych akcji. SZBD jest odpowiedzialny za przechowywanie, organizację i wyszukiwanie danych. Odpowiada również za ich integralność i ochronę.

Konstruowanie bazy danych i obsługującej ją aplikacji można opisać w trzech etapach:

Formułowanie definicji celu i założeń wstępnych

Pierwszą fazą tworzenia projektu bazy danych jest sformułowanie definicji celu oraz założeń wstępnych. Definicja celu mówi, po co projektujemy bazą danych, oraz założeń wstępnych. Definicja celu mówi, po co projektujemy bazę danych, oraz stanowi punkt odniesienia dla jej twórcy.

Oprócz definicji celu na tym etapie należy sformułować założenia wstępne. Są to wymagania, jakie powinny spełniać dane przechowywane na bazie. Warunki te powinny uzupełniać definicję celu i pomagać w tworzeniu poszczególnych elementów bazy danych.

Bazę danych budujemy zatem z tabel które dzielimy na wiersze, każdy wiersz natomiast składa się z poszczególnych pól, w które wpisujemy wartości atrybutów. Odtąd zamiast mówić np. : o atrybucie adres mówić będziemy o polu adres, mając na myśli rubrykę naszej tabeli. Stworzenie tabel naszej bazy danych to dopiero część projektu. Następnie musimy doprowadzić tabele do postaci, która gwarantuje poprawne funkcjonowanie bazy danych, a nazywa się postacią normalną. Czynność ta zwana jest normalizacją i polega ona na podziale normalizowanej tabeli na szereg mniejszych tabel będących już w postaci normalnej. Dane w znormalizowanych tabelach zazwyczaj są już na tym etapie powiązane. Szkic tych powiązań wraz z projektem tabel to szkielet bazy danych.

Następnie zajmujemy się realizacją planów czyli ich implementacją, za pomocą Systemu Zarządzania Bazami Danych ( DataBase Management System). W naszym przypadku będzie to program Microsoft Access 97 w środowisku Windows. Jednakże sama implementacja projektu nie wystarczy, mamy zaledwie bazę w której możemy przechowywać dane. Brakuje mechanizmów pozwalających na wyszukiwanie danych na podstawie określonych kryteriów oraz przetwarzaniu ich zgodnie z potrzebami. Czynności te składają się na podstawowy cel bazy danych, którym jest wyciągnięcie z danych informacji, mechanizmy te to zapytania (Query).

W języku polskim operację wyszukiwania informacji oznacza również termin kwerenda. Terminy te nie są jednak do końca równoważne bowiem zapytanie umożliwia także zmianę wybranych danych w bazie, kwerenda natomiast takiej możliwości nie daje. Kwerenda to poszukiwanie informacji

( w archiwach, bibliotekach) potrzebnych do wyjaśnienia jakiejś kwestii. Słowo to pochodzi od łacińskiego qurenda, który oznacza rzeczy poszukiwane, to czego należy poszukiwać. To samo pochodzenie ma angielskie słowo query tłumaczone jednak jako zapytanie. Kwerenda zatem jest szczególnym przypadkiem zapytania tzn. każda kwerenda jest zapytaniem, natomiast nie każde zapytanie jest kwerendą. Zapytania stanowią drugi po tabelach rodzaj podstawowych obiektów systemu. Do definiowania zapytań stworzono kilka języków, początkowo bardzo sformalizowanych. Wiązało się to z matematycznymi podstawami teorii relacyjnych baz danych. Następnie opracowano języki „wyższego poziomu” bliższe językowi naturalnemu, których współczesnym rezultatem jest język SQL. W relacyjnej bazie danej informacja przechowywana jest w postaci wierszy złożonych z poszczególnych pól. Wiersze te tworzą tabele wyświetlane w postaci arkusza danych.

Arkusz danych jest dobrą formą odpowiedzi na zapytanie. Interesujące nas fakty wybrane z ogółu danych złożą się w wiersze, które dadzą coś na kształt tabeli. Tworzenie zapytań w języku QBE polega na budowaniu przykładów, odpowiedzi w postaci tabel i poleceniu wypełnienia ich danymi pochodzącymi z tabel bazy danych. Do tego celu wykorzystuje się tzw. szablon QBE (QBE grid).

Następnie Access umożliwia uzupełnienie tak stworzonego systemu bazy danych o elementy interfejsu użytkownika, czyli formularze (form) do wprowadzania lub przeglądania danych oraz raporty (report), których zadaniem jest prezentacja informacji uzyskanej z bazy danych.

Podstawowym celem formularzy i raportów jest przedstawienie danych zawartych w bazie. Najczęściej zatem każdy obiekt tego rodzaju odwoływał się będzie do tabeli lub zapytania źródłowego, a jego zadanie to przedstawienie danych z pojedynczych wierszy obiektu źródłowego już nie w postaci arkusza danych ale klasycznego formularza.

Formularze przypominają nieco pola dialogowe, mogą bowiem zawierać spotykane w nich elementy sterujące zwane ogólnie detalami ( control ). Zaliczamy do nich pola tekstowe, listy, listy rozwijane, pola wyboru i przyciski opcji, a także grupy opcji przycisków poleceń i inne. Formularze i raporty wydają się być podobne istnieje jednak pomiędzy nimi zasadnicza różnica.

Raport służy jedynie wydrukowi różnego rodzaju zestawień czy sprawozdań. W pewnym sensie jest on obiektem statycznym, nie można za jego pomocą przeglądać czy zmienić stanu bazy danych. Formularz natomiast pozwala przeglądać, wprowadzać i modyfikować dane w bazie danych. Może być także wydrukowany lub zamieniony w raport. Wobec tej uniwersalności formularzy, raporty nie byłyby potrzebne gdyby nie specjalne właściwości zestawiania i sumowania danych, bardzo przydatne przy sprawozdawczości, a nie występujące w formularzach.

Ponieważ formularze dotyczą oblicza bazy danych, wygląd pełni w ich przypadku dużo większą rolę niż dla tabel czy zapytań. W ich przypadku mogliśmy jedynie decydować o pewnych modyfikacjach wyglądu arkusza danych: zmieniać szerokość kolumn, wysokość wierszy, krój czcionki itp. szczegóły. Tutaj przede wszystkim należy prawidłowo zagospodarować przestrzeń blankietu formularza oraz zaprojektować go pod względem funkcjonalnym tak aby korzystanie z niego było jak najwygodniejsze.

Tak stworzony system bazy danych możemy zamienić w samodzielną aplikację, która wykorzysta jedynie „silnik” Accessa - Microsoft Jet Database Engine (silnik bazy danych MS Jet). Umożliwiają to makropolecenia ( macro) oraz moduły ( module), zbiory procedur napisanych w języku Access Basic będącym wewnętrznym językiem programowania Accessa. Chociaż nie służą przechowywaniu danych jak tabele, nie potrafią zbiorczo przetwarzać danych jak zapytania, nie są wreszcie przeznaczone do ich wprowadzania, ani prezentacji jak formularze i raporty, to jednak makropolecenia mają ogromne znaczenie w budowie kompletnego systemu bazy danych, tworzącego samodzielną aplikację .Natomiast bez modułów będących zbiorami procedur i funkcji napisanych w języku Access Basic można się w zasadzie obejść przy tworzeniu bazy danych, korzystając ze wspomnianych makropoleceń.

Makropolecenia w Accessie to procedury, których działanie powoduje wykonanie jednej lub kilku predefiniowanych czynności zwanych także „akcjami” ( action). Każde makropolecenie to po prostu lista czynności wraz z ich argumentami i ewentualnymi warunkami decydującymi o tym czy dana czynność jest wykonywana czy nie. U podstaw konstrukcji takiego systemu musi jednak „leżeć” solidny projekt uwzględniający potrzeby użytkownika w zakresie gromadzenia przechowywania i przetwarzania danych oraz czynności składające się na obsługę bazy danych.

Istotnym problemem przy budowie takiego systemu jest przewidzenie i uporanie się z sytuacjami niepożądanymi typu:

wprowadzenie błędnych danych, nieumyślne skasowanie danych czy wreszcie próby zmian istotnych elementów systemu. Przed takimi sytuacjami trudno się w zupełności uchronić, choć niewątpliwie można wyeliminować niektóre z nich. Maksymalna automatyzacja wykonywanych operacji, kontrola czynności wykonywanych przez użytkownika oraz prosta obsługa całości to zalety przyjaznego i odpornego na błędy systemu.

Cel i założenia aplikacji

Aplikacja wspomagać będzie obsługę konferencji naukowej na temat Systemy Komputerowe i Sieci. 0x08 graphic
W bazie muszą być przechowywane informacje o zgłoszeniach na konferencje takie jak: elementy które można wykorzystać do skompletowania informacji o uczestniku, informacje szczegółowe dotyczące każdego z uczestników tj. Imię, Nazwisko, Tytuł naukowy, Adresy Prywatny i Miejsca pracy. Ponadto użytkownik będzie chciał otrzymywać dane pomocne w określaniu różnorakich danych. W zależności od określonego zapotrzebowania na miejsca noclegowe, daty noclegów, ilości osób z danej uczelni, aplikacja ma dostarczać informacje o zapotrzebowaniu na wyżej wymienione dane uporządkowanych względem danego kryterium.

Musi zostać zapewniony mechanizm, który umożliwi pokazanie informacji o danym uczestniku w postaci kwerendy lub raportu do wydrukowania. Aplikacja powinna umożliwić drukowanie „Wszystkich uczestników konferencji”, na podstawie którego pracownicy obsługujący konferencję będą mogli dokonać weryfikacji wprowadzonych danych. Aplikacja gromadzić będzie informacje o uczestnikach i raportować o szczególnie ważnych danych na temat konkretnego uczestnika konferencji naukowej.

Kontekst aplikacji

0x08 graphic

Wymagania funkcjonalne

Wprowadzanie danych o uczestniku konferencji, edytowanie, wyszukiwanie, aktualizacja, dokonywać podsumowań form i dat noclegów.

Drukować wybrane raporty na temat uczestników konferencji, z wybiórczymi informacjami na dany temat np. formy noclegów .

Wymagania niefunkcjonalne

Uczelnia korzysta z innego oprogramowania dla potrzeb obsługi bieżącej. Informacje o uczestnikach konferencji powinny być po wprowadzeniu przechowywane w tym systemie. Należało by więc zapewnić procedurę wymiany informacji. Najlepiej byłoby gdyby informacje podczas wprowadzania danych zostały sklasyfikowane na grupy np. adresy powinny zostać sklasyfikowane na dwie kategorie (prywatne, służbowe) itp. Zapewnić należy procedurę która umożliwi wydrukowanie jednego kompletu danych, a nie raportu zbiorczego.

0x08 graphic

0x08 graphic
0x08 graphic

Prezentacja informacji

Wyświetlanie informacji w programie odbywa się przy pomocy formularzy . Jako pierwszy wyświetlany jest formularz główny ( automatycznie po starcie programu ) . Znajdujące się na nim przyciski sterujące umożliwiają otwieranie kolejnych formularzy, natomiast przycisk "Zakończ aplikację" umożliwia zakończenie pracy i powrót do systemu operacyjnego.

Określenie tabel

Zapytania

Zapytanie wyszukujące dane z kilku tabel to rzecz normalna w każdym języku

manipulowania danymi, w tym także w QBE. W Accessie zapytania budujemy umieszczając w oknie projektu zapytania listy pól wszystkich tabel źródłowych z których chcemy skorzystać. Następnie wystarczy umieścić listy wszystkich pól wymienionych tabel w oknie projektu zapytania i wybrać z nich odpowiednie pola do szablonu QBE uwzględniając dodatkowe kryteria np: automatyczne posortowanie

Warto tutaj wspomnieć o relacjach definiowanych na początku budowy bazy danych. Określenie takich związków pozwala Accessowi sprawdzać spójność danych oraz jest konieczne do zbudowania poprawnego zapytania odwołującego się do kilku tabel. Widoczne w oknie projektu zapytania linie łączące pola różnych tabel to właśnie zdefiniowane przez nas wcześniej powiązania. Access potrafi sam domyślnie łączyć pola obiektów źródłowych zapytań, które mają tę samą nazwę i ten sam typ danych. Jednak kiedy nie zrobimy tego sami zapytanie nie będzie działało zgodnie z naszymi oczekiwaniami.

Widać zatem, że powiązanie tabel jest niezbędne do tego, by uzyskać sensowne informacje.

Deklaracja powiązań jest możliwa także dla par zapytanie - tabela, jednak niemożliwe jest wtedy sprawdzenie spójności danych. Powiązanie takie ma charakter pomocniczy i służy temu, aby dana para obiektów użyta w zapytaniu była automatycznie powiązana. Takie powiązanie obiektów źródłowych nazywamy połączeniem (Join) normalne połączenie powoduje, że do zestawienia wybierane są dane tylko z tych wierszy tabel źródłowych, dla których wartości połączonych pól są równe.

W dobrze zaprojektowanej bazie danych przechowuje się jedynie dane elementarne, z których dzięki rożnym obliczeniom otrzymać można nowe dane.

Bezpieczeństwo programu

W celu zabezpieczenia programu przed zmianą jego struktury , automatycznie po starcie ukrywane jest okno dialogowe i standardowe paski narzędzi . Dlatego też użytkownik ma jedynie dostęp do funkcji udostępnionych przez program. Ponadto dostęp do różnych kategorii danych został ograniczony poprzez nadanie systemu zezwoleń. Za pomocą uprawnień pozwalamy użytkownikom wykonywać różne operacje na obiektach wykorzystując instrukcję nadawania uprawnień grant.

Diagram hierarchii funkcji

0x08 graphic

0x08 graphic

0x08 graphic

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

Diagram związków encji

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

Konferencja Naukowa

Karta Uczestnictwa

Raporty

Dane pomocnicze

Dane zewnętrzne

Pracownik wpisujący dane

Karta uczestnictwa

Konferencja Naukowa

Karta Uczestnictwa

Imię

Nazwisko

Tytuł naukowy

Adresy

Forma noclegu

Data noclegu

e-mail

Instytut

Forma uczestnictwa

Przechowywanie informacji o uczestnikach konferencji

Dostarczanie danych w postaci

kwerend i raportów o konferencji.

Karta uczestnictwa

Dane dotyczące uczestnika

Dane dotyczące noclegu

Dane dotyczące daty pobytu na konferencji

Dane dotyczące uczestnika konferencji

Imię i Nazwisko uczestnika konferencji

Tytuł naukowy uczestnika konferencji

Instytut

Daty

Identyfikator

Daty noclegów

Forma noclegu

Identyfikator

Forma noclegu

Zgłoszenie

Identyfikator

Imię

Nazwisko

Tytuł naukowy, stanowisko

Instytut, Zakład

Uczelnia, Instytucja

Adres miejsca pracy

Telefon do pracy

Adres prywatny

Telefon prywatny

e-malil

Adres korespondencyjny

Forma uczestnictwa

Temat

Forma noclegu

Data noclegu

Forma uczestnictwa

Identyfikator

Forma

Tytuł

Identyfikator

Tytuł

Forma uczestnictwa w konferencji

(referat, komunikat, głos w dyskusji)

Adres do korespondencji

e-mail uczestnika konferencji

Adres prywatny, telefon uczestnika konferencji

Adres miejsca pracy, telefon uczestnika konferencji

Uczelnia



Wyszukiwarka