System interaktywnego wspomagania wyszukiwania informacji w hurtowniach danych

Pełen tekst

(1)Zeszyty Naukowe nr. 770. Uniwersytetu Ekonomicznego w Krakowie. 2009. Dariusz Put Katedra Systemów Obliczeniowych. System interaktywnego wspomagania wyszukiwania informacji w hurtowniach danych Streszczenie. Dane zapisane w bazie danych mogą być źródłem wiedzy analitycznej, stanowiącej istotny czynnik w procesie podejmowania decyzji. Aby takie ich wykorzystanie było możliwe, w bazie danych muszą być przechowywane dane historyczne, co może niekorzystnie wpływać na wydajność systemu, spowalniając jego pracę. Utworzenie hurtowni danych ma na celu oddzielenie danych transakcyjnych (aktualnych) od historycznych i w konsekwencji usprawnienie działania całego systemu. Jednym z elementów hurtowni danych jest system budowy zapytań. W procesie tworzenia hurtowni trudno uwzględnić wszystkie aktualne, a szczególnie przyszłe potrzeby analityczne użytkowników systemu, dlatego ważne jest, aby moduł budowy zapytań był elastyczny i umożliwiał każdemu wyszukiwanie danych, które będą mu potrzebne w danej chwili – teraz lub w przyszłości. Właściwy projekt hurtowni danych, uwzględniający ten postulat, ułatwi utworzenie mechanizmu samodzielnej budowy zapytań. W artykule omówiono problemy budowy systemu wspomagania wyszukiwania danych w hurtowni danych. Słowa kluczowe: baza danych, hurtownia danych, model hurtowni danych, SQL, zapytanie wybierające.. 1. Wstęp Język zapytań do baz danych – SQL – powstawał jako narzędzie dla użytkownika, umożliwiające każdemu napisanie instrukcji i uzyskanie szukanych danych. Wraz z rozwojem baz danych pojawiały się nowe koncepcje, które wpłynęły także na SQL, sprawiając, że stawał się on językiem coraz bardziej skomplikowanym. Obecnie napisanie kwerendy wybierającej wymaga znajomości nie tylko składni SQL, ale także wielu zagadnień bazodanowych, samej strukt ury bazy danych.

(2) 222. Dariusz Put. i występujących w niej powiązań, a także rozumienia sposobu rejestracji w niej obiektów i zdarzeń zachodzących w świecie rzeczywistym. W takiej sytuacji uzyskanie żądanych informacji na podstawie danych pochodzących z bazy danych, a niedostępnych w zaprojektowanej aplikacji, wymaga każdorazowej konsultacji z administratorem lub projektantem systemu. W procesie projektowania bazy danych główny nacisk kładzie się na stworzenie takiego systemu, który będzie umożliwiał rejestrację obiektów i zdarzeń w sposób jednoznaczny, bezbłędny i niepozwalający na występowanie anomalii i nieścisłości. Podczas definiowania aplikacji dla użytkownika składającej się z raportów i formularzy, a także zapytań, projektant powinien wziąć pod uwagę potrzeby każdego szczebla zarządzającego i przygotować rozwiązania wybierające i prezentujące takie dane, które umożliwią podejmowanie zarówno bieżących, jak i krótko i długoterminowych decyzji. Uzyskany efekt najczęściej jest jednak mało elastyczny, aplikacja obejmuje bowiem skończoną liczbę formularzy i musi być co pewien czas aktualizowana. Operacyjna (korporacyjna) baza danych służy do rejestrowania bieżących operacji. Coraz częściej umieszczone w niej dane są wykorzystywane do analizy prowadzonej przez kierownictwo średniego i wyższego szczebla i są jednym z elementów wykorzystywanych w procesie podejmowania decyzji. Wzrost wielkości bazy danych, zwiększen ie liczby użytkown ików rejestrujących w niej bieżące transakcje (zwłaszcza, jeśli użytkownikami są również klienci) oraz wykorzy stujących zgromad zone dane w procesie podejmowania decyzji, prowadzi do spadku wydajności – system zarządzania bazą danych staje się coraz bardziej obciążony i wzrasta czas oczekiwania na odpowiedź lub wykonanie kwerendy funkcjonalnej. Problemowi temu mają zaradzić hurtownie danych, których budowa pozwala na podział danych zgromadzonych w bazie danych na dwie rozłączne części: – bazę transakcyjną, zawierającą dane najświeższe, aktualne, będące przedmiotem bieżących działań operacyjnych, – hurtownię (lub składnicę) danych, zawierającą głównie dane historyczne, pochodzące zarówno z organ izacji, jak i z jej otoczenia, dostarczającą danych analitycznych wykorzystywanych w procesie podejmowania decyzji. Rozwiązanie takie prowadzi do wzrostu efektywności systemu: baza transakcyjna nie jest obciążona danymi historycznymi, czyli jest mniej obszerna, nie jest też obiektem zapytań wybierających dane analityczne, działa więc efektywniej – dane są zwracane szybciej, szybciej też wykonywane są kwerendy funkcjonalne. Hurtownia danych zawiera dane historyczne i do niej kierowane są zapytania analityczne. Poprzez odpowiedni projekt hurtowni można uzyskać zwiększenie jej wydajności – może ona bowiem zawierać pola wyliczane oraz dane będące wynikiem działania funkcji agregujących, co w znormalizowanych bazach trans-.

(3) System interaktywnego wspomagania…. 223. akcyjnych jest niedopuszczalne. Pomiędzy obydwoma bazami danych istnieje jednok ierunkowy związek – hurtownia jest okresowo aktualizowana danymi pochodzącymi z bazy transakcyjnej. Projekt hurtowni danych powinien uwzględniać bieżące i przyszłe potrzeby użytkowników. Ponieważ nie wszystkie potrzeby da się przewidzieć, aplikacja wybierająca dane z hurtowni i prezentująca je użytkownikowi musi umożliwiać budowanie zapytań ad hoc. Najlepszym rozwiązaniem byłoby stworzenie mechanizmu wspomagającego tworzenie kwerend wybierających w języku naturalnym. Realizacja tego postulatu jest trudna zarówno ze względu na złożoność składni języka SQL, jak i niejednoznaczność języka naturalnego. W artykule podjęto próbę rozwiązania pośredniego. Kwerenda jest tworzona przez użytkownika. Proces ten jest wspomagany poprzez kierowanie do niego pytań, a do uzyskania odpowiedzi zaproponowano ogólnie dostępne narzędzia używane w formularzach stosowanych w aplikacjach bazodanowych. 2. Analiza składni zapytania wybierającego Najczęściej używaną instrukcją języka SQL służącą do tworzenia zapytań wybierających jest SELECT1. Analiza całej jej składni jest zadaniem złożonym, dlatego do dalszych rozważań przyjęty zostanie fragment tej instrukcji. Oznacza to, że nie będzie wyczerpana całość rozważanego zagadnienia, niemniej jednak zaprezentowane rozwiązanie może posłuż yć do budowy całej klasy zapytań i zastąpić wiele szczegółowych formularzy. Analizie zostanie poddany poniższy fragment instrukcji SELECT: SELECT [DISTINCT] atrybuty_wybrane_z_tabel, pola_wyliczane, funkcje_agregujące FROM tabele_użyte_w_zapytaniu_wraz_z_klauzulami_ograniczającymi WHERE warunek_selekcji_rekordów GROUP BY atrybuty_grupowania HAVING warunek_selekcji_grup ORDER BY argumenty_ sortowania;. W zaprezentowanym fragmencie instrukcji można wyróżnić następujące elementy, co do których musi być podjęta decyzja w procesie tworzenia kwerendy: – wskazanie pól (atrybutów) pochodzących z tabel bazy danych, które mają pojawić się w tabeli wynikowej zapytania (parametry klauzuli SELECT), – utworzenie pól wyliczanych na podstawie atrybutów występujących w bazie danych (SELECT), – wykorzystanie funkcji agregujących (SELECT), 1. Drugą jest TRANSFORM, używana do tworzenia zapytań krzyżowych..

(4) Dariusz Put. 224. – wskazanie tabel użytych do utworzenia zapytania oraz typu złączeń między nimi wraz z nazwami pól, na podstawie których mają być wykonane złączenia (zależn ie od użytej składni te elementy zapytania występują tylko w klauzuli FROM lub we FROM i WHERE), – utworzenie warunku logicznego będącego podstawą selekcji rekordów (WHERE), – wskazanie pól stanowiących podstawę grupowania (GROUP BY), – utworzenie warunku selekcji grup na podstawie wybranych atrybutów agregacji i (lub) atrybutów powstałych z wykorzystaniem funkcji agregujących (HAVING), – sortowanie danych wyjściowych (ORDER BY), – eliminacja powtarzalnych rekordów (użycie klauzuli DISTINCT). Wymienione składniki mogą się pojawić w zapytaniu w różnej konfiguracji i koniunkcji (użycie niek tór ych wymaga zdefiniowania innych, możliwość stworzenia jednych jest uwar unkowana wcześniejszym powstaniem innych), co dodatkowo komplikuje zadanie. Aplikacja umożliwiająca utworzenie zapytania wybierającego musi być zrozumiała i czytelna dla użytkownika oraz umożliwiać przetworzenie podjętych przez niego decyzji na instrukcję języka SQL. pola wybrane z tabel bazy danych. sortowanie. tabele i złączenia. funkcje agregujące pola wyliczane wybór pól do grupowania warunek wyodrębnienia grup. warunek wyboru rekordów. Rys. 1. Powiązania pomiędzy elementami kwerendy wybierającej Źródło: opracowanie własne..

(5) System interaktywnego wspomagania…. 225. Analizując powiązania pomiędzy wyróżnionymi składnikami zapytania (rys. 1) można zauważyć, że elementem, na który ma wpływ najwięcej innych, jest wybór tabel wraz z istniejącymi między nimi złączeniami. Z kolei na największą liczbę innych elementów wpływa decyzja o wykorzystaniu grupowania rekordów: w zapytaniu, w którym występuje grupowanie mogą być użyte funkcje agregujące, wybrane pola (atrybut y) pochodzą z konkretnych tabel, względem atrybutów grupowania może się odbywać sortowanie, wykorzystanie grupowa nia ogranicza możliwość wyboru pól do tabeli wynikowej zapytania, pozwala na utworzenie war unku selekcji grup. Także decyzja o utworzeniu pól wyliczanych ma wpływ na kilka składników zapytania: w polach wyliczanych można użyć atrybutów występujących w różnych tabelach bazy danych, mogą być podstawą sortowania, atrybutem grupowania lub funkcji agregujących. Powyższa analiza prowadzi do wniosku, że budowa kwerendy musi się odbywać w ściśle określonej kolejności: decyzja dotycząca danego parametru zapytania może być podjęta dopiero, gdy znane są już rozstrzygnięcia dotyczące tych, które mają na niego wpływ. 3. Modele hurtowni danych Przeznaczeniem hurtowni danych jest przechowywanie danych historycznych. Podstawę jej projektu stanowią zidentyfikowane potrzeby analityczne użytkowników. Hurtownia danych to swego rodzaju baza danych, która charakteryzuje się: – ukierunkowaniem na temat. Projekt organizacji danych musi być poprzedzony analizą wymagań w zakresie przetwarzania danych i w konsekwencji identyfikacją tematów, które powinny zostać umieszczone w bazie danych hurtowni. Wybór konkretnych atrybutów do tabel tej bazy danych będzie się odbywał w kon tekście ich przydatności do opisu poszczególnych tematów z punktu widzenia potrzeb użytkownika; – nieulotnością. Dane raz umieszczone w hurtowni zazwyczaj pozostają niezmienione. Identyczne zapyt anie skierowane do hurtowni i dotyczące tego samego okresu zawsze zwróci taki sam wynik niezależnie od tego, kiedy zostanie zadane; – zintegrowaniem. Dane są jednolite – wszystkie atrybuty przechowujące wartość takiego samego rodzaju (np. nazwisko, adres, datę) posiadają identyczny typ oraz format. Ponadto informacje są kodowane w sposób jednoznaczny (np. pole Płeć zawiera wartości K lub M); – zmiennością w czasie. Hurtownia danych jest okresowo odświeżana. Wszystkie dane zapisywane w hurtowni muszą być uzupełnione o wymiar czasowy określający moment zaistnienia zmian, a gdy jest to niemożliwe, moment zapisania ich w hurtowni..

(6) Dariusz Put. 226. Ze względu na rolę, jaką hurtownia spełnia w systemie, musi być odpowiednio zaprojektowana. Choć jest ona swego rodzaju bazą danych, proces jej projektowania różni się od takiego procesu dla analitycznej bazy danych, gdyż w powstałym w jego wyniku systemie należy uwzględnić specyficzne zadania, jakie ma spełniać hurtownia. Projektowanie hurtowni danych składa się z pięciu etapów. 1. Identyfikacja potrzeb analitycznych, propozycja tematów, identyfikacja źródeł danych oraz weryfikacja tematów pod kątem istnienia odpowiednich danych. Ten początkowy etap projektu ma na celu określenie potrzeb analitycznych organizacji oraz możliwości ich zaspokojenia z uwagi na dostęp do odpowiednich danych. Końcowy użytkownik systemu może mieć różne, nawet najbardziej wyszukane wymagania analityczne, może się jednak okazać, że są one niemożliwe do spełnienia ze względu na brak danych zarówno w operacyjnej bazie danych, jak i możliwości ich uzyskania z zewnątrz. Potrzeby analityczne niemożliwe do spełnienia w teraźniejszości mogą być dostępne w przyszłości, jeśli niezbędne dane istnieją, lecz do tej pory nie były zbierane. W takiej sytuacji trzeba dokonać modyfikacji analitycznej bazy danych, co pozwoli zainicjować gromadzenie pewnych dodatkowych danych, które następnie zostaną umieszczone w hurtowni. Hurtownia danych jest zawsze ukierunkowana na temat. Identyfikacja potrzeb analitycznych prowadzi do zaproponowania tematu lub tematów, któr ych dotyczyć będzie projekt. 2. Wybór modelu i projekt logiczny. Zdefiniowano dwa modele logiczne, według których buduje się hurtownie danych (rys. 2): a). b). Tabela tematu Tabela tematu. Tabela faktów. Tabela tematu Tabela tematu. Tabela tematu Tabela tematu. Tabela tematu. Tabela tematu. Tabela tematu. Tabela faktów. Tabela tematu. Rys. 2. Modele logiczne hurtowni danych: a) gwiazda, b) płatek śniegu Źródło: opracowanie własne.. Tabela tematu.

(7) System interaktywnego wspomagania…. 227. – schemat gwiazdy, w którym istnieje jedna tabela faktów oraz wiele połączonych z nią tabel wymiarów, – schemat płatka śniegu, w którym tabele wymiarów są dodatkowo połączone z innymi tabelami, co w efekcie daje wymiar hierarchiczny. W modelu gwiazdy tabele wymiarów zawierają wartości zagregowane i wyliczane, dzięki czemu nie muszą być połączone z innymi tabelami. W modelu płatka śniegu w tabelach wymiarów znajdują się, podobnie jak w korporacyjnej bazie danych, wyłącznie wartości atomowe, przez co tabele te muszą być niekiedy połączone z innymi, zawierającymi dane umożliwiające tworzenie wyliczeń i agregacji. Na proces projektowania schematu logicznego hurtowni danych składają się: – wybór tematu (tematów) hurtowni oraz utworzenie projektu tabeli (tabel) faktów – tabela taka znajduje się w centrum modelu logicznego, – wybór modelu hurtowni (gwiazda, płatek śniegu), – definicja wymiarów i utworzenie tabel wymiarów. 3. Przygotowanie danych. Aby wyniki analiz były wiarygodne, dane stanowiące ich podstawę muszą być dobrej jakości. Jednym z etapów procesu tworzenia hurtowni danych jest wybór danych i eliminacja ewentualnych błędów. Dane mogą pochodzić z różnych systemów, także takich, co do których nie ma pewności, czy zostały zaprojektowane w sposób zapewniający zachowanie integralności oraz czy integralność, nawet jeśli była uwzględniona w projekcie, była weryfikowana podczas eksploatacji systemu. Błędy w bazie danych mogą być wynikiem złego projektu, braku odpowiednich reguł integralności lub pomyłek podczas wprowadzania, usuwania i modyfikacji danych. Można je podzielić na dwie kategorie: – błędy oczywiste – są to błędy nie budzące wątpliwości; do tej kategorii należą wartości niewiar ygodne, niemożliwe w kontekście innych wartości lub wartości poza zakresem, – błędy ukryte, których wykrycie jest trudne, a niejednokrotnie niemożliwe. Procedury sprawdzające jakość danych powinny wykryć wszystkie błędy oczywiste. W wypadku pozostałych decyzja musi być podjęta na podstawie intuicji i doświadczenia projektanta systemu lub na podstawie przyjętych reguł. Szacuje się, że proces „czyszczenia” danych zajmuje nawet do 80% czasu przeznaczonego na przygotowanie całego projektu. Etapu tego nie wolno zaniedbać, gdyż błędne dane mogą zniweczyć wszystkie wysiłki i prowadzić w przyszłości do mylnych wniosków. 4. Okresowe uzupełnianie danych. W projekcie hurtowni należy uwzględnić mechanizmy służące do okresowego uzupełniania danych pochodzących niejednokrotnie z różnych źródeł, przez co trzeba zaprojektować reguły aktualizacji dla każdego źródła osobno. Najprościej stworzyć takie mechanizmy dla danych pochodzących z własnej bazy operacyjnej. W wypadku danych obcych należy zapewn ić możliwość stałego lub okresowego dostępu do nich projektowanego systemu..

(8) Dariusz Put. 228. Zależnie od stawianych przed hurtowniami wymagań dotyczących aktualności przechowywanych danych aktualizacja może następować w różnych okresach (np. codziennie, raz w tygodniu). Proces ten powinno się umiejscowić w okresie spodziewanego najmniejszego obciążenia systemu (w nocy, w weekendy). Okresowe przenoszenie danych operacyjnych do hurtowni może odbywać się automatycznie. Jest to możliwe, o ile w procesie projektowania systemu uwzględniono taką możliwość i dokonano odpowiedniej weryfikacji bazodanowego systemu operacyjnego, dzięki czemu w chwili przenoszenia danych do hurtowni są one kompletne i poprawne. W wypadku danych zewnętrznych (pochodzących od klienta, z obcych baz danych lub od organizacji komercyjnych) procedura auto matycznej aktualizacji może być bardziej skomplikowana lub nawet niemożliwa. Za każdym razem trzeba będzie dokonywać weryfikacji otrzymanych danych pod kątem istnienia błędów, poprawiać je, dostosowywać ich format do tych zapisanych w hurtowni. 5. Okresowa weryfikacja potrzeb analitycznych i ewentualna modyfikacja hurtowni danych. Utworzenie hurtowni danych, wypełnienie jej danymi i wdrożenie nie kończy procesu. Organizacje są dynamiczne, na przestrzeni miesięcy lub lat zmiany mogą obejmować wszystkie ich działy i obszary działalności. Konieczna więc będzie okresowa weryfikacja tematyki hurtowni i ewentualne dostosowanie jej do nowych, zmienionych warunków: zidentyfikowanie nowych potrzeb, weryfikacja przydatności istniejących, zbadanie możliwości wykorzystania nowych źródeł danych. Hurtownia danych powinna być bazą otwartą, aby nowe potrzeby analityczne mogły być w niej uwzględnione w sposób jak najbardziej płynny i niewymagający przebudowy całego systemu. Wybór modelu Identyfikacja tematu (tematów). Okresowa aktualizacja danymi zewnętrznymi. Projekt schematu bazy danych hurtowni Przygotowanie danych Zasilenie hurtowmi danymi. Rys. 3. Proces projektowania hurtowni danych Źródło: opracowanie własne.. Okresowa aktualizacja danymi operacyjnymi. Okresowa aktualizacja danymi operacyjnymi.

(9) System interaktywnego wspomagania…. 229. 4. Model hurtowni danych a składnia zapytania wybierającego Jak wynika z przeprowadzonej analizy zobrazowanej na rys. 1, wykorzystanie agregacji w zapytaniach wybierających ma największy wpływ na złożoność ich składni. Dzięki temu, że hurtownia danych może zawierać wartości zagregowane i wyliczane, uwzględnienie ich w schemacie przyczyni się do uproszczenia składni zapytania wybierającego, a to z kolei ułatwi zaprojektowanie uniwersalnego i nieskomplikowanego – co ma szczególne znaczenie dla użytkownika – kreatora zapytań. Projektując hurtownię danych, należy więc wziąć pod uwagę potrzeby użytkowników oraz umieścić w niej wszystkie wartości zagregowane i wyliczane, co do których istnieje uzasadnione przypuszczenie, że będą użyteczne w procesie wyszukiwania danych analitycznych. Jednym z głównych postulatów, który należy wziąć pod uwagę, projektując system wspomagania tworzenia zapytania dla użytkownika, jest ukrycie przed nim szczegółów dotyczących systemu przechowującego dane. Nie można też wymagać znajomości składni języka SQL i szeregu zagadnień związanych z aspektami formalnymi zapytania, takimi jak na przyk ład złączenia. Problem jest to, że wraz ze wzrostem ułatwień dla użytkownika rośnie poziom abstrakcji, a to pociąga za sobą konieczność zastosowania pewnych uproszczeń w projektowanym systemie. Należy też zauważyć, że większość zapytań kierowanych do hurtowni danych dotyczy operacji wykonanych w wybranym okresie, często wykorzystywane są także funkcje agregujące. W zaproponowanym mechanizmie wspomagającym tworzenie zapytań do hurtowni danych uwzględniono te postulaty i przyjęto następujące założenia: – hurtownia danych oparta jest na modelu gwiazdy, – w tworzonych zapytaniach zawsze wykorzystywane są funkcje agregujące, – wszystkie złączenia są złączeniami wewnętrznymi, – każde zapytanie dotyczy wskazanego przez użytkownika okresu. Mimo związanych z tym ograniczeń utworzona na podstawie proponowanego projektu aplikacja będzie przydatna do budowy całej klasy użytecznych zapytań analitycznych. Można w niej wykorzystać mechanizmy powszechnie stosowane w formularzach, np. pola tekstowe lub listy wyboru. Z punktu widzenia użytkownika tworzenie zapytania będzie się sprowadzało do podjęcia decyzji dotyczących: – wyboru pól do tabeli wynikowej. Na liście atrybutów pojawiają się nazwy wszystkich pól hurtowni danych, z któr ych użytkownik wybiera te, które mają zostać umieszczone w tabeli wynikowej. Nazwy pól mogą być identyczne z tymi występującymi w tabelach hurtowni danych (w takiej sytuacji należy ten fakt uwzględnić w projekcie – nazwy muszą być znaczące) lub mogą być zmienione, aby były czytelne dla użytkownika (wtedy należy zastosować tabele metadanych);.

(10) 230. Dariusz Put. – wskazania przedziału czasowego. Operacja będzie polegać na wpisaniu lub wskazaniu za pomocą listy wyboru dwóch dat: początkowej i końcowej. Na tej podstawie utworzony zostanie warunek ograniczający i umieszczony w klauzuli WHERE zapytania; – utworzenia warunku selekcji rekordów; – tworzenie takich warunków może być wspomagane poprzez listę dostępnych pól; – wybrania funkcji agregujących i wskazania pola-parametru dla każdej funkcji; – wskazania atrybutów sortowania. Atrybuty te będą wyselekcjonowane spośród pól wybranych do tabeli wynikowej w pierwszym kroku oraz pól będących wynikiem działania funkcji agregujących (krok czwarty). Ustalenie tych argumentów może być wspomagane listą wyboru. Tak utworzone zapytanie musi być uzupełnione o odpowiednie złączenia. Wybór tabeli i utworzenie klauzuli łączącej musi się odbywać poza użytkownikiem, na podstawie ustalonych przez niego atrybutów zapytania. Aby sprostać temu zadaniu oraz aby ułatwić komunikację systemu z użytkownikiem podczas podejmowania przez niego decyzji, w projekcie fizycznym hurtowni należy umieścić pewne informacje, tworząc tabele pomocnicze (tabele metadanych). Proponowana struktura takich tabel przedstawia się następująco: CREATE TABLE Atrybuty ( nazwa_pola string primary key, alias_pola string not null unique, typ_pola string not null, nazwa_tabeli string not null); CREATE TABLE Złączenia ( zestaw_tabel string primary key, złączenie string not null);. W polu nazwa_pola przechowywane są nazwy tych pól hurtowni danych, które będą udostępniane użytkownikowi w procesie tworzenia zapytania. Nazwy te są identyczne z występującymi w hurtowni. Użytkownik może także korzystać ze zdefiniowanych tutaj pól wyliczanych, jeśli pól takich nie uwzględniono projekcie hurtowni danych. Wartość wyliczana zostanie wtedy umieszczona w polu nazwa_pola. Alias_pola zawiera nazwę, która będzie prezentowana użytkownikowi – nazwa taka powinna być czytelna, najczęściej dłuższa niż nazwa pola w hurtowni, i jednoznacznie wskazywać, jakiego rodzaju wartość jest przecho wywana (lub wyliczana) w polu. Poprzez odpowiednią zawartość tabeli Atrybuty można wpływać na to, które pola będą dostępne przy tworzeniu kwerendy i zróż nicować ich zbiór dla poszczególnych użytkowników. Aby w praktyce osiągnąć takie zróżnicowanie konieczne będzie utworzenie dodatkowych mechanizmów.

(11) System interaktywnego wspomagania…. 231. (np. dodatkowej tabeli). Dane umieszczone w polu typ_pola będą wspomagać tworzenie funkcji agregujących (na przykład po wybraniu funkcji Suma dostępne będą tylko pola numer yczne). Jeśli podczas tworzenia zapytania użyte zostanie pole z hurtowni danych, automatycznie wybierana będzie tabela, z której to pole pochodzi. Wybór będzie możliwy dzięki umieszczeniu w tabeli Atrybuty pola nazwa_tabeli. Po zakończeniu tworzenia zapytania przez użytkownika informacje o tabelach posłużą do wybrania gotowej klauzuli wybierającej tabele i definiującej złączenia z pola złączenie tabeli Złączenia. 5. Przykład praktycznego zastosowania Proponowane rozwiązanie może służyć do tworzenia całej klasy zapytań wybierających opartych na złączeniach naturalnych oraz zawierających funkcje agregujące. Zaprezentowany przykład oparty jest na fragmencie hurtowni danych (rys. 4), w której tematem jest sprzedaż analizowana z punktu widzenia: – oddziałów, w których jest realizowana, – towarów, które są sprzedawane, – klientów, którzy nabywają towary, – czasu, kiedy miała miejsce operacja.. Rys. 4. Fragment hurtowni danych, której tematem jest sprzedaż Źródło: opracowanie własne..

(12) 232. Dariusz Put. Fakty informujące o zrealizowanej sprzedaży są umieszczone w tabeli Sprzedaż. Dane o oddziałach, klientach i towarach są przechowywane w tabelach wymiarów. Tabela Czas zawiera daty dokonanych transakcji, ale także pola określające, w którym tygodniu, miesiącu i roku miała miejsce sprzedaż. Te dodatkowe pola ułatwią tworzenie zapytań przekrojowych (dotyczących wybranych miesięcy, tygodni, lat). Klucze podstawowe tabel wskazują jednoznacznie na przechowywane w nich obiekty. W wypadku zmiany atrybutów obiektów przechowywanych w tabelach wymiarów (np. adresu klienta lub oddziału, ceny towaru lub innych jego atrybutów), do tabel tych dodawane będą nowe rekordy zawierające aktualne dane. Oznacza to, że w hurtowni będą przechowywane dane historyczne i aktualne tego samego obiektu, co nie powinno mieć miejsca w operacyjnej bazie danych. Umożliwi to śledzenie zachodzących zmian w organizacji i jej otoczeniu. Przykładowe zadanie polega na wyszukaniu wartości sprzedaży zrealizowanej przez każdy z oddziałów oddzielnie, obejmującej wybraną kategorię towarów (stoły bilardowe) w poszczególnych miesiącach pierwszego półrocza 2005 r. Użytkownik otrzymuje kolejno formularze, w których podejmuje decyzje: 1) z listy dostępnych pól wybiera: – miesiąc, – id_oddziału, – wartość_sprzedaży (jest to pole pochodzące z tabeli metadanych, wyliczane jako liczba_jednostek_towaru * cena_jednostkowa); 2) ustala zakres czasowy tworzonego zapytania podając datę początkową (1.01.2005) i końcową (30.06.2005); 3) tworzy inne warunki ograniczające: wybiera kategorię towaru (stół bilardowy), której ma dotyczyć zapytanie; 4) Wybiera pole wartość_sprzedaży i dla niego funkcję agregującą Suma; 5) za pomocą listy zawierającej wyłącznie pola wybrane do tabeli wynikowej (łącznie z polem wyliczanym) decyduje o atrybutach sortowania. Należy zwrócić uwagę, że dla niektórych pól wybranych przez użytkownika tworzone są warunki logiczne (czas.data_sprzedaży, towary.kategoria), dla innych wskazywane są funkcje agreg ujące (wartość_sprzed aży), pozostałe są parametrami grupowania (oddziały.id_oddziału, czas.miesiąc). Pola użyte w zapytaniu pochodzą z czterech tabel: Sprzedaż, Towary, Oddziały, Czas. Wybrana na tej podstawie z tabeli metadanych klauzula złączenia rekordów uzupełnia instrukcję SELECT, której ostateczna postać jest następująca: SELECT Czas.miesiąc, Oddziały.id_oddziału, Sum([sprzedaż].[liczba_jednostek_towaru]*[sprzedaż].[cena_jednostkowa]) AS wartość_sprzedaży FROM Czas INNER JOIN (Towary INNER JOIN (Oddziały INNER JOIN Sprzedaż ON Oddziały.id_oddziału = Sprzedaż.id_oddziału) ON Towary.id_towaru = Sprzedaż. id_towaru).

(13) System interaktywnego wspomagania…. 233. ON Czas.id_data_sprzedaży=sprzedaż.id_data_sprzedaży WHERE (Czas.data_sprzedaży Between „01-01-2005” And „30-06-2005”) And (Towary.kategoria = „stół bilardowy”) GROUP BY Oddziały.id_oddziału, Czas.miesiąc;. 6. Wnioski Zaprezentowana propozycja systemu wspomagającego tworzenie zapytania do hurtowni danych bezpośrednio przez użytkownika poparta analizą problemu i przykładem praktycznym świadczy o złożoności problemu. Praktyczna użyteczność takiego rozwiązania jest uwarunkowana zarówno czynnikami związanymi z samym użytkownikiem, jak i elastycznością projektu. Użytkownik nie musi posiadać teoret ycznej wiedzy o bazach (hurtowniach) danych, ich strukturze logicznej, składni zapytania wybierającego czy celowości i sposobu budowy złączeń. Ponieważ nie posługuje się językiem naturalnym, a pewnym szablonem, musi jednak posiadać pewną wiedzę, m.in.: – co zawierają poszczególne pola hurtowni danych, do których ma dostęp, – na jakiej zasadzie działa grupowanie rekordów oraz jak działają funkcje agregujące, – jak tworzyć warunki ograniczające. Przeprowadzona analiza pozwala na wskazanie następujących cech decydujących o przydatności zaprezentowanego rozwiązania: – użytkownik nie musi znać struktury hurtowni danych, składni instrukcji SELECT, nie musi wiedzieć co to jest tabela, relacja, złączenie itd., – utworzony szablon może być wykorzystany do budowy zapytań wybierających przez użytkownika i może zastąpić wiele szczegółowych formularzy i zapytań, – dodatkowa pomoc na temat sposobu budowy zapytań może być dostępna bezpośrednio w formularzu poprzez wykorzystanie hipertekstu, – użytkownik może mieć dostęp tylko do tych pól, z których rzeczywiście korzysta, dzięki odpowiedniej zawartości tabel metadanych zawierających informacje o hurtowni danych. Liczba pól może być zróżnicowana i dopasowana do potrzeb poszczególnych użytkowników oraz łatwo modyfikowana, – zaprezentowane rozwiązanie jest elastyczne – raz utworzone może być wyko rzystane w różnych aplikacjach hurtowni danych. Każdorazowej zmiany wymagać będzie tylko zawartość tabel metadanych. Zastosowanie zaprezentowanego rozwiązania musi być uwzględnione w proje kcie hurtowni danych, który należy uzupełnić o tabele metadanych ułatwiające tworzenie kwerendy przez użytkownika oraz budowę instrukcji w języku SQL. Aby ułatwić użytkownikowi wybór atrybutów do kwerendy, podczas projektowania należy zwrócić szczególną uwagę na nazwy pól, które powinny być znaczące.

(14) 234. Dariusz Put. i jednoznacznie wskazywać, co w danym polu jest przechowywane. Proponowany schemat jest rozwiązaniem pośrednim między zastosowaniem języka naturalnego a instrukcją SELECT. Skuteczność jego wdrożenia zależy od odpowiedniego prze szkolenia osób, które będą z niego korzystać. W porównaniu z podejściem tradycyjnym, polegającym na tworzeniu wielu szczegółowych formularzy, rozwiązanie takie jest bardziej elastyczne. Może też skrócić czas tworzenia aplikacji, również dzięki temu, że raz utworzone może być wykorzystywane wielokrotnie w różnych systemach. Projekt hurtowni danych powinien uwzględniać bieżące i przyszłe potrzeby analityczne organizacji, dla której jest tworzony. Ze względu na to, że przyszłe potrzeby są trudne do jednoznacznego zidentyfikowania, w projekcie hurtowni należy zaprojektować i utworzyć mechanizmy, które umożliwią tworzenie zapytań ad hoc przez użytkowników. Mechanizmy takie powinny być możliwie najmniej skomplikowane, przez co konieczne jest zapisanie w projekcie hurtowni danych dodatkowych elementów, takich jak: tabele metadanych, tabele zawierające funkcje agregacyjne, formularze umożliwiające tworzenie zapytań analitycznych, procedury przekształcające zapytania utworzone w formie interaktywnej na instrukcje w SQL oraz procedury prezentujące dane pobrane z hurtowni danych w formie atrakcyjnej dla użytkownika. Ta dodatkowa praca ułatwi użyt kownikom uzyskiwanie żądanych informacji i pomoże w podejmowaniu trafnych decyzji obecnie i w przyszłości. Literatura Beynon-Davies P. [2003], Systemy baz danych, WNT, Warszawa. Chi R., Shim J. K., Siegel J. G. [1999], Technologia informacyjna, Biblioteka Praktyków Zarządzania, Dom Wydawniczy ABC, Warszawa. Date C. J. [2000], Wprowadzenie do systemów baz danych, WNT, Warszawa. Ladanyi H. [2000], SQL. Księga eksperta, Helion, Gliwice. Put D. [2004], Propozycja uniwersalnego kreatora zapytań dla użytkownika bazy danych, Materiały z Konferencji „Informatyka Narzędziem Współczesnego Zarządzania”, Wydawnictwo PJWSTK, 9 X 2004, Warszawa. Todman C. [2003], Projektowanie hurtowni danych, WNT, Warszawa. Trueblood R.P., Lovet J.N. jr. [2002], Zastosowanie języka SQL do analizy statystycznej i eksploracji danych, Mikom, Warszawa. Interactive System Supporting the Information Searching in Data Warehouses Data stored in a database can be a source of analytical knowledge that is a significant factor in a decision-making process. Such a data utilisation is possible if a database.

(15) System interaktywnego wspomagania…. 235. contains historical records, what in turn can have an unfavourable influence on a system efficiency, slowing down its performance. The goal of data warehouses creation is to separate transactional (current) from historical data and, consequently, to enhance the system operation. A considerable part of a data warehouse is a queries system. During a data warehouse creation process, all current and particularly future analytical needs of system users are difficult to be considered. Therefore, a module of queries formulation should definitely be flexible and should enable searching for data that is necessary at any moment – now and in future. A sufficient data warehouse project, which takes this demands into account, will facilitate creation of a tool for self-supporting queries formulation. The article discusses issues concerning construction of data searching support system for a data warehouse. Key words: database, data warehouse, data warehouse model, SQL, query..

(16)