Świat obiektów

VIII Konferencja PLOUG
Koœcielisko
PaŸdziernik 2002
„Œwiat obiektów - œwiat analiz”
BusinessObjects jako kompletne narzêdzie
dostêpu do baz danych i systemów Oracle
Bartosz Dobrowolski
Premium Technology Sp. z o.o.
[email protected]
„Świat obiektów – świat analiz”
211
1. Na początku był chaos
W piękny, letni, sobotni poranek, w Paryżu, o godzinie 9:30 w mieszkaniu pewnego młodego
człowieka przez cichy szum miasta i szelest rosnącej nieopodal domu brzozy dało się słyszeć
głośne brzęczenie telefonu. Długo i uparcie próbował on wedrzeć się pod ciężkie po kolejnej
nieprzespanej nocy powieki Bernarda Liautaud’a. Kolejnej nocy programowania, kompilowania, testowania, programowania, testowania. Kolejnej, od dnia kiedy przy szklaneczce czerwonego wina wspólnie z kilkoma kolegami postanowił stworzyć jakiś kawałek kodu, który pozwoli tym z Departamentu Analiz dostawać się do serwera ORACLE wtedy kiedy będą chcieli i to
bez żadnej pomocy IT. Kawałek kodu, który pozwoli wreszcie tym z Marketingu przewracać
dane na wszystkie sposoby bez znajomości SQL’a. Kawałek kodu – dobre sobie. Siedzą nad
tym kolejny tydzień. Pomysł jest genialny w swej prostocie. Skoro tylko IT zna język SQL to
pozostałym trzeba jakoś przetłumaczyć bazę danych....a bazie danych wytłumaczyć to czego
chcą użytkownicy. Mają nawet nazwę dla takiego słownika: angielskie Universe czyli wszechświat, bo dla takiej Claire z Kadr to przecież jak wyprawa w kosmos, tak sobie rozmawiać z bazą danych. Przed nimi jeszcze masa pracy. Teraz spał. Telefon najprawdopodobniej nie zdawał
sobie sprawy z tego, że skoro złote promienie zawieszonej nad miastem ognistej gwiazdy nie
były w stanie dokonać cudu przebudzenia to on, zwykły kawałek czarnego plastiku, pozostaje
bez szans. Kiedy wreszcie postanowił poddać się i pokonany zamilknąć spod kraciastej kołdry
wysunęła się leniwie ręka, słuchawka podskoczyła i Bernard usłyszał roześmiane głosy swoich
kolegów: ”Udało się! Bernard! Odpowiedziała! Baza widzi nasz świat, nasz Universe!”.
2. Wszechświat
Było to dokładnie dwanaście lat temu w 1990 roku. Wtedy to Bernard Laiutaud wraz z kolegami stworzył niezwykle ciekawą aplikację pozwalającą zwykłym, nietechnicznym użytkownikom sięgnąć do wszystkich źródeł danych znajdujących się w przedsiębiorstwie. Sięgnąć samodzielnie. Bez pomocy kolegów informatyków. Bez konieczności kłopotliwego zamawiania raportów. Ponieważ aplikacja pozwalała jakoby „przeskoczyć” znajomość baz danych, języka
SQL, architektury i zabezpieczeń systemu bazodanowego użytkownika autorzy systemu nazwali go początkowo Skipper SQL. Dopiero wersja trzecia została przemianowana na BusinessObjects.
Bernard Liautaud jest teraz prezesem notowanego na giełdach Business Objects, korporacji która zatrudnia obecnie ponad 3000 pracowników w samej kwaterze głównej w Paryżu, posiada
ponadto biura w ponad 40 krajach, nowoczesne centrum wsparcia technicznego w Londynie
oraz setki partnerskich firm na całym świecie. Z systemu BusinessObjects korzysta na świecie
ponad 1 200 000 użytkowników.
W roku 1990, podczas pracy nad swym systemem raportowym zespół Bernarda wynalazł
i opatentował nowatorski sposób dostępu do danych oparty o warstwę semantyczną tłumaczącą
język używany w codziennym życiu przez użytkowników na język rozumiany przez bazy danych – SQL. Warstwa ta, nazwana przez twórców Universe, została przetłumaczona na tyle języków ile wersji językowych aplikacji pojawiło się na rynku. Premium Technology tłumacząc
pierwszą polską wersję systemu na podstawie badań przeprowadzonych wśród użytkowników
angielskiej wersji oprogramowania wybrało nazwę Świat Obiektów.
212
Bartosz Dobrowolski
Rys. 1. Przykładowy Świat Obiektów niewielkiego biura turystycznego. Te obiekty widzi użytkownik końcowy
i z nich buduje raporty
Mimo zaawansowanego mechanizmu tłumaczącego pojęcia biznesowe na język SQL sama zasada działania Świata Obiektów jest bardzo prosta. Świat Obiektów to niewielki binarny plik
(~10-400KB), który zawiera obraz struktury bazy danych, definicję pogrupowanych w tematyczne klasy obiektów (z nich później użytkownik końcowy buduje raporty), konfigurację połączenia do bazy danych, oraz dodatkowe informacje potrzebne do prawidłowego zbudowania i
wykonania raportu (definicję hierarchii drążenia, format danych wynikowych, domyślne
czcionki, kolory, etc). Świat obiektów nie zawiera danych źródłowych a jedynie wskazuje źródłową bazę danych i umożliwia połączenie z nią i wygenerowanie zapytania SQL na podstawie
wybranej do zapytania kombinacji obiektów.
3. Stworzenie Świata
Administrator systemu przy pomocy graficznego narzędzia Designer jednorazowo tłumaczy bazę danych na słowa (obiekty) a następnie udostępnia użytkownikom gotowy Świat Obiektów, z
którego jak z klocków lego można budować dowolne zestawienia z zachowaniem istniejącej polityki bezpieczeństwa firmy. Niezwykle prosty i intuicyjny proces tłumaczenia przebiega w kilku krokach wspieranych kreatorami (Kreator Świata Obiektów, Wykrywanie Pętli, Wykrywanie
Połączeń, Wykrywanie Krotności, etc.) oraz wewnętrznymi mechanizmami kontroli poprawności (Kontrola Składni, Kontrola Struktury, Kontrola Kontektowa, etc.). Dzięki temu projektant
udostępniając Świat Obiektów użytkownikom ma pewność, że generowany przez BusinessObjects SQL będzie poprawny.
•
Kroki prowadzące do stworzenia efektywnego Świata Obiektów to:
•
Połączenie z bazą danych
•
Odwzorowanie (fragmentu lub całości) struktury bazy danych
•
Przetłumaczenie struktury na słowa (obiekty)
•
Udostępnienie gotowego Świata Obiektów użytkownikom
„Świat obiektów – świat analiz”
213
Połączenie z bazą danych odbywa się za pośrednictwem sterowników dedykowanych (Oracle,
DB2, Informix, Teradata, Sybase, SQL Server). Dzięki temu generowany na podstawie Świata
Obiektów kod SQL zawiera natywne funkcje bazy danych (np. DECODE) a zapytanie jest wykonywane efektywnie. W przypadku bazy Oracle należy w SQL*Net stworzyć serwis TNS a
następnie wskazać go z poziomu aplikacji Designer.
Rys. 2. Moduł Designer. Połączenie z bazą danych zostało nawiązane. Projektant może teraz wybrać tabele,
które posłużą za podstawę Świata Obiektów
Po podłączeniu się do bazy danych i wybraniu potrzebnych tabel należy odtworzyć strukturę
bazy danych (lub wybranego fragmentu) definiując relacje między tabelami, określając krotności i ewentualnie edytując formuły warunkowe relacji. Można to zrobić ręcznie lub automatycznie (Designer odczyta Constrains bazy Oracle). Następnie aplikacja optymalizuje obraz struktury bazy danych (nie modyfikując samej bazy) pod kątem generatora SQL, który będzie korzystał ze Świata. Wykrywane i rozwiązywane są tzw. pętle, powstają inteligentne konteksty zapobiegające wysyłaniu do bazy danych błędnych zapytań SQL. Dodatkowo projektant może stworzyć tzw. Shortcut Joins (Połączenia Skrótowe), które pozwalają wielokrotnie skrócić wykonywanie zapytań. Jeżeli baza danych posiada tabele zagregowane (nawet nie połączone z główną strukturą) można dodać je teraz i następnie tak skonfigurować Świat Obiektów (funkcja
@AggregateAware) aby odwoływał się do tych tabel zawsze wtedy kiedy kombinacja użytych
przez użytkownika obiektów pozwala na sięgnięcie do agregatów zamiast do tabel detalicznych!
214
Bartosz Dobrowolski
Rys. 3. Środowisko pracy projektanta – aplikacja Designer. Struktura bazy danych. W tym przypadku relacje
między tabelami zostały automatycznie odczytane z Constrains bazy Oracle
Mając przygotowaną strukturę bazy danych można przystąpić do kreowania obiektów. Każdy
obiekt posiada szczegółową definicję składającą się z nazwy i opisu, typu danych, które będzie
przynosił, fragmentu SQL (klauzula Select i Where) zbudowanego z dowolnej kombinacji
funkcji bazodanowych, definicji listy wartości przeznaczonej do definiowania warunków, etc.
Obiekty można tworzyć także przeciągając po prostu pole tabeli lub całą tabelę z okna struktury
(po prawej) na okno Świata Obiektów (panel po lewej). Obiekt zostanie stworzony automatycznie z domyślnymi ustawieniami, które następnie można edytować.
„Świat obiektów – świat analiz”
215
Rys. 4. Okienko edycji definicji obiektu. Na zakładce Właściwości można ustalić typ obiektu (wymiar, miara,
szczegół)
Aby ułatwić użytkownikom pracę, obiekty grupuje się w klasy (te z kolei mogą posiadać podklasy itd). Klasy porządkują dostępne dla użytkownika dane tematycznie lub hierarchicznie.
Hierarchie mogą być stworzone automatycznie jednak najczęściej projektant sam decyduje o
porządku i kierunkach drążenia danych pozostawiając także do dyspozycji domyślne definicje.
Dzięki temu użytkownik aplikacji analitycznej BusinessObjects może sam zdecydować z jakiej
perspektywy chce oglądać dane a przy pomocy funkcji Drill swobodnie poruszać się po udostępnionych wymiarach (np. przechodzić płynnie z informacji o latach do kwartałów potem
miesięcy, produktów) . Podczas analizy wszystkie wartości liczbowe będą wyliczane w czasie
rzeczywistym. Dzięki podziałowi obiektów na trzy typy jest to możliwe także podczas pracy w
trybie off-line, bez połączenia z bazą danych!
Aby możliwa była efektywna i wygodna praca off-line definiując obiekt należy zakwalifikować
go do jednej z trzech kategorii (patrz rys. 1):
Wymiar (Dimension)
Obiekt Szczegółowy (Detail)
Miara (Measure)
Wymiary to główne wątki analizy, takie jak czas (rok, miesiąc, data faktury, etc.), klient (numer, nazwa, etc.) czy struktura organizacyjna (kraj, miasto, oddział, departament, pracownik,
etc.). Obiekty Szczegółowe nie mogą istnieć samodzielnie i zawsze są „przywiązane” do Wymiaru stanowiąc coś w rodzaju jego atrybutów, dodatkowych informacji, które nie wchodzą w
skład hierarchii i nie są wykorzystywane podczas analizy (np. drążenia danych). Obiektem
Szczegółowym może być na przykład numer telefonu, kod pocztowy czy adres. Wyjątkowym
typem obiektu jest natomiast Miara.
Obiekt typu Miara posiada poza podstawowymi parametrami „zaszytą” funkcję agregującą
(min, max, suma, średnia, zlicz, etc.). Właściwie posiada nawet dwie funkcje tego typu. Jedna
określana jest na poziomie kodu SQL (patrz rys. 4) i po uruchomieniu zapytania wykona się po
stronie serwera bazy danych. Druga (niewidoczna na rysunku ponieważ znajduje się na innej
216
Bartosz Dobrowolski
zakładce) określa w jaki sposób wartości liczbowe będą wyliczane podczas pracy bez połączenia z bazą danych. Oznacza to, że kiedy użytkownik uruchomi raport i otrzyma z bazy danych
wstępnie zagregowany wynik zapytania, może potem dowolnie „przewracać” i „kroić” uzyskane dane a wartości liczbowe będą automatycznie przeliczane lokalnie (na jego stacji) bez konieczności łączenia się ze źródłem danych. Dzięki temu, że wynik zapytania może być przechowywany wewnątrz pliku raportu, pracę nad danymi można kontynuować w dowolnym miejscu i czasie a raz uruchomiony raport (może nawet automatycznie przy pomocy serwera BroadcasAgent) jest gotowy do analizy dla wszystkich uprawnionych użytkowników bez konieczności czasochłonnego odświeżania. Miara domyślnie agreguje się do poziomu wymiarów, z którymi znajduje się w bloku danych (tabela, wykres, macierz). Użytkownik może oczywiście dowolnie wpływać na kontekst agregacji i układ danych.
4. Dzień siódmy
Aby możliwe było zbudowanie raportu projektant po stworzeniu Świata musi udostępnić go
użytkownikom. Sposobów jest kilka. Ponieważ Świat jest pojedynczym plikiem może być udostępniany jako plik poprzez strukturę katalogów czy pocztę elektroniczną. Sposób prosty ale
kłopotliwy w przypadku konieczności wprowadzenia zmian do Świata Obiektów (aktualizacji
struktury bazy danych, przemianowania czy dodania nowych obiektów) – w takim przypadku
należałoby ponownie przesłać świat, upewnić się, czy wszyscy użytkownicy korzystają z nowej
wersji itd. Dużo wygodniej i bezpieczniej można udostępnić Świat Obiektów poprzez repozytorium systemu BusinessObjects.
Repozytorium BusinessObjects to pewnego rodzaju biblioteka. Biblioteka przechowująca zarówno Światy Obiektów jak i dokumenty (z danymi i bez) ale dodatkowo pełniąca funkcje medium pomiędzy użytkownikami systemu oraz będąca centralnym elementem wewnętrznego systemu bezpieczeństwa BusinessObjects (można go opcjonalnie połączyć z domeną NT i wewnętrznym systemem haseł baz danych). Repozytorium to zwykła, relacyjna baza danych
(Oracle, DB2, MS SQL Server, etc) , która w celu określenia polityki bezpieczeństwa generowana jest automatycznie w dowolnej przestrzeni wybranego przez administratora motoru bazy
danych. Tworzenie repozytorium odbywa się z poziomu aplikacji zarządczej Supervisor (patrz
architektura na rys. 5). W tej aplikacji administrator systemu tworzy też drzewiastą hierarchię
użytkowników, nadaje im prawa dostępu do aplikacji, funkcji aplikacji, dokumentów, Światów
Obiektów (z wyszczególnieniem widocznych dla użytkownika obiektów) oraz do danych nawet
na poziomie pojedynczego rekordu. Od momentu stworzenia repozytorium użytkownicy systemu aby skorzystać z jakiejkolwiek aplikacji muszą zweryfikować swój login i hasło. Trzy
błędne próby logowania i....pozostaje już tylko telefon do administratora.
„Świat obiektów – świat analiz”
217
Rys. 5. Architektura systemu BusinessObjects
Wróćmy jeszcze na moment do współdzielenia Światów Obiektów. Projektant umieszcza gotowy Świat w Repozytorium. Dla większego bezpieczeństwa wszystkie informacje dostępowe
(dane serwera, login i hasło) do bazy danych, na której zbudowany został Świat Obiektów przechowywane są w oddzielnym miejscu Repozytorium i nigdy nie są zapisywane na stacji użytkownika. Przy każdym połączeniu do źródłowej bazy raportowej (czyli przy uruchomieniu raportu – zapytania) aplikacja analityczna BusinessObjects sięga do Repozytorium, pobiera dane
logowania uwierzytelniające użytkownika, „podstawia” je do klienta bazy a następnie po uzyskaniu dostępu do danych usuwa z pamięci. Świat Obiektów umieszczony w Repozytorium jest
silnie zabezpieczony a ewentualne modyfikacje wystarczy zaimplementować w jednej jego kopii. Zmiany zostaną automatycznie naniesione na wszystkich stacjach klienckich i raportach.
Repozytorium pełni także funkcję biblioteki dokumentów. Użytkownicy mogą wysyłać do niej
raporty, odbierać je, publikować, współdzielić a dzięki zdefiniowanemu za pomocą aplikacji
Supervisor systemowi bezpieczeństwa każdy użytkownik widzi tylko raporty do których został
uprawniony. System posiada zaawansowany mechanizm ograniczający dostęp do krytycznych
danych. Dzięki temu kilka osób mających dostęp do jednego raportu po jego otwarciu zobaczy
dane przeznaczone tylko dla siebie. Dyrektor Sprzedaży otwierając np. „Raport Miesięczny
Sprzedaży” zobaczy więc zestawienie wyników wszystkich oddziałów firmy, lecz kierownicy
poszczególnych oddziałów pobierając dokładnie ten sam dokument z biblioteki zobaczą tylko
dane swojej jednostki! Filtrowanie odbywa się automatycznie i zupełnie przezroczyście dla
użytkownika.
5. Adam i Ewa
Spójrzmy teraz na system z punktu widzenia użytkownika końcowego. Aby rozpocząć pracę z
aplikacją raportową BusinessObjects użytkownik (np. Adam) musi oczywiście podać swój login
i hasło (sprawdzane w repozytorium lub przy odpowiednich prawach z zaszyfrowanego pliku
profilu zapisanego na stacji użytkownika). Następnie może otworzyć istniejący raport z Repozytorium lub z dysku . Raport zawiera dane więc bez łączenia do bazy danych Adam może rozpocząć analizę. Wartości liczbowe są agregowane lokalnie bez potrzeby sięgania do bazy danych (Miary z wewnętrzną funkcją obliczeniową!). Adam tworzy nowe zakładki raportu, wy-
218
Bartosz Dobrowolski
kresy, tabele, drąży dane, kroi je i przegląda z różnych perspektyw. W dowolnym momencie
Adam może odświeżyć raport aby wypełnić swoją analizę najświeższymi danymi. BusinessObjects odczyta wtedy z pliku raportu nazwę Świata Obiektów, którego autor raportu użył do budowy zapytań. Następnie sprawdzane jest czy na dysku użytkownika znajduje się najświeższa
wersja pliku Świata. Jeśli w repozytorium znajduje się nowsza wersja Świata to następuje jego
aktualizacja i uruchomienie zapytania. W tym momencie BusinessObjects wie już do jakiej bazy będzie się łączyć. Na stacji klienckiej znajduje się sterownik tej bazy i aby uzyskać połączenie do bazy źródłowej, z Repozytorium pobierane są dane logowania. W tym samym czasie do
zapytania wysyłanego od użytkownika dodawane są odpowiednie warunki, które odfiltrują tylko dane, do których użytkownik ma prawo. Następuje połączenie z bazą, zapytanie jest przetwarzane a wynik trafia do raportu, jest formatowany i prezentowany na ekranie.
Rys. 6. Moduł BusinessObjects. Panel Zapytań. Jedyny element systemu, który musi opanować użytkownik
aby samodzielnie budować zapytania do bazy danych za pomocą myszy
Tworzenie nowego raportu odbywa się niemal identycznie z tą tylko różnicą, że użytkownik
zamiast uruchamiać gotowe zapytanie definiuje je sam w Panelu Zapytań (patrz rys. 6) przeciągając za pomocą myszki ze Świata Obiektów te elementy, które chciałby zobaczyć w raporcie,
definiuje warunki, tworzy podzapytania, parametry, listy wartości. W tle generowane jest zapytanie, które następnie przesyłane jest do bazy danych (patrz rys. 7).
„Świat obiektów – świat analiz”
219
Rys. 7. Przetwarzanie zapytania. BO Data Access Pack tłumaczy kombinację obiektów z Panelu Zapytań na
język SQL. Wynik zapytania jest dodatkowo lokalnie indeksowany dla zwiększenia wydajności
Warto jeszcze wspomnieć, że Świat Obiektów to tylko jedno ze źródeł danych, które mogą być
użyte w raportach BusinessObjects. W dokumentach można wykorzystać pliki lokalne (Excel,
CSV, txt), bazy OLAP (np. Oracle Express za pośrednictwem analogicznego do zwykłego
OLAP Panelu), dane z zewnętrznych systemów takich jak Oracle Application, SAP, Baan, Siebel, etc (istnieją gotowe Światy Obiektów i raporty do tych systemów), stron WWW i wielu,
wielu innych. Dane z wielu źródeł można łączyć na poziomie raportu nawet w jednym bloku
danych (tabeli, macierzy, etc).
Do danych oraz biblioteki raportów (Repozytorium) możliwy jest także dostęp przez przeglądarkę internetową (np. Internet Explorer, Netscape, etc.). W takiej sytuacji na stacji klienta nie
jest wymagane żadne dodatkowe oprogramowanie, żadne rozszerzenia czy sterowniki baz danych. Obsługą zapytań zajmuje się wtedy serwer aplikacji WebIntelligence (patrz rys. 5) i poprzez niego na podobnych zasadach jak w przypadku aplikacji klienckiej BusinessObjects użytkownik loguje się do systemu, sięga do dokumentów, odświeża je, generuje nowe zapytania (w
webowym odpowiedniku Panelu Zapytań), współdzieli je. Istnieje też możliwość wykorzystania
środowiska mieszanego. To interesujące rozwiązanie pozwala użytkownikom BusinessObjects
(pracującym w architekturze klient-serwer) dostać się do danych za pośrednictwem serwera
WebIntelligence (architektura wielowarstwowa). Dzięki temu nie ma konieczności wystawiania
bazy danych w Internecie czy nawet Intranecie. Wystarczy udostępnić stronę WWW a schowany za wszystkimi firewall’ami serwer WebIntelligence przez zaszyfrowane SSL’em łącze udostępni uprawnionym użytkownikom dane, raporty i analizy. Także przez WAP. Raporty WAP,
choć zawierające tylko kluczowe wskaźniki są aktywne, mogą być odświeżane, parametryzowane, etc.
Cały system obejmuje jedna polityka bezpieczeństwa. Jeden login, jedno hasło. Bez względu na
aplikację, z której korzysta użytkownik.
6. AD 2002
Od wspomnianego na wstępie letniego poranka upłynęło dwanaście lat. Aplikacja pozwalająca
nietechnicznym użytkownikom„przeskoczyć” SQL przerodziła się w korporacyjną platformę
dostępu do danych składającą się z aplikacji analitycznych, administracyjnych, serwera harmonogramowania, serwera aplikacji pozwalającego na dostęp do systemu z dowolnego miejsca na
świecie, rozwinięto zaawansowany mechanizm subskrypcji do danych i raportów, WAP, kom-
220
Bartosz Dobrowolski
putery naręczne PDA, możliwe stało się łączenie elementów systemu poprzez API z zewnętrznymi aplikacjami (np. GIS, BSC, etc), istnieje możliwość dowolnej modyfikacji interfejsu aplikacji (VBA/ASP/JSP) współdzielenie dokumentów dowolnego typu.....
Nadal jednak system rozwijany jest po to aby użytkownik końcowy mógł po prostu „przeskoczyć” SQL i sięgnąć do dowolnego źródła danych. Administrator systemu może zająć się administracją systemu a nie tworzeniem raportów na zamówienie.
Ostatnia wersja systemu (na dzień 17.07.2002) to BusinessObjects 5.1.5 (Polska wersja językowa)
45% użytkowników BusinessObjects w Polsce jako źródło danych stosuje bazę Oracle.
Telefon Bernarda Liautaud’a ma teraz najprawdopodobniej kolor kremowy.