Konceptualny model biznesowy (rys.2) tworzy się do zapisu wymagań funkcjonalnych, które powinien spełniać tworzony system. Model ten jest wynikiem współpracy przyszłych użytkow ników systemu, któ
rzy definiują swoje potrzeby dotyczące możliwości analizy danych oraz projektantów systemu, którzy starają się zapisać te potrzeby w formie sformalizowanego modelu. Warto zauważyć, że model konceptu
alny jest tworzony na poziomie języka ekonomii, a nie języka technolo
gii informatycznej, stąd przyjęło się nazywanie go modelem biznesowym.
Model biznesowy opisuje proces lub grupę procesów zachodzą
cych w realnym przedsiębiorstw ie. N a m odelu tym w yróżniam y następujące podstaw ow e obiekty:
O obiekty bazowe - tzw. tablice faktów lub tablice bazowe, O w ym iary i atrybuty w ym iarów ,
O pow iązania między atrybutam i wymiarów.
Tablice faktów (sprzedaż) przechowują informacje opisujące ilo
ściowo obserwow ane procesy ( ilość sprzedanych towarów w sztu
kach, sum a otrzym anych pieniędzy, itd.). W zależności od stopnia złożoności procesu, na modelu może znajdować się wiele tablic faktów (sprzedaż, stany magazynowe, stany kont księgowych).
Dla każdej tablicy faktów' ustala się tzw. poziom granulacji informacji, która będzie w nich przechowywana. Przyjęty poziom granulacji określa stopień szczegółowości informacji przechowywanej w hurtowni danych.
Decyzję o poziomie granulacji determinują wymagania stawiane systemo
wi przez końcowych użytkowników, którzy deklarują wymagany sto
pień szczegółowości danych, do jakiego będzie można dotrceć, korzystając z narzędzi systemu DSS. Dla procesów sprzedaży zazwyczaj przyjmuje się poziom granulacji odpowiadający pojedynczej transakcji zakupu do
konanej przez klienta. Innym rozwiązaniem może być przyjęcie poziomu sumarycznej sprzedaży produktu w danym dniu.
Atrybuty modelu biznesowego pozwalają na określenie obszarów' analizy inform acji przechow yw anej w tablicach faktów. Atrybuty związane z pojedynczym obszarem analizy łączy się w logiczne gru
py zwane wymiarami. Na rys.2 obecne są następujące wymiary:
O wymiar Czas obejmuje zagadnienia związane z analizą czasu, w któ
rym zachodzi proces,
O wymiar Geografia opisuje położenie geograficzne, w którym pro
ces ma miejsce,
O w ym iar Produkt sym bolizuje całościow y zbiór informacji po
wiązanych z produktem , który podlega sprzedaży, O wym iar Transakcja opisuje proces sprzedaży.
Liczbę i rodzaj atrybutów, które znajdują się w modelu bizneso
w ym , określa charakter opisyw anych procesów oraz w ym agania analiz, które będziemy chcieli przeprowadzać. O fakcie przypisania danego atrybutu do wymiaru powinien decydować stopień powiąza
nia danego atrybutu z pozostałym i atrybutam i wymiaru. Atrybuty
NOWE TECHNOLOGIE
A tr y b u t 1 ]
A t r y b u t 10
F a k ty
A tr y b u ( 2 0
A try b u t2 1
Model biznesowy
id a tr y b u t 1 o p s a tr v h n l 1
id a tr y b u t 10 o p js a try b u ! 10
id a tr y b ir
id atry b u t 10 id atrvbul20
fakt 1 id a tr y b u t2 0
n n ig n frv t id a try b u t2 1 o p j s _ a tr y b u t 2 1
u t2 0 t21
Model logiczny
id a t r v b u t l l o p is a t r y b u t l l
id a tr y b u t 10 o p is a tr y b u t 10
id _ a tr y b u t 11
id atrvbut21 opis_atrybut2
id a tr v b u t2 0 o n i s al);y.b»i20
121
partycja 01 id atry b u t 10 id atrvbut20
f a k tl
partycja 02
id atrvbutlO id atrvbut20
f a k tl
Schemat fizyczny
R ys. 1. E ta p y M o rze n ia sc h e m a tu h u rto w n i d a n ych
mocno pow iązane pow inny znaleźć się w tym sam ym w ym iarze (tak jak m iesiąc i dzień). Atrybuty nic zw iązane ze sobą, atrybuty słabo skorelowane i takie, między którymi zachodzi relacja wiele do wielu, pow inny zostać rozm ieszczone w oddzielnych w ym iarach.
Przytoczone zasady są tylko zaleceniem do procesu projektowania modelu i w szczególnych przypadkach można je pominąć.
wieloma regionami (rys.2). Relacje wyznaczają logiczne powiązania atrybutów w ramach wymiaru. Definicja relacji opisuje hierarchiczną zależność jednego atrybutu, tzw. dziecka ( np. regionu ) od drugiego, zw anego rodzicem (dla regionu będzie to m enedżer) oraz określa ilościową krotność zależności (1:1, 1:N, N :l, N:M). Znajdujące się na modelu biznesowym powiązania m iędzy atrybutami, w naturalny
Czas G eografia
T y p p ła tn o ś c i M ie s ią c
M e n a d ż e r
P ro d u k t
O ru p a
K a te g o r ia
P ro d u k t T r a n s a k c ja
R ys.2. S c h e m a t bizn eso w y h u rto w n i d a n y ch sy ste m u a n a lizy sp rzed a ży w sie c i sk le p ó w X
Tworzony model nazywa się modelem wielowymiarowym ponie
waż w modelu biznesowym występuje wiele wymiarów i istnieje możli
wość późniejszej analizy danych w wielu perspektywach (wymiarach).
Między atrybutami wchodzącymi w skład danego wymiaru za
chodzą pew ne relacje, np. m enedżer m oże zarządzać jednym lub
sposób definiują uporządkow ane hierarchie zależności (np. mene
dżer ■> region sklep). W ram ach w ym iaru m oże istnieć wiele hierarchii, hierarchie te mogą być jedno- lub wielopoziomowe, proste lub złożone (np. gdy pojedynczy atrybut-rodzic m a więcej niż jeden atrybut-dziecko).
informatyka 5/2000
35NOWE TECHNOLOGIE
Obok podstaw ow ych obiektów m odelu biznesow ego na przy
gotow yw anym diagram ie m ogą znaleźć się i inne obiekty, wśród których warto wspomnieć o tzw. cechach (qualities). Cechy pozwa
lają przechowywać dodatkową informację o analizowanym procesie, której nie da się łatw o przedstaw ić w postaci faktu lub atrybutu.
Często cechy przechow ują informację tekstow ą lub pewien rodzaj flagi. C harakterystyczną w łasnością cech jest ich występowanie na przecięciu wymiarów, stąd przypisano im też drugą nazwę - atrybu
tów m iędzyw ym iarow ych (cross-dim ensional attributes).
N a rys.2 znajdują się dwa obiekty oznaczające cechy: pogoda oraz p rom ocja. C echa pogoda określa typ pogody w ystępującej w danym dniu w danym regionie (słoneczna, deszczowa, opady śnie
gu), flaga promocji (T-TAK, N -NIE) przechowuje natomiast informa
cje o tym, czy dany towar w określonym dniu był sprzedawany po cenie promocyjnej. M iejscem przechowywania cech są tablice fak
tów lub też - przy braku tablic faktów na poziomie przecięcia w y
maganych atrybutów - specjalnie tworzone tablice cech (o charakterze tablic bazowych). Ta właściwość podobieństwa cech do faktów ta
blic bazowych powoduje, że spotyka się jeszcze inną ich nazw ę - faktów tekstowych (text facts).
Analizując obiekty modelu biznesowego w kontekście całego pro
jektu, można wskazać następujące powiązania między nimi a fizycz
nymi obiektami hurtowni danych (bazy danych) oraz aplikacjami DSS:
O tablice faktów zostaną zaim plementowane jak o tablice bazowe hurtowni danych,
O fakty będą podstaw ą do budow y tzw. m etryk, z pom ocą k tó
rych aplikacja DSS będzie wyświetlała na raportach informacje ilościowe,
O wym iary i atrybuty pozw olą użytkow nikow i aplikacji D S S na zdefiniowanie wyglądu i poziomu szczegółow ości raportu oraz na kwalifikowanie w yników raportów (narzucanie ograniczeń, filtrowanie według jednego lub większej liczby atrybutów); można przyjąć, że wymiary będą kwalifikowały obliczenia na pewnym uogólnionym poziom ie (np. wszystkich produktów ), a atrybuty na poziom ach odpow iednio niższych (np. na poziom ie g ru p y produktów)-, atrybuty wym iarów będą zaimplementowane z po
m ocą tzw. tablic wymiarów,
O relacje zachodzące między atrybutami będą definiowały ścieżki prze
glądania oraz analizy danych - ich rozwijania (drill down) i zwijania (drill up),
O elem enty atrybutów - czyli w ystępujące w św iecic rzeczyw i
stym wartości atrybutów ( np. nazwiska menedżerów ) - pozwo
lą na dokonanie filtrowania wyników raportów; każdy element jest atomowym komponentem modelu danych i jest przechowy
wany jako rekord w odpowiedniej tablicy wymiaru,
O cechy mające własności faktów i atrybutów - można będzie wyko
rzystywać do grupowania wyników na raportach (np. porównanie sprzedaży towarów w promocji i zwykłej sprzedaży) oraz do kwa
lifikowania wyników raportów (np. sprzedaż w dni słoneczne).
Podsumowując opis konceptualnego modelu biznesowego, moż
na stwierdzić:
O m odel powstaje w' wyniku w spółpracy użytkow ników końco
w ych oraz projektantów system u.
O model w uporządkowany sposób zbiera w sobie wymagania funk
cjonalne systemu jako systemu wiedzy biznesowej (Business In
telligence),
O model pomaga zrozumieć specyfikę procesów zachodzących w przed
siębiorstwie, i sposób analizy tych procesów (wymiary, atrybuty, hierarchie),
0 model dokładnie określa zakres raportów, które można wykonać, i analiz, które można przeprowadzić.
Przy tw orzeniu m odelu biznesow ego zaw sze należy brać pod uwagę rzeczyw iste warunki, w których będzie pracow ał stworzony na jeg o podstaw ie system . M odel ten nie m oże być zbyt złożony 1 musi uwzględniać wymagania dotyczące wydajności całego systemu oraz przyszłych kosztów jego administracji. W szczególności należy przeprowadzić analizę dostępnych źródeł danych i odpowiednio okre
ślić możliwości budowy modelu wielowymiarowego. N ie ma sensu budować modelu, którego nie będzie można wypełnić danymi, bo brak ich w systemach transakcyjnych. Już na tym etapie ważne jest okre
ślenie złożoności procesu ekstrakcji, poparte analizą struktur i zawar
tości tablic system ów transakcyjnych. Koniecznie należy zapoznać się nie tylko z dostępną dokum entacją, ale również sprawdzić stan faktyczny systemów. Tutaj też należy udokumentować wszelkie nie
zgodności w danych i problemy danych niepoprawnych (dirty data).
Model logiczny
M odel logiczny hurtow ni danych pow staje na podstaw ie m odelu biznesowego. Celem etapu tworzenia modelu logicznego jest budowa takiego schem atu danych, który im plem entując model biznesow y, m ógłby być jed n o cześn ie efektyw nie w ykorzystany p rzez sto so wane narzędzia systemu DSS. W dalszej części artykułu dokładniej opisano rozwiązania budowy modelu logicznego stosowane w tech
nologii ROLAP (Relational OLAP), która obecnie ma najlepsze cha
rakterystyki wydajnościow e i funkcjonalne [4],
N a etapie budowy modelu logicznego liurtowni danych dokonu
je się proces projektowania struktury tablic modelu: określa się ich nazwy, nazw y kolumn, typy danych, definicje kluczy. Dodatkowe zadania, które rozwiązuje zespół projektujący model obejmują:
O określenie stopnia normalizacji modelu - przyjęcie jednego z dwóch standardowych modeli logicznych: modelu gwiazdy lub modelu płatka śniegu,
O ustalenie jednolitego nazew'nictw'a tablic, atrybutów i typów da
nych,
O określenie sposobu implementacji relacji zachodzących między atrybutami - w szczególności relacji M:N i M :l, O określenie koniecznych atrybutów transformacji czasu, O przyjęcie sposobu rozw iązania:
• analiz operujących na przedziałach atrybutów,
• analizy koszyka sprzedaży,
• budowy struktur rekurencyjnych i niepełnych/zmienych hie
rarchii,
• przechow yw ania historii wymiarów.
W wyniku procesu tworzenia modelu logicznego powinien po
wstać pełny schemat logiczny wszystkich tablic hurtowni danych.
Schemat ten powinien być zoptym alizow any pod wymagania syste
mów typu ROLAP. Istnieją dwa standardowe m odele danych reali
zujące ten postulat: model gwiazdy oraz model płatka śniegu. Modele tc wyróżniają się spośród innych wydajnością, prostotą i uniwersal
nością oraz efektywnością składowania informacji. Podstawowe struk
tury budowane są w oparciu o dwa rodzaje tablic:
O tablice faktów (fact lables, base tables), O tablice wymiarów (lookup tables).
Tablice faktów obu modeli są bardzo podobne i zawierają:
O sztuczne klucze identyfikujące - klucze obce migrujące do tabli
cy z tablic wymiarów, O fakty,
O opcjonalnie inne dodatkowe elementy, takie jak np. cechy.
Modele gwiazdy i płatka śniegu zasadniczo różnią się sposobem implementacji tablic wymiarów - model gwiazdy stosuje tablice nie- znormalizowane, natomiast model płatka śniegu - tablice w pełni lub częściowo znorm alizow ane. D latego też w podstawowym m odelu gw iazdy w szystkie atrybuty danego w ym iaru są przechow yw ane w pojedynczej tablicy, a w modelu płatka śniegu, każdy atrybut ma własną tablicę. Wyróżniamy kilka odmian obu modeli, a najpopular
niejsze z nich przedstawia rys.3 [6],
Tablica wymiaru w modelu gwiazdy zazwyczaj przechowuje:
O numeryczny, sztuczny klucz identyfikujący, np. klucz jg e o , O pola opisów atrybutów (zazw yczaj tekstow e), np. opis_sklep,
opis_region, opis menedżer,
O dodatkow e, tekstowe lub num eryczne pola opisujące, np. typ sklepu, wojwództwo,
O numeryczne pole poziom wskazujące na poziom granulacji prze
chow yw anych danych (jeden z dw óch m ożliw ych sposobów implementacji agregacji).
Tablica w ym iaru w m odelu płatka śniegu zazwyczaj przecho
wuje:
O numeryczny, unikalny klucz atrybutu (identyfikator), np. id_sklep, O opis atrybutu (zazw yczaj tekstow y), np. opis sklep; czasami, gdy opis pola jest równoznaczny z jego identyfikatorem i wystar
czająco czytelny dla użytkownika, to można z pola opisu zrezy
gnować (np. przypadku atrybutu rok),
O numeryczne klucze atrybutów rodziców (klucze obce), np. i d j e - gion, idjnenedżer, id typ, id_województwo; pola tego typu nic
w ystępują w tablicach atrybutów znajdujących się na szczycie hierarchii.
Dodatkow a w m odelu płatka śniegu często pojaw iają się tzw.
tablice relacji (relation tables). Tablice tc opisują powiązania między atrybutam i modelu.
Drugim wynikiem tego etapu tworzenia modelu logicznego - obok schematu danych - pow inno być opracow anie m apy transform acji danych z systemów źródłowych do hurtowni.
Schemat fizyczny
Schemat tablic logicznego modelu wielowymiarowego jest podstawą do wygenerowania modelu fizycznego, który' implementujemy w hurtów™
danych. Przy realizacji modelu fizycznego należy wziąć pod uwagę:
O specyficzne własności używanej platformy sprzętowo-programo
wej, a zwłaszcza systemu zarządzania bazą danych - schemat nale
ży zoptym alizow ać z w ykorzystaniem technik dostępnych w danym systemie; dla modelu należy szczegółowo określić parame
try fizyczne struktur bazy danych (np. w Oracle, takie jak; rozmiar początkowy ekstentu, parametry PCTFREE, PCTUSED i inne), O sposób indeksacji,
O sposób optymalizacji dostępu do danych przy uwzględnieniu naj
częstszych sposobów' dostępu do hurtowni przez użytkowników, O sposoby zw iększenia efektyw ności pracy system u przy w yko
rzystaniu technik agregacji i partycjonowania danych ( na pozio
mie bazy danych lub aplikacji),
O rozpatrzenie i efektyw ną im plementację m echanizm ów bezpie
czeństw a i ograniczenia dostępu do danych ( np. poprzez per
spektyw y b ezp ieczeń stw a),
O optym alizację system u pod kątem stosow anych narzędzi eks
trakcji.
G eo g ra fia
klucz geo S klep
opis_sklep id sklęp
opis_region opis_skłcp
opis_m encdżcr id_region
w ojew ództw o id m enedżer
typ id_typ
poziom id^w oiew ództw o
R egion M e n a d że r
!d_EgJiffi id m enedżer
opis_region opis_m enadżer id_nienadżer
XI
Sprzedaż Sprzedaż
klucz czas data
klucz produkt id sklep
klucz geo id produkt
sprzedaż_\v PLN sprzedaż w PLN
sprzedaż_ilość sprzedaż ilość
W ojew ództw o id w ojew ództw o onis w ntew ód/iw o
Im
id tvp opis„typ
Rys.3. S c h e m a ty w ym ia ru G e o g ra fia : g w ia zd a i p ła te k śn ie g u
informatyka 5/2000
37NOWE TECHNOLOGIE
Wszystkie ww. aspekty modelu fizycznego powinny zostać w miarę wcześnie przeanalizowane. Implementacja konkretnych rozwiązań może zostać odsunięta w czasie i jest zazwyczaj wykonywana po wdrożeniu prototypu systemu i przeprowadzaniu jego analizy wydajnościowej.
U zyskany schemat powinien być stosunkowo prosty w zarządzaniu i pozwalać przyszłemu użytkownikowi systemu DSS na efektywną reali
zację wymagań funkcjonalnych modelu biznesowego.
Implementacja modelu fizycznego pozwala na zakończenie eta
pu budowy podsystemu ekstrakcji i transformacji danych ETL oraz otwiera etap projektowania aplikacji końcowego użytkownika.