Idź do

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

• Katalog online

• Dodaj do koszyka

• Zamów cennik

• Zamów informacjeo nowościach

• Fragmenty książekonline

Helion SAul. Kościuszki 1c44-100 Gliwicetel. 32 230 98 63e-mail: helion@helion.pl© Helion 1991–2011

Katalog książek

Twój koszyk

Cennik i informacje

Czytelnia

Kontakt

• Zamów drukowanykatalog

Projektowanie hurtowni danych Wspomaganie zarządzaniarelacjami z klientamiAutor: 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 tre�ci

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

Podzi�kowania .......................................................................................................11

1. Zarz�dzanie relacjami z klientem ........................................................................13Wymiar biznesowy .......................................................................................................................................13Cele biznesowe ..............................................................................................................................................15Strategia biznesowa ......................................................................................................................................16Warto�� marki ..............................................................................................................................................17Zarz�dzanie relacjami z klientem ...............................................................................................................18Podsumowanie ..............................................................................................................................................30

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

3. Problemy projektowe do rozwi�zania ..................................................................61Wielowymiarowe modele danych ...............................................................................................................61Jak wspiera� CRM? ......................................................................................................................................69Podsumowanie ..............................................................................................................................................79

4. Problemy z obróbk� czasu w hurtowniach danych ............................................81Rola czasu ......................................................................................................................................................81Problemy zwi�zane z czasem .......................................................................................................................84Rejestrowanie zmian ....................................................................................................................................90Rozwi�zania problemów z czasem w hurtowniach danych pierwszej generacji ....................................94Odmienne podej�cia ...................................................................................................................................107Konkluzje z przegl�du metod pierwszej generacji ..................................................................................109

4 SPIS TRE�CI

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

6. Model logiczny ......................................................................................................149Modelowanie logiczne ...............................................................................................................................150Implementacja retrospekcji .......................................................................................................................150Zastosowanie wymiaru czasu ....................................................................................................................157Schemat logiczny ........................................................................................................................................161Problemy wydajno�ciowe ..........................................................................................................................163Wybór rozwi�zania .....................................................................................................................................165Cz�stotliwo�� przechwytywania zmian danych ......................................................................................166Ograniczenia ...............................................................................................................................................167Weryfikacja i podsumowanie modelu logicznego ...................................................................................171

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

8. Uzasadnienie biznesowe ......................................................................................199Podej�cie przyrostowe ................................................................................................................................199Wdro�enie ...................................................................................................................................................205Podsumowanie ............................................................................................................................................207

9. Zarz�dzanie projektem ........................................................................................209Wprowadzenie ............................................................................................................................................209Co jest dostarczane? ...................................................................................................................................212Jakie nale�y zdefiniowa� za�o�enia i ryzyka? ..........................................................................................213Jakiego zespo�u potrzebujemy? .................................................................................................................215Podsumowanie ............................................................................................................................................226

10. Oprogramowanie ..................................................................................................227Ekstrakcja, przekszta�canie i �adowanie ..................................................................................................228OLAP ........................................................................................................................................................230Narz�dzia zapyta ......................................................................................................................................232Wydobywanie danych ................................................................................................................................234Zarz�dzanie kampaniami ..........................................................................................................................238Personalizacja .............................................................................................................................................240Narz�dzia metadanych ...............................................................................................................................241Sortowanie ..................................................................................................................................................242

11. Przysz�o�� ..............................................................................................................245Temporalne bazy danych (rozszerzenia temporalne) .............................................................................246Rozszerzenia OLAP dla SQL ...................................................................................................................246Aktywne wsparcie decyzji .........................................................................................................................247

SPIS TRE�CI 5

Dane zewn�trzne ........................................................................................................................................247Dane niestrukturalizowane .......................................................................................................................248Agenci wyszukiwania .................................................................................................................................248Aplikacje obs�uguj�ce 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 ...................................................................................................275Atrybuty finansowe ....................................................................................................................................281Atrybuty zatrudnienia ...............................................................................................................................282Atrybuty zainteresowa i hobby ...............................................................................................................283

E. Odno�niki ..............................................................................................................287

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

9Zarz�dzanie projektem

�aden projekt nie mo�e by� ukoczony bez przygotowania odpowiedniego planu! W tym roz-dziale przedstawi� ró�nice pomi�dzy projektami tworzenia hurtowni danych a tradycyjnymiprojektami dostarczania oprogramowania. T�umaczy to, dlaczego organizacjom nie udaje si�doprowadzi� procesu do koca, je�eli próbuj� korzysta� wy��cznie z tradycyjnych metod, zna-nych z „twardych systemów”. Proces ten musi zosta� zmodyfikowany, aby pasowa� do „mi�k-kich systemów”. Dodatkowo zaprezentuj� pe�n� struktur� podzia�u zada (WBS) dla projek-towania i tworzenia przyrostów hurtowni danych. WBS zawiera ponad 100 elementów, któremusz� by� zrealizowane w ka�dym przyro�cie.

WprowadzenieOdpowiednie zarz�dzanie jest cz�sto kluczem do sukcesu projektu. Ka�dy projekt potrzebujekierownika oraz zastosowania pewnej metodologii zarz�dzania. Nie ma znaczenia, w jakiegorodzaju projekt jeste�my zaanga�owani. Projekty du�ych fizycznych konstrukcji, jak mosty,statki czy tunele, równie� musz� by� zarz�dzane. Cho� czasami kocz� si� spektakularn� klap�,to jednak mamy znacznie wi�ksze do�wiadczenie w budowaniu tego typu struktur ni� w bu-dowaniu du�ych systemów informatycznych. Budowanie fizycznych struktur ma jedn� du��zalet� w porównaniu z budowaniem oprogramowania: na wszystkich etapach pracy mo�na zo-baczy�, co zosta�o zrobione. Nawet niewyszkolony obserwator mo�e spojrze� na most i okre-�li�, w jakiej cz��ci jest on wykonany. To, czy budowane s� fundamenty, podpory, czy prz�s�o,jest dosy� oczywiste i ka�dy z nas mo�e zaryzykowa� okre�lenie ilo�ci pozosta�ych zada. W przy-padku oprogramowania tak nie jest. Nawet wykwalifikowany obserwator b�dzie mia� problemz okre�leniem, jaka cz��� projektu zosta�a zakoczona.

Innym problemem jest poziom z�o�ono�ci systemów komputerowych, który jest znaczniewi�kszy ni� w przypadku innych projektów. Jako przyk�ad wemy odrzutowiec. Projektowaniei budowanie takiej niesamowitej maszyny jest bardzo wymagaj�cym zadaniem. Jednak najbar-dziej z�o�on� cz��ci� nie s� skrzyd�a, silnik czy te� kad�ub, ale oprogramowanie steruj�ce sys-temami samolotu oraz oprogramowanie, które jest u�ywane do zarz�dzania tymi systemami.Systemy pozwalaj� na kierowanie samolotem i zarz�dzanie jego uzbrojeniem oraz dostarczaj�pilotowi informacji, co si� dzieje wewn�trz i na zewn�trz maszyny. Ponadto skrzyd�a, silnik

210 9. ZARZ DZANIE PROJEKTEM

i kad�ub zosta�y zaprojektowane z u�yciem oprogramowania. Nie mo�emy zobaczy� �adnego z tychelementów, wi�c nasze podej�cie do zarz�dzania takim projektem musi by� bardziej z�o�oneni� w przypadku konwencjonalnych przedsi�wzi��.

Jednym ze sposobów na rozwi�zanie tego problemu jest po��czenie metodologii zarz�dza-nia projektem z metodologi� tworzenia oprogramowania u�yt� w tym projekcie. Istnieje wieleró�nych metodologii tworzenia oprogramowania, ale ostatecznie dziel� si� one na dwie g�ównekategorie:

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

Zagadnienie to by�o omówione w rozdziale 1. Mo�emy oczekiwa�, �e wi�kszo�� Czytelnikówtej ksi��ki zna te metody, wi�c wyja�nienie b�dzie 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 wdra�ania, które s� cz�sto przedstawiane na diagramie pokazanymna rysunku 9.1.

Rysunek 9.1. Klasyczna metoda wodospadu

Zasad� metody wodospadu jest konieczno�� zakoczenia tworzenia ka�dego g�ównego kompo-nentu przed rozpocz�ciem pracy nad nast�pnym. Dlatego przed analiz� musz� by� zebranewszystkie wymagania, a przed przyst�pieniem do projektowania niezb�dne jest zakoczeniefazy analizy. Jest to cz�sto nazywane metod� od startu do mety.

WPROWADZENIE 211

Innym wa�nym za�o�eniem metody wodospadu jest to, �e zwykle nie cofamy si� wi�cej ni�o jeden krok. Je�eli wi�c oka�e si� w czasie testowania, �e nale�y zmieni� kod, to wykonuje si�iteracje pomi�dzy kodowaniem i testowaniem a� do momentu, gdy kod przejdzie wszystkietesty. W �wiecie rzeczywistym cz�sto si� zdarza, �e testowanie wykrywa z�e zrozumienie cz��cianalizy dotycz�cej jednego z wymaga.

Cz��ciowe ponowne opracowywanie wymaga, a nast�pnie modyfikowanie projektu, kodui planu testów jest czasoch�onne, demoralizuj�ce oraz oczywi�cie bardzo kosztowne — dlategow�a�nie metoda wodospadu nie jest ju� polecana. Pomimo tego nadal istnieje ona w ró�nychformach jako jedna z g�ównych metod produkcji oprogramowania. Jest szczególnie cz�sto wy-korzystywana przy tworzeniu hurtowni danych, gdzie w niektórych przypadkach jest nadalsensowna.

Metody RAD dzia�aj� w oparciu o nieco inne zasady i mog� by� efektywne dla aplikacji,które maj� nast�puj�c� charakterystyk�:

� Interaktywno�� — funkcje aplikacji s� jasno widoczne w interfejsie u�ytkownika. RAD bazujena przyrostowym prototypowaniu aplikacji w �cis�ej wspó�pracy z u�ytkownikami. Musz�oni by� w stanie w �atwy sposób oceni� funkcje, gdy zostan� im zademonstrowane dzia�aj�ceprototypy.

� Jasno zdefiniowana grupa u�ytkowników. Je�eli grupa u�ytkowników nie jest jasno zdefi-niowana, mo�e zaistnie� niebezpieczestwo skierowania tworzenia aplikacji w z�ym kierun-ku lub (co gorsza) nast�pi� ca�kowite zignorowanie wa�nych elementów aplikacji.

� Brak z�o�ono�ci obliczeniowej. Poziom z�o�ono�ci obliczeniowej aplikacji jest trudny do okre�le-nia i mo�e si� zmienia� w ró�nych projektach. Je�eli aplikacja wymaga na przyk�ad z�o�o-nego modelowania statystycznego, projekt mo�e zak�ada� dwa podej�cia do programowania —dopasowanie istniej�cego, dobrze przetestowanego komponentu modelowania staty-stycznego lub opracowanie modelu od pocz�tku. Pierwsze b�dzie akceptowalne w projekcieRAD. Drugie mo�e by� uznane za ryzykowne, o ile nie istnieje mo�liwo�� podzia�u kom-ponentu na mniejsze lub zapewnienie jego przezroczysto�ci dla interfejsu u�ytkownika.

� Je�eli s� du�e, maj� mo�liwo�� podzia�u na mniejsze komponenty funkcjonalne. Je�eli systemjest du�y, powinien dawa� mo�liwo�� podzia�u na mniejsze, �atwiejsze do zarz�dzaniafragmenty realizuj�ce jasno zdefiniowane funkcje. Elementy te mog� by� dostarczane eta-pami lub równolegle. Jednak cz��� funkcji mo�e by� realizowana z u�yciem standardowejmetody wodospadu.

� Ograniczenie czasowe. Musi zosta� okre�lona data zakoczenia projektu. Je�eli nie jest onapodana, dosy� cz�sto zdarzaj� si� po�lizgi i podstawowa zaleta metody RAD b�dzie nie-wykorzystana.

Cho� jest jasna ró�nica pomi�dzy metod� wodospadu a metod� RAD, istnieje jedno pod-stawowe podobiestwo — obie dotycz� tworzenia tradycyjnych aplikacji. Aplikacje zazwyczajrealizuj� zbiór funkcji biznesowych. Oznacza to, �e du�o mówi si� o funkcjach oraz procesach.Je�eli pomy�limy o hurtowni danych, to gdzie wyró�nimy funkcj�, a gdzie procesy? Oczywi�cieistniej� pewne procesy, na przyk�ad przetwarzanie VIM, ale hurtownia danych nie realizujeprocesów biznesowych — jej zadaniem jest wspieranie innych aplikacji, na przyk�ad wspoma-gania decyzji lub zarz�dzania kampaniami. W tym sensie hurtownia danych nie jest aplikacj�biznesow�. Troch� to dziwne, ale ju� wcze�niej wspomina�em, �e hurtownie danych s� inne.Musimy wi�c rozwa�y�, w jaki sposób b�dziemy je tworzy�.

212 9. ZARZ DZANIE PROJEKTEM

Co jest dostarczane?Jednym z elementów, które musz� koniecznie by� zrealizowane prawid�owo w ka�dym projek-cie, jest upewnienie si�, �e klient otrzyma to, czego oczekiwa�. W rozdziale 1. przedstawi�empodej�cie z u�yciem celów biznesowych do ustalenia oczekiwa, ale nadal mog� wyst�pi� pro-blemy w czasie odbioru. Kierownik projektu musi uzyska� akceptacj� klienta, zanim projektb�dzie móg� by� oficjalnie zamkni�ty. To bardzo wa�ne, poniewa� firma konsultingowa w�a-�nie wtedy otrzymuje p�atno��. Nawet w wewn�trznych 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 zaanga�owane w projekt i zwykle jest to okazja do �wi�towa-nia. Dodatkowo pozwala to przydzieli� cz�onków zespo�u do nast�pnych projektów. Dla nie-których by� mo�e stanowi to pocz�tek nast�pnego etapu budowy hurtowni danych.

W jaki sposób uzyska� kocowy podpis? Wi�kszo�� wykwalifikowanych kierowników projektuuzgadnia 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 zdarzasi�, �e je�eli hurtownia danych zosta�a zbudowana na solidnych podstawach i w�a�ciwie obs�u-guje cele biznesowe, to wystarczaj�cy jest fakt, �e hurtownia fizycznie materializuje si� na ko-cu procesu. Zwykle jednak klient wymaga wi�cej.

Dzieje si� tak, poniewa� hurtownie danych s� inne. Je�eli nie by�aby to hurtownia danych,ale na przyk�ad system przetwarzania zamówie, mogliby�my opracowa� z klientem zbiór kry-teriów akceptacyjnych i wykona� testy akceptacyjne na zestawie danych testowych. Nast�pniemo�emy przetworzy� zamówienie, upewni� si�, �e konto klienta jest prawid�owo aktualizowa-ne, �e dokument dostawy powoduje wygenerowanie faktury itp. Jest to mo�liwe, poniewa�wi�kszo�� systemów jest ukierunkowana na proces i jeste�my w stanie sprawdzi�, czy przebiegaon w taki sposób, �e u�ywane przez niego dane zostaj� prawid�owo przetworzone. W przypad-ku tworzenia hurtowni danych procesy dotycz� tylko pozyskiwania danych z systemów ró-d�owych i ich �adowania do hurtowni danych w odpowiedniej postaci. Mo�emy i powinni�myzrealizowa� kontrol� poprawno�ci w celu upewnienia si�, �e wszystkie rekordy, które zosta�ypobrane z systemu ród�owego, mog� by� dodane do bazy danych, ale nie wystarczy to do wy-tworzenia testów akceptacyjnych. To, co jest najwa�niejsze, to zawarto�� hurtowni. Niestety,ka�dy przypadek b�dzie prawdopodobnie inny, ale poni�ej przedstawi� kilka sugestii.

� Powi�zanie hurtowni danych z jedn� z aplikacji. Przyk�adem mo�e by� system zarz�dzaniakampaniami. Mo�emy uzgodni� zbiór kryteriów segmentacji przy wyborze klientów, doktórych ma trafi� kampania, i zbudowa� aplikacj�, za której po�rednictwem system zarz�-dzania kampaniami otrzyma list� odpowiednich klientów. Kryterium akceptacji mog�by� parametry wyboru tych klientów. Nasi u�ytkownicy b�d� w stanie sprawdzi� otrzy-man� list�.

� Wybranie kilku pyta�, które zosta�y postawione na warsztatach strategii informacyjnej. Je�elib�dziemy w stanie wykona� kilka z tych pyta, udowodni to, �e hurtownia danych mo�edostarcza� organizacji warto�ciowych informacji. Nale�y uwa�nie wybiera� pytania, abymog�y by� zrealizowane przez mechanizmy dostarczane w pierwszych etapach. Nie masensu wykonywa� zapyta zwi�zanych ze zmieniaj�cymi si� okoliczno�ciami klientów, je�elidostarczyli�my cz��� dotycz�c� zachowa przy kupnie wina.

Nale�y równie� zachowa� ostro�no�� w przypadku kryteriów akceptacji odnosz�cych si� dowydajno�ci systemu. Cz�sto nasi klienci ��daj� zapewnienia sztampowych metryk wydajno�ci,takich jak:

Wszystkie zapytania b�d� realizowane w czasie poni�ej 10 sekund.

JAKIE NALE�Y ZDEFINIOWA� ZA�O�ENIA I RYZYKA? 213

Mo�e to by� ogromny problem, poniewa� tego typu kryteria akceptacji najprawdopodob-niej uniemo�liwi� odbiór kocowy. W �adnym razie nie wolno zgadza� si� na tego typu wa-runki. Nale�y wyja�ni� klientowi, �e hurtownie danych ró�ni� si� od konwencjonalnych apli-kacji. Zazwyczaj rozs�dne jest ��danie, aby aplikacje OLTP odpowiada�y niemal natychmiast.W wi�kszo�ci przypadków realizowane przez nie transakcje przebiegaj� w nast�puj�cy sposób:

(1) wyszukanie jednego rekordu w bazie danych (z u�yciem klucza unikatowego),(2) zmiana pewnej warto�ci,(3) zapisanie rekordu.

Jak wszyscy wiedz�, tego typu operacje mog� by� realizowane w mgnieniu oka. Zapytaniehurtowni danych zwykle musi:

(1) odczyta� miliony rekordów,(2) dopasowa� je to tysi�cy innych rekordów z u�yciem z��czenia,(3) wyliczy� sumy cz��ciowe,(4) zaprezentowa� wyniki w czytelnym formacie.

Ka�dy, kto ma pewne do�wiadczenie z bazami danych, za�wiadczy, �e mo�e to zaj�� sporoczasu. Je�eli jest to mo�liwe, nale�y unika� kryteriów akceptacyjnych bazuj�cych na wydajno-�ci. Nie oznacza to, �e mo�emy ignorowa� problemy wydajno�ciowe, tylko dlatego, �e systemnie b�dzie sprawdzany na ich okoliczno��.

Powinni�my prezentowa� pogl�d, �e odpowiedzi na niektóre pytania s� niemo�liwe lubniemal niemo�liwe do uzyskania. Je�eli jeste�my w stanie otrzyma� odpowiedzi na wszystkiepytania, wskazuje to, �e system odniesie sukces. Strojenie wydajno�ci jest czym�, co mo�nazawsze przeprowadzi� w póniej, stosuj�c standardowe metody optymalizacji relacyjnych bazdanych oraz techniki specyficzne dla hurtowni danych, takie jak tabele podsumowa.

Jakie nale�y zdefiniowa� za�o�enia i ryzyka?Ka�dy plan projektu zawiera lub powinien zawiera� za�o�enia. Na pocz�tku projektu nigdy niewiemy wszystkiego, wi�c musimy czasami zgadywa�. Nazywa si� to za�o�eniami. Ró�ne projek-ty wymagaj� ró�nych za�o�e, poniewa� s� realizowane dla ró�nych klientów. Ró�nica pomi�-dzy za�o�eniem i ryzykiem nie jest jasna w kontek�cie planu projektu, poniewa� mo�emy ogra-nicza� ryzyko przez przyjmowanie za�o�e. Na przyk�ad mo�emy uzna� za ryzyko mo�liwo��,�e nasz g�ówny architekt rozwi�zania zostanie potr�cony przez ci��arówk�, wi�c ograniczamyje, zak�adaj�c, �e tak si� nie stanie. Je�eli wolisz prowadzi� rejestr ryzyk, to i tak ten podroz-dzia� nadal jest istotny.

Wymieni� teraz za�o�enia, jakie powinni�my przyj��, planuj�c projekt hurtowni danych:

� Jako�� danych. Je�eli projekt zawiera zadanie zwi�zane z analiz� jako�ci danych, to jest toprawid�owe post�powanie. Je�li tego zadania nie ma, to musimy polega� tylko na twier-dzeniach klienta, �e dane s� odpowiedniej jako�ci. Do�wiadczenie pokazuje, �e kliencicz�sto przesadzaj� z ocen� jako�ci swoich danych. Zwykle nie jest to próba oszukania nas,ale po prostu nie wiedz� oni, jak niskiej jako�ci s� ich dane. Przyk�adem niskiej jako�cidanych s� dane z brakami, dane powielone, b��dy odwo�a itp. Cz�sto zdarza si�, �e ist-nieje kilka baz danych klientów (najgorszym przypadkiem, z jakim si� spotka�em,

214 9. ZARZ DZANIE PROJEKTEM

by�y 23 takie bazy), a ka�da z nich rozwija�a si� w czasie i ka�da by�a stosowana do in-nych celów. Ka�da z tych baz danych zawiera ma�� cz��� informacji, których potrzebujemyw hurtowni. Niestety, nigdy nie s� one spójne. Nieraz w ró�nych bazach danych stosujesi� ró�ne systemy kodowania, a identyfikatory klientów w jednym systemie s� zupe�nieinne ni� w pozosta�ych. Mo�e nam si� wydawa�, �e je�eli ka�dy system zawiera fragmentuk�adanki, wystarczy wykona� ogromne z��czenie tabel i mamy wszystkie potrzebne in-formacje. Czasami si� to udaje, a czasami nie. Cz�sto okazuje si�, �e konieczna b�dzie ta-bela odwzorowa, taka jak pokazana poni�ej, 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 sprzeda�y char(6)

ID klienta ksi�gowo�ci char(6)

Podej�cie to dzia�a, je�eli b�dzie istnia�a relacja „jeden do jednego” pomi�dzy systemami,ale cz�sto tak nie jest. Baza sprzedawców mo�e definiowa� klientów na ró�nych pozio-mach, przez co firmy córki mog� by� interpretowane jako jednostkowi klienci, natomiastsystem ksi�gowy b�dzie zainteresowany tylko klientami, którzy op�acaj� faktury. Kolej-nym problemem jest brak spójno�ci danych pomi�dzy poszczególnymi ród�ami. Adresymog� by� ró�ne, informacje mog� by� bardziej aktualne w jednych systemach ni� w in-nych itp. Ró�nice te sk�adaj� si� na ogólny problem zwi�zany z jako�ci� danych. Naszklient rzadko kiedy rozpoznaje te nie�cis�o�ci. Je�eli nie zarezerwujemy czasu w projek-cie na analiz� danych, to trzeba przyj�� za�o�enia na temat jako�ci danych. Niska jako��danych mo�e w znacznym stopniu wstrzyma� realizacj� projektu hurtowni danych.

� Dost�pno�� danych. Musimy by� w stanie pobiera� wszystkie potrzebne nam dane, a cza-sami mo�e by� to trudne. Przedstawi�em ju� problem pobrania zmienionych danych przyokazji opisu problemów temporalnych w rozdziale 4., ale cz�sto podobne k�opoty mog�by� z danymi zachowa. Zdarza si�, �e dane zachowa s� dost�pne w pewnym momenciew czasie conocnego przetwarzania wsadowego. W jednym z etapów cyklu przetwarzaniawsadowego odpowiednie dane s� umieszczane w pliku, dzi�ki czemu mog� by� przekaza-ne do hurtowni danych w celu przetworzenia. Je�eli proces wsadowy nie dostarczy da-nych z jakiego� powodu, to hurtownia nie mo�e by� zaktualizowana. Cho� wydaje si� toproblemem operacyjnym, a nie programistycznym, to jednak nasz klient mo�e nie zaak-ceptowa� systemu, który nie zapewnia odpowiedniej dost�pno�ci danych. Upewnienie si�,�e tego typu problemy nie wyst�pi�, jest bardzo trudne. Lepiej doda� za�o�enie do planu,w którym odpowiedzialno�� za terminowe dostarczenie danych spoczywa na kliencie.

� Nocne okno przetwarzania. Jest to problem podobny do poprzedniego. Jeste�my odpowie-dzialni za udost�pnianie hurtowni danych przez okre�lon� cz��� dnia, na przyk�ad od 8.00 do20.00. Potrzebujemy pewnej liczby cykli przetwarzania w postaci conocnego okna cza-sowego, w którym wykonywane jest �adowanie danych i przeprowadzane s� czynno�cikonserwacyjne. Nie jest to problem, ale czasami zdarzaj� si� przypadki, w których okno tostaje si� bardzo ma�e. Na przyk�ad na koniec miesi�ca, kwarta�u, a szczególnie roku firmamusi wykona� dodatkowe przetwarzanie danych. Wtedy musimy ust�pi� miejsca. Ponad-to gdy pojawi� si� problemy w „krytycznych dla firmy” operacjach, je�eli pakiety opro-gramowania musz� by� odtworzone, co jest poprzedzone d�ugim procesem odtwarzania

JAKIEGO ZESPO�U POTRZEBUJEMY? 215

bazy danych itp., to conocne przetwarzanie wsadowe nachodzi na nasze okno czasowei znów musimy zmie�ci� si� w krótszym czasie. Tak jak wcze�niej, niezwykle trudno jestzawrze� w kodzie zabezpieczenia przed tak� sytuacj� i najlepsze, co mo�emy zrobi�, todopisa� za�o�enie, �e nasze conocne okno przetwarzania musi pozosta� otwarte.

� Sponsor biznesu. Niezwykle wa�ne jest, aby w firmie klienta by� wysoko postawiony sponsor.Ta osoba musi „by� w�a�cicielem” projektu po stronie klienta. Nie mo�na nie docenia�wagi tej roli w kocowym sukcesie projektu. Osoba ta musi by� entuzjastycznie nastawionado projektu oraz mie� odpowiednie uprawnienia do samodzielnego podejmowania decyzji.Sponsor musi by� w�a�cicielem projektu przez ca�y czas jego trwania. Je�eli opu�ci onprojekt z jakiej� przyczyny, stanowi to powa�ne zagro�enie dla sukcesu przedsi�wzi�cia.Nowi sponsorzy, którzy przejmuj� projekt w po�owie jego trwania, rzadko kiedy rozumiej� gotak dobrze, jak osoba zaanga�owana w projekt od pocz�tku. Warto wi�c doda� za�o�enie,�e sponsor projektu po stronie klienta pozostanie ten sam przez ca�y czas trwania projektu.

� Wiedza na temat systemów �ród�owych. Jest to kolejny powa�ny problem, szczególnie nie-bezpieczny, gdy systemy ród�owe starzej� si� oraz gdy by�y opracowywane w�asnymi si-�ami. Wi�kszo�� projektantów i programistów jest ju� niedost�pna. System mo�e by� roz-szerzany i dostosowywany przez lata dzia�ania, a dokumentacja, o ile istnieje, nie jest takrygorystycznie aktualizowana. Krótko mówi�c, nikt nie wie zbyt du�o na ten temat. Ist-niej� pewne pliki lub miejsca w cyklu przetwarzania, w których mo�na uzyska� potrzebnedane, ale nie ma nikogo, kto dostarczy pe�nego opisu pól danych w rekordach. Czasamizdarza si� to równie� w ca�kiem nowych systemach, szczególnie w przypadku du�ych pa-kietów oprogramowania. Dowiedzenie si�, jak dzia�a interesuj�cy nas system, cz�sto jestkoszmarem. Dobrym pomys�em jest wi�c za�o�enie, �e klient mo�e wskaza� osoby, którew pe�ni rozumiej� dane systemy.

Jakiego zespo�u potrzebujemy?Aby prawid�owo zaplanowa� projekt, jego kierownik musi wiedzie�, kiedy i jakich zasobówb�dzie potrzebowa�. Zacznijmy od nakre�lenia struktury zespo�u produkcji oprogramowania— rysunek 9.2.

Osoby pe�ni�ce funkcje wymienione na rysunku 9.2 powinny mie� nast�puj�c� charaktery-styk�:

� Kierownik projektu. Musi on dobrze radzi� sobie z du�ym poziomem niejednoznaczno�ci,niepewno�ci i zmienno�ci. Projekty hurtowni danych ró�ni� si� od normalnego procesuprodukcji oprogramowania, poniewa� musz� by� bardziej elastyczne i dostosowywa� si�do zmiennych warunków biznesowych; nie s� tak dok�adnie zdefiniowane, jak by�my te-go chcieli. Do�wiadczony kierownik projektu potrafi dostosowa� si� do p�ynnych wyma-ga projektu hurtowni danych. Kierownicy projektów, którzy przyzwyczaili si� do pracyna podstawie sta�ych za�o�e, na przyk�ad dok�adnej specyfikacji systemu, uznaj� te pro-jekty za bardzo trudne.

� Konsultant biznesowy. Jest to funkcja krytyczna dla sukcesu projektu. Absolutnie nie mamy tuna my�li konsultanta zarz�dzaj�cego — konsultant biznesowy to osoba, która pomo�e kliento-wi zrozumie� zalety CRM i potrafi wyja�ni�, w jaki sposób wszystkie komponenty wspó�pra-cuj� ze sob� w celu wspomagania wdra�ania strategii CRM. W idealnej sytuacji konsultantbiznesowy powinien dobrze zna� �rodowisko biznesowe klienta. Osoba ta jest odpowiedzialnaza zbieranie wymaga biznesowych oraz pomoc przy tworzeniu modelu koncepcyjnego.

216 9. ZARZ DZANIE PROJEKTEM

Rysunek 9.2. Przyk�adowa struktura zespo�u projektowego

� Architekt rozwi�zania. Osoba ta jest równie� kluczowym graczem w zapewnieniu kocowegosukcesu projektu. Architekt rozwi�zania specyfikuje komponenty w hurtowni, upew-niaj�c si�, �e wszystkie dobrze do siebie pasuj�. Funkcja architekta rozwi�zania jest naj-wa�niejsz� funkcj� techniczn� w projekcie. Jest on odpowiedzialny za zrozumienie wy-maga i przekszta�cenie ich w rozwi�zanie. Wa�ne jest, aby osoba na tym stanowiskumia�a du�� wiedz� nie tylko na temat integracji systemów, ale równie� na temat hurtownidanych. W projektach CRM tradycyjne techniki hurtowni danych musz� by� zmodyfi-kowane w sposób opisany w tej ksi��ce.

� G�ówny programista. W wielu aspektach funkcja ta mo�e by� uznawana za dosy� podobn�do funkcji kierownika produkcji oprogramowania w tradycyjnych projektach. W hurtownidanych istnieje wiele niewielkich podprojektów, które dzia�aj� w niej jednocze�nie. Ka�dyz tych podprojektów jest realizowany przez ma�y zespó� z�o�ony z g�ównego programistyoraz podlegaj�cych mu programistów. Zespo�y te równolegle tworz� proces ekstrakcji i �ado-wania, sam� hurtowni� danych, jak równie� aplikacje, na przyk�ad zarz�dzanie kampa-niami, jak pokazano na rysunku 9.2. Liczba potrzebnych zespo�ów jest ró�na w ka�dymprojekcie, ale dopóki jest stosowane podej�cie przyrostowe, nie powinni�my potrzebowa�wi�cej ni� trzy lub cztery ma�e zespo�y. Gdy skoczy si� dany etap, mo�emy przydzieli�zespo�om kolejne zadania.

� Administrator bazy danych. Wi�kszo�� pracy, jak� wykonujemy przy tworzeniu hurtownidanych, wymaga korzystania z bazy danych. Z tego powodu w naszym projekcie potrze-bujemy dobrego DBA, który b�dzie z nami wspó�pracowa�. Je�eli jest to mo�liwe, powi-nien to by� administrator z do�wiadczeniem w zakresie hurtowni danych. Projekt hurtownidanych b�dzie wykonywany przez jeden z zespo�ów projektowych, ale powinien on �ci�lewspó�pracowa� z DBA, którego dobra znajomo�� hurtowni danych jest bardzo po��dana.

JAKIEGO ZESPO�U POTRZEBUJEMY? 217

Podobnie zespó� ekstrakcji i �adowania mo�e skorzysta� ze wspó�pracy z DBA, który ro-zumie problemy zwi�zane z �adowaniem danych wyst�puj�ce w hurtowniach danych.

� Administrator systemu. Jest to ekspert w dziedzinie systemów operacyjnych i infrastruktury.Osoba ta przydziela odpowiednie prawa dost�pu dla komputerów programistów i dbao �rodowisko pracy zespo�u. Dobrze jest jednak, je�eli mo�emy polega� na kim�, kto mo�epomóc przy bardziej technicznych elementach. Konieczne jest skonfigurowanie u�yciaprocesora oraz pami�ci 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 wydajno�ci, wi�c du�� zalet� jest dysponowanie w zespole kim�,kto potrafi si� tym zaj��.

Podzia� struktury zada w hurtowni danychW tym podrozdziale przedstawi� ogóln� struktur� podzia�u danych (WBS) dla projektów hur-towni danych. Nasz WBS ma sporo powy�ej 100 elementów i zawiera równie� zale�no�ci po-mi�dzy elementami. Jest dosy� wyczerpuj�cy, ale je�eli Czytelnik uwa�a, �e powinien co� doniego doda� lub go zmodyfikowa�, prosz� bardzo!

Przedstawi�em WBS w logicznych cz��ciach, przez co niektóre elementy mog� nie by� na-tychmiast oczywiste i b�d� wymaga� wyja�nienia. Zwró�my uwag� na kolumn� po lewej stro-nie w tabeli 9.1, „Etap projektu”. Ten WBS zosta� zaprojektowany tak, aby móg� obs�u�y� po-dej�cie przyrostowe. Musimy wype�ni� WBS dla ka�dego przyrostu naszej hurtowni danych.

Pierwsz� cz��� stanowi model koncepcyjny. W modelu koncepcyjnym dodali�my wszystkiekomponenty, które zidentyfikowali�my w rozdziale na temat modelowania koncepcyjnego.Zwró�my uwag�, �e nie ma potrzeby korzystania z techniki modelowania kropki. Ten WBSnie jest zale�ny od �adnej metodologii, cho� dosy� dobrze pasuje do metodologii kropki.

Tabela 9.1. Zadania modelowania koncepcyjnego

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Model koncepcyjny

CM010 Zbieranie wymaga biznesowych

CM020 Tworzenie koncepcyjnego modeluwielowymiarowego

CM010

CM030 Okre�lenie wymaga retrospekcji CM020

CM040 Okre�lenie róde� danych CM020

CM050 Okre�lenie przekszta�ce CM040

CM060 Okre�lenie zale�no�ciw zmienionych danych

CM040

CM070 Okre�lenie cz�stotliwo�cii opónie czasowych

CM040

CM080 Tworzenie metadanych CM040

Retrospekcja, zale�no�ci zmienionych danych oraz cz�stotliwo�ci i opónienia czasowe po-winny by� ju� znanymi terminami.

Nast�pnym krokiem jest konwersja modelu koncepcyjnego na model logiczny (tabela 9.2).Jest to opisane w rozdziale 6.

218 9. ZARZ DZANIE PROJEKTEM

Tabela 9.2. Zadania modelowania logicznego

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Model logiczny

LM010 Przekszta�canie modelukoncepcyjnego w logiczny

CM030

LM020 Projektowanie modelubezpieczestwa

CM020

LM030 Tworzenie logicznegomodelu danych

LM010

Tworzenie modelu fizycznego jest opisane szczegó�owo w rozdziale 7. Wynik z fazy modelufizycznego jest zbiorem instrukcji j�zyka definicji danych (DDL) wymaganych do utworzeniawszystkich obiektów hurtowni danych (tabel, indeksów itp.) (tabela 9.3).

Tabela 9.3. Zadania modelowania fizycznego

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Model fizyczny

PM010 Przekszta�canie modelulogicznego w fizyczny

LM030

PM020 Tworzenie modelubezpieczestwa

LM020

PM030 Projektowanie modelufizycznego

PM010

PM040 Tworzenie DDL PM030

Wi�kszo�� z kolejnych cz��ci projektu mo�e by� realizowana równolegle z modelowaniemdanych. Modelowanie logiczne i fizyczne b�dzie realizowane przez zespó� hurtowni danych,a przechwytywanie danych z systemów ród�owych przez zespó� ekstrakcji. Wyst�puj� tu pewnezale�no�ci od modelu koncepcyjnego w zakresie metadanych, które b�d� kierowa�y zespó� eks-trakcji i �adowania do odpowiednich systemów ród�owych i skojarzonych z nimi elementówdanych. W tabeli 9.4 wymienione s� zadania wymagane w pocz�tkowym �adowaniu wielowymiaro-wych modeli zachowa. Nale�y pami�ta�, �e �adowanie to jest wykonywane tylko raz. W przy-padku tego typu elementów systemu mo�na zastosowa� mniej rygorystyczne podej�cie ni�w odniesieniu do przyrostowych operacji ekstrakcji i �adowania.

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

istnieje znacz�ca ró�nica, poniewa� te procesy b�d� wykorzystywane jako cz��� gotowego, do-starczonego systemu i musz� by� przygotowane z jako�ci� przemys�ow�. Ka�dy proces powinienrejestrowa� swoje dzia�anie w dzienniku systemu. Informacje zapisywane w dzienniku powinnyby� oznaczone jako:� Informacja. Komunikaty informacyjne zawieraj� dat� i czas rozpocz�cia oraz zakoczenia.

Czas realizacji jest kolejn� u�yteczn� informacj�, która pozwala administratorowi systemuna okre�lenie najbardziej czasoch�onnych procesów systemu. Bardzo przydatn� informacj� jest

JAKIEGO ZESPO�U POTRZEBUJEMY? 219

Tabela 9.4. Pocz�tkowe zadania przechwytywania i �adowania danych

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Pocz�tkowe 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 dok�adno�ci i spójno�ci danych IB100

IB120 Tworzenie metadanych CM080

Dane okoliczno�ci 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 ka�dejencji

PM030

ID080 Proces tworzenia �adowania danych ID070

ID090 Proces testowania �adowania danych ID080

ID100 Wykonanie �adowania wymiarów ID090

ID110 Weryfikacja dok�adno�ci i spójno�ci danych ID100

ID120 Tworzenie metadanych CM080

równie� liczba przetworzonych rekordów, a je�eli jest to mo�liwe, tak�e warto��z przetworzonych rekordów. Pozwala to utworzy� pewnego rodzaju zapis �ladu przep�ywudanych z systemu ród�owego do hurtowni i jest nieocenione przy �ledzeniu b��dów.Innym dobrym pomys�em jest rejestrowanie wpisów do dziennika w czasie dzia�aniaprocesu, a nie na jego kocu. Je�eli proces rutynowo obs�uguje miliony rekordów, toprzydatne jest zapisywanie danych do dziennika co 100 000 rekordów. Jednym ze sposobówna zapewnienie bardziej dynamicznego dzia�ania jest utworzenie argumentu wykonaniadefiniuj�cego cz�stotliwo�� zapisu danych do dziennika.

220 9. ZARZ DZANIE PROJEKTEM

� Ostrze�enie. Proces powinien dodawa� ostrze�enie do pliku dziennika, gdy zostanie wy-kryte co� podejrzanego, ale nie ma powodu, aby natychmiast na to reagowa�. Wygenero-wanie ostrze�enia mo�e wyst�pi� wskutek odrzucenia rekordu. Czasami zapis w dziennikumo�e by� informacyjny, na przyk�ad gdy system jest w 10 procentach pe�ny, w 20 procentachpe�ny itd. Te komunikaty informacyjne mog� by� „wypromowane” do ostrze�e, je�elisystem plików jest zaj�ty w ponad 60 procentach. W systemie proaktywnym mo�e to spo-wodowa� wys�anie komunikatu do operatora, aby móg� on podj�� dzia�ania, zanim sytu-acja stanie si� krytyczna.

� B��d. Gdy wyst�pi b��d, proces nie mo�e dalej dzia�a� i musi zosta� zatrzymany. Gdy naprzyk�ad zostanie zape�niony system plików, to pomimo �e proces mo�e uzyska� dost�pdo innego systemu, i tak nie mo�e kontynuowa� pracy i musi si� zatrzyma�. Czasami b��dy s�wykrywane od razu, na pocz�tku, na przyk�ad je�eli proces ustali, �e otrzyma� plik danych,które ju� wcze�niej przetworzy�. B��dy zwykle powoduj� zatrzymanie systemu i aby móg�dalej pracowa�, wymagana jest interwencja.

Gdy wyst�pi b��d, istnieje naturalna pokusa „spróbowania ponownie”. Rozumiemy przezto ponowne uruchomienie procesu. W odniesieniu do relacyjnych baz danych zwykle polega tona wycofaniu wszystkich operacji, które zosta�y wykonane prawid�owo, a nast�pnie, po rozwi�-zaniu problemu, na ponownym realizowaniu zada. Niestety, w przypadku hurtowni danychb�dziemy musieli przetworzy� wiele milionów transakcji. Nierzadko samo wycofanie zmianzajmuje du�o czasu. Zwykle wycofywanie wszystkich transakcji jest niepotrzebne, szczególnieje�eli po prostu zabrak�o nam miejsca — co jest bardzo cz�stym problemem w hurtowniach.Je�eli przetworzymy po�ow� danych, to w przypadku konieczno�ci wycofania zmian i ponow-nego przetworzenia danych od pocz�tku zadanie potrwa dwa razy d�u�ej, ni� pocz�tkowo ocze-kiwali�my. Gdy dzia�amy w ciasnym serwisowym oknie czasowym, to w efekcie mo�e to spo-wodowa�, �e nie b�dziemy mogli rano otworzy� hurtowni danych. Nale�y pami�ta�, �e cz���tych procesów mo�e nawet w normalnych okoliczno�ciach zaj�� kilka godzin. Warto zastano-wi� si�, czy nie mo�na pozwoli� na kontynuowanie procesu. Oznacza to, �e cho� proces zosta�zatrzymany po wykryciu b��du, to mo�e by� wznowiony po rozwi�zaniu problemu.

Podobnie jak w przypadku pocz�tkowego �adowania danych, zadania zwi�zane z ci�g�ym�adowaniem wymiarów, od SD010 do SD1100 w tabeli 9.5, musz� by� powtórzone dla ka�dejencji.

Nast�pny zbiór zada jest zwi�zany z aktywowaniem u�ytkowników. Operacji tu wymie-nionych nie trzeba obja�nia�. Dodatkowo po zdefiniowaniu ról klienta zadania te musz� by�wykonywane równolegle z pozosta�ymi (tabela 9.6).

Nast�pn� operacj� jest zorganizowanie zada administratora hurtowni danych (tabela 9.7).Obejmuje to definicje ról u�ytkowników, schematy u�ytkowników (perspektywy danych u�yt-kowników), jak równie� zidentyfikowane tabele podsumowa. Jako naczeln� zasad� zalecam,aby wstrzyma� tworzenie tabel podsumowa na tym etapie. Powody tego s� nast�puj�ce:

(1) Ich tworzenie powoduje opónienie momentu, w którym mo�na udost�pni� system u�yt-kownikom. Dosy� cz�sto proces sumowania poch�ania znaczn� cz��� zada programowa-nia. Ka�da odpowied, do której sformu�owania by�y u�yte tabele na poziomie podsumo-wa, mo�e by� równie� utworzona na podstawie tabeli szczegó�ów, poniewa� tabelepodsumowa pobieraj� swoje dane ze szczegó�ów. Jest to wy��cznie kwestia wydajno�ci.Ca�kowicie akceptowane jest najpierw udost�pnienie systemu u�ytkownikom, a dopieropóniej utworzenie mechanizmów poprawiaj�cych wydajno��.

JAKIEGO ZESPO�U POTRZEBUJEMY? 221

Tabela 9.5. Ci�g�e zadania przechwytywania i �adowania danych

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Ci�g�e 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 ka�dejencji SB060

SB080 Proces projektowania �adowania danych PM030

SB090 Proces tworzenia �adowania danych SB080

SB100 Proces testowania �adowania danych SB090

Dane okoliczno�ci i wymiarów

SD010 Identyfikowanie zmienionych danych CM040

SD020 Tworzenie po��cze zale�no�ci CM060

SD030 Proces projektowania ekstrakcji danych CM040

SD040 Proces tworzenia ekstrakcji danych SD030

SD050 Proces testowania ekstrakcjidanych

SD040

SD060 Projektowanie procesu VIM CM050

SD070 Tworzenie procesu VIM

Powtórzy�dla ka�dejencji

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 dost�pu u�ytkowników

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Dost�p u�ytkowników

UA010 Przydzia� u�ytkowników do ról WA010

UA020 Rejestrowanie u�ytkowników UA010

UA030 Konfigurowanie oprogramowaniau�ytkowników

UA040 Testowanie dost�pu u�ytkowników UA030

UA050 Projektowanie podr�cznikau�ytkownika

UA030

222 9. ZARZ DZANIE PROJEKTEM

Tabela 9.6. Zadania dost�pu u�ytkowników — ci�g dalszy

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Dost�p u�ytkowników

UA060 Tworzenie podr�cznika u�ytkownika 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 etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Administrowanie hurtowni� danych

WA010 Definiowanie ról u�ytkowników LM020

WA020 Odwzorowanie modelubezpieczestwa na role

WA010

WA030 Projektowanie schematów u�ytkownika WA020

WA040 Tworzenie schematów u�ytkownika WA030

WA050 Testowanie schematów u�ytkownika WA040

WA060 Projektowanie procesu sumowaniadanych

PM030

WA070 Tworzenie procesu sumowania danych WA060

WA080 Testowanie procesu sumowania danych WA070

WA090 Projektowanie procesu sumowaniadanych nawigacji

WA060

WA100 Tworzenie procesu sumowaniadanych nawigacji

WA090

WA110 Testowanie procesu sumowaniadanych nawigacji

WA100

(2) Udost�pnienie u�ytkownikom danych mo�liwie szybko ma równie� inne praktyczne zalety.Mo�emy obserwowa� ich wykorzystanie i u�ycie tej wiedzy do okre�lenia, które tabelepodsumowa powinni�my zainstalowa�. W projektach hurtowni danych cz�sto si� zdarza,�e tabele podsumowa musz� by� przeanalizowane dwukrotnie. Bywa, �e trafiamy zapierwszym razem, ale czasami si� mylimy i niektóre z naszych podsumowa nie s� nigdywykorzystywane przez u�ytkowników.

Nast�pnym krokiem s� zadania automatyzacji (tabela 9.8). Wielu kierowników projektówb�dzie udowadnia�, �e jest to najwi�ksze zagro�enie przy budowaniu hurtowni danych. Naszepodej�cie przyrostowe przy wszystkich swoich zaletach cz�sto pogarsza problem. Powodujeono, �e po pierwszym przyro�cie u�ytkownicy zaczynaj� korzysta� z danych. Jest to ten mo-ment, kiedy mog� si� oni przekona� do rozwi�zania i stwierdzi�: „Spójrzcie, naprawd� s� pew-ne korzy�ci ze wszystkich tych danych!”. Gdy to si� stanie, nie b�d� mieli dosy� i b�d� chcieliwi�cej — nie tylko modyfikacji tu czy tam — b�d� chcieli znacznie wi�cej. Zanim b�dziemywiedzieli, gdzie jeste�my, cz��� zespo�ów zostanie zaanga�owana do drugiego etapu. Jednak

JAKIEGO ZESPO�U POTRZEBUJEMY? 223

Tabela 9.8. Zadania automatyzacji

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci 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 podr�cznika proceduroperacyjnych

AP010

AP060 Tworzenie podr�cznika proceduroperacyjnych

AP050

AP070 Uzyskanie akceptacji operacyjnej AP060

klient nie wie, �e pierwszy etap jest daleki od zakoczenia. Uda�o si� nam tylko pokaza� dane,ale wszyscy b�d� uwa�a�, �e ju� skoczyli�my. U�ytkownicy nie b�d� widzieli tego, �e aby po-bra� dane z systemów ród�owych, przetworzy� je i za�adowa� do hurtowni danych, trzeba wy-kona� �mudn� r�czn� prac�. �aden z procesów nie zosta� jeszcze zintegrowany i systemy jesz-cze ze sob� nie wspó�pracuj�. Musimy wi�c wróci� do pierwszego etapu i zrealizowa� procesyharmonogramu, sterowania, obs�ugi b��dów itd., które s� potrzebne, aby zmieni� zwyk�y systemw produkt jako�ci przemys�owej z mocnymi spawami oraz �rubami i nakr�tkami zamiast tychwszystkich sznurków i ta�my klej�cej.

Jest to powa�ny problem w starej sztuce okre�lania oczekiwa. Je�eli pozwolimy, aby si� towymkn��o spod naszej kontroli, mo�emy nigdy jej nie odzyska�. Dzia�y operacyjne danej firmynigdy nie zaakceptuj� systemu, który nie potrafi samodzielnie sta� na w�asnych nogach, szcze-gólnie je�eli jest tak du�y i zasoboch�onny jak hurtownia danych. Za ka�dym razem musimyprzypomina� naszemu klientowi, �e to, co widzi, nie jest ukoczonym produktem i �e do za-koczenia pracy potrzeba jeszcze sporo czasu. Istnieje równie� pogl�d, aby nie dawa� u�ytkow-nikom dost�pu do hurtowni danych do momentu zakoczenia pierwszego etapu. Cho� niektórzypodzielaj� to twierdzenie, osobi�cie nadal podtrzymuj� opini�, �e u�ytkownicy powinni mie�dost�p do hurtowni tak szybko, jak jest to mo�liwe. W kocu s� to ich dane, a nie nasze. Silnezarz�dzanie projektem i równie silne zarz�dzanie oczekiwaniami s� tu kluczem do sukcesu.

Przejdmy teraz do wsparcia. Wsparcie istnieje na kilku poziomach (tabela 9.9). Ka�dyu�ytkownik ma specyficzne wymagania. Wyst�puj� dwa g�ówne rodzaje wsparcia:

(1) Wsparcie u�ytkowników. W tym przypadku polega to na prowadzeniu telefonicznej liniipomocy lub dzia�u wsparcia u�ytkowników, który im pomaga, gdy maj� pytania na tematsystemu lub us�ugi albo kiedy maj� problemy.

(2) Wsparcie systemu. Oczywiste jest, �e jako dostawcy systemu musimy wzi�� pewn� odpo-wiedzialno�� za jego obs�ug�, co najmniej przez jaki� czas. Po tym czasie musi by� zapew-nione dalsze wsparcie. Obejmuje to rutynow� konserwacj� systemu, w tym aktualizacjeoprogramowania systemowego i aplikacyjnego. Konieczne jest równie� wsparcie ogólnejnatury, na przyk�ad przy rozbudowie przestrzeni dyskowej czy te� odtwarzaniu systemupo awarii sprz�towej lub programowej.

224 9. ZARZ DZANIE PROJEKTEM

Tabela 9.9. Zadania wsparcia u�ytkowników

Numer etapu projektu Numer WBS Opis zadania Zale�no�ci Osobodni

Wsparcie u�ytkowników

US010 Projektowanie procesów wsparcia

US020 Tworzenie procesów wsparcia US010

US030 Testowanie procesów wsparcia US020

W zale�no�ci od klienta zmieniaj� si� wymagane poziomy wsparcia, jak równie� sposoby,w jakie to wsparcie jest realizowane. Niektóre organizacje maj� w�asne oddzia�y pomocy tech-nicznej, natomiast inne zlecaj� te zadania innym firmom. Niezale�nie od sytuacji musimy za-projektowa� strategi� wsparcia, aby by�a ona zgodna z wymaganiami.

Kolejn� pu�apk� jest niezapewnienie u�ytkownikom wsparcia od samego pocz�tku. Cz�stos� to u�ytkownicy, z którymi warto wspó�pracowa�, poniewa� s� oni w stanie powiedzie� namprecyzyjnie, czego potrzebuj�. Musimy dostarczy� im tych mechanizmów, zanim przejm� odnas odpowiedzialno�� za system. W wielu przypadkach czas i pieni�dze przeznaczone na pro-jekt s� tracone przez to, �e nie zwrócono uwagi na wymagania wsparcia. Jest to nieco podobnedo problemu z automatyzacj�, gdy� jest pozostawiane nietkni�te do koca projektu i zwykleuwa�ane za jedno z najnudniejszych zada, cho� w rzeczywisto�ci powinien mu by� nadanystrategiczny priorytet.

Problem kopii zapasowej i wycofywania przedstawi�em ju� w rozdziale 7. Warto powtórzy�,�e tworzenie kopii zapasowej w hurtowni danych nie jest prostym zadaniem i w uzyskanieefektywnego rozwi�zania trzeba w�o�y� sporo pracy (tabela 9.10). Wyst�puje równie� problemwycofania. W jaki sposób mo�emy wycofa� dane z systemu, gdy nie powinny one wcale trafi�do hurtowni danych?

Tabela 9.10. Zadania kopii zapasowej i odtwarzania

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Kopie bezpieczestwa i odtwarzanie

BR010 Projektowanie procesu tworzenia kopiizapasowej

BR020 Tworzenie procesu tworzenia kopiizapasowej

BR010

BR030 Testowanie procesu tworzenia kopiizapasowej

BR020

BR040 Projektowanie procesu wycofywania danych

BR050 Tworzenie procesu wycofywania danych BR040

BR060 Testowanie procesu wycofywania danych BR050

BR070 Projektowanie procesu ponownegowprowadzania danych

BR080 Tworzenie procesu ponownegowprowadzania danych

BR070

BR090 Testowanie procesu ponownegowprowadzania danych

BR080

JAKIEGO ZESPO�U POTRZEBUJEMY? 225

Czym jest „ponowne wprowadzanie danych”? Jest to przeciwiestwo wycofywania danych.Czasami okazuje si�, �e do hurtowni danych zosta�y za�adowane nieprawid�owe dane. Zwyklesi� dowiadujemy o tym, gdy kto� z zespo�u operacyjnego przyjdzie do naszego biura i powie, �ejeden z plików, jaki dostali�my cztery dni temu, by� nieprawid�owy. Musimy wtedy u�y� pro-cedury wycofania w celu usuni�cia nieprawid�owych danych, a nast�pnie procedury ponownegowprowadzenia danych, aby umie�ci� w hurtowni prawid�owe dane (nie zapominajmy, �e te nowedane równie� mog� by� póniej wycofane, je�eli oka�� si� nieprawid�owe — to si� zdarza).

Aby hurtownia danych mog�a normalnie dzia�a�, wi�kszo�� rutynowych procesów musiby� wykonywana automatycznie. Wykonywanie procesów oraz ustawianie ich w czasie i okre�laniezale�no�ci mi�dzy nimi zwykle realizuje si� przez mechanizm harmonogramowania. Harmo-nogramy maj� bardzo ró�ne zestawy dost�pnych funkcji, ale wi�kszo�� z nich jest dosy� zaawanso-wana. Na przyk�ad mo�e si� zdarzy�, �e nie chcemy, aby proces ekstrakcji danych by� urucha-miany wcze�niej, ni� zakoczy si� proces tworzenia pliku potrzebnego mu do pracy. Cho� plikten mo�e by� dost�pny, za�ó�my, o siódmej po po�udniu, to jednak nie ma gwarancji, �e si� takstanie. Je�eli o umówionej godzinie plik nie b�dzie dost�pny, nie mo�emy uruchomi� procesuekstrakcji. Harmonogramy mog� by� konfigurowane tak, aby reagowa�y na istnienie lub brakplików, jak równie� by rozumia�y kody zwracane przez inne procesy, informuj�ce o ich uda-nym wykonaniu lub b��dzie.

Zespó� operacyjny nie przejmie odpowiedzialno�ci za dzia�anie systemu, je�eli nie b�dzie wie-dzia�, jak go obs�ugiwa�. Jest to problem podobny do aspektów zwi�zanych ze wsparciem i automa-tyzacj�; to kolejna znana pu�apka, nie tylko w projektach hurtowni danych, ale we wszystkichprojektach IT. Tak jak w przypadku zespo�u wsparcia, zespó� operacyjny b�dzie mia� w�asnyzestaw wymaga, cz�sto spisanych, które musz� by� spe�nione przed przekazaniem mu systemu.

Kolejnymi elementami, jakie musimy dostarczy�, s� monitorowanie i dostrajanie wydajno�cioraz planowanie pojemno�ci. Nale�y zarezerwowa� nieco czasu na tego rodzaju dzia�ania. Niema sensu, aby dostarcza� system, który jednego dnia dzia�a doskonale, a w nast�pnym zaczyna mubrakowa� pami�ci, cykli procesora, przestrzeni dyskowych lub pasma sieciowego (tabela 9.11).

Tabela 9.11. Zadania zarz�dzania systemem

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Zarz�dzanie systemem

SM010 Planowanie

SM020 Szkolenie zespo�ów operacyjnych

SM030 Monitorowanie wydajno�ci

SM040 Planowanie pojemno�ci

W tabeli 9.12 wymieniono elementy, które czasami s� zapominane lub s� tyle razy odk�a-dane na póniej, �e staj� si� opónione. Inn� pu�apk� jest niedostarczenie u�ytkownikom mo�-liwie dok�adnej specyfikacji. Nie ma znaczenia, jak dobrze jest skonfigurowany serwer ani jakdu�o ma dost�pnej przestrzeni. Wiele �wietnie zaprojektowanych, dobrze skonfigurowanychi doskonale dzia�aj�cych hurtowni danych zosta�o wy��czonych przez negatywne przyj�cie,spowodowane przez próby wci�ni�cia komponentów u�ytkownika kocowego do przestarza-�ych komputerów klienckich.

226 9. ZARZ DZANIE PROJEKTEM

Tabela 9.12. Zadania instalacji i wdro�enia

Numer etapuprojektu Numer WBS Opis zadania Zale�no�ci Osobodni

Instalacja i wdro�enie

IR010 Przeprowadzenie szkoleniau�ytkowników

IR020 Instalowanie komponentówu�ytkownika

IR030 Testowanie konfiguracjioprogramowania u�ytkowników

UA030

Tabela 9.13 zawiera kilka zada, jakie nale�y wykona�, zanim zespo�y programistycznerozpoczn� swoj� prac�.

Tabela 9.13. Zadania konfiguracji pocz�tkowej

Pocz�tkowe wymagania systemowe

Pozyskanie i zainstalowanie oprogramowania DBMS

Pozyskanie i zainstalowanie oprogramowania dost�pu u�ytkownikó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 pojemno�ci

PodsumowanieMusimy kontrolowa� post�p projektu — w tym rozdziale przedstawi�em dok�adn� struktur�podzia�u zada wraz z zale�no�ciami, które mog� by� przystosowane do potrzeb dowolnychprojektów.

Omówi�em 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.

Opisa�em te� zespó� projektowy oraz umiej�tno�ci wymagane do udanego zrealizowaniaprojektu hurtowni danych.

Ponadto przeanalizowa�em niektóre z pu�apek zwi�zanych z jako�ci� danych i ich dost�p-no�ci�, a tak�e z komunikacj� z klientem. Innym problemem jest na przyk�ad potrzeba wspó�-pracy z zespo�em operacyjnym oraz pomocy technicznej po stronie klienta.

Mam nadziej�, �e rozdzia� ten b�dzie warto�ciowym przewodnikiem dla kierowników pro-jektów zaanga�owanych w dostarczanie hurtowni danych.

Skorowidz

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

EASI, 175, 197, 200OLAP, Patrz OLAP

architektura systemu, Patrz specyfikacja systemuarchiwizacja, Patrz dane archiwizacjaatrybut

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

Ccele biznesowe, 16CRM, Patrz zarz�dzanie relacjami z klientemczas

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

Ddane

aktualno��, 181archiwizacja, 194b��dne, 179, 181, 220, 229cykl �ycia, 103czasu, 81ekstrakcja, 194, 228integracja, 38, 46, 47, 90jako��, 213, 234kontrola poprawno�ci, Patrz VIMkopia okoliczno�ci, 194kopia zapasowa, 194kopia zmian, 194�adowanie, 194, 228, 229niestrukturalizowane, 248nieulotno��, 38normalizacja, 62odrzucenie, 177, 178, 179okoliczno�ci, 83operacyjne, 35przechwytywanie zmian, 166przekszta�canie, 228, 229pula, 188, 192, 193referencyjne, 25, 83sortowanie, 242spójno��, 181strategiczne, 35strukturalizowane, 248udost�pnianie, 222warto�� domy�lna, 177, 182wycofywanie, 195, 224wydobywanie, Patrz wydobywanie danychwymiarów, 96zachowa, 83, 193, 194zewn�trzne, 247zmienno�� w czasie, 38

290 SKOROWIDZ

Database Management System, Patrz systemzarz�dzania bazami danych

DBMS, Patrz system zarz�dzania bazami danychDDL, Patrz j�zyk definicji danychDecision Support Systems, Patrz DSSdiagram ERD, 76diagram stanów, 44domena, 151dominacja na rynku produktu, 17, 18doskona�o�� operacyjna, 18DSS, 31, 33, 247, 249, Patrz ograniczenia, Patrz zadania

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

102, 107, 115, 122, 136, 150, 161, 192, 218referencyjna, 92zasada integralno�ci, Patrz zasada integralno�ci

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

Ffakt, Patrz zdarzenieFirst Manhattan Group, 19

GGCM, Patrz model koncepcyjny

Hhierarchia, 100, 107, 109, 123, 133

dekompozycja, 164

Iindukcja regu�, 237istnienie, 151, 153, 169

atrybuty, Patrz atrybut istnienianieci�g�e, 165

JJAD, Patrz warsztat wspólnego tworzenia aplikacjij�zyk definicji danych, 75, 218, 232

Kkampania, 27, 28

jednofazowa, 27, 239powtarzalna, 28, 239wielofazowa, 27, 239zarz�dzanie, 238

Kimball Ralph, 95, 97, 103, 157klient

identyfikacja, 28, 153identyfikator, 214lojalno��, 22migracja, 22, 26, 27, 153, 157, 192, 201okoliczno�ci, 70, 71, 192profil, 24, 202segmentacja, 74, Patrz segmentacjawarto��, 26wymiar, 72, 164zachowania, 70, 71zarz�dzanie relacjami, Patrz zarz�dzanie

relacjami z klientemklucz

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

kluczowe wskaniki wydajno�ci, 112kolumna kluczy obcych, Patrz klucz obcyretrospekcja, 114koncentracja na kliencie, 17kontrola poprawno�ci danych, Patrz VIMkopia okoliczno�ci, Patrz dane kopia okoliczno�cikopia zapasowa, 224, Patrz tak�e dane kopia

zapasowakopia zmian, Patrz dane kopia zmian

Mmargines b��du, 186marketing

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

metadane, 54, 122, 136, 137, 140, 141, 143, 176, 181,183, 193, 228, 241, 258aktywne, 242nawigacji, 242pasywne, 242przekszta�ce, 241

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

migracja klientów, Patrz klient migracjamodel

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

161, 200, 217wymagania, 111

SKOROWIDZ 291

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

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

modelowaniekoncepcyjne, 111metod� kropki, 119, 123, 124, 132, 147, 200,

202, 255modelowanie wymiarów, 42

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

Oograniczenie

podwójnego zliczania, 167spójno�ci odwo�a, 169usuwania, 170

okoliczno�ci, 92, 114, 195kopia, Patrz dane kopia okoliczno�ci

OLAP, 230, 246

Ppartycjonowanie, 193, 194personalizacja, 240pierwsza posta� normalna, 62podej�cie wzrastaj�ce, 174, 200podr�cznik systemu, Patrz specyfikacja systemuposta� normalna Boyce-Codda, 62przetwarzanie analityczne na bie��co, Patrz OLAPprzypadkowo��, 118pula danych, Patrz dane pula

RRAD, Patrz metoda szybkiego tworzenia aplikacjirelacyjna baza danych, 45relacyjny system zarz�dzania baz� danych, 31, 32,

45, 81Relational Database Management System, Patrz

relacyjny system zarz�dzania baz� danychretrospekcja, 114, 116, 143, 144, 147, 150, 154, 161,

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

relacji, 115warto��, 145

ryzyko, 213

Sschemat

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

segmentacja, 24, 27wed�ug danych skojarzonych, 26wed�ug zachowa, 25

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

rozszerzenia temporalne, Patrz TSQL2Structured Query Language, Patrz SQLstruktura podzia�u danych, Patrz WSBsystem zarz�dzania bazami danych, Patrz relacyjny

system zarz�dzania baz� danych

Ttabela

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

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

tematyczna hurtownia danych, 68TSQL2, 105

Uu�ytkownik

aktywowanie, 220wsparcie, 223

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

Wwarstwa

integracji, 183, Patrz te� VIMkontroli poprawno�ci danych, 176, Patrz te�

VIModwzorowania, 184, Patrz te� VIM

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

292 SKOROWIDZ

warto�� domy�lna, Patrz dane warto�� domy�lnawarto�� marki, 17, 18WBS, 209, 217wdro�enie, 205, 206wspomaganie podejmowania decyzji, Patrz DSSwydajno�� systemu, 163, 212, 225wydobywanie danych, 57, 205, 234, 237, 238wykres sieciowy, 236wymiar, 122, 132, 150, 192

czasu, Patrz czas wymiarhierarchia, 123, 133kszta�t, 113powoli zmieniaj�cy si�, 95

XXML, 248

Zzachowanie, 113, 131, 195, 234zadania

strategiczne, 35zale�no�� przechodnia, 64za�o�enia, 213zapytanie SQL, Patrz SQLzarz�dzanie relacjami z klientem, 18, 19, 21, 23, 29,

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

atrybutów identyfikuj�cych, 116integralno�ci encji, 62przyczyny i efektu, 71

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