Dr hab. Marek J. Greniewski Profesor nadzwyczajny WSM-SIG

Wprowadzenie

• Lata sześćdziesiąte – osiemdziesiąte XX wieku to gwałtowny

rozwój zastosowań informatyki w zarządzaniu firmami.

• Większość tych zastosowań dotyczyła wspomagania wybranych

funkcji zarządzania, takich jak:

– Rachunkowość i finanse;
– Ewidencja osobowa i płace;
– Gospodarka zapasami;
– Planowanie potrzeb materiałowych (systemy MRP);
– Planowania produkcji, gospodarowanie zapasami, planowanie sprzedaży i

zakupów (systemy MRP II).

• W tym okresie, powstała jedna z zasadniczych technologii

informatycznych, tj. systemy baz danych, a w szczególności

relacyjnych baz danych, która to technologia otworzyła

możliwości dalszego rozwoju zastosowań informatyki.

• Rozwój informatyki (lata sześćdziesiąte – osiemdziesiąte XX

wieku) doprowadził do powstania szeregu „wysp informatyzacji”

w firmach, zostawiając wiele obszarów firmy - poza sferą

bezpośredniego oddziaływania informatyki.

Likwidacja „wysp

informatyzacji” I

• Pomysł Data Warehouse, pochodzący od amerykańskiego informatyka

Billa Inmona, zakładał zbudowanie specjalnych baz danych

zawierających historyczne dane o prowadzonym przez firmę biznesie

(szeregi czasowe uśrednionych danych dla okresów), obejmujący sfery

podaży i popytu.

• Historyczne dane o prowadzonym przez firmie biznesie, to zapisy

transakcji odpowiadających tzw. zdarzeniom, jakie miały miejsce w toku

realizacji poszczególnych procesów biznesowych firmy, zarówno

wewnątrz firmy,

jak i w jej otoczeniu.

• Przykładowo, jeśli ograniczymy nasze rozważania do prywatnych szkół

wyższych - to zdarzeniami, którym towarzyszą transakcje, są między

innymi:

– Zarejestrowanie kandydata na studia w toku prowadzenia rekrutacji, wraz z jego

danymi osobowymi oraz wyborem kierunku, czyli określenie programu studiów

kandydata;

– Wniesienie opłaty rejestracyjnej i czesnego przez kandydata - za pierwszy semestr

studiów, powodującej przekształcenie kandydata na studia w studenta;

– Wydanie nowo przyjętemu studentowi indeksu;
– Rejestracja kolejnych zaliczeń przedmiotów i wyników egzaminów studenta;
– Rejestracja opłat czesnego za kolejne semestry i innych opłat wnoszonych przez

studenta.

Likwidacja „wysp informatyzacji”

• W odróżnieniu od tabel danych zawartych w BD - informatycznych

systemów operacyjnych (czyli wspomagających zarządzanie operacjami i

zarządzanie taktyczne), Data Warehouse zawiera dwa typy tabel: tzw.

tabele faktów (fact tables) i tzw. tabele wymiarów (dimensional tables).

• Przykładowo, jeśli ograniczymy nasze rozważania do prywatnych szkół

wyższych, to będziemy mieli pięć tabeli faktów. A mianowicie:

– „Studenci”. Tabela faktów zawierająca klucze podstawowych danych o

studentach oraz flagi statusu każdego z nich;

– „Grupy studenckie”. Tabela faktów zawierająca klucze podstawowe danych o

poszczególnych grupach studenckich oraz flagi statusu każdego z nich;

– „Wykładowcy”. Tabela faktów zawierająca klucze podstawowych danych o

nauczycielach akademickich oraz flagi statusu każdego z nich;

– „Przedmioty nauczania”. Tabela faktów zawierająca klucze podstawowych

danych o przedmiotach nauczanych w szkole oraz flagi statusu każdego z nich;

– „Programy nauczania”. Tabela faktów zawierająca klucze podstawowych

danych o programach nauczania wraz ze specjalnościami oraz flagi statusu

każdego z nich.

• Tabele faktów, mogą zawierać wzajemne odwołania. Np. poszczególni

studenci - są przypisani do grup studenckich. Każdy student, może należeć

np. - tylko do jednej grupy dziekańskiej i kilku grup ćwiczeniowych.

Likwidacja „wysp

informatyzacji” III

• Z kolei tabele wymiarów, mogą mieć w - szczególności postać -

tzw. wielowymiarowych kostek danych, czyli wymagają wówczas
systemów RDBMS o dodatkowej funkcjonalności.

• Przykładowo, jeśli ograniczymy nasze rozważania do prywatnych

szkół wyższych, to tabeli faktów „studenci” – będą dołączone
następujące tabele wymiarów:

– „Jednostki czasu”. Tabela jednostek czasu zawiera kalendarz jednostek czasu (np.

w układzie kolejnych dat i numerów semestrów), w stosunku do których zbierane są
dane o zdarzeniach;

– „Dane studenta”. Tabela zawierająca dane osobowe poszczególnych studentów

(imiona, nazwisko, data urodzenia, płeć, imię ojca, adres zamieszkania, datę
rozpoczęcia studiów, stan cywilny i ew. datę zawarcia związku itp., oraz numer
albumu);

– „Dane szkoły średniej”. Tabela zawierająca dane szkół średnich, w których

studenci uzyskali świadectwo maturalne.

– „Czesne i inne opłaty”. Tabela zawiera dane o wszystkich wpłatach dokonywanych

przez każdego ze studentów, z uwzględnieniem podziału czesnego na raty, np.
według rodzaju przyznanego, zgodnie z regulaminem opłat czesnego, przez kanclerza
szkoły – rozkładu
czesnego na raty

– „Wyników nauki”. Tabela zawiera dane o wynikach uzyskiwanych przez każdego

studenta.

Definicje

• Data Warehouse – zbiór danych zorientowanych tematycznie,

wewnętrznie zintegrowany, rosnący wraz z upływem czasu, służący

np. wspomaganiu podejmowania decyzji przez kierownictwo firmy

(korporacji). Definicje wszystkich danych zawartych w Data

Warehouse, składają się na tzw. Meta-Dane (Metadata).

• Data Mart – jest typem Data Warehouse zaprojektowanym dla

potrzeb wybranej grupy użytkowników (np. zarządu dywizji

korporacji) z wybranej jednostki organizacyjnej firmy. Na ogół Data

Mart dotyczy jednej wybranej dziedziny np. sprzedaży.

• Executive Information System (EIS) – zbiór raportów tworzonych

na podstawie zawartości Data Warehouse wspomagających

podejmowanie decyzji opartych o wstępnie zdefiniowane modele.

• Data Mining – narzędzie do tworzenie z danych surowych – opisów

zdarzeń: tabel faktów oraz wielowymiarowych kostek danych Data

Warehouse.

• On-Line Analytical Processing (OLAP) – narzędzia do

przetwarzania (analizy) wielowymiarowych kostek danych Data

Warehouse.

Przykład tabeli faktów

„Studenci”

• Tabela faktów „Studenci” zawiera następujące atrybuty:

– Klucz_studenta (identyfikator studenta), klucz tabeli wymiarów „Dane

studenta”;

– Klucze_przedmiotów, grupa kluczy do tabeli wymiarów „Wyniki nauki”;
– Klucz_wpłaty, jeden z kluczy tabeli wymiarów „Czesne i inne opłaty”;
– Klucz_szkoły, jeden z kluczy tabeli wymiarów „Dane szkoły średniej”;
– Klucz_czasu, klucz tabeli wymiarów „Jednostki czasu” oraz jeden z kluczy

wielu tabel;

– Status na koniec semestru;
– Flaga uzyskania dyplomu;

• Wybieranie danych dotyczących danego studenta, np.

dotyczące wpłat, odbywa się za pomocą kluczy:

(1) Klucz_studenta, (2) Klucz_wpłaty i (3) Klucz_czasu.

Powoduje to, wybranie oraz wyświetlenie - dla wskazanego

studenta oraz numeru semestru, wysokości wniesionych wpłat i

całości rozliczenia pomiędzy studentem i szkołą.

• Liczba wierszy (n-tupel) tabeli faktów „Studenci” jest równa

liczbie wszystkich studentów danej szkoły.

Przykład tabeli wymiarów

„Dane

studenta”

•

Tabela wymiarów „Dane studenta”, zawiera np.- następujące

atrybuty:

– Klucz_studenta (identyfikator studenta),
– Imiona;
– Nazwisko;
– Data urodzenia;
– Płeć (K – kobieta, M – mężczyzna);
– Imię ojca;
– Adres zamieszkania;
– Data rozpoczęcia studiów;
– Stan cywilny;
– Data zawarcia związku małżeńskiego (nie dotyczy samotnych);
– Numer albumu.

•

Wybranie danych wskazanego studenta, wymaga użycia tylko

jednego klucza – identyfikatora studenta.

•

Tabela wymiarów „Dane studenta” jest kostką dwuwymiarową,

czyli tabelą zawierającą liczbę wierszy (n-tupel) równą liczbie

studentów.

Przykład tabeli wymiarów

„Wyniki

Nauki”

Uwaga:

Liczba tabel RBD odpowiadających trójwymiarowej

kostce ocen,

jest równa liczbie semestrów objętych działalnością szkoły.

Przedmioty

(zaliczenia i egzaminy)

Trójwymiarowa kostka ocen

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Tabele RBD odpowiadające
trójwymiarowej kostce ocen

Dla wyszukania wyniku należy
użyć następujących identyfikatorów:
klucz_studenta, klucz_czasu oraz
klucz_przedmiotu.

Zasada działania programu

Data Mining

•

Surowe dane przeznaczone do zasilania Data Warehouse są

rekordami o poszczególnych zdarzeniach (czyli są to dane

transakcyjne), np. dotyczących wpłat czesnego przez

konkretnego studenta.

•

Program Data Mining pobiera kolejny rekord zdarzeń np.

dotyczący danego studenta (w naszym przykładzie - jeden

rekord tabeli faktów odpowiada jednemu studentowi):

1. Sprawdza czy student o danym kluczu_studenta posiada już rekord w

tabeli faktów, jeśli taki rekord nie istnieje w tabeli faktów, to Data Mining

tworzy nowy rekord z nowym kluczem_studenta zostawiając miejsce na

pozostałe klucze odwołań do tabeli wymiarów, ustawiając jedynie flagi;

2. Następnie w zależności od rodzaju zdarzenia wstawia do rekordu

odpowiadającemu danemu studentowi - wartości kluczy dotyczące

danego zdarzenia do rekordu w tabeli faktów;

3. Kolejnym krokiem, jest sprawdzenie czy istnieje tabela wymiarowa,

odpowiadająca rejestrowanemu zdarzeniu, jeśli takiej tabeli niema, to

Data Mining ją tworzy;

4. Ostatnim krokiem obsługi pojedynczego rekordu zdarzenia, jest

utworzenie rekordu odpowiadającego zdarzeniu w tabeli wymiarowej;

•

Jeśli jest to ostatni rekord surowych zdarzeń, to program Data

Mining kończy działanie.

Zasada działania

programu OLAP

• Prostym przykładem

zastosowania programu OLAP,
jest wyliczenie średniej oceny
uzyskiwanej przez studentów w
okresie kilku kolejnych
semestrów.

• Program OLAP sprawdza kolumnę

ocen (atrybutów), zliczając liczbę
wystawionych ocen, czyli
odrzucając dane studentów,
którzy z jakichś powodów nie
zdawali egzaminu z wybranego
przedmiotu, sumuje oceny, a
następnie wyznacza średnią
ocenę z przedmiotu.

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Lista przedmiotów

(danego semestru)

Oceny zaliczeń

i egzaminów

Tabele RBD odpowiadające
trójwymiarowej kostce ocen

Wybrany przedmiot, któremu

odpowiada ten przekrój

Cel wprowadzenia Data

Warehousing

• Jak już wcześniej zostało powiedziane jednym z celów

wprowadzania technologii Data Warehousing, była chęć

zbudowania narzędzi informatycznych umożliwiających

wspomaganie podejmowania decyzji,

a w szczególności decyzji strategicznych, w oparciu o dane

dotyczące przeszłości.

• Przedstawione wycinkowe przykłady dotyczące Data Warehouse

między innymi, studentów prywatnej szkoły wyższej, nie są

dobrym unaocznieniem faktu przydatności technologii Data

Warehousing do wspomagania podejmowania decyzji

strategicznych.

• Technologia Data Warehousing zakłada okresowe, ale nie

transakcyjne, aktualizowanie bazy danych Data Warehouse –

zarówno danymi z transakcji - dotyczącymi zdarzeń

zachodzących wewnątrz firmy, jak również zdarzeniami

występującymi w otoczeniu firmy.

E – Extracting (Data

Acquisition)

• Źródłem zasilania każdego Data Warehouse, są systemy

dziedzinowe wspomagania działalności operacyjnej firmy
(co już zostało pokazane na poprzedzających slajdach) lub
systemy zewnętrzne w stosunku do firmy obsługiwanej
przez dany Data Warehouse, np. system banku
prowadzącego rachunek firmy, system informacji
statystycznej GUS, system informacji giełdowej.

• Proces Data Extracting, zwany również Data Acquisition,

pobiera wyspecyfikowane dane z systemów źródeł zasilania
danymi, a następnie umieszcza je w niezmienionym
formacie w obszarze roboczym Data Warehouse.

• Proces Data Extracting, jest realizowany w oparciu o

specyfikacje ekstrakcji określone w Meta Data.
Przykładowo, specyfikacje te mogą mieć format instrukcji
zapisanych w języku SQL.

C – Cleansing

•

Dane pozyskiwane przez proces Data Extracting

, a

następnie umieszczone w obszarze roboczym Data

Warehouse, zachowują formaty i kody systemów

źródłowych.

•

Funkcjonalność procesu Data Cleansing, umożliwia:

– Unifikację formatów danych pochodzących z różnych źródeł, np.

unifikowanie formatów daty, itp.

– Unifikację kodów danych pochodzących z różnych źródeł, np. kodów

płci lub unifikację kodów stanu cywilnego, itp.

– Usunięcie danych nadmiarowych (powtarzających się), z obszaru

roboczego.

– Wstępna weryfikacja i kontrola zgodności danych pochodzących z

różnych źródeł oraz usuwanie danych błędnych.

•

Proces Data Cleansing, jest realizowany w oparciu o

specyfikacje unifikacji, czyszczenia i walidacji - określone w

Meta Data. Przykładowo, specyfikacje te mogą mieć

format instrukcji zapisanych w języku SQL.

T – Transforming

• Dane zapisane w obszarze roboczym Data Warehouse – w

wyniku działania procesów Data Extracting oraz Data

Cleansing, posiadają wprawdzie strukturę zunifikowaną, ale

nadal typową dla źródła pochodzenia, a nie dla Data

Warehouse.

• Funkcjonalność procesu Data Transforming umożliwia:

– Tworzenie danych pochodnych, w stosunku do danych uzyskanych

źródłowych, np. wyznaczanie wartości miernika ROI (zwrot nakładów

inwestycyjnych) dla danego przedziału czasu, które to dane

pochodne zostaną zapisane w Data Warehouse.

– Przekształcanie danych ze zunifikowanych formatów źródłowych, do

formatów tabel Data Warehouse, to jest rekordów umożliwiających

aktualizację tabel faktów i tabel tworzących tzw. kostki

wielowymiarowe danych. Tę funkcjonalność nazywamy Data

Mining.

• Proces Data Transforming, jest realizowany w oparciu o

specyfikacje tworzenia danych pochodnych, rekordów

aktualizujących tabele faktów oraz tabele „kostek

wielowymiarowych danych” - określone w Meta Data.

Przykładowo, specyfikacje te mogą mieć format instrukcji

zapisanych w języku SQL.

ML – Moving & Loading

• Dane zapisane w obszarze roboczym danego Data

Warehouse – w wyniku działania procesów Data

Extracting, Data Cleansing oraz Data Transforming,

mają formaty umożliwiające bezpośrednią aktualizację (lub

zakładanie) poszczególnych Data Mart wchodzących w skład

systemu Data Warehousing, z pomocą specjalizowanego

procesu ładowania i aktualizacji bazy danych DBMS.

• Funkcjonalność procesów Data Moving & Loading

umożliwia:

– Wskazanie specjalizowanemu procesowi ładowania i aktualizacji bazy

danych, którymi danymi ma być zaktualizowany dany Data Mart.

– Uruchomienie działania specjalizowanego procesu ładowania i

aktualizacji bazy danych.

– Powtórzenie powyższych dwu czynności dla kolejnych Data Mart

wchodzących w skład systemu Data Warehousing.

• Proces Data Moving & Loading, jest realizowany w oparciu

o specyfikacje ładowania i aktualizacji poszczególnych Data

Mart - określone w Meta Data. Przykładowo, specyfikacje te

mogą mieć format instrukcji zapisanych w języku SQL.

Pierwsze scentralizowane

rozwiązania

• Podstawową wadą pierwszych

scentralizowanych Data Warehouse’ów

budowanych w oparciu o dosłowne rozumienie

idei Billa Inmona

były gigantyczne wprost

rozmiary oraz związane z tymi rozmiarami

bardzo długie czasy ładowania danych do Data

Warehouse’u.

• Kolejnym problemem, wynikającym z rozmiarów

Data Warehous’u były długie czasy dostępu do

potrzebnych danych.

• Spowodowało to, odejście od rozwiązań

scentralizowanych i poszukiwanie sukcesu na

drodze pełnej decentralizacji Data Warehous’ów.

Rozwiązanie

zdecentralizowane

• Klasyczny Data Warehouse - został więc podzielony na mniejsze jednostki,

zwane umownie Data Marts, powstał w ten sposób model całkowicie
zdecentralizowanego Data Warehouse’u.

• Tak więc - Data Mart to Data Warehouse zorientowany na obsługę informacyjną

mniejszych jednostek organizacyjnych, jak np. piony funkcjonalne lub jednostki
obsługujące określony segment rynku.

• Rozwiązanie zdecentralizowane posiada również wady. Jeśli firma (korporacja)

posiada
kilka niezależnie zaprojektowanych Data Mart’ów, to zachodzi
niebezpieczeństwo braku synchronizacji informacji zawartych w poszczególnych
Data Mart’ach.

• Jeśli dodamy do tego, że ten sam termin - może być rozumiany inaczej w

różnych jednostkach organizacyjnych firmy, to staje się jasnym, dlaczego
groźny jest – brak synchronizacji Data Mart’ów.
Np. pojęcie wielkość sprzedaży jest różnie interpretowane w: (1) biurze
sprzedaży, gdzie jest rozumiane jako wartość przyjętych do realizacji zamówień
klientów; (2) produkcji, gdzie jest rozumiane jako produkcja zdana do magazynu
wyrobów gotowych; (3) magazynie, gdzie jest rozumiana jako produkcja
ekspediowana do klienta; (4) w finansach, gdzie jest rozumiana jako produkcja
dostarczona na zamówienie klienta i zapłacona.

Podejście współczesne

•

Łączne wady przyjętych wcześniej rozwiązań

scentralizowanego oraz całkowicie zdecentralizowanego

Data Warehouse’u – usunięto przez opracowanie modelu

Data Warehouse - złożonego z centralnego Data Store’u z

którego ładowane są dziedzinowe Data Mart’y.

•

Rozwiązanie to pozwoliło, z jednej strony na prowadzenie

wspólnego Meta Data dla całego Data Warehouse’u, z drugiej

strony na wspólne przygotowywanie aktualizacji

poszczególnych Data Mart’ów przez jeden wspólny program

Data Mining operujący na wspólnych surowych danych

dostarczanych z różnych źródeł do Data Store – przez

programy Extraction oraz Cleansing.

•

Z kolei użytkownicy Data Warehouse’u w zależności od

potrzeb mogą korzystać z jednego lub więcej Data Mart’u,

mając pewność, że uzyskiwane informacje są spójne i

jednoznaczne, niezależnie od tego z jakiego Data Mart’u

zostały uzyskane.

Meta-Dane

•

Meta-Dane (Metadata), to charakterystyka wszystkich danych

występujących lub powiązanych z architekturą systemu Data

Warehousing (tj. E/C/T/ML, OLAP, itp.). Charakterystyki danych -

obok formatów i opisu danych, obejmują również wskazanie

miejsc (programów), które wykorzystują dane.

•

Meta-Dane przechowywane są w transakcyjnej relacyjnej bazie

danych – zwanej repozytorium (repository) Meta-Danych.

•

Dla ułatwienia synchronizacji Meta-Danych - pomiędzy dwoma

lub więcej produktami - oprogramowaniem Data Warehousing

pochodzącym od różnych dostawców, opracowano dwa

standardy dotyczące Meta-Danych:

– Tzw. Open Information Model opracowany przez firmę Microsoft,

przeznaczony dla dostawców oprogramowania systemów Data Warehouse,

umożliwiający ujednolicenie struktury repozytorium Meta-Danych;

– Tzw. technologię PLATINUM zawierającą schematy translacji dla

istniejących architektur systemów Data Warehousing – oferowanych przez

niezależnych dostawców do postaci określonej przez Open Information

Model.

Metoda Balanced

Scorecard

• Balanced Scorecard (tzw. Strategiczną kartą wyników);
• Business Processes (tzw. Procesy biznesowe);
• Data Warehousing Technology.
• To trzy metody łącznie - tworzące istotę podejścia do

komputerowo wspomaganego zarządzania

strategicznego, zapewniając równocześnie niezbędną

integrację – procesów zarządzania.

• Perspektywy Balanced Scorecard (Finansów, Klientów,

Procesów biznesowych i Rozwoju firmy) – zawierają

zestaw mierników, które z kolei wyznaczają model

danych (Data Model) – decydujący o niezbędnej

zawartości informacyjnej Data Warehouse.

Składowe Data

Warehousing

Baza danych

No 1

Baza danych

No 2

Baza danych

No 3

Proces

Magazyn

danych

(Data

Store)

Proces

Data Model

Data Mart

OLAP

Meta

data

Perspektywy Balanced Scorecard

Procesy biznesowe firmy

wspomagane systemami transakcyjnymi

Proces E

Data Mart

OPAP

Data Mart

OLAP

Proces

Dekompozycja procesów

S ro d o w is k o k o m p u te r o w e

A d m in is tr o w a n ie

D a n e tra n s a k c y jn e

In fo rm a c je

D a n e d o
c z y s z c z e n ia

D a n e
o c z y s z c z o n e

D a n e d o
a k tu a liz a c ji

E x tra c tio n

C le a n s in g

T r a n s fo r m in g

(D a ta M in in g )

M o v in g

& L o a d in g

Struktura procesów tworzenia i

aktualizacji Data Warehouse

P ro c e s y t w o r z e n ia

D a t a W a r e h o u s e

E x tr a c tio n

C le a n s in g

T ra n s fo rm in g

( D a ta M in in g )

M o v in g

& L o a d in g

P ro c e d u ra
" E x tr a c tio n "

P ro c e d u ra
" C le a n s in g "

P ro c e d u ra
" T ra n s fo r m in g "

P ro c e d u ra
" M o v in g &
L o a d in g "

Użytkownicy Data

Warehouse

• Statistician (statystycy): pojęcie to obejmuje zarówno osoby

sporządzające statystyki dla potrzeb firmy, jak również osoby
prowadzące badania operacyjne.

• Knowledge Workers (specjaliści): pojęcie obejmuje stosunkowo

nieliczną grupę osób formułujących masowe zapytania (kwerendy)
Data Warehouse oraz prowadzącą analizy w oparciu o dane
zgromadzone w Data Warehouse.

• Information Consumers (konsumenci informacji): pojęcie

obejmuje większość użytkowników Data Warehouse, korzystających
bezpośrednio głównie z gotowych raportów oraz zestawień
tworzonych w ramach EIS.

• Executive (naczelne kierownictwo): pojęcie obejmuje członków

naczelnego kierownictwa firmy (korporacji) wchodzących w skład
zarządu korzystających bezpośrednio głównie z gotowych raportów,
zestawień tworzonych w ramach EIS oraz pośrednio ze statystyk,
wyników badań operacyjnych oraz kwerend przygotowanych przez
statystyków oraz specjalistów.

Struktura powiązań

• Jak zostało powiedziane wcześniej, typowa struktura Data

Warehouse zawiera dwa typy tabel:

– Tabele faktów
– Tabele składające się na „kostki wielowymiarowe danych”.

• Tabele faktów zawierają praktycznie klucze obce (forein

key), umożliwiające szybki dostęp do indywidualnych

informacji zawartych w tabelach składających się „kostki

wielowymiarowe danych”.

• „Kostki wielowymiarowe danych” zawierają szeregi

czasowe danych, np. wyniki egzaminów i zaliczeń z

poszczególnych przedmiotów, uzyskiwane w na kolejnych

semestrach studiów.

• W dalszym ciągu, wyróżniać będziemy dwa typy powiązań

pomiędzy tabelami faktów i tabelami składającymi się

„kostki wielowymiarowe danych”. Są to:

– Struktura typu „gwiazda”.
– Struktura typu „płatek śniegu”.

Struktura typu gwiazda

Fakty

id_student
id_status
id_kierunek
id_specjalnosc
id_grupa
id_semestr
id_dyplom
id_akademik

Student

id_student

nazwisko
imie
data_urodzenia
imie_ojca
adres
matura
zdjecie
indeks
data_rozp

Akademik

id_akademik

nazwa
adres
numer_pokoju
data_zam

Semestr

id_semestr

nr_semestru
komentarz
id_grupa (FK)

Kierunek

id_kierunek

nazwa
lista_specjalnosci
nr_programu
id_grupa (FK)
id_specjalnosc (FK)

Specjalnosc

id_specjalnosc

nazwa
nr_programu
id_grupa (FK)

Grupa

id_grupa

typ
symbol_grupy
id_semestr
opiekun_grupy

Status

id_status

Dyplom

id_dyplom

nazwa_ust?
temat
praca_przyjeta?
praca_recenz?
dopuszczenie_egzam?
data_egzaminu
wynik_egzam
dyplom_wyd

Struktura

systemów

informatycz

nych

firmy

Przetwarzanie transakcyjne na

OLTP-RDB

Przetwarzanie okresowe: planowanie;

budżetowanie; sprawozdawczość; itp.

na OLTP-RDB

E/C/T/ML –

Przetwarzanie

zasilające Data

Warehouse

danymi z RDBMS i

zewnętrznymi

Data

Warehouse

RDB

EIS

OLAP

Legenda:

EIS – Executive Information System

OLAP – On-Line Analytical
Processing czyli analizowanie
wielowymiarowych „kostek”

RDB – relacyjna baza danych

E – Extracting czyli pobieranie
danych zasilania

C – Cleansing czyli czyszczenie
danych

T – Transforming czyli
przekształcanie

ML – Moving & Loading czyli
ładowanie

OLTP – On-Line Transaction
Processing

Uwagi dotyczące

prowadzenia DW

• Systemy źródła danych dla Data Warehouse ulegają

ciągłym zmianom, ze względu na nowe wymagania

biznesu oraz zmiany typu łączenia firm (mergers).

• Platformy sprzętowo-programowe Data Warehouse i

Data Marts będą się zmieniać i osiągać coraz lepsze

parametry eksploatacyjne.

• Standardy przemysłowe będą podlegały stałemu

rozwojowi, któremu towarzyszy wzrost wymagań na

produkty i obsługę.

• Wymagania prowadzących biznes oraz zasady

planowania strategicznego - będą się zmieniać i

rozrastać.

• Wolumen danych będzie szybciej rosnąć,

prawdopodobnie znacznie szybciej niż wyobrażamy

sobie to na początku.

CRM – Zarządzanie związkami z

klientem

• Jedną z tzw. Business Intelligence Application, jest Customer

Relationship Management (w skrócie CRM). Powstanie CRM
wiąże się z tzw. Customer -Driven Company.

• Praktyczne zastosowanie CRM wymagało opracowania:

– Technologii Data Warehousing (technologii umożliwiającej efektywne

operowanie wielkimi plikami danych historycznych);

– Multi Channel Contact Server (urządzenia komputerowego

umożliwiającego koncentracje informacji pochodzących z wielu
różnorodnych kanałów informacyjnych, takich jak telefon, fax, e-mail,
itd.), zwanego również Call Center.

• Efektywne działanie CRM wymaga obok informatyzacji strony

popytu firmy (demand), wymaga również informatyzacji
strony podaży (supply) firmy oraz ścisłego współdziałania tych
dwóch części składowych, dających w wyniku tzw. Business
Intelligence Application.

1990s-2005

A Customer-Driven

Company

Product

Advertising

Sales

Distribution

Customer

Driven

Company

Customer

Needs

Firma typu Customer-Driven Company musi:

1. Modyfikować swoje kanały komunikacji z klientami, tak żeby
„słuchać” opinii klientów;
2. Określić jakie dane dotyczące klientów i popytu należy
gromadzić;
3. Opracować metodę efektywnego wykorzystywania informacji
zebranych od klientów,
tak aby w wyniku - tworzyć i dostarczać lepsze produkty i usługi
klientom.

Zasady działania CRM

Distribution

Human

Resources

Manufacturing

Finance

Operations

Contact Management

Internet

Sales

Retail

Mail

Customer

Service

Customers

Intermediaries

Direct Channels

Indirect Channels

Sales

Distributors

Customer Management

Strategic Development

& Planning

Market Intelligence

& Research

Information Management

Product

Management

Channel

Management

MarCom

Management

Customer

Łańcuchy popytu i podaży

Internet

Orders

(

Cust

. Owner)

Functions:

•

Order

Mgt

•

Billing

•

(Product Owner)

Functions:

•

Inventory

Mgt

•

General Ledger

•

MRP

(

Mktg

Data Mart)

Functions:

•

Campaign

Mgt

•

Channel

Mgt

•

DSS

Inventory Details

Order/Sales Info

Journal Entries

Customer Details

Reporting

EIS

Extract

Reporting

Extract (B)

Reporting

Extract (B)

Customer

Profile

Data

Call

Center

Porównanie dwóch klas

relacyjnych baz danych

• OLTP RDB (aktualizowane transakcjami) - relacyjne bazy

danych, służące do obsługi tzw. operational systems:

– Obsługa transakcji czyli OLTP;
– Obsługa wsadowego przetwarzania okresowego, planistycznego

oraz sprawozdawczego;

– Dostarczanie informacji klasy „structured” - dla szeroko

rozumianego kierownictwa, w szczególności nadzoru.

• Data Warehouse RDB (aktualizowane wsadowo) –

relacyjne bazy danych, służące do obsługi Data

Warehousingu:

– Obsługa funkcji E

xtracting

leansing

ransforming

oving &

oading

;

– Obsługa funkcji D

ata

ining

(część funkcjonalności T

ransforming)

;

– Obsługa funkcji OLAP;
– Dostarczanie informacji klasy „semi-structured” - dla

naczelnego kierownictwa, składających się łącznie na EIS.

Literatura tematu

Dave Browning & Joy Mundy – Data Warehouse Design Considerations,

Microsoft® SQL Server™ 2000, December 2001, http://www.microsoft.com.

James F. Courtney (Jr.), David B. Paradice – Database Systems for Management,

Times Mirror/Mosby College Publishing, St. Louis USA 1988.

Joseph M. Firesone – Dimentional Modeling and E-R Modeling in The Data

Warehouse, Executive Information Systems, Inc. USA, White Paper No. Eight

June 22, 1988.

Tomas Flanagan, Elias Safdie (editors) – A Practical Guide to Getting Started

with Data Warehousing, http://

wwwe.com

The Applide Technology Group, Main

USA 1997.

Tomas Flanagan, Elias Safdie (editors) – Building a Decision Support

Architecture for Data Warehousing, http://www.techguide.com The Applide

Technology Group, Main USA 1997.

Tomas Flanagan, Elias Safdie (editors) - Building a Successful CRM Environment,

http://www.techguide.com The Applide Technology Group, Main USA 1998.

Tomas Flanagan, Elias Safdie (editors) – Putting Metadata to Work in the

Warehouse, http://www.techguide.com The Applide Technology Group, Main

USA 1998.

Literatura tematu

Tomas Flanagan, Elias Safdie (editors) – Data Warehousing Today:
Summaries and Subsets, http://www.techguide.com The Applide
Technology Group, Main USA 1999.

Robert S. Kaplan, David P. Norton –  Strategiczna karta wyników:
Jak  przełożyć  strategię  na  działanie  (tłumaczenie  z  języka
angielskiego),  Artur  Andersen  –  Wydawnictwo  Naukowe  PWN,
Warszawa 2001.

10. Oracle Balanced Scorecard - http://

www.oracle.com

Oracle

Corporation, California USA 1999.

11. Jerry Rajan (editor) - Building and Deploying an Enterprise Data

Warehouse, http//

www.techguide.com

The Applied Technology

Group, Main USA 2000.

Document Outline