Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00330 004422 14686879 na godz. na dobę w sumie
PostgreSQL. Wydanie II - książka
PostgreSQL. Wydanie II - książka
Autor: Liczba stron: 192
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3068-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> postgresql - programowanie
Porównaj ceny (książka, ebook, audiobook).

Jeśli baza danych, to tylko z PostgreSQL!

PostgreSQL jest jednym z najbardziej popularnych systemów zarządzania relacyjnymi bazami danych. To bezpłatne oprogramowanie jest rozwijane i wykorzystywane przez użytkowników na całym świecie. Cieszy się wsparciem dużych przedsiębiorstw tworzących rozwiązania bazodanowe i znajduje zastosowanie zarówno w przypadku niewielkich inicjatyw prywatnych, jak i poważnych środowisk komercyjnych. Doceniane za swoje możliwości, stabilność i wydajność działania oraz zgodność ze standardami, stanowi także podstawę nauczania teorii i praktyki w dziedzinie nowoczesnych systemów baz danych na wielu najbardziej prestiżowych uczelniach technicznych.

PostgreSQL jest niewątpliwie systemem, który musisz poznać, gdy planujesz rozpocząć karierę administratora baz danych, wybierasz taką specjalizację na studiach informatycznych lub po prostu chcesz zorientować się, na czym polega praca z relacyjnymi bazami danych w praktyce na przykładzie stale rozwijanego, popularnego środowiska. Dobrze będzie skorzystać przy tym z książki 'PostgreSQL. Wydanie II'. Prezentuje ona całą niezbędną teorię, stojącą za działaniem nowoczesnych baz danych, oraz strukturę i sposób korzystania z języka SQL. Znajdziesz w niej także zagadnienia związane z tworzeniem i używaniem bazy pracującej w oparciu o system PostgreSQL oraz budowaniem aplikacji bazodanowych.

Postaw na bezpłatne rozwiązania. Postaw na PostgreSQL!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

• Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treĈci Wprowadzenie. Dlaczego baza danych PostgreSQL? ............................................. 7 Rozdziaä 1. Relacyjny model bazy danych ............................................................ 9 Formalny model relacyjny danych ................................................................................. 11 Rozdziaä 2. Elementy jözyka ............................................................................. 19 Rozdziaä 3. Typy danych ................................................................................... 21 Rozdziaä 4. Operatory ....................................................................................... 27 Rozdziaä 5. Funkcje wbudowane w PostgreSQL ................................................. 35 Rozdziaä 6. Funkcje wbudowane i funkcje grupowe jözyka SQL .......................... 41 Funkcje wbudowane w strukturĊ SQL ............................................................................ 41 Funkcje grupowe ............................................................................................................ 42 Rozdziaä 7. Polecenia SQL ................................................................................ 45 abort ................................................................................................................................ 46 alter ................................................................................................................................. 47 alter table .................................................................................................................. 47 alter user ................................................................................................................... 47 begin ............................................................................................................................... 48 cluster ............................................................................................................................. 48 close ................................................................................................................................ 48 commit ............................................................................................................................ 49 copy ................................................................................................................................ 49 create .............................................................................................................................. 50 create aggregate ........................................................................................................ 50 create constraint trigger ............................................................................................ 50 create database ......................................................................................................... 51 create function .......................................................................................................... 51 create group .............................................................................................................. 52 create index .............................................................................................................. 52 create language ......................................................................................................... 52 create operator .......................................................................................................... 54 create rule ................................................................................................................. 54 create sequence ......................................................................................................... 55 create table ............................................................................................................... 55 create trigger ............................................................................................................. 56 4 PostgreSQL create type ................................................................................................................ 56 create user ................................................................................................................ 57 create view ............................................................................................................... 58 declare ............................................................................................................................ 58 delete .............................................................................................................................. 59 drop ................................................................................................................................ 59 drop aggregate .......................................................................................................... 59 drop database ............................................................................................................ 60 drop function ............................................................................................................ 60 drop group ................................................................................................................ 60 drop index ................................................................................................................ 61 drop language ........................................................................................................... 61 drop operator ............................................................................................................ 61 drop rule ................................................................................................................... 62 drop sequence ........................................................................................................... 62 drop table .................................................................................................................. 62 drop trigger ............................................................................................................... 63 drop type .................................................................................................................. 63 drop user ................................................................................................................... 63 drop view .................................................................................................................. 63 end work ......................................................................................................................... 64 explain ............................................................................................................................ 64 fetch ................................................................................................................................ 64 grant ................................................................................................................................ 65 insert ............................................................................................................................... 65 listen ............................................................................................................................... 66 load ................................................................................................................................. 66 lock ................................................................................................................................. 67 move ............................................................................................................................... 67 notify .............................................................................................................................. 68 reset ................................................................................................................................ 68 revoke ............................................................................................................................. 68 rollback ........................................................................................................................... 69 select ............................................................................................................................... 69 set ................................................................................................................................... 70 show ............................................................................................................................... 71 unlisten ........................................................................................................................... 71 truncate ........................................................................................................................... 71 update ............................................................................................................................. 72 vacuum ........................................................................................................................... 72 Rozdziaä 8. Zarzñdzanie bazñ danych PostgreSQL ............................................. 73 Mechanizmy pracy bazy danych PostgreSQL ................................................................ 73 Instalacja serwera baz danych PostgreSQL z binariów .................................................. 75 Podstawowe czynnoĞci administracyjne ......................................................................... 78 Konfiguracja autoryzacji .......................................................................................... 80 Interaktywny monitor psql ....................................................................................... 80 Rozdziaä 9. Interfejs bazy danych PostgreSQL ................................................... 83 DostĊp do bazy danych poprzez strony WWW .............................................................. 83 UĪycie heitmla w celu uzyskania dostĊpu do bazy danych ........................................... 84 UĪycie AppGEN 4GL dla aplikacji web opartych na bazie danych PostgreSQL ..... 90 Interfejs CGI/DBI i jĊzyk Perl .................................................................................. 91 Spis treĈci 5 Zastosowanie wbudowanego w strony html jĊzyka skryptowego PHP w celu uzyskania dostĊpu do baz danych PostgreSQL ...................................................... 99 Zastosowanie interfejsu jĊzyka Python w celu uzyskania dostĊpu do baz PostgreSQL .......................................................................................................... 107 Uniwersalne interfejsy dostĊpu do bazy PostgreSQL ................................................... 108 Interfejs ODBC ...................................................................................................... 109 Interfejs OLEDB .................................................................................................... 113 Interfejs JDBC ........................................................................................................ 114 Preprocesor ecpg .......................................................................................................... 118 Rozdziaä 10. Budowa aplikacji bazodanowych ................................................... 121 Model bazy danych a PostgreSQL ................................................................................ 122 Model dziaáania firmy .................................................................................................. 125 Metodologia projektowania i wykonywania aplikacji bazodanowej ............................ 126 Praktyczna implementacja modelu ............................................................................... 128 Rozdziaä 11. Systemy replikacji danych w PostgreSQL ...................................... 143 ZewnĊtrzne narzĊdzia do replikacji danych .................................................................. 143 Mechanizmy replikacji wbudowane w bazĊ danych ..................................................... 145 Rozdziaä 12. Instalacja i konfiguracja bazy danych PostgreSQL ......................... 147 Wymagania systemowe ................................................................................................ 147 Instalacja PostgreSQL w Linuxie ................................................................................. 147 Konfiguracja procesu instalacyjnego ............................................................................ 149 Kompilacja i instalacja PostgreSQL ............................................................................. 150 Instalacja PostgreSQL na platformie Windows z uĪyciem cygwina ............................. 152 Instalacja PostgreSQL dla Windows ............................................................................ 155 Rozdziaä 13. Jözyki proceduralne w PostgreSQL ................................................ 159 JĊzyk PL/Tcl ................................................................................................................. 159 JĊzyk PL/pgsql ............................................................................................................. 160 JĊzyk PL/perl ................................................................................................................ 162 Kursory ......................................................................................................................... 163 Tworzenie wyzwalaczy ................................................................................................ 164 Rozdziaä 14. Tablice systemowe ....................................................................... 167 Rozdziaä 15. Multimedia w PostgreSQL ........................................................... 171 Dodatki ........................................................................................ 177 Funkcje dostĊpne w PostgreSQL .................................................................................. 177 Funkcje grupowe .......................................................................................................... 180 WyraĪenia regularne ..................................................................................................... 181 Zmienne bazy danych ................................................................................................... 182 Wykonywanie obliczeĔ w poleceniach SQL .................................................................... 182 Oracle a PostgreSQL .................................................................................................... 183 Elementy wspólne i róĪnice .................................................................................... 183 Aplikacje, czyli PL/SQL ........................................................................................ 186 Skorowidz ..................................................................................... 188 6 PostgreSQL Rozdziaä 10. Budowa aplikacji bazodanowych Budowanie kaĪdego programu jest trudnym zagadnieniem. Tworzenie zaĞ aplikacji bazodanowej jest szczególnie trudne. SpróbujĊ w tej czĊĞci ksiąĪki streĞciü pokrótce za- gadnienia, które naleĪaáoby rozpatrzyü, aby odnieĞü sukces w dziedzinie budowy progra- mów i baz danych. PostgreSQL stanowi doskonaáą bazĊ danych, na której moĪna oprzeü budowĊ i dziaáanie bardzo wymagających aplikacji, i to o strategicznym znaczeniu dla firm. Coraz czĊĞciej firmy decydują siĊ na uĪycie PostgreSQL wáaĞnie ze wzglĊdu na jego wysoką wydaj- noĞü, niezawodnoĞü i uniwersalnoĞü dostĊpu do danych. Zasadniczym problemem, przed jakim stają twórcy baz danych, jest prawidáowe mo- delowanie zjawisk Ğwiata rzeczywistego, które mają byü przeáoĪone na informacje uzyskiwane z bazy danych. Problem ten moĪna rozpatrzyü na páaszczyĨnie tego, co mamy gromadziü w bazie danych, w jaki sposób to czyniü, aby samo gromadzenie danych nie staáo siĊ udrĊką uĪytkowników, oraz w jaki sposób przechowywaü zebrane dane i od- zyskiwaü z nich niezbĊdne nam informacje. Cechą kaĪdego modelu jest to, Īe moĪe on tylko w sposób uproszczony opisywaü rzeczy- wistoĞü. Z reguáy jest to rzeczywistoĞü z dziedziny obrotu gospodarczego i zjawisk pokrewnych, ale równieĪ otaczającego nas Ğwiata, codziennych czynnoĞci, rozkáadów zajĊü, hobby i temu podobnych czynnoĞci Īyciowych. Stąd teĪ zaáoĪyü moĪna, Īe model nigdy nie bĊdzie doskonaáy, jak równieĪ i to, Īe ze zbudowanej bazy danych bĊdzie mogáa korzystaü doĞü ograniczona liczba uĪytkowników, gdyĪ zakres przechowywa- nej informacji z natury rzeczy musi byü ograniczony. Kolejną cechą modelu jest to, Īe modelowana rzeczywistoĞü zmienia siĊ, stąd teĪ pomimo pewnej elastycznoĞci modelu czas jego Īycia, jak równieĪ budowanej na nim bazy danych jest ograniczony. 122 PostgreSQL Model bazy danych a PostgreSQL Model bazy danych jest elementem abstrakcyjnym i niezaleĪnym od sprzĊtu i oprogra- mowania systemu operacyjnego czy teĪ bazy danych. JednakĪe juĪ na etapie tworzenia takiego modelu naleĪy wziąü pod uwagĊ pewne ograniczenia sprzĊtowe i programowe. Zacznijmy od przymierzenia siĊ z abstrakcyjnym modelem dziaáania firmy handlowej do bazy danych PostgreSQL. Pierwszym elementem, który naleĪy uwzglĊdniü, jest granica zasobów. To pojĊcie powinno uwzglĊdniaü zarówno iloĞü skáadowanej informacji, dáugoĞü Īycia informacji zawartej w bazie danych, jak równieĪ szybkoĞü dostĊpu do informacji. Rozpatrując te zagadnienia, naleĪy stwierdziü, Īe PostgreSQL, posiadający pewne perspektywy rozwoju, powinien speániü zaáoĪenia o nieprzekraczaniu przez model funkcjonowania przedsiĊbior- stwa granicy zasobów. JednakĪe to stwierdzenie jest prawdziwe jedynie dla maáych i Ğrednich przedsiĊbiorstw. W przypadku duĪych organizacji gospodarczych centrum, z którego moĪna wydobywaü informacje, musi byü z koniecznoĞci rozproszone. Z ograniczeniami zasobów moĪna walczyü poprzez modernizowanie sprzĊtu komputero- wego, na którym osadzone jest oprogramowanie motoru baz danych i sama fizyczna baza danych, jak równieĪ poprzez unowoczeĞnianie oprogramowania systemów operacyjnych i motorów baz danych. Te ostatnie czynnoĞci są szczególnie trudne do realizacji. Kolejnym elementem, który naleĪy uwzglĊdniü, jest Īądanie nowych aplikacji uĪyt- kowych opartych na posiadanej juĪ bazie danych. Ta cecha prowokowana przez uĪytkow- ników wynika z natury baz danych, gdyĪ z zaáoĪenia powinny one uáatwiaü i przyspieszaü dostĊp do informacji. UĪytkownicy na początku nie potrafią precyzyjnie okreĞliü swoich potrzeb, stąd w miarĊ wzrostu kultury obcowania z informacją zawartą w bazie danych ich oczekiwania w stosunku do aplikacji rosną. Z reguáy tylko nowe wersje pozwalają zaspokajaü te rosnące potrzeby. Rozpatrując to zagadnienie, naleĪy zaznaczyü, Īe PostgreSQL pozwala na doĞü swobodny rozwój aplikacji. MoĪliwoĞü ta wynika z wieloĞci dostĊpnych interfejsów do áączno- Ğci z bazą danych. Dobrze stworzony model funkcjonowania przedsiĊbiorstwa pozwala na wyodrĊbnienie szeregu oddzielnych zagadnieĔ, które stosunkowo áatwo przeksztaáciü w moduáy jednej aplikacji bazodanowej z moĪliwie ujednoliconą obsáugą. Dodatkowo, stosunkowo áatwo jest przenieĞü modele zbudowane za pomocą narzĊdzi CASE z in- nych platform bazodanowych na PostgreSQL. NastĊpnym elementem jest koniecznoĞü wymiany sprzĊtu i oprogramowania klienc- kiego. Zazwyczaj model i zbudowana na nim aplikacja nie wymuszają takich zmian w sprzĊcie i oprogramowaniu. JednakĪe szereg pomocniczych aplikacji funkcjonujących w firmie moĪe skutecznie wymuszaü cykliczne zmiany w oprogramowaniu i w sprzĊcie stosowanym równieĪ do prac z aplikacją obsáugi przedsiĊbiorstwa. PosáuĪenie siĊ tutaj mechanizmami Intranetu pozwala na ograniczenie takich dziaáaĔ. Z kolei oparcie siĊ na klastrze Linuxa i PostgreSQL pozwala na dynamiczne generowanie niezbĊdnej wy- dajnoĞci systemu. Rozdziaä 10. i Budowa aplikacji bazodanowych 123 Zastosowanie do budowy aplikacji na podstawie PostgreSQL musi mieĞciü siĊ w przyjĊ- tym modelu rozwoju przedsiĊbiorstwa, moĪliwych do poniesienia nakáadach, jak równieĪ przenoszalnoĞci bazy danych na inną platformĊ systemową i sprzĊtową, gdy istniejąca infrastruktura ulegnie uszkodzeniu lub producent wycofa swoje wsparcie dla przyjĊtego wczeĞniej przez nas rozwiązania i technologii. PostgreSQL jest z punktu widzenia plat- formy klienta odporny na takie dziaáania. Wynika to z faktu, Īe kilka interfejsów dostĊpu do bazy danych PostgreSQL jest uniwersalnych na tyle, Īe mogą funkcjonowaü nie- zaleĪnie od Ğrodowiska klienta. OczywiĞcie, najbardziej perspektywicznie zapowiada siĊ tutaj technologia oparta na jĊzyku Java i JDBC, ale równieĪ dostĊp poprzez serwer web z uĪyciem PHP. Ostatnim, ale równie waĪnym zagadnieniem, jakie naleĪy rozpatrzyü, jest zmiana uwarunkowaĔ prawnych, które wpáywaü mogą i zazwyczaj wpáywają na funkcjono- wanie systemu informatycznego i aplikacji bazodanowych w przedsiĊbiorstwie. Model funkcjonowania przedsiĊbiorstwa powinien uwzglĊdniaü nie tylko zastaną sytuacjĊ, ale równieĪ byü na tyle elastyczny, aby moĪna byáo wprowadziü poĪądane zmiany i mody- fikacje w bazie danych. Zmiana struktury baz danych pociąga za sobą koniecznoĞü zmian w wiĊkszoĞci moduáów tworzących zintegrowany system obsáugi przedsiĊbiorstwa. PostgreSQL jest w peáni relacyjną bazą danych, zaĞ relacje nie wystĊpują w bazie danych jako fizyczne obiekty. Dobrze przygotowany model moĪna z áatwoĞcią przenieĞü na strukturĊ bazy danych w PostgreSQL. MoĪna by rzec, Īe dopóki zaáoĪenia modelu dobrze korelują z relacyjnoĞcią bazy danych, to przeniesienie modelu na strukturĊ bazy danych i zapytania jest moĪliwe, a zmiany prawne nie powinny w istotny sposób wpáywaü na koniecznoĞü modyfikacji juĪ istniejących i poprawnie funkcjonujących moduáów. Rozpatrując problem modelowania zagadnieĔ gospodarczych i przenoszenia ich na grunt bazy danych PostgreSQL, naleĪy pamiĊtaü, Īe skonstruowanie modelu i nastĊpnie jego poprawne przeniesienie na bazĊ danych i aplikacje obsáugi baz danych nie wystar- czają do zagwarantowania rzeczywistego sukcesu aplikacji bazodanowej. Istnieje caáy szereg uwarunkowaĔ, które sprawiają, Īe aplikacja bazodanowa zbudowana na podstawie modelu uwzglĊdniającego granicĊ zasobów, koniecznoĞü modernizacji po stronie klienta, zmianĊ przepisów prawa i rodzące siĊ w miarĊ rozwoju systemu Īądania nowych aplikacji moĪe byü traktowana jako udana. Takie aplikacje odznaczają siĊ nastĊ- pującymi cechami:  Wykazują duĪą i rzeczywistą uĪytecznoĞü w pracy na poszczególnych stanowiskach. Im bardziej aplikacja okazuje siĊ speániaü oczekiwania uĪytkownika, tym jest lepsza. NaleĪy jednakĪe pamiĊtaü, Īe wraz z uĪytkowaniem systemów informatycznych rosną wymagania wobec posiadanej aplikacji i w stosunku do posiadanej bazy danych.  Aplikacja musi wspomagaü dziaáania organizacji (szczególnie gospodarczych) w osiąganiu ich celów. Stąd teĪ wymagania dla bazy danych firmy wysyákowej bĊdą róĪne od wymagaĔ firmy produkcyjnej, chociaĪ czĊĞü zaáoĪeĔ modelu bazy danych i aplikacji moĪe byü wspólna. 124 PostgreSQL  Baza danych i zbudowana na niej aplikacja powinny umoĪliwiaü bez wiĊkszych modyfikacji obsáugĊ innych niĪ obecnie zadaĔ, w miarĊ jak zmienia siĊ profil organizacji. Prawdopodobne kierunki zmian w dziaáaniu firm powinny byü uwzglĊdnione juĪ na etapie tworzenia modelu bazy danych.  Powstanie i wdroĪenie aplikacji bazodanowej powinno byü akceptowane przez uĪytkowników. Ten cel najtrudniej jest osiągnąü. Wynika to z faktu, Īe bardzo czĊsto firmy i organizacje posiadają uksztaátowaną historycznie strukturĊ i hierarchiĊ podlegáoĞci pracowniczej, od której trudno jest odstąpiü, a która okazuje siĊ przeszkodą w sprawnym przepáywie informacji. Dobrze zaprojektowana baza danych zakáada sprawny przepáyw informacji pomiĊdzy stanowiskami oraz pewną synchronizacjĊ w czasie operacji na bazie danych. Dotychczasowe, niezsynchronizowane dziaáania wielu pracowników nie mogą juĪ mieü miejsca, jeĪeli aplikacja ma obejmowaü i wspomagaü swoją pracą wiele stanowisk. W czasie projektowania aplikacji i tworzenia modelu bazy danych niezbĊdne jest uĞwiadomienie uĪytkownikom zmian związanych z wprowadzeniem systemu informatycznego i uzyskanie od nich akceptacji. Bez tego nawet najlepsza aplikacja nie zafunkcjonuje prawidáowo i nie speáni pokáadanych w niej nadziei.  Tworzenie aplikacji i wdroĪenie jej do dziaáania musi byü akceptowane przez zarząd organizacji. Dotyczy to zarówno akceptacji niezbĊdnych do poniesienia finansowych nakáadów początkowych, jak i akceptacji kosztów eksploatacji systemów. Konieczne jest równieĪ zaaprobowanie przez kierownictwo niezbĊdnych zmian organizacyjnych, w tym wzrostu roli kadry informatycznej w przedsiĊbiorstwie czy w administracji. Podsumowując, moĪna rzec, Īe dziĊki zrozumieniu rzeczywistych potrzeb organizacji i tworzących ją uĪytkowników moĪliwe jest opracowanie prawidáowego modelu bazy danych, na której ma funkcjonowaü aplikacja bazodanowa. Z kolei zrozumienie i akcepta- cja przez uĪytkowników przygotowanego i opracowanego modelu pozwala na peáne wykorzystanie moĪliwoĞci tkwiących w nowoczesnym systemie informatycznym zbu- dowanym na relacyjnej bazie danych. Bardzo czĊsto brak dobrego modelu bazy danych lub brak akceptacji wdraĪanego sys- temu informatycznego skutkuje jedynie ogromnymi kosztami i znikomą przydatnoĞcią aplikacji dla organizmów gospodarczych. Przewaga PostgreSQL w stosunku do innych baz danych wynika z prostoty obsáugi tej bazy danych, stosunkowo duĪej wydajnoĞci i niesamowitej mnogoĞci interfejsów do bazy danych. Nie sposób teĪ nie dostrzec, Īe wszystko to odbywa siĊ na zasadach licen- cyjnych niewymagających opáat. Ponadto na jednym serwerze moĪe byü umieszczonych wiele niezaleĪnych od siebie baz danych. ZwiĊksza to stopieĔ elastycznoĞci i pozwala na etapowe tworzenie i wdraĪanie aplikacji bazodanowych. Rozdziaä 10. i Budowa aplikacji bazodanowych 125 Model dziaäania firmy Zasadniczym elementem modelu danych jest okreĞlenie funkcji firmy lub organizacji i sporządzenie na podstawie opisu modelu danych. Model danych powinien okreĞlaü, które dane są niezbĊdne dla caáej organizacji, a które są jedynie danymi pomocniczymi. Pozwala to na skupienie siĊ na najwaĪniejszych celach i funkcjach firmy i na doáączenie potem funkcji pobocznych do zasadniczego modelu jej dziaáania. Z opisów zasadniczych funkcji i celów firmy powinna wynikaü struktura organizacyjna. Na podstawie formularzy moĪna okreĞliü podstawowe wymagania dotyczące przetwarza- nych na stanowisku danych, jednakĪe cele i funkcje organizacji muszą byü okreĞlone przez kierownictwo. W przypadku definicji funkcji przedsiĊbiorstwa naleĪy opracowaü:  Zakres Ğwiadczonych usáug lub towarów bĊdących przedmiotem zainteresowania firmy.  Czynniki niezbĊdne do osiągniĊcia celów stawianych sobie przez organizacjĊ. Chodzi tutaj przede wszystkim o czynnik ludzki, gdyĪ posiadane poĪądane cechy zaáogi stanowiü bĊdą o sukcesie lub poraĪce przedsiĊwziĊcia i bĊdą wpáywaü na postrzeganie systemu informatycznego przez uĪytkowników. Innym elementem bĊdą niezbĊdne do dziaáania maszyny i urządzenia oraz sposoby rozliczania pracy tych urządzeĔ. Szczególnie ten ostatni czynnik musi znaleĨü odzwierciedlenie w modelu dziaáania firmy, a póĨniej w modelu bazy danych.  ListĊ dáugo- i krótkoterminowych celów gospodarczych firmy.  Priorytety poszczególnych celów gospodarczych. BĊdą one róĪne w zaleĪnoĞci od stadium rozwoju firmy.  OkreĞlenie zadaĔ systemu informatycznego.  OcenĊ, które z istniejących juĪ systemów informatycznych mogą byü przydatne w dalszej dziaáalnoĞci firmy. Dotyczy to równieĪ systemów informatycznych, z których w sposób zautomatyzowany moĪna przenosiü dane do nowo tworzonej aplikacji bazodanowej. Na bazie zebranych informacji moĪna zamodelowaü dziaáanie firmy i okreĞliü kluczowe elementy w modelu dziaáania. Model pozwala na okreĞlenie wszelkich nieefektywnoĞci w procedurach uĪywanych dotychczas w firmie. Sztuką jest taka wspóápraca z kierowni- kami róĪnych szczebli, aby postrzegali zakáócenia i nieefektywnoĞci w dziaáaniu swoich dziaáów i pracowników na poszczególnych stanowiskach nie jako wytykanie báĊdów, a jako sposób na podniesienie wydajnoĞci. Pracownicy zaĞ powinni dostrzegaü w mo- delu dziaáania firmy sposób na wzrost páac lub chociaĪby na moĪliwoĞü zdobywania nowych kwalifikacji i doĞwiadczeĔ. Na bazie modelu dziaáania firmy moĪna zbudowaü model bazy danych, a dalej aplikacje bazodanowe. Tak utworzony system powinien dawaü typowe korzyĞci wynikające z zastosowania systemu informatycznego. Zasadniczą korzyĞcią jest zmniejszenie 126 PostgreSQL nakáadów pracy przy przetwarzaniu informacji. Dotychczasowe, czĊsto wielokrotne, wprowadzanie do systemów lub do formularzy jednakowej informacji moĪe zostaü wyeliminowane przez dobrze zaprojektowaną aplikacjĊ bazodanową. Baza danych, która stanowi podstawĊ systemów informatycznych, pozwala na wspólne posáugiwanie siĊ informacją zarówno przez dziaá ksiĊgowoĞci czy kadr, jak i przez dziaá handlowy i marketingu. Metodologia projektowania i wykonywania aplikacji bazodanowej Podczas budowania aplikacji bazodanowej moĪna natknąü siĊ na dwa zasadnicze pro- blemy. Jednym z nich jest prawidáowe zaprojektowanie aplikacji, zaĞ drugim jakoĞü jej wykonania. Oba te zagadnienia są ze sobą ĞciĞle związane. Pierwsze podejĞcie do zagadnienia stawia nas zwykle przed ogromną záoĪonoĞcią systemu, który ma obejmowaü firmĊ. Mechanizmem, który pozwala zmniejszyü wy- nikające z tego zagroĪenie zagubieniem jakichĞ istotnych rzeczy w procesie projek- towania, jest dzielenie zagadnienia na mniejsze czĊĞci. Wszystkie póĨniejsze zagad- nienia wiąĪą siĊ z rozwaĪaniem mniejszego i zamkniĊtego obszaru. Dopiero analiza strategiczna wiąĪe ze sobą poszczególne czĊĞci w wiĊkszą caáoĞü. Postaramy siĊ teraz omówiü zagadnienia związane z róĪnymi technikami tej analizy. Na etapie analizy strategicznej przedsiĊbiorstwa moĪna przeprowadzaü rozeznanie za- równo wĞród kadry zarządczej, jak i u Ğredniego personelu technicznego i biurowego. Na bazie zebranych informacji moĪna budowaü zarówno modele zbieĪne, w których sta- ramy siĊ uchwyciü elementy áączące poszczególne informacje w jedną wspólną caáoĞü, jak i rozbieĪne, sáuĪące odnalezieniu zasadniczych róĪnic w sposobie postrzegania istoty dziaáania przedsiĊbiorstwa. W efekcie powinniĞmy uzyskaü spójną informacjĊ, w wyniku której moĪna zbudowaü stabilny model. Podczas tworzenia modeli firmy waĪne jest uchwycenie jej zasadniczych zadaĔ. Nie od dziĞ przecieĪ wiadomo, Īe przedsiĊbiorstwo inaczej jest postrzegane przez wáaĞciciela, inaczej przez zarząd, zaĞ jeszcze inaczej przez Ğredni i niĪszy szczebel pracowniczy. Istotą hierarchii funkcji przedsiĊbiorstwa ma byü okreĞlenie tego, co powinna robiü firma. Wbrew obiegowym opiniom, czĊsto róĪni siĊ to znacznie od tego, co firma i jej poszczególni pracownicy robią w rzeczywistoĞci. NaleĪy tutaj rozpatrzyü wszystkie funkcje przedsiĊbiorstwa, a nie tylko te, które w chwili obecnej mają byü związane z in- formatyzacją czy automatyzacją pewnych procesów w firmie. Gdy juĪ zostaną sprecyzowane elementarne funkcje przedsiĊbiorstwa, naleĪy przystąpiü do analizy zdarzeĔ. Zdarzenia noszą cechĊ istotną z punktu widzenia przekazu in- formacji. Sprawiają one mianowicie, Īe uaktywniane są poszczególne elementarne funk- cje przedsiĊbiorstwa. Z reguáy teĪ zdarzenia powodują zmianĊ lub aktualizacjĊ pewnych danych albo same wywoáane są poprzez zmianĊ lub aktualizacjĊ danych. Rozdziaä 10. i Budowa aplikacji bazodanowych 127 W efekcie moĪna wyodrĊbniü pojedyncze obszary funkcjonowania przedsiĊbiorstwa, zamknąü je w moduáy (np. ksiĊgowoĞü, kadry, produkcja itp.) oraz okreĞliü zakres wspóá- dziaáania pomiĊdzy poszczególnymi moduáami. NaleĪy dąĪyü do tego, aby to, co zawarte jest w module, ĞciĞlej okreĞlaáo związki pomiĊdzy zdarzeniami i elementarnymi funkcjami niĪ to, co jest poza moduáem. Wynika to z faktu, Īe informacje i dane spoza pewnego monolitycznego obszaru dziaáania przedsiĊbiorstwa są trudniej dostĊpne niĪ dane we- wnątrz takiego obszaru, a czasami wrĊcz niedostĊpne. W ĞciĞle okreĞlonym module moĪna zbudowaü diagramy encji. EncjĊ naleĪy rozumieü jako cokolwiek, o czym chcemy przechowywaü informacjĊ w naszej bazie danych. Dobrym przykáadem diagramu encji jest związek towar – klient, w którym kaĪdy towar jest powiązany z klientem, który ten towar zamówiá lub kupiá. Na bazie diagramów encji moĪna wyodrĊbniü poszczególne atrybuty, doskonale opisu- jące encjĊ. Dla przykáadu, kaĪdy klient bĊdzie miaá swój adres, nazwisko lub nazwĊ, udzielony kredyt itp. Tego typu diagramy áatwo przekáadają siĊ na tabele i ich kolumny. Teraz, jeszcze przed zbudowaniem tabel, naleĪy okreĞliü związki relacyjne. W zasadzie są ich trzy rodzaje:  Jeden do jednego — rzadko spotykany; z reguáy jest to sygnaá, iĪ byü moĪe diagram encji zostaá niepoprawnie zbudowany.  Jeden do wielu — najbardziej rozpowszechniony rodzaj związku; doskonale moĪna go zobrazowaü tym, Īe jeden klient moĪe mieü kilka adresów, pod które wysyáany jest towar z zamówienia.  Wiele do wielu — czĊsto wskazuje to na potrzebĊ dalszej normalizacji encji, chociaĪ równie czĊsto záoĪonoĞü systemu wymusza stosowanie tego typu związków. Dokáadniejsza analiza obiegu dokumentów z reguáy wystarcza do wyjaĞnienia sprawy. Podczas analizy związków encji moĪliwe staje siĊ wyodrĊbnienie podtypów i nadtypów encji. Pozwala to na skupienie siĊ tylko na niezbĊdnym nam zakresie informacji poprzez stworzenie nadtypów lub dalsze uszczegóáowienie informacji poprzez wydzielenie podtypów. Kolejny etap to porównanie przetwarzanej przez dany moduá informacji z informacją przetwarzaną w ramach innego, wyodrĊbnionego wczeĞniej moduáu. Taka analiza jedno- stek w przedsiĊbiorstwie ma na celu okreĞlenie, czy nie zachodzi niepotrzebne dublowanie wprowadzania, analizowania lub przetwarzania informacji. Trzeba pamiĊtaü o tym, Īe kaĪde takie dublowanie siĊ obciąĪa dodatkowymi kosztami przedsiĊbiorstwo i obniĪa jego zdolnoĞü do konkurencji. Czasem jednak moĪe siĊ równieĪ okazaü, Īe nie sposób wyeli- minowaü dublowania siĊ pewnych czynnoĞci, szczególnie na rozproszonej bazie danych. W efekcie podjĊtych dziaáaĔ powinniĞmy otrzymaü model logiczny, zaĞ na bazie dia- gramów encji moĪliwe jest stworzenie diagramów przepáywu danych. Teraz pozostaje wybraü mechanizmy dziaáaĔ oraz opisaü procedury realizacji elementarnych funkcji. Te elementy opisowe powinny pomóc nam podczas wdraĪania aplikacji zbudowanej na bazie naszych analiz. 128 PostgreSQL Etap projektowania powinien zakoĔczyü siĊ powtórną analizą. Brak kontroli na etapie projektowania czĊsto powoduje powstanie zasadniczych báĊdów, które są niemoĪliwe do wyeliminowania w przyszáoĞci i mogą spowodowaü, Īe caáy proces tworzenia i wdra- Īania aplikacji bazodanowej zakoĔczy siĊ niepowodzeniem. Metodologia wykonania sprowadza siĊ do wyboru odpowiedniej platformy systemowej, na której ma byü osadzona aplikacja, wyboru narzĊdzi i bazy danych oraz zapewnienia standardów jakoĞciowych. Wybór platformy systemowej z reguáy nie jest trudny. Platform znaczących jest obecnie niezbyt duĪo i czĊsto wybór ten związany jest z wyborem narzĊdzi czy teĪ bazy danych. PostgreSQL jako baza danych doskonale wspóápracuje z rodziną systemów uniksowych. Stąd teĪ wybór tego rodzaju systemu wydaje siĊ najbardziej celowy. SpoĞród systemów klasy Posix wyróĪnia siĊ, w sensie pozytywnym, Linux. Wybór tej platformy jest atrak- cyjny zarówno z uwagi na nowoczesne technologie zastosowane podczas jej tworzenia, jak i ze wzglĊdów cenowych. Z kolei dla firm, gdzie systemy Posix nie wystĊpują, byü moĪe do przyjĊcia bĊdzie korzystanie z platformy Windows. Najnowsze wersje PostgreSQL są dostĊpne dla tej platformy. NarzĊdzia do tworzenia aplikacji bazodanowej mogą zaĞ byü róĪne, gdyĪ róĪne bĊdą platformy klienckich stacji roboczych czy teĪ zorganizowania siĊ przedsiĊbiorstwa. Stąd teĪ dla jednych podstawowy moĪe byü wybór MS Accessa jako warstwy obsáu- gującej klienta aplikacji, zaĞ dla innych celowe bĊdzie przeorientowanie siĊ na serwis web, poprzez który bĊdzie nastĊpowaáa interakcja z bazą danych. Kolejnym elementem znaczącym dla procesu powstawania oprogramowania jest przy- jĊcie standardów zapewnienia jakoĞci oraz modelu pozyskiwania informacji dla osób zarządzających poszczególnymi dziaáami i caáoĞcią firmy. Praktyczna implementacja modelu ZaáóĪmy, Īe zostaáy juĪ zbadane cele firmy oraz Īe model dziaáania przedsiĊbiorstwa zostaá pozytywnie zaopiniowany. Wydzielone bloki zagadnieĔ pozwalają na zamkniĊcie danych w hermetyczne struktury, z których pobór informacji, uzupeánianie i wymiana nastĊpowaü bĊdą poprzez ĞciĞle zdefiniowane interfejsy. Doskonaáym przykáadem takiej implementacji jest zagadnienie związane z obsáugą magazynu hurtowni. Staáym elementem tej czĊĞci firmy jest nieustanny obrót towa- rowy i dokumentowy wyraĪony w pieniądzach, iloĞci towarów i asortymencie. Zanim rozpoczniemy tworzenie aplikacji, warto przygotowaü i przetestowaü skrypt powáoki shell, gdyĪ przyda siĊ on nam do zautomatyzowania procesu tworzenia bazy danych. Rozdziaä 10. i Budowa aplikacji bazodanowych 129 Skrypt mógáby wyglądaü nastĊpująco: #!/bin/sh psql -d template1 ! /* usuniecie starej bazy danych */ drop database firma; /* utworzenie nowej bazy danych */ create database firma; /* podáaczenie sie do bazy danych */ \connect firma /* utworzenie przykladowej tabeli */ DROP TABLE test; CREATE TABLE test ( id_test serial not null primary key test char(25) NOT NULL, opcja boolean NOT NULL CHECK (tak = 1 OR nie= 0 ) , data date DEFAULT CURRENT_DATE ); \q ! Mechanizm dziaáania skryptu jest stosunkowo prosty. Po podáączeniu siĊ do wzorcowej bazy danych template1 usuwana jest poprzednia wersja bazy danych (uwaga! — wraz z danymi), nastĊpnie generowana jest nowa baza danych firma, a po podáączeniu siĊ do nowo utworzonej bazy danych wysyáany jest ciąg zapytaĔ SQL, który tworzy strukturĊ bazy danych. Takie rozwiązanie jest bardzo wygodne, gdyĪ w poáączeniu z automatycznym eks- portem pozwala to na bardzo szybkie odtworzenie stanu bazy danych sprzed awarii. RozwaĪmy teraz zagadnienie obrotu magazynowego od strony asortymentu. W magazy- nie znajdują siĊ towary, których stan moĪe byü zerowy, które byáy kiedyĞ juĪ w sprzedaĪy i obecnie są wycofane z obrotu, oraz nowe towary, które bĊdą pojawiaü siĊ w magazynie przedsiĊbiorstwa. Stąd teĪ wszystkie elementy pozwalające wyróĪniü towar powinny byü zgrupowane w jednej zasadniczej tabeli. Dane z takiej tabeli nie mogą byü usuwane, gdyĪ moĪe to spowodowaü problemy z dokumentami, na których przecieĪ muszą widnieü nazwy towaru. Na tym drobnym przykáadzie widaü, Īe naleĪy przyjąü ogólną zasadĊ nieusuwania danych z bazy danych. KaĪde dane, które usuniemy z bazy danych, są tracone bezpowrotnie. Bardzo czĊsto tuĪ po usuniĊciu danych niezbĊdne jest skorzystanie z nich. Stąd teĪ, gdy usuniĊcia danych nie moĪna uniknąü, naleĪaáoby z usuwanych danych sporządziü zestawienia zbiorcze i te przechowywaü dáuĪej w bazie danych. Magazyn towarów posáugujący siĊ semantyką asortymentową musi obejmowaü pewne elementy charakterystyki, które moĪna przedstawiü w postaci tabeli encji (tabela 10.1). 130 PostgreSQL Tabela 10.1. Tablica z charakterystyką asortymentu Lp. 1. 2. 3. 4. 5. 6. 7. 8. 9. Nazwa atrybutu Indeks Nazwa asortymentu Magazyn VAT Akcyza Miara SWW Grupa towarowa Dostawca towaru Charakterystyka Ciąg znaków alfanumerycznych Tekst nazwy Opis magazynu Stawka podatku VAT Stawka podatku akcyzowego Jednostka miary Symbol SWW Rodzaj towaru lub grupy Nazwa dostawcy towaru Elementem encji, który pozwoli poáączyü te zapisy w bazie danych z innymi, bĊdzie uni- katowy indeks lub nazwa towaru. Innym wyjĞciem jest ustanowienie zupeánie niezaleĪ- nego klucza gáównego dla zbioru asortymentu. Zazwyczaj uĪywa siĊ tutaj sekwencji, która moĪe byü w prosty sposób utworzona i wywoáana podczas wstawiania wartoĞci do tabeli. drop sequence ID create sequence ID increment 10 start 10; Sekwencja jest pewnym szeregiem liczb caákowitych, stąd teĪ unikniemy powtórzeĔ, gdy bĊdziemy podawaü kolejne wartoĞci z sekwencji. Dobrym zwyczajem jest uĪywanie tej samej sekwencji dla tej samej grupy zbiorów. W tabeli encji pewne atrybuty moĪna by byáo wyróĪniü w postaci sáowników, z których wartoĞci byáyby wybierane do tabeli zasadniczej. Do takich atrybutów naleĪą stawka VAT, stawka podatku akcyzowego, jednostka miary, symbol SWW oraz grupa towarowa i nazwa dostawcy. PowyĪszą tabelĊ moĪna przestawiü w postaci zapytania SQL. drop table asortyment; create table asortyment ( id_asortyment integer not null primary key default nextval( id ), asortyment text not null, id_magazyn integer references magazyn(id_magazyn), id_VAT integer references VAT(id_VAT) not null, id_akcyza integer references akcyza(id_akcyza), id_miara intteger references miara(id_miara) not null, index char(15) not null, id_grupa integer references grupa(id_grupa) not null, id_SWW integer references sww(id_sww), id_kontrahent integer references kontrahent(id_kontrahent) not null, opakowanie_zwrotne boolean not null default no , stempel_czasowy timestamp not null default now() ); Rozdziaä 10. i Budowa aplikacji bazodanowych 131 Tablice sáownikowe zostaną utworzone po wysáaniu do bazy danych zapytaĔ, takich jak poniĪej. drop table magazyn; create table magazyn ( id_magazyn integer not null primary key default nextval( id ), magazyn char(25) not null, lokacja text not null ); drop table vat; create table vat ( id_VAT integer not null primary key default nextval( id ), vat integer not null default 22 ); drop table akcyza; create table akcyza ( id_akcyza integer not null primary key default nextval( id ), akcyza integer not null ); drop table miara; create table miara ( id_miara integer not null primary key default nextval( id ), miara char(10) not null ); drop table grupa; create table grupa ( id_grupa integer not null primary key default nextval( id ), grupa text not null, index_grp char(15) not null ); drop table sww; create table sww ( id_SWW integer not null primary key default nextval( id ), SWW char(25) not null, nazwa text not null ); Powiązania pomiĊdzy tablicami sáownikowymi a tablicą zasadniczą wymuszane są po- przez polecenie references. NaleĪy przy tym pamiĊtaü o tym, Īe wiĊzy integralnoĞci są 132 PostgreSQL wymuszane dopiero w najnowszych wersjach bazy danych, oraz o problemach z warto- Ğcią null. Te ostatnie moĪna rozwiązaü, stosując podzapytania do zapytania gáównego. PostgreSQL na razie nie obsáuguje powiązaĔ zewnĊtrznych, ale nie jest to problem záo- Īony i stosunkowo áatwo jest znaleĨü rozwiązanie zadowalające programistów. Oczywiste teĪ jest to, Īe tablice sáownikowe powinny byü zawsze tworzone przed utwo- rzeniem tabeli gáównej, inaczej nie bĊdzie moĪna powoáaü siĊ na referencje do obiektu bazy danych, który przecieĪ jeszcze nie istnieje. Skupmy siĊ teraz na kontrahencie, który wobec firmy moĪe peániü rolĊ dostawcy lub odbiorcy towarów albo teĪ obie te role áącznie. MoĪliwe jest równieĪ, Īe kontrahent peáni rolĊ usáugową i nie ma bezpoĞredniego związku z asortymentem. Zatem tylko czĊĞü kontrahentów i informacji o nich bĊdzie związana z asortymentem, który stanowi przedmiot obrotu firmy handlowej lub produkcyjnej. BĊdą to oczywiĞcie dostawcy to- warów, bezpoĞrednio związani z konkretnym towarem, ale równieĪ odbiorcy towarów, których związki nie uwidocznią siĊ w powiązaniach grup zbioru nazw towarów (asor- tyment) i zbioru kontrahentów (dostawców). Przykáadowa tabela encji moĪe wyglądaü nastĊpująco (tabela 10.2). Tabela 10.2. Tablica z charakterystyką dostawcy Lp. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Nazwa atrybutu Firma Nazwisko ImiĊ NIP Regon MiejscowoĞü Ulica Numer domu Numer lokalu Poczta Kod pocztowy Region PaĔstwo Typ kontrahenta Status Charakterystyka Nazwa przedsiĊbiorstwa Nazwisko wáaĞciciela lub osoby odpowiedzialnej ImiĊ wáaĞciciela lub osoby odpowiedzialnej Numer identyfikacji podatkowej Numer statystyczny MiejscowoĞü bĊdąca siedzibą firmy Nazwa ulicy Numer domu Numer biura Poczta Kod pocztowy Powiat lub województwo Nazwa paĔstwa siedziby kontrahenta Dostawca lub odbiorca OkreĞlenie, czy kontrahent jest aktywny Podobnie jak to miaáo miejsce poprzednio, z tablicy encji moĪna wyodrĊbniü atrybu- ty, które z áatwoĞcią dadzą siĊ przeksztaáciü w tabele sáownikowe. Stąd teĪ zapytania tworzące grupĊ tabel związanych z kontrahentem mogáyby wyglądaü nastĊpująco: drop table kontrahent; create table kontrahent ( Rozdziaä 10. i Budowa aplikacji bazodanowych 133 id_kontrahent integer not null primary key default nextval( id ), nazwa text not null, nazwisko text, imie text, NIP char(10) not null, REGON char(20), miejscowosc text not null, ulica text, nr_domu char(5) not null, nr_lokalu char(5), poczta text not null, kod_pocztowy char(6) not null, id_powiat integer references powiat(id_powiat) not null default 0, id_panstwo integer references panstwo(id_panstwo) not null default 0, id_typ integer references typ(id_typ) not null default 0, id_status integer references status(id_status) not null default 0, stempel_czasowy timestamp not null default now() ); Teraz spróbujmy utworzyü zapytania tworzące sáowniki do tej grupy danych, które związane są z informacjami o kontrahentach. PamiĊtajmy przy tym, Īe w rzeczywistej bazie danych najpierw tworzymy sáownik, a dopiero potem tabelĊ powiązaną z tym sáownikiem. drop table panstwo; create table panstwo ( id_panstwo integer not null primary key default nextval( id ), panstwo text not null ); drop table powiat; create table powiat ( id_powiat integer not null primary key default nextval( id ), wojewodztwo text not null, powiat text not null ); drop table typ; create table typ ( id_typ integer not null primary key default nextval( id ), typ text ); drop table status; create table status ( id_status integer not null primary key default nextval( id ), status text ); 134 PostgreSQL Na koniec przeanalizujmy dane zawierające rzeczywiste informacje o stanach maga- zynowych. Z danych tych bĊdą przecieĪ korzystaü zarówno osoby przyjmujące towar do magazynu, jak i sprzedawcy oraz osoby odpowiedzialne za zamówienia, analizy przepáywów i rotacji itp. Zasadnicze dane przechowywane w tej grupie tabel (tabela 10.3) to informacje o iloĞci danego towaru, cenie zakupu, cenie sprzedaĪy i, jeĞli jest to szybko psujący siĊ produkt, o okresie przydatnoĞci do uĪycia. Tabela 10.3. Tablica z charakterystyką magazynu w ujĊciu iloĞciowym i cenowym Lp. 1. 2. 3. 4. Nazwa atrybutu Nazwa asortymentu Cena zakupu Cena sprzedaĪy IloĞü Charakterystyka Tekst nazwy Cena nabycia towaru Aktualna cena sprzedaĪy Aktualna iloĞü towaru w magazynie Z tablicy encji áatwo juĪ jest utworzyü konkretne zapytanie tworzące tabelĊ. Ta ostatnia, w odróĪnieniu od poprzednich tabel, nie bĊdzie otoczona sáownikami, gdyĪ są one zu- peánie zbĊdne w przypadku tej grupy danych. drop table pozycje_mag; create table pozycje_mag ( id_pozycje_mag integer not null primary key default nextval( id ), id_asortyment integer not null references asortyment(id_asortyment), cena_zakupu money not null, cena_sprzedaľy money not null, ilosc real not null default 1.0, data_waznosci date, stempel_czasowy timestamp not null default now() ); PoprzestaĔmy na tych przykáadach i utwórzmy teraz obraz powiązaĔ encji. Wizualizacja relacji pomiĊdzy danymi znakomicie uáatwi nam utworzenie zapytaĔ SQL (rysunek 10.1) wstawiających dane do tabel, aktualizujących dane i usuwających je z tablic, najczĊ- Ğciej sáownikowych. Jest to niezbĊdne, gdyĪ kaĪda relacyjna baza danych ogranicza operacje z danymi wyáącznie do zapytaĔ, zazwyczaj jĊzyka SQL, których rezultaty do- piero dalej mogą zostaü obsáuĪone poprzez rozbudowane o elementy proceduralne jĊ- zyki programowania, takie jak PL/SQL, C++ i im podobne. Tabele sáownikowe nieco komplikują zapytania, ale znakomicie wpáywają na wydajnoĞü bazy danych. Na początek przeĞledĨmy proces wpisywania danych do bazy danych. Jako pierwsze naleĪaáoby zapeániü tablice sáownikowe. Zapytania tego typu są niezwykle proste i po- zwalają na samym początku usystematyzowaü zakres informacji przechowywanych w ba- zie danych. Polecenie wprowadzania danych do sáownika przeĞledĨmy na przykáadzie tabeli typów dostawców. Rozdziaä 10. i Budowa aplikacji bazodanowych 135 Rysunek 10.1. Wizualizacja powiązaĔ relacyjnych pomiĊdzy tabelami w bazie danych PostgreSQL. Access zostaá tu uĪyty jako klient i posiada wyáącznie zaáączone tablice z bazy danych PostgreSQL begin work; insert into typ (typ) values ( Dostawca ); insert into typ (typ) values ( Odbiorca ); commit work; Do zgrupowania zapytaĔ w transakcje warto uĪyü polecenia begin work otwierającego transakcje, a po zakoĔczeniu procesu wstawiania informacji do bazy danych zatwierdziü transakcje za pomocą polecenia commit work. Pozwala to na zachowanie spójnoĞci relacyjnej w tych rzadkich przypadkach, gdy nastĊpuje przerwanie poáączenia do bazy danych. Transakcje niezatwierdzone po pewnym czasie są automatycznie cofane z bazy. Z kolei dla transakcji niezadeklarowanych jawnie dziaáa mechanizm automatycznego zatwierdzania transakcji, gdy tylko zapytanie zakoĔczy siĊ sukcesem. Spróbujmy teraz usunąü dane z tabel sáownikowych. delete from typ where typ=’Odbiorca’; 136 PostgreSQL Jak widaü, operacje na tabelach sáownikowych są proste i mogą doskonale sáuĪyü jako wprawki do programowania w jĊzyku SQL. Z reguáy zapytania uzupeániające tablice sáownikowe podstawowymi danymi są traktowane jako czĊĞü konstrukcji samej bazy danych. Teraz, gdy tablice sáownikowe są przygotowane, moĪemy przystąpiü do wprowadzania danych do tablic podstawowych. Zapytania wpisujące dane do tabeli są nieco bardziej skomplikowane i z reguáy wykorzystują klauzulĊ select do wybierania danych ze sáowników. Zerknijmy na przykáad wprowadzania danych do tabeli kontrahentów. insert into kontrahent (nazwa, NIP, miejscowosc, nr_domu, poczta, kod_pocztowy, id_powiat, id_panstwo, id_typ, id_status) select Fadena Ltd. , 7181784060 , Lomza , 23 , Đomľa , 18-400 , id_powiat, id_panstwo, id_typ, id_status from powiat, panstwo, typ, status where powiat= Lomza miasto and panstwo= Polska and typ= Dostawca and status= Aktywny ; Jak widaü na powyĪszym przykáadzie, zapytanie wybierające sáuĪy do pozyskania wartoĞci z kluczy gáównych i wstawienia tych wartoĞci do kolumn zawierających klucze obce. Taka metoda nieco komplikuje zapytanie, jednakĪe zapewnia spójnoĞü relacyjną, niezbĊdną w kaĪdej bazie danych. PowyĪsze zapytanie moĪna potraktowaü jako wzo- rzec i z uĪyciem elementów jĊzyków proceduralnych konstruowaü elementy interfejsu uĪytkownika. Jak juĪ wspomniano wyĪej, danych raczej nie naleĪy usuwaü z bazy danych. Stąd teĪ rozpatrzmy teraz zapytanie aktualizujące dane. Dla przykáadu chcielibyĞmy zmieniü adres siedziby firmy. update kontrahent set miejscowosc= Kolno , nr_domu= 11 , poczta= Kolno , Rozdziaä 10. i Budowa aplikacji bazodanowych 137 kod_pocztowy= 18-200 , where nazwa= Fadena Ltd. ; Aktualizacja danych jest zazwyczaj prostsza niĪ ich wprowadzanie. Wynika to z faktu rzadszego siĊgania do sáowników i mniejszej komplikacji zapytania. Niezwykle poĪytecznym elementem bazy danych jest moĪliwoĞü korzystania z wido- ków. Widoki bazy danych pozwalają ukryü záoĪonoĞü wewnĊtrznej struktury bazy danych przed uĪytkownikiem oraz w znacznym stopniu uáatwiają operacje na danych. PrzeĞledĨmy widok bazy danych záoĪony z tabeli podstawowej i tabel sáownikowych. Do tworzenia widoków moĪna z powodzeniem wykorzystaü zapytania wybierające, gdyĪ sam widok nie zawiera danych, a do wyĞwietlania uĪywa zapytaĔ. drop view v_kontrahent; create view v_kontrahent as select nazwa, NIP, miejscowosc, poczta, kod_pocztowy, powiat, wojewodztwo, panstwo, typ, status from powiat, wojewodztwo, panstwo, typ, status where kontrahent.id_powiat=powiat.id_powiat and kontrahent.id_wojewodztwo=wojewodztwo.id_wojewodztwo and kontrahent.id_panstwo=panstwo.id_panstwo and kontrahent.id_typ=typ.id_typ and kontrahent.id_status=status.id_status; Widoki z bazy danych mogą sáuĪyü za podstawĊ do sporządzania raportów. Ukryta za widokiem záoĪonoĞü bazy danych pozwala uproĞciü zapytania, które stanowią podstawĊ do generowania raportów. Widoki z reguáy scalają dane na róĪne sposoby, uáatwiając operowanie na bazie danych, i przygotowują materiaá do wyciągów z bazy danych. W czĊĞci komercyjnych baz danych widoki pozwalają na aktualizacjĊ danych. W PostgreSQL, mimo Īe zapytanie aktualizujące wykona siĊ poprawnie, w rzeczywistoĞci aktualizacja poprzez widoki bazy danych nie jest moĪliwa. TrudnoĞü ta ma zostaü naprawiona w nowszych wersjach PostgreSQL. Nie zmniejsza to jednak obszaru zasto- sowania widoków, zwáaszcza Īe w specyfikacji SQL92 ten element bazy danych nie wystĊpuje i pojawia siĊ dopiero po roku 1995. Widoki pozwalają wiĊc na peáną gamĊ operacji z widokami, mimo iĪ niezaimplementowana czĊĞü nie wykona siĊ w rzeczy- wistoĞci. PoniĪej jeszcze jeden przykáad widoku bazy danych, tym razem na grupĊ danych związa- nych z nazwami asortymentu w powiązaniu z grupą danych opisujących kontrahenta. 138 PostgreSQL drop view v_asortyment; create view v_asortyment as select asortyment, index, subindex, opakowanie_zwrotne, magazyn, miara, VAT, akcyza, grupa, SWW, kontrahent.nazwa, NIP from asortyment, magazyn, miara, vat, akcyza, grupa, sww, kontrahent where asortyment.id_magazyn=magazyn.id_magazyn and asortyment.id_miara=miara.id_miara and asortyment.id_VAT=vat.id_vat and asortyment.id_akcyza=akcyza.id_akcyza and asortyment.id_grupa=grupa.id_grupa and asortyment.id_SWW=sww.id_sww and asortyment.id_kontrahent=kontrahent.id_kontrahent; Relacyjna baza danych posiada wáasne mechanizmy zabezpieczeĔ dostĊpu do bazy da- nych. Jedynie uĪytkownik postgres posiada wszelkie przywileje do baz danych Postgre- SQL. Zazwyczaj teĪ administrator bazy danych wykonuje operacje tworzenia struktur ba- zodanowych, tablic, widoków, wprowadzenia podstawowych danych do sáowników. Dlatego teĪ ostatnim etapem tworzenia bazy danych jest nadanie uprawnieĔ do obiektów bazy danych. OczywiĞcie, uprawnienia powinny byü adekwatne do roli uĪytkownika w procesie przetwarzania informacji w bazie danych. Uprawnienia moĪna przypisaü do grupy, której czáonkiem bĊdzie uĪytkownik bazy danych. Przywilejów jest kilka: prawo do wykonywania zapytaĔ wybierających, prawo do wprowadzania informacji do tablic, prawo do aktualizacji danych, prawo do usuwania danych i prawa administracyjne. Przykáadowe przywileje do obiektów PostgreSQL i sposób ich nadania mogą byü wziĊte z poniĪszego przykáadu. drop user fakt1; create user fakt1 with password ‘fadena’ nocreatedb nocreateuser in group fakturzysta; drop user kasa1; create user kasa1 with password ‘fadena’ nocreatedb nocreateuser in group rachunkowosc; grant select on v_kontrahent, v_asortyment, v_pozycje_mag, to group rachunkowosc; grant select, insert, update on kontrahent, panstwo, wojewodztwo, Rozdziaä 10. i Budowa aplikacji bazodanowych 139 powiat, typ, status, magazyn, vat, akcyza, miara, grupa, sww, asortyment, pozycje_mag, to group fakturzysta; W powyĪszym przykáadzie wiĊksze uprawnienia do tablic baz danych posiada uĪyt- kownik bĊdący czáonkiem grupy o identyfikatorze fakturzysta, gdyĪ to on bĊdzie wpro- wadzaá dane do bazy danych. UĪytkownik ten nie ma prawa usuwania danych. Przywilej ten moĪna by nadaü kierownikowi zmiany lub osobie obsáugującej system informatycz- ny firmy. Z kolei grupa rachunkowoħè i odpowiednio jej czáonkowie mają ograniczone przywileje jedynie do widoków z bazy danych. Pozwala to na zabezpieczenie przed báĊdną operacją na danych juĪ na poziomie samej bazy danych. Taki sposób zabezpieczeĔ zdejmuje teĪ szereg obowiązków z programistów tworzących interfejs aplikacji bazoda- nowej, gdyĪ sama baza danych chroni zawarte w niej informacje przed niesankcjono- wanym dostĊpem do nich. Nadanie uprawnieĔ jedynie do widoków stanowi kolejny stopieĔ w procesie zabezpieczania danych. Pozwala to ukryü poszczególne kolumny, zaĞ z wielu tabel utworzyü jedną zbiorczą, zawierającą skondensowane lub tylko wy- brane informacje. Ostatnim elementem budowy aplikacji bazodanowej jest wytworzenie interfejsu uĪyt- kownika. NajczĊĞciej z bazy danych korzysta siĊ poprzez sieü lokalną, jednakĪe coraz czĊĞciej wymagany jest zdalny dostĊp, na przykáad poprzez stronĊ serwisu web. DostĊp zdalny byá juĪ prezentowany w poprzednich rozdziaáach, teraz wspomnĊ jedynie o apli- kacjach uĪywających ODBC. Coraz czĊĞciej aplikacje obsáugujące interfejs do bazy danych budowane są z uĪyciem jĊzyków czwartej generacji, zawierających generatory aplikacji. Do takich jĊzyków naleĪy Visual Basic (rysunek 10.2). Rysunek 10.2. Obiekt Data Environment jĊzyka Visual Basic z przyáączeniami do bazy danych PostgreSQL 140 PostgreSQL Szczególnie interesujący jest wáaĞnie Visual Basic, gdyĪ posiada on cechy obiektowe, mechanizm ADO, jest doĞü szeroko znany, a przede wszystkim pozwala na zbudowa- nie interfejsu do bazy danych z uĪyciem gotowych juĪ aplikacji, takich jak Excel, Word czy teĪ Access. Arkusz kalkulacyjny lub edytor tekstu peániü bĊdą raczej rolĊ generatora raportów z bazy danych, natomiast za pomocą Accessa moĪliwe jest wytwo- rzenie peánowartoĞciowego interaktywnego interfejsu do relacyjnej i dostĊpnej po- przez sieü bazy danych PostgreSQL. Innym, równie ciekawym jak Visual Basic jĊzykiem tworzenia aplikacji bazodano- wych jest Delphi. JĊzyk ten wykorzystuje mechanizm BDE (Borland Database Engine) jako jednolity dla wszystkich aplikacji interfejs dostĊpu do bazy danych (rysunek 10.3). Rysunek 10.3. Administrator BDE z definicją áącza do bazy danych uĪywającego ODBC PostgreSQL Przedstawianie mechanizmów programowych w Delphi do áączenia siĊ aplikacji z bazą danych wykracza poza zakres tej ksiąĪki. NaleĪy jedynie podkreĞliü, Īe za pomocą znanych programistom narzĊdzi moĪna szybko i wydajnie tworzyü interfejsy uĪytkownika. Przedstawione powyĪej przykáady prezentują PostgreSQL w zupeánie innym Ğwietle. Wysoko wydajna baza danych, prosta w obsáudze, ze zgodnym ze standardem jĊzy- kiem SQL oraz wykorzystująca do przekazywania danych mechanizmy DBI, ODBC, JDBC moĪe stanowiü solidną podstawĊ dla programów komercyjnych. W trakcie pracy programistycznej nad interfejsem uĪytkownika czĊsto zachodzi po- trzeba sprawdzenia wielu zaleĪnoĞci w bazie danych. MoĪna by powiedzieü, Īe im bardziej rozbudowana aplikacja, tym czĊĞciej uĪywane są róĪnego typu monitory bazy danych w celu Ğledzenia zaleĪnoĞci pomiĊdzy obiektami i zawartoĞci tych obiektów. Delphi jako jeden z nielicznych jĊzyków programowania dostarczany jest wraz z uniwer- salnym monitorem relacyjnych baz danych (rysunek 10.4). Rozdziaä 10. i Budowa aplikacji bazodanowych 141 Rysunek 10.4. SQL Explorer pozwala na bieĪąco kontrolowaü strukturĊ i zawartoĞü bazy danych PostgreSQL Taki podgląd oraz wykorzystanie wáączonych lub doáączonych do PostgreSQL jĊzy- ków programowania umoĪliwiają stworzenie procedur i przechowywanie ich we- wnątrz bazy danych. Dodając do tego mechanizmy obsáugi zdarzeĔ oraz wyzwalacze (trigery), moĪna umieĞciü znaczną czĊĞü kodu aplikacji bazodanowej wewnątrz samej bazy danych. Przyspiesza to dziaáanie samej bazy danych i zmniejsza obciąĪenie áączy do bazy. W efekcie kod programów staje siĊ prostszy i bardziej przejrzysty, áatwiej budowaü nowe wersje aplikacji, zaĞ sam program pracuje szybciej i jest zdecydowanie stabilniejszy. Pomimo Īe taka metodologia programistyczna przy budowie aplikacji nie jest zbyt czĊsto stosowana, jednakĪe, jak pokazują doĞwiadczenia wielu niezaleĪnych programi- stów, zwiĊksza siĊ w ten sposób produktywnoĞü pisania programów, co jest niezwykle waĪne w Ğwiecie, gdzie uĪytkownicy i firmy Īądają ciągle nowych lub ulepszonych aplikacji. 142 PostgreSQL Skorowidz A B abort, 46 action, 94 administrator baz danych, 76 after, 56 alfabetyczny spis funkcji, 177–180 algebra relacyjna, 16 alter, 47 alter table, 47 alter user, 47 analiza jednostek, 127 analiza strategiczna, 126 analiza zdarzeĔ, 126 ANSI SQL, 19 ANSI SQL-2, 119 ANSI, American National Standards Institute, 19 aplikacja bazodanowa, 123 analiza jednostek, 127 analiza strategiczna, 126 analiza zdarzeĔ, 126 diagram encji, 127 diagram przepáywu danych, 127 implementacja modelu, 128 interfejs uĪytkownika, 139 powtórna analiza, 128 proces projektowania, 126 proces wdraĪania, 128 związki relacyjne, 127 aplikacja pgadmin3, 78 AppGEN, 90 architektura klient serwer, 99 atrybut bytu, 9 awk, 91 backend, 80 baza danych, 7 DB2, 7 Interbase, 7 Microsoft Access, 70 MySQL, 19 Oracle, 7 PostgreSQL, 7, 154 Yard, 85 BDE, Borland Database Engine, 140 before, 56 begin, 48 begin work, 135 biblioteka cygwin, 152 biblioteka dla serwisu web, 103 byt, 9 byt-relacja, 12 C case, 42 CGI, Common Gateway Interface, 90 close, 48 cloud computing, 143 cluster, 48 coalesce, 42 commit, 20, 49, 64 commit work, 135 compare, 16 configure, 149 connect, 92 copy, 49 create, 50 create aggregate, 50 create constraint trigger, 50 create database, 51, 110 create function, 51 create group, 52 create index, 52 create language, 52 create operator, 54 create rule, 54 create sequence, 55 create table, 55 create trigger, 56 create type, 56 create user, 57 create view, 58 cursor, 163 D dbf, 108 dbf2msql, 108 dbf2sql, 91 declare, 58 dekompozycja, 13 delete, 56, 59 Delphi, 140 demon httpd, 102 diagram encji, 127 diagram przepáywu danych, 127 distinct, 58 divide, 16 dostĊp do bazy danych heitml, 84 interfejs jĊzyka Python, 107 interfejsy uniwersalne, 108 PHP, 99 dostĊp poprzez identyfikator i hasáo, 101 drop, 59 drop aggregate, 59 drop database, 60 190 PostgreSQL drop function, 60 drop group, 60 drop index, 61 drop language, 61 drop operator, 61 drop rule, 62 drop sequence, 62 drop table, 62 drop tigger, 63 drop type, 63 drop user, 63 drop view, 63 druga postaü normalna, 13 dynamiczne tworzenie bitmap, 100 dziaáanie w chmurze, cloud computing, 143 E ecpg, 118 elementy formularza, 94 encja, 127 end, 64 explain, 64 F FastCGI, 100 fetch, 64, 67, 164 FI, Form Interpreter, 100 format daty, 70 formularz, 100 Framework ADO NET, 113 frontend, 80 funkcja, 35 crypt, 88 lo_export, 172 lo_import, 172 funkcje czasu, 38 daty, 38 definiowane (wáasne), 40 dostĊpne w PostgreSQL, 177 geometryczne, 38 grupowe, 42, 180 konwersji, 35 matematyczne, 35 PHP, 102, 103 planimetryczne, 38 sieciowe, 38 wbudowane w skáadniĊ SQL, 41 wáasne, 40 znakowe, 37 G generator aplikacji, 91 GET, 93 GNU, 152 GNU-Linux, 152 granica za
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

PostgreSQL. Wydanie II
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: