Idź do
• Spis treści
• Przykładowy rozdział
• Skorowidz
Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl
© Helion 1991–2011
Katalog książek
Twój koszyk
Cennik i informacje
Czytelnia
Kontakt
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:
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