Idź do

• Spis treści
• Przykładowy rozdział
• Skorowidz

• Katalog online

• Dodaj do koszyka

• Zamów cennik

• Zamów informacje

o nowościach

• Fragmenty książek

online

Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. [phone]
e-mail: [e-mail]

© Helion 1991–2011

Katalog książek

Twój koszyk

Cennik i informacje

Czytelnia

Kontakt

• Zamów drukowany

katalog

Projektowanie hurtowni danych
Wspomaganie zarządzania
relacjami z klientami

Autor: Chris Todman
Tłumaczenie: Paweł Gonera
ISBN: 978-83-246-3225-1
Tytuł oryginału:

Designing A Data Warehouse:

Supporting Customer Relationship Management

Format: 172×245, stron: 296

Umiejętnie zarządzaj informacjami!

• Czym są hurtownie danych?
• Jak je zaprojektować, aby wykorzystać maksimum ich możliwości?
• Jak wydajnie zarządzać relacjami z klientem?

Zastanawiasz się, jak zmaksymalizować zyski czerpane z właściwego zarządzania relacjami
z klientem? Jest to pytanie, które spędza sen z oczu każdemu przedsiębiorcy. Jedną z możliwości
jest wykorzystanie odpowiednio zaprojektowanej hurtowni danych. Projekt takiej bazy danych,
uwzględniającej potrzeby klienta, wymaga nowych technik i metodologii. Jakich?

Na to pytanie odpowiada Chris Todman w książce, którą trzymasz w rękach. Wiodący konsultant
w dziedzinie hurtowni danych przedstawi Ci kompletną metodologię, pozwalającą na zaprojektowanie,
wytworzenie i wdrożenie hurtowni danych pod kątem zarządzania relacjami z klientem. Najpierw
przeczytasz o kilku zagadnieniach teoretycznych, związanych z relacjami z klientem oraz hurtowniami
danych. Potem zapoznasz się z typowymi problemami, aby w rozdziale piątym przejść do
omówienia modelu koncepcyjnego. Dowiesz się, jak obsługiwać okoliczności, identyfikować
zmiany w danych oraz modelować metodą kropki. Kolejne omawiane zagadnienia to model
logiczny i sposoby rozwiązywania problemów wydajnościowych. W rozdziale poświęconym
implementacji fizycznej zobaczysz, jak kontrolować poprawność danych, zarządzać kopiami
zapasowymi oraz aplikacjami CRM. Ponadto nauczysz się zarządzać projektem, przejrzysz
możliwości dostępnego oprogramowania oraz zdobędziesz wiedzę o perspektywach rozwoju.
To wszystko znajdziesz w tej długo oczekiwanej książce, poświęconej hurtowniom danych.

• Zarządzanie relacjami z klientem
• Wartość marki
• Zarządzanie kampaniami i marketing personalizowany
• Budowanie hurtowni danych – komponent ekstrakcji oraz integracji danych
• Baza danych hurtowni – opis encji
• Problemy przy wykorzystywaniu relacyjnych baz danych
• Problemy z obróbką czasu w hurtowniach danych
• Wybór modelu koncepcyjnego
• Modelowanie metodą kropki
• Modelowanie logiczne – schemat, wybór rozwiązania, ograniczenia
• Implementacja fizyczna
• Zarządzanie kopiami zapasowymi
• Aplikacje CRM
• Zarządzanie projektem
• Oprogramowanie
• Przyszłość hurtowni danych

Sprawdź, jak zmaksymalizować zyski poprzez właściwe zarządzanie relacjami z klientem!

Spis treci

Wprowadzenie ..........................................................................................................7

Podzikowania .......................................................................................................11

1. Zarzdzanie relacjami z klientem ........................................................................13

Wymiar biznesowy .......................................................................................................................................13
Cele biznesowe ..............................................................................................................................................15
Strategia biznesowa ......................................................................................................................................16
Warto marki ..............................................................................................................................................17
Zarzdzanie relacjami z klientem ...............................................................................................................18
Podsumowanie ..............................................................................................................................................30

2. Wprowadzenie do hurtowni danych ....................................................................31

Wprowadzenie ..............................................................................................................................................31
Czym jest hurtownia danych? .....................................................................................................................37
Analiza wymiarów ........................................................................................................................................38
Budowanie hurtowni danych ......................................................................................................................41
Problemy zwizane z zastosowaniem relacyjnych baz danych ................................................................58
Podsumowanie ..............................................................................................................................................59

3. Problemy projektowe do rozwizania ..................................................................61

Wielowymiarowe modele danych ...............................................................................................................61
Jak wspiera CRM? ......................................................................................................................................69
Podsumowanie ..............................................................................................................................................79

4. Problemy z obróbk czasu w hurtowniach danych ............................................81

Rola czasu ......................................................................................................................................................81
Problemy zwizane z czasem .......................................................................................................................84
Rejestrowanie zmian ....................................................................................................................................90
Rozwizania problemów z czasem w hurtowniach danych pierwszej generacji ....................................94
Odmienne podejcia ...................................................................................................................................107
Konkluzje z przegldu metod pierwszej generacji ..................................................................................109

4

SPIS TRECI

5. Model koncepcyjny ..............................................................................................111

Wymagania modelu koncepcyjnego .........................................................................................................111
Identyfikowanie zmian w danych .............................................................................................................118
Modelowanie metod kropki ....................................................................................................................119
Warsztaty modelowania metod kropki ..................................................................................................124
Podsumowanie ............................................................................................................................................147

6. Model logiczny ......................................................................................................149

Modelowanie logiczne ...............................................................................................................................150
Implementacja retrospekcji .......................................................................................................................150
Zastosowanie wymiaru czasu ....................................................................................................................157
Schemat logiczny ........................................................................................................................................161
Problemy wydajnociowe ..........................................................................................................................163
Wybór rozwizania .....................................................................................................................................165
Czstotliwo przechwytywania zmian danych ......................................................................................166
Ograniczenia ...............................................................................................................................................167
Weryfikacja i podsumowanie modelu logicznego ...................................................................................171

7. Implementacja fizyczna .......................................................................................173

Architektura hurtowni danych .................................................................................................................173
Aplikacje CRM ...........................................................................................................................................193
Kopia zapasowa danych .............................................................................................................................193
Archiwizacja ...............................................................................................................................................194
Ekstrakcja i adowanie ...............................................................................................................................194
Podsumowanie ............................................................................................................................................197

8. Uzasadnienie biznesowe ......................................................................................199

Podejcie przyrostowe ................................................................................................................................199
Wdroenie ...................................................................................................................................................205
Podsumowanie ............................................................................................................................................207

9. Zarzdzanie projektem ........................................................................................209

Wprowadzenie ............................................................................................................................................209
Co jest dostarczane? ...................................................................................................................................212
Jakie naley zdefiniowa zaoenia i ryzyka? ..........................................................................................213
Jakiego zespou potrzebujemy? .................................................................................................................215
Podsumowanie ............................................................................................................................................226

10. Oprogramowanie ..................................................................................................227

Ekstrakcja, przeksztacanie i adowanie ..................................................................................................228
OLAP ........................................................................................................................................................230
Narzdzia zapyta ......................................................................................................................................232
Wydobywanie danych ................................................................................................................................234
Zarzdzanie kampaniami ..........................................................................................................................238
Personalizacja .............................................................................................................................................240
Narzdzia metadanych ...............................................................................................................................241
Sortowanie ..................................................................................................................................................242

11. Przyszo ..............................................................................................................245

Temporalne bazy danych (rozszerzenia temporalne) .............................................................................246
Rozszerzenia OLAP dla SQL ...................................................................................................................246
Aktywne wsparcie decyzji .........................................................................................................................247

SPIS TRECI

5

Dane zewntrzne ........................................................................................................................................247
Dane niestrukturalizowane .......................................................................................................................248
Agenci wyszukiwania .................................................................................................................................248
Aplikacje obsugujce DSS .......................................................................................................................249

A. Temporalna klasyfikacja danych Klubu Winiarza ..........................................251

B. Model kropki dla Klubu Winiarza .....................................................................255

C. Model logiczny dla Klubu Winiarza ..................................................................269

D. Atrybuty klienta ...................................................................................................275

Atrybuty finansowe ....................................................................................................................................281
Atrybuty zatrudnienia ...............................................................................................................................282
Atrybuty zainteresowa i hobby ...............................................................................................................283

E. Odnoniki ..............................................................................................................287

Skorowidz .............................................................................................................289

9

Zarzdzanie projektem

aden projekt nie moe by ukoczony bez przygotowania odpowiedniego planu! W tym roz-
dziale przedstawi rónice pomidzy projektami tworzenia hurtowni danych a tradycyjnymi
projektami dostarczania oprogramowania. Tumaczy to, dlaczego organizacjom nie udaje si
doprowadzi procesu do koca, jeeli próbuj korzysta wycznie z tradycyjnych metod, zna-
nych z „twardych systemów”. Proces ten musi zosta zmodyfikowany, aby pasowa do „mik-
kich systemów”. Dodatkowo zaprezentuj pen struktur podziau zada (WBS) dla projek-
towania i tworzenia przyrostów hurtowni danych. WBS zawiera ponad 100 elementów, które
musz by zrealizowane w kadym przyrocie.

Wprowadzenie

Odpowiednie zarzdzanie jest czsto kluczem do sukcesu projektu. Kady projekt potrzebuje
kierownika oraz zastosowania pewnej metodologii zarzdzania. Nie ma znaczenia, w jakiego
rodzaju projekt jestemy zaangaowani. Projekty duych fizycznych konstrukcji, jak mosty,
statki czy tunele, równie musz by zarzdzane. Cho czasami kocz si spektakularn klap,
to jednak mamy znacznie wiksze dowiadczenie w budowaniu tego typu struktur ni w bu-
dowaniu duych systemów informatycznych. Budowanie fizycznych struktur ma jedn du
zalet w porównaniu z budowaniem oprogramowania: na wszystkich etapach pracy mona zo-
baczy, co zostao zrobione. Nawet niewyszkolony obserwator moe spojrze na most i okre-
li, w jakiej czci jest on wykonany. To, czy budowane s fundamenty, podpory, czy przso,
jest dosy oczywiste i kady z nas moe zaryzykowa okrelenie iloci pozostaych zada. W przy-
padku oprogramowania tak nie jest. Nawet wykwalifikowany obserwator bdzie mia problem
z okreleniem, jaka cz projektu zostaa zakoczona.

Innym problemem jest poziom zoonoci systemów komputerowych, który jest znacznie

wikszy ni w przypadku innych projektów. Jako przykad wemy odrzutowiec. Projektowanie
i budowanie takiej niesamowitej maszyny jest bardzo wymagajcym zadaniem. Jednak najbar-
dziej zoon czci nie s skrzyda, silnik czy te kadub, ale oprogramowanie sterujce sys-
temami samolotu oraz oprogramowanie, które jest uywane do zarzdzania tymi systemami.
Systemy pozwalaj na kierowanie samolotem i zarzdzanie jego uzbrojeniem oraz dostarczaj
pilotowi informacji, co si dzieje wewntrz i na zewntrz maszyny. Ponadto skrzyda, silnik

210

9. ZARZDZANIE PROJEKTEM

i kadub zostay zaprojektowane z uyciem oprogramowania. Nie moemy zobaczy adnego z tych
elementów, wic nasze podejcie do zarzdzania takim projektem musi by bardziej zoone
ni w przypadku konwencjonalnych przedsiwzi.

Jednym ze sposobów na rozwizanie tego problemu jest poczenie metodologii zarzdza-

nia projektem z metodologi tworzenia oprogramowania uyt w tym projekcie. Istnieje wiele
rónych metodologii tworzenia oprogramowania, ale ostatecznie dziel si one na dwie gówne
kategorie:

x metod wodospadu,
x metod szybkiego tworzenia aplikacji (RAD).

Zagadnienie to byo omówione w rozdziale 1. Moemy oczekiwa, e wikszo Czytelników

tej ksiki zna te metody, wic wyjanienie bdzie krótkie.

Istnieje wiele odmian metody wodospadu, które róni si wyborem gównego komponentu.

Przyjmuje si, e powinny by zastosowane fazy zbierania wymaga, analizy, projektowania,
kodowania, testowania oraz wdraania, które s czsto przedstawiane na diagramie pokazanym
na rysunku 9.1.

Rysunek 9.1. Klasyczna metoda wodospadu

Zasad metody wodospadu jest konieczno zakoczenia tworzenia kadego gównego kompo-

nentu przed rozpoczciem pracy nad nastpnym. Dlatego przed analiz musz by zebrane
wszystkie wymagania, a przed przystpieniem do projektowania niezbdne jest zakoczenie
fazy analizy. Jest to czsto nazywane metod od startu do mety.

WPROWADZENIE

211

Innym wanym zaoeniem metody wodospadu jest to, e zwykle nie cofamy si wicej ni

o jeden krok. Jeeli wic okae si w czasie testowania, e naley zmieni kod, to wykonuje si
iteracje pomidzy kodowaniem i testowaniem a do momentu, gdy kod przejdzie wszystkie
testy. W wiecie rzeczywistym czsto si zdarza, e testowanie wykrywa ze zrozumienie czci
analizy dotyczcej jednego z wymaga.

Czciowe ponowne opracowywanie wymaga, a nastpnie modyfikowanie projektu, kodu

i planu testów jest czasochonne, demoralizujce oraz oczywicie bardzo kosztowne — dlatego
wanie metoda wodospadu nie jest ju polecana. Pomimo tego nadal istnieje ona w rónych
formach jako jedna z gównych metod produkcji oprogramowania. Jest szczególnie czsto wy-
korzystywana przy tworzeniu hurtowni danych, gdzie w niektórych przypadkach jest nadal
sensowna.

Metody RAD dziaaj w oparciu o nieco inne zasady i mog by efektywne dla aplikacji,

które maj nastpujc charakterystyk:

x Interaktywno — funkcje aplikacji s jasno widoczne w interfejsie uytkownika. RAD bazuje

na przyrostowym prototypowaniu aplikacji w cisej wspópracy z uytkownikami. Musz
oni by w stanie w atwy sposób oceni funkcje, gdy zostan im zademonstrowane dziaajce
prototypy.

x Jasno zdefiniowana grupa uytkowników. Jeeli grupa uytkowników nie jest jasno zdefi-

niowana, moe zaistnie niebezpieczestwo skierowania tworzenia aplikacji w zym kierun-
ku lub (co gorsza) nastpi cakowite zignorowanie wanych elementów aplikacji.

x Brak zoonoci obliczeniowej. Poziom zoonoci obliczeniowej aplikacji jest trudny do okrele-

nia i moe si zmienia w rónych projektach. Jeeli aplikacja wymaga na przykad zoo-
nego modelowania statystycznego, projekt moe zakada dwa podejcia do programowania —
dopasowanie istniejcego, dobrze przetestowanego komponentu modelowania staty-
stycznego lub opracowanie modelu od pocztku. Pierwsze bdzie akceptowalne w projekcie
RAD. Drugie moe by uznane za ryzykowne, o ile nie istnieje moliwo podziau kom-
ponentu na mniejsze lub zapewnienie jego przezroczystoci dla interfejsu uytkownika.

x Jeeli s due, maj moliwo podziau na mniejsze komponenty funkcjonalne. Jeeli system

jest duy, powinien dawa moliwo podziau na mniejsze, atwiejsze do zarzdzania
fragmenty realizujce jasno zdefiniowane funkcje. Elementy te mog by dostarczane eta-
pami lub równolegle. Jednak cz funkcji moe by realizowana z uyciem standardowej
metody wodospadu.

x Ograniczenie czasowe. Musi zosta okrelona data zakoczenia projektu. Jeeli nie jest ona

podana, dosy czsto zdarzaj si polizgi i podstawowa zaleta metody RAD bdzie nie-
wykorzystana.

Cho jest jasna rónica pomidzy metod wodospadu a metod RAD, istnieje jedno pod-

stawowe podobiestwo — obie dotycz tworzenia tradycyjnych aplikacji. Aplikacje zazwyczaj
realizuj zbiór funkcji biznesowych. Oznacza to, e duo mówi si o funkcjach oraz procesach.
Jeeli pomylimy o hurtowni danych, to gdzie wyrónimy funkcj, a gdzie procesy? Oczywicie
istniej pewne procesy, na przykad przetwarzanie VIM, ale hurtownia danych nie realizuje
procesów biznesowych — jej zadaniem jest wspieranie innych aplikacji, na przykad wspoma-
gania decyzji lub zarzdzania kampaniami. W tym sensie hurtownia danych nie jest aplikacj
biznesow. Troch to dziwne, ale ju wczeniej wspominaem, e hurtownie danych s inne.
Musimy wic rozway, w jaki sposób bdziemy je tworzy.

212

9. ZARZDZANIE PROJEKTEM

Co jest dostarczane?

Jednym z elementów, które musz koniecznie by zrealizowane prawidowo w kadym projek-
cie, jest upewnienie si, e klient otrzyma to, czego oczekiwa. W rozdziale 1. przedstawiem
podejcie z uyciem celów biznesowych do ustalenia oczekiwa, ale nadal mog wystpi pro-
blemy w czasie odbioru. Kierownik projektu musi uzyska akceptacj klienta, zanim projekt
bdzie móg by oficjalnie zamknity. To bardzo wane, poniewa firma konsultingowa wa-
nie wtedy otrzymuje patno. Nawet w wewntrznych projektach odbiór jest istotny, gdy
wskazuje on moment, w którym system zosta zaakceptowany. Ten moment jest zawsze przyj-
mowany z du ulg przez osoby zaangaowane w projekt i zwykle jest to okazja do witowa-
nia. Dodatkowo pozwala to przydzieli czonków zespou do nastpnych projektów. Dla nie-
których by moe stanowi to pocztek nastpnego etapu budowy hurtowni danych.

W jaki sposób uzyska kocowy podpis? Wikszo wykwalifikowanych kierowników projektu

uzgadnia list warunków akceptacyjnych, jeszcze zanim przejm odpowiedzialno za projekt.
Jest to jeden z tych trudnych problemów, z którymi musimy sobie poradzi. Czasami zdarza
si, e jeeli hurtownia danych zostaa zbudowana na solidnych podstawach i waciwie obsu-
guje cele biznesowe, to wystarczajcy jest fakt, e hurtownia fizycznie materializuje si na ko-
cu procesu. Zwykle jednak klient wymaga wicej.

Dzieje si tak, poniewa hurtownie danych s inne. Jeeli nie byaby to hurtownia danych,

ale na przykad system przetwarzania zamówie, moglibymy opracowa z klientem zbiór kry-
teriów akceptacyjnych i wykona testy akceptacyjne na zestawie danych testowych. Nastpnie
moemy przetworzy zamówienie, upewni si, e konto klienta jest prawidowo aktualizowa-
ne, e dokument dostawy powoduje wygenerowanie faktury itp. Jest to moliwe, poniewa
wikszo systemów jest ukierunkowana na proces i jestemy w stanie sprawdzi, czy przebiega
on w taki sposób, e uywane przez niego dane zostaj prawidowo przetworzone. W przypad-
ku tworzenia hurtowni danych procesy dotycz tylko pozyskiwania danych z systemów ró-
dowych i ich adowania do hurtowni danych w odpowiedniej postaci. Moemy i powinnimy
zrealizowa kontrol poprawnoci w celu upewnienia si, e wszystkie rekordy, które zostay
pobrane z systemu ródowego, mog by dodane do bazy danych, ale nie wystarczy to do wy-
tworzenia testów akceptacyjnych. To, co jest najwaniejsze, to zawarto hurtowni. Niestety,
kady przypadek bdzie prawdopodobnie inny, ale poniej przedstawi kilka sugestii.

x Powizanie hurtowni danych z jedn z aplikacji. Przykadem moe by system zarzdzania

kampaniami. Moemy uzgodni zbiór kryteriów segmentacji przy wyborze klientów, do
których ma trafi kampania, i zbudowa aplikacj, za której porednictwem system zarz-
dzania kampaniami otrzyma list odpowiednich klientów. Kryterium akceptacji mog
by parametry wyboru tych klientów. Nasi uytkownicy bd w stanie sprawdzi otrzy-
man list.

x Wybranie kilku pyta, które zostay postawione na warsztatach strategii informacyjnej. Jeeli

bdziemy w stanie wykona kilka z tych pyta, udowodni to, e hurtownia danych moe
dostarcza organizacji wartociowych informacji. Naley uwanie wybiera pytania, aby
mogy by zrealizowane przez mechanizmy dostarczane w pierwszych etapach. Nie ma
sensu wykonywa zapyta zwizanych ze zmieniajcymi si okolicznociami klientów, jeeli
dostarczylimy cz dotyczc zachowa przy kupnie wina.

Naley równie zachowa ostrono w przypadku kryteriów akceptacji odnoszcych si do

wydajnoci systemu. Czsto nasi klienci daj zapewnienia sztampowych metryk wydajnoci,
takich jak:

Wszystkie zapytania bd realizowane w czasie poniej 10 sekund.

JAKIE NALEY ZDEFINIOWA ZAOENIA I RYZYKA?

213

Moe to by ogromny problem, poniewa tego typu kryteria akceptacji najprawdopodob-

niej uniemoliwi odbiór kocowy. W adnym razie nie wolno zgadza si na tego typu wa-
runki. Naley wyjani klientowi, e hurtownie danych róni si od konwencjonalnych apli-
kacji. Zazwyczaj rozsdne jest danie, aby aplikacje OLTP odpowiaday niemal natychmiast.
W wikszoci przypadków realizowane przez nie transakcje przebiegaj w nastpujcy sposób:

(1)

wyszukanie jednego rekordu w bazie danych (z uyciem klucza unikatowego),

(2)

zmiana pewnej wartoci,

(3)

zapisanie rekordu.

Jak wszyscy wiedz, tego typu operacje mog by realizowane w mgnieniu oka. Zapytanie

hurtowni danych zwykle musi:

(1)

odczyta miliony rekordów,

(2)

dopasowa je to tysicy innych rekordów z uyciem zczenia,

(3)

wyliczy sumy czciowe,

(4)

zaprezentowa wyniki w czytelnym formacie.

Kady, kto ma pewne dowiadczenie z bazami danych, zawiadczy, e moe to zaj sporo

czasu. Jeeli jest to moliwe, naley unika kryteriów akceptacyjnych bazujcych na wydajno-
ci. Nie oznacza to, e moemy ignorowa problemy wydajnociowe, tylko dlatego, e system
nie bdzie sprawdzany na ich okoliczno.

Powinnimy prezentowa pogld, e odpowiedzi na niektóre pytania s niemoliwe lub

niemal niemoliwe do uzyskania. Jeeli jestemy w stanie otrzyma odpowiedzi na wszystkie
pytania, wskazuje to, e system odniesie sukces. Strojenie wydajnoci jest czym, co mona
zawsze przeprowadzi w póniej, stosujc standardowe metody optymalizacji relacyjnych baz
danych oraz techniki specyficzne dla hurtowni danych, takie jak tabele podsumowa.

Jakie naley zdefiniowa zaoenia i ryzyka?

Kady plan projektu zawiera lub powinien zawiera zaoenia. Na pocztku projektu nigdy nie
wiemy wszystkiego, wic musimy czasami zgadywa. Nazywa si to zaoeniami. Róne projek-
ty wymagaj rónych zaoe, poniewa s realizowane dla rónych klientów. Rónica pomi-
dzy zaoeniem i ryzykiem nie jest jasna w kontekcie planu projektu, poniewa moemy ogra-
nicza ryzyko przez przyjmowanie zaoe. Na przykad moemy uzna za ryzyko moliwo,
e nasz gówny architekt rozwizania zostanie potrcony przez ciarówk, wic ograniczamy
je, zakadajc, e tak si nie stanie. Jeeli wolisz prowadzi rejestr ryzyk, to i tak ten podroz-
dzia nadal jest istotny.

Wymieni teraz zaoenia, jakie powinnimy przyj, planujc projekt hurtowni danych:

x Jako danych. Jeeli projekt zawiera zadanie zwizane z analiz jakoci danych, to jest to

prawidowe postpowanie. Jeli tego zadania nie ma, to musimy polega tylko na twier-
dzeniach klienta, e dane s odpowiedniej jakoci. Dowiadczenie pokazuje, e klienci
czsto przesadzaj z ocen jakoci swoich danych. Zwykle nie jest to próba oszukania nas,
ale po prostu nie wiedz oni, jak niskiej jakoci s ich dane. Przykadem niskiej jakoci
danych s dane z brakami, dane powielone, bdy odwoa itp. Czsto zdarza si, e ist-
nieje kilka baz danych klientów (najgorszym przypadkiem, z jakim si spotkaem,

214

9. ZARZDZANIE PROJEKTEM

byy 23 takie bazy), a kada z nich rozwijaa si w czasie i kada bya stosowana do in-
nych celów. Kada z tych baz danych zawiera ma cz informacji, których potrzebujemy
w hurtowni. Niestety, nigdy nie s one spójne. Nieraz w rónych bazach danych stosuje
si róne systemy kodowania, a identyfikatory klientów w jednym systemie s zupenie
inne ni w pozostaych. Moe nam si wydawa, e jeeli kady system zawiera fragment
ukadanki, wystarczy wykona ogromne zczenie tabel i mamy wszystkie potrzebne in-
formacje. Czasami si to udaje, a czasami nie. Czsto okazuje si, e konieczna bdzie ta-
bela odwzorowa, taka jak pokazana poniej, która pozwoli utrzyma spójno identyfika-
torów klientów w hurtowni danych.

Odwzorowanie identyfikatorów klientów

ID klienta hurtowni char(8)

ID klienta przetwarzania zamówie number(6)

ID klienta sprzeday char(6)

ID klienta ksigowoci char(6)

Podejcie to dziaa, jeeli bdzie istniaa relacja „jeden do jednego” pomidzy systemami,
ale czsto tak nie jest. Baza sprzedawców moe definiowa klientów na rónych pozio-
mach, przez co firmy córki mog by interpretowane jako jednostkowi klienci, natomiast
system ksigowy bdzie zainteresowany tylko klientami, którzy opacaj faktury. Kolej-
nym problemem jest brak spójnoci danych pomidzy poszczególnymi ródami. Adresy
mog by róne, informacje mog by bardziej aktualne w jednych systemach ni w in-
nych itp. Rónice te skadaj si na ogólny problem zwizany z jakoci danych. Nasz
klient rzadko kiedy rozpoznaje te niecisoci. Jeeli nie zarezerwujemy czasu w projek-
cie na analiz danych, to trzeba przyj zaoenia na temat jakoci danych. Niska jako
danych moe w znacznym stopniu wstrzyma realizacj projektu hurtowni danych.

x Dostpno danych. Musimy by w stanie pobiera wszystkie potrzebne nam dane, a cza-

sami moe by to trudne. Przedstawiem ju problem pobrania zmienionych danych przy
okazji opisu problemów temporalnych w rozdziale 4., ale czsto podobne kopoty mog
by z danymi zachowa. Zdarza si, e dane zachowa s dostpne w pewnym momencie
w czasie conocnego przetwarzania wsadowego. W jednym z etapów cyklu przetwarzania
wsadowego odpowiednie dane s umieszczane w pliku, dziki czemu mog by przekaza-
ne do hurtowni danych w celu przetworzenia. Jeeli proces wsadowy nie dostarczy da-
nych z jakiego powodu, to hurtownia nie moe by zaktualizowana. Cho wydaje si to
problemem operacyjnym, a nie programistycznym, to jednak nasz klient moe nie zaak-
ceptowa systemu, który nie zapewnia odpowiedniej dostpnoci danych. Upewnienie si,
e tego typu problemy nie wystpi, jest bardzo trudne. Lepiej doda zaoenie do planu,
w którym odpowiedzialno za terminowe dostarczenie danych spoczywa na kliencie.

x Nocne okno przetwarzania. Jest to problem podobny do poprzedniego. Jestemy odpowie-

dzialni za udostpnianie hurtowni danych przez okrelon cz dnia, na przykad od 8.00 do
20.00. Potrzebujemy pewnej liczby cykli przetwarzania w postaci conocnego okna cza-
sowego, w którym wykonywane jest adowanie danych i przeprowadzane s czynnoci
konserwacyjne. Nie jest to problem, ale czasami zdarzaj si przypadki, w których okno to
staje si bardzo mae. Na przykad na koniec miesica, kwartau, a szczególnie roku firma
musi wykona dodatkowe przetwarzanie danych. Wtedy musimy ustpi miejsca. Ponad-
to gdy pojawi si problemy w „krytycznych dla firmy” operacjach, jeeli pakiety opro-
gramowania musz by odtworzone, co jest poprzedzone dugim procesem odtwarzania

JAKIEGO ZESPOU POTRZEBUJEMY?

215

bazy danych itp., to conocne przetwarzanie wsadowe nachodzi na nasze okno czasowe
i znów musimy zmieci si w krótszym czasie. Tak jak wczeniej, niezwykle trudno jest
zawrze w kodzie zabezpieczenia przed tak sytuacj i najlepsze, co moemy zrobi, to
dopisa zaoenie, e nasze conocne okno przetwarzania musi pozosta otwarte.

x Sponsor biznesu. Niezwykle wane jest, aby w firmie klienta by wysoko postawiony sponsor.

Ta osoba musi „by wacicielem” projektu po stronie klienta. Nie mona nie docenia
wagi tej roli w kocowym sukcesie projektu. Osoba ta musi by entuzjastycznie nastawiona
do projektu oraz mie odpowiednie uprawnienia do samodzielnego podejmowania decyzji.
Sponsor musi by wacicielem projektu przez cay czas jego trwania. Jeeli opuci on
projekt z jakiej przyczyny, stanowi to powane zagroenie dla sukcesu przedsiwzicia.
Nowi sponsorzy, którzy przejmuj projekt w poowie jego trwania, rzadko kiedy rozumiej go
tak dobrze, jak osoba zaangaowana w projekt od pocztku. Warto wic doda zaoenie,
e sponsor projektu po stronie klienta pozostanie ten sam przez cay czas trwania projektu.

x Wiedza na temat systemów ródowych. Jest to kolejny powany problem, szczególnie nie-

bezpieczny, gdy systemy ródowe starzej si oraz gdy byy opracowywane wasnymi si-
ami. Wikszo projektantów i programistów jest ju niedostpna. System moe by roz-
szerzany i dostosowywany przez lata dziaania, a dokumentacja, o ile istnieje, nie jest tak
rygorystycznie aktualizowana. Krótko mówic, nikt nie wie zbyt duo na ten temat. Ist-
niej pewne pliki lub miejsca w cyklu przetwarzania, w których mona uzyska potrzebne
dane, ale nie ma nikogo, kto dostarczy penego opisu pól danych w rekordach. Czasami
zdarza si to równie w cakiem nowych systemach, szczególnie w przypadku duych pa-
kietów oprogramowania. Dowiedzenie si, jak dziaa interesujcy nas system, czsto jest
koszmarem. Dobrym pomysem jest wic zaoenie, e klient moe wskaza osoby, które
w peni rozumiej dane systemy.

Jakiego zespou potrzebujemy?

Aby prawidowo zaplanowa projekt, jego kierownik musi wiedzie, kiedy i jakich zasobów
bdzie potrzebowa. Zacznijmy od nakrelenia struktury zespou produkcji oprogramowania
— rysunek 9.2.

Osoby penice funkcje wymienione na rysunku 9.2 powinny mie nastpujc charaktery-

styk:

x Kierownik projektu. Musi on dobrze radzi sobie z duym poziomem niejednoznacznoci,

niepewnoci i zmiennoci. Projekty hurtowni danych róni si od normalnego procesu
produkcji oprogramowania, poniewa musz by bardziej elastyczne i dostosowywa si
do zmiennych warunków biznesowych; nie s tak dokadnie zdefiniowane, jak bymy te-
go chcieli. Dowiadczony kierownik projektu potrafi dostosowa si do pynnych wyma-
ga projektu hurtowni danych. Kierownicy projektów, którzy przyzwyczaili si do pracy
na podstawie staych zaoe, na przykad dokadnej specyfikacji systemu, uznaj te pro-
jekty za bardzo trudne.

x Konsultant biznesowy. Jest to funkcja krytyczna dla sukcesu projektu. Absolutnie nie mamy tu

na myli konsultanta zarzdzajcego — konsultant biznesowy to osoba, która pomoe kliento-
wi zrozumie zalety CRM i potrafi wyjani, w jaki sposób wszystkie komponenty wspópra-
cuj ze sob w celu wspomagania wdraania strategii CRM. W idealnej sytuacji konsultant
biznesowy powinien dobrze zna rodowisko biznesowe klienta. Osoba ta jest odpowiedzialna
za zbieranie wymaga biznesowych oraz pomoc przy tworzeniu modelu koncepcyjnego.

216

9. ZARZDZANIE PROJEKTEM

Rysunek 9.2. Przykadowa struktura zespou projektowego

x Architekt rozwizania. Osoba ta jest równie kluczowym graczem w zapewnieniu kocowego

sukcesu projektu. Architekt rozwizania specyfikuje komponenty w hurtowni, upew-
niajc si, e wszystkie dobrze do siebie pasuj. Funkcja architekta rozwizania jest naj-
waniejsz funkcj techniczn w projekcie. Jest on odpowiedzialny za zrozumienie wy-
maga i przeksztacenie ich w rozwizanie. Wane jest, aby osoba na tym stanowisku
miaa du wiedz nie tylko na temat integracji systemów, ale równie na temat hurtowni
danych. W projektach CRM tradycyjne techniki hurtowni danych musz by zmodyfi-
kowane w sposób opisany w tej ksice.

x Gówny programista. W wielu aspektach funkcja ta moe by uznawana za dosy podobn

do funkcji kierownika produkcji oprogramowania w tradycyjnych projektach. W hurtowni
danych istnieje wiele niewielkich podprojektów, które dziaaj w niej jednoczenie. Kady
z tych podprojektów jest realizowany przez may zespó zoony z gównego programisty
oraz podlegajcych mu programistów. Zespoy te równolegle tworz proces ekstrakcji i ado-
wania, sam hurtowni danych, jak równie aplikacje, na przykad zarzdzanie kampa-
niami, jak pokazano na rysunku 9.2. Liczba potrzebnych zespoów jest róna w kadym
projekcie, ale dopóki jest stosowane podejcie przyrostowe, nie powinnimy potrzebowa
wicej ni trzy lub cztery mae zespoy. Gdy skoczy si dany etap, moemy przydzieli
zespoom kolejne zadania.

x Administrator bazy danych. Wikszo pracy, jak wykonujemy przy tworzeniu hurtowni

danych, wymaga korzystania z bazy danych. Z tego powodu w naszym projekcie potrze-
bujemy dobrego DBA, który bdzie z nami wspópracowa. Jeeli jest to moliwe, powi-
nien to by administrator z dowiadczeniem w zakresie hurtowni danych. Projekt hurtowni
danych bdzie wykonywany przez jeden z zespoów projektowych, ale powinien on cile
wspópracowa z DBA, którego dobra znajomo hurtowni danych jest bardzo podana.

JAKIEGO ZESPOU POTRZEBUJEMY?

217

Podobnie zespó ekstrakcji i adowania moe skorzysta ze wspópracy z DBA, który ro-
zumie problemy zwizane z adowaniem danych wystpujce w hurtowniach danych.

x Administrator systemu. Jest to ekspert w dziedzinie systemów operacyjnych i infrastruktury.

Osoba ta przydziela odpowiednie prawa dostpu dla komputerów programistów i dba
o rodowisko pracy zespou. Dobrze jest jednak, jeeli moemy polega na kim, kto moe
pomóc przy bardziej technicznych elementach. Konieczne jest skonfigurowanie uycia
procesora oraz pamici w optymalny sposób, a dodatkowo mirrorowania dysków, kon-
trolerów cache itp. Te elementy musz by wykonane w pewnym momencie, gdy przej-
dziemy do dostrajania wydajnoci, wic du zalet jest dysponowanie w zespole kim,
kto potrafi si tym zaj.

Podzia struktury zada w hurtowni danych

W tym podrozdziale przedstawi ogóln struktur podziau danych (WBS) dla projektów hur-
towni danych. Nasz WBS ma sporo powyej 100 elementów i zawiera równie zalenoci po-
midzy elementami. Jest dosy wyczerpujcy, ale jeeli Czytelnik uwaa, e powinien co do
niego doda lub go zmodyfikowa, prosz bardzo!

Przedstawiem WBS w logicznych czciach, przez co niektóre elementy mog nie by na-

tychmiast oczywiste i bd wymaga wyjanienia. Zwrómy uwag na kolumn po lewej stro-
nie w tabeli 9.1, „Etap projektu”. Ten WBS zosta zaprojektowany tak, aby móg obsuy po-
dejcie przyrostowe. Musimy wypeni WBS dla kadego przyrostu naszej hurtowni danych.

Pierwsz cz stanowi model koncepcyjny. W modelu koncepcyjnym dodalimy wszystkie

komponenty, które zidentyfikowalimy w rozdziale na temat modelowania koncepcyjnego.
Zwrómy uwag, e nie ma potrzeby korzystania z techniki modelowania kropki. Ten WBS
nie jest zaleny od adnej metodologii, cho dosy dobrze pasuje do metodologii kropki.

Tabela 9.1. Zadania modelowania koncepcyjnego

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Model koncepcyjny

CM010

Zbieranie wymaga biznesowych

CM020

Tworzenie koncepcyjnego modelu
wielowymiarowego

CM010

CM030

Okrelenie wymaga retrospekcji

CM020

CM040

Okrelenie róde danych

CM020

CM050

Okrelenie przeksztace

CM040

CM060

Okrelenie zalenoci
w zmienionych danych

CM040

CM070

Okrelenie czstotliwoci
i opónie czasowych

CM040

CM080

Tworzenie metadanych

CM040

Retrospekcja, zalenoci zmienionych danych oraz czstotliwoci i opónienia czasowe po-

winny by ju znanymi terminami.

Nastpnym krokiem jest konwersja modelu koncepcyjnego na model logiczny (tabela 9.2).

Jest to opisane w rozdziale 6.

218

9. ZARZDZANIE PROJEKTEM

Tabela 9.2. Zadania modelowania logicznego

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Model logiczny

LM010

Przeksztacanie modelu
koncepcyjnego w logiczny

CM030

LM020

Projektowanie modelu
bezpieczestwa

CM020

LM030

Tworzenie logicznego
modelu danych

LM010

Tworzenie modelu fizycznego jest opisane szczegóowo w rozdziale 7. Wynik z fazy modelu

fizycznego jest zbiorem instrukcji jzyka definicji danych (DDL) wymaganych do utworzenia
wszystkich obiektów hurtowni danych (tabel, indeksów itp.) (tabela 9.3).

Tabela 9.3. Zadania modelowania fizycznego

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Model fizyczny

PM010

Przeksztacanie modelu
logicznego w fizyczny

LM030

PM020

Tworzenie modelu
bezpieczestwa

LM020

PM030

Projektowanie modelu
fizycznego

PM010

PM040

Tworzenie DDL

PM030

Wikszo z kolejnych czci projektu moe by realizowana równolegle z modelowaniem

danych. Modelowanie logiczne i fizyczne bdzie realizowane przez zespó hurtowni danych,
a przechwytywanie danych z systemów ródowych przez zespó ekstrakcji. Wystpuj tu pewne
zalenoci od modelu koncepcyjnego w zakresie metadanych, które bd kieroway zespó eks-
trakcji i adowania do odpowiednich systemów ródowych i skojarzonych z nimi elementów
danych. W tabeli 9.4 wymienione s zadania wymagane w pocztkowym adowaniu wielowymiaro-
wych modeli zachowa. Naley pamita, e adowanie to jest wykonywane tylko raz. W przy-
padku tego typu elementów systemu mona zastosowa mniej rygorystyczne podejcie ni
w odniesieniu do przyrostowych operacji ekstrakcji i adowania.

Zwrómy uwag, e procesy od ID010 do ID120 s powtarzane dla kadej encji.
Nastpny zbiór procesów wydaje si bardzo podobny i w pewnym sensie taki jest. Jednak

istnieje znaczca rónica, poniewa te procesy bd wykorzystywane jako cz gotowego, do-
starczonego systemu i musz by przygotowane z jakoci przemysow. Kady proces powinien
rejestrowa swoje dziaanie w dzienniku systemu. Informacje zapisywane w dzienniku powinny
by oznaczone jako:

x Informacja. Komunikaty informacyjne zawieraj dat i czas rozpoczcia oraz zakoczenia.

Czas realizacji jest kolejn uyteczn informacj, która pozwala administratorowi systemu
na okrelenie najbardziej czasochonnych procesów systemu. Bardzo przydatn informacj jest

JAKIEGO ZESPOU POTRZEBUJEMY?

219

Tabela 9.4. Pocztkowe zadania przechwytywania i adowania danych

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Pocztkowe przechwytywanie i adowanie danych

Dane zachowa

IB010

Proces projektowania ekstrakcji danych

CM040

IB020

Proces tworzenia ekstrakcji danych

IB010

IB030

Proces testowania ekstrakcji danych

IB020

IB040

Projektowanie procesu VIM

CM050

IB050

Tworzenie procesu VIM

IB040

IB060

Testowanie procesu VIM

IB050

IB070

Proces projektowania adowania danych

PM030

IB080

Proces tworzenia adowania danych

IB070

IB090

Proces testowania adowania danych

IB080

IB100

Wykonanie adowania danych faktów

IB090

IB110

Weryfikacja dokadnoci i spójnoci danych

IB100

IB120

Tworzenie metadanych

CM080

Dane okolicznoci i wymiarów

ID010

Proces projektowania ekstrakcji danych

CM040

ID020

Proces tworzenia ekstrakcji danych

ID010

ID030

Proces testowania ekstrakcji danych

ID020

ID040

Projektowanie procesu VIM

CM050

ID050

Tworzenie procesu VIM

ID040

ID060

Testowanie procesu VIM

ID050

ID070

Proces projektowania
adowania danych

Powtórzy
dla kadej
encji

PM030

ID080

Proces tworzenia adowania danych

ID070

ID090

Proces testowania adowania danych

ID080

ID100

Wykonanie adowania wymiarów

ID090

ID110

Weryfikacja dokadnoci i spójnoci danych

ID100

ID120

Tworzenie metadanych

CM080

równie liczba przetworzonych rekordów, a jeeli jest to moliwe, take warto
z przetworzonych rekordów. Pozwala to utworzy pewnego rodzaju zapis ladu przepywu
danych z systemu ródowego do hurtowni i jest nieocenione przy ledzeniu bdów.
Innym dobrym pomysem jest rejestrowanie wpisów do dziennika w czasie dziaania
procesu, a nie na jego kocu. Jeeli proces rutynowo obsuguje miliony rekordów, to
przydatne jest zapisywanie danych do dziennika co 100 000 rekordów. Jednym ze sposobów
na zapewnienie bardziej dynamicznego dziaania jest utworzenie argumentu wykonania
definiujcego czstotliwo zapisu danych do dziennika.

220

9. ZARZDZANIE PROJEKTEM

x Ostrzeenie. Proces powinien dodawa ostrzeenie do pliku dziennika, gdy zostanie wy-

kryte co podejrzanego, ale nie ma powodu, aby natychmiast na to reagowa. Wygenero-
wanie ostrzeenia moe wystpi wskutek odrzucenia rekordu. Czasami zapis w dzienniku
moe by informacyjny, na przykad gdy system jest w 10 procentach peny, w 20 procentach
peny itd. Te komunikaty informacyjne mog by „wypromowane” do ostrzee, jeeli
system plików jest zajty w ponad 60 procentach. W systemie proaktywnym moe to spo-
wodowa wysanie komunikatu do operatora, aby móg on podj dziaania, zanim sytu-
acja stanie si krytyczna.

x Bd. Gdy wystpi bd, proces nie moe dalej dziaa i musi zosta zatrzymany. Gdy na

przykad zostanie zapeniony system plików, to pomimo e proces moe uzyska dostp
do innego systemu, i tak nie moe kontynuowa pracy i musi si zatrzyma. Czasami bdy s
wykrywane od razu, na pocztku, na przykad jeeli proces ustali, e otrzyma plik danych,
które ju wczeniej przetworzy. Bdy zwykle powoduj zatrzymanie systemu i aby móg
dalej pracowa, wymagana jest interwencja.

Gdy wystpi bd, istnieje naturalna pokusa „spróbowania ponownie”. Rozumiemy przez

to ponowne uruchomienie procesu. W odniesieniu do relacyjnych baz danych zwykle polega to
na wycofaniu wszystkich operacji, które zostay wykonane prawidowo, a nastpnie, po rozwi-
zaniu problemu, na ponownym realizowaniu zada. Niestety, w przypadku hurtowni danych
bdziemy musieli przetworzy wiele milionów transakcji. Nierzadko samo wycofanie zmian
zajmuje duo czasu. Zwykle wycofywanie wszystkich transakcji jest niepotrzebne, szczególnie
jeeli po prostu zabrako nam miejsca — co jest bardzo czstym problemem w hurtowniach.
Jeeli przetworzymy poow danych, to w przypadku koniecznoci wycofania zmian i ponow-
nego przetworzenia danych od pocztku zadanie potrwa dwa razy duej, ni pocztkowo ocze-
kiwalimy. Gdy dziaamy w ciasnym serwisowym oknie czasowym, to w efekcie moe to spo-
wodowa, e nie bdziemy mogli rano otworzy hurtowni danych. Naley pamita, e cz
tych procesów moe nawet w normalnych okolicznociach zaj kilka godzin. Warto zastano-
wi si, czy nie mona pozwoli na kontynuowanie procesu. Oznacza to, e cho proces zosta
zatrzymany po wykryciu bdu, to moe by wznowiony po rozwizaniu problemu.

Podobnie jak w przypadku pocztkowego adowania danych, zadania zwizane z cigym

adowaniem wymiarów, od SD010 do SD1100 w tabeli 9.5, musz by powtórzone dla kadej
encji.

Nastpny zbiór zada jest zwizany z aktywowaniem uytkowników. Operacji tu wymie-

nionych nie trzeba objania. Dodatkowo po zdefiniowaniu ról klienta zadania te musz by
wykonywane równolegle z pozostaymi (tabela 9.6).

Nastpn operacj jest zorganizowanie zada administratora hurtowni danych (tabela 9.7).

Obejmuje to definicje ról uytkowników, schematy uytkowników (perspektywy danych uyt-
kowników), jak równie zidentyfikowane tabele podsumowa. Jako naczeln zasad zalecam,
aby wstrzyma tworzenie tabel podsumowa na tym etapie. Powody tego s nastpujce:

(1)

Ich tworzenie powoduje opónienie momentu, w którym mona udostpni system uyt-

kownikom. Dosy czsto proces sumowania pochania znaczn cz zada programowa-
nia. Kada odpowied, do której sformuowania byy uyte tabele na poziomie podsumo-
wa, moe by równie utworzona na podstawie tabeli szczegóów, poniewa tabele
podsumowa pobieraj swoje dane ze szczegóów. Jest to wycznie kwestia wydajnoci.
Cakowicie akceptowane jest najpierw udostpnienie systemu uytkownikom, a dopiero
póniej utworzenie mechanizmów poprawiajcych wydajno.

JAKIEGO ZESPOU POTRZEBUJEMY?

221

Tabela 9.5. Cige zadania przechwytywania i adowania danych

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Cige przechwytywanie i adowanie danych

Dane zachowa

SB010

Identyfikacja punktu przechwycenia w cyklu
ycia encji

CM040

SB020

Proces projektowania ekstrakcji danych

CM040

SB030

Proces tworzenia ekstrakcji danych

SB020

SB040

Proces testowania ekstrakcji danych

SB030

SB050

Projektowanie procesu VIM

CM050

SB060

Tworzenie procesu VIM

SB050

SB070

Testowanie procesu VIM

Powtórzy
dla kadej
encji

SB060

SB080

Proces projektowania adowania danych

PM030

SB090

Proces tworzenia adowania danych

SB080

SB100

Proces testowania adowania danych

SB090

Dane okolicznoci i wymiarów

SD010

Identyfikowanie zmienionych danych

CM040

SD020

Tworzenie pocze zalenoci

CM060

SD030

Proces projektowania ekstrakcji danych

CM040

SD040

Proces tworzenia ekstrakcji danych

SD030

SD050

Proces testowania ekstrakcji
danych

SD040

SD060

Projektowanie procesu VIM

CM050

SD070

Tworzenie procesu VIM

Powtórzy
dla kadej
encji

SD060

SD080

Testowanie procesu VIM

SD070

SD090

Proces projektowania adowania danych

PM030

SD100

Proces tworzenia adowania danych

SD090

SD110

Proces testowania adowania danych

SD100

Tabela 9.6. Zadania dostpu uytkowników

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Dostp uytkowników

UA010

Przydzia uytkowników do ról

WA010

UA020

Rejestrowanie uytkowników

UA010

UA030

Konfigurowanie oprogramowania
uytkowników

UA040

Testowanie dostpu uytkowników

UA030

UA050

Projektowanie podrcznika
uytkownika

UA030

222

9. ZARZDZANIE PROJEKTEM

Tabela 9.6. Zadania dostpu uytkowników — cig dalszy

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Dostp uytkowników

UA060

Tworzenie podrcznika uytkownika

UA050

UA070

Projektowanie pomocy dla procesów

UA030

UA080

Tworzenie pomocy dla procesów

UA070

UA090

Testowanie pomocy dla procesów

UA080

Tabela 9.7. Zadania administrowania zadaniami przetwarzania w hurtowni danych

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Administrowanie hurtowni danych

WA010

Definiowanie ról uytkowników

LM020

WA020

Odwzorowanie modelu
bezpieczestwa na role

WA010

WA030

Projektowanie schematów uytkownika WA020

WA040

Tworzenie schematów uytkownika

WA030

WA050

Testowanie schematów uytkownika

WA040

WA060

Projektowanie procesu sumowania
danych

PM030

WA070

Tworzenie procesu sumowania danych

WA060

WA080

Testowanie procesu sumowania danych WA070

WA090

Projektowanie procesu sumowania
danych nawigacji

WA060

WA100

Tworzenie procesu sumowania
danych nawigacji

WA090

WA110

Testowanie procesu sumowania
danych nawigacji

WA100

(2)

Udostpnienie uytkownikom danych moliwie szybko ma równie inne praktyczne zalety.

Moemy obserwowa ich wykorzystanie i uycie tej wiedzy do okrelenia, które tabele
podsumowa powinnimy zainstalowa. W projektach hurtowni danych czsto si zdarza,
e tabele podsumowa musz by przeanalizowane dwukrotnie. Bywa, e trafiamy za
pierwszym razem, ale czasami si mylimy i niektóre z naszych podsumowa nie s nigdy
wykorzystywane przez uytkowników.

Nastpnym krokiem s zadania automatyzacji (tabela 9.8). Wielu kierowników projektów

bdzie udowadnia, e jest to najwiksze zagroenie przy budowaniu hurtowni danych. Nasze
podejcie przyrostowe przy wszystkich swoich zaletach czsto pogarsza problem. Powoduje
ono, e po pierwszym przyrocie uytkownicy zaczynaj korzysta z danych. Jest to ten mo-
ment, kiedy mog si oni przekona do rozwizania i stwierdzi: „Spójrzcie, naprawd s pew-
ne korzyci ze wszystkich tych danych!”. Gdy to si stanie, nie bd mieli dosy i bd chcieli
wicej — nie tylko modyfikacji tu czy tam — bd chcieli znacznie wicej. Zanim bdziemy
wiedzieli, gdzie jestemy, cz zespoów zostanie zaangaowana do drugiego etapu. Jednak

JAKIEGO ZESPOU POTRZEBUJEMY?

223

Tabela 9.8. Zadania automatyzacji

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Automatyzacja przetwarzania

AP010

Projektowanie procesu automatyzacji

AP020

Tworzenie procesu automatyzacji

AP010

AP030

Testowanie procesu automatyzacji

AP020

AP040

Wykonanie testów integracyjnych

AP030

AP050

Projektowanie podrcznika procedur
operacyjnych

AP010

AP060

Tworzenie podrcznika procedur
operacyjnych

AP050

AP070

Uzyskanie akceptacji operacyjnej

AP060

klient nie wie, e pierwszy etap jest daleki od zakoczenia. Udao si nam tylko pokaza dane,
ale wszyscy bd uwaa, e ju skoczylimy. Uytkownicy nie bd widzieli tego, e aby po-
bra dane z systemów ródowych, przetworzy je i zaadowa do hurtowni danych, trzeba wy-
kona mudn rczn prac. aden z procesów nie zosta jeszcze zintegrowany i systemy jesz-
cze ze sob nie wspópracuj. Musimy wic wróci do pierwszego etapu i zrealizowa procesy
harmonogramu, sterowania, obsugi bdów itd., które s potrzebne, aby zmieni zwyky system
w produkt jakoci przemysowej z mocnymi spawami oraz rubami i nakrtkami zamiast tych
wszystkich sznurków i tamy klejcej.

Jest to powany problem w starej sztuce okrelania oczekiwa. Jeeli pozwolimy, aby si to

wymkno spod naszej kontroli, moemy nigdy jej nie odzyska. Dziay operacyjne danej firmy
nigdy nie zaakceptuj systemu, który nie potrafi samodzielnie sta na wasnych nogach, szcze-
gólnie jeeli jest tak duy i zasobochonny jak hurtownia danych. Za kadym razem musimy
przypomina naszemu klientowi, e to, co widzi, nie jest ukoczonym produktem i e do za-
koczenia pracy potrzeba jeszcze sporo czasu. Istnieje równie pogld, aby nie dawa uytkow-
nikom dostpu do hurtowni danych do momentu zakoczenia pierwszego etapu. Cho niektórzy
podzielaj to twierdzenie, osobicie nadal podtrzymuj opini, e uytkownicy powinni mie
dostp do hurtowni tak szybko, jak jest to moliwe. W kocu s to ich dane, a nie nasze. Silne
zarzdzanie projektem i równie silne zarzdzanie oczekiwaniami s tu kluczem do sukcesu.

Przejdmy teraz do wsparcia. Wsparcie istnieje na kilku poziomach (tabela 9.9). Kady

uytkownik ma specyficzne wymagania. Wystpuj dwa gówne rodzaje wsparcia:

(1)

Wsparcie uytkowników. W tym przypadku polega to na prowadzeniu telefonicznej linii

pomocy lub dziau wsparcia uytkowników, który im pomaga, gdy maj pytania na temat
systemu lub usugi albo kiedy maj problemy.

(2)

Wsparcie systemu. Oczywiste jest, e jako dostawcy systemu musimy wzi pewn odpo-

wiedzialno za jego obsug, co najmniej przez jaki czas. Po tym czasie musi by zapew-
nione dalsze wsparcie. Obejmuje to rutynow konserwacj systemu, w tym aktualizacje
oprogramowania systemowego i aplikacyjnego. Konieczne jest równie wsparcie ogólnej
natury, na przykad przy rozbudowie przestrzeni dyskowej czy te odtwarzaniu systemu
po awarii sprztowej lub programowej.

224

9. ZARZDZANIE PROJEKTEM

Tabela 9.9. Zadania wsparcia uytkowników

Numer etapu projektu Numer WBS

Opis zadania

Zalenoci

Osobodni

Wsparcie uytkowników

US010

Projektowanie procesów wsparcia

US020

Tworzenie procesów wsparcia

US010

US030

Testowanie procesów wsparcia

US020

W zalenoci od klienta zmieniaj si wymagane poziomy wsparcia, jak równie sposoby,

w jakie to wsparcie jest realizowane. Niektóre organizacje maj wasne oddziay pomocy tech-
nicznej, natomiast inne zlecaj te zadania innym firmom. Niezalenie od sytuacji musimy za-
projektowa strategi wsparcia, aby bya ona zgodna z wymaganiami.

Kolejn puapk jest niezapewnienie uytkownikom wsparcia od samego pocztku. Czsto

s to uytkownicy, z którymi warto wspópracowa, poniewa s oni w stanie powiedzie nam
precyzyjnie, czego potrzebuj. Musimy dostarczy im tych mechanizmów, zanim przejm od
nas odpowiedzialno za system. W wielu przypadkach czas i pienidze przeznaczone na pro-
jekt s tracone przez to, e nie zwrócono uwagi na wymagania wsparcia. Jest to nieco podobne
do problemu z automatyzacj, gdy jest pozostawiane nietknite do koca projektu i zwykle
uwaane za jedno z najnudniejszych zada, cho w rzeczywistoci powinien mu by nadany
strategiczny priorytet.

Problem kopii zapasowej i wycofywania przedstawiem ju w rozdziale 7. Warto powtórzy,

e tworzenie kopii zapasowej w hurtowni danych nie jest prostym zadaniem i w uzyskanie
efektywnego rozwizania trzeba woy sporo pracy (tabela 9.10). Wystpuje równie problem
wycofania. W jaki sposób moemy wycofa dane z systemu, gdy nie powinny one wcale trafi
do hurtowni danych?

Tabela 9.10. Zadania kopii zapasowej i odtwarzania

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Kopie bezpieczestwa i odtwarzanie

BR010

Projektowanie procesu tworzenia kopii
zapasowej

BR020

Tworzenie procesu tworzenia kopii
zapasowej

BR010

BR030

Testowanie procesu tworzenia kopii
zapasowej

BR020

BR040

Projektowanie procesu wycofywania danych

BR050

Tworzenie procesu wycofywania danych

BR040

BR060

Testowanie procesu wycofywania danych

BR050

BR070

Projektowanie procesu ponownego
wprowadzania danych

BR080

Tworzenie procesu ponownego
wprowadzania danych

BR070

BR090

Testowanie procesu ponownego
wprowadzania danych

BR080

JAKIEGO ZESPOU POTRZEBUJEMY?

225

Czym jest „ponowne wprowadzanie danych”? Jest to przeciwiestwo wycofywania danych.

Czasami okazuje si, e do hurtowni danych zostay zaadowane nieprawidowe dane. Zwykle
si dowiadujemy o tym, gdy kto z zespou operacyjnego przyjdzie do naszego biura i powie, e
jeden z plików, jaki dostalimy cztery dni temu, by nieprawidowy. Musimy wtedy uy pro-
cedury wycofania w celu usunicia nieprawidowych danych, a nastpnie procedury ponownego
wprowadzenia danych, aby umieci w hurtowni prawidowe dane (nie zapominajmy, e te nowe
dane równie mog by póniej wycofane, jeeli oka si nieprawidowe — to si zdarza).

Aby hurtownia danych moga normalnie dziaa, wikszo rutynowych procesów musi

by wykonywana automatycznie. Wykonywanie procesów oraz ustawianie ich w czasie i okrelanie
zalenoci midzy nimi zwykle realizuje si przez mechanizm harmonogramowania. Harmo-
nogramy maj bardzo róne zestawy dostpnych funkcji, ale wikszo z nich jest dosy zaawanso-
wana. Na przykad moe si zdarzy, e nie chcemy, aby proces ekstrakcji danych by urucha-
miany wczeniej, ni zakoczy si proces tworzenia pliku potrzebnego mu do pracy. Cho plik
ten moe by dostpny, zaómy, o siódmej po poudniu, to jednak nie ma gwarancji, e si tak
stanie. Jeeli o umówionej godzinie plik nie bdzie dostpny, nie moemy uruchomi procesu
ekstrakcji. Harmonogramy mog by konfigurowane tak, aby reagoway na istnienie lub brak
plików, jak równie by rozumiay kody zwracane przez inne procesy, informujce o ich uda-
nym wykonaniu lub bdzie.

Zespó operacyjny nie przejmie odpowiedzialnoci za dziaanie systemu, jeeli nie bdzie wie-

dzia, jak go obsugiwa. Jest to problem podobny do aspektów zwizanych ze wsparciem i automa-
tyzacj; to kolejna znana puapka, nie tylko w projektach hurtowni danych, ale we wszystkich
projektach IT. Tak jak w przypadku zespou wsparcia, zespó operacyjny bdzie mia wasny
zestaw wymaga, czsto spisanych, które musz by spenione przed przekazaniem mu systemu.

Kolejnymi elementami, jakie musimy dostarczy, s monitorowanie i dostrajanie wydajnoci

oraz planowanie pojemnoci. Naley zarezerwowa nieco czasu na tego rodzaju dziaania. Nie
ma sensu, aby dostarcza system, który jednego dnia dziaa doskonale, a w nastpnym zaczyna mu
brakowa pamici, cykli procesora, przestrzeni dyskowych lub pasma sieciowego (tabela 9.11).

Tabela 9.11. Zadania zarzdzania systemem

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Zarzdzanie systemem

SM010

Planowanie

SM020

Szkolenie zespoów operacyjnych

SM030

Monitorowanie wydajnoci

SM040

Planowanie pojemnoci

W tabeli 9.12 wymieniono elementy, które czasami s zapominane lub s tyle razy odka-

dane na póniej, e staj si opónione. Inn puapk jest niedostarczenie uytkownikom mo-
liwie dokadnej specyfikacji. Nie ma znaczenia, jak dobrze jest skonfigurowany serwer ani jak
duo ma dostpnej przestrzeni. Wiele wietnie zaprojektowanych, dobrze skonfigurowanych
i doskonale dziaajcych hurtowni danych zostao wyczonych przez negatywne przyjcie,
spowodowane przez próby wcinicia komponentów uytkownika kocowego do przestarza-
ych komputerów klienckich.

226

9. ZARZDZANIE PROJEKTEM

Tabela 9.12. Zadania instalacji i wdroenia

Numer etapu
projektu

Numer WBS

Opis zadania

Zalenoci

Osobodni

Instalacja i wdroenie

IR010

Przeprowadzenie szkolenia
uytkowników

IR020

Instalowanie komponentów
uytkownika

IR030

Testowanie konfiguracji
oprogramowania uytkowników

UA030

Tabela 9.13 zawiera kilka zada, jakie naley wykona, zanim zespoy programistyczne

rozpoczn swoj prac.

Tabela 9.13. Zadania konfiguracji pocztkowej

Pocztkowe wymagania systemowe

Pozyskanie i zainstalowanie oprogramowania DBMS

Pozyskanie i zainstalowanie oprogramowania dostpu uytkowników

Pozyskanie i zainstalowanie oprogramowania repozytorium metadanych

Pozyskanie i zainstalowanie oprogramowania nawigacji zagregowanej

Pozyskanie i zainstalowanie oprogramowania szybkiego sortowania

Pozyskanie i zainstalowanie systemów kopii zapasowej

Pozyskanie i zainstalowanie serwerów WWW i oprogramowania klienckiego

Pozyskanie i zainstalowanie oprogramowania planowania pojemnoci

Podsumowanie

Musimy kontrolowa postp projektu — w tym rozdziale przedstawiem dokadn struktur
podziau zada wraz z zalenociami, które mog by przystosowane do potrzeb dowolnych
projektów.

Omówiem równie zagadnienie dostarczania oprogramowania. Jest to znany problem w hur-

towniach danych, poniewa ich tworzenie róni si nieco od tworzenia tradycyjnego oprogra-
mowania.

Opisaem te zespó projektowy oraz umiejtnoci wymagane do udanego zrealizowania

projektu hurtowni danych.

Ponadto przeanalizowaem niektóre z puapek zwizanych z jakoci danych i ich dostp-

noci, a take z komunikacj z klientem. Innym problemem jest na przykad potrzeba wspó-
pracy z zespoem operacyjnym oraz pomocy technicznej po stronie klienta.

Mam nadziej, e rozdzia ten bdzie wartociowym przewodnikiem dla kierowników pro-

jektów zaangaowanych w dostarczanie hurtowni danych.

Skorowidz

A

administrator systemu, 217, 220
alert, 247
analiza wymiarów, 38, 39, 59
architektura

EASI, 175, 197, 200
OLAP, Patrz OLAP

architektura systemu, Patrz specyfikacja systemu
archiwizacja, Patrz dane archiwizacja
atrybut

finansowy, 281
gospodarstwa domowego, 275
identyfikujcy, 116
istnienia, 151, 152, 154, 164, 171, 269
klienta, 275
osobisty, 275
zachowania, 278
zainteresowa i hobby, 283
zatrudnienia, 282

C

cele biznesowe, 16
CRM, Patrz zarzdzanie relacjami z klientem
czas

opónienia, 167
prawidowy, 82, 83, 93, 106, 119
rozdzielczo, 114, 119, 146, 168
rozwizania problemów, 94
transakcji, 82, 83, 93, 106, 119, 167
wymiar, 90, 157, 164
znacznik koca, 154
znakowanie, Patrz znakowanie czasem

D

dane

aktualno, 181
archiwizacja, 194
bdne, 179, 181, 220, 229
cykl ycia, 103
czasu, 81
ekstrakcja, 194, 228
integracja, 38, 46, 47, 90
jako, 213, 234
kontrola poprawnoci, Patrz VIM
kopia okolicznoci, 194
kopia zapasowa, 194
kopia zmian, 194
adowanie, 194, 228, 229
niestrukturalizowane, 248
nieulotno, 38
normalizacja, 62
odrzucenie, 177, 178, 179
okolicznoci, 83
operacyjne, 35
przechwytywanie zmian, 166
przeksztacanie, 228, 229
pula, 188, 192, 193
referencyjne, 25, 83
sortowanie, 242
spójno, 181
strategiczne, 35
strukturalizowane, 248
udostpnianie, 222
warto domylna, 177, 182
wycofywanie, 195, 224
wydobywanie, Patrz wydobywanie danych
wymiarów, 96
zachowa, 83, 193, 194
zewntrzne, 247
zmienno w czasie, 38

290

SKOROWIDZ

Database Management System, Patrz system

zarzdzania bazami danych

DBMS, Patrz system zarzdzania bazami danych
DDL, Patrz jzyk definicji danych
Decision Support Systems, Patrz DSS
diagram ERD, 76
diagram stanów, 44
domena, 151
dominacja na rynku produktu, 17, 18
doskonao operacyjna, 18
DSS, 31, 33, 247, 249, Patrz ograniczenia, Patrz zadania

E

encja, 33, 41, 44, 45, 48, 73, 83, 86, 87, 89, 91, 100,

102, 107, 115, 122, 136, 150, 161, 192, 218
referencyjna, 92
zasada integralnoci, Patrz zasada integralnoci

encji

ETL, 228, 229, 249
Extensible Markup Language, Patrz XML

F

fakt, Patrz zdarzenie
First Manhattan Group, 19

G

GCM, Patrz model koncepcyjny

H

hierarchia, 100, 107, 109, 123, 133

dekompozycja, 164

I

indukcja regu, 237
istnienie, 151, 153, 169

atrybuty, Patrz atrybut istnienia
niecige, 165

J

JAD, Patrz warsztat wspólnego tworzenia aplikacji
jzyk definicji danych, 75, 218, 232

K

kampania, 27, 28

jednofazowa, 27, 239
powtarzalna, 28, 239
wielofazowa, 27, 239
zarzdzanie, 238

Kimball Ralph, 95, 97, 103, 157
klient

identyfikacja, 28, 153
identyfikator, 214
lojalno, 22
migracja, 22, 26, 27, 153, 157, 192, 201
okolicznoci, 70, 71, 192
profil, 24, 202
segmentacja, 74, Patrz segmentacja
warto, 26
wymiar, 72, 164
zachowania, 70, 71
zarzdzanie relacjami, Patrz zarzdzanie

relacjami z klientem

klucz

generalizowany, 96
gówny, 96
obcy, 87
produkcyjny, 98
techniczny, 96

kluczowe wskaniki wydajnoci, 112
kolumna kluczy obcych, Patrz klucz obcy
retrospekcja, 114
koncentracja na kliencie, 17
kontrola poprawnoci danych, Patrz VIM
kopia okolicznoci, Patrz dane kopia okolicznoci
kopia zapasowa, 224, Patrz take dane kopia

zapasowa

kopia zmian, Patrz dane kopia zmian

M

margines bdu, 186
marketing

agresywny, 27
defensywny, 27
osobisty, 20
personalizowany, 29

metadane, 54, 122, 136, 137, 140, 141, 143, 176, 181,

183, 193, 228, 241, 258
aktywne, 242
nawigacji, 242
pasywne, 242
przeksztace, 241

metoda

szybkiego tworzenia aplikacji, 199, 210, 211
wodospadu, 14, 199, 210

migracja klientów, Patrz klient migracja
model

fizyczny, 75, 76, 163
GCM, 188
implementacji, Patrz model fizyczny
komponent, 114
koncepcyjny, 75, 76, 79, 95, 113, 119, 147, 149,

161, 200, 217
wymagania, 111

SKOROWIDZ

291

korporacyjny, 84
logiczny, 75, 76, 95, 112, 124, 161, 171, 217

ograniczenia, 167, 168, 169, 170

normalizowany, 64
relacyjny, 42, 48
trzeciej postaci normalnej, 62
wielowymiarowy, 61, 64, 70, 79, 112, 123, 171, 230
wymiarów, 48
zorientowany na klienta, 72

modelowanie

koncepcyjne, 111
metod kropki, 119, 123, 124, 132, 147, 200,

202, 255

modelowanie wymiarów, 42

N

nawigator podsumowa, 54, 55, 56
numer przetwarzania, 196

O

ograniczenie

podwójnego zliczania, 167
spójnoci odwoa, 169
usuwania, 170

okolicznoci, 92, 114, 195

kopia, Patrz dane kopia okolicznoci

OLAP, 230, 246

P

partycjonowanie, 193, 194
personalizacja, 240
pierwsza posta normalna, 62
podejcie wzrastajce, 174, 200
podrcznik systemu, Patrz specyfikacja systemu
posta normalna Boyce-Codda, 62
przetwarzanie analityczne na bieco, Patrz OLAP
przypadkowo, 118
pula danych, Patrz dane pula

R

RAD, Patrz metoda szybkiego tworzenia aplikacji
relacyjna baza danych, 45
relacyjny system zarzdzania baz danych, 31, 32,

45, 81

Relational Database Management System, Patrz

relacyjny system zarzdzania baz danych

retrospekcja, 114, 116, 143, 144, 147, 150, 154, 161,

164, 165, 171, 181, 186, 251
atrybutu, 116
encji, 115
ograniczenia, 169

relacji, 115
warto, 145

ryzyko, 213

S

schemat

gwiazdy, 40, 48, 50, 67, 68, 72, 101, 121, 231
kropki, 121
logiczny, 269
patka niegu, 51, 67, 68, 150, 231

segmentacja, 24, 27

wedug danych skojarzonych, 26
wedug zachowa, 25

sieci neuronowe, 237
silnik wyszukiwania, 248
specyfikacja projektowa, Patrz specyfikacja systemu
specyfikacja systemu, 14
SQL, 32, 45, 49, 54, 58, 59, 88, 104, 232, 246

rozszerzenia temporalne, Patrz TSQL2

Structured Query Language, Patrz SQL
struktura podziau danych, Patrz WSB
system zarzdzania bazami danych, Patrz relacyjny

system zarzdzania baz danych

T

tabela

faktów, 49, 52, 56, 66, 70, 74, 85, 95, 96, 100, 109,

164

podsumowa, 195
wymiarów, 96, 109, 152

tematyczna hurtownia danych, 68
TSQL2, 105

U

uytkownik

aktywowanie, 220
wsparcie, 223

V

VIM, 176, 183, 184, 188, 195, 211, 229, 249

W

warstwa

integracji, 183, Patrz te VIM
kontroli poprawnoci danych, 176, Patrz te

VIM

odwzorowania, 184, Patrz te VIM

warsztat

analizy komponentów, 138
strategii informacyjnej, 125, 126, 127, 138
wspólnego tworzenia aplikacji, 125

292

SKOROWIDZ

warto domylna, Patrz dane warto domylna
warto marki, 17, 18
WBS, 209, 217
wdroenie, 205, 206
wspomaganie podejmowania decyzji, Patrz DSS
wydajno systemu, 163, 212, 225
wydobywanie danych, 57, 205, 234, 237, 238
wykres sieciowy, 236
wymiar, 122, 132, 150, 192

czasu, Patrz czas wymiar
hierarchia, 123, 133
ksztat, 113
powoli zmieniajcy si, 95

X

XML, 248

Z

zachowanie, 113, 131, 195, 234
zadania

strategiczne, 35

zaleno przechodnia, 64
zaoenia, 213
zapytanie SQL, Patrz SQL
zarzdzanie relacjami z klientem, 18, 19, 21, 23, 29,

69, 109, 147, 193, 199, 227, 238, 245

zasada

atrybutów identyfikujcych, 116
integralnoci encji, 62
przyczyny i efektu, 71

zdarzenie, 91, 97, 107, 113, 122, 150
zespó produkcji oprogramowania, 215
zczenie teta, 164
zmiana przypadkowa, Patrz przypadkowo
znakowanie czasem, 103