Uniwersytet Warszawski Wydział Matematyki, Informatyki i ...students.mimuw.edu.pl/~os/download/mgr.pdf · w hurtowni danych Praca magisterska na kierunku INFORMATYKA w zakresie HURTOWNIE

Uniwersytet WarszawskiWydział Matematyki, Informatyki i Mechaniki

Maciej OsińskiNr albumu: 189426

Optymalizacja wykorzystaniaprzekrojów hiperkostekw hurtowni danych

Praca magisterskana kierunku INFORMATYKA

w zakresie HURTOWNIE DANYCH

Praca wykonana pod kierunkiemdra Krzysztofa StenclaInstytut Informatyki

06.02.2005

Oświadczenie kierującego pracą

Oświadczam, że niniejsza praca została przygotowana pod moim kierunkiem i stwier-dzam, że spełnia ona warunki do przedstawienia jej w postępowaniu o nadanie tytułuzawodowego.

Data Podpis kierującego pracą

Oświadczenie autora (autorów) pracy

Świadom odpowiedzialności prawnej oświadczam, że niniejsza praca dyplomowazostała napisana przeze mnie samodzielnie i nie zawiera treści uzyskanych w sposóbniezgodny z obowiązującymi przepisami.Oświadczam również, że przedstawiona praca nie była wcześniej przedmiotem pro-

cedur związanych z uzyskaniem tytułu zawodowego w wyższej uczelni.Oświadczam ponadto, że niniejsza wersja pracy jest identyczna z załączoną wersją

elektroniczną.

Data Podpis autora (autorów) pracy

Streszczenie

W ramach niniejszej pracy zaprojektowano, zaimplementowano oraz przetestowano algorytmsłużący do wyboru perspektyw do zmaterializowania i indeksów na nich w hurtowni danych.Celem algorytmu jest optymalizacja czasu wykonania zadanego zestawu zapytań do hurtownidanych przy ustalonym ograniczeniu dostępnej przestrzeni dyskowej. Proponowany algorytmjest oparty na idei programowania ewolucyjnego.

Słowa kluczowe

hurtownia danych, zmaterializowane perspektywy, indeksy, algorytmy genetyczne, programo-wanie ewolucyjne

Dziedzina pracy (kody wg programu Socrates-Erasmus)

11.3 Informatyka

Klasyfikacja tematyczna

H. Information Technology and SystemsH.2 Database ManagementH.2.7 Database AdministrationH.2.7.b Data warehouse and repository

I. Computing MethodologiesI.2 Artificial IntelligenceI.2.m MiscellaneousI.2.m.c Evolutionary computing and genetic algorithms

Spis treści

Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Zawartość pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Podziękowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Nawiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1. Hurtownia danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1. OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2. Hurtownia danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Model hurtowni danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1. Atrybut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2. Wymiar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.3. Hierarchia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.4. Modele ROLAP, MOLAP i HOLAP . . . . . . . . . . . . . . . . . . . 9

1.4. Przykład . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5. Zapytania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.1. Przykładowe zapytanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6. Zmaterializowane perspektywy . . . . . . . . . . . . . . . . . . . . . . . . . . 121.7. Indeksy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.8. Model kosztów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.8.1. Relacja obliczalności . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.8.2. Koszt wyliczenia zapytania . . . . . . . . . . . . . . . . . . . . . . . . 141.8.3. Przykład . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.9. Sformułowanie problemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.9.1. Problem NP-zupełny . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.9.2. Algorytmy zachłanne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.9.3. Inne rozwiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Algorytmy genetyczne i programowanie ewolucyjne . . . . . . . . . . . . . 172.1. Podstawowe definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1. Gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.2. Chromosom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3. Populacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.4. Funkcja oceny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.5. Strategia wyboru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.6. Parametry algorytmu genetycznego . . . . . . . . . . . . . . . . . . . . 21

2.2. Schemat działania algorytmu genetycznego . . . . . . . . . . . . . . . . . . . 212.3. Przykład . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4. Schematy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3

2.5. Techniki programowania ewolucyjnego . . . . . . . . . . . . . . . . . . . . . . 232.5.1. Gatunki i nisze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.2. Zmieniające się parametry . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.3. Podpopulacje i wspólnoty . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6. Algorytmy genetyczne a optymalizacja hurtowni danych . . . . . . . . . . . . 24

3. Proponowane rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1. Użyte techniki programowania ewolucyjnego . . . . . . . . . . . . . . . . . . . 27

3.1.1. Reprezentacja problemu . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2. Wspólnoty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.3. Funkcje oceny i kary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2. Implementacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3. Wyniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Dodatek A. Załączniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4

Wprowadzenie

Hurtownie danych umożliwiają przedsiębiorstwom dogłębną analizę ich działalnościz różnych punktów widzenia. Zapytania zadawane hurtowniom danych są bardzo złożone,a ich wyliczenie trwałoby bardzo długo, gdyby nie specjalne techniki mające na celuprzyspieszenie ich wykonania. Jedną z podstawowych takich technik jest wygenerowaniei przechowywanie częściowych wyników, a następnie wykorzystywanie ich do przyspieszeniaprocesu wyliczania zapytań. Takie wyliczone wyniki częściowe nazywamy zmaterializowa-nymi perspektywami (ang. materialized views). Jeśli dane przechowywane w hurtowni da-nych traktujemy jako hiperkostkę, to zmaterializowane perspektywy nazywamy przekrojamihiperkostki. Dodatkowe przyspieszenie działania systemu można uzyskać poprzez stworze-nie (wielowymiarowych) indeksów na wygenerowanych danych częściowych. Przechowywaniezmaterializowanych perspektyw i indeksów wymaga dodatkowej przestrzeni dyskowej orazczasu na aktualizację tych danych podczas procesu zasilania hurtowni danych.Problem wyboru optymalnego zestawu perspektyw i indeksów do zmaterializowania przy

zadanym zestawie zapytań oraz ograniczeniu przestrzeniu dyskowej jest NP-zupełny (szcze-góły w rozdziale 1), dlatego w rzeczywistych zastosowaniach korzysta się z metod heurystycz-nych.Celem niniejszej pracy jest rozwiązanie tego problemu przy pomocy programowania

ewolucyjnego, będącego rozszerzeniem idei algorytmów genetycznych, a następnie porównanieproponowanego rozwiązania z istniejącymi metodami.

Zawartość pracy

Kolejne rozdziały obejmują:

• wprowadzenie do tematyki hurtowni danych, zapotrzebowania biznesowego i stawianychwymagań,

• opis zastosowanego w pracy modelu danych,

• opis zastosowanego w pracy modelu kosztów, służącego do oceny kosztu wykonaniazapytań oraz obliczania przestrzeni zajmowanej przez zmaterializowane perspektywyi indeksy,

• omówienie znanych algorytmów służących do wyboru perspektyw do zmaterializowaniaoraz indeksów, ze szczególnym uwzględnieniem algorytmu zachłannego,

• wprowadzanie do tematyki algorytmów genetycznych i programowania ewolucyjnego,możliwości ich stosowania, ograniczeń i sposobów radzenia sobie z nimi,

• przedstawienie mojego pomysłu,

• wyniki przeprowadzonych testów i ich analizę.

5

Podziękowania

Chciałbym podziękować panu Rafałowi Blejszowi z SAS Institute Polska za zainteresowa-nie mnie tematyką optymalizacji projektu hurtowni danych.

Nawiązania

Pomysł zastosowania algorytmów genetycznych do optymalizacji projektu hurtowni da-nych (wyboru perspektyw do zmaterializowania) pojawił się w pracy [LH99]. Autorzy po-zostawili m.in. dodanie do przedstawionego algorytmu mechanizmów służących do wyboruindeksów oraz umożliwienie równoległego wykonywania obliczeń jako potencjalne rozszerzeńich pracy.W celu przetestowania mojego algorytmu zaimplementowałem algorytm genetyczny przed-

stawiony w [LH99] oraz algorytm zachłanny przedstawiony w [GHRU].

6

Rozdział 1

Hurtownia danych

Duże przedsiębiorstwa potrzebują odpowiednich systemów informacyjnych w celu wspie-rania ich działalności. Do takich systemów należą m.in. systemy klasy ERP (Enterprise Re-source Planning) służące do wspierania operacyjnej działalności, systemy klasy CRM (ClientRelationship Management) do obsługi relacji z klientami, systemy klasy SRM (Supplier Re-lationship Management) do wspierania obsługi współpracy z dostawcami.Kolejnym takim systemem jest system wspierania decyzji (DSS - Decision Support Sys-

tem), umożliwiający modelowanie i analizowanie działalności przedsiębiorstwa pod kątemprocesu podejmowania decyzji oraz planowanie przyszłych posunięć w oparciu o dostępnedane. Systemy wspierania decyzji mogą być wykorzystywane przez kadrę kierowniczą dlaoceny podjętych działań, przez analityków do poszukiwania tendencji w informacjach orazsymulacji nowych posunięć, jak również przez narzędzia Data Mining do zautomatyzowanegoposzukiwania trendów i wzorców zachowań w posiadanych danych.

1.1. OLAP

Użytkownicy wymagają od systemów DSS prezentowania danych w postaci wielowymia-rowej oraz możliwości analizowania tych danych z różnych punktów widzenia, dlatego z regułystosuje się wielowymiarowy model danych. Klasę systemów umożliwiających interaktywnąanalizę wielowymiarowych danych określa się terminem OLAP (On-Line Analytical Proces-sing) lub terminem analityczna baza danych.W 1993 r. E.F. Codd podał 12 postulatów, jakie powinien spełniać silnik przetwarzający

serwera OLAP. 2 lata później rozszerzył je o kolejne 6. Ważniejsze z nich to:

• Wielowymiarowe spojrzenie na dane (z punktu widzenia użytkownika), jednakowe trak-towanie wymiarów.

• Elastyczne możliwości analizowania danych i raportowania – m.in. agregowaniei wybieranie danych w oparciu o dowolnie wybrane przez użytkownika wymiary.

• Architektura klient – serwer z możliwością jednoczesnej pracy wielu użytkowników.

• Serwer OLAP jako przezroczysta warstwa pośrednia pomiędzy systemami hete-rogenicznymi (np. systemy transakcyjne) a klientem OLAP.

Dodatkowo, od systemu OLAP wymaga się dużej szybkości działania. Przykładowo, testFASMI (Fast Analysis of Shared Multidimensional Information, zobacz np. [FASMI]) wy-maga, aby zapytania wyliczały się w ciągu maksymalnie 5 sekund (bardzo skomplikowane

7

zapytania mogą wyliczać się do 20 sekund). Przedstawione w [FASMI] wyniki badań poka-zują, że bardzo często po około 30 sekundach oczekiwania na wynik zapytania, użytkownikalbo zakończy działanie aplikacji przy użyciu Alt+Ctrl+Del, albo zostanie na tyle wybity ztoku myślenia, że wynik do niczego już się nie przyda.

1.2. Hurtownia danych

W celu zapewnienia opisanej wyżej funkcjonalności, dane są pobierane z systemów przed-siębiorstwa (np. transakcyjnych baz danych, systemów klasy ERP, etc.) i przechowywane whurtowni danych. W roku 1991 W.H. Inmon zdefiniował hurtownię danych jako repozytoriumdanych dedykowane systemom wspomagania decyzji, zawierające dane:

• Zintegrowane – dane pochodzące z wielu systemów (m.in. systemów transakcyjnych,arkuszy kalkulacyjnych, plików tekstowych, hierarchicznych baz danych), odpowiednioprzekształcone, wyczyszczone oraz zagregowane do odpowiedniego poziomu.

• Zorientowane na temat – związane z dziedziną, w której chcemy korzystać ze wspoma-gania decyzji.

• Historyczne – przeciętnie z ostatnich 5 lat.

• Nieulotne – dane w hurtowni nie zmieniają się w czasie, są jedynie rozszerzane o nowedane.

Powody, dla których transakcyjna baza danych nie może zapewnić funkcjonalności anali-tycznej bazy danych to m.in.:

• Dane w hurtowni danych są zorientowane na przetwarzanie związane z analizami orazraportowaniem, podczas gdy dane w bazie danych są zorientowane na przetwarzanietransakcyjne wspierające operacyjną działalność przedsiębiorstwa.

• W procesie zasilania hurtowni danych, dane są czyszczone, integrowane i agregowanedo pewnego poziomu. Można powiedzieć, że w systemach transakcyjnych przechowujesię szczegółowe dane, a w hurtowni danych – informacje.

• Hurtownia danych przechowuje dane historyczne, a baza danych z reguły tylko bieżące.

• Dane w hurtowni danych nie są modyfikowane.

• Model relacyjny wykorzystywany w bazach danych wraz z postaciami normalnymi niesprawdzają się w hurtowniach danych, ponieważ zapytania wymagałyby łączenia zesobą większości tabel, a czas odpowiedzi byłby zbyt długi.

1.3. Model hurtowni danych

Poniżej przedstawię uproszczony model hurtowni danych. Taki model był wystarczającydo moich badań. Dokładne opisy różnych modeli hurtowni danych wraz z opisem operacjimożna znaleźć np. w [AGS97], [ASS], [VS99]. Podstawowe pojęcia, z których korzystam przyopisie użytego modelu zostały opisane w kolejnych sekcjach.

8

1.3.1. Atrybut

Atrybut to podstawowa jednostka używana do opisu modelu oraz do wyboru sposobuprezentacji danych do analizy. Przykładowymi atrybutami są rok, klient, wartość sprzedaży.Atrybut może wyznaczać (np. rok, klient) inne atrybuty lub być wyznaczany przez inneatrybuty (np. wartość sprzedaży). Atrybuty wymiaru Di będę oznaczał przez a0

i , . . . , aki .

Każdy atrybut posiada pewien zbiór przyjmowanych wartości, np. atrybut rok możeprzyjmować wartości 2001 – 2004. Liczbę różnych wartości atrybutu ai będę oznaczał przez|ai|. Jeśli atrybut rok przyjmuje wartości 2001 – 2004, to |rok| = 4.Dodatkowo, dla każdego wymiaru Di definiujemy sztuczny atrybut ALLi, będący naj-

mniejszym elementem w tym wymiarze. Jest on używany, jeśli grupowanie przy agregacji nieuwzględnia danego wymiaru. Przyjmuję, że dla każdego wymiaru Di zachodzi |ALLi| = 1.

1.3.2. Wymiar

Wymiarem nazywamy zbiór powiązanych atrybutów. Poszczególne wymiary są rozłączne.Przykładowo, wymiar czas może zawierać atrybuty: rok, miesiąc, dzień. Wymiary oznaczamprzez Di.Wyróżnionym wymiarem jest wymiar miar, do którego należą atrybuty wyznaczane przez

inne atrybuty – np. wartość transakcji sprzedaży może być wyznaczana przez klienta, datę isprzedawaną część.

1.3.3. Hierarchia

Hierarchią nazywamy częściowy porządek atrybutów w obrębie wymiaru. Przykładowo,dla wymiaru czas możemy zdefiniować następującą hierarchię rok ≤czas miesiąc ≤czas dzień.Hierarchie umożliwiają zmianę poziomu szczegółowości prezentowanych informacji w intu-icyjny sposób – np. przejście z podsumowania sprzedaży rocznej na sprzedaż miesięczną.W ogólnym przypadku, każdy wymiar może posiadać wiele hierarchii, jednak dla potrzeby

badań przyjąłem model, w którym każdy wymiar posiada dokładnie jedną hierarchię, będącąporządkiem liniowym atrybutów należących do tego wymiaru. Hierarchię wymiaru Di będęoznaczał przez ≤i.

1.3.4. Modele ROLAP, MOLAP i HOLAP

Dane w hurtowni danych mogą być przechowywane w tabelach relacyjnych (mówimywtedy o architekturze ROLAP – Rys. 1.1) lub wielowymiarowych kostkach (architekturaMOLAP – Rys. 1.2). W modelu relacyjnym wyróżniamy tabelę faktów, zawierającą wartościmiar dla poszczególnych kombinacji atrybutów wyznaczających, oraz tabele wymiarów. Wmodelu wielowymiarowym dane są przechowywane w hiperkostce. Zauważmy, że rozmiarkostki wynika z iloczynu liczby różnych wartości w jej wymiarach, mimo że część komórekmoże być pusta. Z tego powodu kostka jest z reguły większa od odpowiadających jej tabelw modelu ROLAP.Rozwiązanie hybrydowe (HOLAP) dopuszcza przechowywanie części danych w wielowy-

miarowych kostkach (ze względu na szybkość działania), a reszty w tablicach relacyjnych (zewzględu na oszczędność miejsca).W ramach moich badań przyjąłem, że mam daną podstawową kostkę z bazowymi danymi

(opis struktury w 1.4).

9

Rysunek 1.1: Przykład architektury ROLAP.

Rysunek 1.2: Przykład architektury MOLAP. Kostka KLIENT–CZĘŚĆ–CZAS dla ustalo-nego dostawcy.

10

1.4. Przykład

Dla potrzeb testów użyłem prostej “hurtowni danych”, będącej zmodyfikowaną przezemnie wersją testu TPC-R Benchmark organizacji Transaction Processing Performance Coun-cil (zobacz [TPC]). Modyfikacje były konieczne, aby doprowadzić strukturę danych testowychdo postaci kostki. Struktura danych testowych jest przedstawiona na Rys. 1.1.Testowa hurtownia danych posiadała jedną miarę – wartość sprzedaży – oraz 4 wymiary:

czas, klient, dostawca, część. Atrybuty wchodzące w skład poszczególnych wymiarów orazliczba różnych wartości dla poszczególnych atrybutów to:

czas

ALLczas – 1

rok – 4

kwartał – 16

miesiąc – 48

tydzień – 200

klient

ALLklient – 1

region klienta – 8

kraj klienta – 40

klient – 500

dostawca

ALLdostawca – 1

region – 5

kraj – 30

dostawca – 50

część

ALLczesc – 1

typ – 50

część – 100

Każdy wymiar posiada jedną hierarchię atrybutów, zgodną z kolejnością, w jakiej atrybutyzostały wymienione powyżej. Atrybuty znajdujące się wyżej w hierachii oznaczają wyższystopień agregacji. Podstawowa kostka ma 200 ∗ 500 ∗ 50 ∗ 100 = 5 ∗ 108 komórek.Testowane algorytmy otrzymywały na wejściu metadane opisujące powyższą strukturę

hurtowni danych, w tym liczbę różnych wartości każdego atrybutu. Metody przedstawionew [PT], [SDN96] umożliwiają oszacowanie tych wielkości jak również rozmiaru tworzonychkostek na podstawie danych znajdujących się w hurtowni.Testowane algorytmy miały za zadanie zoptymalizować czas wykonania zestawu 20 zapy-

tań. Każde zapytanie qi miało przypisaną wagę wi z przedziału (0, 1).

11

1.5. Zapytania

Do niedawna, każdy dostawca systemów hurtowni danych posiadał własny język zapytań,zbliżony składnią do języka SQL. W ciągu ostatnich kilku lat bardzo dużą popularność zdo-był język MDX (Multidimensional Expressions) zaproponowany przez firmę Microsoft (zobacznp. [WPZ03] i [SMDX]) i jest on obecnie wspierany przez większość nowych silników prze-twarzających hurtowni danych. Dla potrzeb przykładów będę korzystał z języka zbliżonegoskładnią do języka SQL.W przyjętym modelu, zapytanie qi jest wyznaczane przez zbiór atrybutów, po których na-

stępuje grupowanie przy agregacji, oznaczany przez groupby(qi), oraz przez zbiór atrybutówużywanych przy selekcji (tzn. występujących w warunku where), oznaczany przez where(qi).Jeśli zapytanie nie dokonuje grupowania po żadnym atrybucie należącym do danego wymiaruDk, to przyjmujemy, że następuje grupowanie po atrybucie ALLk tego wymiaru.

1.5.1. Przykładowe zapytanie

Mamy dane następujące zapytanie qi:

SELECT sum(sprzedaż)FROM kostkaGROUP BY klient, rokWHERE rok = 2003 ;

W przykładzie mamy:

groupby(qi) = {klient, tydzien, ALLdostawca, ALLczesc}where(qi) = {rok}.

Przyjmuję, że koszt wykonania zapytania jest równy liczbie rekordów, które należyprzetworzyć. Szczegółowy opis modelu kosztów znajduje się w sekcji 1.8.Zapytania, których wykonywanie chcemy optymalizować oraz ich wagi mogę pochodzić

z logów hurtowni danych (większość nowych silników hurtowni danych wspiera popularnystandard Application Response Measurement [ARM], oferujący interfejsy i struktury danych,które można wykorzystać do zebrania potrzebnych danych [ARMJB]). Na wczesnym etapieprojektowanie hurtowni danych, początkowy zestaw zapytań do zoptymalizowania możnauzyskać dzięki technikom modelowania zachowań użytkowników, przedstawionym np. w[Sap99].Przyjąłem następujące upraszczające założenie:

dla każdego zapytania qi zachodzi where(qi) ⊂ groupby(qi),czyli warunek selekcji dotyczy jedynie atrybutów wykorzystywanych przy agregacji. Założenieto nie zmniejsza istotnie ogólności problemu i nie wpływa na jakość wyników algorytmów,pozwala natomiast uprościć model i implementację systemu.

1.6. Zmaterializowane perspektywy

W obu modelach (tzn. relacyjnym i wielowymiarowym) wyliczenie skomplikowanych za-pytań wymagałoby przetworzenia bardzo dużej ilości danych. Aby uniknąć tego problemu,w hurtowni danych przechowujemy również częściowe wyniki, używane przy wyliczaniu za-pytań, zagregowane do pewnego poziomu. Zauważmy, że w skrajnym przypadku – w celupodania łącznej wartości sprzedaży w przykładowej hurtowni danych należałoby przeczytać

12

i zsumować wszystkie 5 ∗ 108 komórek, podczas gdy odpowiedź na to samo zapytanie napodstawie perspektywy zagregowanej do poziomów ALL we wszystkich wymiarach (tzn. po-siadającej tylko jedną komórkę z łączną wartością sprzedaży) wymaga przetworzenie tylkojednej komórki.Perspektywa mvi jest wyznaczana przez zbiór atrybutów używanych przy grupowaniu

groupby(mvi) = {aj00 , . . . , ajk

k }

oraz zbiór indeksów, oznaczanych przez

index(mvi).

Przyjmuję, że wielkość zmaterializowanej perspektywy jest równa iloczynowi liczby róż-nych wartości w poziomach, po których następuje agregacja, czyli:

|mvi| =∏

j∈groupby(mvi)

|aj |.

1.7. Indeksy

Dla przyspieszenie wyliczania zapytań z warunkiem where na podstawie zmaterializowanejperspektywy mv możemy użyć indeksów. Indeksy dla perspektywy mvk będę oznaczał przezindex(mvk). Indeks może być prosty (tzn. zbudowany w oparciu o tylko jeden atrybut) lubzłożony i jest wyznaczany przez ciąg wykorzystywanych atrybutów. Podobnie jak autorzy[GHRU] rozważamy jedynie indeksy gęste.Zauważmy, że kolejność atrybutów w indeksie jest istotna. Mając perspektywę mvi, dla

której groupby(mvi) = {rok, klient, czesc}, oraz indeks (klient, czesc), możemy użyć indeksudo przyspieszenie wykonywania zapytań z warunkiem where dotyczącym atrybutu klient lubatrybutów klient i część. Nie możemy jednak wykorzystać tego indeksu dla przyspieszeniawykonania zapytania z warunkiem selekcji opartym wyłącznie o atrybut część (dyskusja w[GHRU]).Przyjmuję, że rozmiar indeksu na perspektywie mvi jest równy rozmiarowi tej perspek-

tywy |mvi| (szczegóły rozumowania w [GHRU]).

1.8. Model kosztów

Podobnie jak autorzy [GHRU] przyjmuję, że koszt wyliczenia zapytania qi na podstawiezmaterializowanej perspektywy mvj jest proporcjonalny do liczby komórek mvj , które należyprzetworzyć (tzw. liniowy model kosztów).

1.8.1. Relacja obliczalności

Zdefiniujmy najpierw relację obliczalności qi � mvj , mówiącą, że zapytanie qi może zo-stać wyliczone na podstawie perspektywy mvj . Zapytanie qi jest wyliczalne w oparciu operspektywę mvj , jeśli wszystkie atrybuty używane w grupowaniu zapytania są nie mniejzagregowane, niż odpowiadające im atrybuty perspektywy, czyli dla każdego wymiaru Dk

zachodzi aqk ≤i amv

k , gdzie aqk ∈ groupby(qi), amv

k ∈ groupby(mvj) oraz aqk, a

mvk ∈ Dk.

13

1.8.2. Koszt wyliczenia zapytania

Koszt wyliczenia zapytania qi na podstawie perspektywy mvj będę oznaczał przezcost(qi,mvj). Jeśli zapytanie qi jest obliczalne w oparciu o perspektywę mvj i where(qi) = ∅lub wyrażenie where zapytania jest niepuste, ale nie możemy użyć indeksów do wybraniaodpowiednich komórek, to przyjmujemy koszt wyliczenia cost(qi,mvj) = |mvj |.Jeśli warunek where zapytania nie jest pusty, to można wykorzystać indeksy do przyspie-

szenia wykonania zapytania – jeśli atrybuty a1, a2, . . . ∈ where(qi) tworzą prefiks jednegoz indeksów na perspektywie, to możemy użyć indeksu do selekcji tylko wybranych wartościtych atrybutów. Zakładając równomierny rozkład wartości (jak ma to miejsce w [GHRU]),otrzymujemy dla każdego takiego atrybutu a przyspieszenie o czynnik 1

|a| .Jeśli zapytanie qi nie jest obliczalne w oparciu o perspektywę mvj , to przyjmujemy koszt

wyliczenia +∞.

1.8.3. Przykład

Weźmy perspektywę mv, dla której groupby(mv) = {rok, klient, ALLdostawca, typ} z in-deksami (klient, typ) i (typ, rok, klient). Rozmiarmv to |mv| = 4∗500∗1∗50 = 105 komórek.Zgodnie z przyjętym założeniem, rozmiar indeksu to również 105, stąd łączny rozmiar per-spektywy i obydwu indeksów to 3 ∗ 105.Przeanalizujmy możliwość użycia mv do wyliczenia zapytań q1:

SELECT sum(sprzedaż)FROM mvGROUP BY dostawca, rokWHERE rok = 2003 ;

q2:

SELECT sum(sprzedaż)FROM kostkaGROUP BY [region klienta], rok, typ;

i q3:

SELECT sum(sprzedaż)FROM kostkaGROUP BY [region klienta], rok, typWHERE typ = ’żelazko’and [region klienta]=’Europe CE’and rok = 2002;

Nie możemy użyć perspektywymv do wyliczenia zapytania q1, ponieważ dostawca >dostawca

ALLdostawca, stąd q1 � mv i, zgodnie z założeniem, przyjmujemy cost(q1,mv) = +∞. Za-chodzi natomiast q2 � mv oraz q3 � mv. Dla zapytania q2 mamy where(q2) = ∅, stąd niemożemy użyć indeksu do przyspieszenia wykonania zapytania. Koszt wykonania q2 wynosicost(q2,mv) = |mv| = 105. W przypadku zapytania q3, atrybuty typ i rok stanowią prefiksindeksu i2, więc możemy skorzystać z tego indeksu do ograniczenia liczby przetwarzanychkomórek, a w rezultacie do przyspieszenia wykonywania zapytania. Stąd otrzymujemycost(q3,mv) = 105 ∗ 1

|rok| ∗1

|typ| = 500. Jak widzimy, użycie indeksu przyspieszyło ewaluacjęzapytania q3 200 razy.

14

1.9. Sformułowanie problemu

W niniejszej pracy zajmuję się problemem wyboru perspektyw do zmaterializowania orazindeksów na nich, które optymalizują czas wykonania zadanego zestawu zapytań z wagamiprzy zadanym ograniczeniu na przestrzeń używaną dyskową. Formalnie, dla zadanego zbioruzapytań

Q = {q1, . . . , qn},

szukamy zbioru perspektywMV = {mv1, . . . ,mvk}

oraz indeksówI = {i1,1, . . . , i1,k1 , . . . , ik,kk

},

które minimalizują wartość:

cost(Q,MV ) =n∑

i=1

wi ∗minj=1...k(cost(qi,mvj)).

1.9.1. Problem NP-zupełny

W pracy [Gup97] jest przedstawiony dowód na NP-zupełność powyższego problemu.Mimo, że problem można sprowadzić do problemu, dla którego istnieją dobre implemen-tacje rozwiązań wyczerpujących, dla dużych (produkcyjnych) danych wejściowych stosuje sięprzede wszystkim techniki heurystyczne.Jednym ze stosowanych podejść jest heurystyczne ograniczenie przeszukiwanej przestrzeni

rozwiązań, a następnie przeanalizowania wszystkich pozostałych rozwiązań np. [LSTV99],[TS99], [TS97], [BPT97].W pracy [Fei96] udowodniono, że nie możemy rozwiązywać problemów NP-zupełnych z

dokładnością lepszą od pewnego czynnika przy pomocy algorytmów działających w czasiewielomianowym (o ile P 6= NP). W pewnych przypadkach, możemy udowodnić, że algorytmyzachłanne uzyskują rozwiązania o jakości nie gorszej od wynikającej z tego czynnika (szczegółynp. w [Gup97]).

1.9.2. Algorytmy zachłanne

Standardowy algorytm zachłanny służący do wyboru (przedstawiony np. w [Gup97]) zo-stał przedstawiony poniżej:

MV = ∅dopóki można dodawać

wybierz perspektywę mv o najwyższym współczynnikucost(Q,MV )−cost(Q,MV ∪{mv})

|mv|MV = MV ∪mv

W każdym kroku algorytmu dodawana jest perspektywa mv posiadająca najkorzystniejszystosunek poprawy szybkości działania systemu po dodaniu mv do wielkości |mv|.Powyższy algorytm dokonuje wyboru perspektyw do zmaterializowania, nie wybiera na-

tomiast indeksów. Wybór indeksów może nastąpić jednocześnie z wyborem perspektyw lubmożemy najpierw wybrać perspektywy (np. przeznaczyć połowę dostępnej przestrzeni dys-kowej na perspektywy a resztę na indeksy) a następnie indeksy. Pierwsze podejście daje

15

zdecydowanie lepsze rezultaty (dyskusja m.in. w [GHRU]), gdyż nie musimy z góry decydo-wać, ile jaką część dostępnej przestrzeni przeznaczamy na indeksy. Standardowy algorytmzachłanny rozszerzony o wybór indeksów ma następującą postać (zobacz [Gup97], [GHRU]):

MV = ∅Indeksy = ∅dopóki można dodawać

wybierz perspektywę mvlub indeks i o najwyższym współczynnikuprzyspieszenie działania systemu do wielkościdodaj mv do MV lub i do Indeksy

Zauważmy, że takie postępowanie może łatwo doprowadzić do wygenerowania sub-optymalnego rozwiązania. Załóżmy, że mamy 3 możliwe perspektywy do dodania mv1, mv2

i mv3 o rozmiarach odpowiednio 101, 100 i 100 oraz o współczynniku przyspieszenia działa-nia systemu 203, 200 i 200. Jeśli będziemy mieli tylko 200 jednostek dostępnej przestrzenidyskowej, to możemy wybrać albo mv1 albo mv2 i mv3, uzyskując w pierwszym przypadkuzysk 203, a w drugim 400. Niestety, algorytm zachłanny wybierze w tym przypadku mv1.W niektórych pracach (np. [SDN98]) kładziono nacisk na konieczność modyfikacji stan-

dardowych algorytmów zachłannych w celu ograniczenia rozpatrywanej przestrzeni rozwiązań(ze względów wydajnościowych).

1.9.3. Inne rozwiązania

Zaproponowano kilka interesujących, niedeterministycznych alternatyw dla algorytmuzachłannego. Opierają się one o mechanizmy stosowane w sztucznej inteligencji, np. symu-lowane wyżarzanie, metodę A* lub algorytmy genetyczne. Moja praca jest rozszerzeniemkoncepcji użycia algorytmów genetycznych do wyboru zbioru perspektyw do zmaterializowa-nia, zaprezentowanej w [LH99].

16

Rozdział 2

Algorytmy genetycznei programowanie ewolucyjne

Algorytmy genetyczne są metodą rozwiązywania zadań optymalizacyjnych za pomocą me-chanizmów naśladujących ewolucję. W tym celu wyodrębniamy składowe rozwiązania, zapi-sujemy je w postaci binarnej a następnie przy pomocy odpowiedników dziedziczenia, mutacjioraz naturalnej selekcji lepiej przystosowanych osobników staramy się otrzymać rozwiązaniebliskie optymalnemu.

Autorem idei użycia mechanizmów naśladujących ewolucję w informatyce był John Hol-land, który w latach sześćdziesiątych prowadził badania dotyczące systemów adaptacyjnych.Od tego czasu algorytmy genetyczne były z powodzeniem stosowane do bardzo szerokiego za-kresu zagadnień, począwszy od stricte informatycznych, m.in. optymalizacji zapytań do bazydanych [BFI91] i [SS96], przez systemy służących do sterowania pracą gazociągu (rozprawadoktorska Davida Goldberga, autora [Gold]), aż do systemu służącego do ustalania szkolnegoplanu zajęć, opisanego w [ST01].

W standardowej wersji algorytmu genetycznego, potencjalne rozwiązania są zapisywanejako ciągi bitów (oznaczających występowanie lub niewystępowanie poszczególnych składo-wych rozwiązania). Do standardowych operacji należą mutacja, polegająca na zmianie war-tości jednego z bitów na przeciwną, oraz krzyżowania, polegające na wymianie podciągówbitów. W starszych pracach (np. [Gold]), traktowano mutację jako operację drugorzędną.Obecnie (np. [Mic03], [Sp98]) docenia się jej rolę w procesie zapewniania różnorodności orazzdolności adaptacyjnych populacji.

Bardziej zaawansowane rozwiązania, dopuszczające zakodowanie rozwiązania w sposóbzależny od problemu oraz dodatkowe operacje nazywamy programowaniem ewolucyjnym.Szczegółowy opis tematyki algorytmów genetycznych i programowania ewolucyjnego znajdujesię m.in. w [Mic03], [Gold], [Ko92], [Mit98]. Zarówno standardowe algorytmy genetyczne jaki techniki programowania ewolucyjnego zostaną omówione w kolejnych sekcjach.

2.1. Podstawowe definicje

Terminologia wykorzystywana do opisu algorytmów genetycznych z oczywistych względównawiązuje do odpowiednich sformułowań biologicznych. Poniżej znajdują się definicje pojęćwykorzystywanych do opisu algorytmów genetycznych oraz mojego rozwiązania.

17

2.1.1. Gen

Gen odpowiada elementarnej składowej rozwiązania optymalizowanego zagadnienia. W naj-prostszej wersji może być bitem oznaczającym występowanie lub niewystępowanie pewnej ce-chy. W bardziej zaawansowanych rozwiązaniach może być reprezentowany np. przy pomocystruktury opisującej stan danej cechy. Dopuszczalne wartości (odmiany) genu nazywamy al-lelami. W najprostszej wersji (binarna reprezentacja) każdy gen ma 2 allele o wartościachodpowiednio 0 i 1.W systemach adaptujących się do zmieniających się warunków można stosować mecha-

nizm genów recesywnych, czyli ujawniających się tylko w pewnych warunkach (zobacz po-liploidalność w opisie chromosomu). Jest to szczególnie przydatne do “zapamiętywania”rozwiązań, które sprawdziły się w przeszłości i mogą być użyteczne, jeśli warunki ponownieosiągną zbliżone wartości. Zastosowanie algorytmów genetycznych do systemów adaptacyj-nych zostało opisane m.in. w [Scha], [Sm98], [DeJ75].Gen kodujący i-tą cechę będę oznaczał przez gi, a jego odmiany (allele) przez a1

i , . . . , akii .

2.1.2. Chromosom

Chromosom reprezentuje potencjalne rozwiązanie problemu, który chcemy optymalizo-wać. Chromosom może posiadać pojedynczy zestaw genów (tzn. po jednym genie repre-zentującym daną cechę), mówimy wtedy o chromosomie monoidalnym, lub kilka zestawówgenów, z których jeden jest uznawany za nadrzędny i wykorzystywany, a pozostałe są genamirecesywnymi i mogą być wykorzystane jedynie wtedy, gdy nie będą przesłaniane przez genyo wyższym priorytecie. W drugim przypadku mówimy o poliploidalnym zestawie genów.W genetyce, gen (poza pełnioną funkcją) ma przypisaną pozycję (locus) w chromosomie.

W algorytmach genetycznych często pomija się tą cechę, ponieważ gen występuje z reguły naz góry ustalonym miejscu w reprezentacji chromosomu – np. przy reprezentacji chromosomujako tablicy genów, gen kodujący daną cechę będzie zawsze występował pod ustalonym in-deksem. Jeśli dopuszczamy chromosomy o zmiennej długości lub złożonej strukturze, należyumożliwić identyfikację pozycji genu w chromosomie, np. poprzez nadanie genom identyfika-torów.Chromosom będę reprezentował jako ciąg genów:

chi = (g1, . . . , gk).

2.1.3. Populacja

Grupa chromosomów rozważanych w danym momencie. Część z nich jest wybierana dooperacji krzyżowania lub mutacji oraz do budowy nowej populacji (nowego pokolenia). Wniektórych zastosowaniach przydatne jest utrzymywanie kilku małych populacji (nazywanychpodpopulacjami lub wspólnotami) i wymiana chromosomów pomiędzy nimi. Dokładny opisw dalszej części. Model algorytmu genetycznego z podpopulacjami został opisany m.in. w[Mic03] oraz [SVM].Populacja może mieć stały, z góry ustalony rozmiar lub może zmieniać swoją liczebność w

trakcie działania algorytmu. W drugim przypadku często stosuje się przypisywanie poszcze-gólnym chromosomom maksymalnego wieku, na podstawie wartości funkcji oceny. W takimprzypadku ważny jest odpowiedni dobór metody przydzielania wieku dla chromosomów, po-nieważ łatwo można osiągnąć wykładniczy wzrost liczebności populacji. Szczegóły dotyczącedobierania wielkości populacji można znaleźć m.in. w pracach [Khan], [EMV04], [EHM99].

18

Z punktu widzenia jakości rozwiązania i wydajności algorytmu genetycznego istotne jest,aby populacja umożliwiała osiągnięcie kompromisu pomiędzy utrzymywaniem różnorodno-ści chromosomów (dla zwiększenia prawdopodobieństwa znalezienia dobrego rozwiązania) aszybką zbieżnością do potencjalnie dobrych rozwiązań.Populację w momencie t (pokolenie numer t) będę reprezentował jako multizbiór chromo-

somów:P (t) = {ch1, . . . , chn}.

2.1.4. Funkcja oceny

Funkcja odpowiadająca doborowi naturalnemu. Służy do oceny jakości poszczególnychchromosomów jako rozwiązań optymalizowanego problemu.Chromosomy niespełniające ustalonych wymagań (np. zadane ograniczenie w proble-

mie optymalizacyjnym) mogą być eliminowane, naprawiane (tzn. przekształcane tak, abyspełniały stawiane im wymagania) lub karane. W ostatnim przypadku należy zdefiniowaćfunkcję kary, odpowiadającą za modyfikowanie funkcji oceny w oparciu o stopień naruszeniawymagań.Wartość funkcji oceny oraz funkcji kary dla chromosomu chi będę zapisywał odpowiednio

jako f(chi) oraz k(chi).Możemy zawsze założyć, że sumaryczna wartość f(ch)+k(ch) jest nieujemna i że chcemy

tę wartość maksymalizować. Jeśli funkcja oceny zwraca wartości ujemne, możemy skonstru-ować nową funkcję

f(ch) = f(ch) + A,

gdzie stała A jest większa od wszystkich możliwych wartości |f(ch)| w badanym zakresie.Jeśli staramy się minimalizować wartość danej funkcji f , za funkcję oceny możemy przyjąć

f(ch) = −f(ch)

i maksymalizować f .

2.1.5. Strategia wyboru

Strategia wyboru to mechanizm służący do tworzenia nowego pokolenia P (t + 1) na pod-stawie starego P (t), w oparciu o funkcję oceny i funkcję kary. Odpowiednia reguła wyboruma kluczowe znaczenie dla uzyskania wymaganego kompromisu pomiędzy utrzymaniem róż-norodności populacji (czyli unikaniem zbieżności do lokalnego minimum) a szybkością znaj-dowania dobrych rozwiązań. W literaturze opisano wiele strategii wyboru chromosomów dopopulacji, kilka najpopularniejszych opisałem poniżej. Szczegółowy opis oraz analiza tych iinnych strategii można znaleźć np. w [Gold], [Mic03], [BB03], [DeJ75], [Mit98].W opisie poszczególnych strategii będę korzystał z sumarycznej wartości chromosomów

w populacji:C =

∑ch∈P (t)

(f(ch) + k(ch))

oraz z wartości oczekiwanej egzemplarzy danego chromosomu, wynikającej z jego wartości:

c(ch) =f(ch) + k(ch)

C∗ n,

gdzie n, to docelowa liczba chromosomów w nowym pokoleniu, |P (t + 1)| = n.

19

Rysunek 2.1: Ruletka z naniesionymi obszarami dla poszczególnych chromosomów.

Próbkowanie deterministyczne

Najprostsza strategia wyboru to deterministyczne stworzenie nowego pokolenia z najsil-niejszych chromosomów (w sensie najwyższej wartości funkcji oceny, być może po uwzględ-nieniu funkcji kary) starego pokolenia. Każdy chromosom ch jest dodawany w takiej liczbieegzemplarzy, jaka wynika z jego wartości c(ch).Takie postępowanie umożliwia uzyskanie dużej wydajności, jednak jest bardzo podatne

na zbieżność do lokalnego optimum optymalizowanego zagadnienia. Stąd, taka strategiajest użyteczna jedynie dla problemów jednomodalnych (tzn. posiadających jedynie jedno,globalne, optimum). W przypadku problemów wielomodalnych (tzn. posiadających wielelokalnych optimów, dotyczy to większości optymalizowanych problemów), takie postępowanienie sprawdza się.

Strategia ruletki

W strategii ruletki dzielimy obwód ruletki na |P (t)| obszarów. i-ty obszar ma rozmiarc(chi), stąd łączna rozmiar ruletki to C. Następnie “obracamy” ruletką n razy w celu wy-losowania chromosomów do nowego pokolenia. Oczekiwana liczba egzemplarzy chromosomuchi w nowym pokoleniu to c(chi), podobnie jak w strategii wyboru silniejszych, ale, dziękiniedeterminizmowi, jest szansa na przekazanie do kolejnego pokolenia również pewnej liczbysłabszych chromosomów, co pozytywnie wpływa na różnorodność populacji i unikanie ugrzęź-nięcia w lokalnym optimum. Przykładowa “ruletka” została przedstawiona na Rys. 2.1.

Stochastyczne próbkowanie na podstawie reszty bez zamiany

Ta strategia łączy cechy próbkowania deterministycznego oraz reguły ruletki. Do nowegopokolenia dodajemy taką liczbę egzemplarzy chromosomu ch, jaka wynika z części całko-witej wartości oczekiwanej jego egzemplarzy, czyli bc(ch)c. Pozostałe n −

∑ch∈P (t)bc(ch)c

wolnych miejsc jest uzupełniane niedeterministycznie przy pomocy ruletki. Obszar ruletkiodpowiadający chromosomowi ch ma rozmiar c(ch)− bc(ch)c.Takie postępowanie zapewnia zachowanie najlepszych rozwiązań w populacji, dając jed-

nocześnie szanse na przetrwanie innym osobnikom, a przez to zwiększając różnorodność po-pulacji. Wyniki eksperymentalne pokazują, że ta strategia postępowania daje dobre wyniki

20

dla najszerszego obszaru zagadnień.

Turnieje stochastyczne

Strategia turnieju stochastycznego polega na losowaniu kilku (np. 2) chromosomów zpopulacji i wybieraniu lepiej przystosowanego z nich do dodania do nowego pokolenia. Procesnależy powtórzyć aż do zapełnienia wszystkich miejsc w nowym pokoleniu. Istnieją licznemodyfikacje powyższej reguły, uwzględniające m.in. wagi, oznaczające prawdopodobieństwowylosowania poszczególnych chromosomów.

2.1.6. Parametry algorytmu genetycznego

Do parametrów sterujących algorytmem genetycznym należą:

• prawdopodobieństwo krzyżowania,

• prawdopodobieństwo mutacji,

• współczynnik wymiany pokoleń,

• wielkość populacji,

• warunek zakończenia (np. maksymalna liczba pokoleń).

W standardowej wersji algorytmów genetycznych parametry są ustalane z góry dla danejinstancji algorytmu. Istnieją również wersje algorytmów genetycznych z parametrami dosto-sowywanymi podczas działania algorytmu, np. [BRV00], [EHM99], [TC02].

2.2. Schemat działania algorytmu genetycznego

Po zdefiniowaniu podstawowych pojęć możemy przedstawić schemat działania algorytmugenetycznego.Działanie algorytmu rozpoczyna się od wygenerowania początkowej populacji. Chromo-

somy mogą zostać wygenerowane losowo. Aby poprawić jakość tworzonej losowo populacjimożemy wygenerować k∗n chromosomów (gdzie n to docelowa liczność populacji a k to pewnastała, np. 4), a następnie rozgrywać turnieje i wybierać najlepszy z każdej grupy k chromo-somów. Populacja początkowa może być również wygenerowana przez inny znany algorytmsłużący do rozwiązywania tego problemu (wtedy wykorzystujemy algorytm genetyczny doulepszenia posiadanego rozwiązania).Następnie wykonujemy operacje mutacji i krzyżowania, oceniamy bieżącą populację oraz

tworzymy kolejne pokolenia zgodnie z przyjętą strategią. Warunkiem końcowym może byćm.in. osiągnięcie pewnej liczby pokoleń, upłynięcie zadanego czasu lub uzyskanie rozwiązaniaspełniającego zadane warunki.

Stwórz P(1)t = 1

dopóki nie warunek końcowyoceń chromosomy z P(t)dokonaj mutacji i krzyżowania w P(t)zbuduj P(t+1) na podstawie P(t)t = t + 1

21

Chromosom Geny x f(x) f(x)ch1 011001001111 1.615 2.597 3.403ch2 010011101101 1.261 0.744 5.256ch3 110000110000 -0.976 0.046 5.954ch4 101010110111 -1.353 -1.124 7.124ch5 001011001100 0.716 -0.349 6.349ch6 110110011000 -0.616 0.382 5.618

Tablica 2.1: Początkowa populacja (wygenerowana losowo). Funkcja f(ch) przyjmuje warto-ści z przedziału [−6, 6]. Strategie wyboru nowego pokolenia wymagają, aby poszukiwanymoptimum było maksimum, a funkcja oceny przyjmowała wartości nieujemne, stąd optymali-zujemy funkcję f(ch) = 6− f(ch).

Rodzice Krzyżowanie Dzieci

11 0000110000 11 1010110111−→

10 1010110111 10 0000110000

Rysunek 2.2: Krzyżowanie chromosomów ch3 i ch4 z tabeli 2.1 na pozycji 3. W wynikuotrzymujemy chromosomy ch7 i ch8.

2.3. Przykład

Załóżmy, że chcemy znaleźć wartość zmiennej x (z dokładnością do 0.001), dla którejfunkcja f(x) = x3 − x osiąga minimum w przedziale [−2, 2]. Funkcja f przyjmuje zarównowartości dodatnie jak i ujemne, dlatego za funkcję oceny przyjmujemy funkcję f(x) = 6−f(x),której wartość będziemy się starali zmaksymalizować (zobacz 2.1.4).W przedziale [−2, 2] mamy 4000 możliwych wartości zmiennej x, stąd jako chromosomów

możemy użyć ciągów złożonych z 12 bitów (genów). Możemy przyjąć, że chromosom repre-zentuje zapis liczby x w kodzie uzupełnieniowym do 2, podzielony przez 1000. Chromosomyodpowiadające wartościom wykraczającym poza przedział [−2, 2] będziemy eliminowali, jakoniepoprawne. Operacje mutacji i krzyżowania będą odpowiednio zamieniały losowy bit wchromosomie na przeciwny oraz dzieliły 2 chromosomy w losowym miejscu i zamieniały pod-ciągi. Niech prawdopodobieństwa mutacji oraz krzyżowania wynoszą odpowiednio 0.01 i 0.3.Zauważmy, że istnieje wiele innych sposobów reprezentacji chromosomów, nawet dla tak

prostego problemu – np. moglibyśmy przeznaczyć część bitów na mantysę a część na cechę iużyć reprezentacji zmiennoprzecinkowej.Początkowa populacja jest przedstawiona w tabeli 2.1. Załóżmy, że do mutacji został wy-

brany gen g5 chromosomu ch2 a do krzyżowania chromosomy ch3 i ch4, krzyżowanie nastąpiłona 3. pozycji, tworząc nowe chromosomy ch7 i ch8 (Rysunek 2.2). Następnie, zgodnie z przy-jętą strategią tworzenia nowej populacji, budujemy P (2), wybierając 6 z 8 chromosomów zpokolenia P (1). Sumaryczna wartość 8 chromosomów wynosi C = 51.834. W tabeli 2.2 ze-brano wartości c(ch) dla poszczególnych chromosomów (wykorzystywane w strategii ruletki).Dla stochastycznego próbkowania na podstawie reszt z zamianą, używamy wartości bc(ch)coraz c(ch)−bc(ch)c odpowiednio dla wartości oczekiwanej liczby egzemplarzy chromosomu ifragmentu ruletki służącej do obsadzenia pozostałych miejsc w populacji.

22

Chromosom Geny x f(x) f(x) c(ch)ch1 011001001111 1.615 2.597 3.403 0.4ch2 010001101101 1.133 0.321 5.679 0.66ch3 110000110000 -0.976 0.046 5.954 0.69ch4 101010110111 -1.353 -1.124 7.124 0.82ch5 001011001100 0.716 -0.349 6.349 0.73ch6 110110011000 -0.616 0.382 5.618 0.65ch7 111010110111 -0.329 0.293 5.707 0.66ch8 100000110000 -2.000 -6 12 1.39

Tablica 2.2: Populacja przed wybraniem chromosomów do 2. pokolenia. Dodano nowechromosomy ch7 i ch8.

2.4. Schematy

Załóżmy, że do reprezentowania chromosomów wykorzystujemy słowa nad alfabetem{0, 1} o ustalonej długości n. Schematem nazwiemy słowo długości n nad alfabetem {0, 1, ∗},gdzie symbol ∗ może zastąpić 0 lub 1 z odpowiedniego słowa reprezentującego chromosom.Przykładowo, schemat 01 ∗ ∗0 reprezentuje chromosomy 01000, 01010, 01100 oraz 01110.Istnieją twierdzenia oraz wzory pozwalające na modelowanie przetrwania i rozprze-strzeniania poszczególnych schematów w populacji. Szczegółowy opis można znaleźć m.in. w[Gold] oraz [Mic03].

2.5. Techniki programowania ewolucyjnego

Standardowa wersja algorytmu genetycznego obejmuje zakodowanie potencjalnych roz-wiązań badanego problemu jako ciągów 0-1, będących wektorami charakterystycznymi dladanych zestawów cech rozwiązania. Te wektory są następnie poddawane operacjom muta-cji i krzyżowania, które odpowiadają odpowiednio zamianie wybranego bitu na przeciwnyoraz wymianie podciągów pomiędzy chromosomów. Ten ogólny schemat postępowania jestparametryzowany funkcją oceny, prawdopodobieństwem użycia operacji oraz warunkiem za-kończenia.W pewnych przypadkach stosowanie powyższego schematu może się okazać problema-

tyczne, m.in. ze względu na wydajność, przedwczesną zbieżność lub problem z zakodowaniemproblemu jako wektora 0–1 i wykonywania operacji jako operacji na ciągach bitów (np. jeśliistnieją pewne zależności pomiędzy poszczególnymi parametrami rozwiązania lub rozwiąza-nie ma skomplikowaną strukturę). W takim wypadku możemy zastosować rozszerzoną wersjęalgorytmów genetycznych, nazywaną programowaniem ewolucyjnym (zobacz np. [Mic03]), wktórej do reprezentacji problemu wykorzystuje się bardziej skomplikowane, specyficzne dladanego problemu, struktury i operacje na nich.W przypadku systemów adaptacyjnych możemy stosować kilka zestawów genów dla każ-

dego chromosomu (poliploidalność), z których tylko jeden jest wykorzystywany w danymmomencie (gen dominujący), a pozostałe (geny recesywne) nie ujawniają się. Takie postę-powanie umożliwia “zapamiętywanie” w chromosomie rozwiązań, które okazały się dobre wprzeszłości i mogą być ponownie przydatne w przyszłości.Kilka przydatnych technik programowania ewolucyjnego zostało opisane w kolejnych sek-

cjach. Wszystkie służą przede wszystkim utrzymywaniu zróżnicowania populacji.

23

2.5.1. Gatunki i nisze

Przez analogię do ewolucji naturalnej możemy wprowadzić odpowiedniki gatunków i niszekologicznych. Przez gatunek będziemy rozumieli zbiór osobników (chromosomów), które sądo siebie w pewien sposób podobne (np. mają pewne cechy wspólne). Jeśli dopuścimy krzy-żowanie tylko pomiędzy osobnikami jednego gatunku, to zmniejszymy prawdopodobieństwozdominowania populacji przez rozwiązania skoncentrowane wokół jednego lokalnego optimum.W zamian, uzyskamy grupy osobników skupionych w niszach, reprezentujących różne lokalneoptima. Dodatkowo, możemy np. zmodyfikować funkcję oceny, aby zmniejszała się, gdy wdanej niszy przybywa osobników. W ten sposób uzyskamy mechanizm równoważący liczbęosobników w poszczególnych niszach i utrudniający dominację jednego rozwiązania.

2.5.2. Zmieniające się parametry

Parametry sterujące algorytmem genetycznym mogą być ustalone na początku działa-nia, mogą się zmieniać zgodnie z zadaną funkcją lub być regulowane automatycznie podczasdziałania algorytmu.Zauważmy, że w pierwszej fazie działania algorytmu genetycznego kluczowym czynni-

kiem jest utrzymanie zróżnicowania populacji (aby nie zniszczyć zbyt wcześnie potencjalniedobrych rozwiązań). W drugiej fazie, chcielibyśmy możliwie zoptymalizować otrzymane roz-wiązania. Dlatego interesującym pomysłem jest używanie funkcji (zależnych od czasu, czylinumeru kolejnego pokolenia), które modyfikują działanie algorytmu. Przykładowo, z czasemmożemy zwiększać rolę funkcji kary, aby w fazie optymalizacji usuwać błędne rozwiązania(chociaż mogły one być przydatne dla utrzymywania różnorodności populacji w pierwszejfazie działania algorytmu). Podobnie, możemy sterować parametrami dotyczącymi mutacji,krzyżowania i implementacją gatunków.Jedno z podejść (prezentowane m.in. w [Mic03]) sugeruje, aby pracą algorytmu genetycz-

nego sterował nadrzędny algorytm genetyczny (meta-algorytm genetyczny). Algorytmy gene-tyczne, w których parametry (m.in. wielkość populacji i prawdopodobieństwa występowaniaposzczególnych operacji) są dostosowywane w trakcie działania algorytmu były rozważanerównież w [EHM99], [EMV04], [Sm98].

2.5.3. Podpopulacje i wspólnoty

Kolejną metodą utrzymywania zróżnicowania populacji (opisaną m.in. w [Mic03] i [SVM])jest rezygnacja z jednej dużej populacji na rzecz grupy małych populacji (nazywanych pod-populacjami lub wspólnotami). Pomysł prezentowany w [Mic03] sugeruje, aby część two-rzonych chromosomów (np. w wyniku krzyżowania) była rozsyłana do innych wspólnot zapośrednictwem “obszaru wymiany” (schemat na rysunku 2.3). Ocena chromosomów, wybórchromosomów do poszczególnych operacji, symulacja gatunków i nisz oraz tworzenie nowegopokolenia na podstawie starego (z uwzględnieniem nowych chromosomów, pobranych z ob-szaru wymiany) odbywa się niezależnie w każdej wspólnocie.

2.6. Algorytmy genetyczne a optymalizacja hurtowni danych

W pracy [LH99] został opisany pomysł wykorzystania algorytmów genetycznych do wy-boru perspektyw do zmaterializowania w hurtowni danych. Autorzy zaproponowali, abychromosom był wektorem charakterystycznym zbioru możliwych perspektyw. Gen przyjmo-wał wartość 1, jeśli odpowiadająca mu perspektywa została wybrana do zmaterializowania

24

Rysunek 2.3: Model ze wspólnotami.

lub 0 w przeciwnym przypadku. Do wyboru nowego pokolenia zastosowano strategię ruletki.Proponowany algorytm był porównywany do algorytmu sprawdzającego wszystkie możliwerozwiązanie. Autorzy zauważyli, że w pewnych przypadkach nieznaczne przekroczenie zada-nego ograniczenia może istotnie poprawić czas wykonania zapytań.Autorzy zasugerowali kilka możliwych rozszerzeń swojej pracy, m.in. uwzględnienie in-

deksów oraz umożliwienie równoległego wykonywania obliczeń.

25

Rozdział 3

Proponowane rozwiązanie

Celem tej pracy jest zaprezentowanie rozwiązania problemu wyboru perspektyw do zmate-rializowania i indeksów w hurtowni danych przy pomocy algorytmów genetycznych. Kolejnesekcje opisują: proponowane przeze mnie rozwiązanie, szczegóły implementacyjne, zakresi wyniki wykonanych testów oraz wnioski.

3.1. Użyte techniki programowania ewolucyjnego

Postanowiłem skorzystać ze specjalnych, dedykowanych dla danego problemu strukturdanych oraz zmodyfikowanych wersji operacji na chromosomach.Dla zapewnienia różnorodności populacji postanowiłem skorzystać z technik programowa-

nia ewolucyjnego, opisanych w 2.5: gatunków i nisz, zmieniających się w czasie parametrówsterujących pracą algorytmu oraz wspólnot. Użycie wspólnot pozwoliło również na zrówno-leglenie wykonywania algorytmu.

3.1.1. Reprezentacja problemu

Do reprezentowania potencjalnych rozwiązań skorzystałem z dwupoziomowej struktury(zobacz Rys. 3.1):

gen odpowiada perspektywie; gen występuje w tylu odmianach (allelach), ile jest możliwychkombinacji indeksów dla danej perspektywy,

chromosom jest zbiorem perspektyw wybranych do zmaterializowania (wraz z indeksami,wybranymi w genach) i odpowiada kompletnemu rozwiązaniu problemu.

Ze względu na taką reprezentację problemu wyróżniłem 2 rodzaje mutacji:

zewnętrzna – polegająca na dodaniu perspektywy do rozwiązania (z pustym zbiorem in-deksów) lub usunięciu jej (z usunięciem wszystkich jej indeksów),

wewnętrzna – polegająca na dodaniu lub usunięciu indeksu z perspektywy. W przypadkudodawania indeksu następowało usuwanie zbędnych indeksów w danej perspektywie,czyli takich, które stanowiły prefiks dodanego indeksu i mogą być przez niego zastąpioneprzy wyliczaniu zapytań (zobacz 1.7 i 1.8).

Dodatkowo, wprowadziłem operację zmniejszania chromosomów, które przekraczająograniczenie dostępnej przestrzeni dyskowej o więcej niż zadany współczynnik – w takimprzypadku usuwano najmniej potrzebne perspektywy spośród kilku (wybranych niedetermi-nistycznie) kandydatów.

27

Rysunek 3.1: Chromosom i gen.

3.1.2. Wspólnoty

Zdecydowałem się na użycie mechanizmu wspólnot (szczegóły w 2.5.3). Ocena rozwiąza-nia, operacje mutacji i krzyżowania oraz wybór chromosomów do kolejnego pokolenia odbywasię niezależnie w każdej wspólnocie. Wymiana chromosomów pomiędzy wspólnotami odbywasię za pośrednictwem “obszaru wymiany”. Schemat działania wspólnoty jest przedstawionyponiżej. Jak widać, różni się on od schematu działania standardowego algorytmu gene-tycznego jedynie fragmentami związanymi z pobieraniem chromosomów z obszaru wymianyi umieszczaniem tam części chromosomów stworzonych podczas krzyżowania.

Stwórz P(1)t = 1

dopóki nie warunek końcowypobierz chromosomy z obszaru wymiany do P(t)dokonaj mutacji i krzyżowania w P(t)umieść część chromosomów z krzyżowania w obszarze wymianyoceń chromosomy z P(t)zbuduj P(t+1) na podstawie P(t)t = t + 1

Wprowadziłem 2 rodzaje wspólnot chromosomów: o stałym i o zmiennym rozmiarze. Im-plementacje obydwu wspólnot różnią się wyłącznie treścią metody tworzącej nowe pokolenie.Wspólnota o stałym rozmiarze wykorzystywała stochastyczne próbkowanie na podstawie

reszty (opis różnych strategii wyboru w 2.1.5) do budowania kolejnych pokoleń chromosomów.W przypadku wspólnoty o zmiennym rozmiarze, każdy chromosom miał przypisywany

wiek, określający, przez ile pokoleń chromosom będzie “żył” w populacji. Wiek był ustalanyna podstawie wartości funkcji oceny i funkcji kary dla chromosomu. Po pierwszych testachpostanowiłem dodać mały czynnik niedeterministyczny, umożliwiający przeżycie słabszymchromosomom i, w konsekwencji, utrzymywanie różnorodności populacji.

28

Pierwsze testy wykazały, że wspólnoty o stałym rozmiarze łatwiej i szybciej znajdowałylokalne optimum, były też podatniejsze na zdominowanie przez jedno rozwiązanie. Wspól-noty o zmiennym rozmiarze przez dłuższy czas zachowywały różnorodność populacji. Najlep-sze wyniki uzyskiwały konfiguracje zawierające obydwa typy wspólnot – wspólnoty o stałymrozmiarze eksplorowały lokalne optima a wspólnoty o zmiennym rozmiarze dostarczały różno-rodnych chromosomów, umożliwiając w efekcie przeszukiwanie szerszego zakresu rozwiązań.Z tego powodu w końcowych testach skoncentrowałem się na połączeniach obydwu typówwspólnot.Przyjąłem, że współczynnik wymiany pomiędzy wspólnotami (czyli procent stworzonych

chromosomów, które są przekazywane do wspólnej puli) powinien być wyższy odprawdopodobieństwa mutacji, ale nie powinien powodować przekazywania więcej niż kilkuprocent chromosomów do innych wspólnot. W ten sposób planowałem “indukować” zmianyw innych wspólnotach bez ryzyka zbyt łatwego zdominowania ich przez jedno rozwiązanie.To założenie potwierdziło się w wykonanych testach.

3.1.3. Funkcje oceny i kary

Funkcja oceny chromosomu uwzględniała wartość rozwiązania, wynikającą z czasu wy-konywania zadanego zestawu zapytań oraz z ewentualnej kary wynikającej z przekroczeniazadanego ograniczenia dostępnej przestrzeni dyskowej.Za podstawową składową oceny potencjalnego rozwiązaniaMV przyjąłem czas wyliczenia

zadanego zestawu zapytań Q wynoszący cost(Q,MV ).Przyjmijmy, że rozwiązania składające się wyłącznie z podstawowej kostki MVbase ma

rozmiar |MVbase| i czas wyliczenia zapytań cost(Q,MVbase) oraz że zadane ograniczenie nadostępną przestrzeń dyskową to MVmax a maksymalny dopuszczalny numer pokolenia totmax. Możemy zapisać składową funkcji kary, wynikającą z przekroczenia rozmiaru, jako:

p(MV ) =

{|MV |−|MVmax|

MVmaxgdy |MV | > |MVmax|

0 wpp

Następnie wyliczałem wartość funkcji kary jako:

p(MV ) = p(MV ) ∗ (0.4 +t

tmax).

Wartość 0.4 oraz liniowa zależność wartości funkcji kary zostały dobrane eksperymentalnie.Jeśli p(MV ) > 1, to przyjmowałem p(MV ) = 1.Ostateczna wartość rozwiązania MV wynosiła:

f(MV ) = (cost(Q,MVbase − cost(Q,MV )) ∗ (1− (p(MV ))2).

Kwadratowa zależność ostatecznej oceny chromosomu od wartości funkcji kary została rów-nież dobrana eksperymentalnie. Zauważmy, że tak skonstruowana funkcja f przyjmuje zawszewartości nieujemne oraz daje wyższe wartości dla lepiej przystosowanych chromosomów, stądmoże być użyta w procesie tworzenia nowego pokolenia.

3.2. Implementacja

Prototyp proponowanego rozwiązania został zaimplementowany w języku Java, przy wy-korzystaniu środowiska Eclipse (w tym wtyczki JMechanic Profiler, służącej do profilowania

29

Rysunek 3.2: Środowisko testowe

aplikacji). Dla testów porównawczych zaimplementowałem również algorytm zachłanny opi-sany w [GHRU] oraz algorytm genetyczny (bez wyboru indeksów) z [LH99]. Stworzyłemrównież proste środowisko służące do zarządzania wykonywanymi testami, generowania pa-rametrów dla algorytmu oraz zbierania i przetwarzania wyników.System został zaprojektowany w taki sposób, aby możliwie mała jego część zależała od

problemu i sposobu jego reprezentacji. Jak widać na przedstawionych poniżej diagramachUML, jedynie implementacja genu jest zależna od rozwiązywanego problemu i po jej pod-mianie można byłoby wykorzystać dużą część systemu do zupełnie innych zadań. Dziękimodularnej budowie można łatwo zmienić model kosztów używany do oceny jakości rozwią-zań. W celu przyspieszenia działania prototypu zastosowałem m.in. leniwe wyliczanie orazspamiętywanie częściowych wyników. Pozwoliło to na znaczne ograniczenie liczby wykony-wanych operacji.

3.3. Wyniki

Testy zostały przeprowadzone na komputerze klasy PC z procesorem Intel Celeron 2GHz i512 MB pamięci operacyjnej, działającym pod kontrolą systemu Windows XP. Dla zasymulo-wania równoległego działania wspólnot, dodałem mechanizmy powodujące częste zwalnianieprocesora przez wątki wspólnot. Bez takiej wymuszonej współbieżności mechanizm wymie-niania chromosomów pomiędzy wspólnotami nie dawałby oczekiwanych rezultatów.Każdy algorytm miał ustalony górny limit 6 minut na czas wykonania. Przeciętny czas

działania wahał się od 1 do 3 minut. Podczas wstępnych testów zauważyłem, że zbieżnośćbyła osiągana w znacznej większości przypadków podczas pierwszych 30 – 40 pokoleń i dalszeprzetwarzanie nie poprawiało już osiągniętego wyniku, dlatego ograniczyłem liczbę pokoleń

30

Rysunek 3.3: Model hurtowni danych

Rysunek 3.4: Proponowany algorytm

31

symulowanych przez proponowany algorytm do 50. Każdy test był powtarzany minimumpięcioktrotnie. Interesował mnie najlepszy oraz średni wynik.Danymi wejściowymi do testów była przykładowa hurtownia danych opisana w 1.4. Każdy

algorytm był testowany dla małej, średniej oraz dużej dostępnej przestrzeni dyskowej. Wszyst-kie algorytmy miały możliwość przekroczenia (w uzasadnionym przypadku) tego ograni-czenia, jednak nie więcej niż o 10%. Z powodu nieuwzględniania indeksów, wyniki algorytmuprzedstawionego w [LH99] są o kilka rzędów wielkości gorsze od wyników uzyskanych przezpozostałe algorytmy dla większej ilości dostępnej przestrzeni dyskowej.Interesowało mnie przede wszystkim sprawdzenie, czy pewne konfiguracje proponowanego

przeze mnie rozwiązania dają częściej dobre rozwiązania niż inne. Interesują mnie zarównonajlepsze jak i średnie wyniki uzyskane przy każdej konfiguracji. Przez konfigurację rozumiemliczbę używanych wspólnot, prawdopodobieństwa mutacji i krzyżowania oraz współczynnikwymiany pomiędzy wspólnotami. Liczba chromosomów we wspólnotach była dobrana tak,żeby łączny czas działania algorytmu był zbliżony (tzn. mniej chromosomów w każdej wspól-nocie dla większej liczby wspólnot) i wahała się od 64 do 2048. Podczas wstępnych testówwyodrębniłem wartości parametrów, które generowały często dobre rozwiązania oraz wybra-łem m.in. stosowaną funkcję kary oraz funkcje sterujące zmianą parametrów w czasie i dlanich przeprowadzałem dalsze testy.Tabelki 3.1, 3.2 i 3.3 przedstawiają wyniki (podane w tysiącach komórek, które nale-

żało przetworzyć do wyliczenia zapytań), w których testowane konfiguracje dawały rezultatyporównywalne z algorytmem zachłannym. Niższa wartość oznacza lepszy wynik.

Tryb Wsp. wymiany Wsp. mutacji Minimalny Średni[GHRU] 458465 458465[LH99] 514265 619305F1 V1 0 0.01 469530 492720F1 V1 0.01 0.01 460248 501930F1 V1 0.1 0.01 493969 528036F1 V1 0.1 0.05 455326 501183F1 V1 0.2 0.05 467957 510122F2 V2 0.1 0.05 468121 510652F4 V4 0.01 0.01 469121 503850F4 V4 0.1 0.01 468448 503732F4 V4 0.2 0.05 502186 522631F8 V4 0.1 0.05 468003 497019F8 V4 0.2 0.05 464341 520345F8 V8 0.01 0.01 468038 513427F8 V8 0.1 0.01 468615 530597F8 V8 0.1 0.05 458219 497786F8 V8 0.2 0.05 468107 507997

Tablica 3.1: Wyniki dla konfiguracji, które dawały rezultaty porównywalne z algorytmemzachłannym dla małej dostępnej przestrzeni dyskowej.Tryb: FnVm oznacza n wspólnot o stałej im wspólnot o zmiennej liczbie chromosomów. Innewartości oznaczają użycie odpowiednio [GHRU] – algorytmu zachłannego a [LH99] algorytmugenetycznego nieuwzględniającego indeksów.

Dla bardzo ograniczonej dostępnej przestrzeni dyskowej (a co za tym idzie ograniczeniana liczbę używanych indeksów) wszystkie algorytmy dawały zbliżone wyniki.

32


Tablica 3.2: Wyniki dla konfiguracji, które dawały rezultaty porównywalne z algorytmemzachłannym dla średniej ilości dostępnej przestrzeni dyskowej.Tryb: FnVm oznacza n wspólnot o stałej im wspólnot o zmiennej liczbie chromosomów. Innewartości oznaczają użycie odpowiednio [GHRU] – algorytmu zachłannego a [LH99] algorytmugenetycznego nieuwzględniającego indeksów.

Przy dużej ilości dostępnej przestrzeni dyskowej (gdzie można było wybrać bardzo dużoperspektyw i indeksów) najlepsze wyniki dawał algorytm zachłanny. Jednak, ze względu nato, że dodawane było bardzo dużo perspektyw i indeksów (a w rezultacie należało wielokrotniewykonywać obliczenia w głównej pętli algorytmu – zobacz 1.9.2), algorytm zachłanny działałw tym przypadku zdecydowanie wolniej. W tym przypadku konfiguracje z większą liczbąwspólnot dawały istotnie lepsze wyniki od konfiguracji z małą liczbą wspólnot (w szczególno-ści dotyczy to średnich uzyskanych rezultatów). Uważam, że potwierdza to tezę o mniejszejpodatności konfiguracji z większą liczbą wspólnot na zdominowanie przez sub-optymalne roz-wiązania.W wersji pośredniej, najlepsze wyniki uzyskane przez większość konfiguracji były lepsze

od wyników algorytmu zachłannego. Wyniki średnie większości konfiguracji były zbliżone.Podsumowując: wykorzystanie wspólnot wpływało na polepszenie średnich rezultatów,

czyli częstsze uzyskiwanie akceptowalnych wyników. Uważam, że w przypadku aplikacjiodpowiadającej za optymalizację produkcyjnej hurtowni danych, powtarzalne uzyskiwaniedobrych rezultatów jest ważniejsze od sporadycznego uzyskiwania bardzo dobrych wyników.Dodatkowo, w każdej konfiguracji łączna liczba chromosomów była zbliżona (czyli przy 16wspólnotach każda z nich miała około 8 razy mniej chromosomów niż przy 2 wspólnotach).Stąd, przy użyciu maszyny wieloprocesorowej, duża liczba wspólnot umożliwia uzyskaniezbliżonych lub lepszych wyników w znacznie krótszym czasie.Zauważmy, że rozwiązanie oparte o programowanie ewolucyjne daje zbliżone wyniki do

algorytmu zachłannego oraz (dzięki uwzględnieniu indeksów) znacznie lepsze wyniki od po-mysłu zaprezentowanego w pracy [LH99].

33


Tablica 3.3: Wyniki dla konfiguracji, które dawały rezultaty porównywalne z algorytmemzachłannym dla dużej dostępnej przestrzeni dyskowej.Tryb: FnVm oznacza n wspólnot o stałej im wspólnot o zmiennej liczbie chromosomów. Innewartości oznaczają użycie odpowiednio [GHRU] – algorytmu zachłannego a [LH99] algorytmugenetycznego nieuwzględniającego indeksów.

34

Rozdział 4

Podsumowanie

Celem pracy było zaproponowanie i zbadanie metody wyboru perspektyw do zmateriali-zowania oraz indeksów w hurtowni danych przy użyciu mechanizmów programowania ewolu-cyjnego. Postawiony cel został osiągnięty. Wyniki generowane przez sugerowane przeze mnierozwiązanie są często lepsze od najbardziej popularnego w literaturze mechanizmu, opartegoo algorytm zachłanny. Dzięki uwzględnieniu w modelu wpływu indeksów na wykonywaniezapytań, uzyskane wyniki są znacznie lepsze od wyników pierwowzoru, zaprezentowanegow pracy [LH99].Użyte mechanizmy programowania ewolucyjnego pozwoliły na stworzenie systemu dają-

cego w krótkim czasie dobre i powtarzalne wyniki, pomimo wykorzystania niedeterministycz-nych mechanizmów. Udało się również ograniczyć zbieżność rozwiązań do lokalnych optimum.W szczególności dotyczy to przypadku z dużą ilością dostępnej przestrzeni dyskowej.Dodatkowo, proponowane przeze mnie rozwiązanie umożliwia równoległe wykonywanie

obliczeń, co pozwala na dalsze przyspieszenie działania przy wykorzystaniu maszyny wielo-procesorowej.W pracy [KR99] opisano system DynaMat, będący warstwą pośrednią pomiędzy aplika-

cją kliencką a hurtownią danych i służący do dynamicznego materializowania potrzebnychperspektyw (i usuwania nieużywanych) oraz zarządzania pamięcią podręczną (cache) w za-leżności od działalności użytkowników (bieżącej i historycznej). Ciekawym rozszerzeniemzaprezentowanego przeze mnie pomysłu mogłoby być stworzenie podobnego systemu opar-tego o programowanie ewolucyjne, z wykorzystaniem mechanizmów używanych w systemachadaptacyjnych – m.in. poliploidalności dla “zapamiętywania” w chromosomach rozwiązań,które okazały się korzystne w przeszłości i mogą być przydatne w przyszłości.

35

Dodatek A. Załączniki

Do pracy została dołączona płyta CD zawierająca:

• niniejszą pracę magisterską w formacie PDF i TEX,

• źródła prototypowej implementacji opisywanego rozwiązania, implementacje algorytmuzachłannego (wersja opisana w pracy [GHRU]) i algorytmu genetycznego (opisanego w[LH99]) oraz środowisko testowe.

37

Bibliografia

[ACN00] Sanjay Agrawal, Surajit Chaudhuri, Vivek Narasayya, Automated Selection ofMaterialized Views and Indexes for SQL Databases, Proceedings of the 26th In-ternational Conference on Very Large Data Bases, 2000, pp. 496–505.

[AGS97] R. Agrawal, A. Gupta, S. Sarawagi, Modeling Multidimensional Databases, 13thInternational Conference on Data Engineering, 1997, pp. 232–243.

[ARM] The Open Group Technical Standard, Systems Management: Appli-cation Response Measurement (ARM) API, Document Number: C807,http://www.opengroup.org, 1998.

[ARMJB] The Open Group Technical Standard, Application Response Measure-ment (ARM) Issue 4.0 – Java Binding, Document Number: C037,http://www.opengroup.org, 2003.

[ASS] A. Abello, J. Samos, F. Saltor, A DataWarehouse Multidimensional Data ModelsClassification.

[BB03] Thomas Bartz-Beielstein, Experimental Analysis of Evolution Strategies – Ove-rview and Comprehensive Introduction, Technical Report of the CollaborativeResearch Centre 531 Computational Intelligence, CI-157/03, University of Do-rtmund, 2003.

[BFI91] K. Bennett, M.C. Ferris, Y.E. Ioannidis, A Genetic Algorithm for Database QueryOptimization, Univ. Wisconsin, Madison, Tech. Rep. TR1004, 1991.

[BPT97] E. Baralis, S. Paraboschi, E. Teniente, Materialized View Selection in a Multidi-mensional Database, The VLDB Journal, 1997, pp. 156–165.

[BRV00] Th. Back, A.E. Eiben, N.A.L. van der Vaart, An empirical study on GAs “withoutparameters”, Proceedings of the 6th International Conference on Parallel ProblemSolving from Nature, 2000, pp. 315–324.

[CD97] Surajit Chaudhuri, Umeshwar Dayal, An Overview of Data Warehousing andOLAP Technology, ACM SIGMOD Record, 26:1, 1997, pp. 65–74.

[CN] S. Chaudhuri, V. Narasayya, An Efficient, Cost-Driven Index Selection Tool forMicrosoft SQL Server, Microsoft Research.

[DeJ75] K.A. De Jong, An Analysis of the Behavior of a Class of Genetic Adaptive Systems,rozprawa doktorska, University of Michigan, 1975.

39

[DNR97] P.M. Deshpande, J.F. Naughton, K. Ramasamy, A. Shukla, K. Tufte, Y. Zhao,Cubing Algorithms, Storage Estimation, and Storage and Processing Alternativesfor OLAP, Bulletin of the Technical Committee on Data Engineering, 20, 1997.

[EHM99] A.E. Eiben, R. Hinterding, Z. Michalewicz, Parameter Control in EvolutionaryAlgorithms, IEEE Transactions on Evolutionary Computation, 3:2, 1999, pp.124–141.

[EMV04] A.E. Eiben, E. Marchiori, V.A. Valkó, Evolutionary Algorithms with on-the-flyPopulation Size Adjustment, Parallel Problem Solving from Nature, PPSN VIII,Vol. 3242, 2004, pp.41-50.

[Fei96] U. Feige, A threshold ln n for approximating set cover, Proc. 28th ACM Symp. onTheory of Computing, 1996, pp. 314–318.

[GHRU] Himanshu Gupta, Venky Harinarayan, Anand Rajaraman, Jeffrey D. Ullman,Index Selection for OLAP, Proceedings of the Thirteenth International Conferenceon Data Engineering, 1997, pp. 208–219.

[GL97] M. Gyssens, L.V.S. Lakshmanan, A Foundation for Multi-Dimensional Databases,Proceedings of the 23rd International Conference on Very Large Data Bases, 1997,pp. 106–115.

[GM99] H. Gupta, I. Mumick, Selection of Views to Materialize Under a MaintenanceCost Constraint, Proceedings of the International Conference on Database Theory,Jerusalem, pp. 1999, pp. 453–470.

[Gold] David E. Goldberg, Algorytmy genetyczne i ich zastosowania, Wydawnictwo Na-ukowo Techniczne, 2003.

[GR99] Kiran B. Goyal, Krithi Ramamritham, Indexing and Compression in Data Wa-rehouses, Proceedings of the International Workshop Design and Management ofData Warehouses, Heidelberg, 1999.

[Gup97] H. Gupta, Selection of Views to Materialize in a Data Warehouse, Proceedings ofthe International Conference on Database Theory, Delphi, 1997, pp. 98–112.

[Ha94] W.E. Hart, Adaptive Global Optimization with Local Search, rozprawa doktorska,University of California, San Diego, 1994.

[HCK] E. Hung, D.W. Cheung, B. Kao, Optimization in Data Cube System Design,

[HRU96] V. Harinarayan, A. Rajaraman, J.D. Ullman, Implementing data cubes efficiently,SIGMOD Record (ACM Special Interest Group on Management of Data), 25:2,1996, pp. 205–216.

[Hun00] E. Hung, Data Cube System Design: An Optimization Problem, praca magisterska,University of Hong Kong, 2000.

[JS97] T. Johnson, D. Shasha, Some Approaches to Index Design for Cube Forests, Bul-letin of the Technical Committee on Data Engineering, 20, 1997.

[Khan] N. Khan, Population Sizing in Genetic and Evolutionary Algorithms.

40

[Ko92] John R. Koza, Genetic Programming - On the programming of computers by meansof natural selection, Bradford Books, 1992.

[KR97] Y. Kotidis, N. Roussopoulos, A Generalized Framework for Indexing OLAP Ag-gregates, Technical Report CS-TR-3841, University of Maryland, 1997.

[KR99] Y. Kotidis, N. Roussopoulos, DynaMat: A Dynamic View Management Systemfor Data Warehouses, ACM SIGMOD International Conference on Managementof Data, 1999, pp. 371–382.

[LH99] M. Lee, J. Hammer, Speeding Up Warehouse Physical Design Using a RandomizedAlgorithm, University of Florida, Technical Report, 1999.

[LQA97] Wilburt Juan Labio, Dallan Quass, Brad Adelberg, Physical Database Design forData Warehouse, Proceedings of the International Conference of Data Engine-ering, 1997, pp. 277–288.

[LSTV99] Spyros Ligoudistianos, Timos Sellis, Dimitri Theodoratos, Yannis Vassiliou, Heu-ristic Algorithms for Designing a Data Warehouse with SPJ Views, Proc. of the1st Intl. Conf. on Data Warehousing and Knowledge Discovery, Florence, 1999,pp. 66–105.

[Mic03] Zbigniew Michalewicz, Algorytmy genetyczne + struktury danych = programy ewo-lucyjne, Wydawnictwo Naukowo Techniczne, 2003.

[Mit98] M. Mitchell, An Introduction to Genetic Algorithms, Bradford Books, 1998.

[MSDN] MSDN library, MS SQL Server 2000 Documentation,http://msdn.microsoft.com/library.

[FASMI] The OLAP Report, http://www.olapreport.com/fasmi.htm.

[Pak] M.K. Pakhira, A Hybrid Genetic Algorithm using Probabilistic Selection.

[PT] Thomas P. Nadeau, Toby J. Teorey, A Pareto Model for OLAP View Size Esti-mation, Proceedings of the 2001 conference of the Centre for Advanced Studieson Collaborative research, Toronto, 2001, p. 13.

[Sap99] Carsten Sapia, On Modeling and Predicting Query Behavior in OLAP Systems,Proceedings of the Intl. Workshop on Design and Management of Data Wareho-uses, Heidelberg, 1999.

[Sar97] S. Sarawagi, Indexing OLAP Data, Bulletin of the Technical Committee on DataEngineering, 20, 1997.

[Scha] R. Schafer, Using a diploid genetic algorithm to create and maintain a complexsystem in dynamic equilibrium.

[SDN96] A. Shukla, P.M. Deshpande, J.F. Naughton, K. Ramasamy, Storage Estimationfor Multidimensional Aggregates in the Presence of Hierarchies, VLDB, Bombay,1996, pp. 522–531.

[SDN98] Amit Shukla, Prasad M. Deshpande, Jeffrey F. Naughton, Materialized View Se-lection for Multidimensional Datasets, Proceedings of the 24rd International Con-ference on Very Large Data Bases, 1998, pp. 488–499.

41

[Si00] A. Sinha, Designing Efficient Genetic and Evolutionary Algorithm Hybrids, pracamagisterska, University of Illinois, 2003.

[Sm98] J.E. Smith, Self Adaptation in Evolutionary Algorithms, rozprawa doktorska, Uni-versity of the West of England, 1998.

[SMDX] SAS 9.1.3 OLAP Server MDX Guide, http://support.sas.com/documentation/onlinedoc/91pdf/sasdoc 913/olap mdx 8379.pdf, SAS Institute, 2004.

[Sp98] W.M. Spears, The Role of Mutation and Recombination in Evolutionary Algori-thms, rozprawa doktorska, George Mason University, Virginia, 1998.

[ST01] C. Di Stefano, A.G.B. Tettamanzi, An Evolutionary Algorithm for Solving theSchool Time-Tabling Problem, Proceedings of the EvoWorkshops on Applicationsof Evolutionary Computing, 2001.

[SS96] M. Stillger, M. Spiliopoulou, Genetic Programming in Database Query Optimiza-tion, Proc First Annu. Conf. Genetic Programming, Stanford, CA, 1996.

[SVM] D. Schlierkamp-Voosen, H. Muhlenbein, Adaptation of Population Sizes by Com-peting Subpopulations.

[TC02] Shisanu Tongchim, Prabhas Chongstitvatana, Parallel genetic algorithm with pa-rameter adaptation, Information Processing Letters, 82:1, 2002, pp. 47–54.

[Tet96] A.G.B. Tettamanzi, Genetic Programming without Fitness, Genetic Programming1996 Conference Stanford University, 1996.

[Tom95] M. Tomassini, A Survey of Genetic Algorithms, Annual Reviews of ComputationalPhysics, Vol. III, World Scientific, 1995, pp. 87-118.

[TPC] Transaction Processing Performance Council, http://www.tpc.org.

[TPGS01] Juan Trujillo, Manuel Palomar, Jaime Gomez, Il-Yeol Song, Designing Data Wa-rehouses with OO Conceptual Models, Computer, 34:12, 2001, pp. 66-75.

[TS97] D. Theodoratos and T.K. Sellis, Data Warehouse Configuration, in Proceedingsof the 23rd International Conference on Very Large Databases, Athens, 1997,pp. 126–135.

[TS99] D. Theodoratos, T. Sellis, Dynamic Data Warehouse Design, Proc. Intl. Conf.on Data Warehousing and Knowledge Discovery, Florence, 1999, pp. 1–10.

[TU] Michael Teschke, Achim Ulbrich, Using Materialized Views To Speed Up DataWarehousing.

[Vas] Panos Vassiliadis, Modeling Multidimensional Databases, Cubes and Cube Opera-tions, Proceedings of the 10th International Conference on Scientific and StatisticalDatabase Management, 1999, pp. 53-62.

[VS99] Panos Vassiliadis, Timos Sellis, A Survey on Logical Models for OLAP Databases,ACM SIGMOD Record, 28:4, 1999, pp. 64–69.

42

[VVK02] Satyanarayana R. Valluri, Soujanya Vadapalli, Kamalakar Karlapalem, View Re-levance Driven Materialized View Selection in Data Warehousing Environment,Proceedings of the thirteenth Australasian conference on Database technologies –Volume 5, Melbourne, 2002, pp. 187–196.

[Wid95] J. Widom, Research Problems in Data Warehousing, Conference on Informationand Knowledge Management, Baltimore, 1995, pp. 25–30.

[WPZ03] Mark Whitehorn, Mosha Pasumansky, Robert Zare, Fast Track to MDX, SpringerVerlag, 2003.

[YKL96] Jian Yang, Kamalakar Karlapalem, Q. Li, A Framework for Designing Materiali-zed View in Data Warehousing Environment, Technical Report HKUST-CS96-35,The Hong Kong University of Science & Technology, 1996.

[YKL97] Jian Yang, Kamalakar Karlapalem, Q. Li, Algorithms for Materialized View De-sign in Data Warehousing Environment, Proceedings of the 23rd InternationalConference on Very Large Data Bases, 1997, pp. 136–145.

43

Documents

Uniwersytet Warszawski Wydział Matematyki, Informatyki i ...students.mimuw.edu.pl/~os/download/mgr.pdf · w hurtowni danych Praca magisterska na kierunku INFORMATYKA w zakresie HURTOWNIE