|
Sukces projektu hurtowni danych jest ściśle związany z zaangażowaniem
jej przyszłych użytkowników oraz kierownictwa i ekspertów firmy. To
oni muszą zdecydować, jakie tematy będzie obejmował system oraz jakie
aplikacje będą im niezbędne do pracy. Zazwyczaj jest tak, że sami użytkownicy,
będący fachowcami w danej branży (np. analitycy finansowi), potrafią
najefektywniej wydobyć interesujące ich informacje. Z kolei bez
przychylności i zaangażowania kierownictwa i ekspertów ponoszących
odpowiedzialność za proces tworzenia hurtowni danych nie można myśleć
o jej rozbudowie o kolejne elementy. To nie konkretna technika sprawia, że
hurtownia danych jest udana, ale zrozumienie zadań biznesowych i potrzeb
użytkownika końcowego. Do innych przyczyn niepowodzeń projektów można
zaliczyć:
-
brak
dobrego uzasadnienia projektu,
-
źle
określony cel i produkt końcowy,
-
brak
kryteriów i standardów wykonania projektu,
-
złe
planowanie, monitorowanie i kontrolowanie realizacji projektu,
-
nieuwzględnienie
w projekcie zagrożeń i rezerw,
-
brak
procedury wprowadzania zmian.
Poniżej
przedstawiono wnioski z badania ryzyka projektu wdrożenia hurtowni
danych. Wykorzystuje ona katalog czynników powtarzalnych. Zespół
ekspertów zdefiniował potencjalne zagrożenia i sklasyfikował je w
kategorie [1]:
-
wpływ
czynników zewnętrznych,
-
czynniki
organizacyjne,
-
ryzyko
związane z planowaniem,
-
zagrożenia
definicji biznesowych,
-
technologia,
-
jakość
danych.
Ocena
ww. wskaźników ujawnia ryzyko na etapie planowania, kontroli zmian,
definicji potrzeb użytkowników. Okazuje się, że największym ryzykiem
obarczone są czynniki zewnętrzne, ponieważ przedsięwzięcie budowy
hurtowni danych wymaga wyspecjalizowanego personelu. Gdy w trakcie
projektu wdrożenia hurtowni danych dział IT prowadzi inne projekty, wówczas
ryzyko niepowodzenia gwałtownie rośnie. Ten fakt przyczynia się do
powstania problemów z przydziałem pracowników do poszczególnych zadań
oraz bieżącej obsługi działalności operacyjnej przedsiębiorstwa. Do
innych czynników z tej grupy można zaliczyć: poziom zaangażowania zewnętrznych
środków oraz doświadczenie we współpracy z firmą, która bierze
udział w projekcie.
Ryzyko
organizacyjne okazuje się niewielkie, gdyż kadra menedżerska zazwyczaj
w dużym stopniu angażuje się w przedsięwzięcie. Badacz metod wdrażania
hurtowni danych - B. Shin wskazuje czynnik zagrożenia, którym jest niechęć
do zmian. Dlatego należy położyć duży nacisk na edukowanie personelu,
którego wdrożenie bezpośrednio dotyczy. Inne niebezpieczeństwa z tej
grupy to: poziom zmian w procedurach pracowniczych i ilość lokalizacji
objętych wdrożeniem.
W
projekcie budowy hurtowni danych ryzyko wynikające z użytej technologii
zostało ocenione wyżej aniżeli organizacji i planowania. Powodem może
być użycie dużej ilości systemów i interfejsów pomiędzy nimi. Wg
Oracle odpowiedni projekt i realizacja bazy danych, która stanowi podstawę
hurtowni danych ma duże znaczenie. Właściwa architektura i projekt
zapewniają odpowiednią wydajność w przyszłości. Ważne jest również
zapewnienie odpowiedniej elastyczności, która jest dogodna dla użytkownika.
Jako kolejny czynnik wskazano złożoność hurtowni danych oraz doświadczenie
kadry IT w obsłudze wybranego systemu. Istotny jest również problem
szybkości wydobywania informacji z baz analitycznych o dużych
rozmiarach. Zadanie pytania trwa w takich systemach bardzo długo. Tak więc
należy określić mechanizmy selekcji rekordów przed wprowadzeniem ich
do hurtowni danych tak, ażeby dane znajdujące się w bazie analitycznej
nie były nadmiarowe. Pojawia się również problem zmiany indeksowania pól
w hurtowniach danych, względem źródłowej bazy danych, pod kątem
optymalizacji zapytań.
Ostatnią
grupą, ale nie mniej ważną są zagrożenia związane z definicjami
biznesowymi. Najważniejszym czynnikiem jest ilość obszarów objętych
wdrożeniem oraz aktualność dokumentacji definicji biznesowych. To właśnie
od nich zależy szybkość tworzenia hurtowni danych. Gdy mamy do
dyspozycji kompletną dokumentację możemy uniknąć wielu błędów
podczas odzwierciedlania bazy operacyjnej na hurtownię danych. Inne zagrożenia
to: duża częstotliwość zmian w procesach, błędne dane. Dużym
problemem jest również nie sprecyzowanie modeli biznesowych procesów
podejmowania decyzji w zarządzaniu strategicznym. Pozostaje opracowanie
stosownych modeli i zaimplementowanie ich w systemach wspomagania decyzji
bazujących na hurtowniach danych. Do dalszego rozwoju można poddać również
definiowanie mechanizmów kontrolnych realizacji strategii marketingu. Mam
tu na myśli identyfikację zestawu stosownych wskaźników i niezbędnych
zestawień oraz raportów ułatwiających proces kontroli, a jednocześnie
dający kompendium wiedzy o stanie firmy.
Analitycy
zajmujący się budową hurtowni danych zidentyfikowali problemy dotyczące
w głównej mierze jakości danych. Jest to jeden z najważniejszych
czynników wpływających na jakość produktu końcowego. Do najczęściej
spotykanych problemów związanych z tą tematyką należą [2, 3, 4, 5]:
-
Niekompletność
danych:
-
brakujące
rekordy (powinny się znajdować w systemach źródłowych, a ich
brakuje; zostały ujęte w projekcie hurtowni danych),
-
brakujące
pola (to te, które są oczekiwane, a ich nie ma; mają najczęściej
miejsce, gdy systemy źródłowe nie żądają wpisania pewnych
danych, które zostały ujęte w projekcie hurtowni danych),
-
pola
lub rekordy, które nie zostały ujęte w trakcie projektu (dane,
które mają być zapisane w hurtowni danych i nie zostały
zapisane nigdzie w systemach źródłowych).
-
Niepoprawne
rekordy:
-
błędne
obliczenia, agregacje występujące (gdy wczytywane dane są
przeliczane lub agregowane poza hurtownią danych),
-
zdublowane
rekordy (wynikające z nieprawidłowego zapisu w bazie danych lub
z niewłaściwych relacji pomiędzy tabelami w trakcie procesów
ETL),
-
błędny
kod (dotyczy sytuacji, gdy w różnych okresach ten sam kod
oznaczał co innego, np. w 1968 roku 100 oznaczał kod naprawy części,
natomiast obecnie posiada inne znaczenie),
-
błędne
informacje w systemach źródłowych z winy operatora (są związane
z błędami wprowadzania danych do systemów źródłowych; można
wyodrębnić dwa typy tych błędów; pierwsze z nich powstają w
wyniku pomyłki; jest to sytuacja w której osoba wprowadzająca
dane zna prawidłowe wartości, natomiast omyłkowo wprowadziła
inne; drugie powstają w wyniku nieświadomości operatora
(sytuacja w której osoba wprowadzająca dane jest przekonana, że
wartości które wprowadza są prawidłowe podczas gdy tak nie
jest)). Do tej kategorii można zaliczyć:
-
błędne
wartości i ich zakresy (błędy powstałe na skutek braku
kontroli przez system wprowadzanych danych),
-
integralność
(brak zgodności danych z ich opisem),
-
rozmiar
pola (np. niepoprawna długość tekstu),
-
typ
danych (niezgodność wprowadzanych danych z typem pola),
-
obligatoryjność
(nie powinna istnieć możliwość pozostawienia pustego pola
w miejscu gdzie jest wymagane).
-
nieprawidłowe
(nie arytmetyczne) relacje pomiędzy atrybutami (dotyczy przypadków
nie arytmetycznych relacji między atrybutami gdzie oczekujemy stałych
reguł np. jeżeli sufiks numery seryjnego jest XXX wówczas kod
kategorii powinien należeć do przedziału {A,B,C}),
-
zdublowane
atrybuty (ten sam atrybut pojawia się kilkukrotnie w jednym
obiekcie; prowadzi to do sytuacji, w której nie można określić
który jest prawidłowym źródłem dla hurtowni danych),
-
błąd
klucza podstawowego (każda tabela powinna zawierać klucz
podstawowy, który musi być unikatowy).
-
Niezrozumiałe
dane:
-
podczas
tworzenia wielu pól w hurtowni danych z jednego w systemie źródłowym
(gdy z jednego pola w bazie źródłowej ma powstać wiele w
hurtowni danych np. Joe E. Brown -> Joe, E., Brown),
-
błędne
formatowanie (wynikłe np. z chęci zaoszczędzenia przestrzeni
dyskowej przez programistę),
-
błędy
w trakcie ładowania danych z plików źródłowych nie posiadających
struktury bazy danych (Excel, Word, ..),
-
transfer
z systemów źródłowych przy użyciu plików hierarchicznych (z
powodu łatwości transferu danych w ten sposób należy zwrócić
uwagę na ich poprawność i powtarzalność),
-
niezrozumiała
zawartość rekordu (kod trudny do zidentyfikowania np. z powodu
nienależytego opisu lub starego zapisu),
-
Niezgodność
danych:
-
niezgodne
kodowanie w różnych systemach (np. oznaczenia płci w różnych
systemach),
-
niezgodność
znaczenia kodu w czasie (np. w różnych latach sklep należał do
różnych sieci i istniał pod różnymi numerami stąd pytanie
jak zidentyfikować sprzedaż tego sklepu),
-
pokrywające
się dane (w różnych systemach transakcje z tym samym klientem
odbywały się z użyciem różnych kodów klienta),
-
błędne
odwzorowanie kodów w hurtowni danych (np. w systemach źródłowych
oznaczono dwa kolory, natomiast w hurtowni danych widnieją jako
jeden),
-
niezgodne
nazwy i adresy (wyszukiwanie i ustanawianie relacji po nazwie lub
adresie jest zgodne w około 80%),
-
niezgodne
reguły biznesowe (np. obliczenia w bazach źródłowych i
hurtowni danych),
-
niezgodność
danych sumarycznych (najczęściej ma miejsce, gdy podsumowań
dokonuje użytkownik),
-
niezgodność
danych na poziomie atomowym (brak możliwości przeprowadzenia
analiz porównawczych przez brak powiązań np. zyskowności
klienta i produktu),
-
niezgodność
czasowa (gdy dane w bazie źródłowej podlegają innym regułom
czasowym niż analiza tych danych z hurtowni danych, np. zakupy
dokonywane tygodniowo natomiast analizowane miesięcznie),
-
niezgodne
użycie atrybutów (w systemach źródłowych może występować różne
użycie atrybutów encji w zależności od potrzeby np. inne konto
księgowania sprzedaży netto w różnych procesach, dla tego
samego klienta),
-
niezgodność
daty (podczas integracji różnych systemów źródłowych błędne
połączenie daty),
-
niezgodne
użycie stringów, spacji, pól pustych,
-
brak
zgodności odnośników w danych (np. w relacjach),
-
brak
synchronizacji danych (np. w różnym czasie są aktualizowane różne
tabele powiązane ze sobą).
Na
podstawie tak zdefiniowanych problemów można wnioskować, że istnieje
duża potrzeba zastosowania odpowiednich technik, które pomogą
przeciwdziałać opisanym problemom. Zarysowane zagrożenia występują na
każdym etapie trwania projektu. Dlatego istotne jest przeciwdziałanie w
sposób metodyczny i przemyślany a nie stosowanie metod doraźnych. Z
pomocą wychodzą tu metody budowy hurtowni danych. Druga część artykułu
będzie stanowić o sposobach przeciwdziałania problemom napotkanym w
procesie budowy systemu hurtowni danych.
Literatura:
[1]
Summer E., Ali D.: A practical guide for implementing data warehousing,
Computers Ind. Engng, Volume 31, No. 1, 1996
[2] www.dwinfocenter.org, 2004
[3] Bałaga Z.: Hurtownie czwartkowe, Materiały szkoleniowe Hogart,
Warszawa, 2001
[4] Twidale M.B., Marty P.F.: An investigation of data quality and
collaboration, Technical report ISRN UIUCLIS-1999/0+CSCW, 1999
[5] www.dataqualitymodeldocument.com, 2004 |