CC BY
52
kpt. mgr inz. Adam KRASUSKI prof. dr hab. inz. Tadeusz MACIAK
Szkola Glówna Sluzby Pozarniczej
HISTORIA ROZWOJU SYSTEMÓW ZARZ^DZANIA BAZAMI
DANYCH
Streszczenie
W artykule przedstawiony zostal rozwój systemów baz danych. Omówiono w nim technologie Hierarchicznych, Sieciowych, Relacyjnych oraz Obiektowych baz danych. Artykul ma charakter przegl^dowy a celem jego jest przyblizenie wiedzy na temat powstawania i ksztaltowania siç wspólczesnych systemów baz danych. Opis technologii baz danych zaprezentowano w ujçciu historycznym, co zapewni lepsze poznanie materialu czytelnikom nieobeznanym z t^ technologic.
Summary
This paper outlines the historical development of data management systems. Hierachical, Network, Relational, Objectoriented and Objectrelational data management systems are reviewed. A short summary of related research is given.
1.Wstçp
Historia rozwoju systemów baz danych liczy ponad 40 lat. W tym czasie powstaly systemy stanowi3.ce obecnie najprawdopodobniej najwiçksze dotychczasowe osi^gniçcie inzynierii oprogramowania. Systemy zarz^dzania baz^ danych, popularnie z angielskiego zwane DBMS (ang. Database Management Systems) staly siç podstaw^ systemów informacyjnych i istotnie zmienily sposób dzialania wielu instytucji. Ich rozwój pobudzil powstawanie oprogramowania do zarz^dzania informacjami, w srodowisku, którego pracuje siç w sposób prosty i naturalny. Niestety pozorna prostota obslugi baz danych niesie za sob^ kilka zagrozen. Jednym z nich jest to,
iz do pracy z aplikacjami operujqcymi na danych, kierowani sq ludzie bez specjalnego przeszkolenia w tym zakresie. Skutkuje to korzystaniem z baz danych w sposob niewlasciwy lub nie wykorzystujqcy w pelni ich mozliwosci.
Rozwoj DBMS wprowadzil tez istotne zmiany w funkcjonowaniu Panstwowej Strazy Pozarnej (PSP). Do codziennych obowiqzkow funkcjonariuszy PSP nalezy wprowadzanie meldunkow do bazy danych, sporzqdzanie zestawien sprzçtu i ludzi bçdqcych w podziale bojowym oraz wiele innych podobnych operacji. W sytuacjach wyjqtkowych, wykorzystywane sq chemiczne bazy danych, systemy wspomagania decyzji DSS (ang. Decision Support Systems) czy systemy informacji przestrzennej GIS (ang. Geographic Information Systems). Podstawç Historia rozwoju Systemow zarzqdzania bazami danych prawidlowego dzialania tych aplikacji stanowi przetwarzanie danych. W zwiqzku z tym, iz w PSP wykorzystywane sq zaawansowane technologie z dziedziny baz danych, swiadomosc pracownikow odnosnie ich obslugi musi bye, wiçc odpowiednio wysoka celem wykorzystania mozliwosci tych systemow.
Ponizszy artykul ma charakter przeglqdowy a celem jego jest przyblizenie wiedzy na temat powstawania i ksztaltowania siç wspolczesnych systemow baz danych. Opis technologii baz danych zaprezentowano w ujçciu historycznym co zapewni lepsze poznanie materialu czytelnikom nieobeznanym z t^. technologic Artykul stanowic moze wprowadzenie do technologii systemow zarzqdzania bazami danych dla funkcjonariuszy PSP.
2.Wprowadzenie
Istnieje wiele definicji okreslajqcych, czym jest baza danych. Dodatkowo ciqgle zmiany w tej dziedzinie rozszerzajq znaczenia tego slowa o nowe obszary wiedzy. Baza danych nie koniecznie musi stanowic zasoby przechowywane w formie elektronicznej. Jednak w odwolaniu do informatyki mozna jq zdefiniowac jako zbior danych przechowywanych na komputerze w formie ustrukturyzowanej, pozwalajqcej systemowi komputerowemu jq obslugujqcego na udzielanie odpowiedzi dotyczqcych przechowywanych danych. System komputerowy obslugujqcy zasoby bazy nazwany jest "systemem zarzqdzania bazq danych" [13]. Jednakze na skutek skrotow myslowych oraz wygody, oprogramowanie to bardzo czçsto nazywane jest rowniez systemem baz danych lub po prostu "bazq danych".
Ze wzglçdu na rodzaj danych oraz sposob ich przechowywania i reprezentowania powstaly rozne opisy strukturalne zasobow bazy. Opisy te nazywane sq schematami bazy danych [2].
Schemat bazy opisuje obiekty przechowywane w bazie a takze relacje miçdzy nimi. Istnieje kilka sposobow organizacji schematow bazy danych. Budowa takiego schematu nazywana jest modelowaniem bazy danych. Sposoby modelowania baz danych zmienialy siç wraz z rozwojem technologicznym. Powstawaly kolejno modele baz danych: plaski (ang. flat file), hierarchiczny, sieciowy, relacyjny i obiektowy [1].
Bazy danych operuj^ glownie na danych tekstowych i liczbowych. Wiçkszosc wspolczesnych baz umozliwia rowniez przechowywanie danych binarnych typu: grafika, dzwiçk lub inne.
Do podstawowych funkcji, jakie powinien realizowac system baz danych zaliczyc mozna [1]:
• Definiowanie bazy danych, czyli okreslenie struktury danych, typu przechowywanych danych oraz relacji miçdzy nimi;
• Umozliwienie dopisywania, modyfikacji oraz pozyskiwania danych z bazy;
• Kontrola dostçpu do zasobow bazy, zapewnienie bezpieczenstwa danych;
• Dbanie o integralnosc i spojnosc danych;
• Umozliwienie i kontrolowanie wielodostçpu do danych;
• Odtwarzanie danych po awarii sprzçtu czy oprogramowania.
Wykorzystywane obecnie systemy zarz^dzania bazami danych s^. w stanie realizowac wyzej wymienione funkcje. Osi^gniçcie tych funkcjonalnosci poprzedzal jednak burzliwy rozwoj technologiczny.
3. Historia rozwoju DBMS
Pocz^tki technologii baz danych siçgaj^ urz^dzen mechanicznych sterowanych perforowanymi metalowymi plytkami. Okolo roku 1725 sterowanie takie wykorzystywane bylo do kontroli pracy maszyn tkackich w zakladach Jacquarta [4]. W systemach tych otwory w plytkach pozycjonowaly odpowiednie mechaniczne przekazniki steruj3.ce prac^. krosien (rys. 1).
Rysunek 1. Perforowane metalowe plytki uzywane w warsztatach tkackich Jacquarta.
Zrodlo: [4]
Technologia plytek perforowanych stala si§ podstawq do budowy maszyny liczqco-analitycznej. Maszyna ta uzywala kart perforowanych jako nosnikow informacji. Dane na karcie zapisywane byly z uzyciem specjalnego kodu. Maszyna potrafila sortowac i wyszukiwac dane zgodnie z zalozonymi regulami oraz dokonywac porownan informacji zamieszczonych na kartach [5]. Konstruktorem maszyny liczqco-analitycznej - popularnie zwanej tabulatorem - byl Herman Hollerith. Wykorzystano jq po raz pierwszy w Komisji ds. Zdrowia (ang. Board of Health) w Nowym Jorku [6]. Po wst^pnych testach maszyna okazala si§ bardzo uzyteczna w wykonywaniu zmudnych zadan sortowania oraz liczenia danych. Zostalo to zauwazone przez amerykanskq administraj i w roku 1890 zmodernizowana maszyna Holleritha zostala uzyta podczas narodowego spisu ludnosci w US . Wspomagala ona opracowanie wynikow spisu [7].
Maszyna liczqco-analityczna byla urzqdzeniem elektromechanicznym i zazwyczaj w jej sklad wchodzily nast^pujqce moduly [5]:
• perforatory kart, sluzqce do wybijania otworow w kartach (r^czne lub automatyczne), jak rowniez wyprowadzania wynikow obliczen;
• reproducery kart, sluzqce do kopiowania kart juz wydziurkowanych;
• kolatory, sluzqce do porownywania oraz lqczenia roznych kart w pliki wedlug okreslonych regul;
• sortery, sluzqce do ukladania kart zgodnie z okreslonymi regulami;
• tabulatory, sluz^ce do drukowania zawartosci kart perforowanych w formie tekstu;
• kalkulatory, sluz3.ce do wykonywania obliczen arytmetycznych;
• czytniki kart perforowanych, sluz3.ce do wprowadzania danych do systemu.
Przykladowe moduly maszyny licz^co-analityczne pokazano na rysunku nr 2.
Rysunek 2.Maszyny licz^co-analityczne. Od lewej: perforator, reproducer,
kalkulator, sorter. Zrodto: [5]
3.1. Plaskie pliki
Wraz z pojawieniem si§ pierwszych systemow komputerowych rol§ maszyn licz^co-analitycznych przej^ly komputery. Niemniej dane nadal zapisywane byly na kartach perforowanych.
System pracy komputerow bazowal na operacjach wsadowych [8]. Dane do programu oraz lista rozkazow (tzw. wsad) przygotowane byly na kartach i wprowadzane do komputera. Po wykonaniu zaprogramowanych operacji pojawialy si§ informacje wyjsciowe zawieraj3.ce wynik dzialania programu, a niekiedy obraz jego pami^ci - jesli dzialanie programu zakonczylo si§ blödem.
Informacje przechowywane byly w tzw. „plaskich plikach". Wszystkie dane zawarte byly w jednym pliku a ich interpretacji dokonywala aplikacja zewn^trzna [9]. Struktur^ danych przechowywanych w plaskich plikach przedstawia rysunek 3.
Rysunek 3: Logiczna struktura danych przechowywanych w plikach ptaskich
Zapis oraz uaktualnianie zawartosci plikow opieral siç na fizyczno-sekwencyjnej metodzie zapisu [10]. Metoda ta polegala na przechowywaniu glownego pliku z danymi (ang. Master file), posortowanego wedlug pewnego klucza oraz pliku, na ktorym przeprowadzano modyfikacje zawartosci (ang. Transaction file). Co jakis czas dane z pliku roboczego przenoszono do pliku glownego, sortowano ponownie i zapisywano. Rysunek nr 4 przedstawia koncepcjç fizyczno-sekwencyjnej metody zapisu.
Rysunek 4. Koncepcja fizyczno-sekwencyjnego zapisu, wg [11]
Wynalezienie magnetycznych nosnikow pamiçci wywolalo prawdziwq rewolucjç w systemach gromadzenia danych [9]. W porownaniu z kartami perforowanymi mozna bylo zapisac na magnetycznych nosnikach bardzo duze ilosci danych. Dodatkowo podzielenie tasmy
na strony i przydzielenie im unikalnych adresów umozliwilo odejscie od sekwencyjnego zapisu danych.
Korzystajec z odpowiedniej funkcji haszujecej [l] rozmieszczano rekordy na nosnikach w sposób odpowiadajecy rozkladowi jednostajnemu. Adres strony, do której mial byé wpisany rekord wyliczany byl za pomoce wyzej wymienionej funkcji. Analogicznie bylo z wyszukiwaniem danych, zamieniano wyszukiwane slowo kluczowe na fizyczny adres obszaru dysku lub tasmy. W obszarze tym przechowywane byly informacje dotyczece danego slowa. Jedne z pierwszych szeroko wykorzystywanych metod pozyskiwania danych z nosników magnetycznych byla metoda o nazwie BDAM (ang. Basic Direct Access Method) wykorzystujeca wyzej opisane funkcjç haszujece [lO].
Jednak metody te, mimo, iz relatywnie szybkie (komputery typu mainframe potrzebowaly zaledwie 50 ms, aby zamienié slowo kluczowe na adres fizyczny) posiadaly kilka wad, miçdzy innymi [l, 9, lO]:
• Brak mozliwosci implementacji relacji pomiçdzy danymi. W plaskich plikach nie bylo mozliwosci tworzenia powiezan pomiçdzy poszczególnymi plikami. Utrudnialo to tworzenie struktury bazy danych odwzorowujecej struktur^ swiata rzeczywistego.
• Powstawanie tzw. „wysp informacji". Dane pomiçdzy oddzialami firmy nie byly wymieniane. Kazdy dzial posiadal swój wlasny plik i przewaznie inne aplikacjç napisane do jego obslugi.
• Powtarzanie tych samych danych. Niewymienialnosé danych pomiçdzy wydzialami powodowala, iz byly one dublowane.
• Zaleznosé aplikacji od struktury danych. Istniala scisla zaleznosé pomiçdzy plikiem a aplikacje je obslugujece. W przypadku zmiany struktury pliku nalezalo równiez przeprogramowaé aplikacjç.
• Brak mechanizmów jednoczesnego dostçpu do danych przez kilku uzytkowników oraz mechanizmów przywracania zawartosci bazy po awarii.
• Brak mozliwosci rozwiezania problemu relacji pomiçdzy danymi.
Problemy zwiezane z systemem plaskich plików zapoczetkowaly rozwój nowego oprogramowania - systemów zarzedzania baze danych.
3.2. Hierarchiczne bazy danych
Za pierwszy DBMS uwazane jest oprogramowanie do obslugi projektu Apollo, ktory powstal na poczqtku lat 60tych [1]. Zwiqzany on byl z zadaniem postawionym przez Prezydenta Kenndy'ego lotu czlowieka na ksiçzyc. Systemy bazujqce na plaskich plikach nie byly w stanie zgromadzic i nadzorowac takiej ilosci danych powstajqcych w zwiqzku z tym projektem. W rezultacie North American Aviation (NAA), glowny wykonawca projektu, stworzyla system dostçpu i modyfikacji danych znany jako GUAM (ang. Generalized Update Access Method).
Struktura GUAM powstawala z malych elementow lqczonych stopniowo w wiçksze komponenty, az do powstania koncowego systemu. W wyniku tego zbudowano drzewiastq struktur^ bazy danych. W polowie lat 60tych do projektu NAA przylqczyla siç firma IBM w efekcie, czego na bazie GUAM powstal system IMS (ang. Information Management System).
Sposob zapisu danych w IMS opieral siç na modelu hierarchicznym [1,912]. Przypominalo to obecny schemat zapisu systemu plikow. Struktura hierarchiczna zakladala, iz zwiqzki pomiçdzy danymi mogly zachodzic tylko typu 1 :N (rysunek nr 5).
Rysunek 5. Hierarchiczny model danych, wg [11]
Choc dopuszczano blizniacze powiqzania miçdzy rekordami podstawç struktury bazy stanowily relacje w kategoriach ojciec-syn,[12]. Oznaczalo to, iz rekord typu ojciec mogl byc powiqzany z wieloma rekordami typu syn. Sposob ich powiqzania mogl byc jawny, przez wskazniki, lub poprzez fizycznq organizacjç rekordow wewnqtrz pliku. Zmienna „poziom"
w modelu hierarchicznym definiowala jak glçboko dany rekord wystçpowal w strukturze drzewa [11]. Korzen (ang. root) struktury drzewa mial numer 1. Nastçpuj^ce po nim rekordy mialy kolejne numery. W modelu hierarchicznym dostçp do danych odbywal siç po zdefiniowanych sciezkach. Sciezka dostçpu jest to sekwencja rekordow pocz^wszy od korzenia poprzez kolejne rekordy typu syn.
Do zalet modelu hierarchicznego mozna zaliczyc prost^ i przejrzyst^ struktur^. Stanowilo to duze uproszczenie w obsludze baz danych, ktorych podstaw^ byla nawigacja. Niemniej taki sposob opisu danych posiadal liczne ograniczenia. Jednym z nich byl problem zaprojektowania bazy w przypadku, gdy rzeczywista struktura danych nie odzwierciedlala drzewa. W takich przypadkach dane byly dublowane celem zachowania struktury zwi^zkow jeden do wielu [9, 10]. Powodowalo to problemy z zachowaniem spojnosci danych. Bardzo latwo, bowiem moglo dosc do sytuacji, w ktorej jeden ze zdublowanych rekordow zostal zaktualizowany natomiast odpowiadaj^cy mu rekord nadmiarowy pominiçty [10]. Zwiçkszalo to ponadto koszty systemu poprzez zakup dodatkowych nosnikow pamiçci.
Wbrew swoim osobliwosciom, systemy oparte o model hierarchiczny stanowily w pewnym momencie znacz^c^ pozycjç w dziedzinie baz danych. Ich sukces wynikal z faktu iz w latach szescdziesi^tych podstawowym nosnikiem informacji byly tasmy magnetyczne z sekwencyjnym sposobem dostçpu do danych [11]. Umieszczenie na tasmie rekordu rodzica a po nim sekwencji rekordow potomkow (z odpowiednio ustawion^. zmienn^. poziom) skutkowalo tym, iz informacje z danej galçzi struktury drzewa przechowywane byly blisko siebie w pliku. Bylo to jednym z czynnikow decyduj^cym o szybkosci dzialania tych systemow.
IMS umozliwial rowniez jednoczesny dostçpu do danych wielu uzytkownikom. Dodatkowo wyposazony zostal w mechanizmy odzyskiwania danych [10].
IMS nie potrafil dokonywac identyfikacji danych przechowywanych w bazie poza reprezentacj^ relacji pomiçdzy rekordami [9]. Poszczegolne pola rekordow nie byly identyfikowane przez System zarz^dzania baz^. danych. Rekord widoczny byl jako liczba bajtow zawartych w danym polu. W konsekwencji, w systemach tych nie mozna bylo realizowac zapytan „ad hoc".
3.3. Sieciowe bazy danych
Ograniczenia wynikajqce ze struktury hierarchicznej probowano ominqc tworzqc systemy sieciowe. Dawaly one mozliwosc tworzenia zwiqzkow mi^dzy danymi typu wiele do wielu (N:N)
[9].
Rysunek 6: Przyktad stuktury sieciowej z widocznymi zwi^zkami N:N
Schemat oraz sposob budowy bazy danych opartej o model sieciowy dawal projektantom dosyc duzq swobod§. W zwiqzku z tym pojawilo si§ szereg rozwiqzan promowanych przez poszczegolnych producentow. Zazwyczaj jednak wykonywane projekty baz danych byly mocno specjalizowane, czyli dostosowywane do specyfiki przechowywanych danych. Projektant tworzqcy struktur^ bazy musial rowniez przewiedziec sposob, w jaki dane mogq byc w przyszlosci pozyskiwane z bazy. Aplikacja napisana do wspolpracy z bazq mogla tylko wykonywac zdefiniowane wczesniej operacje. Utrudnialo to w znacznym stopniu przenoszenie danych a takze komplikowalo wszelkie zmiany w dzialaniu aplikacji [9].
Bazy danych, hierarchiczne oraz sieciowe, mialy charakter nawigacyjny. Implementacja zaprojektowanej bazy danych polegala na fizycznym rozmieszczeniu rekordow zgodnie ze schematem lub utworzeniu odnosnikow mi^dzy rekordami. Nawigacja w bazie polegala na poruszaniu si§ po tych wskaznikach, przeglqdanie poszczegolnych rekordow i wybieraniu wlasciwych [11]. Kiedy baza danych zostala po raz pierwszy otwierana, program/uzytkownik, ktory do niej si§ lqczyl, otrzymywal na wst^pie dost^p do jej pierwszego rekordu. Rekord ten zazwyczaj zawieral zarazem wskaznik do dalszych zasobow bazy. Aby znalezc okreslone informacje programista musial przyglqdac poszczegolne rekordy dopoki nie trafil na wlasciwy rekord [10]. Proste zapytanie typu „Znajdz wszystkich ludzi z Polski", wymagalo przejscia okreslonej ilosci zdefiniowanych sciezek i wybranie rekordow odpowiadajqcych zapytaniu.
W polowie lat 60tych powstala juz duza liczba oprogramowania do zarzqdzania danymi. Kazde z nich mialo zazwyczaj swoj wlasny sposob implementacji oraz korzystania z zasobow bazy. W zwiqzku z tq roznorodnosciq powstal problem przenosnosci danych a takze wspolpracy
pomiçdzy tymi aplikacjami. Probç utworzenia standardu w systemach baz danych rozpocz^l Charles W. Bachmann (tworca systemu IDS ang. Integrated Data Storage). Zainicjowal on utworzenie wewn^trz organizacji o nazwie CODASYL (ang. Conference on Data Systems Languages) grupy DBTG (ang. Database Task Group) [9, 10], ktora miala siç zaj^c tworzeniem standardow w dziedzinie baz danych.
Wynikiem prac DBTG byl opublikowany raport, ktory zdefiniowal nastçpuj^ce pojçcia
[10]:
• Termin „baza danych" (ustalono, iz w jçzyku angielskim obowi^zywac bçdzie termin "database" zamiast "data base").
• Opracowano szkielet „slownika danych". Slownik danych zostal zaprojektowany celem przechowywania metadanych, wl^czaj^c informacje o rodzaju danych, relacjach pomiçdzy nimi oraz informacje, w jaki sposob programy powinny korzystac z bazy danych.
• Opracowano zalozenia standardowej architektury bazy danych, opartej o metodç zapisu BDAM oraz listç relacji.
• Zaproponowano separacjç logicznej struktury bazy od jej fizycznego zapisu oraz sposobu pozyskiwania danych.
• Opracowano procedury maj^ce na celu zapewnienie bezpieczenstwa oraz wielodostçpu do bazy. Wprowadzono metodç blokowania modyfikowanych rekordow.
• Zaproponowano koncepcyjny sposob opisu bazy.
Koncepcyjny model danych wymagal aby kazda baza danych zawierala logiczny opis swojej zwartosci. Opis ten powinien byc konstruowany na dwoch plaszczyznach, administratora systemu oraz uzytkownika [1]. Wyodrçbniono te dwie plaszczyzny poniewaz zlozonosc modelu sieciowego przysparzala wiele trudnosci uzytkownikom bazy.
Schemat bazy przeznaczony dla administratora zostal nazwany „schematem sieci" i zawieral definicjç bazy, jej nazwç, typy wszystkich rekordow oraz skladniki kazdego z typow rekordow, Natomiast schemat przeznaczony dla uzytkownika otrzymal nazwç „podschematu" i zawieral opis fragmentu bazy, z ktorego uzytkownik lub aplikacja miala korzystac. W zaleznosci o ilosci uzytkownikow lub aplikacji podschematow moglo byc wiele.
Dodatkowo grupa DBTG zaproponowala zunifikowane jçzyki zarz^dzania danymi. Pozwalalo to miçdzy innymi na rozdzielenie funkcji projektanta bazy od programistow a takze
zapewnilo wiçkszq czytelnosc projektow. Zaproponowany jçzyk zarzqdzania danymi pozwalal opisywac dane, struktur^ ich przechowywania a takze je przetwarzac. Dzielil siç na jçzyki [1]:
• opisu danych schematu sieci DDL (ang. Data Definition Language),
• opisu danych podschematu,
• manipulacji danymi DML (ang. Data Manipulation Language), ktory umozliwial programistom nawigowanie w strukturze bazy.
Jak wspomniano grupa DBTG rozpoczçla rowniez pracç nad dwoma waznymi aspektami dotyczqcymi technologii baz danych: wspolbieznosci oraz bezpieczenstwa [7]. Wspolbieznosc zrealizowano poprzez blokowanie odpowiednich obszarow bazy danych w przypadku rownoczesnego dostçpu do tego obszaru przez kilku uzytkownikow. Natomiast bezpieczenstwo umozliwialo ochronç obszarow danych odpowiednimi haslami.
Pod koniec lat 60tych istnialy w przemysle bazodanowym dwa rodzaje systemow zarzqdzania bazami danych. Model sieciowy rozwijany i regulowany przez CODASYL oraz hierarchiczny promowany przez firmç IBM i jej system IMS. Jednak te schematy opisu danych nie spelnialy wszystkich wymagan stawianych przed DBMS. Projektowanie baz danych z wykorzystaniem modelu hierarchicznego czy CODASYL nie mialo podstaw matematycznych. Jakosc zaprojektowanej aplikacji a pozniej sposob jej przeszukiwania zalezal od doswiadczenia projektantow [8].
3.4.Relacyjne bazy danych
Edgar F. Codd matematyk z Oxfordu postawil sobie problem opracowania zalozen DBMS, ktory spelnialby nastçpujqce zasady:
• Calkowitq niezaleznosc fizycznego zapisu danych od ich struktury logicznej;
• Matematyczne podstawy w sposobie przechowywania oraz pozyskiwania danych;
• Mozliwosc zadawania dowolnych zapytan przez uzytkownikow a nie tylko zdefiniowanych przez projektantow;
Badania przeprowadzone przez Codda daly poczqtek rozwojowi nowych systemow zarzqdzania bazami danych. W 1970 Codd opublikowal w raportach technicznych IBM artykul pod tytulem ,A Relational Model of Data for Large Shared Data Banks'' dajqc tym samym podstawy nowej organizacji przechowywania oraz dostçpu do danych [13]. Schemat organizacji danych nazwany zostal przez Codda modelem relacyjnym. Bazowal on w opracowaniu swojego
modelu na dwoch galçziach matematyki - teorii mnogosci oraz rachunku predykatow pierwszego rzçdu [1]. W swojej publikacji zaproponowal nowy system do przechowywania i pozyskiwania danych dla duzych centrow informacyjnych. Zamiast rekordow o zmiennej dlugosci i duzej swobodzie, uporz^dkowanych i pol^czonych wedlug pewnego wzoru (CODASYL) zaproponowal on przechowywanie danych w tabeli o rekordach stalej dlugosci. Wydajnosc takiego systemu moglby byc niska w przypadku sortowania duzych tabel z pustymi komorkami. Zaproponowany model relacyjny pokonywal ten problemem poprzez rozbicie jednej tabeli na wiele oraz przeniesienie opcjonalnych elementow z glownej tabeli do tabel z ni^. powi^zanych. W tabelach tych tworzone byly nowe rekordy wtedy tylko, gdy dane opcjonalne istnialy [10].
Rysunek 7: Model relacyjny
Model zapisu danych zaprezentowanych przez Codda pocz^tkowo zostal przyjçty przez naukowcow jako intelektualne kuriozum. Aby jego propozycja mogla doczekac siç realizacji Codd musial stoczyc dwie bitwy. Pierwsz^. wewn^trz IBM o realizacjç projektu, drug^ ze spolecznosci^ naukow^ promuj^c^ tradycyjne systemy zarz^dzania bazami danych [7].
W IBM problemem byl istniej^cy system zarz^dzania baz^ danych - IMS. Firma zainwestowala olbrzymie naklady finansowe i organizacyjne w infrastruktur ç oraz ekspertow koniecznych do sprzedazy produktu. Wprowadzenie nowej technologii spowodowaloby, wiçc iz poczynione naklady nie zostalyby zrekompensowane. Przeslanki te powodowaly, ze zainteresowanie IBM w rozbudowç projektu Codda bylo minimalne.
Dodatkowo jak wspomniano wczesniej propozycja Codda odnosnie systemu relacyjnego odbierana byla przez naukowcow z dziedziny baz danych jako nierealna [7]. Chc^c popularyzowac swoj projekt Codd zorganizowal publiczn^ debatç pomiçdzy nim a Charlesem Bachmanem, w owym czasie kluczow^ postaci^ w CODASYL. Debata ta spotkala siç z krytyk^. ze strony IBM
poniewaz podminowywala jej strategiczny produkt - IMS. Jednak odniosla wymierny skutek. Na poczqtku lat siedemdziesiqtych ukazaly siç dwa projekty majqce na celu implementacjç zalozen Codda. Pierwszy z nich o nazwie System R [15], rozwijany byl przez IBM drugi o nazwie Ingres na Uniwersytecie Berkeley w Kalifornii [16].
Prace nad budowq Systemu R trwaly okolo 9 lat. Na przelomie 197475 zbudowano prototyp sytemu celem dokonania prezentacji jego mozliwosci. Na pelnowartosciowy produkt trzeba bylo jednak czekac do roku 1979. Najwazniejszym osiqgniçciem jednak zespolu pracujqcego nad Systemem R bylo opracowanie jçzyka zapytan bazy danych o nazwie SQL (ang. Structured Query Language) [17]. Jçzyk ten stal siç amerykanskim a pozniej miçdzynarodowym standardem pozyskiwania oraz manipulacji danymi w relacyjnych bazach danych.
Pod koniec roku 1973 dwoch naukowcow z Uniwersytetu Berkeley, Michael Stonebraker oraz Eugene Wong zainteresowalo siç mozliwosciami systemow relacyjnych. Pozyskawszy pieniqdze na rozwoj, rozpoczçli pracç nad budowq systemu opartego o model relacyjny. System ten uzyskal nazwç Ingres (ang.Interactive Graphics and Retrieval System). Ingres rozwijany byl podobnie do Systemu R jednakze budowany z przeznaczeniem na inne platformy sprzçtowe i systemowe [7]. Projekt zapoczqtkowany na Uniwersytecie Berkeley zaczql byc rozwijany przez male grupy pasjonatow zarowno na uczelniach jak i poza nimi. Ingres rowniez poslugiwal siç ustrukturyzowanym jçzykiem zapytan bazy danych o nazwie QUEL nieznacznie rozniqcy siç od IBM SQL [16].
Fakt rozwijania Ingres przez szerokq spolecznosc informatycznq przyczynil siç do sukcesu modelu relacyjnego. Liczne publikacje oraz otwartosc kodu spowodowaly iz zastosowane rozwiqzania szybko zaczçly przyjmowac siç w biznesie [7]. Dzisiaj systemy relacyjne oparte na przechowywaniu danych w tabelach sq najpowszechniej wykorzystywanym sposobem przechowywania danych.
3.5. Obiektowe bazy danych
Model relacyjny mimo odniesionego sukcesu posiadal kilka ograniczen. Jednym z nich byla obsluga bardzo malej ilosci typow danych. Najczçsciej byly to tekst, data, liczby i kilka innych. W polowie lat osiemdziesiqtych powstala cala gama aplikacji typu GIS, CAD (ang. Computer Aided Design), CAM (ang. Computer Aided Manufacture), ktore wymagaly przechowywania danych, o typach niezbyt nadajqcych siç dla relacyjnych baz danych [18,19]. Dodatkowo coraz
wi^ksz^ popularnosc zdobywaly obiektowe j^zyki programowania, ktore sposobem organizacji aplikacji i reprezentacji danych roznily si§ istotnie od programowania strukturalnego stosowanego przy relacyjnych bazach danych. Zawsze zachodzila mozliwosc przeksztalcenia na obiekty danych przechowywanych w relacyjnych bazach, jednak wymagalo to wielu pracochlonnych przerobek aplikacji i odchodzilo od istoty aplikacji obiektowych. Braki te daly pocz^tek rozwojowi obiektowych systemow zarz^dzania bazami danych. Obiektowe bazy danych opieraly si§ na paradygmacie obiektowym zapocz^tkowanym przez Norwega Kristena Nygarrda. W tradycyjnych systemach dane oraz procedury przechowywane byly oddzielnie (dane i relacje w bazie natomiast procedury w programie uzytkowym) [19]. W modelu obiektowym nast^puje pol^czenie procedur wykonywanych na relacjach - lub bardziej ogolnie na encjach [18] - z jej danymi.
W wyniku tego pol^czenia encje staj^ si§ niezaleznymi jednostkami, ktore stosunkowo latwo mog^ byc wielokrotnie wykorzystywane i przenoszone. Zachowanie encji nie jest juz powi^zane z okreslonym programem uzytkowym, lecz stanowi cz^sc samej encji, tak wi§c bez wzgl^du na to, gdzie jest uzyta, zachowuje si§ w przewidywalny, znany sposob.
Rysunek 8: Struktura obiektowej bazy danych
Obiektowe bazy danych nie byly ewolucjq baz relacyjnych lecz raczej alternatywq dla nich. Obiektowe bazy danych uwazane sq jako powrot do systemow hierarchicznych i sieciowych. Rozwoj obiektowych baz danych wynikal z popularyzacji jçzykow programowania takich jak Smalltalk, C++ czy Java, ktore wymagaly obiektowego podejscia do przechowywania oraz pozyskiwania informacji z bazy.
3.6. Obiektowo-relacyjne bazy danych
Powstanie obiektowych baz danych mial bezposredni wplyw na relacyjne bazy danych. Zauwazono, iz obiektowe bazy danych wprawdzie doskonale nadajq siç do kompleksowej obslugi wszystkich typow danych, jednak posiadajq duze ograniczenia w obsludze jçzykow zapytan [9]. Implementacja jçzykow zapytan w obiektowych bazach danych wydala siç na tyle trudna, iz prostsza bylaby rozbudowa relacyjnych baz danych o obslugç dodatkowych typow danych. Badania przeprowadzone miçdzy innymi przez Michaela Stonebrakera przyczynily siç do powstania nowej grupy systemow zarzqdzania bazami danych. Nowe oprogramowanie zostalo nazwane obiektoworelacyjne i porownaniu do tradycyjnych systemow relacyjnych zostalo rozbudowane o dodatkowe mozliwosci, w postaci [20]:
• obslugi rozszerzonych typow danych definiowanych przez uzytkownikow,
• obslugi obiektow przez ustrukturyzowany jçzyk zapytan SQL,
• mozliwosc dziedziczenia wbudowana w jçzyk SQL,
• wprowadzenie tzw. wyzwalaczy czyli procedur uruchamianych automatycznie w przypadku zaistnienia zdefiniowanego przypadku.
Mimo wielu niedoskonalosci obiektoworelacyjne DBMS staly siç obecnie najczçsciej wykorzystywanym oprogramowaniem do obslugi baz danych. Szacuje siç, iz okolo 95% systemow gromadzenia i przetwarzania danych bazuje na tym modelu danych.
4. Kierunki rozwoj u
Technologia baz danych znajduje siç w ciqglym rozwoju. Obecnie dla naukowcow najwiçkszym problemem jest przechowywanie bardzo duzych ilosci danych. Proby rozwiqzania tych problemow ukierunkowane sq na:
• opracowanie nowego modelu danych - strumieniowe bazy danych [21,22],
• modernizacjç sposobu zapisu danych na nosnikach pamiçci [23],
• rozproszenie danych w sieci komputerowej [4, 9, 10, 24]
Prace nad rozproszonymi systemami baz danych zapocz^tkowane zostaly juz okolo roku 1980 [24]. Jednak dopiero rozwoj technik telekomunikacyjnych i zwi^zany z nim wzrost przepustowosci l^czy umozliwil wykorzystanie tych systemow do celow komercyjnych. Z rozproszonymi DBMS wi^ze siç szereg bardzo skomplikowanych problemow i obecnie s3 one jednym glownych projektow rozwijanych przez naukowcow z dziedziny baz danych.
Oprocz DBMS istnieje szereg innych technologii zwi^zanych z przetwarzaniem danych. Korzystaj^ one posrednio z Systemow zarz^dzania bazami danych, w sklad ich wchodz^:
• Hurtownie danych [1]. Zgodnie z definij hurtownia danych to zorientowana podmiotowo, zintegrowana, zroznicowana czasowo i trwala kolekcja danych przeznaczona do wspomagania procesu podejmowania decyzji. Hurtownie informacji zostaly zaproponowane organizacjom przemyslowym jako technologia pozwalaj^ca uzyc swoich archiwow danych jako srodka do uzyskania przewagi nad konkurenj
• Narzçdzia OLAP (ang. online analytical processing) [25]. Jest to technologia, ktora uzywa wielowymiarowych perspektyw zagregowanych danych w celu zapewnienia szybkiego dostçpu do strategicznych informacji przeznaczonych do zaawansowanych analiz. Technologia OLAP pozwala uzytkownikom na uzyskanie glçbszego zrozumienia oraz dodatkowej wiedzy o roznorodnych aspektach swoich danych korporacyjnych poprzez szybki, konsekwentny i interakcyjny dostçp do wielu odmian mozliwych sposobow widzenia danych.
• Eksploracja danych (ang. Data mining) [26]. Przed eksploracja danych postawione jest zadanie odkrywania wartosciowej wiedzy z bardzo duzych baz danych, hurtowni danych i innych informacyjnych repozytoriow.
Eksploracja danych jest dziedziny ukierunkowan^ na zastosowania. Problemy badawcze, ktore siç w niej podejmuje, s3 umotywowane specyfik^ dostçpnych zbiorow danych dotycz^cych swiata rzeczywistego.
• Mobilne bazy danych [1]. S3, to przenosne bazy danych, fizycznie odseparowane od serwera scentralizowanej bazy danych, lecz posiadaj3.ce mozliwosc komunikacji z odleglych lokalizacji z serwerem, dziçki czemu pozwalaj^ na wspoldzielenie danych firmowych. Rozwoj tych systemow jest nastçpstwem rozwoju komunikacji bezprzewodowej.
Oprogramowanie to w wiçkszosci przypadkow znajduje siç w fazie rozwoju jednak powstala juz znaczna liczba produktow komercyjnych implementujqcych te zalozenia.
5.Podsumowanie
Informacja stanowi kluczowq rolç w dzialaniu kazdej organizacji. Dlatego tez firmy starajq siç gromadzic jak najwiçcej danych i traktujqc je jako swoj kapital, odpowiednio chronic. Posiadanie odpowiednich informacji oraz wlasciwy sposob ich wykorzystania pozwala firmom uzyskac przewagç biznesowq nad konkurencjq.
Chociaz Panstwowa Straz Pozarna jest organizacjq „non profit" i nie posiada konkurencji, to presja spoleczna wymusza na niej skutecznosc oraz ekonomicznosc w dzialaniu.
Zakres oraz roznorodnosc danych przetwarzanych przez PSP jest bardzo duzy, poczqwszy od informacji o materialach i zwiqzkach niebezpiecznych a skonczywszy na konstrukcji elementow danego budynku i liczbie jego mieszkancow. Aby podniesc swojq skutecznosc oraz ekonomicznosc, PSP stançla przez trudnymi problemami technicznymi. Obecne systemy gromadzenia i przetwarzania danych [27] nie sq w stania sprostac lawinowo przyrastajqcym ilosciom informacji oraz wymaganiom co do sposobu ich przetwarzania i udostçpniania. Dlatego tez, konieczna jest reorganizacja systemow informatycznych w PSP. Modernizacja powinna byc przeprowadzona w obszarach:
• budowy odpowiednich struktur przechowywania danych, dopasowanych do rodzaju informacji - systemy relacyjne, obiektowe,
• metod pozyskiwania i aktualizacji informacji - budowa kanalow przeplywu informacji z innych instytucji np. urzçdow geodezyjnych, sluzb miejskich a takze pozyskiwanie danych z przeprowadzonych akcji i cwiczen,
• wymiany informacji pomiçdzy komorkami PSP oddalonymi od siebie geograficznie -budowa rozproszonych baz danych,
• zastosowania odpowiednich narzçdzi do analizy i eksploracji danych,
• dystrybucji danych oraz budowy mobilnych baz danych - dostçp do danych z samochodow pozarniczych lub innych mobilnych jednostek.
Dla wiçkszosci z przedstawionych problemow rozwiqzanie znalezc mozna w najnowszych osiqgniçciach techniki z dziedziny baz danych. Dlatego tez kluczem do podniesienia skutecznosci
dzialania PSP a takze obnizenia kosztow jej dzialalnosci jest wiedza z zakresu systemow baz danych.
Literatura
1. Connolly T. Begg C.: Systemy Baz Danych - projektowanie, wdrazanie i zarzqdzanie w praktyce. Tom 1 i 2. Warszawa 2003
2. Ullman J. D., Windom J.: Podstawowy wyklad z systemow baz danych. WNT Warszawa (2000)
3. Date C. J.: Wprowadzenie do systemow baz danych. WNT Warszawa 2000
4. Jones D. W.: Punched Cards A brief illustrated technical history.
http://www. cs.uiowa. edu/~j ones/cards/history. html
5. Philips N.V.: Everything about punch cards. (1967)
http : //www. tno. nl/instit/fel/museum/computer/en/punchcards. html
6. Gulliver D.: Sillicon Valley and Beyond. Berkeley Area Goverment Press Berkeley CA ( 1981)
7. National Research Council: Funding a Revolution: Government Support for Computing Research. NATIONAL ACADEMY PRESS Washington D. C. ( 1999)
8. Silberschatz A., Galvin P. B.: Podstawy systemow operacyjnych. WNT Warszawa ( 2000)
9. Jackson M.: Thirty years (and more) of databases. Information and Software Technology Nr 41
(1999)
10.Burleson D. K.: Managing Distributed Databases: Building Bridges between Database Islands. John Wiley & Sons New York (1994)
11.Date C. J.: Wprowadzenie do systemow baz danych. WNT Warszawa (1981)
12.Courtney J. F., Paradice D. B.: Database Systems for Managment. Times Mirror/Mosby College Publishing St. Louis (1988)
13.Codd E. F.: A relational model of data for large shared data banks. Communications of the ACM Nr 13 (1970)
14.GarciaMolina
H., Ullman J. D.: Implementacja systemow baz danych. WNT Warszawa (2000)
15.Chamberlin D. D. i inni: A History and Evaluation of System R. CACM 24, 10 (October 1981) pages 632646.
16.Stonebraker M.: Getting started in INGRES - a tutorial. Memorandum Nr ERLM518 23 kwiecien 1975. db.cs.berkeley.edu/papers/
17.McJones P.: The 1995 SQL Reunion: People, Projects, and Politics. 1995 http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html
18.Lausen G., Vossen G.: Obiektowe bazy danych. WNT Warszawa (2000)
19.Harrington J. L.: Obiektowe bazy danych. Micom Warszawa 2001.
20.Cattell R. G. G.: Object Data Management - ObjectOriented and Exetended Relational Database Systems. AddisonWesley Reading MA (1994)
21.http://wwwdb. stanford.edu/sdt/
22. http : //www. cs. cornell. edu/database/cougar/index.htm
23.http://www.sybase. com/tpcwhitepaper
24.Bell D. Grimson J.: Distributed Database Systems. AddisonWesley Reading MA 1994
25.OLAP Council White Paper http://www.olapcouncil.org/research/whtpapco.html
26.Kryszkiewicz M.: Eksploracja danych w telekomunikacji. Warszawa 2004 Konferencja Hurtownie Danych i Bussiness Intelligence
27.Praca zbiorowa: Efektywne metody zarzedzania ryzykiem zwiezane z ochrone ludnosci wg wlasciwosci terenowych organów administracji panstwowej i samorzedowej. SGSP Warszawa 200l
