Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00176 005946 14495070 na godz. na dobę w sumie
Projektowanie hurtowni danych. Wspomaganie zarządzania relacjami z klientami - książka
Projektowanie hurtowni danych. Wspomaganie zarządzania relacjami z klientami - książka
Autor: Liczba stron: 296
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3225-1 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> inne
Porównaj ceny (książka, ebook, audiobook).

Umiejętnie zarządzaj informacjami!

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.

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

Darmowy fragment publikacji:

Idź do • Spis treści • Przykładowy rozdział • Skorowidz Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2011 Projektowanie hurtowni danych Wspomaganie zarządzania relacjami z klientami Autor: Chris Todman Tłumaczenie: Paweł Gonera ISBN: 978-83-246-3225-1 Tytuł oryginału: Designing A Data Warehouse: Supporting Customer Relationship Management Format: 172×245, stron: 296 Umiejętnie zarządzaj informacjami! • Czym są hurtownie danych? • Jak je zaprojektować, aby wykorzystać maksimum ich możliwości? • Jak wydajnie zarządzać relacjami z klientem? Zastanawiasz się, jak zmaksymalizować zyski czerpane z właściwego zarządzania relacjami z klientem? Jest to pytanie, które spędza sen z oczu każdemu przedsiębiorcy. Jedną z możliwości jest wykorzystanie odpowiednio zaprojektowanej hurtowni danych. Projekt takiej bazy danych, uwzględniającej potrzeby klienta, wymaga nowych technik i metodologii. Jakich? Na to pytanie odpowiada Chris Todman w książce, którą trzymasz w rękach. Wiodący konsultant w dziedzinie hurtowni danych przedstawi Ci kompletną metodologię, pozwalającą na zaprojektowanie, wytworzenie i wdrożenie hurtowni danych pod kątem zarządzania relacjami z klientem. Najpierw przeczytasz o kilku zagadnieniach teoretycznych, związanych z relacjami z klientem oraz hurtowniami danych. Potem zapoznasz się z typowymi problemami, aby w rozdziale piątym przejść do omówienia modelu koncepcyjnego. Dowiesz się, jak obsługiwać okoliczności, identyfikować zmiany w danych oraz modelować metodą kropki. Kolejne omawiane zagadnienia to model logiczny i sposoby rozwiązywania problemów wydajnościowych. W rozdziale poświęconym implementacji fizycznej zobaczysz, jak kontrolować poprawność danych, zarządzać kopiami zapasowymi oraz aplikacjami CRM. Ponadto nauczysz się zarządzać projektem, przejrzysz możliwości dostępnego oprogramowania oraz zdobędziesz wiedzę o perspektywach rozwoju. To wszystko znajdziesz w tej długo oczekiwanej książce, poświęconej hurtowniom danych. • Zarządzanie relacjami z klientem • Wartość marki • Zarządzanie kampaniami i marketing personalizowany • Budowanie hurtowni danych – komponent ekstrakcji oraz integracji danych • Baza danych hurtowni – opis encji • Problemy przy wykorzystywaniu relacyjnych baz danych • Problemy z obróbką czasu w hurtowniach danych • Wybór modelu koncepcyjnego • Modelowanie metodą kropki • Modelowanie logiczne – schemat, wybór rozwiązania, ograniczenia • Implementacja fizyczna • Zarządzanie kopiami zapasowymi • Aplikacje CRM • Zarządzanie projektem • Oprogramowanie • Przyszłość hurtowni danych Sprawdź, jak zmaksymalizować zyski poprzez właściwe zarządzanie relacjami z klientem! Spis treĂci Wprowadzenie ..........................................................................................................7 PodziÚkowania .......................................................................................................11 1. ZarzÈdzanie relacjami z klientem ........................................................................13 Wymiar biznesowy .......................................................................................................................................13 Cele biznesowe ..............................................................................................................................................15 Strategia biznesowa ......................................................................................................................................16 WartoĂÊ marki ..............................................................................................................................................17 ZarzÈdzanie 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 zwiÈzane z zastosowaniem relacyjnych baz danych ................................................................58 Podsumowanie ..............................................................................................................................................59 3. Problemy projektowe do rozwiÈzania ..................................................................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 zwiÈzane z czasem .......................................................................................................................84 Rejestrowanie zmian ....................................................................................................................................90 RozwiÈzania problemów z czasem w hurtowniach danych pierwszej generacji ....................................94 Odmienne podejĂcia ...................................................................................................................................107 Konkluzje z przeglÈdu metod pierwszej generacji ..................................................................................109 4 SPIS TRE¥CI 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 wydajnoĂciowe ..........................................................................................................................163 Wybór rozwiÈzania .....................................................................................................................................165 CzÚstotliwoĂÊ 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 PodejĂcie przyrostowe ................................................................................................................................199 Wdroĝenie ...................................................................................................................................................205 Podsumowanie ............................................................................................................................................207 9. ZarzÈdzanie projektem ........................................................................................209 Wprowadzenie ............................................................................................................................................209 Co jest dostarczane? ...................................................................................................................................212 Jakie naleĝy zdefiniowaÊ zaïoĝenia i ryzyka? ..........................................................................................213 Jakiego zespoïu potrzebujemy? .................................................................................................................215 Podsumowanie ............................................................................................................................................226 10. Oprogramowanie ..................................................................................................227 Ekstrakcja, przeksztaïcanie i ïadowanie ..................................................................................................228 OLAP ........................................................................................................................................................230 NarzÚdzia zapytañ ......................................................................................................................................232 Wydobywanie danych ................................................................................................................................234 ZarzÈdzanie kampaniami ..........................................................................................................................238 Personalizacja .............................................................................................................................................240 NarzÚdzia metadanych ...............................................................................................................................241 Sortowanie ..................................................................................................................................................242 11. PrzyszïoĂÊ ..............................................................................................................245 Temporalne bazy danych (rozszerzenia temporalne) .............................................................................246 Rozszerzenia OLAP dla SQL ...................................................................................................................246 Aktywne wsparcie decyzji .........................................................................................................................247 SPIS TRE¥CI 5 Dane zewnÚtrzne ........................................................................................................................................247 Dane niestrukturalizowane .......................................................................................................................248 Agenci wyszukiwania .................................................................................................................................248 Aplikacje 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 ...................................................................................................275 Atrybuty finansowe ....................................................................................................................................281 Atrybuty zatrudnienia ...............................................................................................................................282 Atrybuty zainteresowañ i hobby ...............................................................................................................283 E. OdnoĂniki ..............................................................................................................287 Skorowidz .............................................................................................................289 9 ZarzÈdzanie projektem ¿aden projekt nie moĝe byÊ ukoñczony bez przygotowania odpowiedniego planu! W tym roz- dziale przedstawiÚ róĝnice pomiÚdzy projektami tworzenia hurtowni danych a tradycyjnymi projektami dostarczania oprogramowania. Tïumaczy to, dlaczego organizacjom nie udaje siÚ doprowadziÊ procesu do koñca, 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óre muszÈ byÊ zrealizowane w kaĝdym przyroĂcie. Wprowadzenie Odpowiednie zarzÈdzanie jest czÚsto kluczem do sukcesu projektu. Kaĝdy projekt potrzebuje kierownika oraz zastosowania pewnej metodologii zarzÈdzania. Nie ma znaczenia, w jakiego rodzaju projekt jesteĂmy zaangaĝowani. Projekty duĝych fizycznych konstrukcji, jak mosty, statki czy tunele, równieĝ muszÈ byÊ zarzÈdzane. ChoÊ czasami koñczÈ 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ï problem z okreĂleniem, jaka czÚĂÊ projektu zostaïa zakoñczona. Innym problemem jest poziom zïoĝonoĂci systemów komputerowych, który jest znacznie wiÚkszy niĝ w przypadku innych projektów. Jako przykïad weěmy odrzutowiec. Projektowanie i 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. ZARZkDZANIE PROJEKTEM i kadïub zostaïy zaprojektowane z uĝyciem oprogramowania. Nie moĝemy zobaczyÊ ĝadnego z tych elementów, wiÚc nasze podejĂcie do zarzÈdzania takim projektem musi byÊ bardziej zïoĝone niĝ 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 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 byïo omówione w rozdziale 1. Moĝemy oczekiwaÊ, ĝe wiÚkszoĂÊ Czytelników tej 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 pokazanym na rysunku 9.1. Rysunek 9.1. Klasyczna metoda wodospadu ZasadÈ metody wodospadu jest koniecznoĂÊ zakoñczenia tworzenia kaĝdego gïównego kompo- nentu przed rozpoczÚciem pracy nad nastÚpnym. Dlatego przed analizÈ muszÈ byÊ zebrane wszystkie wymagania, a przed przystÈpieniem do projektowania niezbÚdne jest zakoñczenie fazy 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 wszystkie testy. W Ăwiecie rzeczywistym czÚsto siÚ zdarza, ĝe testowanie wykrywa zïe zrozumienie czÚĂci analizy dotyczÈcej jednego z wymagañ. CzÚĂciowe ponowne opracowywanie wymagañ, a nastÚpnie modyfikowanie projektu, kodu i planu testów jest czasochïonne, demoralizujÈce oraz oczywiĂcie bardzo kosztowne — dlatego wïaĂnie 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 czÚsto wy- korzystywana przy tworzeniu hurtowni danych, gdzie w niektórych przypadkach jest nadal sensowna. Metody RAD dziaïajÈ w oparciu o nieco inne zasady i mogÈ byÊ efektywne dla aplikacji, które majÈ nastÚpujÈcÈ charakterystykÚ: x InteraktywnoĂÊ — funkcje aplikacji sÈ jasno widoczne w interfejsie uĝytkownika. RAD bazuje na 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Èce prototypy. x Jasno zdefiniowana grupa uĝytkowników. Jeĝeli grupa uĝytkowników nie jest jasno zdefi- niowana, moĝe zaistnieÊ niebezpieczeñstwo skierowania tworzenia aplikacji w zïym kierun- ku lub (co gorsza) nastÈpiÊ caïkowite zignorowanie waĝnych elementów aplikacji. x 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 projekcie RAD. 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. x Jeĝeli sÈ duĝe, majÈ moĝliwoĂÊ podziaïu na mniejsze komponenty funkcjonalne. Jeĝeli system jest duĝy, powinien dawaÊ moĝliwoĂÊ podziaïu na mniejsze, ïatwiejsze do zarzÈdzania fragmenty 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 standardowej metody wodospadu. x Ograniczenie czasowe. Musi zostaÊ okreĂlona data zakoñczenia projektu. Jeĝeli nie jest ona podana, 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 podobieñstwo — obie dotyczÈ tworzenia tradycyjnych aplikacji. Aplikacje zazwyczaj realizujÈ 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Ăcie istniejÈ pewne procesy, na przykïad przetwarzanie VIM, ale hurtownia danych nie realizuje procesó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. ZARZkDZANIE 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ïem podejĂ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 projekt bÚ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Ê koñcowy podpis? WiÚkszoĂÊ 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 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Úpnie moĝ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 przebiega on 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Ămy zrealizowaÊ kontrolÚ poprawnoĂci w celu upewnienia siÚ, ĝe wszystkie rekordy, które zostaïy pobrane 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. x PowiÈzanie hurtowni danych z jednÈ z aplikacji. Przykïadem moĝe byÊ system zarzÈdzania kampaniami. Moĝemy uzgodniÊ zbiór kryteriów segmentacji przy wyborze klientów, do któ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Ú. x Wybranie kilku pytañ, które zostaïy postawione na warsztatach strategii informacyjnej. Jeĝeli bÚdziemy w stanie wykonaÊ kilka z tych pytañ, udowodni to, ĝe hurtownia danych moĝe dostarczaÊ organizacji wartoĂciowych informacji. Naleĝy uwaĝnie wybieraÊ pytania, aby mogïy byÊ zrealizowane przez mechanizmy dostarczane w pierwszych etapach. Nie ma sensu wykonywaÊ zapytañ zwiÈzanych ze zmieniajÈcymi siÚ okolicznoĂciami klientów, jeĝeli dostarczyliĂmy czÚĂÊ dotyczÈcÈ zachowañ przy kupnie wina. Naleĝy równieĝ zachowaÊ ostroĝnoĂÊ w przypadku kryteriów akceptacji odnoszÈcych siÚ do wydajnoĂ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 ZDEFINIOWAm ZA’O¿ENIA I RYZYKA? 213 Moĝe to byÊ ogromny problem, poniewaĝ tego typu kryteria akceptacji najprawdopodob- niej uniemoĝliwiÈ odbiór koñcowy. 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. Zapytanie hurtowni 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ÈÊ sporo czasu. 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 system nie bÚdzie sprawdzany na ich okolicznoĂÊ. PowinniĂmy prezentowaÊ poglÈd, ĝe odpowiedzi na niektóre pytania sÈ niemoĝliwe lub niemal niemoĝliwe do uzyskania. Jeĝeli jesteĂmy w stanie otrzymaÊ odpowiedzi na wszystkie pytania, wskazuje to, ĝe system odniesie sukces. Strojenie wydajnoĂci jest czymĂ, co moĝna zawsze przeprowadziÊ w póěniej, stosujÈc standardowe metody optymalizacji relacyjnych baz danych 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 nie wiemy 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 ograniczamy je, 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: x JakoĂÊ danych. Jeĝeli projekt zawiera zadanie zwiÈzane z analizÈ jakoĂci danych, to jest to prawidï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 klienci czÚ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Ăci danych 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. ZARZkDZANIE 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 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È zupeïnie inne niĝ w pozostaïych. Moĝe nam siÚ wydawaÊ, ĝe jeĝeli kaĝdy system zawiera fragment ukï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, natomiast system 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. Adresy mogÈ 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. Nasz klient 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. x 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 przy okazji 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 momencie w czasie conocnego przetwarzania wsadowego. W jednym z etapów cyklu przetwarzania wsadowego 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Ú to problemem 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. x 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 do 20.00. Potrzebujemy pewnej liczby cykli przetwarzania w postaci conocnego okna cza- sowego, w którym wykonywane jest ïadowanie danych i przeprowadzane sÈ czynnoĂci konserwacyjne. Nie jest to problem, ale czasami zdarzajÈ siÚ przypadki, w których okno to staje siÚ bardzo maïe. Na przykïad na koniec miesiÈca, kwartaïu, a szczególnie roku firma musi 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 czasowe i znów musimy zmieĂciÊ siÚ w krótszym czasie. Tak jak wczeĂniej, niezwykle trudno jest zawrzeÊ w kodzie zabezpieczenia przed takÈ sytuacjÈ i najlepsze, co moĝemy zrobiÊ, to dopisaÊ zaïoĝenie, ĝe nasze conocne okno przetwarzania musi pozostaÊ otwarte. x 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 koñcowym sukcesie projektu. Osoba ta musi byÊ entuzjastycznie nastawiona do 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 on projekt 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È go tak 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. x 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 tak rygorystycznie 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Ê potrzebne dane, ale nie ma nikogo, kto dostarczy peïnego opisu pól danych w rekordach. Czasami zdarza 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 jest koszmarem. Dobrym pomysïem jest wiÚc zaïoĝenie, ĝe klient moĝe wskazaÊ osoby, które w peïni rozumiejÈ dane systemy. Jakiego zespoïu potrzebujemy? Aby prawidïowo zaplanowaÊ projekt, jego kierownik musi wiedzieÊ, kiedy i jakich zasobów bÚ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Ú: x 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 procesu produkcji 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 pracy na podstawie staïych zaïoĝeñ, na przykïad dokïadnej specyfikacji systemu, uznajÈ te pro- jekty za bardzo trudne. x Konsultant biznesowy. Jest to funkcja krytyczna dla sukcesu projektu. Absolutnie nie mamy tu na 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 konsultant biznesowy powinien dobrze znaÊ Ărodowisko biznesowe klienta. Osoba ta jest odpowiedzialna za zbieranie wymagañ biznesowych oraz pomoc przy tworzeniu modelu koncepcyjnego. 216 9. ZARZkDZANIE PROJEKTEM Rysunek 9.2. Przykïadowa struktura zespoïu projektowego x Architekt rozwiÈzania. Osoba ta jest równieĝ kluczowym graczem w zapewnieniu koñcowego sukcesu 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 stanowisku miaïa 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 ksiÈĝce. x Gïówny programista. W wielu aspektach funkcja ta moĝe byÊ uznawana za dosyÊ podobnÈ do funkcji kierownika produkcji oprogramowania w tradycyjnych projektach. W hurtowni danych istnieje wiele niewielkich podprojektów, które dziaïajÈ w niej jednoczeĂnie. Kaĝdy z tych podprojektów jest realizowany przez maïy zespóï zïoĝony z gïównego programisty oraz 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ĝdym projekcie, ale dopóki jest stosowane podejĂcie przyrostowe, nie powinniĂmy potrzebowaÊ wiÚcej niĝ trzy lub cztery maïe zespoïy. Gdy skoñczy siÚ dany etap, moĝemy przydzieliÊ zespoïom kolejne zadania. x Administrator bazy danych. WiÚkszoĂÊ pracy, jakÈ wykonujemy przy tworzeniu hurtowni danych, 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 hurtowni danych bÚdzie wykonywany przez jeden z zespoïów projektowych, ale powinien on ĂciĂle wspóï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. x 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 dba o Ărodowisko pracy zespoïu. Dobrze jest jednak, jeĝeli moĝemy polegaÊ na kimĂ, kto moĝe pomóc przy bardziej technicznych elementach. Konieczne jest skonfigurowanie uĝycia procesora 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 danych W 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Ă do niego 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 wszystkie komponenty, które zidentyfikowaliĂmy w rozdziale na temat modelowania koncepcyjnego. ZwróÊmy uwagÚ, ĝe nie ma potrzeby korzystania z techniki modelowania kropki. Ten WBS nie jest zaleĝny od ĝadnej metodologii, choÊ dosyÊ dobrze pasuje do metodologii kropki. Tabela 9.1. Zadania modelowania koncepcyjnego Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni Model koncepcyjny CM010 CM020 CM030 CM040 CM050 CM060 CM070 CM080 Zbieranie wymagañ biznesowych Tworzenie koncepcyjnego modelu wielowymiarowego OkreĂlenie wymagañ retrospekcji OkreĂlenie ěródeï danych OkreĂlenie przeksztaïceñ OkreĂlenie zaleĝnoĂci w zmienionych danych OkreĂlenie czÚstotliwoĂci i opóěnieñ czasowych Tworzenie metadanych CM010 CM020 CM020 CM040 CM040 CM040 CM040 Retrospekcja, zaleĝnoĂci zmienionych danych oraz czÚstotliwoĂci i opóěnienia czasowe po- NastÚpnym krokiem jest konwersja modelu koncepcyjnego na model logiczny (tabela 9.2). winny byÊ juĝ znanymi terminami. Jest to opisane w rozdziale 6. 218 9. ZARZkDZANIE PROJEKTEM Tabela 9.2. Zadania modelowania logicznego Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni Model logiczny LM010 LM020 LM030 Przeksztaïcanie modelu koncepcyjnego w logiczny Projektowanie modelu bezpieczeñstwa Tworzenie logicznego modelu danych CM030 CM020 LM010 Tworzenie modelu fizycznego jest opisane szczegóïowo w rozdziale 7. Wynik z fazy modelu fizycznego jest zbiorem instrukcji jÚzyka 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 ZaleĝnoĂci Osobodni Model fizyczny PM010 PM020 PM030 PM040 Przeksztaïcanie modelu logicznego w fizyczny Tworzenie modelu bezpieczeñstwa Projektowanie modelu fizycznego Tworzenie DDL LM030 LM020 PM010 PM030 WiÚkszoĂÊ z kolejnych czÚĂci projektu moĝe byÊ realizowana równolegle z modelowaniem danych. 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 pewne zaleĝ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ów danych. 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 powinien rejestrowaÊ swoje dziaïanie w dzienniku systemu. Informacje zapisywane w dzienniku powinny byÊ oznaczone jako: x Informacja. Komunikaty informacyjne zawierajÈ datÚ i czas rozpoczÚcia oraz zakoñczenia. Czas realizacji jest kolejnÈ uĝytecznÈ informacjÈ, która pozwala administratorowi systemu na 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 etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni PoczÈtkowe przechwytywanie i ïadowanie danych Dane zachowañ Proces projektowania ekstrakcji danych IB010 Proces tworzenia ekstrakcji danych IB020 Proces testowania ekstrakcji danych IB030 Projektowanie procesu VIM IB040 Tworzenie procesu VIM IB050 Testowanie procesu VIM IB060 Proces projektowania ïadowania danych IB070 Proces tworzenia ïadowania danych IB080 IB090 Proces testowania ïadowania danych IB100 Wykonanie ïadowania danych faktów IB110 Weryfikacja dokïadnoĂci i spójnoĂci danych IB120 Dane okolicznoĂci i wymiarów ID010 ID020 ID030 ID040 ID050 ID060 ID070 Proces projektowania ekstrakcji danych Proces tworzenia ekstrakcji danych Proces testowania ekstrakcji danych Projektowanie procesu VIM Tworzenie procesu VIM Testowanie procesu VIM Proces projektowania ïadowania danych Proces tworzenia ïadowania danych Proces testowania ïadowania danych PowtórzyÊ dla kaĝdej encji Tworzenie metadanych CM040 IB010 IB020 CM050 IB040 IB050 PM030 IB070 IB080 IB090 IB100 CM080 CM040 ID010 ID020 CM050 ID040 ID050 PM030 ID070 ID080 ID090 ID100 CM080 ID080 ID090 ID100 Wykonanie ïadowania wymiarów ID110 Weryfikacja dokïadnoĂci i spójnoĂci danych ID120 Tworzenie metadanych 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ïywu danych 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ïania procesu, a nie na jego koñcu. Jeĝeli proces rutynowo obsïuguje miliony rekordów, to przydatne jest zapisywanie danych do dziennika co 100 000 rekordów. Jednym ze sposobów na zapewnienie bardziej dynamicznego dziaïania jest utworzenie argumentu wykonania definiujÈcego czÚstotliwoĂÊ zapisu danych do dziennika. 220 9. ZARZkDZANIE PROJEKTEM x 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 dzienniku moĝe byÊ informacyjny, na przykïad gdy system jest w 10 procentach peïny, w 20 procentach peïny itd. Te komunikaty informacyjne mogÈ byÊ „wypromowane” do ostrzeĝeñ, jeĝeli system 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. x BïÈd. Gdy wystÈpi bïÈd, proces nie moĝe dalej dziaïaÊ i musi zostaÊ zatrzymany. Gdy na przykïad zostanie zapeïniony system plików, to pomimo ĝe proces moĝe uzyskaÊ dostÚp do 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 przez to ponowne uruchomienie procesu. W odniesieniu do relacyjnych baz danych zwykle polega to na 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 danych bÚdziemy musieli przetworzyÊ wiele milionów transakcji. Nierzadko samo wycofanie zmian zajmuje duĝo czasu. Zwykle wycofywanie wszystkich transakcji jest niepotrzebne, szczególnie jeĝ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ĝdej encji. 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ĝ tabele podsumowañ pobierajÈ swoje dane ze szczegóïów. Jest to wyïÈcznie kwestia wydajnoĂci. Caïkowicie akceptowane jest najpierw udostÚpnienie systemu uĝytkownikom, a dopiero póěniej utworzenie mechanizmów poprawiajÈcych wydajnoĂÊ. JAKIEGO ZESPO’U POTRZEBUJEMY? 221 Tabela 9.5. CiÈgïe zadania przechwytywania i ïadowania danych Numer etapu projektu 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 Proces projektowania ekstrakcji danych Proces tworzenia ekstrakcji danych Proces testowania ekstrakcji danych Projektowanie procesu VIM Tworzenie procesu VIM Testowanie procesu VIM Proces projektowania ïadowania danych Proces tworzenia ïadowania danych Proces testowania ïadowania danych PowtórzyÊ dla kaĝdej encji SB020 SB030 SB040 SB050 SB060 SB070 SB080 SB090 SB100 Dane okolicznoĂci i wymiarów SD010 SD020 SD030 SD040 SD050 Identyfikowanie zmienionych danych Tworzenie poïÈczeñ zaleĝnoĂci Proces projektowania ekstrakcji danych Proces tworzenia ekstrakcji danych Proces testowania ekstrakcji danych Projektowanie procesu VIM Tworzenie procesu VIM Testowanie procesu VIM Proces projektowania ïadowania danych Proces tworzenia ïadowania danych Proces testowania ïadowania danych PowtórzyÊ dla kaĝdej encji SD060 SD070 SD080 SD090 SD100 SD110 CM040 CM040 SB020 SB030 CM050 SB050 SB060 PM030 SB080 SB090 CM040 CM060 CM040 SD030 SD040 CM050 SD060 SD070 PM030 SD090 SD100 ZaleĝnoĂci Osobodni WA010 UA010 UA030 UA030 Tabela 9.6. Zadania dostÚpu uĝytkowników Numer etapu projektu Numer WBS Opis zadania DostÚp uĝytkowników UA010 UA020 UA030 UA040 UA050 Przydziaï uĝytkowników do ról Rejestrowanie uĝytkowników Konfigurowanie oprogramowania uĝytkowników Testowanie dostÚpu uĝytkowników Projektowanie podrÚcznika uĝytkownika 222 9. ZARZkDZANIE PROJEKTEM Tabela 9.6. Zadania dostÚpu uĝytkowników — ciÈg dalszy Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni DostÚp uĝytkowników UA060 UA070 UA080 UA090 Tworzenie podrÚcznika uĝytkownika UA050 UA030 Projektowanie pomocy dla procesów UA070 Tworzenie pomocy dla procesów Testowanie pomocy dla procesów UA080 Tabela 9.7. Zadania administrowania zadaniami przetwarzania w hurtowni danych Numer etapu projektu Opis zadania Numer WBS ZaleĝnoĂci Osobodni Administrowanie hurtowniÈ danych WA010 WA020 LM020 WA010 Definiowanie ról uĝytkowników Odwzorowanie modelu bezpieczeñstwa na role Projektowanie schematów uĝytkownika WA020 Tworzenie schematów uĝytkownika WA030 Testowanie schematów uĝytkownika WA040 Projektowanie procesu sumowania PM030 danych Tworzenie procesu sumowania danych WA060 Testowanie procesu sumowania danych WA070 WA060 Projektowanie procesu sumowania danych nawigacji Tworzenie procesu sumowania danych nawigacji Testowanie procesu sumowania danych nawigacji WA100 WA090 WA030 WA040 WA050 WA060 WA070 WA080 WA090 WA100 WA110 (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 tabele podsumowañ powinniĂmy zainstalowaÊ. W projektach hurtowni danych czÚsto 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 uĝytkowników. NastÚpnym krokiem sÈ zadania automatyzacji (tabela 9.8). Wielu kierowników projektów bÚdzie udowadniaÊ, ĝe jest to najwiÚksze zagroĝenie przy budowaniu hurtowni danych. Nasze podejĂcie przyrostowe przy wszystkich swoich zaletach czÚsto pogarsza problem. Powoduje ono, ĝ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È chcieli wiÚcej — nie tylko modyfikacji tu czy tam — bÚdÈ chcieli znacznie wiÚcej. Zanim bÚdziemy wiedzieli, gdzie jesteĂmy, czÚĂÊ zespoïów zostanie zaangaĝowana do drugiego etapu. Jednak JAKIEGO ZESPO’U POTRZEBUJEMY? Tabela 9.8. Zadania automatyzacji 223 Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni Automatyzacja przetwarzania AP010 AP020 AP030 AP040 AP050 Projektowanie procesu automatyzacji Tworzenie procesu automatyzacji Testowanie procesu automatyzacji Wykonanie testów integracyjnych Projektowanie podrÚcznika procedur operacyjnych Tworzenie podrÚcznika procedur operacyjnych Uzyskanie akceptacji operacyjnej AP060 AP070 AP010 AP020 AP030 AP010 AP050 AP060 klient nie wie, ĝe pierwszy etap jest daleki od zakoñczenia. Udaïo siÚ nam tylko pokazaÊ dane, ale wszyscy bÚdÈ uwaĝaÊ, ĝe juĝ skoñczyliĂ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Ê procesy harmonogramu, sterowania, obsïugi bïÚdów itd., które sÈ potrzebne, aby zmieniÊ zwykïy system w produkt jakoĂci przemysïowej z mocnymi spawami oraz Ărubami i nakrÚtkami zamiast tych wszystkich sznurków i taĂmy klejÈcej. Jest to powaĝny problem w starej sztuce okreĂlania oczekiwañ. Jeĝeli pozwolimy, aby siÚ to wymknÚïo spod naszej kontroli, moĝemy nigdy jej nie odzyskaÊ. Dziaïy operacyjne danej firmy nigdy 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 musimy przypominaÊ naszemu klientowi, ĝe to, co widzi, nie jest ukoñczonym produktem i ĝe do za- koñczenia pracy potrzeba jeszcze sporo czasu. Istnieje równieĝ poglÈd, aby nie dawaÊ uĝytkow- nikom dostÚpu do hurtowni danych do momentu zakoñczenia pierwszego etapu. ChoÊ niektórzy podzielajÈ to twierdzenie, osobiĂcie nadal podtrzymujÚ opiniÚ, ĝe uĝytkownicy powinni mieÊ dostÚp do hurtowni tak szybko, jak jest to moĝliwe. W koñcu sÈ to ich dane, a nie nasze. Silne zarzÈdzanie projektem i równie silne zarzÈdzanie oczekiwaniami sÈ tu kluczem do sukcesu. Przejděmy teraz do wsparcia. Wsparcie istnieje na kilku poziomach (tabela 9.9). Kaĝdy uĝytkownik ma specyficzne wymagania. WystÚpujÈ dwa gïówne rodzaje wsparcia: (1) Wsparcie uĝytkowników. W tym przypadku polega to na prowadzeniu telefonicznej linii pomocy lub dziaïu wsparcia uĝytkowników, który im pomaga, gdy majÈ pytania na temat systemu 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 aktualizacje oprogramowania systemowego i aplikacyjnego. Konieczne jest równieĝ wsparcie ogólnej natury, na przykïad przy rozbudowie przestrzeni dyskowej czy teĝ odtwarzaniu systemu po awarii sprzÚtowej lub programowej. 224 9. ZARZkDZANIE 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 US020 US030 Projektowanie procesów wsparcia Tworzenie procesów wsparcia Testowanie procesów wsparcia US010 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Ústo sÈ to uĝytkownicy, 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 pieniÈdze 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 nietkniÚte do koñca projektu i zwykle uwaĝane za jedno z najnudniejszych zadañ, choÊ w rzeczywistoĂci powinien mu byÊ nadany strategiczny 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 uzyskanie efektywnego rozwiÈzania trzeba wïoĝyÊ sporo pracy (tabela 9.10). WystÚpuje równieĝ problem wycofania. 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 etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni Kopie bezpieczeñstwa i odtwarzanie BR010 BR020 BR030 BR040 BR050 BR060 BR070 BR080 BR090 BR020 BR010 Projektowanie procesu tworzenia kopii zapasowej Tworzenie procesu tworzenia kopii zapasowej Testowanie procesu tworzenia kopii zapasowej Projektowanie procesu wycofywania danych Tworzenie procesu wycofywania danych BR040 Testowanie procesu wycofywania danych BR050 Projektowanie procesu ponownego wprowadzania danych Tworzenie procesu ponownego wprowadzania danych Testowanie procesu ponownego wprowadzania danych BR070 BR080 JAKIEGO ZESPO’U POTRZEBUJEMY? 225 Czym jest „ponowne wprowadzanie danych”? Jest to przeciwieñstwo wycofywania danych. Czasami okazuje siÚ, ĝe do hurtowni danych zostaïy zaïadowane nieprawidïowe dane. Zwykle siÚ dowiadujemy o tym, gdy ktoĂ z zespoïu operacyjnego przyjdzie do naszego biura i powie, ĝe jeden 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 ponownego wprowadzenia danych, aby umieĂciÊ w hurtowni prawidïowe dane (nie zapominajmy, ĝe te nowe dane 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 musi byÊ wykonywana automatycznie. Wykonywanie procesów oraz ustawianie ich w czasie i okreĂlanie zaleĝ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ĝ zakoñczy siÚ proces tworzenia pliku potrzebnego mu do pracy. ChoÊ plik ten moĝe byÊ dostÚpny, zaïóĝmy, o siódmej po poïudniu, to jednak nie ma gwarancji, ĝe siÚ tak stanie. Jeĝeli o umówionej godzinie plik nie bÚdzie dostÚpny, nie moĝemy uruchomiÊ procesu ekstrakcji. Harmonogramy mogÈ byÊ konfigurowane tak, aby reagowaïy na istnienie lub brak plikó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 wszystkich projektach IT. Tak jak w przypadku zespoïu wsparcia, zespóï operacyjny bÚdzie miaï wïasny zestaw wymagañ, czÚsto spisanych, które muszÈ byÊ speïnione przed przekazaniem mu systemu. Kolejnymi elementami, jakie musimy dostarczyÊ, sÈ monitorowanie i dostrajanie wydajnoĂci oraz planowanie pojemnoĂci. Naleĝy zarezerwowaÊ nieco czasu na tego rodzaju dziaïania. Nie ma sensu, aby dostarczaÊ system, który jednego dnia dziaïa doskonale, a w nastÚpnym zaczyna mu brakowaÊ pamiÚci, cykli procesora, przestrzeni dyskowych lub pasma sieciowego (tabela 9.11). Tabela 9.11. Zadania zarzÈdzania systemem Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni ZarzÈdzanie systemem SM010 SM020 SM030 SM040 Planowanie Szkolenie zespoïów operacyjnych Monitorowanie wydajnoĂci 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 jak duĝo ma dostÚpnej przestrzeni. Wiele Ăwietnie zaprojektowanych, dobrze skonfigurowanych i 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 koñcowego do przestarza- ïych komputerów klienckich. 226 9. ZARZkDZANIE PROJEKTEM Tabela 9.12. Zadania instalacji i wdroĝenia Numer etapu projektu Numer WBS Opis zadania ZaleĝnoĂci Osobodni Instalacja i wdroĝenie IR010 IR020 IR030 Przeprowadzenie szkolenia uĝytkowników Instalowanie komponentów uĝytkownika Testowanie konfiguracji oprogramowania uĝytkowników UA030 Tabela 9.13 zawiera kilka zadañ, jakie naleĝy wykonaÊ, zanim zespoïy programistyczne rozpocznÈ 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
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Projektowanie hurtowni danych. Wspomaganie zarządzania relacjami z klientami
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


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