Oracle Database 10g. Kompendium Administratora

IDZ DO
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Oracle Database 10g.

Kompendium administratora
Autor: Kevin Loney
Tumaczenie: Zbigniew Banach, Sawomir
Dzieniszewski, Pawe Gonera, Radosaw Meryk
ISBN: 83-7361-750-7
Tytu oryginau: Oracle Database 10g.
The Complete Reference
Format: B5, stron: 1480
Baza danych Oracle od dawna cieszy si zasuon saw. Jest wykorzystywana
wszdzie tam, gdzie dba si o stabilno i bezpieczestwo danych oraz szybko
dostpu do nich. Kada nowa wersja Oraclea wnosi co nowego i wytycza nowe
standardy. Ogromne moliwoci Oraclea pocigaj za sob konieczno doczania
do niej tysicy stron dokumentacji. Kady z opasych tomw instrukcji szczegowo
opisuje inne elementy systemu. Czsto jednak podczas pracy z baz zachodzi
konieczno szybkiego odnalezienia konkretnej informacji. W takich przypadkach
przydatne okazuje si zestawienie najbardziej istotnych zagadnie, zebranych
w jednej publikacji.
W ksice Oracle Database 10g. Kompendium administratora zebrano wszystkie
najwaniejsze pojcia dotyczce bazy danych Oracle. W jednym podrczniku
zgromadzone s opisy polece, funkcji i waciwoci oraz dokumentacja narzdzi
doczanych do Oraclea. Kady uytkownik, administrator i programista baz danych
znajdzie tu co, co przyda mu si w pracy. Jednych zainteresuje opis jzyka SQL,
innych opis instalacji, konfiguracji i strojenia bazy, a jeszcze inni doceni omwienie
zasad tworzenia aplikacji wsppracujcych z Oracleem.
Instalacja bazy danych Oracle 10g
Planowanie i projektowanie aplikacji bazodanowych
Jzyk SQL i narzdzie SQL*Plus
Operacje na danych z wykorzystaniem jzyka SQL
Budowanie zoonych zapyta
Zarzdzanie tabelami, perspektywami, indeksami i klastrami
Mechanizmy bezpieczestwa bazy danych
Eksport danych i technologia Data Pump
Zapytania flashback
Doczanie tabel zewntrznych
Tworzenie aplikacji w jzyku PL/SQL
Strojenie aplikacji i optymalizacja zapyta
Dodatkow pomoc dla uytkownikw Oraclea jest przewodnik po wszystkich
jej funkcjach, potencjalnych zastosowaniach i zestawienie polece wraz z opcjami
i parametrami.
Ta ksika powinna znale si na biurku kadego,

kto wykorzystuje w pracy baz Oracle 10g
Spis treci
O Autorze .............................................................................................13
Wstp ..................................................................................................15
Cz I
Najwaniejsze pojcia dotyczce bazy danych ..................... 17
Rozdzia 1. Opcje architektury bazy danych Oracle 10g ...........................................19

Bazy danych i instancje .......................................................................................................... 20
Wntrze bazy danych ............................................................................................................. 21
Wybr architektury i opcji ..................................................................................................... 26
Rozdzia 2. Instalacja bazy danych Oracle 10g i tworzenie bazy danych ...................29
Przegld opcji licencji i instalacji ........................................................................................... 31
Rozdzia 3. Aktualizacja do wersji Oracle 10g .........................................................43

Wybr metody aktualizacji .................................................................................................... 44
Przed aktualizacj .................................................................................................................. 45
Wykorzystanie asystenta aktualizacji bazy danych ................................................................ 46
Rczna aktualizacja bezporednia .......................................................................................... 47
Wykorzystanie mechanizmw eksportu i importu ................................................................. 50
Zastosowanie metody z kopiowaniem danych ....................................................................... 51
Po aktualizacji ........................................................................................................................ 52
Rozdzia 4. Planowanie aplikacji systemu Oracle

sposoby, standardy i zagroenia ........................................................55
Podejcie kooperacyjne .......................................................................................................... 56
Dane s wszdzie ................................................................................................................... 57
Jzyk systemu Oracle ............................................................................................................. 58
Zagroenia .............................................................................................................................. 64
Znaczenie nowego podejcia .................................................................................................. 66
Jak zmniejszy zamieszanie? ................................................................................................. 68
Normalizacja nazw ................................................................................................................. 75
Czynnik ludzki ....................................................................................................................... 76
Model biznesowy ................................................................................................................... 82
Normalizacja nazw obiektw ................................................................................................. 84
Inteligentne klucze i wartoci kolumn .................................................................................... 87
Przykazania ............................................................................................................................ 88
Oracle Database 10g. Kompendium administratora
Cz II
SQL i SQL*Plus ................................................................. 89
Rozdzia 5. Zasadnicze elementy jzyka SQL ...........................................................91

Styl ......................................................................................................................................... 92
Utworzenie tabeli GAZETA .................................................................................................. 93
Zastosowanie jzyka SQL do wybierania danych z tabel ....................................................... 94
Sowa kluczowe select, from, where i order by ...................................................................... 97
Operatory logiczne i wartoci ................................................................................................ 99
Inne zastosowanie klauzuli where: podzapytania ................................................................. 108
czenie tabel ...................................................................................................................... 111
Tworzenie perspektyw ......................................................................................................... 113
Rozdzia 6. Podstawowe raporty i polecenia programu SQL*Plus ...........................117

Tworzenie prostego raportu ................................................................................................. 119
Inne wasnoci ...................................................................................................................... 129
Odczytywanie ustawie programu SQL*Plus ...................................................................... 136
Klocki ................................................................................................................................... 137
Rozdzia 7. Pobieranie informacji tekstowych i ich modyfikowanie .........................139

Typy danych ......................................................................................................................... 139
Czym jest cig? .................................................................................................................... 140
Notacja ................................................................................................................................. 140
Konkatenacja (||) .................................................................................................................. 143
Wycinanie i wklejanie cigw znakw ................................................................................ 144
Zastosowanie klauzul order by oraz where z funkcjami znakowymi ................................... 160
Podsumowanie ..................................................................................................................... 163
Rozdzia 8. Wyszukiwanie z wykorzystaniem wyrae regularnych ..........................165

Wyszukiwanie w cigach znakw ........................................................................................ 165
REGEXP_SUBSTR ............................................................................................................. 167
Rozdzia 9. Operacje z danymi numerycznymi ........................................................179

Trzy klasy funkcji numerycznych ........................................................................................ 179
Notacja ................................................................................................................................. 182
Funkcje operujce na pojedynczych wartociach ................................................................. 183
Funkcje agregacji ................................................................................................................. 191
Funkcje operujce na listach ................................................................................................ 198
Wyszukiwanie wierszy za pomoc funkcji MAX lub MIN .................................................. 199
Priorytety dziaa i nawiasy ................................................................................................. 200
Podsumowanie ..................................................................................................................... 202
Rozdzia 10. Daty: kiedy, teraz i rnice ................................................................203

Arytmetyka dat ..................................................................................................................... 203
Funkcje ROUND i TRUNC w obliczeniach z wykorzystaniem dat ..................................... 212
Formatowanie w funkcjach TO_DATE i TO_CHAR .......................................................... 213
Daty w klauzuli where ......................................................................................................... 224
Obsuga wielu stuleci ........................................................................................................... 225
Zastosowanie funkcji EXTRACT ........................................................................................ 226
Zastosowanie typu danych TIMESTAMP ........................................................................... 226
Rozdzia 11. Funkcje konwersji i transformacji ........................................................229

Podstawowe funkcje konwersji ............................................................................................ 231
Specjalne funkcje konwersji ................................................................................................. 236
Funkcje transformacji ........................................................................................................... 237
Podsumowanie ..................................................................................................................... 239
Spis treci
Rozdzia 12. Grupowanie danych ............................................................................241

Zastosowanie klauzul group by i having .............................................................................. 241
Perspektywy grup ................................................................................................................. 246
Moliwoci perspektyw grupowych ..................................................................................... 248
Dodatkowe moliwoci grupowania .................................................................................... 253
Rozdzia 13. Kiedy jedno zapytanie zaley od drugiego ............................................255

Zaawansowane podzapytania ............................................................................................... 255
Zczenia zewntrzne ........................................................................................................... 260
Zczenia naturalne i wewntrzne ........................................................................................ 266
UNION, INTERSECT i MINUS .......................................................................................... 267
Rozdzia 14. Zaawansowane moliwoci .................................................................271

Zoone grupowanie ............................................................................................................. 271
Tabele tymczasowe .............................................................................................................. 273
Zastosowanie funkcji ROLLUP, GROUPING i CUBE ....................................................... 273
Drzewa rodzinne i klauzula connect by ................................................................................ 277
Rozdzia 15. Modyfikowanie danych: insert, update, merge i delete .........................287

insert .................................................................................................................................... 287
rollback, commit i autocommit ............................................................................................ 291
Wprowadzanie danych do wielu tabel .................................................................................. 293
delete .................................................................................................................................... 297
update ................................................................................................................................... 298
Zastosowanie polecenia merge ............................................................................................. 301
Rozdzia 16. DECODE i CASE: if, then oraz else w jzyku SQL ..................................305
if, then, else .......................................................................................................................... 305
Zastpowanie wartoci przy uyciu funkcji DECODE ........................................................ 308
Funkcja DECODE w innej funkcji DECODE ...................................................................... 309
Operatory wikszy ni i mniejszy ni w funkcji DECODE ................................................. 312
Funkcja CASE ..................................................................................................................... 314
Rozdzia 17. Tworzenie tabel, perspektyw, indeksw, klastrw i sekwencji

oraz zarzdzanie nimi ..........................................................................319
Tworzenie tabeli ................................................................................................................... 319
Usuwanie tabel ..................................................................................................................... 328
Uaktualnianie definicji tabel ................................................................................................ 328
Tworzenie tabeli na podstawie innej tabeli .......................................................................... 333
Tworzenie tabeli o strukturze indeksu .................................................................................. 334
Tabele podzielone na partycje .............................................................................................. 335
Tworzenie perspektyw ......................................................................................................... 340
Indeksy ................................................................................................................................. 343
Klastry .................................................................................................................................. 350
Sekwencje ............................................................................................................................ 352
Rozdzia 18. Podstawowe mechanizmy bezpieczestwa systemu Oracle ..................355

Uytkownicy, role i uprawnienia ......................................................................................... 355
Jakie uprawnienia mog nadawa uytkownicy? ................................................................. 363
Nadawanie uprawnie do ograniczonych zasobw .............................................................. 377
Cz III Wicej ni podstawy ........................................................ 379

Rozdzia 19. Zaawansowane waciwoci bezpieczestwa
wirtualne prywatne bazy danych .....................................................381
Konfiguracja wstpna ........................................................................................................... 382
Tworzenie kontekstu aplikacji ............................................................................................. 383
Tworzenie wyzwalacza logowania ....................................................................................... 384
Tworzenie strategii bezpieczestwa ..................................................................................... 385
Zastosowanie strategii bezpieczestwa do tabel ................................................................... 387
Testowanie mechanizmu VPD ............................................................................................. 387
Implementacja mechanizmu VPD na poziomie kolumn ...................................................... 388
Wyczanie mechanizmu VPD ............................................................................................. 389
Korzystanie z grup strategii .................................................................................................. 390
Rozdzia 20. Przestrzenie tabel ...............................................................................393

Przestrzenie tabel a struktura bazy danych ........................................................................... 393
Planowanie wykorzystania przestrzeni tabel ........................................................................ 399
Rozdzia 21. Zastosowanie programu SQL*Loader do adowania danych ..................403

Plik sterujcy ........................................................................................................................ 404
Rozpoczcie adowania ........................................................................................................ 405
Uwagi na temat skadni pliku sterujcego ............................................................................ 410
Zarzdzanie adowaniem danych ......................................................................................... 412
Dostrajanie operacji adowania danych ................................................................................ 414
Dodatkowe wasnoci ........................................................................................................... 417
Rozdzia 22. Mechanizm eksportu i importu Data Pump ..........................................419

Tworzenie katalogu .............................................................................................................. 419
Opcje mechanizmu Data Pump Export ................................................................................ 420
Uruchamianie zadania eksportu mechanizmu Data Pump .................................................... 422
Opcje mechanizmu Data Pump Import ................................................................................ 426
Uruchamianie zadania importu mechanizmu Data Pump ..................................................... 429
Rozdzia 23. Zdalny dostp do danych ....................................................................435

cza baz danych ................................................................................................................. 435
Zastosowanie synonimw w celu uzyskania przezroczystej lokalizacji obiektw ............... 442
Pseudokolumna User w perspektywach ............................................................................... 444
cza dynamiczne: uycie polecenia copy programu SQL*Plus ......................................... 445
Poczenia ze zdaln baz danych ........................................................................................ 447
Rozdzia 24. Perspektywy zmaterializowane ............................................................449

Dziaanie .............................................................................................................................. 449
Wymagane uprawnienia systemowe .................................................................................... 450
Wymagane uprawnienia do tabel ......................................................................................... 450
Perspektywy tylko do odczytu a perspektywy z moliwoci aktualizacji ........................... 451
Skadnia polecenia create materialized view ........................................................................ 452
Zastosowanie perspektyw zmaterializowanych do modyfikacji
cieek wykonywania zapyta .......................................................................................... 458
Pakiet DBMS_ADVISOR .................................................................................................... 459
Odwieanie perspektyw zmaterializowanych ..................................................................... 462
Polecenie create materialized view log ................................................................................ 468
Modyfikowanie zmaterializowanych perspektyw i dziennikw ........................................... 470
Usuwanie zmaterializowanych perspektyw i dziennikw .................................................... 470
Spis treci
Rozdzia 25. Zastosowanie pakietu Oracle Text do wyszukiwania cigw znakw ....473
Wprowadzanie tekstu do bazy danych ................................................................................. 473
Zapytania tekstowe i indeksy ............................................................................................... 474
Zestawy indeksw ................................................................................................................ 488
Rozdzia 26. Tabele zewntrzne ..............................................................................491

Dostp do zewntrznych danych .......................................................................................... 491
Tworzenie tabeli zewntrznej ............................................................................................... 492
Modyfikowanie tabel zewntrznych ..................................................................................... 501
Ograniczenia, zalety i potencjalne zastosowania tabel zewntrznych .................................. 503
Rozdzia 27. Zapytania flashback ...........................................................................505

Przykad czasowego zapytania flashback ............................................................................. 506
Zapisywanie danych ............................................................................................................. 507
Przykad zapytania flashback z wykorzystaniem numerw SCN ......................................... 508
Co zrobi, jeli zapytanie flashback nie powiedzie si? ....................................................... 510
Jaki numer SCN jest przypisany do kadego wiersza? ......................................................... 510
Zapytania flashback o wersje ............................................................................................... 512
Planowanie operacji flashback ............................................................................................. 514
Rozdzia 28. Operacje flashback tabele i bazy danych .........................................515

Polecenie flashback table ..................................................................................................... 515
Polecenie flashback database ............................................................................................... 519
Cz IV PL/SQL ........................................................................... 523

Rozdzia 29. Wprowadzenie do jzyka PL/SQL ........................................................525
Przegld jzyka PL/SQL ...................................................................................................... 525
Sekcja deklaracji .................................................................................................................. 526
Sekcja polece wykonywalnych .......................................................................................... 529
Sekcja obsugi wyjtkw ...................................................................................................... 540
Rozdzia 30. Wyzwalacze ........................................................................................545

Typy wyzwalaczy ................................................................................................................. 546
Skadnia wyzwalaczy ........................................................................................................... 548
Wczanie i wyczanie wyzwalaczy ................................................................................... 558
Zastpowanie wyzwalaczy ................................................................................................... 559
Usuwanie wyzwalaczy ......................................................................................................... 560
Rozdzia 31. Procedury, funkcje i pakiety ................................................................565

Procedury a funkcje .............................................................................................................. 568
Procedury a pakiety .............................................................................................................. 568
Skadnia polecenia create procedure .................................................................................... 568
Skadnia polecenia create function ....................................................................................... 570
Skadnia polecenia create package ....................................................................................... 577
Przegldanie kodu rdowego obiektw proceduralnych ................................................... 580
Kompilacja procedur, funkcji i pakietw ............................................................................. 581
Zastpowanie procedur, funkcji i pakietw .......................................................................... 582
Usuwanie procedur, funkcji i pakietw ................................................................................ 582
10
Rozdzia 32. Wbudowany dynamiczny SQL i pakiet DBMS_SQL ................................583

Polecenie EXECUTE IMMEDIATE ................................................................................... 583
Zmienne wice .................................................................................................................. 585
Pakiet DBMS_SQL .............................................................................................................. 586
Cz V
Obiektowo-relacyjne bazy danych ..................................... 591
Rozdzia 33. Implementowanie typw, perspektyw obiektowych i metod ..................593

Zasady pracy z abstrakcyjnymi typami danych .................................................................... 593
Implementowanie perspektyw obiektowych ........................................................................ 599
Metody ................................................................................................................................. 605
Rozdzia 34. Kolektory (tabele zagniedone i tablice zmienne) ...............................609

Tablice zmienne ................................................................................................................... 609
Tabele zagniedone ............................................................................................................ 615
Dodatkowe funkcje dla tabel zagniedonych i tablic zmiennych ....................................... 620
Zarzdzanie tabelami zagniedonymi i tablicami zmiennymi ............................................ 621
Rozdzia 35. Wielkie obiekty (LOB) .........................................................................625

Dostpne typy ...................................................................................................................... 625
Definiowanie parametrw skadowania dla danych LOB .................................................... 627
Zapytania o wartoci typu LOB ........................................................................................... 629
Rozdzia 36. Zaawansowane funkcje obiektowe ......................................................653

Obiekty wierszy a obiekty kolumn ....................................................................................... 653
Tabele obiektowe i identyfikatory OID ................................................................................ 654
Perspektywy obiektowe z odwoaniami REF ....................................................................... 662
Obiektowy jzyk PL/SQL .................................................................................................... 667
Obiekty w bazie danych ....................................................................................................... 669
Cz VI Jzyk Java w systemie Oracle .......................................... 671

Rozdzia 37. Wprowadzenie do jzyka Java .............................................................673
Krtkie porwnanie jzykw PL/SQL i Java ....................................................................... 673
Zaczynamy ........................................................................................................................... 674
Deklaracje ............................................................................................................................ 675
Podstawowe polecenia ......................................................................................................... 676
Klasy .................................................................................................................................... 685
Rozdzia 38. Programowanie z uyciem JDBC ..........................................................691

Zaczynamy ........................................................................................................................... 692
Korzystanie z klas JDBC ...................................................................................................... 693
Rozdzia 39. Procedury skadowane w Javie ............................................................701

adowanie klas do bazy danych ........................................................................................... 703
Korzystanie z klas ................................................................................................................ 705
Cz VII Klastrowy system Oracle i siatka ..................................... 709

Rozdzia 40. Opcja Real Application Clusters w systemie Oracle .............................711
Przygotowania do instalacji ................................................................................................. 711
Instalowanie konfiguracji Real Application Clusters ........................................................... 712
Uruchamianie i zatrzymywanie instancji klastra .................................................................. 716
Spis treci
11
Mechanizm TAF .................................................................................................................. 719

Dodawanie wzw i instancji do klastra ............................................................................. 720
Zarzdzanie rejestrem klastra i usugami ............................................................................. 721
Rozdzia 41. Architektura siatki .............................................................................723

Konfiguracja sprztu i systemu operacyjnego ...................................................................... 724
Dodawanie serwerw do siatki ............................................................................................ 727
Wsplne uytkowanie danych w ramach siatki .................................................................... 728
Zarzdzanie siatk ................................................................................................................ 729
Uruchamianie menedera OEM ........................................................................................... 732
Cz VIII Przewodniki autostopowicza ............................................ 735

Rozdzia 42. Autostopem po sowniku danych Oracle ..............................................737
Nazewnictwo ........................................................................................................................ 738
Nowe perspektywy w systemie Oracle 10g .......................................................................... 738
Nowe kolumny w systemie Oracle 10g ................................................................................ 743
Mapy DICTIONARY (DICT) i DICT_COLUMNS ............................................................ 751
Tabele (z kolumnami), perspektywy, synonimy i sekwencje ............................................... 753
Kosz: USER_RECYCLEBIN i DBA_RECYCLEBIN ........................................................ 761
Ograniczenia i komentarze ................................................................................................... 761
Indeksy i klastry ................................................................................................................... 767
Abstrakcyjne typy danych, struktury obiektowe i obiekty LOB .......................................... 771
cza bazy danych i perspektywy zmaterializowane ........................................................... 774
Wyzwalacze, procedury, funkcje i pakiety ........................................................................... 777
Wymiary .............................................................................................................................. 780
Alokacja i zuycie przestrzeni .............................................................................................. 781
Uytkownicy i przywileje .................................................................................................... 787
Role ...................................................................................................................................... 789
Audytowanie ........................................................................................................................ 790
Inne perspektywy ................................................................................................................. 793
Monitorowanie wydajnoci: dynamiczne perspektywy V$ .................................................. 793
Rozdzia 43. Autostopem po dostrajaniu aplikacji i zapyta SQL ..............................799

Nowe moliwoci dostrajania .............................................................................................. 799
Zalecane praktyki dostrajania aplikacji ................................................................................ 801
Generowanie i czytanie planw wykonania ......................................................................... 814
Najwaniejsze operacje spotykane w planach wykonania .................................................... 819
Implementowanie zarysw skadowanych ........................................................................... 844
Podsumowanie ..................................................................................................................... 846
Rozdzia 44. Analiza przypadkw optymalizacji ........................................................847

Przypadek 1. Czekanie, czekanie i jeszcze raz czekanie ...................................................... 847
Przypadek 2. Mordercze zapytania ...................................................................................... 851
Przypadek 3. Dugotrwae zadania wsadowe ....................................................................... 853
Rozdzia 45. Autostopem po serwerze aplikacji Oracle 10g .....................................857

Czym jest Oracle Application Server 10g? .......................................................................... 859
Usugi komunikacyjne ......................................................................................................... 865
Usugi zarzdzania treci .................................................................................................... 866
Usugi logiki biznesowej ...................................................................................................... 870
Usugi prezentacyjne ............................................................................................................ 872
Usugi analizy biznesowej .................................................................................................... 874
12
Usugi portalowe .................................................................................................................. 876

Web Services ........................................................................................................................ 877
Narzdzia programistyczne .................................................................................................. 878
Usugi warstwy trwaoci ..................................................................................................... 883
Usugi buforowania .............................................................................................................. 885
Usugi systemowe ................................................................................................................ 889
Narzdzia programistyczne .................................................................................................. 890
Rozdzia 46. Autostopem po administrowaniu baz danych ......................................897

Tworzenie bazy danych ........................................................................................................ 897
Uruchamianie i zamykanie bazy danych .............................................................................. 899
Zarzdzanie obszarami pamici ........................................................................................... 900
Zarzdzanie przestrzeni dla obiektw ................................................................................ 902
Monitorowanie przestrzeni tabel wycofania ......................................................................... 913
Automatyczne zarzdzanie skadowaniem danych ............................................................... 914
Zarzdzanie miejscem w segmentach .................................................................................. 915
Przenoszenie przestrzeni tabel ............................................................................................. 916
Kopie zapasowe ................................................................................................................... 918
Co dalej? .............................................................................................................................. 933
Rozdzia 47. Autostopem po XML w bazach danych Oracle ......................................935

Definicje DTD, elementy i atrybuty ..................................................................................... 935
Schematy XML .................................................................................................................... 939
Wykonywanie polece SQL na danych XML za pomoc XSU ........................................... 941
Korzystanie z typu danych XMLType ................................................................................. 946
Inne funkcje ......................................................................................................................... 948
Cz IX Alfabetyczne zestawienie polece .................................... 951

Dodatki ......................................................................... 1425
Skorowidz ........................................................................................1427
Rozdzia 4.
Planowanie aplikacji
systemu Oracle
sposoby, standardy
i zagroenia
Aby stworzy aplikacj systemu Oracle i szybko oraz efektywnie z niej korzysta, uytkownicy i programici musz posugiwa si wsplnym jzykiem, a take posiada gbok wiedz zarwno na temat aplikacji biznesowych, jak i narzdzi systemu Oracle.
W poprzednich rozdziaach zaprezentowano oglny opis systemu Oracle oraz sposoby
jego instalacji i aktualizacji. Teraz, po zainstalowaniu oprogramowania moemy przystpi do tworzenia aplikacji. Kluczowym elementem w tym przypadku jest cisa wsppraca menederw i personelu technicznego. Obie grupy pracownikw powinny orientowa si w zadaniach firmy oraz wiedzie, jakie dane s przetwarzane w codziennym
dziaaniu.
Dawniej analitycy systemowi szczegowo badali wymagania klienta, a nastpnie programici tworzyli aplikacje, ktre speniay te wymagania. Klient dostarcza jedynie
opis procesu, ktry aplikacja miaa usprawni, oraz testowa jej dziaanie. Dziki najnowszym narzdziom systemu Oracle mona tworzy aplikacje znacznie lepiej odpowiadajce potrzebom i przyzwyczajeniom uytkownikw. Jest to jednak moliwe tylko
w przypadku waciwego rozumienia zagadnie biznesowych.
Zarwno uytkownicy, jak i programici powinni zmierza do maksymalnego wykorzystania moliwoci systemu Oracle. Uytkownik aplikacji ma wiedz na temat zagadnie
merytorycznych, ktrej nie posiada programista. Programista rozumie dziaanie wewntrznych funkcji i wasnoci systemu Oracle i rodowiska komputerw, ktre s zbyt
skomplikowane dla uytkownika. Ale takie obszary wycznoci wiedzy nie s liczne.
Podczas korzystania z systemu Oracle uytkownicy i programici zwykle poruszaj si
w obrbie zagadnie znanych obu stronom.
Nie jest tajemnic, e pracownicy merytoryczni i techniczni od lat nie darz si
szczegln sympati. Przyczyn tego stanu s rnice w posiadanej wiedzy, zainteresowaniach i zwyczajach, a take inne cele. Nie bez znaczenia jest take poczucie odrbnoci,
56
Cz I
Najwaniejsze pojcia dotyczce bazy danych
jakie powstaje w wyniku fizycznego oddzielenia obu grup. Mwic szczerze, te zjawiska nie s wycznie domen osb zajmujcych si przetwarzaniem danych. Podobne
problemy dotycz na przykad pracownikw dziau ksigowoci, ktrzy czsto pracuj
na rnych pitrach, w oddzielnych budynkach, a nawet w innych miastach. Relacje
pomidzy czonkami fizycznie odizolowanych grup staj si formalne, sztywne i dalekie
od normalnoci. Powstaj sztuczne bariery i procedury, ktre jeszcze bardziej potguj
syndrom izolacji.
Mona by powiedzie, e to, co zostao napisane powyej, jest interesujce dla socjologw. Dlaczego wic przypominamy te informacje przy okazji systemu Oracle? Poniewa wdroenie tego systemu fundamentalnie zmienia natur zwizkw zachodzcych
pomidzy pracownikami merytorycznymi a technicznymi. W systemie Oracle nie uywa
si specyficznego jzyka, ktry rozumiej tylko profesjonalici. System ten moe opanowa kady i kady moe go uywa. Informacje, wczeniej wizione w systemach
komputerowych pod czujnym okiem ich administratorw, s teraz dostpne dla menederw, ktrzy musz jedynie wpisa odpowiednie zapytanie. Ta sytuacja znaczco zmienia obowizujce reguy gry.
Od momentu wdroenia systemu Oracle obydwa obozy znacznie lepiej si rozumiej,
normalizujc zachodzce pomidzy nimi relacje. Dziki temu powstaj lepsze aplikacje.
Ju pierwsze wydanie systemu Oracle bazowao na zrozumiaym modelu relacyjnym
(ktry wkrtce zostanie szczegowo omwiony). Osoby, ktre nie s programistami,
nie maj problemw ze zrozumieniem zada wykonywanych przez system Oracle.
Dziki temu jest on dostpny w stopniu praktycznie nieograniczonym.
Niektre osoby nie rozumiej, jak wan rzecz jest, aby runy przestarzae i sztuczne
bariery pomidzy uytkownikami i systemowcami. Z pewnoci jednak metoda kooperacyjna korzystnie wpywa na jako i uyteczno tworzonych aplikacji.
Jednak wielu dowiadczonych projektantw wpada w puapk: pracujc z systemem Oracle,
usiuj stosowa metody sprawdzone w systemach poprzedniej generacji. O wielu z nich
powinni zapomnie, gdy bd nieskuteczne.
Niektre techniki (i ograniczenia), ktre byy staym elementem systemw poprzedniej
generacji, teraz nie tylko s zbyteczne, ale nawet maj ujemny wpyw na dziaanie aplikacji. W procesie poznawania systemu Oracle naley pozby si wikszoci starych nawykw i bezuytecznych metod. Od teraz s dostpne nowe odwieajce moliwoci.
Zaoeniem tej ksiki jest prezentacja systemu Oracle w sposb jasny i prosty z wykorzystaniem poj, ktre s zrozumiae zarwno dla uytkownikw, jak i programistw.
Omawiajc system, wskazano przestarzae i niewaciwe techniki projektowania i zarzdzania oraz przedstawiono alternatywne rozwizania.
Podejcie kooperacyjne
Oracle jest obiektowo-relacyjnym systemem baz danych. Relacyjna baza danych to niezwykle prosty sposb przedstawiania i zarzdzania danymi wykorzystywanymi w biznesie. Model relacyjny to nic innego, jak kolekcja tabel danych. Z tabelami wszyscy
Rozdzia 4.
Planowanie aplikacji systemu Oracle....
57
spotykamy si na co dzie, czytajc na przykad raporty o pogodzie lub wyniki sportowe. Wszystko to s tabele z wyranie zaznaczonymi nagwkami kolumn i wierszy.
Pomimo swojej prostoty model relacyjny wystarcza do prezentowania nawet bardzo
zoonych zagadnie. Obiektowo-relacyjna baza danych charakteryzuje si wszystkimi
wasnociami relacyjnej bazy danych, a jednoczenie ma cechy modelu obiektowego.
Oracle mona wykorzysta zarwno jako relacyjny system zarzdzania baz danych
(RDBMS), jak te skorzysta z jego wasnoci obiektowych.
Niestety jedyni ludzie, ktrym przydaje si relacyjna baza danych uytkownicy biznesowi z reguy najmniej j rozumiej. Projektanci aplikacji tworzcy systemy dla uytkownikw biznesowych czsto nie potrafi objani poj modelu relacyjnego w prosty
sposb. Aby bya moliwa wsppraca, potrzebny jest wsplny jzyk.
Za chwil wyjanimy, czym s relacyjne bazy danych i w jaki sposb wykorzystuje si
je w biznesie. Moe si wydawa, e materia ten zainteresuje wycznie uytkownikw.
Dowiadczony projektant aplikacji relacyjnych odczuje zapewne pokus pominicia
tych fragmentw, a ksik wykorzysta jako dokumentacj systemu Oracle. Chocia
wikszo materiau z pierwszych rozdziaw to zagadnienia elementarne, to jednak
projektanci, ktrzy powic im czas, poznaj jasn, spjn i funkcjonaln terminologi,
uatwiajc komunikacj z uytkownikami oraz precyzyjniejsze ustalenie ich wymaga.
Wane jest rwnie pozbycie si niepotrzebnych i prawdopodobnie niewiadomie stosowanych przyzwyczaje projektowych. Wiele z nich zidentyfikujemy podczas prezentacji
modelu relacyjnego. Trzeba sobie uwiadomi, e nawet moliwoci tak rozbudowanego
systemu, jak Oracle mona zniweczy, stosujc metody waciwe dla projektw nierelacyjnych.
Gdy uytkownik docelowy rozumie podstawowe pojcia obiektowo-relacyjnych baz
danych, moe w spjny sposb przedstawi wymagania projektantom aplikacji. Pracujc
w systemie Oracle, jest w stanie przetwarza informacje, kontrolowa raporty i dane
oraz niczym prawdziwy ekspert zarzdza wasnociami tworzenia aplikacji i zapyta.
wiadomy uytkownik, ktry rozumie funkcjonowanie aplikacji, z atwoci zorientuje
si, czy osigna ona maksymaln wydajno.
System Oracle uwalnia take programistw od najmniej lubianego przez nich obowizku: tworzenia raportw. W duych firmach niemal 95 % wszystkich prac programistycznych to dania tworzenia nowych raportw. Poniewa dziki systemowi Oracle uytkownicy tworz raport w kilka minut, a nie w kilka miesicy, spenianie takiego obowizku
staje si przyjemnoci.
Dane s wszdzie
W bibliotece znajduj si informacje o czytelnikach, ksikach i karach za nieterminowy
zwrot. Waciciel kolekcji kart baseballowych zbiera informacje o graczach, notuje daty
i wyniki meczw, interesuje si wartoci kart. W kadej firmie musz by przechowywane rejestry z informacjami o klientach, produktach czy cenach. Informacje te okrela
si jako dane.
58
Cz I
Teoretycy czsto mwi, e dane pozostaj danymi, dopki nie zostan odpowiednio zorganizowane. Wtedy staj si informacjami. Jeli przyj tak tez, system Oracle miao
mona nazwa mechanizmem wytwarzania informacji, gdy bazujc na surowych danych,
potrafi na przykad wykonywa podsumowania lub pomaga identyfikowa trendy handlowe. Jest to wiedza, z istnienia ktrej nie zawsze zdajemy sobie spraw. W niniejszej
ksice wyjanimy, jak j uzyskiwa.
Po opanowaniu podstaw obsugi systemu Oracle mona wykonywa obliczenia z danymi,
przenosi je z miejsca na miejsce i modyfikowa. Takie dziaania nazywa si przetwarzaniem danych. Rzecz jasna, przetwarza dane mona rwnie, wykorzystujc owek, kartk
papieru i kalkulator, ale w miar jak rosn zbiory danych, trzeba sign po komputery.
System zarzdzania relacyjnymi bazami danych (ang. Relational Database Management
System RDBMS) taki, jak Oracle umoliwia wykonywanie zada w sposb zrozumiay dla uytkownika i stosunkowo nieskomplikowany. Mwic w uproszczeniu, system Oracle pozwala na:
wprowadzanie danych do systemu,
utrzymywanie (przechowywanie) danych,
wyprowadzanie danych i posugiwanie si nimi.
Schemat tego procesu pokazano na rysunku 4.1.

Rysunek 4.1.
Dane w systemie
Oracle
W systemie Oracle sposb postpowania z danymi mona opisa schematem wprowadzanie-utrzymywanie-wyprowadzanie. System dostarcza inteligentnych narzdzi pozwalajcych na stosowanie wyrafinowanych metod pobierania, edycji, modyfikacji i wprowadzania danych, zapewnia ich bezpieczne przechowywanie, a take wyprowadzanie, na
przykad w celu tworzenia raportw.
Jzyk systemu Oracle

Informacje zapisane w systemie Oracle s przechowywane w tabelach. W podobny sposb s prezentowane w gazetach na przykad informacje o pogodzie (rysunek 4.2).
Rozdzia 4.
59
Rysunek 4.2.
Dane w gazetach
czsto podawane
s w tabelach
Tabela pokazana na rysunku skada si czterech kolumn: Miasto, Temperatura, Wilgotno i Warunki. Zawiera take wiersze dla poszczeglnych miast od Aten do Sydney
oraz nazw: POGODA. Kolumny, wiersze i nazwa to trzy gwne cechy drukowanych
tabel. Podobnie jest w przypadku tabel z relacyjnych baz danych. Wszyscy z atwoci
rozumiej pojcia uywane do opisu tabeli w bazie danych, poniewa takie same pojcia
stosuje si w yciu codziennym. Nie kryje si w nich adne specjalne, niezwyke czy
tajemnicze znaczenie. To, co widzimy, jest tym, na co wyglda.
Tabele
W systemie Oracle informacje s zapisywane w tabelach. Kada tabela skada si z jednej lub wikszej liczby kolumn. Odpowiedni przykad pokazano na rysunku 4.3. Nagwki: Miasto, Temperatura, Wilgotno i Warunki wskazuj, jaki rodzaj informacji przechowuje si w kolumnach. Informacje s zapisywane w wierszach (miasto po miecie).
Kady niepowtarzalny zestaw danych, na przykad temperatura, wilgotno i warunki
dla miasta Manchester, jest zapisywany w osobnym wierszu.
Rysunek 4.3.
Tabela POGODA
w systemie Oracle
Aby produkt by bardziej dostpny, firma Oracle unika stosowania specjalistycznej, akademickiej terminologii. W artykuach o relacyjnych bazach danych kolumny czasami
okrela si jako atrybuty, wiersze jako krotki, a tabele jako encje. Takie pojcia s
jednak mylce dla uytkownika. Czsto terminy te s tylko niepotrzebnymi zamiennikami dla powszechnie zrozumiaych nazw z jzyka oglnego. Firma Oracle stosuje
oglny jzyk, a zatem mog go rwnie stosowa programici. Trzeba pamita, e niepotrzebne stosowanie technicznego argonu stwarza barier braku zaufania i niezrozumienia. W tej ksice, podobnie jak to uczyniono w dokumentacji systemu Oracle, konsekwentnie posugujemy si pojciami tabele, kolumny i wiersze.
60
Cz I
Strukturalny jzyk zapyta

Firma Oracle jako pierwsza zacza stosowa strukturalny jzyk zapyta (ang. Structured
Query Language SQL). Jzyk ten pozwala uytkownikom na samodzielne wydobywanie informacji z bazy danych. Nie musz siga po pomoc fachowcw, aby sporzdzi
choby najmniejszy raport.
Jzyk zapyta systemu Oracle ma swoj struktur, podobnie jak jzyk angielski i dowolny
inny jzyk naturalny. Ma rwnie reguy gramatyczne i skadni, ale s to zasady bardzo
proste i ich zrozumienie nie powinno przysparza wikszych trudnoci.
Jzyk SQL, ktrego nazw wymawia si jako sequel lub es-ku-el, oferuje, jak wkrtce si
przekonamy, niezwyke wrcz moliwoci. Korzystanie z niego nie wymaga adnego
dowiadczenia w programowaniu.
Oto przykad, jak mona wykorzystywa SQL. Gdyby kto poprosi nas, abymy w tabeli
POGODA wskazali miasto, gdzie wilgotno wynosi 89 %, szybko wymienilibymy
Ateny. Gdyby kto poprosi nas o wskazanie miast, gdzie temperatura wyniosa 19C,
wymienilibymy Chicago i Manchester.
System Oracle jest w stanie odpowiada na takie pytania niemal rwnie atwo. Wystarczy
sformuowa proste zapytania. Sowa kluczowe wykorzystywane w zapytaniach to
(wybierz), (z),
(gdzie) oraz (uporzdkuj wedug). S to wskazwki
dla systemu Oracle, ktre uatwiaj mu zrozumienie da i udzielenie poprawnej odpowiedzi.
Proste zapytanie w systemie Oracle

Gdyby w bazie danych Oracle bya zapisana przykadowa tabela , pierwsze zapytanie przyjoby pokazan poniej posta (rednik jest informacj dla systemu, e naley
wykona zapytanie):

System Oracle odpowiedziaby na nie w taki sposb:

Drugie zapytanie przyjoby nastpujc posta:

! " #
W przypadku tego zapytania system Oracle odpowiedziaby tak:

$%&'
$%($
Rozdzia 4.
61
Jak atwo zauway, w kadym z tych zapyta wykorzystano sowa kluczowe ,
oraz
. A co z klauzul ? Przypumy, e interesuj nas wszystkie
miasta uporzdkowane wedug temperatury. Wystarczy, e wprowadzimy takie oto zapytanie:

) ! "

*+, ! "
a system Oracle natychmiast odpowie w nastpujcy sposb:

! "

-(.
$%&'#
$%($#
& /#
&'/0
' 1/.
02
System Oracle szybko uporzdkowa tabel od najniszej do najwyszej temperatury.

W jednym z kolejnych rozdziaw dowiemy si, jak okreli, czy najpierw maj by
wywietlane wysze, czy nisze wartoci.
Zaprezentowane powyej przykady pokazuj, jak atwo uzyskuje si potrzebne informacje
z bazy danych Oracle, w postaci najbardziej przydatnej dla uytkownika. Mona tworzy
skomplikowane dania o rne dane, ale stosowane metody zawsze bd zrozumiae.
Mona na przykad poczy dwa elementarne sowa kluczowe
i po
to, by wybra tylko te miasta, w ktrych temperatura przekracza 26 stopni, oraz wywietli je uporzdkowane wedug rosncej temperatury. W tym celu naley skorzysta
z nastpujcego zapytania:

) ! "

! " 3/2

*+, ! "
System Oracle natychmiast wywietli nastpujc odpowied:

! "

' 1/.
02
Mona stworzy jeszcze dokadniejsze zapytanie i poprosi o wywietlenie miast,

w ktrych temperatura jest wysza ni 26 stopni, a wilgotno mniejsza ni 70 %:

) ! " )

! " 3/2
*

4.5

*+, ! "
a system Oracle natychmiast odpowie w nastpujcy sposb:

! "

' 1/.2/
62
Cz I
Dlaczego system baz danych nazywa si relacyjnym?

Zwrmy uwag, e w tabeli wywietlaj si miasta z kilku pastw, przy czym
w przypadku niektrych pastw w tabeli znajduje si wicej ni jedno miasto. Przypumy, e interesuje nas, w ktrym pastwie ley okrelone miasto. W tym celu mona
utworzy oddzieln tabel zawierajc informacje o zlokalizowaniu miast
(rysunek 4.4).
Rysunek 4.4.
Tabele POGODA
i LOKALIZACJA
Kade miasto z tabeli znajduje si rwnie w tabeli . Wystarczy odnale interesujc nas nazw w kolumnie , a wwczas w kolumnie
w tym
samym wierszu znajdziemy nazw pastwa.
S to cakowicie odrbne i niezalene od siebie tabele. Kada z nich zawiera wasne
informacje zestawione w kolumnach i wierszach. Tabele maj cz wspln: kolumn . Dla kadej nazwy miasta w tabeli istnieje identyczna nazwa miasta
w tabeli .
Sprbujmy na przykad dowiedzie si, jakie temperatury, wilgotno i warunki atmosferyczne panuj w miastach australijskich. Spjrzmy na obie tabele i odczytajmy z nich te
informacje.
Rysunek 4.5.
Relacje pomidzy
tabelami POGODA
i LOKALIZACJA
Rozdzia 4.
63
W jaki sposb to zrobilimy? W tabeli znajduje si tylko jeden zapis z wartoci !" w kolumnie
. Obok niego, w tym samym wierszu w kolumnie
figuruje nazwa miasta #$%#. Po odnalezieniu nazwy #$%# w kolumnie
tabeli przesunlimy si wzdu wiersza i znalelimy wartoci pl ! &',
() i ('*. Byy to odpowiednio: +,, -- i .$%$%.
Nawet jeli tabele s niezalene, z atwoci mona spostrzec, e s z sob powizane. Nazwa miasta w jednej tabeli jest powizana (pozostaje w relacji) z nazw miasta w drugiej
(patrz: rysunek 4.5 powyej). Relacje pomidzy tabelami tworz podstaw nazwy relacyjna baza danych (czasami mwi si te o relacyjnym modelu danych).
Dane zapisuje si w tabelach, na ktre skadaj si kolumny, wiersze i nazwy. Tabele mog by z sob powizane, jeli w kadej z nich znajduje si kolumna o takim samym typie informacji. To wszystko. Nie ma w tym nic skomplikowanego.
Proste przykady
Kiedy zrozumiemy podstawowe zasady rzdzce relacyjnymi bazami danych, wszdzie
zaczynamy widzie tabele, wiersze i kolumny. Nie oznacza to, e wczeniej ich nie widzielimy, ale prawdopodobnie nie mylelimy o nich w taki sposb. W systemie
Oracle mona zapisa wiele tabel i wykorzysta je do szybkiego uzyskania odpowiedzi
na pytania.
Typowy raport kursw akcji w postaci papierowej moe wyglda tak, jak ten, ktry
zaprezentowano na rysunku 4.6. Jest to fragment wydrukowanego gst czcionk alfabetycznego zestawienia wypeniajcego szereg wskich kolumn na kilku stronach w gazecie. Jakich akcji sprzedano najwicej? Ktre akcje odnotoway najwyszy procentowy
wzrost, a ktre najwikszy spadek? W systemie Oracle odpowiedzi na te pytania mona
uzyska za pomoc prostych zapyta. Jest to dziaanie o wiele szybsze ni przeszukiwanie kolumn cyfr w gazecie.
Na rysunku 4.7 pokazano indeks gazety. Co mona znale w sekcji F? W jakim porzdku bdziemy czyta artykuy, jeli wertujemy gazet od pocztku do koca?
W systemie Oracle odpowiedzi na te pytania mona uzyska z pomoc prostych zapyta. Nauczymy si, jak formuowa takie zapytania, a nawet tworzy tabele do zapisywania informacji.
W przykadach uytych w tej ksice wykorzystano dane i obiekty, z ktrymi czsto
spotykamy si na co dzie w pracy i w domu. Dane do wykorzystania w wiczeniach
mona znale wszdzie. Na kolejnych stronach pokaemy, w jaki sposb wprowadza
si i pobiera dane. Przykady bazuj na spotykanych na co dzie rdach danych.
Podobnie jak w przypadku kadej nowej technologii, nie wolno dostrzega tylko jej zalet, trzeba rwnie widzie zagroenia. Jeli skorzystamy z relacyjnej bazy danych oraz
szeregu rozbudowanych i atwych w uyciu narzdzi dostarczanych z systemem Oracle,
niebezpieczestwo, e padniemy ofiar tej prostoty, stanie si bardzo realne. Dodajmy
do tego waciwoci obiektowe i atwo wykorzystania w internecie, a zagroenia stan si jeszcze wiksze. W kolejnych punktach przedstawimy niektre zagroenia zwizane z korzystaniem z relacyjnych baz danych, o ktrych powinni pamita zarwno
uytkownicy, jak i projektanci.
64
Cz I
Rysunek 4.6. Tabela kursw akcji

Rysunek 4.7.
Tabela danych
o sekcjach w gazecie
Zagroenia
Podstawowym zagroeniem podczas projektowania aplikacji wykorzystujcych relacyjne
bazy danych jest... prostota tego zadania. Zrozumienie, czym s tabele, kolumny i wiersze
nie sprawia kopotw. Zwizki pomidzy dwoma tabelami s atwe do uchwycenia.
Nawet normalizacji procesu analizy wewntrznych normalnych relacji pomidzy
poszczeglnymi danymi mona z atwoci si nauczy.
Rozdzia 4.
65
W zwizku z tym czsto pojawiaj si eksperci, ktrzy s bardzo pewni siebie, ale maj
niewielkie dowiadczenie w tworzeniu rzeczywistych aplikacji o wysokiej jakoci. Gdy
w gr wchodzi niewielka baza z danymi marketingowymi lub domowy indeks, nie ma to
wielkiego znaczenia. Popenione bdy ujawni si po pewnym czasie. Bdzie to dobra lekcja pozwalajca na uniknicie bdw w przyszoci. Jednak w przypadku wanej aplikacji droga ta w prostej linii prowadzi do katastrofy. Brak dowiadczenia twrcw aplikacji jest czsto podawany w artykuach prasowych jako przyczyna niepowodze
wanych projektw.
Starsze metody projektowania generalnie s wolniejsze, poniewa zadania takie, jak kodowanie, kompilacja, konsolidacja i testowanie zajmuj wicej czasu. Cykl powstawania aplikacji, w szczeglnoci dla komputerw typu mainframe, czsto jest tak mudny,
e aby unikn opnie zwizanych z powtarzaniem penego cyklu z powodu bdu
w kodzie, programici du cz czasu powicaj na sprawdzanie kodu na papierze.
Narzdzia czwartej generacji kusz projektantw, aby natychmiast przekazywa kod do
eksploatacji. Modyfikacje mona implementowa tak szybko, e testowanie bardzo czsto
zajmuje niewiele czasu. Niemal cakowite wyeliminowanie etapu sprawdzania przy biurku stwarza problem. Kiedy znikn negatywny bodziec (dugotrway cykl), ktry zachca do sprawdzania przy biurku, znikno take samo sprawdzanie. Wielu programistw
wyraa nastpujcy pogld: Jeli aplikacja nie dziaa waciwie, bd szybko si poprawi. Jeli dane ulegn uszkodzeniu, mona je szybko zaktualizowa. Jeli metoda okae
si niedostatecznie szybka, dostroi si j w locie. Zrealizujmy kolejny punkt harmonogramu i pokamy to, co zrobilimy.
Testowanie wanego projektu Oracle powinno trwa duej ni testowanie projektu tradycyjnego, niezalenie od tego, czy zarzdza nim dowiadczony, czy pocztkujcy meneder. Musi by take dokadniejsze. Sprawdzi naley przede wszystkim:
poprawno formularzy wykorzystywanych do wprowadzania danych,
tworzenie raportw,
adowanie danych i uaktualnie,
integralno i wspbieno danych,
rozmiary transakcji i pamici masowej w warunkach maksymalnych obcie.
Poniewa tworzenie aplikacji za pomoc narzdzi systemu Oracle jest niezwykle proste,
aplikacje powstaj bardzo szybko. Si rzeczy czas przeznaczony na testowanie w fazie
projektowania skraca si. Aby zachowa rwnowag i zapewni odpowiedni jako
produktu, proces planowanego testowania naley wiadomie wyduy. Cho zazwyczaj
problemu tego nie dostrzegaj programici, ktrzy rozpoczynaj dopiero swoj przygod
z systemem Oracle lub z narzdziami czwartej generacji, w planie projektu naley
przewidzie czas i pienidze na dokadne przetestowanie projektu.
66
Cz I
Znaczenie nowego podejcia

Wielu z nas z niecierpliwoci oczekuje dnia, kiedy bdzie mona napisa zapytanie
w jzyku naturalnym i w cigu kilku sekund uzyska na ekranie odpowied. Jestemy
o wiele blisi osignicia tego celu, ni wielu z nas sobie wyobraa. Czynnikiem ograniczajcym nie jest ju technika, ale raczej schematy stosowane w projektach aplikacji. Za
pomoc systemu Oracle mona w prosty sposb tworzy aplikacje pisane w jzyku
zblionym do naturalnego jzyka angielskiego, ktre z atwoci eksploatuj niezbyt zaawansowani technicznie uytkownicy. W bazie danych Oracle i skojarzonych z ni narzdziach tkwi potencja, cho jeszcze stosunkowo niewielu programistw wykorzystuje go
w peni.
Podstawowym celem projektanta Oracle powinno by stworzenie aplikacji zrozumiaej
i atwej w obsudze tak, aby uytkownicy bez dowiadczenia programistycznego potrafili
pozyskiwa informacje, stawiajc proste pytania w jzyku zblionym do naturalnego.
Czasami oznacza to intensywniejsze wykorzystanie procesora lub wiksze zuycie miejsca na dysku. Nie mona jednak przesadza. Jeli stworzymy aplikacj niezwykle atw
w uyciu, ale tak skomplikowan programistycznie, e jej pielgnacja lub usprawnianie
oka si niemoliwe, popenimy rwnie powany bd. Pamitajmy take, e nigdy nie
wolno tworzy inteligentnych programw kosztem wygody uytkownika.
Zmiana rodowisk
Koszty uytkowania komputerw liczone jako cena miliona instrukcji na sekund (MIPS)
stale spadaj w tempie 20 % rocznie. Z kolei koszty siy roboczej cigle wzrastaj.
Oznacza to, e wszdzie tam, gdzie ludzi mona zastpi komputerami, uzyskuje si
oszczdnoci finansowe.
W jaki sposb cech t uwzgldniono w projektowaniu aplikacji? Odpowied brzmi:
W jaki, cho na pewno nie jest to sposb zadowalajcy. Prawdziwy postp przynioso
na przykad opracowanie rodowiska graficznego przez instytut PARC firmy Xerox, a nastpnie wykorzystanie go w komputerach Macintosh, w przegldarkach internetowych
oraz w innych systemach bazujcych na ikonach. rodowisko graficzne jest znacznie
przyjaniejsze w obsudze ni starsze rodowiska znakowe. Ludzie, ktrzy z niego korzystaj, potrafi stworzy w cigu kilku minut to, co wczeniej zajmowao im kilka dni. Postp w niektrych przypadkach jest tak wielki, e cakowicie utracilimy obraz tego, jak
trudne byy kiedy pewne zadania.
Niestety wielu projektantw aplikacji nie przyzwyczaio si do przyjaznych rodowisk.
Nawet jeli ich uywaj, powielaj niewaciwe nawyki.
Kody, skrty i standardy nazw

Problem starych przyzwyczaje programistycznych staje si najbardziej widoczny, gdy
projektant musi przeanalizowa kody, skrty i standardy nazewnictwa. Zwykle
uwzgldnia wwczas jedynie potrzeby i konwencje stosowane przez programistw, zapominajc o uytkownikach. Moe si wydawa, e jest to suchy i niezbyt interesujcy
Rozdzia 4.
67
problem, ktremu nie warto powica czasu, ale zajcie si nim oznacza rnic pomidzy
wielkim sukcesem a rozwizaniem takim sobie; pomidzy popraw wydajnoci o rzd
wielkoci a marginalnym zyskiem; pomidzy uytkownikami zainteresowanymi i zadowolonymi a zrzdami nkajcymi programistw nowymi daniami.
Oto, co czsto si zdarza. Dane biznesowe s rejestrowane w ksigach i rejestrach. Wszystkie zdarzenia lub transakcje s zapisywane wiersz po wierszu w jzyku naturalnym. W miar opracowywania aplikacji, zamiast czytelnych wartoci wprowadza si kody (np. /,
zamiast &0
, /+ zamiast 0
itd). Pracownicy musz zna te
kody i wpisywa je w odpowiednio oznaczonych polach formularzy ekranowych. Jest to
skrajny przypadek, ale takie rozwizania stosuje si w tysicach aplikacji, przez co trudno
si ich nauczy.
Problem ten najwyraniej wystpuje podczas projektowania aplikacji w duych, konwencjonalnych systemach typu mainframe. Poniewa do tej grupy nale rwnie relacyjne
bazy danych, wykorzystuje si je jako zamienniki starych metod wprowadzania-wyprowadzania danych takich, jak metoda VSAM (ang. Virtual Storage Access Method) oraz
systemy IMS (ang. Information Management System). Wielkie moliwoci relacyjnych
baz danych s niemal cakowicie marnotrawione, jeli s wykorzystywane w taki sposb.
Dlaczego zamiast jzyka naturalnego stosuje si kody?

Po co w ogle stosowa kody? Z reguy podaje si dwa uzasadnienia:
kategoria zawiera tak wiele elementw, e nie mona ich sensownie przedstawi
lub zapamita w jzyku naturalnym,
dla zaoszczdzenia miejsca w komputerze.
Pierwszy powd mona uzna za istotny, a poza tym czciej wystpuje. Wprowadzanie
kodw numerycznych zamiast cigw tekstowych (np. tytuw ksiek) zwykle jest mniej
pracochonne (o ile oczywicie pracownicy s odpowiednio przeszkoleni), a co za tym
idzie tasze. Ale w systemie Oracle stosowanie kodw oznacza po prostu niepene wykorzystanie jego moliwoci. System Oracle potrafi pobra kilka pierwszych znakw tytuu
i automatycznie uzupeni pozosta jego cz. To samo potrafi zrobi z nazwami produktw, transakcji (litera z moe by automatycznie zastpiona wartoci zakup, a litera s
wartoci sprzeda) i innymi danymi w aplikacji. Jest to moliwe dziki bardzo rozbudowanemu mechanizmowi dopasowywania wzorcw.
Drugi powd to ju anachronizm. Pami operacyjna i masowa byy niegdy tak drogie,
a procesory tak wolne (ich moc obliczeniowa nie dorwnywaa wspczesnym nowoczesnym kalkulatorom), e programici musieli stara si zapisywa dane o jak najmniejszej
objtoci. Liczby przechowywane w postaci numerycznej zajmuj w pamici o poow
mniej miejsca ni liczby w postaci znakowej, a kody jeszcze bardziej zmniejszaj wymagania w stosunku do komputerw.
Poniewa komputery byy kiedy drogie, programici wszdzie musieli stosowa kody.
Takie techniczne rozwizanie problemw ekonomicznych stanowio prawdziw udrk
dla uytkownikw. Komputery byy zbyt wolne i za drogie, aby sprosta wymaganiom
ludzi, a zatem szkolono ludzi, aby umieli sprosta wymaganiom komputerw. To dziwactwo byo koniecznoci.
68
Cz I
Ekonomiczne uzasadnienie stosowania kodw zniko wiele lat temu. Komputery s teraz
wystarczajco dobre, aby mona je byo przystosowa do sposobu pracy ludzi, a zwaszcza do uywania jzyka naturalnego. Najwyszy czas, aby tak si stao. A jednak projektanci
i programici, nie zastanawiajc si nad tym zbytnio, w dalszym cigu uywaj kodw.
Korzyci z wprowadzania czytelnych danych

Stosowanie jzyka naturalnego przynosi jeszcze jedn korzy: niemal cakowicie znikaj
bdy w kluczach, poniewa uytkownicy natychmiast widz wprowadzone przez siebie
informacje. Cyfry nie s przeksztacane, nie trzeba wpisywa adnych kodw, zatem nie
istnieje tu moliwo popenienia bdu. Zmniejsza si rwnie ryzyko, e uytkownicy
aplikacji finansowych strac pienidze z powodu bdnie wprowadzonych danych. Aplikacje staj si take bardziej zrozumiae. Ekrany i raporty zyskuj czytelny format, ktry
zastpuje cigi tajemniczych liczb i kodw.
Odejcie od kodw na rzecz jzyka naturalnego ma olbrzymi i oywczy wpyw na firm
i jej pracownikw. Dla uytkownikw, ktrzy musieli si uczy kodw, aplikacja bazujca na jzyku naturalnym oznacza chwil wytchnienia.
Jak zmniejszy zamieszanie?

Zwolennicy kodw argumentuj czasami, e istnieje zbyt dua liczba produktw, klientw, typw transakcji, aby mona byo kadej pozycji nada odrbn nazw. Dowodz
rwnie, ile kopotw sprawiaj pozycje identyczne bd bardzo podobne (np. trzydziestu
klientw nazywajcych si Jan Kowalski). Owszem, zdarza si, e kategoria zawiera
za duo pozycji, aby mona je byo atwo zapamita lub rozrni, ale znacznie czciej
jest to dowd nieodpowiedniego podziau informacji na kategorie: zbyt wiele niepodobnych do siebie obiektw umieszcza si w zbyt obszernej kategorii.
Tworzenie aplikacji zorientowanej na jzyk naturalny wymaga czasu, w ktrym uytkownicy musz komunikowa si z programistami trzeba zidentyfikowa informacje
biznesowe, zrozumie naturalne relacje i kategorie, a nastpnie uwanie skonstruowa baz danych i schemat nazw, ktre w prosty i dokadny sposb odzwierciedl rzeczywisto.
S trzy podstawowe etapy wykonywania tych dziaa:
normalizacja danych,
wybr nazw dla tabel i kolumn w jzyku naturalnym,
wybr nazw danych.
Kady z tych etapw zostanie omwiony w dalszej czci rozdziau. Naszym celem jest
projektowanie sensownie zorganizowanych aplikacji, zapisanych w tabelach i kolumnach,
ktrych nazwy brzmi znajomo dla uytkownika, gdy s zaczerpnite z codziennoci.
Normalizacja
Biece relacje pomidzy krajami, wydziaami w firmie albo pomidzy uytkownikami
i projektantami zazwyczaj s wynikiem historycznych uwarunkowa. Poniewa okolicznoci historyczne dawno miny, w efekcie czasami powstaj relacje ktrych nie mona
Rozdzia 4.
69
uwaa za normalne. Mwic inaczej, s one niefunkcjonalne. Zaszoci historyczne rwnie czsto wywieraj wpyw na sposb zbierania, organizowania i raportowania danych,
co oznacza, e dane take mog by nienormalne lub niefunkcjonalne.
Normalizacja jest procesem tworzenia prawidowego, normalnego stanu. Pojcie pochodzi
od aciskiego sowa norma oznaczajcego przyrzd uywany przez stolarzy do zapewnienia kta prostego. W geometrii normalna jest lini prost przebiegajc pod ktem
prostym do innej linii prostej. W relacyjnych bazach danych norma take ma specyficzne
znaczenie, ktre dotyczy przydzielania rnych danych (np. nazwisk, adresw lub umiejtnoci) do niezalenych grup i definiowania dla nich normalnych lub inaczej mwic
prawidowych relacji.
W normalizacji wyrnia si kilka postaci: najpopularniejsze s pierwsza, druga i trzecia
posta normalna, przy czym trzecia reprezentuje stan najbardziej znormalizowany. Istniej
take postacie czwarta i pita, ale wykraczaj one poza zakres przedstawionego tu wykadu.
Za chwil zostan omwione podstawowe zasady normalizacji, dziki czemu uytkownicy bd mogli uczestniczy w procesie projektowania aplikacji lub lepiej zrozumiej
aplikacj, ktra zostaa stworzona wczeniej. Bdem byoby jednak mylenie, e proces
normalizacji dotyczy jedynie baz danych lub aplikacji komputerowych. Normalizacja to
gboka analiza informacji wykorzystywanych w biznesie oraz relacji zachodzcych pomidzy elementami tych informacji. Umiejtno ta przydaje si w rnych dziedzinach.
Model logiczny
Jedn z pierwszych czynnoci w procesie analizy jest utworzenie modelu logicznego,
czyli po prostu znormalizowanego diagramu danych. Wiedza na temat zasad klasyfikowania danych jest niezbdna do zrozumienia modelu, a model jest niezbdny do stworzenia funkcjonalnej aplikacji.
Rozwamy przypadek z bibliotek. Kada ksika ma tytu, wydawc, autora lub autorw
oraz wiele innych charakterystycznych cech. Przyjmijmy, e dane te posu do zaprojektowania dziesiciokolumnowej tabeli w systemie Oracle. Tabel nazwalimy 11!%,
a kolumnom nadalimy nazwy !', (
, ',, '+, '2 oraz ),,
)+, )2, i &. Uytkownicy tej tabeli ju maj problem:
jednej ksice mona przypisa tylko trzech autorw lub tylko trzy kategorie.
Co si stanie, kiedy zmieni si lista dopuszczalnych kategorii? Kto bdzie musia przejrze wszystkie wiersze tabeli 11!% i poprawi stare wartoci. A co si stanie, jeli
jeden z autorw zmieni nazwisko? Ponownie bdzie trzeba zmodyfikowa wszystkie
powizane rekordy. A co zrobi, jeli ksika ma czterech autorw?
Kady projektant powanej bazy danych staje przed problemem sensownego i logicznego zorganizowania informacji. Nie jest to problem techniczny sensu stricto, wic waciwie nie powinnimy si nim zajmowa, ale przecie projektant bazy danych musi si z nim
upora musi znormalizowa dane. Normalizacj wykonuje si poprzez stopniow reorganizacj danych, tworzc grupy podobnych danych, eliminujc niefunkcjonalne relacje
i budujc relacje normalne.
70
Cz I
Normalizacja danych
Pierwszym etapem reorganizacji jest sprowadzenie danych do pierwszej postaci normalnej. Polega to na umieszczeniu danych podobnego typu w oddzielnych tabelach i wyznaczeniu w kadej z nich klucza gwnego niepowtarzalnej etykiety lub identyfikatora.
Proces ten eliminuje powtarzajce si grupy danych takie, jak autorzy ksiek w tabeli
11!%.
Zamiast definiowa tylko trzech autorw ksiki, dane kadego autora s przenoszone
do tabeli, w ktrej kademu autorowi odpowiada jeden wiersz (imi, nazwisko i opis).
Dziki temu w tabeli 11!% nie trzeba definiowa kolumn dla kilku autorw. Jest to
lepsze rozwizanie projektowe, poniewa umoliwia przypisanie nieograniczonej liczby
autorw do ksiki.
Nastpn czynnoci jest zdefiniowanie w kadej tabeli klucza gwnego informacji,
ktra w niepowtarzalny sposb identyfikuje dane, uniemoliwia dublowanie si grup
danych i pozwala na wybranie interesujcego nas wiersza. Dla uproszczenia zamy, e
tytuy ksiek i nazwiska autorw s niepowtarzalne, a zatem kluczem gwnym w tabeli
!" jest kolumna $0
*'.
Podzielilimy ju tabel 11!% na dwie tabele: !" zawierajc kolumny $3
0
*' (klucz gwny) i
) oraz 11!%, z kluczem gwnym !'
i kolumnami (
, ),, )+, )2, i &. Trzecia
tabela 11!%4!" definiuje powizania. Jednej ksice mona przypisa wielu
autorw, a jeden autor moe napisa wiele ksiek jest to zatem relacja wiele do
wielu. Relacje i klucze gwne zaprezentowano na rysunku 4.8
Rysunek 4.8.
Tabele
BIBLIOTECZKA,
AUTOR
i BIBLIOTECZKA_
AUTOR
Nastpna czynno w procesie normalizacji doprowadzenie danych do drugiej postaci

normalnej obejmuje wydzielenie danych, ktre zale tylko od czci klucza. Jeli
istniej atrybuty, ktre nie zale od caego klucza, naley je przenie do nowej tabeli.
W tym przypadku kolumna & w istocie nie zaley od kolumny !', zaley natomiast od kolumny i dlatego naley j przenie do oddzielnej tabeli.
Aby osign trzeci posta normaln, naley pozby si z tabeli wszystkich atrybutw,
ktre nie zale wycznie od klucza gwnego. W zaprezentowanym przykadzie pomidzy kategoriami zachodz relacje wzajemne. Nie mona wymieni ksiki jednoczenie w kategorii Fikcja i Fakty, a w kategoriach Doroli i Dzieci mona wymieni kilka
podkategorii. Z tego powodu informacje o kategoriach naley przenie do oddzielnej
tabeli. Tabele w trzeciej postaci normalnej przedstawia rysunek 4.9.
Rozdzia 4.
71
Rysunek 4.9.
Tabela
BIBLIOTECZKA
i tabele powizane
Dane, ktre osigny trzeci posta normaln, z definicji znajduj si take w postaciach
pierwszej i drugiej. W zwizku z tym nie trzeba mudnie przeksztaca jednej postaci
w drug. Wystarczy tak zorganizowa dane, aby wszystkie kolumny w kadej tabeli
(oprcz klucza gwnego) zaleay wycznie od caego klucza gwnego. Trzeci posta
normaln czasami opisuje si fraz klucz, cay klucz i nic innego, tylko klucz.
Poruszanie si w obrbie danych

Baza danych 11!% jest teraz w trzeciej postaci normalnej. Przykadow zawarto
tabel pokazano na rysunku 4.10. Z atwoci mona zauway relacje pomidzy tabelami.
Aby uzyska informacje o poszczeglnych autorach, korzystamy z kluczy. Klucz gwny
w kadej tabeli w sposb niepowtarzalny identyfikuje pojedynczy wiersz. Wybierzmy
na przykad autora o nazwisku Stephen Jay Gould, a natychmiast znajdziemy odpowiadajcy mu zapis w tabeli !", poniewa pole $0
*' jest kluczem gwnym.
Odszukajmy autork Harper Lee w kolumnie $0
*' w tabeli 11!%4!",
a zobaczymy, e napisaa ona powie Zabi drozda. Nastpnie w tabeli 11!%
moemy sprawdzi wydawc, kategori i ocen tej ksiki, a w tabeli %$ opis oceny.
Jeli szukamy tytuu Zabi drozda w tabeli 11!%, skorzystamy z klucza gwnego
w tabeli. Aby znale autora ksiki, mona odwrci wczeniejsz ciek wyszukiwania, poszukujc w tabeli 11!%4!" rekordw, ktre w kolumnie !' maj
szukan warto kolumna !' jest kluczem obcym w tabeli 11!%4!".
Jeli klucz gwny tabeli 11!% znajdzie si w innej tabeli tak, jak to ma miejsce
w przypadku tabeli 11!%4!", nazywa si go kluczem obcym tej tabeli.
Poniewa dane zorganizowano w sposb logiczny, mona przygotowa kategorie i oceny, do ktrych nie przypisano jeszcze adnych ksiek. Jest to sensowny i logiczny sposb organizowania informacji nawet wtedy, gdy tabele s zapisane w ksice magazynowej lub na fiszkach przechowywanych w pudekach. Oczywicie cigle czeka nas
sporo pracy, aby dane zorganizowane w ten sposb przeksztaci w prawdziw baz danych. Na przykad pole $0
*' mona podzieli na i $0
*. Przydaaby
si te moliwo wywietlenia informacji o tym, kto jest gwnym autorem ksiki, a kto
na przykad recenzentem.
72
Cz I
Rysunek 4.10.
Przykadowe dane
z bazy danych
BIBLIOTECZKA
Cay ten proces nazywa si normalizacj. Naprawd nie ma w tym nic specjalnego.
Chocia dobry projekt aplikacji bazodanowej uwzgldnia kilka dodatkowych zagadnie, podstawowe zasady analizowania normalnych relacji pomidzy rnymi danymi
s tak proste, jak wanie opisalimy.
Trzeba jednak pamita, e normalizacja jest czci procesu analizy, a nie projektu.
Uznanie, e znormalizowane tabele modelu logicznego s projektem rzeczywistej bazy
danych to istotny bd. Mylenie procesw analizy i projektowania jest podstawow
przyczyn niepowodze powanych aplikacji wykorzystujcych relacyjne bazy danych,
Rozdzia 4.
73
o ktrych pniej mona przeczyta w prasie. Zagadnienia te z ktrymi dokadnie

powinni zapozna si programici zostan opisane bardziej szczegowo w dalszej
czci rozdziau.
Opisowe nazwy tabel i kolumn

Po zidentyfikowaniu relacji zachodzcych pomidzy rnymi elementami w bazie danych
i odpowiednim posegregowaniu danych, naley powici sporo czasu na wybranie
nazw dla tabel i kolumn, w ktrych zostan umieszczone dane. Zagadnieniu temu czsto
powica si zbyt mao uwagi. Lekcewa je nawet ci, ktrzy powinni zdawa sobie
spraw z jego doniosoci. Nazwy tabel i kolumn czsto s wybierane bez konsultacji
oraz odpowiedniej analizy. Nieodpowiedni dobr nazw tabel i kolumn ma powane nastpstwa podczas korzystania z aplikacji.
Dla przykadu rozwamy tabele pokazane na rysunku 4.10. Nazwy mwi tu same za siebie. Nawet uytkownik, dla ktrego problematyka relacyjnych baz danych jest nowa,
nie bdzie mia trudnoci ze zrozumieniem zapytania nastpujcej postaci1:
,"),*

6(6-($78

*+,,*
Uytkownicy rozumiej zapytanie, poniewa wszystkie sowa brzmi znajomo. Nie s to

jakie tajemnicze zaklcia. Kiedy trzeba zdefiniowa tabele zawierajce znacznie wicej
kolumn, dobranie odpowiednich nazw jest trudniejsze. W takiej sytuacji wystarczy jednak
konsekwentnie stosowa kilka regu. Przeanalizujmy kilka problemw, ktre czsto powstaj w przypadku braku odpowiedniej konwencji nazw. Zastanwmy si, co by si stao,
gdybymy zastosowali takie oto nazwy:
6(6-($7869:8'(

,"," ;9 <
,* ;9 <
!9<
< 9<
Nazwy zastosowane w tej tabeli, mimo e dziwne, s niestety do powszechne. Zostay

dobrane zgodnie z konwencj (lub brakiem konwencji) wykorzystywan przez znanych
producentw oprogramowania i programistw. Poniej wymieniono kilka bardziej znanych
problemw wystpujcych podczas dobierania nazw.
Stosowanie skrtw bez powodu. W ten sposb zapamitanie pisowni nazw staje
si niemal niemoliwe. Nazwy mogyby rwnie dobrze by kodami, poniewa
uytkownicy i tak musz ich szuka.
Niespjne stosowanie skrtw.
Mowa tu oczywicie o uytkownikach znajcych podstawy jzyka angielskiego. Jednak nawet ci, ktrzy nie
znaj tego jzyka, zrozumiej zapytanie, jeli poznaj znaczenie kilku sw: select wybierz, from z,
where gdzie, order by uporzdkuj wedug przyp. tum.
74
Cz I
Na podstawie nazwy nie mona w sposb jednoznaczny okreli przeznaczenia

tabeli lub kolumny. Skrty nie tylko powoduj, e zapamitanie pisowni nazw
staje si trudne, ale rwnie zaciemniaj natur danych zapisanych w kolumnie
lub tabeli. Co to jest &4* lub * ?
Niespjne stosowanie znakw podkrelenia. Znakw podkrelenia czasami uywa

si do oddzielania sw w nazwie, ale innym razem nie uywa si ich w ogle.
W jaki sposb zapamita gdzie wstawiono znaki podkrelenia, a gdzie nie?
Niespjne stosowanie liczby mnogiej. !%" czy !%"%? 0

czy 0?
Stosowane reguy maj ograniczenia. Jeli nazwa kolumny rozpoczyna si

od pierwszej litery nazwy tabeli (np. kolumna 0 w tabeli, ktrej nazwa
rozpoczyna si na liter A), to co naley zrobi, kiedy innej tabeli trzeba nada
nazw na liter A? Czy kolumn w tej tabeli rwnie nazwiemy 0? Jeli tak,
to dlaczego nie nada obu kolumnom nazwy $0
*?
Uytkownicy, ktrzy nadaj tabelom i kolumnom niewaciwe nazwy, nie s w stanie

w prosty sposb formuowa zapyta. Zapytania nie maj intuicyjnego charakteru i znajomego wygldu tak, jak w przypadku zapytania do tabeli 11!%, co w znacznym
stopniu zmniejsza uyteczno aplikacji.
Dawniej od programistw wymagano tworzenia nazw skadajcych si maksymalnie z omiu
znakw. W rezultacie nazwy byy mylcym zlepkiem liter, cyfr i niewiele mwicych
skrtw. Obecnie podobne ograniczenia, wymuszane przez star technologi, nie maj ju
zastosowania. W systemie Oracle nazwy kolumn i tabel mog mie rozmiar do 30 znakw.
Projektanci zyskali dziki temu moliwo tworzenia nazw penych, jednoznacznych
i opisowych.
Pamitajmy zatem, aby w nazwach wystrzega si skrtw, liczby mnogiej i nie stosowa
znakw podkrelenia (lub stosowa je konsekwentnie). Unikniemy wwczas mylcych
nazw, ktre obecnie zdarzaj si nader czsto. Jednoczenie konwencje nazw musz by
proste, zrozumiae i atwe do zapamitania. W pewnym sensie potrzebna jest zatem normalizacja nazw. W podobny sposb, w jaki analizujemy dane, segregujemy je wedug
przeznaczenia i w ten sposb normalizujemy, powinnimy przeanalizowa standardy
nazewnictwa. Bez tego zadanie utworzenia aplikacji zostanie wykonane niewaciwie.
Dane w jzyku naturalnym

Po przeanalizowaniu konwencji nazw dla tabel i kolumn, trzeba powici uwag samym
danym. Przecie od czytelnoci danych bdzie zalee czytelno drukowanego raportu.
W przykadzie z baz danych 11!%, wartoci w kolumnie s wyraone za
pomoc kodu, a ) to poczenie kilku wartoci. Czy to dobrze? Jeli zapytamy
kogo o ksik, czy chcielibymy usysze, e uzyskaa ona ocen 4 w kategorii DoroliFakty? Dlaczego mielibymy pozwala maszynie, aby wyraaa si nie do jasno?
Dziki opisowym informacjom formuowanie zapyta staje si atwiejsze. Zapytanie
powinno w maksymalny sposb przypomina zdanie z jzyka naturalnego:
"") ;<
"

6(6-($789:'
Rozdzia 4.
75
Stosowanie wielkich liter w nazwach i danych

Nazwy tabel i kolumn s zapisywane w wewntrznym sowniku danych systemu Oracle
za pomoc wielkich liter. Gdy w zapytaniu nazwy wpiszemy maymi literami, system
natychmiast zmieni ich wielko, a nastpnie przeszuka sownik danych. W niektrych
systemach relacyjnych baz danych wielko liter ma znaczenie. Jeli uytkownik wpisze
nazw kolumny jako , a w bazie danych kolumna ta wystpuje jako 0
lub $ (w zalenoci od tego, w jaki sposb zdefiniowano kolumn podczas tworzenia tabeli), system nie zrozumie zapytania.
Uytkownik moe wymusi na systemie Oracle obsug nazw o mieszanej wielkoci
liter, ale wwczas tworzenie zapyta i praca z danymi bd trudniejsze. Z tego
powodu najlepiej wykorzystywa domyln waciwo stosowanie wielkich liter.
Rozrnianie wielkoci liter jest czasami promowane jako zaleta baz danych, dziki ktrej
programici mog tworzy rne tabele o podobnych nazwach jak choby &
*,

* i &"
*. Ale w jaki sposb zapamita rnice? Taka waciwo jest
w istocie wad, a nie zalet. Firma Oracle bya wystarczajco rozsdna, aby nie wpa w t
puapk.
Podobnie rzecz si ma w przypadku danych zapisanych w bazie. Skoro istnieje moliwo
interakcji z systemem Oracle w taki sposb, e wielko liter w zapytaniach nie ma znaczenia, to istniej rwnie sposoby wyszukiwania danych, niezalenie od tego, czy zostay
zapisane wielkimi, czy maymi literami. Ale po co wykonywa niepotrzebne dziaania?
Poza kilkoma wyjtkami, takimi jak teksty prawnicze lub formularze, o wiele atwiej
zapisywa dane za pomoc wielkich liter i tworzy aplikacje, w ktrych wybrano spjn
wielko liter dla danych. Dziki temu formuowanie zapyta staje si atwiejsze, a dane
otrzymuj spjniejszy wygld w raportach. Jeli niektre dane trzeba zapisa mieszanymi
literami (np. nazwisko i adres na kopercie), mona wywoa funkcj systemu Oracle,
ktra dokona odpowiedniej konwersji.
Uwani czytelnicy dostrzegli zapewne, e autor ksiki nie przestrzega dotychczas tej
zasady. Jej stosowanie opniano do czasu odpowiedniego wprowadzenia i umieszczenia
jej we waciwym kontekcie. Od tej pory, poza kilkoma uzasadnionymi wyjtkami, dane
w bazie danych bd zapisywane wielkimi literami.
Normalizacja nazw
Na rynku pojawio si kilka narzdzi umoliwiajcych stosowanie w zapytaniach sw
jzyka naturalnego zamiast dziwnych zestawie. Dziaanie tych produktw polega na utworzeniu logicznej mapy ze sw jzyka naturalnego, trudnych do zapamitania kodw
oraz nazw kolumn i tabel. Przygotowanie takiego odwzorowania wymaga szczegowej
analizy, ale po pomylnym wykonaniu tego zadania interakcja z aplikacj staje si o wiele
atwiejsza. Jednak dlaczeg by nie zwrci uwagi na ten problem od pocztku? Po co
tworzy dodatkowy produkt i wykonywa dodatkow prac, skoro mona unikn wikszoci zamieszania, od razu nadajc odpowiednie nazwy?
76
Cz I
Aby zapewni odpowiedni wydajno aplikacji, czasami niektre dane s zapisywane

w bazie w postaci zakodowanej. Kody te nie powinny by ujawniane uytkownikom ani
podczas wprowadzania danych, ani podczas ich pobierania. System Oracle umoliwia
ich atwe ukrywanie.
Jeli przy wprowadzaniu danych trzeba zastosowa kody, natychmiast wzrasta liczba bdw literowych. Jeli kody wystpuj w raportach zamiast powszechnie uywanych
sw, pojawiaj si bdy interpretacji. A kiedy uytkownicy chc utworzy nowy raport,
ich zdolno do szybkiego i dokadnego wykonania tej czynnoci jest znacznie ograniczona zarwno za spraw kodw, jak i z powodu trudnoci w zapamitaniu dziwnych
nazw kolumn i tabel.
System Oracle daje uytkownikom moliwo posugiwania si jzykiem naturalnym
w caej aplikacji. Ignorowanie tej sposobnoci jest marnotrawieniem moliwoci systemu
Oracle. Jeli z niej nie skorzystamy, bezsprzecznie powstanie mniej zrozumiaa i mao
wydajna aplikacja. Programici maj obowizek skorzystania z okazji. Uytkownicy
powinni si tego domaga. Obie grupy z ca pewnoci na tym skorzystaj.
Czynnik ludzki
Uytkownicy, ktrzy dopiero rozpoczynaj przygod z systemem Oracle, by moe poczuli
ju ochot, aby przej do konkretnych dziaa. Jednak sposoby pracy z uyciem jzyka
SQL zostan opisane dopiero w nastpnym rozdziale. Teraz zajmiemy si inn problematyk: sprbujemy przeanalizowa projekt programistyczny, w ktrym zamiast skupia
si na danych, wzito pod uwag rzeczywiste zadania biznesowe wykonywane przez
uytkownikw docelowych.
Technologie normalizacji danych oraz wspomagana komputerowo inynieria oprogramowania (ang. Computer Aided Software Engineering CASE) zyskay tak wielkie znaczenie podczas projektowania aplikacji relacyjnych, e koncentracja na danych, zagadnieniach referencyjnej integralnoci, kluczach i diagramach tabel staa si prawie obsesj.
Zagadnienia te czsto s mylone z waciwym projektem. Przypomnienie, i jest to tylko
analiza, dla wielu stanowi spore zaskoczenie.
Normalizacja jest analiz, a nie projektowaniem. A waciwie jest to jedynie cz analizy, niezbdna do zrozumienia zasad funkcjonowania danej firmy i stworzenia uytecznej
aplikacji. Celem aplikacji jest przede wszystkim wspomaganie dziaa przedsibiorstwa
poprzez szybsze i wydajniejsze wykonywanie zada biznesowych oraz usprawnienie
rodowiska pracy. Jeli pracownikom damy kontrol nad informacjami oraz zapewnimy
do nich prosty i intuicyjny dostp, odpowiedz wzrostem wydajnoci. Jeli kontrol
powierzymy obcej grupie, ukryjemy informacje za wrogimi interfejsami pracownicy
bd niezadowoleni, a przez to mniej wydajni.
Naszym celem jest zaprezentowanie filozofii dziaania, ktra prowadzi do powstania
przyjaznych i wygodnych aplikacji. Do projektowania struktur danych oraz przepywu
sterowania wystarcz narzdzia, ktre znamy i ktrych uywamy w codziennej pracy.
Rozdzia 4.
77
Zadania aplikacji i dane aplikacji

Twrcy oprogramowania czsto nie powicaj naleytej uwagi identyfikacji zada, ktrych wykonywanie chc uproci. Jedn z przyczyn tego stanu rzeczy jest wysoki poziom zoonoci niektrych projektw, drug znacznie czciej wystpujc skupienie si na danych.
Podczas analizy programici najpierw pytaj o rodzaj pobieranych danych oraz sposb
ich przetwarzania i przedstawiania w raportach. Pniej zadaj szereg pyta pomocniczych,
poruszajc takie zagadnienia, jak formularze do wprowadzania danych, kody, projekty ekranw, obliczenia, komunikaty, poprawki, raport audytu, objto pamici masowej, cykl
przetwarzania danych, formatowanie raportw, dystrybucja i pielgnacja. S to bardzo wane zagadnienia. Problem polega na tym, e wszystkie koncentruj si wycznie na danych.
Profesjonalici korzystaj z danych, ale wykonuj zadania. Ich wiedza i umiejtnoci s
naleycie zagospodarowane. Z kolei szeregowi urzdnicy czsto jeszcze zajmuj si jedynie wpisywaniem danych do formularza wejciowego. Zatrudnianie ludzi tylko po to,
by wprowadzali dane, w szczeglnoci dane o duej objtoci, spjne co do formatu
(tak, jak w przypadku formularzy) oraz z ograniczon rnorodnoci, jest drogie, przestarzae, a przede wszystkim antyhumanitarne. Czasy takiego mylenia ju przeminy,
podobnie jak czasy kodw minimalizujcych ograniczenia maszyn.
Pamitajmy ponadto, e rzadko kiedy pracownik, rozpoczwszy realizacj zadania, zajmuje si nim tak dugo, a je ukoczy. Zwykle wykonuje rne dodatkowe czynnoci,
mniej lub bardziej wane, ale w jaki sposb powizane z zadaniem gwnym. Bywa,
e realizuje je rwnolegle wszystkie naraz.
Wszystko to ma swoje konsekwencje praktyczne. Projektanci, ktrzy pracuj w nowoczesny sposb, nie koncentruj si na danych tak, jak to byo w przeszoci. Dla nich
najwaniejsze s zadania, ktre z pomoc aplikacji bdzie wykonywa uytkownik. Dlaczego rodowiska okienkowe odniosy taki sukces? Poniewa pozwalaj uytkownikowi
na szybk zmian realizowanego zadania, a kilka zada moe oczekiwa na swoj kolej
w stanie aktywnoci. Takiej lekcji nie mona zmarnowa. Naley wycign z niej
prawidowe wnioski.
Identyfikacja zada aplikacji to przedsiwzicie znacznie ambitniejsze ni prosta identyfikacja i normalizacja danych lub zwyke zaprojektowanie ekranw, programw przetwarzajcych i narzdzi raportujcych. Oznacza ona zrozumienie rzeczywistych potrzeb
uytkownika i w efekcie opracowanie aplikacji, ktra interpretuje zadania, a nie tylko
pobiera skojarzone z nimi dane. Jeli projektant skoncentruje si na danych, aplikacja
znieksztaci zadania uytkownikw. Najwikszym problemem jest wic uwiadomienie
sobie, e skoncentrowanie si na zadaniach jest koniecznoci.
Rozpoczynajc proces analizy, najpierw musimy okreli, do jakich zada uytkownicy docelowi wykorzystuj komputery. Jak usug lub produkt chc wytworzy? Jest to podstawowe i moe nawet nieco uproszczone pytanie, ale jak zaraz zobaczymy, zaskakujco
wielu ludzi nie potrafi udzieli na nie przekonujcej odpowiedzi. Przedstawiciele licznych
bran, poczwszy od ochrony zdrowia, a na bankach, firmach wysykowych i fabrykach skoczywszy, uwaaj, e istot ich pracy jest przetwarzanie danych. Przecie dane s
wprowadzane do komputerw i przetwarzane, po czym tworzy si raporty czy nie?
78
Cz I
Z powodu tej deformacji, ktr naley uzna za jeszcze jeden przejaw orientacji na dane
w projektowaniu systemw, mnstwo firm podjo prb wprowadzenia na rynek wyimaginowanego produktu przetwarzania danych z katastrofalnymi, rzecz jasna, skutkami.
Dlatego tak wana jest wiedza na temat przeznaczenia aplikacji. Aby projektant zrozumia,
czym naprawd zajmuje si dana dziedzina, do czego suy wytworzony produkt i jakie
zadania s wykonywane w procesie produkcji, musi mie otwart gow i czsto intuicyjnie
wyczuwa przedmiot biznesu. Rwnie wane jest, aby uytkownicy aplikacji znali jzyk
SQL i orientowali si w zaoeniach modelu relacyjnego. Zesp skadajcy si z projektantw, ktrzy rozumiej potrzeby uytkownikw i doceniaj warto zorientowanego
na zadania, czytelnego rodowiska aplikacji, oraz z uytkownikw majcych odpowiednie
przygotowanie techniczne (np. dziki przeczytaniu niniejszej ksiki) z pewnoci
stworzy bardzo dobry system. Czonkowie takiego zespou wzajemnie sprawdzaj si,
mobilizuj i pomagaj w realizacji indywidualnych zada.
Punktem wyjcia w pracach nad przygotowaniem profesjonalnej aplikacji bdzie wic opracowanie dwch zbienych z sob dokumentw: jednego z opisem zada, drugiego z opisem danych. Przygotowujc opis zada, uwiadamiamy sobie sens aplikacji. Opis danych
pomaga w implementacji wizji i zapewnia uwzgldnienie wszystkich szczegw i obowizujcych zasad.
Identyfikacja zada
Dokument, ktry opisuje zadania zwizane z prowadzon dziaalnoci, powstaje w wyniku wsplnej pracy uytkownikw docelowych i projektantw aplikacji. Rozpoczyna
si od zwizego opisu tej dziaalnoci. Powinno to by jedno proste zdanie, skadajce
si z nie wicej ni 10 sw, pisane w stronie czynnej, bez przecinkw i z minimaln
liczb przymiotnikw, na przykad:
Zajmujemy si sprzeda ubezpiecze.
A nie:
Firma Amalgamated Diversified jest wiodcym midzynarodowym dostawc
produktw finansowych w dziedzinie ubezpiecze zdrowotnych i komunikacyjnych,
prowadzc w tym zakresie rwnie szkolenia i wiadczc usugi doradcze.
Istnieje pokusa, aby w pierwszym zdaniu umieci wszelkie szczegy dotyczce prowadzonej dziaalnoci. Nie naley tego robi. Skrcenie rozwlekego opisu do prostego
zdania umoliwia skoncentrowanie si na temacie. Jeli kto nie potrafi si w ten sposb streci, oznacza to, e jeszcze nie zrozumia istoty prowadzonej dziaalnoci.
Uoenie tego zdania, ktre inicjuje proces tworzenia dokumentacji, jest wsplnym obowizkiem projektantw i uytkownikw. Wsppracujc, atwiej znajd odpowied na
pytania, czym zajmuje si przedsibiorstwo i w jaki sposb wykonywane s jego zadania. Jest
to cenna wiedza dla firmy, gdy w procesie poszukiwania odpowiedzi zidentyfikowanych
zostaje wiele zada podrzdnych, jak rwnie procedur i regu, ktre nie maj znaczenia
lub s uywane marginalnie. Zazwyczaj s to albo odpryski problemu, ktry ju rozwizano, albo postulaty menederw, ktre dawno zostay zaatwione.
Rozdzia 4.
79
Przekorni twierdz, e aby poradzi sobie z nadmiarem raportw, naley zaprzesta ich
tworzenia i sprawdzi, czy ktokolwiek to zauway. W tym przesadnym stwierdzeniu
tkwi ziarno prawdy przecie w podobny sposb rozwizano problem roku dwutysicznego w starszych komputerach! Okazao si, e wiele programw nie wymagao wprowadzania poprawek z tego prostego powodu, e zaprzestano ich uywania!
Programista aplikacji, dokumentujc zadania firmy, ma prawo zadawa dociekliwe pytania
i wskazywa marginalne obszary jej dziaalnoci. Naley jednak zdawa sobie spraw, e
projektant nigdy nie bdzie tak dobrze rozumia zada firmy, jak uytkownik docelowy.
Istnieje rnica pomidzy wykorzystaniem prac projektowych do zracjonalizowania wykonywanych zada i zrozumienia ich znaczenia a obraaniem uytkownikw poprzez
prb wmwienia im, e znamy firm lepiej ni oni.
Naley poprosi uytkownika o w miar szczegowe przedstawienie celw firmy, a take
zada, ktre zmierzaj do ich realizacji. Jeli cele s niezbyt dobrze umotywowane (np.
zawsze to robimy w ten sposb lub myl, e wykorzystuj to do czego), powinna
zapali si nam czerwona lampka. Powinnimy powiedzie, e nie rozumiemy, i poprosi
o ponowne wyjanienia. Jeli odpowied w dalszym cigu nie jest zadowalajca, naley
umieci takie zadanie na oddzielnej licie w celu pniejszej dokadnej analizy. Na
niektre z takich pyta odpowiedzi udziel uytkownicy lepiej znajcy temat, z innymi
bdzie trzeba si zwrci do kierownictwa, a wiele zada wyeliminujemy, poniewa
oka si niepotrzebne. Jednym z dowodw na dobrze przeprowadzony proces analizy
jest usprawnienie istniejcych procedur. Jest to niezalene od nowej aplikacji komputerowej i generalnie powinno nastpi na dugo przed jej zaimplementowaniem.
Oglny schemat dokumentu opisujcego zadania

Dokument opisujcy zadania skada si z trzech sekcji:
zdanie charakteryzujce prowadzon dziaalno (trzy do dziesiciu sw),
kilka krtkich zda opisujcych w prostych sowach gwne zadania firmy,
opis zada szczegowych.
Po kadej sekcji mona umieci krtki, opisowy akapit, jeli jest taka potrzeba, co oczywicie nie usprawiedliwia lenistwa w deniu do jasnoci i zwizoci. Gwne zadania
zazwyczaj numeruje si jako 1.0, 2.0, 3.0 itd. i opisuje jako zadania poziomu zero. Dla
niszych poziomw wykorzystuje si dodatkowe kropki, na przykad 3.1 oraz 3.1.14.
Kade zadanie gwne rozpisuje si na szereg zada niepodzielnych takich, ktre albo
trzeba wykona do koca, nie przerywajc ich realizacji, albo cakowicie anulowa.
Wypisanie czeku jest zadaniem niepodzielnym, ale wpisanie samej kwoty ju nie. Odebranie telefonu w imieniu dziau obsugi klienta nie jest zadaniem niepodzielnym. Odebranie telefonu i spenienie da klienta jest zadaniem niepodzielnym. Zadania niepodzielne musz mie znaczenie, a ich wykonanie musi przynosi jakie rezultaty.
Poziom, na ktrym zadanie staje si niepodzielne, zaley od treci zadania gwnego.
Zadanie oznaczone jako 3.1.14 moe by niepodzielne, ale rwnie dobrze moe zawiera
kilka dodatkowych poziomw podrzdnych. Niepodzielne moe by zadanie 3.2, ale take 3.1.16.4. Wany nie jest sam schemat numerowania (ktry jest po prostu metod opisu hierarchii zada), ale dekompozycja zada do poziomu niepodzielnego.
80
Cz I
Dwa zadania w dalszym cigu mog by niepodzielne, nawet jeli okae si, e jedno zaley od drugiego, ale tylko wtedy, kiedy jedno moe zakoczy si niezalenie od drugiego.
Jeli dwa zadania zawsze zale od siebie, nie s to zadania niepodzielne. Prawdziwe
zadanie niepodzielne obejmuje oba te zadania.
W przypadku wikszoci przedsiwzi szybko si zorientujemy, e wiele zada podrzdnych mona przyporzdkowa do dwch lub wikszej liczby zada z poziomu zero,
co niemal zawsze dowodzi, e niewaciwie zdefiniowano zadania gwne lub dokonano nieodpowiedniego ich podziau. Celem naszych dziaa jest przeksztacenie kadego
zadania w pojciowy obiekt, z dobrze zdefiniowanymi zadaniami i jasno okrelonymi
zasobami niezbdnymi do osignicia celu.
Wnioski wynikajce z dokumentu opisujcego zadania

Wnioskw jest kilka. Po pierwsze, poniewa dokument ten jest bardziej zorientowany na
zadania ni na dane, istnieje prawdopodobiestwo, e pod wpywem zawartych w nim
zapisw zmieni si sposb projektowania ekranw uytkownika. Dokument ma take
wpyw na zasady pobierania i prezentacji danych oraz na implementacj systemu pomocy.
Gwarantuje, e przeczanie pomidzy zadaniami nie bdzie wymagao od uytkownika
zbytniego wysiku.
Po drugie, w miar odkrywania konfliktw pomidzy zadaniami podrzdnymi moe
zmieni si opis zada gwnych. To z kolei wpywa na sposb rozumienia zada przedsibiorstwa zarwno przez uytkownikw, jak i projektantw aplikacji.
Po trzecie, nawet akapity koczce sekcje prawdopodobnie ulegn zmianie. Racjonalizacja, polegajca w tym przypadku na definiowaniu niepodzielnych zada i budowaniu
wspomnianych przed chwil pojciowych obiektw, wymusza usunicie niedomwie i zalenoci, ktre niepotrzebnie wywieraj wpyw na dziaalno firmy.
Tworzenie tego dokumentu nie jest procesem bezproblemowym trzeba szuka odpowiedzi na niewygodne pytania, ponownie definiowa niewaciwe zaoenia, mudnie korygowa bdy. Ostatecznie jednak jego opracowanie przynosi due korzyci. Lepiej rozumiemy sens dziaalnoci firmy, potrafimy okreli obowizujce procedury,
moemy zaplanowa automatyzacj zada.
Identyfikacja danych
Definiujc kade zadanie, okrelamy zasoby potrzebne do jego realizacji, w tym przede
wszystkim dane. Wymagania w zakresie danych uwzgldniamy w dokumencie opisu
danych. Nie chodzi tu o opis pl w formularzach i zawartych w nich elementw. Chodzi
o rejestr koniecznych danych. Poniewa o tym, ktre dane s konieczne, decyduje tre
zadania, a nie istniejce formularze, niezbdna staje si dokadna analiza tej treci oraz
okrelenie rzeczywistych wymaga w zakresie danych. Jeli osoba wykonujca zadanie
nie zna zastosowania pola, w ktre wprowadza dane, takie pole naley umieci na licie
problemw wymagajcych dokadniejszej analizy. Pracujc w ten sposb, usuwamy mnstwo niepotrzebnych danych.
Rozdzia 4.
81
Po zidentyfikowaniu danych naley je uwanie przeanalizowa. Szczegln uwag powinnimy zwrci na kody numeryczne i literowe, ktre ukrywaj rzeczywiste informacje
za barier nieintuicyjnych, niewiele mwicych symboli. Poniewa zawsze budz podejrzenia, naley do nich podchodzi z dystansem. W kadym przypadku trzeba zada sobie
pytanie, czy okrelony element powinien by kodem, czy nie. Czasami uycie kodw
jest porczne choby dlatego, e uatwia zapamitywanie. Dla ich stosowania mona
znale rwnie inne racjonalne argumenty i sensowne powody. Jednak w gotowym
projekcie takie przypadki nie mog zdarza si czsto, a znaczenie kodw powinno by
oczywiste. W przeciwnym razie atwo si pogubimy.
Proces konwersji kodw na wartoci opisowe to zadanie do proste, ale stanowi dodatkow prac. W dokumencie opisujcym dane kody naley poda wraz z ich znaczeniem
uzgodnionym i zatwierdzonym wsplnie przez uytkownikw i projektantw.
Projektanci i uytkownicy powinni rwnie wybra nazwy grup danych. Nazwy te zostan
uyte jako nazwy kolumn w bazie danych i bd regularnie stosowane w zapytaniach, a zatem powinny to by nazwy opisowe (w miar moliwoci bez skrtw, poza powszechnie
stosowanymi) i wyraone w liczbie pojedynczej. Ze wzgldu na bliski zwizek nazwy
kolumny z zapisanymi w niej danymi, oba te elementy naley okreli jednoczenie.
Przemylane nazwy kolumn znacznie upraszczaj identyfikacj charakteru danych.
Dane, ktre nie s kodami, take musz zosta dokadnie przeanalizowane. W tym momencie moemy przyj, e wszystkie zidentyfikowane elementy danych s niezbdne do
wykonania zada biznesowych, cho niekoniecznie s one dobrze zorganizowane. To,
co wyglda na jeden element danych w istniejcym zadaniu, moe w istocie by kilkoma
elementami, ktre wymagaj rozdzielenia. Dane osobowe, adresy, numery telefonw to
popularne przykady takich danych.
Na przykad w tabeli !" imiona byy poczone z nazwiskami. Kolumna $0
*'
zawieraa zarwno imiona, jak i nazwiska, pomimo e tabela zostaa doprowadzona do
trzeciej postaci normalnej. Byby to niezwykle nieudolny sposb zaimplementowania
aplikacji, cho z technicznego punktu widzenia reguy normalizacji zostay zachowane.
Aby aplikacja pozwalaa na formuowanie prostych zapyta, kolumn $0
*'
naley rozdzieli na co najmniej dwie nowe kolumny: i $0
*. Proces wydzielania nowych kategorii, ktry prowadzi do poprawy czytelnoci i wikszej funkcjonalnoci bazy danych, bardzo czsto jest niezaleny od normalizacji.
Stopie dekompozycji zaley od przewidywanego sposobu wykorzystania danych. Istnieje moliwo, e posuniemy si za daleko i wprowadzimy kategorie, ktre cho
skadaj si z oddzielnych elementw, w rzeczywistoci nie tworz dodatkowej wartoci w systemie. Sposb wykonywania dekompozycji zaley od aplikacji i rodzaju danych. Nowym grupom danych, ktre stan si kolumnami, naley dobra odpowiednie
nazwy. Trzeba uwanie przeanalizowa dane, ktre zostan w tych kolumnach zapisane.
Nazwy naley take przypisa danym tekstowym, dla ktrych mona wyrni skoczon liczb wartoci. Nazwy tych kolumn, ich wartoci oraz same kody mona uzna
za tymczasowe.
82
Cz I
Modele danych niepodzielnych

Od tego momentu rozpoczyna si proces normalizacji, a razem z nim rysowanie modeli
danych niepodzielnych. Istnieje wiele dobrych artykuw na ten temat oraz mnstwo
narzdzi analitycznych i projektowych, ktre pozwalaj przyspieszy proces normalizacji, a zatem w tej ksice nie proponujemy jednej metody. Taka propozycja mogaby raczej zaszkodzi, ni pomc.
W modelu naley uwzgldni kad niepodzieln transakcj i oznaczy numerem zadanie, ktrego ta transakcja dotyczy. Naley uwzgldni nazwy tabel, klucze gwne i obce oraz najwaniejsze kolumny. Kadej znormalizowanej relacji naley nada opisow
nazw oraz oszacowa liczb wierszy i transakcji. Kademu modelowi towarzyszy dodatkowy arkusz, w ktrym zapisano nazwy kolumn z typami danych, zakresem wartoci
oraz tymczasowymi nazwami tabel, kolumn oraz danych tekstowych w kolumnach.
Model biznesowy
Dokument opisujcy dane jest teraz poczony z dokumentem opisujcym zadania, tworzc model biznesowy. Projektanci aplikacji i uytkownicy musz wsplnie go przeanalizowa w celu sprawdzenia jego dokadnoci i kompletnoci. W tym momencie
powinni posiada ju jasn wizj przedsiwzicia, realizowanych w nim zada i uywanych danych.
Po wprowadzeniu poprawek oraz zatwierdzeniu modelu biznesowego rozpoczyna si
proces syntezy zada i danych. W tej fazie nastpuje sortowanie danych, przydzielanie
ich do zada, ostateczne zakoczenie normalizacji oraz przypisanie nazw wszystkim
elementom, ktre ich wymagaj.
W przypadku rozbudowanych aplikacji zwykle powstaje do duy rysunek. Docza
si do niego dokumentacj pomocnicz uwzgldniajc zadania, modele danych (z poprawionymi nazwami utworzonymi na podstawie kompletnego modelu), list tabel,
nazw kolumn, typw danych i zawartoci. Jedn z ostatnich czynnoci jest przeledzenie cieek dostpu do danych dla kadej transakcji w penym modelu biznesowym
w celu sprawdzenia, czy wszystkie dane wymagane przez transakcje mona pobiera
lub wprowadza oraz czy nie przetrway zadania wprowadzania danych z brakujcymi
elementami, co mogoby uniemoliwi zachowanie integralnoci referencyjnej modelu.
Z wyjtkiem nadawania nazw poszczeglnym tabelom, kolumnom i danym, wszystkie
czynnoci a do tego momentu byy elementami analizy, a nie fazami projektowania.
Celem tego etapu byo waciwe zrozumienie biznesu i jego komponentw.
Wprowadzanie danych
Model biznesowy koncentruje si raczej na zadaniach, a nie na tabelach danych. Ekrany
aplikacji projektowanej w oparciu o model biznesowy wspomagaj t orientacj, umoliwiajc sprawn obsug zada, a w razie potrzeby przeczanie si midzy nimi. Ekrany
Rozdzia 4.
83
te wygldaj i dziaaj nieco inaczej ni ekrany typowe, odwoujce si do tabel i wystpujce w wielu aplikacjach, ale przyczyniaj si do wzrostu skutecznoci uytkownikw
oraz podnosz jako ich pracy.
W praktyce oznacza to moliwo formuowania zapyta o wartoci umieszczone w tabeli
gwnej dla danego zadania oraz w innych tabelach, aktualizowanych w momencie, kiedy
jest wykonywany dostp do tabeli gwnej. Bywa jednak i tak, e gdy nie okrelono tabeli
gwnej, dane mona pobra z kilku powizanych z sob tabel. Wszystkie one zwracaj
(a w razie potrzeby przyjmuj) dane w czasie wykonywania zadania.
Interakcja pomidzy uytkownikiem a komputerem ma znaczenie kluczowe. Ekrany do
wprowadzania danych i tworzenia zapyta powinny by zorientowane na zadania i pisane
w jzyku naturalnym. Wan rol odgrywaj take ikony i interfejs graficzny. Ekrany
musz by zorganizowane w taki sposb, aby komunikacja odbywaa si jzyku, do jakiego s przyzwyczajeni uytkownicy.
Zapytania i tworzenie raportw

Jedn z podstawowych cech, odrniajcych aplikacje relacyjne i jzyk SQL od aplikacji
tradycyjnych, jest moliwo atwego formuowania indywidualnych zapyta do obiektw
bazy danych oraz tworzenia wasnych raportw. Pozwala na to narzdzie SQL*Plus.
Zapytania wpisywane z wiersza polece i otrzymywane t drog raporty nie wchodz
w skad podstawowego zestawu opracowanego przez programist w kodzie aplikacji. Dziki
temu uytkownicy i programici systemu Oracle zyskuj niezwyk kontrol nad danymi.
Uytkownicy mog analizowa informacje, modyfikowa zapytania i wykonywa je w cigu kilku minut oraz tworzy raporty. Programici s zwolnieni z niemiego obowizku
tworzenia nowych raportw.
Uytkownicy maj moliwo wgldu w dane, przeprowadzenia szczegowej ich analizy
i reagowania z szybkoci i dokadnoci, jakie jeszcze kilka lat temu byy nieosigalne.
Wydajno aplikacji znacznie wzrasta, jeli nazwy tabel, kolumn i wartoci danych s opisowe, spada natomiast, jeli w projekcie przyjto z konwencj nazw oraz uyto kodw
i skrtw. Czas powicony na spjne, opisowe nazwanie obiektw w fazie projektowania opaci si. Z pewnoci uytkownicy szybko odczuj korzyci z tego powodu.
Niektrzy projektanci, szczeglnie ci niemajcy dowiadczenia w tworzeniu duych aplikacji z wykorzystaniem relacyjnych baz danych, obawiaj si, e kiepsko przygotowani
uytkownicy bd pisa nieefektywne zapytania zuywajce olbrzymi liczb cykli
procesora, co spowoduje spowolnienie pracy komputera. Dowiadczenie pokazuje, e
z reguy nie jest to prawda. Uytkownicy szybko si ucz, jakie zapytania s obsugiwane
sprawnie, a jakie nie. Co wicej, wikszo dostpnych dzi narzdzi, sucych do wyszukiwania danych i tworzenia raportw, pozwala oszacowa ilo czasu, jak zajmie wykonanie zapytania, oraz ograniczy dostp (o okrelonej porze dnia lub gdy na komputerze zaloguje si okrelony uytkownik) do tych zapyta, ktre spowodowayby zuycie
nieproporcjonalnie duej iloci zasobw. W praktyce dania, ktre uytkownicy wpisuj
do wiersza polece, tylko czasami wymykaj si spod kontroli, ale korzyci, jakie z nich
wynikaj, znacznie przekraczaj koszty przetwarzania. Niemal za kadym razem, kiedy
scedujemy na komputery zadania wykonywane dotychczas przez ludzi, osigamy oszczdnoci finansowe.
84
Cz I
Rzeczywistym celem projektowania jest sprecyzowanie i spenienie wymaga uytkownikw biznesowych. Zawsze naley stara si, aby aplikacja bya jak najatwiejsza do
zrozumienia i wykorzystania, nawet kosztem zuycia procesora lub miejsca na dysku.
Nie mona jednak dopuci do tego, aby wewntrzna zoono aplikacji bya tak dua,
e jej pielgnacja i modyfikacja stan si trudne i czasochonne.
Normalizacja nazw obiektw

Najlepsze nazwy to nazwy przyjazne w uytkowaniu: opisowe, czytelne, atwe do zapamitania, objanienia i zastosowania, bez skrtw i kodw. Jeli decydujemy si w nazwach na znaki podkrelenia, stosujmy je w sposb spjny i przemylany. W duych
aplikacjach nazwy tabel, kolumn i danych czsto skadaj si z wielu sw, na przykad

0 lub 4)4 *4. Na kilku nastpnych
stronach zostanie zaprezentowane nieco bardziej rygorystyczne podejcie do nazewnictwa, ktrego celem jest opracowanie formalnego procesu normalizacji nazw obiektw.
Integralno poziom-nazwa
W systemie relacyjnej bazy danych obiekty takie, jak bazy danych, waciciele tabel, tabele, kolumny i wartoci danych, s uporzdkowane hierarchicznie. W przypadku bardzo
duych systemw rne bazy danych mog zosta rozmieszczone w rnych lokalizacjach. Dla potrzeb zwizoci, wysze poziomy zostan na razie zignorowane, ale to, co
tutaj powiemy, ich take dotyczy.
Kady poziom w hierarchii jest zdefiniowany w ramach poziomu znajdujcego si powyej.
Obiektom naley przypisywa nazwy odpowiednie dla danego poziomu i unika stosowania nazw z innych poziomw. Na przykad w tabeli nie moe by dwch kolumn o nazwie $0
*, a konto o nazwie 0 nie moe zawiera dwch tabel o nazwie !".
Nie ma obowizku, aby wszystkie tabele konta 0 miay nazwy niepowtarzalne w caej
bazie danych. Inni waciciele take mog posiada tabele !". Nawet jeli 0 ma
do nich dostp, nie ma moliwoci pomyki, poniewa tabel mona zidentyfikowa w sposb niepowtarzalny, poprzedzajc nazw tabeli prefiksem w postaci imienia jej waciciela, na przykad '05!". Nie byoby spjnoci logicznej, gdyby czci
nazw wszystkich tabel nalecych do Jerzego byo jego imi, jak na przykad %"#!",
%"#11!% itd. Stosowanie takich nazw jest mylce, a poza tym umieszczenie
w nazwie czci nazwy nadrzdnej niepotrzebnie komplikuje nazewnictwo tabel i w efekcie narusza integralno poziom-nazwa.
Zwizoci nigdy nie naley przedkada nad czytelno. Wczanie fragmentw nazw
tabel do nazw kolumn jest z technik, gdy narusza logiczn struktur poziomw oraz
wymagan integralno poziom-nazwa. Jest to take mylce, poniewa wymaga od uytkownikw wyszukiwania nazw kolumn niemal za kadym razem, kiedy pisz zapytania.
Nazwy obiektw musz by niepowtarzalne w obrbie poziomu nadrzdnego, ale uywanie nazw spoza wasnego poziomu obiektu nie powinno by dozwolone.
Rozdzia 4.
85
Obsuga abstrakcyjnych typw danych w systemie Oracle wzmacnia moliwoci tworzenia spjnych nazw atrybutw. Na przykad typ danych o nazwie "% 4!# bdzie charakteryzowa si takimi samymi atrybutami za kadym razem, kiedy zostanie uyty. Kady
atrybut ma zdefiniowan nazw, typ danych i rozmiar, co powoduje, e implementacja
aplikacji w caym przedsibiorstwie stanie si spjniejsza. Jednak wykorzystanie abstrakcyjnych typw danych w ten sposb wymaga:
waciwego zdefiniowania typw danych na pocztku procesu projektowania,

aby unikn koniecznoci pniejszego ich modyfikowania,
spenienia wymaga skadniowych obowizujcych dla abstrakcyjnych typw

danych.
Klucze obce
Jedn z przeszkd stojcych na drodze do stosowania zwizych nazw kolumn jest
wystpowanie obcych kluczy w tabeli. Czasem si zdarza, e kolumna w tabeli, w ktrej
wystpuje klucz obcy, ma t sam nazw, co kolumna klucza obcego w swojej tabeli macierzystej. Nie byoby problemu, gdyby mona byo uy penej nazwy klucza obcego
wraz z nazw tabeli macierzystej (np. 11!%5!').
Aby rozwiza problem z takimi samymi nazwami, trzeba wykona jedno z nastpujcych
dziaa:
opracowa nazw, ktra obejmuje nazw tabeli rdowej klucza obcego,

bez wykorzystywania kropki (np. z uyciem znaku podkrelenia),
opracowa nazw, ktra obejmuje skrt nazwy tabeli rdowej klucza obcego,
opracowa nazw, ktra rni si od nazwy w tabeli rdowej,
zmieni nazw kolumny powodujcej konflikt.
adne z tych dziaa nie jest szczeglnie atrakcyjne, ale jeli zetkniemy si z tego typu
dylematem dotyczcym nazwy, naley wybra jedno z nich.
Nazwy w liczbie pojedynczej

Obszarem niespjnoci powodujcym sporo zamieszania jest liczba gramatyczna nazw
nadawanych obiektom. Czy tabela powinna nosi nazw !", czy !"#? Kolumna ma
mie nazw $0
* czy $0
*?
Najpierw przeanalizujmy kolumny, ktre wystpuj niemal w kadej bazie danych: $0
*,
, , (6
0
i 0
. Czy nie liczc pierwszej kolumny kiedykolwiek zauwaylimy, aby kto uywa tych nazw w liczbie mnogiej? Jest niemal
oczywiste, e nazwy te opisuj zawarto pojedynczego wiersza rekordu. Pomimo e
relacyjne bazy danych przetwarzaj zbiory, podstawow jednostk zbioru jest wiersz,
a zawarto wiersza dobrze opisuj nazwy kolumn w liczbie pojedynczej. Czy formularz do wprowadzania danych osobowych powinien mie tak posta, jak poniej?
;< =99999999999999999999999999999999999999999999999999999999999
*,=9999999999999999999999999999999999999999999999999999999999999
=99999999999999999999999
>?*; =999998
*,
;
=99999
86
Cz I
Czy te nazwy wywietlane na ekranie powinny mie liczb pojedyncz, poniewa

w okrelonym czasie pobieramy jedno nazwisko i jeden adres, ale podczas pisania zapyta
trzeba poinformowa uytkownikw, aby przeksztacili te nazwy na liczb mnog? Konsekwentne stosowanie nazw kolumn w liczbie pojedynczej jest po prostu bardziej intuicyjne.
Jeli nazwy wszystkich obiektw maj t sam liczb, ani programista, ani uytkownik nie
musz zapamitywa dodatkowych regu. Korzyci s oczywiste. Zamy, e zdecydowalimy o tym, e wszystkim obiektom nadamy nazwy w liczbie mnogiej. W tym przypadku
pojawi si rne kocwki w nazwie niemal kadego obiektu. Z kolei w nazwie wielowyrazowej poszczeglne sowa otrzymaj rne kocwki. Jakie korzyci mielibymy
osign z cigego wpisywania tych dodatkowych liter? Czyby tak byo atwiej? Czy
takie nazwy s bardziej zrozumiae? Czy takie nazwy atwiej zapamita? Oczywicie nie.
Z tego powodu najlepiej stosowa nastpujc zasad: dla wszystkich nazw obiektw
zawsze naley uywa liczby pojedynczej. Wyjtkami mog by terminy, ktre s powszechnie stosowane w biznesie, takie jak na przykad *
.
Zwizo
Jak wspomniano wczeniej, zwizoci nigdy nie naley przedkada nad czytelno, ale
w przypadku dwch jednakowo treciwych, rwnie atwych do zapamitania i opisowych
nazw zawsze naley wybra krtsz. W czasie projektowania aplikacji warto zaproponowa alternatywne nazwy kolumn i tabel grupie uytkownikw i programistw i wykorzysta
ich rady w celu wybrania tych propozycji, ktre s czytelniejsze. W jaki sposb tworzy
list alternatyw? Mona skorzysta z tezaurusa i sownika. W zespole projektowym, zajmujcym si tworzeniem rnych aplikacji, kadego czonka zespou naley wyposay
w tezaurus i sownik, a nastpnie przypomina im o koniecznoci uwanego nadawania
nazw obiektom.
Obiekt o nazwie tezaurus

Relacyjne bazy danych powinny zawiera obiekt o nazwie tezaurus, podobnie jak zawieraj sownik danych. Tezaurus wymusza korzystanie z firmowych standardw nazewniczych i zapewnia spjne stosowanie nazw i skrtw (jeli s uywane). Takie standardy
czasami wymagaj uywania (rwnie spjnego i konsekwentnego!) znakw podkrelenia, co uatwia identyfikacj poszczeglnych elementw zoonej nazwy.
W agencjach rzdowych lub duych firmach wprowadzono standardy nazewnictwa
obiektw. Standardy obowizujce w duych organizacjach w cigu lat przenikny do
pozostaej czci komercyjnego rynku i moe si zdarzy, e tworz podstaw standardw nazewnictwa naszej firmy. Mog one na przykad zawiera wskazwki dotyczce
stosowania terminw Korporacja lub Firma. Jeli nie zaadaptowalimy takich standardw
nazewnictwa, w celu zachowania spjnoci naley opracowa wasne normy, ktre
uwzgldniaj zarwno standardy bazowe, jak i wskazwki nakrelone w tym rozdziale.
Rozdzia 4.
87
Inteligentne klucze i wartoci kolumn

Nazwa inteligentne klucze jest niezwykle mylca, poniewa sugeruje, e mamy do czynienia z czym pozytywnym lub godnym uwagi. Trafniejszym okreleniem mgby by
termin klucze przecione. Do tej kategorii czsto zalicza si kody Ksigi Gwnej oraz
kody produktw (dotycz ich wszystkie trudnoci charakterystyczne dla innych kodw).
Trudnoci typowe dla kluczy przecionych dotycz take kolumn niekluczowych, ktre
zawieraj wicej ni jeden element danych.
Typowy przykad przecionego klucza opisano w nastpujcym fragmencie: Pierwszy
znak jest kodem regionu. Kolejne cztery znaki s numerem katalogowym. Ostatnia cyfra
to kod centrum kosztw, o ile nie mamy do czynienia z czci importowan w takiej
sytuacji na kocu liczby umieszcza si znacznik /. Jeli nie jest to element wystpujcy
w duej iloci, wtedy dla numeru katalogowego s wykorzystywane tylko trzy cyfry,
a kod regionu oznacza si symbolem HD.
W dobrym projekcie relacyjnym wyeliminowanie przecionych kluczy i wartoci kolumn ma zasadnicze znaczenie. Zachowanie przecionej struktury stwarza zagroenie
dla relacji tworzonych na jej podstawie (zazwyczaj dotyczy to obcych kluczy w innych
tabelach). Niestety w wielu firmach przecione klucze s wykorzystywane od lat i na
trwae wrosy w jej zadania. Niektre zostay wdroone we wczeniejszych etapach automatyzacji, kiedy uywano baz danych nieobsugujcych kluczy wielokolumnowych. Inne maj podoe historyczne stosowano je po to, aby krtkiemu kodowi nada szersze
znaczenie i obj nim wiksz liczb przypadkw, ni pierwotnie planowano. Z wyeliminowaniem przecionych kluczy mog by trudnoci natury praktycznej, ktre uniemoliwiaj natychmiastowe wykonanie tego zadania. Dlatego tworzenie nowej aplikacji
relacyjnej staje si wwczas trudniejsze.
Rozwizaniem problemu jest utworzenie nowego zestawu kluczy zarwno gwnych,
jak i obcych, ktre w prawidowy sposb normalizuj dane, a nastpnie upewnienie si,
e dostp do tabel jest moliwy wycznie za pomoc tych nowych kluczy. Przecione
klucze s wwczas utrzymywane jako dodatkowe, niepowtarzalne kolumny tabeli. Dostp
do danych za pomoc historycznych metod jest zachowany (np. poprzez wyszukanie
przecionego klucza w zapytaniu), ale jednoczenie promuje si klucze o poprawnej strukturze jako preferowan metod dostpu. Z czasem, przy odpowiednim szkoleniu, uytkownicy przekonaj si do nowych kluczy. Na koniec przecione klucze (lub inne przecione wartoci kolumn) mona po prostu zamieni na wartoci $ lub usun z tabeli.
Jeli nie uda si wyeliminowa przecionych kluczy i wartoci z bazy danych, kontrola
poprawnoci danych, zapewnienie integralnoci danych oraz modyfikowanie struktury
stan si bardzo trudne i kosztowne.
88
Cz I
Przykazania
Omwilimy wszystkie najwaniejsze zagadnienia wydajnego projektowania. Warto teraz
je podsumowa w jednym miejscu, std tytu Przykazania (cho moe lepszy byby tytu
Wskazwki). Znajc te zalecenia, uytkownik moe dokona racjonalnej oceny projektu
i skorzysta z dowiadcze innych osb rozwizujcych podobne problemy.
Celem tego podrozdziau nie jest opisanie cyklu tworzenia oprogramowania, ktry prawdopodobnie wszyscy dobrze znaj, ale raczej udowodnienie twierdzenia, e projektowanie z odpowiedni orientacj powoduje radykaln zmian wygldu i sposobu korzystania z aplikacji. Uwane postpowanie zgodnie z podanymi wskazwkami pozwala na
znaczc popraw wydajnoci i poziomu zadowolenia uytkownikw aplikacji.
Oto dziesi przykaza waciwego projektu:
1. Nie zapominajmy o uytkownikach. Wczajmy ich do zespou projektowego
i uczmy modelu relacyjnego i jzyka SQL.

2. Nazwy tabel, kolumn, kluczy i danych nadawajmy wsplnie z uytkownikami.
Opracujmy tezaurus aplikacji w celu zapewnienia spjnoci nazw.

3. Stosujmy opisowe nazwy w liczbie pojedynczej, ktre maj znaczenie, s atwe
do zapamitania i krtkie. Wykorzystujmy znaki podkrelenia konsekwentnie

lub wcale.
4. Nie mieszajmy poziomw nazw.
5. Unikajmy kodw i skrtw.
6. Wszdzie tam, gdzie to moliwe, uywajmy kluczy majcych znaczenie.
7. Przeprowadmy dekompozycj kluczy przecionych.
8. Podczas analizy i projektowania miejmy na uwadze zadania, a nie tylko dane.
Pamitajmy, e normalizacja nie jest czci projektu.

9. Jak najwicej zada zlecajmy komputerom. Opaca si powici cykle
procesora i miejsce w pamici, aby zyska atwo uytkowania.

10. Nie ulegajmy pokusie szybkiego projektowania. Powimy odpowiedni ilo
czasu na analiz, projekt, testowanie i dostrajanie.

Ten rozdzia celowo poprzedza rozdziay opisujce polecenia i funkcje jeli projekt
jest zy, aplikacja rwnie bdzie dziaaa le, niezalenie od tego, jakich polece uyjemy. Funkcjonalno, wydajno, moliwoci odtwarzania, bezpieczestwo oraz dostpno
trzeba odpowiednio zaplanowa. Dobry plan to gwarancja sukcesu.

Oracle Database 10g. Kompendium Administratora

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Database 10g. Kompendium Administratora

Uploaded by

Copyright:

Available Formats

IDZ DO

Oracle Database 10g.

Ta ksika powinna znale si na biurku kadego,

Najwaniejsze pojcia dotyczce bazy danych ..................... 17

Rozdzia 1. Opcje architektury bazy danych Oracle 10g ...........................................19

Rozdzia 3. Aktualizacja do wersji Oracle 10g .........................................................43

Rozdzia 4. Planowanie aplikacji systemu Oracle

Oracle Database 10g. Kompendium administratora

SQL i SQL*Plus ................................................................. 89

Rozdzia 5. Zasadnicze elementy jzyka SQL ...........................................................91

Rozdzia 6. Podstawowe raporty i polecenia programu SQL*Plus ...........................117

Rozdzia 7. Pobieranie informacji tekstowych i ich modyfikowanie .........................139

Rozdzia 8. Wyszukiwanie z wykorzystaniem wyrae regularnych ..........................165

Rozdzia 9. Operacje z danymi numerycznymi ........................................................179

Rozdzia 10. Daty: kiedy, teraz i rnice ................................................................203

Rozdzia 11. Funkcje konwersji i transformacji ........................................................229

Rozdzia 12. Grupowanie danych ............................................................................241

Rozdzia 13. Kiedy jedno zapytanie zaley od drugiego ............................................255

Rozdzia 14. Zaawansowane moliwoci .................................................................271

Rozdzia 15. Modyfikowanie danych: insert, update, merge i delete .........................287

Rozdzia 17. Tworzenie tabel, perspektyw, indeksw, klastrw i sekwencji

Rozdzia 18. Podstawowe mechanizmy bezpieczestwa systemu Oracle ..................355

Oracle Database 10g. Kompendium administratora

Cz III Wicej ni podstawy ........................................................ 379

Rozdzia 20. Przestrzenie tabel ...............................................................................393

Rozdzia 21. Zastosowanie programu SQL*Loader do adowania danych ..................403

Rozdzia 22. Mechanizm eksportu i importu Data Pump ..........................................419

Rozdzia 23. Zdalny dostp do danych ....................................................................435

Rozdzia 24. Perspektywy zmaterializowane ............................................................449

Rozdzia 26. Tabele zewntrzne ..............................................................................491

Rozdzia 27. Zapytania flashback ...........................................................................505

Rozdzia 28. Operacje flashback tabele i bazy danych .........................................515

Cz IV PL/SQL ........................................................................... 523

Rozdzia 30. Wyzwalacze ........................................................................................545

Rozdzia 31. Procedury, funkcje i pakiety ................................................................565

Oracle Database 10g. Kompendium administratora

Rozdzia 32. Wbudowany dynamiczny SQL i pakiet DBMS_SQL ................................583

Obiektowo-relacyjne bazy danych ..................................... 591

Rozdzia 33. Implementowanie typw, perspektyw obiektowych i metod ..................593

Rozdzia 34. Kolektory (tabele zagniedone i tablice zmienne) ...............................609

Rozdzia 35. Wielkie obiekty (LOB) .........................................................................625

Rozdzia 36. Zaawansowane funkcje obiektowe ......................................................653

Cz VI Jzyk Java w systemie Oracle .......................................... 671

Rozdzia 38. Programowanie z uyciem JDBC ..........................................................691

Rozdzia 39. Procedury skadowane w Javie ............................................................701

Cz VII Klastrowy system Oracle i siatka ..................................... 709

Mechanizm TAF .................................................................................................................. 719

Rozdzia 41. Architektura siatki .............................................................................723

Cz VIII Przewodniki autostopowicza ............................................ 735

Rozdzia 43. Autostopem po dostrajaniu aplikacji i zapyta SQL ..............................799

Rozdzia 44. Analiza przypadkw optymalizacji ........................................................847

Rozdzia 45. Autostopem po serwerze aplikacji Oracle 10g .....................................857

Oracle Database 10g. Kompendium administratora

Usugi portalowe .................................................................................................................. 876

Rozdzia 46. Autostopem po administrowaniu baz danych ......................................897

Rozdzia 47. Autostopem po XML w bazach danych Oracle ......................................935

Cz IX Alfabetyczne zestawienie polece .................................... 951

Najwaniejsze pojcia dotyczce bazy danych

Planowanie aplikacji systemu Oracle....

Najwaniejsze pojcia dotyczce bazy danych

wprowadzanie danych do systemu,

utrzymywanie (przechowywanie) danych,

wyprowadzanie danych i posugiwanie si nimi.

Ta ksika powinna znale si na biurku kadego,

Niespjne stosowanie liczby mnogiej. !%" czy !%"%? 0