Spis treści

I Wstęp

• Wstęp

Działalność każdej firmy wiąże się z tworzeniem i zapamiętywaniem dużej ilości danych różnego rodzaju - o klientach, rynkach, sprzedaży. W przypadku dużych firm ilość tych danych jest ogromna i stale rośnie. Oczywiście dane te nie są gromadzone bez powodu - ich staranna analiza dostarcza wielu informacji i często ułatwia podejmowanie strategicznych dla firmy decyzji. W praktyce okazuje się jednak, że im większa liczba danych, tym trudniejszy dostęp do nich. Jesteśmy wprawdzie w stanie je magazynować, jednak ich ilość uniemożliwia efektywne odszukiwanie i przeglądanie niezbędnych informacji. Eksperci szacują, że w dużych firmach decydenci mają dostęp do bardzo niewielkiej części zgromadzonej informacji, a przecież właśnie ona stanowi podstawę, przy podejmowaniu ważnych decyzji. Zjawisko to określa się czasem „uwięzieniem danych”.

Magazyn danych (hurtownia danych, ang. data warehouse) jest próbą rozwiązania tego problemu - wydobycia z ogromnych baz danych niezbędnej wiedzy. Hurtownie przechowują informację, analizowaną później z wykorzystaniem technik OLAP (przetwarzanie analityczne na bieżąco - On-Line Analitycal Processing), a przechowywana informacja ma zwykle charakter wielowymiarowy. Hurtownie danych są więc praktycznym wykorzystaniem trzech nowoczesnych trendów rozwojowych obejmujących:

• przetwarzanie analityczne na bieżąco (OLAP - on-line anaytical processing),

• wielowymiarowe bazy danych,

• odkrywanie wiedzy.

1. Cel i zakres pracy

Celem pracy jest zaprojektowanie i implementacja systemu hurtowni danych o określonych wymaganiach. Najważniejsze przedstawiono poniżej:

• W odróżnieniu od istniejących i działających na rynku systemów OLAP, chcielibyśmy, aby nasz system utrzymywał przez cały czas pracy aktualne dane - czyli dbał o ich spójność z danymi zawartymi w źródłowych bazach danych. Cecha ta staje się pożądana ponieważ od aktualnej informacji zgromadzonej w hurtowni zależą strategiczne decyzje dotyczące rozwoju firmy.

• Wymóg aktualności danych w magazynie stawia kolejne wymaganie - efektywność procesu aktualizacji danych w magazynie. Pożądane jest zminimalizowanie czasu między zmianą danych w źródłowych bazach danych, a aktualizacją danych w magazynie. Dlatego przyjęliśmy, że dane w magazynie powinny być składowane przyrostowo (inkrementalnie) - oznacza to aktualizowanie magazynu jedynie o nowe informacje, uwzględniając jego poprzednią zawartość.

• Praktyka pokazuje, że gotowe oprogramowanie wymaga pielęgnacji, a praca nad projektem kończy się dopiero w momencie zaprzestania jego używania. Dlatego podstawową cechą umożliwiającą użytkowanie systemu i dostosowywanie do zmieniających się warunków jego pracy jest łatwość jego rozbudowy. Chodzi przede wszystkim o możliwość obsługi nowych standardów baz danych oraz możliwość wykorzystania informacji magazynowych w tworzonych na potrzeby firmy aplikacjach.

Architektura systemu

Na poniższym rysunku przedstawiono schemat systemu umożliwiającego spełnienie podanych wymagań:




Otoczenie systemu stanowią źródłowe bazy danych (na rysunku źródła) i z nich czerpane są informacje, które magazynujemy. Miejscem ich magazynowania jest magazyn danych (ang. data warehouse). Jak widać na rysunku, całość systemu składa się z czterech modułów. Moduł integratora jest odpowiedzialny, za składowanie danych w magazynie. Nie odwołuje się on jednak bezpośrednio do źródłowych baz danych, lecz za pośrednictwem modułów pomocniczych. Monitor zajmuje się „śledzeniem” zmian w źródłowej bazie danych i informowaniem o tym integratora. Na tej podstawie integrator wykonuje aktualizację magazynu. Używa w tym celu modułu wrappera, jako pośrednika w odwołaniach do baz danych. Integrator nie musi więc znać szczegółów implementacyjnych związanych z źródłowymi bazami danych. Wszystkie informacje złożone w magazynie są dostępne dla użytkownika za pomocą modułu query processora. Stanowi on interfejs, między magazynem a użytkownikiem - transformuje zapytania użytkownika, wykonuje je i dostarcza gotowe wyniki.

Z przyjętych wcześniej założeń wynika przydział dla każdej źródłowej bazy danych osobnej pary monitor / wrapper. Jedynie te moduły komunikują się bezpośrednio z bazami źródłowymi, więc jedynie one muszą znać odpowiednie protokoły komunikacji i sposoby wymiany danych. Umożliwia to uniezależnienie systemu od systemów zastosowanych w źródłowych bazach danych. Jeżeli chcemy rozbudować nasz system o obsługę nie znanego standardu bazy danych, musimy dopisać te dwa moduły.

Zakres pracy obejmuje zaprojektowanie i implementację czterech modułów systemu:

• moduł monitora,

• moduł wrappera,

• moduł integratora,

• moduł query processora.

Zakładamy opracowanie jednej pary monitor / wrapper dla systemu zarządzania bazą danych firmy Oracle. Zakładamy również, że magazyn danych opierać się będzie również na systemie firmy Oracle. Częścią pracy jest opracowanie ujednoliconych protokołów komunikacji między poszczególnymi modułami a także postaci naszego magazynu - jego słownika i części magazynowej.

1. Podział zadań

Projektując nasz system, podzieliliśmy się zadaniami w następujący sposób:

• moduł wrappera - Daniel Krawiec,

• moduł monitora - Paweł Orzechowski,

• moduł integratora - Krzysztof Ostrowski,

• moduł query processora - Arkadiusz Kaźmierowski.

Zadania opracowania specyfikacji odpowiednich protokołów komunikacyjnych i postaci magazynu przypadają twórcom modułów z nich korzystających, tak więc:

• za opracowanie specyfikacji protokołu używanego do komunikacji między integratorem i monitorem odpowiedzialni są Paweł Orzechowski i Krzysztof Ostrowski,

• za opracowanie specyfikacji protokołu używanego do komunikacji między integratorem i wrapperem odpowiedzialni są Daniel Krawiec i Krzysztof Ostrowski,

• za opracowanie ogólnej struktury magazynu (jego relacji) odpowiedzialni są Arkadiusz Kaźmierowski i Krzysztof Ostrowski,

• opracowania programu ułatwiającego użytkownikowi skonfigurowanie słownika magazynu podjął się Krzysztof Ostrowski.

Wybór języków programowania i narzędzi programistycznych, używanych do tworzenia danego modułu należy do jego twórcy.

• Przetwarzanie analityczne w trybie on-line (OLAP)

1. Wprowadzenie

Słowo OLAP (ang. On-Line Analytical Processing) po raz pierwszy pojawiło się w literaturze w roku 1993 (artykuł E.F. Codd & Associates Providing OLAP to User-Analysts: An IT Mandate). Mimo kilkuletniej historii samego terminu o żadnej z jego definicji nie można powiedzieć, że została powszechnie przyjęta i jest przez wszystkich uznawana. Gdy mówimy - OLAP, myślimy zwykle - narzędzie do wygodnej i szybkiej analizy danych z różnych obszarów działalności przedsiębiorstwa. Najważniejszą, a zarazem jedyną zgodnie podawaną przez wszystkie popularne definicje, cechą technologii OLAP jest wielowymiarowość.

Zadaniem OLAP jest dostarczenie - w jak najefektywniejszy sposób - informacji strategicznej dla danego przedsiębiorstwa i prezentowanie jej zgodnie z ludzkimi schematami poznawczymi. W dużej części obecnych systemów informatycznych jest za dużo danych, a za mało informacji niezbędnej by odpowiedzieć na nurtujące kierowników i analityków pytania. Odpowiedzi te są niejednokrotnie kluczem do utrzymania się firmy na wymagającym, zmieniającym się w szybkim tempie rynku. Narzędzia OLAP zalicza się do kategorii oprogramowania nazywanej systemami wspomagania decyzji; SWD (ang. DSS - Decision Support Systems), która obejmuje oprócz aplikacji wywodzących się z nurtu bazodanowego - jak OLAP - również te powstałe w oparciu o zaawansowane modelowanie matematyczne. Uzupełnieniem powyższych są narzędzia Data Mining czyli eksploracji danych - również operujące na hurtowniach danych - których zadaniem jest odkrywanie pewnych wzorców, schematów czy trendów trudnych do spostrzeżenia innymi metodami. Łącznie, narzędzia te wraz z technologią hurtowni danych noszą miano Business Intelligence (termin Gartner Group) a ich zadaniem jest zamiana źródłowych danych w wartościową informację i dostarczanie jej w ręce użytkownika w celu szybszego podejmowania właściwych decyzji. Przeważnie użytkowników takich narzędzi jest w firmie (lub jej dziale) kilku, kilkunastu. ostatnio jednak panuje trend do rozmieszczania oprogramowania klienckiego OLAP na biurkach pracowników niższego szczebla jak na przykład szefów komórek przedsiębiorstwa tak by mogli stale kontrolować swoją pozycję finansową na tle całej organizacji. Hurtownie danych i systemy OLAP wzajemnie się uzupełniają. Hurtownie gromadzą dane i odpowiednio nimi zarządzają, OLAP przekształca te dane w strategiczną informację.

Wielowymiarowa perspektywa oraz duża interakcyjność analiz wyróżnia narzędzia OLAP spośród innych rodzajów oprogramowania analitycznego. Uważa się, że model ten jest bliski schematowi informacyjnemu człowieka i stanowi naturalny sposób prezentacji i poruszania się wśród danych dotyczących organizacji i jej działalności. Przeciętny użytkownik systemów wspomagania decyzji dyrektor, kierownik czy analityk nie będący przecież specjalistą od baz danych, z trudem porusza się wśród schematów relacyjnych czy poleceń SQL Są to dla niego pojęcia obce i stanowiące dodatkowy balast utrudniający uchwycenie istoty rzeczy.

W przypadku OLAP łatwiej jest ogarnąć przedsiębiorstwo czy organizację jako całość a dzięki prostocie i szybkości analizy zmniejsza się zagubienie w informacji i możliwość jej błędnej interpretacji. Dzięki zgromadzeniu danych w jednym miejscu, w postaci jednej, wspólnej, wielowymiarowej kostki przedsiębiorstwo może być oglądane i analizowane przez wszystkich mających uprawniony dostęp (to ważna cecha odróżniająca OLAP od aplikacji typu EIS gdzie dostęp do nich mieli przeważnie tylko kierownicy wysokiego szczebla). Ten podobny, standardowy sposób prezentacji danych i informacji stanowi wspólny mianownik dla tego typu analiz. Informacja może być stąd wydobywana pod różnymi kątami widzenia - w zależności od tego czy analizy dokonuje kierownik pewnego produktu czy szef marketingu. Ich spojrzenia są różne ale korzystają oni ze wspólnego modelu pojęciowego przedsiębiorstwa

2. Cechy OLAP

Wielowymiarowość nie jest nowym pojęciem. Postrzegamy świat jako trójwymiarowy - aby określić położenie przedmiotu podajemy jego odległość, czy jest na lewo, czy na prawo, wyżej czy niżej. Zwykle kojarzymy linię z jednym wymiarem, płaszczyznę - z dwoma, przestrzeń - z trzema. Próbujemy wyobrażać sobie czas jako czwarty wymiar. W modelach niektórych zjawisk fizycznych jako piąty wymiar traktuje się masę (względnie energię). Matematyka - w przeciwieństwie do ludzkiej percepcji - nie zna ograniczeń na liczbę wymiarów (rozwiązań układu równań z n niewiadomymi szuka się w przestrzeni n-wymiarowej).

Podstawą modelu OLAP są:

• wymiary - opisują kluczowe aspekty działania organizacji jak czas, produkt, usługa, geografia, klient, kanały dystrybucyjne, personel, środki trwałe itd.,

• miary - wartości (przeważnie) liczbowe stanowiące przedmiot analiz takie jak sprzedaż, liczba sztuk, liczba awarii, liczba reklamacji, liczba impulsów.

Koncepcyjnie model ten przedstawia się jako hiperkostkę, która w swoim wnętrzu zawiera miary natomiast wymiary stanowią jej brzegi. Ponieważ wszelkie analizy, porównania, zestawienia dotyczą różnych poziomów szczegółowości wymiary posiadają przeważnie wewnętrzną hierarchiczną strukturę (jedną lub kilka w zależności od potrzeb) ułatwiającą przechodzenie od ogółu do szczegółu i z powrotem.

Wymiary

Podobnie jak w przypadku terminu OLAP, nie istnieje powszechnie przyjęta i stosowana definicja wymiaru. Taki stan rzeczy wynika głównie z faktu, że rynek narzędzi tej klasy jest bardzo młody i dopiero rodzą się porządkujące go standardy, a to z kolei powoduje, że wymiary w kontekście poszczególnych narzędzi różnią się między sobą funkcjonalnością. Bardzo ogólna a zarazem prosta definicja wymiaru pojawiła się na początku niniejszego artykułu - wymiar to zbiór elementów klasyfikujący dane.

Najczęściej używane wymiary mają strukturę drzewa elementów. Takie drzewo nazywane jest hierarchią wymiaru, a grupa elementów położonych na tej samej głębokości w drzewie - poziomem hierarchii. Wymiar może zawierać więcej niż jedną hierarchię (należy wówczas ustalić, która hierarchia ma być hierarchią domyślną), co pozwala zdefiniować różne sposoby przechodzenia „od ogółu do szczegółu” (od sumy dla wszystkich produktów do wartości dla soku jabłkowego, etc.). Struktura wymiaru nie może zawierać cykli, dlatego za pomocą hierarchii (drzew) można przedstawić dowolne prawidłowe powiązania między elementami w wymiarze.

Związki między elementami zwykle mają charakter statyczny. Definiuje się je bezpośrednio, a więc poprzez wskazanie dwóch elementów: rodzica i potomka. Czasem jednak wygodnie jest zdefiniować związki dynamiczne, czyli takie, w których zaistnienie między dwoma elementami relacji rodzic-potomek, zależy od spełnienia ustalonego warunku. Przykładem dynamicznej hierarchii może być podział wszystkich produktów na trzy grupy (wg zysku wygenerowanego w 1998 roku): zysk poniżej 1 mln, zysk od 1 mln do 10 mln, zysk powyżej 10 mln. Warto w tym miejscu zaznaczyć, że kryterium podziału musi opierać się wyłącznie na zawartości bazy danych, a nie może zależeć od aktualnie oglądanego przez użytkownika zestawienia.

Elementom wymiaru można przypisywać atrybuty. Ze względu na przeznaczenie wyróżnia się dwa rodzaje atrybutów: opisowe (tekstowe - adres klienta, numeryczne - waga produktu, inne - data rozpoczęcia sprzedaży produktu) i aliasy. Atrybuty opisowe dostarczają dodatkowych (rzadko zmieniających się lub o mało interesującej z punktu widzenia analizy historii) danych do sporządzania raportów oraz służą do generowania zapytań wewnątrz wymiaru (na przykład: pokaż dane dla produktów o wadze powyżej 1 kg). Aliasy stanowią alternatywny w stosunku do głównych nazw sposób identyfikowania elementów w wymiarze. Cecha ta nabiera ogromnego znaczenia przy tworzeniu aplikacji wielojęzycznych (użytkownik może wybrać, czy chce się posługiwać polskimi, angielskimi, czy niemieckimi nazwami produktów - oczywiście o ile nazwy w podanych językach zostały wcześniej zdefiniowane).

Niektóre narzędzia wyróżniają wymiary kategorii danych (nazywane też wymiarami miar) oraz wymiary czasu. W każdej kostce musi znaleźć się dokładnie jeden wymiar kategorii danych i co najwyżej jeden wymiar czasu. Wymiar kategorii danych definiuje typy danych przechowywanych w kostce (najczęściej dane numeryczne, czasem - tekstowe) i jest silnie związany ze sposobem, w jaki system przechowuje dane zawarte w kostce na dysku i w pamięci operacyjnej. Wymiar czasu podczas analizy jest domyślnie umieszczany w kolumnach tabeli, a na wykresie na osi X, dodatkowo wspomagane jest prezentowanie danych narastająco, na przykład od początku roku.

Model hiperkostki

Kostka to przestrzeń danych zbudowana za pomocą co najmniej dwóch wymiarów. W typowych zastosowaniach liczba wymiarów w kostce nie przekracza 10. Kostki zwykle przechowują dane numeryczne, rzadziej - tekstowe. Zestawienie danych kostki oglądane przez użytkownika nazywane jest widokiem. W widoku wyróżnia się wymiary w wierszach, wymiary w kolumnach oraz wymiary tytułowe.

Dane widoku stanowią podzbiór danych kostki. Istnieją dwa mechanizmy zawężania zbioru danych:

• dla wymiarów w wierszach i kolumnach - wybór podzbioru elementów wymiaru (zwanego też zestawem elementów),

• dla wymiarów tytułowych - rzutowanie kostki na pojedyncze elementy wymiaru.

Poszczególni producenci troszczą się o to, by analizowanie danych stawało się coraz łatwiejsze i jednocześnie jak najbardziej efektywne. Stąd wiele systemów klasy OLAP z jednej strony oferuje użytkownikowi proste mechanizmy tworzenia modeli i przelewania danych z systemów ewidencyjnych, z drugiej - zapewnia płynną zmianę formy wyświetlania danych (tabela, wykres, mapa) oraz wspomaga tworzenie dynamicznych raportów o bogatej szacie graficznej.

Oczywiście analizy sprzedaży nie są jedyną dziedziną zastosowań technologii OLAP. Narzędzia wielowymiarowe używane są także w analizach finansowych, planowaniu strategicznym, sprawozdawczości bankowej, a z zastosowań nietypowych - mogą służyć na przykład do badania skuteczności reklamy.

1. Podział systemów OLAP

OLAP jest dzisiaj postrzegany jako kluczowa technologia dostarczania danych do analiz w wydajny i jednocześnie intuicyjny sposób. Sam termin OLAP nie jest stary, niemniej historia narzędzi tego typu sięga dwadzieścia lat wstecz, kiedy to firma Express tworzyła swój pierwszy produkt, a niektórzy jego korzeni doszukują się w języku APL, opierającym się o wielowymiarowe struktury danych, stworzonym już ponad trzydzieści lat temu. Dzisiaj po firmie Express zachowała się jedynie nazwa produktu, znajdującego się obecnie w ofercie jednego z gigantów rynku baz danych, a termin OLAP możemy usłyszeć wszędzie, często z różnymi, poprzedzającymi go literkami: ROLAP, MOLAP czy HOLAP. Rdzeń wszędzie pozostaje ten sam: OLAP, a wraz z nim to na czym najbardziej zależy użytkownikom: intuicyjność modelu, proste tworzenie raportów, analiz i zapytań „ad hoc”, jednym zdaniem - „dobry interfejs analityczny”. I tak naprawdę na tym podobieństwa się kończą. Poza interfejsem są bowiem jeszcze źródła danych oraz prawdziwe potrzeby użytkownika.

ROLAP

Na początek przyjrzyjmy się „R” jak „relational” czyli „relacyjny”. Relacyjne bazy danych jako źródło danych dla systemów analitycznych wydają się rozwiązaniem najprostszym. Prawie każda firma ma system ewidencyjny oparty o taką bazę danych, zatem nic łatwiejszego niż kupić interfejs, który przedstawi dane w ujęciu wielowymiarowym, zrozumiałym dla analityka. Niestety, chociaż wielu sprzedawców twierdzi, że aby otrzymać upragniony system analityczny wystarczy podłączyć do istniejącej w firmie bazy danych ich produkty, to jednak wdrożenie systemu typu ROLAP prawie zawsze wiąże się co najmniej ze stworzeniem kopii bazy operacyjnej. Dlaczego? Powodów jest wiele.

Istnieje wiele wymogów formalnych dla takich baz. Okazuje się bowiem, że dla systemu OLAP dane trzeba przedstawić w specjalny sposób, który nazywa się układem „gwiazdy” lub „płatka śniegu”. Polega to na tym, że jednemu z wymiarów odpowiada tablica faktów (niestety najczęściej może być tylko jedna), a pozostałe wymiary przechowywane są w dodatkowych tablicach. Hierarchie są budowane na dwa sposoby: dla układu gwiazdy są przechowywane w kolumnach, a w schemacie płatka śniegu - w kolejnych tablicach. Trudno powiedzieć jednoznacznie, które rozwiązanie jest lepsze. W pierwszym zyskujemy na prędkości, w drugim na pamięci dyskowej i trzeba dużego doświadczenia, żeby odnaleźć złoty środek. Można oczywiście wymóg stosowania odpowiedniej struktury zgrabnie ominąć, stosując wirtualne widoki utworzone na znormalizowanej bazie danych. Można tego dokonać budując je bezpośrednio na serwerze bazy danych lub definiując w samym programie. Jednak próba wygenerowania kilku raportów sprawi, że odrzucimy ten, jakże wygodny na pierwszy rzut oka sposób, ze względów wydajnościowych. Dzieje się tak dlatego, że zbudowanie niektórych skomplikowanych wielowymiarowych raportów wymaga wykonania wielokrotnie zagnieżdżonych zapytań. Pozostaje zatem replikacja do dedykowanych struktur.

Potrzeba tworzenia drugiej bazy danych wynika również z innych przesłanek. Od systemów analitycznych wymaga się dużej wydajności bez zaburzania pracy operacyjnej bazy danych, co powoduje konieczność tworzenia oddzielnych zoptymalizowanych struktur, takich jak opisane powyżej. Często istnieje potrzeba zasilania systemu z wielu źródeł, a nawet aplikacji lokalnych, choćby w przypadku wielooddziałowych firm, posługujących się z powodów historycznych, różnymi systemami. Nowa, spójna analityczna baza danych jest wówczas jedynym rozwiązaniem. Kolejnym bardzo istotnym powodem takiej duplikacji jest konieczność oczyszczenia i uzupełnienia danych do analiz. Oprócz tego, że w każdej bazie istnieje niewielki procent przypadkowo niespójnych danych, to dodatkowych problemów nastręczają pola wypełniane opcjonalnie, które dla użytkowników systemu analitycznego mogą mieć duże znaczenie. Podobnie ma się rzecz z dopasowywaniem danych, czy to spowodowanym używaniem różnych standardów zapisu w oddziałach (na przykład planów kont księgowych), czy to potrzebą uzupełnienia systemu o dodatkowe dane (demograficzne lub statystyczne). Inną przyczyną tworzenia oddzielnej bazy danych może być fakt, że dane w systemach źródłowych są odświeżane z różną częstotliwością (na przykład w jednym raz na miesiąc, a w innym raz na tydzień), tymczasem analizy muszą opierać się na zawsze spójnych danych. Przyczyn konieczności tworzenia drugiej bazy danych można wymienić więcej: potrzeba analiz danych historycznych, które często nie są przechowywane w bazach operacyjnych, czy niezbyt mile widziana potrzeba zapisu do nich dodatkowych informacji z zewnętrznych źródeł.

Podsumowując, przy wdrożeniu systemu ROLAP, niemal zawsze trzeba stworzyć drugą bazę danych, wyłącznie do celów analitycznych. Oznacza to po prostu zbudowanie hurtowni danych, choćby tematycznej. Jest to oczywiste dla tych, którzy takową posiadają lub są w trakcie jej tworzenia, ale nie dla nieświadomych nabywców samego systemu OLAP.

Mimo to, systemy ROLAP są bardzo popularne. Ich wybór jest „naturalny”, ponieważ użytkownicy posiadają już operacyjną, relacyjną bazę danych lub, co jest silniejszym powodem, posiadają hurtownię danych zrealizowaną w tej technologii. Ogromną zaletą rozwiązania opartego na relacyjnej bazie danych jest niemal nieograniczona pojemność systemu. Dotyczy ona zarówno danych (poddawanych analizom), jak i metadanych - elementów wymiarów analitycznych, czy samych wymiarów. Niestety, wraz ze wzrostem wielkości, maleje wydajność takiej bazy danych. Powstało wiele sposobów na ominięcie tej wady, począwszy od wspominanych już, opartych na denormalizacji, struktur gwiazdy i płatka śniegu (które dodatkowo dobrze odwzorowują struktury wielowymiarowe), aż po używanie skomplikowanych narzędzi, które jednak wymagają dużego wysiłku związanego z ich wdrożeniem i bardzo często efekty ich użycia nie są satysfakcjonujące. Kolejny problem z wydajnością pobierania danych w systemach relacyjnych polega na niedostatkach SQL, który nie posiada możliwości przeprowadzania wielowymiarowych obliczeń w pojedynczym zapytaniu. Konieczne jest używanie złożonych, wielokrotnie powtarzanych zapytań. Producenci narzędzi próbują w różny sposób omijać ten problem. Najprostszym jest stosowanie tablic agregacji, przechowujących przeliczone uprzednio podsumowania. Sposób ten powoduje jednak rozrost bazy i nie sprawdza się przy często zmieniających się danych. Podobnie - przy częstym uaktualnianiu danych nie sprawdza się przechowywanie raz pozyskanych informacji w pamięci operacyjnej serwera lub stacji klienckiej, choć bardzo zwiększa wydajność systemu.

MOLAP

Dla przeciwwagi, o wiele wydajniejsze, lecz znacznie mniej pojemne są wielowymiarowe bazy danych (ang. Multidimensional, stąd litera „M” na początku terminu MOLAP). Zastosowanie w nich zoptymalizowanych struktur, dopasowanych do wielowymiarowych obliczeń powoduje, że ich prymat pod względem szybkości przetwarzania analitycznego jest nie do podważenia tak, jak przewaga baz relacyjnych pod względem potencjalnej ilości analizowanych danych. Ze względu na zastosowanie odmiennej technologii, systemy MOLAP zawsze wymagają drugiej bazy danych (wielowymiarowej właśnie). Wbrew obiegowej opinii, coraz częściej zapewniają wielodostęp oraz bardzo dobry system zabezpieczeń i kontroli dostępu. Stosowanie serwerów OLAP, jak nazywa się wielowymiarowe bazy danych, jest coraz popularniejsze, tak ze względu na ich wydajność, jak i na łatwość budowy modeli (często jest to wykonalne dla końcowego użytkownika) oraz prostej administracji. Ponadto bazy takie niemal nie wymagają dostrajania. Jednak i tutaj w ciągu kilku lat zdołały się już wykształcić dwie podklasy narzędzi: przechowujące podczas pracy dane na dysku (ang. Disk based MDB) oraz w pamięci operacyjnej (ang. RAM based MDB lub RAM Cubes). Są one na tyle różne, że należy je rozpatrywać osobno.

Dyskowe bazy wielowymiarowe zdecydowaną większość informacji przechowują w plikach o specyficznej strukturze i używają stosunkowo niewiele pamięci operacyjnej, te drugie pamięć dyskową używają jedynie do przechowywania danych pomiędzy sesjami oraz dla bezpieczeństwa. Pierwsze mają większą pojemność, drugie są znacznie szybsze. Wychodząc z założenia, że pamięć RAM jest około 150 razy szybsza od dysku, ale równocześnie około 60 razy droższa, łatwo obliczyć, że pamięć operacyjna oferuje lepszy stosunek ceny do wydajności przetwarzania. Niestety - ograniczenia sprzętowe powodują, że zakup dodatkowych kości RAM jest nieopłacalny lub często niemożliwy. Ponadto szybkość przetwarzania w bazach dyskowych może być zwiększana, ze względu na brak ograniczeń co do zajmowanej pamięci. Jedną z dostępnych metod jest stosowanie rozbudowanych metod indeksowania, znacznie usprawniających dostęp do danych, co nie jest możliwe w bazach danych operujących w silnie ograniczonej pamięci RAM. Drugim sposobem jest prekalkulacja - wsadowe przeliczanie danych. Grozi ono jednak eksplozją bazy danych, czyli nagłym wzrostem zajętości pamięci dyskowej. Pomimo że coraz częściej stosowane są zabezpieczenia, ograniczające ryzyko takiego zdarzenia, to jednak i dzisiaj jest ono realnym zagrożeniem. Prekalkulacja nie jest również wskazana w modelach dynamicznych, ze względu na to, że zajmuje dużo czasu, co dla często zmieniających się danych może znacznie spowalniać pracę systemu, a staje się nie do przyjęcia w przypadku baz danych o więcej niż pięciu wymiarach i danych bardzo rozsianych.

W przypadku dyskowych baz wielowymiarowych daje się zauważyć znana z baz relacyjnych zależność - im szybsza baza, tym więcej miejsca zajmuje na dysku. Natomiast systemy pracujące w pamięci operacyjnej swoją szybkość zawdzięczają wydajności pamięci RAM, a na dysku zajmują stosunkowo niewiele miejsca. Jest to pod tym względem rozwiązanie bardzo wygodne i co więcej, w bardzo wielu przypadkach, wystarczające, choć na pierwszy rzut oka ograniczenie w postaci określonej pamięci RAM wydaje się być poważne. Rozważmy pojemność modelu wielowymiarowego dla 500 MB RAM. Typowy system MOLAP bazujący na pamięci operacyjnej potrzebuje od 10 do 15 bajtów na liczbę (dla porównania w dyskowych: 50 - 100 bajtów, a często i więcej, ze względu na indeksowanie i prekalkulację). Daje to pojemność rzędu 45 milionów komórek. W większości zastosowań, rozsianie danych analitycznych jest znacznie większe od 99%. Wynika z tego teoretyczna pojemność rzędu 5 miliardów danych, co odpowiada dużemu modelowi finansowemu. Analogiczna baza dyskowa, w najlepszym przypadku będzie zajmowała około 2,5 GB przy znacznie gorszej wydajności. Pozostaje pytanie, czy 500MB RAM to dużo, czy mało? Wydaje się, że nie jest to zbyt wiele, poza tym rozbudowane systemy dyskowych baz wielowymiarowych, czy serwery baz relacyjnych wymagają porównywalnej lub większej ilości pamięci operacyjnej. Zatem wybór systemu powinien zależeć od innych kryteriów niż potrzebna ilość czy cena pamięci operacyjnej i dyskowej.

HOLAP

Próby połączenia technologii relacyjnej i wielowymiarowej (w obydwu wydaniach), zaowocowały literą „H”, powstały systemy hybrydowe, HOLAP. Mamy tutaj do czynienia niemal z tyloma technikami realizacji takich połączeń, ile tego typu produktów jest dostępnych na rynku. Istnieje nawet narzędzie (a raczej jest ciągle zapowiadane) łączące technologię relacyjną z wielowymiarową - dyskową, z jednoczesną możliwością przechowywania danych w strukturach wielowymiarowych w pamięci operacyjnej zarówno na serwerze jak i na stacji klienckiej.

Najpopularniejszym rozwiązaniem w systemach hybrydowych jest używanie relacyjnej bazy danych jako źródła danych i jednoczesne przechowywanie najczęściej przetwarzanych informacji w strukturach wielowymiarowych w pamięci operacyjnej (RAM Cubes) na stacjach klienckich. Jest to połączenie najwydajniejszych strategii z punktu widzenia rozmiaru i szybkości. Oczywiste jest jednak, że tego typu rozwiązanie dziedziczy i wady swoich składników - pozyskanie nowych danych jest powolne, a ilość pamięci na stacji roboczej zwykle ograniczona, co zmniejsza obszar szybkiej analizy. Zdarza się, że dodatkowo niektóre, regularnie używane, dane przechowywane są w wielowymiarowych plikach dyskowych (Disk Cubes), co może poprawiać w niektórych wypadkach szybkość pozyskiwania i przetwarzania danych, ale znakomicie komplikuje strukturę systemu oraz utrudnia jego utrzymanie i administrację.

Mimo tego, że producenci narzędzi hybrydowych stanowczo sugerują, że ich systemy łączą pojemność systemów relacyjnych z wydajnością wielowymiarowych, to nie jest to do końca prawdą. Ze względu na użycie relacyjnych baz danych jako podstawowego źródła danych pierwsza część stwierdzenia jest niepodważalna, druga - nieco przesadzona. Owszem, wydajność systemu hybrydowego jest zazwyczaj większa niż analogicznego, opartego tylko na bazie relacyjnej, ale nie może równać się z szybkością przetwarzania baz wielowymiarowych, szczególnie jeżeli spojrzymy z punktu widzenia całości przechowywanych danych, a nie tylko wycinka aktualnie analizowanego na stacji klienckiej. Biorąc pod uwagę również to, że systemy hybrydowe dziedziczą wady ROLAP - ograniczone możliwości zapisu, trudności w administracji - nie należy sądzić, że wyeliminują one narzędzia wielowymiarowe tam, gdzie nie zagroziły im relacyjne. Niewątpliwie jednak należy z uwagą podejść do nich jako niezwykle skutecznych „przyspieszaczy” systemów relacyjnych.

Na koniec wada, która ma szansę być wyeliminowana w niedalekiej przyszłości. System hybrydowy jest albo konfigurowany przez człowieka, albo konfiguruje się sam. Do niedawna „inteligencja” autokonfiguracji systemów hybrydowych, mechanizmy wyboru, w jakich strukturach powinny być przechowywane poszczególne obszary danych były niezadowalające. Jednak ostatnio pojawiające się na rynku systemy sprawiają, że można mieć nadzieję na rychłą poprawę w tym zakresie, co znacząco ułatwiłoby pracę użytkownikom.

Zakończenie

Przedstawiony podział systemów analitycznych klasy OLAP jest już podziałem klasycznym. Nie można również podważać jego zasadności, przeciwnie, wady i zalety poszczególnych sposobów przechowywania danych powinny być ważnymi kryteriami branymi pod uwagę przy doborze narzędzi tego typu. Istnieje jednak wiele innych, istotnych cech, które nie powinny być bagatelizowane. Od strony technologicznej ważne mogą być szczegóły architektury systemu, a nie tylko rodzaj źródła danych. Drugim, zupełnie innym aspektem, który nie może zostać pominięty jest satysfakcja użytkownika. Na początku stwierdziłem, że aplikacje klienckie wszystkich narzędzi OLAP są podobne. W rzeczywistości mają one podobną funkcjonalność, ale często różnią się znacznie i właśnie takie różnice mogą zadecydować, czy dany system będzie lubiany i chętnie wykorzystywany przez użytkowników. Jest to prawda często nie brana pod uwagę przez informatyków delegowanych do wyboru narzędzia. W swoim zapale skłaniającym ich do wyboru najlepszego (technologicznie) rozwiązania, bagatelizują oni użytkowników. Zbyt często okazuje się, że prawdziwe powodzenie takiego wdrożenia zależało właśnie od tego. Niestety - wówczas zwykle jest już za późno.

• Magazyny danych (data warehouse)

1. Wprowadzenie

Każdego dnia wielkie i małe firmy generują ogromne ilości danych, dotyczących wszystkich aspektów ich działalności, odnotowują miliony faktów o klientach, produktach, operacjach i pracownikach. Ale w większości przypadków dane te są zapamiętywane w pamięciach wielu różnych systemów komputerowych czyniąc dostęp do nich prawie niemożliwym. Fenomen ten bywa określany mianem „uwięzienia danych”.

Eksperci szacują, że jedynie niewielka część informacji gromadzonych, przetwarzanych i zapamiętywanych w instytucji znajduje się w zasięgu decydentów. Z chwilą, gdy rynek technologii przetwarzania i prezentacji danych niemal codziennie eksploduje nowymi rozwiązaniami, jedynie część osób odpowiedzialnych za opracowywanie strategii informatycznej przedsiębiorstwa zdaje sobie sprawę z faktu, że przeważająca część ich organizacji cierpi na niedoinformowanie.

Nowe rozwiązanie technologiczne, którego celem jest udostępnienie informacji pracownikom firmy podejmującym najważniejsze decyzje, przyjęło się określać mianem „hurtowni danych”. Hurtownia danych wyrosła z szeregu prób powtarzanych przez badaczy i organizacje w celu zapewnienia ich instytucjom elastyczności, skuteczności i nadania właściwego znaczenia szeregowi danych, reprezentującemu jedne z najcenniejszych aktywów firmy. Doświadczenia wyniesione z tych prób pozwoliły branży informatycznej zidentyfikować kluczowe problemy wymagające rozwiązania.

Hurtownie danych mają spowodować uwolnienie informacji gromadzonych w operacyjnych bazach danych w celu połączenia ich z informacjami mającymi swoje źródło w innym miejscu firmy lub poza nią. Coraz więcej przedsiębiorstw czerpie informacje również z zewnętrznych baz danych. Dotyczy to m.in. danych demograficznych, ekonometrycznych, o konkurencji, trendach dotyczących zakupów, itp. Internet umożliwia każdego dnia dostęp do coraz większej ilości informacji.

2. Definicja hurtowni danych

Twórca teorii hurtowni danych B. Immon definiuje hurtownię jako tematycznie zorientowaną, spójną, chronologiczną i niezmienną kolekcję danych. Z kolei S. Kelly, kładąc główny nacisk na problemy biznesowe, określa hurtownię jako strukturę niezależną od systemu operacyjnego, przeznaczoną dla użytkowników, którzy potrzebują nie tyle głębokiej wiedzy informatycznej, co ekonomicznej, dalej mówiąc, że struktura hurtowni powinna odpowiadać modelowi organizacji, być niezmienna i odzwierciedlać stan organizacji w czasie.

Pracownicy firmy SAS Institute, M. Kornacki i J. Szyller, charakteryzują hurtownię danych jako infrastrukturę informatyczną składającą się z systematycznie archiwizowanych, uporządkowanych tematycznie informacji (zazwyczaj pochodzących ze źródeł zewnętrznych) i opisujących je metadanych oraz zestawu aplikacji umożliwiających dalszą analitykę.

Do zrozumienia istoty pojęcia „hurtownia danych” niezbędne jest uświadomienie sobie zadań, które ma ona spełniać.

3. Funkcje hurtowni danych

Hurtownie danych ukierunkowane są zwykle na kierownictwo (tworzą najistotniejszy człon systemów wspomagania decyzji - SWD) i ich zastosowanie ma na celu odciążenie operacyjnych baz danych, przeznaczonych przede wszystkim do obsługi procesów produkcyjnych i klientów. Dzięki temu następuje więc rozdzielenie sfery informacji wykonawczych od sfery informacji decyzyjnych. Generalnym zadaniem hurtowni danych jest ujęcie w postaci ujednoliconej istotnych (krytycznych) informacji biznesowych w skali firmy oraz udostępnienie ich do potrzeb wydajnej analizy wielowymiarowej, zapytań i raportowania.

Potrzeba ujednolicenia informacji w skali firmy jest ewidentna, zważywszy, iż są one zwykle rozproszone po wielu aplikacjach, przechowywane w różnych formatach i często, mimo takich samych nazw, reprezentują inną treść.

Przyczynami pojawienia się hurtowni danych są więc niedostatki stosowanych systemów informatycznych (zła jakość danych i niewystarczający stopień zintegrowania, niewydolność obsługi w zakresie analiz informacji) oraz potrzeba posiadania globalnych informacji w skali firmy.

Hurtownia danych jawi się jako metoda scalania danych operacyjnych, rozproszonych po różnych aplikacjach i komputerach wewnątrz firmy oraz „ściąganych” (zwykle kupowanych) z otoczenia zewnętrznego (np. informacje demograficzne niezbędne w wypadku hurtowni marketingowo-klientowskiej).

Niewydolność obsługi informacyjnej w systemach aplikacyjnych polega na tym, iż przetwarzanie złożonych zapytań (raportów) powoduje znaczne spowolnienie operacji wykonywanych w trybie on-line, a więc na przykład obsługi okienkowej klientów. Dotyczy to szczególnie żądań wymagających przeglądnięcia całych baz danych, obejmujących miliardy (GB), a nawet biliony (TB) znaków.

Hurtownia danych jest więc całkowicie odrębną (ale działającą w ramach istniejącego systemu) zorientowaną tematycznie bazą danych wraz z towarzyszącymi jej aplikacjami. Powinna być regularnie zasilana danymi pochodzącymi z przeróżnych źródeł (baz transakcyjnych, systemów billingowych, zbiorów tekstowych i binarnych).

Każdą porcję danych, którą zasilamy hurtownię można porównać do fotografii wybranych informacji będących podstawą do wyciągania istotnych informacji dotyczących działalności firmy w określonym przedziale czasu. Tak też hurtownia danych powinna być przede wszystkim systemem służącym do dostarczania informacji zarządczej.

Najbardziej krytyczne i złożone funkcje hurtowni danych to integracja i transformacja danych operacyjnych w dane analityczne. Wymaga to zbierania danych z najróżniejszych źródeł oraz przekształcanie ich do analitycznego formatu danych hurtowni. Po załadowaniu danych do hurtowni są one dostępne i mogą być analizowane z użyciem arkuszy kalkulacyjnych lub innych narzędzi analitycznych.

O ile ogólne zasady scalania i przekształcania danych dla celów analitycznych pozostają stałe o tyle konkretna implementacja musi być dostosowana do konkretnych potrzeb. Wymaga to zidentyfikowania potrzebnych analiz, zdefiniowania formatów danych, zlokalizowania źródeł informacji.

4. Architektura hurtowni danych

Realizacja hurtowni danych wykracza z reguły poza możliwości realizacji w ramach jednego cyklu RAD (Rapid Application Development) i wymaga podziału projektu na kilka przyrostów, odpowiadających różnym obszarom analizy. Co więcej, rozwój hurtowni danych jest przedsięwzięciem, które raz rozpoczęte trwa tak długo, jak długo rozwijają się potrzeby informacyjne organizacji oraz ewoluuje środowisko systemów podstawowych, stanowiących źródła danych dla hurtowni.. System budowany w cyklu przyrostowym wymaga dobrze zdefiniowanej architektury, inaczej niemożliwe jest zachowanie kontroli nad jego rozwojem. Chaotyczna rozbudowa hurtowni, danych źródłowych, brak punktu odniesienia umożliwiającego zaplanowanie kolejnych przyrostów i modyfikacji sprawia, że adaptacja systemu do zmian biznesowych staje się coraz trudniejsza i coraz bardziej kosztowna. W przypadku hurtowni danych, definicja architektury obejmuje dokumentację strategii biznesowych, korporacyjny model danych, dokumentację systemów źródłowych, model systemu zasilania i model technologii wykorzystywanej do implementacji i wdrożenia systemu. Model technologii jest szczególnie istotny w wypadku zastosowań korporacyjnych, wymagających integracji rozwiązań różnych dostawców - od środowiska raportowania i analiz interakcyjnych (OLAP) poprzez bazę danych dla korporacyjnej hurtowni danych, do systemu transformacji i czyszczenia danych źródłowych. Dobrze zdefiniowana architektura znacząco upraszcza proces projektowania i budowy kolejnych przyrostów systemu. Daje też dobre podstawy do dyskutowania z użytkownikami takiego planu realizacji kolejnych przyrostów, który zapewni szybkie osiągnięcie strategicznych korzyści z budowanego rozwiązania. Definicja architektury pozwala nie tylko uzyskać lepszą jakość rozwiązania i lepsze jego dopasowanie do biznesu. W dłuższej perspektywie, zdefiniowanie architektury zwiększa wydajność całego procesu budowy hurtowni dzięki temu, że w poszczególnych iteracjach zminimalizowany jest obszar prac koncepcyjnych na korzyść implementacji funkcjonalności rozwiązania.

W ciągu kilku najbliższych lat należy oczekiwać rozwoju technologii i zastosowań hurtowni danych na niespotykaną dotychczas skalę. Oznacza to, że stratedzy, planiści i użytkownicy hurtowni danych muszą rozwijać umiejętności wyboru strategii i metod zapewniających efektywne wykorzystanie technologii.

• Metody i narzędzia

1. Język SQL i relacyjne bazy danych

Najczęściej używanymi obecnie systemami baz danych są systemy relacyjne. Stosowane wcześniej bezy nierelacyjne stwarzały wiele problemów - wymagały od programistów i administratorów szczegółowej wiedzy na temat rozmieszczenia danych i struktury samej bazy. To z kolei utrudniało rozbudowy i modyfikacje aplikacji. Można powiedzieć, że relacyjne systemy baz danych umożliwiają pracę na wyższym poziomie - wszystkie operacje na danych są wykonywane za pomocą Systemu Zarządzania Bazą Danych (SZBD, ang. database management system). Komunikacja z tym systemem odbywa się za pośrednictwem języka wysokiego poziomu. Niektóre produkty używają własnych języków, jednak za standard we wszystkich znaczących systemach uznano SQL.

Od 1986 roku SQL jest oficjalnym standardem zatwierdzonym przez Międzynarodowe Stowarzyszenie Normalizacyjne ISA i jego amerykański odpowiednik - Amerykański Narodowy Instytut Normalizacji (ANSI). Poprzedni oficjalny standard był ratyfikowany na wspólnym gruncie pomiędzy istniejącymi produktami, jednak końcowa postać zależała od twórców danego systemu. Badania i doświadczenia z językiem rozwijają go i doprowadzają do tworzenia nowych standardów, odpowiadających rozwojowi systemów zarządzania bazami danych - m. in. unowocześniony standard SQL 92.

SQL nie jest jedynym językiem wysokiego poziomu mogącym służyć do komunikacji z SZBD. Nie musi być on również koniecznie uznany za najlepszy. Jego siła wynika jednak z popularności. Stał się standardem i każdy znaczący produkt musi umieć się nim posługiwać. Jest warunkiem sukcesu. Z tego powodu, jak również z systemu, na którym opiera się nasz magazyn, wynika używanie SQL'a - w komunikacjach z bazami danych, w komunikacji z użytkownikiem. Z tych powodów zdecydowaliśmy się zamieścić skrótowy opis najważniejszych zasad SQL'a i relacyjnych baz danych.

1. Geneza języka. Jego funkcja w SZBD

Język SQL (Structured Query Language - strukturalny język zapytań) został opracowany przez firmę IBM w latach siedemdziesiątych. SQL jest standardem w systemach zarządzania bazą danych m.in. firm Oracle, INGRES, Informix, Sybase, SQLbase, Microsoft SQL Server, Paradox, Access, Approach, a także w produktach firmy IBM: DB2, SQL/DS.

Typowy system relacyjnych baz danych składa się nie tylko z systemu zarządzania bazą danych. SZBD określany jest często jako „tył bazy danych” (back end) lub jej „silnik” (engine). W odpowiedzi na instrukcje języka SQL wyszukuje on lub modyfikuje dane i odpowiada za ich przechowywanie. Systemy relacyjnych baz danych mają też zwykle wbudowane narzędzia zwane „frontem bazy danych” (front end), które ułatwiają komunikację z SZBD. Są to np. formularze, generatory raportów, języki czwartej generacji (4GL), graficzne języki zapytań, czy generatory interfejsu użytkownika. Wszystkie te narzędzia wymagają SZBD do wykonywania różnych operacji, sam SZBD odpowiada natomiast za przechowywanie, organizację i wyszukiwanie danych, a także za ich integralność i ochronę.

2. Sposoby użycia SQL'a

Sam SQL służy jedynie do komunikacji z bazą danych - zwykle nie pisze się w nim samodzielnych programów. Używamy go na trzy sposoby:

• interaktywny SQL - używany do wprowadzania albo wyszukiwania informacji w bazie danych, użytkownik wpisuje zapytanie i otrzymuje wynik (drukowany na ekran, drukarkę, itp.),

• statyczny SQL - jest to stały kod SQL napisany przed wykonaniem (i zwykle kompilacją) właściwego programu napisanego w języku wysokiego poziomu (C/C++, COBOL),

• dynamiczny SQL - jest to kod SQL'a generowany przez aplikację w czasie jej wykonywania; jest używany zamiast statycznego SQL'a gdy jego kod nie może być określony podczas pisania programu, ponieważ zależy od warunków nie znanych w tym czasie (np. od wyboru użytkownika).

1. Zasady SQL'a i relacyjnych baz danych

Relacyjne bazy danych i język SQL są oparte na kilku prostych zasadach:

• Wszystkie wartości danych są typów prostych. W przeciwieństwie do języków programowania wysokiego poziomu w SQL'u nie ma tablic, wskaźników, czy wektorów.

• Wszystkie dane w relacyjnej bazie są zapisane w dwuwymiarowej tablicy relacji. Tablica składa się z wierszy (rows) - zwanych inaczej krotkami oraz z kolumn (columns) - zwanych inaczej atrybutami. Tablica może nie zawierać żadnych wierszy, ale musi posiadać przynajmniej jeden atrybut.

• Po wprowadzeniu danych do bazy można wykonywać różne operacje - arytmetyczne, logiczne - na wartościach z różnych kolumn oraz łączyć odpowiadające sobie wiersze.

• Operacje są definiowane logicznie, a nie poprzez pozycje wiersza w tablicy. Pytając bazę o wiersze pytamy np. o takie wiersze, dla których x = 5, a nie o wiersze nr 1, 3 itd. W samej bazie zgromadzone wiersze są dowolnie uporządkowane. Kolejność ich odczytywania nie musi być taka sama jak kolejność, w jakiej zostały wprowadzone do bazy.

• Ponieważ nie można identyfikować wierszy za pomocą ich pozycji, można zdefiniować w relacji klucz główny (primary key), wskazując jedną, lub więcej kolumn. Jeżeli wybierzemy jako klucz główny np. dwie kolumny, to każdy wiersz w bazie będzie musiał mieć tę parę wartości unikalną.

1. Łączenie tablic

Dwie tablice pozostają zawsze oddzielne w bazie danych, ale możemy powiązać wartość każdego klucza obcego jednej relacji z kluczem - rodzicem drugiej tablicy. Operację wyszukiwania informacji w bazie danych nazywamy zapytaniem (query), a operację łączenia ze sobą dwóch (lub więcej) tablic, poprzez powiązania kolumn jednej tablicy z kolumnami drugiej - złączeniem (join). Złączenie klucza obcego z kluczem - rodzicem nazywane jest złączeniem naturalnym, ponieważ zostaje ono wbudowane w strukturę bazy. Łączy ono informacje, które zostały rozdzielone podczas wstawiania danych.

Grupa połączonych tablic modelująca pewną rzeczywistość nazywana jest schematem relacji (schema). Według oficjalnego standardu SQL'a opis schematu (ilość tablic, kolumn w tablicy itd.) powinien być umieszczony w specjalnej grupie tablic o nazwie Information_Schema (informacja o schemacie). W niektórych systemach tablice te określa się mianem katalogu (catalog), lecz termin ten w standardowym SQL'u ma nieco inne znaczenie. Opis schematu nazywamy metadaną (metadata) - jest to informacja o danych.

Właścicielem schematu jest „użytkownik” (w rzeczywistości jest to identyfikator uprawnień oznaczający użytkownika). Użytkownik umieszcza w schemacie obiekty (objects). Każdy obiekt posiada swoją nazwę i stały identyfikator. Obiektem może być np. tablica, ale nie tylko. Użytkownik może udostępniać swoje tablice innym osobom. Za pomocą uprawnień (privileges) pozwalamy użytkownikom wykonywać różne operacje na obiektach, a zabraniamy innych. Do ustalania uprawnień służą instrukcje GRANT i REVOKE.

2. Podstawy języka SQL

SQL jest językiem nieproceduralnym. Oznacza to, że napisany w nim program nie mówi jak wykonać zadanie (krok po kroku), lecz co chcemy uzyskać. Sposób rozwiązania pozostawia SZBD. Jest to zgodne z filozofią relacyjnych baz danych - nie musimy się interesować jak SZBD wykonuje zadania, traktujemy go jako „czarną skrzynkę”.

Przykładowe zapytanie:

SELECT *
FROM Klienci
WHERE miasto = `Praga'

oznacza: wybierz wszystkie wiersze (znak `*' w pierwszej linijce) z tablicy Klienci (klauzula FROM) dla których atrybut `miasto' ma wartość `Praga'. Najbardziej interesująca jest tu klauzula WHERE - w niej podajemy warunki, jakie musi spełnić wiersz, aby został wybrany. W wyniku otrzymamy wszystkie wiersze, które spełniają wymagane warunki. Jeśli interesuje nas tylko jeden wiersz, zwykle powinniśmy odszukać go korzystając z klucza głównego. Bez jego znajomości nigdy nie wiemy ile wierszy otrzymamy w wyniku. Ukazuje to ważną cechę języka - operuje on na dowolnie dużych zbiorach danych. Instrukcje przetwarzają cały zbiór danych (set-at-a-time) w odróżnieniu od większości języków proceduralnych, przetwarzających pojedyncze dane (item-at-a-time).

Inną cechą SQL'a jest trójwartościowa logika (3VL). W większości języków wyrażenie logiczne może być prawdziwe (TRUE) lub fałszywe (FALSE). SQL zezwala na wprowadzenie do tablicy wartości NULL (wartość nieokreślona). Znacznik ten jest wpisywany automatycznie, podczas wstawiania wiersza, w kolumnach, w których nie podano wartości (jeśli ograniczenia na to zezwalają). Gdy użyjemy wartości NULL w porównaniu, wynik nie będzie ani prawdziwy, ani fałszywy, lecz przyjmie wartość nieokreśloną (UNKNOWN). Jest to jeden z bardziej kontrowersyjnych aspektów SQL'a.

Instrukcje SQL'a są pogrupowane według funkcji. W standardzie SQL używa się najczęściej trzech grup instrukcji. Są to:

• Język definicji danych (DDL - Data Definition Language), który zawiera wszystkie instrukcje służące do definiowania schematów i należących do nich obiektów. Najważniejsze instrukcje, to: CREATE SCHEMA, CREATE TABLE, CREATE VIEW, CREATE ASSERTION, CREATE DOMAIN.

• Język manipulowania danymi (DML - Data Manipulation Language) zawierający wszystkie instrukcje służące do przechowywania, modyfikowania i wyszukiwania danych w tablicach. Najważniejsze instrukcje to: SELECT, INSERT, UPDATE, DELETE. Polecenie SELECT służy do formułowania zapytań i jest najbardziej złożoną instrukcją języka.

• Instrukcje sterowania danymi, które kontrolują uprawnienia użytkownika umożliwiające wykonywanie określonych operacji na obiektach (w standardzie 92 często uważa się je za część DDL). Najważniejsze instrukcje w tej grupie to GRANT i REVOKE.

Głównym, praktycznym znaczeniem podziału na kategorie jest to, że standard nie pozwala na mieszanie instrukcji DDL i DML w jednej transakcji. Jednak większość produktów na to pozwala.

1. Metody dostępu do baz danych z poziomu języków programowania wysokiego poziomu

1. Open Database Connectivity (ODBC)

ODBC jest obecnie najbardziej rozpowszechnionym standardem dostępu do baz danych. Standardowo mechanizm ten jest wbudowany w systemy operacyjne platformy win32 (Windows 98, NT). Ideą standardu, opartego na bibliotekach X/OPEN jest dostarczenie programiście funkcji operujących na źródle danych. Przez źródło danych rozumiemy odpowiednio skonfigurowany sterownik ODBC, umożliwiający dostęp do serwera bazy danych, dla którego ten sterownik został stworzony.

Biblioteki ODBC zawierają funkcje niskiego poziomu, dlatego często tworzy się biblioteki wyższego poziomu korzystające z ODBC (klazy MFC firmy Microsoft, czy Borland Database Enginy dawnej firmy Borland, obecnie Inprise). Programy korzystające z ODBC są niezależne od konkretnego produktu stanowiącego serwer bazy danych. Korzystają one z pośrednika, którym jest sterownik ODBC i po zmianie sterownika mogą korzystać z systemu innego producenta.

Standard ODBC jest obecnie szeroko rozpowszechniony, dlatego też dostępne są sterowniki do niemal wszystkich systemów zarządzania bazą danych.

2. Java Database Connectiviy (JDBC)

JDBC (Java DataBase Connectivity) to zbiór klas i funkcji napisanych w języku Java, przeznaczonych do korzystania z informacji zawartych w bazach danych, a konkretnie, do przetwarzania i wykonywania zapytań SQL. Jest narzędziem pozwalającym na pisanie programów bez używania żadnych dodatkowych bibliotek, gdyż znajduje się w standardowym pakiecie JDK (Java Development Kit) firmy Sun. JDBC umożliwia skierowanie zapytania do dowolnej relacyjnej bazy danych (np.: Oracle, Sybase, Informix) przy wykorzystaniu jednakowego interfejsu dla każdej z nich. Jest to bardzo wygodnym rozwiązaniem z punktu widzenia programisty, gdyż jeden program napisany przy wykorzystaniu JDBC posiada możliwość obsługi zapytań do kilku baz danych - wystarczy zmienić sterownik. To rozwiązanie pozwala na dużą „oszczędność kodu” - programista nie musi pisać oddzielnego programu dla każdego rodzaju bazy danych. Poza tym JDBC posiada ważną cechę, która jest „wizytówką” Javy - przenaszalność na różne platformy systemowe. Reasumując: JDBC pozwala programiście napisać jeden program, który będzie działał z dowolną bazą danych na dowolnej platformie.

W chwili obecnej najbardziej rozpowszechnionym interfejsem dostępu do baz danych jest ODBC. Jak na jego tle wygląda JDBC? Po pierwsze JDBC jest prostsze - programowanie przy użyciu ODBC wymaga pewnego zaawansowania, a wykonanie prostego zapytania wymaga użycia skomplikowanych funkcji; po drugie ODBC używa interfejsu języka C, przez co posiada ograniczenia dotyczące przenośności.

W naszej pracy interfejs JDBC został użyty przy tworzeniu modułów integratora oraz monitorów. Postanowiliśmy skorzystać ze sterownika typu most JDBC-ODBC (pozostałe typy to: Native API - Java, Java Network - All Java, Native Protocol - All Java; nie będziemy się jednak na nich koncentrować, gdyż nie zostały użyte w naszej pracy). Jest to jedyny sterownik dostarczany standardowo z pakietem JDK. Jest to jedyny sterownik, który umożliwia połączenie z wieloma różnymi bazami danych. ODBC, podobnie jak JDBC, definiuje tylko sposób dostępu do bazy danych - kod pozostaje niezależny od zastosowanego serwera bazy danych. Most tłumaczy wywołania JDBC na wywołania ODBC i przekazuje je do sterownika ODBC zainstalowanego w systemie. W tym momencie odpowiedzialność za komunikację z serwerem bazy danych przejmuje ODBC. Wadą tego sterownika jest dodanie kolejnej warstwy na drodze zapytania z aplikacji do bazy danych. Wprowadza to dodatkowy narzut czasowy spowodowany koniecznością przełożenia wywołań JDBC na ODBC. Do zalet tego sterownika należy zaliczyć to, że może on być zastosowany do komunikacją z serwerem bazy danych, do którego nie jest osiągalny sterownik JDBC. Jako zaletę należy również uznać cenę sterownika (sterowniki są dostarczane przez producentów systemów zarządzania bazami danych a nie przez firmę Sun - autora Javy) - jest on darmowy.

Teraz krótko opiszemy podstawowe operacje JDBC. Pierwszą czynnością, jaką programista musi wykonać, chcąc korzystać z interfejsu JDBC, jest zaimportowanie pakietu java.sql. Następnie należy załadować i zarejestrować sterownik JDBC - to druga konieczna czynność. Po trzecie trzeba nawiązać połączenie z bazą danych. Po wykonaniu tych trzech punktów programista może już tworzyć i wykonywać zapytania oraz odczytywać ich wyniki. Czwartą konieczną czynnością jest zamknięcie zapytania i połączenia z bazą danych. Jak widać, korzystanie z JDBC jest bardzo proste.

Interfejs JDBC wymaga od programisty znajomości języka SQL (Structured Query Language). Jest to tak uznany i powszechny, że nie sposób go pominąć przy omawianiu metod dostępu do baz danych z poziomu języków oprogramowania. Standard ten zawiera, oprócz opisu formatu zapytań do serwera bazy danych, polecenia dotyczące definiowania danych (DDL - Data Definition Language) i operowania na nich (DML -Data Manipulation Language). Jakkolwiek SQL został uznany przez ANSI jako standard języka dla systemów zarządzania bazami danych, to większość producentów oprogramowania dostarcza własne rozszerzenia tego języka, jak np. SQLplus firmy Oracle. JDBC służy do odpowiedniego przedstawienia serwerowi bazy danych zapytania w języku SQL. Na poziomie aplikacji klienta nie jest dokonywana żadna kontrola składni zapytania - ewentualne błędy pojawią się dopiero przy wykonywaniu zapytania przez serwer bazy danych.

JDBC jest prostym i wygodnym oraz przenaszalnym narzędziem pozwalającym na korzystanie z informacji zawartych w bazach danych. Dlatego połowa naszej pracy powstała w oparciu o właśnie ten interfejs.

3. Oracle Call Interface (OCI)

Oracle Call Interface (OCI) to zestaw bibliotek dołączonych do pakietu Oracle, służących do komunikacji ze źródłową bazą danych, wykonywania zapytań, definiowania danych, dostępu do danych. Zastosowanie OCI ułatwiło dostęp do źródłowej bazy danych Oracle a także stanowiło zaletę w postaci przenośności tego modułu na inne platformy sprzętowe i systemy operacyjne. Programista używający bibliotek OCI ma do wyboru kilka języków programowania: Ada, C, COBOL, FORTRAN, PL/I.

Ważniejsze pojęcia związane z OCI

• context area - bufor pamięci wykorzystywany przez Oracle'a do przechowywania i przetwarzania informacji związanej z wykonaniem pojedynczego wyrażenia SQL,

• cursor data area (CDA) - 64-bajtowy obszar danych w programie użytkownika skojarzony (powiązany) z context area,

• logon data area (LDA) - 64 bajtowy obszar danych w naszym programie, który Oracle wykorzystuje kiedy programista łączy się z bazą danych. LDA jest przekazywana jako parametr w kilku funkcjach OCI.

• select-list item - kolumna lub wyrażenie w zapytaniu SQL określające dane wyjściowe, np. w zapytaniu:

select ENAME, ROUND (SYSDATE) - ROUND (HIREDATE) from emp

mamy dwie select-list item ENAME i (ROUND (SYSDATE) - ROUND (HIREDATE))

Struktura programu OCI

Pisząc program używając OCI musimy pamiętać o pewnej strukturze tego programu, która pozwoli na poprawną jego pracę. Musimy wyróżnić kilka głównych punktów z jakich musi się składać nasz program:

• połączenie z jedną lub większą ilością baz danych,

• otwarcie kursorów potrzebnych dla naszego programu,

• przetwarzanie wyrażenia SQL w celu otrzymania danych wyjściowych,

• zamknięcie kursorów po zakończeniu przetwarzania,

• odłączenie się od bazy danych.

W celu połączenia się z bazą danych wywołujemy funkcję OLON (jedna baza) lub ORLON (kilka baz danych). Aby połączyć się z ORACLE musimy zdefiniować w naszym programie obszar danych zwany (logon data area - LDA). Po podłączeniu do bazy danych następnie musimy zdefiniować kursor, będący strukturą danych związanych z przetwarzanym poleceniem (cursor data area - CDA). Do otwarcia kursora służy funkcja oopen(). Następnym krokiem jest przetworzenie wyrażenia. Przed przetworzeniem wyrażenia musimy sprawdzić jego poprawność. Używamy w tym celu funkcji osql3(). Kolejnym krokiem jest powiązanie adresu zmiennych występujących w naszym programie ze specyficznym placeholder'em poprzez zastosowanie funkcji obndrv() oraz zdefiniowanie typów i danych wyjściowych (funkcja odefin()). Teraz możemy przetworzyć zapytanie - oexec() - i zebrać dane wyjściowe - ofetch(). Gdy już otrzymaliśmy wyniki przetwarzanego wyrażenia, przed odłączeniem się od bazy - funkcja ologof() - musimy zamknąć kursor (kursory) poprzez wywołanie funkcji oclose(). Strukturę programu OCI można przedstawić na schemacie:




Na przedstawionym rysunku query oznacza zapytanie (instrukcja SELECT), re-execute ponowne wykonanie polecenia, re-bind ponowne wiązanie zmiennych programowych z wyrażeniem języka SQL, natomiast execute others - wykonanie kolejnych poleceń.

1. Komunikacja sieciowa

1. Protokół TCP/IP

Ze względu na wykorzystanie protokołu TCP/IP do komunikacji między modułami systemu, postanowiliśmy zamieścić krótki opis pewnych aspektów związanych z tym protokołem. Poza ogólnym opisem, zdecydowaliśmy się zamieścić dokładniejszy opis zagadnień związanych z tworzeniem naszej pracy - warstwy aplikacji protokołu i zasady numeracji IP.

Architektura protokołów TCP/IP

Architektura protokołów TCP/IP jest trochę odmienna od modelu ISO/OSI. Mamy tutaj do czynienia z czterowarstwowym hierarchicznym modelem protokołów TCP/IP:

warstwa aplikacji

warstwa transportowa

warstwa Internet

warstwa dostępu do sieci

Dane generowane przez programy aplikacyjne są przekazywane w dół stosu jeśli mają być przesyłane poprzez sieć i w górę stosu przy odbiorze. Każda warstwa stosu dodaje do danych przekazywanych z warstwy wyższej informacje sterujące w postaci nagłówków. Nagłówek dodany w warstwie wyższej jest traktowany jako dane w warstwie niższej.

Warstwy protokołów TCP/IP używają różnych nazw do określania przekazywanych danych. Aplikacje stosujące w warstwie transportowej protokół TCP nazywają swoje dane strumieniem. Z kolei TCP nazywa swoje dane segmentem. Aplikacje wykorzystujące w warstwie transportowej protokół UDP określają swoje dane jako wiadomości, a dane protokołu UDP to pakiety. W warstwie Internet protokół IP traktuje swoje dane jako bloki zwane datagramami. W najniższej warstwie bloki danych to ramki lub pakiety w zależności od używanego protokołu.

Warstwa dostępu do sieci jest najniższą warstwą w hierarchii architektury protokołów TCP/IP. W warstwie tej do datagramów IP dodaje się nagłówki oraz zakończenie i w ten sposób otrzymuje się ramki przesyłane w sieci. Funkcje tej warstwy odpowiadają w przybliżeniu funkcjom trzech najniższych warstw modelu ISO/OSI. Do komunikacji w sieciach rozległych lub przez łącza szeregowe mogą być stosowane takie protokoły jak X.25, PPP (Point-to-Point Protocol) lub SLIP (Serial Line IP). Te dwa ostatnie protokoły zostały specjalnie opracowane do przesyłania datagramów IP poprzez szeregowe łącza dwupunktowe. Protokół SLIP zazwyczaj jest stosowany do łączenia pojedynczych komputerów poprzez łącza szeregowe. Natomiast w sieciach rozległych zalecane jest stosowanie protokołu PPP.

Warstwa Internet znajduje się powyżej warstwy dostępu do sieci. Podstawowym protokołem tej warstwy jest IP. Protokół ten jest odpowiedzialny za przesyłanie pakietów zwanych datagramami między użytkownikami sieci. Jest to protokół bezpołączeniowy, co oznacza, że datagramy są przesyłane przez sieć bez kontroli poprawności ich dostarczenia. W efekcie datagram może zostać zgubiony w sieci, przekłamany lub zniekształcony. Protokół IP jest przeznaczony do sieci o bardzo dobrej jakości i niezawodności łączy transmisyjnych. Drugim protokołem tej warstwy jest ICMP ściśle związany z IP. Służy on do przesyłania komunikatów o nieprawidłowościach w pracy sieci. Protokół pozwala na przesyłanie wiadomości sterujących między węzłami sieci. Wiadomości te dotyczą sterowania przepływem, testowania połączeń, wskazania alternatywnych połączeń i wykrywania niedostępnych użytkowników.

Warstwa transportowa zapewnia bezpośrednie połączenie między końcowymi użytkownikami (systemami) wymieniającymi informacje. Do najważniejszych protokołów tej warstwy zaliczamy TCP oraz UDP. Protokół TCP jest protokołem połączeniowym umożliwiającym wykrywanie błędów na obu końcach połączenia. Ma on możliwość ustanowienia i utrzymania połączenia wirtualnego między dwoma użytkownikami w celu przesyłania danych, sterowania przepływem, przesyłania potwierdzeń oraz kontroli i korekcji błędów. Protokół UDP jest protokołem bezpołączeniowym, nie posiadających mechanizmów sprawdzania poprawności dostarczenia danych do miejsca przeznaczenia. Segmenty TCP jak i pakiety UDP w celu ich dalszego przesłania są umieszczane wewnątrz datagramu IP.

Warstwa aplikacyjna

Warstwa aplikacji zawiera procesy wykorzystujące protokoły TCP lub UDP. Protokoły tej warstwy dostarczają użytkownikom różnych usług. Do najbardziej znanych protokołów warstwy aplikacji korzystających z TCP należą:

• TELNET dla usług terminalowych. Pozwala na rozpoczęcie sesji poprzez sieć.

• TFTP (Trivial File Transfer Protocol) dla prostych usług transferu plików. Jest to uproszczona wersja protokołu FTP.

• FTP (File Transfer Protocol) dla transferu plików. Umożliwia interakcyjne przesyłanie plików.

• SMTP (Simple Mail Transfer Protocol) dla wymiany poczty elektronicznej. Umożliwia pracę w trybie zapamiętaj i prześlij (store-and-forward) pomiędzy systemami poczty korzystającymi z serwerów pocztowych.

Natomiast do bardziej znanych protokołów warstwy aplikacji korzystających z protokołu UDP należą:

• DNS (Domain Name Service) do zamiany adresów IP na nazwy urządzeń sieciowych.

• RIP (Routing Information Protocol) do wymiany informacji związanych z aktualizacją reguły doboru tras w węzłach sieci.

• NFS (Network File System) do współdzielenia plików przez wiele komputerów dołączonych do sieci. Jest to rozproszony system plików działających według modelu klient-serwer.

Każda aplikacja korzystająca z protokołów TCP/IP jest identyfikowana za pomocą numeru portu. Z kolei protokoły transportowe są określone za pomocą numerów protokołów. Pozwala to łączyć dane generowane przez różne aplikacje z kilkoma protokołami transportowymi i z kolei te protokoły z protokołem IP. Takie podejście daje możliwość multipleksacji danych, czyli np. umożliwia równoczesną komunikację wielu aplikacji z TCP. W Internecie niektóre numery portów są zarezerwowane i wstępnie przypisane do tzw. dobrze znanych usług (mogą przyjmować numery od 0 do 255). Dobrze znane usługi to np. takie protokoły sieciowe jak FTP lub TELNET. Protokoły TCP/IP używają również abstrakcyjnego pojęcia gniazda. Gniazdo to kombinacja adresu IP i numeru portu. W związku z tym gniazdo jednoznacznie określa proces w Internecie. Gniazd to również zakończenie logicznego łącza komunikacyjnego między dwiema aplikacjami. Jeśli aplikacje realizowane są na dwóch różnych komputerach, to para odpowiadających im gniazd definiuje połączenie w protokole połączeniowym TCP.

Adresy IP

W sieciach wykorzystujących protokoły TCP/IP aktualnie są stosowane 32-bitowe adresy które jednoznacznie określają sieć oraz komputer dołączony do tej sieci. Adres IP składa się z dwóch części: części sieciowej i części identyfikującej komputer wewnątrz sieci. Adresy IP można sklasyfikować wg ich formatów. W adresie IP wzajemna relacja między liczbą bitów określających sieć i liczbą bitów określających komputer zależy od klasy adresów. Istnieje 5 klas adresów: A, B, C, D, E. Strukturę adresów w tych klasach, dla protokołu IP w wersji 4, przedstawiono na rysunku:

Bajty	1						2	3	4
Klasa A	0	sieć(7)					komputer(24)
Klasa B	10		sieć(14)					komputer(16)
Klasa C	110			sieć(21)					komputer(8)
Klasa D	1110				adres grupowy (28)
Klasa E	11110					przyszłe zastosowania (27)

Adresy klasy A posiadają pierwszy bit równy 0. Następne 7 bitów określa sieć, a pozostałe 24 bity komputer wewnątrz sieci. Zauważmy, że ta klasa adresów obejmuje tylko 127 numerów sieciowych i ponad 16 mln komputerów w jednej sieci.

Adresy klasy B rozpoczynają się od pary bitów o wartościach 10. Kolejne 14 bitów określa sieć a pozostałe 16 bitów komputer wewnątrz sieci. W klasie B istnieje ponad 16 tys. sieci, a w każdej z nich ponad 65 tys. komputerów.

Adresy klasy C identyfikowane są następującą sekwencją trzech pierwszych bitów 110. Następne 21 bitów przeznaczone jest na wskazanie sieci, a tylko 8 na określenie komputera w każdej sieci. Pozwala to obsłużyć ponad 2 mln sieci i 254 komputery.

Adresy klasy D mają na pierwszych 4 bitach sekwencję 1110, a na pozostałych adres grupowy. Odnoszą się one nie do sieci, a do grupy komputerów, które nie koniecznie muszą się znajdować w tej samej sieci fizycznej. Taki adres IP umożliwia jednoczesną komunikację z grupą komputerów.

Adresy klasy E rozpoczynają się od sekwencji 11110 i są przeznaczone do przyszłych zastosowań.

Adresy IP są zapisywane jako cztery liczby dziesiętne oddzielone kropkami, np. 132.21.123.23. Liczby te odpowiadają liczbą dwójkowym zawartym w kolejnych czterech bajtach adresu IP, a zatem są one z zakresu 0-255.

Przypisanie ustalonych wartości pierwszym bitom pierwszego bajtu adresu IP powoduje, że wartość pierwszej liczby dziesiętnej jest ściśle związana z klasą adresu, a zatem:

• wartości mniejsze od 128 - klasa A,

• wartości 128 - 191 - klasa B,

• wartości 192 - 223 - klasa C,

• wartości 224 - 229 - klasa D,

• powyżej 239 - klasa E.

Adresy IP umożliwiają utworzenie sieci logicznych w jednej dużej sieci fizycznej posiadającej jeden adres IP. Można tego dokonać korzystając z bitów części identyfikującej komputer w adresie IP oraz 32-bitowej maski podsieci. Zasada użycia maski jest następująca: jeśli bit w masce ma wartość 1, to odpowiadający mu bit w adresie IP jest bitem części sieciowej. Jeśli bit w masce jest równy 0, to bit adresu należy do części określającej komputer. Przykładowo maska 255.255.255.0 zastosowana do adresu klasy B rozszerzy część sieciową o jeden bajt. Pierwsze dwa bajty są częścią sieciową klasy B, trzeci bajt jest adresem podsieci a ostatni określa komputer w podsieci.

Obecnie podstawową niedogodnością sieci Internet jest nieustanna redukcja puli adresów IP - praktycznie nie ma już większych możliwości adresowania w klasach A i B. Rozwiązaniem może być propozycja nowego protokołu IP v6. Proponuje się aby dotychczasowe 32-bitowe adresy zastąpić 128-bitowymi. Oczywiście zakłada się, że nowe adresy obejmą aktualnie używane (32-bitowe).

1. Wykorzystanie protokołów sieciowych w językach C/C++

Jedną z możliwości korzystania z zalet protokołu TCP/IP, jeśli korzystamy z platformy Win32, jest użycie Windows Sockets 2. Biblioteki te używają metod spopularyzowanych początkowo przez Berkeley Software Distribution UNIX (BSD), które zostały później zaadoptowane na potrzeby środowiska Windows.

Podstawowym celem biliotek Windows Sockets 2 jest zapewnienie komunikacji niezależnej od używanych protokołów, wykorzystującej wszystkie możliwości sieci komputerowych, takie jak komunikacje multimedialne w czasie rzeczywistym. Windows Sockets 2 nie jest więc protokołem, lecz interfejsem, więc może korzystać z dowolnej liczby protokołów transportowych i nie wymaga, aby był stosowany na obu końcach łącza komunikacyjnego.

Należy zaznaczyć, że większość funkcji Windows Sockets ma postać zgodną z rodziną funkcji unixowych (BSD), co czyni programy przenośne na poziomie kodu.

2. Wykorzystanie protokołów sieciowych w języku Java

Realizacja połączeń sieciowych w Javie jest możliwa za pomocą pakietu „java.net”. Pakiet ten udostępnia klasy Socket i ServerSocket, które zarządzają gniazdem połączenia. Klasy te udostępniają wszystkie niezbędne funkcje umożliwiające połączenie się z nasłuchującym serwerem, jak również utworzenie połączenia nasłuchującego.

1. Narzędzia do budowy parserów

Języki możemy podzielić na naturalne (język polski, angielski itp.) oraz formalne (języki programowanie, języki poleceń systemów operacyjnych, języki zapytań bazy danych). Różni je to, że języki formalne mają ściśle określone reguły składniowe - wynika to z faktu, iż polecenia w tych językach są zwykle przetwarzane przez automaty (choć często tworzone przez ludzi). Otrzymując zdanie w języku formalny, natychmiast można określić, czy jest ono poprawnie zbudowane.

Jeżeli język formalny jest językiem programowania, jego realizacja może mieć postać translatora lub interpretera. Interpreter na podstawie programu i danych wejściowych generuje wynik. Natomiast translator na podstawie programu wygeneruje jego przekład i dopiero ten przekład przetworzy dane wejściowe na wyniki. Schemat działania translatora i interpretera przedstawiono na rysunku poniżej. Przedstawiony na nim translator nazywamy kompilatorem.




Niezależnie od tego, czy mamy do czynienia z interpreterem, czy translatorem, istnieje problem analizy składniowej, czyli problem sprawdzenia, czy tekst na wejściu jest zbudowany zgodnie z regułami danego języka. Aby podnieść efektywność analizatora składniowego i uprościć jego budowę, wyodrębnia się tzw. analizator leksykalny i analizator składniowy.

1. Analiza leksykalna - Lex

Zadaniem analizatora leksykalnego, który jest modułem podrzędnym analizatora składniowego, jest:

• rozpoznawanie identyfikatorów i stałych numerycznych,

• pomijanie komentarzy,

• wyodrębnianie łańcuchów znakowych,

• rozpoznawanie słów kluczowych.

Zadania te mógłby rozwiązać analizator składniowy, ale spowodowałoby to zbyt duży wzrost nakładów pamięciowych i czasowych.

Lex jest wyspecjalizowanym generatorem analizatorów leksykalnych. Jest on w istocie rzeczy kompilatorem problemowo zorientowanego języka, w którym opisuje się konstruowany analizator. Lex został opracowany w połowie lat 70. w firmie AT&T (USA) przez J. Leska. Z początku stworzony dla środowiska UNIX, dziś działa także w innych środowiskach - MS-DOS, Win32, OS/2.

Podstawowe pojęcia analizy leksykalnej

Zadanie analizy leksykalnej polega na rozpoznawaniu i wyodrębnianiu ciągów znaków o określonych cechach z podanego tekstu wejściowego. Czasami jest to zadanie proste, polegające na wyodrębnianiu pojedynczych znaków, czy słów, jednak zwykle zadanie analizy jest trudniejsze - podział tekstu programu na tzw. jednostki leksykalne. Zadanie to wchodzi w skład każdego kompilatora języka programowania.

Podstawowymi pojęciami analizy leksykalnej są: leksem i jednostka leksykalna. Z każdym językiem (niekoniecznie musi to być język programowania) można związać zbiór jednostek leksykalnych (identyfikator, liczba itp.). Ciągi znaków, które z punktu widzenia składni języka pełnią podobną rolę, wchodzą w skład tej samej jednostki leksykalnej. Moduł nadrzędny (analizator składniowy) otrzymuje jedynie informacje o rozpoznanej jednostce - upraszcza to jego pracę.

Przez leksem rozumie się rozumiemy wyodrębniony w tekście ciąg znaków, który odpowiada rozpoznanej jednostce leksykalnej. Na przykład, w tekście wyjściowym, mającym postać programu paskalowego:

var liczba : integer = 12;
begin
liczba := liczba + 567
end.

możemy wyróżnić następujące leksemy i jednostki leksykalne:

Jednostki leksykalne	Leksemy	Atrybuty
„var”	var	-
id	liczba	„liczba'
„:”	:	-
id	integer	„integer”
„=”	=	-
numb	12	„12”
„;”	;	-
„begin”	begin	-
id	liczba	„liczba”
asgn	:=	-
id	liczba	„liczba”
„+”	+	-
numb	567	„567”
„end”	end	-
„.”	.	-

Ponieważ w pewnym momencie translacji (interpretacji) informacja o samych jednostkach leksykalnych nie wystarcza, przypisuje się im (jednostkom leksykalnym) atrybuty. Atrybut jest zwykle leksemem, ale może też przyjmować inną postać - np. kodu binarnego liczby.

Współpraca analizatora leksykalnego z modułem nadrzędnym (zwykle analizatorem składniowym) może odbywać się w dwóch systemach, zwanych umownie poziomym i pionowym. Poniższy schemat przedstawia system poziomy:




W systemie poziomym, w pierwszej fazie pracuje tylko analizator leksykalny. Na podstawie tekstu wejściowego, generuje on reprezentację pośrednią w postaci pliku, zawierającego ciąg jednostek leksykalnych. W drugiej fazie pracy, moduł nadrzędny wykonuje swoją część pracy (np. analizę składniową) na podstawie otrzymanej reprezentacji pośredniej.

Schemat działania analizatora leksykalnego i modułu nadrzędnego w systemie pionowym przedstawia poniższy rysunek:




W takim systemie pracy analizator leksykalny i moduł nadrzędny pracują jednocześnie. Analizator leksykalny ma zwykle postać podprogramu (funkcji) i jest wywoływany na żądanie modułu nadrzędnego, któremu przekazuje informację o rozpoznanej jednostce leksykalnej. Analizator leksykalny będzie więc uaktywniony tyle razy, ile jest jednostek leksykalnych w tekście źródłowym.

Wprowadzenie do generatora Lex

Lex jest narzędziem ułatwiającym realizację analizatorów leksykalnych. Na podstawie specyfikacji analizatora tworzy on funkcję yylex zapisaną w języku C. Funkcja ta może zostać wykorzystana zarówno w systemie poziomym (w połączeniu z funkcją main w przypadku języka C), jak i pionowym (po dołączeniu modułu nadrzędnego).

Ogólny schemat specyfikacji analizatora leksykalnego w języku Lex ma następującą postać:

[definicje pomocnicze]
%%
[reguły przetwarzania]
%%
[podprogramy pomocnicze]

Zarówno definicje pomocnicze, jak i podprogramy pomocnicze są opcjonalne. Każda reguła przetwarzania składa się ze wzorca i akcji, zapisanych w postaci:

wzorzec akcja

Jeśli w tekście zostanie rozpoznany ciąg znaków opisanych przez wzorzec, wówczas zostanie wykonana akcja. Wszystkie nierozpoznane ciągi znaków (nie pasujące do żadnego wzorca) zostaną przepisane na standardowe wyjście. Najprostszy wzorzec może po prostu podać, o jaki ciąg chodzi. Najprostsza akcja ma natomiast postać średnika, oznaczającego „nic nie rób”.

Ważną cechą Lexa jest możliwość opisu skomplikowanych wzorców. Jak już wspomniano, najprostszym wzorcem jest tekst, który musi pojawić się na wejściu, aby została wykonana akcja. Ale wzorzec może zawierać zbiory znaków. Ujmuje się je w nawiasy prostokątne, więc na przykład wzorzec [abc] oznacza zbiór znaków składający się z trzech liter: `a', `b' i `c'. Jeśli więc którykolwiek z tych znaków pojawi się na wejściu zostanie dopasowany do wzorca. W sytuacjach, gdy łatwiej jest podać znaki, które nie należą do zbioru, można zastosować operator dopełnienia zbioru - `^'. Umieszcza się go zaraz po nawiasie `[` otwierającym zbiór. Można też określić zbiór podając zakres znaków o kolejnych numerach w kodzie ASCII. Wykorzystujemy w tym celu znak `-`. Tak więc do wzorca [^0-9] pasują wszystkie znaki nie będące cyframi.

Przedstawiane wzorce są wyrażeniami regularnymi. Lex udostępnia wiele operacji na tych wyrażeniach ułatwiających konstruowanie skomplikowanych wzorców. Jedną z podstawowych operacji jest konkatenacja. Jeżeli L(r₁) oznacza zbiór znaków opisanych przez wyrażenie r₁, a L(r₁) - zbiór znaków odpowiadających wyrażeniu regularnemu r₂, to konkatenację wyrażeń regularnych definiujemy jako:




Przykładowy wzorzec [0-9][0-9] oznacza więc liczbę składającą się z dwóch cyfr.

Wyrażenie regularne może zostać poddane operacji domknięcia zwrotnego oznaczanej przez znak gwiazdki. Podstawową własnością pustego ciągu znaków jest to, że εx = x = xε dla dowolonego ciągu x. Przyjmijmy następujące definicje:


,


.

Wówczas operację domknięcia można zdefiniować następująco:


.

Z definicji wynika, że jeżeli z wyrażeniem w związany jest zbiór znaków W, to w* zawiera ciąg pusty ε, zbiór W, oraz konkatenacje WW, WWW itd. Na przykład 1* oznacza zbiór {ε, 11, 111, …}. Z analizą takich ciągów wiąże się pewien problem - nie wiadomo, czy przykładowy ciąg 111 potraktować jako jeden ciąg, jako konkatenację trzech ciągów, czy może konkatenację dwóch. We wszystkich analizatorach leksykalnych ten problem rozwiązuje się tak samo - poprzez zasadę najdłuższego dopasowania. Postępując zgodnie z tą zasadą analizator stara się rozpoznać i dopasować możliwie najdłuższy ciąg wejściowy. Zatem w podanym przykładzie analizator dopasowałby ciąg 111. Ponieważ we wzorcach podobnych do przykładu, analizator każdy pusty ciąg (jest ich nieskończenie wiele) dopasowywałby do wzorca (i wykonywał odpowiednią akcję), przyjęto zasadę, że wykorzystywane są tylko te reguły, którym odpowiada niepusty ciąg wejściowy. Jeżeli natomiast okaże się, że tekst odpowiada kilku regułom (i nie można zastosować zasady najdłuższego dopasowania), wybrana zostanie reguła występująca jako pierwsza w kolejności.

Innym operatorem ułatwiającym konstrukcję wzorców jest operator opcjonalności - znak `?'. Ciąg w? oznacza ciąg w lub ciąg pusty. Możemy również używać symbolu `+', różniącego się od `*' tym, że nie zawiera ciągu pustego. Wzorzec m+ możemy więc zapisać jako m*m. Możemy również określić wprost krotność konkatenacji danego wyrażenia. Krotność tę zapisuje się po danym wyrażeniu, ujętą w nawiasy klamrowe. Specyfikacja generatora Lex zawiera jeszcze operator kropki (`.'), który odpowiada dowolnemu, widzialnemu znakowi.

Generator Lex ma wbudowany mechanizm retrakcji, dzięki czemu unika dopasowywania ciągu do wzorcu w sytuacji, w której dłuższy ciąg (rozpoczynający się od dotychczas przeczytanego) mógłby zostać dopasowany. W chwili, gdy ciąg na wejściu został kompletnie dopasowany do jakiegoś wzorca, a zasada najdłuższego dopasowania sugeruje kontynuację dopasowania do innego wzorca, Lex zapamiętuje pozycję w tekście wejściowym i wzorzec, do którego udało mu się już dopasować ciąg wejściowy, a następnie kontynuuje dopasowanie do dłuższego „wzorca” (wzorca, do którego dopasowane tekst będzie dłuższy). W przypadku, gdyby dopasowanie nie powiodło się, Lex wraca do ostatniego dopasowanego wzorca, wykonuję związaną z nim akcję i rozpoczyna analizę od miejsca, w którym zakończył się dopasowany ciąg.

Z zaawansowanych technik, które Lex udostępnia użytkownikowi, należy jeszcze wymienić możliwość uwzględniania kontekstu - zarówno prawego, jak i lewego. Pozwala to rozstrzygać sytuacje, w których ten sam ciąg znaków może być różnie potraktowany, w zależności od kontekstu, w którym występuje. Uwzględnianie lewego kontekstu zrealizowano w Lexie za pomocą możliwości korzystania ze stanów początkowych, natomiast uwzględnianie prawego kontekstu za pomocą możliwości konstruowania reguł typu w/p - reguła taka oznacza, że ciąg wejściowy można dopasować do wzorca w tylko wtedy, gdy po tym ciągu występuje ciąg pasujący do p.

1. Analiza składniowa - Yacc

Jak wspomniano wcześniej, z analizatora składniowego wyodrębnia się osobny moduł, analizator leksykalny, do zbudowania którego może nam posłużyć Lex. Analizator składniowy jest wtedy modułem nadrzędnym dla analizatora leksykalnego - wykorzystuje wyniki jego pracy. Dobrym narzędziem pomocniczym, służącym do tworzenia analizatorów składniowych, jest YACC - podobnie jak Lex opracowany w amerykańskiej firmie AT&T. YACC może współpracować z Lexem w systemie pionowym (patrz p. IV.4.1). Połączone siły obu narzędzi mogą posłużyć do tworzenia różnorakich translatorów i interpreterów - począwszy od prostego kalkulatora, zakończywszy na kompilatorach skomplikowanych języków programowania.

Język i gramatyka bezkontekstowa

Pierwszym warunkiem, jaki musi spełniać język, aby można było przetwarzać go za pomocą YACCa jest bezkontekstowość jego gramatyki. Oznacza to, że opisując gramatykę języka, specyfikujemy jedną, lub więcej grup syntaktycznych i tworzymy (opisujemy) reguły konstruowania ich z części. Dla przykładu - w języku C taką grupą jest wyrażenie. Jedną z reguł tworzących wyrażenie może być zdanie: „wyrażenie składa się ze znaku minus i innego wyrażenia”. Inną może być zdanie: „wyrażenie może być liczbą całkowitą”. Jak widać, w opisie reguł często stosuje się rekursję, jednak musi istnieć przynajmniej jedna reguła, który rekursję kończy.

Najbardziej rozpowszechnionym, formalnym systemem zapisu takich reguł (czyli zapisu gramatyki), w formie czytelnej dla człowieka jest postać BNF (Backus-Naur Form). Postać ta została opracowana przy pisaniu specyfikacji języka Algol 60. Podstawową jej cechą jest to, że każda gramatyka wyrażona w notacji BNF jest gramatyką bezkontekstową. Postać wejściową dla YACC'a stanowi gramatyka zapisana w notacji BNF w formacie czytelnym dla maszyny.

Należy zaznaczyć, że nie wszystkie gramatyki bezkontekstowe mogą być przetworzone przez YACC'a. Podzbiór gramatyk, które mogą być przetworzone nazywa się LALR(1) i jest on podzbiorem zbioru gramatyk określanego jako LR(1). Definicja gramatyki LR(1) mówi, że jest to taka gramatyka, dla której w dowolnej chwili można określić, jak przetworzyć dany fragment tekstu wejściowego, odczytując tylko jeden symbol (jednostkę leksykalną) więcej, niż wymaga tego reguła. W języku angielskim tę jednostkę leksykalną określa się jako look-ahead token. Gramatyka LALR(1) jest gramatyką LR(1) z pewnymi małymi ograniczeniami, które w praktyce zdarzają się bardzo rzadko, a pozwoliły znacznie uprościć budowę generatora YACC.

W formalnym zapisie gramatyki, każdą jednostkę syntaktyczną, lub ich grupą nazywa się symbolem. Jednostki, które składają się z grupy innych jednostek opisanych regułą gramatyczną, nazywamy symbolami nieterminalnymi. Natomiast jednostki niepodzielne nazywamy symbolami terminalnymi (są to jednostki leksykalne).

Każdy symbol nieterminalny musi być opisany przez regułę gramatyczną określającą, jak można rozłożyć go na prostsze symbole. Dla przykładu jedną z reguł opisujących instrukcję języka C mógłby być opis instrukcji „return” zapisany jako ”instrukcja może składać się ze słowa kluczowego `return', `wyrażenia' i `średnika'”. Takich reguł opisujących instrukcję języka C byłoby znacznie więcej. Symbolami terminalnymi w tej regule są: słowo kluczowe `return' i średnik (`;'). Natomiast symbol nieterminalny `wyrażenie' podlega dalszemu rozkładowi.

W zapisie gramatyki wyróżniamy jeden symbol nieterminalny, który określa całość tekstu wejściowego w opisywanym języku. Jest on nazywany symbolem początkowym (ang. start symbol). W przypadku kompilatora ten symbol opisywałby cały program.

Parser (analizator składniowy) wygenerowany przez YACC'a odczytuje sekwencję jednostek leksykalnych i grupuje te jednostki używając do tego reguł gramatycznych. Jeżeli wejście zawiera prawidłowy tekst (zapisany zgodnie z gramatyką danego języka), cała sekwencja jednostek leksykalnych zostanie zredukowana do jednego symbolu - symbolu początkowego. W przeciwnym razie parser zgłosi błąd składniowy.

Reguły formalne w zapisie dla YACC'a

Gramatyka formalna jest konstrukcją matematyczną. Aby zdefiniować język dla YACC'a, należy stworzyć plik zawierający zapis gramatyki w formacie czytelnym dla YACC'a. Należy przy tym pamiętać o kilku zasadach.

Symbol nieterminalny gramatyki formalnej jest w YACC'u reprezentowany przez identyfikator (wyraz złożony z liter, cyfr i znaku podkreślenia, w krórym pierwszy znak nie może być cyfrą). Nieterminale przyjęło się zapisywać małymi literami - np. expr, statement, declaration.

Symbole terminalne reprezentowane są również za pomocą identyfikatorów, ale dla odróżnienia od nieterminali zwykło się zapisywać je wielkimi literami - przykładami mogą być słowa: IF, RETURN, INTEGER. Symbol terminalny, który jest jednostką leksykalną opowiadającą słowu kluczowemu języka przyjęto nazywać tak, jak to słowo kluczowe, ale też zapisane wielkimi literami. Symbol terminalny error jest zarezerwowany. Symbol terminalny może być również reprezentowany przez stałą znakową, zapisywaną podobnie jak w języku C - za pomocą znaku ujętego w apostrofy. Tego oznaczenia używa się zawsze wtedy, gdy leksem jest pojedynczym znakiem.

Reguła zapisana w języku YACC'a składa się z symbolu nieterminalnego, który jest przez tę regułę opisywany, dwukropka, wyrażeń określających możliwy rozkład nieterminalu (oddzielonych symbolem `|') i średnika kończącego regułę. Na przykład:

stmt : RETURN expr ';'
;

Wartości semantyczne

Gramatyka formalna rozróżnia jednostki leksykalne tylko według ich rodzaju. Dla przykładu jeśli w regule znajdziemy określenie `stała całkowita', oznacza to, że w tym miejscy może się znaleźć dowolna liczba całkowita. A więc wyrażenia x+1 i x+15 są gramatycznie równe. Jednak przy translacji (interpretacji) tekstu wejściowego potrzebne są również informacji nie mające znaczenia z gramatycznego punktu widzenia. Jeżeli tworzymy translator tłumaczący tekst na inną postać, te wartości (np. konkretne liczby) zostaną gdzieś umieszczone w tekście wynikowym, jeżeli tworzymy interpreter - te wartości są potrzebne do obliczeń. Dlatego każdy symbol w gramatyce YACC'a niesie ze sobą dwie wartości - jednostkę leksykalną i wartość semantyczną.

Jednostka leksykalna, jak już napisano wcześniej, jest symbolem terminalnym gramatyki - i zawiera wszystkie informacje potrzebne do zadecydowania, w którym miejscu dany symbol może się pojawić i jak grupować symbole z innymi symbolami według reguł gramatycznych. Wartość semantyczna przechowuje natomiast resztę informacji związanej z symbole - wartość liczby całkowitej, konkretną nazwę identyfikatora itd.

Dla przykładu: symbol wejściowy mógłby zostać rozpoznany jako `liczba całkowita' i mieć wartość semantyczną równą 4. Inny symbol mógłby zostać rozpoznany również jako `liczba całkowita', ale mieć inną wartość semantyczną, np. 534. Jeżeli reguła gramatyczna mówi, że w danym miejscu może pojawić się `liczba całkowita', oba symbole mogłyby się tam pojawić, gdyż oba są identyczną jednostką leksykalną. Należy zaznaczyć, że grupa symboli (opisana przez regułę) również może (i zwykle powinna) mieć wartość semantyczną.

Akcje semantyczne

Aby kod wygenerowany przez YACC'a był użyteczny, musi robić on coś więcej, niż tylko stwierdzić poprawność tekstu wejściowego. W przypadku kompilatora powinien on wygenerować program wynikowy, w przypadku interpretera wykonać jakieś obliczenia itp. W zapisie gramatyki dla generatora YACC, każda reguła gramatyczna może posiadać akcję, zapisaną w języku C. Za każdym razem, gdy parser korzysta z danej reguły, wykonuje związaną z nią akcję. Typowym zadaniem akcji jest obliczenie wartości semantycznej grupy wyrażeń na podstawie wartości semantycznych jej poszczególnych wyrażeń. Dla przykładu załóżmy, że reguła opisująca wyrażenie opisuje je jako sumę dwóch wyrażeń. Gdy parser rozpozna na wejściu taką sumę, każde z wyrażeń wchodzących w jej skład ma już wartość semantyczną. Zadaniem akcji powinno więc być obliczenie wartości semantycznej dla nowo rozpoznanego wyrażenia. Regułę można by zapisać w następujący sposób:

expr : expr '+' expr { $$ = $1 + $3; }
;

Akcja (zapisana w nawiasach klamrowych) mówi, że wartość semantyczna wyrażenia ($$) powinna być sumą wartości dwóch symboli - pierwszego ($1) i trzeciego ($3). Drugim symbolem w regule jest `+' i oznaczylibyśmy go jako $2.

Wynik działania YACC'a - parser

Plikiem wejściowym dla generatora YACC jest zapis gramatyki języka. Plikiem wynikowym jest natomiast źródło parsera języka wejściowego zapisane w języku C. Ten parser wykorzystujemy we własnym programie.

Zadaniem parsera (programu wygenerowanego przez YACC'a) jest grupowanie jednostek leksykalnych zgodnie z regułami gramatyki i wykonywanie odpowiednich akcji. Jednostki leksykalne są pobierane za pomocą funkcji z analizatora leksykalnego, który musi być dołączony do wynikowego programu. YACC wywołuje analizator leksykalny (dokładnie mówiąc: funkcję yylex) za każdym razem, gdy musi odczytać nową jednostkę leksykalną. Jak wspomniano na początku opisu generatora YACC, jako analizator leksykalny świetnie nadaje się Lex. Oba analizatory współpracują wtedy w systemie pionowym.

W kodzie wygenerowanym przez YACC'a najważniejszą rolę pełni funkcja yyparse, która uruchamia właściwy parser. Kod nie zawiera funkcji main, która w języka C jest obowiązkowa. Funkcję tę należy dopisać (umieszczając gdzieś wywołanie funkcji yyparse). Do programisty należy również zadanie napisania funkcji obsługującej błędy podczas analizy tekstu wejściowego - jest to funkcja yyerror, jest ona wywoływana przez parser w przypadku stwierdzenia nieprawidłowości w tekście wejściowym (tzn. jego niezgodności z gramatyką języka).

Etapy praca z generatorem analizatora składniowego

Podsumowując, stworzenie kompilatora lub interpretera, przy założeniu, że dysponujemy gramatyką opisywanego języka, składa się w ogólności z czterech kroków:

1. Zapis gramatyki w formie rozpoznawalnej dla YACC'a, napisanie akcji dla każdej reguły językowej.

2. Napisanie analizatora leksykalnego. W tym celu można wykorzystać generator analizatorów leksykalnych - Lex.

3. Napisanie własnej części programu, w której zawrzemy wywołanie funkcji parsera - yyparse.

4. Napisanie funkcji obsługującej błędy.

Aby z otrzymanych plików źródłowych otrzymać działający program, należy wykonać trzy kroki:

1. Uruchomić YACC'a z zapisaną gramatyką, aby otrzymać parser.

2. Skompilować kod wygenerowany przez YACC'a, jak również pozostałe moduły programu.

3. Złączyć powstałe pliki aby otrzymać program wykonywalny (łączenie - linking).

• Projekt systemu magazynu danych - architektura

1. Założenia projektowanego systemu

Przystępując do pracy nad projektem, ustaliliśmy konkretne założenia dotyczące projektu, ustalające jego architekturę i opisujące jego cechy. Przyjęliśmy, że zaprojektujemy system magazynowania danych oparty na metodologii ROLAP - oznaczający relacyjny system OLAP (patrz opis ROLAPu - s. 13).

Wymaganiem, jakie stawiamy tworzonemu jest ciągłe utrzymywanie jego zawartości w stanie spójności w stosunku do źródłowych informacji. Oznacza to utrzymywanie informacji w magazynie w stanie zgodnym ze stanem źródłowych baz danych. Ta cecha odróżnia nasz system od typowych systemów OLAP, a wprowadzamy taką innowację ze względu na wymagania firm korzystających z takich systemów informacji - zwykle decyzje podejmuje się szybko i wiele zależy od szybkiego uzyskania aktualnych informacji.

Owa szybkość uzyskiwania informacji narzuca kolejną pożądaną cechę systemu - jego efektywność. Ponieważ jest to dosyć istotna sprawa, nasz system musi składować dane inkrementalnie - czyli uzupełniać zawartość magazynu jedynie o nowe informacje.

Kolejnym założeniem projektowanego systemu jest komunikacja z użytkownikiem za pomocą języka SQL. Wynika to z faktu, iż język ten jest dziś standardem w dziedzinie relacyjnych bazach danych i jego wybór jest właściwie naturalny.

W kolejnym punkcie przedstawiono architekturę systemu i wymagania, jakie stawiamy jego otoczeniu, a dalej opisano przeznaczenie wszystkich modułów systemu.

2. Architektura systemu

Architekturę projektowanego systemu można przedstawić na rysunku:




Całość systemu składa się z kilku elementów: magazynu danych, źródłowych baz danych i czterech modułów projektowanego systemu „rozpiętych” pomiędzy tymi bazami, a użytkownikiem. Zakładamy istnienie poprawnie skonstruowanych źródłowych baz danych - za ich utrzymywanie odpowiedzialny jest odbiorca systemu. Zakładamy również fizyczne istnienie bazy danych przeznaczonej na magazyn. Sam projekt składa się z czterech głównych modułów - query processora, integratora, monitora i wrappera oraz narzędzi konfiguracyjnych. Aby dokładnie omówić zadania systemu, niezbędne jest przedstawienie jego wymagań, co do struktury źródłowych baz danych.

3. Wymagania dla źródłowych baz danych

Z założeń systemu (jest to system ROLAP) wynikają wymagania, jakie muszą spełniać źródłowe bazy danych. Przyjęliśmy, że układ relacji w tych bazach ma układ płatka śniegu. Dokładne założenia tej struktury są następujące:

• W zbiorze relacji możemy wyróżnić jedną relację centralną, zwaną tabelą faktów. Gromadzi ona informacje o wartościach liczbowych pewnych operacji, np. o wartościach sprzedanych towarów, ilości itd.

• Pozostałe relacje nazywamy relacjami bocznymi - zawierają one jedynie informacje o podmiotach, na których są wykonywane operacje - np. w przypadku systemu sprzedaży o towarach, klientach, sprzedawcach itd.

• Klucz główny relacji bocznej składa się z jednego atrybutu (jest to zwykle identyfikator numeryczny, ale nie jest to wymogiem).

• Relacje mogą łączyć się ze sobą za pomocą kluczy obcych, przy czym atrybutem wskazywanym przez klucz obcy musi być klucz główny relacji bocznej.

• Układ relacji wraz z powiązaniami tworzy strukturę płatka śniegowego. Jego centrum stanowi relacja centralna, która zawiera powiązania do relacji bocznych, te zaś zawierają powiązania do kolejnych relacji bocznych itd. Wymogiem jest, aby klucz obcy tworzący powiązanie zawsze wskazywał na relację boczną tworzącą nową gałąź, a nie dołączał się do gałęzi już istniejącej. Inaczej mówiąc: każda relacja może zawierać wiele kluczy obcych, ale może być wskazywany tylko przez jeden klucz obcy.

Aby zobrazować tę strukturę, przedstawimy przykładowy schemat prawidłowo utworzonych relacji źródłowych - schemat systemu sprzedaży:




Klucze obce podkreślono na rysunku linią przerywaną, natomiast klucze główne linią ciągłą. Klucz obcy `zamówienie' relacji `sprzedaż' wskazuje na klucz główny relacji `zamówienia' (`id'), klucz obcy `towar' w relacji `sprzedaz' wskazuje na klucz główny `id' w relacji `towary', itd. Podobnie z relacjami bocznymi - klucz obcy `kategoria' relacji `towary' wskazuje na klucz główny relacji `kategorie' (`id') itd.

Relacja centralna zawiera dwa atrybuty nie będące kluczami - `ilość' i `wartość'. Każdy wpis w tabeli `sprzedaż' opisuje więc jeden fakt sprzedaży - podaje identyfikatory klienta, sprzedawcy, towaru, itd. oraz wartość sprzedaży i ilość sprzedanych towarów. Korzystając z dalszych relacji bocznych możemy również na podstawie tego faktu określić do jakiej kategorii należy sprzedany towar, do jakiego województwa trafił itd.

Jak widać, przykład nie wykorzystuje wszystkich możliwości układu płatka śniegu - z każdej relacji bocznej może przecież wychodzić więcej niż jedno powiązanie z kolejnymi relacjami. Jest jednak wystarczający do zilustrowania struktury ROLAPu i będzie często wykorzystywany w dalszej części pracy jako przykład.

Efektem prawidłowo działającego systemu powinno być utrzymywanie w magazynie (przez cały czas pracy systemu) zagregowanych danych zawierających wartości funkcji grupujących, których argumentem będą wybrane atrybuty relacji centralnej (w przedstawionym przykładzie byłyby to `ilość' i `wartość') pogrupowane według różnych kombinacji kluczy głównych relacji bocznych. Umożliwi to „wyciąganie” z magazynu informacji typu: „ile towarów z branży kosmetycznej trafia do różnych województw?”, „Jak rozkłada się sprzedaż dla konkretnego klienta w poszczególnych miesiącach?” itd. Są to zwykle informacje mające dla firmy znaczenie strategiczne - mówiące gdzie inwestować, dokąd lepiej sprzedawać itd. W naszym przypadku w magazynie zbieramy zagregowane wartości pięciu funkcji grupujących języka SQL. Są to:

• AVG - wartość średnia,

• SUM - suma,

• MIN - wartość minimalna,

• MAX - wartość maksymalna,

• COUNT - liczba krotek.

1. Funkcje poszczególnych modułów systemu

Jak już zaznaczono, w skład projektu wchodzą cztery moduły, współpracujące ze sobą oraz moduł do konfiguracji systemu.

Od modułu konfiguracji wymaga się przede wszystkim łatwości obsługi i przejrzystego interfejsu użytkownika. Program sam powinien zapytać o wszystkie niezbędne informacje (adresy źródłowych baz danych, schematy relacji itd.) i poprawnie skonfigurować system magazynowania. Wymagany jest interfejs graficzny.

Moduł query processora jest pośrednikiem pomiędzy użytkownikiem, a magazynem danych. Jak wcześniej zaznaczono, użytkownik komunikuje się z tym modułem w języku SQL, zadaniem query processora jest natomiast zrealizowanie jego poleceń. Ponieważ użytkownik korzysta z informacji zawartych w magazynie w trybie „tylko do odczytu”, jego polecenia są zapytaniami (queries). Oczywiście użytkownik (w firmie korzystającej z systemu użytkowników jest zwykle wielu) nie chce się zagłębiać w strukturę magazynu, więc zadaje zapytania tak, jakby pytał źródłową bazę danych. Zadaniem query processora jest natomiast odpowiednie przetworzenie i wykonanie tego zapytania. Podstawowym wymaganiem modułu jest możliwość jego wykorzystania w nowo tworzonych aplikacjach - generatorach raportów, wykresów, systemach wspomagania decyzji - zastosowań jest wiele.

Moduł integratora jest najważniejszym modułem w całym opracowywanym systemie. Jego funkcję można porównać do roli silnika w samochodzie. Zadaniem integratora jest inicjalizacja magazynu danych, początkowa integracja danych ze źródłowych baz danych oraz przyrostowa pielęgnacja zmaterializowanych danych w magazynie danych.

Moduł wrappera ma za zadanie konwertowanie danych ze źródłowych baz danych do wspólnego formatu danych używanego w naszym projekcie. Moduł ten jest umiejscowiony nad każdą źródłową bazą danych, wykonuje zapytanie otrzymane od modułu integratora i konwertuje wyniki otrzymane z tego źródła do wspólnego formatu danych specyficznych dla naszego projektu.

Moduł monitora ma za zadanie reagowanie na zachodzące w bazie źródłowej zmiany i przesyłanie wiadomości o nich do integratora. Ważne przy tym jest to, by wiadomości o zmianach przychodziły do integratora w takiej samej kolejności co zachodziły zmiany.

Podstawowym wymaganiem dotyczącym monitora i wrappera jest to, by dla każdego rodzaju źródłowej bazy danych można było przy możliwie najniższym nakładzie sił stworzyć odpowiednią wersję monitora i wrappera.

• Implementacja systemu

1. Struktura magazynu

Magazyn jest w istocie zbiorem relacji, który można podzielić na dwie części. Pierwszą część stanowi słownik systemu. W nim zgromadzone są wszystkie informacje niezbędne do prawidłowego działania całego systemu, a więc:

• informacje o strukturze źródłowych baz danych - opis wszystkich relacji, atrybutów, ograniczeń (klucze główne, klucze obce) itd.,

• informacje o położeniu źródłowych baz danych - adresy komputerów, porty komunikacyjne itd.,

• informacje o danych, które system powinien agregować.

Drugą część magazynu stanowią dane zbierane na bieżąco ze źródłowych baz. Oba podzbiory zbioru relacji magazynu są przechowywane na tym samym koncie w bazie danych (w naszym przypadku opartej na systemie firmy Oracle w wersji 8).

Aby system rozpoczął pracę, wymagane jest wcześniejsze utworzenie odpowiedniego wpisu w bazie użytkowników SZBD (konta - accout). Wymagane jest także utworzenie wszystkich relacji słownika i ich prawidłowe wypełnienie. Do wykonania tej części pracy zaleca się wykorzystanie dołączonego programu konfiguracyjnego, który zapyta o odpowiednie informacje i zrobi to za nas. Słownik (czyli konfiguracja systemu magazynowania) jest jednak zawarty całkowicie w opisanym poniżej zbiorze relacji, a więc możliwe jest jego ręczne modyfikowanie (lub nawet utworzenie). Takie podejście umożliwia rozszerzenie systemu w przyszłości o system zbierający automatycznie dane ze źródłowych relacji. Po utworzeniu słownika systemu można rozpocząć pracę - relacje części magazynowej są tworzone i wypełniane w trakcie pracy systemu na bieżąco. W następnych dwóch punktach przedstawiono szczegółowy opis struktury obu części magazynu.

1. Słownik (metadata store)

Na słownik systemu składa się szereg relacji. Niektóre z nich mają strukturę (zbiór atrybutów) zależną od struktury relacji źródłowych, jednak większość ma budowę niezależną od konkretnego zbioru relacji w źródłowych bazach danych. Poniżej przedstawiono przeznaczenie wszystkich relacji słownika, ich strukturę, przykładowe wypełnienie (przy wykorzystaniu przykładowego zbioru relacji przedstawionego przy opisie struktury źródłowych baz danych) oraz polecenie języka SQL tworzące relację (przydatne podczas modyfikacji lub ręcznego tworzenia słownika).

`relacje'

W tej tabeli zgromadzone są informacje o relacjach istniejących w źródłowych bazach danych. Należy dodać, że jeżeli istnieje relacja źródłowa, która nie jest używana przy agregowaniu danych, wpis o niej nie musi pojawić się w słowniku systemu (nie dotyczy to relacji centralnej - tabeli faktów). Zwiększy to wydajność systemu. Budowa relacji jest następująca:

nazwa atrybutu	typ atrybutu	ograniczenia
id_relacji	NUMBER(4)	primary key
nazwa_relacji	VARCHAR2(100)	not null

Opis atrybutów:

• `id_atrybutu' jest unikalnym identyfikatorem opisywanej tabeli. Jak opisano wcześniej, w relacjach źródłowych można wyróżnić relację główną (tabelę faktów). Tabela ta powinna mieć `id_relacji' równe zero. Identyfikatory pozostałych relacji w ich opisie słownikowym mogą być dowolne.

• `nazwa_relacji' zawiera nazwę relacji źródłowej.

Polecenie języka SQL tworzące relację może wyglądać następująco:

CREATE TABLE relacje
(
id_relacji NUMBER(4) primary key,
nazwa_relacji VARCHAR2(100) not null
)

Wypełnianie tabeli dla przykładowego schematu magazynu danych, przedstawionego wcześniej, mogłoby przebiegać następująco:

insert into relacje values ( 0, 'sprzedaz' )
insert into relacje values ( 1, 'wojewodztwa' )
insert into relacje values ( 2, 'miasta' )
insert into relacje values ( 3, 'klienci' )
...

`atrybuty'

Ta tabela gromadzi informacje o atrybutach wszystkich relacji wpisanych w tabeli `relacje'. Jeżeli jakaś relacja istnieje w źródłowej bazie danych, a nie posiada wpisu w tabeli `relacje', jej atrybuty nie powinny posiadać wpisów w tabeli `atrybuty'. Podobnie, jak w przypadku relacji, nie wszystkie atrybuty relacji źródłowych muszą mieć wpis w słowniku. Pociąga to jednak za sobą pewne konsekwencje:

• jeżeli atrybut jest kluczem obcy, jego pominięcie spowoduje odcięcia całej gałęzi relacji odchodzących od relacji, do której ten atrybut należy; Jeżeli jest to naszym zamierzeniem, powinniśmy pominąć odcięte relacje (i ich atrybuty) w opisie słownika,

• nie można pominąć w opisie klucza głównego relacji,

• jeżeli atrybut nie jest kluczem głównym, ani kluczem obcym, jego pominięcie spowoduje niemożliwość używania tego atrybutu w zapytaniach kierowanych do magazynu.

Budowa relacji `atrybuty' jest następująca:

nazwa atrybutu	typ atrybutu	ograniczenia
id_atrybutu	NUMBER(4)	primary key
nazwa_atrybutu	VARCHAR2(100)	not null
id_relacji	NUMBER(4)	foreign key
typ	VARCHAR2(15)	not null

Opis atrybutów:

• `id_atrybutu' jest unikalnym identyfikatorem danego atrybutu, numery identyfikatorów mogą być dowolne.

• `nazwa_atrybutu' określa nazwę atrybutu w źródłowej bazie danych; wartość tego pola musi być dokładną kopią źródłowego atrybutu, jeżeli więc nazwa ta jest atrybutem ograniczonym powinna zostać wpisana do słownika łącznie ze znakami ograniczającymi i z odpowiednią wielkością liter.

• `id_relacji' określa relację, do której należy opisywany atrybut; w rzeczywistości jest to klucz obcy, wskazujący na atrybut `id_relacji' tabeli `relacje'.

• `typ' jest ciągiem tekstowym określającym typ atrybutu (np. `NUMBER(4,5)'), informacja ta jest potrzebna podczas tworzenia relacji magazynujących dane w celu określenia dokładności pól gromadzących informacje o np. średniej z jakiejś wartości.

Polecenie języka SQL, tworzące tabelę wygląda następująco:

create table atrybuty
(
id_atrybutu NUMBER(4) primary key,
nazwa_atrybutu VARCHAR2(100) not null,
id_relacji NUMBER(4) references
relacje(id_relacji),
typ VARCHAR2(15) not null
)

Wypełnianie tabeli dla przykładowego schematu magazynu danych, przedstawionego wcześniej, mogłoby przebiegać następująco:

insert into atrybuty values( 0, 'id', 1, 'NUMBER(4)' )
insert into atrybuty values( 1, 'nazwa' , 1, 'VARCHAR2(30)')
insert into atrybuty values( 2, 'id', 2, 'NUMBER(4)' )
insert into atrybuty values( 3, 'nazwa', 2, 'VARCHAR2(20)')
insert into atrybuty values( 4, 'wojewodztwo', 2, 'NUMBER(4)' )
-- pozostałe atrybuty relacji bocznych
...
insert into atrybuty values( 28, 'zamowienie', 0, 'NUMBER(4)' )
insert into atrybuty values( 29, 'klient', 0, 'NUMBER(4)' )
insert into atrybuty values( 30, 'sprzedawca', 0, 'NUMBER(4)' )
insert into atrybuty values( 31, 'towar', 0, 'NUMBER(4)' )
insert into atrybuty values( 32, 'miesiac', 0, 'NUMBER(4)' )
insert into atrybuty values( 33, 'ilosc', 0, 'NUMBER(6)' )
insert into atrybuty values( 34, 'wartosc', 0, 'NUMBER(8,2)' )

`klucze_glowne'

Relacja `klucze_glowne' gromadzi informacje o kluczach głównych (primary keys) relacji bocznych. W słowniku nie przechowujemy informacji o kluczu głównym relacji centralnej, nawet jeśli taki istnieje. Jeżeli jakaś źródłowa relacja boczna nie jest wykorzystywana do agregowania danych (więc nie ma wpisu w słowniku), informacja o jej kluczu głównym zostaje pominięta. Struktura relacji jest prosta:

nazwa atrybutu	typ atrybutu	ograniczenia
id_atrybutu	NUMBER(4)	primary key, foreign key

Klucz główny relacji - atrybut `id_atrybutu' - jest jednocześnie kluczem obcym i wskazuje na pole `id_atrybutu' relacji `atrybuty'. Każdy wiersz relacji określa jeden klucz główny (dla jednej z relacji bocznych). Zgodnie z wcześniejszym opisem struktury źródłowych baz danych, klucz główny relacji bocznej składa się z dokładnie jednego atrybutu (zwykle identyfikatora obiektu). Aby system magazynu działał poprawnie, każdej relacji bocznej, opisanej w tabeli `relacji' (czyli takiej, dla której `id_relacji' ma wartość niezerową) musi towarzyszyć wpis o kluczu głównym w tabeli `klucze_główne'.

Polecenie języka SQL, tworzące relację `klucze_główne' wygląda następująco:

create table klucze_glowne
(
id_atrybutu NUMBER(4) primary key
references atrybuty(id_atrybutu)
)

Wypełnianie tabeli dla przykładowego schematu magazynu danych, przedstawionego wcześniej, mogłoby przebiegać następująco:

insert into klucze_glowne values ( '0' )
insert into klucze_glowne values ( '2' )
...

`klucze_obce'

Relacja `klucze_obce' gromadzi informacje o powiązaniach między relacjami źródłowymi. Zawiera opisy powiązań kluczy obcych relacji centralnej z kluczami głównymi relacji bocznych, jak również powiązań między relacjami bocznymi. Zgodnie z wymaganą strukturą relacji źródłowych (opisaną w punkcie V.3) powiązanie klucza obcego trafia zawsze na klucz główny relacji bocznej. Relacja `klucze_obce' musi więc zawierać tyle samo wierszy, co relacje `klucze_glowne' i zawierać dowiązania do wszystkich kluczy głównych opisanych w słowniku. Struktura tabeli jest następująca:

nazwa atrybutu	typ atrybutu	ograniczenia
od	NUMBER(4)	foreign key
do	NUMBER(4)	foreign key

Opis atrybutów:

• `od' - określa identyfikator atrybutu, który jest kluczem obcym (i jednocześnie początkiem dowiązania). Jest to klucz obcy wskazujący na atrybut `id_atrybutu' relacji `atrybuty'.

• `do' - określa atrybut docelowy dowiązania. Ponieważ atrybut ten musi być kluczem głównym relacji bocznej, atrybut `do' jest kluczem obcym wskazującym na atrybut `id_atrybutu' relacji `klucze_glowne'.

Polecenie języka SQL, tworzące tabelę wygląda następująco:

create table klucze_obce
(
od NUMBER(4) references atrybuty(id_atrybutu),
do NUMBER(4) references klucze_glowne(id_atrybutu)
)

Wypełnianie tabeli dla przykładowego schematu magazynu danych, przedstawionego wcześniej, mogłoby przebiegać następująco:

insert into klucze_obce values ( '4', '0' )
insert into klucze_obce values ( '8', '2' )

`wartosci_agregowane'

W relacji `wartosci_agregowane' przechowywane są identyfikatory atrybutów, które będą argumentami funkcji grupujących języka SQL (SUM, MIN, MAX, COUNT, AVG). Atrybuty te muszą się znajdować w relacji centralnej. Każdy wiersz relacji `wartosci_agregowane' wskazuje na jeden atrybuty, budowa tabeli składa się więc z jednego atrybutu:

nazwa atrybutu	typ atrybutu	ograniczenia
id_atrybutu	NUMBER(4)	primary key, foreign key

• Atrybut `id_atrybutu' jest identyfikatorem atrybutu źródłowej relacji, którego wartość chcemy agregować. Jest to klucz obcy, wskazujący na atrybut `id_atrybutu' relacji `atrybuty'.

Polecenie języka SQL, tworzące opisywaną relację wygląda następująco:

create table wartosci_agregowane
(
id_atrybutu NUMBER(4) primary key
references atrybuty(id_atrybutu)
)

Wypełnianie tabeli dla przykładowego schematu magazynu danych, przedstawionego wcześniej, mogłoby przebiegać następująco:

insert into wartosci_agregowane values ( '33' )
insert into wartosci_agregowane values ( '34' )

`agregaty'

Tabela `agregaty' przechowuje informacje o kombinacjach kluczy głównych, dla których chcemy przechowywać zagregowane wartości funkcji grupujących. Jej budowa jest zależna od informacji zawartej w źródłowych bazach danych. Tabela posiada dokładnie tyle kolumn, ile jest kluczy głównych w relacjach bocznych (i jednocześnie wierszy w relacji `klucze_glowne'). Nazwami kolumn tabeli są identyfikatory tych kluczy głównych (są to więc liczby). Tak więc strukturę tabeli `agregaty' można przedstawić następująco:

nazwa atrybutu	typ atrybutu	ograniczenia
<id_atrybutu>	NUMBER

Jeden atrybut relacji odpowiada jednemu kluczowi głównemu, według którego możemy agregować wcześniej zdefiniowane pola relacji centralnej. Każdy wiersz opisywanej relacji opisuje jedną kombinację, według której chcemy agregować. Jeżeli dany klucz główny wchodzi w skład tej kombinacji, to na odpowiednim atrybucie relacji 'agregaty' musi pojawić się wartość liczbowa (dowolna), w przeciwnym wypadku atrybut przyjmuje wartość NULL.

Dla przykładu, załóżmy, że w pokazanym wcześniej przykładowym systemie sprzedaży klucze główne relacji bocznych mają następujące identyfikatory:

wojewodztwa.id - 0
miasta.id - 2
klienci.id - 5
sprzedawcy.id - 9
branze.id - 12
kategorie.id - 14
towary.id - 17
lata.rok - 21
kwartaly.id - 22
miesiace.id - 24
zamowienia.id - 26

Polecenie języka SQL, tworzące odpowiednią relację `agregaty' wyglądałoby następująco:

create table agregaty
(
"0" NUMBER,
"2" NUMBER,
"5" NUMBER,
"9" NUMBER,
"12" NUMBER,
"14" NUMBER,
"17" NUMBER,
"21" NUMBER,
"22" NUMBER,
"24" NUMBER,
"26" NUMBER
)

Załóżmy teraz, że chcemy magazynować gotowe wartości agregatów dla dwóch przykładowych kombinacji kluczy głównych:

• `wojewodztwa.id' - `branze.id' (czyli chcemy zbierać wartości zgrupowane według branż towarów i według wojewodztwa, w którym mieszka kupujący), w takim wypadku musimy wstawić do bazy krotkę:

insert into agregaty values
( 1, null, null, null, 1, null, null, null, null, null, null )

• `lata.rok' - `klienci.id' - `kategorie.id' czyli klienci, kategorie towarów i lata sprzedaży), musimy wstawić następującą krotkę:

insert into agregaty values
( null, null, 1, null, null, 1, null, 1, null, null, null )

1. Część magazynowa

Część magazynowa jest odpowiedzielna za przechowywanie zagregowanych danych. Użytkownik ma dostęp jedynie do tej części magazynu (za pośrednictwem modułu query processora). Relacje w części magazynowej projektowanej hurtownii, podobnie jak w źródłowych bazach danych, możemy podzielić na relacje boczne i jedną relacje centralną.

Postać relacji bocznych pozostaje dokładnie taka sama, jak w źródłowych bazach danych. Relacje te powinny też zawierać te same krotki. System magazynowy powinien więc utworzyć te relacje na wzór źródłowych i w czasie pracy dbać, aby zawartość tych relacji zgadzała się z zawartością relacji źródłowych.

Atrybuty relacji centralnej

Budowa relacji centralnej jest natomiast inna. Zbiór jej atrybutów możemy podzielić na dwie części. Pierwszą stanowią identyfikatory kluczy głównych relacji bocznych. Są to takie same atrybuty, jak w relacji `agregaty' i mają takie same nazwy. Są one kluczami obcymi. Każdy z tych atrybutów wskazuje na taki klucz główny relacji bocznych, którego identyfikator jest nazwą tego atrybutu.

Drugą część zbioru atrybutów stanowią zagregowane wartości. Każdej agregowanej wartości odpowiada pięć atrybutów (suma, średnia, wartość minimalna i maksymalna oraz liczba krotek). Nazwa atrybutu składa się z dwóch części połączonych znakiem `_' - pierwszą stanowi pierwotna nazwa agregowanej wartości, a drugą określenie funkcji grupującej (dla średniej - `avg', sumy - `sum', wartości minimalnej - `min', wartości maksymalnej - `max', liczby krotek - `cnt'). Przykład - jeżeli nazwą agregowanej wartości jest wyraz `ilosc', atrybuty zawierające zagregowane wartości będą się nazywać:

ilosc_avg, ilosc_cnt, ilosc_max, ilosc_min, ilosc_sum

Jeżeli natomiast nazwą atrybutu jest "cena netto" (atrybut ograniczony), to wygenerowane nazwy atrybutów będą następujące:

"cena netto_avg", "cena netto_cnt", ...

Na atrybuty określające zagregowane wartości nakładamy dodatkowe ograniczenie - nie mogą one przyjąć wartości pustej (NULL).

Postać krotki relacji centralnej

Każda krotka w relacji centralnej określa zbiór zagregowanych wartości dla jednej kombinacji kluczy głównych. Atrybuty, będące kluczami obcymi, określają kombinację kluczy głównych, dla której wiersz opisuje zagregowane wartości. Podobnie, jak w przypadku relacji `agregaty' wartość NULL oznacza, że dany atrybuty nie wchodzi w skład kombinacji, według której agregujemy. Inna wartość oznacz natomiast, że atrybut jest częścią tej kombinacji. Wartość ta wskazuje jednocześnie na konkretny obiekt - klienta, towar, sprzedawcę itd. - podając jego identyfikator.

Atrybuty zawierające zagregowane wartości zawieraja natomias konkretne wyniki, będące sumą, średnią itd. danej wartości dla danego zestawu obiektów.

Przykład relacji centralnej

Dla przykładowego, opisanego wcześniej systemu sprzedaży, relacja centralna wyglądałaby następująco (w formie polecenia języka SQL tworzącego relację):

create table sprzedaz
(
"0" NUMBER(4) references wojewodztwa(id),
"2" NUMBER(4) references miasta(id),
"5" NUMBER(4) references klienci(id),
"9" NUMBER(4) references sprzedawcy(id),
"12" NUMBER(4) references branze(id),
"14" NUMBER(4) references kategorie(id),
"17" NUMBER(4) references towary(id),
"21" NUMBER(4) references lata(rok),
"22" NUMBER(4) references kwartaly(id),
"24" NUMBER(4) references miesiace(id),
"26" NUMBER(4) references zamowienia(id),

wartosc_max NUMBER(10,5) not null,
wartosc_min NUMBER(10,5) not null,
wartosc_sum NUMBER(10,5) not null,
wartosc_avg NUMBER(10,5) not null,
wartosc_cnt NUMBER not null,

ilosc_max NUMBER(10,5) not null,
ilosc_min NUMBER(10,5) not null,
ilosc_sum NUMBER(10,5) not null,
ilosc_avg NUMBER(10,5) not null,
ilosc_cnt NUMBER not null
)

Przy tak skonstruowanej relacji centralnej, przykładowy wiersz (w formie polecenia języka SQL, tworzącego wiersz):

insert into sprzedaz values
( 10, null, null, null, 20, null, null, null, null, null, null,
250, 112, 1500, 150, 100,
30, 5, 1000, 10, 100 )

opisuje wartości liczbowe zwiazane ze sprzedażą towarów z konkretnej branży (o identyfikatorze równym 20) do konkretnego województwa (o identyfikatorze równym 10). Łącznie wartość sprzedanych towarów wyniosła 1500, sprzedano 1000 towarów itd.

1. Program konfiguracji słownika systemu

Program ten to graficzne narzędzie służące do poprawnej konfiguracji słownika systemu. Program oparto na pojawiających się kolejno oknach dialogowych, w których wprowadza się wszystkie niezbędne do skonfigurowania informacje takie jak nazwy relacji, nazwy atrybutów, typy atrybutów czy powiązania pomiędzy relacjami. Na podstawie wszystkich wprowadzonych informacji program łączy się z bazą danych w której ma się znajdować magazyn danych, generuje tabele słownika oraz odpowiednio je wypełnia. Schemat interfejsu graficznego jest wzorowany na kreatorze tworzenia nowych relacji zawartym w systemie ORACLE. Program napisany jest w języku Java przy użyciu narzędzia programistycznego Visual Cafe 2.5 służącego do projektowania aplikacji graficznych w Java. Do połączenia się z bazą danych ORACLE i wygenerowania słownika użyto mostu JDBC - ODBC.

2. Moduł komunikacji z użytkownikiem (query processor)

1. Założenia projektowe

W projektowanym systemie, query processor (procesor zapytań) jest ogniwem pośredniczącym między magazynem danych, zawierającym zagregowane dane, a aplikacjami użytkownika. Pierwszym założeniem, jakie stawiamy modułowi query processora, jest to, aby jego interfejs można było wykorzystać we własnych aplikacjach. Dlatego zdecydowaliśmy się zaimplementować moduł w postaci biblioteki łączonej dynamicznie (DLL).

Komunikacja z użytkownikiem może odbywać się na różne sposoby. Nowoczesnym rozwiązaniem wydaje się być opracowanie graficznego sposobu generowania zapytań. Zadecydowaliśmy jednak, że zapytania kierowane do query processora mają format SQL'owego polecenia SELECT. Jest to konsekwencją zakładanej możliwości wykorzystania query processora we własnych aplikacjach. Takie podejście umożliwia tworzenie dowolnych aplikacji, które posługując się query processorem, wydobywają informację za magazynu za pomocą języka SQL.

2. Zadanie query processora

Zadania query processora można skrótowo ująć w trzech punktach:

1. Analiza i przetworzenie zapytania użytkownika na zapytanie w języku SQL, zgodne ze strukturą danych w magazynie.

5. Wykonanie zapytania i odebranie wyników.

6. Przekazanie wyników użytkownikowi.

Przetworzenie zapytania użytkownika

Zakładamy, że użytkownik systemu magazynowania danych zna strukturę źródłowych baz danych nie zna natomiast struktury wewnętrznej magazynu. Z tego powodu jego zapytania zakładają istnienie w bazie danych odpowiednich relacji (takich, jak w źródłowych bazach danych) i wyliczanie agregatów na podstawie istniejących krotek. Przykładowe zapytanie użytkownika przy założeniu podanego wcześniej, przykładowego schematu magazynu może wyglądać następująco:

SELECT id_sprzedawcy, id_towaru, sum(wartosc)
FROM sprzedaz
GROUP BY id_sprzedawcy, id_towaru
HAVING sum(wartosc) > 250

Zapytanie powinno więc podać sumaryczną wartość wszystkich zamówień na danych towar złożonych u danego sprzedawcy, przy czym w wyniku wyświetlamy tylko te zamówienia, w których ta suma jest większa od 250 zł. Te dane odczytujemy z magazynu, ale musimy odpowiednio przekonwertować zapytanie. Polecenie, jakie powinniśmy skierować do magazynu, zgodne z wcześniejszym opisem jego budowy, mogłoby wyglądać następująco:

SELECT "9", "17", -- id_sprzedawcy, id_towaru,
wartosc_sum as "sum(wartosc)"
FROM sprzedaz
WHERE wartosc_sum > 250
AND "9" is not null -- id_sprzedawcy
AND "17" is not null -- id_towaru
AND "11" is null -- id_zamowienia
AND "0" is null -- id_wojewodztwa
AND <reszta> is null -- pozostale klucze obce relacji sprzedaz

Takie zapytanie powinno zostać skierowane do magazynu, przy założeniu, że magazynujemy wartości zgrupowane według sprzedawcy i towaru. Jeśli taka kombinacja nie jest składowana, natomiast istnieje kombinacja szersza (zawierająca sprzedawcę i towar, czyli np. sprzedawca - towar - klient - rok), zapytanie się zmieni i będzie zawierało klauzulę GROUP BY. Jak łatwo się domyśleć, wykonanie tego zapytania będzie wymagało większego nakłady czasowego. Zapytanie mogłoby wyglądać następująco:

SELECT "9", "17", -- id_sprzedawcy, id_towaru,
sum(wartosc_sum) as "sum(wartosc)"
FROM sprzedaz
WHERE "9" is not null -- id_sprzedawcy
"17" is not null -- id_towaru
"5" is not null -- id_klienta
"21" is not null -- rok
<reszta> is null -- pozostale klucze obce relacji sprzedaz
GROUP BY "9", "17" -- id_sprzedawcy, id_klienta
HAVING sum(wartosc_sum) > 250

Możliwa jest także sytuacja, w której nie istnieje ani wymagana, ani szersza kombinacja kluczy, według których agregujemy. W takim wypadku query processor powinien zasygnalizować błąd.

W praktyce zapytania mogą być bardziej skomplikowane, w szczególności mogą wykorzystywać operatory i funkcje arytmetyczne, łańcuchowe, stosować złączenia (join) itd.

Wykonanie zapytania

Kolejnym zadaniem modułu jest wykonanie zbudowanego zapytania. Ponieważ zakładamy, że nasz magazyn jest oparty na systemie firmy Oracle, do komunikacji możemy użyć gotowego zestawu bibliotek dostarczonych razem z produktem - Oracle Call Interface.

Przekazanie wyników użytkownikowi

Ostatnią fazą pracy query processora (podczas wykonywania jednego zapytania) jest przekazanie otrzymanych wyników użytkownikowi. Ponieważ komunikacja z użytkownikiem, jak również z magazynem odbywa się za pomocą języka SQL, format wyników jest identyczny. Dlatego otrzymane z magazynu wyniki możemy przekazać użytkownikowi bez konwersji. W praktyce oznacza to możliwość połączenia dwóch kroków algorytmu - odebrania wyników z magazynu i przekazania ich użytkownikowi - w jeden.

1. Wymagany format zapytania

Jako format zapytań użytkownika wybraliśmy język SQL. Jest to oczywisty wybór, pokierowany popularnością języka (jest on standardem w relacyjnych bazach danych), jak również wyborem produktu firmy Oracle, jako bazy danych magazynu. Korzystamy właściwie jedynie z polecenia SELECT. Modyfikacje danych w magazynie (przez użytkownika) nie jest przecież dozwolone. Składnia polecenia jest niemal identyczna, z pewnymi ograniczeniami i zmianami opisanymi poniżej.

Ogólna skłania polecenia jest następująca:

SELECT [ DISTINCT | ALL ]
{ funkcja_agregująca.. | wyrażenie [ [AS] alias_kolumny ] }.,..
FROM
nazwa_relacji.,..
GROUP BY { [ nazwa_relacji. ] nazwa_kolumny }.,..
[HAVING predykat]
[ORDER BY wyrażenie]

Jak widać, nie jest dozwolone stosowanie podzapytań, jak również klauzul WHERE, UNION, INTERSECT, EXCEPT itd. Obowiązkowa jest natomiast klauzula GROUP BY.

Podstawowym ograniczeniem jest niemożliwość odnoszenia się do poszczególnych krotek tabel (źródłowych), ponieważ nie są one składowane w magazynie. Z magazynu pobieramy jedynie informacje o gotowych wartościach funkcji agregujących (SUM, MIN, MAX, COUNT, AVG). Na miejsce wyrażenia możemy wstawić dowolne wyrażenie języka SQL, zawierające funkcje arytmetyczne, grupujące itd. jeśli standard języka na to pozwala. Podobnie jest z predykatami. Nie możemy natomiast używać innych funkcji agregujących, niż pięć wcześniej wymienionych. W funkcjach grupujących słowa kluczowe DISTINCT i ALL są zabronione.

Klauzula SELECT nie ma większych ograniczeń. Nie można jedynie stosować znaku '*' wybierającego wszystkie kolumny relacji. Należy pamiętać, że obowiązkowa jest klauzula GROUP BY i ona nakłada pewne warunki, jakie muszą spełnić elementy listy wybieranych kolumn. Natomiast w klauzuli FROM zabronione są aliasy relacji. Tam, gdzie nazwa atrybutu wymaga podania nazwy relacji, należy ją podać w pełnym brzmieniu. Oczywiście nie można również stosować w tej klauzuli operatorów złączeniowych (JOIN). Klauzula FROM jest obowiązkowa i musi zawierać relację centralną. Nazwy relacji nie mogą się powtarzać.

Klauzula WHERE nie jest dozwolona. Jest to spowodowane faktem, że jakiekolwiek zmniejszenie liczby wybranych do grupowania krotek (poprzez odrzucenie niektórych z nich - a taki jest wynik działania omawianej klauzuli) zmieniłoby wyniki funkcji grupujących. Jest to niedozwolone, ponieważ w magazyn nie dysponuje informacją o krotkach źródłowych relacji, a jedynie gotowymi wartościami funkcji grupujących. Jedynym zastosowaniem klauzuli WHERE mogłoby być tworzenie warunków łączenia relacji. Postanowiliśmy, że użytkownik nie podaje tej informacji. Dozwolone są tylko specyficzne łączenia tablic i program je zna (na podstawie informacji zgromadzonych w słowniku), więc lepiej jest je dodać automatycznie niż sprawdzać, czy użytkownik na pewno zrobił to właściwie. Przy założeniu, że w podanym wcześniej, przykładowym schemacie relacji wykorzystujemy relacje 'sprzedaz', 'kategorie', 'towary', 'klienci', warunki odpowiedniego połączenia relacji wyglądałyby następująco:

WHERE sprzedaz.klient = klienci.id
AND sprzedaz.towar = towary.id
AND towary.kategoria = kategorie.id

Query processor zakłada takie właśnie powiązanie relacji podanych w klauzuli FROM, stąd też klauzula WHERE jest niepotrzebna. W wynikowym zapytaniu (po translacji) warunki te będą miały zupełnie inną postać.

Jak wcześniej wspomniano, klauzula GROUP  BY jest obowiązkowa. Ze względu na specyfikę magazynu - gromadzimy jedynie wartości funkcji grupujących według konkretnych atrybutów - w tej klauzuli podajemy jedynie nazwy tych atrybutów. Atrybutami, według których grupujemy, mogą być wszystkie atrybuty relacji bocznych i klucze obce relacji centralnej. Klauzula HAVING nie ma natomiast żadnych większych ograniczeń. Należy jedynie pamiętać o funkcjach agregujących - niedozwolone są operacje zmieniające wartość funkcji grupującej - czyli słowa kluczowe DISTINCT (i ALL) lub wykonywanie operacji arytmetycznych na argumencie funkcji. Klauzula ORDER BY powoduje posortowanie wyników według podanych wyrażeń, których składnia pokrywa się ze składnią języka SQL.

2. Uwagi implementacyjne

Ponieważ założyliśmy możliwość wykorzystania modułu query processora we własnych aplikacjach, program składa się z dwóch części. Pierwszą (i najważniejszą) jest biblioteka łączona dynamicznie (DLL - dynamic linked library). Udostępnia ona klasę - CWarehouseConnection - umożliwiającą nam połączenie się z bazą danych i wykonywanie zapytań. Podając zapytanie w języku SQL (patrz punkt VI.3.3) otrzymujemy gotowy wynik. Bibliotekę tę można wykorzystać we własnych programach, a jej specyfikację i sposób dołączenia opisano w punkcie VI.3.9.

Drugą część programu stanowi prosty program napisany na wzór SQL*Plus firmy Oracle. Program jest aplikacją 32-bitową środowiska Windows (Win32) działającą w trybie konsoli. Umożliwia interaktywne wykonywanie zapytań, a dzięki operacjom przekierowywania strumieni także przetwarzanie wsadowe.

Część modułów biblioteki DLL napisano w języku C, część w C++. Analizatory - leksykalny i składniowy - wygenerowały kod w języku C. Program wykorzystujący bibliotekę napisany jest w C++.

3. Moduły składowe query processora

Ten punkt zawiera opisy poszczególnych modułów składowych query processora opisanych w kolejności ich tworzenia. W praktyce pracę z nimi rozpoczęto od pewnych szkieletowych rozwiązań, a później rozwijano wszystkie moduły równocześnie.

Uwagi dotyczące parsera

Napisanie parsera polecenia SELECT języka SQL jest dosyć trudnym zadaniem, głównie ze względu na konstrukcję języka, sprawiającą czasem wrażenie „mało formalnej”. Największym utrudnieniem jest fakt, że klauzula FROM występuje dopiero po liście wyboru kolumn (select-list). Ponieważ w czasie przetwarzania listy wybieranych kolumn niezbędna jest wiedza o relacjach, z których polecenie SELECT wybiera krotki, parser musi być dwuprzebiegowy. W zaimplementowanym analizatorze przetwarzanie listy kolumn odbywa się w drugim przebiegu, który jest potem kończony (ściśle mówiąc drugi przebieg analizy kończy się na słowie kluczowym FROM). Pierwszy przebieg analizuje wszystko począwszy od klauzuli FROM. Wykorzystano go także do zapamiętania nazw wybieranych kolumn - ponieważ niektóre kolumny po przetworzeniu zmienią się należy nadać im aliasy, będące ich właściwymi nazwami.

Analizator leksykalny

Pracę rozpoczęto od napisania analizatora leksykalnego w języku generatora Lex. Analizator ma za zadanie rozdzielić zapytanie użytkownika, sformułowane w postaci polecenia SELECT języka SQL, na jednostki leksykalne. Moduł zawarto w pliku `scan.l'. Jego zadaniem jest również odczytywanie łańcuchów znakowych i odpowiednia konwersja liter do tej samej wielkości (język SQL nie rozróżnia wielkości liter). Oczywiście konwersja wielkości liter nie powinna dotyczyć łańcuchów znakowych (ujętych w apostrofy) i identyfikatorów ograniczonych.

Jak napisano wcześniej, w pierwszym przebiegu parser zbiera nazwy kolumn wybieranych poleceniem SELECT. Jeżeli kolumna nie ma aliasu, to jej nazwą jest opisujący ją tekst. Na przykład w zapytaniu

SELECT zamowienie as z, avg(wartosc)+5 FROM ...

nazwą pierwszej kolumny jest „z”, natomiast nazwą drugiej „avg(wartosc)+5”. Ponieważ pola opisujące wybierane kolumny zmienią się, należy dodać im aliasy przywracające im poprzednią nazwę (o ile wcześniej nie miały aliasów). Zbieranie tych nazw jest zadaniem analizatora leksykalnego. Można zastanawiać się nad słusznością takiego podejścia - analizator leksykalny nie zna przecież gramatyki języka i trudno jest mu zorientować się, gdzie dana nazwa się zaczyna a gdzie kończy. Konieczne jest zatem wyposażenie go w pewien zakres wiedzy umożliwiającej wykonanie tego zadania. Tak też uczyniono, dzięki wykorzystaniu stanów początkowych. Niestety, wykonanie tego zadania za pomocą analizatora składniowego (YACC'a), który zna wszystkie reguły gramatyczne, okazało się niemożliwe. Wynika to z faktu, iż analizator składniowy otrzymuje jedynie informację o jednostkach leksykalnych w źródłowym zapytaniu oraz o wartościach semantycznych. Duża część znaków (np. odstępy) jest tracona, ponieważ nie jest istotna z gramatycznego punktu widzenia.

Plik z opisem analizatora leksykalnego jest przetwarzany za pomocą generatora leksykalnego Lex, czego wynikiem jest źródło (w języku C) analizatora leksykalnego - jest to plik `scan.c'. Plik ten jest włączany do projektu.

Analizator składniowy

Tekst źródłowy analizatora składniowego zawarto w pliku `gram.y' - jest to zapis gramatyki języka (polecenia SELECT SQL'a) i akcji zgodny z formatem generatora analizatorów składniowych YACC. Plik zawiera też kilka funkcji pomocniczych wykorzystywanych w akcjach. Akcje gromadzą właściwie wszystkie operacje przekształcające zapytanie, ale korzystają z funkcji zawartych w dodatkowym module (`sql.c'). Wszystkie informacje niezbędne do dalszego przetwarzania tekstu, znalezione w zapytaniu są zapamiętywane w odpowiednich tablicach. Te informacje to np. identyfikatory relacji wybranych klauzulą FROM, identyfikatory atrybutów, według których grupujemy itd. Właściwe zapytanie (przetworzone) jest tworzone poza modułem parsera - przy wykorzystaniu zgromadzonych informacji i szkieletu zapytania.

Ponieważ program przyjmuje, jako wejście zapytanie (z określonymi danymi), a efektem jego działania są gotowe wyniki (odczytane z magazynu), powinniśmy patrzeć na niego raczej jako na rodzaj interpretera, niż kompilatora. Jeśli jednak spojrzymy na jego wewnętrzną strukturę, wyraźnie można wydzielić dwie części - pierwszą, transformującą podane zapytanie do przekładu (a więc moglibyśmy nazwać ją kompilatorem) oraz drugą, wykonującą zapytanie.

Po uruchomieniu YACC'a, otrzymujemy plik `gram.c' będący kodem źródłowym wygenerowanego parsera (w języku C). Kod ten zawiera funkcję yyparse, której wywołanie uruchamia właściwy parser. Dla każdego zapytania funkcja ta jest wywoływana dwukrotnie.

Zarządzanie tablicą symboli

Moduł `symbol.c' (i odpowiadający mu zbiór nagłówkowy `symbol.h') zawiera funkcje zarządzające tablicą symboli. Tablica symboli gromadzi słowa kluczowe języka i ich wartości (jednostki leksykalne), co ułatwia napisanie analizatora leksykalnego. Moduł ten powstał w firmie MKS, Inc. i jest dołączony do przykładów pakietu MKS Lex & Yacc do własnego wykorzystania. W parserze wykorzystano podstawową funkcję modułu - znalezienie jednostki leksykalnej na podstawie leksemu. Umożliwia to zgromadzenie słów kluczowych w tablicy o korzystanie z nich. Bez wykorzystania tablicy symboli, każde słowo kluczowe musiałoby pojawić się jako wzorzec w analizatorze leksykalnym.

Moduł `sql.c'

Następnym etapem pracy było opracowanie modułu, który połączy wszystkie informacje zgromadzone przez parser ze szkieletowym zapytaniem. Główna funkcja tego moduły, parse, inicjalizuje oba analizatory, przeprowadza (z ich wykorzystaniem) dwuprzebiegową translację, a następnie łączy wyniki w jedno zapytanie, gotowe do wykonania. W module tym zdefiniowano również wszystkie struktury danych potrzebne do przechowywania gromadzonych informacji. Przeważająca większość tych struktur jest tworzona dynamicznie, ze względu na nieprzewidywalne rozmiary.

Moduł zawiera też różnorakie elementy wykorzystywane przez analizator składniowy i leksykalny. Przede wszystkim tutaj zdefiniowano wszystkie słowa kluczowe języka. Tutaj zawarta jest także funkcja zapewniająca obsługę błędów podczas analizy składniowej - yyerror.

Ważniejszym składnikiem jest duża paleta funkcji wykorzystywanych przez parser - funkcje porównujące ciągi, odszukujące nazwy relacji lub atrybutów na podstawie identyfikatorów, odszukujące relację, do jakiej należy atrybut, gdy nie podano tego jawnie. Jest tu też zawarta funkcja wyszukująca odpowiednią, agregowaną kombinację kluczy głównych, którą można wykorzystać.

Funkcja parse zawarta w module, jako parametry dostaje adresy struktur danych zawierających odczytany już z bazy słownik systemu.

Moduł `WhConn.cpp'

Moduł `WhConn.cpp' (napisany w języku C++), wraz z plikiem `WhConn.h' zawiera definicję klasy `CWarehouseConnection', która obsługuje połączenie z magazynem. Metody tej klasy umożliwiają połączenie się z bazą, rozłączenie, a także wykonanie kilku operacji zmierzających do wykonania zapytania. Operacje te, to spradzenie poprawności zapytanie, zdefiniowanie miejsca w pamięci na wyniki, pobranie tytułów kolumn i rozmiarów czytanych danych, wykonanie zapytania i odczytywanie danych po jednej krotce. Funkcje te są podobne do funkcji OCI, więc ktoś zaznajomiony z tą biblioteką nie będzie miał problemów z wykorzystaniem klasy.

Różnica między użyciem tej klasy, a klasycznym połączeniem się z bazą danych tkwi w dwóch operacjach. Pierwszą jest połączenie się z bazą. Służąca do tego metoda nie tylko połączy nas z bazą danych, ale również odczyta wszystkie relacje słownika i zgromadzi je w odpowiednich strukturach danych. Dzieje się to niejawnie, w przypadku stwierdzenia nieprawidłowości w słowniku połączenie nie powiedzie się. Drugą funkcją jest funkcja sprawdzająca poprawność zapytania. Korzystając z OCI, zapytanie przesyłamy do bazy tylko raz - właśnie w funkcji sprawdzającej poprawność zapytania (osql3). Następne operacje (wykonanie zapytanie, pobieranie wyników) już tego nie wymagają, polecenie jest pamiętane w obszarze kursora w serwerze bazy danych. W naszej klasie jest podobnie - z tą różnicą, że przed wysłaniem do bazy zapytania zostaje ono przetworzone (za pomocą wcześniej opisanych modułów - funkcja parse).

Plik `WhConn.h' zawiera interfejs klasy `CWarehouseConnection'. Powinien on zostać dołączony do aplikacji wykorzystujących tę klasę (a więc wykorzystujących moduł query processora). Opis wykorzystania tej klasy zamieszczono w p. VI.3.9).

4. Etapy działania programu

Aby zilustrować działanie query processora, prześledźmy etapy jego działania, dla przykładowego zapytanie języka SQL. Przyjmijmy, że w źródłowych bazach danych znajduje się schemat relacji przedstawiony w p. V.3. Niech zapytanie ma postać:

SELECT klienci.nazwa, kategorie.nazwa, 2+sin(avg(wartosc))
FROM sprzedaz, klienci, kategorie
GROUP BY klienci.nazwa, kategorie.nazwa
HAVING sum(ilosc) > 20

Jak widać, podano poprawne zapytanie SQL, zgodne z opisanym wcześniej formatem. Zgodnie z wymogami zapytanie nie posiada klauzuli WHERE, która w przypadku pytania źródłowej bazy danych miałaby postać:

WHERE sprzedaz.klient = klienci.id
AND sprzedaz.towar = towary.id
AND towary.kategoria = kategorie.id

Oczywiście w takim przypadku klauzula FROM musiałaby zawierać również relację `towary'.

Zgodnie z wcześniejszym opisem, parser rozpoczyna właściwe przetwarzanie tekstu wejściowego w pierwszym przebiegu od klauzuli FROM. Natomiast analizator leksykalny ma za zadanie zebranie nazw wybieranych kolumn. W tym przypadku zbierze ciągi: „klienci.nazwa” dla pierwszej kolumny, „kategorie.nazwa” dla drugiej kolumny i „2+sin(avg(wartosc))” dla trzeciej kolumny. Ponieważ żadna z kolumn nie posiada aliasu, wszystkim kolumnom zostaną przypisane aliasy zgodne z ich nazwami.

Podczas przetwarzania klauzuli FROM, parser kontroluje (na podstawie informacji ze słownika), czy podane relacje rzeczywiście istnieją i zapamiętuje je w tablicy. Parser sprawdza też, czy wśród podanych relacji jest relacja centralna - jeśli nie, zgłasza odpowiedni błąd, jeśli tak, kontynuuje pracę. Od tej chwili wszystkie atrybuty zawarte w pozostałych klauzulach muszą należeć do relacji wymienionych w klauzuli FROM. Jeśli przy jakimś atrybucie nie podano relacji, w celu jej określenia przeszukuje się relacje podane w klauzuli FROM. Jeśli przy takim przeszukiwaniu atrybutowi odpowiada więcej niż jedna relacja, zgłaszany jest błąd.

Dalszym etapem działania parsera jest przetworzenie klauzuli GROUP BY. Efektem tego przetworzenia powinien być zbiór atrybutów, będących kluczami głównymi relacji bocznych. Jeżeli podane atrybuty nie są kluczami obcymi (jak w naszym przypadku), wystarczy wyznaczyć klucz główny relacji w której się znajdują i zapamiętać go. Tak więc w podanym przykładzie zostaną zapamiętane dwa klucze: `klienci.id' oraz `kategorie.id'. Może się jednak zdarzyć, że atrybut podany w klauzuli GROUP BY będzie kluczem obcym. Wówczas odpowiadającym mu kluczem głównym jest atrybut wskazywany przez niego. Oczywiście w omawianej klauzuli nazwy relacji nie muszą poprzedzać nazw atrybutów, jeśli nazwa atrybutu określa go jednoznacznie. W naszym przypadku jednak tak nie jest.

Nieobowiązkowa klauzula HAVING zawiera warunki, jakie muszą spełniać krotki po operacji grupowania, aby zostały wybrane. Postać tej klauzuli zostaje zapamiętana w podobnej postaci. Nie może ona po prostu pozostać w zapytania, ponieważ predykat podany w niej może (ale nie musi) zostać przeniesiony do klauzuli WHERE docelowego zapytania (patrz niżej). Jedyną zmianą w predykacie jest zapamiętanie wszystkich funkcji grupujących (wraz z argumentami) i wstawienie w ich miejsce specjalnych znaczników, umożliwiających późniejsze wklejenie tych funkcji w zmienionej postaci. W tym przypadku tekst „sum(ilosc)” zastąpimy takim znacznikiem (z odpowiednim numerem), oraz zapamiętamy, że znacznikowi o danym numerze (tutaj 1) odpowiada funkcja sumy z atrybutu `ilosc' relacji `sprzedaz'. Ponieważ nie podano relacji, do której należy atrybut `ilosc', zostanie ona odnaleziona. Przetworzenie klauzuli HAVING zakończy w naszym przypadku pierwszy przebieg parsera.

W drugim przebiegu nastąpi przetworzenie listy wybieranych kolumn. Do wszystkich kolumn nie zawierających aliasów zostaną one dodane, więc lista będzie miała postać:

SELECT klienci.nazwa as "klienci.nazwa",
kategorie.nazwa as "kategorie.nazwa",
2+sin(avg(wartosc)) as "2+sin(avg(wartosc))"

Następnie zostanie dokonana podobna operacja, jak w przypadku klauzuli HAVING - wszystkie wystąpienia funkcji grupujących zostaną zapamiętanie, a w ich miejsce wstawione znaczniki. W naszym przypadku znacznikiem (oznaczonym numerem 2) zastąpimy tekst „avg(wartosc)” oraz zapamiętamy, że znacznik nr 2 oznacza wartość średnią z atrybutu `wartosc' relacji `sprzedaz'. Relację, do której należy atrybut musimy odnaleźć. Oczywiście we wnętrzu programu te informacje są pamiętane nieco inaczej - nie zapamiętujemy nazw atrybutów ani relacji, lecz ich identyfikatory zapisane w słowniku systemu.

Przetworzyliśmy całe zapytanie. Aby skonstruować zapytanie wynikowe, musimy jeszcze znać odpowiedź na jedno pytanie - z jakiej kombinacji grupującej kluczy głównych skorzystać. Możliwe są tu trzy sytuacje:

1. Najlepsza sytuacja występuje, gdy agregujemy wartości funkcji grupujących według kluczy głównych otrzymanych na podstawie klauzuli GROUP BY. Informacja, według jakich kluczy grupujemy jest oczywiście zawarta w słowniku systemu (relacja `agregaty'). W takim, najlepszym przypadku wygenerujemy następujące zapytanie:

SELECT klienci.nazwa AS "klienci.nazwa"
kategorie.nazwa AS "kategorie.nazwa"
2+sin(sprzedaz.wartosc_avg) AS "2+sin(avg(wartosc)"
FROM sprzedaz, klienci, kategorie
WHERE sprzedaz.ilosc_sum > 20
AND sprzedaz.k1 is not null
AND sprzedaz.k2 is not null
AND sprzedaz.k3 is null
AND sprzedaz.k4 is null
AND <reszta> is null
AND sprzedaz.k1 = klienci.id
AND sprzedaz.k2 = kategorie.id

Jak widać, zapytanie nie wymaga dużych nakładów czasowych ze strony serwera, ponieważ nie wymaga grupowania krotek. Postaci funkcji grupujących zmieniły się - zastąpiły je nazwy konkretnych atrybutów, zawierających zagregowane wartości. Predykat zawarty w klauzuli HAVING został przeniesiony do klauzuli WHERE, gdzie pojawiły się dodatkowy warunki. Ponieważ klucze nazwy kluczy obcych w relacji centralnej zostają zmienione, nie możemy przewidzieć jakie mają nazwy w rzeczywistości (informacja ta jest zawarta w słowniki, ich nazwami są identyfikatory atrybutów przez nie wskazywanych). Przyjmijmy, że k1 jest kluczem obcym wskazującym na atrybut 'id' relacji 'klienci, natomiast k2 kluczem obcym wskazującym również na atrybut 'id', z;e relacji 'kategorie'. Jak widać, wartości tych dwóch atrybutów muszą być określone, wartości pozostałych kluczy obcych muszą zaś buć nieokreślone (NULL). Jak widać, dodano również warunki poprawnego złączenia tabel. Ponieważ relacje centralna w magazynie zawiera klucze obce, wskazujące wszystkie klucze główne relacji bocznych, dodanie tych warunków jest proste.

7. Gorsza sytuacja wystąpi, gdy magazyn nie zbiera wartości pogrupowanych według podanych kluczy. Ale może zbierać wartości grupowane według szerszej kombinacji. Program wybierze w takim przypadku kombinację możliwie krótką. Załóżmy, że magazynujemy dane zgrupowane według kombinacji: klienci, sprzedawcy, kategorie. Załóżmy również, że klucz obcy relacji centralnej w magazynie, wskazujący na atrybut 'id' relacji 'sprzedawcy' ma nazwę 'k6'. Zapytanie wyglądałoby następująco:

SELECT klienci.nazwa AS "klienci.nazwa"
kategorie.nazwa AS "kategorie.nazwa"
2+sin(sum(sprzedaz.wartosc_sum)/sum(sprzedaz.wartosc_cnt))
AS "2+sin(avg(wartosc)"
FROM sprzedaz, klienci, kategorie
WHERE sprzedaz.k1 is not null
AND sprzedaz.k2 is not null
AND sprzedaz.k6 is not null
AND sprzedaz.k3 is null
AND sprzedaz.k4 is null
AND <reszta> is null
AND sprzedaz.k1 = klienci.id
AND sprzedaz.k2 = kategorie.id
GROUP BY klienci.nazwa, kategorie.nazwa
HAVING sum(sprzedaz.ilosc_sum) > 20

Jak widać, zapytanie jest bardziej skomplikowane i, ze względy na operacje grupowania, będzie wymagać większych nakładów czasowych i pamięciowych ze strony serwera zarządzającego magazynem. Klauzula GROUP BY pozostała na swoim miejscy, tak samo klauzula HAVING. Klauzula WHERE zawiera te same warunki co poprzedni, z wyłączeniem predykatu zabranego wcześniej klauzuli WHERE, oraz z wymogiem, aby wartość klucza 'k6' była określona. Zmieniły się natomiast określenia wartości funkcji grupujących. o ile w poprzednim przypadku sytuacja była prosta - funkcję z jej argumentem można było zastąpić nazwą odpowiedniego atrybutu, tutaj odpowiednie wartości trzeba jeszcze wyliczyć za pomocą funkcji grupujących. Jeśli więc w poprzednim przypadku zamiast „sum(sprzedaz.ilosc)” napisalibyśmy „sprzedaz.ilosc_sum”, tak w obecnym przypadku musielibyśmy napisać „sum(sprzedaz.ilosc_sum)”. Odpowiednie przekształcenia zebrano w tabelce:

Wyrażenie źródłowe	Przypadek pierwszy	Przypadek drugi
sum(atrybut)	atrybut_sum	sum(atrybut_sum)
min(atrybut)	atrybut_min	min(atrybut_min)
max(atrybut)	atrybut_max	max(atrybut_max)
count(atrybut)	atrybut_cnt	sum(atrybut_cnt)
avg(atrybut)	atrybut_avg	sum(atrybut_sum) / sum(atrybut_cnt)

Jak widać, największy kłopot sprawia w przypadku drugim wartość średnia - obliczenie jej, jako wartości średniej z agregowanych wartości (czyli też wartości średnich) dałoby niepoprawny wynik.

8. Trzecim przypadek występuje, gdy w magazynie nie zbieramy zagregowanych informacji zgrupowanych ani według podanej kombinacji atrybutów, ani według kombinacji szerszej. W takiej sytuacji pozostaje jedynie poinformować użytkownika o niemożliwości wykonania zapytania. Query processor sygnalizuje w takiej sytuacji odpowiedni błąd.

Ostatnim etapem działania programu jest oczywiście wykonanie zapytania. Nie jest to trudne zadanie, dlatego zdecydowano się pominąć jego szczegółowy opis. Warto jedynie zaznaczyć, że przebieg programu, z jakim mamy do czynienia podczas wykonywania polecenia języka SQL za pomocą OCI, przedstawiono na schemacie w punkcie IV.2.3.

1. Wykorzystane narzędzia

• Analizator leksykalny został wygenerowany za pomocą narzędzia 'flex' (wersja 2.5.2 dla win32), na podstawie zapisu reguł dla Lex'a.

• Analizator składniowy został wygenerowany za pomocą narzędzia 'bison' (wersja 1.24 dla win32), na podstawie zapisu gramatyki dla Yacc'a.

• Do kompilacji modułów zawierających kod w językach C i C++ (także wygenerowany przez analizatory: składniowy i leksykalny) posłużył 32-bitowy kompilator języka C/C++ firmy Microsoft w wersji 11.00.7022, przeznaczony dla rodziny procesorów 80x86 (zawarty w pakiecie MS Visual C++ 5.0).

• Jako środowisko programistyczne posłużył pakiet Microsoft Developer Studio.

• Program SQL*Plus firmy Oracle posłużył jako środowisko testowe poleceń i programów języka SQL.

• Wykorzystano zestaw bibliotek OCI (Oracle Call Interface) firmy Oracle zapewniających komunikację z bazą danych (w wersji 8).

1. Przenośność kodu

W modułach składających się na bibliotekę, zawierającą query processor starano się nie używać żadnych elementów, które nie byłyby przenośne na inne platformy sprzętowe. Przenośność poszczególnych elementów query processora wygląda następująco:

• moduły składowe napisane w językach C (sql.c, symbol.c, scan.c, gram.c) oraz C++ (WhConn.cpp) są przenośne na poziomie kodu na platformy, na które istnieją kompilatory języków C i C++,

• Jeżeli istnieje potrzeba ponownego przetworzenia (kompilacji) modułów analizatora leksykalnego (scan.l) lub analizatora składniowego (gram.y), wymagane jest istnienie na przenoszonej platformie narzędzi kompatybilnych ze standardem Lex i Yacc; inną metodą może być przetworzenie tych plików do modułów w języku C na platformie, dla której te narzędzia stworzono,

• wymogiem przenośności całego modułu query processora jest istnienie na docelowej platformie zestawu bibliotek OCI (Oracle Call Interface) rozprowadzanych z pakietem Oracle; biblioteki te należy połączyć ze skompilowanymi modułami.

1. Wykorzystanie modułu we własnych aplikacjach. Składowe publiczne klasy CWarehouseConnection

Biblioteka zawierająca moduł query processora może być wykorzystana w nowo tworzonych aplikacjach. Należy przy tym pamiętać o kilku rzeczach:

• do modułów wykorzystujących query processor należy dołączyć plik nagłówkowy `WhConn.h' zawierający definicję klasy CWarehouseConnection,

• w tych modułach można korzystać z query processora poprzez wywołanie metod klasy CWarehouseConnection opisanych poniżej,

• program powinien być rozprowadzany wraz z biblioteką Warehouse.dll,

• niezbędne pliki .dll, .h, i .lib są załącznikiem do niniejszej pracy.

Aby wykorzystać moduł we własnych programach, niezbędna jest znajomość klasy CWarehouseConnection. Poniżej opisano jej publiczne metody:

• CWarehouseConnection() - bezparametrowy konstruktor klasy, zwykle wywoływany automatycznie,

• ~CWarehouseConnection() - destruktor klasy, zwalnia zajmowaną pamięć, zwykle wywoływany automatycznie,

• int GetLastError() - bezparametrowa funkcja przyjmująca wartość kodu błędu ostatniej operacji zakończonej niepowodzeniem, kod ten jest zwykle kodem funkcji OCI, której wykonanie się nie powiodło,

• char * GetLastErrorText() - funkcja, której wartością jest łańcuch tekstowy, zawierający komunikat błędu ostatnie operacji zakończonej niepowodzeniem,

• int Connect(char *username, char *password) - funkcja tworząca połączenie z bazą danych, wymaga podania nazwy użytkownika i jego hasła jako parametrów,

• int Disconnect() - funkcja powoduje odłączenie od bazy danych,

• int CParse(char *statement, char *debug = NULL) - funkcja wysyła zapytanie (przekonwertowane) do bazy danych, która sprawdza jego poprawność i zapamiętuje je,

• odsc - funkcja ma takie same parametry i wartość zwrotną, jak identyczna funkcja OCI, pominięto więc dokładny opcji; funkcja opisuje listę wybranych kolumn - nazwy kolumn, typy zwracanych danych i ich rozmiary,

• odefin - funkcja służy do zdefiniowania w pamięci operacyjnej miejsca, do którego trafią dane pobieranych krotek; funkcja jest identyczna z funkcją OCI o tej samej nazwie,

• int Execute(void) - bezparametrowa funkcja powoduje wykonanie (w bazie danych) zapytania podanego wcześniej w funkcji osql3,

• int ofetch(void) - bezparametrowa funkcja pobierająca z serwera bazy danych pojedynczą krotkę i umieszczająca je we wcześniej zdefiniowanym miejscu w pamięci komputera (za pomocą odefin).

1. Moduł integratora

1. Zadanie integratora

Moduł integratora jest najważniejszym modułem w całym opracowywanym systemie. Jego zadaniem jest inicjalizacja magazynu danych, początkowa integracja danych ze źródłowych baz danych oraz pielęgnacja zmaterializowanych danych w magazynie danych. Zadania te samoczynnie dzielą czas pracy modułu na dwie podstawowe fazy:

1. Fazę inicjalizacji magazynu danych.

2. Fazę pielęgnacji magazynu danych.

1. Założenia implementacyjne

Aktualizowanie magazynu można zrealizować na dwa sposoby. Łatwiejszym sposobem jest odnawianie całej zawartości magazynu za każdym razem, gdy wykryto zmianę w źródłowej bazie danych. Jednak, jak zaznaczyliśmy w założeniach systemu, jest to proces nieefektywny. Długi czas takiej aktualizacji może spowodować, że dane po umieszczeniu w magazynie mogą być już nieaktualne.

Innym podejściem jest aktualizowanie magazynu w sposób przyrostowy, uwzględniając poprzednią zawartość magazynu. Jest to trudniejsze, ponieważ trzeba rozpatrywać rodzaje zmian jakie zaszły w źródłowej bazie danych - podczas uaktualniania magazynu danych w przypadku dodania krotki w źródłowej bazie danych wykonywane są inne czynności niż w przypadku usunięcia lub modyfikacji krotki w źródłowej bazie danych. Podejście takie zapewnia jednak efektywność działania systemu na założonym przez nas poziomie.

Sam proces uaktualniania magazynu może być inicjowany przez użytkownika (administratora), wykonywany automatycznie w określonych odstępach czasowych, lub uaktualniany na bieżąco. Jak już napisano w wymaganiach tworzonego systemu, zdecydowaliśmy się na ostatnie rozwiązanie - jest to konsekwencja założenia, że dane w magazynie muszą być aktualne.

2. Faza inicjalizacji magazynu danych

Fazę inicjalizacji magazynu danych można dodatkowo podzielić na kilka etapów:

1. Połączenie z magazynem danych.

2. Utworzenie odpowiednich relacji w magazynie danych.

3. Zainicjalizowanie monitorów.

4. Wypełnienie relacji bocznych.

5. Wypełnienie relacji centralnej.

1. Faza pielęgnacji magazynu danych

W fazie tej następuje ciągłe uaktualnianie magazynu danych. Moduł integratora odpytuje monitory i jeśli te zgłoszą jakieś zmiany w źródłowych bazach danych następuje ponowne przeliczenie odpowiednich wartości. Jeśli uaktualnienie nie jest możliwe na podstawie dostarczonych przez monitory danych następuje połączenie z odpowiednimi wraperami z nakazem odczytania odpowiednich informacji. Kiedy aktualizowanie danych w magazynie dobiegnie końca cykl się zamyka i następuje ponowne odpytanie monitorów.

2. Implementacja modułu integratora

W fazie inicjalizacji magazynu danych następuje połączenie z bazą danych w której znajduje się słownik. Przyjęto iż magazyn danych znajdować się będzie w bazie danych firmy ORACLE (wersja 8). Po nawiązaniu połączenia następuje zainicjalizowanie magazynu danych. Ze słownika odczytywane są nazwy relacji bocznych, nazwy i typy atrybutów każdej z tych relacji oraz następuje utworzenie relacji na podstawie odczytanych danych. Kolejnym krokiem jest utworzenie relacji centralnej. Relacja centralna w magazynie odpowiada logicznie tabeli faktów w źródłowych bazach danych, jednak posiada inną strukturę wewnętrzną. Na atrybuty relacji centralnej składają się atrybuty agregujące oraz atrybuty agregowane. Atrybuty agregujące to wszystkie klucze główne występujące w relacjach bocznych w źródłowych bazach danych. Atrybuty agregowane to odpowiednio przerobione atrybuty z tabeli faktów o których chcemy przechowywać zagregowane dane. Każdy atrybut grupujący z tabeli faktów jest zamieniany na pięć odpowiadających mu atrybutów np. atrybut ilość jest zamieniany na ilość_max, ilość_min, ilość_sum, ilość_avg, ilość_cnt. Atrybuty te odpowiadają największej oraz najmniejszej wartości atrybutu ilość, sumie wartości atrybutu ilość, średniej wartości atrybutu ilość i liczbie wystąpień atrybutu ilość dla odpowiedniej kombinacji atrybutów grupujących. Po utworzeniu wszystkich relacji zostają aktywowane monitory, które będą rejestrowały wszystkie zachodzące zmiany w źródłowych bazach danych. Następnym krokiem systemu jest wypełnienie danymi utworzonych uprzednio relacji. Najpierw wypełniane są relacje boczne, później relacja centralna. Dla każdej relacji bocznej odpytywane są wszystkie wrapery, które przesyłają zawartości danej relacji ze wszyst-kich źródłowych bazach danych. Powtarzające się krotki są redukowane. Wypełnienie relacji centalnej wymagało zastosowania opracowanego specjalnie do tego celu algo-rytmu. Dla każdej kombinacji atrybutów grupujących jest budowane specjalne zapyta-nie, które jest kierowane do wszystkich wraperów. Odczytane wartości są odbierane od wraperów pojedynczo (po jednej krotce od każdego wrapera), następnie w otrzymanym w ten sposób zestawieniu jest wyszukiwana krotka (lub kilka krotek mających taki sam „znacznik”) i z oddzielonych krotek wyliczane są wartości, które są wstawiane do magazynu. Jeśli aktualnie przetwarzaną kombinacją atrybutów grupujących jest klient, sprzedawca, towar a atrybutem agregowanym jest wartość to zapytanie wysłane do wraperów zwróci tyle krotek ile jest kombinacji wartości atrybutów klient, sprzedawca i towar (jeśli jest 10 klientów, 15 sprzedawców i 5 towarów to otrzymamy maksymalnie 10 * 15 * 5 = 750 krotek). Możliwe jest, iż z kilku źródłowych baz danych otrzymamy krotki z takimi samymi wartościami numerów klienta, sprzedawcy i towaru - czyli ta-kim samym „znacznikiem” (np. ten sam klient kupił u tego samego sprzedawcy ten sam towar, lecz raz odebrał go w jednym magazynie a drugi raz w drugim, za każdym razem dokonał zakupu na inna sumę). „Znacznikiem” są połączone wartości numerów klienta, sprzedawcy i towaru czyli atrybutów grupujących - na przykład „102010”. „Znacznik” jest traktowany jako łańcuch znaków. Odnajdowany jest zawsze jeden lub kilka jednakowych znaczników o najmniejszej wartości. Na wszystkich krotkach posiadających ten sam, aktualnie najmniejszy znacznik, dokonywane są obliczenia. Odnajdywana jest największa wartość pól wartość_max, najmniejsza wartość pól wartość_min, sumowana jest wartość pól wartość_sum i wartość_cnt, oraz obliczana wartość dla pola wartość_avg = (suma wszystkich pół wartość_sum)/(suma wszystkich pól wartość_cnt).

Przykład:

Tabela faktów w źródłowej bazie danych nr 1:

Klient	Sprzedawca	Towar	Wartość
10	10	10	5
10	20	10	15

Tabela faktów w źródłowej bazie danych nr 2:

Klient	Sprzedawca	Towar	Wartość
10	20	10	10
20	20	10	15

Tabela faktów w źródłowej bazie danych nr 3:

Klient	Sprzedawca	Towar	Wartość
10	20	10	15
30	10	10	15
30	20	10	15

Krotka odczytana od wrapera nr 1:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	10	10	5	5	5	5	1

Krotka odczytana od wrapera nr 2:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	20	10	10	10	10	10	1

Krotka odczytana od wrapera nr 3:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	20	10	15	15	15	15	1

Krotka 1 posiada znacznik = 101010, krotki 2 i 3 posiadają znacznik = 102010. Znacznik krotki 1 jest najmniejszy, więc jest to krotka na której zostaną wykonane obliczenia. Z uwagi na to iż przeliczana jest tylko jedna krotka wstawiane wartości agregowane nie ulegną zmianie.

Krotka 1 wstawiona do magazynu:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	10	10	5	5	5	5	1

Kolejna krotka odczytana od wrapera nr 1:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	20	10	15	15	15	15	1

Wszystkie trzy krotki posiadają znacznik = 102010. Zatem przeliczane są wszystkie trzy krotki.

Krotka 2 wstawiona do magazynu:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	20	10	15	5	30	10	3

Od wrapera nr 1 odebrano już wszystkie krotki, dlatego teraz pod uwagę brane są tylko krotki odczytane od wraperów nr 2 i 3.

Kolejna krotka odczytana od wrapera nr 2:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
20	20	10	15	15	15	15	1

Kolejna krotka odczytana od wrapera nr 3:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
30	10	10	15	15	15	15	1

Najmniejszy znacznik posiada krotka nr 2 (202010). Zostanie ona wstawiona do magazynu. Jest to ostatnia krotka od wrapera nr 2, więc brane pod uwagę są teraz tylko krotki od wrapera nr 3. Jako iż występują one pojedynczo zostają po kolei i bez zmian wstawione do magazynu.

Zawartość relacji centralnej w magazynie danych:




Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	10	10	5	5	5	5	1
10	20	10	15	5	30	10	3
20	20	10	15	15	15	15	1
30	10	10	15	15	15	15	1
30	20	10	15	15	15	15	1

Opisane powyżej czynności wykonywane są dla każdej kombinacji atrybutów grupujących np. klient, sprzedawca, towar lub towar, branża itp. Kiedy relacja centralna jest już wypełniona (czyli w relacji centralnej znajdują się przetworzone dane ze wszystkich tabel faktów ze źródłowych baz danych) wtedy faza inicjalizacji magazynu danych dobiega końca i zaczyna się faza kolejna - faza przyrostowej pielęgnacji zgromadzonych wcześniej danych.

W fazie tej następuje nieustające odpytywanie monitorów. Monitory mogą zgłosić, iż dokonano modyfikacji danych, lub nie zgłosić żadnych zmian jeśli takowe nie nastąpiły. Możliwe zmiany dokonane w źródłowych bazach danych to modyfikacja relacji bocznych lub relacji centralnej. W przypadku relacji centralnej możliwe jest dodanie nowej krotki, zmiana oraz usunięcie istniejącej krotki (Jeśli przyjmiemy iż jedna krotka w tabeli faktów to jeden fakt sprzedaży np. faktura to dostępne modyfikacje będą dotyczyły kolejno wystawienia nowej faktury, korekty oraz unieważnienia istniejącej faktury). W przypadku relacji bocznych możliwe jest jedynie dodanie nowej krotki lub zmiana istniejącej, niemożliwe jest natomiast usunięcie krotki (możemy to rozumieć jako np. dopisanie nowego klienta - dodanie nowej krotki, zmiana danych personalnych klienta - modyfikacja krotki, usunięcie klienta wiązałoby się z usunięciem wszystkich faktur dotyczących danego klienta - usunięciem odpowiednich wpisów z relacji centralnej). Zachodzące zmiany w źródłowych bazach danych są oznaczane przez monitory odpowiednio:

• INS - dodanie krotki,

• DEL - usunięcie krotki,

• UPD - modyfikacja krotki.

Podczas sprawdzania zmian monitory informują moduł integratora o rodzaju zmiany, numerze relacji w której nastąpiła zmiana (relacji centralnej odpowiada zawsze numer 0, pozostałe numery to relacje boczne), oraz wstawianych, usuwanych lub zmianianych wartościach (przesyłana jest odpowiednio dodana krotka, usunięta krotka, krotka przed i po dokonanej zmianie).

W przypadku jakiejkolwiek modyfikacji relacji bocznych integrator jest w stanie uaktualnić zawartość magazynu na podstawie otrzymanych od monitora danych. W przypadku zmian dokonanych w tabelach faktów konieczne jest uaktualnienie relacji centralnej. Uaktualnianie to jest wykonywane przyrostowo. Oznacza to, że relacja centralna nie jest wypełniana od nowa, lecz modyfikowane są tylko odpowiednie krotki. Modyfikacja krotek w relacji centralnej odbywa się w następujący sposób:

1. Jeśli dodano jedną krotkę:

Klient	Sprzedawca	Towar	Wartość
10	20	10	20

Wówczas przetwarzana jest krotka z relacji centralnej z magazynu danych, gdzie klient = 10, sprzedawca = 20 i towar = 10. Dodano krotkę gdzie atrybut wartość = 20 - czyli więcej niż aktualne maksimum (wartość_max = 15) - nowa wartość maksymalna = 20, więcej niż aktualne minimum (wiec wartość_min pozostaje bez zmian), suma jest powiększona o dodaną wartość (wartość_sum = 30 + 20 = 50), ilość wystąpień (krotek) jest zwiększona o jeden (dodano jedną krotkę), a wartość średnia jest obliczana na podstawie nowej sumy i nowej ilości wystąpień (wartość avg = 50/4= 12 - dokładnie 12,5 jednak wartość ta jest zaokrąglana). Oto zawartość relacji centralnej po uaktualnieniu:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	10	10	5	5	5	5	1
10	20	10	20	5	50	12	4
20	20	10	15	15	15	15	1
30	10	10	15	15	15	15	1
30	20	10	15	15	15	15	1

9. Jeśli usunięto krotkę:

Klient	Sprzedawca	Towar	Wartość
10	20	10	20

Wówczas przetwarzana jest krotka z relacji centralnej z magazynu danych, gdzie klient = 10, sprzedawca = 20 i towar = 10. Usunięto krotkę gdzie atrybut wartość = 20 - czyli aktualne maksimum (wartość_max = 20) - nowa wartość maksymalna nie jest znana - konieczne jest wówczas odwołanie się do wszystkich wraperów z pytaniem o aktualne maksimum atrybutu wartość. Otrzymamy tyle krotek ile jest wraperów i wybierzemy z nich nowe maksimum, które zostanie wstawione do bazy danych. Podobne odwołanie do wraperów występuje jeszcze w przypadku usunięcia aktualnego minimum - postępowanie jest wtedy dokładnie takie same. Usunięto krotkę gdzie atrybut wartość = 20 - czyli więcej niż aktualne minimum (wiec wartość_min pozostaje bez zmian), suma jest pomniejszona o usuniętą wartość (wartość_sum = 50 - 20 = 30), ilość wystąpień (krotek) jest pomniejszona o jeden (usunięto jedną krotkę), a wartość średnia jest obliczana na podstawie nowej sumy i nowej ilości wystąpień (wartość avg = 30/3= 10). Oto zawartość relacji centralnej po uaktualnieniu:

Klient	Sprzedawca	Towar	Wartość_max	Wartość_min	Wartość_sum	Wartość_avg	Wartość_cnt
10	10	10	5	5	5	5	1
10	20	10	15	5	30	10	3
20	20	10	15	15	15	15	1
30	10	10	15	15	15	15	1
30	20	10	15	15	15	15	1

Jak widać dodanie krotki a następnie jej usunięcie spowodowało powrót do wartości sprzed wprowadzenia zmian.

10. Jeśli zmieniono krotkę

Klient	Sprzedawca	Towar	Wartość
10	20	10	15

na:

Klient	Sprzedawca	Towar	Wartość
10	20	10	20

System postępuje tak jakby najpierw usunięto „starą” krotkę, a następnie dodano „nową” krotkę.

1. Rozbudowa modułu integratora

Podczas implementacji ujawniło się kilka dodatkowych problemów, których rozwiązanie skomplikowałoby znacznie cały projekt. Najważniejszym uproszczeniem było założenie, iż moduł integratora w fazie pielęgnacji magazynu danych ciągle odpytuje monitory. Zmiana systemu tak, aby monitory same informowały moduł integratora o zaistniałych zmianach zredukowałoby ilość przesyłanych przez sieć komunikatów oraz wyeliminowało ciągły odczyt tabel zmian przez monitory co w znaczny sposób wpłynęłoby na efektywność całego systemu. Wiązało się to jednak z wprowadzeniem w module integratora wątków odpowiedzialnych za odczyt komunikatów od monitorów i wątków odpowiedzialnych za uaktualnianie magazynu danych oraz zaimplementowania kolejek komunikatów. Kolejnym założeniem upraszczającym było wykluczenie usuwania krotek z relacji bocznych. Wyeliminowało to konieczność usuwania krotek z relacji centralnej powiązanych z usuniętą krotką z relacji bocznej. Innym rozwiązaniem które mogłoby być zmienione sposób odczytu nowych ekstremów w przypadku usunięcia wartości będącej aktualnym maksimum lub minimum. Przyjęto, iż usunięcie wartości ekstremalnych występuje na tyle rzadko, iż nie powoduje zauważalnego spadku wydajności całego systemu. Jednak w wyjątkowych sytuacjach mogłoby się to okazać problemem. Te i inne zmiany ulepszyłyby system i spowodowały wzrost jego wartości. Jednym z założeń stawianych systemowi była możliwość ciągłej jego rozbudowy. Wyżej wymienione zmiany są więc pierwszymi etapami rozbudowy i ulepszania systemu.

1. Moduł monitora

1. Zadanie monitora

Zadaniem monitorów jest wykrywanie i przesyłanie do integratora zmian w źródłowych bazach danych. Zmiany te powinny być przedstawione w postaci jednej z trzech operacji: wstawiania, usuwania lub uaktualniania krotki. W naszym projekcie źródłową bazą danych jest baza danych firmy Oracle.

2. Założenia implementacyjne

Do implementacji modułu monitora użyłem języka Java i interfejsu JDBC. Głównymi przesłankami tego wyboru były: przenaszalność Javy oraz łatwość użycia JDBC. Komunikację z modułem integratora oparłem na interfejsie gniazd (sockets).

W kręgu moich zainteresowań znalazły się dwa sposoby wykrywania zmian w źródłowej bazie danych. Pierwszy, oparty o zdalne wywoływanie procedur (RPC - remote procedure call), mimo niewątpliwej zalety polegającej na natychmiastowym powiadamianiu o zaistniałych modyfikacjach źródłowej bazy danych został przeze mnie porzucony ze względu na ograniczone zastosowanie tego mechanizmu (jest on udostępniany dopiero w bazie danych Oracle8). Wybrałem sposób drugi, oparty na wyzwalaczach (ang. triggers). Wymaga on okresowego przeglądania tabel w których zapisywane są zachodzące w źródłowej bazie danych zmiany. Powoduje to pewne opóźnienie w otrzymaniu informacji o zajściu zmiany, jednak nie jest to opóźnienie na tyle duże, aby wykluczało zastosowanie tego rozwiązania. Niewątpliwymi zaletami powyższej metody są: po pierwsze ułatwione buforowanie zaistniałych zmian w źródłowej bazie (polecenie „insert into tabela_zmian” w ciele wyzwalacza); po drugie fakt, iż mechanizm wyzwalaczy jest mechanizmem już wypróbowanym i pewnym. Dlatego wybrałem sposób oparty na wyzwalaczach.

W tym momencie zaprezentuję szkieletowy algorytm działania monitora:




3. Implementacja

Ze względu na szybkość działania postanowiłem rozbić monitor na dwa niezależne programy, z których pierwszy uruchamiany jest w momencie rozpoczęcia śledzenia zmian w źródłowej bazie danych, natomiast drugi - w momencie rozpoczęcia pracy przez moduł integratora. Zadaniem pierwszego programu jest:

• pobranie ze słownika schematu źródłowej bazy danych,

• utworzenie liczników pozwalających na odczytywanie danych z tabel we właściwej kolejności,

CREATE SEQUENCE licznik
increment by 1
start with 1

• utworzenie tabel zmian w których będą zapisywane modyfikacje źródłowej bazy danych, np. dla tabeli wojewodztwa (id NUMBER(4), nazwa VARCHAR2(30)) tworzę tabelę awojewodztwa (numer NUMBER, r VARCHAR2(5), id NUMBER(4), nazwa VARCHAR2(30))

Licznik zmian

Rodzaj zmiany (INS, DEL, UPD)

Zmieniona krotka...

Podczas implementacji monitora problemem okazał się fakt, iż system Oracle odczytuje krotki z tabeli w dowolnej kolejności. Rozwiązaniem tego problemu okazało się dodanie do tabeli zmian licznika i odczytywanie danych z niej zgodnie z rosnącą wartością tegoż pola.

• utworzenie wyzwalaczy odpowiedzialnych za zapis tych modyfikacji do tabel zmian. Np. dla tabeli awojewodztwa tworzę wyzwalacz atwojewodztwa:

after insert or update or delete on wojewodztwa
for each row
begin
if inserting then
insert into awojewodztwa values(licznik.nextval,'ins',:new.id,:new.nazwa);
elsif deleting then
insert into awojewodztwa values(licznik.nextval,'del',:old.id,:old.nazwa);
elsif updating then
begin
insert into awojewodztwa values(licznik.nextval,'upd',:old.id,:old.nazwa);
insert into awojewodztwa values(licznik.nextval,'upd',:new.id,:new.nazwa);
end;
end if;
end;

Z powyższego opisu widać, że pierwszy program ma funkcję inicjalizującą - przygotowuje system do rozpoczęcia śledzenia zmian w bazie danych.

Drugi program jest monitorem właściwym - czeka na sygnał integratora i gdy go otrzyma wysyła informacje o zmianach zaszłych w bazie źródłowej (informacje te pobiera z tabel zmian). Format wysyłanych informacji jest następujący:

Rodzaj zmiany

Numer monitora

Nazwa tabeli

Zmieniona krotka (lub 2 krotki)...

Pole „rodzaj zmiany” może przyjąć jedną z trzech postaci (INS, DEL, UPD) w zależności od rodzaju zmiany o której informacja jest przekazywana. Pole „numer monitora” zawiera numer jaki został nadany danemu monitorowi przez integrator przy inicjalizacji. „Nazwa tabeli” określa tabelę, w której zmiana zaszła. W przypadku zmiany typu „insert” lub „delete” do integratora wysyłana jest tylko jedna krotka w ramce. Natomiast w przypadku zmiany typu „update” monitor przekazuje w ramce dwie krotki: starą i nową.

1. Moduł osłony (wrapper)

1. Funkcje modułu osłony

Dane gromadzone w zbiorczej bazie danych są pozyskiwane ze źródłowych baz danych, przy czym formaty fizyczne, logiczne i pojęciowe poszczególnych źródeł danych mogą się różnić między sobą. Z każdym z takich źródeł jest związana warstwa oprogramowania o nazwie wrapper, którego zadaniem jest pozyskiwanie danych z różnych źródłowych baz danych i transformowanie danych z formatu wykorzystywanego w źródle do formatu wykorzystywanego w magazynie - dla każdego modelu danych źródłowych konieczne jest zastosowanie specyficznego modułu wrappera. Wrapper możemy zatem zdefiniować jako moduł programistyczny umożliwiający przystosowanie interfejsu lokalnej bazy danych do pewnego standardu (CORBA, HTTP, COM). Funkcją wrappera jest umożliwienie fizycznego połączenia ze źródłową bazą danych. W zasadzie wrapper nie zajmuje się bardziej wyrafinowanym odwzorowaniem, chodzi głównie o translację danych, parametrów i wywołań funkcji płynących z zewnątrz na analogiczne dane, parametry i funkcje wyrażone w API konkretnego lokalnego systemu do postaci, która jest wygodna dla systemu heterogenicznych baz danych. Wrappery są podstawą innych środków odwzorowania schematów i aplikacji, takich jak monitory i perspektywy.

2. Założenia implementacyjne

Projektując system, rozważaliśmy stworzenie jednego wrappera, który obsługiwałby wszystkie źródłowe bazy danych. Musiałby on umieć obsługiwać wszystkie systemy zarządzania bazą danych, jakie zastosowano do gromadzenia źródłowych informacji. Takie rozwiązanie wydało się nam jednak niewłaściwe, gdyż utrudniałoby rozszerzenie systemu, o obsługę nowych standardów baz danych. Rozbudowa taka wymagała by przerabiania istniejącego modułu wrappera.

Zdecydowaliśmy się zastosować rozwiązanie, które jest już wykorzystywane w działających na rynku systemach. Z każdą źródłową bazą danych współpracuje jeden moduł wrappera i obsługuje on tylko tę jedną bazę. Umożliwia to łatwiejszą rozbudowę systemu.

Myśleliśmy również o opracowaniu ogólniejszego interfejsu obsługi baz danych. Interfejsu, który zawierałby wbudowane mechanizmy stosowane w komunikacji z większością systemów obecnych na rynku. Uzupełnienie systemu o obsługę nowych systemów baz danych sprowadzałoby się do określenia jedynie niezbędnych informacji, którymi istniejące systemy się różnią. Odrzuciliśmy jednak to rozwiązanie, jako zbyt trudne i przekraczające zakres pracy. W zastosowanym rozwiązaniu wrapper jest programem wykonywalnym, obsługującym konkretną bazę danych. Dla bazy danych w innym standardzie należy opracować nowy moduł wrappera, tworząc go od początku.

3. Zasada działania wrappera

Moduł osłony ma za zadanie konwertowanie danych ze źródłowych baz danych do wspólnego formatu danych używanego w naszym projekcie. Moduł ten jest umiejscowiony nad każdą źródłową bazą danych i konwertuje informacje z tego źródła do wspólnego formatu danych. W naszym modelu bazy danych wrapper komunikuje się z modułem integratora i ze źródłową bazą Oracle. Czas pracy wrappera można podzielić na trzy fazy:

1. Ponieważ wrapper działa jako serwer TCP to oczekuje (nasłuchuje) na zgłoszenie się modułu integratora (klienta). Po nawiązaniu połączenia z integratorem otrzymuje od niego potrzebne do dalszej pracy dane o użytkowniku , które zostaną przechowane w dwuelementowej tablicy znakowej (nazwa użytkownika oraz jego hasło). Po wysłaniu potwierdzenia, że dane te otrzymał wrapper oczekuje od integratora przesłania zapytania, które też przechowywane zostaje w odpowiednich strukturach.

2. Po otrzymaniu zapytania od integratora wrapper musi uzyskać połączenie ze źródłową bazą danych a następnie przekazać wyniki zapytania z powrotem do integratora. Do komunikacji z bazą źródłową wykorzystuje dołączone do pakietu Oracle biblioteki języka C - Oracle Call Interface (OCI). Zatem logowanie do źródłowej bazy danych, otwarcie kursora, przetwarzanie zapytania, wiązanie adresu zmiennych z obszarem kursora, zbieranie wyników do odpowiednich tablic, zamykanie kursora i wylogowanie jest realizowane za pomocą OCI.

3. Otrzymane wyniki zapytania zostają przesyłane do integratora wg wcześniej uzgodnionego schematu. Następnie zamykane jest połączenie z integratorem i następuje czas oczekiwania na kolejne zgłoszenie się integratora.

1. Komunikacja z modułem integratora

Komunikacja z modułem integratora odbywa się zgodnie z protokołem TCP (architektura klient-serwer) i według wcześniej uzgodnionego schematu. Wrapper działa jako serwer TCP nasłuchując na porcie 5001. Po nawiązaniu połączenia musi od modułu integratora otrzymać dane o użytkowniku czyli nazwa użytkownika i hasło dostępu do źródłowej bazy danych. Po otrzymaniu pojedynczej porcji danych wrapper przesyła potwierdzenie do integratora w postaci liczby 1. Następnie integrator musi przesłać zapytanie, które to wrapper będzie musiał przetworzyć. Po zebraniu wyników zapytania wrapper przesyła je integratorowi i czeka na potwierdzenie ich otrzymania. Po otrzymaniu potwierdzenia zamyka połączenie i czeka (nasłuchuje) na kolejne połączenie.

Funkcje związane z połączeniem TCP:

• bind() - kojarzy adres lokalny i port z utworzonym soketem,

• listen() - oczekuje na przychodzące połączenie na określonym porcie,

• accept() - akceptuje połączenie,

• recv() - odbiera dane,

• send() -wysyła dane,

• closesocket() - zamyka połączenie.

1. Zaimplementowane funkcje

Oto wykaz zaimplementowanych funkcji (wraz z dostępnymi funkcjami OCI i funkcjami protokołu TCP w celu otrzymania połączenia z modułem integratora ):

• connect_user() - połączenie z bazą danych Oracle, wykorzystując funkcję OCI olog(),

• new_cursor() - otwarcie nowego kursora (wykorzystanie funkcji oopen() - OCI),

• get_sql_statement() - pobranie zapytania i zapamiętanie go w odpowiednich strukturach,

• analyze() - analiza poprawności zapytania (wykorzystanie funkcji oparse() - OCI),

• do_binds() - wiązanie adresu dla zmiennych wejściowych (zapytania), wykorzystuje funkcję OCI obndrv(),

• describe_define() - zdefiniowanie i opisanie kolumn lub wyrażeń zapytania SQL, związane z danymi wyjściowymi; wykorzystuje funkcje OCI odescr() oraz odefin(),

• execute() - wykonanie zapytania (wykorzystanie funkcji exec() - OCI),

• print_rows() - zbieranie wyników przetworzonego zapytania, wykorzystuje funkcje ofetch(),

• do_exit() - zamyka kursor i wylogowuje użytkownika przy pomocy funkcji oclose() i ologof(),

1. Uwagi końcowe

Dosyć ważnym elementem implementowanego systemu jest moduł wrappera odpowiedzialny za komunikację z bazą danych i przetwarzanie zapytań. Powinien on zapewniać niezależność od systemu zarządzania bazą danych. Ze względów czasowych ograniczyliśmy się tylko do systemu Oracle co znacznie ułatwiło główne zadanie wrapppera, czyli konwersję danych. Zastosowanie języka C oraz wykorzystanie OCI (Oracle Call Interface) uprościło komunikację z bazą Oracle, ale także stanowiło zaletę w postaci przenośności tego modułu na inne platformy sprzętowe i systemy operacyjne. Komunikacja wrappera z integratorem została zaimplementowana zgodnie z protokołem TCP/IP (tryb połączeniowy) co zwiększyło jej niezawodność.

• Instrukcja użytkownika

1. Program konfiguracyjny słownika magazynu

Program służy do automatycznego generowania słownika systemu, w którym opisane są relacje występujące w źródłowych bazach danych. Użytkownik systemu nie musi znać schematu budowy słownika, który jest niezbędny do prawidłowego działania całego systemu, więc aby dokonać jego konfiguracji powinien postępować według podanych niżej kroków:

1. Uruchom program generujący słownik np. poleceniem

java Slownik.class

Uwaga: sposób uruchomienia programu zależy od systemu operacyjnego, którego używasz. Może okazać się konieczne podanie ścieżki dostępu do katalogu zawierającego plik `Slownik.class'

Na ekranie monitora pokaże się okienko programu, podobne do tego:




11. Następnie wybieramy z menu pozycję Slownik/Relacje, co spowoduje otworzenie kolejnego okna:




12. W polu „Nazwa relacji” należy wpisać po kolei nazwy wszystkich relacji, które występują w źródłowych bazach danych. Należy pamiętać aby pierwszą wprowadzoną relacją była relacja centralna, kolejność wprowadzania reszty relacji nie ma znaczenia. Aby podać następną relację należy użyć przycisku „Kolejna relacja”. Do ewentualnej korekty służy przycisk „Poprzednia relacja”, który pozwala cofnąć się jednorazowo do wpisanej uprzednio pozycji. Po wpisaniu nazw wszystkich relacji należy przejść do poniższego okna przy użyciu przycisku „Koniec relacji”.




13. Po wprowadzeniu nazw wszystkich relacji należy podać nazwy atrybutów każdej z wprowadzonych wcześcniej relacji oraz określić typ każdego atrybutu. Nazwę atrybutu należy wprowadzać w polu „Nazwa atrybutu”. Wprowadzany atrybut należy do relacji, której nazwa wyświetlona jest w polu „Nazwa relacji”. Typ wprowadzanego właśnie atrybutu wybieramy z listy rozwijanej, która zawiera wszystkie dostępne typy atrybutów. Jeśli wybrany zostanie typ np. number(r),char(r),varchar(r) lub varchar2(r) w pierwszym okienku należy wprowadzić liczbę znaków z ilu ma składać się ten atrybut. Dla typu number(r,n) należy w pierwszym okienku podać liczbę znaków z ilu ma składać się ten atrybut, w drugim zaś liczbę miejsc po przecinku. Aby wpisać kolejny atrybut danej relacji należy użyć przycisku „Kolejny atrybut”. Aby wprowadzić atrybuty dla kolejnej relacji należy użyć przycisku „Kolejna relacja”. W przypadku ewentualnej krekty można posłużyć się przyciskiem „Poprzedni atrybut” lub „poprzednia relacja” -działanie tych przycisków jest analogiczne do przycisków z poprzedniego okna. Po wprowadzeniu wszystkich atrybutuów dla wszystkich relacji należy użyć przycisk „Koniec atrybutów”. Pokaże się poniższe okno




14. Tutaj dokonujemy wyboru który z atrybutów relacji ma być jej kluczem głównym. Wyboru dokonujemy wybierając odpowiednią pozycję z rozwijanej listy, która zawiera nazwy wszystkich atrybutów aktualnie wybranej relacji. Po ustwleniu kluczy głównych wszystkich relacji przechodzimy do następnego okna przyciskiem „Koniec kluczy głównych”. Ukaże się poniższe okno




1. Teraz neleży określić powiązania pomiędzy relacjami. Dokonuje się tego poprzez określenie par uporządkowanych <klucz obcy;klucz główny>, gdzie klucz obcy jest dowolnym atrybutem jednej relacji, a klucz główny kluczem głównym drugiej relacji. Jednak aby powiązanie tych dwóch relacji było możliwe obydwa atrybuty będące kluczami muszą mieć taki sam typ.

W polu „Nazwa relacji” jest wyświetlona nazwa relacji dla której jest aktualnie wyznaczane powiązanie. W polu „Nazwa atrybutu” jest wyświetlaona nazwa atrybutu który ma być kluczem obcym, zaś w polu „Klucze główne” są wyświetlone klucze główne wszystkich relacji, które są tego samego typu co atrybut będący kluczem obcym. Relacja centralna może mieć teoretycznie tyle powiązań ile posiada atrybutów. Pozostałe relacje powinny posiadać co najwyżej po jednym powiązaniu. Należy tak ustalić powiązania pomiędzy relacjami, aby utworzyły one „gwiazdę”. Powiązane relacje nie mogą tworzyć cyklu tzn. jeśli np. relacja A jest powiązana z relacją B a relacja B z relacją C to relacja C nie może być powiązana z relacją A. Należy pamiętać także o tym aby dwie relacje różne relacje nie były powiązane z tą samą relacją.

Przykładowy schemat gwiazdy




Przykładowy schemat cyklu w połączeniach relacji




Przykładowy schemat połączenia dwóch relacji do jednej relacji




Zakończenie wprowadznia powiązań relacji następuje po użyciu przycisku „Koniec kluczy głównych”. Ukaże się wówczas poniższe okno




15. W polu „Wybierz agregaty” należy zaznaczyć nazwy tych atrybutów, których wartości chcemy agregować (agregowane są maksymalna i minimalma warotść, suma, średnia wartość oraz liczba wystąpień danego atrybutu). W polu „Wybierz atrybuty grupujące” należy zaznaczyć te atrybuty, według których będą pogrupowane agregowane wartości. Kończymy wybór naciskając przycisk „Koniec agregatów”. Pokaże się poniższe okno




16. Tutaj możliwe jest podanie różnych kombinacji atrybutów według których będą grupowane agregowane wartości. Jeśli w poprzednim oknie wybraliśmy jako atrybuty grupujące np. klient_id, sprzedawca_id, towar_id, zamówienie_id to możemy teraz określić ich kombinacje np.

• klient_id; towar_id; sprzedawca_id

• towar_id; klient_id

• klient_id; srzedawca_id

Kolejność atrybutów w jednej kombinacji nie ma znaczenia. Tworzenie kombinacji następuje poprzez wybranie z rozwijanej listy nazwy atrybutuoraz naciśnięcie przycisku „Dodaj”. W jednej kombinacji może być tyle atrybutów ile jest ich na w rozwijanej liście, przy czym atrybuty nie mogą się powtarzać. Aby utworzyć nową kombinację należy nacisnąć przycisk „Nowa kombinacja”. Aby usunąć niepotrzebną lub błędną komn=binację należy zaznaczyć ją w polu „Wybrane kombinacje atrybutow grupujacych” a następnie nacisnąć przycisk „Usun”. Aby zakończyć wprowadzanie kombinacji atrybutów grupujących należy użyć przycisku „Koniec”. Pojawi się wtedy następujące okno




17. Należy wymienić adresy wszystkich komputerów na których znajdują się źródłowe bazy danych, nazwę użytkownika i hasło na którego koncie znajdują się opisane wcześniej relacje, oraz określić numer portu na którym będą działały moduły monitora i wrapera.

Adres komputera podajemy w polu „Adres bazy danych” i w tym samym polu po dwukropku numer portu np.:

adres.komputera.pl:1234 lub 123.123.123.123:1234

Jeśli źródłowa baza danych znajduje się na tym samym komputerze co generowany słownik to można podać adres tego komputera lub wpisać zamiast niego localhost lub 127.0.0.1 oraz oczywiście numer portu.

Nazwę użytkownika wpisujemy w polu „Uzytkownik”, a jego hasło w polu „Hasło”. Zamiast wpisywanego hasła ukażą się gwiazdki. Określanie adresów źródłowych baz danych można zakończyć używając przycisku „Koniec baz danych”. Pojawi się poniższe okno




18. Dla każdej źródłowej bazy danych należy wybrać odpowiednie relacje które się w niej znajdują. W każdej bazie powinien znajdować się ten sam zestaw relacji. Aby unikąć przypadkowych niespójności najlepiej umieścić wszystkie relacje we wszystkich źródłowych bazach danych. Aby tego dokonać należy zaznaczyć wszystkie pozycje w polu „Relacje znajdujące się w bazie danych” i nacisnąć przycisk „Kolejna baza danych”. Po przypisaniu relacji do wszystkich źródłowych baz danych należy nacisnąć przycisk „Koniec”.Pojawi się okno




19. To już koniec opisu relacji. Teraz pozostaje jedynie podanie nazwy użytkownika na koncie którego będzie składowany wygenerowany słownik oraz magazyn danych. Nazwę użytkownika należy podać w polu „Uzytkownik”, a jego hasło w polu „Haslo”. Wprowadzane hasło będzie wyświetlone w postaci gwiazdek. W polu „Nazwa magazynu” należy podać nazwę sterownika obsługującego daną bazę danych. Po naciśnięciu przycisku „Polacz się z magazynem” następuje połączenie się z bazą danych i wygenerowanie słownika.

20. W przypadku niewypełnienia jakiegoś pola lub w razie niewybrania jakiejś opcji pojawi się okno ze stosownym komunikatem




Aby w takim przypadku zakończyć działanie programu należy użyć przycisku „Tak”, w przeciwnym razie „Nie” - komunikat zniknie dając możliwość ponowego wypełnienia pola lub wybory opcji.

1. Query processor

Do właściwej biblioteki query processora dołączono prosty program, umożliwiający zadawanie zapytań do magazynu w trybie interaktywnym. Ponieważ jest to 32-bitowy program działający w trybie konsoli, jest możliwe jego wykorzystanie w trybie wsadowym za pomocą operatorów przekierowywania strumieni. Program uruchamiamy z linii komend, wpisując jego nazwę (z ewentualną ścieżką dostępu)

WhConsole.exe

Podanie rozszerzenia `.exe' jest opcjonalne. Program zgłosi się znakiem zachęty w postaci:

Warehouse>

za którym znajduje się mrugający kursor, oznaczający miejsce wpisywania tekstu. Od tej chwili możemy zadawać zapytania do magazynu, posługując się instrukcją SELECT języka SQL.

Uwaga: w tym miejscu instrukcji powinien pojawić się dokładny opis formatu zapytań, jakie możemy kierować do magazynu. Zdecydowano się go pominąć, ponieważ opis ten pojawił się już wcześniej w niniejszej pracy.

Po wpisaniu zapytania, które należy zakończyć średnikiem (zapytanie może być rozdzielone znakami końca linii) i naciśnięciu klawisza ENTER, na ekranie zostaną wyświetlone wyniki zapytania, lub komunikat o błędzie. Obsługa programu jest podobna do obsługi programu SQL*Plus firmy Oracle.

Poza poleceniami języka SQL, możemy użyć dwóch komend specjalnych, które również należy zakończyć średnikiem. Komendy specjalne poprzedzamy znakiem ukośnika (`/'). Są to:

• exit - polecenie powoduje zakończenie pracy z magazynem i opuszczenie programu,

• debug - polecenie powoduje włączenie tzw. trybu testowego - w tym trybie program przedstawia postać przetworzonego zapytania języka SQL, które jest kierowane do magazynu.

1. Uruchomienie modułu wrappera

Wrapper uruchamiamy poleceniem

wrapper.exe <nr_portu>

Jeśli jest to konieczne, należy podać ścieżkę dostępu do katalogu, zawierającego moduł wykonywalny wrappera. Jako parametr, podajemy nr portu, na którym wrapper powinien nasłuchiwać. Wrapper jest uruchamiany na komputerze zawierającym bazę danych z relacjami źródłowymi.

Na komputerach wyposażonych w system operacyjny Windows NT moduł można uruchomić jako serwis (service, polskie tłumaczenie - usługa), za pomocą narzędzia SRVANY, dołączone do ResourceKit'a dla WinNT.

2. Uruchomienie modułu monitora

Monitor uruchamiamy poleceniem

java monit <nr_portu> <username> <password>

Jeśli jest to konieczne, należy podać ścieżkę dostępu do katalogu, zawierającego moduł wykonywalny monitora. Jako parametry, podajemy nr portu, na którym monitor powinien nasłuchiwać, oraz parametry konta w bazie danych, która obsługuje dany monitor. Monitor jest uruchamiany na komputerze zawierającym bazę danych z relacjami źródłowymi.

• Przykładowa sesja z systemem

Założyliśmy, że źródłowe bazy danych zawierają schemat relacji zawarty w p. V.3. Po uruchomienia programu konfiguracyjnego słownika i wpisaniu potrzebnych danych, program wygenerował i wypełnił następujące relacje w magazynie:

Tabela `relacje'

ID_RELACJI NAZWA_RELACJI
---------- -------------
0 sprzedaz
1 wojewodztwa
2 miasta
3 klienci
4 sprzedawcy
5 branze
6 kategorie
7 towary
8 lata
9 kwartaly
10 miesiace
11 zamowienia

Tabela `atrybuty'

ID_ATRYBUTU NAZWA_ATRYBUTU ID_RELACJI TYP
----------- -------------- ---------- ------------
0 id 1 NUMBER(4)
1 nazwa 1 VARCHAR2(30)
2 id 2 NUMBER(4)
3 nazwa 2 VARCHAR2(20)
4 wojewodztwo 2 NUMBER(4)
5 id 3 NUMBER(4)
6 nazwa 3 VARCHAR2(25)
7 adres 3 VARCHAR2(25)
8 miasto 3 NUMBER(4)
9 id 4 NUMBER(4)
10 nazwa 4 VARCHAR2(25)
11 adres 4 VARCHAR2(25)
12 id 5 NUMBER(4)
13 nazwa 5 VARCHAR2(15)
14 id 6 NUMBER(4)
15 nazwa 6 VARCHAR2(15)
16 branza 6 NUMBER(4)
17 id 7 NUMBER(4)
18 nazwa 7 VARCHAR2(30)
19 cena 7 NUMBER(8,2)
20 kategoria 7 NUMBER(4)
21 rok 8 NUMBER(4)
22 id 9 NUMBER(4)
23 rok 9 NUMBER(4)
24 id 10 NUMBER(4)
25 kwartal 10 NUMBER(4)
26 id 11 NUMBER(4)
27 data 11 DATE
28 zamowienie 0 NUMBER(4)
29 klient 0 NUMBER(4)
30 sprzedawca 0 NUMBER(4)
31 towar 0 NUMBER(4)
32 miesiac 0 NUMBER(4)
33 ilosc 0 NUMBER(6)
34 wartosc 0 NUMBER(8,2)

Tabela `klucze_glowne'

ID_ATRYBUTU
-----------
0
2
5
9
12
14
17
21
22
24
26

Tabela `klucze_obce'

OD DO
-- --
4 0
8 2
29 5
30 9
16 12
20 14
31 17
23 21
25 22
32 24
28 26

Tabela `wartosci_agregowane'

ID_ATRYBUTU
-----------
33
34

Tabela `agregaty'

2 5 9 12 14 17 21 22 24 26
-- -- -- -- -- -- -- -- -- -- --
-- -- 1 1 -- 1 -- -- -- -- --
1 -- -- -- -- -- 1 1 -- -- --
-- -- 1 1 -- -- 1 -- -- -- --
-- 1 -- -- -- -- -- -- -- -- --

W źródłowych bazach danych istnieją już pewne krotki. Wykonano zapytanie:

SELECT sprzedawcy.nazwa, klienci.nazwa, sum(ilosc), max(wartosc)
FROM sprzedaz, sprzedawcy, klienci
GROUP BY sprzedawcy.nazwa, klienci.nazwa
HAVING max(wartosc) < 1000

Otrzymano wynik:

sprzedawcy.nazwa klienci.nazwa sum(ilosc) max(wartosc)
---------------- -------------- ---------- ------------
hurtownia nr 1 sklep Piotrowo 5 300

Teraz dodano krotkę, która dla otrzymanej w wyniku pary sprzedawca - klient, i o określonych pozostałych wartości (towar, zamowienie itd.) dodała ilosc równą 1 i wartość = 200. Wykonano to samo zapytanie. Wynik:

sprzedawcy.nazwa klienci.nazwa sum(ilosc) max(wartosc)
---------------- -------------- ---------- ------------
hurtownia nr 1 sklep Piotrowo 6 300

Następnie dodano identyczną krotkę, ale ilość = 2, a wartość 400. Teraz wynik wygląda następująco:

sprzedawcy.nazwa klienci.nazwa sum(ilosc) max(wartosc)
---------------- -------------- ---------- ------------
hurtownia nr 1 sklep Piotrowo 8 400

• Zakończenie

W pracy przedstawiono prototypowy system magazynu danych dla przetwarzania analitycznego danych w trybie on-line. Zapoznano czytelnika z celem tworzenia takiego systemu i podobnych do niego i przedstawiono ogólny opis obecnego stanu wiedzy w zakresie projektowania hurtowni danych i systemów OLAP (on-line analitycal processing). Przedstawiono dokładny opis zaprojektowanego systemu - jego założeń i przebiegu implementacji - poprzedzony opisem metod i narzędzi zastosowanych przy jego tworzeniu.

Praca nad systemem magazynu danych generalnie zakończyła się sukcesem. Opracowano system spełniający oczekiwania - prawidłowo magazynujący dane w magazynie w trybie na bieżąco, opracowano też interfejs pośredniczący między magazynem a użytkownikiem.

Udało się opracować system otwarty. Dopisanie modułów wrappera i monitora umożliwia dodanie nowych standardów baz danych, z których magazyn może czerpać dane. Szkoda, że nie starczyło czasu na dopisanie jeszcze jednej pary tych modułów - myśleliśmy na początku o obsłudze baz MS Access. Należy jednak zaznaczyć, że dopisanie modułów wrappera i monitora nie jest zadaniem trywialnym. Rozwijając system, można by pomyśleć o ogólniejszym interfejsie pośredniczącym w komunikacji ze źródłowymi bazami danych. Wymagałoby to przejrzenia istniejących na rynku produktów i znalezienia wspólnego formatu danych. Nie chodzi tu o znaczne ułatwienie dodawania nowych standardów danych, bo ze względu na ich liczbę wydaje się to bardzo trudne, ale być może możliwe byłoby stworzenie interpretowanego języka, który ułatwiałby dodawanie nowych modułów. Obecnie, do napisania wrappera użyto języka C, natomiast do stworzenia monitora - Javy. Wyspecjalizowany język do tworzenia takich modułów skracałby czas wykonania tego zadania.

Same moduły systemu nie są zbyt wymagające pod względem pamięciowym. Dlatego chyba nie można uznać systemu mało efektywnym. Jego wymagania zależą przede wszystkim od serwerów baz danych (zarówno magazynu, jak i baz źródłowych) oraz od ilości przetwarzanych danych. Jeżeli zakładamy duże ilości danych (a dla takich baz projektuje się przecież hurtownie), to dodatkowy nakład wytworzony przez działające moduły systemu jest niewielki. Oczywiście, zgodnie z założeniami, dane w magazynie są składowane przyrostowo.

Pomysłem na poszerzenie możliwości systemu wydaje się nam zmiana wymagań, co do struktury źródłowych relacji. (Obecne wymagania, zgodne z modelem ROLAP'u opisano w p. V.3.) Gdy przyjrzymy się przykładowemu schematowi relacji - systemowi magazynowania faktów sprzedaży w sieci hurtowni - zauważymy, że przydatne byłoby zniesienie ograniczenia polegającego na tym, że każda relacja może być wskazywana przez klucz obcy innej relacji tylko jeden raz. Dla przykładu wyobraźmy sobie, że dla sprzedawcy, podobnie jak dla klienta, chcielibyśmy pamiętać informację o jego położeniu - mieście i województwie. Obecnie wymaga to stworzenia nowych relacji - miasta i województwa - i w dodatku pod zmienionymi nazwami. Nie możemy relacji odpowiadającej za województwa nazwać po prostu województwa, bo taka relacja istnieje. Rodzi się pytanie: czy klucz obcy `miasto' relacji `sprzedawcy' nie mógłby wskazywać na już istniejącą relację `miasta'? Wydaje się, ze znacznie utrudni to zadanie. W takiej sytuacji, dla każdego atrybutu musimy znać nie tylko relację, do której on należy, ale również ścieżkę relacji, po której powinniśmy dojść do niego z relacji centralnej. Wymagałoby to również zmian w formacie zapytania, które podaje użytkownik systemu. Cóż, jest to pomysł na przyszłość.

Kolejnym udoskonaleniem systemu, które wydaje się nam potrzebne, gdy konfigurujemy system, jest opracowanie bardziej zaawansowanego modułu konfiguracji. Chodzi o opracowanie metod, które pozwalały by automatycznie zbierać ze źródłowych baz danych informacje o relacjach i atrybutach, orientować się w ich strukturze - która relacja jest relacją centralną, jakie są między nimi powiązania - i zapisywać te dane w słowniku systemu. Ponieważ zakładamy różnorodność standardów źródłowych baz danych, wymagałoby to opracowania interfejsów pośredniczących w wymianie danych z tymi bazami. Takie interfejsy już mamy - są to moduły wrapperów - należałoby tylko rozszerzyć je o nowe funkcje, funkcje opisu relacji istniejących w bazie.

• Literatura

1. Z. Królikowski, T. Koszlajda, M. Matysiak, R. Wrembel, Magazyny Magazyny danych i technologia OLAP - materiały pomocnicze do wykładów przedmiotu Zaawansowane Systemy Baz Danych.

2. J. Wiener, H. Gupta, W. Labio, W. Zhuge, H. Garcia-Molina, J. Widom, A System Prototype for Warehouse View Maintenance, , Departament of Computer Science, Stanford University.

3. http://www.java.sun.com

4. http://figaro.ae.katowice.pl/~stanek

5. M. Spile, The Complete Guide to Java Database Programming, McGraw-Hill.

6. R. Shukla, T. Smith, Programmer's Giude to the ORACLE Call Interfaces, Oracle Corporation, 1990.

7. M. Gruber, SQL - znakomity podręcznik opisujący najnowszy standard SQL-a, Helion, 1996.

8. Z. Królikowski, M. Zakrzewicz, Materiały z wykładów przedmiotu Zaawansowane systemy baz danych, Politechnika Poznańska, Instytut Informatyki, 1999.

Prototypowy system magazynu danych dla przetwarzania analitycznego w trybie on-line

2

---